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

[Joe Hildebrand <[e-mail]>]

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.

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

On 8/25/11 12:06 PM, "Joe Touch" <[e-mail]> wrote:

> 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:
>> 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.
> 
> 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.
> 
>>> 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
>> 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
> _______________________________________________
> Port-srv-reg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/port-srv-reg

-- 
Joe Hildebrand