Re: [nbs] Scenarios

Denis Martin <martin@kit.edu> Tue, 08 February 2011 14:56 UTC

Message-ID: <4D5159B0.2070501@kit.edu>
Date: Tue, 08 Feb 2011 15:56:48 +0100
From: Denis Martin <martin@kit.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: RJ Atkinson <rja.lists@gmail.com>
References: <6679305B-6552-4F98-83B3-3F74C39FE678@gmail.com>
In-Reply-To: <6679305B-6552-4F98-83B3-3F74C39FE678@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Cc: nbs@ietf.org
Subject: Re: [nbs] Scenarios
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/02/11 15:55, RJ Atkinson wrote:
> [...]
> 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 for the pointers. IMO, those service names should definitely be
supported by a new interface by default. Protocol selection then becomes
obsolete, at least for those registered services (or should become
obsolete). Only the flat namespace for service names is maybe not that
good, but maybe irrelevant for the time being.

Specifying the service name to the API does not yet say anything about
how it is resolved into protocol + port number. Initially,
getservbyname() is probably just fine, extended maybe by a DNS SRV
query. Additionally, something like Bonjour could be used underneath.

One design goal of a new socket API should then be that it is able to
handle any transport protocol transparently to the application if
standard services are used.

But what to do with custom connections where no service has been
registered? Even in such cases, I'd like to push down protocol selection
underneath the socket interface.

Denis

- -- 
Dipl.-Inform. Denis Martin

Institut für Telematik,  KIT   Tel +49 721 608 46420
Zirkel 2,  D-76131 Karlsruhe   Fax +49 721 608 46789
http://telematics.tm.kit.edu   Geb. 20.20,  Raum 371
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1RWbAACgkQdL7YNzuKPo0apwCgrDHqtGD7MZDmRU46Kv4FPoVo
LigAn03vyh/JqgpFVGhxA8rHTqAAYIaA
=r8zQ
-----END PGP SIGNATURE-----

Re: [nbs] Scenarios RJ Atkinson
Re: [nbs] Scenarios Denis Martin