Hello Robert,
Thanks for your comments. Could you please take a look at https://github.com/ietf-wg-httpapi/deprecation-header/commit/04a5077d6ab5a8caba52e177badfb2986ba8d781 to verify if your comments are addressed? Thank you.
sanjay
On Fri, Sep 13, 2024 at 8:10 AM Robert Sparks via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Robert Sparks
Review result: Has Nits
I was also the genart reviewer for this document. See that review at
https://datatracker.ietf.org/doc/review-ietf-httpapi-deprecation-header-06-genart-lc-sparks-2024-08-29/.
I was hoping another reviewer could make comments about the security aspects of
this document, so I didn't emphasize that in my genart review. With the
security lens in mind:
This document provides a mechanic to transport a date and a pointer to
information to the humans, ostensibly the developers, behind appllications
using HTTP resources about the deprecation of those resources. The use of HTTP,
and HTTPS mitigate risks to the attacks on the date and pointer themselves.
There's no behavior specified that insists clients do, or don't do, something
different when the deprecation date passes. There is some text that reinforces
that this is information from the (operators of the) server (or should that be
the administrators of the resources?) and that _servers_ shouldn't act
differently, other than providing the information, because they are using the
header.
I can't think of anything further that could be said about the human use of the
information pointed to given what the document specifies.
(I've indicated "has nits" as I still think it might be possible to more
clearly say "who is this for" in several places.)
RjS
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
