sdatspun2
commented
2 months ago The abstract uses 'URI-identified resource.' That's somewhat redundant, and confusing to people who know the terminology. Suggest 'resource (in the sense of [URI])' (but see below).
done
Best practice is not to use ABNF to define structured fields; see https://httpwg.org/admin/editors/style-guide#structured-fields. changed
'Servers MUST NOT include more than one Deprecation header field in the same response.' This is redundant; because it is an Item field, it cannot occur more than once, and error handling for that is defined by SF.
removed
Some consider it bad practice to put RFC2219 requirements in Security Considerations. Also, SC needs to come at the end of the middle of the document (usually after IANA Considerations).
moved after IANA Considerations
The Scope section seems very uncertain of itself. I'm concerned interoperability may suffer.
@mnot elaborate please?
cc @richsalz @dret
mnot
richsalz
On Thu, May 2, 2024 at 10:30 PM Mark Nottingham wrote: Apologies for tardiness.
Some feedback from a quick read-through:
The abstract uses 'URI-identified resource.' That's somewhat redundant, and confusing to people who know the terminology. Suggest 'resource (in the sense of [URI])' (but see below).
The Introduction goes on to talk about HTTP resources. Is it all resources, or just HTTP ones?
Best practice is not to use ABNF to define structured fields; see https://httpwg.org/admin/editors/style-guide#structured-fields.
'Servers MUST NOT include more than one Deprecation header field in the same response.' This is redundant; because it is an Item field, it cannot occur more than once, and error handling for that is defined by SF.
The Scope section seems very uncertain of itself. I'm concerned interoperability may suffer.
Some consider it bad practice to put RFC2219 requirements in Security Considerations. Also, SC needs to come at the end of the middle of the document (usually after IANA Considerations).
Cheers,