Hi Deb (and *IANA), Just CC’ing IANA so we can get some guidance from them as to how to proceed with #1 below. I would guess this change would not be time intensive, so a change to the registry group name could likely be updated in RFC-to-be 9999 prior to publication.
Sounds like #2 is something that would not be happening any time soon, so we assume that RFC-to-be 9999 will not be affected. Please let us know if that assumption is in error. Thank you for having a look! Megan Ferguson RFC Production Center > On Jun 25, 2026, at 4:45 AM, Deb Cooley <[email protected]> wrote: > > Adding cose and jose chairs for their awareness.... > > Registry questions: > > 1. Removing 'Claims' from the group name (currently CBOR Web Token (CWT) > Claims) seems like a sensible change. There are no other CWT registries and > the other sub-registries under it currently seem out of place. The easiest > thing to do would be to remove 'Claims' from the top level group name. > Please tell me what I need to do to make this happen. > > 2. I agree with the logic of why a column isn't in the JWT Claims registry, > but I'm hesitant to make that change without discussion in the jose working > group. I suspect that it might not be a straightforward change, and I would > want the working group to agree. I think that an I-D/RFC would be in order. > > I hope this answers the questions. > > Deb > > On Wed, Jun 24, 2026 at 2:19 PM 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]
