[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D Action:draft-reid-dnsext-zs-00.txt
[ Moderators note: Post was moderated, either because it was posted by
a non-subscriber, or because it was over 20K.
With the massive amount of spam, it is easy to miss and therefore
delete relevant posts by non-subscribers.
Please fix your subscription addresses. ]
On Nov 16, 2007, at 21:55, Stephane Bortzmeyer wrote:
I'm not really convinced of the usefulness of this RR. It is non
structured (so it cannot be automatically parsed) and the only thing
it gives that TXT does not provide is the ability to query only ZS
records, which does not seem a lot. (In the wild, TXT records seem to
be used a lot for this purpose, sometimes with a full CVS $Id$ in a
TXT value.)
The whole point of this proposed RRType is that it's unstructured.
Its RDATA is meant to be read by a human being, not a computer. In
fact the reason for proposing this RRType is that providing zone
status info can't readily be done with a TXT record because these are
already used for all sorts of things, like $Id$ strings or SPF cruft.
As the draft explains.
If someone wants to work on this topic, I would suggest a more
structured RR. Things like the date of the last update should really
be a parsable type.
IMO it would make more sense to have a discrete RRtype that held a
timestamp for the zone's last update (or whatever).
But I'm not sure it is worth working on that instead of, for instance,
IRIS for things like "publishing real-time contact data for [ENUM]
zone owners" or the various presence protocols (RFC 3856, or RFC 3921)
for things like "the zone owner is asleep, so don't bother trying
voice-based communication".
This is a very, very bad idea. First off, it assumes that all zones
are supported by a registry that runs IRIS. This is just not true:
where's the IRIS server for some delegation of example.com? Second,
it assumes that every registry has an IRIS service that can take
updates for every zone (from zillions of different zone owners?)
several times a day whenever the zone's presence/status info changes.
Which seems highly unlikely. It would be much simpler for everyone if
this was done through the DNS using an RRtype that was specifically
defined for disclosing human-readable zone status and/or presence
info. Finally, it's not possible to update an IRIS server and some
zone file in an atomic transaction. So the zone data can't be
guaranteed to be in sync with what some IRIS status message might say.
The end user considerations section seems to be quite broken, as far
as i18n is concerned. Speaking of "unusual character sets" is
inappropriate, specially when the examples given are Chinese and
Arabic scripts, hardly "unusual". If such records would be used for
messages to the end-user, as suggested in section 3, a real i18n would
be necessary, with language-tagging of the messages.
You're being mischeivous. :-) It's quite wrong to imply that I'm
saying these scripts are unusual: everyone knows they're not. The
objective of this section of the draft is to advise prospective
publishers of ZS records to consider the audience that will be
reading these records and the devices they might have. In other
words, "Don't put an Arabic (say) string in the RDATA unless you're
sure that the majority of people looking his up can read Arabic and
have devices which can render these characters/scripts
appropriately.". If you feel the language in the draft does not
properly reflect that common sense principle, please contribute text
that does.
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>