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

From: Thomas Narten <[email-masked]>
Date: Mon, 01 Jun 2009 08:20:43 -0400

> > Create a separate new regisry for new uses is usually the
> > cleanest.

> I'm afraid I have to disagree with you absolutely 100% here.

I did say "usually".

> Design for reuse is widely recognized as a good thing. It's
> entrenched in the philosophy of IP networking.

Of course. But what I see happening here is not the existing port name
space being "designed for resuse", but being retractively changed to
make it easier to reuse in other contexts. That is a rather different
thing.

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

Ah, so the real motivation here is to simplify one vendors APIs??? (I
think it is important that there be agreement/understanding of the
actual problem being solve when evaluating a potential solution...)

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

This is a wrong question to ask. The IETF has a very long tradition of
preserving backwards compatability and not making gratuitous changes
that impact deployed software unless the benefits clearly are
necessary and outweigh the potential costs. 

As I've stated before, there may be deployed software that works with
existing names for services. It is rather challenging to anticipate
what would break if we changed the name of an existing service. The
IETF has rather little information about what dependencies may exist
on registrations that are 10+ years old.

And again. *why* is that change necessary? What is the benefit and
what problem does this fix?

Again, my concern stems entirely from retroactively changing the
contents of an existing registry entry. That should never be done
lightly. There may be applications using (say) get servbyname() using
one of those names.

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

Please (clearly) list the pros/cons of doing this so we can have a
proper discussion about whether the benefit justifies the cost.

Thomas

---

From: Joe Touch <[email-masked]>
Date: Mon, 01 Jun 2009 08:37:59 -0700

Thomas Narten wrote:
...
> Ah, so the real motivation here is to simplify one vendors APIs??? 
...

The real motivation here is to have a clean specification for describing
port names. Right now, they're supposed to be compatible with the DNS
already, but they're not.

All we're doing is bringing the legacy assignments up to date with a use
that has been around for quite a while, so that:

a) new assignments can be made with more clear requirements

b) new implementations no longer need to support legacy names that don't
meet those requirements

If we don't do (b), there's little point in restricting (a) to
DNS-compatible names; we can continue to allow components that would
break use in the DNS, but that then defeats the utility of existing
DNS-based solutions (Stuart's is just one of those).

Joe

---

From: Thomas Narten <[email-masked]>
Date: Mon, 01 Jun 2009 12:10:14 -0400

Where/what is the current version of the draft under discussion?
draft-ietf-tsvwg-iana-ports-02.txt expired in May.

Thomas

---

From: Joe Touch <[email-masked]>
Date: Mon, 01 Jun 2009 09:18:49 -0700

> draft-ietf-tsvwg-iana-ports-02.txt expired in May.

We were discussing the proposed text in the email which has not been
added to a draft yet.

Joe

---

From: Thomas Narten <[email-masked]>
Date: Mon, 01 Jun 2009 16:17:32 -0400

I kind of think I should hold off on further comment until I see the
latest draft, since I may be missing some obvious things.

> already, but they're not.

Well, I don't necessarily agree with this assertion, partly because I
don't know what it means. But maybe I'm just missing a bunch of stuff
that the draft will make clear.

Thomas

---

From: Joe Touch <[email-masked]>
Date: Mon, 01 Jun 2009 14:16:57 -0700

> that the draft will make clear.

I was hoping to close on this with the group before adding it to the
draft. The motivation is just as I noted:

	- we need to explain what the definition of a port name is

	- we want to unify the definition of a port name (IANA's list) 	
	and a service name (Cheshire's list)

E.g.:

IANA's applications:	14 characters max, no other requirements listed

IANA port list:		15 chars max
			case sensitive?
			starts with [a-z0-9]
			ends with and +
			middle/end chars a-z, 0-9, and any of: _-/.*

Cheshire's services:	14 chars max
			lower case only
			starts with [a-z0-9]
			middle chars a-z, 0-9, and -

- From Cheshire's summary email:
* 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 underscores *and* being 15 chars long
*     16 contained other invalid characters: + * / .
*      0 were longer than 15 characters
*     20 use upper case characters

The simplest unifications would be as follows. The answer, of course,
depends on impact - we do not want to impact currently running systems.
As a result, we might recommend:

	a) moving to one of these proposals for new names
	b) adding new alternate names compatible with the proposal
	for existing names that do not follow the proposal
	c) recommending that all new systems prefer the new names
	where possible, and report any problems that ensue

Joe

- -----------------------------------

PROPOSAL 1:		15 chars max
			case insensitive
			starts with [a-z0-9]
			middle/end chars a-z, 0-9, and -

	rationale:	there appear to be useful reasons to avoid
			non "DNS hostname" chars in port/service names

	impact:
		*    162 were legal except for containing underscores
		*     16 contained other invalid characters: + * / .
		*     20 use upper case characters
		tot: 198 changes

- -----------------------------------

PROPOSAL 2:		15 chars max
			case insensitive
			starts with [a-z0-9]
			middle/end chars a-z, 0-9, -_

`	rationale:	compatible with DNS use (?)
			fewer changes than PROPOSAL 1

	impact:
		*     16 contained other invalid characters: + * / .
		*     20 use upper case characters
		tot:  36 changes

- -----------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 02 Jun 2009 16:52:25 +0200

Hi,

I am actually getting a bit confused by this whole debate. Are the port
registries "keyword" used in the getservname? What other usages are
there real for the "keyword"?

We are trying to merge three different registries because there usage
seems to have gotten entangled. Are there other ways we could untangle
them?

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: Thomas Narten <[email-masked]>
Date: Wed, 03 Jun 2009 08:11:14 -0400

> registries "keyword" used in the getservname?

yes. And IMO, that is a problem. Whether this is "good practice" or
not is irrelevant. We have to assume there is some usage of this. So
changing the names of existing port numbers risk breaking deployed
systems.  And Michelle's draft note seems to do exactly that. It is
way premature for IANA to do this based on a draft that has not even
been published... (I am certain others in the comunity will share my
concern, if indeed, the proposal is as I understand it.)

> What other usages are there real for the "keyword"?

I gather, for Stuart, it is also an API issue. I.e., the application
somehow specifies the service (using a keyword -- presumably the port
name) and lower-level software is then free to use the equivalent of
getservbyname or construct SRV names or both. So, here, the service
name is used for things other than just naming the port. 

> seems to have gotten entangled. Are there other ways we could untangle

It is not at all clear to me that merging them is the right
approach. For SRV records, IMO, the proper approach is creating a
separate registry for SRV names. It is fine if 95% of those names
overlap with port names. But it does not need to be an absolute
requirement.

And the idea that it should be trivial for applications to use SRV
records (rather than port names) without application involvement goes
against recommendations for how to rollout SRVs. So that discussion
needs to be had as well (e.g., in dnsext).

But, I feel like I need to read the (expired) draft first, since some
of this may be covered there. So I'm waiting for the current version
of the draft to review...

Thomas

---

From: Joe Touch <[email-masked]>
Date: Wed, 03 Jun 2009 07:01:40 -0700

> concern, if indeed, the proposal is as I understand it.)

I agree with this. We could send a note out, however, asking whether a
proposed change would have an impact --- but we would need to know what
question we're asking.

> name is used for things other than just naming the port. 

What does "naming the port" mean, other than getservbyname, TCPMUX, and
SRVs?

AFAICT, all three define their use of service names to match exactly the
port name assigned by IANA when a port number is assigned. Stuart's list
is intended to provide names when numbers have not been assigned, and
uses rules that are compatible with existing IANA assignments.

The real question here is what to do about new IANA assignments, and
whether to have different rules when a port number is requested and when
it is not. E.g., the current IANA rules are incompatible with existing
assignments, so if we aren't going to change the existing assignments
(using *,/,.,+, e.g.) then we ought to allow those characters in new names.

I don't have a horse in the race of what to require, but the updated
ports doc needs to have a precise description of what is required.

>> seems to have gotten entangled. Are there other ways we could untangle

The IANA and SRV name registries are *defined* as entangled; we didn't
create this problem in this group just to write the draft or provide new
work for IANA ;-)

E.g., SRV names are defined as "IANA port names + a new list of names
without numbers"

> needs to be had as well (e.g., in dnsext).

Can you explain this? I'm not sure what "without application
involvement" means.

> of the draft to review...

If we don't converge on what the update will say on this point, then the
point will not be updated in the new draft. I've put everything I recall
about this discussion on this list. If we need additional information,
we should engage the parties involved (Randall for SCTP, Stuart for SRV
names) at the next IETF.

Joe

---

From: Thomas Narten <[email-masked]>
Date: Wed, 03 Jun 2009 10:24:24 -0400

again (I hope I am not being too repetitive here), but I am fine with
cleaning things up GOING FORWARD. I am not at all OK with making
retroactive changes to ANY existing registries. The latter requires
very careful consideration.

> E.g., SRV names are defined as "IANA port names + a new list of names

Not sure this is exactly right.

> Can you explain this? I'm not sure what "without application

See RFC 2782.

>    In general, it is expected that SRV records will be used by clients
>    for applications where the relevant protocol specification indicates
>    that clients should use the SRV record. Such specification MUST
>    define the symbolic name to be used in the Service field of the SRV
>    record as described below. It also MUST include security
>    considerations. Service SRV records SHOULD NOT be used in the absence
>    of such specification.

I.e., folk shouldn't just start using SRV without there being a spec
for the specific application defining how they are to be used. And
that spec needs to define the specific SRV label.

If we want to change this, we need to discuss this in dnsext. (I think
it is high time we had such a discussion, fwiw.)

and later

>    Service
>         The symbolic name of the desired service, as defined in Assigned
>         Numbers [STD 2] or locally.  An underscore (_) is prepended to
>         the service identifier to avoid collisions with DNS labels that
>         occur in nature.

note the "or locally".

There are specific RFCs on using SRV in specific cases (i.e.,
application-specific). I think there may be an exception to the "IANA
port name" rule, though I can't cite an example right off.

Thomas

---

From: Joe Touch <[email-masked]>
Date: Wed, 03 Jun 2009 07:53:43 -0700

> Not sure this is exactly right.

RFC2782 defines SRVs as using existing IANA names. Published in 2000,
that includes the names with non "DNS hostname" characters.

http://www.dns-sd.org/ServiceTypes.html describes Stuart's service name
registry for names without numbers, which reiterates this point.

> that spec needs to define the specific SRV label.

I'm not sure what the language means. I had read it as meaning that the
value of the strings in the SRV records need to be defined as a protocol
that must include security considerations.

Note that later in this section 2782 defines these names as case
insensitive, although earlier in the doc it defines these as IANA names
- -- which have had indicated cases for a long time. This is yet another
inconsistency.

>>         the service identifier to avoid collisions with DNS labels that

Oh, sure - just like /etc/services can override getsrvbyname vs. IANA's
allocations. We're not talking about whether a local system can override
these entries, or create new ones; were talking about what values IANA
manages.

> port name" rule, though I can't cite an example right off.

Well, using SRVs for other apps IMO presumes some sort of decision on
the impact to other apps that use the SRVs. SRVs don't include a
"requesting application" field, so there's only one list for all apps.

If what you're saying is that SRVs are not defined as being used for a
DNS version of getsrvbyname, I would say that this has been their
implicit target all along, and that can be fixed easily with a new RFC.
I'm not sure what else your concern raises, though... can you clarify?

(I can call if that'd help, and summarize our discussion to the group if
you prefer)

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 03 Jun 2009 08:24:48 -0700

> registries "keyword" used in the getservname? 

There are different registries:

	IANA's TCP/UDP number registry
	Stuart's name-only registry (SRV service types, rfc2782)
	IANA's SCTP registry
	IANA's DCCP registry

Currently, all three have different rules for names:
  IANA legacy - 15 chars, start a-z0-9, interior/end .+*/_-, use cases
  IANA new names -
	as specified on the application - 14 characters (no other rules)
	as reviewed - 14 chars, start a-z0-9, interior -, no case
  DNS SRV service types - 14 chars, start/end a-z0-9, include -, no case
  SCTP names - (no length specified) a-z0-9 .+*/_-, use cases
  DCCP names - (no length specified) a-z0-9 .+*/_-, use cases

> there real for the "keyword"?

TCPMUX defines their use. My TCP portnames draft did too (expired, but
still bumping around). Neither one is particularly sensitive to the
characters used.

> seems to have gotten entangled. Are there other ways we could untangle

SCTP and DCCP did NOT subsume existing IANA TCP/UDP names, though they
could easily have done so.

SRV names claim to subsume existing IANA ports when created, but many
are not listed. New IANA assignments are required to register with the
SRV service type registry separately.

We could redefine the names to use the IANA legacy rules, which are a
superset of all the rules. The key question at that point is whether
this breaks anything - presumably only DNS SRV use would be an issue,
since everything else either uses primarily the numbers IANA assigns
rather than the names, or uses the name as an opaque string
(getsrvbyname, TCPMUX, TCP portnames).

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 03 Jun 2009 19:14:15 -0700

On 3 Jun 2009, at 5:11, Thomas Narten wrote:

> For SRV records, IMO, the proper approach is creating a
> overlap with port names.

Fine, then let's do that. We'll define a new registry for service  
names. Those names will be used in DNS SRV records, Bluetooth SDP,  
802.11 GAS Queries, and similar service discovery protocols.

About 97.4% of the names in the new registry will be the same as the  
current port names. About 2.5% of the names will be the same as the  
current port names, but with underscores mapped to hyphens and/or  
truncated down to 14 characters. And the remaining 0.15% (16 names)  
will be manually assigned SRV names which do not use disallowed  
characters.

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

---

From: Joe Touch <[email-masked]>
Date: Wed, 03 Jun 2009 21:45:45 -0700

Stuart Cheshire wrote:
> Fine, then let's do that. We'll define a new registry for service names.
> Those names will be used in DNS SRV records, Bluetooth SDP, 802.11 GAS
> Queries, and similar service discovery protocols.
> 
> truncated down to 14 characters. And the remaining 0.15% (16 names) will
> be manually assigned SRV names which do not use disallowed characters

Given these are SRV records, is there a reason that the other characters
cannot be used?

I.e., RFC 2782 just says that:

	an underscore is prepended to the name

	the name is case insensitive

It also says that IANA service names are usable, and at the time it was
published (2000), some names like sql*net, cl/1, z39.50, and many names
with underscores had already been assigned (e.g., see RFC1700, 1994).

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 4 Jun 2009 09:06:26 -0700

> Given these are SRV records, is there a reason that the other  

The restriction is not for SRV records. It's for other uses of this  
namespace, like Bluetooth SDP and 802.11 Generic Advertisement  
Services (GAS) Queries.

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2009 09:10:07 -0700

Stuart Cheshire wrote:
> namespace, like Bluetooth SDP and 802.11 Generic Advertisement Services
> (GAS) Queries.

What is their specific restriction (length, chars, case, etc.)?

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2009 09:29:47 -0700

> Queries, and similar service discovery protocols.

I don't see why SRV names need to be restricted to the subset that
supports these other protocols. IMO, they should support existing use -
which, as described in the RFC, appears to be IANA TCP and UDP port
resolution over the DNS, which implies that existing IANA port names
should be available without modification.

If there needs to be record that is used by Bluetooth, 802.11, etc.,
that can be defined using the kind of translation below, but why would
we want to defeat the availability of existing IANA names as SRV
records, as defined in the RFC?

Joe

> be manually assigned SRV names which do not use disallowed characters.
>

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 4 Jun 2009 09:37:50 -0700

> What is their specific restriction (length, chars, case, etc.)?

The specific restriction is "as short as possible". Those pre- 
association messages are expensive and highly constrained. The fewer  
bits of entropy in a service name, the better it works. The current  
case-insensitive LDH naming gives us 5.21 bits of entropy per  
character, or 73 bits for a 14-character service name.

Ideally we want a namespace that is large enough and expressive  
enough to allow en effectively unlimited number of service names, but  
no larger.

I would argue that 2^73 is large enough, and don't see much to be  
gained by making it any larger.

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 4 Jun 2009 09:58:19 -0700

> should be available without modification.

That's NOT what RFC 2782 says, which is the reason we need a new  
document to unambiguously define the RFC 2782 namespace.

RFC 2782 says:

    record as described below.

    Service SRV records SHOULD NOT be used in the absence of such  
specification.

So, RFC 2782:

1. says SRV records SHOULD NOT blindly use the existing IANA port names,
2. says SRV records should only be used when the specification for  
the protocol in question defines the symbolic name to be used in the  
SRV, and
3. fails to define a registry to record such symbolic names, which is  
why I've had to run one for the last five years.

At the rate these discussions are converging to consensus, it  
starting to look like I might still be running that service name  
registry five years from now.

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2009 10:01:21 -0700

Stuart Cheshire wrote:
> The specific restriction is "as short as possible". Those
> pre-association messages are expensive and highly constrained. The fewer
> case-insensitive LDH naming gives us 5.21 bits of entropy per character,
> or 73 bits for a 14-character service name.
> 
> Ideally we want a namespace that is large enough and expressive enough
> to allow en effectively unlimited number of service names, but no larger.
> 
> I would argue that 2^73 is large enough, and don't see much to be gained
> by making it any larger.

I'd agree if we were making a decision from scratch, but we're not.
There are three options that appear to be present:

1) allow port names to be 15 chars, case sensitive, including _+.*/
	this allows us to have a single namespace

2) require SRV records to have a different definition than existing port
 names already use
	this basically requires the SRV namespace to be distinct,
	but then impacts its defined use in the RFC, i.e., for
	name to port number resolution of IANA-assigned names,
	because some existing IANA assignments would be invalid

3) allow SRV records to include all legacy IANA TCP/UDP allocations, as
well as SCTP, DCCP, etc., but require that all new allocations follow
the more restrictive rules
	this is basically what we're already doing with IANA TCP/UDP
	allocations, but it begs the question of impact:

	a) it could mislead developers of new code to not support
	case or _+.*/

	b) case has a big impact on entropy, but _+.* do not
	entropy per character:
		a-zA-Z0-9 and -_+.*/ 	6.07
		a-z90-9 and -_+.*/	5.36
		a-z0-9 and -		5.21

I agree we should make future allocations as short as possible, but that
can be achieved as follows:

	A) declare names case insensitive
		this doesn't appear to have a huge impact;
		there are no current case collisions, and it
		seems at best to generate only false positives
		not false negatives, so it should not break things
		that work

	B) allow all existing allocations
		this has no impact on SCTP, DCCP, or SRV
		but does allow existing IANA allocations

	C) require future allocations as follow:

		starts with a-z0-9
		other chars allow any of -_+.*/
		allow up to 15 chars,
			but with a preference of 8 or less

	D) in the ports doc, update SCTP, DCCP, SRV, TCP, UDP
	as all following the rules in C)
		i.e., the ports doc would update all these
		specs

Is that feasible? It seems preferable, as it has the least impact on
legacy assignments while allowing the broadest unification of the
namespaces.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2009 10:04:45 -0700

> 1. says SRV records SHOULD NOT blindly use the existing IANA port names,

It also says:

Overview and rationale

...
   Clients ask for a specific service/protocol for a specific domain
   (the word domain is used here in the strict RFC 1034 sense), and get
   back the names of any available servers.

and later:

   Service

That is a specified use.

> 2. says SRV records should only be used when the specification for the
> protocol in question defines the symbolic name to be used in the SRV, and

AFAICT, it does define the initial contents of the registry as above
where it refers to STD2.

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 4 Jun 2009 10:08:49 -0700

> records, as defined in the RFC?

Because the application advertising a service doesn't even know  
whether it's using DNS SRV, Bluetooth SDP, 802.11u, or something else.

This is the whole *point* of a layered or modular network  
architecture. An application using IP doesn't need to know what  
hardware is underneath, and an application using a generic service  
advertising/discovery mechanism doesn't need to know what hardware is  
underneath.

The application may not know what Bluetooth SDP is, and the Bluetooth  
engineers certainly don't know every single application that's ever  
been written, but by using a common service type name registered at  
<http://www.dns-sd.org/ServiceTypes.html> the application works over  
Bluetooth PAN without the user or developer even knowing what  
Bluetooth PAN is. This property is incredibly useful, and powerful,  
and beneficial to our customers, and we intend to continue doing it.

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 4 Jun 2009 10:15:21 -0700

> registries "keyword" used in the getservname?

In principle yes, though I don't think any real-world applications do  
this.

> What other usages are there real for the "keyword"?

None, apart from as a mnemonic name for the protocol in human  
communication.

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 4 Jun 2009 10:21:56 -0700

> 	a) it could mislead developers of new code to not support

Our APIs on Mac, Windows, iPhone and iPod *already* return  
kDNSServiceErr_BadParam for names containing these characters, so  
anyone trying to advertise a service name like "whois++" or "sql*net"  
will have found already that their code doesn't work.

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2009 10:28:51 -0700

Stuart Cheshire wrote:
> kDNSServiceErr_BadParam for names containing these characters, so anyone
> trying to advertise a service name like "whois++" or "sql*net" will have
> found already that their code doesn't work.

OK, so that's a bug that needs to be fixed, right?

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2009 10:30:14 -0700

Stuart Cheshire wrote:
> Because the application advertising a service doesn't even know whether
> it's using DNS SRV, Bluetooth SDP, 802.11u, or something else.
> 
> This is the whole *point* of a layered or modular network architecture.
> An application using IP doesn't need to know what hardware is
> underneath, and an application using a generic service
> engineers certainly don't know every single application that's ever been
> written, but by using a common service type name registered at
> Bluetooth PAN without the user or developer even knowing what Bluetooth
> PAN is. This property is incredibly useful, and powerful, and beneficial
> to our customers, and we intend to continue doing it.

I didn't disagree with the desire to unify the namespaces. I asked why
the namespace *needs* to declare some of the existing IANA allocations
as invalid. Is there a reason, other than a bug in the code?

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 4 Jun 2009 10:33:53 -0700

On 4 Jun, 2009, at 10:04, Joe Touch wrote:

>         Numbers [STD 2] or locally.

Tell me which *section* of [STD 2] you think this is referring to.

I think it's pretty obvious that the "symbolic names of services"  
would most likely appear under a heading called something like  
"SERVICE NAMES".

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 4 Jun 2009 10:36:25 -0700

> as invalid. Is there a reason, other than a bug in the code?

They're not invalid. They continue to be perfectly valid for their  
current use, as a human mnemonic string.

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2009 10:43:45 -0700

Stuart Cheshire wrote:
> I think it's pretty obvious that the "symbolic names of services" would
> most likely appear under a heading called something like "SERVICE NAMES".

I think it's fairly clear from the abstract, the description of the
system as indexing services to port numbers, etc., that this refers to
the "keywords". The examples used follow this convention - LDAP, POP,
etc.  It also specifically refers to /etc/services as being moved to the
DNS.

E.g., in RFC1700 (STD2 at the time the SRV RFC was publised), the port
tables include the term "service" in the description:

- ---
Ports are used in the TCP [RFC793] to name the ends of logical
connections which carry long term conversations.  For the purpose of
providing services to unknown callers, a service contact port is
          ^^^^^^^^                       ^^^^^^^
defined.  This list specifies the port used by the server process as
its contact port.  The contact port is sometimes called the
"well-known port".
- ---

The term "service" to describe these values predates this RFC: TCPMUX is
a "port service demultiplexer", even though the thing being demuxed is
the keyword as well.

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2009 10:45:31 -0700

> current use, as a human mnemonic string.

They're used in getsrvbyname and /etc/services as a level of
indirection, not just as a human mnemonic. Declaring some of these
values as no longer valid defeats the use of DNS SRVs to replace the
/etc/services table - which is an explicit goal indicated in the RFC.

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 4 Jun 2009 11:00:15 -0700

On 4 Jun, 2009, at 10:45, Joe Touch wrote:

> indirection, not just as a human mnemonic.

Then leave the old names in /etc/services, in addition to the new  
names, and if there is in fact any old software using getservbyname  
then that will continue to work.

By the way, you keep writing 'getsrvbyname' instead of  
'getservbyname' which is misleading, since it suggests to the  
uninitiated that 'getsrvbyname' might be something to do with SRV  
records, or might be used to retrieve SRV records, which it's not,  
and can never be.

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2009 11:07:56 -0700

Stuart Cheshire wrote:
> Then leave the old names in /etc/services, in addition to the new names,
> and if there is in fact any old software using getservbyname then that
> will continue to work.
> 
> By the way, you keep writing 'getsrvbyname' instead of 'getservbyname'
> which is misleading, since it suggests to the uninitiated that
> 'getsrvbyname' might be something to do with SRV records, or might be
> used to retrieve SRV records, which it's not, and can never be.

Yes, I meant getservbyname.

There is, however, getsrvbyname too, which is getservbyname that
interfaces to the DNS to access SRVs.

I can't understand why you can assert that getsrvbyname cannot be
redefined to access SRVs, though - esp. if you want to redefine the IANA
legacy assignments.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2009 11:09:45 -0700

> I can't understand why you can assert that getsrvbyname cannot be

Sorry - typed too fast. Of course I'm talking abouth changing
getservbyname to access SRVs.

---

From: Lars Eggert <[email-masked]>
Date: Fri, 5 Jun 2009 11:06:05 +0200

Hi,

On 2009-6-4, at 4:14, Stuart Cheshire wrote:
> names.
...
> current port names.

I still believe one registry is desirable, but I do understand the  
issues around legacy service names that aren't well-formed.

Pragmatic proposal: Why don't we simply enforce well-formedness for  
new registrations, and flag those 2.6% of the legacy entries that  
aren't currently well-formed, maybe with "legacy service name; invalid  
for use with SRV" in a new "Notes" column? Maybe with an added note  
somewhere that if someone really does want to use SRV wirth such a  
legacy service, they need to request a new service name. Or, if we  
want to be nice, maybe we pre-define a well-formed service name for  
those 2.6% of the entries.

Lars

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jun 2009 07:25:07 -0700

Lars Eggert wrote:
> Pragmatic proposal: Why don't we simply enforce well-formedness for new
> registrations, and flag those 2.6% of the legacy entries that aren't
> currently well-formed, maybe with "legacy service name; invalid for use
> with SRV" in a new "Notes" column? Maybe with an added note somewhere
> that if someone really does want to use SRV wirth such a legacy service,
> they need to request a new service name. Or, if we want to be nice,
> maybe we pre-define a well-formed service name for those 2.6% of the
> entries.

I do not support declaring any existing IANA assignements as invalid for
any reason unless there is a clear and convincing reason to do so.

So far, the reason appears to be a desire for a smaller namespace; there
are no direct incompatibility issues. As I've described, the namespace
is not substantially affected by the few odd characters; it is affected
primarily by the length and whether case is important. We can conserve
length using future guidance without declaring existing allocations invalid.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Fri, 5 Jun 2009 17:38:41 +0200

Hi,

On 2009-6-5, at 16:25, Joe Touch wrote:
>> new

maybe I was unclear. I don't want to declare the assignment invalid -  
I want to mark it as saying "won't work in a SRV RR." I mean, if  
someone tried to use one of those service names in a SRV RR, there's a  
good chance that would fail, so it's not like we're making an  
incorrect statement, right?

> are no direct incompatibility issues.

OK, I'm confused now. I thought that Stuart said that there *are*  
incompatibilities? (I may have missed something when I read through  
the long thread.)

> As I've described, the namespace

In terms of namespace, there is the broader one that encompasses  
everything that is currently in the ports registry first column, and  
then there's the 97.4% subset of that that conforms to a more  
restrictive syntax. I think we all agree that for *new* registrations,  
the service name should conform to the stricter syntax, correct?

That leaves the question on what to do with the other 2.4% of legacy  
names. One proposal was to rename them. I think that is off the table.  
Then we had the proposal to maintain service names as a separate  
registry. I admit that I still don't quite see the benefit to that. My  
proposal was to not do anything to those existing legacy registrations  
other than to highlight in the single registry that those entries  
won't work in SRV RRs. *Optionally*, we could also pre-define  
*another* service name for each of those and say something like "use  
foopp in a SRV RR for foo++".

Lars

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jun 2009 08:54:36 -0700

Lars Eggert wrote:
> maybe I was unclear. I don't want to declare the assignment invalid - I
> want to mark it as saying "won't work in a SRV RR." I mean, if someone
> tried to use one of those service names in a SRV RR, there's a good
> chance that would fail, so it's not like we're making an incorrect
> statement, right?

Exactly why should it not work in a SRV RR? There's no technical reason,
AFAICT.

> incompatibilities? (I may have missed something when I read through the
> long thread.)
> 

The only reason to use a stricter syntax would be an incompatibility
with using legacy names in SRV RRs that overrides the incompatibility
that arises when those legacy names are prohibited from SRV RRs.

If there's no such need, then there's no reason to restrict the syntax
for the future.

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 5 Jun 2009 12:31:57 -0700

> interfaces to the DNS to access SRVs.

On what OS?

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jun 2009 12:59:24 -0700

Found it by googling 'getsrvbyname' and found three implementations. One
looks integrated into minix; the other two look stand-alone (user-level).

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 5 Jun 2009 14:18:36 -0700

> looks integrated into minix; the other two look stand-alone (user- 

So, not Mac, Windows, Windows CE, iPhone, NetBSD, FreeBSD, Linux,  
VxWorks, or anything else remotely mainstream.

If this were actually in widespread use (or even insignificant  
occasional use) by application writers, there would be demand for it  
on at least one of those operating systems. This seems like pretty  
strong evidence that there is NOT widespread use of getsrvbyname.

I'm still not seeing any evidence of any actual deployed use of these  
port number 'keywords' in any programmatic APIs, apart from reading / 
etc/services, which is handled by keeping the old names around as  
aliases.

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jun 2009 14:33:18 -0700

> VxWorks, or anything else remotely mainstream.

Any of these can be done trivially in user space, embedded in an
application without any particular participation by the OS.

> occasional use) by application writers, there would be demand for it on
> at least one of those operating systems. This seems like pretty strong
> evidence that there is NOT widespread use of getsrvbyname.
> 
> port number 'keywords' in any programmatic APIs, apart from reading
> /etc/services, which is handled by keeping the old names around as aliases.

If the point is to define a capability that is not tied to services (as
in /etc/*services*, then SRV records are misnamed at least, and I agree
should have a different independent namespace.

That also means any attempt to try to encourage use of SRV records for
IANA service discovery is moot - if it won't use the same namespace, it
can't be an IANA discovery service. That use is my only interest in
exploring this issue, or being involved in SRVs at all. If we're
explicitly decoupling it, then IMO RFC2782 needs an update (since that's
decidedly not the intent I got from reading it).

Note, though, that until RFC2782 is revised, the existing IANA service
names trump any new definitions, as noted therein:

	If Assigned Numbers names the service
        indicated, that name is the only name which is legal for SRV
        lookups.

Joe

---

From: Thomas Narten <[email-masked]>
Date: Fri, 05 Jun 2009 18:08:42 -0400

getservbyname() is a standard part of unix... was part of the original
and early BSD distros... I have a man page for it on the linux system
I'm sending this from.

Thomas

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jun 2009 15:27:49 -0700

> and early BSD distros... I have a man page for it on the linux system

We're talking about getSRVbyname (capitalization mine).

getservbyname indexes /etc/services

getSRVbyname indexes the DNS SRV records for (AFAICT) the same purpose
as getservbyname

IMO, the ability to implement getservbyname as getSRVbyname (or replace
getservbyname with getSRVbyname) seems to be the intent of SRVs in the
first place, and I'm reluctant to toss it out by assuming that the SRV
namespace does not include as a subset the IANA TCP/UDP service keywords.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Mon, 8 Jun 2009 11:35:08 +0300

> Exactly why should it not work in a SRV RR? There's no technical  

Because they contain characters that are invalid for DNS names.

Lars

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Jun 2009 06:48:04 -0700

> Because they contain characters that are invalid for DNS names.

They contain names that are invalid as DNS *host* names. But DNS SRV RRs
don't name hosts; they name services.

Services are used in a format of
	_service._proto.host
e.g.:
	_ldap._tcp.example.com

This means that the only string that would be problematic inside service
names would be "._", which should be described as an issue and avoided
in future assignments, but does not currently exist.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Mon, 8 Jun 2009 19:08:21 +0300

Hi,

...
> in future assignments, but does not currently exist.

Ah, I think I finally get what you are saying - SRV RRs aren't  
restricted in the same way host names are. Which is why all the  
service names in the current ports registry are usable with SRV RRs.

Which seems to be true:

[eggert@lars: ~] host -t srv _http\*special\!._tcp.fit.nokia.com
_http*special!._tcp.fit.nokia.com has SRV record 0 5 80  
db.fit.nokia.com.

Lars

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Jun 2009 09:17:55 -0700

Lars Eggert wrote:
> restricted in the same way host names are. Which is why all the service
> names in the current ports registry are usable with SRV RRs.

Which is why, IMO, IANA should continue to assign names using the most
unrestrictive rules possible, excepting only the sequence ._ and
allowing any other printable ASCII character sequence (the one below
uses \ and !, which we haven't assigned to date, but apparently could).

It certainly is useful to keep the names preferably short, but otherwise
there's no reason to deprecate, change, or provide aliases for existing
names, or to restrict future assignments in other ways.

Joe

> _http*special!._tcp.fit.nokia.com has SRV record 0 5 80 db.fit.nokia.com.
> 
> Lars

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Jun 2009 18:11:01 -0700

Hi, all,

I followed up on this issue with the authors of RFC 2782, and a few
other DNS advisors, and determined the following:

1. RFC 2782 allows the use of most IANA service names (aka keywords) in
SRV records

	there are problems with "." and "*" in the service name,
	but all other characters should be OK

	the applicability statement in RFC 2782 is intended only
	for protocols that _require_ SRV use; it does not optional
	use of SRVs (i.e., it does not apply to IANA services)

2. there is no current reason to prohibit characters other than "." and
"*" in the unified namespace

	"." is a DNS delimeter, "*" is a DNS wildcard, and either could
	cause problems

	IANA could assign alternate names for services using these
	characters which would be compatible with SRV use; this does
	not require deprecating the existing names, just providing
	additional aliases

I would like to propose, as a way forward, that we do the following:

	A. define the new namespace as "15 chars or less,
	using a-z, 0-9, and any of "-_+/", with no restrictions
	on initial or terminal characters

		new names should be assigned preferring names
		of 10 chars or less where possible

	B. assign aliases for existing IANA names using .*
		these would be required when used as SRV targets,
		and the existing names using .* would be prohibited as
		such targets

This avoids changing existing names as used in existing contexts, and
allows the widest possible use of the resulting unified namespace, AFAICT.

I'd also propose that we setup SRV records for current IANA assignments,
the details of which I'm working out with Vixie. It would likely involve
 setting up SRV records at a name like protocols.iana.org which would
serve as a default servicename target when the target is not otherwise
known (e.g., for use in a revised implementation of getservbyname that
would avoid taking a second argument).

Thoughts?

Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 30 Jun 2009 10:58:38 +0200

> would avoid taking a second argument).

I think this is a good suggestion. I would write this up in the draft
and raise it in the WG and on the relevant area list to get feedback.

Cheers

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

-- 

Magnus Westerlund