From: Sam Hartman [mailto:hartmans-ietf(_at_)mit(_dot_)edu]
"Robert" == Robert Sayre <sayrer(_at_)gmail(_dot_)com> writes:
Robert> On 9/5/06, Sam Hartman <hartmans-ietf(_at_)mit(_dot_)edu> 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf