Network Working Group Kutscher
Internet-Draft Ott
Expires: August 24, 2001 TZI, Universitaet Bremen
February 23, 2001
An Mbus Profile for Internet Appliance Control
draft-kutscher-mbus-ipac-00.txt
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.
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
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 24, 2001.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
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
entities.
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@192.168.1.1)
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
addresses:
(class:lamp location:bedroom floor:1 id:1035-0@192.168.1.1)
(class:lamp location:bedroom id:1035-0@192.168.1.1)
(class:lamp id:1035-0@192.168.1.1)
(class:lamp)
()
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
tools.
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
features:
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
appropriate.
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
encryption).
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
protocol.
4. Provide some proxying mechanisms.
5. ...
Appearance on the Mbus:
mbus/1.0 U (id:4711@192.168.1.11 class:lamp) () ()
mbus.hello ()
ia.desrcription (vendor=Fasel name=lignerose-designer-lamp ...)
ia.caps (power)
ia.properties (power=100W bulbs=3 voltage=220V current=0.5A)
ia.status.power (off)
Query:
mbus/1.0 U (id:4711@192.168.1.11 class:lamp) () ()
mbus.whereami ()
Response:
mbus/1.0 U (class:configurator id:4711) (id:4711@192.168.1.11 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@192.168.1.11 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@192.168.1.11 class:lamp) ()
power.on ()
power.dim (0.50)
Asynchronous status notification:
mbus/1.0 U (id:4711@192.168.1.11 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)
power.off ()
Alternative: subcribe/notify
mbus/1.0 R (id:4711@192.168.1.23 class:monitor) (id:4711@192.168.1.11 class:lamp)
mbus.subscribe (power.status)
mbus/1.0 R (id:4711@192.168.1.11 class:lamp) (id:4711@192.168.1.23 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
given.
+------------------- 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
References
[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
Germany
Phone: +49.421.218-7595
Fax: +49.421.218-7000
EMail: dku@tzi.org
Joerg Ott
TZI, Universitaet Bremen
Bibliothekstr. 1
Bremen 28359
Germany
Phone: +49.421.201-7028
Fax: +49.421.218-7000
EMail: jo@tzi.org
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
English.
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
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Kutscher & Ott Expires August 24, 2001 [Page 19]