Subject: rfc2052bis

From: Robert Elz <[email-masked]>
Date: Fri, 20 Nov 1998 19:38:40 +1100

Since the updated version of 2052bis has been available for several days
now (and Paul's diffs of what changed was on the mailing list even before
that), and there has been no adverse comment, I plan on requesting our ADs
to initiate an IETF last call on this doc, for Proposed Standard status,
after which it should go to the IESG for consideration.

If anyone has any last minute comments before this happens, right now is the
time to make them - though unless there is something quite serious, I think
we won't be requesting a new draft until after the IETF last call period.

kre

---

From: Peter Koch <[email-masked]>
Date: Fri, 20 Nov 1998 17:04:53 +0100

> time to make them - though unless there is something quite serious, I think

The draft still says about the field "target": "Name compression is to be
used for this field." This has already been agreed upon as an interoperability
problem, so either (a) do not allow compression for this field, or (b) use
local compression.  In this particular case I think (a) is the correct choice,
because the SRV RR is not new, the revised spec still uses the old type code
and so (a) is safe from producing interoperability problems - at the cost
of more occupied datagram space. No showstopper, though.

-Peter

---

From: Robert Elz <[email-masked]>
Date: Mon, 23 Nov 1998 21:27:13 +1100

Date:        Fri, 20 Nov 1998 17:04:53 +0100
    From:        Peter Koch <[email-masked]>
    Message-ID:  <[email-masked]>

  | The draft still says about the field "target": "Name compression is to be
  | used for this field." This has already been agreed upon as an
  | interoperability problem,

I think we need to know here what the existing users of SRV actually
do in this area?   That is, how is it implemented now?

Essentially everyone agrees that there is no good way to add new RRs using
general DNS name compression - but at the same time, that is exactly what
everyone has been doing since the inception of the DNS.   Strictly, MX
records should not be using compression for their names - but they do.

kre

---

From: Paul A Vixie <[email-masked]>
Date: Mon, 23 Nov 1998 21:41:34 -0800

> do in this area?   That is, how is it implemented now?

BIND 4.9.* through 8.1.2 does the wrong thing.  But I'll arrange for 8.1.2++
to not compress the name field.

> records should not be using compression for their names - but they do.

Shall I fix 8.1.2++ to stop doing that, or should we just admit that MX has
been around long enough that it can be grandfathered into the "bad old days"?

---

From: Peter Koch <[email-masked]>
Date: Tue, 24 Nov 1998 10:57:42 +0100

>> records should not be using compression for their names - but they do.

This view is probably too restrictive. Following the word and wisdom of 1035,
all the RRs defined in section 3.3 are "well known" and hence all domain names
in their RDATA sections are subject to conventional compression.
The problem does exist only with RRs defined later than 1035. That's what
draft-ietf-dnsind-local-compression-03.txt tries to address in section five,
"Old RR types and deployment".

> been around long enough that it can be grandfathered into the "bad old days"?

An implementation predating 1035 would have lost anyway, so there's nothing
to fix.

-Peter

---

From: Robert Elz <[email-masked]>
Date: Tue, 24 Nov 1998 20:41:07 +1100

Date:        Mon, 23 Nov 1998 21:41:34 -0800
   From:        Paul A Vixie <[email-masked]>
   Message-ID:  <[email-masked]>

 | BIND 4.9.* through 8.1.2 does the wrong thing.  But I'll arrange for 8.1.2++
 | to not compress the name field.

With this, I think we can assume that 2052bis will be corrected so that
the sense of the sentence ...

	Name compression is to be used for this field.

will be reversed.   In fact, it ought become a MUST NOT.

 | Shall I fix 8.1.2++ to stop doing that, or should we just admit that MX has
 | been around long enough that it can be grandfathered into the "bad old days"?

I think we can assume that name compression in MX records is now blessed
by usage.   If an update of the DNS spec is ever written, it ought be
specially noted.

kre

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 24 Nov 1998 09:05:39 -0600

> Shall I fix 8.1.2++ to stop doing that, or should we just admit
> that MX has been around long enough that it can be grandfathered
> into the "bad old days"?

If no one can point to a well-deployed implementation which chokes on
RDATA-compressed MX records, then let a document be written to codify
existing practice.  Is there a second?