Re: Request that the WG reconsider section 3.4: Content Negotiation

Bjoern Hoehrmann writes:

> * Henry S. Thompson wrote:
>>See my response to Julian.  Either "contains a list" is a reference to
>>a 300 response, in which case I repeat my request to be pointed to
>>_any_ user agent which implements any kind of response to a 300 (other
>>than to treat it as a 200), or it refers to something in the message
>>body, in which case it has nothing to do with HTTP as a protocol.
>
> The redirection response codes are for cases where further action needs
> to be taken. The draft specifically mentions that a server might prefer
> such action over offering one of the alternatives directly in which case
> 300 might be a good choice for a response code. Consider as an example
>
>   Please choose your language to continue: English, Deutsch
>
> This requires the user to react. A common alternative would be
>
>   Herzlich Willkommen (also available in -> English)
>
> Which allows the user to react but does not require it. That would be a
> 200 response. It does not make sense to me that a server would include a
> list of available alternatives only if it forces the user to choose, so
> your first interpretation strikes me as unreasonable.

I'm not sure I follow the above, but at the very least if "contains a
list" is _not_ a reference to 300, that should be clarified.

> Your second interpretation is mistaken, the draft specifically mentions
> the option of including the list in header fields.

But says it's been removed!?  I presume you're refering here to 6.4.1 [1].  

Seems to me the first sentence of the first para there, namely

  The 300 (Multiple Choices) status code indicates that the target
  resource has more than one representation, each with its own more
  specific identifier, and information about the alternatives is being
  provided so that the user (or user agent) can select a preferred
  representation by redirecting its request to one or more of those
  identifiers.

But the next sentence

  In other words, the server desires that the user agent engage in
  reactive negotiation to select the most appropriate
  representation(s) for its needs (Section 3.4).

goes way too far.  All the actual uses of 300 responses we see on the
Web today invite, indeed require, the user, not the user agent, to
make a selection, and this really doesn't fit the definition of
reactive conneg from 3.4.

Note that _none_ of the 300 responses I explored included a Location:
header.

> It is appropriate to discuss how users and clients and servers can
> select among alternative representations including how to discover
> available alternatives. That is a core concern for people developing
> and deploying implementations of the protocol. If discovering
> alternatives often involves looking at links in Hypertext documents,
> the Hypertext Transport Protocol specifi- cation surely can mention
> that.

Only insofar as it makes clear that choices listed in the body, which
can only be interpreted relative to the Content-Type, are
application-specific, and not generic.  And that in fact no examples
are currently in place of user agents (as opposed to users) _making_
the choice.

Link: header elements enable HTTP-generic choice, but the spec. itself
is at least more honest about this case, by saying in the Note that
there's a chicken-and-egg problem wrt deployment.


> I think your proposal to remove a large portion of text without any
> replacement would make the draft worse, not better. I do see much room
> for improving the current text, but no particular need to do it.

3.4 describes reactive conneg in a way which is nowhere realised on
the Web today.  Leaving it as it is does your readers a disservice.

And, perhaps more important, by suggesting that reactive conneg is in
some way preferable, or more efficient, than proactive conneg, when
reactive conneg is at best rare, and the only examples you can offer
of it involve user interaction, and when proactive conneg _is_ widely
deployed, just reduces the credibility of the spec.

ht

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-6.4.1
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

Received on Tuesday, 5 November 2013 16:06:56 UTC