Ah, I missed that. Sorry about that. Thanks for your patience. https://github.com/ietf-wg-httpapi/deprecation-header/commit/a32eb7f65cddd8a4dc6ff1899814ae3756710e66
https://github.com/ietf-wg-httpapi/deprecation-header/blob/main/draft-ietf-httpapi-deprecation-header.md On Thu, Sep 12, 2024 at 1:25 PM Robert Sparks <rjspa...@nostrum.com> wrote: > Thanks - its going in the right direction I think. > > Please look again where you are saying applications will make an educated > guess and if that's really _software_ maybe choose different words than > "educated guess"? Software can't do that. > > RjS > On 9/12/24 3:20 PM, Sanjay Dalal wrote: > > Hello Robert, > > Thanks for clarifying. Take a look at > https://github.com/ietf-wg-httpapi/deprecation-header/commit/5d4a4f65175001cea293204c9e245388f1552d45. > I went ahead and re-looked where a human would be needed and added > "developer" over there. > > If you are ok now, I will mark this issue resolved. We will publish the > draft once we have addressed comments we may receive from other reviewers. > > regards, > sanjay > > On Thu, Sep 12, 2024 at 9:34 AM Robert Sparks <rjspa...@nostrum.com> > wrote: > >> Thanks Sanjay - >> >> I think there's still some tension to resolve on who has agency in >> several places. With the description in section 6.2 in mind (particularly >> at "intended for human consumption", please look again at the places you've >> changed "client" to "client application". You're still talking in places of >> having the application do things an application can't do. Only the >> application developers can do them. >> >> What does it mean for an application to make an educated guess? >> >> How does an application inspect (and make sense of) a home document? >> >> In both of those places, and others, you are talking about humans doing >> things, not applications. >> >> RjS >> On 9/12/24 11:19 AM, Sanjay Dalal wrote: >> >> Hello Robert, >> >> Thanks for your review comments. We captured your review notes in >> https://github.com/ietf-wg-httpapi/deprecation-header/issues/35 and we >> have addressed those. Draft 08 published today >> https://datatracker.ietf.org/doc/draft-ietf-httpapi-deprecation-header/ >> incorporates all your comments per our understanding. Let me know if >> something is missed. >> >> regards, >> sanjay >> >> On Thu, Aug 29, 2024 at 10:21 AM Robert Sparks via Datatracker < >> nore...@ietf.org> wrote: >> >>> Reviewer: Robert Sparks >>> Review result: Almost Ready >>> >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>> >>> For more information, please see the FAQ at >>> >>> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. >>> >>> Document: draft-ietf-httpapi-deprecation-header-06 >>> Reviewer: Robert Sparks >>> Review Date: 2024-08-29 >>> IETF LC End Date: 2024-09-06 >>> IESG Telechat date: Not scheduled for a telechat >>> >>> Summary:Almost Ready for publication as a Proposed Standard (?) RFC >>> >>> Why is this standards track? The shepherd's writeup explanation of "that >>> makes >>> sense since it defines a new HTTP header field" seems at odds with >>> RFC8594 >>> being Informational. Should that have been standards track? >>> >>> Generally, the document would benefit from an editorial pass further >>> clarifying >>> when it is talking about an application or a developer. There are many >>> points >>> where it says application or client when it means developer. Some key >>> instances: * Introduction: "informs applications about the risk" * >>> Security >>> considerations "Applications consuming the resource SHOULD check the >>> referred >>> resource documentation to verify authenticity and accuracy." * Security >>> considerations "Therefore, applications consuming the resource SHOULD, if >>> possible, consult the resource developer to discuss potential impact due >>> to >>> deprecation and plan for possible transition to a recommended >>> resource(s)" >>> >>> There is a contradiction between section 5's "Deprecated resources >>> SHOULD keep >>> functioning as before" and the Security Consideration's "Deprecated >>> resources >>> MUST function (almost) as before," >>> >>> In both cases, "function as before" is not really what you mean. >>> "function as >>> they would have without sending the deprecation header" is closer. As >>> written, >>> (particularly if the MUST above is what you intend), this puts an >>> unverifiable >>> requirement on the resource. I suggest changing the language similar to >>> what I >>> suggested you mean. Or, better, step back and reformulate this as a >>> simple >>> statement that the presence of a Deprecation header is not meant to >>> signal a >>> change in the meaning or function of a resource in the context of this >>> response, and avoid using 2119 keywords. >>> >>> I realize that Appendix A won't appear in the resulting RFC, but the >>> drafts >>> will still be in the archive. Calling an internet draft an >>> implementation and >>> an organization is just strange. Revising the draft to use a separate >>> section >>> (or just a sentence) to say draft-loffredo-regex-rdap-jcard-deprecation >>> is a >>> specification that says to use this mechanic would make more sense than >>> listing >>> it as an implementation. >>> >>> Since the WG felt using structured fields was important for this header, >>> consider creating a Structured-Sunset header field. >>> >>> >>> >>>
_______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
