Hi, Keith,
On 9/12/2011 1:42 PM, Keith Moore wrote:
On Sep 12, 2011, at 4:22 PM, Joe Touch wrote:
On 9/12/2011 1:15 PM, Keith Moore wrote:
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
On 9/12/2011 11:41 AM, Keith Moore wrote:
I think at this point we're just talking past each other, but I
simply disagree with your assertion that RFC 2782 should be taken as
a prohibition on using SRV RRs in any way other than defined in RFC
2782.
It might be useful to explain to this list what you think a spec means, so we can understand what you think it means to comply with a spec.
I think RFC 2782 inappropriately specified SRV RRs by defining both the label syntax and the RDATA syntax at the same time.
How is that different from every other RR except TXT?
Most RRs tie some set of data to a domain name which is historically
a host name, though in recent years it's become a somewhat more
nebulous concept (e.g. "a collection of services", or in the case of
MX records "a collection of recipient mailboxes"). SRV is odd in that
it overloads the domain to include "service name" and transport
protocol.
Yes - it was defined that way.
Part of the problem with the way SRV is defined is that often,
"service name" (in the sense of something that's tied to port number,
is not what the application is looking for). Another part of the
problem is that "transport protocol" is often not appropriately part
of the query - it's something that the application needs to know,
rather than something the application should provide when doing the
query.
Yes - this has been a persistent problem in the IANA service/port registry.
Here's where we are today:
service = L5-L7 inclusive
transport = L4
It would be useful to have a richer way to describe services, which
could include:
- late-binding of transport (or even network)
- layering of protocols
e.g., CMD-over-SOAP-over-HTML-over-SSL
- out-of-band service bootstrap info
- richer descriptions of service variants
that support richer searches than DNS supports
Any of these requires an overhaul to the IANA notion of services and
port numbers, as well as SRV records.
SRV appears to have been designed with the idea that the DNS was a
good place to advertise port numbers of services, and that it would
make sense to have a standard mechanism to advertise alternate port
numbers that would work across all applications. For a wide variety
of reasons, this is not a good idea. But because SRV already exists
and is deployed, and we occasionally find applications that need
something similar to SRV, people keep trying to use it in ways that
are contrary to its design.
Port numbers are inherently meaningful only between pairs of consenting
endpoints. The ability to indicate the local map of service:port seems
entirely appropriate in an E2E sense. Further, it avoids the burden of
pre-allocating port numbers (a quite constrained resource) for services
that might never be used at a given endpoint, and allows that map to be
assigned dynamically and locally.
Consider that the DNS distributed /etc/hosts, and basically SRVs
distribute /etc/services
Or would your arguments against SRV use also apply to the DNS? :-)
If DNS were easier to extend - in particular if RR types weren't
limited to small integers but rather something like OIDs, and if the
format of RDATA weren't hard-coded into DNS servers - I'd absolutely
agree that the thing to do would be to deprecate SRV for new
applications and define new RR types whenever needed.
OK. So basically you claim that new RR types are bad because they are
defined in a way that doesn't do what you want.
But then you want to change SRVs - for the same reason you don't want a
new RR type.
Again, I remain confused as to your position.
My claim is that:
SRVs represent services as they are currently assigned by IANA
a new RR could be useful for things that aren't sufficiently
expressible in the IANA service/port registry
Joe
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf