On Wed, 2004-04-21 at 12:05, John Peacock wrote:
> That text I quoted points to a specific problematic implementation; the current
> RFC2782 (Feb 2000) _prohibits compression_ of SRV records, RFC2052 (Oct 1996)
> _mandated_ it, and some servers following that earlier specification are still
> in use.
This is not a practical issue.
The history of this situation is: during part of the 1990s, a number of
new record types were specified as containing possibly-compressed domain
names, which isn't compatible with old resolvers. RP, AFSDB, RT, SIG,
PX, NXT, NAPTR, and SRV were affected by this error. AXFR
implementations also tended to blow out when they saw unrecognized RR
types.
In the past few years, more attention has been paid to this problem, and
new record types are barred from compressing domain names. When SRV was
respecified, it reflected the new discipline. Because there exist
implementations of the old experimental SRV specification, RFC 3597
recommends that resolvers know how to uncompress domain names in SRV
records. And they all do.
> > And about the widelyness, I know Windows 2000 uses SRV records
> > everytime it can...
>
> OK, that's one then (and yes I was already aware of it). I also happen to
> believe that M$loth's implementation of DNS records in this instance is an abuse
> of the core protocol.
Both of these statements confuse me. What does it mean to use SRV
records "every time you can?" And why is this an abuse of "the core
protocol?"
> > The SRV implementation is also in the TODO list of
> > projects like KDE and Mozilla, and there's already some SRV code in the
> > GNOME CVS.
For what?
> And that's zero more. There are plans, there are TODO entries, but there aren't
> other large projects which support it today (some 8 years after the RFC was
> ratified). It was a good idea which failed the test of actual usage in the wild.
There are several problems here, beyond your folding of Pierre's
comments into "plans [and] TODO entries" when there appears to also be
mainline code.
First, RFC 2052 is experimental; that is not a "ratification". RFC 2782
(four years old) is a Proposed Standard, which is more or less a
ratification.
Second, independent of the time frame, your usage expectations are
overblown. The point of SRV is to allow protocols to have an MX-like
record without a new type code for each protocol. The intent is not to
have implementations of existing protocols (like HTTP) suddenly start
using SRV, unless the protocol community wants to specify that.
A handful of protocols use SRV records. None of them are going to look
impressive because no new protocols have developed a great deal of
mindshare ever since firewalls became de rigeur. SIP and Kerberos are
the best examples I know of.
> In addition, the Subversion client would be required to link to a resolver
> library to make use of this feature. Right now, the client merely requests the
> IP address associated with a name, then opens a connection to the requested port
> on that address. Implementing SRV would require yet another platform
> independent library to resolve the chain of SRV records.
SRV records don't form a chain.
I'm also a bit skeptical that SRV support could be implemented in a
manner acceptable to us, but I wouldn't totally rule it out.
I'm also skeptical that many people would find SRV support useful at
this time. SRV's primary usefulness is replicating a service among
multiple servers. You can replicate an SVN server for read-only access,
but it's kind of hackish and I doubt many people do it. SRV is also
useful for redirecting a service to a different domain (in the same way
that MX allows you to have mail service and web service at the same
domain without running an SMTP and HTTP server on the same machine), but
that's kind of a marginal justification; people just aren't going to
mind advertising svn://svn.foo.bar/ instead of svn://foo.bar/ for
version control access.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 21 19:03:46 2004