Subject: RE: Last Call: 'Procedures for protocol extensions and variations'to BCP (draft-carpenter-protocol-extensions)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 5 Sep 2006 14:11:12 -0700

> From: Sam Hartman [mailto:[email-masked]] 
> >>>>> "Robert" == Robert Sayre <[email-masked]> writes:
> 
>     Robert> On 9/5/06, Sam Hartman <[email-masked]> wrote:
>     >>  There are a lot of complexities--for example while we hope
>     >> every IP stack works with every other IP stack, two machines
>     >> may not share a common upper-layer protocol or application
>     >> protocol.
> 
>     Robert> I worry that such text will encourage sprawling
>     Robert> specifications that make requirements across many
>     Robert> layers. I think the example you give is a little
>     Robert> misleading, since it can be harmful for specifications to
>     Robert> make requirements on lower layers as well. For example,
>     Robert> HTTP requires a reliable transport, but I think it's good
>     Robert> that RFC2616 does not include text like "HTTP
>     Robert> implementations MUST support TCP/IP, but may support other
>     Robert> transport protocols".
> 
> 
> To be clear, I think I'm documenting what is a long-standing 
> consensus in the IETF.  And I do consider it a bug that HTTP 
> does not require TCP.  It's typical for protocols to require 
> a transport.  For example , I believe SIP requires UDP (and 
> possibly TCP).  Kerberos requires TCP.

At the time that the HTTP spec was originaly written a significant proportion of HTTP traffic went over DECNET-IV and there was an expectation of support for OSI and DECNET-V.

It is not possible to layer HTTP directly over UDP, although there are HTTP like schemes that do run on UDP. The statement was intended to exclude UDP but not exclude then existing use on other networks.

Today there are no other networking protocols of any significance a fact that is largely the result of the interaction between HTTP and DNS. There is no expectation that this will change in the forseable future and if it were to change there are more things that are likely to require fixing in HTTP than in TCP.

I think that it is both acceptable and even good practice for a specification to clearly set out the expectations it has of both lower and upper levels in the stack. It is good to see these set out in abstract terms 'MUST be reliabile' in addition to specifying protocols that satisfy these requirements 'MAY use TCP/IP'

What is very bad practice is to define a dependency on layers other than those that the protocol is adjacent to. A protocol that is layered on SOAP is layered on SOAP not SOAP/HTTP. A protocol that is layered on TCP should not be dependent on IPv4 and so on.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf