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

>subgroup's hypermail archive.  The only difference is that I require
>Vary to be sent even when Alternates is present, since that is the only

This is enough of a difference to concern me.  I have not yet seen a
convincing series of examples that demonstrate a set of rules by which all
parties can logically behave when presented with both a Vary header and an
Alternates header in a response.

If I as an origin server serve different responses based on the strlen() of
the Accept: header, I would add "Vary: Accept".  That's a different beast
than adding "Vary: Accept" to a transparently negotiated response.  You
might be able to come up with a clear, air-tight description of Alternates
that 'frees up' some of the constraints normally placed on a recipient by
the presence of a Vary: header, but it has yet to be proven to me.

Anyway, it's pretty late in the game for this change, and my comfort level
with this is certainly much lower than my comfort level with the "Vary:
{accept-headers}" facility.

>9. FATAL description of Vary in contradiction of all past discussion of
>the Vary header field, including David Robinson's draft at
><http://www.ast.cam.ac.uk/~drtr/vary.html>, and directly contradicting
>the previously cited consensus on conneg.  Vary specifies the list of
>header fields over which the representation may vary on any future request.
>Vary would serve no useful purpose if that were not true.

a) I don't quite yet understand what aspect is 'fatal'.  If you have time,
please elaborate.  b) David Robinson's draft never represented the consensus
of the conneg group.  In fact, DR, never even posted to the conneg group.

>not think that they were absolutely necessary.  I did not make them
>directly to the document, nor did I ask Jim to change the draft before
>this was reviewed by the WG, as might be implied by Koen's messages.

I would have liked to have seen the reasons before the diffs, rather than
after.  (Personally, I'd rather see large chunks of straight text than diffs
anyway).

>The problems outlined above are major errors.  For example, they would
>have made it impossible for the Apache server to make use of HTTP/1.1.
>I believe the same would be true of Spyglass's server.

I've been avoiding intimacy with the details of the opaque negotiation draft
since I do not foresee the Spyglass Server ever doing opaque negotiation,
but I never saw anything fatal either.

Certianly you have raised some valid points (in particular the negotiation
of error responses).  I would advocate a more conciliatory position both by
Koen and Roy to reach a mutual agreement quickly.

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

Received on Tuesday, 28 May 1996 11:40:23 UTC