> From: Keith Moore [mailto:moore@xxxxxxxxxx] > > We are currently seeing an explosion of new protocol > development using > > Web Services. It is long past time to declare UDDI a failure and > > recognize that it isn't going to happen. But Web Services are > > predicated on the existence of a signaling infrastructure. > > if SRV works well for Web Services, fine, but that doesn't > mean SRV is appropriate for everything. and as far as I can > tell, DNS is poorly suited to be an application signaling > infrastructure. I don't expect there to be very many standards based protocols in the future that are not Web Services. Angle brackets are now as inescapable as ASCII was twenty years ago. The only real design choice is whether to layer on SOAP and WS-* or to layer directly onto HTTP and SSL. The point here is not to 'use DNS' but to 'involve DNS'. We are agreed that you certainly do not want to put every possible piece of protocol configuration data into the DNS. This is particularly the case in Business 2 Business Web services where you want a really strong bilateral connection and thus a 'fat handshake' is really appropriate (think the purchasing dept of Ford Motor Co talking to TRW). The point is that if you use a DNS Domain Name as the index you want to use the DNS as part of the distribution mechanism. In simple cases this may be call by value but in cases with more than 64 bytes worth of complexity you really need to think about call by reference. Storing pointers to policy in the DNS means that the DNS remains the one authoritative source for DNS information. There are three levels of policy 1) Trivial 'I always sign with DKIM' We could put a pointer to the policy distribution in the DNS but the policy is essentially only a boolean. 2) Complex Static 'I support WREURF 1.2 through 2.4.3, I support WREURF 1.0 through 1.1.2 on a deprecated basis and will withdraw support on 2006-12-25, you must use AES-256 with SHA-3242b...' We could define an escape mechanism to encode several kb in the DNS but this would be a bad idea. I think that SPF is more complex than I would like to see policy for in DNS but not objectionably so. Write an XML document describing the policy, put the link to the policy in the DNS. This has the additional benefit that the policy can be updated without reference to the DNS. 3) Complex Dynamic/Context Dependent 'Alice can use protocol X, Bob can use protocol Y' This level of policy is certainly desirable but the DNS is certainly not the protocol to use whether on the same port or a different one. Write a Web Service and put a pointer to the service in the DNS. The point about using the DNS to distribute the location information is that it ensures that when example.com changes hands that ALL the services associated with example.com do as well. Using prefixed policy and SRV records rather than host names is important because what we care about is the services not the hosts that happen to be supporting them at one point in time. The hosts will change, possibly dynamically. The services the hosts provide are persistent. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf