Subject: Re: [port-srv-reg] Survey of current service (port) names

From: Joe Touch <[email-masked]>
Date: Fri, 15 May 2009 10:37:52 -0700

Hi, all,

A few questions about this.

Our current proposed rule is:

	(L|D)((L|D|H){0,12}(L|D))?

I.e., 14 chars starting and ending with a letter or digit, but allowing
internal hyphens.

Two questions:
	- are we sticking with 14 chars, or allowing 15 to avoid
	needing to rename some below?

		we could allow 15, but assign new ones with 14
		as a preferred max

	- are we allowing initial digits?

		if not, we have to change 25 entries!

Joe

Stuart Cheshire wrote:
> Since none of us could remember this morning how many exceptions there
> are to the service name rules, I decided to do a quick check.
> 
> Note that <http://iana.org/cgi-bin/usr-port-number.pl> says:
> 
>> What SHORT name (14 CHARACTER MAXIMUM) do you want associated with
>> this port number? (For example: sums)
> 
> 
> I pulled down <http://www.iana.org/assignments/service-names> and
> <http://www.iana.org/assignments/port-numbers>
> 
> All names in the service-names list are legal according to our new
> rules: LHD, only interior hyphens, 14 characters or less.
> 
> The port-numbers list is more interesting. Of the service (port) names
> listed here:
> 
> * 10,299 entries have legal names
> *    162 were legal except for containing underscores
> *     92 were legal except for being 15 characters long
> *      7 were legal except for containing underscores *and* being 15
> characters long
> *     16 contained other invalid characters: + * / .
> *      0 were longer than 15 characters
> 
> Here are the ones with invalid characters
> 
> whois++          63/tcp    whois++
> whois++          63/udp    whois++
> sql*net          66/tcp    Oracle SQL*NET
> sql*net          66/udp    Oracle SQL*NET
> cl/1            172/tcp    Network Innovations CL/1
> cl/1            172/udp    Network Innovations CL/1
> z39.50          210/tcp    ANSI Z39.50
> z39.50          210/udp    ANSI Z39.50
> 914c/g          211/tcp    Texas Instruments 914C/G Terminal
> 914c/g          211/udp    Texas Instruments 914C/G Terminal
> novell-lu6.2    1416/tcp   Novell LU6.2
> novell-lu6.2    1416/udp   Novell LU6.2
> EtherNet/IP-1   2222/tcp   EtherNet/IP I/O
> EtherNet/IP-1   2222/udp   EtherNet/IP I/O
> EtherNet/IP-2   44818/tcp   EtherNet/IP messaging
> EtherNet/IP-2   44818/udp   EtherNet/IP messaging
> 
> If we want to be lazy, we can allow 15 characters and underscores, and
> then we only have eight to fix by hand.
> 
> If we want to be strict we have more work do to: 162 to rename by
> mapping underscore to hyphen, 92 to truncate down to 14 characters, and
> 7 to map and truncate.
> 
> Stuart Cheshire <[email-masked]>
> * Wizard Without Portfolio, Apple Inc.
> * Internet Architecture Board
> * www.stuartcheshire.org
> 
> _______________________________________________
> Port-srv-reg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/port-srv-reg

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 May 2009 15:23:40 +0200

> 		if not, we have to change 25 entries!

Hi,

Considering the feedback we have gotten I think we need to do a little
more thinking about this. Are there places where expanding this will
break things? IF not expanding is probably good.

And I think we needs to be very clear on what the legacy name was and
ensure that we make it clear that you might need to support them in
certain application. The ones with illegal characters are clearly not
usable in SRV requests, but for local operation I think we need to
specify the greater set that the legacy has.

Opinions?

cheers

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
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: Joe Touch <[email-masked]>
Date: Mon, 25 May 2009 08:45:51 -0700

> break things? IF not expanding is probably good.

Well, given the fact that there are existing 15-char names, expanding
just makes sure they all work. We're not going beyond the length of the
currently longest existing name.

> specify the greater set that the legacy has.

Right - do we declare 15 chars legacy too?

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 May 2009 13:56:19 +0200

> Right - do we declare 15 chars legacy too?

A good question. The TCPMUX protocol seems to not be defining anything
about character length, nor have any technical reasons for rejecting 15
character names. It seems like SRV is the same.

If we consider our usages of the service name there seems to be the
following:

SRV records in DNS
getservbyname()
TCPMUX

The question is if anyone of these are going to barf on 15 character
lengths. getservbyname will clearly require using the legacy name. SRV
will not be possible to use legacy names in case of illegal characters.
TCPMUX seems to be able to handle legacy, will prefer it.

So maybe allowing 15 characters is fine, while recommending that you
don't use more than 14 for the risk of encountering danger. In other
words MUST support 15 character service names, SHOULD not register
longer than 14. But declaring them legacy and give clear guidance on
when legacy will be used may be simpler and more consistent.

Cheers

Magnus Westerlund

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 29 May 2009 12:36:10 -0700

> Hi, all,
>
> I'm wondering what specific requirements limit hostnames to 14
> characters, and if it'll break anything to allow 15-character service
> names or longer.
>
> The DNS allows labels of 63 characters or less (RFC1035).

The issue I'm concerned about is not so much using service names in  
SRV records, but where we're using them in much more constrained  
contexts, like Bluetooth SDP, and 802.11u beacon frames, where packet  
sizes are severely limited.

> The ones with illegal characters are clearly not

Actually, the inverse is true. DNS is perfectly capable of carrying  
arbitrary 8-bit text. If we only cared about DNS SRV there wouldn't  
be a problem. It's the other environments where we're using this same  
namespace of service type identifiers that present problems.

Perhaps we need to allow an "old" and a "new" name? E.g. If you're  
the getservbyname API then you use the "old" name: "sql*net". If  
you're writing something new, like a new iPhone app that uses the  
"Oracle SQL*NET" protocol over Bluetooth, then you have to use the  
"new" service name, or it won't work.

(Does *ANYONE* actually use the getservbyname API? It seems to be  
just a way to make your application brittle and unreliable. E.g. if I  
were to edit "/etc/services" and change my local port number for  
"http", it would just mean that any web browser which actually uses  
the getservbyname API would instantly stop working.)

I'm okay with allowing 15 characters instead of 14. I'm okay with  
allowing underscores in names. I'm okay with allowing names to start  
or end with a digit. What I do want though is a firm rule, so  
implementers using these identifiers in novel new contexts know what  
they need to support and what they do not need to support. (And 63- 
byte service names are right out.)

---

From: Thomas Narten <[email-masked]>
Date: Fri, 29 May 2009 17:07:00 -0400

> "new" service name, or it won't work.

Overloading namespaces tends to be a Bad Idea. I fear we are
overloading the port name space, at the cost of trying to change
existing registrations -- a cost I am not convinced is justified

Create a separate new regisry for new uses is usually the
cleanest. Unless you can reuse the existing name space w/o making
*any* changes to the existing one.

> the getservbyname API would instantly stop working.)

I agree. Using the API is a Bad Idea. But that is an academic point
for us. ;-) We should not make gratuituous changes that might break
things that are working perfectly well today. We just have no business
doing that. Especially when we really don't know what the potential
consequences would be.

If we want to make retroactive changes to an existing registry, the
burden is on us to first make the case that such a change will not
cause unacceptable or unintended problems.

Thomas

---

From: Stuart Cheshire <[email-masked]>
Date: Sun, 31 May 2009 13:27:35 -0700

On 29 May 2009, at 14:07, Thomas Narten wrote:

> cleanest.

I'm afraid I have to disagree with you absolutely 100% here. Design  
for reuse is widely recognized as a good thing. It's entrenched in  
the philosophy of IP networking.

A web browser client that opens a TCP connection to port 80 gets more- 
or-less the same result regardless of whether the underlying  
technology is Ethernet, WiFi, a modem, or something else. What you're  
proposing is that when a web browser client asks to discover  
instances of the logical service "HTTP over TCP" by *name*, then it  
has to pass a different string to the API depending on whether the  
underlying technology is mDNS, or Bluetooth SDP, or WiFi 802.11u, or  
some new thing not yet invented. That's crazy, and Apple would never  
in a million years ship APIs that worked like that. A web browser  
client asks for instances of "_http._tcp", and our APIs call will  
give consistent results for *all* supported service discovery  
technologies.

> We should not make gratuituous changes that might break things that  
> are working perfectly well today. We just have no business doing  
> that. Especially when we really don't know what the potential  
> consequences would be.

Can you point to a single example of an *actual* bad consequence of  
correcting names that don't comply with the rules?

Fear of the unknown can be used as an argument against *any* change.  
Letting that fear rule us paralyses the IETF into irrelevance. The  
reason Apple has had to run its own service type registry for the  
last five years is because the IETF has been paralyzed into inaction.