Re: New content negotiation draft available

Mark Stemm:
>
>I had a couple of comments on the content negotiation draft. I am new to
>this discussion, so I apologize if these comments have been addressed
>before.
>
>1. I am curious why Section 5.4 makes the inclusion of type, language,
>charset, and length attributes optional. Are there some cases where it
>would be difficult for a web server/proxy to determine these
>characteristics at the time it generates the variant list?

Yes, there are such times.  First, an document author may simply not
have specified the language of a document, or even the charset, so the
server is allowed to leave them out.  Second, as you note below,
computing the length can be expensive.

 The only
>examples I can think of are cgi-bin scripts and streaming documents that
>do not have a fixed size. Additionally, I am also curious why the server
>does not have to maintain a one-to-one correspondence between the
>attributes in the variant description and the relevant HTTP Content-*
>headers. Obviously, making these fields required and identical to those in
>the HTTP header would make a client's job of choosing the most appropriate
>variant much easier, and unless there is a reason that this is difficult,
>it might be useful to make these MUSTs.

In the transparent negotiation scheme, the client uses the alternates
header field only to select content, it never needs to look at the
header fields of variants for this, so a MUST would not make the life
of a client any easier, while it might make the life of a server
(implementer) somewhat harder.

>
>2. The list of alternates in an "Alternates:" header currently uses the
>URI of documents for identification. It seems that there might be some
>advantages to using the URL of the document instead, e.g. the example in
>Section 4.3:

Hmm, I think you are confusing terminology here; an URI is not a
relative URL, it is an old term which is supposed to be somewhat more
general than an URL.  The URI can be both absolute and relative, as the
draft says, so your examples below are already allowed.

>
>>Alternates: {"paper.1" 0.9 {type text/html} {language en}},
>>                 {"paper.2" 0.7 {type text/html} {language fr}},
>>                 {"paper.3" 1.0 {type application/postscript}
>
>becomes:
>
>>Alternates: {"http://x.org/paper.1" 0.9 {type text/html} {language en}},
>>                 {"http://x.org/paper.2" 0.7 {type text/html} {language
>fr}},
>>                 {"http://x.org/paper.3" 1.0 {type
>application/postscript}
>
>Using URLs instead of URIs has the significant advantage that it provides
>a simple mechanism for pointing clients to mirror locations that replicate
>the same content. For example, the Internet Movie Database could have an
>"Alternates:" header like:
>
>Alternates: {"http://www.imdb.com/" 1.0 {type text/html} {language en}},
>                 {"http://uk.imdb.com/" 0.7 {type text/html} {language
>en}},
>                 {"http://italy.imdb.com/" 0.7 {type text/html} {language
>it}}
>
>I don't know of any existing mechanism to do replication of this nature
>other than mapping a DNS name to multiple addresses, which doesn't handle
>replicas on sites that are not a part of the same administrative domain
>and does not allow fine-grained replica support.

Nobody ever did a good mirroring system for the web (and managed to
get is deployed), and I would not argue that the alternates
header is a good mirroring mechanism, but as you note it can be abused
to do mirroring.

>I'd appreciate your comments, and thanks.

Thanks for your comments.  Note, by the way, that nobody is currently
working on developing the protocol in draft-ietf-http-negotiation any
further, we are going to take the current version and release it as an
experimental protocol.

>        --Mark

Koen.

Received on Monday, 19 January 1998 01:59:49 UTC