Re: Prefer Draft Feedback

On 2011-12-06 17:29, Alex Rousskov wrote:
> On 12/05/2011 05:32 PM, James Snell wrote:
>> Ok... updated the draft based on much of the feedback provided. There
>> will be another round of changes coming. Hopefully I've adequately
>> addressed most of the concerns raised so far.
>>
>> http://tools.ietf.org/html/draft-snell-http-prefer-05
>
>
>>       Prefer           =  "Prefer" ":" 1#preference
>>       preference       = OWS preference-token OWS *prefer-params OWS
>>       preference-value = token / quoted-string
>>       preference-token = token OWS [ "=" OWS preference-value OWS ]
>>       prefer-params    =  ";" OWS preference-token
>
> Looking at HTTPbis Part 1 examples, some of the above OWS should
> actually be BWS (i.e., something that should not be there).

Yes, around "=".

> Furthermore, HTTPbis already defines OWS for #rules (Section 1.2.1). I
> think you can reuse that without explicitly adding so many OWSs.

Correct.

> I would not call a 'name = "foo bar"' string a "token" but
> preference-token does.
>
> preference-value should probably be defined after use, for clarity and
> symmetry with other top-down definitions.
>
> The prefer-params name implies multiple parameters but defines only one.
>
> How about this:
>
>    Prefer     = "Prefer" ":" 1#preference
>    preference = name [ BWS "=" BWS value ] *parameter
>    parameter  = OWS ";" OWS name [ BWS "=" BWS value ]
>    name       = token
>    value      = token / quoted-string

Better.

How about:

   preference = name [ BWS "=" BWS value ] *( OWS ";" OWS [ parameter ] )
   parameter = token [ BWS "=" BWS ( token / quoted-string ) ]

Note that this allows trailing ";", which in practice most recipients 
will accept anyway, so there's little point to forbid it.

> Overall, the Prefer grammar is more complex than any similar construct I
> saw in HTTPbis Part 1 or Part 6! If I did not miss any existing cases,
> would it be possible to simplify the Prefer grammar so that existing
> parsing code and data structures can be reused to deal with it?

+1

I think it should be possible to get rid of the optional preference 
values (they always can be moved into parameters).

We're trying to find some structure in HTTP header field syntax, see 
<http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HeaderFieldTypes> for 
the work-in-progress.

>> 7. The "wait" Preference
>>
>>
>>     The "wait" preference can be used to establish an upper bound on the
>>     length of time, in seconds, the user-agent is willing to wait for a
>>     response, after which the user-agent may choose to abandon the
>>     request.
>
> Do you have to limit this feature to user-agents?
>
> A caching proxy in a poor connectivity environment may want to use this
> mechanism to respond with a cached stale response if it cannot get a
> fast fresh response from the server, for example. Such a proxy will work
> well with user-agents that do not support Prefer.
>
> It seems to me that replacing most occurrences of "user-agent" with
> "client" will not harm your specification and may make it more generally
> useful.

That sounds right to me.

> ...

Best regards, Julian

Received on Tuesday, 6 December 2011 18:47:22 UTC