Network Working Group                                           Kutscher
Internet-Draft                                                       Ott
Expires: August 24, 2001                        TZI, Universitaet Bremen
                                                       February 23, 2001

             An Mbus Profile for Internet Appliance Control

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of Internet-Draft Shadow Directories, see

   This Internet-Draft will expire on August 24, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2001). All Rights Reserved.


   This document discusses scenarios for the control of Internet
   Appliances -- Internet hosts with with specific user funtionalities
   -- using the Mbus protocol [1]. A first sketch of an Mbus
   application profile for controlling Internet appliances is
   presented, describing mechanisms for controlling a group of
   co-located appliances without the need for central controlling

   This document does not address the issue of wide area control, i.e.,
   controlling appliances that are not on the same network link as the
   controlling entity. Instead, it is expected that the Mbus based
   local control is to be complemented by a, yet to be defined,
   protocol for that purpose.

   The underlying message passing and addressing mechanisms for the

Kutscher & Ott          Expires August 24, 2001                 [Page 1]

Internet-Draft           Mbus appliance control            February 2001

   Mbus is defined in the Mbus transport specification[1].

   This document is a contribution to the Internet Appliance Control
   (ipac) BoF at the 50th Internet Engineering Task Force meeting.
   Comments are solicited and should be addressed to the authors.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2 Scope of this Document . . . . . . . . . . . . . . . . . . . .  6
   2.  The System Model . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Characteristics  . . . . . . . . . . . . . . . . . . . . . . .  9
   3.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   3.2 Autoconfiguration  . . . . . . . . . . . . . . . . . . . . . .  9
   3.3 Serverless Operation . . . . . . . . . . . . . . . . . . . . .  9
   3.4 Interaction Models . . . . . . . . . . . . . . . . . . . . . . 10
   4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.1 Integrating Devices into an Appliance Network  . . . . . . . . 11
   4.2 Controlling Appliances . . . . . . . . . . . . . . . . . . . . 12
   5.  Interworking with Wide Area Control  . . . . . . . . . . . . . 15
   6.  Integrating Dumb Devices . . . . . . . . . . . . . . . . . . . 16
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19

Kutscher & Ott          Expires August 24, 2001                 [Page 2]

Internet-Draft           Mbus appliance control            February 2001

1. Introduction

1.1 Background

   The Mbus transport specification[1] defines the transport mechanisms
   of the Message Bus (Mbus), a local coordination infrastructure that
   allows message passing between a group of application components.

   As its basic service, the Message Bus provides local (intra-system)
   exchange of messages between components that attach to the Mbus
   (Mbus entities). A system is typically expected to comprise one or
   more hosts, but a may also extend across a network link and include
   several hosts sharing the tasks; a local system does not extend
   beyond a single link -- the Mbus is not intended or designed for use
   as a wide-area control protocol. Wide-area control has significantly
   different requirements regarding trust-models and scalability and
   must deal with different problems regarding reliability and message
   transport delay.

   The message transport service provides group- and
   point-to-point-communication. It does not offer all the features
   that are frequently found in protocols for coordinating distributed
   applications in general such as guaranteeing a global or causal
   ordering of delivered messages.

   Given these deliberate restrictions in functionality it is important
   to note that the Mbus implies a component model where communication
   between components can be realized without services from a
   full-featured infrastructure for distributed applications.

   Message exchange takes place using UDP: datagrams are sent either
   via unicast to a single entity or multicast to a locally scoped
   group. For unicast communications, message delivery is optionally
   performed reliably, with acknowledgements and retransmissions taking
   place at the Mbus transport layer. All group communication is
   performed unreliably. For deployment in scopes larger than
   link-local Mbus the multicast address (i.e., the multicast scope to
   use) can be configured accordingly, or bridging elements can be
   deployed that interconnect two or more Mbus domains.

   For unicast communications, message delivery is optionally performed
   reliably, with acknowledgements and retransmissions taking place at
   the Mbus transport layer. Point-to-point and multicast communication
   is in general not distinguished by the transmission mechanism
   employed at the IP layer but rather by the qualification of the Mbus
   destination address. There is however the possibility to use
   IP-unicast for messages that are directed to a single receiver. (See
   section Entity Awareness.)

Kutscher & Ott          Expires August 24, 2001                 [Page 3]

Internet-Draft           Mbus appliance control            February 2001

   A key concept of the Mbus is its flexible and extensible addressing
   scheme. Mbus entities are identified by n-tuples with each component
   of the tuple represented as an attribute-value pair. The addressing
   scheme for conferencing applications includes address elements like
   conference (conf), media (media), module type (module), application
   name (app), and application identifier (id). For example:

   (class:lamp location:bedroom floor:1 id:1035-0@

   Each Mbus entity responds to messages addressed to any subset of its
   own address. For example, the entity with the address illustrated
   above will respond to messages pro-viding the following target

   (class:lamp location:bedroom floor:1 id:1035-0@

   (class:lamp location:bedroom id:1035-0@

   (class:lamp id:1035-0@



   A fully qualified address (with all components of the tuple present)
   indicates a unicast Mbus address. Messages with incomplete addresses
   have the potential to be received by multiple entities.

   An entity on the Message Bus can learn the existence of other
   entities (and their complete addresses) by listening to the
   self-announcement messages that all entities send periodically. The
   rate at which these periodic heartbeat messages are sent is adapted
   dynamically depending on the number of entities in a Mbus session,
   thus allowing the Mbus to scale to larger groups of entities.

   This mechanism is used to locate entities and to monitor their
   liveness during a session but also to build a complete set of the
   addresses of all available entities -- Mbus layer addresses and
   transport layer addresses. The latter information can be used for
   optimization strategies, e.g. for deciding whether a message can be
   sent via IP-unicast.

   Based upon these awareness functions, a bootstrap procedure is
   defined that allows entities to determine whether all other entities
   they depend on are present (without bearing the risk of deadlocks).

   Each entity has a unique Mbus address that can be used to identify
   it and that is composed of any number of named address elements. The
   types and values of address elements are application-specific and

Kutscher & Ott          Expires August 24, 2001                 [Page 4]

Internet-Draft           Mbus appliance control            February 2001

   can be used to aggregate entities into address groups.

   Address element names may be associated with semantics: by providing
   certain address elements, entities can signal the type of service
   functionality they are able to supply. The Mbus specification itself
   does not impose any restrictions on application specific address
   elements. The semantics are provided by application specific
   profiles. For example, the address element set for conferencing
   applications defines elements for distinguishing entities by the
   media type that is assigned to them allowing a local conference
   controller to address one or more audio, video and other media

   A message that is to be sent via the Mbus has a target address -- at
   the application level -- that is used to determine how to deliver
   the respective message. This allows for subject-based
   addressing-like message delivery semantics and different
   communication models represented by the different group addressing

   Broadcast: When a target address list is empty the message is
      broadcast to all entities on the Mbus.

   Unicast: A message that contains a target address that is a unique
      Mbus address of another entity will be processed by this entity
      only. The Mbus defines mechanisms allowing such messages to be
      sent directly via unicast to the specific en-tity.

   Multicast: As mentioned above target addresses can be used to
      identify groups on a per-message basis. All entities that match
      the given target address will receive and process corresponding
      messages: In situations where a certain module requires a
      specific service functionality, that can be pro-vided by more
      than one other module, it can use a multicast address specifying
      the group of service providers to locate the desired entity. This
      may facilitate the imple-mentation of service clients
      significantly: addresses of ser-vice providers do not need to be
      hardcoded and the com-munication model can accommodate many
      different spe-cific scenarios regardless of the number of
      potential service providers.

   It is not necessary to know the exact addresses of all potential
   receivers of a message. Instead a sufficiently unam-biguous address
   list can be used. For example, in order to reach all audio engines
   in a session the address list (media:audio module:engine) might be

   Mbus messages are text-encoded and consist of a header with protool
   information and a payload section that can carry several textual

Kutscher & Ott          Expires August 24, 2001                 [Page 5]

Internet-Draft           Mbus appliance control            February 2001

   commands with parameter lists. Command names are hierarchical and a
   set of basic data types for command parameters is defined, including
   numeric types, character strings, lists and opaque data.

   Message authentication and encryption are supported as inherent
   transport features to prevent malicious attacks and to provide
   privacy for the communication within an Mbus domain. This allows the
   Mbus to accommodate multiple sessions of a user per host (including
   cross-session coordination) as well as any number of users on the
   same host or link (preventing accidental cross-user interaction).

   The Mbus guidelines[2] define a list of conventions for terminology,
   algorithms and procedures for higher level interaction models that
   are useful for applications using the Mbus. These conventions are
   intended as guidelines for designers of Mbus application profiles
   and Mbus implementations/applications.

   This document builds on these two specifications and provides an
   Mbus application profile for Internet Appliance Control that uses
   the conventions codified in the Mbus guidelines[2] to specify an
   Mbus application profile, i.e., a list of Mbus commands and
   procedures that allow to implement Internet appliances and
   corresponding controllers.

1.2 Scope of this Document

   This document discusses a first command set and corresponding
   interactions between application components for Internet appliance
   control, such as

   o  locating appliances;

   o  discovering capabilities and services of appliances;

   o  sending event notifications from appliances to controllers or
      other appliances; and

   o  sending controlling messages to appliances.

   The Mbus commands presented are mainly intended as illustrations of
   the principle discussed here. Because the requirements of the
   application are not yet defined, we only present examples for the
   sake of clarification and for initiating discussions.

Kutscher & Ott          Expires August 24, 2001                 [Page 6]

Internet-Draft           Mbus appliance control            February 2001

2. The System Model

   The system model that is used in this document assumes that the
   appliances of a certain control domain, e.g., a house, build a
   cooperation group, that includes appliances (controllees) as well as
   controllers. However, a clear distinction between controllers and
   controllees is not always reasonable. For example, the event
   notifications generated by a certain appliance might be of interest
   to more than one entity, e.g., a controller. Instead, the
   corresponding information could be useful for a group of entities at
   the same time.

   On the other hand, is is required to ensure that a certain
   appliance, say a microwave oven, is controlled by exactly one
   controller at a time, without the possibility of conflicts that
   could arise from receiving control messages from different entities.

   We therefore distinguish between different types of interaction
   between appliances. Some interaction styles are appropriate for
   group communication, while others should be realized with the notion
   of tight, exclusive control relations.

Kutscher & Ott          Expires August 24, 2001                 [Page 7]

Internet-Draft           Mbus appliance control            February 2001

         +------------------- Mbus Appliance Domain ----------------+
         |                                                          |
         | +---------------+   +---------------+  +---------------+ |
         | |               |   |               |  |               | |
         | |   microwave   |   |  light switch |  |    radio      | |
         | |               |   |               |  |               | |
         | +---------------+   +---------------+  +---------------+ |
         |         |                   |                  |         |
         |         |                   |                  |         |
         | +---------------+   +---------------+  +---------------+ |
         | |               |   |               |  |    house      | |
         | |      TV       |   |   alarm clock |  |    alarm      | |
         | |               |   |               |  |    system     | |
         | +---------------+   +---------------+  +---------------+ |
         |                            ||                            |
                                      || Wide Area Control
                                      ||     Protocol

   As shown in the above picture, we assume that a group of appliances
   is modeled as an Mbus domain where a set of Mbus entities represent
   the appliances. It is further assumed, that wide area control is to
   be provided by a dedicated control protocol, e.g., a SIP-based
   protocol. See Section 5 for a disussion of the interworking with a
   wide area control protocol.

Kutscher & Ott          Expires August 24, 2001                 [Page 8]

Internet-Draft           Mbus appliance control            February 2001

3. Characteristics

3.1 Addressing

   The Mbus provides a subject-based addressing mechanism. This means,
   an appliance can use a descriptive address that contains information
   about service functionality it can provide. This information can be
   used for addresses of messages that are to be sent to the appliance.
   Using the wildcard/group communication mechanisms it thus is
   possible to address messages to an appliance by refering to a
   function (or other criteria).

   There is another aspect of the Mbus addressing mechanism: Appliances
   that are generating periodic event notifications that would be sent
   to a well-known group target address. Other appliances can "tune in"
   into this event notification "channel" by choosing ("joining") a
   proper Mbus address. This is a scalable way to implement simple
   "subscribe/notify" scenarios, because the entities that generate the
   notifications do not have to know the exact list of subcribers.

3.2 Autoconfiguration

   In general, it should be possible to connect a set of appliance
   systems without having to manually configure them. There might be
   some degree of configuration that is required to setup trust
   relationships etc. but apart from that, it is probably not
   acceptable to require customers to configure and maintain databases
   of IP addresses and other information about their appliances in
   order to be able to control and use them.

   The Mbus can help to reduce the amount of manual configuration by
   its addressing architecture and the notion of a "soft state" of
   addressing information that is maintained at each Mbus entity:

   As described in Section 3.1, entities are addressed using subject
   based addressing. This means, it is not always required to know the
   addresses of receivers exactly, because the group communication
   mechanisms allow senders to send messages to a group address.

   Additionally, the entity awareness mechanism enables entities to
   build and maintain a list of active entities. Because of the
   periodic self-announcement messages that are sent by each entity,
   this state can be "soft", does not have to be initialized manually
   and is updated automatically.

3.3 Serverless Operation

   In order to achieve plug-and-play functionality, robustness, device
   mobility and ease of deployment it is required to be able to have

Kutscher & Ott          Expires August 24, 2001                 [Page 9]

Internet-Draft           Mbus appliance control            February 2001

   appliance functioning correctly without having to supply a central
   server. A central server would have to be installed, maintained --
   and may possibly fail at some time.

   Due to the entity awareness mechanisms and the peer-to-peer
   communication model, the Mbus can accomodate serverless operation
   very easily: Mbus based appliances can be attached to a network and
   will immediately be able to communicate without the need of a
   central server. (It should be noted, though, that servers of any
   kind may be supplied to provide for (de-)centralized functionality).

3.4 Interaction Models

   Within a group of appliances, more than the obvious client-server
   communication model will be required. The two most important
   communication styles:

   Event notification: In an appliance environment, it is useful to
      have certain appliances asynchronously send certain information
      that other entities can take advantage of.
      Using group communication and the notion of subject based
      addressing it is possible to realize this functionality.

   RPCs: In order to control appliances reliably, it is required to
      invoke remote procedures and receive acknowledgements in order to
      obtain results and error notifications. For a message oriented
      communication infrastructure, this means that a mechanism for
      reliable message transmission and the possibility to relate
      reponses to message invocations is required. The Mbus therefore
      provides reliable message transmission of messages that are sent
      to a single entity. The [2] provide convention for building RPC
      communicatin upon this basic reliable message exchange.

Kutscher & Ott          Expires August 24, 2001                [Page 10]

Internet-Draft           Mbus appliance control            February 2001

4. Examples

   In the following sections we present some scenarios and potential
   sample message exchanges that are primarily intended to illustrate
   the ideas behind appliance control via the Mbus.

4.1 Integrating Devices into an Appliance Network

   Home Configuration:

   1.  Buy.

   2.  Install and "plug in" (provide local KEY for HMAC and possibly

   3.  Provide keys possibly use multi-level key provisioning s in
       Bluetooth or similar environments.

   4.  Determine device level parameters in browser.

   5.  Assign name and other home level parameters.
       This step could be automated if an individual "locator"
       components is available per logical location and there is no
       interference between these components.  This could e.g. be
       realized by having an individual link in each room and a
       room-local multicast address.

   Home level parameters can either be stored in the devices
   themselves, or, in the case of dumb devices, be stored externally.
   In that case, the devices could either be configured dynamically to
   use the home level address or proxy entities could be deployed that
   represent the entities using the home level addresses and relay
   messages to the device level addresses.

   Functional components:

   o  Device manager (e.g. Mbus Browser)

   o  Device proxy

      *  for non-Mbus entities

      *  for very trivial entities

   1.  Tell the vendor when you buy it and have him configure it
       properly (plus remote maintenance service).

   2.  Use a small configuration tool (Mbus Browser) and store the
       settings in the device (in permanent storage).

Kutscher & Ott          Expires August 24, 2001                [Page 11]

Internet-Draft           Mbus appliance control            February 2001

   3.  Use a small configuration tool (Mbus Browser) and store the
       settings in some bootstrap device (for the device itself has
       only ephemeral storage) -> BOOTP/DHCP-style initialization

   4.  Provide some proxying mechanisms.

   5.  ...

   Appearance on the Mbus:

   mbus/1.0 U (id:4711@ class:lamp) () ()
   mbus.hello ()
   ia.desrcription (vendor=Fasel name=lignerose-designer-lamp ...)
   ia.caps (power) (power=100W bulbs=3 voltage=220V current=0.5A)
   ia.status.power (off)


   mbus/1.0 U (id:4711@ class:lamp) () ()
   mbus.whereami ()


   mbus/1.0 U (class:configurator id:4711) (id:4711@ class:lamp) ()
   mbus.associate (id:com.manufacturer.lamp.23765827346593 floor:1 \
              location:bedroom name:my-reading-light)

   Re-appearance on the Mbus:

   mbus/1.0 U (id:4711@ class:lamp floor:1 location:bedroom \
              name:my-reading-light) () ()
   mbus.hello ()

4.2 Controlling Appliances

   Controlling a lamp:

   mbus/1.0 R (id:875462873694 class:remote-control) (id:4711@ class:lamp) ()
   power.on ()
   power.dim (0.50)

   Asynchronous status notification:

   mbus/1.0 U (id:4711@ class:lamp) (class:lamp status)
   power.status (on dim=50)

Kutscher & Ott          Expires August 24, 2001                [Page 12]

Internet-Draft           Mbus appliance control            February 2001

   Shutdown when leaving the house:

   mbus/1.0 U (class:door name:front-door id:4711) (class:lamp) ()

   Alternative: subcribe/notify

   mbus/1.0 R (id:4711@ class:monitor) (id:4711@ class:lamp)
   mbus.subscribe (power.status)

   mbus/1.0 R (id:4711@ class:lamp)  (id:4711@ class:monitor)
   power.status (on dim=50)

   Independent provision and consumption of information:

   mbus/1.0 U (class:environment id:76490947983 name:terrace-thermometer) \
              (class:environment) ()
   weather.temperature ("25F")

   mbus/1.0 U (class:environment id:76490947984 name:light-sensor) (class:environment) ()
   weather.light (brightness:0.25)

   mbus/1.0 U (class:clock id:76490947985) (class:clock) ()
   clock.current-time ("18:25:17 UTC")
   clock.alarm-time (name="wakeup" time="07:00:00 UTC")
   clock.alarm-time (name="call-mother-in-law" time="21:00:00 UTC")

   mbus/1.0 U (class:remote-control id:4774856923649) (class:clock id:76490947985) ()
   clock.alarm.set (name="coffee" time="06:50:00 UTC" address="class:coffee-maker" \
              command="coffee.brew (\"type=strong\")")

   mbus/1.0 U (class:clock id:76490947985) (class:clock) ()
   clock.current-time ("18:25:17 UTC")
   clock.alarm-time (name="wakeup" time="07:00:00 UTC")
   clock.alarm-time (name="call-mother-in-law" time="21:00:00 UTC")
   clock.alarm-time (name="coffee" time="06:50:00 UTC")

   mbus/1.0 U (class:remote-control id:4774856923649) (class:clock id:76490947985) ()
   clock.alarm.delete (name="call-mother-in-law")

   Alarm at 06:50:

   mbus/1.0 U (class:clock id:76490947985) (class:coffee-maker) ()
   coffee.brew ("type=strong")

Kutscher & Ott          Expires August 24, 2001                [Page 13]

Internet-Draft           Mbus appliance control            February 2001

Kutscher & Ott          Expires August 24, 2001                [Page 14]

Internet-Draft           Mbus appliance control            February 2001

5. Interworking with Wide Area Control

   Since the Mbus-based control of appliances is defined for local
   network of appliances only the issue of how to provide remote
   control from arbitrary Internet hosts need to be addressed.

   We propose the use of gateway systems that translates requests from
   a controller to Mbus messages. The protocol that is used for wide
   area control is not defined in this document. It could be HTTP or a
   SIP variant. A few required properties for such an protocol can be

         +------------------- Mbus Appliance Domain ----------------+
         |                                                          |
         | +---------------+   +---------------+  +---------------+ |
         | |               |   |               |  |               | |
         | |   microwave   |   |  light switch |  |    radio      | |
         | |               |   |               |  |               | |
         | +---------------+   +---------------+  +---------------+ |
         |         |                   |                  |         |
         |         |                   |                  |         |
         | +---------------+   +---------------+  +---------------+ |
         | |               |   |               |  |    house      | |
         | |      TV       |   |  Mbus gateway |  |    alarm      | |
         | |               |   |               |  |    system     | |
         | +---------------+   +---------------+  +---------------+ |
         |                            ||                            |
                                      || Wide Area Control
                                      ||     Protocol
                            |    Remote     |
                            |  Controller   |
                               |               |

Kutscher & Ott          Expires August 24, 2001                [Page 15]

Internet-Draft           Mbus appliance control            February 2001

6. Integrating Dumb Devices

   Not every device that needs to be controlled in an appliance network
   can be equipped with a TCP/IP and an Mbus stack. There may be cost
   issues for very small devices or the issue of legacy devices that
   users want to be able to integrate.

   Since a host with an Mbus stack can host more than one Mbus entity
   that are uniquely addressable, the proposed solution for these
   scenarios is to employ "proxy" Mbus systems that simply represent
   the dumb devices that cannot directly connect to the Mbus.

   In fact, the presence of such a proxy system is completely
   transparent to the other entities of an Mbus session since it is not
   a special to have multiple entities reside on one host.

   The way how those dumb devices are connected to and controlled by an
   proxy system is of course left to the implementations and is not
   subject of this document.

   The following figure illustrates this using the example of a proxy
   system for a set of light bulbs.

Kutscher & Ott          Expires August 24, 2001                [Page 16]

Internet-Draft           Mbus appliance control            February 2001

         +------------------- Mbus Appliance Domain ----------------+
         |                                                          |
         | +---------------+   +---------------+  +---------------+ |
         | |               |   |               |  |               | |
         | |   microwave   |   |  light switch |  |    radio      | |
         | |               |   |               |  |               | |
         | +---------------+   +---------------+  +---------------+ |
         |         |                   |                  |         |
         |         |                   |                  |         |
         | +---------------+   +---------------+  +---------------+ |
         | |               |   |               |  |    house      | |
         | |      TV       |   |  Mbus proxy   |  |    alarm      | |
         | |               |   |               |  |    system     | |
         | +---------------+   +---------------+  +---------------+ |
         |                       /     |     \                      |
         |                      /      |      \                     |
         |                     /       |       \                    |
         |             +----------+    |    +----------+            |
         |             |Light bulb|    |    |Light bulb|            |
         |             +----------+    |    +----------+            |
         |                             |                            |
         |                        +----------+                      |
         |                        |Light bulb|                      |
         |                        +----------+                      |
         |                                                          |

Kutscher & Ott          Expires August 24, 2001                [Page 17]

Internet-Draft           Mbus appliance control            February 2001


   [1]  Ott, J., Perkins, C. and D. Kutscher, "A Message Bus for Local
        Coordination", Internet Draft draft-ietf-mmusic-mbus-03.txt,
        December 2000.

   [2]  Kutscher, D., "The Message Bus: Guidelines for Application
        Profile Writers", Internet Draft
        draft-ietf-mmusic-mbus-guidelines-00.txt, February 2001.

   [3]  Handley, , Schulzrinne, H., Schooler,  and  Rosenberg, "SIP:
        Session Initiation Protocol", Internet Draft
        draft-ietf-sip-rfc2543bis-02.txt, November 2000.

Authors' Addresses

   Dirk Kutscher
   TZI, Universitaet Bremen
   Bibliothekstr. 1
   Bremen  28359

   Phone: +49.421.218-7595
   Fax:   +49.421.218-7000

   Joerg Ott
   TZI, Universitaet Bremen
   Bibliothekstr. 1
   Bremen  28359

   Phone: +49.421.201-7028
   Fax:   +49.421.218-7000

Kutscher & Ott          Expires August 24, 2001                [Page 18]

Internet-Draft           Mbus appliance control            February 2001

Full Copyright Statement

   Copyright (C) The Internet Society (2001). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an


   Funding for the RFC editor function is currently provided by the
   Internet Society.

Kutscher & Ott          Expires August 24, 2001                [Page 19]