Re: [nbs] Scenarios

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

Return-Path: <martin@kit.edu>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3133A67C3 for <nbs@core3.amsl.com>; Tue, 8 Feb 2011 06:56:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orGzxTWueZzS for <nbs@core3.amsl.com>; Tue, 8 Feb 2011 06:56:50 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id DFCBD3A659A for <nbs@ietf.org>; Tue, 8 Feb 2011 06:56:49 -0800 (PST)
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1Pmozo-0004Tx-Vw; Tue, 08 Feb 2011 15:56:55 +0100
Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1Pmozo-0000Sg-Ln; Tue, 08 Feb 2011 15:56:48 +0100
Received: from [IPv6:2001:638:204:6:21f:16ff:fe28:b05c] (unknown [IPv6:2001:638:204:6:21f:16ff:fe28:b05c]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTPSA id 9A1612FC00A; Tue, 8 Feb 2011 15:56:48 +0100 (CET)
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>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de)
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1297177015.738638000
Cc: nbs@ietf.org
Subject: Re: [nbs] Scenarios
X-BeenThere: nbs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nbs>
List-Post: <mailto:nbs@ietf.org>
List-Help: <mailto:nbs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Feb 2011 14:56:52 -0000

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