From: Keith Moore [mailto:moore(_at_)cs(_dot_)utk(_dot_)edu]
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf