Subject: [dnsop] Underscore registration summary

From: Bill Fenner <[email-masked]>
Date: Mon, 17 Jul 2006 07:26:31 -0700

There are two possibly orthogonal issues here:

1. Registration for any _foo that may appear, possibly just
the one closest to the root in a given domain name.
http://tools.ietf.org/html/draft-crocker-dns-attrleaf
Its introduction points out that the semantics of records
underneath the reserved node name may be restricted;
however, this wording may need a bit of work because,
e.g., dnssec may need to put records there no matter
what the semantics defined elsewhere.

2. Registration for service names used in SRV records.
http://tools.ietf.org/html/draft-fenner-iana-dns-srv
was my proposal some time ago (summary: update 2782
to use the WKS name registry instead of a vague reference
to 1700 that many have taken to refer to the port number/name
registry, possibly populate the registry, define rules
for new registrations).  This is related to
http://tools.ietf.org/html/draft-lear-iana-no-more-well-known-ports
in that it also says that IANA keeps registrations for
SRV records; presumably whether or not IANA charges for
well known ports is outside the scope of dnsop.

How to move forward?  In a way, it's a question of one registry
or two.  If draft-crocker-dns-attrleaf intends to have all
protocols and services used in SRV records as well as the other
contents, it could serve as both.  However, given the history, I
think SRV records need a little bit different registration rules,
so it may make sense to split them out into a different registry.
The question there would be whether it's just the top-most
prefixed label that gets registered in draft-crocker-dns-attrleaf
or all of them.

  Bill
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Edward Lewis <[email-masked]>
Date: Mon, 17 Jul 2006 19:46:38 -0400

This seems to be in conflict with the iab-dns-choices document.  One 
reason I brought up the existence of that document in the meeting in 
Montreal was situations like this - if the WG wants to recommend 
"prefixing names" it wouldn't be too wise to have the IAB saying 
"don't do that" at the same time.

I'm undecided on whether this is a good approach.  We do something 
similar for non-ASCII domain names and that seems to work.  But that 
isn't tying semantics to the label, just syntax.

We heard about the HTTP cookies and their folly of trying to 
distinguish "delegation-only" zones from others based on label count, 
only to find that 192.in-addr.arpa is more TLD-like than 
root-servers.net.

I know that SRV records have the concept of "_app+._transport.<base>" 
but I've seen that not work so well when CNAMEs are used for 
"services."  My SIP phone was configured with sip.ourlabs.example., 
so it tried to look up _sip._tcp.sip.ourlabs.example.  Problem was 
there is only a CNAME at sip.ourlabs.example.  There's a weakness in 
defining the shape of the tree to be such-and-such, as the IAB 
document mentions.  Not that this means the idea is dead (to me). 
But, still...

After umpteen years of DNS development, the basics ought to be 
getting more coherent...not just the data space.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 18 Jul 2006 11:12:16 +0200

Colleagues,

First expanding on something Ed said, then commenting on Dave's draft  
and then getting back to Bill, all in one thread.

On Jul 18, 2006, at 1:46 AM, Edward Lewis wrote:
> This seems to be in conflict with the iab-dns-choices document.   
> One reason I brought up the existence of that document in the  
> meeting in Montreal was situations like this - if the WG wants to  
> recommend "prefixing names" it wouldn't be too wise to have the IAB  
> saying "don't do that" at the same time.

Well... my reading of dns-choices is a bit different. Choices is  
intended to provide the arguments and considerations to make a trade- 
off; it does not say "don't do [TXT|underscores|*]", it just states a  
very strong preference for using new RR types. I think that the  
editors of that document most clearly pointed that out on page 11 of  
choices:

   Given the various issues described in this note, we believe that:
    o  there is no magic solution which allows a completely painless
       addition of new data to the DNS, but
    o  on the whole, the best solution is still to use the DNS type
       mechanism designed for precisely this purpose, and
    o  of all the alternate solutions, the "obvious" approach of using
       TXT RRs is almost certainly the worst.
    This especially for the two reasons outlined above (lack of  
semantics
    and its implications, and size leading to the need to use TCP).

In other words if people choose to use prefix names they should  
demonstrate (to whoever does the review of their documents) that they  
considered other options as well and that the use of a prefix does  
satisfy their needs and architecture best. In that context I think it  
would be useful for people who write internet-drafts that define use  
of prefixes or TXT RRs to add a DNS considerations section where they  
describe their trade-offs.

I think that whoever does the review of documents that 'extend' the  
DNS should have a very critical look to see if trade-offs have been  
made and if those trade offs have solid arguments.

Back to the matter at hand:

http://tools.ietf.org/html/draft-crocker-dns-attrleaf describes:

>    Recent additions have defined DNS leaves that contain a reserved  
> leaf
>    node name, beginning with an underscore.  The underscore  
> construct is
>    used to define a semantic scope for the name, within which the  
> choice
>    of valid RRs is limited to a defined set.  Hence the underscore
>    construct defines a basic paradigm modification to the DNS.  Within
>    the scope of a defined underscore leaf, the specific uses of  
> specific
>    resource records can be formally defined and constrained.  An
>    established example is the SRV record,[RFC2782] which generalizes
>    concepts long-used for email routing in the MX
>    record.[RFC0974][RFC2821] The use of special DNS names has
>    significant benefits and detriments

Focus on: "The underscore construct is used to define a semantic  
scope for the name, within which the choice of valid RRs is limited  
to a defined set."

I think this is the wrong way around (hence including Dave in the  
CC). I read the text above as: once one has a domain name with an  
underscored label that name gets a semantic scope and only a limited  
number of RRs are allowed to be used with that name. I think it is  
wrong to assign a semantic scope to a label and then restrict the set  
of RRs and/or assume that other RRs will comply to the same semantic  
scope.

So I would rather see that turned around: Within the context of  
specific resource records underscore labels can define a semantic  
scope. In other words a domain name with an underscored label only  
has specific semantic scope when used in combination with a RR type  
for which the semantics are described/defined.

For instance: an underscored label in the owner name of an RRSIG or  
NSEC record does not have any semantics whatsoever. Another example  
is the use of TXT RRs as comments.

  _sip._tcp.example.com 86400 IN SRV 20 0 5060 backupbox.example.com.
  _sip._tcp.example.com 86400 IN NSEC foo.example.com SRV NSEC RRSIG
  *._tcp.example.com 86400 IN TXT "I only care for sip"

Here the underscored labels do not have any relevance to the TXT  
record. Besides the same TXT RR would show up were a dns client to  
query for a tcp service other than sip.

The use of underscore labels with a particular RR is just convention  
and the chances of folk not sticking to the convention (and creating  
interop problems) becomes more problematic when the RR type has a  
more general use. In other words there are still good reasons to  
specify new RRs for specific use.

Oops.. I side tracked again...

> prefixed label that gets registered in draft-crocker-dns-attrleaf

Could you elaborate on that history and why you think you need  
different registration rules?

If a registry as proposed by Dave were to be established I would also  
register for which RRs the particular underscored label has semantic  
scope. I don't have particular strong feelings but I also think I am  
missing some background wrt the SRV history.

   hatless,
--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Bill Fenner <[email-masked]>
Date: Tue, 18 Jul 2006 07:06:46 -0700

>different registration rules?

RFC 2782 says that the service name is "from RFC1700" and doesn't
say which section.  I've seen varying interpretations, from meaning
"any name registered anywhere in any IANA registry" to "the name
from the port-numbers registry".  The latter is particularly
odd (you need to have a statically assigned port number in order
to get a name to be able to use the record that allows you to use
a dynamic port number), but seems fairly prevalent.

I think that these names need different rules for two reasons:
a) I don't think there's a need to have globally unique
values for the "service" of a SRV record - it's OK if there's
an _spf._udp.example.com even if _spf is reserved as the "top
level" reserved label.
b) It's too high a barrier to require people who have validly
been using values such as _http._tcp.example.com under the
RFC 2782 rules to write an RFC in order to register the usage.

  Bill
.

---

From: Peter Koch <[email-masked]>
Date: Tue, 18 Jul 2006 18:21:30 +0200

> for which the semantics are described/defined.

this I'd like to support, maybe s/semantic scope/resolution context/.
Such context can either be provided by the prefix or by the "suffix",
i.e. some ancestor domain, not necessarily the TLD. A precedent is that
A RRs have a very specific meaning in the "normal" tree and a different
one in the reverse tree. This overloading/context building has its
drawbacks, though.

> query for a tcp service other than sip.

(With qtype==srv?) Other than that, yes, those RRs can't be forbidden,
they just have no defined meaning -- as don't TXT RRs in today's
forward tree.
RFC 2782 seems to suggest that the SRV RR type is only defined for
"underscored" domains. That I'd consider broken, the RR type definition
needs to be owner-agnostic. A particular application ("using SRV RRs to locate
the foo service") however may well make use of or depend on the contextual
information.

> specify new RRs for specific use.

$ack++;

-Peter
.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Jul 2006 12:09:50 -0700

On Jul 18, 2006, at 9:21 AM, Peter Koch wrote:

> (With qtype==srv?) Other than that, yes, those RRs can't be  
> forbidden, they just have no defined meaning -- as don't TXT RRs in  
> today's forward tree. RFC 2782 seems to suggest that the SRV RR  
> type is only defined for "underscored" domains. That I'd consider  
> broken, the RR type definition needs to be owner-agnostic. A  
> particular application ("using SRV RRs to locate the foo service")  
> however may well make use of or depend on the contextual information.

The the SRV RR in conjunction with the underscore name offers a WINS  
style approach for finding services while also avoiding conflicts  
with "names in the wild".  Dropping use of the underscore convention  
would suggest that there be a RR type per service instead.  Perhaps  
there should have been a range of SRV RR types assigned by IANA.

>> The use of underscore labels with a particular RR is just  
>> convention and the chances of folk not sticking to the convention  
>> (and creating interop problems) becomes more problematic when the  
>> RR type has a more general use. In other words there are still  
>> good reasons to specify new RRs for specific use.
>
> $ack++;

While wanting to agree, there is also an expectation in the DKIM WG  
that utilization of newer RR types will be problematic (especially  
with respect to MS), and a purported rationale for use of underscores  
and TXT.  Which alternative would you expect to cause greater  
interoperability problems?

-Doug

.

---

From: Joe Abley <[email-masked]>
Date: Tue, 18 Jul 2006 15:59:25 -0400

On 18-Jul-2006, at 15:09, Douglas Otis wrote:

> with respect to MS), and a purported rationale for use of  
> underscores and TXT.

Without wanting to drag the whole DKIM design discussion into this  
list (one list is more than enough, I think, for that) this thinking  
is thoroughly broken.

If the use of new custom-fit RRs causes implementation problems with  
specific platforms, then those implementations need to be fixed in  
order for the DNS to be extensible in the RRtype dimension. That's  
never going to happen if new RRtypes aren't routinely assigned and  
used for new applications.

The right thing for DKIM to do is to register a DKIM RRtype with  
appropriately-structured RDATA. DKIM's requirement for underscore  
names disappears as soon as there's a DKIM record which can be used,  
so DKIM *ought* not to be a consideration when thinking about an  
_names registry.

>   Which alternative would you expect to cause greater  

The requirement to parse free-form data from TXT RDATA is hardly a  
recipe for trivial interop. From the list of specification nits I saw  
in the first DKIM meeting relating to parsing the TXT RDATA, one  
might also conclude that it's not easy to specify, either.

Unless Microsoft has an enormous hidden marketshare in authority  
servers and ISP mail relays, I'm not sure why they're being singled  
out as problematic with respect to new RRtypes and DKIM, incidentally.

Joe

.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Jul 2006 14:29:57 -0700

On Jul 18, 2006, at 12:59 PM, Joe Abley wrote:

> recipe for trivial interop. From the list of specification nits I  
> saw in the first DKIM meeting relating to parsing the TXT RDATA,  
> one might also conclude that it's not easy to specify, either.

While a valid consideration, these details are within the control of  
the WG.

> Unless Microsoft has an enormous hidden market share in authority  

The signature can also be verified at the MUA.  The desire is to  
ensure greater availability than just MTAs.  Do you know of barriers  
related to deploying new RR types for a typical user when they are  
running an MS OS?

-Doug
.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Jul 2006 07:58:11 +1000

> RFC 2782 rules to write an RFC in order to register the usage.

	Have you looked at what you need to do to migrate from non
	srv http to srv http?  I did and it is not as straight
	forward as it would appear at first glance.  I even wrote
	a I-D to describe the transition.

	It was reasons like this that the WG decided that existing
	protocols needed a RFC to transition to SRV usage.

	Mark

   INTERNET-DRAFT                                          M. Andrews (ISC)
   <draft-andrews-http-srv-02.txt>                              T. Kottelin
   Updates: RFC 2616, RFC 2782                                February 2002

             Use of SRV records in conjuction with HTTP and URIs.

   Status of this Memo

      This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.

      Internet-Drafts are working documents of the Internet Engineering
      Task Force (IETF), its areas, and its working groups.  Note that
      other groups may also distribute working documents as Internet-
      Drafts.

      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as "work in progress."

      The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

      Comments should be sent to the authors.

      This draft expires on August 2002

   Copyright Notice

      Copyright (C) The Internet Society (2002).  All rights reserved.

   Abstract

      The combined use of SRV records for HTTP along with URIs is not as
      straight forward as it would appear at first glance.  This document

   Expires August 2002                                             [Page 1]

   INTERNET-DRAFT                   SRV-URI                   February 2002

      looks at the issues involved and recommends solutions.

   Introduction

      Many of todays HTTP sites are virtual, that is they are hosted on a
      machine that is not known by the name the HTTP site is known by.
      This leads to the problem of how to rationally give these HTTP sites
      IP addresses.  This has traditionally been done by using CNAMES
      [RFC1034][RFC1035] or by using explicit IP address records where
      CNAMES are illegal due to restrictions in the DNS.

      Both of these solutions have undesired side effects.  CNAMES are not
      protocol specific.  Using IP address records is a logistic nightmare
      for large servers with many virtual sites.  This is becoming a bigger
      problem as companies move away from identifying their HTTP site with
      a ``www'' prefix and just use their delegated domain name, e.g.
      ``http://example.com/''.

      Using SRV [RFC2782] records would seem to be a natural solution to
      this problem in that they are protocol specific and will work where
      CNAMES are illegal in the DNS.

      There are problems with doing this without thought however in that
      URIs [RFC1738] can specify a port and SRV records do specify a port.
      When this occurs which one do you honour?

      In addition to this SRV records provide for load balancing.  For most
      protocols this is straight forward as there will only be a single
      connection made.  For HTTP however there are often many connections
      made in a session.  Should each of these individual connections be
      load balanced or should the load balancing be on a per session basis?

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in RFC 2119.

   1. URIs without an explicit port specification

      If the URI does not explicitly specify a port to connect to, i.e. the
      URI does not contain a ``:<port>'' part, there is no port conflict.
      In this case a client MUST follow the logic specified in [RFC2782],
      including the server selection mechanism provided by the priority and
      weight fields.  If SRV records do not exist then the client MUST fall

   Expires August 2002                                             [Page 2]

   INTERNET-DRAFT                   SRV-URI                   February 2002

      back to looking for IP address records.

      Once a server is selected it SHOULD be continued to be used for the
      rest of the session if possible after an initial connection is made.
      If a server has multiple addresses the client SHOULD continue to use
      the same address while possible taking into consideration ttl values
      on address records.  If connections to this address fail it SHOULD
      try the other addresses for the server first before attempting other
      servers.

      The use of a SRV record does not affect the contents of the "Host:"
      field of the HTTP transaction.  Its only effect is to potentially
      change the address and port the client connects to.  All other parts
      of the HTTP transaction are not affected by the presence of a SRV
      record.

      Examples:

      Single SRV record:

         URI:     http://example.com/
         SRV RR:  _http._tcp.example.com. SRV   10 0 8080 host1.example.com.
         A RRs:   example.com.            A     10.0.0.2
                  host1.example.com.      A     10.0.1.1

      Connect to:  10.0.1.1 port 8080

      Multiple SRV records:

         URI:      http://example.com/
         SRV RRs:  _http._tcp.example.com. SRV   10 1 8080 host1.example.com.
                   _http._tcp.example.com. SRV   10 3 8080 host2.example.com.
                   _http._tcp.example.com. SRV   20 0 8080 host3.example.com.
         A RRs:    example.com.            A     10.0.0.4
                   host1.example.com.      A     10.0.1.2
                   host2.example.com.      A     10.0.2.2
                   host3.example.com.      AAAA  1080::8:800:200C:417A

      Connect to: 10.0.1.2 port 8080 or 10.0.2.2 port 8080 if either is
      available (the probability of being selected should be 25% for
      10.0.1.2 port 8080, and 75% for 10.0.2.2 port 8080); otherwise, try
      1080::8:800:200C:417A port 8080.

   Expires August 2002                                             [Page 3]

   INTERNET-DRAFT                   SRV-URI                   February 2002

   2. URIs with a explicit port specification

      If the URI does explicitly specify a port to connect to then there is
      a potential conflict in the port specification between the URI and
      the SRV records, and the SRV record is ignored.  In this case the
      user agent MUST query for address records for the host name in the
      URI (instead of SRV records).

      If the server has multiple addresses the client SHOULD continue to
      use the same address while possible taking into consideration ttl
      values on address records.

      Note [RFC2616], Section 3.2.3 URI Comparison, states that URIs with a
      port value equal to the default port (80) are identical to those with
      no port or a empty port.  URIs with port are no longer treated as
      identical to those without a port or with a empty port.

      Examples:

      Default port specified:

         URI:      http://example.com:80/
         SRV RR:   _http._tcp.example.com. SRV   10 1 8080 host2.example.com.
         A RRs:    example.com.            A     10.0.0.1
                   host2.example.com.      A     10.0.2.2

      Connect to: 10.0.0.1 port 80

      Non-default port specified:

         URI:      http://example.com:8080/
         SRV RR:   _http._tcp.example.com. SRV   10 1 80 host2.example.com.
         CNAME RR: example.com.            CNAME host1.example.com.
         A RRs:    host1.example.com.      A     10.0.0.1
                   host2.example.com.      AAAA  1080::8:800:200C:417A

      Connect to: 10.0.0.1 port 8080

   3. Transitioning Considerations

      When transitioning from using a non-SRV solution to using a SRV based
      solution old, non-SRV aware, clients will continue to look for
      address records.  It may be necessary to use redirection at the HTTP
      layer to direct these clients to the new servers if the SRV records

   Expires August 2002                                             [Page 4]

   INTERNET-DRAFT                   SRV-URI                   February 2002

      point to a different <address, port> tuple.

      It will also be necessary to continue to provide the existing address
      / CNAME records until there is a significant percentage of SRV aware
      clients.  Experience has shown that this should be within one to two
      years of the introduction of the first SRV aware client.

      In cases where you are just trying to replace the A or CNAME record
      referring to a service providers machine with a SRV record the
      following should suffice.

      The service provider is hosting the service on machine.example.net
      and you are example.com.

         example.com.        A   <IP address of machine.example.net>
         _http._tcp.example.com. SRV 0 0 80 machine.example.net.

   Security Considerations

      The authors believe the algorithm described in this document to not
      cause any new security problems.  However care should be taken as SRV
      and non-SRV aware clients may be directed to different locations.

   IANA Considerations

      A well known label has to be allocated for the first label of the
      http SRV record.  This document has used ``_http''.

   References

   [RFC1034]
      Domain names - concepts and facilities. P.V. Mockapetris.
      Nov-01-1987. STD 0013, RFC 1034.

   [RFC1035]
      Domain names - implementation and specification. P.V. Mockapetris.
      Nov-01-1987. STD 0013, RFC 1035.

   Expires August 2002                                             [Page 5]

   INTERNET-DRAFT                   SRV-URI                   February 2002

   [RFC1738]
      Uniform Resource Locators (URL). T. Berners-Lee, L. Masinter, M. McC
      ahill. December 1994. RFC 1738.

   [RFC2616]
      Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J.
      Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999.
      RFC 2616.

   [RFC2782]
      A DNS RR for specifying the location of services (DNS SRV). A. Gul
      brandsen, P. Vixie, L. Esibov. February 2000. RFC 2782.

   Authors' Addresses

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

         Thor Kottelin
            Laivalahden puistotie 10 C 37
            FIN-00810 Helsinki, Finland
            +358 400878169
            [email-masked]

   Expires August 2002                                             [Page 6]


--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Jul 2006 08:50:44 +1000

> related to deploying new RR types for a typical user when they are  

	If the end user wants to use DKIM then they will get their
	infrastructure fixed if it can't handle a DKIM record.

	If you really don't want to add a new record then use the
	DNS to point to a HTTP(S) server that will serve the requested
	record.  Don't overload the TXT record.

	Doing this may be a good thing in its own right.  The DNS
	was designed to handle small RRsets.  From what I've seen
	of DKIM the RRsets are getting big.  This has impacts on
	DNS cache design.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Jul 2006 12:28:38 -0700

Folks,

I am delighted to see thoughtful discussion exploring this topic.  It was
exactly my goal in writing dns-attrleaf. (And many thanks for alerting me to the
thread.)

Preface:  When documents specify the use of a special name, then the space from
which that name is drawn needs a registry.  This is a basic fact of computing
life.

So I will suggest that any argument against this needs to explain why collisions
-- different uses for the same name -- are not a problem.  In other words, the
burden needs to be on anyone claiming no registry is needed.  Similarly, the
idea of having multiple registries for the same namespace needs to explain how
collisions will be avoided.

> what the semantics defined elsewhere.

Right.  On reviewing the comments, I now suspect that the language needs to be
in terms of specifying restrictions only with respect to particular RRs that are
explicitly listed.

That is, the ones that are listed are under the control of the scope limitation,
but all other RRs are unrestricted/unspecified.  (This seems consonant with
later postings in the thread.)

> think SRV records need a little bit different registration rules,

In order to have something concrete to use for discussion, I think it is fine to
use dns-attrleaf as an base of reference and try to understand what differences
from -- or alternatives to -- it are needed.  I included SRV in dns-attrleaf
because my intent was to include ALL uses of underscore names. This then led to
discovering what seem to me to be some basic problems with the details of the
SRV specification.

Although the form of the SRV documents listing of underscore names is indirect
and, I believe, ambiguous I am not clear why it needs to be treated differently
from any other. (Comments on your response to Olaf's query about this are below.)

Olaf M. Kolkman wrote:
>> This seems to be in conflict with the iab-dns-choices document. ...
>
> intended to provide the arguments and considerations to make a
> trade-off;
...
> I think that whoever does the review of documents that 'extend' the DNS
> should have a very critical look to see if trade-offs have been made and
> if those trade offs have solid arguments.

An extremely constructive view.

It begs the next question, which is what criteria are supposed to be used, in
creating and evaluating any discussion of trade-off considerations? We need to
find ways to make this step both useful and predictable, lest it become merely
another formal and unpredictable road-block.

One example of a likely point of impasse is the tendency to confuse "it won't
work" with "I don't like it".  Hence the team doing the specification can go
through it's considerations, document them, and produce a solution that will, in
fact, work, but that reviewers disagree with.

This difference between finding fatal flaws, versus points of differing
preference, is a common difficulty in the IETF.  My own experience with DNS
discussions is that the tension between defining a new RR versus using an
existing one is a particularly sensitive point that often confuses "it won't
work" with "I don't like it".

It occurs to me that we also have to ask how much extra burden to impose on the
design team and working group, compared with typical IETF specification work.
As a rule, the IETF does not require documenting trade-off discussions.
Although being able to point to such discussions is sometimes called for, it is
not a rule.  The rule is that a solution must work, according to a variety of
definitions of "work".

> Focus on: "The underscore construct is used to define a semantic scope
> for the name, within which the choice of valid RRs is limited to a
> defined set."
>
> I think this is the wrong way around (hence including Dave in the CC). I
> read the text above as: once one has a domain name with an underscored
> label that name gets a semantic scope and only a limited number of RRs
> are allowed to be used with that name. I think it is wrong to assign a
> semantic scope to a label and then restrict the set of RRs and/or assume
> that other RRs will comply to the same semantic scope.
>
> So I would rather see that turned around: Within the context of specific
> resource records underscore labels can define a semantic scope. In other
> words a domain name with an underscored label only has specific semantic
> scope when used in combination with a RR type for which the semantics
> are described/defined.

This one gave me quite a bit of pause.  (I seem to recall hearing it in
Montreal, so I've been paused for about a week...)

As nearly as I can tell, the problem with this alternative view is that it fails
to solve the primary issues being addressed. The major reasons for using
underscore names are to eliminate ambiguity and to eliminate scaling problems,
such as multiple and different occurrences of SRV and TXT records. For example,
the name says how to interpret any SRV or TXT records that occur under the name
ensuring that no other interpretations are allowed, under that underscore name.

That is, clear syntax/semantics, and no linear searching for a means of
distinguishing one use from another in an undifferentiated set.

> The use of underscore labels with a particular RR is just convention and
> the chances of folk not sticking to the convention (and creating interop

Standard protocols and format are "just convention", so I'm not sure what is
being dismissed, here.  Wherever there is supposed to be precise parsing and
precise semantics, formal "conventions" are needed.  In this case, "formal"
means standardized.

> register for which RRs the particular underscored label has semantic

I like your wording here.  I think it is simple, clear and correct.

> a dynamic port number), but seems fairly prevalent.

Just to state the obvious:  What you have just described is a pretty classic
definition of a deficient specification.  What is then required is fixing the
spec, not creating a registry hack that tries to work around it.

> an _spf._udp.example.com even if _spf is reserved as the "top

This makes sufficiently little sense to me that I am not even sure what to ask
or comment about it.

Use of the "service" name for SRV is useless without a specification that
defines it.  If a specification defines it, then how can it possibly be
acceptable to have two different specifications define different semantics for
the same name?

> RFC 2782 rules to write an RFC in order to register the usage.

I do not know what is the minimum to require.  I certainly believe that IETF
standardization is far, far too high a bar.  I tried for the lowest level that
had long-term stability.  This would seem to require an archival specification.
RFC publication seems to require that.  (We can grandfather all existing name
uses in the document that defines the underscore registry.)

I suspect that resolving the question of ambiguous usage -- and therefore,
registered global uniqueness -- will resolve this question of how high the
documentation bar should be.

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 24 Jul 2006 22:54:50 +0200

Hello Dave,

Thanks for the long reply.

> collisions will be avoided.

Well said.

I only hope we both agree that the 'domainname' namespace will have  
two registries once we create a registry for "underscored". The  
distributed registry that roots in the IANA/ICANN domain name root  
and this new registry for underscored labels.

(...)
Dave:
> I now suspect that the language needs to be

> later postings in the thread.)

I think that is a fair summary.

(...)

> another formal and unpredictable road-block.

Shall we, as a collective, try to start from common sense. I think  
that creating a check list or set of evaluation criteria is overkill.

> fact, work, but that reviewers disagree with.

As always this goes two ways. There have been many occasions where  
DNS folk suggested that the definition of a new RR type is the best  
way forward and the folk using "TXT" said "that won't work".   
Personally I think it is important that protocol developers try to  
develop protocols in a way that comes closest to what I, and many or  
my colleagues here, have  started to appreciate as architecturally  
sound. That way can be a little bit more certain that the DNS can  
scale just a bit more. Demonstrating the understanding of the  
principles by making the trade-off will certainly help the protocol  
designers and the folk that need to do the DNS reviewing.

> work" with "I don't like it".

I think that in this space it is more about finding the balance  
between "a hack that works" and an architecturally sound solution.  
Again a tradeoff.

> not a rule.  The rule is that a solution must work, according to a  

That definition should IMHO include that it does not break something  
else.

>> scope
>> CC). I

The point that I am trying to make is that for the SRV record this  
makes sense; roughly speaking for SRV RRs the underscored labels have  
always had specified semantics. Besides the underscored labels are  
used for subtyping the SRV RR.  For TXT RRs this has not been the  
case and even when one uses a registry for the underscored labels  
there might be different groups that use the TXT RR for the same  
owner name with different semantics. In other words there is  
opportunity for collisions.

One could have started using SRV techniques with TXT RRs with owner  
names like _sip._udp._srv.example.com. That would have worked and  
would have had more or less the same properties as the use of SRV RRs  
today.

So the difference in trade-off here is, I think, between sub-typing  
that is needed in the the application of SRV and sub-typing the TXT  
RR for use with different applications.

>> convention and

I used a platitude :-) I seem to do that all the time :-)

> I like your wording here.  I think it is simple, clear and correct.

Thanks for the compliment. But I also hope that there is a bit more  
elaborate wording that refers to dns-choices and explains that TXT  
RRs are the least optimal choice.

I hope it is somewhat clear what I mean.

--Olaf

[1] http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-2929bis/draft- 
ietf-dnsext-2929bis-03.txt

PS. I will be leaving for vacation soon but I wanted to reply before  
I leave; therefore I only replied on a few main points. I am not able  
to put more attention to this thread in the next 4 weeks.

PPS. oh by the way. DNSEXT has a last call on RFC2929bis [1] that  
document is relevant to this discussion, it explains how to obtain a  
new typecode.

PPS.  On a less serious note:  Bert's Secure Reverse Polish DNS  
Calculator really abuses the namespace but it works :-) ( dig 1.1.+. 
8.sin.rp.secret-wg.org TXT )

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Jul 2006 15:29:32 -0700

Olaf M. Kolkman wrote:
> I only hope we both agree that the 'domainname' namespace will have two
> registries once we create a registry for "underscored". The distributed
> registry that roots in the IANA/ICANN domain name root and this new
> registry for underscored labels.

Good point.  That perspective had not occurred to me, but of course you are right.

Alas, it is a natural outgrowth of having special meaning for underscore names.
Value-add formal meaning requires value-add formal registration.

>> One example of a likely point of impasse is the tendency to confuse "it
>> won't work" with "I don't like it". Hence the team doing the specification 
>> can go through it's considerations, document them, and produce a solution 
>> that will, in fact, work, but that reviewers disagree with.>
> 
> As always this goes two ways. There have been many occasions where DNS
> folk suggested that the definition of a new RR type is the best way
> forward and the folk using "TXT" said "that won't work".  Personally I
> think it is important that protocol developers try to develop protocols
> in a way that comes closest to what I, and many or my colleagues here,
> have  started to appreciate as architecturally sound. That way can be a

Is it equally important for this group to wonder at the long-term poor track
record, in getting new RRs to reach critical mass in a timely fashion?

> little bit more certain that the DNS can scale just a bit

If a particular proposal has real scaling problems, then their details can be
stated clearly and compellingly.  Not as a principle but as a specific,
mechanical implication of the particular design.

At that point, "it won't work" becomes a pretty obvious reality for the proposal...

>> existing one is a particularly sensitive point that often confuses "it 
>> won't work" with "I don't like it".>
> 
> I think that in this space it is more about finding the balance between
> "a hack that works" and an architecturally sound solution. Again a tradeoff.

yup.

> 
>> It occurs to me that we also have to ask how much extra burden to impose on
>> the design team and working group, compared with typical IETF specification
>> work. As a rule, the IETF does not require documenting trade-off
>> discussions. Although being able to point to such discussions is sometimes
>> called for, it is not a rule. The rule is that a solution must work,
>> according to a variety of definitions of "work".
> 
> That definition should IMHO include that it does not break something else.

SRV "breaks" wildcard.  Should we deprecate SRV?

> The point that I am trying to make is that for the SRV record this makes
> sense; roughly speaking for SRV RRs the underscored labels have always
> had specified semantics. 

In terms of DNS history, SRV is quite recent, so I am not sure what you mean by
"always".  My reading of the SRV specification is that it is, in fact, ambiguous
about the specific tables of names that it is citing.  This prompts me to
suspect that the SRV specification is really specification of a template, and
that particular uses of that template need their own specification, citing the
specific underscore names being covered.

(It was only the process of writing the -attrleaf draft and reviewing the SRV
spec closely that led me to that conclusion.  I am hoping that someone will
point out how that conclusion is incorrect, since the SRV has always struck me
as being intended to enable its use for a broad class of services, without the
overhead of specifying the lookup mechanism for each one in detail.)

> For TXT RRs this has not been the case and even
> when one uses a registry for the underscored labels there might be
> different groups that use the TXT RR for the same owner name with
> different semantics. In other words there is opportunity for collisions.

You appear to be saying that two different groups have defined different
semantics for the TXT record, under *the same* underscore name.  I was not aware
that this had happened.

> names like _sip._udp._srv.example.com. That would have worked and would
> have had more or less the same properties as the use of SRV RRs today.  

I think that's what the registry idea is intended to handle.

>> Standard protocols and format are "just convention", so I'm not sure what
>> is being dismissed, here. Wherever there is supposed to be precise parsing
>> and precise semantics, formal "conventions" are needed. In this case, 
>> "formal" means standardized.>

Platitudes are nice.

d/

ps. have a fun vacation.
-- 

  Dave Crocker

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Jul 2006 10:01:05 +1000

> record, in getting new RRs to reach critical mass in a timely fashion?

	Dave,
	     we looked at the process and removed most of the hurdles.

	* We cleaned up where compress domain names could be used.
	* We formalised the handling of unknown types and classes.
	* We gave IANA guidance on how to allocate new types and classes.

	People didn't take advantage of the changes we put in place.
	They wouldn't listen to us when we said things had changed.

	In reality it is easy to get a new type and deploy new RRs.
	I've done it.  I've watched others do it.

	Mark

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Jul 2006 18:31:18 -0700

Mark, et al,

> 	They wouldn't listen to us when we said things had changed.

Why?

In all other matters of adopting IETF work, the real choice of whether to use
that work is a matter of decision by the market.  If the "we" you refer to has
not yet convinced the market of IETF developers who are designing new
applications that use the DNS, then that "we" clearly has more work to do,
beyond complaining or exercising a frustrating veto,

> 	I've done it.  I've watched others do it.

The DNS core community seems to be missing the fact that DNS "application"
groups keep considering the issue quite carefully -- since they are not unaware
of the push-back from the DNS core community -- and keep coming to a different
conclusion.  The considerations include extensive discussion with the core
community.

No doubt your own assessment is right and the application groups are wrong, but
have you considered wondering why repeated, diligent consideration by groups
interested in timely deployment of their applications come to a different
conclusion?  At the least, the core community needs to create compelling
documentation and convince the rest of the community.

However there is a meta-issue here that seems to get lost:  It is the difference
between doing things in a way that is comfortable for the folks fielding the
application, versus doing it in a way that that group has deemed more risky.  If
the former does not actually break the DNS, then what is the basis for blocking it?

4. On the matter of "it won't work" as applied to "breaking the DNS", we need to
distinguish between doing something that degrades aggregate DNS usage, versus
something that limits the DNS for a particular application.  Surely the
application-related group making the decisions should be afforded the right to
decide to accept the limitations, as long as it is clear they understand the
choice? In any event anyone complaining about their choice certainly has the
obligation to provide detailed explanation of how it will not work or how it
will degrade aggregate DNS operation.

d/

ps. I changed the Subject because this sub-thread seems to be interesting, but
unrelated to the matter of an underscore registry.

-- 

  Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Mon, 24 Jul 2006 18:59:18 -0700

On Jul 24, 2006, at 5:01 PM, Mark Andrews wrote:

>> Is it equally important for this group to wonder at the long-term  
>> poor track record, in getting new RRs to reach critical mass in a  
>> timely fashion?
>
> Dave,

Are there known deployment barriers for new RR types within the  
typical Windows XP network infrastructure?  Including numeric RR type  
codes within an API, or parsing responses should be acceptable.

-Doug
.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Jul 2006 12:32:46 +1000

> > 	They wouldn't listen to us when we said things had changed.

	Mainly FUD.
 
> beyond complaining or exercising a frustrating veto,

	We conviced the SSH wg and we now have SSHFP.

	I got DLV through relatively fast.  The hardest part was
	convincing the IESG that it was not a run around the IETF
	process.

	There was also a DLV testbed before that using a private
	type value.

> conclusion.  The considerations include extensive discussion with the core

	They keep coming back with "it won't work with Microsoft"
	because Microsoft decided to not support unknown RR properly.
	The rest of the world has basically supported unknown RR
	since word dot or has intended to support them.

	As far as I can tell this is the only arguement today against
	deploying new RRs.  Guess what.  The way to fix this problem
	is to deploy new RRs.  Force the broken implementation to
	be fixed.  If there is no pressure they won't be fixed.

> the former does not actually break the DNS, then what is the basis for blocki

	The problem is that continuing to use the TXT record *will*
	break the DNS.  IT DOES NOT SCALE.  It may not be today but
	as each application comes along and decides "we can use TXT
	records" it is one more pile of straw on the camel's back.

	We have problems today with application making "*" queries.
	These are causing caches to have to fallback to TCP.
	Sometimes even the TCP responses are truncated.  One gets
	around this by making queries for the types you want.  The
	same thing will happen with TXT record but there won't be
	a work around.  You will have to choose which protocol you
	can do without.

	TXT is a fine way to prototype.  It is not and never will
	be a long term solution.  Re-using the TXT format for the
	new RR is also almost always a sub-optimal solution but that
	is a different arguement.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Jul 2006 20:11:01 -0700

Mark,

> 	be fixed.  If there is no pressure they won't be fixed.

So your view is to coerce application protocol developers, in the hope that it
will (eventually) coerce one or more product developers?

And there is some track record of producing timely results that fix
long-standing limitations in major implementations through this technique,
without damaging adoption of the new application?

> 	records" it is one more pile of straw on the camel's back.

Given that underscore naming partitions the occurrence of TXT records to
particular semantic contexts, what -- specifically -- is the scaling problem
that you believe will happen?

> 	We have problems today with application making "*" queries.

This does not "break" the aggregate DNS.  It is a limitation in the use of the
DNS for that particular application.  The folks using underscore naming are
aware of that issue.

> 	These are causing caches to have to fallback to TCP.

1. From your text, I could not quite track what it is that is causing these
fallbacks.  Please clarify.

2. I don't recall seeing documentation of this problem, during discussions about
the use of underscore names.  (A registry for underscore naming IS what was
being discussed.)

d/
-- 

  Dave Crocker

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 25 Jul 2006 08:35:12 +0200

> 	* We gave IANA guidance on how to allocate new types and classes.

Please review the document currently in DNSEXT WGLC.

(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00971.html)

DNSEXT will need 5 reviewers (count is 2 now) and this 2929bis is  
relevant in this context.

--Olaf

---

From: Peter Koch <[email-masked]>
Date: Tue, 25 Jul 2006 18:33:57 +0200

On Tue, Jul 18, 2006 at 07:06:46AM -0700, Bill Fenner wrote:

{this has been aging in my draft folder for too long}

> a dynamic port number), but seems fairly prevalent.

the latter seems pretty straightforward to me since 'services' as in 'ports'
are the next level in hierarchy when '_udp' and '_tcp' represent the
(transport) protocol, what they obviously do. Also, there's an explicit
reference to /etc/services under "The Port number".
But I'd also agree that the fixed port requirement might seem strange.

> an _spf._udp.example.com even if _spf is reserved as the "top

This is a different issue.

> RFC 2782 rules to write an RFC in order to register the usage.

The validity of such use should be contested based on the "Applicability
Statement" in RFC 2782. But this again is a different issue.

Now, I regret having put this on the meeting agenda in a way less specific than
obviously necessary, so let's try to focus a bit and see what this group
can do about the "underscored" names:

1) There's the architectural issue of using a prefix at all, as described
   in draft-iab-dns-choices-03.txt. The limitations are described there
   as well, but there's a proposal in draft-hallambaker-pcon-00.txt
   (the beef is in 3.4 and ignore the RR types used) that is definitely
   worth an evaluation regarding coexistence of wildcards and the
   prefix scheme.

2) There's the architectural (or protocol hygiene) issue of the '_' being
   special or not and of "registering" names in an already delegated
   namespace. This also has operational and layer9 aspects.

3) SRV is up for advancement to Draft in dnsext tentatively in January.
   Some of the issues identified above, including the stale reference to
   RFC 1700, would probably best be addressed during that review process.

What I'm missing a bit is a clear problem statement as to what problem
"underscore names" can solve that a dedicated RR type doesn't. Either may
have their merits, or even a combination of both, but we'd need that problem
description first. From what I've read I'd also doubt this is mostly about
wildcards.
Instead, "easy" extension of the query structure seems to be one goal.

-Peter, sans chapeau
.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Jul 2006 14:23:58 -0400

>SRV "breaks" wildcard.  Should we deprecate SRV?

It's not the SRV record that breaks wildcard.

Look at 
ftp://ftp.isi.edu/internet-drafts/draft-ietf-dnsext-wcard-clarify-11.txt, 
section 4.5.  (BTW, This document has concluded - as far as I am 
concerned - AUTH48 and should be an RFC real soon now.)

>In terms of DNS history, SRV is quite recent,

Proposed RFC appeared in February 2000, experimental in October 1996.

Things newer than experimental SRV: DNSSEC II, DNSSEC III, Dynamic 
Update, Clarifications to the DNS, Bit Labels, EDNS0, DNS for NAT, 
NAPTR, and so on.  To "us" SRVs are not new.

>specific underscore names being covered.

That's true - the RFC on SRV really talks about a use case.

BTW - in searching for SRV's in the archives, I came across the 
chair's message on proposed work items, including an examination of 
the SRV framework.  Is this discussion evidence that such work is 
justified (to be in the charter)?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Dave Crocker <[email-masked]>
Date: Mon, 31 Jul 2006 09:51:39 -0700

> description first. 

Perhaps not.

Certainly it is interesting -- and possibly even productive -- to have the
discussion about Underscore-vs-RR.

However underscore names exist and the topic at hand is whether or how to
register them.

In this context I believe that having a discussion about architectural
preferences is a considerable distraction.

(Since underscore names come from a single namespace and since their use is
based on defined semantics, the idea that a registry is not needed strikes me as
violating basic models of network operations. So for me, the only question is
how the registry should operate.)

d/

-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 31 Jul 2006 10:05:27 -0700

Ed,

> It's not the SRV record that breaks wildcard.

Right.  I didn't mean the RR broke it.

I meant that the *specification* for SRV includes definition of underscore
naming and that the use of the underscore naming convention -- defining where to
place the SRV RR's -- *does* cause wildcarding not to work.

> NAPTR, and so on.  To "us" SRVs are not new.

I suspect this demonstrates the problematic disconnect between DNS theory and
practice that some folks have gotten sensitive to.

The issue is not when a specification is first written or even when it is first
issued as a Proposed Standard.

The issue is when it gains meaningful traction in the operational community.
(Meta-comment: This distinction is specifically where the IETF has suffered, by
operating in an open-loop manner that focuses only on publication of a document
and not on its deployment.)

Please remember that the DNS began useful operation about 20 years ago.

How long do you say that the SRV has been in "useful" operation, with support in
a substantial fraction of *deployed* DNS implementations and support in a
substantial fraction of DNS administrative operations?

Then ask the same questions for the lengthy list of additional specifications
you cited.

It will be interesting to see a basis for calling any of those details anything
but "recent".

> BTW - in searching for SRV's in the archives, I came across the chair's
> message on proposed work items, including an examination of the SRV
> framework.  Is this discussion evidence that such work is justified (to
> be in the charter)?

Which chair? (Ie, which group?)

And more importantly, what do you mean?  I do not understand your question.

d/
-- 

  Dave Crocker

---

From: Joe Abley <[email-masked]>
Date: Mon, 31 Jul 2006 14:37:47 -0400

> substantial fraction of DNS administrative operations?

There are certain other protocols for which SRV has been an integral  
component for some time: SIP, Jabber and KRB5 spring to mind.

Tracking the deployment of those protocols might be a useful way to  
start finding approximate answers to your question (e.g. hunt down  
the date at which asterisk implemented their SRV option within  
<http://svn.digium.com/view/asterisk/trunk/>).

Joe
.

---

From: Doug Barton <[email-masked]>
Date: Mon, 31 Jul 2006 13:54:52 -0700

> place the SRV RR's -- *does* cause wildcarding not to work.

Can you please explain in more detail what you mean here, and preferably
give examples? I don't think anyone is saying there is no room to improve
SRV, but if it's demonstrably broken then fixing it needs to move up the
priority list, hopefully before DNSSEC N gets wide[r] deployment.

> The issue is when it gains meaningful traction in the operational community.

I would suggest that the distinction is also not between when something
starts getting deployed, and when individual members of the IETF community
learn of it. :)

> and not on its deployment.)

On this we are in complete agreement. I would like to see more docs move
down the standards track process, but I think that topic has been covered
pretty well on ietf@ in recent months.

> substantial fraction of DNS administrative operations?

In addition to the examples that Joe cited, the one that we all love to hate
is Microsoft's early adoption of SRV records for Windows 2000 Active Directory.

hth,

Doug

-- 

	If you're never wrong, you're not trying hard enough
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Aug 2006 10:07:57 +1000

> priority list, hopefully before DNSSEC N gets wide[r] deployment.

	A better description is that the expected usage pattern
	doesn't work with wildcards.  It does however work with all
	published names provided there is enough space for the
	prepended labels.

	In most cases the issues can be solved by just publishing
	the names in use rather than depending apon a wildcard to
	match.

	Mark

---

From: Dave Crocker <[email-masked]>
Date: Mon, 31 Jul 2006 17:19:53 -0700

> 	published names provided there is enough space for the

Thank you.  Yes.

That is *much* better wording for what I meant.

d/
-- 

  Dave Crocker