From martin@kit.edu Tue Feb 1 02:10:22 2011 Return-Path: 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 D42B53A6C40 for ; Tue, 1 Feb 2011 02:10:22 -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 e+XtX0Ie6IEx for ; Tue, 1 Feb 2011 02:10:21 -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 1B1803A6C3C for ; Tue, 1 Feb 2011 02:10:19 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1PkDEn-0008R1-IX; Tue, 01 Feb 2011 11:13:35 +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 1PkDEn-0000Nd-D7; Tue, 01 Feb 2011 11:13:29 +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 532A62FC024; Tue, 1 Feb 2011 11:13:29 +0100 (CET) Message-ID: <4D47DCC9.8030601@kit.edu> Date: Tue, 01 Feb 2011 11:13:29 +0100 From: Denis Martin 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: Javier Ubillos References: <1294943649.3346.104.camel@bit> In-Reply-To: <1294943649.3346.104.camel@bit> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 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 1296555215.621364000 Cc: Name-based Sockets List nbs Subject: Re: [nbs] Scenarios (Was: Re: A suggestion for an "on-demand API". X-BeenThere: nbs@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Name based sockets discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 10:10:22 -0000 Hi, On 13/01/11 19:34, Javier Ubillos wrote: > I've attempted to define some scenarios (two so far) test some API ideas > against. > > [...] > > We're still trying to define an abstract API, please overlook if I slip > into C'ish syntax :) Looks pretty straight forward, i.e. one is still able to match it to today's socket API using bind/connect etc. > [...] > +----------------------------------------------------------------------+ > | * One to one | > | * Bi-directional (e.g. TCP) | > | * Bi-lateral support (Name-based sockets on both ends) | > | * Requiring authentication of name->locator binding | > +----------------------------------------------------------------------+ > | > | -- Initiator: > | CONNECTION *my_conn = ALLOC_SOCKET(); > | > | /* LOCAL_NAME() binds a local name. Unless some name-type is > | chosen it defaults to FQDN */ > | LOCAL_NAME( my_conn, "initiator.name" ); > | > | DESTINATION_NAME( my_conn, "recipient.name" ); > | TRANSPORT( my_conn, TCP ); > | SERVICE( my_conn, HTTP ); // equivalent to htons(80) Why mentioning the transport protocol explicitly? Isn't that a step backwards compared to, e.g., SOCK_STREAM where I just state that I want a reliable, stream-based transport? In the end, it should not matter to the application if it is TCP or SCTP or any future transport protocol as long as connectivity is provided. > [...] > | // equivalent to htons(12333), my imaginary service :) > | SERVICE( my_conn, MY_VIDEO ); 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. In this case, the interface should allow more than 65k for future extensibility. A general thought about a new socket interface: We have to modify applications anyway, so we could even more augment that interface. We not only should get rid of addresses, but also of a concrete protocol selection done by the application. Regarding the scenarios, it could even be worth looking at new paradigms such as CCN. Admittedly, it might be a bit more distant in the future, but if we change that interface now, there might be the necessity of changing it again in a couple of years ;) Regards, 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 From jav@sics.se Wed Feb 2 08:20:55 2011 Return-Path: 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 C387C3A6D6D for ; Wed, 2 Feb 2011 08:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 JpZZaQAAjnkh for ; Wed, 2 Feb 2011 08:20:54 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 46A0E3A6D65 for ; Wed, 2 Feb 2011 08:20:54 -0800 (PST) Received: from [193.10.66.199] (dab.sics.se [193.10.66.199]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 087A4402D8; Wed, 2 Feb 2011 17:24:13 +0100 (CET) From: Javier Ubillos To: Denis Martin In-Reply-To: <4D47DCC9.8030601@kit.edu> References: <1294943649.3346.104.camel@bit> <4D47DCC9.8030601@kit.edu> Content-Type: text/plain; charset="UTF-8" Date: Wed, 02 Feb 2011 17:24:04 +0100 Message-ID: <1296663844.2155.226.camel@dab> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: Name-based Sockets List nbs Subject: Re: [nbs] Scenarios (Was: Re: A suggestion for an "on-demand API". X-BeenThere: nbs@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Name based sockets discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 16:20:56 -0000 On Tue, 2011-02-01 at 11:13 +0100, Denis Martin wrote: > > +----------------------------------------------------------------------+ > > | * One to one | > > | * Bi-directional (e.g. TCP) | > > | * Bi-lateral support (Name-based sockets on both ends) | > > | * Requiring authentication of name->locator binding | > > +----------------------------------------------------------------------+ > > | > > | -- Initiator: > > | CONNECTION *my_conn = ALLOC_SOCKET(); > > | > > | /* LOCAL_NAME() binds a local name. Unless some name-type is > > | chosen it defaults to FQDN */ > > | LOCAL_NAME( my_conn, "initiator.name" ); > > | > > | DESTINATION_NAME( my_conn, "recipient.name" ); > > | TRANSPORT( my_conn, TCP ); > > | SERVICE( my_conn, HTTP ); // equivalent to htons(80) > > Why mentioning the transport protocol explicitly? Isn't that a step > backwards compared to, e.g., SOCK_STREAM where I just state that I want > a reliable, stream-based transport? In the end, it should not matter to > the application if it is TCP or SCTP or any future transport protocol as > long as connectivity is provided. Good point! Any suggestions on how that choice should be made? Perhaps happy-eyeballs style? > > [...] > > | // equivalent to htons(12333), my imaginary service :) > > | SERVICE( my_conn, MY_VIDEO ); > > 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. In this case, the interface should allow > more than 65k for future extensibility. > > A general thought about a new socket interface: We have to modify > applications anyway, so we could even more augment that interface. We > not only should get rid of addresses, but also of a concrete protocol > selection done by the application. Regarding the scenarios, it could > even be worth looking at new paradigms such as CCN. Admittedly, it might > be a bit more distant in the future, but if we change that interface > now, there might be the necessity of changing it again in a couple of > years ;) About service/ports: I'm having a hard time marrying ports and service-names. I don't know where to turn, in particular if we are not defining the transport. If we use regular TCP, we need to reach a numeric port at some point. If we are using some cool futuristic protocol, we might use strings. But how do we get both? I think the only way is to distribute a list somehow. Do you have any suggestions on alternatives? Why not check the official IANA list if we hit an unknown service name? And of course, also accept "raw" port-numbers. CCN: I think this is a natural evolution, where we go down the path to address in "higher resolution". Where we either address a serivce on a specific host, or "just" the service/content. It makes sense to "open" an identifier which is some content and e.g. get a file descriptor to it. e.g. fd = open("/mystuff.org/things/somefile.txt/_v3/_s1"); // Javier From martin@kit.edu Wed Feb 2 09:16:58 2011 Return-Path: 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 5C1E43A6C0B for ; Wed, 2 Feb 2011 09:16:58 -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 OC+HW+LsxE6a for ; Wed, 2 Feb 2011 09:16:56 -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 976123A6BC0 for ; Wed, 2 Feb 2011 09:16:54 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1PkgND-0000aU-VG; Wed, 02 Feb 2011 18:20:13 +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 1PkgND-000133-Q8; Wed, 02 Feb 2011 18:20:07 +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 B69DA2FC024; Wed, 2 Feb 2011 18:20:07 +0100 (CET) Message-ID: <4D499246.5080903@kit.edu> Date: Wed, 02 Feb 2011 18:20:06 +0100 From: Denis Martin 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: Javier Ubillos References: <1294943649.3346.104.camel@bit> <4D47DCC9.8030601@kit.edu> <1296663844.2155.226.camel@dab> In-Reply-To: <1296663844.2155.226.camel@dab> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 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 1296667213.807490000 Cc: Name-based Sockets List nbs Subject: Re: [nbs] Scenarios (Was: Re: A suggestion for an "on-demand API". X-BeenThere: nbs@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Name based sockets discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 17:16:58 -0000 On 02/02/11 17:24, Javier Ubillos wrote: > On Tue, 2011-02-01 at 11:13 +0100, Denis Martin wrote: > >>> | DESTINATION_NAME( my_conn, "recipient.name" ); >>> | TRANSPORT( my_conn, TCP ); >>> | SERVICE( my_conn, HTTP ); // equivalent to htons(80) >> >> Why mentioning the transport protocol explicitly? Isn't that a step >> backwards compared to, e.g., SOCK_STREAM where I just state that I want >> a reliable, stream-based transport? In the end, it should not matter to >> the application if it is TCP or SCTP or any future transport protocol as >> long as connectivity is provided. > > Good point! > Any suggestions on how that choice should be made? > Perhaps happy-eyeballs style? Could be an option, though I wasn't thinking about how to actually select the "right" transport protocol. These might be two different problems: 1) Specifying the transport requirements, eg.: stream-based, datagram-based, unreliable, reliable, with flow-control, without flow-control, authenticated, encrypted, etc. The application could select any combination, eg. "datagram-based with flow-control but not necessarily with ARQ". This could even be augmented with QoS requirements such as minimum guaranteed bandwidth. 2) Selection of an actual (combination) of protocols. The hardest part ;) In case there is only UDP and TCP, it could be hard-coded, of course. If there is a huge number of protocols to choose from, happy-eyeballs probably won't scale. With a new socket interface, maybe 1) can be considered. 2) adds too much complexity - but it might also not be necessary to solve it right now, is it? > About service/ports: > I'm having a hard time marrying ports and service-names. > I don't know where to turn, in particular if we are not defining the > transport. If we use regular TCP, we need to reach a numeric port at > some point. If we are using some cool futuristic protocol, we might use > strings. But how do we get both? > I think the only way is to distribute a list somehow. Do you have any > suggestions on alternatives? Not really. 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? > Why not check the official IANA list if we hit an unknown service name? > And of course, also accept "raw" port-numbers. Agree. > CCN: > I think this is a natural evolution, where we go down the path to > address in "higher resolution". Where we either address a serivce on a > specific host, or "just" the service/content. > It makes sense to "open" an identifier which is some content and e.g. > get a file descriptor to it. > > e.g. fd = open("/mystuff.org/things/somefile.txt/_v3/_s1"); So, you mean that such application interfaces would be on a higher level anyway? And if we introduced namespaces? Eg. DESTINATION_NAME( fd, "ccn:/mystuff.org/things/somefile.txt" ); Regards, 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 From rja.lists@gmail.com Thu Feb 3 06:52:02 2011 Return-Path: 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 C38663A699E for ; Thu, 3 Feb 2011 06:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 dJqDLjIx9yuP for ; Thu, 3 Feb 2011 06:52:00 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 58D7C3A692F for ; Thu, 3 Feb 2011 06:51:59 -0800 (PST) Received: by vws7 with SMTP id 7so742084vws.31 for ; Thu, 03 Feb 2011 06:55:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=Pk/XowpQ4y4MEL4HseGsMeOWG08fDlchDgB/chDMvho=; b=xAExTmxf4rpqg6Z1nWJOX9ylkJEZ5oiZVlEx7O3Qdv0iDyxtdK7Lf+D777FYc+QHiy h+iM+r363JM84Ny+irWnVNMKKRAsTUUXmACw9aUN9szXqeUtoVrWRObMGCkWj9J09Vhr Irx99VuNIXtTJLDajIgbnBqC326AUQlz/y8QU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=W4wTdqTcjOKrCnuSC2m2U1zdpbuxKeKkjha6DPIgk27WXZVTVtUNGZDW+oQgVOvqnR oqPMxGYUnCENB9A7Ry0IMNZF8UOD31B5maFERbA2QuYlcMmYK+iqz6orBkrhHa8ZCjag krYewIxPCEgjf3AjP9vHRXjPmCMmYifT2270w= Received: by 10.220.99.204 with SMTP id v12mr2677299vcn.166.1296744921623; Thu, 03 Feb 2011 06:55:21 -0800 (PST) Received: from vi-mhowell55.leclairryan.com ([38.103.42.150]) by mx.google.com with ESMTPS id bq5sm344105vcb.32.2011.02.03.06.55.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 06:55:20 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Feb 2011 09:55:19 -0500 Message-Id: <6679305B-6552-4F98-83B3-3F74C39FE678@gmail.com> To: nbs@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: Re: [nbs] Scenarios X-BeenThere: nbs@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Name based sockets discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 14:52:02 -0000 On 1st February 2011 at 11:13:29 +0100, Denis Martin wrote: > A global service registry would be necessary in this case.=20 > Or a namespace for user-defined services. So it probably=20 > 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 (=E0 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. =20 Instead, we can simply reuse long-standing on-the-shelf capabilities=20 for this. We definitely do NOT require the complexity created by=20 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=20 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()=20 interface, which portable applications already use to resolve from=20 a Service Name to the (transport-protocol + transport-layer port)=20 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=20 Specification: = 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. For more on the existing and future Service Name registry,=20 and some very slight fine-tuning of existing entries in the=20 Port Numbers registry please see this current I-D: 'Internet Assigned Numbers Authority (IANA) Procedures=20 for the Management of the Service Name and=20 Transport Protocol Port Number Registry' Please let us recycle the existing Service Name schema,=20 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 From martin@kit.edu Tue Feb 8 06:56:51 2011 Return-Path: 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 ; 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 ; 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 ; 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 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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' > > > > 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-----