W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

Re: New content negotiation draft available

From: Mark Stemm <stemm@cs.berkeley.edu>
Date: Thu, 15 Jan 1998 16:39:59 -0800
Message-Id: <34BEAC5F.460AF949@cs.berkeley.edu>
To: Koen Holtman <koen@win.tue.nl>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, ietf-conneg@imc.org
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? 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.

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:

>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.

I'd appreciate your comments, and thanks.

        --Mark
Received on Thursday, 15 January 1998 16:45:56 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:10 EDT