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]
