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]
