[httpapi] Re: Genart last call review of draft-ietf-httpapi-deprecation-header-06

[Robert Sparks <[e-mail]>]

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 <[e-mail]> 
> 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
>>     <[e-mail]> 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.
>>
>>
>>