- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 05 Dec 2011 21:29:33 +0100
- To: James Snell <jasnell@gmail.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>
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. Martin? >>>> [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