Re: [port-srv-reg] we need to make progress

[Joe Touch <[e-mail]>]

Stuart Cheshire wrote:
...
>       <t>For each service name, there may exist zero or more associated port
>       number assignments. A port number assignment associated with a service
>       name contains the transport protocol, port number and possibly additional
>       data, such as a DCCP Service Code.</t>
> 
> This implies that a given service name can have *different* port
> numbers assigned for different transport protocols.

That is correct, and always has been.

> If we really want that then a lot of the rest of the document will
> have to change too. I propose we just delete it.

Not sure it needs to be called out specifically. OK to delete, but with
the understanding that we're already allowed to do this and it shouldn't
affect anything.

>       For aliases that do not indicate a primary alias, a server is expected
>       to register itself under all aliased service names.
> 
> numbers assigned for different transport protocols. If we really want
> that then a lot of the rest of the document will have to change too. I
> propose we just delete it.

I don't like the idea of a primary alias either; there's no notion of it
in the way users interact with port indices (/etc/ports or SRVs).
However, since aliases *do* exist, I would say we should keep the latter
part, i.e.:

--

A a server is expected to register itself under all aliased service names.

--

>         <t>If the registration request is for a service name alias (see <xref
>         target="srvname"/>), IANA needs to confirm with the administrative
>         contact for the existing service name whether the registration of the
>         alias is appropriate.</t>
> 
> This is a worse idea. We should not be allowing registration of new alias names at all.

Agreed. However, note that the document itself creates a number of
aliases for names that don't follow the new syntax.

>       <t>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. </t>
> 
> I have no idea what that is talking about. It gives the sense of
> referring to something in particular, but doesn't actually say what.

Basically, it's intended to prevent attempts to parse the part between
"_" and "." in a DNS SRV record, or to parse the string of a lookup in
/etc/ports.

It's specifically intended to prevent any attempt to create hierarchical
naming within the current assignments. E.g., to prevent someone from
declaring that "--" delineates sub-names in a service name, and that
"soap--http" is "http" over "soap". It was discussed in mid-Dec 2009 on
this list. You were included in that thread (search for "syntax" in the
subject line).

Overall, the point is that the namespace of service names is flat.
Perhaps that's a better way to say it:

--

Service names represent a flat, unstructured namespace, and MUST NOT be
parsed to interpret components therein.

--

>    SRVNAME = (ALPHA / *([HYPHEN] ALNUM)) /
>              (1*DIGIT ((HYPHEN ALNUM) / ALPHA) *([HYPHEN] ALNUM))
>    ALNUM   = ALPHA / DIGIT   ; A-Z, a-z, 0-9
>    HYPHEN  = %x2d            ; "-" 
>    ALPHA   = <See [RFC5234]>
>    DIGIT   = <See [RFC5234]>
> 
> Why do we have BNF in this document? 

Because we are declaring a syntax, and BNF is the only unabiguous way to
do so.

> It's certainly a lot less clear than the plain-English explanation. 
> It's also wrong. I found at least one class of strings that it allows
> that the plain-English rules do not, and it prohibits at least one
> class of strings that the plain-English rules allow.

Can you be more specific and indicate what those each are?

I can see the error that it currently doesn't allow multiple hyphens in
a row, but that's easily fixed:

    SRVNAME = (ALPHA / *(*HYPHEN ALNUM)) /
              (1*DIGIT ((1*HYPHEN ALNUM) / ALPHA) *(*HYPHEN ALNUM))
    ALNUM   = ALPHA / DIGIT   ; A-Z, a-z, 0-9
    HYPHEN  = %x2d            ; "-"
    ALPHA   = <See [RFC5234]>
    DIGIT   = <See [RFC5234]>

The only other omission is to limit the length to 15, but that's very
difficult except as a separate BNF rule (which we could add if useful).

The current English text (as context) is:

   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).

What's missing?

> The fact that no one else noticed this just proves my point
> that BNF is impenetrable to normal human beings and almost no one can
> read that BNF description and understand it.

The English has required multiple rounds of refinement as well.
Arguably, in later email, you raise this point by asking whether the
following example should be valid:

	6000-6063

IMO, that's valid as a name because it cannot represent a single port.
If we disallow that, then we need to emend the English too.
> 
>       <t>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 <xref target="RFC2782"/> for service discovery with DNS SRV, 
>       i.e., the Service Label is constructed from the Service Name 
>       registered in <xref target="PORTREG"/> by prepending a single 
>       underscore character ("_").</t>
> 
> This is nonsense and must go. What is "the unextended naming scheme"? There's no mention in RFC 2782 of "extended" or "unextended" naming.

This refers to the appendix of the gudmundsson-dnsext-srv-clarify, and I
would agree it should be removed too.

Joe