Subject: Re: [port-srv-reg] Comments on svn r32

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 01 Dec 2009 11:51:55 -0500

Magnus,

(Alfred added as CC).
Thanks for your sensitivity and asking the right 
question, I was off-line during
the last few days.

How about replacing your text with something like this:

5.1.  Service Name Usage in DNS SRV Records

    [RFC2782] defines SRV records for the DNS system.  One part of the
    DNS name of an SRV record includes what is called "SERVICE", i.e., a
    symbolic name for the service.  [ogud-srv] updates [RFC2782]
    to clarify that the symbolic name ("SERVICE") to be a
    service name that has been registered
    in [PORTREG] and specifies the rules for 
deriving FQDN from the "SERVICE" name.
    This to ensure that only a single registry exists and name
    collisions can be avoided in the future.

[ogud-srv] is AH and my SRV clarification document, this way you also
get around having Ports document forwarded to 
DNS-dir/dnsext for formal review.
This does not create a new dependency as both documents need to advance at the
same time anyway.

         Olafur

At 03:38 30/11/2009, Magnus Westerlund wrote:
>Hi,
>
>My question to you and Olafur, is what more than was in the previous
>version is really needed?
>
>5.1.  Service Name Usage in DNS SRV Records
>
>    [RFC2782] defines SRV records for the DNS system.  One part of the
>    DNS name of an SRV record includes what is called "SERVICE", i.e., a
>    symbolic name for the service.  This document updates [RFC2782] in
>    order to clarify that the symbolic name ("SERVICE") SHALL only be a
>    service name as defined in this document that has been registered
>    with IANA and recorded in the port number and service name registry
>    [PORTREG].  This to ensure that only a single registry exist and name
>    collisions can be more easily avoided in the future.
>
>/Magnus
>
>
>Alexey Melnikov skrev:
> > Joe Touch wrote:
> >
> >> Alexey Melnikov wrote:
> >>
> >>
> >>> Joe Touch wrote:
> >>> [...]
> >>>
> >>>> What specifically is needed that isn't already in RFC 2782?
> >>>>
> >>>> As I noted, I have discussed this with Paul Vixie, and the intent of
> >>>> the
> >>>> restrictive language in 2782 was to ensure that protocols that
> >>>> *require*
> >>>> the use of SRVs for discovery so specify that explicitly, but not to
> >>>> prevent the use of SRVs as optional.
> >>>>
> >>>> Do we need to alter that requirement?
> >>>>
> >>> RFC 2782 didn't establish an IANA registry for SRV service names, we
> >>> want to update it to say that this registry is now the registry define
> >>> by draft-ietf-tsvwg-iana-ports. This is updating RFC 2782, even if we
> >>> are not updating the protocol bits.
> >>>
> >> Sure - that's a single sentence, though.
> >>
> >>
> > You might be right.
> >
> > Stuart, if you propose the new text, it might be easier to agree what
> > belongs to draft-ietf-tsvwg-iana-ports.
> >
> > _______________________________________________
> > Port-srv-reg mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/port-srv-reg
> >
>
>
>--
>
>Magnus Westerlund
>
>IETF Transport Area Director
>----------------------------------------------------------------------
>Multimedia Technologies, Ericsson Research EAB/TVM
>----------------------------------------------------------------------
>Ericsson AB                | Phone  +46 10 7148287
>Färögatan 6                | Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden| mailto: [email-masked]
>----------------------------------------------------------------------
>_______________________________________________
>Port-srv-reg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/port-srv-reg

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Dec 2009 09:01:49 -0800

Olafur,

The existing text already says that the unified service names can be
used in SRVs. We don't need a separate doc to state that - nor should we
want to. This one doc unifies the spaces; it should be the place where
that unification is asserted.

As to the syntax changes in your doc, that's a syntax change to SRVs
that needs to go through the DNS group as a distinct issue.

This IANA doc shouldn't specify such usage syntax changes, i.e., in how
the names are used in other contexts.

Joe

Olafur Gudmundsson wrote:
> 
> Magnus,
> 
> (Alfred added as CC).
> Thanks for your sensitivity and asking the right question, I was
> off-line during
> the last few days.
> 
>    in [PORTREG] and specifies the rules for deriving FQDN from the
> "SERVICE" name.
> get around having Ports document forwarded to DNS-dir/dnsext for formal
> review.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 01 Dec 2009 12:26:16 -0500

Joe,
I want to avoid having 2 documents updating RFC2782.

The text that Magnus proposed did only small part of the update to RFC2782
thus my counter proposal for an indirection.

         Olafur

At 12:01 01/12/2009, Joe Touch wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Olafur,
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.9 (MingW32)
>
>iEYEARECAAYFAksVS/0ACgkQE5f5cImnZrusbACgtCBirFcPis3UaCTe1aEIE6HP
>UWwAn1Q7IV3m/18oJtG9J9K9ijzrQiXv
>=ocni
>-----END PGP SIGNATURE-----

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Dec 2009 10:01:46 -0800

Hi, Olafur,

> I want to avoid having 2 documents updating RFC2782.

It seems like that raises two options:

	- 2 docs updating 2782
		- one unifying service names across all uses (IANA doc)
		- one changing the syntax of how those names are used
		in SVR records

	- 2 docs separately unifying the service names

IMO, we need to select the first option. It's hard to unify the service
names via separate documents.

Additionally, I don't believe the IANA doc, which focuses on the
registry, should include changes to protocols (DNS SRV syntax). We're
trying to cleanly focus the IANA doc on two issues:

	1) unify multiple registries
	2) update the process associated with managing that registry

Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 02 Dec 2009 10:58:29 +0100

Hi,

Olafur, what is the state of Alfred's and your's document? Is it
something that exist well enough that you can share it? It would help
make it clear what you are doing.

I want to understand if is sufficient that we define service names as a
clear concept and then your document updates RFC 2782 to use that. I am
not certain that I agree with Joe's statement below that you need to
update RFC 2782 to create a unified concept and registry. However, it
wouldn't be applied to SRV until the other document is ready.

However, I think there is a very valid concern in that you want to be
able to find the registration rules with single hop from RFC 2782. That
speaks for having both documents update RFC 2782. An alternative that I
see is tha Alfred and Olafur writes a replacement for RFC 2782 instead
of an update.

I think we need to schedule an phone conference to sort this out.
However, I do want to understand what the update to RFC 2782 really is
going to be before that.

/Magnus

-- 

Magnus Westerlund

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 04 Dec 2009 19:59:58 -0800

The issue we need to address is that the service name registry just  
lists service names, whereas in SRV records there's additional  
structure as well (the transport protocol label). To reconcile the  
two, the issue can't be ignored. We need to have some discussion. Some  
proposed text is below:

    One part of the DNS name of an SRV record includes what the SRV
    specification [RFC2782] calls "SERVICE", i.e., a symbolic name for
    the service.  This document updates that specification in order to
    clarify that the symbolic name ("SERVICE") SHALL only be a service
    name as defined in this document that has been registered with IANA
    and recorded in the port number and service name registry [PORTREG].
    This to ensure that only a single registry exist and name collisions
    can be more easily avoided in the future.

    When used in the context of DNS SRV records, the "SERVICE" label is
    the service name string (one to fifteen characters in length) as
    recorded in the port number and service name registry [PORTREG],
    preceded by an underscore.

    The "SERVICE" label in a DNS SRV record is followed by the "PROTO"
    label, which is either "_tcp" or "_udp". It is important that the
    "PROTO" label be exactly one of these two strings, and nothing else.
    Some have assumed that because the "PROTO" label can be either  
"_tcp"
    or "_udp", this suggests that other proto labels like "_sctp" or
    "_dccp" would also be valid. The problem with this approach is that
    some organizations have the "_tcp" and "_udp" subdomains delegated  
to
    a DNS server responsible for handling those records, and may even
    have dynamic DNS update [RFC 2136] [RFC 3007] enabled for those
    zones. They do not have other subdomains like "_sctp" and "_dccp"
    similarly delated. SCTP and DCCP have faced barriers to adoption in
    the wild because, "they don't go through NAT gateways." Requiring
    SCTP- and DCCP-based applications to use a different variant of SRV
    record structure that may not work everywhere would just be creating
    additional unnecessary barriers to their adoption. Consequently,
    applications that use TCP should use "_tcp" as their DNS SRV "PROTO"
    label, and all other application protocols should use "_udp."
    (In hindsight, it might have been better if the DNS SRV  
specification
    had specified something like "_srv" instead of "_tcp" and "_udp",
    but given that DNS SRV records using "_tcp" and "_udp" are already
    in widespread use, it's too late to go back and revisit that.)

    Similarly, application protocols that are created by extending or
    building on some existing protocol do not need to reflect that by
    using layered or nested labels in their DNS SRV record. For example,
    consider a Digital Audio Access Protocol (DAAP) where clients fetch
    data from servers using HTTP "GET" requests. This application
    protocol reuses the structure and syntax of HTTP, except that the
    resources the clients generally fetch are not text documents, HTML,
    JPEG images, etc., but the audio files comprising a music  
collection.
    In this case the DNS SRV service name should be "_daap._tcp", not
    "_daap._http._tcp". There is no reason to make the service name -- a
    simple opaque identifier -- into something that tries to document  
the
    internal design decisions of the protocol's creators. If a server
    were to advertise its Digital Audio Access Protocol service as
    "_daap._tcp" and a client were to try to discover instances of
    service type "_daap._http._tcp", then the client would fail to
    discover that server, thereby defeating the purpose of having  
service
    names.

    For service name registrations where the specified transport  
protocol
    is TCP, the DNS SRV "PROTO" label "_tcp" should be used. For service
    name registrations where the specified transport protocol is  
anything
    else, the DNS SRV "PROTO" label "_udp" should be used.

    For application protocols where multiple non-TCP transport protocols
    are supported, and not negotiated in-band by the application  
protocol
    itself, multiple distinct service name registrations should be
    created, registering a different unique service name for each  
variant
    of the application protocol. For example, HTTP has service name
    "http" for basic unencrypted HTTP-over-TCP, and service name "https"
    for HTTP-over-TLS-over-TCP. However for new application protocols,
    it is recommended that wherever possible they use in-band capability
    negotiation to determine whether to enable features like encryption,
    instead of having that communicated out-of-band by using different
    service names.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 05 Dec 2009 14:27:30 +0000

Stuart Cheshire wrote:

> two, the issue can't be ignored. We need to have some discussion. 
> Some  proposed text is below:

Hi Stuart,

>    and recorded in the port number and service name registry [PORTREG].

Minor: I think we agreed to change this to "service name and port number 
registry", because service name is always present and port number is 
optional.

>    Some have assumed that because the "PROTO" label can be either  "_tcp"
>    some organizations have the "_tcp" and "_udp" subdomains delegated  to
>    similarly delated.

typo: delegated

> SCTP and DCCP have faced barriers to adoption in
>    (In hindsight, it might have been better if the DNS SRV  specification

I think this paragraph (as currently written) is going to be 
controversial, especially comments about adoption (even if they are 
true). If we need to say anything about PROTO labels (and I am not 
entirely convinced we do), I would rather just say that currently only 
_tcp and _udp are used and a future document (e.g. Alfred's/Olafur's) 
may change that.

>    JPEG images, etc., but the audio files comprising a music  collection.
>    simple opaque identifier -- into something that tries to document  the
>    discover that server, thereby defeating the purpose of having  service
>    names.

I think this text doesn't belong to the IANA ports document. It might 
belong to Alfred's/Olafur's.

>    For service name registrations where the specified transport  protocol
>    name registrations where the specified transport protocol is  anything
>    are supported, and not negotiated in-band by the application  protocol
>    created, registering a different unique service name for each  variant

I think the last paragraph is good, but once again it doesn't belong to 
the IANA ports document.

---

From: Joe Touch <[email-masked]>
Date: Sat, 05 Dec 2009 10:53:55 -0800

Hi, all,

I agree with Alexey's points, but would edit further. What we need is to
say:

 - the names in the unified registry are used in SRV records

The syntax that states that they are used in front of their transport
protocols should be noted as a *reminder*, but not "specified". This is
not a protocol doc.

I.e., at most I think we need maybe 1-2 sentences added to the current text.

Joe

---

From: Alfred Hönes <[email-masked]>
Date: Sun, 6 Dec 2009 18:41:25 +0100 (MEZ)

Folks,
IMHO the text proposed by Stuart largely is out of scope of that draft.
We (Olafur and me) have been tasked to provide the needed clarifications
in the new draft-gudmundsson-dns-srv-iana-registry, henceforth referred
to as "[ogud-srv]", for brevity.

a) SRV Protocol Labels

Restrictions of the protocol label beyond the restrictions currently
imposed for the Service Name and Port Numbers registry to *only*
allow "_tcp" and "_udp" are neither needed nor do they make sense.
Recommending "_udp" for services over SCTP or DCCP would be extremely
confusing.
For instance, use of "_sctp" already has been specified in RFCs for
SIP[S] and DIAMETER; SIP already supports TCP, UDP, *and* SCTP via
Standards Track RFCs.

In 2000, RFC 2782 said (2nd para on page 3 of the RFC):

   "_TCP" and "_UDP" are at present the most useful values for this
			 ^^^^^^^^^^     ^^^^^^^^^^^^^^^^^^
   [the "Proto"] field [of the Protocol Label], though any names
						       ^^^^^^^^^
   defined by Assigned Numbers or locally may be used (as for Service)."
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

There is no reason to change that, and in particular for doing that
in a document not originating in a working group chartered for
maintenance of the DNS specifications.

Presence or absense of a delegation in the DNS does not hamper the
lookup; if there are no SRV records, a "NODATA" response will be
returned in either case, and if there are, they will be returned
in an authoritative answer.

[ogud-srv] will elaborate on the SRV Protocol Labels and reinforce
the rules from RFC 2782, specifying that SRV Protocol Labels are
constructed by prefixing a single underscore character ("_") to a
protocol name registered in the IANA "Protocols" registry, for
transport protocols supported by [PORTREG].  To be more explicit,
this currently includes "_tcp", "_sctp", "_dccp", and "_udp",
where the latter includes 'classical' UDP and UDP-lite, and this
list will automatically be expanded by a future expansion of
[PORTREG] to support new transport protocols.

b)  SRV Service Labels

The proposed text for the SRV Service Labels excludes any sensical
future devlopment.  That is inappropriate and does *not* belong into
a draft from TSV.

c)  Proposal

I suggest the following text, using the terms and their spelling from
RFC 2782 and [ogud-srv] for consistency.

(Please note that the Service Names are not used "in" SRV resource
records, but in the *owner names* of the nodes in the DNS tree where
they are stored; the syntax of owner name in the SRV RR presentation
format is not normative -- DNS implementations support various
abbreviated schemes.  Contemporary DNS terminology uses "in" for
information items contained in the *RDATA* portion of a DNS RR,
not for data common to a whole RRset or multiple RRsets.)

--------  snip  --------
5.1.  Service Name Usage for DNS SRV Records

   The DNS SRV specification [RFC2782] requests that the Service Label
   part of the owner name of DNS SRV records includes a "Service"
   element, defined to be "the symbolic name of the desired service",
   but did not state precisely which part of the IANA database (i.e.
   STD 2 when RFC 2782 was written) serves as a registry for standard
   service names.

   This document clarifies that the Service Label SHOULD be based on a
   service name as defined herein that has been registered with IANA
   and recorded in the Service Names and Port Numbers registry
   [PORTREG].  This is needed to ensure that only a single registry of
   Service Names exists and name collisions can be avoided in the
   future.

   The details of the use of Service Names from [PORTREG] in SRV
   Service Labels are specified in [RFC2782] and the documents
   updating or replacing that specification (see the companion
   document [ogud-srv] for more information).

   The details of how applications make use of DNS SRV should be
   specified in the documentation set of the application/service.  In
   the absense of such specification, prospective clients of a given
   service should not assume the existence of SRV RRs for this service
   or, if they have indications that this will be the case (e.g., by
   configuration), must assume the unextended naming scheme from
   [RFC2782] for service discovery with DNS SRV, i.e., the Service
   Label is constructed from the Service Name registered in [PORTREG]
   by prepending a single underscore character ("_").
--------  snip  --------

> * Internet Architecture Board

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Joe Touch <[email-masked]>
Date: Sun, 06 Dec 2009 10:10:41 -0800

Hi, Alfred,

I like your suggestion... see also below.

Alfred ý wrote:
...
> c)  Proposal
...
>    by prepending a single underscore character ("_").

FWIW, I really like this last paragraph.

Joe

---

From: Michelle Cotton <[email-masked]>
Date: Thu, 10 Dec 2009 14:56:05 -0800

Do I need to schedule a teleconference to get through any issues?
If so, please let me know and I will arrange it.

Thanks,

Michelle

On 12/6/09 10:10 AM, "Joe Touch" <[email-masked]> wrote:

Hi, Alfred,

Alfred ý wrote:
...
...

Joe

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 Dec 2009 20:49:47 +0000

>I like your suggestion... see also below.
(Speaking as a participant) I am happy with this as well.

>>   This document clarifies that the Service Label SHOULD be based on a
Is there a reason why this is a SHOULD and not a MUST?

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Dec 2009 16:41:23 -0800

Alexey Melnikov wrote:
...
>>>   [PORTREG].  

While we want only a single registry for services, would we care if
someone made up their own names?

Joe

---

From: Alfred Hönes <[email-masked]>
Date: Tue, 15 Dec 2009 03:05:21 +0100 (MEZ)

> someone made up their own names?

I apologize for slight confusion caused by several overlapping
threads on related topics.  I already had responded to Alexey
giving the followinf considerations and comments on his question
quoted above:

[AH]:
> a)  Otherwise, a couple of existing Standards Track RFCs would have
>     to be obsoleted immediately.  Is that desired?
>     I would prefer to give the 'responsible' authors / WGs enough time
>     to reconsider their requirements and current deployment and revise
>     their own specifications based on the new rules, once these are out.
> 
> b)  Can we enforce a MUST at layer 8 and above?
>     Even a MUST could not force DNS zone admins to reject other labels.
>     There's no protocol police, or DNS admin police, and I prefer to not
>     request human behavior with a RFC 2119 MUST that cannot be enforced.
> 
> c)  I still await response from 3GPP liaison; I've been told that this
>     might take quite some time; maybe we shouldn't outcast them if they
>     find convincing arguments to continue to use other labels.
> 
> I would not strongly object to "MUST", but it seemed reasonable
> for me to avoid it here, after considering the above arguments.

BTW:
Workin heavily on the "SRV clarify" document and the
"Service Cruft Cleanup" document, Olafur and I expect to be soon
able to circulate a pre-draft version alomost ready for posting,
but we would like to take a look at the most recent version of
your [PORTREG] document before posting, in order to avoid irritating
inconsistencies in the document set subjected to public comments.

There's another detail I stumbled over yesterday:

Shouldn't the syntax specification for Service Names in [PORTREG]
also exclude adjacent hyphens ("--"), in order to decrease the
likelyhood for collisions with current and future IDNA work?
(Doing so should not conflict with the existing data base.)

IIRC, there's a work in progress now to precisely specify what is
allowed in 'normal' DNS labels for hostnames, and it contains
provisions to reserve "--" for IDNA and future Standardization.
AFAICT, this condition is not spelled out in the predraft version
(dated Dec. 2) Magnus has sent us last week.
What do you think: should this restriction be added to the
"Service Name" bullet in your Section 8.1 ?

I already have provisionally added it to our "SRV-clarify" draft,
in the part where it informationally recalls the restrictions
on Service Names from tsvwg-iana-ports.

Kind regards,
  Alfred Hönes.

--

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Dec 2009 08:47:33 -0800

Alfred � wrote:
...
> "Service Name" bullet in your Section 8.1 ?

It seems reasonable to avoid "--" for many reasons. However, I disagree
with using our syntax for delineation - it should be used only for
validation. We should thus add:

- --
The service name syntax MAY be used to validate a service name string,
but MUST NOT be used for any other purpose (e.g., delineation). Any
system that includes a service name inside a longer string is itself
responsible for delineating the service name.  Such systems MUST NOT
rely on the syntax of a service name alone for such delineation.
- --

Joe

---

From: Alfred Hönes <[email-masked]>
Date: Tue, 15 Dec 2009 18:49:51 +0100 (MEZ)

> rely on the syntax of a service name alone for such delineation.

The only property we need for "delineation" is the absence of
underscore ("_") characters in Service Names.  That property is
granted by text in many parts of your draft -- among other, the
corrective actions on legacy registrations described in Section 10.1.

Can you agree on that invariant?

I have crafted ABNF [RFC5234] for inclusion in our "SRV clarify" draft
(noting that tsvwg-iana-ports has precedence in case of conflict):

<artwork>
      service-name   = 1*15(l-d-h)
                       ; also conforming to the <token> rule below

      token          = ( ALPHA *( [HYPHEN] 1*ALPHANUM ) )
                     / ( *( 1*ALPHANUM [HYPHEN] ) ALPHA )

      l-d-h          = ALPHA | DIGIT | HYPHEN
      ALPHANUM       = ALPHA | DIGIT   ; A-Z, a-z, 0-9
      HYPHEN         = %x2d            ; "-"
</artwork>

Does that match your expectations?

Having normative ABNF could also be of utility for IANA, as a base
element for semi-automatical verification of registration requests.

  Alfred.

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Dec 2009 10:28:38 -0800

> Can you agree on that invariant?

It seems like SRV uses need both lack of underscore and lack of period
'.'. So long as we stick to the current definition, that's fine.

> Does that match your expectations?

I don't want to omit double hyphens as a syntax rule to support an
unknown future need. I don't think IANA should encourage their use, but
can't see why we would remove them.

I prefer a simpler result:

token = ( ALPHA 1*( ( *l-d-h ALPHA ) ) )

However, if we agree to force a single hyphen anyway, the following may
be simpler than the above:

token = ( ALPHA 1*( *( [HYPHEN] l-d-h ) ( [HYPHEN] ALPHA ) )

> element for semi-automatical verification of registration requests.

Agreed - that might be more useful in the main doc.

Joe

---

From: Alfred Hönes <[email-masked]>
Date: Tue, 15 Dec 2009 20:23:45 +0100 (MEZ)

Joe Touch wrote:
> Alfred Hönes wrote:

Joe,
you caught me!
Of course, the absence of periods was a deeply buried assumption
for us, as we discuss DNS labels.  More precisely, essentially
l-d-h was taken as given.
(Purists might argue that literal periods indeed *can* be inserted
in DNS labels by using "\xxx" notation in the presentation form,
but we do not want to sow confusion!)

> unknown future need. I don't think IANA should encourage their use,
> but can't see why we would remove them.
>

Hmm, no trailing digit allowed, or leading digit?

That would exclude quite some of the conversion results for entries
picked from the table in 10.1, e.g.  914c-g  or  z39-50 !
Hence, somehow   ALPHA  -->  ALPHANUM   is needed.

> However, if we agree to force a single hyphen anyway, the following
> may be simpler than the above:
>

Ooops.  This does not parse -- parentheses don't match.
I assume dropping the first '('.
Then the above concern applies again.
Also this would not actually exclude adjacent hyphens; essentially you
need to replace  l-d-h  by  1*ALPHANUM  -- but that already approaches
my strawman proposal.
Finally, this version would *enforce* at least two characters.

I have revisited the current IANA database and found a few
service names not matching my strawman <token> syntax;
these are the names of the form     ("3com" *(l-d-h) DIGIT)
To allow these, another alternative is needed in the ABNF,
for instance:

     token       = ( ALPHA *( [HYPHEN] 1*ALPHANUM ) )
                 / ( *( 1*ALPHANUM [HYPHEN] ) ALPHA )
                 / ( DIGIT ALPHA *( [HYPHEN] 1*ALPHANUM ) )

or simplified:

     token       = ( [DIGIT] ALPHA *( [HYPHEN] 1*ALPHANUM ) )
                 / ( *( 1*ALPHANUM [HYPHEN] ) ALPHA )

or, looking more complicated, but also more regular and symmetric,
and being even more liberal:

     token       = *( 1*ALPHANUM [HYPHEN] ) ALPHA *( [HYPHEN] 1*ALPHANUM )

I now guess that the latter rule indeed is the best one.

Maybe, replacing  ALPHANUM  by  L-D  throughout, presentation space
can be saved.  That way I arrive at a new try for the complete ABNF
(some parentheses are redundant but may be useful for readability):

<artwork>
      service-name  = 1*15(L-D-H)
                      ; also conforming to the <token> rule below

      token         = *( 1*(L-D) [HYPHEN] ) ALPHA *( [HYPHEN] 1*(L-D) )

      L-D-H         = ALPHA | DIGIT | HYPHEN
      L-D           = ALPHA | DIGIT   ; A-Z, a-z, 0-9
      HYPHEN        = %x2d            ; "-"
</artwork>

> Agreed - that might be more useful in the main doc.

O.k.

  Alfred.

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Dec 2009 11:41:30 -0800

Alfred ý wrote:
...
> Hmm, no trailing digit allowed, or leading digit?

I was going off of what you had. You're right, though - all those ALPHAs
should be ALPHANUM.

> I assume dropping the first '('.

Yes. Sorry.

> Finally, this version would *enforce* at least two characters.

Actually, replace l-d-h above with ALPHANUM and change the second part
to [] (sorry - that's what I was thinking). Also change all the alphas
to alphanum anyway:

 token = ALPHANUM [ *( [HYPHEN] ALPHANUM ) ( [HYPHEN] ALPHANUM ) ]

There's no strict rule that excludes 34-68. All we want to exclude is
all nums, so ALSO:

token = *( l-d-h ) l-h *( l-d-h )

where	l-h = ALPHA | HYPHEN

If we had to write this all as a single rule, it's basically:

token = ( ALPHA | DIGIT 1*( [HYPHEN] ALPHANUM ) ) [ *( [HYPHEN] ALPHANUM
) ( [HYPHEN] ALPHANUM ) ]

Joe

---

From: Alfred Hönes <[email-masked]>
Date: Tue, 15 Dec 2009 22:02:07 +0100 (MEZ)

Joe,
I read "MUST NOT consist of only digits" as indicating that
at least one letter is needed, because I saw the hyphens as
a kind of punctuation, as in telephone numbers.
If that's not the intent, I'm fine with dropping that restriction;
however I fear that will ironically make the ABNF more complicated.

...
>  token = ALPHANUM [ *( [HYPHEN] ALPHANUM ) ( [HYPHEN] ALPHANUM ) ]

That would simplify to

   token = ALPHANUM *( [HYPHEN] ALPHANUM )

where both forms in turn would allow numbers (digits only).

> where  l-h = ALPHA | HYPHEN

You still have the rule "MUST NOT begin or end with a hyphen".
That rules out  <l-d-h>  as the first or last element in the ABNF
production.  The above would also allow  "-", "--", "---", etc.  !

> ) ( [HYPHEN] ALPHANUM ) ]

Hmmm. Not just that.

The trailing part       [ *( [HYPHEN] ALPHANUM ) ( [HYPHEN] ALPHANUM ) ]
clearly simplifies to     *( [HYPHEN] ALPHANUM )

Thus you would have:

  token = ( ALPHA | DIGIT 1*( [HYPHEN] ALPHANUM ) ) *( [HYPHEN] ALPHANUM )

This would obviously be matched by all numbers of two ore more digits.

Sigh.  I have no perfect idea at hands now and better think about
it a while than exchange more mails.

The only escape that comes to mind now is making use of an exception
rule -- slightly non-standard ABNF, needing escape to ABNF comment:

        token     = ALPHANUM  *( [HYPHEN] ALPHANUM )
                    ; ... but _not_ matching  1*DIGIT

Is that "socially acceptable" ?

Kind regards,
  Alfred.

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Dec 2009 13:26:23 -0800

Alfred ý wrote:
...
> This would obviously be matched by all numbers of two more more digits.

Right - tried too hard to avoid the "OR"; here's the solution:

token = ( ALPHA | *( [HYPHEN] ALPHANUM ) )
	| ( 1*DIGIT ( HYPHEN | ALPHA ) *( [HYPHEN] ALPHANUM ) )

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Dec 2009 13:50:13 -0800

> 	| ( 1*DIGIT ( HYPHEN | ALPHA ) *( [HYPHEN] ALPHANUM ) )

Minor correction to avoid "888-":

 token = ( ALPHA | *( [HYPHEN] ALPHANUM ) )
 	| (1*DIGIT ( (HYPHEN ALPHANUM) | ALPHA) *([HYPHEN] ALPHANUM) )

Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Dec 2009 14:34:36 +0100

Hi,

I have now reviewed this thread. I do support Alfred's abbreviated text
for update of the RFC 2782. However, I do think we should restructure
the text so it is clear that it is this registry, or an unregistered
name that should be registered to ensure uniqueness.

I have just committed (r35) that generates the following text:

5.1.  Service Name Syntax

   Valid service names MUST contain only these US-ASCII [ANSI.X3-4.1986]
   characters: letters from A to Z and a to z, digits from 0 to 9, and
   hyphens ("-", ASCII 0x2D or decimal 45).  They MUST be at least one
   character and no more than fifteen characters long, MUST NOT begin or
   end with a hyphen, and MUST NOT consist of only digits (in order to
   be distinguishable from port numbers, which are typically written as
   all digits).

   The service name syntax MAY be used to validate a service name
   string, but MUST NOT be used for any other purpose (e.g.,
   delineation).  Any system that includes a service name inside a
   longer string is itself responsible for delineating the service name.
   Such systems MUST NOT rely on the syntax of a service name alone for

Cotton, et al.            Expires June 21, 2010                 [Page 8]

Internet-Draft   Port Number and Service Name Procedures   December 2009

   such delineation.

   The syntax defined in ABNF [RFC5234]:

      SERVICE-NAME   = ( ALPHA / *( [HYPHEN] ALPHANUM ) )
         / (1*DIGIT ( (HYPHEN ALPHANUM) | ALPHA) *([HYPHEN] ALPHANUM) )

      ALPHA          = <See RFC 5234>
      DIGIT          = <See RFC 5234>

5.2.  Service Name Usage in DNS SRV Records

   This document clarifies that the Service Label MUST be a service name
   as defined herein.  The service name SHOULD be registered with IANA
   and recorded in the Service Names and Port Numbers registry
   [PORTREG].  This is needed to ensure that only a single registry of
   Service Names exists and name collisions can be avoided in the
   future.

   The details of the use of Service Names from [PORTREG] in SRV Service
   Labels are specified in [RFC2782] and the documents updating or
   replacing that specification (see the companion document [ogud-srv]
   for more information).

   The details of how applications make use of DNS SRV should be
   specified in the documentation set of the application/service.  In
   the absence of such specification, prospective clients of a given
   service should not assume the existence of SRV RRs for this service
   or, if they have indications that this will be the case (e.g., by
   configuration), must assume the unextended naming scheme from
   [RFC2782] for service discovery with DNS SRV, i.e., the Service Label
   is constructed from the Service Name registered in [PORTREG] by
   prepending a single underscore character ("_").

I would propose that if you have suggestions for improvement implement
them. I would like to submit a new draft to IETF as soon as possible. I
am going on vacation and not be back until the 11th of Jan. But, unless
large modifications are performed I think anyone of the authors can
submit the 04 version on Monday or Tuesday. Stating this alternatively.
It is better that you get the new version out even if I would disagree
with it. We can discuss further in other groups.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 18 Dec 2009 20:19:51 +0100 (MEZ)

> name that should be registered to ensure uniqueness.

Magnus,
thanks for the information.

Would it be possible to copy us (Olafur and me) the current version ?

This way, we can cross-check with our pending draft,
"draft-gudmundsson-dnsext-srv-clarify" -- denoted [ogud-srv] below --,
essentially waiting for this alignment.  From our working copy:

-------------------snip----------------

DNS Extensions                                            O. Gudmundsson
Internet-Draft                                             Shinkuro Inc.
Updates: 2782 (if approved)                                    A. Hoenes
Intended status: Standards Track                                  TR-Sys
Expires: June 18, 2010                                 December 15, 2009

                  Clarification of DNS SRV Owner Names
                draft-gudmundsson-dnsext-srv-clarify-00f

Abstract

   The DNS SRV record has been specified in RFC 2052 and RFC 2782 for
   use in dynamic service discovery for a domain.  These two RFCs did
   not clearly specify an IANA registry for the names of the services
   and their underlying protocols.  This document clarifies RFC 2782
   regarding the formation and use of the Service Prefix in the owner
   name of SRV records, based on the unified IANA registry for "Service
   Names and Port Numbers" established by RFC YYYY.

   [[ RFC-Editor: Please replace 'YYYY' by the RFC number assigned to
   Ref. [RFCyyyy]. ]]

...

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Problem Statement  . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Objective for this Document and its Companions . . . . . .  4
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  General Considerations for SRV Service Prefixes  . . . . . . .  6
   3.  Protocol Labels  . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Standard Service Labels  . . . . . . . . . . . . . . . . . . .  8
   5.  Service Discovery Client Considerations  . . . . . . . . . . . 10
     5.1.  Protocol Label Selection . . . . . . . . . . . . . . . . . 11
     5.2.  Service Label Selection  . . . . . . . . . . . . . . . . . 11
   6.  Provisioning of SRV records  . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   ...

-------------------snip----------------

>       ALPHANUM       = ALPHA | DIGIT   ; A-Z, a-z, 0-9

[AH]  Sorry, my mistake to insert (in some emails) the "|" characters
where "/" should have been written.  Please correct.
Further, the first alternative would still admit a leading hyphen.
I assume that the first "/" should be deleted, giving:

|       SERVICE-NAME   = ( ALPHA *( [HYPHEN] ALPHANUM ) )
|          / (1*DIGIT ( (HYPHEN ALPHANUM) / ALPHA) *([HYPHEN] ALPHANUM) )

However, the readability of the primary rule might be better if the
common trailing part of both alternatives were only written once,
giving the entire syntax as:

|       SERVICE-NAME   = ( ALPHA / (1*DIGIT ((HYPHEN ALPHANUM) / ALPHA))
|                        *([HYPHEN] ALPHANUM)
| 
|       ALPHANUM       = ALPHA / DIGIT   ; A-Z, a-z, 0-9
|       HYPHEN         = %x2d            ; "-"
|       ALPHA          = <See RFC 5234>
|       DIGIT          = <See RFC 5234>

>    as defined herein.  ...

[AH]
No, that's not true.  That contradicts the 1st and the 3rd para.
The "service name" is what goes into the registry and follows the
above syntax, right.

But the term "label" is fixed from DNS (STD 13) -- the components
of DNS names that are written with periods as separator characters
in the presentation form.
One of the changes from Olafurs (and mine) previous draft that you
wanted to insist on, and which we now accommodate, is that we stay
with "underscore labels".

Hence, the Service Label *contains* this Service Name, in that the
basic form of a Service Label is, in ABNF amending the above rules
(we use lowercase for ABFN non-terminals, as recommended):
       std-serv-label  = "_" service-name

The first paragraph gets it better, and the last paragraph below
very precisely says that.

Also, I have been firmly instructed from IETF 76 that [ogud-srv]
shall Update RFC 2782 and your draft shall make normative reference
to it, in order to decouple the responsible Areas, and to properly
serialize possible future updates to DNS specifications, and that
Normative cros-references between the two documents serve to ensure
coordinated publication.

Therefore I would like to see the above sentence replaced by:

|    [ogud-srv] clarifies that the Service Label MUST be based on a
|    service name as defined herein.  ...

Similarly, the front matter and the Abstract of the version we had
been copied needs to be adjusted as well.

>                   ...  The service name SHOULD be registered with IANA

[AH]  That's all o.k., IMHO.

> with it. We can discuss further in other groups.

We will update [ogud-srv] to now admit telephone-number style
service names like "0800-666-123" as specified by the prose and
ABNF in your 5.1 above.  Olafur will circulate the pre-draft
(or directly submit it to the Secretariat) after another
cross-check with your updated version.

Kind regards,
  Alfred Hönes.

--