Re: [nbs] NBS and TCP connection identification

Rémi Després <remi.despres@free.fr> Thu, 14 October 2010 15:38 UTC

Return-Path: <remi.despres@free.fr>
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 20EF53A6AB2 for <nbs@core3.amsl.com>; Thu, 14 Oct 2010 08:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.123
X-Spam-Level:
X-Spam-Status: No, score=-0.123 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
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 3laLrI67a+Z0 for <nbs@core3.amsl.com>; Thu, 14 Oct 2010 08:38:48 -0700 (PDT)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by core3.amsl.com (Postfix) with ESMTP id BA7393A6A6E for <nbs@ietf.org>; Thu, 14 Oct 2010 08:38:46 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2204.sfr.fr (SMTP Server) with ESMTP id AE2A87000094; Thu, 14 Oct 2010 17:40:05 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2204.sfr.fr (SMTP Server) with ESMTP id EDBE5700008D; Thu, 14 Oct 2010 17:40:04 +0200 (CEST)
X-SFR-UUID: 20101014154004973.EDBE5700008D@msfrf2204.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
In-Reply-To: <1287070476.2253.97.camel@bit>
Date: Thu, 14 Oct 2010 17:40:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <87E974EA-A815-4844-9DC5-196FDEB72914@free.fr>
References: <4C97D9A8.2050001@oracle.com> <ACE9611A-9107-46EC-ADD2-56E553DC1C3A@ericsson.com> <4C9826D0.2060703@oracle.com> <1285067950.2068.59.camel@bit> <4C98D525.1030808@oracle.com> <DC2EB1A1-B9BE-49B0-B443-B513873B9AF2@ericsson.com> <EBB53DE6-2EEB-43C2-9451-0A38EBD10BAA@free.fr> <CD376A37-C756-47E5-BBC7-205595F523AB@ericsson.com> <C3056CB3-DDD3-4B13-A80F-552350031FEF@free.fr> <C0F28CE9-B47D-416A-907D-394AC2FAF487@ericsson.com> <0631EE7A-FC0D-4130-AC87-397299CA4594@free.fr> <1287070476.2253.97.camel@bit>
To: Javier Ubillos <jav@sics.se>
X-Mailer: Apple Mail (2.1081)
Cc: Christian Vogt <christian.vogt@ericsson.com>, "nbs@ietf.org" <nbs@ietf.org>
Subject: Re: [nbs] NBS and TCP connection identification
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: Thu, 14 Oct 2010 15:38:50 -0000

Le 14 oct. 2010 à 17:34, Javier Ubillos a écrit :

> On Thu, 2010-10-14 at 09:12 +0200, Rémi Després wrote:
>> The semantics of the IP address at the socket API can, and IMHO should, remain unchanged during the connection.
> 
> I agree, and the issue of synthesize names is not directly associated to
> this. Synthesized names can very be hidden from the application if one
> wants that. If a literal IP is provided, this data structure can very
> well become the anchor point of the application.
> However, it would be a little bit awkward, if you open a socket, with
> address family AF_NAME, and then encode a literal IP into name field.
> But it wouldn't be a major technical hurdle.

The idea is rather to keep the address field as is with previous AFs, and leave the name field empty if none is available?
It is the up to the application to decide whether it accepts connections with blank names.

Does that make sense?

RD
> 
> // Javier