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

Reply via email to