Subject: Q1 followup - arguements against "MUST NOT" language

From: "Scott Rose" <[email-masked]>
Date: Wed, 12 Feb 2003 13:40:38 -0500

The general consensus is that name compression in RDATA is A Bad Thing (tm),
but there are some differences on the wording for the spec:

Sub-Question:  What are the arguments against using the terms (1)"MUST NOT
use name compression on DNS names in the RDATA on sending over the wire"
(paraphrasing here) over (2)"SHOULD NOT use name compression on DNS names in
the RDATA..."?

Notes:
    A.  (1) is the strength of the wording used in the unknown-rrs draft.
There would be consistency.

Scott

--
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: Edward Lewis <[email-masked]>
Date: Wed, 5 Mar 2003 11:15:53 -0500

At 17:09 +0100 3/5/03, Alexis Yushin wrote:
>Yes, I understand this sort of a bad thing, but that's a bit too late
>to fix it if we dont want to introduce an entirely new protocol. Now you
>basically suggest to introduce *additional* special rules (and I could live
>with it if it would solve the historical issues in the protocol) to help
>particular implementation.

I think I don't understand.  I'm advocating a return to what 1035 
said, not any additional rules.  RFC 1035 says that just a few types 
are subject to compression.  The DNSSEC specs overstepped their 
bounds in saying that the new RRs were also subject to compression.

>I strongly believe we should stay uniform on handling domain names,
>either forbid domain name compression at all (since the connectivity
>improved over years and we're not saving anything with it) or leave it
>as is.

The problem is that "as it is" is 'broken and inconsistent.' ;)

>I think that clear standard has priority over implementation simplicity.

The problem is that the standards are not clear, they are 
self-conflicting.  That's the issue, not really the implementation 
thing.  2535 should not break 1035 in any way, okay, not in this way.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer