Response to "On the use of HTTP as a Substrate for Other Protoco ls"

	This following was sent to IETF in response to Keith Moore's
Internet Draft "On the use of HTTP as a Substrate for Other Protocols." [1]
	-Randy
> Individual members of W3C XML Protocol Working Group, listed below, have
> discussed the proposal [1] and have authored the following response. These
> individuals agree in principle with the stated objective of this document,
> to highlight and make recommendations regarding decision points faced by
> protocol designers, working groups, and implementers who are considering
> using HTTP in their work, and offer comments in the sections that follow:
> 	- Mark Baker, Sun Microsystems (mark.baker@canada.sun.com) 
> 	- Henrik Frystyk Nielsen (frystyk@microsoft.com)
> 	- Randy E Hall, Intel Corporation (randy.e.hall@intel.com)
> Input  has been organized according to the key sections of the Internet
> Draft submission.   Note that all of the comments provided herein
> represent those of individuals, and do not represent the official position
> of the W3C XML Protocol Working Group.
> 
> GENERAL COMMENTS 
> The premise on which this draft is based seems contradictory in nature. On
> one hand, HTTP is promoted as an extensible, general-purpose protocol but
> on the other hand the draft recommends against actually using HTTP for
> anything but what can vaguely be described as classic Web browsing based
> on HTTP and HTML." Specifically, the abstract of RFC 2616 begins with: 
> 	"The Hypertext Transfer Protocol (HTTP) is an application-level
> protocol for distributed, collaborative, hypermedia information systems.
> It is a generic, stateless, protocol that can be used for many tasks
> beyond its use for hypertext, such as name servers and distributed object
> management systems, through extension of its request methods, error codes
> and headers. [2]  A feature of HTTP is the typing and negotiation of data
> representation, allowing systems to be built independently of the data
> being transferred."  
> We believe the draft could have gone farther in underscoring design
> choices that must be made when building an HTTP-based application.  By
> stating decisions, HTTP's extensibility features and intended usage could
> be more clearly explained and a loosely coupled, state representation
> model, for which HTTP is designed, could be promoted.
> This could be added as a design question in section 2.5.  Also, section
> 2.2 could include additional detail or design questions that might
> recommend other protocols. The decision criteria should help implementers
> specify or choose the best protocol for use on the Internet at-large and
> one that does not negatively impact other protocols.
> 
> SECURITY
> While XP certainly is to take security into account, it is not within the
> charter of the work to invent new security mechanisms as part of the core
> protocol.   From an HTTP perspective, the relevance of a discussion of the
> limitations of the various security models, which can be used in
> combination with HTTP, to whether or not an application should be written
> as an HTTP application is not clear.  We suggest that issues associated
> with current security implementations, and not directly related to HTTP
> itself, be addressed in the appropriate forums and not in this document.
> 
> PORT UTILIZATION
> Port utilization has been a frequent subject of discussion in our own
> working group.  Section 3 of the Internet Draft under discussion states: 
> 	"IANA has reserved TCP port number 80 for use by HTTP. It would not
> be appropriate for a substantially new service, even one which uses HTTP
> as a substrate, to usurp port 80 from its traditional use. A new use of
> HTTP might be considered a "substantially new service", thus requiring a
> new port, if any of the following are true:  
> 	* The "new service" and traditional HTTP service are likely to
> reference different sets of data, even when they both operate on the same
> host. 
> 	* There is a good reason for the "new service" to be implemented by
> a separate server process, or separate code, than traditional HTTP service
> on the same host, at least on some platforms.
> 	* There is a good reason to want to easily distinguish the traffic
> of the  "new service" from traditional HTTP, e.g. for the purposes of
> firewall access control or traffic analysis. "
> Addressing these in bullet item order, the definitions of "traditional
> HTTP service" and  "new service" are not clear.  It is very difficult to
> characterize HTTP traffic in a meaningful way since every URI is
> potentially a "new service" in some fashion. Using the dataset referenced
> doesn't follow the spirit of the World Wide Web and resources of many
> types can co-exist in similar URI namespaces. 
> Using the codebase or server process model to distinguish whether a "new
> service" is being offered is equally inadequate since it is common
> practice to use a variety of provisioning and coding models to implement
> services. Utilization of dedicated ports to filter services on the Web
> would not address all security issues and would be expensive in terms of
> number of ports in use and enterprise support requirements.  Significant
> reconfiguration of enterprise infrastructure and additional implementation
> and support costs may be avoidable if a layered approach can be used to
> meet security, filtering and support requirements.  Furthermore, it is not
> clear how allocating new port numbers is consistent with the desire for
> limiting use of new port numbers as has been seen in the case of SSL.
> While we do not support the specification of bindings to HTTP for the
> purpose of circumventing firewall policies, if a protocol uses the
> documented application semantics and extensibility features of HTTP 1.1,
> it should not be discouraged from using port 80.
> We agree with the goals of draft-moore-using-http-01, that some uses and
> extensions to HTTP are unsuitable to be used over port 80 and/or with the
> http URI scheme.   The draft does not discuss or provide examples of
> unsuitable uses nor does it acknowledge the fact that it is possible to
> write a tightly coupled, statefull application using HTML and HTTP as-is.
> Rather, it attempts to discuss the problem of application architecture in
> terms of HTTP, which after all is a protocol, not an application.  We
> believe that the draft as written includes at least one fundamental
> misunderstanding of the use of HTTP that makes some of the arguments
> provided, inaccurate.   REUSE OF HTTP OR OTHER URL SCHEMES
> Section 4 of draft-moore-using-http-01.txt states:
> 	"In practice, the URL scheme not only serves as a 'tag' to govern
> the interpretation of the remaining portion of the URL, it also provides
> coarse identification of the kind of resource or service which is being
> accessed."
> HTTP provides no indication of the type of resource or the type of service
> it provides.  In fact, this separation has been one of the guiding
> principles of Web design. Next generation e-Business solutions based on
> W3C XP should not require that a consumer (client) understand the
> implementation details associated with a "new service."  In fact, it would
> be unfortunate if this were mandated since it would undoubtedly hinder
> progress towards a semantic web by forcing additional service negotiation
> requirements on applications.  It also appears that this draft makes
> assumptions of how URIs work rather than actually reflecting the URI
> specification [3] and its description of URI schemes.
> 
> HTTP AS SUBSTRATE
> 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.
> 
> HTTP STATUS CODES
> Section 8 of draft-moore-using-http-01.txt states:
> 	"A layered application may return a 200 response code for both
> successfully processed requests and errors resulting from the request
> message-body (but not from the request headers)" 
> As discussed in the previous section, there appears to be no concrete
> definition of what tunneling is.  Because of this, it is impossible to
> discuss what "error" means in this situation and how it differs from
> "complete failure".
> Also in section 8, the statement 
> 	"Or a proxy may modify the result of a request which returns a 500
> error code in order to add a "helpful" error message"
> 	
> This is neither described as a common, or even legal, operation nor is it
> mentioned that a message can easily be protected against re-write.
> Rather, it is often a mechanism performed by transparent HTTP proxies.
> Nowhere it is indicated that because transparent proxies break HTTP's
> end-to-end model, this is will cause serious problems in HTTP
> interoperability.  It would be nice if there were a statement to the
> effect that transparent proxies cause a huge interoperability problem for
> the Web and additional guidance should be developed to avoid such
> problems.
> 
> SUMMARY
> In general, we would encourage the development and publication of a
> document describing what it means to be an HTTP application, including
> focusing on loosely-coupled, state representation architectures.  A
> document of this type would be very useful in our work, however, the
> current draft falls short of this goal due to the fact that the problem is
> discussed in terms of HTTP rather than in terms of applications using
> HTTP.   We ask that work continue on this document and that additional
> details and clarification be provided in the areas mentioned in this
> discussion.
> [1] Moore, K., "On the use of HTTP as a Substrate for Other Protocols",
> Internet Draft, 16 October 2000.
> <http://www.ietf.org/internet-drafts/draft-moore-using-http-01.txt>
> [2] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)",
> RFC 2324, 1 April 1998.  <http://www.ietf.org/rfc/rfc2324.txt>
> [3] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
> Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
> <http://www.ietf.org/rfc/rfc2396.txt>
> 
>  
>

Received on Wednesday, 6 December 2000 12:51:45 UTC