Hi Carsten,
Thank you for your detailed replies! We have updated the document accordingly.
See inline for followup comments and updated files.
> On May 6, 2025, at 9:26 AM, Carsten Bormann <c...@tzi.org> wrote:
>
> Hi Madison,
>
> Thank you for the update.
> On your followup questions:
>
>>>> 1) <!-- [rfced] Document title:
>>>>
>>>> a) Note that we have updated the title as follows to expand abbreviations.
>>>>
>>>> Original:
>>>> A CBOR Tag for Unprotected CWT Claims Sets
>>>>
>>>> Current:
>>>> A Concise Binary Object Representation (CBOR) Tag for Unprotected
>>>> CBOR Web Token Claims Sets (UCCS)
>>>
>>> This unannounced expansion of CWT makes it hard to understand what UCCS
>>> stands for (it’s not UCWTCS).
>>> (I don’t have a conclusive answer, as these nested expansions tend to get
>>> out of hand.
>>> A logical fix that at least is not wronger would be:
>>>
>>> Maybe:
>>> A Concise Binary Object Representation (CBOR) Tag for Unprotected
>>> CBOR Web Token (CWT) Claims Sets (UCCS)
>>
>> [rfced] Thank you for your suggestion! Looking back at the Abstract of the
>> document, UCCS is simply expanded as "Unprotected CWT Claims Set". Would the
>> following title work to match how the abbreviation is expanded in the
>> Abstract (and perhaps make the title more concise)?
>>
>> Current:
>> A Concise Binary Object Representation (CBOR) Tag for Unprotected
>> CBOR Web Token Claims Sets (UCCS)
>>
>> Perhaps:
>> A Concise Binary Object Representation (CBOR) Tag for Unprotected
>> CWT Claims Sets (UCCS)
>
> I believe this is an improvement, as “CBOR Web Token” really doesn’t confer
> that much more information than “CWT” and the “UCCS” abbreviation now becomes
> understandable.
>
> I need to note though that one of us liked my original “Maybe" formulation
> for its consistency, unwrapping all of the acronyms.
> I generally agree with this RFC editor style policy (despite its sometimes
> comical results — which could be dodged e.g., with RFC 9528), but I think
> there are diminishing returns at some point, and expanding CWT is of negative
> value here.
> Maybe we can return to this if needed.
[rfced] Thank you for your explanation. We have left the title as is for now,
but if at any point we need to make updates to the title during AUTH48, please
let us know.
>> […]
>>
>> [rfced] Noted - Thank you for the suggestion! We will leave the use of UCCS
>> as is per your response to 1b. With that being said, we found one spot where
>> clarification may be needed regarding the use of articles before UCCS.
>> Please review the text below and let us know which option you prefer (or if
>> you have any additional revisions/suggestions).
>>
>> Current:
>> In this regard, UCCS is similar in security considerations to
>> JWTs [BCP225] using the algorithm "none".
>>
>> Perhaps 1 (singular use of UCCS):
>> In this regard, a UCCS is similar in security considerations to
>> JWTs [BCP225] using the algorithm "none".
>>
>> Perhaps 2 (plural use of UCCS):
>> In this regard, UCCS are similar in security considerations to
>> JWTs [BCP225] using the algorithm "none".
>
> I think the above variant 2 works best.
>
>> Or (plural use of UCCS, plus rewording):
>> In this regard, UCCS have similar security considerations compared to
>> JWTs [BCP225] using the algorithm "none".
> Grüße, Carsten
[rfced] Note that we have updated the following sentence to use the "NEW2"
suggestion for the sentence that includes "PCIe IDE".
Original:
Examples include conveyance via
PCIe (Peripheral Component Interconnect Express) IDE (Integrity
and Data Encryption) or a TLS tunnel.
Current:
Examples include conveyance via
PCIe (Peripheral Component Interconnect Express) IDE (Integrity
and Data Encryption) or a TLS tunnel.
Additionally, updates suggested in previous emails have also been made.
Please review the document carefully to ensure satisfaction as we do not make
changes once it has been published as an RFC. 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.
The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9781.txt
https://www.rfc-editor.org/authors/rfc9781.pdf
https://www.rfc-editor.org/authors/rfc9781.html
https://www.rfc-editor.org/authors/rfc9781.xml
The diff files have been posted here:
https://www.rfc-editor.org/authors/rfc9781-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9781-rfcdiff.html (side by side)
https://www.rfc-editor.org/authors/rfc9781-auth48diff.html (AUTH48 changes
only)
https://www.rfc-editor.org/authors/rfc9781-auth48rfcdiff.html (side by side)
For the AUTH48 status page, please see:
https://www.rfc-editor.org/auth48/rfc9781
Thank you!
RFC Editor/mc
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
