Re: [schemeProtocols-49] New draft of proposed "URI Schemes and Web Protocols" Finding

Mark Baker writes:

>> With this approach the existing http URI would be used, but clients 
that support more video-friendly application protocols would advertise 
that fact via the HTTP Upgrade header in their GET request ("Upgrade: 
VIDEO/1.0"). 

Excellent point Mark.  If the rest of the finding meets with sufficient 
support to move ahead, I'll include this.  I do note some limitations on 
"Upgrade" in RFC 2616 [1]:

"The Upgrade header field only applies to switching application-layer 
protocols upon the existing transport-layer connection."

[...]

"The Upgrade header field only applies to the immediate connection."

So, HTTP Upgrade seems to make sense only if the Video protocol is going 
to use the same transport-layer connection.  Interesting question: should 
the application invoking HTTP know or care what connection(s) the Video 
protocol might use?  Likewise for a P2P protocol?  Why indeed should the 
application know how how many transport-layer connections HTTP is using?  
In the case where the application is likely to know that the same 
connection will be used, then I agree that Upgrade is a good option.

"The Upgrade header field cannot be used to indicate a switch to a 
protocol on a different connection. For that purpose, it is more 
appropriate to use a 301, 302, 303, or 305 redirection response."

Hmm.  Seems to imply some preference for using a separate URI when new 
transport-layer connections are likely to be involved.  I'd still like to 
believe that the media-type approach is also a good one.

Noah

[1] http://www.faqs.org/rfcs/rfc2616.html

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Mark Baker <distobj@acm.org>
Sent by: mbaker@gmail.com
11/23/2005 08:55 PM
 
        To:     "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>
        cc:     www-tag@w3.org, uri@w3.org
        Subject:        Re: [schemeProtocols-49] New draft of proposed 
"URI Schemes and Web Protocols" Finding


This is good stuff, Noah.

I haven't had time to do a full review yet, but one thing I noticed early 
on in section 3.1 was that an (IMO) valuable approach wasn't mentioned; 
protocol upgrading.

With this approach the existing http URI would be used, but clients that 
support more video-friendly application protocols would advertise that 
fact via the HTTP Upgrade header in their GET request ("Upgrade: 
VIDEO/1.0").  The server would then be free to switch if it was able using 
the 101 response, or could ignore it and continue to do video-over-HTTP, 
or just plain old XHTML.

As if the scheme/protocol relationship wasn't complex enough! 8-)

Cheers,

Mark.

On 11/21/05, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com > 
wrote:

I have promised the TAG that I would prepare for our upcoming F2F a 
position on where to go with issue schemeProtocols-49 [1] (see action at
[2]).   This note is to announce that I have prepared a significant
revision to the draft finding on "URI Schemes and Web Protocols" [3], and 
I propose that we use it as the basis for our discussions at the F2F. This
draft attempts to synthesize the many important bits of input that I've
received since offering the initial draft last June (the June draft is at 
[4]).

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com

Received on Monday, 28 November 2005 16:35:22 UTC