Hi Thomas,
Thank you for your response! We have updated the document per your reply and
all of our questions have been addressed. Please see inline for a few followup
comments.
> On Apr 25, 2025, at 1:46 AM, Thomas Fossati <thomas.foss...@linaro.org> wrote:
>
> Dear Editor,
>
> On Tue, 22 Apr 2025 at 05:33, <rfc-edi...@rfc-editor.org> wrote:
>>
>> Authors,
>>
>> While reviewing this document during AUTH48, please resolve (as
>> necessary) the following questions, which are also in the XML file.
>>
>> 1) <!-- [rfced] We have updated the title of the document to expand
>> "EAT" per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review.
>>
>> Original: EAT Media Types
>>
>> Current: Entity Attestation Token (EAT) Media Types -->
>
> OK
>
>> 2) <!-- [rfced] Abstract and Section 1: Note that we have updated the
>> expansion of RATS per RFC 9334. In addition, may we rephrase the text
>> as follows to clarify the object being used in RESTful APIs?
>>
>> Original: Payloads used in Remote Attestation Procedures may require
>> an associated media type for their conveyance, for example when used
>> in RESTful APIs.
>>
>> Perhaps: The payloads used in Remote ATtestation procedureS (RATS) may
>> require an associated media type for their conveyance, for example,
>> when the payloads are used in RESTful APIs. -->
>
> OK
>
>> 3) <!-- [rfced] FYI - We have updated the title of Section 1.1 to
>> "Terminology" from "Requirements Language" in order to avoid confusion
>> regarding the use of "Requirements Language" in RFCs 2119 and 8174
>> (see https://www.rfc-editor.org/rfc/rfc7322.html#section-4.8.2).
>> Please let us know any objections. -->
>
> OK
>
>> 4) <!-- [rfced] Figure 2: Note that we have changed "Legenda" to
>> "Legend" for clarity. Legeneda appears in some dictionaries without
>> being defined as a key or explanation for a map or chart. -->
>
> OK (apologies for the Italianism.)
>
>> 5) <!-- [rfced] RFC-to-be 9711 <draft-ietf-rats-eat> seems to double
>> quotes for Claim names, while this document seems to use <tt>. Should
>> this document use double quotes to align with RFC 9711?
>>
>> Example from 9711: The "eat_profile" claim identifies ...
>>
>> From section 3 of this document: ... identifier using the eat_profile
>> claim ...
>
> 9711 did it to be consistent with CWT, RFC 8392. So it makes sense to
> be consistent with RFC 9711.
>
>> In addition, please review the use of <tt> to ensure use is as desired
>> and consistent. The pattern of use is unclear to us. We see the
>> following instances of <tt>:
>
> These instances come from using backticks in kramdown-rfc, which we had
> (wrongly) assumed would be rendered as quoted text in TXT and <tt> in
> HTML.
>
> Happy to follow the established convention.
>
>> <tt>eat_profile</tt> claim <tt>eat_profile</tt> parameter
>> <tt>application/eat+cwt</tt> <tt>parameter-value</tt>
>> <tt>quoted-string</tt> encoding <tt>application/eat+jwt;
>> eat_profile="tag:evidence.example,2022"</tt> <tt>token</tt> encoding
>> <tt>application/eat+cwt; eat_profile=2.999.1</tt>
>> <tt>application/eat-ucs+json</tt> and
>> <tt>application/eat-ucs+cbor</tt> <tt>+cwt</tt> Structured Syntax
>> Suffix <tt>+cwt</tt> <tt>application/cwt</tt>
>>
>> Double quotes are used in the registration templates: Optional
>> parameters: "eat_profile"
>>
>> application/eat* (sans <tt> in table) +cwt (sans <tt> in the IANA
>> template) -->
>
> OK
1) Thank you for your explanation. We have updated the following usage of <tt>
for consistency:
<tt>eat_profile</tt> claim to "eat_profile" claim (per use in RFC-to-be-9711)
<tt>eat_profile</tt> parameter to "eat_profile" parameter
+cwt to <tt>+cwt</tt>
Note that the following terms use <tt> tags in running text but do not contain
<tt> tags in Tables 1 and 2. We have left each instance as is.
application/eat+cwt
application/eat-ucs+json
application/eat-ucs+cbor
Please review the updates regarding <tt> tagging closely and let us know if any
further updates are needed.
>> 6) <!-- [rfced] Note that we have updated the "NOTE" in Figures 3 and
>> 4 to reflect what appears in Section 7.1.1 in RFC 8792
>> (https://www.rfc-editor.org/rfc/rfc8792.html#name-header). Are the
>> pound symbols important (e.g., do they indicate comments)?
>>
>> Original: # NOTE: '\' line wrapping per RFC 8792
>>
>> Updated: NOTE: '\' line wrapping per RFC 8792 -->
>
> I believe I originally added the pound because of compatibility with the
> automatic validator script. It was a while ago, though, so my memory
> may not be 100% accurate. I have just removed the pound from my local
> copy, re-run the validators, and everything still works perfectly!
>
> Long story short: OK with the removal :-)
>
>> 7) <!-- [rfced] We note that RFC 7519 is not cited anywhere in this
>> document. Please let us know if there is an appropriate place in the
>> text to reference this RFC. Otherwise, we will remove it from the
>> Normative References section. -->
>
> OK with removing. JWT is brought in "transitively" through EAT.
2) Upon further review, we found a place to cite this reference in the text
instead of removing it from the normative references entirely. Please review
the updated text below and let us know if you approve (or if you would prefer
to remove the reference as originally suggested).
Original:
Figure 2 illustrates the six EAT wire formats and how they relate to
each other. [EAT] defines four of them (CWT, JWT and Detached EAT
Bundle in its JSON and CBOR flavours), whilst [UCCS] defines UCCS and
UJCS.
Current:
Figure 2 illustrates the six EAT wire formats and how they relate to
each other. [EAT] defines four of them (CBOR Web Token (CWT), JSON
Web Token (JWT) [JWT], and the detached EAT bundle in its JSON and
CBOR flavours), while [UCCS] defines the Unprotected CWT Claims Set
(UCCS) and Unprotected JWT Claims Sets (UJCS).
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/rfc9782.txt
https://www.rfc-editor.org/authors/rfc9782.pdf
https://www.rfc-editor.org/authors/rfc9782.html
https://www.rfc-editor.org/authors/rfc9782.xml
The relevant diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9782-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9782-rfcdiff.html (side by side)
https://www.rfc-editor.org/authors/rfc9782-auth48diff.html (AUTH48 changes
only)
https://www.rfc-editor.org/authors/rfc9782-auth48rfcdiff.html (side by side)
For the AUTH48 status of this document, please see:
https://www.rfc-editor.org/auth48/rfc9782
Thank you,
RFC Editor/mc
>> 8) <!-- [rfced] We have the following queries regarding abbreviations
>> and expansions.
>>
>> a) FYI - We have added expansions for abbreviations upon first use per
>> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
>> expansion in the document carefully to ensure correctness.
>
> OK
>
>> b) FYI - When the abbreviation "EAT" is used in plural form, we have
>> updated to use "EATs". We note this expansion in particular since
>> there are multiple occurences that have been updated. Please let us
>> know any objections. -->
>
> OK
>
>> 9) <!-- [rfced] Please review the "Inclusive Language" portion of the
>> online Style Guide
>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and
>> let us know if any changes are needed. Updates of this nature
>> typically result in more precise language, which is helpful for
>> readers.
>>
>> Note that our script did not flag any words in particular, but this
>> should still be reviewed as a best practice.
>
> OK.
>
> Thanks very much for your work on the document.
>
> Cheers, Thomas, Laurence and Henk.
>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
