Re: Multiple Content-Location headers

>  Sender: stef@nma.com
>  From: Einar Stefferud <Stef@nma.com>
>  Date: Thu, 15 Jan 1998 16:51:09 -0800
>  To: Jim Gettys <jg@pa.dec.com>
>  Cc: Jacob Palme <jpalme@dsv.su.se>, Nick Shelness <shelness@lotus.com>,
>          IETF working group on HTML in e-mail <mhtml@segate.sunet.se>,
>          http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>  Subject: Re: Multiple Content-Location headers 
>  
>  Hi Jim -- 
>  
>  I hope the garbling of all that included text was an accident;-)...  I
>  was gretly revlied to discover that there were no comments inserted
>  there-in;-)...  (I trust such garbelling is not considered to be a
>  useful feature of WEB Mail UAs;-)...
> 

I did mention in a previous message I was using an EXPERIMENTAL mail UA. :-).

I had hit the "wrap" button to rewrap a paragraph that Pachyderm has, and 
it did the wrong thing.  I manually undid the damage I saw, but it did alot 
more than I saw (I didn't scroll the window back far enough).

 
>  Next, I think we may be out of synch in the discussion.
>  
>  MHTML folk almost immediately gave up on the ideas of allowing
>  multiple Content-location headers, or of giving them multiple
>  values...  
> 

OK, great. I think I may have added the discussion to the HTTP issues list 
yesterday; I'll go mark it closed then.  

>  This is no longer any kind of an issue between HTTP and MHTML!!!!
>  We are now looking for two other new things:
>  
>  1.  Are there any other gotchas lurking in the HTTP/MHTML wood pile
>      that we have not noticed before, since all us woodpile residents
>      would like to avoid all possible hidden gotchas???

Probably.  The problem is finding people who really understand both
to go over the specs looking for trouble.  I know I don't have time
to catch up on MHTML at the moment, in the push to get to draft
standard, and due to personal events that have reduced my available time.
If there are people who could go looking for trouble it would be
very good.  Sooner rather than later, for both our sakes...

>  
>  2.  Can we use the new idea articulated by Nick Shelness to use a new
>      Content-Label header, or allow a new Content-Alternate-Location?
>  

Yes, though try to keep the header names short.  There is an important
difference between HTTP and mail that many overlook; HTTP is real time,
and each byte adds to user latency (and reduces operations per second).
Mail is store and forward, and not latency sensitive.

Clearly for this kind of application, allowing multiple values on a single 
header reduces the overhead of the header name.  This is usually preferable 
than multiple headers.  (We had real trouble with naive implementations 
of Accept headers early in the Web listing each content type one per header, 
compounding the number of bytes sent by a good factor, and causing lousy 
interactive "feel"); ergo the language to allow a proxy to "undo" the
damage somewhat.

Don't go overboard on this recommendation, but bear it in mind.  It is
one more area where HTTP has different requirements than mail.

>  I think MHTML is leaning toward Content-Alternate-Location, but lets
>  consider both in looking for gotchas.
>  

As you look at this problem, you should understand the need HTTP has for 
what we call "Alternates".  

The issue in HTTP is that there may be multiple representations for an object 
(different languages, content types, etc.).  A request returns only one 
of these.  But the client is the only place where you fully understand what 
the application is, and you'd like to know of alternate representations. 

A good example is that you are looking a web page for which there is both 
HTML and Postscript and Acrobat available (the Postscript is probably higher 
quality, as well). If you are about to print a document, you'd like to know 
that there are these other representations available.  

I think the HTTP working group has consensus on the need for Alternates, 
though I don't think the exact details have been finalized. So besides the 
document URL, you need other information: e.g. type, size (so you can figure 
out how long it will take to download), maybe some quality metric. 

It isn't clear that MHTML and HTTP needs will exactly match, but
you should be aware of it anyway.
				- Regards,
					Jim
--
Jim Gettys
Industry Standards and Consortia
Digital Equipment Corporation
Visting Scientist, World Wide Web Consortium, M.I.T.
http://www.w3.org/People/Gettys/
jg@w3.org, jg@pa.dec.com

Received on Friday, 16 January 1998 08:54:34 UTC