Hi Hannes and *Deb (AD), Thank you for providing your approval; we have noted so at <https://www.rfc-editor.org/auth48/rfc9999>. We will now ask IANA to update their registries to match the edited document. We will inform you once the updates are complete.
*Deb, we wanted to ensure you saw the June 2nd email regarding the differences between the registries for CWT and JWT claims. If any changes should be made, please let us know (email copied below for ease). > On Jun 2, 2026, at 8:53 AM, Megan Ferguson <[email protected]> > wrote: > > ADs, > > We were wondering if we could get your take on the following that the IANA > review of this document pointed out to us. > > We noticed that there are two really similar IANA registries for CWT Claims > and JWT Claims; however, the registries are treated a little differently: > > 1) The Registry Group names don’t follow the same pattern: > > CBOR Web Token (CWT) Claims = registry group name > CBOR Web Token (CWT) Claims = registry > https://www.iana.org/assignments/cwt > Appears in Section 9.1 of this document > > JSON Web Token (JWT) = registry group > JSON Web Token Claims = registry > https://www.iana.org/assignments/jwt > Appears in Section 9.2 of this document > > Should “Claims” be removed from the “CBOR Web Token (CWT) Claims” registry > group name? In chatting with IANA, they were in favor of this change for > consistency but also because it may sound as if other types of CWT registries > would not fit there. > > 2) Also, the CWT registry has a column for the “JWT Claim Name”, but the JWT > registry does not have a column to mention the corresponding CWT Claim > Name...the template for CWTs in RFC 8392 calls for the JWT to be listed as > “corresponding”, but the template in RFC 7519 for JWTs does not call for a > CWT to be listed (likely because it came first): > > From RFC 8392: > JWT Claim Name: > Claim Name of the equivalent JWT claim, as registered in > [IANA.JWT.Claims]. CWT claims should normally have a > corresponding JWT claim. If a corresponding JWT claim would not > make sense, the Designated Experts can choose to accept > registrations for which the JWT Claim Name is listed as "N/A". > > Is this a reciprocal relationship that the JWT Claims registry should be > updated to capture? > > If so, chatting with IANA, they pointed out that RFC 8126, Section 2.4 does > give ADs latitude to approve new columns sometimes: > > Under some circumstances, such as with a straightforward change that is > clearly needed (such as adding a "status" column), or when an earlier error > needs to be corrected, the IESG may approve an update to a registry without > requiring a new document. > > Not sure if this case would fit into that or if this would cause the need for > an I-D (or is even necessary at all). > > We look forward to hearing your thoughts. > > Megan Ferguson > RFC Production Center Best regards, Karen Moore RPC Production Center > On Jun 23, 2026, at 12:35 AM, Hannes Tschofenig <[email protected]> > wrote: > > I also believe this document is ready for publication. > > Thanks for the work! > > > Am 18.06.2026 um 20:59 schrieb Karen Moore: >> Hi Ned, >> >> Thank you for your reply. We have noted your approval at >> https://www.rfc-editor.org/auth48/rfc9999. >> >> We now await approval from Hannes prior to moving forward with publication. >> >> Best regards, >> Karen Moore >> RFC Production Center >> >>> On Jun 17, 2026, at 5:09 PM, Ned Smith IETF <[email protected]> >>> wrote: >>> >>> Karen, >>> I believe it is ready for publication. >>> Thanks, >>> Ned >>> >>> From: Karen Moore <[email protected]> >>> Sent: Wednesday, 17 June 2026 15:04:57 >>> To: Henk Birkholz <[email protected]>; [email protected] >>> <[email protected]>; [email protected] >>> <[email protected]>; Thomas Fossati <[email protected]> >>> Cc: [email protected] <[email protected]>; >>> [email protected] <[email protected]>; >>> [email protected] <[email protected]>; [email protected] >>> <[email protected]>; [email protected] >>> <[email protected]>; [email protected] >>> <[email protected]>; Deb Cooley <[email protected]> >>> Subject: Re: Final Review: RFC-to-be 9999 (draft-ietf-rats-msg-wrap) for >>> your review Hi Henk, >>> >>> Thank you for your reply. We have noted your approval (see >>> https://www.rfc-editor.org/auth48/rfc9999). >>> >>> We now await approvals from Hannes and Ned. >>> >>> Best regards, >>> >>> Karen Moore >>> RPC Production Center >>> >>> >>>> On Jun 17, 2026, at 12:58 PM, Henk Birkholz <[email protected]> >>>> wrote: >>>> >>>> Karen, >>>> >>>> thank you for the nudge! Yes, of course. Thomas is our shining example of >>>> not dropping the ball here. >>>> >>>> This document is ready for publication. >>>> >>>> >>>> Viele Grüße, >>>> >>>> Henk >>>> >>>> On 17.06.2026 21:08, Karen Moore wrote: >>>>> Dear Hannes, Henk, and Ned, >>>>> We do not believe we have heard from you regarding this document's >>>>> readiness for publication. Please review the files below and let us know >>>>> if any further updates are needed or if the document is ready for >>>>> publication. >>>>> https://www.rfc-editor.org/authors/rfc9999.xml >>>>> https://www.rfc-editor.org/authors/rfc9999.txt >>>>> https://www.rfc-editor.org/authors/rfc9999.html >>>>> https://www.rfc-editor.org/authors/rfc9999.pdf >>>>> https://www.rfc-editor.org/authors/rfc9999-diff.html >>>>> https://www.rfc-editor.org/authors/rfc9999-rfcdiff.html (side by side) >>>>> https://www.rfc-editor.org/authors/rfc9999-auth48diff.html >>>>> https://www.rfc-editor.org/authors/rfc9999-auth48rfcdiff.html (side by >>>>> side) >>>>> For the status of this document, please see: >>>>> https://www.rfc-editor.org/auth48/rfc9999 >>>>> We will wait to hear from you before continuing with the publication >>>>> process. >>>>> Thank you. >>>>> Karen Moore >>>>> RFC Production Center >>>>>> On Jun 11, 2026, at 10:59 AM, Karen Moore <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Hi Deb, >>>>>> >>>>>> Thank you for the review. We have noted your approval at >>>>>> <https://www.rfc-editor.org/auth48/rfc9999>. >>>>>> >>>>>> We now await approval of the document from Hannes, Henk, and Ned prior >>>>>> to moving forward with publication. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Karen Moore >>>>>> RPC Production Center >>>>>> >>>>>> >>>>>>> On Jun 11, 2026, at 3:19 AM, Deb Cooley <[email protected]> wrote: >>>>>>> >>>>>>> I approve. >>>>>>> >>>>>>> I'm sorry that Dionna Glaze had to be moved to the ack section, it is >>>>>>> too bad they can't be an author as an 'individual', ie. w/out work >>>>>>> affiliation. >>>>>>> >>>>>>> Deb >>>>>>> >>>>>>> On Wed, Jun 10, 2026 at 6:16 PM Karen Moore >>>>>>> <[email protected]> wrote: >>>>>>> Hi Deb (AD), >>>>>>> >>>>>>> Please review the updates in Sections 3.1.1, 5.4, and 9.6.2 and let us >>>>>>> know if you approve. The updates are outlined below for ease and can be >>>>>>> viewed here: https://www.rfc-editor.org/authors/rfc9999-auth48diff.html. >>>>>>> >>>>>>> 1) Section 3.1.1 >>>>>>> >>>>>>> Original: >>>>>>> As such, it indicates which bits are allowed to be set in the ind >>>>>>> byte string. >>>>>>> >>>>>>> Current: >>>>>>> As such, it indicates which bits are allowed to be set in the ind >>>>>>> byte bitmap. >>>>>>> >>>>>>> ... >>>>>>> 2) In the second figure in Section 5.4, the following line was updated: >>>>>>> >>>>>>> Original: >>>>>>> d28440a044d901f5a040 # "҄@\xA0D\xD9\u0001\xF5\xA0\@" >>>>>>> >>>>>>> Current: >>>>>>> d28440a044d901f5a040 # serialized CM value >>>>>>> >>>>>>> Rationale: >>>>>>> [TF] The annotations are automatically generated by Carsten's >>>>>>> cbor2pretty.rb >>>>>>> tool. In this case, we don't think there's any reason to attempt a >>>>>>> string conversion, as the encoded message is just a series of random >>>>>>> bytes. If this is a problem, we suggest replacing the string in the >>>>>>> comment with an ellipsis, as no information would really be lost. >>>>>>> >>>>>>> After some more discussion, we believe that it's worth annotating it >>>>>>> with something more meaningful like "serialized CM value” >>>>>>> >>>>>>> ... >>>>>>> 3) Section 9.6.2 (Table 4) >>>>>>> >>>>>>> Original: >>>>>>> Tag Number Tag Content >>>>>>> 1668547091 bytes .cbor cbor-cmw >>>>>>> 1668547092 bytes-wrapped json-cmw >>>>>>> 1668547093 bytes .cbor signed-cbor-cmw >>>>>>> 1668547094 bytes-wrapped signed-json-cmw >>>>>>> >>>>>>> Current: >>>>>>> Tag Number Tag Content >>>>>>> 1668547091 bytes .cbor cbor-collection >>>>>>> 1668547092 bytes .cbor signed-cbor-cmw >>>>>>> 1668547093 bytes-wrapped json-collection >>>>>>> 1668547094 bytes-wrapped signed-json-cmw >>>>>>> >>>>>>> ... >>>>>>> 4) Dionna Glaze was removed from the author list and added to the >>>>>>> Acknowledgements section. >>>>>>> >>>>>>>> [DG] Apple still hasn’t approved my contributions to ietf, so you >>>>>>>> might as well remove me from authors >>>>>>> >>>>>>> —Files (please refresh)— >>>>>>> >>>>>>> Note: We will await approvals from Hannes, Henk, and Ned prior to >>>>>>> moving forward with publication. >>>>>>> >>>>>>> Updated XML file: >>>>>>> https://www.rfc-editor.org/authors/rfc9999.xml >>>>>>> >>>>>>> Updated output files: >>>>>>> https://www.rfc-editor.org/authors/rfc9999.txt >>>>>>> https://www.rfc-editor.org/authors/rfc9999.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9999.html >>>>>>> >>>>>>> Diff files showing all changes made during Final Review (formally >>>>>>> AUTH48): >>>>>>> https://www.rfc-editor.org/authors/rfc9999-auth48diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9999-auth48rfcdiff.html (side by >>>>>>> side) >>>>>>> >>>>>>> Diff files showing only changes made during the last editing round: >>>>>>> https://www.rfc-editor.org/authors/rfc9999-lastdiff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9999-lastrfcdiff.html (side by >>>>>>> side) >>>>>>> >>>>>>> Diff files showing all changes: >>>>>>> https://www.rfc-editor.org/authors/rfc9999-diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9999-rfcdiff.html (side by side) >>>>>>> >>>>>>> For the status of this document, please see: >>>>>>> https://www.rfc-editor.org/auth48/rfc9999 >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Karen Moore >>>>>>> RFC Production Center >>>>>>> >>>>>>> >>>>>>>> On Jun 10, 2026, at 10:35 AM, Thomas Fossati >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> Hi Karen, >>>>>>>> >>>>>>>> On Wed, 10 Jun 2026 at 19:22, Karen Moore >>>>>>>> <[email protected]> wrote: >>>>>>>>> Hi Thomas, >>>>>>>>> >>>>>>>>> Thank you for the nice comment. Note that we have updated Hannes’ >>>>>>>>> affiliation and marked your approval. >>>>>>>> Thanks! >>>>>>>> >>>>>>>>> In terms of removing "this example uses line wrapping per [RFC8792]” >>>>>>>>> within the figure in Section 5.4, note that other RFCs typically >>>>>>>>> contain this text within the figure as well as in the running text >>>>>>>>> (we add it to the running text if not present in order to cite RFC >>>>>>>>> 8792). Please see RFCs 9644, 9834, and 9950 as examples. >>>>>>>>> >>>>>>>>> Given this, we have left the text as is. >>>>>>>> OK, as usual, I'll leave it to your superior judgement :-) >>>>>>>> >>>>>>>>> Another option would be to remove "(this example uses line wrapping >>>>>>>>> per [RFC8792])” from Section 5.4 and instead state the following in >>>>>>>>> Section 2: >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> The example in Section 5.4 uses line wrapping per [RFC8792]. >>>>>>>>> >>>>>>>>> Please review and let us know your preference. >>>>>>>> I'm fine with leaving it as it is. >>>>>>>> >>>>>>>> cheers! >>>>>>>> >>>>>>>>> —Files (please refresh)— >>>>>>>>> >>>>>>>>> Updated XML file: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9999.xml >>>>>>>>> >>>>>>>>> Updated output files: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9999.txt >>>>>>>>> https://www.rfc-editor.org/authors/rfc9999.pdf >>>>>>>>> https://www.rfc-editor.org/authors/rfc9999.html >>>>>>>>> >>>>>>>>> Diff files showing all changes made during Final Review (formally >>>>>>>>> AUTH48): >>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-auth48diff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-auth48rfcdiff.html (side >>>>>>>>> by side) >>>>>>>>> >>>>>>>>> Diff files showing only changes made during the last editing round: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-lastdiff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-lastrfcdiff.html (side by >>>>>>>>> side) >>>>>>>>> >>>>>>>>> Diff files showing all changes: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-diff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-rfcdiff.html (side by side) >>>>>>>>> >>>>>>>>> For the status of this document, please see: >>>>>>>>> https://www.rfc-editor.org/auth48/rfc9999 >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Karen Moore >>>>>>>>> RFC Production Center >>>>>>>>> >>>>>>>>>> On Jun 9, 2026, at 10:41 PM, Thomas Fossati >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> Hi Karen, thanks for the update. >>>>>>>>>> >>>>>>>>>> (nearly) Everything looks very good. >>>>>>>>>> >>>>>>>>>> On doing another scan, I noticed a couple of minor issues: >>>>>>>>>> 1. Hannes' affiliation is still reported as H-BRS in the header, but >>>>>>>>>> it should be "UniBw M." >>>>>>>>>> 2. In §5.4, since the prose now says "this example uses line wrapping >>>>>>>>>> per [RFC8792]", we could remove the similar text from the example >>>>>>>>>> just >>>>>>>>>> below. >>>>>>>>>> >>>>>>>>>> Once these two items are fixed, I approve publication of the >>>>>>>>>> document. >>>>>>>>>> >>>>>>>>>> Thank you very much for the great work! >>>>>>>>>> >>>>>>>>>> cheers, t >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, 9 Jun 2026 at 22:50, Karen Moore >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> Hi Thomas, >>>>>>>>>>> >>>>>>>>>>> We have updated our files accordingly. Please let us know if you >>>>>>>>>>> approve the document in its current form or if any further updates >>>>>>>>>>> are needed. We will await approvals from each author prior to >>>>>>>>>>> moving forward with publication. >>>>>>>>>>> >>>>>>>>>>> 1) Note that for Figures 1 and 2, we made “topology” uppercase >>>>>>>>>>> (rather than making “Conceptual Messages” lowercase). Thanks for >>>>>>>>>>> pointing that out. >>>>>>>>>>> >>>>>>>>>>> —Files (please refresh)— >>>>>>>>>>> >>>>>>>>>>> Updated XML file: >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999.xml >>>>>>>>>>> >>>>>>>>>>> Updated output files: >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999.txt >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999.pdf >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999.html >>>>>>>>>>> >>>>>>>>>>> Diff files showing all changes made during Final Review (formally >>>>>>>>>>> AUTH48): >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-auth48diff.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-auth48rfcdiff.html (side >>>>>>>>>>> by side) >>>>>>>>>>> >>>>>>>>>>> Diff files showing only changes made during the last editing round: >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-lastdiff.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-lastrfcdiff.html (side >>>>>>>>>>> by side) >>>>>>>>>>> >>>>>>>>>>> Diff files showing all changes: >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-diff.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-rfcdiff.html (side by >>>>>>>>>>> side) >>>>>>>>>>> >>>>>>>>>>> For the status of this document, please see: >>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9999 >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> >>>>>>>>>>> Karen Moore >>>>>>>>>>> RFC Production Center >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Jun 9, 2026, at 7:35 AM, Thomas Fossati >>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Karen, >>>>>>>>>>>> >>>>>>>>>>>> Thanks very much for your changes. >>>>>>>>>>>> >>>>>>>>>>>> Please find some more comments below. >>>>>>>>>>>> >>>>>>>>>>>> cheers! >>>>>>>>>>>> >>>>>>>>>>>> On Fri, 5 Jun 2026 at 22:46, Karen Moore wrote: >>>>>>>>>>>>> Hi Thomas, >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you for your reply! We have updated our files accordingly. >>>>>>>>>>>>> We >>>>>>>>>>>>> have a few additional questions: >>>>>>>>>>>>> >>>>>>>>>>>>> 1) We note that “Collection CMW” is preferred. Please let us know >>>>>>>>>>>>> if/how you would like this sentence to be updated. >>>>>>>>>>>>> >>>>>>>>>>>>> Current: >>>>>>>>>>>>> CMW Records, Tags, and Collections alone do not offer >>>>>>>>>>>>> authenticity, >>>>>>>>>>>>> integrity protection, or confidentiality. >>>>>>>>>>>>> >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> Record, Tag, and Collection CMWs alone do not offer authenticity, >>>>>>>>>>>>> integrity protection, or confidentiality. >>>>>>>>>>>> The "Perhaps" looks better. >>>>>>>>>>>> >>>>>>>>>>>>> 2) In Section 5.4, we replaced "҄@\xA0D\xD9\u0001\xF5\xA0\@" with >>>>>>>>>>>>> "…". >>>>>>>>>>>>> Please review and let us know if any further changes are needed. >>>>>>>>>>>> After some more discussion, we believe that it's worth annotating >>>>>>>>>>>> it >>>>>>>>>>>> with something more meaningful like "serialized CM value" >>>>>>>>>>>> >>>>>>>>>>>>> 3) We moved Dionna Glaze to the Acknowledgements section. If she >>>>>>>>>>>>> should be listed as a contributor instead, please let us know. >>>>>>>>>>>> Dionna told us that her employer has not yet approved her >>>>>>>>>>>> contributions >>>>>>>>>>>> to the IETF. Therefore, I don't think it would be appropriate to >>>>>>>>>>>> list >>>>>>>>>>>> her as a contributor. >>>>>>>>>>>> >>>>>>>>>>>>> —Files— >>>>>>>>>>>>> Note that it may be necessary for you to refresh your browser to >>>>>>>>>>>>> view >>>>>>>>>>>>> the most recent version. Please review the document carefully to >>>>>>>>>>>>> ensure satisfaction as we do not make changes once it has been >>>>>>>>>>>>> published as an RFC. >>>>>>>>>>>>> >>>>>>>>>>>>> Please contact us with any further updates or with your approval >>>>>>>>>>>>> of >>>>>>>>>>>>> the document in its current form. We will await approvals from >>>>>>>>>>>>> each >>>>>>>>>>>>> author prior to moving forward in the publication process. >>>>>>>>>>>> After reviewing the whole document we have the following comments: >>>>>>>>>>>> >>>>>>>>>>>> 1. Abstract and Introduction (two instances): >>>>>>>>>>>> >>>>>>>>>>>> "[...] conveyed between RATS roles during RATS." >>>>>>>>>>>> >>>>>>>>>>>> sounds like the sentence was cut short. >>>>>>>>>>>> >>>>>>>>>>>> We'd like to propose: >>>>>>>>>>>> >>>>>>>>>>>> "[...] conveyed between RATS roles during RATS interactions." >>>>>>>>>>>> >>>>>>>>>>>> 2. The new caption of Figure 2 has a couple of typos: >>>>>>>>>>>> a. missing "of" after "Conveyance" >>>>>>>>>>>> b. extra '"' at the end >>>>>>>>>>>> >>>>>>>>>>>> Also, these captions are the only place where "Conceptual >>>>>>>>>>>> Messages" is >>>>>>>>>>>> capitalised like this. Should they be "conceptual messages" >>>>>>>>>>>> instead? >>>>>>>>>>>> >>>>>>>>>>>> 3. Hannes's affiliation is not current and should be updated to: >>>>>>>>>>>> >>>>>>>>>>>> Hannes Tschofenig >>>>>>>>>>>> University of the Bundeswehr Munich >>>>>>>>>>>> Institute of Distributed Intelligent Systems >>>>>>>>>>>> Werner-Heisenberg-Weg 39 >>>>>>>>>>>> 85577 Neubiberg >>>>>>>>>>>> Germany >>>>>>>>>>>> Email: [email protected] >>>>>>>>>>>> >>>>>>>>>>>> 4. The [TLS-DTLS] reference is no longer active. It has been >>>>>>>>>>>> replaced >>>>>>>>>>>> by I-D.fossati-seat-early-attestation. We should update it and >>>>>>>>>>>> display >>>>>>>>>>>> it as [RA-TLS-EARLY]. >>>>>>>>>>>> >>>>>>>>>>>> 5. In the abstract: >>>>>>>>>>>> >>>>>>>>>>>> "[...] evolves message serialization formats without breaking >>>>>>>>>>>> compatibility" >>>>>>>>>>>> >>>>>>>>>>>> suggests the wrong idea that CMW itself drives the evolution of >>>>>>>>>>>> message serialisation formats, whereas the concept here is that CMW >>>>>>>>>>>> enables the smooth evolution of serialisation formats. >>>>>>>>>>>> >>>>>>>>>>>> We'd like to propose: >>>>>>>>>>>> >>>>>>>>>>>> "[...] enables the evolution of message serialization formats >>>>>>>>>>>> without >>>>>>>>>>>> breaking compatibility" >>>>>>>>>>>> >>>>>>>>>>>> 6. In the abstract, the following statement contains a couple of >>>>>>>>>>>> inaccuracies: >>>>>>>>>>>> >>>>>>>>>>>> "[...] this document defines a media type and a CoAP Content-Format >>>>>>>>>>>> to transport CMWs over protocols" >>>>>>>>>>>> >>>>>>>>>>>> The "to transport" part makes it sound as though the >>>>>>>>>>>> Content-Format is >>>>>>>>>>>> transporting the CMW. >>>>>>>>>>>> >>>>>>>>>>>> Besides, we define more than one media type and one C-F. >>>>>>>>>>>> >>>>>>>>>>>> Therefore, we'd like to propose the following: >>>>>>>>>>>> >>>>>>>>>>>> "[...] this document defines media types and CoAP Content-Formats >>>>>>>>>>>> which may be used to identify CMWs when transported over >>>>>>>>>>>> protocols". >>>>>>>>>>>> >>>>>>>>>>>> 7. In Section 3.1.1: we say "the ind byte string" but it should be >>>>>>>>>>>> "the >>>>>>>>>>>> ind bitmap" instead. >>>>>>>>>>>> >>>>>>>>>>>> 8. We have also just noticed that some incorrect information has >>>>>>>>>>>> been >>>>>>>>>>>> introduced: >>>>>>>>>>>> >>>>>>>>>>>> "IANA has allocated CBOR tag numbers and the corresponding data >>>>>>>>>>>> items, >>>>>>>>>>>> as shown in Table 4." >>>>>>>>>>>> >>>>>>>>>>>> However, in this case, IANA hasn't done any allocation; the >>>>>>>>>>>> carve-out >>>>>>>>>>>> has been in place since RFC9277. >>>>>>>>>>>> >>>>>>>>>>>> To fix the two problems above we propose: >>>>>>>>>>>> >>>>>>>>>>>> OLD >>>>>>>>>>>> >>>>>>>>>>>> 9.6.2. CBOR Tags per RFC 9277 >>>>>>>>>>>> >>>>>>>>>>>> Registering the CoAP Content-Formats listed in Table 3 >>>>>>>>>>>> automatically >>>>>>>>>>>> allocates CBOR tags in the range [1668546817, 1668612095] using the >>>>>>>>>>>> TN() transform defined in Appendix B of [RFC9277]. IANA has >>>>>>>>>>>> allocated CBOR tag numbers and the corresponding data items as >>>>>>>>>>>> shown >>>>>>>>>>>> in Table 4. >>>>>>>>>>>> >>>>>>>>>>>> +============+===============================+ >>>>>>>>>>>> | Tag Number | Tag Content | >>>>>>>>>>>> +============+===============================+ >>>>>>>>>>>> | 1668547091 | bytes .cbor cbor-cmw | >>>>>>>>>>>> +------------+-------------------------------+ >>>>>>>>>>>> | 1668547092 | bytes .cbor signed-cbor-cmw | >>>>>>>>>>>> +------------+-------------------------------+ >>>>>>>>>>>> | 1668547093 | bytes-wrapped json-cmw | >>>>>>>>>>>> +------------+-------------------------------+ >>>>>>>>>>>> | 1668547094 | bytes-wrapped signed-json-cmw | >>>>>>>>>>>> +------------+-------------------------------+ >>>>>>>>>>>> >>>>>>>>>>>> Table 4: TN-Derived CBOR Tags >>>>>>>>>>>> >>>>>>>>>>>> Figure 7 extends the $cbor-tag socket defined in Section 3.2 to add >>>>>>>>>>>> the definitions of the associated Tag CMWs. Note that CMWs in Tag >>>>>>>>>>>> and Record form are excluded from the productions. This is because >>>>>>>>>>>> they can already be represented as a CMW, so the extra wrapping >>>>>>>>>>>> would >>>>>>>>>>>> be redundant. >>>>>>>>>>>> >>>>>>>>>>>> $cbor-tag /= tag-cm-cbor<1668547091, cbor-collection> >>>>>>>>>>>> $cbor-tag /= tag-cm-cbor<1668547092, signed-cbor-cmw> >>>>>>>>>>>> $cbor-tag /= tag-cm-data<1668547093> ; bytes(cmw+json collection) >>>>>>>>>>>> $cbor-tag /= tag-cm-data<1668547094> ; bytes(cmw+jws) >>>>>>>>>>>> >>>>>>>>>>>> Figure 7: Tag CMW Definitions >>>>>>>>>>>> >>>>>>>>>>>> NEW >>>>>>>>>>>> >>>>>>>>>>>> 9.6.2. CBOR Tags per RFC 9277 >>>>>>>>>>>> >>>>>>>>>>>> Registering the CoAP Content-Formats listed in Table 3 >>>>>>>>>>>> automatically >>>>>>>>>>>> allocates CBOR tags in the range [1668546817, 1668612095] using the >>>>>>>>>>>> TN() transform defined in Appendix B of [RFC9277]. The allocated >>>>>>>>>>>> CBOR tag numbers and the corresponding data items are shown in >>>>>>>>>>>> Table 4. >>>>>>>>>>>> >>>>>>>>>>>> Note that CMWs in Tag and Record form are excluded. This is >>>>>>>>>>>> because >>>>>>>>>>>> they can already be represented as a CMW, so the extra wrapping >>>>>>>>>>>> would >>>>>>>>>>>> be redundant. >>>>>>>>>>>> >>>>>>>>>>>> +============+===============================+ >>>>>>>>>>>> | Tag Number | Tag Content | >>>>>>>>>>>> +============+===============================+ >>>>>>>>>>>> | 1668547091 | bytes .cbor cbor-collection | >>>>>>>>>>>> +------------+-------------------------------+ >>>>>>>>>>>> | 1668547092 | bytes .cbor signed-cbor-cmw | >>>>>>>>>>>> +------------+-------------------------------+ >>>>>>>>>>>> | 1668547093 | bytes-wrapped json-collection | >>>>>>>>>>>> +------------+-------------------------------+ >>>>>>>>>>>> | 1668547094 | bytes-wrapped signed-json-cmw | >>>>>>>>>>>> +------------+-------------------------------+ >>>>>>>>>>>> >>>>>>>>>>>> Table 4: TN-Derived CBOR Tags >>>>>>>>>>>> >>>>>>>>>>>> Figure 7 extends the $cbor-tag socket defined in Section 3.2 to add >>>>>>>>>>>> the definitions of the associated Tag CMWs. >>>>>>>>>>>> >>>>>>>>>>>> $cbor-tag /= tag-cm-cbor<1668547091, cbor-collection> >>>>>>>>>>>> $cbor-tag /= tag-cm-cbor<1668547092, signed-cbor-cmw> >>>>>>>>>>>> $cbor-tag /= tag-cm-data<1668547093> ; bytes(cmw+json collection) >>>>>>>>>>>> $cbor-tag /= tag-cm-data<1668547094> ; bytes(cmw+jws) >>>>>>>>>>>> >>>>>>>>>>>> Figure 7: Tag CMW Definitions >>>>>>>>>>>> >>>>>>>>>>>>> —Files— >>>>>>>>>>>>> Note that it may be necessary for you to refresh your browser to >>>>>>>>>>>>> view the most recent version. Please review the document >>>>>>>>>>>>> carefully to ensure satisfaction as we do not make changes once >>>>>>>>>>>>> it has been published as an RFC. >>>>>>>>>>>>> >>>>>>>>>>>>> Please contact us with any further updates or with your approval >>>>>>>>>>>>> of the document in its current form. We will await approvals >>>>>>>>>>>>> from each author prior to moving forward in the publication >>>>>>>>>>>>> process. >>>>>>>>>>>>> >>>>>>>>>>>>> Updated XML file: >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999.xml >>>>>>>>>>>>> >>>>>>>>>>>>> Updated output files: >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999.txt >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999.pdf >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999.html >>>>>>>>>>>>> >>>>>>>>>>>>> Diff files showing all changes made during Final Review (formally >>>>>>>>>>>>> AUTH48): >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-auth48diff.html >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-auth48rfcdiff.html >>>>>>>>>>>>> (side by side) >>>>>>>>>>>>> >>>>>>>>>>>>> Diff files showing all changes: >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-diff.html >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9999-rfcdiff.html (side by >>>>>>>>>>>>> side) >>>>>>>>>>>>> >>>>>>>>>>>>> For the status of this document, please see: >>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9999 >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Karen Moore >>>>>>>>>>>>> RFC Production Center -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
