Change:
11.2. IANA will create a new registry for SenML labels.  The initial <del> content of the registry are shown in tbl-json-labels and tbl-xml- labels. </del> <ins> content of the registry is: Note to RFC Editor.  Please replace RFCXXXX with the number for this RFC. All new entries must define the Label Name, Label, and XML Type but the CBOR labels SHOULD be left empty as CBOR will use the string encoding for any new labels.  The ID fields contains the EXI schemaID of the first Schema which includes this label or is empty if this label was not intended for use with EXI.  The Note field SHOULD contain information about where to find out more information about this label. The JSON, CBOR, and EXI types are derived from the XML type.  All XML numeric types such as double, float, integer and int become a JSON Number.  XML boolean and string become a JSON Boolean and String respectively.  CBOR representes numeric values with a CBOR type that does not loose any information from the JSON value.  EXI uses the XML types. </ins> New entries can be added to the registration by either Expert Review or IESG Approval as defined in RFC5226.  Experts should exercise their own good judgment but need to consider that shorter labels should have more strict review. <del> All new SenML labels that have "base" semantics (see senml-base) must start with character 'b'.  Regular labels must not start with that </del> <ins> All new SenML labels that have "base" semantics (see senml-base) MUST start with character 'b'.  Regular labels MUST NOT start with that </ins> character. <del> All new entries must define the Label Name, Label, JSON Type, and XML Type. </del> <ins> Extensions that add a label that is intended for use with XML need to create a new RelaxNG scheme that includes all the labels in the IANA registry. Extensions that add a label that is intended for use with EXI need to create a new XSD Schema that includes all the labels in the IANA registry then allocate a new EXI schemaID.  Moving to the next letter in the alphabet is the suggested way to create the new EXI schemaID. Any labels with previously blank ID values SHOULD be updated in the IANA table to have their ID set to this new schemaID value. </ins> 11.3.

Discussion:
From EMAIL - aug 31 Hello Ari, I'm just putting the finishing touches on an IETF draft to introduce the base time offset attribute that we discussed in Berlin. One thing I noticed was that the IANA considerations section (11.2) that describes the SenML label registry mentions the need to define the label name, label, json type and xml type for the new attribute. However the SenML draft also defines the CBOR representation and EXI representation. I assume updates to these will also be needed in order to register a new SenML label? For the XML representation the IANA text mentions the need to define the XML type. However section 7 "XML representation" includes the RelaxNG compact schema. Does this also need to be updated? and if so how? Should the entire schema be listed or should a new schema be defined using an "include" construct? The schema in the SenML draft doesn't have a name (e.g. URL) so I'm not sure how this would be done? The other issue is that the current compact RelaxSchema enforces ordering of the labels. If I define a new bto attribute I take it that bto should be associated with the base attributes and come after bver and before the regular attributes. I'm not familiar enough with RelaxNG to detail that without re-including the entire schema. It also leads to the question of what happens with ordering if someone else defines another base attribute. Should bto or the other attribute take precedence after bver? I think the syntax and draft needs to take this into account. The EXI representation clause 8 in the SenML draft includes an XSD generated from the RelaxNG. Would the generation of the complete schema be required for the addition of an new attribute? There seems to be similar issues to the RelaxNG schema. For CBOR there's also the CDDL specification in section 10. I'm not that familiar with CDDL but it seems to define an extension mechanism that group the base and regular attributes. There's no text associated with this section as to the need to define extensions and whether the defining the JSON label and type is enough for the CDDL. It seems to me that the schemes need to be updated to include some extension points to enable new attributes to be added without having to update the schemas.

Also given that we have to define these various different representations I wonder if the registry should instead be called the SenML attribute registry? The reasoning is that the registry would have to include not only JSON labels but the CBOR mapping key etc. Regards, Christian