1. Joint PRO/ARC session 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. ClauseDescriptionARCPRO 8.1Notification URI structureN/ACR needed 8.2Notification Content formatCR needed 8.3Structured resource URI formatN/ACR needed 8.4Timestamp formatN/APRO-2015-0996/7 8.5Ability to use milliseconds in timestampsN/ACR needed 8.6XSD file version consistencyN/A? 8.7XSD validationN/A? 8.8Root element in JSON representationN/APRO-2015-0915 8.9Representation of JSON listsN/A? Interop test findings -1

6. ClauseDescriptionARCPRO 8.10Altering resourceName by the server?PRO-2015-0961 8.11Notification event type default?PRO-2015-1006/7 8.12Notification type 3 (direct child creation)?? 8.13SP-ID position in resource URI?? 8.14HTTP header case sensitivityN/APRO-2015-1002/3 8.15Contents of update responseN/A? 8.16Default ACP for registered AE’sN/A? 8.17HTTP conflict status code inconsistencyN/APRO-2015-1013/4 8.18ResourceID attribute structure?CR needed Interop test findings -2

7. 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