Subject: Re: I-D ACTION:draft-ietf-dnsind-rfc2052bis-00.txt

From: Bill Woodcock <[email-masked]>
Date: Sat, 5 Sep 1998 19:01:17 -0700 (PDT)

> The RFC Editor made an unrepresented change to the final draft,
        > for reasons which remain unclear to me, and that RFC 2052 does
        > not represent the intent of its authors.
    
    This came up in the first place because I was discussing Apple's
    service-location issues with Paul, and showed him a current copy of
    the RFC.  Taking the liberty of speaking for Apple, since I'm the
    person primarily working on it at the moment, we'd much rather
    implement it with underscores, to eliminate collisions in the name
    space, which will happen if no escape character is used.  We'll also
    only implement something that's RFC-compliant.  That means that we'd
    _very much prefer_ that the RFC were fixed, so we could implement this
    correctly, rather than shipping a broken version.
      
                             -Bill

---

From: Randy Bush <[email-masked]>
Date: Sun, 6 Sep 1998 03:25:21 -0700 (PDT)

> we'd much rather implement it with underscores, to eliminate collisions in
> the name space, which will happen if no escape character is used.

this is the part i am having a hard time understanding.  as the underscore
is just another character like any other, how will its use in this case
avoid name collisions or be an 'escape'?

randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 7 Sep 1998 07:44:55 -0700 (PDT)

> Underscores are not valid in *hostnames*

What's a hostname?

randy

---

From: [email-masked]
Date: Mon, 07 Sep 1998 15:54:12 +1000

> avoid name collisions or be an 'escape'?

	Underscores are not valid in *hostnames* and even when they have
	been used illegally they are internal to the label and not at
	the ends.

	Lets say you wanted to define a whois SVR record for "com". You would
	register need to register the name "whois.tcp.com" with rfc2052.
	Unfortunatly "tcp.com" is already delegated *and* out of the com
	administrators control.  Now with rfc2052bis (or how it was
	originally proposed) "_whois._tcp.com" which does not clash with
	"tcp.com".

	Personally I like the idea of "whois\.tcp.com" i.e. "whois.tcp" is
	a single label. Or "whois/tcp.com".  I can't see the need for
	two levels here though I am willing to be convinced.

	Mark
--
Mark Andrews, CSIRO Mathematical and Information Sciences
Locked Bag 17, North Ryde, NSW 1670, Australia.
PHONE: +61 2 9325 3148                 INTERNET: [email-masked]
MOBIL: +61 41 442 9884           UUCP:....!uunet!cmis.csiro.au!mark.andrews

---

From: Steve Traugott <[email-masked]>
Date: Mon, 07 Sep 1998 02:00:10 -0600

> avoid name collisions or be an 'escape'?

The underscore is not allowed in hostnames.  Therefore a name beginning with
an underscore cannot be a hostname.  Therefore SVR keys cannot conflict with
hostnames.  (Unless you're using NT 5.0 Beta 2, which was dutifully written
in accordance with a version of 2052 in which the RFC editor had 
inadvertently deleted the underscores.)

How's that for a summary?  ;-}

Steve

---

From: [email-masked]
Date: Tue, 08 Sep 1998 06:54:57 +1000

>> Underscores are not valid in *hostnames*
	A name use to identify a machine.  This syntax of this name 
	is restricted by RFC 952 / RFC 1123 to PREVENT PROBLEMS WITH
	INTEROPABILITY.  The fact that people use names outside of this
	syntax and get away with it some of the time does *not* mean
	that restricting the syntax is a bad idea. It just means that
	they are lucky.

	This is exactly the same reason we are sitting here dissussing
	whether unserscore should be prepend to the lables in the SVR
	record.

	Mark

---

From: Robert Elz <[email-masked]>
Date: Tue, 08 Sep 1998 07:45:14 +1000

Date:        Tue, 08 Sep 1998 06:54:57 +1000
    From:        [email-masked]
    Message-ID:  <[email-masked]>

    A name use to identify a machine.

That's OK, in which case all of the names in the DNS which are not
to identify machines (all the virtual domain names, all the names of
services, like "www...." "ftp..." etc) are not subject to those
restrictions.

Then, since you have no way to tell what is one of those and what is
the name of a machine, you can't really object to any name you see.

    This syntax of this name is restricted by RFC 952 / RFC 1123
    to PREVENT PROBLEMS WITH INTEROPABILITY.

Nonsense.   952 defines the syntax of names in hosts.txt.   Since that
file has to be distributed and parsed (or used to have to be, once, long
long ago), defining the syntax of the various fileds in it was perfectly
reasonable.   If you plan on putting your names in hosts.txt then yes, you
will need to comply with its syntax.   Personally, I don't...

    The fact that people use names outside of this
    syntax and get away with it some of the time does *not* mean
    that restricting the syntax is a bad idea. It just means that
    they are lucky.

Sometimes it does (when they get away with underscores in the domain name
part of an e-mail address).   Other times it simply means that there is
no restriction defined, and they're just living within whatever limits
their implementation inposes.

No, the mis-conception that underscore can't occur in a DNS name is
why it is suggested for SRV records.   Since there is nothing that can't
occur in a DNS name, this is a lost cause.   The best that can be done (if
anything needs doing) is to find something which is unlikely to occur in
a domain name.   A leading underscore might be that, but there are most
probably other, better, variations (like the embedded dot that you suggested)
which would be even less likely.

kre

---

From: Steve Traugott <[email-masked]>
Date: Thu, 10 Sep 1998 19:57:16 -0600

> 	two levels here though I am willing to be convinced.

Gack!  Using a separator character (like a dot) that would have to be
escaped (one way in some shells or OS's and differently or not at all in
others) would be asking for trouble, and would be *very* confusing.  We're
s'posed to be making technology *easier* to use, not harder.  If it's hard
to use people won't use it and we're wasting our time, right?  Which always
opens the door to vendors stepping in and releasing their easy-to-use 
proprietary solution and ignoring IETF.  Right?

rfc2052bis as originally worded by Paul makes a great deal of sense and avoids
confusion in namespace with a minimum of new concepts for Joe Sysadmin:  "Oh,
leading underscore means it's probably an SVR record.  Okeydokey."

Steve

---

From: [email-masked]
Date: Fri, 11 Sep 1998 15:14:06 +1000

> leading underscore means it's probably an SVR record.  Okeydokey."
	Do you really think users are going to look this up.  Users just
	put in hostnames to there favorite application.  This then
	generates an appropriate query.  Making this complicated for
	users is a good thing as they are much less likely to accidently
	generate the query.

	As for the application writers, all they need is a well defined
	API to call.  It's then up to the vendors to supply an
	implementation.

	struct serv_rr {
		u_int16_t priority_sv;
		u_int16_t weight_sv;
		u_int16_t port_sv;
		char *    host_sv;
		} ;

	struct serv_rr *
	getservbyname(const char service, const char transport,
		const char hostname);

	or

	int
	openserv(const char service, const char *hostname);

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Phillip Hallam-Baker" <[email-masked]>
Date: Fri, 11 Sep 1998 10:22:04 -0400

I am now somewhat confused. This may be my fault but let
me explain the reason.

The argument for the underscores appears to be that there
is a potential confusion with a host name. A search for
http.foobar.com is likely to throw up a number of SRV
record which are not required.

I don't see that this creates a semantic confusion however 
since a client that does not understand the SRV semantics
must simply ignore the records entirely. The only undesirable
consequence of not escaping appears to be that the SRV record
is potentially a logical part of an entry as far as the DNS
is concerned even though there is no actual correspondence.
Again I don't see that this actually breaks anything, it
just results in unnecessary SRV records being provided.

Is there a potential conflict with the first two entries of
the SRV record being interpreted as a hostname for some
reason? I do not think so because the semantics are defined
by SRV. Likewise I do not see concrete examples of the
type of confusion motivating proposals to @/! 

If there is a possible confusion with something other than
a hostname it appears to me that rather than search for a 
character whose use cannot be ambiguous the simpler solution 
is to state that the doubling convention holds, i.e. 
__ is equivalent to _

		Phill

---

From: [email-masked]
Date: Sun, 13 Sep 1998 08:22:01 +1000

> is to state that the doubling convention holds, i.e. 

	The problem lies in the fact that there is potentially a large
	number SVR records for a given hostname.  There are three possible
	solutions to this

	1) live with this and just use TCP. In this case the data
	component of the SVR  record would have to identify the serivice
	and transport as well as the preference weight port and hostname
	(and hence A / AAAA records) to connect to.

	2) shift the service and transport into the namespace so
	that the number of records returned is any lookup is small.  This
	does have the problem that we want to avoid collisions in the
	namespace with existing delegations.  This was the solution
	chosen and what we are arguing over now.  Remember tcp.com is
	*not* administered by the same blokes that administer com.

	3) extend the protocol (create a new one) so that you can ask
	for only a subset of the RRset and use 1.

	This last one provides a nice solution for things other that SVR
	records.

	Mark

---

From: Jerry Scharf <[email-masked]>
Date: Sun, 13 Sep 1998 08:13:27 -0700

>	for only a subset of the RRset and use 1.

doing DNSSEC signing is an exercise left to the reader.

jerry