Hi Thomas,
Thank you for the nice comment. Note that we have updated Hannes’ affiliation
and marked your approval.
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.
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.
—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]
