Hi David, Thank you for the quick turnaround! The updates look good.
RFC Editor/mc > On May 23, 2025, at 2:49 PM, David Dong via RT <iana-mat...@iana.org> wrote: > > Hi Madison, > > Changes 1), 2) and 4) are completed for each of the following media type > templates: > > https://www.iana.org/assignments/media-types/application/eat+cwt > https://www.iana.org/assignments/media-types/application/eat+jwt > https://www.iana.org/assignments/media-types/application/eat-bun+cbor > https://www.iana.org/assignments/media-types/application/eat-bun+json > https://www.iana.org/assignments/media-types/application/eat-ucs+cbor > https://www.iana.org/assignments/media-types/application/eat-ucs+json > > Regarding requested change 3), the email address is already listed as > "r...@ietf.org" in the templates. The "@" character is masked as "&" in the > published templates as part of an anti-spam measure used across all IANA > protocol parameter registries. > > Thank you. > > Best regards, > > David Dong > IANA Services Sr. Specialist > > On Fri May 23 14:33:01 2025, mchu...@staff.rfc-editor.org wrote: >> IANA, >> >> Please make the minor updates below to the following media types in >> the "Media Types" registry (https://www.iana.org/assignments/media- >> types/media-types.xhtml). These updates apply to each media type: >> >> application/eat+cwt >> application/eat+jwt >> application/eat-bun+cbor >> application/eat-bun+json >> application/eat-ucs+cbor >> application/eat-ucs+json >> >> 1) Update "case-insensitive" to "case insensitive" (no hyphen). >> >> OLD: >> Optional parameters: "eat_profile" (EAT profile in string format. >> OIDs must use the >> dotted-decimal notation. The parameter value is case-insensitive.) >> >> NEW: >> Optional parameters: "eat_profile" (EAT profile in string format. >> OIDs must use the >> dotted-decimal notation. The parameter value is case insensitive.) >> >> >> 2) Add "and" before "Replying Parties". >> >> OLD: >> Applications that use this media type: Attesters, Verifiers, >> Endorsers and Reference-Value providers, Relying Parties that >> need >> to transfer EAT payloads over HTTP(S), CoAP(S), and other >> transports. >> >> NEW: >> Applications that use this media type: Attesters, Verifiers, >> Endorsers and Reference-Value providers, and Relying Parties >> that >> need to transfer EAT payloads over HTTP(S), CoAP(S), and other >> transports. >> >> >> 3) Update "&" to "@". >> >> OLD: >> Person & email address to contact for further information: RATS WG >> mailing list (rats&ietf.org) >> >> NEW: >> Person & email address to contact for further information: RATS WG >> mailing list (r...@ietf.org) >> >> >> 4) Please add "Provisional registration: no" after "Author/Change >> controller: IETF" >> >> Thank you, >> RFC Editor/mc >> >> >>> On May 7, 2025, at 4:15 PM, Madison Church <mchu...@staff.rfc- >>> editor.org> wrote: >>> >>> *Resending with the correct name in the greeting! Apologies for the >>> misspelling.* >>> >>> All, >>> >>> With Laurence's approval, we have now received all necessary >>> approvals and consider AUTH48 complete (see https://www.rfc- >>> editor.org/auth48/rfc9782). >>> >>> Please note that this document normatively references RFC-to-be-9781, >>> which is still currently in AUTH48 (see https://www.rfc- >>> editor.org/cluster_info.php?cid=C522). Once RFC-to-be-9781 finishes >>> AUTH48, we will move both documents forward in the publication >>> process. >>> >>> Thank you for your attention and guidance during AUTH48! >>> >>> Best, >>> RFC Editor/mc >>> >>>> On May 7, 2025, at 4:11 PM, Madison Church <mchu...@staff.rfc- >>>> editor.org> wrote: >>>> >>>> All, >>>> >>>> With Lance’s approval, we have now received all necessary approvals >>>> and consider AUTH48 complete (see https://www.rfc- >>>> editor.org/auth48/rfc9782). >>>> >>>> Please note that this document normatively references RFC-to-be- >>>> 9781, which is still currently in AUTH48 (see https://www.rfc- >>>> editor.org/cluster_info.php?cid=C522). Once RFC-to-be-9781 finishes >>>> AUTH48, we will move both documents forward in the publication >>>> process. >>>> >>>> Thank you for your attention and guidance during AUTH48! >>>> >>>> Best, >>>> RFC Editor/mc >>>> >>>>> On May 7, 2025, at 3:27 PM, Laurence Lundblade >>>>> <l...@securitytheory.com> wrote: >>>>> >>>>> I approve. >>>>> >>>>> LL >>>>> >>>>> >>>>>> On May 7, 2025, at 12:45 PM, Madison Church <mchu...@staff.rfc- >>>>>> editor.org> wrote: >>>>>> >>>>>> Hi Henk, >>>>>> >>>>>> Thank you for your response! We have noted your approval here: >>>>>> https://www.rfc-editor.org/auth48/rfc9782. >>>>>> >>>>>> Once we receive approval from Lawrence, we will move this document >>>>>> forward in the publication process. >>>>>> >>>>>> Thank you! >>>>>> RFC Editor/mc >>>>>> >>>>>>> On May 7, 2025, at 12:50 PM, Henk Birkholz >>>>>>> <henk.birkholz@ietf.contact> wrote: >>>>>>> >>>>>>> Hi Madison, >>>>>>> >>>>>>> please add my approval, too. >>>>>>> >>>>>>> >>>>>>> Thanks a ton! >>>>>>> >>>>>>> Henk >>>>>>> >>>>>>> On 07.05.25 19:07, Madison Church wrote: >>>>>>>> Hi Thomas, >>>>>>>> Thank you for your reply! We have noted your approval on the >>>>>>>> AUTH48 status page (see https://www.rfc- >>>>>>>> editor.org/auth48/rfc9782). >>>>>>>> Once we receive approvals from Henk and Laurence, we will move >>>>>>>> this document forward in the publication process. >>>>>>>> Thank you! >>>>>>>> RFC Editor/mc >>>>>>>>> On May 7, 2025, at 12:00 PM, Thomas Fossati >>>>>>>>> <thomas.foss...@linaro.org> wrote: >>>>>>>>> >>>>>>>>> Hi Madison, all, >>>>>>>>> >>>>>>>>> On Wed, 7 May 2025 at 16:40, Madison Church >>>>>>>>> <mchu...@staff.rfc-editor.org> wrote: >>>>>>>>>> >>>>>>>>>> Hi Authors, *Debbie, >>>>>>>>>> >>>>>>>>>> *Debbie - As responsible AD for this document, please review >>>>>>>>>> the removal of RFC 7519 from the Normative References section >>>>>>>>>> and let us know if you approve. >>>>>>>>>> >>>>>>>>>> Authors - Thank you for your reply! We have updated the files >>>>>>>>>> as requested and all of our questions have been addressed. >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9782-rfcdiff.html (side >>>>>>>>>> by side) >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9782-auth48diff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9782-auth48rfcdiff.html >>>>>>>>>> (side by side) >>>>>>>>> >>>>>>>>> Thanks much, LGTM. >>>>>>>>> >>>>>>>>> cheers! >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9782 >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> RFC Editor/mc >>>>>>>>>> >>>>>>>>>>> On May 3, 2025, at 3:07 PM, Thomas Fossati >>>>>>>>>>> <thomas.foss...@linaro.org> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Madison, >>>>>>>>>>> >>>>>>>>>>> On Tue, 29 Apr 2025 at 20:21, Madison Church >>>>>>>>>>> <mchu...@staff.rfc-editor.org> wrote: >>>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> Works for us, thanks. >>>>>>>>>>> >>>>>>>>>>>>>> 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). >>>>>>>>>>> >>>>>>>>>>> We prefer it without the JWT reference. >>>>>>>>>>> The media types are for EAT, UCCS and UJCS, not JWT. >>>>>>>>>>> A clickable reference in that opening sentence leads away >>>>>>>>>>> from that. >>>>>>>>>>> >>>>>>>>>>> We think the document is OK without a JWT reference. >>>>>>>>>>> The CWT reference is just there for the “+cwt” registration, >>>>>>>>>>> not >>>>>>>>>>> because it is needed for any of the EAT media type >>>>>>>>>>> registrations. >>>>>>>>>>> >>>>>>>>>>> cheers, thanks! >>>>>>>>>>> Thomas, Henk & Laurence >>>> >>> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
