- From: Hall, Randy E <randy.e.hall@intel.com>
- Date: Wed, 6 Dec 2000 08:40:35 -0800
- To: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
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