Re: [nbs] Scenarios

[RJ Atkinson <[e-mail]>]

On 1st February 2011 at 11:13:29 +0100, Denis Martin wrote:
> A global service registry would be necessary in this case. 
> Or a namespace for user-defined services. So it probably 
> will result in the use of today's port numbers.

Later, on 2nd February 2011 at 18:20:06 +0100, Denis Martin wrote:
> A general service registry (à la DNS - which is already used
> as such if you look at MX records or SIP entries) could be an option. Or
> a standardized end-to-end signalling protocol for protocol and service
> negotiation. That's also something which needs to be solved, but is not
> directly bound to the socket interface as seen by the application, right?


Hmm.  We don't need to re-invent the wheel here.  

Instead, we can simply reuse long-standing on-the-shelf capabilities 
for this.  We definitely do NOT require the complexity created by 
any sort of "signalling protocol for protocol and service negotiation".

Well-defined Service Names have existed since the early 1980s,
at least since 4.2 BSD UNIX, along with well-defined UNIX APIs 
for using them in network-aware applications.

On a typical UNIX system, one might look at the file /etc/services,
which contains mappings between transport-protocol + transport-layer
port number and the sundry 'service name' strings.  Usually the
contents of that file come from the IANA Ports Registry (more below).

One also ought to look at the equally long-standing getservbyname() 
interface, which portable applications already use to resolve from 
a Service Name to the (transport-protocol + transport-layer port) 
combination.

I'll note that getservbyname() is mandatory in the BSD, UNIX 95,
UNIX 98, and POSIX interface specifications.  So this is long
since a portable and standardised interface.  Here is a pointer
to the canonical manual page (online) from The Single UNIX 
Specification:

  <http://pubs.opengroup.org/onlinepubs/7990989775/xns/getservbyname.html>

The existing IANA "Port Numbers" registries (one for System ports,
one for User ports) is normative and should be re-used here.
In the URL below, the "Keyword" field is the normative Service Name,
while the "Decimal" field indicates both transport-layer port
number and the transport-protocol that applies.

  <http://www.iana.org/assignments/port-numbers>

For more on the existing and future Service Name registry, 
and some very slight fine-tuning of existing entries in the 
Port Numbers registry please see this current I-D:

	'Internet Assigned Numbers Authority (IANA) Procedures 
	for the Management of the Service Name and 
	Transport Protocol Port Number Registry'

  	<http://tools.ietf.org/id/draft-ietf-tsvwg-iana-ports-09.txt>

Please let us recycle the existing Service Name schema, 
instead of re-inventing this particular wheel.

If one were implementing a prototype Name-oriented API as
a library, it would seem possible to implement that library
using standard APIs such as getservbyname() -- at least initially,
for proof-of-concept work.

Thanks,

Ran