Right, the DNS is no longer providing mere hostname mapping and host discovery, it is providing service mapping and service discovery.
dcrocker@xxxxxxxxxxx does not connect to an IP address, the outgoing email server first attempts to resolve MX records.
What we are discussing here is architecture, that is not just about solving the problems of today, it is looking forward to the problems that are emerging today and will be worse over time. Questions such as performance are really not very relevant. It is very easy to over-optimize for the current network and use and foreclose better ways of solving problems.
If resolving service endpoints is your biggest performance concern, you probably don't have a performance concern.
Is the current situation entirely ideal? Certainly not, or else there would be no work to be done. We have a lot of pieces but no integration between them. DHCP and DNS are only sometimes integrated. If we had an architectural statement we could make that a much stronger assumption.
Another, bigger problem is that the IETF/W3C split has led to a situation where we don't have so many of the application developers here. Now in Web Services land they have a model, but the original model had a box labeled UDDI which clearly is not going to happen. So now we (apps folk) have a bunch of bubbleware, an abstraction without a specified reification as protocol. And there are slight differences in each instantiation.
OK we now have two standards orgs producing platform, but we can only have one Internet architecture. And the bigger problem here is that instead of arguments being followed through to a conclusion, each camp can retreat to its own tent. And the discussion never gets finished.
Case in point here being the question of whether schema URIs should be URLs or URNs. The arguments made by both camps are true. But instead of developing an architecture that resolves both sets of requirements W3C does things one way and IETF another.
I know IETF thinks IP is the center of the universe and the one true religion. But not in process control it is not. A PIC controller comes with 384 bytes (BYTES, not kilo) of RAM. Good luck getting an IP stack in there. And even if you use a bigger processor with a built in TCP/IP stack you can only run it over Ethernet type media. You can't use RS485 which looks a much better bet for hardwired home automation systems to me, it is what process control has used for decades.
What I think we need here is for IETF to construct a service discovery architecture. By this I mean the mechanism that all future protocols MUST support and the one mechanism that all future network layer protocol changes will be required to support. Protocols can do whatever they like in addition. And then the IETF needs to convince the W3C and OASIS architecture boards to make this a requirement at their end. And this needs to be through negotiation, not a diktat.
And the W3C needs to come up with a framework for device and service description that works in that service discovery architecture and sell it to the IETF. This will involve lots of angle bracket thingies but essentially it is a MIB for applications.
-----Original Message-----
From: ietf-bounces@xxxxxxxx on behalf of Dave CROCKER
Sent: Mon 12/1/2008 12:05 AM
To: John Day
Cc: Keith Moore; ietf@xxxxxxxx
Subject: Re: The internet architecture
John Day wrote:
>>
>>
>> Please elaborate. I agree that the current resolution protocol is not
>> perfect but what is wrong with the semantics of domain names?
>
> As we have known since the early 80s, naming the host has nothing to do
> with the problem at hand. It is sloppy and gets in the way of getting
"The problem at hand" is what, exactly? Concretely and specifically.
> it right. Currently, domain name is a synonym for an IP-address. The
> IP-address names the interface and is largely redundant since the MAC
> address does the same thing.
Ignoring, for the moment, that a domain name does not always map to an IP
Address, nevermind that it often maps to a set of them, the fact of mapping is
not quite the same as being "synonymous". It can be -- and often is --
equivalent to find a path to the named resource. A path is not a synonym.
www.example.com is a common name for the an organization's online web presence.
That sort of description of the name is quite different from the mechanical and
narrow simplicity of a host name or a synonym for a *set of* IP Addresses that
might refer to a single machine or to multiple.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf