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

[Stephen J. Turnbull]

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

    Paul> I'd read it before, but not for some time, so took the
    Paul> opportunity to read it again. While it's certainly a
    Paul> stirring indictment of the Gnutella protocol, it's far from
    Paul> clear what this has to do with mDNS. Ditto Windows shares.

Just that protocols that browse for distributed resources can be hell
on a network.  One has to be very careful.

    >> You definitely want an "arch" service.  However, the assigned
    >> port doesn't take you directly to arch; it takes you to the
    >> arch archive directory service.

    Paul> I've done a little more reading on DNS-SD, and this doesn't
    Paul> appear to be necessary: we can indeed specify that an "arch"
    Paul> service lives at a particular URL. See page 11 and beyond of
    Paul> <http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt>.

Hehe.  (1) This isn't an RFC, even, yet.  (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.  (3)
That's on a datagram service.  (4) And it's deprecated by the authors
anyway.  The lpd example is about _backward compatibility_.  New
protocols SHOULD NOT depend on it.

This is _definitely_ going to be hell on the conference network at
registration hour.  Not to mention abuse of the whole DNS idea.  The
DNS was never intended to be a directory for arbitrary text.

    Paul> See above: we can actually have straight DNS-SD support for
    Paul> URLs.

My guess is that the IETF will say: if you want to use SRV records to
discover lpd queues, rewrite the lpd protocol spec.

    Paul> And now we're back to where we left off on the other thread,
    Paul> with the thought that an extended "tla grab"

tla grab is technologically trivial, and it's a social solution.

    >> That's a mistaken association.  Some problems have only social
    >> solutions.  (mDNS is essentially a social solution.)

    Paul> I'm not sure what you mean by this. mDNS is a technology.

mDNS amounts to walking into a crowded room and yelling, "Yo, is Paul
Snively here?"  That's social behavior; you're talking to a specific
group, the ones in front of you, and who knows if anyone will bother
to answer?  And sure, humans are more fallible than machines, but UDP
is pretty fallible as mechanical technologies go.  Especially in the
packet storm that is likely to characterize registration hour at a
conference.

    Paul> So let me just emphasize once more that DNS-SD

DNS-SD as written in that draft looks to me to suffer from severe lack
of the kinds of experience that informs the Gulbrandsen, Vixie, Esibov
RFC for SRV records.  I think it's years from acceptance, and two of
the features that arch might want to depend on (DNS TXT records and
multilevel protocol discovery, cf the _anon._ftp._tcp example) are
likely to be extremely controversial.  IMO YMMV IANAL etc. but I think
we're better off looking for a solution we can implement today in
conformance with the existing RFCs.

-- 
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.