Subject: Prefer Draft Feedback

From: James Snell <[email-masked]>
Date: Fri, 2 Dec 2011 15:01:27 -0800

All,

I would like to take a quick moment to solicit feedback on the current
version of the HTTP Prefer Header specification:

http://tools.ietf.org/html/draft-snell-http-prefer-04

The draft should be pretty well self-explanatory. There are some
highly tentative pieces included in this draft that may likely be
removed in a future iteration. They have been included now primarily
for the purpose of soliciting feedback on their overall utility.

- James

---

From: Julian Reschke <[email-masked]>
Date: Sat, 03 Dec 2011 12:16:45 +0100

On 2011-12-03 00:01, James Snell wrote:
> ...

Will review.

One thing I already noticed is that the spec does the same mistake most 
other header field definitions make; it defines an extensible syntax but 
then special cases the header field it defines itself.

Parsing should be uniform.

So,

- if you take value-less tokens, you need to state whether

   x

   x=

   x=""

are equivalent or not.

- if values can be tokens or quoted-strings, you should state that both 
notations are equivalent, and are allowed everywhere, so are

   priority=100

and

   priority="100"

the same thing?

Best regards, Julian

---

From: Alex Rousskov <[email-masked]>
Date: Sat, 03 Dec 2011 10:25:19 -0700

> 6. The "return-no-content" Preference
> 
> 
>    The "return-no-content" preference indicates that the user-agent
>    wishes the server to not include an entity in the response to a
>    successful request. Typically, such responses would use the 204 No
>    Content status, but other codes MAY be used as appropriate.
>    Regardless of the status returned, when honoring the "return-no-
>    content" preference, the server MUST NOT include an entity within the
>    response.

Please try to rephrase this preference to reduce the chances that some
servers will start responding with something like HTTP 200 (OK) without
body and without zero Content-Length header and expect the clients to
correctly frame such a malformed response.

The preference cannot change message framing rules so for most response
status codes "no-content" and "no entity" has to be interpreted as "zero
length body" rather than "no body".

> 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.  In the case generating a response will take longer than the
>    time specified, the server, or proxy, can choose to either return a
>    202 Accepted response, cancel processing, or continue attempting to
>    complete the request.
> 
>      wait = "wait" "=" delta-seconds

Since clients often do not send a Date header, the message recipients
would not be able to know how long the client has been waiting for. Do
you expect the wait time to be measured locally at each hop? If not, you
may want to require clients to send a date header with this preference.

> 3. The "return-accepted" Preference
> 
> 
>    The "return-accepted" preference indicates that the user-agent
>    prefers the server to respond with a 202 Accepted status in the case
>    where the length of time it takes to generate a response will exceed
>    some arbitrary threshold established by the server.

A "202 Accepted" response is a response. Consider replacing "generate a
response" with something like "generate a regular response".

You have specified Prefer as a request header. Have you considered
removing that restriction so that servers may send certain preferences
in HTTP 1xx control messages or even regular responses (when the
preference exceeds the lifetime of a single HTTP transaction)?

Thank you,

Alex.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 04 Dec 2011 20:06:43 +0100

> notations are equivalent, and are allowed everywhere, so are

OK, here's more feedback:

2.  The Prefer Request Header

    The Prefer request-header is used to indicate that particular server
    behaviors are preferred by the user-agent, but not required for
    successful completion of the request.  Prefer is similar in nature to
    the Expect header defined by [RFC2616] with the exception that
    servers are allowed to ignore stated preferences.

      Prefer       =  "Prefer" ":" 1#preference

      preference   =  (return-accepted /
                      return-no-content /
                      return-content /
                      return-status /
                      wait /
                      priority /
                      handling /
                      detail /
                      preference-extension)
                      *prefer-params
      preference-value = token / quoted-string
      preference-token = token [ "=" preference-value ]
      preference-extension =  preference-token
      prefer-params =  ";" preference-token

1) Do not define the individual tokens in the grammar; consumers should 
not special-case them. Just define the generic grammar, then define the 
invididual tokens in prose.

2) You need to say what ABNF form you use. Right now it looks like 
HTTPbis ABNF, in which case you need to reference HTTPbis Part 1.

3) Need to think about whitespace between tokens and delimiters!

4) So preference token can have optional values, plus optional 
parameters. This looks like one degree of freedom too much. The value of 
a token could always be replaced by a parameter on the value. In any 
case, as the grammar as currently proposed is relatively complex, a set 
of examples would be very good.

5) Need to state recurrence rules (multiple same-named tokens, repeating 
parameters).

6) Need to state case-matching for token and parameter names.

    Comparison of preference tokens is case-insensitive for unquoted
    tokens and is case-sensitive for quoted-string preference-extensions
    and prefer-params values.

Not good, this differs from all header fields. Make the token *names* 
case-insensitive and the values case-sensitive (no matter whether token 
or quoted string)

    Note that the application of a preference by the server MAY affect
    the caching characteristics of the response.  Specifically, should
    the application of a preference result in a variance to the
    representation returned by a cacheable response, a Vary header SHOULD

MUST?

    be included listing the Prefer header as one of the selecting header
    fields.

4.  The "return-content" Preference

    The "return-content" preference indicates that the user-agent prefers
    that the server include an entity representing the current state of
    the resource in the response to a successful request.

      return-content = "return-content"

Maybe this should be called "return-representation".

5.  The "return-status" Preference

    The "return-status" preference indicates that the user-agent prefers
    the server to include an entity describing the status of the request
    in the response as opposed to returning a representation of the
    current state of the resource.

      return-status = "return-status"

    When honoring the "return-status" preference, the server SHOULD NOT
    include a Content-Location header in the response.

Why not?

      return-no-content = "return-no-content"

    The "return-no-content" preference is intended to provide a means of
    optimizing communication between the user-agent and server by
    reducing the amount of data the server is required to return to the
    user-agent following a modification request.  This can be
    particularly useful, for instance, when communicating with limited-
    bandwidth mobile devices or when the user-agent simply does not
    require any further information about the result of a request beyond
    knowing if it was successfully processed.

"return-minimal"?

7.  The "wait" Preference

Potential overlap with other work?

8.  The "priority" Preference

-1; maybe later.

9.  The "strict" and "lenient" Processing Preferences

+0

10.  The "detail" Preference

+0

11.  Registered Preferences

    Well-defined preferences can be registered for convenience and/or to
    promote reuse by other applications.  This specification establishes
    an IANA registry of such relation types see Section Section 12.1.

    Registered preference names MUST conform to the token rule, and MUST
    be compared character-by-character in a case-insensitive fashion.

No, this is inconsistent with the use in similar header fields (like 
Cache-Control)

13.  Security Considerations

    Specific preferences requested by a client can introduce security
    considerations and concerns beyond those discussed in [RFC2616].

Be consistent in referencing HTTPbis *or* RFC2616.

Editorial:

Throughout: s/header/header field/

---

From: James Snell <[email-masked]>
Date: Mon, 5 Dec 2011 10:39:11 -0800

Julian, thanks for the input... comments below...

> then special cases the header field it defines itself.

Excellent point... will clarify that in the draft.

> - if you take value-less tokens, you need to state whether

Yes, these would be equivalent. I will make sure that's clear.

---

From: James Snell <[email-masked]>
Date: Mon, 5 Dec 2011 10:44:16 -0800

Alex, thanks for the feedback, comments below...

> length body" rather than "no body".

Ok, yeah, will take another run at this then.

> may want to require clients to send a date header with this preference.

Excellent point, I really hadn't considered that previously. The
application where we've implemented this previous already had
reasonable synchronization between the client and server clocks so it
never came up. Will make sure to add that bit in.

> preference exceeds the lifetime of a single HTTP transaction)?

Considered it yes, but wasn't really able to come up with a practical,
non-theoretical use case so I didn't pursue it. If such a case
emerges, or if it can be demonstrated that Prefer would work
reasonably with a response, I will gladly remove the restriction.

---

From: James Snell <[email-masked]>
Date: Mon, 5 Dec 2011 11:55:46 -0800

Julian, again, thank you for feedback.. a few clarifying questions
below however...

On Sun, Dec 4, 2011 at 11:06 AM, Julian Reschke <[email-masked]> wrote:
> [snip]

I'm thinking "return-content" is going to be a bit more consistent
with other bits... such as "Content-Location".. but I'm not adverse to
renaming it.

>   include a Content-Location header in the response.

I've gone back and forth on this particular point... essentially tho,
there really isn't any clear means of identifying when a particular
response is a representation of the resource or a representation of
the request status... there's absolutely nothing in the response that
I can key off of to make that determination reliably... The idea,
then, is to use the presence or lack of a Content-Location header as
that key. If I send return-content and get back a response with a
Content-Location header, then I assume it's a representation of the
resource and can assume the preference was applied, if I receive back
a response without a Content-Location, then I assume it's a status
response and have to handle it accordingly. I'm definitely open to a
better suggestion.

>   knowing if it was successfully processed.

Yeah, return-minimal is better... also, I'm removing the requirement
that the response be empty. It's better to allow the server to define
what constitutes an appropriate minimal response.

> Potential overlap with other work?

I've considered that also but I'm not sure. I haven't really seen much
that specifically deals with wait times, especially in an optional
arrangement such as this. I think for now, I'll leave this in and if
it becomes clear that there's overlap in other areas, I can revisit
it.

> [snip]

Not sure what exactly you're objecting to here. Is it the registry or
the comparison rule?

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Dec 2011 21:12:12 +0100

On 2011-12-05 20:55, James Snell wrote:
> On Sun, Dec 4, 2011 at 11:06 AM, Julian Reschke<[email-masked]>  wrote:
>> [snip]

Well, at least the prose needs to make clear what it means :-)

> response and have to handle it accordingly. I'm definitely open to a

Well, a status message could have a content-location as well. Think a 
monitor resource after 202.

I think the current language restricts servers from doing what's allowed 
today.

Wouldn't (have Content-Location) AND (Content-Location == effective 
Request URI) work?

> it becomes clear that there's overlap in other areas, I can revisit

There was talk about this in the context of making long polling work better.

> Not sure what exactly you're objecting to here. Is it the registry or

The comparison rule.

Best regards, Julian

---

From: James Snell <[email-masked]>
Date: Mon, 5 Dec 2011 12:20:00 -0800

On Mon, Dec 5, 2011 at 12:12 PM, Julian Reschke <[email-masked]> wrote:
> Wouldn't (have Content-Location) AND (Content-Location == effective Request
> URI) work?
>

Unfortunately, no.. consider the Atom Publishing Protocol for
example.. when I POST a new item to the collection URI, the response
can include a representation of the created resource. The
Content-Location header would point to the location of the created
entry, while the effective request URI would be for the collection.

> There was talk about this in the context of making long polling work better.

Ok... well like I said, I don't have a problem pulling this if it does
overlap. For now, however, until it's clear that something else
adequately covers this requirement, I'll keep it in.

>> Not sure what exactly you're objecting to here. Is it the registry or

Ok, I'm confused then. We've established that preference names are
case-insensitive and values are case-sensitive, so I'm not sure why
you're objecting to this one.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Dec 2011 21:29:33 +0100

> entry, while the effective request URI would be for the collection.

Indeed; I had PUT on my mind.

> adequately covers this requirement, I'll keep it in.

Martin?

> you're objecting to this one.

OK, I'm confused now as well. Sorry.

To repeat: the names of parameters should be case-insensitive, but the 
values (independently of token vs quoted-string) should not.

Best regards, Julian

---

From: James Snell <[email-masked]>
Date: Mon, 5 Dec 2011 15:50:25 -0800

Oh.. the conditional request is definitely an interesting case. I'd
definitely be open to adding some additional discussion.

On Mon, Dec 5, 2011 at 3:46 PM, Martin Thomson <[email-masked]> wrote:
> On 6 December 2011 07:29, Julian Reschke <[email-masked]> wrote:
> The 'wait' tag seems perfectly appropriate to me for monitoring
> changes in resource state (aka long -polling).  As specified in -04,
> it works, though it's not necessarily clear from the text.
>
> My current thoughts are that you can have a resource with a particular
> state, indicated by an ETag.  By using If-None-Match (or one of the
> other conditional headers) and Prefer: wait=x, then you can request
> that the server only provide an update when the resource changes,
> within that interval.  It's a new use of the conditional headers, as
> well as a slightly different spin on the wait header, but I think that
> it's workable.
>
> Of course, you could use the 'wait' tag without anything fancy if the
> resource simply had specific logic for long-polling.  It seems less
> nice that way.
>
> I might be able to draft a paragraph or two to add if folks are
> amenable to this.
>
> --Martin

---

From: James Snell <[email-masked]>
Date: Mon, 5 Dec 2011 16:32:34 -0800

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

- James

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 06 Dec 2011 09:29:01 -0700

>      preference       = OWS preference-token OWS *prefer-params OWS
>      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?

>    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.

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

I think HTTPbis wants you to use BWS here.

HTH,

Alex.

---

From: "Moore, Jonathan (CIM)" <[email-masked]>
Date: Tue, 6 Dec 2011 16:38:17 +0000

> http://tools.ietf.org/html/draft-snell-http-prefer-05
Hi James,

I had a question about the following recommendation:

> include a Content-Location header field in the response.

What if the status has its own URI, to be used for polling the status of a
long-running job, for example? Wouldn't it be appropriate to provide this
URI in a Content-Location header on the response?

Jon 

........
Jon Moore
Comcast Interactive Media

---

From: James Snell <[email-masked]>
Date: Tue, 6 Dec 2011 10:43:37 -0800

>  value      = token / quoted-string

That works.

> parsing code and data structures can be reused to deal with it?

The grammar for Prefer is modeled closely after the Expect header
field grammar in Part 2 and adds only the allowance that a preference
can have it's own value (e.g. "Prefer: wait=10" ...

> "client" will not harm your specification and may make it more generally

Ok, I can definitely do that.

> I think HTTPbis wants you to use BWS here.

Ok, good to know.

> Alex.

Definitely helpful, thank you for the feedback.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Dec 2011 19:46:47 +0100

> actually be BWS (i.e., something that should not be there).

Yes, around "=".

> think you can reuse that without explicitly adding so many OWSs.

Correct.

>    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.

> 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.

> "client" will not harm your specification and may make it more generally

That sounds right to me.

Best regards, Julian

---

From: James Snell <[email-masked]>
Date: Tue, 6 Dec 2011 10:48:01 -0800

Yeah, this is an item that's still somewhat up in the air. The main
challenge is that when sending "Prefer: return-status" or "Prefer:
return-representation" (yes, Julian, if you're reading, I went ahead
and renamed it.. you were right it did make more sense that way)...
it's generally impossible to reliably determine which type of response
you're getting back. There's absolutely nothing in the response I can
key off of to determine whether the entity is a representation of the
resource or a representation of the request status. The idea here was
to use the presence of the Content-Location header as that key. If
Content-Location is in the response, then I would assume that it's a
representation of the resource, otherwise, I have to assume it's a
status. This is definitely far from perfect, obviously, but it aligns
with the behavior of apis based on the Atom protocol and a few others
I have seen. However, ideally, there would be some explicit signaling
mechanism that I could use without having to abuse Content-Location in
this way.

---

From: James Snell <[email-masked]>
Date: Tue, 6 Dec 2011 10:54:57 -0800

On Tue, Dec 6, 2011 at 10:46 AM, Julian Reschke <[email-masked]> wrote:
> I think it should be possible to get rid of the optional preference values
> (they always can be moved into parameters).
>
> <http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HeaderFieldTypes> for the
> work-in-progress.
>
>

Hmmm... part of my brain is just screaming about the apparent
simplicity of something like "Prefer: wait=10" as opposed to "Prefer:
wait; v=10" but I can live with it, especially for the sake of
maintaining consistency with other header fields.

I'll work in the suggested changes...

- James

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Dec 2011 19:55:14 +0100

> can have it's own value (e.g. "Prefer: wait=10" ...

Good point:

   Expect       = 1#expectation

   expectation  = "100-continue" / expectation-extension
   expectation-extension = token [ "=" ( token / quoted-string )
                            *expect-params ]
   expect-params = ";" token [ "=" ( token / quoted-string ) ]

So this allows values here as well.

I'm still not too enthusiastic about this, as I haven't seen this in use.

It appears making it a bit simpler wouldn't hurt a lot. So you'd have 
for instance

   Prefer: wait; sec=10

Best regards, Julian

---

From: "Moore, Jonathan (CIM)" <[email-masked]>
Date: Tue, 6 Dec 2011 19:07:20 +0000

Even if a client sends "Prefer: return-representation" and gets a response
with a Content-Location in return, there's no guarantee this isn't a
status response. Perhaps the server doesn't implement Prefer, and returned
a status response with a Content-Location that could be polled for ongoing
status updates--this is a commonly-described mechanism for long-running
jobs, and fits with the RFC2616 definition of Content-Location.

In other words, I think the SHOULD NOT convention here doesn't actually
buy you anything. Perhaps a server that understands Prefer should have a
response header indicating which preferences were honored? Such as:

HTTP/1.1 202 Accepted
Date: Tue, 06 Dec 2011 19:04:51 GMT
Preferences-Honored: return-status, return-accepted
...

Jon
........
Jon Moore

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 06 Dec 2011 12:13:25 -0700

On 12/06/2011 11:43 AM, James Snell wrote:
> On Tue, Dec 6, 2011 at 8:29 AM, Alex Rousskov wrote:

> can have it's own value (e.g. "Prefer: wait=10" ...

As Julian pointed out, expectation-extension in RFC 2616 attempts to use

>   expect-params = ";" token [ "=" ( token / quoted-string ) ]

The only difference I see is that expect-params are only allowed for
expectations that start with name=value but I bet that is just a bug
with the closing ']' placement in expectation-extension definition
(something for HTTBis to fix?).

If expectation-extension is fixed, we would have to support the same
syntax for Expect, my "this is too complex!" comment would be
essentially wrong, and you can have the nice-looking wait=10 preference.

Thank you,

Alex.

---

From: James Snell <[email-masked]>
Date: Tue, 6 Dec 2011 11:15:00 -0800

Previous versions of the draft included a Preference-Applied response
header that would list out the ones applied, it was removed based on
some other push back I had received. I could easily add that back in,
however, if that provides the necessary signaling mechanism.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Dec 2011 20:23:30 +0100

>>    expect-params = ";" token [ "=" ( token / quoted-string ) ]

I just sanitized the grammar to:

   expectation  = "100-continue" / expectation-extension
   expectation-extension = token [ "=" ( token / quoted-string )
                            *(";" expect-param) ]
   expect-param = token [ "=" ( token / quoted-string ) ]

(<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1489>).

Also, I think while converting the ABNF, we forgot to allow OWS around 
";"; I opened a ticket for that: 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/327>

> (something for HTTBis to fix?).

Make sense to me; I don't believe anybody is using this anyway, so let's 
make Prefer and Expect at least the same.

(I added your observation to the ticket).

> essentially wrong, and you can have the nice-looking wait=10 preference.

Agreed.

I also need to get this pattern into the Wiki page 
<http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HeaderFieldTypes> 
(contributions welcome!).

Best regards, Julian

---

From: "Moore, Jonathan (CIM)" <[email-masked]>
Date: Tue, 6 Dec 2011 20:56:30 +0000

Ah, I see where Mark Nottingham referred to these rules:

> 3.  If the response has a Content-Location header field, and that URI
> is the same as the effective request URI, the response payload is
> a representation of the target resource.

> 4.  If the response has a Content-Location header field, and that URI
> is not the same as the effective request URI, then the response
> asserts that its payload is a representation of the resource
> identified by the Content-Location URI.  However, such an
> assertion cannot be trusted unless it can be verified by other
> means (not defined by HTTP).

I am thinking of the case where I do a POST to one resource. In case (3),
then it's clear the server is basically doing "return-representation". In
case (4), however, it's returning a representation that is also available
at the Content-Location. A client cannot distinguish whether this is
"return-representation" or "return-status" in this case. For example, a
POST might return either one with a Content-Location that was different
from the effective request URI.

Clearly a client sending Prefer must be prepared to examine a response
as-is, as a compliant server may simply ignore Prefer (or may not even
implement it at all). So I can see the argument that Preference-Applied
isn't necessary. However, it clearly offers a leg up to a client, if only
to advertise that the server (or an intermediary) supports Prefer.
However, it actually distinguishes things in the above case. Perhaps
Preference-Applied should be a MAY?

Jon

........
Jon Moore

---

From: Martin Thomson <[email-masked]>
Date: Wed, 7 Dec 2011 10:26:09 +1100

> Do you have to limit this feature to user-agents?

Good point.  In our work on timeouts we observed that intermediaries
are equally capable of placing their own constraints on time.  In
fact, there's nothing inherently wrong with an intermediary changing
the value to a lower value (my client was prepared to wait 30s, but I
have policy that limits this to 10), though increasing the value might
not work out so well.

--Martin

---

From: James Snell <[email-masked]>
Date: Tue, 6 Dec 2011 16:57:10 -0800

Current iterations based on today's feedback...

http://www.ietf.org/id/draft-snell-http-prefer-06.txt

Change summary:

- replaced user-agent with client
- brought Preference-Applied back
- Fixed grammar for Prefer and Preference-Applied
- ABNF references
- Added examples

- James

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 07 Dec 2011 15:45:34 +1300

On Tue, 06 Dec 2011 19:46:47 +0100, Julian Reschke wrote:
> for

 That list of ABNF is missing the pattern that could be called 
 "quoted-blob" or such. Things which appear superficially to have the 
 syntax of quoted-string but exclude the quoted-pair (or failed to spec 
 escaping entirely, with the same end result). ie the string portion may 
 contain bare \ characters which will break attempts to use a 
 quoted-string parser on it.

 Examples for this can be found in the new ETag ABNF from HTTPbis and 
 the path= parameter of Digest authentication. Possibly elsewhere I have 
 not run into yet.

 AYJ

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Dec 2011 17:36:53 +1100

> - replaced user-agent with client

What's the reasoning here? Do you expect intermediaries to have preferences?

> - brought Preference-Applied back

This needs to be discussed. I'm very uneasy about turning this into Yet Another HTTP Negotiation Mechanism. 

--
Mark Nottingham   http://www.mnot.net/

---

From: James Snell <[email-masked]>
Date: Tue, 6 Dec 2011 22:53:27 -0800

Mark,

Check the thread for discussion on the change to the user agent to client.

As for Preference-Applied... It's back currently but everything is open to
discussion. It doesn't have to go on forever tho :) ... I'm sure you're
aware of the rationale... What are your thoughts on it?

---

From: Dale Anderson <[email-masked]>
Date: Tue, 6 Dec 2011 23:45:19 -0800

HTTPWorld at large beyond my comprehension,

Just a quick note this makes me think of - there was no hit for 'abnf' in
RFC2616; had to be 'Augmented BNF' for search and that has duffed engineer
attempts to find associated BNF materials when looking for a reference to
ABNF.

To make sure the search works in httpbis the tables of contents should say
both in the proper acronym introduction fashion like for example

       1.2.1.  ABNF Extension: #rule  . . . . . . . . . . . . . . . .  8

Would be

       1.2.1.  Augmented BNF (ABNF) Extension: #rule  . . . . . . . .
. . . . . . . .  8

Regards

Dale Anderson

2011/12/6 Amos Jeffries <[email-masked]>

>> <http://trac.tools.ietf.org/**wg/httpbis/trac/wiki/**HeaderFieldTypes<http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HeaderFieldTypes>>
>> for
>> the work-in-progress.
>>
>>
> "quoted-blob" or such. Things which appear superficially to have the syntax
> of quoted-string but exclude the quoted-pair (or failed to spec escaping
> entirely, with the same end result). ie the string portion may contain bare
> \ characters which will break attempts to use a quoted-string parser on it.
>
> Examples for this can be found in the new ETag ABNF from HTTPbis and the
> path= parameter of Digest authentication. Possibly elsewhere I have not run
> into yet.
>
>
> AYJ
>
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Dec 2011 10:01:45 +0100

> quoted-string parser on it.

Oh, that's something we don't want to encourage!

> path= parameter of Digest authentication. Possibly elsewhere I have not
> run into yet.

If "path" does this in Digest for WWW-Authenticate, then Digest is 
broken and we should raise an erratum.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 07 Dec 2011 23:30:31 +1300

> broken and we should raise an erratum.

Err. double-checking myself that parameter name was "uri=" I was 
recalling from bad experiences ...
  with WebKit (Chrome) http://bugs.squid-cache.org/show_bug.cgi?id=3077#c3
  and Gecko (Firefox) http://bugs.squid-cache.org/show_bug.cgi?id=3077#c9

Arguably the RFC 2617 does not explicitly mention quotes in the 
definition and one can argue that they should not have placed the "" 
around the value. Still, its happening anyway.

On the Digest challenge header "domain=" explicitly defines use of 
quotes ( <"> absoluteURI | abs_path <">  ), again with no mention what 
to do with the quoted-pair escape character which MAY be in the URI 
query-string portion (RFC 2396 emphasis). This one has not been sighted 
(yet) AFAIK.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Dec 2011 11:38:54 +0100

> and Gecko (Firefox) http://bugs.squid-cache.org/show_bug.cgi?id=3077#c9

...where's the definition for "uri"?

> around the value. Still, its happening anyway.

That should be reported as bug.

> quotes ( <"> absoluteURI | abs_path <"> ), again with no mention what to
> do with the quoted-pair escape character which MAY be in the URI

That's almost a bug in 2617; except that - unless I'm missing something 
- \ us invalid in URIs (yes, in 2396 as well).

Best regards, Julian

---

From: "Moore, Jonathan (CIM)" <[email-masked]>
Date: Wed, 7 Dec 2011 11:46:52 +0000

> This needs to be discussed. I'm very uneasy about turning this into Yet Another HTTP Negotiation Mechanism.

Can you explain your unease? It seems like all the pre-existing server-side negotiation mechanisms (Accept, Accept-Language, etc.) all basically have an "express your desire but check the response anyway" semantic. For example, servers are explicitly not required to send a 406 if they can't honor an Accept header. However, there are (optional) protocol-level means that servers can use to provide more context to clients--Content-Language being a good example. Therefore, in some sense, they are all client "preferences" one way or another. Perhaps we're just defining "the last negotiation mechanism you'll ever need"?

Or are you suggesting server-side negotiation was a Bad Idea, and hence we shouldn't be pursuing other means for it?

Curiously yours,
Jon

---

From: James Snell <[email-masked]>
Date: Wed, 7 Dec 2011 06:34:02 -0800

For me, it's not so much about coming up with an über negotiation
mechanism... In fact, that's rather frightening to think about... I just
need it to be unambiguous as to whether or not particular preferences were
applied or not. For most preferences, I suspect, as Mark has argued in
previous feedback, application is going to be readily apparent and
detectable via context, however there will be some that aren't easily
detectable. The return-representation v. return-status tokens, for example.
In most cases, I suspect the use of content-location as a signal would be
sufficient, or some heuristic based on comparing request uri, to
content-location, and possibly the location field, etc but such heuristics
are certainly not infalible. I fear that the cases where it doesn't hold up
will undermine their utility and increase the complexity of the mechanism.
So let's focus on just that one use case and see if we can reach s
reasonable solution... Given return-representation and return-status, how
can I reliably, consistently and simply know which type of response the
server has provided?
On Dec 7, 2011 3:46 AM, "Moore, Jonathan (CIM)" <[email-masked]>
wrote:

> Can you explain your unease? It seems like all the pre-existing
> server-side negotiation mechanisms (Accept, Accept-Language, etc.) all
> basically have an "express your desire but check the response anyway"
> semantic. For example, servers are explicitly not required to send a 406 if
> they can't honor an Accept header. However, there are (optional)
> protocol-level means that servers can use to provide more context to
> clients--Content-Language being a good example. Therefore, in some sense,
> they are all client "preferences" one way or another. Perhaps we're just
> defining "the last negotiation mechanism you'll ever need"?
>
> Or are you suggesting server-side negotiation was a Bad Idea, and hence we
> shouldn't be pursuing other means for it?
>
> Curiously yours,
> Jon
>
>
>
>
>
>

---

From: "Moore, Jonathan (CIM)" <[email-masked]>
Date: Wed, 7 Dec 2011 15:33:31 +0000

My point is that existing negotiation schemes (Accept, Accept-Encoding, Accept-Language, Accept-Charset) are all basically preferences—a (conditionally) compliant server may simply ignore them. Even conditional GETs simply express a preference to get a 304 if possible—but a 200 is still a valid response.

So I guess I'll ask: how are preferences as you see them different from existing server-side negotiations? Is the difference that an unconditionally compliant server SHOULD honor requested negotiations but MAY choose to honor preferences or not, as it chooses?

On the topic of return-status v. return-representation, couldn't the server set a Link header to make this unambiguous?

Jon
........
Jon Moore

From: James Snell <[email-masked]<mailto:[email-masked]>>
Date: Wed, 7 Dec 2011 06:34:02 -0800
To: Jonathan Moore <[email-masked]<mailto:[email-masked]>>
Cc: Alex Rousskov <[email-masked]<mailto:[email-masked]>>, Martin Thomson <[email-masked]<mailto:[email-masked]>>, HTTP Working Group <[email-masked]<mailto:[email-masked]>>, Mark Nottingham <[email-masked]<mailto:[email-masked]>>
Subject: RE: Prefer Draft Feedback

For me, it's not so much about coming up with an über negotiation mechanism... In fact, that's rather frightening to think about... I just need it to be unambiguous as to whether or not particular preferences were applied or not. For most preferences, I suspect, as Mark has argued in previous feedback, application is going to be readily apparent and detectable via context, however there will be some that aren't easily detectable. The return-representation v. return-status tokens, for example. In most cases, I suspect the use of content-location as a signal would be sufficient, or some heuristic based on comparing request uri, to content-location, and possibly the location field, etc but such heuristics are certainly not infalible. I fear that the cases where it doesn't hold up will undermine their utility and increase the complexity of the mechanism. So let's focus on just that one use case and see if we can reach s reasonable solution... Given return-representation and return-status, how can I reliably, consistently and simply know which type of response the server has provided?

On Dec 7, 2011 3:46 AM, "Moore, Jonathan (CIM)" <[email-masked]<mailto:[email-masked]>> wrote:

Curiously yours,
Jon

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 07 Dec 2011 08:53:15 -0700

> What's the reasoning here? Do you expect intermediaries to have preferences?

IMO, the general reasoning should be "we do not want to exclude
intermediaries without a specific reason because some of them might find
the new mechanism useful". This is especially true when the mechanism
can be extended.

In this specific case, we have already come up with at least one
possible use: wait=10 preference set by a proxy in a poorly connected
environment when validating a cached response. See this thread for more
info.

> Yet Another HTTP Negotiation Mechanism.

If there is an existing mechanism that can be reused to acknowledge
which preference was honored, we should reuse it. Otherwise, a "yet
another" acknowledgement mechanism seems justified.

I am not an expert on this, but my understanding of the arguments
presented so far is that reusing Content-Location to indicate whether
the status preference was applied is not going to cover all possible use
cases.

I also find the Preference-Applied acknowledgement mechanism useful for
debugging/troubleshooting.

[ N.B. If "Preference-Applied" stays, please consider renaming it to
"Preferred" to save a few bytes and to remove the implication that all
preferences can be "applied" rather than honored, etc. ]

Thank you,

Alex.

---

From: James Snell <[email-masked]>
Date: Wed, 7 Dec 2011 07:56:32 -0800

On Wed, Dec 7, 2011 at 7:33 AM, Moore, Jonathan (CIM)
<[email-masked]> wrote:
> [snip]
> So I guess I'll ask: how are preferences as you see them different from
> existing server-side negotiations? Is the difference that an unconditionally
> compliant server SHOULD honor requested negotiations but MAY choose to honor
> preferences or not, as it chooses?
>

The distinction between SHOULD and MAY is critical for Prefer, yes.

> On the topic of return-status v. return-representation, couldn't the server
> set a Link header to make this unambiguous?
>

Possibly yes, but there are other possible solutions. For instance, we
could -- in theory -- leverage the Content-Disposition header using an
extension parameter... e.g.

Content-Disposition: inline; nature=representation
Content-Disposition: inline: nature=status

This would address the issue just fine, I think.  What I'm wondering,
however, is whether this is really all that much different than using
Preference-Applied, tho, and whether Just Using Something Else really
addresses Mark's concern.

- James

> From: James Snell <[email-masked]>
> To: Jonathan Moore <[email-masked]>
> Cc: Alex Rousskov <[email-masked]>, Martin Thomson
> <[email-masked]>, HTTP Working Group <[email-masked]>, Mark
> Nottingham <[email-masked]>

---

From: James Snell <[email-masked]>
Date: Wed, 7 Dec 2011 10:06:36 -0800

Ok... so let's walk through the scenarios a bit to see if we can't put
this content-location question to bed for good...

Once again, the requirement is simple: When a client posts a request
to a server, the server can return either a representation of the
resource or a representation of the request status, there is currently
no reliable means of determining which is being returned beyond the
following statements in httpbis part2, from section 5.1:

    ...

For most operations, the distinction between the status and
representation is going to be pretty simple.. for PUT, for instance,
matching the Content-Location to the effective Request URI can be
generally sufficient. There are edge cases where the type of response
becomes ambiguous.

The one case where this falls down.. and so far, the only case I've
seen where the Content-Location/Request URI rule doesn't work, is the
case such as in the Atom Publishing Protocol where an entity is POSTed
to one URL resulting in the creation of a new resource with a
different URL. The fact that the response contains a Content-Location
header that differs from the Effective Request URI is not sufficient
to tell us whether the returned entity is a representation of the
created resource.

For the Atom case, there is a workable solution given that a
successful POST to a Collection URI also returns a Location header
thanks to the defined semantics of the 201 Created response (httpbis
part 2, section 7.2.2)... for instance:

POST /collection HTTP/1.1
Host: example.org
  ...

HTTP/1.1 201 Created
Location: /collection/item1
Content-Location: /collection/item1

In this case, we can apply the additional heuristic that if the
response has both a Content-Location AND Location header that match,
the returned entity is a representation of the created resource,
however, if the Content-Location and Location headers do not match,
the returned entity *might* be a representation of the request status.
Notice the *might*... there are edge cases where if the two fields
differ, it may not actually be a status response. The question is
whether that ambiguity is acceptable. I know that in the use cases
where I've implemented this, use of Preference-Applied hasn't been
strictly required.

Another example tho, to tease it out further...

PATCH /some/resource HTTP/1.1
Prefer: return-status
Content-Type: application/mypatchformat

...

HTTP/1.1 200 OK
Content-Type: application/json
Content-Location: /status-messages/1

{"changed-elements":["foo","bar","baz"]}

As opposed to...

PATCH /some/resource HTTP/1.1
Prefer: return-representation
Content-Type: application/mypatchformat

...

HTTP/1.1 200 OK
Content-Type: application/json
Content-Location: /some/resource

{"foo":"1","bar":"2","baz":"3"}

Ok, so with this, in case 2, the fact that the effective request URI
matches the Content-Location means we have a representation of the
resource. In case 1, it could be a status message but we cannot be
100% sure...

Hmm... ok, so drawing this out highlights a couple of very important
point that I may have missed before: a) The use cases for requesting
the resource representation are more prevalent that the use cases for
requesting the status response and b) even when requesting a status
response, we cannot be 100% that's what we're getting, forcing us to
inspect the data anyway. Given that, I'm wondering if we can simply
drop the return-status preference all together, making the option
"return-representation" or "do the default" that requires us to
examine the response.

GET with Prefer: return-representation is nonsensical since GET always
returns the representation
POST with Prefer: return-representation is only relevant if the POST
is being used to create a resource, in which case the 201 Response
with both Location and Content-Location headers can be returned...
PUT with Prefer: return-representation is handled easily by matching
the Content-Location to the effective request URI
DELETE with Prefer: return-representation is nonsensical
PATCH with Prefer: return-representation is essentially same as PUT

return-status isn't strictly necessary in any of these cases. Dropping
it from the spec eliminates the need to differentiate which preference
was applied as we'd just assume that all responses that aren't
unambiguously representations of the resource are likely status
responses.

Sorry for rambling a bit on that, but does that make sense or am I
missing something?

- James

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Dec 2011 10:24:57 +1100

> Or are you suggesting server-side negotiation was a Bad Idea, and hence we shouldn't be pursuing other means for it?

More the latter; experience has shown that conneg is of limited value, and can be abused + cause more problems than it's worth. There's a relevant HTTPbis ticket, don't remember offhand which one.

--
Mark Nottingham
http://www.mnot.net/

---

From: James Snell <[email-masked]>
Date: Thu, 8 Dec 2011 09:56:54 -0800

Ok, a new draft has been published.

http://www.ietf.org/id/draft-snell-http-prefer-07.txt

After discussing caching issues with Mark in detail, I've made a
number of important changes to the draft... specifically, it is
important to point out that Prefer was always intended to be a
behavior-negotiation mechanism, not content-negotiation. While the
application of a behavioral preference could potentially impact the
construction of a response, implementations should avoid utilizing
preferences in a way that causes a variance in the caching of a
response. For that reason, I added a new short section detailing cache
considerations and removed the detail preference. Basically, if you're
using Prefer for content-negotiation, you're likely doing it wrong.

Also, per the conversation around return-status, return-representation
and Preference-Applied, I have removed the return-status and pulled
Preference-Applied back out. The logic is straightforward... if the
response cannot be unambiguously determined to be a representation
response based on a comparison of the effective request URI,
content-location and, in some cases, the Location header (e.g. for 201
Created responses), then the client must inspect the content to
determine the nature of the response regardless of which return-*
preference was used. Return-status, then, provides no additional value
and the need for Preference-Applied disappears. If, at some point in
the future the need for Preference-Applied arises, it can be looked at
again.

- James

---

From: Martin Thomson <[email-masked]>
Date: Sat, 10 Dec 2011 14:48:06 +1100

On 9 December 2011 04:56, James Snell <[email-masked]> wrote:
> Basically, if you're

Great.

> if the
> response [...] then the client must inspect the content to
> determine the nature of the response [...]

Cool.

Regarding wait and Date and the text added since -05:

You recommend that the client use Date so that the server knows the
absolute time that a response is required.  I don't see that working
particularly well in practice.  I also want to caution against over
engineering.

It's very hard to know what time the client truly made a request, even
with a Date header.  At least at the client end, you can make some
assumptions so that you can compensate for clock drift and
request/response transit times.  Without a closed loop, it's virtually
impossible to guarantee good timing.

Pragmatically, I think that the only reasonable way to implement this
header at the server is to take the time of request receipt, add the
wait time, and use that as the end date.  That could mean that a
response is ready for delivery milliseconds after that time limit has
expired, and will ultimately be received some time past the clients
reported deadline.

The client is in the best position to observe latencies that the
server cannot see, and they are then able to make allowances.  That
could mean offloading complexity to a client, which I would ordinarily
be leery of doing.  However, once again, I expect that it will be a
very simple process.  If I absolutely can't wait more than 20s, I
might set wait=18 or even wait=15 and leave it at that.  I can't see
anything more complicated being necessary in 99% of cases.  For
applications with tight latency requirements, and strict resource
constraints, I can imagine that a fairly sophisticated solution could
be constructed...but it's probably unnecessary most places.

--Martin

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 12 Dec 2011 10:40:48 -0700

On 12/09/2011 08:48 PM, Martin Thomson wrote:

> particularly well in practice.

An accurate Date header seems necessary for "wait" when multiple
intermediaries are present. Without it, the end recipient will not be
able to approximate the amount of time the user agent has been waiting.
If such approximation is not necessary, the preference wording should be
adjusted accordingly.

We could assume that any number of intermediaries will not delay the
requests by more than a couple of seconds, but that assumption will be
wrong when connectivity is poor. Whether the preference is meant to work
in poor connectivity cases or just in slow origin server cases is not
clear to me.

If recommendation for the Date header is removed, new wording should be
added to explain that proxying and transmission delays are deemed
unimportant for this preference.

> impossible to guarantee good timing.

If an agent clock is seriously wrong, the inclusion of Date header may
indeed screw things up. Thus, we have a choice between two directions:

1) Focusing on correctly handling proxied transactions and slow
connections when agent clocks are reasonably correct.

2) Focusing on per-hop processing delays and bad clocks while ignoring
many delays caused by slow/poor connectivity.

Either choice is OK, I guess, as long as it is clearly documented.

Cheers,

Alex.

---

From: James Snell <[email-masked]>
Date: Mon, 12 Dec 2011 10:41:09 -0800

The bottom line to it is timing on the web is always going to be messy
and there's not a thing we're going to be able to do about that (nor
should we really try). The wait preference is intended as a hint to
the server as to what the client will likely do if the request takes
too long to process, not an absolute top limit. When setting the
preference, the client needs to specify a reasonable period of time
based on what it expects the latency to be. There's not much else we
can (or should) do... it is an optional preference afterall.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Dec 2011 22:15:56 +0100

> using Prefer for content-negotiation, you're likely doing it wrong.

Not convinced. Where's the difference? If the response without "Prefer" 
would have been cacheable, and the presence of the Prefer header field 
changes the response I receive, how is that *not* content negotiation?

> the future the need for Preference-Applied arises, it can be looked at

I think this works, but let me try an example to make sure.

Request:

   PUT /foo HTTP/1.1
   Host: example.com
   Content-Type: text/plain

   Hello

Response (1):

   HTTP/1.1 200 OK
   ETag: "1"
   Content-Type: text/plain

   /foo updated

or (2)

   HTTP/1.1 200 OK
   ETag: "1"
   Content-Type: text/plain
   Content-Location: /foo

   Hello

In (1), the response is a status message, in (2) it's the new 
representation that I'd also get if I did an immediate GET (and if there 
was no in-between modification).

Or with POST:

   PUT /container HTTP/1.1
   Host: example.com
   Slug: bar
   Content-Type: text/plain

   Hello

Response (1):

   HTTP/1.1 201 Created
   ETag: "1"
   Content-Type: text/plain
   Location: /container/bar

   /container/bar created

or (2):

   HTTP/1.1 201 Created
   ETag: "1"
   Content-Type: text/plain
   Location: /container/bar
   Content-Location: /container/bar

   Hello

I think this is going to work.

Best regards, Julian

PS: and notice the beauty of the new ABNF :-)

---

From: James Snell <[email-masked]>
Date: Mon, 12 Dec 2011 13:52:07 -0800

> changes the response I receive, how is that *not* content negotiation?

I tend to view it more as behavior negotiation but it is definitely a
grey area. Going to be thinking this through a bit more.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Dec 2011 14:10:04 +0100

>> http://www.ietf.org/id/draft-snell-http-prefer-07.txt

    A preference token MAY specify a value.  Empty, or zero length values
    on both the preference token and within parameters are equivalent to
    no value being specified at all.  The following, then, are
    equivalent:

      Prefer: foo; bar=""
      Prefer: foo=; bar
      Prefer: foo=""; bar=

In the above examples, the second and the third one are invalid (missing 
value after "="). Bad examples, or bug in the ABNF? (I'd prefer the former).

Best regards, Julian

---

From: James Snell <[email-masked]>
Date: Tue, 13 Dec 2011 11:08:03 -0800

Yes, they are invalid. I need to point that out. They are equivalent
to the first but shouldn't ever be done.

---

From: James Snell <[email-masked]>
Date: Tue, 13 Dec 2011 11:42:20 -0800

> changes the response I receive, how is that *not* content negotiation?

Ok, here's another run at explaining this... let me know if it makes
sense and is convincing enough ;-)

As I've pointed out, the Prefer mechanism is essentially
behavior-negotiation, which means, it allows the client a means of
politely asking the server to act a particular way when processing a
request. In the case of the return-representation, return-minimal and
return-accepted preferences, it is essentially negotiating with the
server about the processing model for a request. Whether the content
actually returned by the server is cacheable or not is a different
question that will be dependent on a number of factors including the
specific response code, request method and effective cache-controls.
Asking a server to return a representation a modified resource has no
impact on whether that representation is cacheable. Asking the server
to return a minimal response (e.g. 204 No Content) also has no impact
on whether the representation is cacheable. Let's look at an
example...

Suppose we have an api that supports to use of the
return-representation and return-minimal preferences... basically,
when I modify content, I can send Prefer: return-representation or
Prefer: return-minimal. Specifying either of these on a GET makes
absolutely no sense given that return-representation implied in the
nature of GET and return-minimal should still return the
representation. If an application supports alternate representations
(minimal and verbose) of a resource, then it has to be prepared to
deal with cacheability independently of whether Prefer is used or not.
So assume we POST a resource to a collection and want a minimal
reponse...

  Prefer: return-minimal

  {Data}

...

  HTTP/1.1 201 Created
  Location: http://example.org/collection/1
  Content-Length: 0

Ok, since this is a POST (content modification), the default
assumption is that the response is not cacheable (per
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-17#section-6.5).
The response would have to contain specific caching information in
order to be cacheable. So here, it's not a problem.

Let's look at return-representation now...

  {Data}

...

  HTTP/1.1 201 Created
  Location: http://example.org/collection/1
  Content-Type: text/plain
  Content-Length: 6

  {Data}

Ok, in this example, again, the default assumption is that the
response is not cacheable. It doesn't matter that
return-representation was used. The server would have to include
additional freshness information in the response in order to make the
request cacheable (e.g a cache-control header).

PUT and PATCH would be handled the same... whether the response is
cacheable or not has absolutely nothing to do with which preference
was passed in.

The same considerations apply to returning a 202 Accepted for
asynchronous processing using the return-accepted preference... again,
because of the requests used, and the nature of handling 202
responses, the cacheability of the response is completely independent
of the specific preference applied.

So for the various return-* (and wait) preferences currently defined
in the spec, it's clear that they are not content-negotiation
mechanisms.

Contrast that with the detail preference that I removed. In that case,
the preference specifically deals with the amount of information to
include in the response. Let's assume I left that in... per the
definition of the preference, it's up to the server to figure out how
it applies. The original intent for the preference is to affect the
amount of detail included in error responses in an api (4xx and 5xx
responses), primarily for debugging purposes. Again, for modification
requests (DELETE, PUT, POST, PATCH, etc) the default cacheability of
the response has absolutely nothing to do with the preference
specified, and anyone who is caching error responses that could
potentially contain request-specific content is asking for trouble
anyway. (btw, it's interesting the the http spec is completely silent
on the cacheability of 4xx and 5xx responses with the exception of
410). If a specific API wishes to apply the Detail preference to
non-error output, then it has to be prepared to deal with the caching
consequences regardless or whether Prefer is used or not. That said,
however, an API that allows non-error variability in the verboseness
of the non-error output would be better off defining a querystring
parameter specifying the verboseness than using Prefer. Prefer: detail
works great for debugging error responses, not so much for regular api
use. Regardless, use of Prefer: detail would not inherently impact the
caching of the response.

Convinced yet?

Now, if I defined a preference like "Prefer: return-atom", that would
be Just Plain Silly. Preferences should be limited to behavioral
options (how to handle a request, how to handle the response, how to
deal with various error conditions, etc) leaving the content options
up to the request uri and various Accept-* headers, etc.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Dec 2011 21:04:32 +0100

> sense and is convincing enough ;-)

You may or may not have noticed that we had a perfect storm of 
back-and-forth on [email-masked] today. It was about 
whether selecting the type of a response (status vs representation vs 
...) is some kind of content negotiation, that should or should not be 
triggered using Accept:.

In that discussion it became clear to me that what we really want to 
select are different resources that are related to the outcome of the 
operation, such as:

- status
- new representation
- monitor resource
- something else (next step in a UI workflow?)

Maybe that would make at least the return-* preferences clearer.

> server about the processing model for a request. Whether the content

I agree for -accept, but -minimal vs -representation doesn't seem to 
affect processing but just the type^h^h^h^hkind of response (*not* the 
media type).

> on whether the representation is cacheable. Let's look at an

Yes.

> nature of GET and return-minimal should still return the

Absolutely. It might be good to state this in the spec.

>    Location: http://example.org/collection/1

Content-Location missing here?

> request cacheable (e.g a cache-control header).

Yes.

> use. Regardless, use of Prefer: detail would not inherently impact the

When used with GET, with Vary. Yes.

> Convinced yet?

Maybe. I think the key is to clarify that for return-*, Prefer doesn't 
select different representation types for the same resource, but 
actually defines what resource to represent in the response.

> up to the request uri and various Accept-* headers, etc.

Yes.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Dec 2011 11:23:28 +0100

> to the first but shouldn't ever be done.

Not sure that phrasing it this way is a good idea.

If they are invalid, they can't be equivalent.

If you want to make them equivalent, then you have to require recipients 
to process them.

(my preference would be to leave them invalid)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Dec 2011 21:19:08 +0100

> essentially wrong, and you can have the nice-looking wait=10 preference.

Here's an attempt to clean up Expect:

- fixes the grammar to allow params for value-less expectations

- re-adds whitespace (lost during ABNF update)

- untangles the predefined value 100-continue from the ABNF

The whole paragraph would be:

9.3.  Expect

    The "Expect" header field is used to indicate that particular server
    behaviors are required by the client.

      Expect       = 1#expectation

      expectation  = expect-name [ BWS "=" BWS expect-value ]
                                 *( OWS ";" OWS expect-param )
      expect-param = expect-name [ BWS "=" BWS expect-value ]

      expect-name  = token
      expect-value = token / quoted-string

    A server that does not understand or is unable to comply with any of
    the expectation values in the Expect field of a request MUST respond
    with appropriate error status code.  The server MUST respond with a
    417 (Expectation Failed) status code if any of the expectations
    cannot be met or, if there are other problems with the request, some
    other 4xx status code.

    This header field is defined with extensible syntax to allow for
    future extensions.  If a server receives a request containing an
    Expect field that includes an expectation that it does not support,
    it MUST respond with a 417 (Expectation Failed) status code.

    The only expectation defined by this specification is:

    100-continue

       Defined in Section 6.2.3 of [Part1]

    Comparison is case-insensitive for names (expect-name), and is case-
    sensitive for values (expect-value).

    The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
    return a 417 (Expectation Failed) status code if it receives a
    request with an expectation that it cannot meet.  However, the Expect
    header field itself is end-to-end; it MUST be forwarded if the
    request is forwarded.

    Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
    Expect header field.

(see 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/327/327.diff>)

Feedback appreciated, Julian

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 14 Dec 2011 15:20:51 -0700

>    with appropriate error status code.

It is not 100% clear what "expectation value" is in the above MUST
context. Just "expect-value" inside "expectation"? Or also
"expect-value" inside "expect-param"? Or anything inside "expectation"?
I suspect it is the latter but the addition of "-value" suffixes in BNF
made it less clear.

For example, if a server is able to comply with 100-continue but receives

    Expect: 100-continue; q=0

can that server assume that it is still able to comply or must it
respond with 417? Again, I suspect it is the latter.

Note that the BNF in RFC 2616 did not use "value" elements so it did not
raise similar "what is expectation value" questions.

Please consider replacing "any of the expectation values" with "any
expectations".

>    The server MUST respond with a

Technically, the above is ambiguous because both conditions could be
true. Not a big problem, but perhaps it should be polished since this is
a MUST. More on this below.

>    it MUST respond with a 417 (Expectation Failed) status code.

This paragraph kind of adds a third condition to the previous group of
MUSTs so it would be nice to merge them together:

  does not understand: 417
  understands but cannot meet: 417
  cannot parse: 4xx that is not 417

with some prioritization language to resolve conflicts when multiple
conditions apply at the same time.

>    request with an expectation that it cannot meet.  

In general, it is a bad idea to partially repeat a MUST specified
elsewhere. It raises questions whether this repetition for proxies
somehow annuls other related MUSTs when it comes to proxies (e.g.,
server MUST respond with 4xx if ...). It may be better to replace this
with something like:

    The Expect mechanism is hop-by-hop; the above server requirements
    apply to proxies.

> However, the Expect

RFC 2616 does not have an explicit "end-to-end headers MUST be
forwarded" rule (AFAIK). If that problem is fixed in HTTPbis, there will
be (or already is) a similar "repeated MUST" concern here.

Thank you,

Alex.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Dec 2011 00:09:45 +0100

>>     with appropriate error status code.

And looking at this, that error code will always be 417, right? Thus 
that text can be simplified.

Yes.

> a MUST. More on this below.

Actually, the 4xx part isn't needed here. It's not specific to Expect:.

> MUSTs so it would be nice to merge them together:

Doesn't is just repeat what was said before? I think it can be dropped 
as well.

> server MUST respond with 4xx if ...). It may be better to replace this

Yes, we can just state that the requirements apply to all *recipients*.

> be (or already is) a similar "repeated MUST" concern here.

"It always said that" :-) Not sure what we should do here.

I now have:

9.3.  Expect

      Expect       = 1#expectation

      expect-name  = token

    A recipient that does not understand or is unable to comply with any
    of the expectations in the Expect header field(s) of a request MUST
    respond with a 417 (Expectation Failed) status code.

    100-continue

    Comparison is case-insensitive for names (expect-name), and case-
    sensitive for values (expect-value).

    The Expect mechanism is hop-by-hop: the above requirements apply to
    any component receiving requests.  However, the Expect header field
    itself is end-to-end; it MUST be forwarded if the request is
    forwarded.

Thanks for the feedback, Alex. Please have another look!

Best regards, Julian

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 14 Dec 2011 17:02:42 -0700

>    respond with a 417 (Expectation Failed) status code.

You essentially dropped the 4xx part for invalid Expect headers. That
simplified the specs a lot, but I am not sure we can do that because
"does not understand" and "unable to comply" do not necessarily cover
"cannot parse".

You have argued that inability to parse a header field is covered
elsewhere. I am not well versed in HTTPbis yet, but I doubt this is
true. There are probably no requirements that a server MUST respond with
an error if it cannot parse Date or other non-critical headers. We need
an _explicit_ rule to make Expect critical. I suspect that is why there
was an explicit "MUST respond with ... 4xx" rule here in RFC 2616.

Consider the following text:

If all received Expect header field(s) are syntactically valid but
contain an expectation that the recipient does not understand or cannot
comply with, the recipient MUST respond with a 417 (Expectation Failed)
status code. A recipient of a syntactically invalid Expectation header
field MUST respond with a 4xx status code other than 417.

>    any component receiving requests.  However, the Expect header field

I would replace "any component receiving requests" with "any receiving
agent, including proxies" or with "any server, including proxies" to use
terminology established in HTTPbis part 1.

Thank you,

Alex.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Dec 2011 10:03:38 +0100

> You have argued that inability to parse a header field is covered

Covered in that we say "it depends".

> was an explicit "MUST respond with ... 4xx" rule here in RFC 2616.

Probably. Will adjust.

> field MUST respond with a 4xx status code other than 417.

400?

> terminology established in HTTPbis part 1.

Thanks for the feedback; will send out a new proposal later today.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Dec 2011 22:10:57 +0100

Again, thanks for the feedback. I used the text you suggested and now have:

9.3.  Expect

      Expect       = 1#expectation

      expect-name  = token

    If all received Expect header field(s) are syntactically valid but
    contain an expectation that the recipient does not understand or
    cannot comply with, the recipient MUST respond with a 417
    (Expectation Failed) status code.  A recipient of a syntactically
    invalid Expectation header field MUST respond with a 4xx status code
    other than 417.

    100-continue

    The Expect mechanism is hop-by-hop: the above requirements apply to
    any server, including proxies.  However, the Expect header field
    itself is end-to-end; it MUST be forwarded if the request is
    forwarded.

(<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/327/327.3.diff>)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Dec 2011 22:14:30 +0100

> Again, thanks for the feedback. I used the text you suggested and now have:

OK, I did two more changes:

- in the grammar, allow trailing semicolons; so that "100-continue;" 
isn't invalid (we have the same in Prefer)

- state that 100-continue doesn't have expect-params

The change is committed with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1494>, and the 
text now says:

9.3.  Expect

      Expect       = 1#expectation

      expectation  = expect-name [ BWS "=" BWS expect-value ]
                                 *( OWS ";" [ OWS expect-param ] )
      expect-param = expect-name [ BWS "=" BWS expect-value ]

      expect-name  = token

    100-continue

       The "100-continue" expectation is defined Section 6.2.3 of
       [Part1].  It does not support any expect-params.

Best regards, Julian

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 16 Dec 2011 14:56:42 -0700

> isn't invalid (we have the same in Prefer)

Any specific reason to allow that trailing semicolon? Seems like it
should not be allowed unless Expect is already commonly used that way.

I cannot find it right now, but I think there was some text in HTTPbis
that talked about "cleansing" of header fields before
comparing/interpreting them (folding, removing BWS, and such). If that
text is indeed there somewhere, does it allow an implementation to
remove bare semicolon before comparing?

Finally, I expect some currently compliant implementations to fail
updated tests if a bare semicolon is allowed and must be ignored.

Thank you,

Alex.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Dec 2011 23:22:59 +0100

> should not be allowed unless Expect is already commonly used that way.

a) there's no harm

b) it's a very easy mistake to make

c) it doesn't introduce ambiguity

d) for other header fields, we have evidence that parsers already do this

For Expect:, I have no data, as it doesn't seem to be used for anything 
other than "100-continue".

> remove bare semicolon before comparing?

Before comparing what?

> updated tests if a bare semicolon is allowed and must be ignored.

Will those accept things like

   foo, 100-continue

or

   foo; bar="q\ux,", 100-continue

?

Best regards, Julian

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 16 Dec 2011 16:48:26 -0700

>> should not be allowed unless Expect is already commonly used that way.

I am sure some servers that can grok "100-continue" will fail to
recognize "100-continue;" as equivalent and respond with 417. Granted,
many of those servers are not compliant in other Expect-related ways,
but I do not think "no harm" is a 100% valid assumption in this case.

> b) it's a very easy mistake to make

Agreed, on both counts: easy and mistake.

> c) it doesn't introduce ambiguity

It kind of does. Is "100-continue" equivalent to "100-continue;" and
"100-continue;;;;;"? On an intuitive level, they should be equivalent,
but I see no explicit rules that make them equivalent, especially since
we say that 100-continue does not have parameters.

> d) for other header fields, we have evidence that parsers already do this

but I am guessing there is no evidence that senders send bare semicolons
in Expect headers.

> other than "100-continue".

And that is one of the reasons making this header more complex is more
dangerous.

>> remove bare semicolon before comparing?

Comparing with other [cached] headers (for Vary and such) or, in this
case, comparing with the list of supported extensions (which is usually
just 100-continue).

>   foo; bar="q\ux,", 100-continue

Yes, some will handle the above (and worse) because we already test them
for those cases :-)

Again, I understand that this is a very minor issue that is unlikely to
cause serious problems. It feels strange to defend a "do not change
unless there is a problem" principle in an HTTPbis effort, but I am not
trying to insist on reversing this change.

Thank you,

Alex.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 17 Dec 2011 01:02:21 +0100

> but I do not think "no harm" is a 100% valid assumption in this case.

Will those servers process

   ,100-continue

or

   100-continue,

? These were valid before already.

> we say that 100-continue does not have parameters.

Yes, they should be equivalent.

> but I am guessing there is no evidence that senders send bare semicolons

Yes, so it doesn't make any difference in practice.

> And that is one of the reasons making this header more complex is more

There's some truth to this, but then maybe we shouldn't have started to 
fix the grammar in the first place.

> case, comparing with the list of supported extensions (which is usually

Well, the main issue is that other expectations never have been tried; 
in particular expectations using all these syntactic features.

> trying to insist on reversing this change.

I agree it's in the gray area. On the other hand, we want to clarify 
extension points etc. Expect: certainly is a header that never has been 
tested a lot.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 17 Dec 2011 08:37:24 +0100

Hi Alex,

> but I do not think "no harm" is a 100% valid assumption in this case.

Just checked, and I can confirm that haproxy only matches
"100-continue" when the field value is exactly 12 chars. And I'm sure
it's not the only one to match this exact value since rfc2616 did not
allow for anything past "100-continue".

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 17 Dec 2011 08:40:46 +0100

Hi Julian,

> ? These were valid before already.

Speaking for haproxy, the second one will work, because it splits header
values on the commas and trims the spaces. So the first above will be
considered as an empty expectation followed by a 100-continue (but haproxy
only considers the first Expect value) and the second one is OK.

Haproxy's processing of Expect is incomplete and almost unused, so it
should not be seen as a reference implementation at all (!). However
the semi-colon after 100-continue was not supposed to happen in 2616,
which is why I think other implementations might get trapped.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Sat, 17 Dec 2011 22:12:05 +0100

> which is why I think other implementations might get trapped.

That is true, but it *is* an edge case.

The alternative is to make the grammar different from Prefer:; or to 
change Prefer: as well.

In practice, most parsers that understand ";" separated parameters allow 
"empty" parameters (see, for instance, my Content-Disposition test 
cases). We can pretend this is wrong, or we can try to bring a bit more 
sanity to this.

In any case, the fact that existing implementations might trip over 
something that (for Expect!) will only happen in test cases doesn't seem 
to be a big problem to me.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 17 Dec 2011 22:58:05 +0100

On Sat, Dec 17, 2011 at 10:12:05PM +0100, Julian Reschke wrote:
> >However

Agreed.

> The alternative is to make the grammar different from Prefer:; or to 

We have enough different grammars, let's try to factor them as much as
possible!

> to be a big problem to me.

Well, it's possible that in a few years we see new implementations write
their Expect header as $expectation ";" $extension but by this time, server
implementations will have applied the rules from the new RFC and will support
the extra semi-colon. I'm not quite worried, I just wanted to outline that
*some* existing implementations are not compatible with the proposal, that's
all.

Best Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Sat, 17 Dec 2011 23:01:14 +0100

> We have enough different grammars, let's try to factor them as much as

+10

> their Expect header as $expectation ";" $extension but by this time, server

Example?

> *some* existing implementations are not compatible with the proposal, that's

Which reminds me that this needs to go into the Changes-from-2616 section.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 17 Dec 2011 23:25:38 +0100

> >their Expect header as $expectation ";" $extension but by this time, server

I basically mean this (sorry for the poor naming above) :

  int make_header(char *out, const char *hdr, const char *name, const char *value)
  {
	return sprintf(out, "%s: %s; %s\r\n", hdr, name, value);
  }

and further in the code :

  if (post_request)
      req += make_header(req, "Expect", "100-continue", "");

Which will result exactly in this, which was not possible in 2616 :

  "Expect: 100-continue; \r\n"

That said, since Expect is only used with 100-continue, we could add
a line indicating that previous versions did not allow the trailing
semi-colon and that senders should avoid emitting it for the sake of
interoperability.

Regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 18 Dec 2011 12:47:14 +1300

> 	return sprintf(out, "%s: %s; %s\r\n", hdr, name, value);

At which point the authors gets breakage reports and someone points out 
it should have been:

   return sprintf(out, "%s: %s%s%s\r\n", hdr, name, (*value?";":""), value);

Which is both less bandwidth and more compliant across all headers. 
Including those which use ';' as delimiter between names and those which 
dont permit parameters.

> semi-colon and that senders should avoid emitting it for the sake of

Which is a bit doubtful on the need. Under that same reasoning every 
other header BNF would need a similar statement about things which 
*might* be sent but not accepted by all receivers? I think its not a 
good idea to go down that road. The worst that would happen here is 417 
responses to broken sender software.

AYJ

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 18 Dec 2011 00:57:53 +0100

> Including those which use ';' as delimiter between names and those which 

I agree Amos, I was just showing an example of what naive code can look
like when applying a rule which (fortunately) becomes simpler, and where
it can break current software, eventhough arguably in a non-critical way.

> *might* be sent but not accepted by all receivers?

No, here we're changing what's allowed to be sent for a case where only
one single value was allowed. We should just get prepared for a few
isolated breakage reports. At least a referrer to the "changes from 2616"
would be nice. The worst thing with this spec is that it's so huge that
you can't imagine that other areas precise what you're reading hundreds
of pages later if you don't have any hint.

> I think its not a 

No, not to broken sender software, to the ones implementing the new
standard the lazy way.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Sun, 18 Dec 2011 13:38:24 +0100

> Which reminds me that this needs to go into the Changes-from-2616 section.

I have added for now:

     The ABNF for the Expect header field has been both fixed (allowing
     parameters for value-less expectations as well) and simplified
     (allowing trailing semicolons after "100-continue" when they were
     invalid before).  (Section 9.3)

(<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1495>)

...just so the text as checked-in is complete.

Now with respect whether we should make this change (allowing trailing 
semicolons): I'm open to reversing that, but in that case Prefer should 
match that. That being said, I think the harm done by not allowing them 
in both is bigger than the new edge case we introduce for 100-continue 
matching.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 19 Dec 2011 00:00:12 +0100

Hi Julian,

> ...just so the text as checked-in is complete.

OK

> in both is bigger than the new edge case we introduce for 100-continue 

I too think we should keep the change for now as the risk seems low.

Regards,
Willy

---

From: James Snell <[email-masked]>
Date: Sun, 18 Dec 2011 18:46:42 -0800

Updated version based on the latest round of feedback...

  http://www.ietf.org/id/draft-snell-http-prefer-08.txt

- James

On Wed, Dec 14, 2011 at 2:23 AM, Julian Reschke <[email-masked]> wrote:
> If you want to make them equivalent, then you have to require recipients to
> process them.
>

---

From: Alex Rousskov <[email-masked]>
Date: Sun, 18 Dec 2011 22:15:00 -0700

>    In the case generating a response will take longer than the time
>    specified, the server, or proxy, can choose to either return a 202
>    Accepted response, cancel processing, or continue attempting to
>    complete the request

If you want to recommend one of TWO server actions (either "return 202"
or "continue"), then please remove "cancel processing" to avoid the
implication that there is a third action.

If you want to recommend one of THREE server actions ("return 202",
"cancel processing", or "continue"), then please consider removing
"either". In this case, you may want to clarify what "cancel processing"
means from the HTTP protocol point of view. Some kind of response is
probably appropriate even if request processing is canceled.

Please consider replacing "can choose to" with "MAY".

>    Failing to include a Date header field in the request would
>    require the server to use the instant it received and began
>    processing the request as the baseline for determining how long the
>    client has been waiting which could yield unintended results
>    depending on how out of synch the client and server clocks are.

The "depending on how out of synch the client and server clocks are"
trailer should be removed because:

1) When the clocks are out of sync, the Date header can only hurt so the
"Failing to include" precondition is not applicable when clocks are out
of sync.

2) When the clocks are in perfect sync, but there is no Date header,
then there still will be "unintended results", caused by absence of any
information regarding how long the client has already been waiting for
when the server received the request.

In other words, the Date header is no meant to solve the problem with
out-of-sync clocks. It is meant to solve the problem of a [long] chain
of [slow] connections/proxies eating at the remaining time to process
the request.

>    Note that because of the inherent difficulties in reliably
>    determining the length of time a request will take to arrive at
>    server, the wait preference is, at most, a hint to the server as to
>    what the client is likely to do should the processing of a request
>    take too long.

It feels like the "is, at most, a hint" part implies that all of the
above specs were useless. If the preference is just such a hint (or
less!), there is no need to specify the wait time. Perhaps it would be
better to rephrase the above in most specific terms? For example,

Lack of a Date header or poor clock synchronization makes it impossible
to determine the exact length of time the client has already been
waiting for when the request was received by the server. The only
reliable information conveyed by the wait preference is that the client
is not expecting the server to spend more than the specified time on
request processing and may terminate the transaction at any time.

>    When specifying a value for the wait preference,
>    Client's need to take appropriate care to specify a reasonable period
>    of time.

Replace "Client's need" with "client needs". I would actually remove
this sentence completely because it essentially says that "client needs
to be reasonable" which is kind of obvious/understood.

Moreover, when thinking about a _client_ implementation, I think all of
the above complications become unimportant. Our assumption is that the
client has its reasons to limit the wait.  It should not be important to
the _client_ what portion of its lifetime the request spends in-transit
or whether the clocks are in sync. All of that is outside client control
anyway. The client has reasons to terminate the transaction in X seconds
[after Date], and that is what it should say using this preference.

HTH,

Alex.

---

From: James Snell <[email-masked]>
Date: Mon, 19 Dec 2011 10:00:00 -0800

Thx for the quick response... I'm making some tweaks and using some of
your suggested text in the next draft.

I'd like to be able to put a wrap on this after this next iteration.

- James

---

From: James Snell <[email-masked]>
Date: Mon, 19 Dec 2011 11:37:38 -0800

Ok.. another iteration... bumped it once but realized just after that
I had omitted the Date header from the wait examples so bumped it
again...

  http://www.ietf.org/id/draft-snell-http-prefer-10.txt

- James