Greetings,
Unfortunately, the following lines extend 1 character beyond the margin. How
may we break these lines so they fit within the 69 character limit?
"api-catalog": "https://www.example.net/.well-known/api-catalog”
"href": "https://developer.example.com/apis/foo_api/policies";,
We will wait to hear from you before continuing with the publication process.
Thank you,
RFC Editor/sg
> On Jun 4, 2025, at 10:18 AM, Madison Church <[email protected]>
> 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
>> <[email protected]> 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 <[email protected]>
>> Sent: 04 June 2025 16:18
>> To: Kevin Smith, Vodafone <[email protected]>
>> Cc: RFC Editor <[email protected]>; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]
>> Subject: Re: AUTH48: RFC-to-be 9727 <draft-ietf-httpapi-api-catalog-08> for
>> your review
>>
>> [You don't often get email from [email protected]. 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
>>> <[email protected]> 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: [email protected] <[email protected]>
>>> Sent: 03 June 2025 00:59
>>> To: Kevin Smith, Vodafone <[email protected]>
>>> Cc: [email protected]; [email protected];
>>> [email protected];
>>> [email protected];[email protected];
>>> [email protected]
>>> 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, [email protected]:
>>> *****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
>>> * [email protected] (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).
>>> * [email protected], 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,
>>> [email protected] 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 -- [email protected]
To unsubscribe send an email to [email protected]
