doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc4237.txt b/doc/rfc/rfc4237.txt
new file mode 100644
index 0000000..eb1c221
--- /dev/null
+++ b/doc/rfc/rfc4237.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                       G. Vaudreuil
+Request for Comments: 4237                           Lucent Technologies
+Category: Standards Track                                   October 2005
+
+
+                   Voice Messaging Directory Service
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document provides details of the Voice Profile for Internet Mail
+   (VPIM) directory service.  The service provides the email address of
+   the recipient that is given a telephone number.  It optionally
+   provides the spoken name of the recipient and the media capabilities
+   of the recipient.
+
+   The VPIM directory Schema provides essential additional attributes to
+   recreate the voice mail user experience using standardized
+   directories.  This user experience provides, at the time of
+   addressing, basic assurances that the message will be delivered as
+   intended.  This document combines two earlier documents, one from
+   Anne Brown and one from Greg Vaudreuil, that define a voice messaging
+   schema into a single working group submission.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 1]
+
+RFC 4237           Voice Messaging Directory Service        October 2005
+
+
+Table of Contents
+
+   1. Scope ...........................................................2
+      1.1. Design Goals ...............................................2
+      1.2. Performance Constraints ....................................2
+      1.3. Scaling Constraints ........................................3
+      1.4. Reliability Constraints ....................................3
+   2. The VPIMUser Directory Schema ...................................3
+      2.1. vPIMTelephoneNumber ........................................4
+      2.2. vPIMRfc822Mailbox ..........................................4
+      2.3. vPIMSpokenName .............................................4
+      2.4. vPIMTextName ...............................................5
+      2.5. vPIMSupportedAudioMediaTypes ...............................5
+      2.6. vPIMSupportedMessageContext ................................5
+      2.7. vPIMExtendedAbsenceStatus ..................................6
+      2.8. vPIMSupportedUABehaviors ...................................6
+      2.9. vPIMMaxMessageSize .........................................7
+      2.10. vPIMSubMailboxes ..........................................8
+   3. Security Considerations .........................................8
+   4. IANA Considerations .............................................9
+      4.1. Object Identifiers .........................................9
+      4.2. Object Identifier Descriptors ..............................9
+   5. References .....................................................10
+      5.1. Normative References ......................................10
+      5.2. Informative References ....................................10
+
+1.  Scope
+
+1.1.  Design Goals
+
+   The VPIM directory Schema (VPIMDIR) is accessed from outside the
+   enterprise or service provider domain using the recipient's telephone
+   number.
+
+1.2.  Performance Constraints
+
+   Once the identity of the VPIM directory server is known, the email
+   address, capabilities, and spoken name confirmation information can
+   be retrieved.  This query is expected to use LDAP [LDAP], a
+   connection-oriented protocol.  The protocol transaction includes
+   multiple packet round-trips to execute the query and retrieval and is
+   considered to be the highest latency element of the messaging
+   service.  Further, retrieval of the confirmation information may
+   require the return of a spoken name segment of up to 20kbytes (5
+   seconds at 4kbytes/second).  Over a sufficiently engineered Internet
+   connection, a 1250 ms response time is believed to be achievable over
+   the Internet at large.
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 2]
+
+RFC 4237           Voice Messaging Directory Service        October 2005
+
+
+1.3.  Scaling Constraints
+
+   A service provider's namespace is expected to include entries for
+   tens of millions of subscribers in a flat namespace based on the VPIM
+   inter-domain address form: telephone_number@domain_name.  A large
+   corporation may have a hundred-thousand entries, while a large
+   service provider may have tens of millions of entries in a single
+   domain.  It is expected that there will be a single public address
+   validation service for a given service provider's network.  It is
+   believed that existing directory technology, including horizontal
+   scalability through replication, will provide sufficient transaction
+   throughput within the required latency requirements to address this
+   need.  The only fundamental, new requirement this application imposes
+   on directory servers, beyond similar existing services, is the
+   ability to return the recipient's spoken name.  Preliminary
+   investigation suggests that storage and retrieval of a spoken name
+   will not add appreciable latency; however, it will add to the need
+   for storage capacity.
+
+1.4.  Reliability Constraints
+
+   DNS provides well-documented redundancy and load-balancing
+   capabilities for the VPIMDIR.  However, the latency requirements to
+   the end-user may not permit client-side fail-over to a secondary
+   server and may require the directory server to be implemented as a
+   high-availability service.
+
+2.  The VPIMUser Directory Schema
+
+      (IANA-ASSIGNED-OID.1 NAME 'vPIMUser'
+              SUP 'top'
+              AUXILIARY
+              MUST ( vPIMRfc822Mailbox $
+                     vPIMTelephoneNumber )
+              MAY  ( vPIMSpokenName $
+                     vPIMSupportedUABehaviors $
+                     vPIMSupportedAudioMediaTypes $
+                     vPIMSupportedMessageContext $
+                     vPIMTextName $
+                     vPIMExtendedAbsenceStatus $
+                     vPIMMaxMessageSize $
+                     vPIMSubMailboxes ) )
+
+   When present, the vPIMUser object contains information useful for
+   verifying that the dialed telephone number corresponds to the
+   intended recipient.  This object also provides capability information
+   and mailbox status information useful for guiding composition by the
+   sender and for setting delivery expectations at sending time.
+
+
+
+Vaudreuil                   Standards Track                     [Page 3]
+
+RFC 4237           Voice Messaging Directory Service        October 2005
+
+
+2.1.  vPIMTelephoneNumber
+
+   The attribute vPIMTelephoneNumber is the full E.164 form of the
+   telephone number [E164], including any sub-addressing portion.  The
+   normal search will be for this attribute.
+
+      (IANA-ASSIGNED-OID.2.1 NAME 'vPIMTelephoneNumber'
+                          EQUALITY caseIgnoreMatch
+                          SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{20} )
+
+   Example: A North American telephone number with the sub address of 12
+   would be represented as "+12145551212+12".
+
+   Note that vPIMTelephoneNumber is, by default, a multi-valued
+   attribute.  But if an entry has multiple values for this attribute,
+   those values MUST be distinct from each other in the telephone number
+   portion.  It is expected that each submailbox of a single telephone
+   number will have its own vPIMUser entry.
+
+   The vPIMTelephoneNumber differs from telephoneNumber in [LDAP] in its
+   support for sub-addressing information and its use as a voice
+   messaging address.  In most cases, these values will be the same.
+
+   The telephone number is stored with no parenthesis, spaces, dots, or
+   hyphens.  The leading '+' and the '+' delineating the submailbox are
+   required markup.
+
+2.2.  vPIMRfc822Mailbox
+
+   The attribute vPIMRfc822Mailbox stores the inter-domain SMTP address
+   of the voice mailbox associated with a given telephone number.  It is
+   defined as a distinct attribute to distinguish it from the
+   rfc822Mailbox attribute that may be used for other purposes.
+   Although it would be preferable to define vPIMRfc822Mailbox as a
+   subtype of rfc822Mailbox, it is defined here as an entirely new
+   attribute because some directory implementations do not support sub-
+   typing.
+
+      (IANA-ASSIGNED-OID.2.2 NAME 'vPIMRfc822Mailbox'
+                        EQUALITY caseIgnoreIA5Match
+                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
+
+2.3.  vPIMSpokenName
+
+   The vPIMSpokenName attribute is an octet string and MUST be encoded
+   in 32 kbit/s ADPCM exactly, as defined by [32KADPCM].  vPIMSpokenName
+   shall contain the spoken name of the user in the voice of the user.
+   The length of the spoken name segment MUST NOT exceed five seconds.
+
+
+
+Vaudreuil                   Standards Track                     [Page 4]
+
+RFC 4237           Voice Messaging Directory Service        October 2005
+
+
+   Private or additional encoding types are outside the scope of this
+   version.
+
+      (IANA-ASSIGNED-OID.2.3 NAME 'vPIMSpokenName'
+                        EQUALITY octetStringMatch
+                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{20000}
+                        SINGLE-VALUE )
+
+2.4.  vPIMTextName
+
+   The text name is designed to be consistent with the unstructured
+   text name databases used for calling name delivery service of
+   caller ID.
+
+      (IANA-ASSIGNED-OID.2.4 NAME 'vPIMTextName'
+                        EQUALITY caseIgnoreMatch
+                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20}
+                        SINGLE-VALUE )
+
+2.5.  vPIMSupportedAudioMediaTypes
+
+   The vPIMSupportedAudioMediaTypes attribute indicates the type(s) of
+   audio encodings that can be received at the address specified in
+   vPIMRfc822Mailbox.
+
+      (IANA-ASSIGNED-OID.2.5 NAME 'vPIMSupportedAudioMediaTypes'
+                        EQUALITY caseIgnoreIA5Match
+                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+   This is a multi-value attribute.  The allowable values for this
+   attribute are the MIME audio subtypes registered with IANA.  Non-
+   standard and private encoding types must be indicated by prepending
+   the new type name with either "X-" or "x-".
+
+   Because ADPCM is a required format, the audio32kadpcm value must be
+   listed if this attribute is present.
+
+2.6.  vPIMSupportedMessageContext
+
+   The message context provides guidance to the sender about the message
+   contexts the recipient is likely to accept.  Message context provides
+   less precise information about a given recipient's capabilities than
+   a list of media types.  However, given the growing role of media-
+   conversion gateways, the context indicator provides more useful
+   guidance to a sender in a "unified messaging" environment.
+
+
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 5]
+
+RFC 4237           Voice Messaging Directory Service        October 2005
+
+
+      (IANA-ASSIGNED-OID.2.6 NAME 'vPIMSupportedMessageContext'
+                        EQUALITY caseIgnoreIA5Match
+                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+   This is a multi-value attribute.  The set of valid message context
+   values is defined in [CONTEXT].
+
+2.7.  vPIMExtendedAbsenceStatus
+
+   It is common to have an attribute that indicates to the subscriber
+   whether the recipient is accepting messages during his absence.  This
+   feature -- called "extended absence" -- provides an advisory message
+   at sending time.  It is similar in concept to "vacation notices"
+   common for textual email, but has its own cultural and operational
+   nuances.
+
+      (IANA-ASSIGNED-OID.2.7 NAME 'vPIMExtendedAbsenceStatus'
+                        EQUALITY caseIgnoreIA5Match
+                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+                        SINGLE-VALUE )
+
+   The three values defined are:
+
+            "Off", "On", "MsgBlocked"
+
+   "Off" indicates that the recipient either does not support extended
+   absence or has not set such an indicator.  "Off" is the default
+   condition if this attribute is not returned.
+
+   "On" indicates that the recipient has set an extended absence
+   indicator, but the mailbox is still accepting messages for review at
+   an unspecified future time.
+
+   "MsgBlocked" indicates that the recipient has set an extended absence
+   indicator and the mailbox is currently configured to reject incoming
+   messages.  Messages SHOULD NOT be sent to the recipient if this value
+   is returned in the vPIMExtendedAbsenceStatus attribute.
+
+2.8.  vPIMSupportedUABehaviors
+
+   Internet mail does not provide facilities for the sender to know
+   whether the recipient supports a number of optional features that can
+   be requested or indicated in the RFC822 headers.  This attribute
+   provides a list of the attributes, considered optional by VPIM and
+   other vendor-specific attributes, that may be supported by the
+   recipient.  If this attribute is not supported, only those attributes
+
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 6]
+
+RFC 4237           Voice Messaging Directory Service        October 2005
+
+
+   listed as mandatory in VPIM are assumed to be supported.  Undisclosed
+   behaviors may be indicated in the RFC822 message; however, there is
+   no assurance by the receiving system of their support.
+
+      (IANA-ASSIGNED-OID.2.8 NAME 'vPIMSupportedUABehaviors'
+                        EQUALITY caseIgnoreIA5Match
+                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+   The following behaviors are defined:
+
+            MessageDispositionNotification
+            MessageSensitivity
+            MessageImportance
+
+   The presence of the MessageDispositionNotification value indicates
+   that the recipient will send an MDN in response to an MDN request.
+
+   MessageSensitivity indicates that the recipient fully supports the
+   sensitivity indication as defined in VPIM [VPIMV2].
+
+   MessageImportance indicates that the recipient fully supports the
+   importance indication as defined in VPIM [VPIMV2].
+
+   These may be further extended without standardization to include
+   proprietary user interface functional extensions.  These proprietary
+   extension values must be prefixed with an "X-" or "x-".
+
+2.9.  vPIMMaxMessageSize
+
+   At the time of composition, the message can be checked for acceptable
+   length using the maximum message size attribute.  Maximum message
+   size is an attribute usually configured by policy of the receiving
+   system, typically in units of minutes.  While ESMTP provides a
+   mechanism to determine if a message is too long in bytes, it is an
+   unreliable guide for the composer when multiple encodings, multiple
+   media, or variable bit-rate encodings are supported.
+
+      (IANA-ASSIGNED-OID.2.9 NAME 'vPIMMaxMessageSize'
+                        EQUALITY integerMatch
+                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+                        SINGLE-VALUE )
+
+   The attribute indicates the maximum message length in seconds that
+   the receiving mailbox may receive.
+
+
+
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 7]
+
+RFC 4237           Voice Messaging Directory Service        October 2005
+
+
+2.10.  vPIMSubMailboxes
+
+   This attribute indicates the presence of sub-mailboxes for the
+   queried telephone number.  This information may be used to provide a
+   post-dial sub-addressing menu to the sender.
+
+      (IANA-ASSIGNED-OID.2.10 NAME 'vPIMSubMailboxes'
+                        EQUALITY numericStringMatch
+                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{4} )
+
+   The allowable values include a list of sub-mailbox numbers with a
+   numeric range of 1-9999.  The user interface may use this information
+   to prompt the sender to select a sub-mailbox.  Spoken names
+   associated with each sub-mailbox may be individually retrieved by
+   subsequent queries to the recipient's VPIMDIR service.
+
+3.  Security Considerations
+
+   The following are known security issues.
+
+   1) Service provider customer information is very sensitive,
+      especially in this time of local phone competition.  Service
+      providers require maximum flexibility to protect this data.
+      Because of the dense nature of telephone number assignments, this
+      data is subject to "go fish" queries via repeated LDAP queries to
+      determine a complete list of current or active messaging
+      subscribers.  To reduce the value of this retrieved data, service
+      providers may limit disclosure of data that is useful for
+      telemarketing, such as the textual name, and may disclose only
+      information useful to the sender, such as the recipient's spoken
+      name, a data element that is much harder to auto-process.
+
+   2) In many countries, there are privacy laws or regulations that
+      prohibit disclosure of certain kinds of descriptive information
+      (e.g., text names).  Hence, server implementors are encouraged to
+      support DIT structural rules and name forms [LDAPMODELS] as these
+      provide a mechanism for administrators to select appropriate
+      naming attributes for entries.  Administrators are encouraged to
+      use these mechanisms, access controls, and other administrative
+      controls, which may be available to restrict use of attributes
+      containing sensitive information when naming entries.
+
+   3) The LDAP directory service needs to be secured properly for this
+      intended use.  [LDAPAUTH] describes a number of considerations
+      that apply in this use.  In particular, this service provides
+      unauthenticated, public access to directory data, and as such, it
+      is vulnerable to attacks that redirect the query to a rogue server
+      and offer malicious data.
+
+
+
+Vaudreuil                   Standards Track                     [Page 8]
+
+RFC 4237           Voice Messaging Directory Service        October 2005
+
+
+4.  IANA Considerations
+
+   Reference RFC 3383 "Internet Assigned Numbers Authority (IANA)
+   Considerations for the Lightweight Directory Access Protocol (LDAP)"
+   [LDAPREG].
+
+4.1.  Object Identifiers
+
+   IANA has registered an LDAP Object Identifier for use in this
+   technical specification, according to the following template:
+
+   Subject: Request for LDAP OID Registration
+
+   Person & email address to contact for further information:
+
+      Greg Vaudreuil (gregv@ieee.org)
+
+   Specification: RFC 4237
+
+   Author/Change Controller: IESG
+
+   Comments:
+
+   The assigned OID will be used as a base for identifying a number of
+   schema elements defined in this document.
+
+4.2.  Object Identifier Descriptors
+
+   IANA has registered the LDAP Descriptors used in this technical
+   specification, as detailed in the following template:
+
+   Subject: Request for LDAP Descriptor Registration Update
+
+   Descriptor (vPIM): see comment
+
+   Object Identifier: see comment
+
+   Person & email address to contact for further information:
+
+      GregV@ieee.org
+
+   Usage: see comment
+
+   Specification: RFC 4237
+
+   Author/Change Controller: IESG
+
+   Comments:
+
+
+
+Vaudreuil                   Standards Track                     [Page 9]
+
+RFC 4237           Voice Messaging Directory Service        October 2005
+
+
+   The following descriptors have been added:
+
+   NAME                            Type    OID
+   --------------                  ----    ------------
+   vPIMUser                         O      IANA-ASSIGNED-OID.1.1
+   vPIMRfc822Mailbox                A      IANA-ASSIGNED-OID.2.1
+   vPIMTelephoneNumber              A      IANA-ASSIGNED-OID.2.2
+   vPIMSpokenName                   A      IANA-ASSIGNED-OID.2.3
+   vPIMSupportedUABehaviors         A      IANA-ASSIGNED-OID.2.4
+   vPIMSupportedAudioMediaTypes     A      IANA-ASSIGNED-OID.2.5
+   vPIMSupportedMessageContext      A      IANA-ASSIGNED-OID.2.6
+   vPIMTextName                     A      IANA-ASSIGNED-OID.2.7
+   vPIMExtendedAbsenceStatus        A      IANA-ASSIGNED-OID.2.8
+   vPIMMaxMessageSize               A      IANA-ASSIGNED-OID.2.9
+   vPIMSubMailboxes                 A      IANA-ASSIGNED-OID.2.10
+
+   Where Type A is Attribute and Type O is ObjectClass
+
+5.  References
+
+5.1.  Normative References
+
+   [LDAP]       Hodges, J. and R. Morgan, "Lightweight Directory Access
+                Protocol (v3): Technical Specification", RFC 3377,
+                September 2002.
+
+   [32KADPCM]   Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32
+                kbit/s Adaptive Differential Pulse Code Modulation
+                (ADPCM) MIME Sub-type Registration", RFC 3802, June
+                2004.
+
+   [CONTEXT]    Burger, E., Candell, E., Eliot, C., and G. Klyne,
+                "Message Context for Internet Mail", RFC 3458, January
+                2003.
+
+   [E164]       CCITT Recommendation E.164 (1991), Telephone Network and
+                ISDN Operation, Numbering, Routing and Mobile Service -
+                Numbering Plan for the ISDN Era.
+
+5.2.  Informative References
+
+   [VPIMV2]     Vaudreuil, G. and G. Parsons, "Voice Profile for
+                Internet Mail - version 2 (VPIMv2)", RFC 3801, June
+                2004.
+
+
+
+
+
+
+
+Vaudreuil                   Standards Track                    [Page 10]
+
+RFC 4237           Voice Messaging Directory Service        October 2005
+
+
+   [LDAPREG]    Zeilenga, K., "Internet Assigned Numbers Authority
+                (IANA) Considerations for the Lightweight Directory
+                Access Protocol (LDAP)", BCP 64, RFC 3383, September
+                2002.
+
+   [LDAPAUTH]   Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
+                "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+   [LDAPMODELS] Zeilenga, K., "LDAP: Directory Information Models" Work
+                in Progress, February 2005.
+
+Acknowledgements
+
+   This directory schema builds upon the earlier work of Carl Malamud
+   and Marshall Rose in their TPC.INT remote printing experiment and the
+   work lead by Anne Brown as part of the EMA voice messaging
+   committee's directory effort.  Anne Brown has provided important
+   leadership and was a co-author of the original version of this
+   document.
+
+   Bernhard Elliot, working with the TMIA, has provided most of the
+   organizational impetus to get this project moving, which was a
+   substantial task given the sometimes slow and bureaucratic nature of
+   the voice mail industry and regulatory environment.
+
+   Thanks to Dave Dudley and the Messaging Alliance (TMA) for their
+   early work in pioneering a shared directory service for voice
+   messaging and their continuing efforts to apply that work to this
+   effort.
+
+   Greg White and Jeff Bouis, both of Lucent Technologies, provided
+   invaluable assistance in reviewing and sanity checking.  Countless
+   errors and inconsistencies were corrected with their diligent review.
+
+   As chairman of the VPIM working group, Glenn Parsons has provided
+   essential support over the many years this document has been in
+   development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil                   Standards Track                    [Page 11]
+
+RFC 4237           Voice Messaging Directory Service        October 2005
+
+
+Author's Address
+
+   Please send comments on this document to the VPIM working group
+   mailing list <vpim@ietf.org>.
+
+   Gregory M. Vaudreuil
+   Lucent Technologies
+   9489 Bartgis Ct
+   Frederick, MD 21702
+
+   EMail: GregV@ieee.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil                   Standards Track                    [Page 12]
+
+RFC 4237           Voice Messaging Directory Service        October 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Vaudreuil                   Standards Track                    [Page 13]
+