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