Authors, IANA has completed the requested actions. The Final Review for this document is complete; we will now move this document forward in the publication process.
Thank you all for your time! Best regards, Karen Moore RFC Production Center > On Jun 24, 2026, at 11:19 AM, Karen Moore <[email protected]> wrote: > > 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]
