On 2012-01-31 22:28, James Snell wrote:
> I just posted an update for the HTTP Prefer Header altering the
> intended status from "Informational" to "Standards Track". No
> additional changes were made. As I have not received any further
> technical input on the specification, I am issuing an *Informal* Last
> Call for comments before I request that it be kicked up the chain for
> review.
>
> Mark Nottingham has agreed to serve as the document shepherd for
> helping to move it forward.
>
> Current Draft: http://www.ietf.org/id/draft-snell-http-prefer-11.txt
>
> - James
I think we're almost there. Some notes:
s/2. The Prefer Request Header/2. The Prefer Request Header Field/
Prefer = "Prefer" ":" 1#preference
preference = token [ BWS "=" BWS value ]
*( OWS ";" [ OWS parameter ] )
parameter = token [ BWS "=" BWS value ]
value = token / quoted-string
Could use <word> instead of value
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.3.2.4>)
s/Registry of Preferences (Section 9.1))/Registry of Preferences
(Section 9.1)/
s/In various situations, A proxy may/In various situations, a proxy may/
Also: is this MAY? If not say "can". Same in other places.
2.2 Examples: end the descriptions with a colon (":").
If "strict" and "lenient" are described as a mutually exclusive pair,
shouldn't this also be the case for return-minimal vs return-representation?
/This specification establishes an IANA registry of such relation types
see Section 9.1./This specification establishes an IANA registry of such
relation types (see Section 9.1)./
9.1:
"Application Data: [optional]" -- copied from RFC 5988 (?) but doesn't
make sense here...
The httpbis references need an update.
Finally, I notice that most registry considerations are cloned from RFC
5988. I'm not totally sure that this is a good idea; Mark has been
discussing this in a different context for some time now, so I guess
he'll have something to say :-)
Best regards, Julian