Subject: Re: [port-srv-reg] FW: Conflicts between port-numbers and Stuart Cheshire's registry

From: Stuart Cheshire <[email-masked]>
Date: Mon, 15 Aug 2011 16:03:52 -0700

First, apologies for being slow to respond. Since the Apple Developers Conference in June I got way behind on email, and I'm still catching up.

On 30 Jun 2011, at 13:12, Joe Touch wrote:

> Hi, all,
> 
> Stuart's page says:
> 
> "Before you send your email, check the IANA list of assigned port names and numbers to make sure that your chosen protocol name is not already in use for a different protocol."
> 
> However, there was never an attempt to avoid IANA port names that avoided his service registry.
> 
> AFAICT, the IANA port names should take precedence for this set. The conflicting names might be listed as "historical" or "removed due to conflict" (not "unauthorized use"), and we should try to contact the service name owners and inform them.

In principle I agree with you. As a general rule, I'd say an official IANA registry should take precedence over an unofficial registry. I'd love to just be able to tell these four developers that they got unlucky and they need to update their registrations. Unfortunately, having slept on that idea, I don't think it is going to work, for two reasons:

1. In at least three of the four cases the dns-sd registry entry was created *first*. It doesn't seem fair to tell developers who -- as far as they knew -- properly registered a unique name, that their registration has been retroactively revoked, years later.

2. There is a qualitative difference between the dns-sd service name registry and the old IANA ports list:

2a. When a developer registers a service name in the dns-sd service name registry, it's because they are actually *using* that service name string in their software. It's embedded in compiled executables. It's passed on-the-wire in packet exchanges. Changing to a new service name would result in on-the-wire incompatibility with existing deployed software. 

2b. In the old IANA ports list, the mnemonic "short name" existed (almost without exception) solely as a human convenience. It was (in almost all cases) never used by software, never passed on-the-wire, and changing it would create no on-the-wire compatibility issues.

So we're in the bizarre position asking people who had the service name first to change to a new service name, even though that's extremely disruptive for them, so that new people, who don't need the name and aren't even using it, can have it instead.

That smacks of capricious punishment towards developers who did nothing wrong.

It's also ineffective. The DNS-SD-using developers are never going to break their installed base of software. SubEthaEdit in particular has been shipping since 2003 -- they're not going to break compatibility with that existing software so that some new developer who came along six years later can have it instead -- especially when as far as we know that new developer doesn't even need or use that name.

On balance I think it's better that we try to make our IANA registry reflect reality as it actually is, rather than some fantasy of reality as we wish it would be.

What I propose we do, if others agree, is to send email to the four new (IANA ports list) registrants, informing them of the inadvertent name conflict, informing them of a new unique mnemonic "short name" that has been selected for them instead, and asking them if they know of any reason this change would affect any of their deployed software or protocols. I predict that in all likelihood the answer in these four cases will be that the name was nothing but a human mnemonic convenience (if even that) and changing it will have no impact on any deployed software or protocols.

Registration records for the four names are attached below.

Michelle, do you know what date "recipe 2240/tcp RECIPe Charlie Limoges <Charlie.Limoges&GDC4S.com>" was registered? If it was before 2007 then I'm willing to tell Daniel Taylor that he made a mistake and cannot have that name.

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

--

1.

> esp  6567/tcp   eSilo Storage Protocol
> esp  6567/udp   eSilo Storage Protocol
> #      Andrew Chernow<andrew&esilo.com>  January 2007

> esp             Extensis Server Protocol
>                 Loren Barr<lbarr at extensis.com>
>                 Protocol description: Proprietary
>                 Defined TXT keys: None

From: Loren Barr <[email-masked]>
Date: Mon, 11 Dec 2006 18:20:22 -0700
To: <[email-masked]>
Conversation: Service Type Request
Subject: Service Type Request

Hi,

I'd like to request a new service type:

1. 	short name of protocol:		esp
2.	longer description:			Extensis Server Protocol
3.	name, email:					Loren Barr, [email-masked]
4.	protocol description:			proprietary
5.	primary transport protocol:		_tcp
6.	defined TXT keys:			none

--

2.

> hydra           2374/tcp   Hydra RPC
> #                          Jacob Feisley<jacob&hydralabs.com>  21 January 2009

> hydra           SubEthaEdit
>                 TheCodingMonkeys<monkeys at codingmonkeys.de>
>                 Defined TXT keys: None

I don't have the email this far back, but this was registered around April 2003.

--

3.

> recipe  2240/tcp   RECIPe
> recipe  2240/udp   RECIPe
> #      Charlie Limoges<Charlie.Limoges&GDC4S.com>

> recipe          Recipe Sharing Protocol
>                 Daniel G. Taylor<dan at programmer-art.org>
>                 Protocol description: http://www.recipemanager.org/rsp/
>                 Defined TXT keys: http://www.recipemanager.org/rsp/rsp10draft.html#dnssd

From: Daniel Taylor <[email-masked]>
Date: Wed, 28 Nov 2007 09:42:26 -0700
To: <[email-masked]>
Conversation: Service Type Request
Subject: Service Type Request

Hello,

I would like to request a service type for a project I am working on
that supports automatic service discovery using DNS-SD. Currently we
are advertising and browsing using "_recipe._tcp" but I would like to
formalize it. Here are the six points listed on the services page:

1. recipe
2. Recipe Sharing Protocol
3. Daniel G. Taylor <[email-masked]>
4. http://www.recipemanager.org/rsp/
5. _tcp
6. http://www.recipemanager.org/rsp/rsp10draft.html#dnssd

--

4.

> xmp             5270/tcp   Cartographer XMP
> xmp             5270/udp   Cartographer XMP
> #                          Bobby Krupczak<rdk&krupczak.org>  03 April 2008

> xmp             Xperientia Mobile Protocol
>                 Henric Bergh<henric.bergh at xperientia.com>
>                 Protocol description: Proprietary
>                 Defined TXT keys: txtvers, user, system, nodeid, desc

From: Henric Bergh <[email-masked]>
Date: Wed, 24 Jan 2007 14:14:52 -0700
To: <[email-masked]>
Conversation: Service Type Request
Subject: Service Type Request

Hello

I want to request the following service type.

Service Type: xmp
Description: Xperientia Mobile Protocol
Responsible person: Henric Bergh [email-masked]
Protocol description: Proprietary right now, will soon be public.
Primary transport protocol: "_tcp" and "_udp"
Defined TXT keys: txtvers, user, system, nodeid, desc

--

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Aug 2011 16:31:10 -0700

Hi, Stuart,

I basically agree, with a slight wording change below (and some 
comments), and a potentially different resolution mechanism if both 
parties won't budge...

Joe

On 8/15/2011 4:03 PM, Stuart Cheshire wrote:
> 1. In at least three of the four cases the dns-sd registry entry was
> created *first*. It doesn't seem fair to tell developers who -- as far
> as they knew -- properly registered a unique name, that their
> registration has been retroactively revoked, years later.

But they could only have been told they they got an entry in an 
unofficial registry, FWIW.

> 2a. When a developer registers a service name in the dns-sd service
> name registry, it's because they are actually *using* that service name
> string in their software. It's embedded in compiled executables. It's
> passed on-the-wire in packet exchanges. Changing to a new service name
> would result in on-the-wire incompatibility with existing deployed software.

Agreed.

> 2b. In the old IANA ports list, the mnemonic "short name" existed
> (almost without exception) solely as a human convenience. It was (in
> almost all cases) never used by software, never passed on-the-wire, and
> changing it would create no on-the-wire compatibility issues.

There are plenty of cases where the short name exchanged in a protocol 
message (URLs come to mind first, but there are others). Further, 
they're used by software all the time (rather than putting constant in 
the code).

> So we're in the bizarre position asking people who had the service
> name first to change to a new service name, even though that's
> extremely disruptive for them, so that new people, who don't need the
> name and aren't even using it, can have it instead.
>

I do agree with this, but we similarly cannot take away the name of 
someone who got an allocation through the existing system.

These names too are embedded in code - sometimes code that looks things 
up in /etc/services, but they too may be hard to change.

> It's also ineffective. The DNS-SD-using developers are never going to
> break their installed base of software. SubEthaEdit in particular has
> been shipping since 2003 -- they're not going to break compatibility
> with that existing software so that some new developer who came along
> six years later can have it instead -- especially when as far as we
> know that new developer doesn't even need or use that name.
>
> On balance I think it's better that we try to make our IANA registry
> reflect reality as it actually is, rather than some fantasy of reality
> as we wish it would be.
>
> What I propose we do, if others agree, is to send email to the four
> new (IANA ports list) registrants, informing them of the inadvertent
> name conflict, informing them of a new unique mnemonic "short name" that
> has been selected for them instead, and asking them if they know of any
> reason this change would affect any of their deployed software or
> protocols. I predict that in all likelihood the answer in these four
> cases will be that the name was nothing but a human mnemonic convenience
> (if even that) and changing it will have no impact on any deployed
> software or protocols.

I would be comfortable with the following:

FIRST: Ask the IANA ports list entries if they are voluntarily willing 
to change their name, and let them suggest one (or we can if they prefer).

	NOTE: we should not "inform them" that this is happening;
	they used the official process, so whether this causes
	undue pain isn't the issue; they're technically in the clear

IF THEY REFUSE, then do the same to those on the SRV side.

I.e., voluntary changes, asking IANA ports first (as per Stuart's logic).

If there's still a conflict, unfortunately we have no choice (IMO) but 
to override the SRV names. They were unofficial.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Mon, 15 Aug 2011 21:44:45 -0400

> What I propose we do, if others agree, is to send email to the four new (IANA ports list) registrants, informing them of the inadvertent name conflict, informing them of a new unique mnemonic "shor…

Works for me!

Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 16 Aug 2011 05:30:18 -0400

On 2011-8-15, at 19:31, Joe Touch wrote:
> FIRST: Ask the IANA ports list entries if they are voluntarily willing to change their name, and let them suggest one (or we can if they prefer).
> 

I like this approach.

> If there's still a conflict, unfortunately we have no choice (IMO) but to override the SRV names. They were unofficial.

Let's have that argument if we have to. If we're lucky, the voluntary renaming resolves everything. (Yes, I dream.)

Lars

---

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Aug 2011 09:27:09 -0400

I also favor Joe's proposed approach.

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lars Eggert
> Sent: Tuesday, August 16, 2011 5:30 AM
> To: Joe Touch
> Cc: [email-masked]
> Subject: Re: [port-srv-reg] Conflicts between port-numbers 
> and StuartCheshire's registry
> 
> > FIRST: Ask the IANA ports list entries if they are 
> voluntarily willing to change their name, and let them 
> suggest one (or we can if they prefer).
> > 
> > If there's still a conflict, unfortunately we have no 
> choice (IMO) but to override the SRV names. They were unofficial.
> 
> Let's have that argument if we have to. If we're lucky, the 
> voluntary renaming resolves everything. (Yes, I dream.)
> 
> Lars

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 17 Aug 2011 15:23:33 -0700

On 15 Aug 2011, at 16:31, Joe Touch wrote:

> Hi, Stuart,
> 
> I basically agree, with a slight wording change below (and some comments), and a potentially different resolution mechanism if both parties won't budge...
> 
> Joe

I agree with your comments.

First, some good news: I have learned that SubEthaEdit no longer uses the "hydra" service type, having switched to "see" for SubEthaEdit 2. So one of our four problem names is already dealt with.

I'm going to email the other three dns-sd.org registrants, to ask if their names are still in use in software. With luck one or more will not be currently in use, resolving some of the remaining problem names.

In a couple of days, depending on what I hear back from the three dns-sd.org registrants, I'll then email the IANA ports registrants with the same question.