Subject: Re: I-D Action:draft-reid-dnsext-zs-00.txt

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 16 Nov 2007 19:55:13 -0200

On Mon, Nov 12, 2007 at 08:20:01AM -0500,
 [email-masked] <[email-masked]> wrote 
 a message of 88 lines which said:

> 	Title           : The Zone Status (ZS) DNS Resource Record
> 	Author(s)       : J. Reid
> 	Filename        : draft-reid-dnsext-zs-00.txt

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

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.

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

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.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Jim Reid <[email-masked]>
Date: Sun, 18 Nov 2007 19:37:01 +0000

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

> be used a lot for this purpose, sometimes with a full CVS $Id$ in a

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.

> structured RR. Things like the date of the last update should really

IMO it would make more sense to have a discrete RRtype that held a  
timestamp for the zone's last update (or whatever).

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

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