Hi, We've made all of these changes aside from a couple involving the addition of the word "and" to lists of section references:
On Wed Jun 24 20:34:28 2026, [email protected] wrote: > Hello IANA, > > Please update the registries outlined below to match the edited > document at <https://www.rfc-editor.org/authors/rfc9999-diff.html>. > > 1) In both the "CBOR Web Token (CWT) Claims” and "JSON Web Token > Claims” registries > (<https://www.iana.org/assignments/cwt> and > <https://www.iana.org/assignments/jwt>): > > OLD: > cmw A RATS Conceptual Message Wrapper > > NEW: > cmw RATS Conceptual Message Wrapper Done. > 2) In the “Structured Syntax Suffixes” registry > <https://www.iana.org/assignments/media-type-structured-suffix>: > > OLD: > JSON Web Signature (JWS) > > binary; values are represented as a JSON Object or as a series of > base64url-encoded values each separated from the next by a single > period ('.') character. > > NEW: > JSON Web Signature (JWS) > > binary. Values are represented as a JSON Object or as a series of > base64url-encoded values, each separated from the next by a single > period ('.') character. Done. > 3) In the "Media Types” registry > <https://www.iana.org/assignments/media-types>: > > OLD: > cmw+cbor application/cmw+cbor [RFC-ietf-rats-msg-wrap-22] > cmw+cose application/cmw+cose [RFC-ietf-rats-msg-wrap-22] > cmw+json application/cmw+json [RFC-ietf-rats-msg-wrap-22] > cmw+jws application/cmw+jws [RFC-ietf-rats-msg-wrap-22] > > NEW: > cmw+cbor application/cmw+cbor [RFC-ietf-rats-msg-wrap-22], > Sections 3.1, 3.2, and 3.3 > cmw+cose application/cmw+cose [RFC-ietf-rats-msg-wrap-22], > Section 4.1 > cmw+json application/cmw+json [RFC-ietf-rats-msg-wrap-22], > Sections 3.1 and 3.2 > cmw+jws application/cmw+jws [RFC-ietf-rats-msg-wrap-22], > Section 4.2 Mostly done, but we've left out the "and." More on this below. > 4) In these registrations: > <https://www.iana.org/assignments/media-types/application/cmw+cbor> > <https://www.iana.org/assignments/media-types/application/cmw+cose> > <https://www.iana.org/assignments/media-types/application/cmw+json> > <https://www.iana.org/assignments/media-types/application/cmw+jws> > > a) Please change every instance of “n/a” to “N/A” (in all the > registrations). > > b) Please make these changes (in all the registrations): > > OLD: > Optional parameters: > cmwc_t (Collection CMW type in string format. OIDs must use the > dotted-decimal notation. The parameter value is case-insensitive. It > must not be used for CMW that are not Collections.) > > Security considerations: > Section 9 of RFC-ietf-rats-msg-wrap-22 > > Applications that use this media type: > Attesters, Verifiers, Endorsers and Reference-Value providers, Relying > Parties that need to transfer CMW payloads over HTTP(S), CoAP(S), and > other transports. > > NEW: > Optional parameters: > cmwc_t (Collection CMW type in string format. OIDs must use the > dotted-decimal notation. The parameter value is case-insensitive. It > must not be used for CMWs that are not collections.) > > Security considerations: > Section 8 of RFC-ietf-rats-msg-wrap-22 > > Applications that use this media type: > Attesters, Verifiers, Endorsers and Reference-Value providers, and > Relying Parties that need to transfer CMW payloads over HTTP(S), > CoAP(S), and other transports. > > c) In application/cmw+jws only: > > OLD: > Encoding considerations: > 8bit; values are represented as a JSON Object or as a series of > base64url-encoded values each separated from the next by a single > period ('.') character. > > NEW: > Encoding considerations: > 8bit. Values are represented as a JSON Object or as a series of > base64url-encoded values, each separated from the next by a single > period ('.') character. Done. > 5) In the “CoAP Content-Formats" registry > <https://www.iana.org/assignments/core-parameters>: > > OLD: > application/cmw+cbor [RFC-ietf-rats-msg-wrap-22, Sections 3.1, > 3.2, 3.3] > application/cmw+json [RFC-ietf-rats-msg-wrap-22, Sections 3.1, > 3.3] > > NEW: > application/cmw+cbor [RFC-ietf-rats-msg-wrap-22, Sections 3.1, > 3.2, and 3.3] > application/cmw+json [RFC-ietf-rats-msg-wrap-22, Sections 3.1 and > 3.3] For now, we're continuing to omit the word "and." It looks like most registries in recent years don't use "and" when we're referring to multiple section numbers. We're going to talk about how to approach this and similar presentation issues across registries. For this, I think we're leaning against including "and" just because tables we transfer into registry text are likely to save space by omitting the "and." If we do make this change, we'll make it across the board. thanks, Amanda > Thank you in advance! > > Karen Moore > RFC Production Center > > > > Begin forwarded message: > > > > From: Karen Moore <[email protected]> > > Subject: [AD] Re: Final Review: RFC-to-be 9999 (draft-ietf-rats-msg- > > wrap) for your review > > Date: June 24, 2026 at 11:19:04 AM PDT > > To: Deb Cooley <[email protected]>, Hannes Tschofenig > > <[email protected]>, Ned Smith IETF > > <[email protected]>, Thomas Fossati > > <[email protected]>, Henk Birkholz > > <[email protected]> > > Cc: "[email protected]" <[email protected]>, > > "[email protected]" <[email protected]>, "sec- > > [email protected]" <[email protected]>, "[email protected]" <rats- > > [email protected]>, "[email protected]" <stndrds- > > [email protected]>, "[email protected]" > > <[email protected]> > > > > 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] > >> editor.org> 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]>; sec- > >>>> [email protected] <[email protected]>; [email protected] <rats- > >>>> [email protected]>; [email protected] <stndrds- > >>>> [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] > >>>>>>> editor.org> 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] > >>>>>>>> editor.org> 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] > >>>>>>>>> editor.org> 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] > >>>>>>>>>>> editor.org> 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]
