W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: Prefer Draft Feedback

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Tue, 06 Dec 2011 09:29:01 -0700
Message-ID: <4EDE42CD.9060503@measurement-factory.com>
To: James Snell <jasnell@gmail.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
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).

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

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

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?

> 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

>      wait = "wait" OWS "=" OWS delta-seconds

I think HTTPbis wants you to use BWS here.


Received on Tuesday, 6 December 2011 16:30:17 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:26 UTC