doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc4485.txt b/doc/rfc/rfc4485.txt
new file mode 100644
index 0000000..4133093
--- /dev/null
+++ b/doc/rfc/rfc4485.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group                                       J. Rosenberg
+Request for Comments: 4485                                 Cisco Systems
+Category: Informational                                   H. Schulzrinne
+                                                     Columbia University
+                                                                May 2006
+
+
+                Guidelines for Authors of Extensions to
+                 the Session Initiation Protocol (SIP)
+
+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 (2006).
+
+Abstract
+
+   The Session Initiation Protocol (SIP) is a flexible yet simple tool
+   for establishing interactive communications sessions across the
+   Internet.  Part of this flexibility is the ease with which it can be
+   extended.  In order to facilitate effective and interoperable
+   extensions to SIP, some guidelines need to be followed when
+   developing SIP extensions.  This document outlines a set of such
+   guidelines for authors of SIP extensions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne      Informational                      [Page 1]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................3
+   3. Should I Define a SIP Extension? ................................3
+      3.1. SIP's Solution Space .......................................4
+      3.2. SIP Architectural Model ....................................5
+   4. Issues to Be Addressed ..........................................7
+      4.1. Backwards Compatibility ....................................7
+      4.2. Security ..................................................10
+      4.3. Terminology ...............................................10
+      4.4. Syntactic Issues ..........................................10
+      4.5. Semantics, Semantics, Semantics ...........................13
+      4.6. Examples Section ..........................................14
+      4.7. Overview Section ..........................................14
+      4.8. IANA Considerations Section ...............................14
+      4.9. Document-Naming Conventions ...............................16
+      4.10. Additional Considerations for New Methods ................16
+      4.11. Additional Considerations for New Header Fields
+            or Header Field ..........................................17
+      4.12. Additional Considerations for New Body Types .............18
+   5. Interactions with SIP Features .................................18
+   6. Security Considerations ........................................19
+   7. Acknowledgements ...............................................19
+   8. References .....................................................19
+      8.1. Normative References ......................................19
+      8.2. Informative References ....................................20
+
+1.  Introduction
+
+   The Session Initiation Protocol (SIP) [2] is a flexible yet simple
+   tool for establishing interactive communications sessions across the
+   Internet.  Part of this flexibility is the ease with which it can be
+   extended (with new methods, new header fields, new body types, and
+   new parameters), and there have been countless proposals that have
+   been made to do just that.  An IETF process has been put into place
+   that defines how extensions are to be made to the SIP protocol [10].
+   That process is designed to ensure that extensions are made that are
+   appropriate for SIP (as opposed to being done in some other
+   protocol), that these extensions fit within the model and framework
+   provided by SIP and are consistent with its operation, and that these
+   extensions solve problems generically rather than for a specific use
+   case.  However, [10] does not provide the technical guidelines needed
+   to assist that process.  This specification helps to meet that need.
+
+   This specification first provides a set of guidelines to help decide
+   whether a certain piece of functionality is appropriately done in
+   SIP.  Assuming the functionality is appropriate, it then points out
+
+
+
+Rosenberg & Schulzrinne      Informational                      [Page 2]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   issues that extensions should deal with from within their
+   specification.  Finally, it discusses common interactions with
+   existing SIP features that often cause difficulties in extensions.
+
+2.  Terminology
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
+   indicate requirement levels for compliant implementations.
+
+3.  Should I Define a SIP Extension?
+
+   The first question to be addressed when defining a SIP extension is
+   whether a SIP extension is the best solution to the problem.  SIP has
+   been proposed as a solution for numerous problems, including
+   mobility, configuration and management, QoS control, call control,
+   caller preferences, device control, third-party call control, and
+   MPLS path setup, to name a few.  Clearly, not every problem can be
+   solved by a SIP extension.  More importantly, some problems that
+   could be solved by a SIP extension probably shouldn't.
+
+   To assist engineers in determining whether a SIP extension is an
+   appropriate solution to their problem, we present two broad criteria.
+   First, the problem SHOULD fit into the general purview of SIP's
+   solution space.  Secondly, the solution MUST conform to the general
+   SIP architectural model.
+
+   Although the first criteria might seem obvious, we have observed that
+   numerous extensions to SIP have been proposed because some function
+   is needed in a device that also speaks SIP.  The argument is
+   generally given that "I'd rather implement one protocol than many".
+   As an example, user agents, like all other IP hosts, need some way to
+   obtain their IP address.  This is generally done through DHCP [11].
+   SIP's multicast registration mechanisms might supply an alternate way
+   to obtain an IP address.  This would eliminate the need for DHCP in
+   clients.  However, we do not believe such extensions are appropriate.
+   We believe that protocols should be defined to provide specific,
+   narrow functions, rather than be defined for all protocols needed
+   between a pair of devices.  The former approach to protocol design
+   yields modular protocols with broad application.  It also facilitates
+   extensibility and growth; single protocols can be removed and changed
+   without affecting the entire system.  We observe that this approach
+   to protocol engineering mirrors object-oriented software engineering.
+
+   Our second criteria, that the extension must conform to the general
+   SIP architectural model, ensures that the protocol remains manageable
+   and broadly applicable.
+
+
+
+Rosenberg & Schulzrinne      Informational                      [Page 3]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+3.1.  SIP's Solution Space
+
+   In order to evaluate the first criteria, it is necessary to define
+   exactly what SIP's solution space is, and what it is not.
+
+   SIP is a protocol for initiating, modifying, and terminating
+   interactive sessions.  This process involves the discovery of users,
+   (or, more generally, entities that can be communicated with,
+   including services, such as voicemail or translation devices)
+   wherever they may be located, so that a description of the session
+   can be delivered to the user.  It is assumed that these users or
+   communications entities are mobile, and that their point of
+   attachment to the network changes over time.  The primary purpose of
+   SIP is a rendezvous function, to allow a request initiator to deliver
+   a message to a recipient wherever they may be.  Such a rendezvous is
+   needed to establish a session, but it can be used for other purposes
+   related to communications, such as querying for capabilities or
+   delivery of an instant message.
+
+   Much of SIP focuses on this discovery and rendezvous component.  Its
+   ability to fork, its registration capabilities, and its routing
+   capabilities are all present for the singular purpose of finding the
+   desired user wherever they may be.  As such, features and
+   capabilities such as personal mobility, automatic call distribution,
+   and follow-me are well within the SIP solution space.
+
+   Session initiation also depends on the ability of the called party to
+   have enough information about the session itself to make a decision
+   on whether to join.  That information includes data about the caller,
+   the purpose for the invitation, and parameters of the session itself.
+   For this reason, SIP includes this kind of information.
+
+   Part of the process of session initiation is the communication of
+   progress and the final results of establishment of the session.  SIP
+   provides this information as well.
+
+   SIP itself is independent of the session, and the session description
+   is delivered as an opaque body within SIP messages.  Keeping SIP
+   independent of the sessions it initiates and terminates is
+   fundamental.  As such, there are many functions that SIP explicitly
+   does not provide.  It is not a session management protocol or a
+   conference control protocol.  The particulars of the communications
+   within the session are outside of SIP.  This includes features such
+   as media transport, voting and polling, virtual microphone passing,
+   chairman election, floor control, and feedback on session quality.
+
+   SIP is not a resource reservation protocol for sessions.  This is
+   fundamentally because (1) SIP is independent of the underlying
+
+
+
+Rosenberg & Schulzrinne      Informational                      [Page 4]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   session it establishes, and (2) the path of SIP messages is
+   completely independent from the path that session packets may take.
+   The path independence refers to paths within a provider's network and
+   the set of providers itself.  For example, it is perfectly reasonable
+   for a SIP message to traverse a completely different set of
+   autonomous systems than the audio in a session SIP establishes.
+
+   SIP is not a general purpose transfer protocol.  It is not meant to
+   send large amounts of data unrelated to SIP's operation.  It is not
+   meant as a replacement for HTTP.  This is not to say that carrying
+   payloads in SIP messages is never a good thing; in many cases, the
+   data is very much related to SIP's operation.  In those cases,
+   congestion-controlled transports end-to-end are critical.
+
+   SIP is not meant to be a general Remote Procedure Call (RPC)
+   mechanism.  None of its user discovery and registration capabilities
+   are needed for RPC, and neither are most of its proxy functions.
+
+   SIP is not meant to be used as a strict Public Switched Telephone
+   Network (PSTN) signaling replacement.  It is not a superset of the
+   Integrated Services Digital Network (ISDN) User Part (ISUP).
+   Although it can support gatewaying of PSTN signaling and can provide
+   many features present in the PSTN, the mere existence of a feature or
+   capability in the PSTN is not a justification for its inclusion in
+   SIP.  Extensions needed to support telephony MUST meet the other
+   criteria described here.
+
+   SIP is a poor control protocol.  It is not meant to be used for one
+   entity to tell another to pick up or answer a phone, to send audio
+   using a particular codec, or to provide a new value for a
+   configuration parameter.  Control protocols have different trust
+   relationships from that assumed in SIP and are more centralized in
+   architecture than SIP is, as SIP is a very distributed protocol.
+
+   There are many network layer services needed to make SIP function.
+   These include quality of service, mobility, and security, among
+   others.  Rather than build these capabilities into SIP itself, they
+   SHOULD be developed outside of SIP and then used by it.
+   Specifically, any protocol mechanisms that are needed by SIP, but
+   that are also needed by many other application layer protocols SHOULD
+   NOT be addressed within SIP.
+
+3.2.  SIP Architectural Model
+
+   We describe here some of the primary architectural assumptions that
+   underlie SIP.  Extensions that violate these assumptions should be
+   examined more carefully to determine their appropriateness for SIP.
+
+
+
+
+Rosenberg & Schulzrinne      Informational                      [Page 5]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   Session independence:  SIP is independent of the session it
+      establishes.  This includes the type of session, be it audio,
+      video, game, chat session, or virtual reality.  SIP operation
+      SHOULD NOT depend on some characteristic of the session.  SIP is
+      not specific to voice only.  Any extensions to SIP MUST consider
+      the application of SIP to a variety of different session types.
+
+   SIP and Session path independence:  We have already touched on this
+      once, but it is worth noting again.  The set of routers, networks,
+      and/or autonomous systems traversed by SIP messages are unrelated
+      to the set of routers, networks, and/or autonomous systems
+      traversed by session packets.  They may be the same in some cases,
+      but it is fundamental to SIP's architecture that they need not be
+      the same.  Standards-track extensions MUST NOT be defined that
+      work only when the signaling and session paths are coupled.  Non-
+      standard P-header extensions [10] are required for any extension
+      that only works in such a case.
+
+   Multi-provider and multi-hop:  SIP assumes that its messages will
+      traverse the Internet.  That is, SIP works through multiple
+      networks administered by different providers.  It is also assumed
+      that SIP messages traverse many hops (where each hop is a proxy).
+      Extensions MUST NOT work only under the assumption of a single hop
+      or specialized network topology.  They SHOULD avoid the assumption
+      of a single SIP provider (but see the use of P-Headers, per RFC
+      3427 [10]).
+
+   Transactional:  SIP is a request/response protocol, possibly enhanced
+      with intermediate responses.  Many of the rules of operation in
+      SIP are based on general processing of requests and responses.
+      This includes the reliability mechanisms, routing mechanisms, and
+      state maintenance rules.  Extensions SHOULD NOT add messages that
+      are not within the request-response model.
+
+   Proxies can ignore bodies:  In order for proxies to scale well, they
+      must be able to operate with minimal message processing.  SIP has
+      been engineered so that proxies can always ignore bodies.
+      Extensions SHOULD NOT require proxies to examine bodies.
+
+   Proxies don't need to understand the method:  Processing of requests
+      in proxies does not depend on the method, except for the well-
+      known methods INVITE, ACK, and CANCEL.  This allows for
+      extensibility.  Extensions MUST NOT define new methods that must
+      be understood by proxies.
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne      Informational                      [Page 6]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   INVITE messages carry full state:  An initial INVITE message for a
+      session is nearly identical (the exception is the tag) to a re-
+      INVITE message to modify some characteristic of the session.  This
+      full state property is fundamental to SIP and is critical for
+      robustness of SIP systems.  Extensions SHOULD NOT modify INVITE
+      processing such that data spanning multiple INVITEs must be
+      collected in order to perform some feature.
+
+   Generality over efficiency:  Wherever possible, SIP has favored
+      general-purpose components rather than narrow ones.  If some
+      capability is added to support one service but a slightly broader
+      capability can support a larger variety of services (at the cost
+      of complexity or message sizes), the broader capability SHOULD be
+      preferred.
+
+   The Request URI is the primary key for forwarding:  Forwarding logic
+      at SIP servers depends primarily on the request URI (this is
+      different from request routing in SIP, which uses the Route header
+      fields to pass a request through intermediate proxies).  It is
+      fundamental to the operation of SIP that the request URI indicate
+      a resource that, under normal operations, resolves to the desired
+      recipient.  Extensions SHOULD NOT modify the semantics of the
+      request URI.
+
+   Heterogeneity is the norm:  SIP supports heterogeneous devices.  It
+      has built-in mechanisms for determining the set of overlapping
+      protocol functionalities.  Extensions SHOULD NOT be defined that
+      only function if all devices support the extension.
+
+4.  Issues to Be Addressed
+
+   Given an extension has met the litmus tests in the previous section,
+   there are several issues that all extensions should take into
+   consideration.
+
+4.1.  Backward Compatibility
+
+   One of the most important issues to consider is whether the new
+   extension is backward compatible with baseline SIP.  This is tightly
+   coupled with how the Require, Proxy-Require, and Supported header
+   fields are used.
+
+   If an extension consists of new header fields or header field
+   parameters inserted by a user agent in a request with an existing
+   method, and the request cannot be processed reasonably by a proxy
+   and/or user agent without understanding the header fields or
+   parameters, the extension MUST mandate the usage of the Require
+   and/or Proxy-Require header fields in the request.  These extensions
+
+
+
+Rosenberg & Schulzrinne      Informational                      [Page 7]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   are not backwards compatible with SIP.  The result of mandating usage
+   of these header fields means that requests cannot be serviced unless
+   the entities being communicated with also understand the extension.
+   If some entity does not understand the extension, the request will be
+   rejected.  The UAC can then handle this in one of two ways.  In the
+   first, the request simply fails, and the service cannot be provided.
+   This is basically an interoperability failure.  In the second case,
+   the UAC retries the request without the extension.  This will
+   preserve interoperability, at the cost of a "dual stack"
+   implementation in a UAC (processing rules for operation with and
+   without the extension).  As the number of extensions increases, this
+   leads to an exponential explosion in the sets of processing rules a
+   UAC may need to implement.  The result is excessive complexity.
+
+   Because of the possibility of interoperability and complexity
+   problems that result from the usage of Require and Proxy-Require, we
+   believe the following guidelines are appropriate:
+
+   o  The usage of these header fields in requests for basic SIP
+      services (in particular, session initiation and termination) is
+      NOT RECOMMENDED.  The less frequently a particular extension is
+      needed in a request, the more reasonable it is to use these header
+      fields.
+
+   o  The Proxy-Require header field SHOULD be avoided at all costs.
+      The failure likelihood in an individual proxy stays constant, but
+      the path failure grows exponentially with the number of hops.  On
+      the other hand, the Require header field only mandates that a
+      single entity, the UAS, support the extension.  Usage of
+      Proxy-Require is thus considered exponentially worse than usage of
+      the Require header field.
+
+   o  If either Require or Proxy-Require are used by an extension, the
+      extension SHOULD discuss how to fall back to baseline SIP
+      operation if the request is rejected with a 420 response.
+
+   Extensions that define new methods do not need to use the Require
+   header field.  SIP defines mechanisms that allow a UAC to know
+   whether a new method is understood by a UAS.  This includes both the
+   OPTIONS request and the 405 (Method Not Allowed) response with the
+   Allow header field.  It is fundamental to SIP that proxies need not
+   understand the semantics of a new method in order to process it.  If
+   an extension defines a new method that must be understood by proxies
+   in order to be processed, a Proxy-Require header field is needed.  As
+   discussed above, these kinds of extensions are frowned upon.
+
+   In order to achieve backwards compatibility for extensions that
+   define new methods, the Allow header field is used.  There are two
+
+
+
+Rosenberg & Schulzrinne      Informational                      [Page 8]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   types of new methods - those that are used for established dialogs
+   (initiated by INVITE, for example), and those that are sent as the
+   initial request to a UA.  Since INVITE and its response both SHOULD
+   contain an Allow header field, a UA can readily determine whether the
+   new method can be supported within the dialog.  For example, once an
+   INVITE dialog is established, a user agent could determine whether
+   the REFER method [12] is supported if it is present in an Allow
+   header field.  If it wasn't, the "transfer" button on the UI could be
+   "greyed out" once the call is established.
+
+   Another type of extension is that which requires a proxy to insert
+   header fields or header field parameters into a request as it
+   traverses the network, or for the UAS to insert header fields or
+   header field parameters into a response.  For some extensions, if the
+   UAC or UAS does not understand these header fields, the message can
+   still be processed correctly.  These extensions are completely
+   backwards compatible.
+
+   Most other extensions of this type require that the server only
+   insert the header field or parameter if it is sure the client
+   understands it.  In this case, these extensions will need to make use
+   of the Supported request header field mechanism.  This mechanism
+   allows a server to determine if the client can understand some
+   extension, so that it can apply the extension to the response.  By
+   their nature, these extensions may not always be able to be applied
+   to every response.
+
+   If an extension requires a proxy to insert a header field or
+   parameter into a request and this header field or parameter needs to
+   be understood by both UAC and UAS to be executed correctly, a
+   combination of the Require and the Supported mechanism will need to
+   be used.  The proxy can insert a Require header field into the
+   request if the Supported header field is present.  An example of such
+   an extension is the SIP Session Timer [13].
+
+   Yet another type of extension is that which defines new body types to
+   be carried in SIP messages.  According to the SIP specification,
+   bodies must be understood by user agents in order to process a
+   request.  As such, the interoperability issues are similar to new
+   methods.  However, the Content-Disposition header field has been
+   defined to allow a client or server to indicate that the message body
+   is optional [2].  Extensions that define or require new body types
+   SHOULD make them optional for the user agent to process.
+
+   When a body must be understood to properly process a request or
+   response, it is preferred that the sending entity know ahead of time
+   whether the new body is understood by the recipient.  For requests
+   that establish a dialog, inclusion of Accept in the request and its
+
+
+
+Rosenberg & Schulzrinne      Informational                      [Page 9]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   success responses is RECOMMENDED.  This will allow both parties to
+   determine what body types are supported by their peers.  Subsequent
+   messaging between the peers would then only include body types that
+   were indicated as being understood.
+
+4.2.  Security
+
+   Security is an important component of any protocol.  Designers of SIP
+   extensions need to carefully consider if additional security
+   requirements are required over those described in RFC 3261.
+   Frequently, authorization requirements and requirements for end-to-
+   end integrity are the most overlooked.
+
+   SIP extensions MUST consider how (or if) they affect usage of the
+   general SIP security mechanisms.  Most extensions should not require
+   any new security capabilities beyond general-purpose SIP.  If they
+   do, it is likely that the security mechanism has more general-purpose
+   application and should be considered an extension in its own right.
+
+   Overall system security requires that both the SIP signaling and the
+   media sessions it established be secured.  The media sessions
+   normally use their own security techniques, which are quite distinct
+   from those used by SIP itself.  Extensions should take care not to
+   conflate the two.  However, specifications that define extensions
+   that impact the media sessions in any way SHOULD consider the
+   interactions between SIP and session security mechanisms.
+
+4.3.  Terminology
+
+   RFC 3261 has an extensive terminology section that defines terms such
+   as caller, callee, user agent, and header field.  All SIP extensions
+   MUST conform to this terminology.  They MUST NOT define new terms
+   that describe concepts already defined by a term in another SIP
+   specification.  If new terminology is needed, it SHOULD appear in a
+   separate section towards the beginning of the document.
+
+   Careful attention must be paid to the actual usage of terminology.
+   Many documents misuse the terms header, header field, and header
+   field values, for example.  Document authors SHOULD do a careful
+   review of their documents for proper usage of these terms.
+
+4.4.  Syntactic Issues
+
+   Extensions that define new methods SHOULD use all capitals for the
+   method name.  Method names SHOULD be shorter than 10 characters and
+   SHOULD attempt to convey the general meaning of the request.  Method
+   names are case sensitive, and therefore, strictly speaking, they
+   don't have to be capitalized.  However, using capitalized method
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 10]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   names keeps with a long-standing convention in SIP and many similar
+   protocols, such as HTTP [15] and RTSP [16].
+
+   Extensions that define new header fields that are anticipated to be
+   heavily used MAY define a compact form if those header fields are
+   more than six characters.  "Heavily used" means that the percentage
+   of all emitted messages that contain that header field is over thirty
+   percent.  Usage of compact forms in these cases is only a MAY because
+   there are better approaches for reducing message overhead [20].
+   Compact header fields MUST be a single character.  When all 26
+   characters are exhausted, new compact forms will no longer be
+   defined.  Header field names are defined by the "token" production in
+   RFC 3261, Section 25.1, and thus include the upper and lowercase
+   letters, the digits 0 through 9, the HYPHEN-MINUS (-), FULL STOP (.),
+   EXCLAMATION MARK (!), PERCENT SIGN (%), ASTERISK (*), LOW LINE (_),
+   PLUS SIGN (+), GRAVE ACCENT (`), APOSTROPHE ('), and TILDE (~).  They
+   SHOULD be descriptive but reasonably brief.  Although header field
+   names are case insensitive, a single common capitalization SHOULD be
+   used throughout the document.  It is RECOMMENDED that each English
+   word present in the header field name have its first letter
+   capitalized.  For example, "ThisIsANewHeader".
+
+   As an example, the following are poor choices for header field names:
+
+   ThisIsMyNewHeaderThatDoesntDoVeryMuchButItHasANiceName
+   --.!A
+   Function
+
+   Case sensitivity of parameters and values is a constant source of
+   confusion, a difficulty that plagued RFC 2543 [17].  This has been
+   simplified through the usage of the BNF constructs of RFC 4234 [5],
+   which have clear rules of case sensitivity and insensitivity.
+   Therefore, the BNF for an extension completely defines the matching
+   rules.
+
+   Extensions MUST be consistent with the SIP conventions for case
+   sensitivity.  Methods MUST be case sensitive.  Header field names
+   MUST be case insensitive.  Header field parameter names MUST be case
+   insensitive.  Header field values and parameter values are sometimes
+   case sensitive, and sometimes case insensitive.  However, generally,
+   they SHOULD be case insensitive.  Defining a case-sensitive component
+   requires explicitly listing each character through its ASCII code.
+
+   Extensions that contain freeform text MUST allow that text to be
+   UTF-8, as per the IETF policies on character set usage [3].  This
+   ensures that SIP remains an internationalized standard.  As a general
+   guideline, freeform text is never needed by programs to perform
+   protocol processing.  It is usually entered by and displayed to the
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 11]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   user.  If an extension uses a parameter that can contain UTF-8-
+   encoded characters, and that extension requires a comparison to be
+   made of this parameter to other parameters, the comparison MUST be
+   case sensitive.  Case-insensitive comparison rules for UTF-8 text
+   are, at this time, impossible and MUST be avoided.
+
+   Extensions that make use of dates MUST use the SIP-Date BNF defined
+   in RFC 3261.  No other date formats are allowed.  However, the usage
+   of absolute dates to determine intervals (for example, the time at
+   which some timer fires) is NOT RECOMMENDED.  This is because it
+   requires synchronized time between peers, and this is frequently not
+   the case.  Therefore, relative times, expressed in numbers of
+   seconds, SHOULD be used.
+
+   Extensions that include network-layer addresses SHOULD permit dotted
+   quad IPv4 addresses, IPv6 addresses in the format described in [4],
+   and domain names.
+
+   Extensions that have header fields containing URIs SHOULD be explicit
+   about which URI schemes can be used in that header field.  Header
+   fields SHOULD allow the broadest set of URI schemes possible that are
+   a match for the semantics of the header field.
+
+   Header fields MUST follow the standard formatting for SIP, defined as
+   follows:
+
+   header          = header-name HCOLON header-value
+                      *(COMMA header-value)
+   header-name     = token
+   header-value    = value *(SEMI value-parameter)
+   value-parameter = token [EQUAL gen-value]
+   gen-value       = token / host / quoted-string
+   value           = token / host / quoted-string
+
+   In some cases, this form is not sufficient.  That is the case for
+   header fields that express descriptive text meant for human
+   consumption.  An example is the Subject header field in SIP [2].  In
+   this case, an alternate form is:
+
+   header          = header-name HCOLON [TEXT-UTF8-TRIM]
+
+   Developers of extensions SHOULD allow for extension parameters in
+   their header fields.
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 12]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   Header fields that contain a list of URIs SHOULD follow the same
+   syntax as the Contact header field in SIP.  Implementors are also
+   encouraged to wrap these URI in angle brackets, "<" and ">", at all
+   times.  We have found this to be a frequently misimplemented feature.
+
+   Beyond the compact form, there is no need to define compressed
+   versions of header field values.  Compression of SIP messages SHOULD
+   be handled at lower layers, for example, using IP payload compression
+   [18] or signalling compression [20].
+
+   Syntax for header fields is expressed in Augmented Backus-Naur Form
+   and MUST follow the format of RFC 4234 [5].  Extensions MUST make use
+   of the primitive components defined in RFC 3261 [2].  If the
+   construction for a BNF element is defined in another specification,
+   it is RECOMMENDED that the construction be referenced rather than
+   copied.  The reference SHOULD include both the document and section
+   number.  All BNF elements must be either defined or referenced.
+
+   It is RECOMMENDED that BNF be collected into a single section near
+   the end of the document.
+
+   All tokens and quoted strings are separated by explicit linear white
+   space.  Linear white space, for better or worse, allows for line
+   folding.  Extensions MUST NOT define new header fields that use
+   alternate linear white space rules.
+
+   All SIP extensions MUST verify that any BNF productions that they
+   define in their grammar do not conflict with any existing grammar
+   defined in other SIP standards-track specifications.
+
+4.5.  Semantics, Semantics, Semantics
+
+   Developers of protocols often get caught up in syntax issues, without
+   spending enough time on semantics.  The semantics of a protocol are
+   far more important.  SIP extensions MUST clearly define the semantics
+   of the extensions.  Specifically, the extension MUST specify the
+   behaviors expected of a UAC, UAS, and proxy in processing the
+   extension.  This is often best described by having separate sections
+   for each of these three elements.  Each section SHOULD step through
+   the processing rules in temporal order of the most common messaging
+   scenario.
+
+   Processing rules generally specify actions to be taken (in terms of
+   messages to be sent, variables to be stored, and rules to be
+   followed) on receipt of messages and expiration of timers.  If an
+   action requires transmission of a message, the rule SHOULD outline
+   requirements for insertion of header fields or other information in
+   the message.
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 13]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   The extension SHOULD specify procedures to be taken in exceptional
+   conditions that are recoverable, or that require some kind of user
+   intervention.  Handling of unrecoverable errors does not require
+   specification.
+
+4.6.  Examples Section
+
+   The specification SHOULD contain a section that gives examples of
+   call flows and message formatting.  Extensions that define
+   substantial new syntax SHOULD include examples of messages containing
+   that syntax.  Examples of message flows should be given to cover
+   common cases and at least one failure or unusual case.
+
+   For an example of how to construct a good examples section, see the
+   message flows and message formatting defined in the Basic Call Flows
+   specification [21].  Note that complete messages SHOULD be used.  Be
+   careful to include tags, Via header fields (with the branch ID
+   cookie), Max-Forwards, Content-Lengths, Record-Route, and Route
+   header fields.  Example INVITE messages MAY omit session
+   descriptions, and Content-Length values MAY be set to "..." to
+   indicate that the value is not provided.  However, the specification
+   MUST explicitly call out the meaning of the "..." and explicitly
+   indicate that session descriptions were not included.
+
+4.7.  Overview Section
+
+   Too often, extension documents dive into detailed syntax and
+   semantics without giving a general overview of operation.  This makes
+   understanding of the extension harder.  It is RECOMMENDED that
+   extensions have a protocol overview section that discusses the basic
+   operation of the extension.  Basic operation usually consists of the
+   message flow, in temporal order, for the most common case covered by
+   the extension.  The most important processing rules for the elements
+   in the call flow SHOULD be mentioned.  Usage of the RFC 2119 [1]
+   terminology in the overview section is NOT RECOMMENDED, and the
+   specification should explicitly state that the overview is tutorial
+   in nature only.  This section SHOULD expand all acronyms, even those
+   common in SIP systems, and SHOULD be understandable to readers who
+   are not SIP experts. [27] provides additional guidance on writing
+   good overview sections.
+
+4.8.  IANA Considerations Section
+
+   Documents that define new SIP extensions will invariably have IANA
+   Considerations sections.
+
+   If your extension is defining a new event package, you MUST register
+   that package.  RFC 3265 [6] provides the registration template.  See
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 14]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   [22] for an example of the registration of a new event package.  As
+   discussed in RFC 3427 [10], only standards-track documents can
+   register new event-template packages.  Both standards-track and
+   informational specifications can register event packages.
+
+   If your extension is defining a new header field, you MUST register
+   that header field.  RFC 3261 [2] provides a registration template.
+   See Section 8.2 of RFC 3262 [23] for an example of how to register
+   new SIP header fields.  Both standards-track and informational
+   P-header specifications can register new header fields [10].
+
+   If your extension is defining a new response code, you MUST register
+   that response code.  RFC 3261 [2] provides a registration template.
+   See Section 6.4 of RFC 3329 [19] for an example of how to register a
+   new response code.  As discussed in RFC 3427 [10], only standards-
+   track documents can register new response codes.
+
+   If your extension is defining a new SIP method, you MUST register
+   that method.  RFC 3261 [2] provides a registration template.  See
+   Section 10 of RFC 3311 [24] for an example of how to register a new
+   SIP method.  As discussed in RFC 3427 [10], only standards-track
+   documents can register new methods.
+
+   If your extension is defining a new SIP header field parameter, you
+   MUST register that header field parameter per the guidelines in RFC
+   3968 [7].  Section 4.1 of that specification provides a template.
+   Only IETF approved specifications can register new header field
+   parameters.  However, there is no requirement that these be standards
+   track.
+
+   If your extension is defining a new SIP URI parameter, you MUST
+   register that URI parameter per the guidelines in RFC 3969 [8].
+   Section 4.1 of that specification provides a template.  Only
+   standards-track documents can register new URI parameters.
+
+   Many SIP extensions make use of option tags, carried in the Require,
+   Proxy-Require, and Supported header fields.  Section 4.1 discusses
+   some of the issues involved in the usage of these header fields.  If
+   your extension does require them, you MUST register an option tag for
+   your extension.  RFC 3261 [2] provides a registration template.  See
+   Section 8.1 of RFC 3262 [23] for an example of how to register an
+   option tag.  Only standards-track RFCs can register new option tags.
+
+   Some SIP extensions will require establishment of their own IANA
+   registries.  RFC 2434 [25] provides guidance on how and when IANA
+   registries are established.  For an example of how to set one up, see
+   Section 6 of RFC 3265 [6] for an example.
+
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 15]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+4.9.  Document-Naming Conventions
+
+   An important decision to be made about the extension is its title.
+   The title MUST indicate that the document is an extension to SIP.  It
+   is RECOMMENDED that the title follow the basic form of "A [summary of
+   function] for the Session Initiation Protocol (SIP)", where the
+   summary of function is a one- to three-word description of the
+   extension.  For example, if an extension defines a new header field,
+   called Make-Coffee, for making coffee, the title would read, "Making
+   Coffee with the Session Initiation Protocol (SIP)".  It is
+   RECOMMENDED that these additional words be descriptive rather than
+   naming the header field.  For example, the extension for making
+   coffee should not be named "The Make-Coffee Header for the Session
+   Initiation Protocol".
+
+   For extensions that define new methods, an acceptable template for
+   titles is "The Session Initiation Protocol (SIP) X Method" where X is
+   the name of the method.
+
+   Note that the acronym SIP MUST be expanded in the titles of RFCs, as
+   per [26].
+
+4.10.  Additional Considerations for New Methods
+
+   Extensions that define new methods SHOULD take into consideration and
+   discuss the following issues:
+
+   o  Can it contain bodies?  If so, what is the meaning of the presence
+      of those bodies?  What body types are allowed?
+
+   o  Can a transaction with this request method occur while another
+      transaction, in the same and/or reverse direction, is in progress?
+
+   o  The extension MUST define which header fields can be present in
+      requests of that method.  It is RECOMMENDED that this information
+      be represented as a new column of Table 2/3 of RFC 3261 [2].  The
+      table MUST contain rows for all header fields defined in
+      standards-track RFCs at the time of writing of the extension.
+
+   o  Can the request be sent within a dialog, or does it establish a
+      dialog?
+
+   o  Is it a target refresh request?
+
+   o  Extensions to SIP that define new methods MAY specify whether
+      offers and answers can appear in requests of that method or its
+      responses.  However, those extensions MUST adhere to the protocol
+
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 16]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+      rules specified in [28] and MUST adhere to the additional
+      constraints for offers and answers as specified in SIP [2].
+
+   o  Because of the nature of reliability treatment of requests with
+      new methods, those requests need to be answered immediately by the
+      UAS.  Protocol extensions that require longer durations for the
+      generation of a response (such as a new method that requires human
+      interaction) SHOULD instead use two transactions - one to send the
+      request, and another in the reverse direction to convey the result
+      of the request.  An example of that is SUBSCRIBE and NOTIFY [6].
+
+   o  The SIP specification [2] allows new methods to specify whether
+      transactions using that new method can be canceled using a CANCEL
+      request.  Further study of the non-INVITE transaction [14] has
+      determined that non-INVITE transactions must be completed as soon
+      as possible.  New methods must not plan for the transaction to
+      pend long enough for CANCEL to be meaningful.  Thus, new methods
+      MUST declare that transactions initiated by requests with that
+      method cannot be canceled.  Future work may relax this
+      restriction, at which point these guidelines will be revised.
+
+   o  New methods that establish a new dialog must discuss the impacts
+      of forking.  The design of such new methods should follow the
+      pattern of requiring an immediate request in the reverse direction
+      from the request establishing a dialog, similar to the immediate
+      NOTIFY sent when a subscription is created per RFC 3265 [6].
+
+   The reliability mechanisms for all new methods must be the same as
+   for BYE.  The delayed response feature of INVITE is only available in
+   INVITE, never for new methods.  The design of new methods must
+   encourage an immediate response.  If the application being enabled
+   requires a delay, the design SHOULD follow a pattern using multiple
+   transactions, similar to RFC 3265's use of NOTIFYs with different
+   Subscription-State header field values (pending and active in
+   particular) in response to SUBSCRIBE [6].
+
+4.11.  Additional Considerations for New Header Fields or Header Field
+       Parameters
+
+   The most important issue for extensions that define new header fields
+   or header field parameters is backwards compatibility.  See
+   Section 4.1 for a discussion of the issues.  The extension MUST
+   detail how backwards compatibility is addressed.
+
+   It is often tempting to avoid creation of a new method by overloading
+   an existing method through a header field or parameter.  Header
+   fields and parameters are not meant to fundamentally alter the
+   meaning of the method of the request.  A new header field cannot
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 17]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   change the basic semantic and processing rules of a method.  There is
+   no shortage of method names, so when an extension changes the basic
+   meaning of a request, a new method SHOULD be defined.
+
+   For extensions that define new header fields, the extension MUST
+   define the request methods the header field can appear in, and what
+   responses it can be used in.  It is RECOMMENDED that this information
+   be represented as a new row of Table 2/3 of RFC 3261 [2].  The table
+   MUST contain columns for all methods defined in standards-track RFCs
+   at the time of writing of the extension.
+
+4.12.  Additional Considerations for New Body Types
+
+   Because SIP can run over UDP, extensions that specify the inclusion
+   of large bodies (where large is several times the ethernet MTU) are
+   frowned upon unless end-to-end congestion controlled transport can be
+   guaranteed.  If at all possible, the content SHOULD be included
+   indirectly [9], even if congestion controlled transports are
+   available.
+
+   Note that the presence of a body MUST NOT change the nature of the
+   message.  That is, bodies cannot alter the state machinery associated
+   with processing a request of a particular method or a response.
+
+   Bodies enhance this processing by providing additional data.
+
+5.  Interactions with SIP Features
+
+   We have observed that certain capabilities of SIP continually
+   interact with extensions in unusual ways.  Writers of extensions
+   SHOULD consider the interactions of their extensions with these SIP
+   capabilities and document any unusual interactions, if they exist.
+   The following are the most common causes of problems:
+
+   Forking:  Forking by far presents the most troublesome interactions
+      with extensions.  This is generally because it can cause (1) a
+      single transmitted request to be received by an unknown number of
+      UASes, and (2) a single INVITE request to have multiple responses.
+
+   CANCEL and ACK:  CANCEL and ACK are "special" SIP requests, in that
+      they are exceptions to many of the general request processing
+      rules.  The main reason for this special status is that CANCEL and
+      ACK are always associated with another request.  New methods
+      SHOULD consider the meaning of cancellation, as described above.
+      Extensions that define new header fields in INVITE requests SHOULD
+      consider whether they also need to be included in ACK and CANCEL.
+      Frequently they do, in order to allow a stateless proxy to route
+      the CANCEL or ACK identically to the INVITE.
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 18]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   Routing:  The presence of Route header fields in a request can cause
+      it to be sent through intermediate proxies.  Requests that
+      establish dialogs can be record-routed, so that the initial
+      request goes through one set of proxies, and subsequent requests
+      through a different set.  These SIP features can interact in
+      unusual ways with extensions.
+
+   Stateless Proxies:  SIP allows a proxy to be stateless.  Stateless
+      proxies are unable to retransmit messages and cannot execute
+      certain services.  Extensions that depend on some kind of proxy
+      processing SHOULD consider how stateless proxies affect that
+      processing.
+
+   Dialog Usages: SIP allows for requests that normally create their own
+      dialog (such as SUBSCRIBE) to be used within a dialog created by
+      another method (such as INVITE).  In such a case, there are said
+      to be multiple usages of that dialog.  Extensions SHOULD consider
+      their interaction with dialog usages.  In particular, extensions
+      that define new error response codes SHOULD describe whether that
+      response code causes the dialog and all usages to terminate, or
+      just a specific usage.
+
+6.  Security Considerations
+
+   The nature of this document is such that it does not introduce any
+   new security considerations.  However, many of the principles
+   described in the document affect whether a potential SIP extension
+   design is likely to support the SIP security architecture.
+
+7.  Acknowledgements
+
+   The authors would like to thank Rohan Mahy and Spencer Dawkins for
+   their comments.  Robert Sparks contributed important text on CANCEL
+   issues.  Thanks to Allison Mankin for her support.
+
+8.  References
+
+8.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+        Session Initiation Protocol", RFC 3261, June 2002.
+
+   [3]  Alvestrand, H., "IETF Policy on Character Sets and Languages",
+        BCP 18, RFC 2277, January 1998.
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 19]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   [4]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+        Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
+        January 2005.
+
+   [5]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 4234, October 2005.
+
+   [6]  Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
+        Notification", RFC 3265, June 2002.
+
+   [7]  Camarillo, G., "The Internet Assigned Number Authority (IANA)
+        Header Field Parameter Registry for the Session Initiation
+        Protocol (SIP)", BCP 98, RFC 3968, December 2004.
+
+   [8]  Camarillo, G., "The Internet Assigned Number Authority (IANA)
+        Uniform Resource Identifier (URI) Parameter Registry for the
+        Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December
+        2004.
+
+   [9]  Burger, E., Ed., "A Mechanism for Content Indirection in Session
+        Initiation Protocol (SIP)  Messages", RFC 4483, May 2006.
+
+8.2.  Informative References
+
+   [10]  Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.
+         Rosen, "Change Process for the Session Initiation Protocol
+         (SIP)", BCP 67, RFC 3427, December 2002.
+
+   [11]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+         March 1997.
+
+   [12]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
+         Method", RFC 3515, April 2003.
+
+   [13]  Donovan, S. and J. Rosenberg, "Session Timers in the Session
+         Initiation Protocol (SIP)", RFC 4028, April 2005.
+
+   [14]  Sparks, R., "Problems Identified Associated with the Session
+         Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4321,
+         January 2006.
+
+   [15]  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.
+
+   [16]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
+         Protocol (RTSP)", RFC 2326, April 1998.
+
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 20]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+   [17]  Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
+         "SIP: Session Initiation Protocol", RFC 2543, March 1999.
+
+   [18]  Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
+         Payload Compression Protocol (IPComp)", RFC 3173, September
+         2001.
+
+   [19]  Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T.
+         Haukka, "Security Mechanism Agreement for the Session
+         Initiation Protocol (SIP)", RFC 3329, January 2003.
+
+   [20]  Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu,
+         Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC
+         3320, January 2003.
+
+   [21]  Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
+         Summers, "Session Initiation Protocol (SIP) Basic Call Flow
+         Examples", BCP 75, RFC 3665, December 2003.
+
+   [22]  Rosenberg, J., "A Session Initiation Protocol (SIP) Event
+         Package for Registrations", RFC 3680, March 2004.
+
+   [23]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
+         Responses in Session Initiation Protocol (SIP)", RFC 3262, June
+         2002.
+
+   [24]  Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
+         Method", RFC 3311, October 2002.
+
+   [25]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434, October
+         1998.
+
+   [26]  Reynolds, J. and R. Braden, "Instructions to Request for
+         Comments (RFC) Authors", Work in Progress, July 2004.
+
+   [27]  Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June
+         2005.
+
+   [28]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+         Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 21]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+Authors' Addresses
+
+   Jonathan Rosenberg
+   Cisco Systems
+   600 Lanidex Plaza
+   Parsippany, NJ  07054
+   US
+
+   Phone: +1 973 952-5000
+   EMail: jdrosen@cisco.com
+   URI:   http://www.jdrosen.net
+
+
+   Henning Schulzrinne
+   Columbia University
+   M/S 0401
+   1214 Amsterdam Ave.
+   New York, NY  10027
+   US
+
+   EMail: schulzrinne@cs.columbia.edu
+   URI:   http://www.cs.columbia.edu/~hgs
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 22]
+
+RFC 4485                     SIP Guidelines                     May 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   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 provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 23]
+