1. PRO/ARC and TST/PRO joint sessions at TP20 Group Name: oneM2M TP20 Source: Peter Niblett, IBM Meeting Date: 2015-11-09

2. Items for discussion ResourceName attribute vs Name Primitive parameter Findings of interop test TS-0001 / TS-0004 Alignment Stage 3 contributions for R2 items

3. Resource Name © 2015 oneM2M Partners 3 Current status – R1 versions of TS-0001 and TS-0004 contain both a Name primitive parameter and a resourceName universal attribute The idea is you use the Name parameter to request a name on a create request, but the actual name (which may be different) is returned in the resourceName attribute There are some contradictions in the current drafts of these documents, which has led to some confusion among implementers – The Name primitive parameters has been removed from the R2 version of TS-0001 On create, you now supply the name that you want in the resourceName attribute – this may then get modified by the hosting CSE WG3 has CRs in progress to remove the Name parameter from R2 versions of TS-0004 and the various protocol bindings TS documents Questions – What changes do we make to R1 ? – Under what circumstances is the hosting CSE allowed to modify the value (8.10)?

4. Resource Name options © 2015 oneM2M Partners 4 1.Remove the Name parameter from release 1 versions of TS-0001 / TS-0004 and the bindings documents. In other words mirror the R2 changes back into R1. 2.Leave the Name parameter in release 1 version of TS-0001 / TS-0004, but update TS-0004 to permit (or possibly encourage) the use of the ResourceName attribute on Create as an alternative. 3.Leave the definition of the Name parameter in release 1 of TS-0001 / TS- 0004 and update the text in TS-0004 to make it clear that you use this parameter (not the ResourceName) on Create. The consequence of this is that release 1 and release 2 will be different. 4.Add the Name parameter back into release 2, and clarify its use on create (i.e. reverse the decision to remove it)

5. ResourceName decisions 1.What changes do we make to R1 ? Go with option 1 from previous slide (remove Name primitive parameter from R1) PRO-2015-1036, PRO-2015-1037, PRO-2015-1038, PRO-2015-1039 2.Under what circumstances is the hosting CSE allowed to modify the value (8.10)? Never. It either accepts the value provided by the requester or it rejects the Create request entirely PRO-2015-0961R02, PRO2015-0962R02

6. ClauseDescriptionARCPRO 8.1Notification URI structureCR needed CR needed for R1 and R2 8.2Notification Content formatARC-2015-2043 CR needed – pending ARC 8.3Structured resource URI formatCR requested CR needed for R1 and R2 8.4Timestamp formatN/APRO-2015-0996/7 8.5Ability to use milliseconds in timestampsN/A CR needed for R1 and R2 8.6XSD file version consistencyN/A Done PRO-2015-0898R01 8.7XSD validationN/A Consider making more flexible for R2 8.8Root element in JSON representationN/A Done PRO-2015-0915 8.9Representation of JSON listsN/ALeave as is Interop test findings - 1

7. ClauseDescriptionARCPRO 8.10Altering resourceName by the serverCR neededPRO-2015-0961 8.11Notification event type defaultN/APRO-2015-1006/7 8.12Notification type 3 (direct child creation)CR needed CR needed – pending ARC 8.13SP-ID position in resource URIN/A CR needed to clarify in TS- 0008 8.14HTTP header case sensitivityN/APRO-2015-1002/3 8.15Contents of update responseN/A TS-0004 says what should happen 8.16Default ACP for registered AE’sInitial config CRN/A 8.17HTTP conflict status code inconsistencyN/APRO-2015-1013/4 8.18ResourceID attribute structureN/ACR needed Interop test findings -2

8. ClauseDescriptionARCPRO 8.19Make RequestID optional?? 8.19Less verbose media typesN/A? 8.19Make Response Status Code optionalN/A? 8.20Allow both long and short names?? 8.20Support other encodings (e.g. binary ones)?? Interop test findings -3

9. Resolutions 8.1 Notification URI – Must be a proper resource reference 8.2 Notification Format – Add new attribute to AE and CSE resources 8.3 Structured URI format – Ask for. To be allowed for CSEName in R1 8.4 Timestamp Format – Example to be corrected in TS-0004

10. Resolutions 8.5 Milliseconds in timestamps – Datatype to be changed to allow arbitrary number of decimal places in the Seconds field 8.6 XSD consistency – Already fixed in TS-0004 1.4.0 8.7 XSD validation of Requests and Responses – To be considered for R2 8.8 Root element in JSON – Already clarified in TS-0004 1.4.0 8.9 Representation of JSON lists – No change

11. Resolutions 8.11 Notification event type default – Update_of_resource is the default 8.12 Notification type 3 Content – Prefer notification to allow you to get the child 8.13 SP-ID position in resource URI – TS-0009 is correct 8.14 HTTP Header case sensitivity – Headers are case insensitive (HTTP spec) 8.15 Update response – Just the updated values - see TS-0001