RFC 3261
SIP: Session Initiation Protocol
Pages: 269
Proposed Standard
→ Errata corrections have been made for all following "Verified" errata except '4300':
Updated by: 3265 3853 4320 4916 5393 5621 5626 5630 5922 5954 6026 6141 6665 6878 7462 7463 8217 8591 8760 8898 8996
Proposed Standard
→ Errata corrections have been made for all following "Verified" errata except '4300':
→ see our illustrations of the:
main example
structure of the protocol
dialog
→ see our: ABNF for SIP (RFC 3261 and other RFCs)
Obsoletes:
2543
→ see our: ABNF for SIP (RFC 3261 and other RFCs)
Updated by: 3265 3853 4320 4916 5393 5621 5626 5630 5922 5954 6026 6141 6665 6878 7462 7463 8217 8591 8760 8898 8996
Part 13 of 13 – Pages 252 to 269
27 IANA Considerations
All method names, header field names, status codes, and option tags used in SIP applications are registered with IANA through instructions in an IANA Considerations section in an RFC. The specification instructs the IANA to create four new sub- registries under http://www.iana.org/assignments/sip-parameters: Option Tags, Warning Codes (warn-codes), Methods and Response Codes, added to the sub-registry of Header Fields that is already present there.27.1 Option Tags
This specification establishes the Option Tags sub-registry under http://www.iana.org/assignments/sip-parameters. Option tags are used in header fields such as Require, Supported, Proxy-Require, and Unsupported in support of SIP compatibility mechanisms for extensions (Section 19.2). The option tag itself is a string that is associated with a particular SIP option (that is, an extension). It identifies the option to SIP endpoints. Option tags are registered by the IANA when they are published in standards track RFCs. The IANA Considerations section of the RFC must include the following information, which appears in the IANA registry along with the RFC number of the publication. o Name of the option tag. The name MAY be of any length, but SHOULD be no more than twenty characters long. The name MUST consist of alphanum (Section 25) characters only. o Descriptive text that describes the extension.27.2 Warn-Codes
This specification establishes the Warn-codes sub-registry under http://www.iana.org/assignments/sip-parameters and initiates its population with the warn-codes listed in Section 20.43. Additional warn-codes are registered by RFC publication.
The descriptive text for the table of warn-codes is: Warning codes provide information supplemental to the status code in SIP response messages when the failure of the transaction results from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. The "warn-code" consists of three digits. A first digit of "3" indicates warnings specific to SIP. Until a future specification describes uses of warn-codes other than 3xx, only 3xx warn-codes may be registered. Warnings 300 through 329 are reserved for indicating problems with keywords in the session description, 330 through 339 are warnings related to basic network services requested in the session description, 370 through 379 are warnings related to quantitative QoS parameters requested in the session description, and 390 through 399 are miscellaneous warnings that do not fall into one of the above categories.27.3 Header Field Names
This obsoletes the IANA instructions about the header sub-registry under http://www.iana.org/assignments/sip-parameters. The following information needs to be provided in an RFC publication in order to register a new header field name: o The RFC number in which the header is registered; o the name of the header field being registered; o a compact form version for that header field, if one is defined; Some common and widely used header fields MAY be assigned one-letter compact forms (Section 7.3.3). Compact forms can only be assigned after SIP working group review, followed by RFC publication.27.4 Method and Response Codes
This specification establishes the Method and Response-Code sub- registries under http://www.iana.org/assignments/sip-parameters and initiates their population as follows. The initial Methods table is:
INVITE [RFC3261]
ACK [RFC3261]
BYE [RFC3261]
CANCEL [RFC3261]
REGISTER [RFC3261]
OPTIONS [RFC3261]
INFO [RFC2976]
The response code table is initially populated from Section 21, the
portions labeled Informational, Success, Redirection, Client-Error,
Server-Error, and Global-Failure. The table has the following
format:
Type (e.g., Informational)
Number Default Reason Phrase [RFC3261]
The following information needs to be provided in an RFC publication
in order to register a new response code or method:
o The RFC number in which the method or response code is
registered;
o the number of the response code or name of the method being
registered;
o the default reason phrase for that response code, if
applicable;
27.5 The "message/sip" MIME type.
This document registers the "message/sip" MIME media type in order to
allow SIP messages to be tunneled as bodies within SIP, primarily for
end-to-end security purposes. This media type is defined by the
following information:
Media type name: message
Media subtype name: sip
Required parameters: none
Optional parameters: version
version: The SIP-Version number of the enclosed message (e.g.,
"2.0"). If not present, the version defaults to "2.0".
Encoding scheme: SIP messages consist of an 8-bit header
optionally followed by a binary MIME data object. As such, SIP
messages must be treated as binary. Under normal circumstances
SIP messages are transported over binary-capable transports, no
special encodings are needed.
Security considerations: see below
Motivation and examples of this usage as a security mechanism
in concert with S/MIME are given in 23.4.
27.6 New Content-Disposition Parameter Registrations
This document also registers four new Content-Disposition header
"disposition-types": alert, icon, session and render. The authors
request that these values be recorded in the IANA registry for
Content-Dispositions.
Descriptions of these "disposition-types", including motivation and
examples, are given in Section 20.11.
Short descriptions suitable for the IANA registry are:
alert the body is a custom ring tone to alert the user
icon the body is displayed as an icon to the user
render the body should be displayed to the user
session the body describes a communications session, for
example, as RFC 2327 SDP body
28 Changes From RFC 2543
This RFC revises RFC 2543. It is mostly backwards compatible with
RFC 2543. The changes described here fix many errors discovered in
RFC 2543 and provide information on scenarios not detailed in RFC
2543. The protocol has been presented in a more cleanly layered
model here.
We break the differences into functional behavior that is a
substantial change from RFC 2543, which has impact on
interoperability or correct operation in some cases, and functional
behavior that is different from RFC 2543 but not a potential source
of interoperability problems. There have been countless
clarifications as well, which are not documented here.
28.1 Major Functional Changes
o When a UAC wishes to terminate a call before it has been answered,
it sends CANCEL. If the original INVITE still returns a 2xx, the
UAC then sends BYE. BYE can only be sent on an existing call leg
(now called a dialog in this RFC), whereas it could be sent at any
time in RFC 2543.
o The SIP BNF was converted to be RFC 2234 compliant.
o SIP URL BNF was made more general, allowing a greater set of
characters in the user part. Furthermore, comparison rules were
simplified to be primarily case-insensitive, and detailed handling
of comparison in the presence of parameters was described. The
most substantial change is that a URI with a parameter with the
default value does not match a URI without that parameter.
o Removed Via hiding. It had serious trust issues, since it relied
on the next hop to perform the obfuscation process. Instead, Via
hiding can be done as a local implementation choice in stateful
proxies, and thus is no longer documented.
o In RFC 2543, CANCEL and INVITE transactions were intermingled.
They are separated now. When a user sends an INVITE and then a
CANCEL, the INVITE transaction still terminates normally. A UAS
needs to respond to the original INVITE request with a 487
response.
o Similarly, CANCEL and BYE transactions were intermingled; RFC 2543
allowed the UAS not to send a response to INVITE when a BYE was
received. That is disallowed here. The original INVITE needs a
response.
o In RFC 2543, UAs needed to support only UDP. In this RFC, UAs
need to support both UDP and TCP.
o In RFC 2543, a forking proxy only passed up one challenge from
downstream elements in the event of multiple challenges. In this
RFC, proxies are supposed to collect all challenges and place them
into the forwarded response.
o In Digest credentials, the URI needs to be quoted; this is unclear
from RFC 2617 and RFC 2069 which are both inconsistent on it.
o SDP processing has been split off into a separate specification
[13], and more fully specified as a formal offer/answer exchange
process that is effectively tunneled through SIP. SDP is allowed
in INVITE/200 or 200/ACK for baseline SIP implementations; RFC
2543 alluded to the ability to use it in INVITE, 200, and ACK in a
single transaction, but this was not well specified. More complex
SDP usages are allowed in extensions.
o Added full support for IPv6 in URIs and in the Via header field.
Support for IPv6 in Via has required that its header field
parameters allow the square bracket and colon characters. These
characters were previously not permitted. In theory, this could
cause interop problems with older implementations. However, we
have observed that most implementations accept any non-control
ASCII character in these parameters.
o DNS SRV procedure is now documented in a separate specification
[4]. This procedure uses both SRV and NAPTR resource records and
no longer combines data from across SRV records as described in
RFC 2543.
o Loop detection has been made optional, supplanted by a mandatory
usage of Max-Forwards. The loop detection procedure in RFC 2543
had a serious bug which would report "spirals" as an error
condition when it was not. The optional loop detection procedure
is more fully and correctly specified here.
o Usage of tags is now mandatory (they were optional in RFC 2543),
as they are now the fundamental building blocks of dialog
identification.
o Added the Supported header field, allowing for clients to indicate
what extensions are supported to a server, which can apply those
extensions to the response, and indicate their usage with a
Require in the response.
o Extension parameters were missing from the BNF for several header
fields, and they have been added.
o Handling of Route and Record-Route construction was very
underspecified in RFC 2543, and also not the right approach. It
has been substantially reworked in this specification (and made
vastly simpler), and this is arguably the largest change.
Backwards compatibility is still provided for deployments that do
not use "pre-loaded routes", where the initial request has a set
of Route header field values obtained in some way outside of
Record-Route. In those situations, the new mechanism is not
interoperable.
o In RFC 2543, lines in a message could be terminated with CR, LF,
or CRLF. This specification only allows CRLF.
o Usage of Route in CANCEL and ACK was not well defined in RFC 2543. It is now well specified; if a request had a Route header field, its CANCEL or ACK for a non-2xx response to the request need to carry the same Route header field values. ACKs for 2xx responses use the Route values learned from the Record-Route of the 2xx responses. o RFC 2543 allowed multiple requests in a single UDP packet. This usage has been removed. o Usage of absolute time in the Expires header field and parameter has been removed. It caused interoperability problems in elements that were not time synchronized, a common occurrence. Relative times are used instead. o The branch parameter of the Via header field value is now mandatory for all elements to use. It now plays the role of a unique transaction identifier. This avoids the complex and bug- laden transaction identification rules from RFC 2543. A magic cookie is used in the parameter value to determine if the previous hop has made the parameter globally unique, and comparison falls back to the old rules when it is not present. Thus, interoperability is assured. o In RFC 2543, closure of a TCP connection was made equivalent to a CANCEL. This was nearly impossible to implement (and wrong) for TCP connections between proxies. This has been eliminated, so that there is no coupling between TCP connection state and SIP processing. o RFC 2543 was silent on whether a UA could initiate a new transaction to a peer while another was in progress. That is now specified here. It is allowed for non-INVITE requests, disallowed for INVITE. o PGP was removed. It was not sufficiently specified, and not compatible with the more complete PGP MIME. It was replaced with S/MIME. o Added the "sips" URI scheme for end-to-end TLS. This scheme is not backwards compatible with RFC 2543. Existing elements that receive a request with a SIPS URI scheme in the Request-URI will likely reject the request. This is actually a feature; it ensures that a call to a SIPS URI is only delivered if all path hops can be secured.
o Additional security features were added with TLS, and these are
described in a much larger and complete security considerations
section.
o In RFC 2543, a proxy was not required to forward provisional
responses from 101 to 199 upstream. This was changed to MUST.
This is important, since many subsequent features depend on
delivery of all provisional responses from 101 to 199.
o Little was said about the 503 response code in RFC 2543. It has
since found substantial use in indicating failure or overload
conditions in proxies. This requires somewhat special treatment.
Specifically, receipt of a 503 should trigger an attempt to
contact the next element in the result of a DNS SRV lookup. Also,
503 response is only forwarded upstream by a proxy under certain
conditions.
o RFC 2543 defined, but did no sufficiently specify, a mechanism for
UA authentication of a server. That has been removed. Instead,
the mutual authentication procedures of RFC 2617 are allowed.
o A UA cannot send a BYE for a call until it has received an ACK for
the initial INVITE. This was allowed in RFC 2543 but leads to a
potential race condition.
o A UA or proxy cannot send CANCEL for a transaction until it gets a
provisional response for the request. This was allowed in RFC
2543 but leads to potential race conditions.
o The action parameter in registrations has been deprecated. It was
insufficient for any useful services, and caused conflicts when
application processing was applied in proxies.
o RFC 2543 had a number of special cases for multicast. For
example, certain responses were suppressed, timers were adjusted,
and so on. Multicast now plays a more limited role, and the
protocol operation is unaffected by usage of multicast as opposed
to unicast. The limitations as a result of that are documented.
o Basic authentication has been removed entirely and its usage
forbidden.
o Proxies no longer forward a 6xx immediately on receiving it.
Instead, they CANCEL pending branches immediately. This avoids a
potential race condition that would result in a UAC getting a 6xx
followed by a 2xx. In all cases except this race condition, the
result will be the same - the 6xx is forwarded upstream.
o RFC 2543 did not address the problem of request merging. This
occurs when a request forks at a proxy and later rejoins at an
element. Handling of merging is done only at a UA, and procedures
are defined for rejecting all but the first request.
28.2 Minor Functional Changes
o Added the Alert-Info, Error-Info, and Call-Info header fields for
optional content presentation to users.
o Added the Content-Language, Content-Disposition and MIME-Version
header fields.
o Added a "glare handling" mechanism to deal with the case where
both parties send each other a re-INVITE simultaneously. It uses
the new 491 (Request Pending) error code.
o Added the In-Reply-To and Reply-To header fields for supporting
the return of missed calls or messages at a later time.
o Added TLS and SCTP as valid SIP transports.
o There were a variety of mechanisms described for handling failures
at any time during a call; those are now generally unified. BYE
is sent to terminate.
o RFC 2543 mandated retransmission of INVITE responses over TCP, but
noted it was really only needed for 2xx. That was an artifact of
insufficient protocol layering. With a more coherent transaction
layer defined here, that is no longer needed. Only 2xx responses
to INVITEs are retransmitted over TCP.
o Client and server transaction machines are now driven based on
timeouts rather than retransmit counts. This allows the state
machines to be properly specified for TCP and UDP.
o The Date header field is used in REGISTER responses to provide a
simple means for auto-configuration of dates in user agents.
o Allowed a registrar to reject registrations with expirations that
are too short in duration. Defined the 423 response code and the
Min-Expires for this purpose.
29 Normative References
[1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [4] Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers", RFC 3263, June 2002. [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000. [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264, June 2002. [14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [15] Postel, J., "DoD Standard Transmission Control Protocol", RFC 761, January 1980.
[16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [18] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. [19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001. [20] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [21] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [24] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [25] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [26] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.30 Informative References
[27] R. Pandya, "Emerging mobile and personal communication systems," IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995. [28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[29] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000. [31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998. [33] E. M. Schooler, "A multicast user directory service for synchronous rendezvous," Master's Thesis CS-TR-96-18, Department of Computer Science, California Institute of Technology, Pasadena, California, Aug. 1996. [34] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [35] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [36] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998. [37] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000. [38] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997. [39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC 2069, January 1997. [40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis, D., Rosenberg, J., Summers, K. and H. Schulzrinne, "SIP Call Flow Examples", Work in Progress. [41] E. M. Schooler, "Case study: multimedia conference control in a packet-switched teleconferencing system," Journal of Internetworking: Research and Experience, Vol. 4, pp. 99--120, June 1993. ISI reprint series ISI/RS-93-359.
A. Table of Timer Values
Table 4 summarizes the meaning and defaults of the various timers used by this specification. Timer Value Section Meaning ---------------------------------------------------------------------- T1 500ms default Section 17.1.1.1 RTT Estimate T2 4s Section 17.1.2.2 The maximum retransmit interval for non-INVITE requests and INVITE responses T4 5s Section 17.1.2.2 Maximum duration a message will remain in the network Timer A initially T1 Section 17.1.1.2 INVITE request retransmit interval, for UDP only Timer B 64*T1 Section 17.1.1.2 INVITE transaction timeout timer Timer C > 3min Section 16.6 proxy INVITE transaction bullet 11 timeout Timer D > 32s for UDP Section 17.1.1.2 Wait time for response 0s for TCP/SCTP retransmits Timer E initially T1 Section 17.1.2.2 non-INVITE request retransmit interval, UDP only Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction timeout timer Timer G initially T1 Section 17.2.1 INVITE response retransmit interval Timer H 64*T1 Section 17.2.1 Wait time for ACK receipt Timer I T4 for UDP Section 17.2.1 Wait time for 0s for TCP/SCTP ACK retransmits Timer J 64*T1 for UDP Section 17.2.2 Wait time for 0s for TCP/SCTP non-INVITE request retransmits Timer K T4 for UDP Section 17.1.2.2 Wait time for 0s for TCP/SCTP response retransmits Table 4: Summary of timers
Acknowledgments
We wish to thank the members of the IETF MMUSIC and SIP WGs for their comments and suggestions. Detailed comments were provided by Ofir Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan, Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema, Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick Workman. Brian Rosen provided the compiled BNF. Jean Mahoney provided technical writing assistance. This work is based, inter alia, on [41,42].
Authors' Addresses
Authors addresses are listed alphabetically for the editors, the writers, and then the original authors of RFC 2543. All listed authors actively contributed large amounts of text to this document. Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA EMail: jdrosen@dynamicsoft.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA EMail: schulzrinne@cs.columbia.edu Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland EMail: Gonzalo.Camarillo@ericsson.com Alan Johnston WorldCom 100 South 4th Street St. Louis, MO 63102 USA EMail: alan.johnston@wcom.com
Jon Peterson NeuStar, Inc 1800 Sutter Street, Suite 570 Concord, CA 94520 USA EMail: jon.peterson@neustar.com Robert Sparks dynamicsoft, Inc. 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 USA EMail: rsparks@dynamicsoft.com Mark Handley International Computer Science Institute 1947 Center St, Suite 600 Berkeley, CA 94704 USA EMail: mjh@icir.org Eve Schooler AT&T Labs-Research 75 Willow Road Menlo Park, CA 94025 USA EMail: schooler@research.att.com
Full Copyright Statement Copyright (C) The Internet Society (2002). 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.