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

[Stephen J. Turnbull]

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

    Paul> Where? I see three instances of the phrase: in section 2,
    Paul> which defines its use; in section 6.2, "Ideally it SHOULD
    Paul> NOT be necessary for a client to retrieve this additional
    Paul> information before it can usefully establish a connection to
    Paul> the service;"

That's the one.

    Paul> As for "specifically deprecates,"

Cheshire et al specifically adopt the RFC 2119 language.  Do you mean
to imply that they didn't mean it?

    Paul> Again, if you wish to limit yourself to installations that
    Paul> require configuration, I think this is fine.

Correction: My proposal requires additional infrastructure, _not_
additional configuration at discovery time.  Nor do I want to limit
myself to such installations.  I proposed an implementation which is
compatible with (among other things) a phased transition to the
protocol you suggest, including concurrent implementation.  It is also
compatible with an explicitly configured ("well-known port") setup,
which would be useful in a conservative domain that might not even
implement SRV RRs, but that's not the primary purpose.

Rather, _you_ insist on limiting _arch_ to a protocol which is not yet
standard, is therefore likely to be revised, have non-conforming and
buggy implementations, and be otherwise unstable for some time, and
may or may not work in practice as you hope.  Not to mention that I
could be right, and the whole TXT RR may get deprecated by the time
it's all standardized.  You have a lot more at risk than a half-hour
of writing a response if you head down that path.

Oh, and about that configuration issue: without mDNS, how do the SRV
RRs and TXT RRs get in the DNS server?  Do you have any idea what
security implications the implicit answer (allowing arbitrary
anonymous clients to update the DNS) would have?

Here's an "other thing" you might want to contemplate: with the
indirect database method I suggest, you could optionally redirect the
query about where databases are, not to the host with the archive, but
to a caching directory server that would, in one efficient operation,
register (if needed) the querent's archives and return the list of
known archives of network neighbors.

Here's another "other thing" that could be interesting: archives
support a =README for each object (category, branch, version), and the
server could (using a TCP connection) cache the results of "tla
abrowse" and return the =README for each object found on request.
This would make the directory have value-added, rather than being
simply a time- and typo-saver in constructing menus.  AFAICT this is
orthogonal to the caching central server idea.

    Paul> particularly since I've now spent approximately half an hour
    Paul> of my life that I can never get back writing trivial
    Paul> rebuttals to selective, out-of-context, unrealistically
    Paul> pessimistic, and in one case merely false, "information"
    Paul> about DNS-SD.

Correction: the merely false statement was about mDNS.  And you forgot
to mention the time you spent generating personal insults ("political").


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