Re: [HTTPSubstrate-16] Propoposed criticsm of RFC3205

On Fri, Feb 07, 2003 at 06:37:20PM -0800, Larry Masinter wrote:
> HTTP was designed for a class of applications.
> Other applications which have very similar requirements
> for latency, transaction semantics, security, error recovery,
> communication of options, client and server capabilities, etc.,
> might well fit as "reasonable" to layer on top of HTTP.

This reminds me of a point that Henrik Frystyk-Nielsen, Randy Hall, and
myself, made[1] to the IESG prior to the publication of RFC 3205; that
the document didn't define what it meant by "substrate".  This is
particularly (and topically) problematic since, for example, I don't
consider the SOAP 1.1 or 1.2 specifications to be using HTTP as either a
substrate or a layer (although most SOAP developers use it in this way),
so it's not clear what portion(s) of 3205 is applicable to SOAP or
developers using it.

The relevant text from our response is;

] There appears to be an undefined assumption of what tunneling is. Nowhere
] is the term "substrate" actually defined nor what it means to write an
] application using HTTP as a substrate. One simple indication of the
] confusion is that HTTP is expanded as "Hypertext *Transport* Protocol" and
] not "Hypertext *Transfer* protocol".  The result of this undefined
] assumption is that the draft describes tunneling as a property of the
] protocol being tunneled through rather than as a property of the
] application, which for some reason cannot or does not want to express its
] parameters in the language of the protocol being tunneled through.

I believe this point needs to be addressed before meaningful discussion
can happen around the other points, so I'd suggest that it be addressed
first.

My preferred resolution would be that it be recognized, as the last
sentence of that snippet says, that tunneling is a property of the
application.

 [1] http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0061

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Saturday, 8 February 2003 17:36:42 UTC