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

[Stuart Cheshire <[e-mail]>]

On 26 Aug 2010, at 2:53, Lars Eggert wrote:

> Hi,
> 
> in Maastricht, both Stuart and Michelle/Pearl said they had pending changes against -5 (or even -04).
> 
> Can you all please edit them into the XML on our subversion server ASAP, so we know what they are?
> 
> This document needs to get published.

I just checked in a bunch of minor grammatical fixes and wordsmithing, which is great.

Unfortunately, what concerns me is that since the last time I looked at this document a while ago, a bunch of new text has been added, much of which makes no sense to me. Just when I thought we were close to being finished we seem to be going backwards. If we keep adding bad text we're never going to finish.

I'll include the text blocks in question below. What I request is that, unless someone can explain clearly what they mean and why they have to be there, they should be deleted, and then we can be finished.

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

      For aliases that do not indicate a primary alias, a server is expected
      to register itself under all aliased service names.

This is a terrible idea. Why do we want to advocate that? For aliases that do not indicate a primary alias they just can't do service discovery until the developers make up their minds and pick a primary. (And in any case, I think it's a moot point. How many aliases do we actually have in reality?)

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

      <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. Regardless, I did my PhD in message framing and the syntax of marking boundaries, and I know of no basis for the claim that paragraph is making.

   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? 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. 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. We should delete it.

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

Stuart Cheshire <[e-mail]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org