Re: Record of http discussions at the Paris WWW conference

>  - There is no spoofing mechanism: i.e. a response with come
>    Content-Location header may _not_ be used by 1.1 caches for
>    serving later requests which are done directly on the
>    Content-Location URI.

I disagree strongly with this change, both in it's nature, and in it's timing.  

In my mind, such a change defeats the purpose of the
Location/Content-Location header with regards to content negotiation, as it
has been discussed and developed over the last 5-10+ months.

As a process issue, there's little (no?) justification for the ground work
laid down by the subgroups over many weeks/months to be tossed in favor of
last minute changes by the editorial group.

>  - variant-IDs are deleted from the protocol.  Their function is
>    taken over by the contents of the Content-Location field.  

Variant-IDs served the useful function of distinguishing non-name-able
'plain resources'.  Content-Location served the more useful purposes of not
only distinguishing but also identifying and locating name-able 'plain
resources'.  These simple, distinct premises fueled the entire Vary vs.
Alternates, opaque vs. transparent, content negotiation structure.  I'm not
willing to see it fall out of the spec without significantly more convincing
reasons other than a hallway discussion wanted to shrink the spec at the
last minute.

>    This means that the entity tags of any two different entities
>    returned by different variant resources bound to the same generic
>    resource are guaranteed to be different.  Another way to look at
>    this is to say that a variant-ID is opaquely encoded in the entity
>    identifier.

I have no qualms with this as this does not affect what I perceive as the
underlying principles of content negotiation as described above.  Whether
the variant ID information is encoded in a separate header is half a dozen
of one, six of the other.

>  - Renaming `generic resources' to `negotiated resources' is
>    considered to be a good idea by some.
>
>  - Renaming `entity tags' to `entity identifiers' is considered to be
>    a good idea by some.

I agree with these, and have no problem with editorial terminology changes
that are made for clarification purposes as long as they do not change the
underlying mechanism.  (Although I might have said "negotiable resources".
"Negotiatied resources" sounds after the fact: in other words, that term
could potentially be confused with plain resources, which means it's
probably not much better.)

I consider it a fundamental necessity that a "GET /index" that returns
"/index.txt" should in every means possible be considered the same as a "GET
/index.txt", including, especially, the abilty to be cached.  When
transparent negotiation 'really arrives' in the future, and people start
manually requesting negotiated resources by their actual name rather than
their generic resource URL, I don't want users to suffer any penalty, either
in logic, treatment, or round trip times.

In my dream future - web pages are going to be *chock full* of embeddable
objects that can negotiated like we've never seen.  Oh, you don't download
images? Here's the HTML description of the image.  Oh, you're blind?  Here's
an audio description of the images.  Oh, you do java?  Here's an annoying
animation of the image.  No one's going to want to tweak their Accept
headers every time they come across a variant they want another version of.
They're not going to be making their 'manual correct variant' request
through the generic/negotiable resource URL, they'll be doing it through the
URL they get from the transparent negotiation headers.

-----
the Programmer formerly known as Dan          
                                     http://www.spyglass.com/~ddubois/

Received on Wednesday, 15 May 1996 07:01:54 UTC