> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf