Hello Sarah, See my answers inline below.
On Mon, Mar 10, 2025 at 9:09 AM Sarah Tarrant <starr...@staff.rfc-editor.org> wrote: > Hi Sanjay, > > Thank you for your reply. We have updated the document accordingly. > > We have a few followup questions/comments. > > A) Regarding: > >> 7) <!-- [rfced] Please review "resource that is documentation" here. > Should this > >> be updated to "resource documentation", "documentation", or something > >> else? > >> > >> If any changes are made, we will ask IANA to update the "Link Relation > Types" > >> accordingly prior to publication (link to registry: > >> https://www.iana.org/assignments/link-relations). > >> > >> Original: > >> Description: Refers to a resource that is documentation (intended for > human > >> consumption) about the deprecation of the link's context. > >> > >> Perhaps: > >> Description: Refers to resource documentation (intended for human > >> consumption) about the deprecation of the link's context. > >> > >> Or: > >> Description: Refers to documentation (intended for human > >> consumption) about the deprecation of the link's context. > >> --> > > > > [sd] Resource's documentation and documentation about the depreaction of > the link's context could be two different things. Link may point to the > deprecation policy that applies to one or more resources. > > We're having trouble parsing your comment. Does this indicate no change to > the current text? > [sd] I think this works... "Description: Refers to documentation (intended for human consumption) about the deprecation of the link's context." > > > B) Regarding: > >> 11) <!-- [rfced] We note inconsistencies in the terms below throughout > the > >> text. Should these be uniform? If so, please let us know which form is > >> preferred. > > > >> Sunset HTTP header field > >> Sunset header field > >> --> > > We updated as you requested. How may we update the remaining terms for > consistency? > Sunset HTTP header field > Sunset header field > > [sd] Sunset HTTP response header field or Sunset HTTP response header > The updated files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9745.txt > https://www.rfc-editor.org/authors/rfc9745.pdf > https://www.rfc-editor.org/authors/rfc9745.html > https://www.rfc-editor.org/authors/rfc9745.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9745-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9745-auth48diff.html (AUTH48 > changes only) > > Note that it may be necessary for you to refresh your browser to view the > most recent version. > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9745 > > Thank you, > RFC Editor/st > > > > > On Mar 6, 2025, at 11:02 AM, Sanjay Dalal <sanjay.da...@berkeley.edu> > wrote: > > > > Hello Sarah, > > > > I had sent approval after reviewing diffs. Attached is xml with answers > to your questions. Look for "[sd]". > > > > @erik.wi...@dret.net pl review my answers too. Thanks! > > > > > > On Tue, Mar 4, 2025 at 11:25 AM Sarah Tarrant < > starr...@staff.rfc-editor.org> wrote: > > Hi Sanjay, > > > > We note that you responded to the other email regarding this document's > AUTH48 status: > > > > > Re: AUTH48: RFC-to-be 9745 <draft-ietf-httpapi-deprecation-header-09> > for your review > > > > > > I approve. > > > > We ask that, before we mark your approval, you resolve the questions we > have remaining. > > > > Please let us know if we can be of further assistance as you complete > your review. > > > > Thank you, > > RFC Editor/st > > > > > On Mar 3, 2025, at 4:02 PM, rfc-edi...@rfc-editor.org wrote: > > > > > > Authors, > > > > > > While reviewing this document during AUTH48, please resolve (as > necessary) the following questions, which are also in the XML file. > > > > > > > > > 1) <!-- [rfced] Please clarify "(in the sense of URI)" here. Also note > that we do > > > not see "URI" used elsewhere in the document. > > > > > > Original: > > > The Deprecation HTTP response header field is used to signal to > > > consumers of a resource (in the sense of URI) that the resource will > > > be or has been deprecated. > > > --> > > > > > > > > > 2) <!-- [rfced] We suggest updating "and possibly ways" to improve > readability of > > > the text. Also, this sentence includes both "Additionally" and > > > "additional". May we replace "additional" with "further" or something > > > similar? > > > > > > Original: > > > Additionally, the deprecation link > > > relation can be used to link to a resource that provides additional > > > information about planned or existing deprecation, and possibly ways > > > in which client application developers can best manage deprecation. > > > > > > Perhaps: > > > Additionally, the deprecation link > > > relation can be used to link to a resource that provides further > > > information about planned or existing deprecation. It may also > provide ways > > > in which client application developers can best manage deprecation. > > > --> > > > > > > > > > 3) <!-- [rfced] Would it be helpful to update this sentence to clarify > what the > > > document uses? Note that [STRUCTURED-FIELDS] has been published as an > RFC > > > 9651, so we updated the reference entry accordingly. We used [RFC9651] > as > > > the citation, bet us know if you prefer to use [STRUCTURED-FIELDS]. > > > > > > Original: > > > This document uses "Structured Field Values for HTTP" > > > ([STRUCTURED-FIELDS]) to specify syntax and parsing of date values. > > > > > > Perhaps: > > > This document uses the mechanisms defined in [RFC9651] to > > > specify syntax and parsing of date values. > > > --> > > > > > > > > > 4) <!-- [rfced] May we we update the text starting with "and > possibly..." as > > > follows to improve the flow of the sentence? > > > > > > Original: > > > This can happen before the actual > > > deprecation, to make a deprecation policy discoverable, or after > > > deprecation, when there may be documentation about the deprecation, > > > and possibly documentation of how to manage it. > > > > > > Perhaps: > > > This can happen before the actual > > > deprecation to make a deprecation policy discoverable or after > > > deprecation when there may be documentation about the deprecation and > > > how to manage it. > > > --> > > > > > > > > > 5) <!-- [rfced] Would it be helpful to update "under which > circumstances and with > > > which policies" for readability as follows? > > > > > > Original: > > > This may be the documentation explaining under which > > > circumstances and with which policies deprecation might take place. > > > > > > Perhaps: > > > This may be the documentation explaining the > > > circumstances in which deprecation might take place and the > deprecation policies. > > > --> > > > > > > > > > 6) <!-- [rfced] How may we update "allowing consumers to still" to > improve > > > clarity? > > > > > > Original: > > > The presence of a Deprecation header field in response is not meant > > > to signal a change in the meaning or function of a resource in the > > > context, allowing consumers to still use the resource in the same way > > > as they did before the resource was declared deprecated. > > > > > > Perhaps: > > > The presence of a Deprecation header field in a response is not meant > > > to signal a change in the meaning or function of a resource in the > > > context; consumers can still use the resource in the same way > > > as they did before the resource was declared deprecated. > > > --> > > > > > > > > > 7) <!-- [rfced] Please review "resource that is documentation" here. > Should this > > > be updated to "resource documentation", "documentation", or something > > > else? > > > > > > If any changes are made, we will ask IANA to update the "Link Relation > Types" > > > accordingly prior to publication (link to registry: > > > https://www.iana.org/assignments/link-relations). > > > > > > Original: > > > Description: Refers to a resource that is documentation (intended for > human > > > consumption) about the deprecation of the link's context. > > > > > > Perhaps: > > > Description: Refers to resource documentation (intended for human > > > consumption) about the deprecation of the link's context. > > > > > > Or: > > > Description: Refers to documentation (intended for human > > > consumption) about the deprecation of the link's context. > > > --> > > > > > > > > > 8) <!-- [rfced] How may we update the text starting with "even though > one > > > might..." to improve sentence clarity? > > > > > > Original: > > > Deprecated resources function as > > > they would have without sending the deprecation header field, even > > > though one might consider non-functional details such as making them > > > progressively less efficient with longer response time for example. > > > > > > Perhaps: > > > Deprecated resources function as > > > they would have without sending the Deprecation header field, > > > even though non-functional details may be affected (e.g., > > > they have less efficiency and longer response times). > > > --> > > > > > > > > > 9) <!-- [rfced] What does "it" refer to in this sentence? > > > > > > Original: > > > In cases where the Deprecation header field value is a date in the > > > future, it can lead to information that otherwise might not be > > > available. > > > > > > Perhaps: > > > In cases where the Deprecation header field value is a date in the > > > future, information might become available that would not be > available otherwise. > > > --> > > > > > > > > > 10) <!-- [rfced] Some sentences in the document mention deprecation of > the > > > resource while others mention deprecation of the context. Please review > > > and let us know if any updates are needed. > > > > > > deprecation of "resource": > > > resource will be or has been deprecated > > > resource in context of the message is or will be deprecated > > > resource in context has been deprecated > > > deprecation of the resource > > > deprecation of that specific resource > > > deprecation of a resource(s) > > > > > > deprecation of "context": > > > resource context will be deprecated > > > resource context has been deprecated > > > deprecation of the context > > > deprecation of the resource context > > > deprecation of the link's context > > > > > > Please also review use of "context" and let us know if any updates are > needed > > > for consistency and clarity. > > > > > > Examples: > > > resource in context of the message > > > resource context > > > resource in context > > > resource in the context > > > link's context > > > --> > > > > > > > > > 11) <!-- [rfced] We note inconsistencies in the terms below throughout > the > > > text. Should these be uniform? If so, please let us know which form is > > > preferred. > > > > > > Deprecation HTTP response header field > > > Deprecation HTTP header field > > > Deprecation response header field > > > Deprecation header field > > > > > > Sunset HTTP header field > > > Sunset header field > > > > > > deprecation link relation > > > "deprecation" link relation type > > > relation type deprecation > > > deprecation link relation type > > > > > > resource documentation > > > resource's documentation > > > > > > deprecation information > > > deprecation-related information > > > --> > > > > > > > > > 12) <!-- [rfced] We see inconsistent use of <tt> in this document. > Please review > > > the specific questions below. Note: In the html and pdf outputs, the > text > > > enclosed in <tt> is output in fixed-width font; in the txt output, > there > > > are no changes to the font. > > > > > > a) For header fields, we see use of both <tt> and no <tt>. See examples > > > below. Which form do you prefer? > > > > > > <tt>Deprecation</tt> header field > > > Deprecation header field > > > > > > <tt>Link</tt> header field > > > Link header field > > > > > > <tt>Sunset</tt> header field > > > Sunset HTTP header field > > > > > > > > > b) For the link relation type, we see use of <tt>, quotation marks, > and no > > > <tt> or quotation marks. Which form do you prefer? > > > > > > <tt>deprecation</tt> link relation type > > > "deprecation" link relation > > > deprecation link relation > > > --> > > > > > > > > > 13) <!-- [rfced] Please review each artwork element in the xml file. > Specifically, > > > should any artwork element be tagged as sourcecode or another element? > > > --> > > > > > > > > > 14) <!-- [rfced] Please review the "Inclusive Language" portion of the > online > > > Style Guide < > https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > > > and let us know if any changes are needed. Updates of this nature > typically > > > result in more precise language, which is helpful for readers. > > > > > > Note that our script did not flag any words in particular, but this > should > > > still be reviewed as a best practice. > > > --> > > > > > > > > > Thank you. > > > > > > RFC Editor/st/rv > > > > > > > > > On Mar 3, 2025, at 1:39 PM, rfc-edi...@rfc-editor.org wrote: > > > > > > *****IMPORTANT***** > > > > > > Updated 2025/03/03 > > > > > > 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/rfc9745.xml > > > https://www.rfc-editor.org/authors/rfc9745.html > > > https://www.rfc-editor.org/authors/rfc9745.pdf > > > https://www.rfc-editor.org/authors/rfc9745.txt > > > > > > Diff file of the text: > > > https://www.rfc-editor.org/authors/rfc9745-diff.html > > > https://www.rfc-editor.org/authors/rfc9745-rfcdiff.html (side by > side) > > > > > > Alt-diff of the text (allows you to more easily view changes > > > where text has been deleted or moved): > > > https://www.rfc-editor.org/authors/rfc9745-alt-diff.html > > > > > > Diff of the XML: > > > https://www.rfc-editor.org/authors/rfc9745-xmldiff1.html > > > > > > > > > Tracking progress > > > ----------------- > > > > > > The details of the AUTH48 status of your document are here: > > > https://www.rfc-editor.org/auth48/rfc9745 > > > > > > Please let us know if you have any questions. > > > > > > Thank you for your cooperation, > > > > > > RFC Editor > > > > > > -------------------------------------- > > > RFC9745 (draft-ietf-httpapi-deprecation-header-09) > > > > > > Title : The Deprecation HTTP Header Field > > > Author(s) : S. Dalal, E. Wilde > > > WG Chair(s) : Darrel Miller, Rich Salz > > > Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini > > > > > > > <rfc9745_sd.xml> > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
