Subject: [port-srv-reg] "xmp" service type and the unified IANA Service Name and Port Number Registry

From: Stuart Cheshire <[email-masked]>
Date: Mon, 22 Aug 2011 21:38:31 -0700

Bobby, I'm writing in reference to your service type registration for "xmp" (port 5270).

We recently merged the volunteer-run dns-sd.org registry and the official IANA "port numbers" registry, to make a new combined "Service Name and Port Number Registry". For more information, see:

<http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports>

Although combining the two registries is overall a great move, unfortunately in the process we discovered that there were three names which got registered differently in the two separate lists, one of which is "xmp".

Prior to your port registration, the "xmp" service name had already been registered in the dns-sd.org registry, for use with DNS-SD (aka "Bonjour") and similar name-based service-discovery mechanisms.

We've contacted the prior dns-sd.org registrant, and they inform us that the "xmp" service name has been in widespread commercial use in their software for many years, and continues to be used in their current products.

The implication of this is that if you were to use the "xmp" service name with DNS-SD (aka "Bonjour"), DNS SRV records, or similar name-based service-discovery mechanisms, then you would get inadvertent conflicts with their use of the name. Your clients would inadvertently discover instances of the other "xmp" service, which your clients don't know anything about, and clients of the other "xmp" service would inadvertently discover instances of your service, which they wouldn't know how to use. Of course this would be confusing and unhelpful for users.

This conflict does not affect your registered port 5270, only the name "xmp".

It is our hope that your software uses your registered port 5270 explicitly, and for you the "xmp" name was merely a mnemonic for human convenience, not actually used by your software for Bonjour service discovery or similar purposes. If this is the case then changing the name to something else (say "Cartographer", or "CartographerXMP"), would not cause any on-the-wire interoperability problems, and this inadvertent name collision can be resolved amicably.

If your software is using the "xmp" service name string (e.g. for Bonjour or similar on-the-wire service discovery protocols), then please let us know as soon as possible, and we'll try to work out a way forward that minimises disruption to all parties.

Ideally, if your software is not using the "xmp" service name string in APIs, protocols, or for service discovery, then we can simply change the mnemonic string for port 5270 without causing undue hardship for anyone involved.

Please let us know.

Thanks in advance.

Stuart Cheshire, on behalf of the IANA port-srv-reg team.

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 23 Aug 2011 16:54:54 -0700

On 23 Aug, 2011, at 07:54, Bobby Krupczak wrote:

> The answer is yes I do use both the port and service name in code,  
> APIs, and rely on this registry.

Thank you for your answer.

Can you let us know for what specific purpose(s) you are using the  
"xmp" service name string in your code or on-the-wire protocols?

It seems clear that neither you nor the prior registrant of the "xmp"  
service name string are willing to change to a different name; they  
because as far as they are concerned they registered it first, and  
you because you consider your later registration to be more  
"official". No matter, we can't force either of you to do anything.  
It seems likely that you will both continue to use the same service  
name string, and deal with the resulting operational conflicts.

If you can let us know how you are actually using the "xmp" service  
name string (what APIs, in what on-the-wire protocols, etc.) then we  
can at least document what manner of problems users are likely to  
experience when trying to use "xmp".

Thank you for your help with this.

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

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 23 Aug 2011 22:41:29 -0700

On 23 Aug 2011, at 19:46, Bobby Krupczak wrote:

> When did the other party "register" and with whom did they register?

Begin forwarded message:

> 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

On 23 Aug 2011, at 19:46, Bobby Krupczak wrote:

> What is the other xmp's product, etc?  Did you do any verification of
> their claims.  When I chose xmp, I googled all over the net to look
> for name clashes and *never* saw anything but xmpp which is distinct.

A Google search for "srv type xmp" finds the DNS SRV Service Types list as the first hit:

<http://www.google.com/search?q=srv+type+xmp>

> So, I'm kind of wondering just how widely deployed and ubiquitous it
> really is.

Begin forwarded message:

> From: Henric Bergh <[email-masked]>
> Date: 18 August 2011 10:43:24 PDT
> To: Stuart Cheshire <[email-masked]>
> Subject: Re: "xmp" service type and the unified IANA Service Name and Port Number Registry
> 
> Stuart,
> 
> The XMP service and protocol is in use in these products:
> 
> Xperientia conXt
> A system used to document and report your regular workday. The system automatically synchronizes the data in the local client database with other clients and servers in the system. The discovery of other peers is done by DNS Service Discovery (DNS-SD) of the service type XMP.
> The system also contains other devices such as a GPS equipped device used in vehicles to track its location. The communication between the device and the contXt client is done by discovery of the service XMP. Mobile phones are also used to track GPS locations, and document user notes with pictures taken by the camera. The communication between the phone and the contXt client is done by discovery of the service XMP.
> 
> Company web site: http://xperientia.com/
> Product web site: https://store.xperientia.com/products/contxt/
> 
> Infospread MobiTime
> The protocol XMP is also used in the product MobiTime by Infospread Euro AB. The service discovery is not currently used but is planned in the future. The product has over 50 000 active users in Sweden.
> 
> Company web site: http://www.infospread.se/eng/
> Product web site: http://www.infospread.se/eng/?page=mobitime.aspx
> 
> The protocol - XMP
> The protocol XMP has no static assigned port number because of the dynamic port discovery features in DNS Service Discovery (DNS-SD).
> 
> Hence, the XMP service and protocol is in use and we need it in our products.
> 
> Regards,
> Henric

The additional factor here is that because Xperientia registered *only* a service name, they don't have an assigned port to go with it. Therefore, by definition they must be using the name, because that's all they have. Their servers bind to a dynamically-allocated port and their clients discover the dynamically-allocated port via DNS-SD queries, thereby conserving the limited remaining assigned port space, which is beneficial for the future of the Internet, and is virtuous behavior we'd like to encourage.

> I use the name in getservbyname()

My personal view is that getservbyname() is a flawed API with very limited usefulness. It simply consults the local /etc/services table on Unix, and, in your case, should always return the fixed constant 5270. So calling getservbyname("xmp", "tcp") is just a less-efficient way of writing "htons(5270)".

If a user were to modify their /etc/services table to change the value to 5271 then your client wouldn't work, because your servers running on unmodified machines will still be listening on 5270. So calling getservbyname("xmp", "tcp") is just a less-reliable way of writing "htons(5270)".

To use the example of HTTP, if someone were to write a web browser that used getservbyname("http", "tcp"), and some user were to change their /etc/services http value to 81, then that web browser wouldn't be able to access most web pages, and people would complain, and a smart web browser developer would stop using getservbyname because it's just a way to make their web browser not work reliably.

And, getting back to your "xmp" example, "xmp" isn't even in the /etc/services table on OS X, so if you do use getservbyname then your application won't even work on Macs and other Apple devices:

grep ^xmp /etc/services
xmpcr-interface 3877/tcp    # XMPCR Interface Port
xmpcr-interface 3877/udp    # XMPCR Interface Port
xmpv7           7430/udp    # OpenView DM xmpv7 api pipe
xmpv7           7430/tcp    # OpenView DM xmpv7 api pipe

The same will be true on older Linux and BSD distributions too. So using getservbyname("xmp", "tcp") will limit your software to a pretty small customer base where that call actually works.

> I use the string xmp in my wire
> protocol, I use the string in loads of configuration, and the
> protocol/service has been incorporated into the OpenNMS project.

In your protocol where you use the string "xmp", what other strings are valid for that protocol field? What purpose does this field have in your protocol?

---

From: Bobby Krupczak <[email-masked]>
Date: Tue, 23 Aug 2011 10:54:23 -0400

Hi!

Your email certainly caught me off guard and I had to think about it for 
a few moments to get what you were writing about.

Let me see if I understand this.

Apple (under the guise of some quasi-independent but non-official group) 
creates its own service name registry for use with Bonjour.

Apple then decides it wants to make it official, gets the IETF to 
combine it with their own *official* service/port registry.

Now, Apple wants *me* to change the name of my service that was 
registered according to the rules and registered with the official 
organization and registry.

Is this a correct inference and is this what the IETF allows private 
corporations to do?

The answer is yes I do use both the port and service name in code, APIs, 
and rely on this registry.

Thanks,

Bobby

---

From: Bobby Krupczak <[email-masked]>
Date: Tue, 23 Aug 2011 22:46:14 -0400

Hi!

> "xmp" service name string in your code or on-the-wire protocols?

Do you guys have access to my original registration?  XMP stands for
XML Management Protocol (hey, I'm a programmer, not an author).  Its
the protocol that my software components and project use.  I
registered using the established protocol outlined at the time.  The
"service" name gets integrated into /etc/services, ldap/nis, x500 etc
for use with functions like getservbyname().  All of these procedures
is common and well-known.  Thats whats so frustrating about your email
and proposal.

> It seems clear that neither you nor the prior registrant of the
> "xmp" service name string are willing to change to a different name;
> they because as far as they are concerned they registered it first,
> and you because you consider your later registration to be more

> experience when trying to use "xmp".

I use the name in getservbyname(), I use the string xmp in my wire
protocol, I use the string in loads of configuration, and the
protocol/service has been incorporated into the OpenNMS project.

Thanks,

Bobby

---

From: Lars Eggert <[email-masked]>
Date: Wed, 24 Aug 2011 10:14:19 +0300

Hi, Bobby,

On 2011-8-23, at 17:54, Bobby Krupczak wrote:
> Apple then decides it wants to make it official, gets the IETF to combine it with their own *official* service/port registry.

I was IETF transport area director when this effort to merge the two registries got started. From the IETF perspective, we were happy to see Apple wanting to merge their private and our "official" registry, precisely because this will in the future avoid name clashes. We can argue whether Apple should have done this sooner, but they are trying to do the right thing now (and have been for a few years, this effort took some time to progress in the IETF.)

Unfortunately, in your particular case, a clash still happened. I fully understand that this is dissappointing. This is why we are now looking for a way to de-conflict the two uses of the serve name.

> Now, Apple wants *me* to change the name of my service that was registered according to the rules and registered with the official organization and registry.

It's not Apple. Stuart send out his email as one of the authors of the IETF RFC-to-be, because he had the contact information of the folks who registered service names with Apple, and he also contacted the respective IANA registrants. (The [email-masked] list on the CC has on it the respective IETF area directors, authors, WG chairs and IANA representatives.)

I hope that Stuarts emails haven't left you upset. For each name conflict, he is trying to determine whether the Apple-assigned name and the IANA assigned name are still in active use. In several cases, at least one of them wasn't, which means that that particular clash was easy to resolve. In your case, both assignees use the service name, which complicates the situation.

In my personal opinion, the best we can do in this case is to document the conflict in the unified registry, and suggest to both assignees that their particular piece of software should attempt to verify that a peer found by resolving the service name is in fact implementing the expected protocol. How exactly that is done is something that remains up to the individual implementation. Do you believe this could be a way forward here?

Thanks,
Lars

---

From: Bobby Krupczak <[email-masked]>
Date: Wed, 24 Aug 2011 08:14:57 -0400

Hi!

>> From: Henric Bergh<[email-masked]>

He has me beat by roughly 1.5 years :(

> A Google search for "srv type xmp" finds the DNS SRV Service Types list as the first hit:

Back in 2008, it did not return this when one searched for XMP or xmp.
> The additional factor here is that because Xperientia registered *only* a service name, they don't have an assigned port to go with it. Therefore, by definition they must be using the name, because…

Good point.

> My personal view is that getservbyname() is a flawed API with very limited usefulness. It simply consults the local /etc/services table on Unix, and, in your case, should always return the fixed co…

Thanks for the networking API tutorial.

I appreciate the additional info.  I think it would have been helpful 
had you given this info in your original request; it might have come off 
less of an imposition.

I'm happy to change my service name as my software only needs the 
assigned port.

Let me think of something cute and we can switch to that.  Give me a 
couple of days to try to be creative with some sort of name.  What is 
the service name criteria?  How many letters/digits?

As a former participant in the IETF, I really do appreciate the work you 
guys do.

Thanks,

Bobby

---

From: Bobby Krupczak <[email-masked]>
Date: Wed, 24 Aug 2011 08:19:03 -0400

Hi!

> I was IETF transport area director when this effort to merge the two registries got started. From the IETF perspective, we were happy to see Apple wanting to merge their private and our "official"…

I think its a good thing too.  However, going forward, you guys (the 
IETF) really should pinch companies that try to do ad hoc registries 
then legitimize them by then bringing them to the IETF.  In the future, 
perhaps the IETF make a policy that IETF registries take precedence over 
ad hoc registries.  Otherwise, the IETF sets themselves up for more of 
this kind of thing.  I cannot stress this enough.

> It's not Apple. Stuart send out his email as one of the authors of the IETF RFC-to-be, because he had the contact information of the folks who registered service names with Apple, and he also conta…

I dont think he realizes how apple-centric his email and persona is. 
Its difficult to separate the person/project from the company behind it 
and in this case bonjour is so tightly bound to Apple products.

> I hope that Stuarts emails haven't left you upset. For each name conflict, he is trying to determine whether the Apple-assigned name and the IANA assigned name are still in active use. In several c…

No biggie at all, I've got very thick skin and am a big boy.

See my previous email about coming up with another, more cute 
service/protocol name.

Thanks,

Bobby

---

From: "David Harrington" <[email-masked]>
Date: Wed, 24 Aug 2011 09:54:24 -0400

Hi Bobby,

I am one of the current transport area directors, and we do believe
that the IANA registries do take precedence. 

But, as Lars says, everybody is trying to do the right thing.
We certainly have no desire to deliberately hurt people's products,
especially when they are willing to voluntarily migrate toward IANA
official registries.

But conflicts do exist, and we try to resolve them amicably.
Taking a confrontational your-registration-is-unofficial approach
would probably be counter-productive.
Stuart has taken the initiative to contact all those who have a
potential conflict, both the Apple-registrants and the IANA
registrants, to try to resolve the conflicts in a friendly and
voluntary manner.
He advised those of us involved in this project, and we approved his
approach.
Maybe I should have let Stuart contact the Apple registrants, and I
should have been the one who sent the messages to IANA-registrants, so
those emails came off as less Apple-centric.
Your feedback has been very helpful, and I'll watch for this in any
future conflict-resolution efforts.

I think it is terrific that you are willing to change the service name
to work around this conflict.
That will be tremendously helpful.
I love this job because I meet so many people willing to do the right
thing. It's just wonderful!

Thanks,
David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bobby Krupczak
> Sent: Wednesday, August 24, 2011 8:19 AM
> To: Lars Eggert
> Cc: [email-masked]
> Subject: Re: [port-srv-reg] "xmp" service type and the 
> unified IANA Service Name and Port Number Registry
> 
> Hi!
> 
> > I was IETF transport area director when this effort to 
> merge the two registries got started. From the IETF 
> perspective, we were happy to see Apple wanting to merge 
> their private and our "official" registry, precisely because 
> this will in the future avoid name clashes. We can argue 
> whether Apple should have done this sooner, but they are 
> trying to do the right thing now (and have been for a few 
> years, this effort took some time to progress in the IETF.)
> 

> > It's not Apple. Stuart send out his email as one of the 
> authors of the IETF RFC-to-be, because he had the contact 
> information of the folks who registered service names with 
> Apple, and he also contacted the respective IANA registrants. 
> (The [email-masked] list on the CC has on it the 
> respective IETF area directors, authors, WG chairs and IANA 
> representatives.)
> 

> > I hope that Stuarts emails haven't left you upset. For each 
> name conflict, he is trying to determine whether the 
> Apple-assigned name and the IANA assigned name are still in 
> active use. In several cases, at least one of them wasn't, 
> which means that that particular clash was easy to resolve. 
> In your case, both assignees use the service name, which 
> complicates the situation.
> 
> _______________________________________________
> Port-srv-reg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/port-srv-reg
>

---

From: Bobby Krupczak <[email-masked]>
Date: Wed, 24 Aug 2011 10:42:22 -0400

Hi David!

> that the IANA registries do take precedence. 

That is not apparently what is taking place though.

> would probably be counter-productive.

Taking Stuart's approach where he said initially that the ideal
approach would be for me to give up my service name is also
counter-productive. 

I mean, really.  Think about the precedent you guys are setting for
the IETF and IANA and ad hoc registries.

> That will be tremendously helpful.

I think the IETF and WG really need to think harder about the
precedence being set here.  In the future, when some company
(e.g. Apple) wants to legitimize an ad hoc registry, rules need to be
set about this and I think IANA registries should take priority.  If I
had not agreed to change my protocol/service name, we would have ended
up in a situation where we had name conflicts.  I just not seeing that
you guys see the bad precedence set here.  

You say IANA registries take precedence but if that were true, I would
not have been asked to give up my service name and there would have
been no potential stalemate.

(I think if you grep through your past email, you'll find that we've
crossed paths in the SNMP world.)

Bobby

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Aug 2011 09:32:38 -0700

Hi, Bobby,

A point of clarification:

> creates its own service name registry for use with Bonjour.

In the IETF, parties act as individuals, not representatives of 
companies. SRV records are defined in RFC 2782 as an open Internet draft 
standard, and to help record the TXT records used for that service 
Stuart offered to create an unofficial registry of SRV names until such 
time as IANA could subsume that role.

There has been an ongoing desire to unify the IANA port names and SRV 
names, which has taken several years to materialize. Although Stuart did 
avoid conflicts in previously assigned names during his assignments, 
IANA did not track his registry because it was unofficial - even though 
in widespread use.

> combine it with their own *official* service/port registry.

The team that is working on this unification - which includes Stuart, 
myself, and a number of others in the IETF - *asked* Stuart to help 
resolve this issue -- *as an individual*. The team includes the authors 
of the following draft (soon to be published as RFC 6335, with an 
updated note on the resolution of this unification):
http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports-10

> organization and registry.

We are *all* (all of us on the ports document team) asking. We're asking 
BOTH parties - IANA assignees and SRV assignees - whether they are 
willing to change, and what the impact is.

Again, recognizing that (IMO) IANA assignments should take precedence, 
we're trying to also recognize that a voluntary resolution would be 
preferable.

Joe Touch
IANA Port Review Team Lead

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Aug 2011 09:33:17 -0700

> On 23 Aug 2011, at 19:46, Bobby Krupczak wrote:
...
> My personal view is that getservbyname() is a flawed API with very
> limited usefulness. It simply consults the local /etc/services table on
> Unix, and, in your case, should always return the fixed constant 5270.
> So calling getservbyname("xmp", "tcp") is just a less-efficient way of
> writing "htons(5270)".

Hi, Bobby,

This view is not held by all parties involved in this issue.

My view is that getservbyname provides the same level of indirection 
inside a host that SRV records provide between hosts. In specific, 
modifications of the /etc/services tables does occur and is valid. As a 
result, I would not suggest that you change to using the port number 
directly.

My position, FWIW, is that IANA assignments were the only official ones, 
and that they will take precedent - that is what I have already 
recommended to IANA. Whether the SRV name or port name is changed, there 
are changes to code required.

The goal of this exchange is to minimize the impact of resolving the 
unification of IANA port names and SRV names. My recommendation to IANA 
is that IANA assignments should take precedence if a true conflict remains.

On one final point:

> And, getting back to your "xmp" example, "xmp" isn't even in the /etc/services table on OS X
...

Stuart - perhaps you can encourage Apple to update their /etc/services 
to track the IANA list more closely. Regardless of similar flaws in 
other OSes, this list should be updated regularly.

Joe Touch

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Aug 2011 09:39:54 -0700

Hi, Bobby,

On 8/24/2011 5:14 AM, Bobby Krupczak wrote:
...
> couple of days to try to be creative with some sort of name. What is the
> service name criteria? How many letters/digits?

Please see http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports-10

The current list of assignments is here:
http://www.iana.org/assignments/port-numbers
(NOTE: this takes a minute to load; IANA is working on that)

The spec (which also affected some legacy assignments, for a variety of 
reasons explained in that doc) is now:

5.1. Service Name Syntax

    Valid service names are hereby normatively defined as follows:

    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

    o  hyphens MUST NOT be adjacent to other hyphens

Since your protocol name is "XML Management Protocol", may I suggest 
"xml-mp" or "xml-mgt"? (these are just my personal offerings; you're 
welcome to come up with anything else of course).

Joe Touch

---

From: "David Harrington" <[email-masked]>
Date: Wed, 24 Aug 2011 14:20:10 -0400

Hi all,

I think it would be good not to give Bobby potentially conflicting
advice.
So is the agreed-upon advice for him to change his current
direct-to-port mappings to indirection-by-service-name?
(and to use his new name rather than his old name to resolve this
naming conflict)

Can we get that advice documented on the TSV wiki (or in the IANA
registry)? or is this advice in the iana-ports document already?

dbh

> [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Wednesday, August 24, 2011 12:33 PM
> To: Stuart Cheshire
> Cc: Bobby Krupczak; [email-masked]

---

From: Bobby Krupczak <[email-masked]>
Date: Wed, 24 Aug 2011 14:21:29 -0400

Hi!

> The spec (which also affected some legacy assignments, for a variety
> of reasons explained in that doc) is now:

Thanks.  I could have found it but you saved me a bunch of time.  I
read and enjoyed lot of your work in grad school.

> welcome to come up with anything else of course).

I was kinda thinking hello-kitty but there may be IP problems with
using that name.

I'll think of something.

Thanks,

Bobby

---

From: Bobby Krupczak <[email-masked]>
Date: Wed, 24 Aug 2011 14:29:46 -0400

Hi!

> modifications of the /etc/services tables does occur and is valid.
> As a result, I would not suggest that you change to using the port
> number directly.

I agree with you (Joe) but didnt think it was worth quibbling with
Stuart on his assertions.

> My position, FWIW, is that IANA assignments were the only official
> ones, and that they will take precedent - that is what I have
> already recommended to IANA. Whether the SRV name or port name is
> changed, there are changes to code required.

Yes, I agree with you.

> unification of IANA port names and SRV names. My recommendation to
> IANA is that IANA assignments should take precedence if a true
> conflict remains.

And thats what I assert as well lest we get into potentially
dangerous precedence setting behavior here.  I thought I was the only
one who was thinking that way.  I feel bad for the Russian XMP guy but
he did not register with IANA and yeah I know about the ports/services
difference.  

> Stuart - perhaps you can encourage Apple to update their
> /etc/services to track the IANA list more closely. Regardless of
> similar flaws in other OSes, this list should be updated regularly.

I enjoyed this Apple-is-the-center-of-the-world thinking but wasnt
going to call him out on it -- I'm glad you did.  I've been in the
field (industry->academic->industry) long enough to have seem several
paradigms come and go.  I'm sure more elder-statesmen have seen even
more.  Apple is the paradigm du jour and it will be some other one in
the future.  Thats why I'm kind of enjoying the discussion.

Thanks for the note.  I consider this a "quality-loss" on my part to
paraphrase college-football-speak.  :)  Really, the impact for me is
pretty negligible but it was the presumption in Stuart's email that
really got my goat.

Besides, I see that Adobe has claimed XMP (Google "xmp" not his
suggested phrase) and see that Adobe links fill up the first page.  My
guess is that the Adobe intellectual property lawyers may take an
interest. :)

Bobby

---

From: Bobby Krupczak <[email-masked]>
Date: Wed, 24 Aug 2011 14:32:14 -0400

Hi!

> companies. 

I know I know; I've worked a bit within the IETF.  However, even if
the IETF does distinguish, some folks have a hard time separating
their work and ietf personas.  And, I'm sure you'll agree that its
naive to think a person's two hats do not co-mingle.

> Again, recognizing that (IMO) IANA assignments should take
> precedence, we're trying to also recognize that a voluntary
> resolution would be preferable.

I volunteer.

Thanks for the clarifications.

Bobby

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Aug 2011 11:53:33 -0700

Hi, David,

> direct-to-port mappings to indirection-by-service-name?

I don't think there ought to be a recommendation on this point from the 
IETF per se. I do think that getservbyname() is ubiquitous and its use 
is good - if not preferred - practice.

> (and to use his new name rather than his old name to resolve this

Yes - and he's agreed tot that.

> registry)? or is this advice in the iana-ports document already?

Neither of those seem necessary - it's out of scope for both the wiki 
and the registry. It would (and IMO should) be in the user-ports doc 
I've been working on, though.

Joe

>> /etc/services

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 25 Aug 2011 10:20:59 -0700

On 24 Aug 2011, at 9:33, Joe Touch wrote:

> My view is that getservbyname provides the same level of indirection inside a host that SRV records provide between hosts. In specific, modifications of the /etc/services tables does occur and is valid. As a result, I would not suggest that you change to using the port number directly.

[Removing Bobby Krupczak from discussion]

I do not agree with you Joe, and I don't think this is good advice.

The difference is that SRV records are a good idea because the client queries the organisation providing the service to discover what port that service instance is listening on. This is broadly applicable on a worldwide Internet encompassing many administrative domains.

The getservbyname() call queries the client's own local table, which has little if any relationship to to whatever port any given server instance may be listening on. The notion that a network administrator can modify *all* the /etc/services tables on *all* machines only made sense in an earlier era of isolated islands of IP connectivity, before mobile devices like laptop computers became common (e.g. pre 1990s). The getservbyname() call is an API for the 1970s and 1980s, which makes little sense in today's world.

> Stuart - perhaps you can encourage Apple to update their /etc/services to track the IANA list more closely. Regardless of similar flaws in other OSes, this list should be updated regularly.

The reason we *stopped* updating /etc/services in 2002 is precisely because we *don't* believe that APIs like getservbyname() are useful any more, and encouraging developers to believe otherwise would not be helpful. Overriding the default port for a service assigned by IANA (if any) can be done usefully though run-time network queries like DNS SRV queries, or (less-usefully) though application-specific configuration files or other mechanisms (like putting ":port" in an HTTP URL), but trying to do it by editing the system-wide /etc/services file is no longer useful. That's just a way of generating customer frustration when things don't work.

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Aug 2011 11:06:07 -0700

Hi, Stuart,

These may be yours and Apple's opinion, but they are not shared by the 
rest of the network community, which has been using /etc/services nearly 
since there have been assigned ports.

On 8/25/2011 10:20 AM, Stuart Cheshire wrote:
>> My view is that getservbyname provides the same level of
>> indirection inside a host that SRV records provide between hosts.
>> In specific, modifications of the /etc/services tables does occur
>> and is valid. As a result, I would not suggest that you change to
>> using the port number directly.
>
> The difference is that SRV records are a good idea because the
> client queries the organisation providing the service to discover
> what port that service instance is listening on. This is broadly
> applicable on a worldwide Internet encompassing many administrative
> domains.

I don't debate the benefits of SRV records, and have recommended many 
use them, but they are not feasible in many cases.

Note however that if SRV records were used *today* for all services, it 
would be a requirement that the SRV tables on the local machine would 
need to include a copy of entries from the ports table - i.e., it would 
need to effectively replicate /etc/services anyway, or you would be 
cutting your node off from all clients that haven't yet converted to SRV 
lookups.

> The getservbyname() call queries the client's own local table, which
> has little if any relationship to to whatever port any given server
> instance may be listening on.

getservbyname() is used both by clients and servers. A server that 
doesn't consult a local /etc/services - or a copy thereof in its local 
DNS SRV entries - is basically saying it cannot be reached by legacy 
clients in the Internet.

Is that seriously Apple's position? That we should all move to SRVs and 
cut ourselves off from legacy clients?

> The notion that a network administrator
> can modify *all* the /etc/services tables on *all* machines only made
> sense in an earlier era of isolated islands of IP connectivity, before
> mobile devices like laptop computers became common (e.g. pre 1990s). The
> getservbyname() call is an API for the 1970s and 1980s, which makes
> little sense in today's world.

With the proliferation of firewalls and NATs it is also useful within 
enterprises. The NAT can convert from local values anyway, and this can 
provide centralized control over external access to various local services.

Further, ports considered 'risky' can (and often are) removed from these 
tables.

>> /etc/services to track the IANA list more closely. Regardless of similar
>> flaws in other OSes, this list should be updated regularly.
>
> The reason we *stopped* updating /etc/services in 2002 is precisely
> ecause we *don't* believe that APIs like getservbyname() are useful any
> more, and encouraging developers to believe otherwise would not be
> helpful.

All that does is set your products apart as having out-of-date tables.

If you want to encourage users to use SRV records, that's fine - but 
forcing users to encode port numbers into their code as an alternative 
to updating /etc/services is short-sighted.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Aug 2011 15:36:19 -0700

On 8/25/2011 2:39 PM, Joe Hildebrand wrote:
> Piping up where my betters are discussing a bikeshed whose color matters to
> me.
>
> In order to set the bikeshed on fire:
>
> /etc/services is useless for modern application-layer protocols not only for
> Stuart's reasons, but also because the only port number that matters is
> 443/tcp.

Arguably, this could be:
	80
	443
	53

;-)

Yes, there's a different problem lurking there, one that Bryan Ford at 
Yale Univ. has been working on, among others.

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 25 Aug 2011 17:33:10 -0700

On 25 Aug, 2011, at 11:06, Joe Touch wrote:

> if SRV records were used *today* for all services, it would be a  
> requirement that the SRV tables on the local machine would need to  
> include a copy of entries from the ports table - i.e., it would  
> need to effectively replicate /etc/services anyway

Joe, I'm not sure you understand how SRV records work. DNS SRV  
records are not "tables on the local machine" -- just like DNS  
address records are not "tables on the local machine" that replicate  
what would have been in that machine's old /etc/hosts file.

> doesn't consult a local /etc/services ... is basically saying it  
> cannot be reached by legacy clients in the Internet.

Apple hasn't updated /etc/services since 2002, and yet... and yet...  
people somehow are managing to continue shipping new network software  
on it at an astonishing rate. How could that be? Is it possible that  
they just bind to the numeric port number IANA assigned to them,  
instead of sitting on their hands and waiting for the OS vendor to  
ship an update (and for all their customers to upgrade) before  
shipping their products? Taking a dependency on /etc/services being  
updated would be disastrous for any software you were actually trying  
to ship to users.

Joe, try updating your /etc/services to put HTTP on a different TCP  
port. Does apache listen on your new port, or does it ignore your  
change and still listen on port 80? Does your web browser pay  
attention to your change, or does it ignore your change and still  
connect to port 80?

I suspect you'll be disappointed.

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Aug 2011 18:36:13 -0700

On 8/25/2011 5:33 PM, Stuart Cheshire wrote:
>> include a copy of entries from the ports table - i.e., it would need
>> to effectively replicate /etc/services anyway
>
> Joe, I'm not sure you understand how SRV records work. DNS SRV records
> are not "tables on the local machine" -- just like DNS address records
> are not "tables on the local machine" that replicate what would have
> been in that machine's old /etc/hosts file.

If you start a service, you need to register it somewhere. If you run a 
DNS somewhere else, you can register it there. Absent that, you need to 
register it on a DNS local to that machine (which I had assumed, since 
I've rarely had a machine that could control any entries in the DNS it 
got its name from).

> people somehow are managing to continue shipping new network software on
> it at an astonishing rate.

Many other manufacturers deploy both OS's and network software without 
Bonjour as well, and yet somehow apps keep running at the same 
astonishing rate. Is that an indication we don't need SRV records either?

 > How could that be? Is it possible that they
> just bind to the numeric port number IANA assigned to them, instead of
> sitting on their hands and waiting for the OS vendor to ship an update
> (and for all their customers to upgrade) before shipping their products?

They *have* to if they use your system, because you MADE them. Not 
because they wanted to, necessarily.

> Taking a dependency on /etc/services being updated would be disastrous
> for any software you were actually trying to ship to users.

It certainly would on an Apple. Good to know.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Aug 2011 22:40:29 -0700

On 8/25/2011 10:13 PM, Joe Hildebrand wrote:
> On 8/25/11 7:36 PM, "Joe Touch"<[email-masked]>  wrote:
>
> I assume you're being a troll here, since I can't imagine that you don't
> realize that SRV is handy without Bonjour.

Sure, but you need to deploy something like Bonjour. I've been around 
that block a few times, and that's a substantial hurdle outside systems 
for which Bonjour is already installed (unless you want to sign Apple's 
licensing agreement and distribute Bonjour with your code, but that 
hurdle is unacceptable to many too).

To see just how many, take a look at the IANA port assignments, and look 
for UDP services named "-disc". All were asked to use SRV records, and 
all gave detailed reasons why that was not acceptable, most focusing on 
Bonjour licensing and the lack of a suitable alternative.

> In case that wasn't just a rhetorical flourish, look up the XMPP federation
> information for GoogleTalk:
>
> $ dig +short -t SRV _xmpp-server._tcp.gmail.com.
> 5 0 5269 xmpp-server.l.google.com.
> 20 0 5269 alt3.xmpp-server.l.google.com.
> 20 0 5269 alt4.xmpp-server.l.google.com.
> 20 0 5269 alt1.xmpp-server.l.google.com.
> 20 0 5269 alt2.xmpp-server.l.google.com.
>
> It's nice that they're running on a registered port (5269/tcp), so that
> people that want to do XMPP federation can open up a single outbound hole in
> their firewall -- but at no point did we need /etc/services.

Sure - because, *as I said*, you've replaced the /etc/services entries 
with an SRV lookup.

Why is this even in the lookup table, though? By Stuart's argument, 
everyone should be burning 5269 in their code.

>  If we used
> "xmpp-server" instead of 5269,

You just did, above...

> then Google wouldn't be *able* to run their
> servers on a port other than 5269, since 5269 would be set in stone on the
> connecting side, where the admin has no clue about how GoogleTalk needs to
> be deployed.

Services need to be on coordinated port numbers. There are many ways to 
do that coordination - one is SRV records, one is a common 
/etc/services, and one is to burn portions of /etc/services in code. 
However, if /etc/services were used inside an enterprise, the sysadmin 
should be able to move xmpp-services by rewriting that file - that can 
be used inside a common enterprise together with an edge NAT to shift 
services around.

This can be useful when services are shifted to other port numbers due 
to attacks that are based on port number values, FWIW. When it isn't 
defeated by poor coding.

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 25 Aug 2011 22:59:25 -0700

> 20 0 5269 alt2.xmpp-server.l.google.com.

We're delving into software deployment philosophy a bit here, but this is a good example.

A sensible strategy to ship (client or server) software is:

  If an SRV record exists, then use it,
  else, if a local /etc/services entry exists, then use it,
  else use the port IANA assigned to you.

This lets you write software and ship it right away, without waiting for some future OS update.

Since the software writer already knows what port IANA assigned, the /etc/services entry is only relevant when it's *different* to the port IANA assigned. The logical conclusion of this line of thought is that it's only necessary to record *exceptions* in your local /etc/services file, since all the apps already know their IANA-assigned default (and if every OS update were to overwrite your /etc/services file with the latest IANA version, overwriting your local changes, you'd get pretty annoyed by that).

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 25 Aug 2011 23:03:35 -0700

On 25 Aug 2011, at 22:40, Joe Touch wrote:

> Sure, but you need to deploy something like Bonjour. I've been around that block a few times, and that's a substantial hurdle outside systems for which Bonjour is already installed (unless you want to sign Apple's licensing agreement and distribute Bonjour with your code, but that hurdle is unacceptable to many too).

You don't need to use Apple's code to use DNS SRV records (but if you do want to use Apple's code, the "licensing agreement" is the Apache 2 license).

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Aug 2011 23:40:07 -0700

> You don't need to use Apple's code to use DNS SRV records (but if you do want to use Apple's code, the "licensing agreement" is the Apache 2 license).

The former isn't the issue - it's known that the format isn't 
proprietary; the latter has been (and has changed over the years).

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Aug 2011 23:48:07 -0700

>    else use the port IANA assigned to you.

I agree.

> Since the software writer already knows what port IANA assigned, the
> /etc/services entry is only relevant when it's *different* to the port
> IANA assigned. The logical conclusion of this line of thought is that
> it's only necessary to record *exceptions* in your local /etc/services
> file, since all the apps already know their IANA-assigned default (and
> if every OS update were to overwrite your /etc/services file with the
> latest IANA version, overwriting your local changes, you'd get pretty
> annoyed by that).

That's a fair point, except that /etc/services is *also* already used by 
a variety of software as a shared ".h" file, where even the defaults are 
looked up by name rather than coded in by number.

Which means there's no particular harm in having an /etc/services that 
includes the current defaults. It would result in the same response 
using the algorithm above.

It's also not uncommon for sysops to grep /etc/services to find out 
what's running. The common "netstat" command consults /etc/services for 
this purpose as well.

(it'd be useful to know what the source to Apple's netstat uses to 
identify protocols that it didn't know about when it was compiled)

Joe

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 25 Aug 2011 15:39:40 -0600

(no, of course I don't actually believe that, but maybe this isn't important
for us to solve here?)

-- 
Joe Hildebrand

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 25 Aug 2011 23:13:34 -0600

It's nice that they're running on a registered port (5269/tcp), so that
people that want to do XMPP federation can open up a single outbound hole in
their firewall -- but at no point did we need /etc/services.  If we used
"xmpp-server" instead of 5269, then Google wouldn't be *able* to run their
servers on a port other than 5269, since 5269 would be set in stone on the
connecting side, where the admin has no clue about how GoogleTalk needs to
be deployed.

-- 
Joe Hildebrand