Re: [dnsext] RRTYPE request: template for ZS record

[Ted Hardie <hardie@qualcomm.com>]

At 11:46 AM -0800 11/21/08, Ted Hardie wrote:
>Reading this, the justification says:
>
>                 There is a need to provide a mechanism in the DNS to publish
>   	descriptive information about the status of the zone,
>   	particularly for zones holding real-time contact data. At
>   	present a variety of ad-hoc schemes and conventions are
>   	used. These approaches are confusing and impractical since an
>   	arbitrary DNS client needs a priori knowledge of which of
>   	these schemes, if any, has been used by a zone administrator.
>	Assigning a new RRtype for a resource record to hold this
>   	information will provide a simple, standardised way of
>   	publishing and retrieving zone status information.
>
>
>I don't see how the proposed ZS RRTYPE solves this problem.  It seems
>like it has exactly the same problem as TXT does:  it will be completely
>unstructured data.  It also seems likely that different zones might
>diverge on how they present zone status information.  Is there a draft
>that describes the standard for zone status information?

Olafur was kind enough to point out I had missed the reference
to draft-reid-dnsext-zs-01.txt.  I've gone and read that now,
and I still have the same issue.  It says:


   Apart from its type code, the wire and text formats for the proposed
   ZS RRtype are identical to the definitions of the TXT record given in
   RFC1035:

   ZS RDATA format

               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
               /                   ZS-DATA                    /
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   where: ZS-DATA One or more character-strings.

   The ZS RRtype will hold descriptive text intended to contain
   information reflecting the status of the zone in which it is held.

It goes on in the End User Considerations:

  Users publishing ZS records SHOULD pay attention to the needs of
   potential readers of these resource records, especially with respect
   to character sets and language.  Although arbitrary text can be
   stored in character-strings, publishers of ZS records SHOULD
   carefully consider the capabilities of the devices and end users who
   query for ZS records.  For example, a mobile phone or other hand-held
   device may not have the font information or suitable rendering
   capabilities to display (say) Chinese or Arabic characters.
   Similarly, publishers of ZS records should try to avoid displaying
   information in multiple languages or assume that all readers of these
   records understand the same language or languages they have chosen to
   use.  In these circumstances it would be inadvisable to publish a
   string in a ZS record that is unlikely to be intelligible to those
   who lookup ZS records.

This does not seem to me enough information for anyone
wanting to use this to do so without zone specific information.  It
replicates the same issue raised in the template:

	These approaches are confusing and impractical since an
   	arbitrary DNS client needs a priori knowledge of which of
   	these schemes, if any, has been used by a zone administrator.

If I am missing yet more context, my apologies, but I
still don't get the real advantage.
			regards,
				Ted Hardie

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