"name-based sockets" standardization efforts

[Tom Spindler <dogcow%babymeat.com@localhost>]

It seems that there's some effort afoot to standardize so-called
'name-based sockets'; to quote the IETF draft 
( http://www.ietf.org/id/draft-ubillos-name-based-api-00.txt ) as to
what those are:

   We suggest a unified API for networked applications.  Isomorphic to the
   existing name-based solutions, but with added network-related
   functionality.  Providing an existing application-layer protocols with
   network features such as mobility, multi-homing, IPv4/IPv6
   interoperability, NAT-traversal and so on...

As, historically, the IETF hasn't been that great at defining APIs,
I thought it might be worthwhile to point some of y'all at it.

----- Forwarded message from Andrew Josey <ajosey%opengroup.org@localhost> -----

From: Andrew Josey <ajosey%opengroup.org@localhost>
Date: Fri, 3 Dec 2010 09:59:11 +0000
To: austin-group-l%opengroup.org@localhost
Cc: Javier Ubillos <jav%sics.se@localhost>
Subject: IETF liaison: Defining APis. [Fwd: A name-oriented API: What should it 
look like? How should it behave?]
Message-Id: <ABD2C7D5-AB8C-49D0-B966-07B04A171FFE%opengroup.org@localhost>
X-Mailer: Apple Mail (2.1082)

hi All

I wanted to alert you to an activity at IETF that may be of interest. They have 
indicated 
to me that would be very much interested in liaising with us on a API as 
described below.

If you are interested in this please contact Javier Ubillos 
<jav%sics.se@localhost>


best regards
Andrew

Begin forwarded message:

> 
> 
> From: Javier Ubillos 
> Date: 1 December 2010 09:19:45 GMT
> 
> Subject: A name-oriented API: What should it look like? How should it behave?
> 
> 
> Hello everyone.
> 
> At the name-based sockets BoF (IETF79 November 8th) there was a clear
> interest in defining an (abstract) API.
> http://www.ietf.org/proceedings/79/minutes/nbs.txt
> 
> I wanted to get that discussion started, and I'd like to emphasize that,
> at this stage, everything is an open question.
> Here's a starting draft in which I intend to capture these discussions.
> http://www.ietf.org/id/draft-Ubillos-name-based-api-00.txt
> 
> I have tried to synthesize, the feedback during the BoF and the  chats 
> afterwards. Thank you Erik Nordmark, Saleem Bhatti, Mika Komu,  Tobias
> Heer, David Thaler, Randall Stewart, Stuart Cheshire and everyone who
> have argued with me and given me feedback. I greatly appreciate it!
> 
> 
> 
> Today we are already seeing name-oriented APIs in all kinds of
> application
> frameworks, they are very popular.
> However, they tend to only leverage app-protocol functionality.
> Also, as the service used defines the application-protocol used,
> bi-lateral support is implied by the used service. This limits the
> functionality
> used to application-protocol functionality.
> 
> The objective is to make it easier for applications to make use of
> networking solutions.
> 
> To achieve this *I* believe we need to:
> 
> API wise:
>   * Provide an API in parallel to the socket() calls.
>      * This API should take "names" in different formats.
>         * Ability to select resolution system for names
> 
>   * The API should be able to receive information about which functions
>     the application wants (e.g. multi-homing)
> 
>   * The API should be able to provide information
>      * About which functions are available.
>      * If the remote peer supports the requested features (if
> bi-lateral
>        support is needed.)
>      * About relevant changes (e.g. if the set of locators has changed)
> 
> Behavior wise:
>   * When a recipient receives a connection, the receiving
> socket/application
>     receives a simple, unauthenticated session handle.
>      * If the application needs more information, it calls some part of
> the API
>        and is obviously prepared to pay whatever performance cost the
> function
>        requires.
>      * Possible (and optional!) features are:
>         * Name exchange
>         * Authenticity
>         * (you name it...)
> 
>   * Making the name-exchange an optional part (and not an integral
> part) means
>     that it can be done on-demand. Whenever the user or some thing else
>     requested by the user requires it.
> 
> 
> I believe this also means that we need to have some functionality which
> checks for bi-lateral support, and is able to exchange information about
> what functions the respective peer wishes to use.
> 
> The name-based sockets implementation and draft(s) are attempts to
> capture this (however, still incomplete when it comes to API questions).
> http://tools.ietf.org/html/draft-ubillos-name-based-sockets-03
> http://tools.ietf.org/html/draft-xu-name-shim6-00
> 
> // Javier
> 

--------
Andrew Josey                 The Open Group
Austin Group Chair          Apex Plaza, Forbury Road
Email: a.josey%opengroup.org@localhost Reading,Berks.RG1 1AX,England
Tel:+44 118 9023044          US fax:  +1 415 276 3760
Mobile:+44 774 015 5794      UK fax:  +44 870 131 0418

----- End forwarded message -----