Kevin, We have now received all necessary approvals and consider AUTH48 complete (see https://www.rfc-editor.org/auth48/rfc9727).
Thank you for your attention and guidance during the AUTH48 process! We will prepare the document for publication at this time. Best, RFC Editor/mc > On Jun 4, 2025, at 3:33 PM, Madison Church <mchu...@staff.rfc-editor.org> > wrote: > > Hi David, > > The updates look good, thank you! > > RFC Editor/mc > >> On Jun 4, 2025, at 3:03 PM, David Dong via RT <iana-mat...@iana.org> wrote: >> >> Hi Madison, >> >> This has been completed: >> >> api-catalog Refers to a list of APIs available from the Publisher of the >> link context. [RFC-ietf-httpapi-api-catalog-08] >> >> Registry: >> https://www.iana.org/assignments/link-relations/ >> >> Thank you! >> >> Best regards, >> >> David Dong >> IANA Services Sr. Specialist >> >> On Wed Jun 04 17:26:16 2025, mchu...@staff.rfc-editor.org wrote: >>> IANA, >>> >>> Please update the Description column for "api-catalog" in the "Link >>> Relation Types” registry (https://www.iana.org/assignments/link- >>> relations/link-relations.xhtml) to match the edited document (see >>> https://www.rfc-editor.org/authors/rfc9727-diff.html). >>> >>> Original: >>> Refers to a list of APIs available from the publisher of the link >>> context. >>> >>> Updated (capitalize "Publisher"): >>> Refers to a list of APIs available from the Publisher of the link >>> context. >>> >>> Thank you! >>> RFC Editor/mc >>> >>>> On Jun 4, 2025, at 12:18 PM, Madison Church <mchu...@staff.rfc- >>>> editor.org> wrote: >>>> >>>> Hi Kevin, >>>> >>>> Thank you for your quick reply! We have noted your approval here: >>>> https://www.rfc-editor.org/auth48/rfc9727. >>>> >>>> We will now ask IANA to make their updates before moving this >>>> document forward in the publication process. >>>> >>>> Thank you, >>>> RFC Editor/mc >>>> >>>>> On Jun 4, 2025, at 11:12 AM, Kevin Smith, Vodafone >>>>> <kevin.sm...@vodafone.com> wrote: >>>>> >>>>> Dear Madison, all, >>>>> >>>>> I approve this RFC for publication. >>>>> >>>>> Many thanks to all for the updates and support throughout the >>>>> process! >>>>> >>>>> All best, >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Madison Church <mchu...@staff.rfc-editor.org> >>>>> Sent: 04 June 2025 16:18 >>>>> To: Kevin Smith, Vodafone <kevin.sm...@vodafone.com> >>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; httpapi-...@ietf.org; >>>>> httpapi-cha...@ietf.org; dar...@tavis.ca; >>>>> francesca.palomb...@ericsson.com; auth48archive@rfc-editor.org >>>>> Subject: Re: AUTH48: RFC-to-be 9727 <draft-ietf-httpapi-api-catalog- >>>>> 08> for your review >>>>> >>>>> [You don't often get email from mchu...@staff.rfc-editor.org. Learn >>>>> why this is important at >>>>> https://aka.ms/LearnAboutSenderIdentification ] >>>>> >>>>> This email was sent from outside our network. Please verify if the >>>>> sender is trusted and be cautious of suspicious links or >>>>> attachments. If you are unsure, kindly use the Report button to >>>>> submit the email. >>>>> >>>>> Hi Kevin, >>>>> >>>>> Thank you for your reply. We have updated the document accordingly >>>>> 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/rfc9727.txt >>>>> https://www.rfc-editor.org/authors/rfc9727.pdf >>>>> https://www.rfc-editor.org/authors/rfc9727.html >>>>> https://www.rfc-editor.org/authors/rfc9727.xml >>>>> >>>>> The relevant diff files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9727-diff.html (comprehensive >>>>> diff) >>>>> https://www.rfc-editor.org/authors/rfc9727-rfcdiff.html (side by >>>>> side) >>>>> https://www.rfc-editor.org/authors/rfc9727-auth48diff.html (diff >>>>> showing AUTH48 changes) >>>>> https://www.rfc-editor.org/authors/rfc9727-auth48rfcdiff.html (side >>>>> by side of AUTH48 changes) >>>>> >>>>> For the AUTH48 status of this document, please see: >>>>> https://www.rfc-editor.org/auth48/rfc9727 >>>>> >>>>> Thank you, >>>>> RFC Editor/mc >>>>> >>>>>> On Jun 3, 2025, at 7:53 AM, Kevin Smith, Vodafone >>>>>> <Kevin.Smith=40vodafone....@dmarc.ietf.org> wrote: >>>>>> >>>>>> Dear RFC Editor(s), Thanks for your review and helpful >>>>>> suggestions. Please see my answers below. >>>>>> >>>>>> 1) Approved >>>>>> 2) Please add the keyword 'API' (which is in the list at >>>>>> https://www/. >>>>>> ietf.org%2Ftechnologies%2Fkeywords%2F&data=05%7C02%7CKevin.Smith%40vod >>>>>> afone.com%7C0b4a17886f4f45b3750008dda37b09a2%7C68283f3b84874c86adb3a52 >>>>>> 28f18b893%7C0%7C0%7C638846471438092763%7CUnknown%7CTWFpbGZsb3d8eyJFbXB >>>>>> 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI >>>>>> ldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=ZeeIxcQLRhlPpnCa4J3H1HZzsxFKQ92 >>>>>> myupcElpzXoE%3D&reserved=0) >>>>>> 3) Please use the third (‘Or’) option >>>>>> 4) Approved >>>>>> 5) Approved >>>>>> 6) Approved (the ‘Perhaps’ option) >>>>>> 7) Approved (the ‘Perhaps’ option) >>>>>> 8) Approved >>>>>> 9) I agree the original wording is confusing, however the suggested >>>>>> change does not reflect the intent . How about: >>>>>> Section 5.1 >>>>>> OLD >>>>>> If the Publisher is not the domain authority for >>>>>> http://www.example.net/ - >>>>>> or any third-party domain that hosts any of the Publisher's APIs - >>>>>> then the >>>>>> Publisher MAY include a link in its own API catalog to that third- >>>>>> party >>>>>> domain's API catalog. >>>>>> >>>>>> NEW >>>>>> If the Publisher is not the domain authority for >>>>>> http://www.example.net/, >>>>>> then the Publisher’s API Catalog MAY include a link to the >>>>>> API catalog of the third-party that is the domain authority for >>>>>> http://www.e/ >>>>>> xample.net%2F&data=05%7C02%7CKevin.Smith%40vodafone.com%7C0b4a17886f4f >>>>>> 45b3750008dda37b09a2%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C6388 >>>>>> 46471438138100%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI >>>>>> wLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000% >>>>>> 7C%7C%7C&sdata=YKW3Uqnxwm99WnqPtAAP1Oy%2BfuFJEtFySUSCcdf3hXs%3D&reserv >>>>>> ed=0 >>>>>> >>>>>> 10) Approved >>>>>> 11) Approved >>>>>> 12) Noted >>>>>> 13) Approved (the ‘Perhaps’ option) >>>>>> 14) Approved (the ‘Perhaps’ option) >>>>>> 15) Here is an updated reference entry for [RESTdesc], note there >>>>>> no date on the website, only the current year. >>>>>> Current: >>>>>> [RESTdesc] Ruben Verborgh, Erik Mannens, Rick Van de Walle, and >>>>>> Thomas Steiner, "RESTdesc", 15 September 2023, >>>>>> < apisjson.org/format/apisjson_0.16.txt>. >>>>>> >>>>>> New: >>>>>> [RESTdesc] Ruben Verborgh, Erik Mannens, Rick Van de Walle, and >>>>>> Thomas Steiner, "RESTdesc", 2025, >>>>>> < https://restdesc.org/about/descriptions >. 16) >>>>>> Approved (the ‘Perhaps’ option) >>>>>> 17) Approved >>>>>> 18) Approved >>>>>> 19) Checked and Approved >>>>>> 20) Approved: please can you set type to "json"? >>>>>> 21) Reviewed, I'm not aware of any changes needed. >>>>>> In addition, there is one typo introduced in the newly revised >>>>>> version: >>>>>> Section: Abstract >>>>>> OLD: >>>>>> well-know >>>>>> NEW: >>>>>> well-known >>>>>> >>>>>> Many thanks, >>>>>> Kevin >>>>>> -----Original Message----- >>>>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >>>>>> Sent: 03 June 2025 00:59 >>>>>> To: Kevin Smith, Vodafone <kevin.sm...@vodafone.com> >>>>>> Cc: rfc-edi...@rfc-editor.org; httpapi-...@ietf.org; >>>>>> httpapi-cha...@ietf.org; >>>>>> dar...@tavis.ca;francesca.palomb...@ericsson.com; >>>>>> auth48archive@rfc-editor.org >>>>>> Subject: Re: AUTH48: RFC-to-be 9727 <draft-ietf-httpapi-api- >>>>>> catalog-08> for your review >>>>>> This email was sent from outside our network. Please verify >>>>>> if the sender is trusted and be cautious of suspicious links or >>>>>> attachments. If you are unsure, kindly use the Report button to >>>>>> submit the email. >>>>>> Authors, >>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>> necessary) the following questions, which are also in the XML file. >>>>>> 1) <!-- [rfced] FYI - We have updated the short title of the >>>>>> document, which appears in the running header in the PDF output, as >>>>>> follows. >>>>>> Please review and let us know any objections. >>>>>> Original: >>>>>> api-catalog well-known URI >>>>>> Current: >>>>>> api-catalog: A Well-Known URI >>>>>> --> >>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that >>>>>> appear in the title) for use onhttps://www.rfc-editor.org/search. >>>>>> --> >>>>>> 3) <!-- [rfced] Are the goals listed in Section 1.1 specified for >>>>>> api-catalog or for this document? >>>>>> Current: >>>>>> The primary goal is to facilitate the automated discovery of a >>>>>> Publisher's public API endpoints, along with metadata that >>>>>> describes the >>>>>> purpose and usage of each API, by specifying a well-known URI that >>>>>> returns an >>>>>> API catalog document. >>>>>> Perhaps: >>>>>> The primary goal for api-catalog is to facilitate the automated >>>>>> discovery of a >>>>>> Publisher's public API endpoints, along with metadata that >>>>>> describes the >>>>>> purpose and usage of each API, by specifying a well-known URI that >>>>>> returns an >>>>>> API catalog document. >>>>>> Or: >>>>>> The primary goal of this document is to facilitate the automated >>>>>> discovery of a >>>>>> Publisher's public API endpoints, along with metadata that >>>>>> describes the >>>>>> purpose and usage of each API, by specifying a well-known URI that >>>>>> returns an >>>>>> API catalog document. >>>>>> --> >>>>>> 4) <!-- [rfced] We find this sentence difficult to parse. We have >>>>>> updated the text to read as follows. Please let us know any >>>>>> objections. >>>>>> Original: >>>>>> For scenarios >>>>>> where the Publisher "example" is not the authority for a given >>>>>> _.example._ domain then that is made explicit in the text. >>>>>> Current: >>>>>> Scenarios where the Publisher "example" is not the authority for a >>>>>> given _.example._ domain are made explicit in the text. >>>>>> --> >>>>>> 5) <!-- [rfced] May we reformat the bulleted list items in Section >>>>>> 3.1 into paragraph form? >>>>>> Original: >>>>>> 3.1. Using additional link relations >>>>>> * "item" [RFC6573]. When used in an API catalog document, the >>>>>> "item" link relation identifies a target resource that >>>>>> represents >>>>>> an API that is a member of the API catalog. >>>>>> * Other link relations may be utilised in an API catalog to >>>>>> convey >>>>>> metadata descriptions for API links. >>>>>> Perhaps: >>>>>> 3.1. Using Additional Link Relations >>>>>> When used in an API catalog document, the "item" [RFC6573] link >>>>>> relation >>>>>> identifies a target resource that represents an API that is a >>>>>> member of the >>>>>> API catalog. >>>>>> Other link relations may be utilised in an API catalog to convey >>>>>> metadata descriptions for API links. >>>>>> --> >>>>>> 6) <!-- [rfced] Is "As illustration" meant to be "as illustrated" >>>>>> in this context? Would "For example" also work here for simplicity? >>>>>> Original: >>>>>> As illustration, the API catalog document URI of >>>>>> https://www.example.com/my_api_catalog.json can be requested >>>>>> directly, or via a request to https://www.example.com/.well-known/ >>>>>> api-catalog, which the Publisher will resolve to >>>>>> https://www.example.com/my_api_catalog. >>>>>> Perhaps: >>>>>> For example, the API catalog document URI of >>>>>> https://www.example.com/my_api_catalog.json can be requested >>>>>> directly or via a request to https://www.example.com/.well-known/ >>>>>> api-catalog, which the Publisher will resolve to >>>>>> https://www.example.com/my_api_catalog. >>>>>> --> >>>>>> 7) <!-- [rfced] May we split the sentence below into two sentences >>>>>> to improve readability? >>>>>> Original: >>>>>> The API catalog MUST include hyperlinks to API endpoints, and is >>>>>> RECOMMENDED to include useful metadata, such as usage policies, >>>>>> API >>>>>> version information, links to the OpenAPI Specification [OAS] >>>>>> definitions for each API, etc. >>>>>> Perhaps: >>>>>> The API catalog MUST include hyperlinks to API endpoints. It is >>>>>> RECOMMENDED that the API catalog also includes useful metadata, >>>>>> such as usage >>>>>> policies, API version information, links to the OpenAPI >>>>>> Specification [OAS] >>>>>> definitions for each API, etc. >>>>>> --> >>>>>> 8) <!-- [rfced] FYI - We have updated the citation below since >>>>>> Section 5.3 of [HTTP] doesn't appear to mention "content >>>>>> negotiation", while Section 12 of [HTTP] is titled "Content >>>>>> Negotiation". Please review. >>>>>> Original: >>>>>> The Publisher MAY make additional formats available via content >>>>>> negotiation (section 5.3 of [HTTP]) to their /.well-known/api- >>>>>> catalog >>>>>> location. >>>>>> Current: >>>>>> The Publisher MAY make additional formats available via content >>>>>> negotiation (Section 12 of [HTTP]) to their /.well-known/api- >>>>>> catalog >>>>>> location. >>>>>> --> >>>>>> 9) <!-- [rfced] May we rephrase the following sentence for clarity? >>>>>> Original: >>>>>> If the Publisher is not the domain authority for >>>>>> http://www.example.net/ - >>>>>> or any third-party domain that hosts any of the Publisher's APIs - >>>>>> then the >>>>>> Publisher MAY include a link in its own API catalog to that third- >>>>>> party >>>>>> domain's API catalog. >>>>>> Perhaps: >>>>>> If the Publisher or any third-party domain that hosts any of the >>>>>> Publisher's APIs is not the domain authority for >>>>>> http://www.example.net/, then the >>>>>> Publisher MAY include a link in its own API catalog to that third- >>>>>> party >>>>>> domain's API catalog. >>>>>> --> >>>>>> 10) <!--[rfced] As this sentence reads awkwardly due to the two >>>>>> instances of "already", may we remove the first one? >>>>>> Original: >>>>>> This grouping may already be implicit >>>>>> where the Publisher has already published their APIs across >>>>>> multiple >>>>>> domains, e.g. at gaming.example.com, iot.example.net, etc. >>>>>> Perhaps: >>>>>> This grouping may be implicit >>>>>> where the Publisher has already published their APIs across >>>>>> multiple >>>>>> domains, e.g., at gaming.example.com, iot.example.net, etc. >>>>>> --> >>>>>> 11) <!-- [rfced] We note that Section 6.3 is titled "Registration >>>>>> of the api-catalog Well-Known URI" and simply states "See Section 7 >>>>>> considerations below." The section that follows immediately is the >>>>>> api-catalog well-known URI IANA registration, thus Section 6.3 >>>>>> seems redundant. May we remove this section to avoid repetition? >>>>>> --> >>>>>> 12) <!-- [rfced] FYI - We have updated "THIS-RFC-URL" to >>>>>> "https://www.rfc-editor.org/info/rfc9727";. Note that this URL will >>>>>> lead to a page that states "RFC 9727 does not exist" until this >>>>>> document is published. >>>>>> --> >>>>>> 13) <!-- [rfced] Please review the following reference. The URL >>>>>> uses the "latest published version", which now takes the reader to >>>>>> version 3.1.1 of [OAS] rather than version 3.1.0 (please note that >>>>>> there has also been a change of authors between versions). Please >>>>>> clarify if you wish for this reference to point to one of these >>>>>> specific versions. If you would like to refer to the latest >>>>>> version, we recommend the following format (with an added >>>>>> annotation). >>>>>> Current: >>>>>> [OAS] Darrel Miller, Ed., Jeremy Whitlock, Ed., Marsh >>>>>> Gardiner, >>>>>> Ed., Mike Ralphson, Ed., Ron Ratovsky, Ed., and Uri >>>>>> Sarid, >>>>>> Ed., "OpenAPI Specification v3.1.0", 15 February 2021, >>>>>> <https://spec.openapis.org/oas/latest>. >>>>>> Perhaps: >>>>>> [OAS] Miller, D., Ed., Andrews, H., Ed., Whitlock, J., Ed., >>>>>> Mitchell, >>>>>> L., Ed., Gardiner, M., Ed., Quintero, M., Ed., Kistler, >>>>>> M., Ed., >>>>>> Handl, R., Ed., and R. Ratovsky, Ed., "OpenAPI >>>>>> Specification >>>>>> v3.1.1", 24 October 2024, >>>>>> <https://spec.openapis.org/oas/v3.1.1.html>. >>>>>> Latest version available at >>>>>> <https://spec.openapis.org/oas/latest.html>. >>>>>> --> >>>>>> 14) <!-- [rfced] Please review the following reference. The date >>>>>> provided for this reference is 15 September 2020, but the URL lists >>>>>> a >>>>>> date of >>>>>> 9 January 2020. We have updated this reference to use that date. >>>>>> There are also more recent versions of this specification (see >>>>>> https://apisjson.org/). The latest version was released on 6 >>>>>> November 2024 (see https://apisjson.org/format/apisjson_0.19.txt). >>>>>> Would you like us to update the URL to use the most current version >>>>>> and date for this reference? >>>>>> Current: >>>>>> [APIsjson] Lane, K. and S. Willmott, "API Discovery Format", 9 >>>>>> January 2020, >>>>>> <http://apisjson.org/format/apisjson_0.16.txt>. >>>>>> Perhaps: >>>>>> [APIsjson] Lane, K. and S. Willmott, "API Discovery Format", 6 >>>>>> November 2024, >>>>>> <https://apisjson.org/format/apisjson_0.19.txt>. >>>>>> Latest version available at <https://apisjson.org/>. >>>>>> --> >>>>>> 15) <!-- [rfced] Please review the reference entry for [RESTdesc]. >>>>>> It uses the same URL as [APIsjson] >>>>>> (https://apisjson.org/format/apisjson_0.16.txt). >>>>>> We found the following the URL, which appears to match some of the >>>>>> original reference information provided:https://restdesc.org/. >>>>>> Please provide an updated reference entry for [RESTdesc]. >>>>>> Current: >>>>>> [RESTdesc] Ruben Verborgh, Erik Mannens, Rick Van de Walle, and >>>>>> Thomas Steiner, "RESTdesc", 15 September 2023, >>>>>> <http://apisjson.org/format/apisjson_0.16.txt>. >>>>>> --> >>>>>> 16) <!-- [rfced] May we rephrase the following section title to >>>>>> avoid using RFC >>>>>> 8615 as an adjective? >>>>>> Also, we have updated the RFC number to 8631 as we belive this was >>>>>> the intended RFC. >>>>>> Original: >>>>>> A.1. Using Linkset with RFC8615 relations >>>>>> Perhaps: >>>>>> A.1. Using Linkset with Link Relations Defined in RFC 8631 >>>>>> --> >>>>>> 17) <!-- [rfced] We have updated the following bulleted list into a >>>>>> definition list for a more cohesive presentation. Please let us >>>>>> know any objections. >>>>>> Original: >>>>>> * "service-desc", used to link to a description of the API that >>>>>> is >>>>>> primarily intended for machine consumption (for example the >>>>>> [OAS] >>>>>> specification YAML or JSON file). >>>>>> * "service-doc", used to link to API documentation that is >>>>>> primarily >>>>>> intended for human consumption (an example of human-readable >>>>>> documentation is the IETF Internet-Draft submission API >>>>>> instructions (https://datatracker.ietf.org/api/submission)). >>>>>> * "service-meta", used to link to additional metadata about the >>>>>> API, >>>>>> and is primarily intended for machine consumption. >>>>>> * "status", used to link to the API status (e.g. API "health" >>>>>> indication etc.) for machine and/or human consumption. >>>>>> Current: >>>>>> "service-desc": Used to link to a description of the API that is >>>>>> primarily intended for machine consumption (for example, the >>>>>> [OAS] >>>>>> specification YAML or JSON file). >>>>>> "service-doc": Used to link to API documentation that is >>>>>> primarily >>>>>> intended for human consumption (an example of human-readable >>>>>> documentation is the IETF Internet-Draft submission API >>>>>> instructions (https://datatracker.ietf.org/api/submission)). >>>>>> "service-meta": Used to link to additional metadata about the >>>>>> API >>>>>> and is primarily intended for machine consumption. >>>>>> "status": Used to link to the API status (e.g., API "health" >>>>>> indication) >>>>>> for machine and/or human consumption. >>>>>> --> >>>>>> 18) <!-- [rfced] We note that the document uses single quotes (') >>>>>> and double quotes (") inconsistently. For example, "api-catalog" >>>>>> and "example" appear multiple times using both single and double >>>>>> quotes. Is this intentional? >>>>>> If there are no objections, may we replace all instances of single >>>>>> quotes with double quotes for consistency? >>>>>> --> >>>>>> 19) <!-- [rfced] FYI - We have added expansions for the following >>>>>> abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). >>>>>> Please review each expansion in the document carefully to ensure >>>>>> correctness. >>>>>> Cross-Origin Resource Sharing (CORS) >>>>>> Fully Qualified Domain Name (FQDN) >>>>>> Top-Level Domain (TLD) >>>>>> --> >>>>>> 20) <!-- [rfced] We updated artwork to sourcecode in Appendix A.1, >>>>>> A.2, and A.4 to match the sourcecode element in Section 5.1. Please >>>>>> confirm that this is correct. >>>>>> Please consider whether the "type" attribute for these sourcecode >>>>>> elements should be set to "json", "pseudocode", or something else. >>>>>> The current list of preferred values for "type" is available at >>>>>> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. >>>>>> If the current list does not contain an applicable type, feel free >>>>>> to suggest additions for consideration. >>>>>> Note that it is also acceptable to leave the "type" attribute not >>>>>> set. >>>>>> --> >>>>>> 21) <!-- [rfced] Please review the "Inclusive Language" portion of >>>>>> the online Style Guide >>>>>> <https://www/ >>>>>> .rfc- >>>>>> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7 >>>>>> C02%7CKevin.Smith%40vodafone.com%7C0b4a17886f4f45b3750008dda37b09a2%7C >>>>>> 68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C638846471438505507%7CUnknow >>>>>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW >>>>>> 4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=zqqzFZFi >>>>>> X87GaJC%2BHCkgCWxQ%2BrVBgzq7Ze6owhdrLuE%3D&reserved=0> >>>>>> 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. --> >>>>>> Thank you. >>>>>> RFC Editor/mc/ap >>>>>> On Jun 2, 2025, at 4:57 PM, rfc-editor@rfc-editor.orgwrote: >>>>>> *****IMPORTANT***** >>>>>> Updated 2025/06/02 >>>>>> RFC Author(s): >>>>>> -------------- >>>>>> Instructions for Completing AUTH48 >>>>>> Your document has now entered AUTH48. Once it has been reviewed >>>>>> and approved by you and all coauthors, it will be published as an >>>>>> RFC. >>>>>> If an author is no longer available, there are several remedies >>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>>>> You and you coauthors are responsible for engaging other parties >>>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>>> your approval. >>>>>> Planning your review >>>>>> --------------------- >>>>>> Please review the following aspects of your document: >>>>>> * RFC Editor questions >>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>> that have been included in the XML file as comments marked as >>>>>> follows: >>>>>> <!-- [rfced] ... --> >>>>>> These questions will also be sent in a subsequent email. >>>>>> * Changes submitted by coauthors >>>>>> Please ensure that you review any changes submitted by your >>>>>> coauthors. We assume that if you do not speak up that you >>>>>> agree to changes submitted by your coauthors. >>>>>> * Content >>>>>> Please review the full content of the document, as this cannot >>>>>> change once the RFC is published. Please pay particular attention >>>>>> to: >>>>>> - IANA considerations updates (if applicable) >>>>>> - contact information >>>>>> - references >>>>>> * Copyright notices and legends >>>>>> Please review the copyright notice and legends as defined in >>>>>> RFC 5378 and the Trust Legal Provisions >>>>>> (TLP – https://trustee.ietf.org/license-info). >>>>>> * Semantic markup >>>>>> Please review the markup in the XML file to ensure that elements >>>>>> of >>>>>> content are correctly tagged. For example, ensure that >>>>>> <sourcecode> >>>>>> and <artwork> are set correctly. See details at >>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>>>> * Formatted output >>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>> formatted output, as generated from the markup in the XML file, is >>>>>> reasonable. Please note that the TXT will have formatting >>>>>> limitations compared to the PDF and HTML. >>>>>> Submitting changes >>>>>> ------------------ >>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as >>>>>> all the parties CCed on this message need to see your changes. The >>>>>> parties >>>>>> include: >>>>>> * your coauthors >>>>>> * rfc-edi...@rfc-editor.org (the RPC team) >>>>>> * other document participants, depending on the stream (e.g., >>>>>> IETF Stream participants are your working group chairs, the >>>>>> responsible ADs, and the document shepherd). >>>>>> * auth48archive@rfc-editor.org, which is a new archival mailing >>>>>> list >>>>>> to preserve AUTH48 conversations; it is not an active >>>>>> discussion >>>>>> list: >>>>>> * More info: >>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh- >>>>>> 4Q9l2USxIAe6P8O4Zc >>>>>> * The archive itself: >>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>> * Note: If only absolutely necessary, you may temporarily opt >>>>>> out >>>>>> of the archiving of messages (e.g., to discuss a sensitive >>>>>> matter). >>>>>> If needed, please add a note at the top of the message that >>>>>> you >>>>>> have dropped the address. When the discussion is concluded, >>>>>> auth48archive@rfc-editor.org will be re-added to the CC list >>>>>> and >>>>>> its addition will be noted at the top of the message. >>>>>> You may submit your changes in one of two ways: >>>>>> An update to the provided XML file >>>>>> — OR — >>>>>> An explicit list of changes in this format Section # (or indicate >>>>>> Global) >>>>>> OLD: >>>>>> old text >>>>>> NEW: >>>>>> new text >>>>>> You do not need to reply with both an updated XML file and an >>>>>> explicit list of changes, as either form is sufficient. >>>>>> We will ask a stream manager to review and approve any changes that >>>>>> seem beyond editorial in nature, e.g., addition of new text, >>>>>> deletion of text, and technical changes. Information about stream >>>>>> managers can be found in the FAQ. Editorial changes do not require >>>>>> approval from a stream manager. >>>>>> Approving for publication >>>>>> -------------------------- >>>>>> To approve your RFC for publication, please reply to this email >>>>>> stating that you approve this RFC for publication. Please use >>>>>> ‘REPLY ALL’, as all the parties CCed on this message need to see >>>>>> your approval. >>>>>> Files >>>>>> ----- >>>>>> The files are available here: >>>>>> https://www.rfc-editor.org/authors/rfc9727.xml >>>>>> https://www.rfc-editor.org/authors/rfc9727.html >>>>>> https://www.rfc-editor.org/authors/rfc9727.pdf >>>>>> >>>>>> https://www/. >>>>>> rfc- >>>>>> editor.org%2Fauthors%2Frfc9727.txt&data=05%7C02%7CKevin.Smith%40vo >>>>>> dafone.com%7C0b4a17886f4f45b3750008dda37b09a2%7C68283f3b84874c86adb3a5 >>>>>> 228f18b893%7C0%7C0%7C638846471438659317%7CUnknown%7CTWFpbGZsb3d8eyJFbX >>>>>> B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >>>>>> IldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=JIcOObyaRe0%2BlBg%2FjFoLxr9bxA >>>>>> wU4S36dl372rEISpM%3D&reserved=0 >>>>>> Diff file of the text: >>>>>> https://www.rfc-editor.org/authors/rfc9727-diff.html >>>>>> >>>>>> https://www.rfc-editor.org/authors/rfc9727-rfcdiff.html (side by >>>>>> side) Diff of the XML: >>>>>> https://www.rfc-editor.org/authors/rfc9727-xmldiff1.html >>>>>> Tracking progress >>>>>> ----------------- >>>>>> The details of the AUTH48 status of your document are here: >>>>>> >>>>>> https://www/. >>>>>> rfc- >>>>>> editor.org%2Fauth48%2Frfc9727&data=05%7C02%7CKevin.Smith%40vodafon >>>>>> e.com%7C0b4a17886f4f45b3750008dda37b09a2%7C68283f3b84874c86adb3a5228f1 >>>>>> 8b893%7C0%7C0%7C638846471438711801%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1 >>>>>> hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI >>>>>> joyfQ%3D%3D%7C60000%7C%7C%7C&sdata=12yVMWjFy1G72baZA%2FM2GVTDXgQbXSbV% >>>>>> 2FsOQFGgXk%2F4%3D&reserved=0 Please let us know if you have any >>>>>> questions. >>>>>> Thank you for your cooperation, >>>>>> RFC Editor >>>>>> -------------------------------------- >>>>>> RFC9727 (draft-ietf-httpapi-api-catalog-08) >>>>>> Title : api-catalog: a well-known URI and link relation >>>>>> to help discovery of APIs >>>>>> Author(s) : K. Smith >>>>>> WG Chair(s) : Darrel Miller, Rich Salz >>>>>> Area Director(s) : Gorry Fairhurst, Mike Bishop >>>>>> >>>>>> C2 General >>>>> >>>>> >>>>> >>>>> C2 General -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
