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

[Robert Sparks <[e-mail]>]

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.
>
>
>