Скачать презентацию PRO-2017 -0196 Further input to the discussion on Скачать презентацию PRO-2017 -0196 Further input to the discussion on

56231313869d974eb1717078d20cbf97.ppt

  • Количество слайдов: 10

PRO-2017 -0196 Further input to the discussion on Service Layer Protocol Version Handling Group PRO-2017 -0196 Further input to the discussion on Service Layer Protocol Version Handling Group Name: PRO WG Source: Qualcomm Inc. , Wolfgang Granzow, Nobu Uchida, Josef Blanz Meeting Date: Joint PRO/ARC, PRO#30. 3, 2017 -08 -23 Agenda Item: Version Handling

Objective • This contributions provides some additional points for discussion complementary to those addressed Objective • This contributions provides some additional points for discussion complementary to those addressed in PRO 2017 -0194 • Following issues are addressed in this contribution: – Should the release version be indicated in both, request and response primitives? • Additional thoughts on forward and backward compatibility of primitive representations – Should every resource representation include a reference to the XSD it complies with? – Version handling issues for end-2 -end security use cases 2

Forward and backward compatibility of primitives • Backward compatibility – A serialized representation of Forward and backward compatibility of primitives • Backward compatibility – A serialized representation of an object (e. g. resource representation or primitive) compliant with „lower release version“ (e. g. R 2) is still schema-valid with respect to the XSD of some „higher release version“ (e. g. R 3) • Forward compatibility – A serialized representation of an object (e. g. resource representation or primitive) compliant with „higher release version“ (e. g. R 3) is still schema-valid with respect to the XSD of some „lower release version“ (e. g. R 2) 3

Impact of XSD changes on forward/backward comp. Action Data type Addition of element any Impact of XSD changes on forward/backward comp. Action Data type Addition of element any Removal of element Details of action Optionality /multipl. BC FC Optional × Mandatory × × O M × × M O × × lower × higher × change in xs: sequence × × change in xs: all × any change of optionality Modification of element any change of multiplicity 4

Impact of XSD changes on forward/backward comp. Action Data type Modification of element BC Impact of XSD changes on forward/backward comp. Action Data type Modification of element BC FC more × less × × Removed enums × Replaced enums Enumerated type Detail Additional enums General simple type Details of action × × value restrictions Addition of element Complex type Removal of element as on previous slide Modif. of element 5

FC/BC of primitives and Content • TS-0004 already differentiates between „control part“ and „Content FC/BC of primitives and Content • TS-0004 already differentiates between „control part“ and „Content part“ TS-0004: Figure 5. 4. 2‑ 1: Primitives modelling 6

FC/BC of primitives and Content • Data type of the Content parameter is xs: FC/BC of primitives and Content • Data type of the Content parameter is xs: any with process. Contents = “lax“ • This means schema validity of the Content parameter is evaluated only if the XSD of the global element included in the Content is available – A CSE doesn‘t need to check schema validity of Content for resource types it doesn‘t support – This is especially important when working with specializations • Version handling should allow differentiation between the version of the primitive „control part“ and version of resource representations in the „content part“ 7

Indication of release version in primitives • Should we define 2 different version indicators Indication of release version in primitives • Should we define 2 different version indicators for control and content parts of a primitive? – This is not needed when it is mandated by definition that the version indicated in a primitive shall also apply to specific resource representations included in the Content parameter – specific resource representations means • it applies to all global elements and resource types defined in the namespace with prefix „m 2 m: “, except for any specializations • The version of specializations should be implicitly visible from the container. Definition attribute • it does not apply to resource types defined with another namespacre prefix (e. g. „hd“) 8

Indication of release version in primitives • Using the approach described on the previous Indication of release version in primitives • Using the approach described on the previous slide – Avoids the need to define a second version indicator applicable to the primitive Content parameter – Avoids the addition of a new universal resource attribute which would indicate the version of resource representations for resource types prefixed with m 2 m: (as described on the previous page) – Implies that also response primitives should be enabled to include a release version indicator in order to clearly define the version the Content parameter complies with 9

Version indication for end-to-end security frameworks • When applying end-to-end security frameworks defined in Version indication for end-to-end security frameworks • When applying end-to-end security frameworks defined in TS-0003, there is currently no way that source and target end nodes can confirm each other that tey support compatible release versions • When using MEF and MAF based procedures, version negotiation could be implemented in the MAF and MEF client registration procedures similarly as discussed for and registration – This could be implement for the next release of TS-0022 • When using direct End-to-End Security Certificate based Key Establishment (ESCert. KE) MAF and MEF are not needed • We conclude that explicit indication of the release version in request and response primitives is highly desirable for support of E 2 E security frameworks 10