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

From: Stuart Cheshire <[email-masked]>
Date: Thu, 02 Sep 2010 23:49:47 -0700

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 <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 03 Sep 2010 00:16:25 -0700

I have four final points for discussion

1. Name of the Registry

Right now the document calls it:

   Transport Protocol Port Number and Service Name Registry

However, Section 5 says:

   Service names are the unique key in the Port and Service Name registry.

Since Service names really are the primary identifier, and the port number is optional, and we expect to see more and more registrations without port numbers, would it make sense to switch the order of the words, and make it:

   Registry of Service Names and Transport Protocol Port Numbers

2. Service Name Rules

I liked Joe's earlier suggestion to disallow all-numeric service names, to avoid service names that look like a numeric port number. However, even with that rule, we still allow service names like this: "6000-6063" (looks like the X Window System port range). Do we care? We could prevent that by requiring that all service names contain at least one alphabetic character.

3. Inconsistent terminology.

We use the term "Registered Ports" in some places to mean "ports in the range 1024-49151", and in other places to mean any "port recorded by IANA in the Registry".

For example, the first meaning:

          <t>the Well Known Ports, also known as the System Ports, from 0-1023
          (assigned by IANA)</t>

          <t>the Registered Ports, also known as the User Ports, from
          1024-49151 (assigned by IANA)</t>

          <t>the Dynamic Ports, also known as the Private Ports, from
          49152-65535 (never assigned)</t>

and now the second:

      <t>It is important to note that ownership of registered port numbers and
      service names remains with IANA. For protocols developed by IETF working

      Thousands of applications and application-level
      protocols have registered ports and service names for their use, and
      there is every reason to believe that this trend will continue into the
      future.

Would it be better to strictly use the terms "System Ports" and "User Ports" to denote the ranges, and keep the term "registered port" to just mean generically, "recorded by IANA in the Registry"?

4. Aliases

The document says:

      <t>IANA is also instructed to indicate which service name aliases in the
      existing registry are the primary aliases (see <xref target="srvname"/>).</t>

Why should we burden IANA with this decision making? I bet there aren't that many. Let's just work it out ourselves, and list them in the document. I'll grep the IANA ports page and send a followup email with the list of aliased names.

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 03 Sep 2010 00:27:37 -0700

Below is the list of every service I found where more than one name is listed for a port number.

In most cases I believe these are *not* aliases. They're two different services inadvertently colliding on the port number. The service names are *not* aliases of each other in these cases because they're not the same service.

In this whole list I only see four names that look like aliases to me:

"name" looks like an alias for "nameserver".

"www" and "www-http" are aliases for "http".

"auth" may be an alias for "ident".

So it looks like we have a total of THREE service names that have aliases.

--

List of aliased service names:

name             42/tcp    Host Name Server
nameserver       42/tcp    Host Name Server

http             80/tcp    World Wide Web HTTP
www              80/tcp    World Wide Web HTTP
www-http         80/tcp    World Wide Web HTTP

cso             105/tcp    CCSO name server protocol
csnet-ns        105/tcp    Mailbox Name Nameserver

ident           113/tcp    
auth            113/tcp    Authentication Service

comsat          512/udp
biff            512/udp    used by mail system to notify users

mdqs            666/tcp	
doom            666/tcp    doom Id Software

loadav          750/udp
kerberos-iv     750/udp    kerberos version iv

accessbuilder   888/tcp    AccessBuilder
cddbp           888/tcp    CD Database Protocol

orasrv          1525/tcp    oracle
prospero-np     1525/tcp    Prospero Directory Service non-priv

tr-rsrb-p3      1989/tcp   cisco RSRB Priority 3 port
mshnet          1989/tcp   MHSnet system

stun-p3         1992/tcp   cisco STUN Priority 3 port
ipsendmsg       1992/tcp   IPsendmsg

hbci            3000/tcp   HBCI
remoteware-cl   3000/tcp   RemoteWare Client

exlm-agent      3002/tcp   EXLM Agent
remoteware-srv  3002/tcp   RemoteWare Server

stun            3478/udp   Session Traversal Utilities for NAT (STUN) port
turn            3478/udp   TURN over UDP
stun-behavior   3478/udp   STUN Behavior Discovery over UDP

stun            3478/tcp   Session Traversal Utilities for NAT (STUN) port
turn            3478/tcp   TURN over TCP
stun-behavior   3478/tcp   STUN Behavior Discovery over TCP

krb524          4444/tcp   KRB524
nv-video        4444/tcp   NV Video default

stuns           5349/tcp   STUN over TLS
turns           5349/tcp   TURN over TLS
stun-behaviors  5349/tcp   STUN Behavior Discovery over TLS

hp-pdl-datastr  9100/tcp    PDL Data Streaming Port
pdl-datastream  9100/tcp    Printer PDL Data Stream

---

From: Lars Eggert <[email-masked]>
Date: Fri, 3 Sep 2010 11:15:20 +0300

Hi,

> 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 wer…

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

> 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 chang…

Agreed.

> 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 p…

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

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

> 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 m…

(No idea either.)

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

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.

> 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

---

From: Lars Eggert <[email-masked]>
Date: Fri, 3 Sep 2010 11:17:50 +0300

Hi,

>   Registry of Service Names and Transport Protocol Port Numbers

agree that we should use one name for the registry throughout. Am OK with your proposal; the main reason I put port numbers first in the title was that historically, that was what the registry was known as, and I didn't want to confuse people.

> I liked Joe's earlier suggestion to disallow all-numeric service names, to avoid service names that look like a numeric port number. However, even with that rule, we still allow service names like…

I like that proposal.

> Would it be better to strictly use the terms "System Ports" and "User Ports" to denote the ranges, and keep the term "registered port" to just mean generically, "recorded by IANA in the Registry"?

We can also use the term "assigned" instead of "registered" in the second case.

> Why should we burden IANA with this decision making? I bet there aren't that many. Let's just work it out ourselves, and list them in the document. I'll grep the IANA ports page and send a followup…

OK.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 3 Sep 2010 11:21:02 +0300

Hi,

> stun-behavior   3478/tcp   STUN Behavior Discovery over TCP
...
> stun-behaviors  5349/tcp   STUN Behavior Discovery over TLS

TURN is a backward-compatible extension of STUN. So if a client looks up "stun", a TURN server can offer service to that client. So a TURN server that wanted to support STUN would need to register both service names.

(Similarly, stun-behavior is backwards compatible with stun.)

Lars

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 03 Sep 2010 09:31:18 +0100

>agree that we should use one name for the registry throughout. Am OK with your proposal; the main reason I put port numbers first in the title was that historically, that was what the registry was k…
BTW, Alfred also raised this point, so changing the registry name would 
keep him happier.

>>I liked Joe's earlier suggestion to disallow all-numeric service names, to avoid service names that look like a numeric port number. However, even with that rule, we still allow service names like…
Fine with me.

>We can also use the term "assigned" instead of "registered" in the second case.
Works for me.

>>Why should we burden IANA with this decision making? I bet there aren't that many. Let's just work it out ourselves, and list them in the document. I'll grep the IANA ports page and send a followup…
Is this text talking about future registrations as well? I.e. if there 
are future requests to register an alias, this requires IANA to show in 
the registry which is primary. IANA doesn't necessarily needs to make 
the decision, IANA just needs to show this somehow.

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Sep 2010 10:07:03 -0700

Stuart Cheshire wrote:
...
> 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.

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

--

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

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

--

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Sep 2010 10:20:07 -0700

>    Registry of Service Names and Transport Protocol Port Numbers

Sounds better.

> 
> 2. Service Name Rules
> 
> I liked Joe's earlier suggestion to disallow all-numeric service
> names, to avoid service names that look like a numeric port number.
> However, even with that rule, we still allow service names like this:
> "6000-6063" (looks like the X Window System port range). Do we care? We
> could prevent that by requiring that all service names contain at least
> one alphabetic character.

The point is only that a service name cannot be confused with a port
number and used in its place without lookup.

If we want to require an alpha - which would be fine - both the English
and BNF would need to be revised, AND we would need to re-scrub the
current table and create a new list of corrective aliases for legacy
names that wouldn't work, if any (I don't think there are).

> We use the term "Registered Ports" in some places to mean "ports in
> the range 1024-49151", and in other places to mean any "port recorded by
> IANA in the Registry".

The problem arises from numerous previous documents that refer to the

>           49152-65535 (never assigned)</t>

We can't fix the problem with the word "registered". We ought to avoid
using it for the IANA process.

Perhaps the word "reserved" or "assigned" for the IANA process?

I.e.:	IANA Reservations / Assignments
	reserved ports (0-49151)

> Would it be better to strictly use the terms "System Ports" and "User
> Ports" to denote the ranges,

Yes. That would help reduce the ambiguity.

> and keep the term "registered port" to just
> mean generically, "recorded by IANA in the Registry"?

We can't use that term; it's already out there to mean 'user ports'. We
should use a different term - either as suggested above or something else.

> Why should we burden IANA with this decision making? I bet there
> aren't that many. Let's just work it out ourselves, and list them in the
> document. I'll grep the IANA ports page and send a followup email with
> the list of aliased names.

Agreed.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Sep 2010 10:22:47 -0700

> So it looks like we have a total of THREE service names that have aliases.

Note that we also allowed aliases where the protocol in use can be
determined in-band (as per STUN/TURN), typically where one is legacy and
the other is the newer, backward-compatible version.

We probably want to discourage that in the future.

For the rest of these, IANA should determine which was actually assigned
and what are just squatters, and update the list accordingly.

Joe

---

From: Michelle Cotton <[email-masked]>
Date: Fri, 3 Sep 2010 12:01:49 -0700

I agree with all the changes below.
Regarding the last point, can the service name aliases for future registrations go in the notes column?

Michelle

On 9/3/10 1:31 AM, "Alexey Melnikov" <[email-masked]> wrote:

Fine with me.

Works for me.

_______________________________________________
Port-srv-reg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/port-srv-reg

---

From: Stuart Cheshire <[email-masked]>
Date: Sat, 04 Sep 2010 00:18:43 -0700

> TURN is a backward-compatible extension of STUN. So if a client looks up "stun", a TURN server can offer service to that client. So a TURN server that wanted to support STUN would need to register…

Right, and that's okay.

In this case TURN is not simply an alias for STUN. It's an extension.

A server that offers TURN on a given port also offers STUN on that port, so it should advertise both.

My point is that there's nothing to be gained by allowing variant names that are merely aliases for the exact same service.

---

From: Stuart Cheshire <[email-masked]>
Date: Sat, 04 Sep 2010 00:21:04 -0700

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

In that case, the ship has already sailed.

Network printers with embedded web servers advertise "_http._tcp"

Safari and other web browsers look for "_http._tcp"

The primary service name is "_http._tcp", and "www" is merely an alias.

---

From: Stuart Cheshire <[email-masked]>
Date: Sat, 04 Sep 2010 00:33:04 -0700

> That is correct, and always has been.

Can you give an example?

In reality, almost no application protocol actually runs over multiple transport protocols.

The only example I know that people tend to cite is DNS, and even that is not strictly the same application protocol over different transport protocols -- over TCP DNS has a two-byte length; over UDP it does not.

> in the way users interact with port indices (/etc/ports or SRVs).

Yes, there is. Safari browses for _http._tcp. Nothing browses for _www._tcp. If your web server advertises _www._tcp then nothing will find it. There's no reason to ever advertise or browse for _www._tcp.

> aliases for names that don't follow the new syntax.

And the new names are all the "primary" name to be used in SRV records and similar.

> Because we are declaring a syntax, and BNF is the only unabiguous way to

Not true. There are many ways to explain things unambiguously.

BNF is good for describing languages with recursive structure. For example, in C, an "if" statement contains an expression, and a statement. That statement can itself be another "if" statement, and so on, without limit. BNF is good at expressing this. Our service name syntax has no such recursive structure, which makes BNF a poor way of describing it.

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 06 Sep 2010 14:46:55 -0700

> a row, but that's easily fixed:

Now I'm less tired I'm going to be more blunt about my opinion here.

I don't know who added the ABNF, and it doesn't really matter, but if anyone feels like I'm picking on them specifically then I apologise.

Sometimes ABNF is appropriate, but many times when I see ABNF in an IETF document it reminds me of the pretentious people who use latin in cocktail party conversations. They're not doing it because it's a clearer way to communicate, on the contrary, they're doing it precisely because they hope the listener will have to ask to have it explained, thereby making the speaker feel smug and intellectually superior. Of course that doesn't work when (a) the speaker gets the latin wrong, and (b) the listener does actually understand latin well enough to know that.

In this case the plain English text is easier to understand than the ABNF. I have asserted that the ABNF has a mistake in it, but I'm not going to say what. Perhaps I'm bluffing? The fact that no one is really sure whether I'm bluffing makes my point: that the ABNF is hard enough to understand that no one is really confident that they truly understand what it's saying. That makes it not very helpful text to have in the document.

---

From: Joe Touch <[email-masked]>
Date: Mon, 6 Sep 2010 16:02:35 -0700

On Sep 6, 2010, at 2:46 PM, Stuart Cheshire <[email-masked]> wrote:

> In this case the plain English text is easier to understand than the ABNF. I have asserted that the ABNF has a mistake in it, but I'm not going to say what. Perhaps I'm bluffing?

If you think there is an error, either you are right or you are not. If you won't tell us what it is, we can't tell which. 

ABNF may be hard for you to understand, but for others - e.g., non-native speakers of English - it can be less ambiguous. 

It was placed in our ID to avoid the "clarify" draft from putting their interpretation in their doc, rather than citing definitive ABNF in ours.

Threatening not to tell us what you think you've found as 'blackmail' to get us to remove the abnf isn't helping either us or your argument. 

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 06 Sep 2010 23:00:07 -0700

On 6 Sep 2010, at 16:02, Joe Touch wrote:

> ABNF may be hard for you to understand

I heard someone say once that an algorithm (or protocol) design can be so simple that it obviously has no errors, or so complicated that it has no obvious errors.

The issue I'm trying to raise is not the particular error I may (or may not) have found, but the deeper concern that I'm not confident that it does not have more errors in addition to that. The issue is that unless a reasonable proportion of the IETF community can look at the ABNF definition and state with confidence that it is obviously right, then we may publish something that's not right.

Processing a computer language generally consists of tokenizing followed by parsing. Tokenizing consists of turning text into logical units; parsing consists of turning those tokens into the language's structure. ABNF is a good way of expressing parsing rules; it is often not a good way of expressing tokenizing rules. The rules for stating what's a valid service name is a tokenizing problem, not a parsing problem. The awkward and convoluted ABNF in the document reflects this poor fit.

I suspect that most people reading this document skip over the ABNF bit, so it has not had good scrutiny. It's also not adding much to the document if it's text that most readers skip over.

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 06 Sep 2010 23:33:56 -0700

> names that wouldn't work, if any (I don't think there are).

I just checked the current ports list for any service names containing text of the form "number-number", and found only three:

mil-2045-47001
ecovisiong6-1
802-11-iapp

All contain other letters as well, so it's not a problem.

I don't think this is a big shock to any of us. I would have been surprised if there were any short name that was just "number-number", and indeed there is not. That no one has registered a short name like this in the decades leading up to now is also a good sign that it would not be not an unreasonable limitation to prohibit such names in the future.

---

From: Joe Touch <[email-masked]>
Date: Tue, 07 Sep 2010 08:25:12 -0700

On 9/6/2010 11:33 PM, Stuart Cheshire wrote:
> I don't think this is a big shock to any of us. I would have been
> surprised if there were any short name that was just "number-number",
> and indeed there is not. That no one has registered a short name like
> this in the decades leading up to now is also a good sign that it
> would not be not an unreasonable limitation to prohibit such names in
> the future.

IMO, we should decide the acceptable syntax based on what we require, 
not necessarily just what has been used in the past (otherwise we'd be 
allowing ".", "+", and a few others).

The sole reason for excluding numbers-only was to require the 
translation step between service name and port number. There's no 
similar reason to exclude the "number*-number*" format.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 07 Sep 2010 09:08:06 -0700

...
> The issue I'm trying to raise is not the particular error I may (or
> may not) have found, but the deeper concern that I'm not confident that
> it does not have more errors in addition to that. The issue is that
> unless a reasonable proportion of the IETF community can look at the
> ABNF definition and state with confidence that it is obviously right,
> then we may publish something that's not right.

I believe we need to publish something, esp. since some programmers will 
want to use what we publish - or a derivation thereof - as code to 
validate the strings.

> Processing a computer language generally consists of tokenizing
> followed by parsing. Tokenizing consists of turning text into logical
> units; parsing consists of turning those tokens into the language's
> structure. ABNF is a good way of expressing parsing rules; it is often
> not a good way of expressing tokenizing rules.

The ABNF we are using includes regular expressions, which is the common 
way to express tokens.

> The rules for stating
> what's a valid service name is a tokenizing problem, not a parsing
> problem. The awkward and convoluted ABNF in the document reflects this
> poor fit.

It describes attempts to over-optimize the description to make it 
compact - which happened back in mid-Dec, and you were cc'd in that 
discussion.

I checked that thread, and we had been developing the ABNF up to a 
point, then Olafur suggested we paste in the copy from the "clarify" 
doc, which introduced the error (indicated below).

                        ^

 From our discussions back in Dec, and correcting to make this easier to 
read (From RFC5234), the intended ABNF would have been:

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

This missed the multiple hyphen case, which can be corrected easily:

       SRVNAME =  ALPHA *(*HYPHEN ALNUM)
       SRVNAME =/ 1*DIGIT ((HYPHEN ALNUM) / ALPHA) *(*HYPHEN ALNUM)

Joe

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 07 Sep 2010 17:12:53 +0100

>In this case the plain English text is easier to understand than the ABNF. I have asserted that the ABNF has a mistake in it, but I'm not going to say what. Perhaps I'm bluffing? The fact that no on…
Stuart,
I am not going to insist on having ABNF in the document if rough 
consensus is against me, but I think documents I care about (in the Apps 
Area, mostly) would need to reference ABNF for service names.

Of course the ABNF needs to be correct, if included.

---

From: Joe Touch <[email-masked]>
Date: Tue, 07 Sep 2010 11:51:50 -0700

>> That is correct, and always has been.

DNS and NFS. We review requests regularly for other numbers that do the 
same (except for formatting differences to deal with transport 
differences) in port reviews for IANA.
...
> The only example I know that people tend to cite is DNS, and even
> that is not strictly the same application protocol over different
> transport protocols -- over TCP DNS has a two-byte length; over UDP
> it does not.

The "same service" doesn't require the same packet format. Sequence
numbers and other information needed to deal with UDP's unreliable 
nature (lossy, out of order, can duplicate) are often omitted, and some 
framing information may be added to deal with TCP's lack of framing.

<> I don't like the idea of a primary alias either; there's no notion of it
> Yes, there is. Safari browses for _http._tcp. Nothing browses for _www._tcp.

We only know that nobody registered "www" in your database; we cannot 
know whether there are no apps that browse for this string.

> And the new names are all the "primary" name to be used in SRV records and similar.

IMO, there is no such thing as primary. It's ALL and ANY - register ALL, 
lookup ANY. That's the only way we know things will work.

If we are to continue to use the term "primary", we need to define what 
it is and what it means; IMO, that's a can of worms we should avoid.

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 7 Sep 2010 16:14:38 -0700

> registrations go in the notes column?

I don't think there will be any future aliases.

I don't see any reason to be allowing further creation of aliases  
that add nothing except being a new name for something else that  
already exists.

If someone says they want to register a new service name "wibble"  
which is in fact identical in all respects to "telnet", using the  
same message formats for the same purpose on the same port, then the  
answer is they're not allowed to do that because it's a bad idea.

It's like someone wanting to register IP protocol number 191 to be a  
new transport protocol identical in all respects to TCP, so that  
clients are now free to use *either* IP protocol number 6 *or* IP  
protocol number 191 to mean "TCP", and all servers have to handle  
both because a client may use either at the client's whim. And if one  
alias, why not ten or twenty different aliases for "TCP"? If someone  
wanted to do that we wouldn't allow them because it's a bad idea that  
serves no purpose.

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 7 Sep 2010 16:16:28 -0700

On 3 Sep, 2010, at 01:31, Alexey Melnikov wrote:

>>> names, to avoid service names that look like a numeric port  
>>> number. However, even with that rule, we still allow service  
>>> names like this: "6000-6063" (looks like the X Window System port  
>>> range). Do we care? We could prevent that by requiring that all  
>>> service names contain at least one alphabetic character.
>>>
>> I like that proposal.
>>
> Fine with me.

I've made this change. The text now says:

    Valid service names:

    o  MUST be at least 1 character and no more than 15 characters long

    o  MUST contain only US-ASCII [ANSI.X3-4.1986] letters 'A' - 'Z' and
       'a' - 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or
       decimal 45)

    o  MUST contain at least one letter ('A' - 'Z' or 'a' - 'z')

    o  MUST NOT begin or end with a hyphen

    The reason for requiring at least one letter is to avoid service
    names like "23" (could be confused with a numeric port number) or
    "6000-6063" (could be confused with a numeric port number range).
    Although service names may contain both upper-case and lower-case
    letters, case is ignored for comparison purposes, so both "http" and
    "HTTP" denote the same service.

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 7 Sep 2010 16:28:31 -0700

On 7 Sep, 2010, at 11:51, Joe Touch wrote:

> DNS and NFS.

DNS is 53 on TCP and 53 on UDP.

NFS is 2049 on TCP and 2049 on UDP.

Can you give an example where a given service name has *different*  
port numbers assigned for TCP and UDP?

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 7 Sep 2010 16:30:11 -0700

> We only know that nobody registered "www" in your database; we  
> cannot know whether there are no apps that browse for this string.

After about eight years of the whole world using "_http._tcp" you're  
claiming that some hermit somewhere is developing software that uses  
"_www._tcp" instead?

That's about as likely as some hermit somewhere whose TCP stack uses  
IP protocol number 191 to mean "TCP".

Good luck convincing printer companies to update their firmware to  
advertise a different service type to accommodate a non-existent web  
browser that's looking for the wrong service type. If such a web  
browser existed they'd have heard customer complaints for the last  
eight years (but of course they haven't, because this mythical web  
browser doesn't exist).

> IMO, there is no such thing as primary. It's ALL and ANY - register  
> ALL, lookup ANY. That's the only way we know things will work.

That's a terrible idea for efficiency on the network, and battery  
life, and I can't see any vendor deciding to do something so pointless.

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 7 Sep 2010 17:16:44 -0700

On 3 Sep, 2010, at 01:15, Lars Eggert wrote:

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

Does this convey our intended meaning better?

       <t>Service names are purely opaque identifiers, and no  
semantics are
       implied by any superficial structure that a given service name  
may appear
       to have. For example, a company called "Example" may choose to  
register
       service names "Example-Foo" and "Example-Bar" for its "Foo"  
and "Bar"
       products, but the "Example" company can't claim to "own" all  
service names
       beginning with "Example-", they can't prevent someone else  
registering
       "Example-Baz" for a different service, and they can't prevent  
other
       developers from using the "Example-Foo" and "Example-Bar"  
service types in
       order to interoperate with the "Foo" and "Bar" products.  
Service names are
       constructed using human-readable characters for mnemonic  
convenience for
       human developers; software should treat them as purely opaque  
identifiers
       and not attempt to parse them for any additional embedded  
meaning.</t>

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 7 Sep 2010 17:20:06 -0700

> the understanding that we're already allowed to do this and it  

Okay, deleted.

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 7 Sep 2010 17:22:26 -0700

On 3 Sep, 2010, at 10:07, Joe Touch wrote:

>> This is nonsense and must go. What is "the unextended naming  
>> scheme"? There's no mention in RFC 2782 of "extended" or  
>> "unextended" naming.
>

Okay, this is deleted too.

---

From: Joe Touch <[email-masked]>
Date: Wed, 08 Sep 2010 08:29:00 -0700

On 9/7/2010 4:28 PM, Stuart Cheshire wrote:
> Can you give an example where a given service name has *different* port
> numbers assigned for TCP and UDP?

Not yet. That's always been possible, and we need to reserve the right 
to do that to conserve the port number space.

That's the whole point of not giving out the UDP if only TCP is needed 
(and the converse) - we can assign them to other protocols later, and if 
we end up needing a corresponding port on another protocol we can assign 
a different number. If we ensured that we'd always give matching 
numbers, there would be no point to giving out only the protocols requested.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 08 Sep 2010 08:33:23 -0700

On 9/7/2010 4:30 PM, Stuart Cheshire wrote:
> That's about as likely as some hermit somewhere whose TCP stack uses IP
> protocol number 191 to mean "TCP".

Although I agree on the likelihood, simply declaring "there are no apps" 
is not how it's done. We would need to verify.

> browser that's looking for the wrong service type. If such a web browser
> existed they'd have heard customer complaints for the last eight years
> (but of course they haven't, because this mythical web browser doesn't
> exist).

They'd have heard complaints ONLY if they didn't interoperate with other 
vendors (maybe even just themselves) who do things the same way. And 
even if they had heard complaints, it's equally unlikely you would have 
known about that.

The overall point is we don't change things because of what we *think* 
is deployed; we always try to verify as thoroughly as possible.

> That's a terrible idea for efficiency on the network, and battery life,
> and I can't see any vendor deciding to do something so pointless.

The whole efficiency of registering is based on the assumption that the 
number of registrations is much smaller than the number of lookups 
(i.e., writes << reads). Given that, there's hardly significant impact 
on network or battery life, and the potential benefit in 
interoperability (since nobody KNOWS for sure what the 'primary' name 
is) could easily be worth the coding effort.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 08 Sep 2010 09:01:06 -0700

On 9/7/2010 4:14 PM, Stuart Cheshire wrote:
> I don't see any reason to be allowing further creation of aliases that
> add nothing except being a new name for something else that already exists.

The burden falls on the owner of the port. If they want to ask for 
aliases, e.g., to shift from an old product name to a new one, I can't 
see why we would care. There is impact, but only on that port anyway. 
However, I'd restrict it to the owner of the port only.

A good example of this would be the STUN/TURN stuff we discussed recently.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 08 Sep 2010 09:06:45 -0700

Hi, all,

On 9/7/2010 4:16 PM, Stuart Cheshire wrote:
>>>> However, even with that rule, we still allow service names like
>>>> this: "6000-6063" (looks like the X Window System port range). Do we
>>>> care? We could prevent that by requiring that all service names
>>>> contain at least one alphabetic character.
>>>>
>>> I like that proposal.
>>>
>> Fine with me.
>
>

But 3-4-5 can't be confused with a range, nor would 6000-45. AFAICT, 
range-like entries can and should be avoided by the registration 
procedure, the same way we avoid double hyphens that look too similar to 
single-hyphen names already registered.

FWIW, I still don't like adding the "must have at least one alpha" rule, 
but IF we keep it, here's the ABNF:

	NAME = *(1*NUM [HYPHEN]) ALPHA *([HYPHEN] 1*ALPHANUM)

> "HTTP" denote the same service.

Service names are already noted as case-insensitive. We typically record 
them in the database in lower case only; we do NOT retain any case as 
provided by the registrant to discourage the notion that case matters.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 08 Sep 2010 09:10:53 -0700

On 9/7/2010 5:16 PM, Stuart Cheshire wrote:
>>> 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.)
>
>
> <t>Service names are purely opaque identifiers, and no semantics are
> implied by any superficial structure that a given service name may appear
> to have. For example, a company called "Example" may choose to register
> service names "Example-Foo" and "Example-Bar" for its "Foo" and "Bar"
> products,but the "Example" company can't claim to "own" all service names
> beginning with "Example-", they can't prevent someone else registering
> "Example-Baz" for a different service, and they can't prevent other
> developers from using the "Example-Foo" and "Example-Bar" service types in
> order to interoperate with the "Foo" and "Bar" products.  Service names are
> constructed using human-readable characters for mnemonic convenience for
> human developers; software should treat them as purely opaque identifiers
> and not attempt to parse them for any additional embedded meaning.</t>

Yes, AFAICT. A better example might be:

	Example-foo-HTTP and Example-bar-SOAP

1) the prefix "example" isn't owned/reserved

2) the substrings "foo" and "bar" aren't owned/reserved

3) the substrings "HTTP" and "SOAP have *no* meaning at all; they do not 
indicate the presentation layer protocol over which these services operate.

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 08 Sep 2010 14:30:28 -0700

On 3 Sep 2010, at 1:31, Alexey Melnikov wrote:

> BTW, Alfred also raised this point, so changing the registry name would keep him happier.

Okay, done.

It's now "Service Name and Transport Protocol Port Number Registry" throughout.

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 08 Sep 2010 18:47:57 -0700

On 3 Sep 2010, at 1:31 AM, Alexey Melnikov wrote:

>>> Would it be better to strictly use the terms "System Ports" and  
>>> "User Ports" to denote the ranges, and keep the term "registered  
>>> port" to just mean generically, "recorded by IANA in the Registry"?
>>>

This is now also done and checked into svn.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 16 Sep 2010 11:11:36 +0200

> A good example of this would be the STUN/TURN stuff we discussed recently.

I think we should strongly recommend against alias for the first case
like http and www. However STUN and TURN are not aliases, they are
compatible services that can co-exist on the same port. Thus I wouldn't
call them aliases at all.

cheers

Magnus Westerlund

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 16 Sep 2010 11:18:03 +0200

> My point is that there's nothing to be gained by allowing variant names that are merely aliases for the exact same service.
Fully agreeing, however compatible services must be possible to register
and allowed to co-exist on the port. However, that should be allowed
currently. I think we are mostly discussing what descriptions are in the
document. I think we should clarify that we recommend against any alias
like www and http. From my perspective we can even disallow it but no
strong preference for me.

The second usage should both be endorsed and recommended when possible.

Cheers

Magnus Westerlund

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Sep 2010 09:44:40 -0700

> call them aliases at all.

Any time more than one string maps to the same port number it's a kind 
of an 'alias'. The only way for the client to know the difference is via 
in-band information.

I.e., we would allow aliases for:
	- different services
	- that can be resolved in-band

Unless BOTH of those apply, we would not allow aliases except:

	a) legacy (www, http)
	b) to support changeover to the new namespace

Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 17 Sep 2010 09:50:30 +0200

> 	b) to support changeover to the new namespace

I think we are in agreement. Are the text clear enough on this in your
view. I think we can have it improved further to make the above clear.

Cheers

Magnus Westerlund

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Sep 2010 16:04:48 -0700

> view. I think we can have it improved further to make the above clear.

I tried to do so in the text I just posted.

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 20 Sep 2010 21:08:28 -0700

On 16 Sep, 2010, at 09:44, Joe Touch wrote:

> Any time more than one string maps to the same port number it's a  
> kind of an 'alias'. The only way for the client to know the  
> difference is via in-band information.
>

I think we agree on the concept, but the terminology previously  
confused me.

When you said, "alias," I read that as meaning, "different names for  
the same service."

Now I see that when you say, "alias," you mean, "different services  
on the same port." (I'd call that a "collision", except in the  
special case of a new service which is a compatible extension to an  
old one on the same port.)

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Sep 2010 07:04:07 -0700

Hi, Stuart,

On 9/20/2010 9:08 PM, Stuart Cheshire wrote:
>> of an 'alias'. The only way for the client to know the difference is
>> via in-band information.
>>
> I think we agree on the concept, but the terminology previously confused
> me.
>
> When you said, "alias," I read that as meaning, "different names for the
> same service."
>
> Now I see that when you say, "alias," you mean, "different services on
> the same port." (I'd call that a "collision", except in the special case
> of a new service which is a compatible extension to an old one on the
> same port.)

Please see the text Lars just checked-in.

- overloading is when different service names correspond to the same 
port number, of which there are three cases:
	1- extended services with in-band resolution mechanisms
	2- legacy names for the same service
	3- names this doc phases out for syntax reasons (i.e.,
	instances of #2 this doc deliberately creates)

The current text does not use a single word to describe 1 vs 2 or 3; it 
distinguishes them in prose instead.

(The only further mod might be to remove the "Overloading occurs" in the 
first bullet, which might suggest (inadvertently) that overloading 
doesn't occur in the other two bullets; it's really in all three, as per 
the lead-in intro to the bullets).

Joe

---

From: Lars Eggert <[email-masked]>
Date: Thu, 23 Sep 2010 15:39:08 +0300

OK, so are we good to submit the revision?

Lars

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Sep 2010 14:52:28 +0200

> OK, so are we good to submit the revision?

I want to check my 15 points against the latest SVN revision. I also are
missing comments on some of my questions in that email: "Comments on SVN
revision 68".

Cheers

Magnus Westerlund

---

From: Michelle Cotton <[email-masked]>
Date: Thu, 23 Sep 2010 06:25:06 -0700

I also owe language changes for the contacts. Should be able to do  
this by tomorrow.
--Michelle

Sent from my iPhone

On Sep 23, 2010, at 5:52 AM, "Magnus Westerlund" <[email-masked] 
 > wrote: