[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata
From: |
Paul Snively |
Subject: |
Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata |
Date: |
Sat, 20 Sep 2003 01:23:39 -0700 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Stephen!
On Saturday, September 20, 2003, at 12:05 AM, Stephen J. Turnbull
wrote:
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.
As an ideal, sure. But:
"In cases where more data is justified (e.g. LPR printing), keeping the
total size under 400 bytes should allow it to fit in a single standard
512-byte DNS message. (This standard DNS message size is defined in RFC
1035.)
In extreme cases where even this is not enough, keeping the size of the
TXT record under 1300 bytes should allow it to fit in a single
1500-byte Ethernet packet.
Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this
time."
I quoted the section earlier on file servers and HTTP servers because
those are precisely the kinds of mechanisms you'd use to make an arch
archive available publicly and because they are clearly, deliberately,
and explicitly within the domain of services that DNS-SD is intended to
address, even if that means that TXT records get up into the 1K range.
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.
Where? I see three instances of the phrase: in section 2, which defines
its use; in section 6.2, "Ideally it SHOULD NOT be necessary for a
client to retrieve this additional information before it can usefully
establish a connection to the service;" and section 6.5, "Authors
defining DNS-SD profiles SHOULD NOT convert binary attribute data types
into printable text (e.g. using hexadecimal, Base64 or UU encoding)
merely for the sake of making the data be printable text when seen in a
generic debugging tool."
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.
"Ideally it SHOULD NOT be necessary." Well, arch isn't a service
running on a port, so it doesn't fit the ideal case. But the
FTP/HTTP/whatever service hosting your public archive does. Add a URL
and you're done, and that's absolutely within not only what Cheshire et
al contemplate, but how DNS-SD is being used today.
What's wrong with the suggestion I made, of standardizing on a
directory service which is pointed out by the SRV record for arch?
What's the configurationless version of that? I don't have a problem
with LDAP for configurationfull installations, but that's not the only
case I'm interested in addressing.
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.
Once again, I think you underestimate the progress on ZeroConf as an
emerging standard; take some time to follow the IETF ZeroConf Working
Group's efforts. Whatever else it may be, it is certainly not
proprietary: <http://developer.apple.com/darwin/projects/rendezvous>,
<http://www.swampwolf.com/products>, <http://zeroconf.sourceforge.net>,
<http://dotlocal.org/mdnsd>, <http://www.acm.uiuc.edu/signet/liaison>,
<http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/zeroconf/tmdns>,
<http://radio.weblogs.com/0105002/stories/2003/01/06/
multicastDnsServiceDiscoverForPython.html>,
<http://www.strangeberry.com/java_rendevous.htm>, and
<http://www.neato.org/%7Efemur/iu> are all open source, and several are
Free-as-in-FSF software.
As for "specifically deprecates," I've quoted whole sections of the
spec that contradict your interpretation, neglecting to leave out such
crucial words as "Ideally" and "In extreme cases where even this is not
enough... 1300 bytes." Note that your example was 113 bytes plus string
overhead. So you could double that, add your 128 bytes for "a minimum
of the DNS overhead, a SRV record, and an A or AAAA record," and still
be within the 512-byte range. In short, with your failure to quote the
spec, argument from the worst-case and assertion that it's the only
case supported by the spec, and mischaracterization of this open-source
technology as "proprietary," it's clear that your argument is political
rather than technical.
On the other hand, if we use my suggestion, then (a) we conform to
current RFCs and drafts and can implement _and deploy_ _now_
Using DNS-SD (and, optionally, mDNS), we also conform to current RFCs
and drafts (since they are drafts) and can implement _and deploy_ _now_
(since DNS-SD and mDNS implementations are available for all popular
platforms).
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.
Again, if you wish to limit yourself to installations that require
configuration, I think this is fine. Such a limitation is an anti-goal
for me. I've indicated not merely a willingness, but a desire, to
discuss DNS-SD distinctly from mDNS, but you seem to wish to continue
conflating them. I've even mentioned alternative no-configuration
technology such as Ensemble and Spread, to which there's been no reply.
So I have to conclude that it is not I who am "hung up on this...
technology" at all, but rather that you are being selectively
perceptive. I'll say it one more time: if anyone knows of a good
_configurationless_ alternative to DNS-SD + mDNS, I'm all ears. It
could be DNS-SD and something other than mDNS or it could be neither; I
really don't care (cf. Ensemble and Spread). But neither Ensemble nor
Spread are IETF standards-tracked; neither have multiple
implementations; neither are provided with any popular computing
platform or supported by any OS vendor. So I suspect that the
resistance to those alternatives would be even greater than the
resistance to ZeroConf. Nevertheless, I remain open to substantive
feedback about the available alternatives to DNS-SD and mDNS,
particularly since I've now spent approximately half an hour of my life
that I can never get back writing trivial rebuttals to selective,
out-of-context, unrealistically pessimistic, and in one case merely
false, "information" about DNS-SD.
--
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.
Best regards,
Paul
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iEYEARECAAYFAj9sDpQACgkQugPBK9DetepInQCgo8Uc83obu9iDpkpVsytm3XZv
QnEAoJPgl7lPjnsjcYAlLHB4aTIZ9x2T
=75JQ
-----END PGP SIGNATURE-----
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, (continued)
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Stephen J. Turnbull, 2003/09/18
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/19
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Stephen J. Turnbull, 2003/09/19
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Andrew Suffield, 2003/09/19
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/19
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Stephen J. Turnbull, 2003/09/20
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata,
Paul Snively <=
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Robert Collins, 2003/09/20
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Stephen J. Turnbull, 2003/09/20
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Andrew Suffield, 2003/09/17
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/18
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Doran Moppert, 2003/09/18
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/19
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/17