Subject: Re: Informal Last Call for HTTP Preference Header

From: Julian Reschke <[email-masked]>
Date: Sun, 05 Feb 2012 18:01:02 +0100

On 2012-01-31 22:28, James Snell wrote:
> I just posted an update for the HTTP Prefer Header altering the
> intended status from "Informational" to "Standards Track". No
> additional changes were made. As I have not received any further
> technical input on the specification, I am issuing an *Informal* Last
> Call for comments before I request that it be kicked up the chain for
> review.
>
> Mark Nottingham has agreed to serve as the document shepherd for
> helping to move it forward.
>
> Current Draft: http://www.ietf.org/id/draft-snell-http-prefer-11.txt
>
> - James

I think we're almost there. Some notes:

s/2. The Prefer Request Header/2. The Prefer Request Header Field/

   Prefer     = "Prefer" ":" 1#preference
   preference = token [ BWS "=" BWS value ]
                *( OWS ";" [ OWS parameter ] )
   parameter  = token [ BWS "=" BWS value ]
   value      = token / quoted-string

Could use <word> instead of value 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.3.2.4>)

s/Registry of Preferences (Section 9.1))/Registry of Preferences 
(Section 9.1)/

s/In various situations, A proxy may/In various situations, a proxy may/

Also: is this MAY? If not say "can". Same in other places.

2.2 Examples: end the descriptions with a colon (":").

If "strict" and "lenient" are described as a mutually exclusive pair, 
shouldn't this also be the case for return-minimal vs return-representation?

/This specification establishes an IANA registry of such relation types 
see Section 9.1./This specification establishes an IANA registry of such 
relation types (see Section 9.1)./

9.1:

"Application Data: [optional]" -- copied from RFC 5988 (?) but doesn't 
make sense here...

The httpbis references need an update.

Finally, I notice that most registry considerations are cloned from RFC 
5988. I'm not totally sure that this is a good idea; Mark has been 
discussing this in a different context for some time now, so I guess 
he'll have something to say :-)

Best regards, Julian

---

From: James Snell <[email-masked]>
Date: Wed, 8 Feb 2012 07:54:08 -0800

Yes, I can add that into the example.

On Tue, Jan 31, 2012 at 5:39 PM, Amos Jeffries <[email-masked]> wrote:
[snip]
>>
>> Can you clarify the meaning of an ETag header returned in the
>> response to a PUT with a Prefer:return-representation header. Would
>> that ETag refer to the resource whose representation is being
>> returned?
>
>
> If it does not something is badly broken. HTTPbis part 4 section 2.3:
> "
> 2.3. ETag
>
>   The ETag header field provides the current entity-tag for the
>   selected representation.
>
> "
>
>> If so, could we please include ETag in the example. If not,
>> then we really need a way to get the actual ETag for the returned
>> representation - otherwise Prefer:return-representation is not that
>> useful.
>
>
> +1.
>
> AYJ
>

---

From: James Snell <[email-masked]>
Date: Wed, 8 Feb 2012 08:18:06 -0800

Thank you for the additional feedback. I've incorporated the suggested
changes. If you have some specific ideas for how to improve the
registry considerations, definitely please let me know as well.

On Sun, Feb 5, 2012 at 9:01 AM, Julian Reschke <[email-masked]> wrote:
> s/Registry of Preferences (Section 9.1))/Registry of Preferences (Section
> 9.1)/
>
>
>
> /This specification establishes an IANA registry of such relation types see
> Section 9.1./This specification establishes an IANA registry of such
> "Application Data: [optional]" -- copied from RFC 5988 (?) but doesn't make
> sense here...
>
>
>
> discussing this in a different context for some time now, so I guess he'll
> have something to say :-)
>
> Best regards, Julian
>

---

From: James Snell <[email-masked]>
Date: Wed, 8 Feb 2012 10:20:58 -0800

Version -12... updated per the feedback provided...

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

At this point, unless there are specific updates that need to be made
to the registry portion as alluded to by Julian, I'm ready to call
this one complete.

Peter: can we start the process of moving this along and issuing a
formal last call. Mark Nottingham has agreed to act as the Document
Shepherd.

- James