[MEDIACTRL] Chaining the MRB function

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Thu, 15 September 2011 11:06 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0779121F87C9 for <mediactrl@ietfa.amsl.com>; Thu, 15 Sep 2011 04:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.924
X-Spam-Status: No, score=-105.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id m8IZgRTjARZy for <mediactrl@ietfa.amsl.com>; Thu, 15 Sep 2011 04:06:55 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr []) by ietfa.amsl.com (Postfix) with ESMTP id 439E221F87C5 for <mediactrl@ietf.org>; Thu, 15 Sep 2011 04:06:54 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com []) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8FB8kis001034 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <mediactrl@ietf.org>; Thu, 15 Sep 2011 13:09:01 +0200
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([]) with mapi; Thu, 15 Sep 2011 13:08:58 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "mediactrl@ietf.org" <mediactrl@ietf.org>
Date: Thu, 15 Sep 2011 13:08:57 +0200
Thread-Topic: Chaining the MRB function
Thread-Index: Acxzl90rzZZpFizWR9i7i3WVShXHrw==
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE220C0DAF0@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on
Subject: [MEDIACTRL] Chaining the MRB function
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Sep 2011 11:06:56 -0000

Given that the MRB can look to an application like a resource function, and and to a resource function like an application, it would appear to me that there is not reason why MRB functionality cannot be chained either logically, i.e. visit an MRB which supplies details of another MRB which is then queried for the particular resource, or physically, as in both MRBs operating in in-line mode.

I can so far see no mention of this possibility in the mrb document.

A potential use case might be were the resources are being provided by a different supplier to that which runs the application. The application provider runs an MRB to determine which resource supplier is best able to supply the resource. The resource provider runs an MRB to determine which resource best meets the needs.

Is it permitted, and are there any implications people can think of that ought to be documented in using performing this in this fashion.