Subject: [SAM] New Version Notification for draft-irtf-samrg-common-api-02.txt (fwd)

From: Matthias Waehlisch <[email-masked]>
Date: Tue, 12 Jul 2011 00:08:50 +0200

Hi folks,

  we updated the common API draft:
  
  * Pseudo syntax for lists objects changed
  * Editorial improvements

  Please, read the document such that we can discuss details on the 
upcoming meeting.

  One open question regards the error codes: Do you think that we should 
explicitly define the error codes within the draft or leave it only to 
the developers?

Thanks & Best regards
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---------- Forwarded message ----------
Date: Mon, 11 Jul 2011 15:02:52 -0700
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: New Version Notification for draft-irtf-samrg-common-api-02.txt

A new version of I-D, draft-irtf-samrg-common-api-02.txt has been successfully submitted by Matthias Waehlisch and posted to the IETF repository.

Filename:	 draft-irtf-samrg-common-api
Revision:	 02
Title:		 A Common API for Transparent Hybrid Multicast
Creation date:	 2011-07-11
WG ID:		 Individual Submission
Number of pages: 31

Abstract:
   Group communication services exist in a large variety of flavors, and
   technical implementations at different protocol layers.  Multicast
   data distribution is most efficiently performed on the lowest
   available layer, but a heterogeneous deployment status of multicast
   technologies throughout the Internet requires an adaptive service
   binding at runtime.  Today, it is difficult to write an application
   that runs everywhere and at the same time makes use of the most
   efficient multicast service available in the network.  Facing
   robustness requirements, developers are frequently forced to use a
   stable, upper layer protocol controlled by the application itself.
   This document describes a common multicast API that is suitable for
   transparent communication in underlay and overlay, and grants access
   to the different multicast flavors.  It proposes an abstract naming
   by multicast URIs and discusses mapping mechanisms between different
   namespaces and distribution technologies.  Additionally, it describes
   the application of this API for building gateways that interconnect
   current multicast domains throughout the Internet.

The IETF Secretariat