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

[Lars Eggert <[e-mail]>]

Hi,

On 2010-9-3, at 9:49, Stuart Cheshire wrote:
> 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.

it was probably me who added that text, based on the notes from Anaheim. Sorry if I messed up.

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

Agreed.

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

General comment: This entire text on aliases is new, and I was not extremely happy even when I wrote it, because it seemed so clumsy. I'm VERY OPEN for a different way of addressing aliases. Like not permitting them for the future and only acknowledge that there are a few existing legacy ones.

Specifically for the issue you mention above, are we going to handle "www" and its aliases? If a web server doesn't register all aliases, it cannot be found by clients that e.g. look up "http".

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

I'm fine with not allowing aliases going forward.

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

(No idea either.)

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

We added it based one a community comment that said we should. I don't care very much if it remains or not, but if it does, it absolutely needs to be fixed.

>      <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.
> 
(No idea either.)

Lars