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
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5195
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

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}


>Alternates: {"http://x.org/paper.1" 0.9 {type text/html} {language en}},
>                 {"http://x.org/paper.2" 0.7 {type text/html} {language
>                 {"http://x.org/paper.3" 1.0 {type

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
                 {"http://italy.imdb.com/" 0.7 {type text/html} {language

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.

Received on Thursday, 15 January 1998 16:45:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC