Hi Alice! On Wed, 18 Feb 2026 at 23:40, Alice Russo <[email protected]> wrote: > > 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?
No, that was done in -08 [1] [1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-cose-tsa-tst-header-parameter-07&url2=draft-ietf-cose-tsa-tst-header-parameter-08&difftype=--html > 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. Thanks, will do it shortly. cheers! > 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]
