Hallam-Baker, Phillip wrote:
It is equally a layer violation for FTP to communicate IP addresses and
port numbers in the protocol. An application should not know if the
transport is IPv4, IPv6 or SNA.
dream on. in every case where I have worked with an application that
tried to be independent of lower layers, that has failed. there's
always been some need for the application to be aware of the
characteristics of an underlying layer. TCP and SCTP aren't
semantically equivalent because of the lack of urgent data and clean
close, SMTP and lpr over DECnet had to be aware of record-size
limitations that don't exist in TCP, etc.
Keith, while I agree with your general point that applications have no choice
but to be aware of lower layer semantics in many if not most cases, this last
is not a good example of that. There is really no difficulty running SMTP or
any other stream oriented protocol on top of a record-based protocol - all you
have to do is ignore the record boundaries and make sure your buffer isn't
larger than the maximum record size. Not only did our SMTP implementation
require nothing more than a change of low-level network primitives to work over
DECnet, it interoperated fine with several other SMTP over DECnet
implementations back in the day with no need to agree on any sort of additional
semantics.
The converse is not true, however - you cannot simply slap a protocol that
depends on record boundaries onto a stream protocol and expect it to work, such
as MAIL-11 over TCP (not that anyone in their right mind would use MAIL-11 this
way...). Even worse, if you do it what often happens is it appears to work fine
because often as not a TCP write of a given amount of data results in the read
on the other end returning just that data and no more. But look out once you
try your application on a connection with a smaller path MTU than the records
you're passing around.
applications need to be able to log IP addresses, they need to be able
to create referrals to other hosts to the the same protocol engine that
is a TCP peer.
And even if logging weren't an issue, things like SMTP relay blocking are. The
way relay blocking is commonly implemented is to instruct your MTA as to which
IP addresses are "outside" and which are "inside" and allow relay only for
"inside" sources. Of course you can eliminate this need by using mutlple MTAs
in different roles, but not everyone has the hardware available to do this, and
even if they do, all you've done is implement the same policy with cables
instead of a configuration file.
a TCP peer address happens to be an IP address and port
number. adding an extra naming layer and indirection for the sake of
layering purity simply isn't worth it, and the people who tout the
benefits of the extra naming layer (and there are some) tend to
disregard the cost and complexity of providing and maintaining that
layer and dealing with the cases where it fails.
I don't discount the costs, however, I think that sooner or later we're going
to be forced to implement some additional naming services. Whether or not these
need to reuse existing DNS services, use DNS protocols as part of a new
service, or use something other than DNS to build the service is not a question
I'm prepared to answer right now. I know you're strongly against basing such
things on existing DNS services but I'm not convinced this is a bad idea - the
vast existing infrastructure is a fairly compelling point in its favor.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf