Thomas,

On Aug 28, 2025, in reply to the intake form, you wrote:
> Yes: the examples in Appendix A need to be recomputed as soon as IANA
> makes the allocations.
> We have scripts in place for that, so the update should take very
> little time when the time comes.
> We put a note for you there just in case.


Do the examples need to be recomputed at this time?


Re:
> Consistency with 9052 seems like an excellent objective.  We could do
> a wholesale change:
> * s/COSE signed object/COSE Signed Message/g
> * s/signed COSE message/COSE Signed Message/g

These terms have been updated; please review.

Thank you for your replies. The revised files are here (please refresh):
  https://www.rfc-editor.org/authors/rfc9921.html
  https://www.rfc-editor.org/authors/rfc9921.txt
  https://www.rfc-editor.org/authors/rfc9921.pdf
  https://www.rfc-editor.org/authors/rfc9921.xml

This diff file shows all changes from the approved I-D:
  https://www.rfc-editor.org/authors/rfc9921-diff.html
  https://www.rfc-editor.org/authors/rfc9921-rfcdiff.html (side by side)

This diff file shows the changes made during AUTH48 thus far:
  https://www.rfc-editor.org/authors/rfc9921-auth48diff.html
  https://www.rfc-editor.org/authors/rfc9921-auth48rfcdiff.html (side by side)

This diff file shows only the changes since the last posted version:
  https://www.rfc-editor.org/authors/rfc9921-lastrfcdiff.html

We will wait to hear from you again and from your coauthors
before continuing the publication process. This page shows 
the AUTH48 status of your document:
  https://www.rfc-editor.org/auth48/rfc9921

Thank you.

Alice Russo
RFC Production Center

> On Feb 17, 2026, at 2:07 AM, Thomas Fossati <[email protected]> wrote:
> 
> hi Alice,
> 
> On Thu, 12 Feb 2026 at 20:23, Alice Russo <[email protected]> wrote:
>> 
>> Thomas,
>> 
>> Thank you for your reply. Please see the follow-ups below. The revised files 
>> are here (please refresh):
>>  https://www.rfc-editor.org/authors/rfc9921.html
>>  https://www.rfc-editor.org/authors/rfc9921.txt
>>  https://www.rfc-editor.org/authors/rfc9921.pdf
>>  https://www.rfc-editor.org/authors/rfc9921.xml
>> 
>> This diff file shows all changes from the approved I-D:
>>  https://www.rfc-editor.org/authors/rfc9921-diff.html
>>  https://www.rfc-editor.org/authors/rfc9921-rfcdiff.html (side by side)
>> 
>> This diff file shows the changes made during AUTH48 thus far:
>>  https://www.rfc-editor.org/authors/rfc9921-auth48diff.html
>>  https://www.rfc-editor.org/authors/rfc9921-auth48rfcdiff.html (side by side)
>> 
>> -- Re: #1, FYI, we reverted to not expand "CBOR" in the title and abstract. 
>> This is in keeping with the titles of recent RFCs (e.g., RFCs 9864, 9679, 
>> 9596) and avoids having an acronymn expansion within an acronym expansion.
>> 
>> Original:
>>          COSE Header parameter for RFC 3161 Time-Stamp Tokens
>> 
>> Current:
>> CBOR Object Signing and Encryption (COSE) Header Parameter for Timestamp
>>                     Tokens as Defined in RFC 3161
>> 
>> 
>> Regarding "CBOR": It is expanded in Section 3.1 (the first instance outside 
>> the context of "COSE"). Just let us know if you prefer to add a reference to 
>> RFC 8949, or a sentence that expands CBOR earlier.
> 
> OK
> 
>> -- Re: #4 (usage of "primary"), no changes needed.
> 
> OK
> 
>> -- Re: #6 (MessageImprint in this document vs. messageImprint in RFC 3161)
>> 
>>> Perhaps we should do this:
>>> * MessageImprint, when referring to the type;
>>> * messageImprint, when referring to the value.
>>> However, there may be a non-zero risk of introducing some confusion.
>>> WDYT?
>> 
>> If the current usage (all 'MessageImprint' in this document) is sufficiently 
>> clear, then we suggest leaving it as is in order to avoid introducing 
>> confusion.
> 
> OK, thanks for the sound advice.
> 
>> -- Re: #10 (use of the OID from freeTSA.org, as detailed in your reply)
>> 
>> Thank you for this information. Because the Internet-Draft was approved with 
>> this OID in the examples in Appendices A.1 and A.2, we will assume it’s fine 
>> to leave it unless someone suggests otherwise.
> 
> Apparently, no one noticed it.  In any case, it doesn't look like a
> substantial problem.
> 
>> -- Re: #12b (Terminology)
>> 
>>>> COSE signed object vs. signed COSE object
>>> 
>>> COSE signer object
>> 
>> We updated to "COSE signed object", assuming "signed" not "signer" was 
>> intended; please review.
> 
> Yes, sorry for the typo, I meant "signed".
> 
>> FYI, there remain 2 instances of "signed COSE message".   (Of note: We see 
>> zero instances of "COSE signed object" in existing RFCs. We see "COSE Signed 
>> Message" in RFC 9052.)
> 
> Consistency with 9052 seems like an excellent objective.  We could do
> a wholesale change:
> * s/COSE signed object/COSE Signed Message/g
> * s/signed COSE message/COSE Signed Message/g
> 
>> We will wait to hear from you again and from your coauthors
>> before continuing the publication process. This page shows
>> the AUTH48 status of your document:
>>  https://www.rfc-editor.org/auth48/rfc9921
>> 
>> Thank you.
>> 
>> Alice Russo
>> RFC Production Center
> 
> Thank you!

-- 
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to