Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt

From: Alexis Yushin <[email-masked]>
Date: Wed, 12 Feb 2003 10:47:40 +0100 (CET)

Once Andreas Gustafsson wrote:
>There is already such a list:
>
>  "the domain names embedded in RRs of type NS, MD, MF, CNAME, SOA, MB,
>  MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT,
>  NAPTR, KX, SRV, DNAME, and A6 are converted to lower case according
>  to the DNS rules for character comparisons"

Side questions, perhaps I missed the answer, but where does this list
come from?

Alexis

--
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: Erik Nordmark <[email-masked]>
Date: Wed, 12 Feb 2003 11:57:16 +0100 (CET)

> And I'm concerned about the use of terms like "defined RRs" and
> "existing RRs" since their meaning changes over time.  The draft
> already precisely specifies which RRs use which canonicalization rule;
> talking about "defined RRs" would be irrelevant and only confuse the
> matter, especially for someone reading the RFC ten years from now.

Agreed that "defined RR" and "existing RR" should not be used.
And given that section 7 has the list of RRs that use downcasing
that part is ok (I didn't re-read the section yesterday so I confused
myself - sorry about that.)

The only thing that is odd is the "changed" in the text:
   For all other RR types, the canonical form is hereby changed such
   that no downcasing of embedded domain names takes place.  The owner
   name is always set to lower case according to the DNS rules for
   character comparisons, regardless of the RR type.
where you've identified that there is no change.

To me it makes sense stating instead:

   This document specifies that for all other RR types, the canonical form
   is such that no downcasing of embedded domain names takes place.  The owner
   name is always set to lower case according to the DNS rules for
   character comparisons, regardless of the RR type.

and then add a note saying that

   Note that after RFC 2931 there has been no RR types defined which have
   an embedded domain name. It is expected that future definitions of
   RR types will explicitly state that there is no downcasing of embedded
   domain names as part of DNSSEC canonicalization.

Does that make sense?

In terms on text suggestions, I don't know if I've seen suggested
text that makes it clear that the document changes the compression
rule for SIG and NXT. For the benefits of clarity it makes sense
having that paragraph point at the paragraphs in 2535 that are changed.

  Erik

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 14 Feb 2003 10:28:12 -0800 (PST)

>    character comparisons, regardless of the RR type.

OK - I still don't quite see why the word "changed" is so
objectionable, but I have no problem with making this change.

>    an embedded domain name.

This is exactly the kind of statement regarding "defined RRs" I have
already repeatedly objected to adding.  It is true today, but will
become false as soon as additional RR types with embedded domain names
are defined, and would cause nothing but confusion to an implementor
reading it ten years from no.  Such a statement does not belong in an
archival document.

>    It is expected that future definitions of

That is not my expectation.  There is a precedent for explicit
statements regarding the applicability of *compression*, but that is
only because RFC1035 was so ambiguous about where compression was
allowed that it had to be specified in the individual RR type
definitions (and even then some RR definitions interpreted RFC1035
differently from others).  In the case of DNSSEC canonicalization, I
hope the specification will be complete and unambiguous so that we
don't have to resort to that kind of workaround.

> having that paragraph point at the paragraphs in 2535 that are

Can do.
-- 
Andreas Gustafsson, [email-masked]