W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: Informal Last Call for HTTP Preference Header

From: James Snell <jasnell@gmail.com>
Date: Wed, 8 Feb 2012 08:18:06 -0800
Message-ID: <CABP7Rbcs0UAeth4XWoLM2R9pBOPGceCJ+8oxTLoSpCM59VpWHQ@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: ietf-http-wg@w3.org
Thank you for the additional feedback. I've incorporated the suggested
changes. If you have some specific ideas for how to improve the
registry considerations, definitely please let me know as well.

On Sun, Feb 5, 2012 at 9:01 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> 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
>
Received on Wednesday, 8 February 2012 16:22:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:55 GMT