Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata

[Stephen J. Turnbull]

>>>>> "Paul" == Paul Snively <address@hidden> writes:

    >> (2) My guess is that the DNS TXT record is just plain dead in
    >> the water.  Why?  Because many DNS implementations are
    >> restricted to 512 (yep, you can count 'em on your fingers if
    >> you're a centipede) _bytes_ of returned data.  So what you're
    >> suggesting surely requires multiple trips to the well.

    Paul> This is addressed in section 6.2 of
    Paul> <http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt>. Certainly
    Paul> most URLs fit nicely in 512 bytes or less.

You're missing the point.  DNS is designed (except for zone transfers)
to return _all_ necessary information in _one_ packet.  That's a
minimum of the DNS overhead, a SRV record, and an A or AAAA record,
say 128 bytes.  But RFC 2782 gives a simple example (one service, two
primary hosts, two backup hosts) which adds up to 365 bytes already.
So you're down to about 140 bytes to share among several DNS TXT
records.  This is starting to look tight:

ARCHIVE-URL=http://@/~lord/{archives}/address@hidden
ARCHIVE-URL=http://@/~lord/{archives}/address@hidden

is 113 bytes right there, plus string overhead, even compressing the
host out (ie, by referring to the query section of the reply).  Note
that (at least at some point in history) you could not check out a
full copy of the current arch without access to both archives.

Note that Cheshire et al recommend keeping a DNS TXT record to _less
than 100 bytes_!  So my example, although obviously incoherent because
it comes from a somewhat different problem, is not at all inconsistent
with what the authors are thinking themselves.

    >> is about _backward compatibility_.  New protocols SHOULD NOT
    >> depend on it.

    Paul> This is far too strong.

Don't tell me, tell Cheshire et al.  The words SHOULD NOT when
capitalized in an RFC have specific meaning.  I didn't introduce them;
Cheshire et al did.

    Paul> earlier, in section 6. we find:

    Paul> "Similarly, a file server may have multiple volumes, each
    Paul> identified by its own volume name. A Web server typically
    Paul> has multiple pages, each identified by its own URL. In these
    Paul> cases, the necessary additional data is stored in a TXT
    Paul> record with the same name as the SRV record."

Those are different in kind from arch.  It is possible to get that
information without use of DNS-SD.  Without that information you
cannot find an arch archive, but Cheshire et al specifically say a
discovery protocol SHOULD NOT depend on that information.

    Paul> if you have an alternative suggestion that addresses the
    Paul> process that you described so well,

What's wrong with the suggestion I made, of standardizing on a
directory service which is pointed out by the SRV record for arch?
You're all hung up on this exciting proprietary technology which may
or may not be standardized and whose current formulation specifically
deprecates the elegant approach you suggest.

On the other hand, if we use my suggestion, then (a) we conform to
current RFCs and drafts and can implement _and deploy_ _now_ and (b)
since DNS TXT records are proposed as an auxiliary discovery method,
there is nothing to prevent us from adding them immediately on an
experimental basis for those who want them, and then later deprecate
the original method when DNS TXT records are promoted to Best Current
Practice.  Finally, if the auxiliary service is well-known (such as
LDAP), then it can be easily deployed at sites that don't implement
DNS SRV records yet.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.