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.
well, mumble. you still get into interesting boundary cases when, for
example, an application reads a zero-length record from a record-based
source that it wants to treat as a stream, and interprets the
zero-length read as end of file. I suppose that's an API issue rather
than a protocol issue, but the API differences are consequences of the
underlying protocol differences. practically speaking, the code nearly
always has to have been written with awareness of the lower layer(s) its
going to be used with, before it can be expected to work reliably.
sometimes you can isolate that awareness to a protocol-specific
adaptation layer, sometimes not.
(in running lpr over DECnet, I seem to recall that one of the problems
was that DECnet has no way to shutdown one end of a connection will
keeping the other end open, so some sort of protocol change was
necessary to make this work.)
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.
if the only tool you have is a hammer...
basically I think if we're going to bother adding an extra layer of
naming, it had better work a hell of a lot better than DNS. between
widespread misconfiguration and lots of lame hacks like DNS-ALG and
multifaced DNS, not to mention ambiguities in how DNS APIs interface
with things like LLMNR and proprietary name lookup services, and fairly
poor reliability, we need to be thinking about how to replace DNS rather
than how to add yet another layer that depends on it. IMHO.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf