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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

noah_mendelsohn

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

Acting on advice from Dave Orchard and others, the new draft opens with
some hypothetical scenarios.  These are intended to serve two roles: (1)
to address concerns raised by Dan and others who asked whether the finding
is addressing problems users will care about today, and (2) to illustrate
the application of the normative parts of the finding, which are captured
in later sections the form of rules and guidelines.

As I dig more deeply into these issues, I am increasingly convinced that
there are important and subtle problems on which users of the Web need
guidance.   So, I think we should do a finding in this area.  The prose in
this draft will surely require polishing and tightening, and I expect
there will be debate on the technical points, but I hope I've made some
progress in getting closer to the essentials that we need to convey.  I
suggest that in anticipation of the F2F, discussion be held on
[hidden email].  Thank you.

Noah

[1] http://www.w3.org/2001/tag/issues.html#schemeProtocols-49
[2] http://www.w3.org/2001/tag/2005/03/action-summary.html
[3] http://www.w3.org/2001/tag/doc/SchemeProtocols.html
[4] http://www.w3.org/2001/tag/doc/schemeProtocols-2005-06-16.html

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





Reply | Threaded
Open this post in threaded view
|

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

Mark Baker
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, [hidden email] <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

noah_mendelsohn

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 <[hidden email]>
Sent by: [hidden email]
11/23/2005 08:55 PM
 
        To:     "[hidden email]" <[hidden email]>
        cc:     [hidden email], [hidden email]
        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, [hidden email] <[hidden email] >
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


Reply | Threaded
Open this post in threaded view
|

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

Mark Baker
On 11/28/05, [hidden email]
<[hidden email]> wrote:

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?

Yes, I think so.  If VIDEO required, say, two UDP streams instead of a single TCP connection, then the client shouldn't use Upgrade to negotiate for its use.

  Likewise for a P2P protocol?  Why indeed should the
application know how how many transport-layer connections HTTP is using?

So that it can use Upgrade? 1/2 8-)

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