5. Message Transport Protocol
Messages are transported between voice mail machines using the
Internet Extended Simple Mail Transfer Protocol (ESMTP). All
information required for proper delivery of the message is included
in the ESMTP dialog. This information, including the sender and
recipient addresses, is commonly referred to as the message
"envelope". This information is equivalent to the message control
block in many analog voice messaging protocols.
ESMTP is a general-purpose messaging protocol, designed both to send
mail and to allow terminal console messaging. Simple Mail Transport
Protocol (SMTP) was originally created for the exchange of US-ASCII
7-bit text messages. Binary and 8-bit text messages have
traditionally been transported by encoding the messages into a 7-bit
text-like form. [ESMTP] formalized an extension mechanism for SMTP,
and subsequent RFCs have defined 8-bit text networking, command
streaming, binary networking, and extensions to permit the
declaration of message size for the efficient transmission of large
messages such as multi-minute voice mail.
The following sections list ESMTP commands, keywords, and parameters
that are required and those that are optional for conformance to this
5.1. Base SMTP Protocol
A conforming system MUST implement all mandatory SMTP and ESMTP
commands. Any defined optional command or parameter MAY be
5.2. SMTP Service Extensions
VPIM utilizes a number of SMTP Service Extensions to provide full-
featured voice messaging service. The following extensions are
profiled for use with VPIM:
5.2.1. DSN Extension
The DSN extension defines a mechanism which allows an SMTP client to
specify (a) DSN's should be generated under certain conditions, (b)
whether such DSN's should return the contents of the message, and (c)
additional information, to be returned with a DSN, that allows the
sender to identify both the recipient(s) for which the DSN was
issued, and the transaction in which the original message was sent.
The DSN extension MUST be supported by VPIM conforming
In addition, beyond the requirements of [DRPT], conforming
implementations MUST support NOTIFY parameter on the RCPT command to
allow indication of when the originator requests a notification. The
RET parameter SHOULD be supported to return the original message with
the notification. Parameters ORCPT and ENVID MAY also be supported.
5.2.2. SIZE Extension
The SIZE extension defines a mechanism whereby an SMTP client and
server may interact to give the server an opportunity to decline to
accept a message (perhaps temporarily) based on the client's estimate
of the message size. From: [SIZE]
The SIZE extension MUST be supported by VPIM-compliant
5.2.3. ENHANCEDSTATUSCODES Extension
The ENHANCEDSTATUSCODES extension defines a mechanism whereby an SMTP
server augments its responses with the enhanced mail system status
codes defined in [CODES]. These codes can then be used to provide
more informative explanations of error conditions. From: [STATUS]
The ENHANCEDSTATUSCODES extension SHOULD be supported by VPIM-
5.2.4. PIPELINING Extension
The PIPELINING extension defines a mechanism whereby an SMTP server
can indicate the extent of its ability to accept multiple commands in
a single TCP send operation. Using a single TCP send operation for
multiple commands can improve SMTP performance significantly. From
The PIPELINING extension SHOULD be supported by VPIM-compliant
5.2.5. CHUNKING Extension
The CHUNKING extension defines a mechanism that enables an SMTP
client and server to negotiate the use of the message data transfer
command "BDAT" (in alternative to the DATA command) for efficiently
sending large MIME messages. From: [BINARY]
The CHUNKING extension MAY be supported by VPIM-compliant
5.2.6. BINARYMIME Extension
The BINARYMIME extension defines a mechanism that enables an SMTP
client and server to negotiate the transfer of unencoded binary
message data utilizing the BDAT command. From: [BINARY]
The BINARYMIME extension MAY be supported by VPIM-compliant
implementations. Note that [BINARY] specifies that if BINARYMIME is
to be supported, then CHUNKING has to be supported by definition.
5.3. ESMTP - SMTP Downgrading
The SMTP extensions suggested or required for conformance to VPIM
fall into two categories. The first category includes features that
increase the efficiency of the transport system such as SIZE,
BINARYMIME, and PIPELINING. In the event of a downgrade to a less-
functional transport system, these features can be dropped with no
functional change to the sender or recipient.
The second category of features is transport extensions in support of
new functions. DSN and ENHANCEDSTATUSCODES provide essential
improvements in the handling of delivery status notifications to
bring email to the level of reliability expected of Voice Mail. To
ensure a consistent level of service across an intranet or the global
Internet, it is essential that VPIM-conforming ESMTP support the DSN
extension at all hops between a VPIM originating system and the
recipient system. In the situation where a "downgrade" is
unavoidable a relay hop may be forced (by the next hop) to forward a
VPIM message without the ESMTP request for delivery status
notification. It is RECOMMENDED that the downgrading system should
continue to attempt to deliver the message, but MUST send an
appropriate delivery status notification to the originator, e.g., the
message left an ESMTP host and was sent relayed to a non-DSN-aware
destination, and this may be the last DSN received.
6. Directory Address Resolution
It is the responsibility of a VPIM system to provide the fully-
qualified domain name (FQDN) of the recipient based on the address
entered by the user (if the entered address is not already a FQDN).
This would typically be an issue on systems that offer only a
telephone user interface. The mapping of the dialed target number to
a routable FQDN address, allowing delivery to the destination system,
can be accomplished through implementation-specific means.
To facilitate a local cache, an implementation may wish to populate
local directories with the first and last names, as well as the
senders' spoken name information extracted from received messages.
Addresses or names parsed from the header fields of VPIM messages MAY
be used to populate directories.
7. Management Protocols
The Internet protocols provide a mechanism for the management of
messaging systems, from the management of the physical network
through the management of the message queues. SNMP SHOULD be
supported on a VPIM-conforming machine.
7.1. Network Management
The digital interface to the VM and the TCP/IP protocols MAY be
managed. MIB II MAY be implemented to provide basic statistics and
reporting of TCP and IP protocol performance [MIB II].
8. Conformance Requirements
VPIM is a messaging application that will be supported in several
environments and be supported on differing devices. These
environments include traditional voice processing systems, desktop
voice messaging systems, store-and-forward relays, and protocol
In order to accommodate all environments, this document defines two
areas of conformance: transport and content.
Transport-conformant systems will pass VPIM messages in a store-and-
forward manner with assured delivery notifications and without the
loss of information. It is expected that most store-and-forward
Internet mail-based messaging systems will be VPIM transport-
Content-conformant systems will generate and interpret VPIM messages.
Conformance in the generation of VPIM messages indicates that the
restrictions of this profile are honored. Only contents specified in
this profile or extensions agreed to by bilateral agreement may be
sent. Conformance in the interpretation of VPIM messages indicates
that all VPIM content types and constructs can be received; that all
mandatory VPIM content types can be decoded and presented to the
recipient in an appropriate manner; and that any unrenderable
contents result in the appropriate notification.
A summary of the conformance requirements is contained in Appendix A.
VPIM end systems are expected to be both transport- and content-
conformant. Voice messaging systems and protocol conversion gateways
are considered end systems.
Relay systems are expected to be transport-conformant in order to
receive and send conforming messages. However, they must also create
VPIM-conforming delivery status notifications in the event of
Desktop Email clients that support VPIM are expected to be content-
conformant. Desktop email clients use various protocols and API's
for exchanging messages with the local message store and message
transport system. While these clients may benefit from VPIM
transport capabilities, specific client-server requirements are out-
of-scope for this document.
9. Security Considerations
9.1. General Directive
This document is a profile of existing Internet mail protocols. To
maintain interoperability with Internet mail, any security to be
provided should be part of the Internet security infrastructure,
rather than a new mechanism or some other mechanism outside of the
9.2. Threats and Problems
Both Internet mail and voice messaging have their own set of threats
and countermeasures. As such, this specification does not create any
security issues not already existing in the profiled Internet mail
and voice mail protocols themselves. This section attends only to
the set of additional threats that ensue from integrating the two
9.2.1. Spoofed sender
The actual sender of the voice message might not be the same as that
specified in the "Sender:" or "From:" message header fields or the
MAIL FROM address from the SMTP envelope. In a tightly constrained
environment, sufficient physical and software controls may be able to
ensure prevention of this problem. In addition, the recognition of
the sender's voice may provide confidence of the sender's identity
irrespective of that specified in "Sender:" or "From:". It should be
recognized that SMTP implementations do not provide inherent
authentication of the senders of messages, nor are sites under
obligation to provide such authentication.
9.2.2. Unsolicited voice mail
Assigning an Internet mail address to a voice mailbox opens the
possibility of receiving unsolicited messages (either text or voice
mail). Traditionally, voice mail systems operated in closed
environments and were not susceptible to unknown senders. Voice mail
users have a higher expectation of mailbox privacy and may consider
such messages as a security breach. Many Internet mail systems are
choosing to block all messages from unknown sources in an attempt to
curb this problem.
9.2.3. Message disclosure
Users of voice messaging systems have an expectation of a level of
message privacy that is higher than the level provided by Internet
mail without security enhancements. This expectation of privacy by
users SHOULD be preserved as much as possible.
9.3. Security Techniques
Sufficient physical and software control may be acceptable in
constrained environments. Further, the profile specified in this
document does not in any way preclude the use of any Internet object
or channel security protocol to encrypt, authenticate, or non-
repudiate the messages.
10. Normative References
[8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
RFC 1652, July 1994.
[ADPCM] 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.
[AMIS-A] Audio Messaging Interchange Specifications (AMIS) - Analog
Protocol Version 1, Issue 2, February 1992.
[AMIS-D] Audio Messaging Interchange Specifications (AMIS) - Digital
Protocol Version 1, Issue 3, August 1993.
[BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of
Large and Binary MIME Messages", RFC 3030, December 2000.
[CODES] Vaudreuil, G. "Enhanced Mail System Status Codes", RFC
1893, January 1996.
[MIMEDIR] Dawson, F., Howes, T. and M. Smith, "A MIME Content-Type
for Directory Information", RFC 2425, September 1998.
[DISP] Troost, R. and S. Dorner, "Communicating Presentation
Information in Internet Messages: The Content-Disposition
Header", RFC 2183, August 1997.
[DNS1] Mockapetris, P., "Domain names - implementation and
specification", RFC 1035, November 1987.
[DNS2] Mockapetris, P., "Domain names - concepts and facilities",
RFC 1034, November 1987.
[DRPT] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC
3461, January 2003.
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, January 2003.
[DUR] Parsons, G. and G. Vaudreuil, "Content Duration MIME Header
Definition", RFC 3803, June 2004.
[E164] CCITT Recommendation E.164 (1991), Telephone Network and
ISDN Operation, Numbering, Routing and Mobile Service -
Numbering Plan for the ISDN Era.
[ESMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
[G726] CCITT Recommendation G.726 (1990), General Aspects of
Digital Transmission Systems, Terminal Equipment - 40, 32,
24,16 kbit/s Adaptive Differential Pulse Code Modulation
[HOSTREQ] Braden, R., "Requirements for Internet Hosts -- Application
and Support", STD 3, RFC 1123, October 1989.
[LANG] Alvestrand, H., "Tags for the Identification of Languages",
BCP 47, RFC 3066, January 2001.
[MDN] Hansen, T., Ed. and G. Vaudreuil, Ed., "Message Disposition
Notification", RFC 3798, May 2004.
[MIB II] Rose, M., "Management Information Base for Network
Management of TCP/IP-based internets: MIB-II", RFC 1213,
[MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[MIME2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types ", RFC 2046,
[MIME3] Moore, K., "Multipurpose Internet Mail Extensions (MIME)
Part Three: Message Header Extensions for Non-ASCII Text ",
RFC 2047, November 1996.
[MIME4] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", RFC 2048, November 1996.
[MIME5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples ", RFC 2049, November 1996.
[PIPE] Freed, N.and A. Cargille, "SMTP Service Extension for
Command Pipelining" STD 60, RFC 2920, September 2000.
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC
3462, January 2003.
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[SIZE] Klensin, J., Freed, N. and K. Moore, "SMTP Service
Extensions for Message Size Declaration" STD 10, RFC 1870,
[STATUS] Freed, N., "SMTP Service Extension for Returning Enhanced
Error Codes", RFC 2034, October 1996.
[TIFF-F] Parsons, G. and J. Rafferty, "Tag Image File Format:
Application F", RFC 2306, March 1998.
[TIFFREG] Parsons, G., Rafferty, J. and S. Zilles, "Tag Image File
Format: image/tiff - MIME sub-type registration", RFC 2302,
[V-MSG] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME
Sub-type Registration", RFC 2423, September 1998.
[VCARD] Dawson, F. and T. Howes, "vCard MIME Directory Profile" RFC
2426, September 1998.
[VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911,
[VPIM2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
Mail, Version 2", RFC 2421, September 1998.
[X.400] CCITT/ISO, "CCITT Recommendations X.400/ ISO/IEC 10021-1,
Message Handling: System and Service Overview", December
The authors would like to offer a special thanks to the Electronic
Messaging Association (EMA), especially the members of the Voice
Messaging Committee, and the IETF VPIM Work Group, for their support
of the VPIM specification and the efforts they have made to ensure
12. Appendix A - VPIM Requirements Summary
The following table summarizes the profile of VPIM version 2 detailed
in this document. Since in many cases it is not possible to simplify
the qualifications for supporting each feature this appendix is
informative. The reader is recommended to read the complete
explanation of each feature in the referenced section. The text in
the previous sections shall be deemed authoritative if any item in
this table is ambiguous.
The conformance table is separated into various columns:
Feature - name of protocol feature (note that the indenting
indicates a hierarchy of conformance, i.e., the
conformance of a lower feature is only relevant if there
is conformance to the higher feature)
Section - reference section in main text of this document
Area - conformance area to which each feature applies:
C - content
T - transport
Status - whether the feature is mandatory, optional, or prohibited.
The key words used in this table are to be interpreted as described
in [REQ], though the following list gives a quick overview of the
different degrees of feature conformance:
Must - mandatory
Should - required in the absence of a compelling
need to omit.
May - optional
Should not - prohibited in the absence of a compelling
Must not - prohibited
Footnote - special comment about conformance for a particular feature
6. Other un-profiled contents MUST only be sent by bilateral
7. If fax is supported.
8. If the fax content cannot be presented it MAY be dropped.
9. Handling of a vCard in text/directory is no longer defined.
13. Appendix B - Example Voice Messages
The following message is a full-featured message addressed to two
recipients. The message includes the sender's spoken name, spoken
subject and a short speech segment. The message is marked as
important and private.
From: "Parsons, Glenn" <12145551234@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Content-Disposition: inline; voice=Originator-Spoken-Name
(This is a sample of the base-64 Spoken Name data)
Content-Disposition: inline; voice=Spoken-Subject
(This is a sample of the base-64 Spoken Subject data)
Content-Description: Brand X Voice Message
Content-Disposition: inline; voice=Voice-Message; filename=msg1.726
(This is a sample of the base64 message data) zb8tFdLTQt1PXj
--MessageBoundary- - - -
The following message is a forwarded single segment voice. Both the
forwarded message and the forwarding message contain the senders spoken
From: "Vaudreuil, Greg" <+19725552345@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
The following example is for a DSN sent to the sender of a message by
a VPIM gateway at VM1.company.com for a mailbox which does not exist.
Date: Thu, 7 Jul 1994 17:16:05 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@vm.company.com>
Subject: Returned voice message
Content-Type: multipart/report; report-type=delivery-status;
Content-Description: Spoken Delivery Status Notification
Content-Disposition: inline; voice= Voice-Message-Notification
(This is a voiced description of the error in base64)
Reporting-MTA: dns; vm1.company.com
Original-Recipient: rfc822; 2145551234@VM1.mycompany.com
Final-Recipient: rfc822; 2145551234@VM1.mycompany.com
Status: 5.1.1 (User does not exist)
Diagnostic-Code: smtp; 550 Mailbox not found
Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
[original VPIM message goes here]
The following example is for an MDN sent to the original sender for a
message that has been played. This delivered VPIM message was
received by a corporate gateway and relayed to a unified mailbox.
Date: Thu, 7 Jul 1994 17:16:05 -0400
From: "Greg Vaudreuil" <firstname.lastname@example.org>
Subject: Voice message played
Content-Description: Spoken Disposition Notification
Content-Disposition: inline; voice= Voice-Message-Notification
(Voiced description of the disposition action in base64)
Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)
Disposition: manual-action/MDN-sent-automatically; displayed
[original VPIM message goes here]
14. Appendix C - Example Error Voice Processing Error Codes
The following common voice processing errors and their corresponding
status codes are given as examples. The text after the error codes
is intended only for reference to describe the error code.
Implementations should provide implementation-specific informative
comments after the error code rather than the text below.
Error condition RFC 1893 Error codes
Analog delivery failed 4.4.1 Persistent connection error
because remote system is busy - busy
Analog delivery failed 4.4.1 Persistent protocol error
because remote system is - no answer from host
Remote system did not answer 5.5.5 Permanent protocol error
AMIS-Analog handshake ("D" in - wrong version
response to "C" at connect
Mailbox does not exist 5.1.1 Permanent mailbox error
- does not exist
Mailbox full or over quota 4.2.2 Persistent mailbox error
Disk full 4.3.1 Persistent system error
Command out of sequence 5.5.1 Permanent protocol error
- invalid command
Frame Error 5.5.2 Permanent protocol error
- syntax error
Mailbox does not support FAX 5.6.1 Permanent media error
- not supported
Mailbox does not support TEXT 5.6.1 Permanent media error
- not supported
Sender is not authorized 5.7.1 Permanent security error
- sender not authorized
Message marked private, but 5.3.3 Permanent system error
system is not private capable - not feature capable
15. Appendix D - Example Voice Processing Disposition Types
The following common voice processing disposition conditions and
their corresponding MDN Disposition (which contains the disposition
mode, type and modifier, if applicable) are given as examples.
Implementers should refer to [MDN] for a full description of the
format of message disposition notifications.
Notification event MDN Disposition mode, type & modifier
Message played by recipient, manual-action/MDN-sent-automatically;
receipt automatically returned displayed
Message deleted from mailbox manual-action/MDN-sent-automatically;
by user without listening deleted
Message cleared when mailbox manual-action/MDN-sent-automatically;
deleted by admin deleted/mailbox-terminated
Message automatically deleted automatic-action/
when older than administrator MDN-sent-automatically; deleted/
set threshold expired
Message processed, however manual-action/MDN-sent-automatically;
audio encoding unknown - processed/error
unable to play to user Error: unknown audio encoding
16. Appendix E - IANA Registrations
There are no changes to the registration per [DISP] of the voice
content disposition parameter defined in the earlier VPIM V2
document, RFC 2421. There are no changes to the registration per
[MIME4] of the Multipart/voice-message content type defines in the
earlier VPIM v2 document, RFC 2423.
Both are presented here for information.
16.1. Voice Content-Disposition Parameter Definition
Subject: Registration of new Content-Disposition parameter
Content-Disposition parameter name: voice
Allowable values for this parameter:
Voice-Message - the primary voice message,
Voice-Message-Notification - a spoken delivery notification
or spoken disposition notification,
Originator-Spoken-Name - the spoken name of the originator,
Recipient-Spoken-Name - the spoken name of the recipient if
available to the originator and present if there is ONLY one
Spoken-Subject- the spoken subject of the message, typically
spoken by the originator
In order to distinguish between the various types of audio contents
in a VPIM voice message a new disposition parameter "voice" is
defined with the preceding values to be used as appropriate. Note
that there SHOULD only be one instance of each of these types of
audio contents per message level. Additional instances of a given
type (i.e., parameter value) may occur within an attached forwarded
16.2. Multipart/Voice-Message MIME Media Type Definition
Subject: Registration of MIME media type
MIME media type name: multipart
MIME subtype name: voice-message
Required parameters: boundary, version
The use of boundary is defined in [MIME2]
The version parameter that contains the value "2.0" if
enclosed content conforms to [VPIM2R2]. The absence of this
parameter indicates conformance to the previous version
defined in RFC 1911 [VPIM1].
Optional parameters: none
Encoding considerations: 7bit, 8bit or Binary
This definition identifies the content as being a voice
message. In some environments (though likely not the
majority), the loss of the anonymity of the content may be a
Systems developed to conform with [VPIM1] may not conform to
this registration. Specifically, the required version will
likely be absent, in this case the recipient system should
still be able to accept the message and will be able to
handle the content. The VPIM v1 positional identification,
however, would likely be lost.
Applications that use this media type:
Primarily voice messaging
Magic number(s): none
File extension(s): .VPM
Macintosh File Type Code(s): VPIM
Person & email address to contact for further information:
Glenn W. Parsons
Gregory M. Vaudreuil
Intended usage: COMMON
Glenn W. Parsons & Gregory M. Vaudreuil
17. Appendix F - Change History: RFC 2421 (VPIM V2) to this Document
The updated profile in this document is based on the implementation
and operational deployment experience of several vendors. The
changes are categorized as general, content, transport and
conformance. They are summarized below:
- Various and substantial editorial updates to improve
- Separated send rules from receive rules to aid clarity.
- Clarified the behavior upon reception of unrecognized content
types expected with the interworking between voice and unified
messaging systems. (E.g., Unsupported non-audio contents should
be discarded to deliver the audio message.)
- Reworked the sensitivity requirements to align them with X.400.
Eliminated dependencies upon the MIXER documents.
- Reorganized the content-type descriptions for clarity
- Changed handling of received lines by a gateway to SHOULD NOT
delete in a gateway. In gateways to systems such as AMIS, it is
not possible to preserve this information. It is intended that
such systems be able to claim conformance.
- Eliminated the vCard as a supported VPIM V2 content type.
- Merged in text from RFC 2423 (Multipart/voice-message)
- Aligned the table of Appendix A to the requirements in the text.
19. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
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
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-
Funding for the RFC Editor function is currently provided by the