Re: Changes to Content Negotiation, Entity Tags, and If-*

>entity body_.  The content negotiation subgroup however has consensus
>that this list should be sent in the Alternates header.  The plain 1.1
>draft should be silent about where and when this computer-readable
>list will appear, and your text is not.

While we had consensus that the list would appear in the Alternates header,
we did not have consensus that it could *not* appear in the entity body.  I
don't recall, but it might have been more of a "don't care" situation.
Since Roy cares, let him have this change, so that we may reach an agreement
more quickly.

>! Roy's requirements on 300 and 406 in general look exactly correct
>! to me, so that an entity can be returned to a dumb client that does
>! not do content negotiation, while smart clients can use Alternates
>! and not bother the user.  In fact, to have a chance of deploying
>! any sort of content negotiation, the requirement to send and entity

Must agree.

>! and the larger group of us last week agreed that the 7 bytes to say
>! "Vary:*" would not be too much.

I've expressed in a previous message that I don't feel the inclusion of
Vary:* makes sense (on a transparently negotiated response).

> negotiation is the process of selecting the best representation when a
> GET or HEAD request is made on the generic resource.
> (section 15)
>!
>! and the definition in 03 was also broken.  For example, GET or HEAD
>! are clearly not the only methods which might apply.

Which others would?  Certainly a negotiated PUT is *way* under-defined.  Is
an Accept: text/html PUT to a negotiation port/generic resource/term of the
week supposed to indicate that the text/html variant should be replaced if
there is one?  I think not.  Are people going to keep POSTing pizza orders
until they get the reply in the content encoding they want?  I think not.

Personally, there was a reason I avoided thinking about negotiation on other
methods - I wanted to save myself burnt out brain cells.  Negotiation on
other methods is a can o worms the size of -- well, something really big.
And I don't know that we want to go there.

>In no way does draft-03, nor the consensus of the content negotiation
>subgroup, prevent servers from dynamically generating error messages
>in an appropriate language -- such generation is just not called
>`content negotiation'.
>!
>! If it were just a few error messages, I wouldn't complain.  But
>! HTTP often returns entities (more than a simple string) to users
>! to explain something.  There is NO need to make the distinction (and
>! in terms of generality, I would argue it is a bad idea, to distinguish
>! between entities returned from a resource (variants) and entities
>! elsewhere in the protocol.
>! I think Roy is right.  Entities in general get negotiated...

I agree it would be good practice to send back an error message in the
language/charset the server saw in the Accept-Language/Charset, but that's
about it.  I don't think we want to open up the idea of negotiation on error
messages.  "Oh, I didn't like that HTML error message, give me a postscript
one"  Huh?  What if the error message was a None Acceptable?  Do you
negotiate the content type on the None Acceptable error entity body?  How
does the server know you want that error in a different content type rather
than the actual URI resource?

>Your claims that draft-03 prevents dynamic selection of error messages
>are incorrect.  They seem to be the result of first making a private,
>much broader definitions of the term `content negotiation', and then
>reading the language in the spec with this definition in mind.  It is
>no surprise that the language in the spec would mean the wrong thing
>under another definition.  However, this does not in any way imply
>that the mechanisms as defined in the spec are wrong.  Most of your
>comments about the incorrectness of the text in the 03 spec can be
>traced back to use of a private, faulty, definition of `content
>negotiation'.
>!
>! Roy is not the only person to believe our terminology, and definitions
>! have been broken.  That is why we've been sweating blood over them.
>! The draft I'll make available later today is alot closer to correct;
>! 03 was still pretty badly broken.

I think Koen has a very good point.  I think Roy's point of view is
fundamentally different, and that's the root of these clashes.  And I'm not
as convinced as some memebers of the editorial group are that Roy's view is
entirely correct.

>! list.  And you have a tendency to write very long messages that
>! make it difficult for people to wade though to find the meat of them.

Have to agree here.

>! simplicity is worth working hard for.  This should be as simple
>! as possible, and no simpler.

I agree, but by we're not only talking about simplifying but also extending
the functionality of content negotiation into areas not yet fully explored,
and by doing that we are risking alot.  I'd like to see lots of working,
useful <EM>examples</EM> of some of the more esoteric fringe protocol
attributes before such additions/extensions are made.

>! It means that HTTP/1.1 implementers don't have to parse yet
>! another complicated BNF in the Vary header; they only
>! have to deal with complexity when/if they need to deal with it, rather than
>! making 1.1 harder to deal with.

Can you elaborate on this argument?  People who choose not to deal with the
complexity of the Vary: header don't need to parse it and if that's the
case, they don't care how complicated the BNF is.  Moot point anyway, since
syntax is not the source of contention here (I hope).

>! My opinion is that this draft is conceivably going to be submitted
>! to the IESG, and statements about controversy, particularly when it
>! has been primarily from a single individual rather than the group at large,
>! do not belong in a document at this stage.

I agree statements about controversy should not be in the draft.  However, a
controversial draft should not be submitted to the IESG, so let's work
quickly to get resolution between Koen/Roy/others on content negotiation
mechanics so the next version won't have any contention.

-----
Daniel DuBois, Software Animal          
                                     dan@spyglass.com
                                     http://www.spyglass.com/~ddubois/

Received on Tuesday, 28 May 1996 17:46:41 UTC