path: root/doc/rfc/rfc3054.txt

Network Working Group                            P. Blatherwick (Editor)
Request for Comments: 3054                               Nortel Networks
Category: Informational                                         R. Bell
                                                           Cisco Systems
                                                              P. Holland
                                                    Circa Communications
                                                   (Chair TIA TR-41.3.4)
                                                            January 2001


           Megaco IP Phone Media Gateway Application Profile

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This document specifies a particular application of the Megaco/H.248
   Protocol for control of Internet telephones and similar appliances:
   the Megaco IP Phone Media Gateway.  The telephone itself is a Media
   Gateway (MG), controlled by the Megaco/H.248 Protocol, with
   application control intelligence located in the Media Gateway
   Controller (MGC).  To achieve a high degree of interoperability and
   design efficiency in such end-user devices, a consistent
   architectural approach, a particular organization of Terminations and
   Packages, and a Protocol Profile are described.  The approach makes
   use of existing Protocol features and user interface related
   Packages, and is thus a straight-forward application of the
   Megaco/H.248 Protocol.

1.  Introduction

   This document represents the current view from the TIA working group
   on VoIP (Voice over IP) telephone specification [1], TIA TR-41.3.4,
   with the intent of using this as part of its "whole device"
   specification as an optional method of device control.

   Industry feedback has made it clear that interoperability and
   acoustic performance of Internet telephones is key to the rapid and
   extensive commercialization of these products.  To facilitate this,
   the TIA has established working group TR-41.3.4 to develop a standard



Blatherwick, et al.          Informational                      [Page 1]
^L
RFC 3054      Megaco IP Phone Media GW Application Profile  January 2001


   for VoIP telephones.  The TR-41.3.4 working group has included the
   "whole device" within the scope of the standard, so a full range of
   requirements including acoustic performance, protocols, methods for
   powering and safety are provided.  Where possible, the requirements
   are based on existing standards, which are included by reference.

   The TIA TR-41.3.4 working group has also recognized that its proposed
   standard must enable creative application of the equipment, encourage
   the development of new capabilities and allow for high levels of
   product customization.  To achieve this, peer to peer architectures
   that are based on protocols such as H.323 or SIP and master/slave
   architectures such as Megaco/H.248 Protocol are both necessary and
   complementary.

   In support of the Megaco/H.248 Protocol development effort, the TR-
   41.3.4 working group has considered product enabling issues and
   requirements, and has developed an approach to use the Megaco/H.248
   Protocol for Internet telephone device control.  This document
   represents the working group's current view.

   This document covers the general requirements of the Megaco IP Phone
   application (section 3), architectural approach and MG organization
   (section 4), details of specific Termination types used and Packages
   supported by each (section 5), and the Megaco IP Phone Protocol
   Profile (section 6).

2.  Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in RFC 2119 [5].

3.  General Requirements

   The following general requirements were identified to drive the
   Megaco IP Phone design [1]:

   1. The Megaco IP Phone must meet the basic needs of the business user
      from day one;

   2. Provide a path for rapid expansion to support sophisticated
      business telephony features;

   3. Flexibility to allow for a very wide range of telephones and
      similar devices to be defined, from very simple to very feature
      rich;

   4. Simple, minimal design;



Blatherwick, et al.          Informational                      [Page 2]
^L
RFC 3054      Megaco IP Phone Media GW Application Profile  January 2001


   5. Allow device cost to be appropriate to capabilities provided;

   6. Packages and Termination types must have characteristics that
      enable reliability;

   7. The IP Phone MG shall meet the appropriate Megaco/H.248 Protocol
      requirements as provided in the Megaco Requirements document [2]
      and be a straight-forward application of the Megaco/H.248 Protocol
      [3].

4.  Architecture Description

   The following subsections describe the general design approach and
   organization of the Megaco IP Phone MG.

4.1.  Design Approach

   Design intent of the Megaco IP Phone is to keep it determinedly
   simple while providing required support for fully featured business
   telephones and the flexibility to allow for a very wide range of
   telephone configurations and similar appliances.

   The approach to achieve this goal is to provide a very simple and
   direct master/slave control model in which very little feature
   intelligence is required in the end device.  This design intent
   matches the Megaco/H.248 Protocol approach well.

   It is important to note that additional functionality, built-in
   feature capability or system-specific optimization can easily be
   provided, at the option of the implementer, by defining additional
   Termination types, Event/Signal Packages, or providing built-in
   application capability.  This document defines the minimal design
   only.

4.2.  General Structure

   As shown in Figure 1 below, the Megaco IP Phone is organized as a
   Media Gateway (MG) that consists of a User Interface Termination and
   a set of Audio Transducer Terminations.

   Several - potentially thousands - of Megaco IP Phone MGs may be
   controlled by a single Media Gateway Controller (MGC).  This is
   distinguished from the organization between traditional analog or PBX
   telephones behind an IP network, where the MGC would control an MG
   which in turn controls the collection of telephone devices in
   question.  In the case of a Megaco IP Phone MG, the MG directly





Blatherwick, et al.          Informational                      [Page 3]
^L
RFC 3054      Megaco IP Phone Media GW Application Profile  January 2001


   implements the media terminations like handset, handsfree and
   headset, as well as the user interface.  In this case, the Megaco IP
   Phone itself is the MG.

                             +---------------+
                             |               |
                             |      MGC      |
                             |               |
                             +---------------+
                                     ^ \ \ \
                                     |
                                     v
               +---------------------------------------------+
               |                                             |
               |   Megaco IP Phone MG                        |
               |   ==================      Audio Transducer  |
               |                           Terminations:     |
               | Audio context(s):         + - - - - - - - + |
               | +---------------------+     +-----------+   |
               | |     Context A       |   | | Handset   | | |
               | |                     |     +-----------+   |
          RTP  | |  +-----+   +-----+  |   | +-----------+ | |
      <--------+-+->| Tr  |   | Ta2 |<-+-----| Handsfree |   |
        audio  | |  +-----+   +-----+  |   | +-----------+ | |
       stream  | |                     |     +-----------+   |
               | +---------------------+   | | Headset   | | |
               |                             +-----------+   |
               |                           |               | |
               |                              ETC.           |
               |                           + - - - - - - - + |
               |                                             |
               |  +----------------------------------------+ |
               |  | User Interface Termination             | |
               |  | +--------------+      +--------------+ | |
               |  | | Text Display |      | Keypad       | | |
               |  | +--------------+      +--------------+ | |
               |  | +--------------+      +--------------+ | |
               |  | | Softkeys     |      | Indicators   | | |
               |  | +--------------+      +--------------+ | |
               |  | +--------------+                       | |
               |  | | Function Keys|       ETC.            | |
               |  | +--------------+                       | |
               |  +----------------------------------------+ |
               +---------------------------------------------+

             Figure 1: Megaco IP Phone Termination / Package Model





Blatherwick, et al.          Informational                      [Page 4]
^L
RFC 3054      Megaco IP Phone Media GW Application Profile  January 2001


4.3.  Termination / Package Organization

   As shown in Figure 1, each Audio Transducer Termination represents an
   individually controllable audio input/output element of the telephone
   device, such as Handset, Handsfree, Headset, etc.  By separating each
   audio element as a distinct Termination, more flexible applications
   can be easily implemented, such as paging, group listening, and so
   on. Since this is actually only the logical view of the device,
   represented by protocol, it is also quite possible to simplify
   representation of the device by hiding all available audio
   input/outputs behind a single Audio Transducer Termination, for
   example the Handset, and implement control of multiple real
   input/outputs locally inside the device.

   All non-audio user interface elements are associated with the User
   Interface Termination.  This special Termination supports Packages to
   implement all user interaction with the telephone user interface,
   including Function Keys, Indicators, the Dialpad, etc, as appropriate
   for the specific device capabilities (within constraints given in the
   section on User Interface Termination).  The User Interface
   Termination cannot be placed in any Context.  This grouping of user
   interface elements behind a well-know Termination greatly simplifies
   audits to determine actual device configuration, and reduces the
   number of Terminations involved in representing user interface.

   In addition, TerminationID naming conventions are provided to
   identify specific Terminations within the Megaco IP Phone MG and
   group them into related sets.  These conventions use a set of well
   known identifier names to specify the individual Terminations, for
   example the User Interface Termination ("ui"), the Handset Audio
   Transducer ("at/hs"), or the Handsfree Audio Transducer ("at/hf").
   This specific naming is important in this application, especially for
   the Audio Transducer Terminations, since the real input/output
   elements to which they map on the physical device have very different
   functional significance to the end-user, yet they may be represented
   in the protocol using exactly the same sets of Packages.  Naming
   conventions allow the controlling MGC to distinguish this end-user
   meaning without specific advance knowledge of physical device
   configuration and without the requirement to provide different
   Packages for each audio input/output type.

   Using these same TerminationID naming conventions in combination with
   wildcards, the MGC application can target commands to groups of
   related Terminations, for example the collection of all Audio
   Transducer Terminations ("at/*").  This is especially useful during
   the discover phase, for example to efficiently Audit all available
   Audio Transducer Terminations, and to efficiently send commands to a
   set of related Terminations in a single command, for example to



Blatherwick, et al.          Informational                      [Page 5]
^L
RFC 3054      Megaco IP Phone Media GW Application Profile  January 2001


   simultaneously Subtract all Audio Transducer Terminations from a
   particular Context.  Further information on TerminationID naming
   conventions and their use can be found under the sections on Control
   Interaction and Capability Discovery (next two subsections) and under
   Termination Types.

4.4.  Control Interaction

   To provide control of audio paths, Audio Transducer Terminations are
   manipulated using Contexts in the normal way, by sending Add, Move,
   Subtract and Modify commands addressed to the specific Terminations
   being manipulated.  For example creating a Context (Context A)
   containing an RTP Termination (Tr) and a Handset Audio Transducer
   Termination (Ta1) creates a voice connection to/from the handset.
   Moving a Handsfree Audio Transducer Termination (Ta2) into the
   Context, and removing the Handset, sets up a handsfree conversation.
   This situation is shown in Figure 1.  See the section on Audio
   Transducer Termination Types for further details on specific Package
   support requirements.

   User input elements, such as Keypad or Function Keys, generate Events
   through Notify commands sent from the User Interface Termination of
   the Megaco IP Phone MG to the controlling MGC for handling.  These
   Events are according to the specific set of Packages supported by the
   User Interface Termination of the device.  See the section on User
   Interface Termination Type for further details on specific Package
   support requirements.

   User output elements such as the Text Display or Indicators are
   controlled by Signals sent by the MGC, addressed to the User
   Interface Termination of the Megaco IP Phone MG, generally as part of
   a Modify command, using syntax defined in the corresponding Packages.
   Since the User Interface Termination cannot be part of any context,
   Add, Move and Subtract commands sent to it are not valid.  See the
   section on User Interface Termination Type for further details on
   specific Package support requirements.

   Some elements, for example Softkeys, have both user input and output
   aspects, so both react to Signals and generate Events as above.

   The TerminationID naming conventions may be used to target commands
   to specific Terminations by well known name, for example to Add the
   Handsfree Audio Transducer Termination ("at/hf") to a Context.  The
   naming conventions in combination with wildcards may be used to
   efficiently send commands to groups of related Terminations, for
   example to simultaneously Subtract all Audio Transducer Terminations
   ("at/*") from a particular Context.




Blatherwick, et al.          Informational                      [Page 6]
^L
RFC 3054      Megaco IP Phone Media GW Application Profile  January 2001


4.5.  Capability Discovery

   At startup or service change, the Megaco IP Phone MG identifies
   itself to its controlling MGC as being a Megaco IP Phone class of
   device by use of the IPPhone Protocol Profile.  This is the first and
   most important stage of capability discovery, and implicitly provides
   a great deal of the necessary information in a single step.
   Thereafter, the MGC can make a large number of assumptions regarding
   organization and behavior of the MG.  See the section on IPPhone
   Protocol Profile for further details of ServiceChange operation.

   Device capabilities, including the list of all Terminations and
   supported Packages for each, are queried through the AuditValue
   command.  Wildcarded AuditValue commands targeted at the whole MG
   (i.e., addressed to ContextID=Null, TerminationID=ALL) return the
   list of all Terminations, including the User Interface Termination
   and all supported Audio Transducer Terminations.  Since the returned
   TerminationIDs use well known identifier names, the MGC can derive
   the specific audio input/output elements available on the physical
   device, and their intended purpose.  Further AuditValues commands on
   individual named Terminations provide further details of each, for
   example for the MGC to query user interface support Packages
   available on the User Interface Termination ("ui").  TerminationID
   naming conventions in combination with wildcards can be used with
   AuditValues commands to query specific Package support for the
   collection of all Audio Transducer Terminations ("at/*").

   Since the structure of the Megaco IP Phone MG is well known in
   advance, by virtue of the IPPhone Protocol Profile, audits can be
   efficiently directed at discovering only what additional information
   is required by the MGC.  Thus the MGC is able to efficiently and
   unambiguously discover both the specific user interface capabilities
   and the supported audio input/outputs of the Megaco IP Phone MG,
   without specific advance knowledge of physical device configuration.
   It is not necessary for the MGC to attempt to infer function from
   supported Packages within a random collection of Terminations, and a
   great deal of behavior common to all Megaco IP Phone MGs can simply
   be assumed.  This pre-determined organization and behavior therefore
   greatly reduces design complexity of both MG and MGC, and greatly
   improves interoperability.

5.  Termination Types

   The Termination types defined for use in the Megaco IP Phone MG are:

   *  User Interface (implements user interface);





Blatherwick, et al.          Informational                      [Page 7]
^L
RFC 3054      Megaco IP Phone Media GW Application Profile  January 2001


   *  Audio Transducer (implements audio input/output to the user, and
      potentially appears as several individual Terminations
      corresponding to individual audio input/outputs on the physical
      device);

   *  RTP (transport of audio streams over IP).

   These Termination types represent minimal capabilities to support
   fully featured business telephones.  Additional Termination types can
   be defined to extend these capabilities.

   The following subsections describe requirements and constraints on
   each type in further detail.

5.1.  User Interface Termination Type

   The User Interface Termination represents the Megaco IP Phone MG user
   interface elements.  Megaco IP Phone MGs MUST support exactly one
   User Interface Termination.

   TerminationID of the User Interface Termination MUST be "ui", used
   for both command addressing and command response return.  ABNF text
   encoding for this MUST be as described in Megaco/H.248 Protocol
   Appendix B.1 [3].

   Note: If ASN.1 binary encoding is used (OPTIONAL in this
   specification), TerminationID for the User Interface Termination MUST
   be encoded as described in Megaco/H.248 Protocol Appendix A.1 [3],
   with alphabetic characters of the identifier given above mapping to
   the equivalent octet string in the ASN.1 encoding.

   The User Interface Termination cannot be part of any context, hence
   Add, Move and Subtract commands are invalid for this Termination.

   The User Interface Termination MAY support the following Packages,
   defined in Megaco/H.248 Protocol H.248 Annex G: "User Interface
   Elements and Actions Packages" [4].














Blatherwick, et al.          Informational                      [Page 8]
^L
RFC 3054      Megaco IP Phone Media GW Application Profile  January 2001


       __________________________________________________________
      | Package           | Name   | Support in User Interface   |
      |                   |        | Termination                 |
      |___________________|_______ |_____________________________|
      | Text Display      | dis    | OPTIONAL                    |
      | Keypad            | kp     | OPTIONAL                    |
      | Function Key      | kf     | OPTIONAL                    |
      | Indicator         | ind    | OPTIONAL                    |
      | Softkey           | ks     | OPTIONAL                    |
      | Ancillary Input   | anci   | OPTIONAL                    |
      |___________________|________|_____________________________|

   Additional Packages not listed above MAY also be provided where these
   are defined to extend to additional user interface elements.

   Note: The reasoning to make all Packages optional in the User
   Interface Termination is to allow maximum flexibility to create a
   very broad range of Internet telephones and similar devices.  For
   example, anything from a simple hotel lobby phone (handset and
   hookswitch only), to conferencing units (handsfree unit and one or
   two buttons) to fully featured business telephones (display, rich set
   of keys and indicators, both handset and handsfree, etc) could be
   designed.

5.2.  Audio Transducer Termination Types

   The Audio Transducer Terminations are used to control audio
   input/output to/from the end user of the device.  Megaco IP Phone MGs
   MUST support at least one Audio Transducer Termination, which MAY be
   chosen from the following well known types (with identifier name):

      *  Handset ("hs")    -- input/output,
      *  Handsfree ("hf")  -- input/output,
      *  Headset ("ht")    -- input/output,
      *  Microphone ("mi") -- input only,
      *  Speaker ("sp")    -- output only.

   TerminationIDs of the Audio Transducer Terminations MUST be of the
   form "at/<name>", where <name> is the 2 character identifier listed
   above, used for both command addressing and command response return.
   If more than one Audio Transducer Termination of a particular type is
   implemented, the TerminationIDs of each MUST be of the form
   "at/<name>/<num>", where <num> is a 2 digit index number in
   hexadecimal format beginning at 01.  Examples of valid TerminationIDs
   include: "at/hs" (handset), "at/mi/02" (microphone 2), "at/*" (all
   audio input/outputs).  ABNF text encoding for this MUST be as
   described in Megaco/H.248 Protocol Appendix B.1 [3].




Blatherwick, et al.          Informational                      [Page 9]
^L
RFC 3054      Megaco IP Phone Media GW Application Profile  January 2001


   Note: If ASN.1 binary encoding is used (OPTIONAL in this
   specification), TerminationIDs and wildcards MUST be encoded as
   described in Megaco/H.248 Protocol Appendix A.1 [3], with alphabetic
   characters of the identifiers given above mapping to octet sub-
   strings in the ASN.1 encoding and the '/' character not used.

   Additional Audio Transducer Termination types MAY also be defined by
   the implementer, however well know identifier names for these are
   outside the scope of this specification.

   All Audio Transducer type Terminations MUST support the following
   Packages, defined in Megaco/H.248 Protocol Annex E [3].

       ____________________________________________________________
      | Package             | Name   | Support in Audio Transducer |
      |                     |        | Terminations                |
      |_____________________|_______ |_____________________________|
      | Basic DTMF Generator| dg     | REQUIRED                    |
      | Call Progress Tones | cg     | REQUIRED                    |
      |   Generator         |        |                             |
      |_____________________|________|_____________________________|

   Additional Packages not listed above MAY also be provided where
   applicable to audio input/output functions.

5.3.  RTP Termination Type

   Megaco IP Phone MGs MUST support at least one RTP Termination in
   order to support audio streams to/from the device, as defined in
   Megaco/H.248 Protocol Annex E.12 [3].

   No special TerminationID naming convention is defined for RTP
   Terminations as part of this specification.

6.  IPPhone Protocol Profile

   The following subsections provide details of the IPPhone Protocol
   Profile, used between Megaco IP Phone MGs and their controlling MGCs.
   This includes implicit application-level agreements between the
   Megaco IP Phone MG and its controlling MGC on organization and
   behavior of the MG, types of Terminations used and the specific
   minimum Package support for each, and specific minimum selections on
   the transport and encoding methods used.

   Use of a this Profile greatly simplifies assumptions necessary by the
   MGC regarding MG organization, thereby reducing complexity and cost
   of both MG and MGC, and improves interoperability for the specific
   Megaco IP Phone application.  Since the Profile is specific to the



Blatherwick, et al.          Informational                     [Page 10]
^L
RFC 3054      Megaco IP Phone Media GW Application Profile  January 2001


   Megaco IP Phone MG, no other applications of Megaco/H.248 Protocol
   are affected.

   It is important to note that the IPPhone Profile specifies minimum
   functionality only, for interoperability purposes.  Additional
   Termination types, Package support, transport or encoding methods, or
   other capabilities MAY be added at the discretion of the implementer
   within the general structure described.

6.1.  Profile Descriptor and Usage

   Profile name: "IPPhone"
   Version: 1

   The Megaco/H.248 Protocol [3] describes startup and service change
   procedures in detail, including use of Profiles.

   In brief, the above Profile name and version are supplied by the
   Megaco IP Phone MG on startup or at service change, in the
   ServiceChangeDescriptor parameter of the ServiceChange command,
   issued to the controlling MGC as part of the registration procedure.
   In response, the MGC may 1) accept control by acknowledging the
   Service Change, 2) pass control to a different MGC by replying with a
   new MGC to try, or 3) refuse control entirely by rejecting the
   Service Change.  If MGC control is refused, the Megaco IP Phone MG
   may attempt registration with other MGCs in its list of MGCs to try.

   Once a controlling MGC accepts the IPPhone Profile, both it and the
   Megaco IP Phone MG become bound by the Profile rules and constraints
   described in subsequent subsections as well as Megaco IP Phone
   Termination/Package organization and behavior rules described in
   previous sections of this document.  Thereafter, any protocol use
   outside these rules is considered an error.

6.2 Termination Organization and Package Support

   Termination organization, required Termination types, and the
   specific Packages supported by each MUST be as described in sections
   4 - 5 of this document.

   Note that additional Termination types and Package support MAY also
   be provided within the general structure described.

6.3.  Transport

   Megaco IP Phone MGs MUST support Application Layer Framing (ALF) over
   UDP transport, as specified in the Megaco/H.248 Protocol Appendix D.1
   [3].



Blatherwick, et al.          Informational                     [Page 11]
^L
RFC 3054      Megaco IP Phone Media GW Application Profile  January 2001


   Note that this does not imply that the Megaco IP Phone MG cannot
   support other transport methods as well.  TCP transport is OPTIONAL,
   but if used MUST conform to Megaco/H.248 Protocol Appendix D.2 [3].

6.4.  Message Encoding

   Megaco IP Phone MGs MUST support ABNF text encoding of the protocol,
   as specified in the Megaco/H.248 Protocol Appendix B [3].

   Note that this does not imply that the Megaco IP Phone MG cannot
   support ASN.1 binary encoding as well.  ASN.1 binary encoding is
   OPTIONAL, but if used MUST conform to Megaco/H.248 Protocol Appendix
   A [3].

7.  Security Considerations

   The Megaco IP Phone Media Gateway Application Profile adds no new
   security issues beyond those endemic to all applications of
   Megaco/H.248 Protocol [3].

8.  References

   [1] TIA/EIA, IS-811, Performance and Interoperability Requirements
       for Voice-over-IP (VoIP) Feature Telephones,
       http://www.tiaonline.org/standards/ip/voip/tia-eia-is-811-
       final.pdf

   [2] Greene, N., Ramalho, M. and B. Rosen, "Media Gateway Control
       Protocol Architecture and Requirements", RFC 2805, April 2000.

   [3] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J.
       Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000.

   [4] ITU-T SG16, H.248 Annex G: User Interface Elements and Actions
       Packages, Brown, M. & P. Blatherwick, November 2000.
       http://www.itu.int/itudoc/itu-t/rec/h/h248anxg.html

   [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.












Blatherwick, et al.          Informational                     [Page 12]
^L
RFC 3054      Megaco IP Phone Media GW Application Profile  January 2001


9.  Authors' Addresses

   Peter Blatherwick (Editor)
   Nortel Networks
   P.O. Box 3511, Stn C
   Ottawa, Ontario,
   Canada K1Y 4H7

   Phone: (613) 763-7539
          (613) 724-4726
   EMail: blather@nortelnetworks.com
          peter.blatherwick@home.com


   Bob Bell
   Cisco Systems Inc.
   576 S. Brentwood Ln.
   Bountiful, UT 84010
   USA

   Phone: (801) 294-3034
   EMail: rtbell@cisco.com


   Phil Holland
   Circa Communications Ltd.
   1000 West 14th Street
   North Vancouver, British Columbia,
   Canada V7P 3P3

   Phone: (604) 924-1742
   EMail: phil.holland@circa.ca



















Blatherwick, et al.          Informational                     [Page 13]
^L
RFC 3054      Megaco IP Phone Media GW Application Profile  January 2001


10.  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 implementation 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.



















Blatherwick, et al.          Informational                     [Page 14]
^L