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
