Thanks - I'm fine with this version. It would be good for fresher eyes
should watch for other improvements like this as it finishes review.
RjS
On 9/12/24 3:36 PM, Sanjay Dalal wrote:
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
