RFC 3205 background (HTTPSubstrate-16)

A couple of people mentioned to me that 3205 was under discussion here;
I thought I'd send a note to try to give some background and rationale
and context that might not be clear from the document.

RFC 3205 was first drafted at a time when several groups in IETF were 
proposing to use HTTP as a substrate for special-purpose protocols.  
It was clear that few of those groups understood the consequences of
that design choice.  Most seemed to be hoping in vain that by simply 
saying "we will layer our protocol over HTTP" that this would 
automatically produce a protocol of adequate quality, performance, 
security, etc. and which would magically work through firewalls.
Few of them had bothered to look at the actual details of how to make this 
work or what the implications would be for network operators or users. *

RFC 3205 is mostly an attempt to draw up a list of things that protocol 
designers need to think about when considering whether to use HTTP
as a substrate for a standard protocol.  Most of the document is 
intended to inform protocol designers, rather than to constrain them.  
The few hard-and-fast prohibitions in the document (such as on the
use of port 80) are there because they was felt necessary to make
very clear policy statements on these issues.

The intended audience for the document was IETF working groups, and 
more generally, other groups or individuals defining protocol standards.  
The emphasis here is on *standards*, implying that there's an expectation 
that the protocol will be widely implemented and widely used.  The 
prohibitions aren't intended to apply to private networks,
enterprise-specific applications, or to bilateral agreeements between 
consenting parties.  So by extension I would say that the prohibitions 
weren't intended to apply to most of the things called "web services", 
though in the case of a particular web service that became so popular 
that nearly every site or host were expected to provide it - under
those circumstances the prohibitions, and the logic behind them, would 
be more applicable. 

As for use of port 80: Traffic monitoring by port # is useful, even 
if it's imperfect.  The same can be said of firewalls that filter traffic 
based on port #.  I like to say that firewalls don't actually provide 
any security assurance by themselves but they can dramatically reduce 
the # of applications that you have to analyze in order to have some 
assurance of security.  If a wide variety of applications use port 80, 
the analysis becomes more difficult - a network admin can no longer 
ask him/herself "which machines are allowed to run web servers?" but 
instead has to allow for the possibility that each machine can run one 
*or more* services over port 80 - each of which needs to be analyzed 
separately.  Granted that there aren't enough port #s available to 
assign one to every single application, but there are plenty of port 
#s to assign one to each standard or widely-used service.  I fully 
agree (and so would everyone on IESG) that sites should not rely on 
port filtering to provide security, but there's a difference between 
relying on port filtering and using port + address filtering as a way 
to restrict the number of application servers which are capable of 
accepting input.

I admit that "traditional use of HTTP" is imprecise language, and I
want to clarify that it wasn't intended to mean that HTTP or its
uses should not evolve.  The net, and most of its protocols, have 
been evolving continuously for the past 20+ years, and I don't 
see why HTTP should be an exception.  By "traditional use" I was 
trying to anticipate the needs of network admins who would want
to distinguish a new protocol from HTTP (as they understood it)
for the purpose of filtering and traffic analysis.  If HTTP over 
port 80 came to be used in so many different ways that a network 
administrator couldn't make any assumptions at all about the nature 
of the traffic - not even coarse assumptions - then this would be 
unfortunate, and IETF doesn't want to encourage things to evolve 
in that way.  On numerous occaions it's been useful to be able to 
make some coarse differentiation of traffic by looking at port #s,
and we don't want to see this functionality lost.

I hope w3c people don't find this insulting, but I must confess that I 
see HTTP is the be-all and end-all of network protocols.  But I'm happy 
that people can use HTTP to build web services, because this makes 
the network much more useful to users.  I'm constantly fighting the 
notion that the only networked applications that matter are those that 
everyone uses.  There are thousands of applications that are important 
to some set of users even if none of them individually ever consume a 
large portion of the bandwidth - and the aggregate importance of these 
applications is tremendous.  So to the extent that HTTP helps people 
get more use of the network, because it was good enough for their 
purposes, I think that's wonderful.

And yet there are clearly numerous application spaces for which HTTP
would be a poor choice - either because of the nature of HTTP itself
or because of the characteristics of the infrastructure that was deployed
to support HTTP.  For that matter, it's also clear to me that TCP
could be vastly improved or replaced (to be able to piggyback payload, 
and probably even security negotiation, on connection setup - and get 
much better latency than the typical TCP/SSL/HTTP layered negotation, 
along with better bandwidth utilization for short transfers.  And these 
things have implications for the cost of running services and networks, 
and I'd like these to be as low as possible.   So I think there's a 
need for lots of other layer 7 protocols besides HTTP (and a few at 
layer 3 besides TCP), and that we're going to find better protocols in 
the future, and so on.  At the same time, people won't change protocols 
unless there's a significant benefit to the new one.  So people will 
be using HTTP, and SSL, and TCP, for a long time.  And that's fine too.

But because I see the need for diversity, I don't think of "the web"
as having much to do inherently with HTTP - not even as a negotiation
mechanism, because it's clear to me that if we're going to have a
universal negotiation mechanism, it needs to be much lower overhead
than HTTP.  (e.g. it shouldn't require a TCP connection setup - that 
adds too much delay).  So to me a document that tries to explain some 
of the consequences and considerations of using HTTP to support some 
application's higher-layer protocol doesn't restrict "the web" in any
way.  I realize other people have different views, but in the long
run it's what people do with the network that matters - not the view
of any particular person or organization.  

Regarding the criticism of a draft of RFC 3205 by the XML Protocols WG,
I did write a response to this, and I also made some changes to the 
language in the RFC based on that input.  Since I received the criticism 
"through channels", I sent the response through channels also, and
I think it must have been dropped somewhere.  I'm sorry that this happened.
In hindsight, I should have cc'ed the authors directly.  I could probably 
find that response if anyone is still interested.  One thing which I do 
recall: there was a suggestion that the document should explain *how* to 
layer a protocol on top of HTTP, rather than saying what not to do.  That 
wasn't really the intent of my document, but I do think that a document 
that described *how* to use HTTP as a substrate (for those cases where it's
a reasonable thing to do) would be quite useful and very welcome.

Keith


* Often HTTP was not a good choice for their applications; sometimes it
was defensible.  e.g. IPP went down the HTTP path - mostly for firewall
compatibility- and as a result had a difficult time accomodating
features that didn't fit the typical model of how HTTP is used -
such as notification that the print job is completed.  This 
isn't an inherent problem with HTTP so much as a conflict between
the needs of IPP on one hand, and the way that sites configure their
networks to support HTTP (clients inside the firewall talking to 
servers outside the firewall) on the other.  I understand why they 
made their design choice to use HTTP and at the time I thought it was 
defensible. But in hindsight it appaers that they would have been 
better off to start from scratch and not to try to make IPP work
with existing HTTP infrastructures.  Again, the problem here is not 
the HTTP protocol itself - clearly they could have had each client run 
an HTTP server for the purpose of accepting notificaitons - but their 
decision to rely on infrastructure that had been deployed to 
support HTTP, even though that infrastructure has very different 
assumptions about the flow of data than are appropriate for printing.

Received on Tuesday, 2 April 2002 15:05:39 UTC