Re: Prefer Draft Feedback

On 2011-12-05 21:20, James Snell wrote:
> ...
> 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.

Indeed; I had PUT on my mind.

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


>>>> [snip]
>>>> 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)
>>> Not sure what exactly you're objecting to here. Is it the registry or
>>> the comparison rule?
>> The comparison rule.
> 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.

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

Received on Monday, 5 December 2011 20:30:11 UTC