Subject: Re: [port-srv-reg] Text to send port registrants and some questions

From: Stuart Cheshire <[email-masked]>
Date: Tue, 22 Sep 2009 19:53:15 -0700

On 2 Sep, 2009, at 12:34, Michelle Cotton wrote:

> Hi Stuart...
> Just checking to see if you had a chance to look at this.

Sorry. Thanks for the reminder.

> 1) In the ServiceTypes registry that Stuart provided, there were 2  
> additional columns that we don’t have in the proposed version of  
> the registry
> They are:
>   - Defined TXT keys
>   - Discovery Protocol
> If these are removed, is this OK?

There is no "Discovery Protocol".

Perhaps you mean "Protocol description"? That would be covered by the  
"Reference" requirement.

Similarly, the list of defined TXT keys would also be covered by the  
"Reference" requirement.

> 2) The ServiceTypes registry that Stuart provided had a field named  
> "Primary Transport Protocol".  The information from this field will  
> be inserted into the "Protocol" field in port-numbers. Is this OK?

Yes.

In the light of recent discussions I've updated the proposed text:

--

Dear <Registrant>,

We are in the process of working to update and unify the IANA  
registry of service and port names. For details of this ongoing work  
see: <http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports>.

Service names are allowed to be up to fifteen characters long,  
conforming to traditional DNS host name rules: only lower-case  
letters, digits, and hyphens; must begin and end with lower-case  
letter or digit. Also, to reduce confusion, all-numeric service names  
are not allowed.

Because these service names will be used widely in a variety of  
programmatic contexts, including (but not limited to) DNS SRV  
records, it is important that we have consistent rules for identifier  
length and allowed character set, so that software and hardware  
implementers have clear guidance about what their implementations  
need to handle.

We plan to populate the initial registry of service names based on  
the existing "Short Name" field from existing port number  
applications. About 98% of the existing Short Names meet the  
requirements for legal service names and will be used unmodified. In  
the case of Short Names containing underscores, the service name will  
be the Short Name with the underscores replaced with hyphens. For the  
eight Short Names listed below we will create the new service names  
as shown:

     Short Name      Service Name
     whois++         whoisplusplus
     sql*net         sql-net
     cl/1            cl-1
     z39.50          z39-50
     914c/g          914c-g
     novell-lu6.2    novell-lu6-2
     EtherNet/IP-1   EtherNet-IP-1
     EtherNet/IP-2   EtherNet-IP-2

Note that in contexts such as the /etc/services file on Unix the old  
"Short Name" identifiers will be retained as valid aliases, so  
software using the old names with those APIs will continue to work.  
However, for new programmatic uses in APIs and protocols, it is  
expected that only the new service names will be used.

It is our understanding that at the present time these "Short Names"  
are generally used only as a convenient human mnemonic for referring  
to the protocol, and (apart from /etc/services and similar contexts  
where the Short Names will be maintained as aliases) are not used  
programmatically in any other contexts where confusion between the  
old "Short Names" and the new service names might cause confusion or  
incompatibility. If you believe this is not correct, and there is  
software and/or hardware already in existence whose behavior will be  
affected by the introduction of this new service name registry,  
please contact us and we will work with you to try to work out the  
best way to proceed.

--

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