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
