doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc3841.txt b/doc/rfc/rfc3841.txt
new file mode 100644
index 0000000..605981d
--- /dev/null
+++ b/doc/rfc/rfc3841.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                       J. Rosenberg
+Request for Comments: 3841                                   dynamicsoft
+Category: Standards Track                                 H. Schulzrinne
+                                                     Columbia University
+                                                              P. Kyzivat
+                                                           Cisco Systems
+                                                             August 2004
+
+
+      Caller Preferences for the Session Initiation Protocol (SIP)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document describes a set of extensions to the Session Initiation
+   Protocol (SIP) which allow a caller to express preferences about
+   request handling in servers.  These preferences include the ability
+   to select which Uniform Resource Identifiers (URI) a request gets
+   routed to, and to specify certain request handling directives in
+   proxies and redirect servers.  It does so by defining three new
+   request header fields, Accept-Contact, Reject-Contact, and Request-
+   Disposition, which specify the caller's preferences.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 1]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   4.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  4
+   5.  UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . .  5
+       5.1.  Request Handling Preferences . . . . . . . . . . . . . .  6
+       5.2.  Feature Set Preferences  . . . . . . . . . . . . . . . .  6
+   6.  UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   7.  Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . .  9
+       7.1.  Request-Disposition Processing . . . . . . . . . . . . .  9
+       7.2.  Preference and Capability Matching . . . . . . . . . . .  9
+             7.2.1. Extracting Explicit Preferences . . . . . . . . . 10
+             7.2.2. Extracting Implicit Preferences . . . . . . . . . 10
+                    7.2.2.1. Methods. . . . . . . . . . . . . . . . . 10
+                    7.2.2.2. Event Packages . . . . . . . . . . . . . 11
+             7.2.3. Constructing Contact Predicates . . . . . . . . . 11
+             7.2.4. Matching. . . . . . . . . . . . . . . . . . . . . 12
+             7.2.5. Example . . . . . . . . . . . . . . . . . . . . . 16
+   8.  Mapping Feature Parameters to a Predicate. . . . . . . . . . . 17
+   9.  Header Field Definitions . . . . . . . . . . . . . . . . . . . 19
+       9.1.  Request Disposition  . . . . . . . . . . . . . . . . . . 20
+       9.2.  Accept-Contact and Reject-Contact Header Fields  . . . . 21
+   10. Augmented BNF  . . . . . . . . . . . . . . . . . . . . . . . . 22
+   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 22
+   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
+   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23
+   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+       14.1. Normative References . . . . . . . . . . . . . . . . . . 24
+       14.2. Informative References . . . . . . . . . . . . . . . . . 24
+   15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
+   16. Full Copyright Statements. . . . . . . . . . . . . . . . . . . 26
+
+1.  Introduction
+
+   When a Session Initiation Protocol (SIP) [1] server receives a
+   request, there are a number of decisions it can make regarding the
+   processing of the request.  These include:
+
+   o  whether to proxy or redirect the request
+
+   o  which URIs to proxy or redirect to
+
+   o  whether to fork or not
+
+   o  whether to search recursively or not
+
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 2]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   o  whether to search in parallel or sequentially
+
+   The server can base these decisions on any local policy.  This policy
+   can be statically configured, or can be based on execution of a
+   program or database access.
+
+   However, the administrator of the server is the not the only entity
+   with an interest in request processing.  There are at least three
+   parties which have an interest: (1) the administrator of the server,
+   (2) the user that sent the request, and (3) the user to whom the
+   request is directed.  The directives of the administrator are
+   embedded in the policy of the server.  The preferences of the user to
+   whom the request is directed (referred to as the callee, even though
+   the request method may not be INVITE) can be expressed most easily
+   through a script written in some type of scripting language, such as
+   the Call Processing Language (CPL) [11].  However, no mechanism
+   exists to incorporate the preferences of the user that sent the
+   request (also referred to as the caller, even though the request
+   method may not be INVITE).  For example, the caller might want to
+   speak to a specific user, but wants to reach them only at work,
+   because the call is a business call.  As another example, the caller
+   might want to reach a user, but not their voicemail, since it is
+   important that the caller talk to the called party.  In both of these
+   examples, the caller's preference amounts to having a proxy make a
+   particular routing choice based on the preferences of the caller.
+
+   This extension allows the caller to have these preferences met.  It
+   does so by specifying mechanisms by which a caller can provide
+   preferences on processing of a request.  There are two types of
+   preferences.  One of them, called request handling preferences, are
+   encapsulated in the Request-Disposition header field.  They provide
+   specific request handling directives for a server.  The other, called
+   feature preferences, is present in the Accept-Contact and Reject-
+   Contact header fields.  They allow the caller to provide a feature
+   set [2] that expresses its preferences on the characteristics of the
+   UA that is to be reached.  These are matched with a feature set
+   provided by a UA to its registrar [3].  The extension is very general
+   purpose, and not tied to a particular service.  Rather, it is a tool
+   that can be used in the development of many services.
+
+   One example of a service enabled by caller preferences is a "one
+   number" service.  A user can have a single identity (their SIP URI)
+   for all of their devices - their cell phone, PDA, work phone, home
+   phone, and so on.  If the caller wants to reach the user at their
+   business phone, they simply select "business phone" from a pull-down
+   menu of options when calling that URI.  Users would no longer need to
+   maintain and distribute separate identities for each device.
+
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 3]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+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 BCP 14, RFC 2119
+   [4] and indicate requirement levels for compliant implementations.
+
+3.  Definitions
+
+   Much of the terminology used in this specification is presented in
+   [3].  This specification defines the following additional terms:
+
+   Caller: Within the context of this specification, a caller refers to
+      the user on whose behalf a UAC is operating.  It is not limited to
+      a user whose UAC sends an INVITE request.
+
+   Feature Preferences: Caller preferences that describe desired
+      properties of a UA to which the request is to be routed.  Feature
+      preferences can be made explicit with the Accept-Contact and
+      Reject-Contact header fields.
+
+   Request Handling Preferences: Caller preferences that describe
+      desired request treatment at a server.  These preferences are
+      carried in the Request-Disposition header field.
+
+   Target Set: A target set is a set of candidate URIs to which a proxy
+      or redirect server can send or redirect a request.  Frequently,
+      target sets are obtained from a registration, but they need not
+      be.
+
+   Explicit Preference: A caller preference indicated explicitly in the
+      Accept-Contact or Reject-Contact header fields.
+
+   Implicit Preference: A caller preference that is implied through the
+      presence of other aspects of a request.  For example, if the
+      request method is INVITE, it represents an implicit caller
+      preference to route the request to a UA that supports the INVITE
+      method.
+
+4.  Overview of Operation
+
+   When a caller sends a request, it can optionally include new header
+   fields which request certain handling at a server.  These preferences
+   fall into two categories.  The first category, called request
+   handling preferences, is carried in the Request-Disposition header
+   field.  It describes specific behavior that is desired at a server.
+   Request handling preferences include whether the caller wishes the
+
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 4]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   server to proxy or redirect, and whether sequential or parallel
+   search is desired.  These preferences can be applied at every proxy
+   or redirect server on the call signaling path.
+
+   The second category of preferences, called feature preferences, is
+   carried in the Accept-Contact and Reject-Contact header fields.
+   These header fields contain feature sets, represented by the same
+   feature parameters that are used to indicate capabilities [3].  Here,
+   the feature parameters represent the caller's preferences.  The
+   Accept-Contact header field contains feature sets that describe UAs
+   that the caller would like to reach.  The Reject-Contact header field
+   contains feature sets which, if matched by a UA, imply that the
+   request should not be routed to that UA.
+
+   Proxies use the information in the Accept-Contact and Reject-Contact
+   header fields to select amongst contacts in their target set.  When
+   neither of those header fields are present, the proxy computes
+   implicit preferences from the request.  These are caller preferences
+   that are not explicitly placed into the request, but can be inferred
+   from the presence of other message components.  As an example, if the
+   request method is INVITE, this is an implicit preference to route the
+   call to a UA that supports the INVITE method.
+
+   Both request handling and feature preferences can appear in any
+   request, not just INVITE.  However, they are only useful in requests
+   where proxies need to determine a request target.  If the domain in
+   the request URI is not owned by any proxies along the request path,
+   those proxies will never access a location service, and therefore,
+   never have the opportunity to apply the caller preferences.  This
+   makes sense because typically, the request URI will identify a UAS
+   for mid-dialog requests.  In those cases, the routing decisions were
+   already made on the initial request, and it makes no sense to redo
+   them for subsequent requests in the dialog.
+
+5.  UAC Behavior
+
+   A caller wishing to express preferences for a request includes
+   Accept-Contact, Reject-Contact, or Request-Disposition header fields
+   in the request, depending on their particular preferences.  No
+   additional behavior is required after the request is sent.
+
+   The Accept-Contact, Reject-Contact, and Request-Disposition header
+   fields in an ACK for a non-2xx final response, or in a CANCEL
+   request, MUST be equal to the values in the original request being
+   acknowledged or cancelled.  This is to ensure proper operation
+   through stateless proxies.
+
+
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 5]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   If the UAC wants to determine whether servers along the path
+   understand the header fields described in this specification, it
+   includes a Proxy-Require header field with a value of "pref" [3] in
+   its request.  If the request should fail with a 420 response code,
+   the UAC knows that the extension is not supported.  In that case, it
+   SHOULD retry, and may decide whether or not to use caller
+   preferences.  A UA should only use Proxy-Require if knowledge about
+   support is essential for handling of the request.  Note that, in any
+   case, caller preferences can only be considered preferences - there
+   is no guarantee that the requested service will be executed.  As
+   such, inclusion of a Proxy-Require header field does not mean that
+   the preferences will be executed, just that the caller preferences
+   extension is understood by the proxies.
+
+5.1.  Request Handling Preferences
+
+   The Request-Disposition header field specifies caller preferences for
+   how a server should process a request.  Its value is a list of
+   tokens, each of which specifies a particular processing directive.
+
+   The syntax of the header field can be found in Section 10, and the
+   semantics of the directives are described in Section 9.1.
+
+5.2.  Feature Set Preferences
+
+   A UAC can indicate caller preferences for the capabilities of a UA
+   that should be reached or not reached as a result of sending a SIP
+   request.  To do that, it adds one or more Accept-Contact and Reject-
+   Contact header field values.  Each header field value contains a set
+   of feature parameters that define a feature set.  The syntax of the
+   header field can be found in Section 10, and a discussion of their
+   usage in Section 9.2.
+
+   Each feature set is constructed as described in Section 5 of [3].
+   The feature sets placed into these header fields MAY overlap; that
+   is, a UA MAY indicate preferences for feature sets that match
+   according to the matching algorithm of RFC 2533 [2].
+
+   A UAC can express explicit preferences for the methods and event
+   packages supported by a UA.  It is RECOMMENDED that a UA include a
+   term in an Accept-Contact feature set with the "sip.methods" feature
+   tag (note, however, that even though the name of this feature tag is
+   sip.methods, it would be encoded into the Accept-Contact header field
+   as just "methods"), whose value includes the method of the request.
+   When a UA sends a SUBSCRIBE request, it is RECOMMENDED that a UA
+   include a term in an Accept-Contact feature set with the "sip.events"
+   feature tag, whose value includes the event package of the request.
+   Whether these terms are placed into a new feature set, or whether
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 6]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   they are included in each feature set, is at the discretion of the
+   implementor.  In most cases, the right effect is achieved by
+   including a term in each feature set.
+
+   As an example, the following Accept-Contact header field expresses a
+   desire to route a call to a mobile device, using feature parameters
+   taken from [3]:
+
+   Accept-Contact: *;mobility="mobile";methods="INVITE"
+
+   The Reject-Contact header field allows the UAC to specify that a UA
+   should not be contacted if it matches any of the values of the header
+   field.  Each value of the Reject-Contact header field contains a "*",
+   purely to align the syntax with guidelines for SIP extensions [12],
+   and is parameterized by a set of feature parameters.  Any UA whose
+   capabilities match the feature set described by the feature
+   parameters matches the value.
+
+   The Accept-Contact header field allows the UAC to specify that a UA
+   should be contacted if it matches some or all of the values of the
+   header field.  Each value of the Accept-Contact header field contains
+   a "*", and is parameterized by a set of feature parameters.  Any UA
+   whose capabilities match the feature set described by the feature
+   parameters matches the value.  The precise behavior depends heavily
+   on whether the "require" and "explicit" parameters are present.  When
+   both of them are present, a proxy will only forward the request to
+   contacts which have explicitly indicated that they support the
+   desired feature set.  Any others are discarded.  As such, a UAC
+   should only use "require" and "explicit" together when it wishes the
+   call to fail unless a contact definitively matches.  It's possible
+   that a UA supports a desired feature, but did not indicate it in its
+   registration.  When a UAC uses both "explicit" and "require", such a
+   contact would not be reached.  As a result, this combination is often
+   not the one a UAC will want.
+
+   When only "require" is present, it means that a contact will not be
+   used if it doesn't match.  If it does match, or if it's not known
+   whether it's a complete match, the contact is still used.  A UAC
+   would use "require" alone when a non-matching contact is useless.
+   This is common for services where the request simply can't be
+   serviced without the necessary features.  An example is support for
+   specific methods or event packages.  When only "require" is present,
+   the proxy will also preferentially route the request to the UA which
+   represents the "best" match.  Here, "best" means that the UA has
+   explicitly indicated it supports more of the desired features than
+   any other. Note, however, that this preferential routing will never
+   override an ordering provided by the called party.  The preferential
+   routing will only choose amongst contacts of equal q-value.
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 7]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   When only "explicit" is present, it means that all contacts provided
+   by the callee will be used.  However, if the contact isn't an
+   explicit match, it is tried last amongst all other contacts with the
+   same q-value.  The principle difference, therefore, between this
+   configuration and the usage of both "require" and "explicit" is the
+   fallback behavior for contacts that don't match explicitly.  Here,
+   they are tried as a last resort.  If "require" is also present, they
+   are never tried.
+
+   Finally, if neither "require" nor "explicit" are present, it means
+   that all contacts provided by the callee will be used.  However, if
+   the contact doesn't match, it is tried last amongst all other
+   contacts with the same q-value.  If it does match, the request is
+   routed preferentially to the "best" match.  This is a common
+   configuration for preferences that, if not honored, will still allow
+   for a successful call, and the greater the match, the better.
+
+6.  UAS Behavior
+
+   When a UAS compliant to this specification receives a request whose
+   request-URI corresponds to one of its registered contacts, it SHOULD
+   apply the behavior described in Section 7.2 as if it were a proxy for
+   the domain in the request-URI.  The UAS acts as if its location
+   database contains a single request target for the request-URI.  That
+   target is associated with a feature set.  The feature set is the same
+   as the one placed in the registration of the URI in the request-URI.
+   If a UA had registered against multiple separate addresses-of-record,
+   and the contacts registered for each had different capabilities, it
+   will have used a different URI in each registration, so it can
+   determine which feature set to use.
+
+   This processing occurs after the client authenticates and authorizes
+   the request, but before the remainder of the general UAS processing
+   described in Section 8.2.1 of RFC 3261.
+
+   If, after performing this processing, there are no URI left in the
+   target set, the UA SHOULD reject the request with a 480 response.  If
+   there is a URI remaining (there was only one to begin with), the UA
+   proceeds with request processing as per RFC 3261.
+
+   Having a UAS perform the matching operations as if it were a proxy
+   allows certain caller preferences to be honored, even if the proxy
+   doesn't support the extension.
+
+   A UAS SHOULD process any queue directive present in a Request-
+   Disposition header field in the request.  All other directives MUST
+   be ignored.
+
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 8]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+7.  Proxy Behavior
+
+   Proxy behavior consists of two orthogonal sets of rules - one for
+   processing the Request-Disposition header field, and one for
+   processing the URI and feature set preferences in the Accept-Contact
+   and Reject-Contact header fields.
+
+   In addition to processing these headers, a proxy MAY add one if not
+   present, or add a value to an existing header field, as if it were a
+   UAC.  This is useful for a proxy to request processing in downstream
+   proxies in the implementation of a feature.  However, a proxy MUST
+   NOT modify or remove an existing header field value.  This is
+   particularly important when S/MIME is used.  The message signature
+   could include the caller preferences header fields, allowing the UAS
+   to verify that, even though proxies may have added header fields, the
+   original caller preferences were still present.
+
+7.1.  Request-Disposition Processing
+
+   If the request contains a Request-Disposition header field and it is
+   the owner of the domain in the Request URI, the server SHOULD execute
+   the directives as described in Section 9.1, unless it has local
+   policy configured to direct it otherwise.
+
+7.2.  Preference and Capability Matching
+
+   A proxy compliant to this specification MUST NOT apply the
+   preferences matching operation described here to a request unless it
+   is the owner of the domain in the request URI, and accessing a
+   location service that has capabilities associated with request
+   targets.  However, if it is the owner of the domain, and accessing a
+   location service that has capabilities associated with request
+   targets, it SHOULD apply the processing described in this section.
+   Typically, this is a proxy that is using a registration database to
+   determine the request targets.  However, if a proxy knows about
+   capabilities through some other means, it SHOULD apply the processing
+   defined here as well.  If it does perform the processing, it MUST do
+   so as described below.
+
+   The processing is described through a conversion from the syntax
+   described in this specification to RFC 2533 [2] syntax, followed by a
+   matching operation and a sorting of resulting contact values.  The
+   usage of RFC 2533 syntax as an intermediate step is not required; it
+   only serves as a useful tool to describe the behavior required of the
+   proxy.  A proxy can use any steps it likes, so long as the results
+   are identical to the ones that would be achieved with the processing
+   described here.
+
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 9]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+7.2.1.  Extracting Explicit Preferences
+
+   The first step in proxy processing is to extract explicit
+   preferences.  To do that, it looks for the Accept-Contact and
+   Reject-Contact header fields.
+
+   For each value of those header fields, it extracts the feature
+   parameters.  These are the header field parameters whose name is
+   "audio", "automata", "class", "duplex", "data", "control",
+   "mobility", "description", "events", "priority", "methods",
+   "extensions", "schemes", "application", "video", "language", "type",
+   "isfocus", "actor", or "text", or whose name begins with a plus (+)
+   [3].  The proxy converts all of those parameters to the syntax of RFC
+   2533, based on the rules in Section 8.
+
+   The result will be a set of feature set predicates in conjunctive
+   normal form, each of which is associated with one of the two
+   preference header fields.  If there was a req-parameter associated
+   with a header field value in the Accept-Contact header field, the
+   feature set predicate derived from that header field value is said to
+   have its require flag set.  Similarly, if there was an explicit-param
+   associated with a header field value in the Accept-Contact header
+   field, the feature set predicate derived from that header field value
+   is said to have its explicit flag set.
+
+7.2.2.  Extracting Implicit Preferences
+
+   If, and only if, the proxy did not find any explicit preferences in
+   the request (because there was no Accept-Contact or Reject-Contact
+   header field), the proxy extracts implicit preferences.  These
+   preferences are ones implied by the presence of other information in
+   the request.
+
+   First, the proxy creates a conjunction with no terms.  This
+   conjunction represents a feature set that will be associated with the
+   Accept-Contact header field, as if it were included there.  Note that
+   there is no modification of the message implied - only an association
+   for the purposes of processing.  Furthermore, this feature set has
+   its require flag set, but not its explicit flag.
+
+   The proxy then adds terms to the conjunction for the two implicit
+   preference types below.
+
+7.2.2.1.  Methods
+
+   One implicit preference is the method.  When a UAC sends a request
+   with a specific method, it is an implicit preference to have the
+   request routed only to UAs that support that method.  To support this
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 10]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   implicit preference, the proxy adds a term to the conjunction of the
+   following form:
+
+   (sip.methods=[method of request])
+
+7.2.2.2.  Event Packages
+
+   For requests that establish a subscription [5], the Event header
+   field is another expression of an implicit preference.  It expresses
+   a desire for the request to be routed only to a server that supports
+   the given event package.  To support this implicit preference, the
+   proxy adds a term to the conjunction of the following form:
+
+   (sip.events=[value of the Event header field])
+
+7.2.3.  Constructing Contact Predicates
+
+   The proxy then takes each URI in the target set (the set of URI it is
+   going to proxy or redirect to), and obtains its capabilities as an
+   RFC 2533 formatted feature set predicate.  This is called a contact
+   predicate.  If the target URI was obtained through a registration,
+   the proxy computes the contact predicate by extracting the feature
+   parameters from the Contact header field [3] and then converting them
+   to a feature predicate.  To extract the feature parameters, the proxy
+   follows these steps:
+
+   1. Create an initial, empty list of feature parameters.
+
+   2. If the Contact URI parameters included the "audio", "automata",
+      "class", "duplex", "data", "control", "mobility", "description",
+      "events", "priority", "methods", "schemes", "application",
+      "video", "actor", "language", "isfocus", "type", "extensions", or
+      "text" parameters, those are copied into the list.
+
+   3. If any Contact URI parameter name begins with a "+", it is copied
+      into the list if the list does not already contain that name with
+      the plus removed.  In other words, if the "video" feature
+      parameter is in the list, the "+video" parameter would not be
+      placed into the list.  This conflict should never arise if the
+      client were compliant to [3], since it is illegal to use the +
+      form for encoding of a feature tag in the base set.
+
+   If the URI in the target set had no feature parameters, it is said to
+   be immune to caller preference processing.  This means that the URI
+   is removed from the target set temporarily, the caller preferences
+   processing described below is executed, and then the URI is added
+   back in.
+
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 11]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   Assuming the URI has feature parameters, they are converted to RFC
+   2533 syntax using the rules of Section 8.
+
+   The resulting predicate is associated with a q-value.  If the contact
+   predicate was learned through a REGISTER request, the q-value is
+   equal to the q-value in the Contact header field parameter, else
+   "1.0" if not specified.
+
+   As an example, consider the following registered Contact header
+   field:
+
+     Contact: <sip:user@example.com>;audio;video;mobility="fixed";
+         +sip.message="TRUE";other-param=66372;
+         methods="INVITE,OPTIONS,BYE,CANCEL,ACK";schemes="sip,http"
+
+   This would be converted into the following predicate:
+
+      (& (sip.audio=TRUE)
+         (sip.video=TRUE)
+         (sip.mobility=fixed)
+         (sip.message=TRUE)
+         (| (sip.methods=INVITE) (sip.methods=OPTIONS) (sip.methods=BYE)
+            (sip.methods=CANCEL) (sip.methods=ACK))
+         (| (sip.schemes=sip) (sip.schemes=http)))
+
+   Note that "other-param" was not considered a feature parameter, since
+   it is neither a base tag nor did it begin with a leading +.
+
+7.2.4.  Matching
+
+   It is important to note that the proxy does not have to know anything
+   about the meaning of the feature tags that it is comparing in order
+   to perform the matching operation.  The rules for performing the
+   comparison depend on syntactic hints present in the values of each
+   feature tag.  For example, a predicate such as:
+
+   (foo>=4)
+
+   implies that the feature tag "foo" is a numeric value.  The matching
+   rules in RFC 2533 only require an implementation to know whether the
+   feature tag is a numeric, token, or quoted string (booleans can be
+   treated as tokens).  Quoted strings are always matched using a case-
+   sensitive matching operation.  Tokens are matched using case-
+   insensitive matching.  These two cases are differentiated by the
+   presence of angle brackets around the feature tag value.  When these
+   brackets are present (i.e., ;+sip.foo="<value>"), it implies case
+
+
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 12]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   sensitive string comparison.  When they are not present, (i.e.,
+   (;+sip.bar="val"), it implies case insensitivity.  Numerics are
+   matched using normal mathematical comparisons.
+
+   First, the proxy applies the predicates associated with the Reject-
+   Contact header field.
+
+   For each contact predicate, each Reject-Contact predicate (that is,
+   each predicate associated with the Reject-Contact header field) is
+   examined.  If that Reject-Contact predicate contains a filter for a
+   feature tag, and that feature tag is not present anywhere in the
+   contact predicate, that Reject-Contact predicate is discarded for the
+   processing of that contact predicate.  If the Reject-Contact
+   predicate is not discarded, it is matched with the contact predicate
+   using the matching operation of RFC 2533 [2].  If the result is a
+   match, the URI corresponding to that contact predicate is discarded
+   from the target set.
+
+   The result is that Reject-Contact will only discard URIs where the UA
+   has explicitly indicated support for the features that are not
+   wanted.
+
+   Next, the proxy applies the predicates associated with the Accept-
+   Contact header field.  For each contact that remains in the target
+   set, the proxy constructs a matching set, Ms.  Initially, this set
+   contains all of the Accept-Contact predicates.  Each of those
+   predicates is examined.  It is matched with the contact predicate
+   using the matching operation of RFC 2533 [2].  If the result is not a
+   match, and the Accept-Contact predicate had its require flag set, the
+   URI corresponding to that contact predicate is discarded from the
+   target set.  If the result is not a match, but the Accept-Contact
+   predicate did not have its require flag set, that contact URI is not
+   discarded from the target set, however, the Accept-Contact predicate
+   is removed from the matching set for that contact.
+
+   For each contact that remains in the target set, the proxy computes a
+   score for that contact against each predicate in the contact's
+   matching set.  Let the number of terms in the Accept-Contact
+   predicate conjunction be equal to N.  Each term in that predicate
+   contains a single feature tag.  If the contact predicate has a term
+   containing that same feature tag, the score is incremented by 1/N.
+   If the feature tag was not present in the contact predicate, the
+   score remains unchanged.  Based on these rules, the score can range
+   between zero and one.
+
+
+
+
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 13]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+                                                    T
+                                              +----------> DROP Contact
+                                              |
+                                              |
+                                             / \
+                                            /   \
+                                        T  /     \   F
+                                    +---->/require\------> Set score=0
+                                    |     \      /
+                                    |      \    /
+                                   / \      \  /
+                                  /   \      \/
+                       score<1   /     \
+                      +-------> /explicit----> Score unchanged
+                      |         \      /    F
+                      |          \    /
+                     / \          \  /
+                    /   \          \/
+    +--------+     /     \
+ -->|Compute |--> /Score  \ --------> Score unchanged
+    |  Score |    \      /  score=1
+    +--------+     \    /
+                    \  /
+                     \/
+
+   Figure 1: Applying the Score
+
+   The require and explicit tags are then applied, resulting in
+   potential modification of the score and the target set.  This process
+   is summarized in Figure 1.  If the score for the contact predicate
+   against that Accept-Contact predicate was less than one, the Accept-
+   Contact predicate had an explicit tag, and if the predicate also had
+   a require tag, the Contact URI corresponding to that contact
+   predicate is dropped.  If, however, the predicate did not have a
+   require tag, the score is set to zero.  If there was no explicit tag,
+   the score is unchanged.
+
+   The next step is to combine the scores and the q-values associated
+   with the predicates in the matching set, to arrive at an overall
+   caller preference, Qa.  For those URIs in the target set which
+   remain, there will be a score which indicates its match against each
+   Accept-Contact predicate in the matching set.  If there are M
+   Accept-Contact predicates in the matching set, there will be M scores
+   S1 through SM, for each contact.  The overall caller preference, Qa,
+   is the arithmetic average of S1 through SM.
+
+
+
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 14]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   At this point, any URIs that were removed from the target set because
+   they were immune from caller preferences are added back in, and Qa
+   for that URI is set to 1.0.
+
+   The purpose of the caller preference Qa is to provide an ordering for
+   any contacts remaining in the target set, if the callee has not
+   provided an ordering.  To do this, the contacts remaining in the
+   target set are sorted by the q-value provided by the callee.  Once
+   sorted, they are grouped into equivalence classes, such that all
+   contacts with the same q-value are in the same equivalence class.
+   Within each equivalence class, the contacts are then ordered based on
+   their values of Qa.  The result is an ordered list of contacts that
+   is used by the proxy.
+
+   If there were no URIs in the target set after the application of the
+   processing in this section, and the caller preferences were based on
+   implicit preferences (Section 7.2.2), the processing in this section
+   is discarded, and the original target set, ordered by their original
+   q-values, is used.
+
+      This handles the case where implicit preferences for the method or
+      event packages resulted in the elimination of all potential
+      targets.  By going back to the original target set, those URIs
+      will be tried, and result in the generation of a 405 or 489
+      response.  The UAC can then use this information to try again, or
+      report the error to the user.  Without reverting to the original
+      target set, the UAC would see a 480 response, and have no
+      knowledge of why their request failed.  Of course, the target set
+      can also be empty after the application of explicit preferences.
+      This will result in the generation of a 480 by the proxy.  This
+      behavior is acceptable, and indeed, desirable in the case of
+      explicit preferences.  When the caller makes an explicit
+      preference, it is agreeing that its request might fail because of
+      a preference mismatch.  One might try to return an error
+      indicating the capabilities of the callee, so that the caller
+      could perhaps try again.  However, doing so results in the leaking
+      of potentially sensitive information to the caller without
+      authorization from the callee, and therefore this specification
+      does not provide a means for it.
+
+   If a proxy server is recursing, it adds the Contact header fields
+   returned in the redirect responses to the target set, and re-applies
+   the caller preferences algorithm.
+
+   If the server is redirecting, it returns all entries in the target
+   set.  It assigns q-values to those entries so that the ordering is
+   identical to the ordering determined by the processing above.
+   However, it MUST NOT include the feature parameters for the entries
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 15]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   in the target set.  If it did, the upstream proxy server would apply
+   the same caller preferences once more, resulting in a double
+   application of those preferences.  If the redirect server does wish
+   to include the feature parameters in the Contact header field, it
+   MUST redirect using the original target set and original q-values,
+   before the application of caller preferences.
+
+7.2.5.  Example
+
+   Consider the following example, which is contrived but illustrative
+   of the various components of the matching process.  There are five
+   registered Contacts for sip:user@example.com.  They are:
+
+   Contact: sip:u1@h.example.com;audio;video;methods="INVITE,BYE";q=0.2
+   Contact: sip:u2@h.example.com;audio="FALSE";
+     methods="INVITE";actor="msg-taker";q=0.2
+   Contact: sip:u3@h.example.com;audio;actor="msg-taker";
+     methods="INVITE";video;q=0.3
+   Contact: sip:u4@h.example.com;audio;methods="INVITE,OPTIONS";q=0.2
+   Contact: sip:u5@h.example.com;q=0.5
+
+   An INVITE sent to sip:user@example.com contained the following caller
+   preferences header fields:
+
+   Reject-Contact: *;actor="msg-taker";video
+   Accept-Contact: *;audio;require
+   Accept-Contact: *;video;explicit
+   Accept-Contact: *;methods="BYE";class="business";q=1.0
+
+   There are no implicit preferences in this example, because explicit
+   preferences are provided.
+
+   The proxy first removes u5 from the target set, since it is immune
+   from caller preferences processing.
+
+   Next, the proxy processes the Reject-Contact header field.  It is a
+   match for all four remaining contacts, but only an explicit match for
+   u3.  That is because u3 is the only one that explicitly indicated
+   support for video, and explicitly indicated it is a message taker.
+   So, u3 gets discarded, and the others remain.
+
+   Next, each of the remaining three contacts is compared against each
+   of the three Accept-Contact predicates.  u1 is a match to all three,
+   earning a score of 1.0 for the first two predicates, and 0.5 for the
+   third (the methods feature tag was present in the contact predicate,
+   but the class tag was not).  u2 doesn't match the first predicate.
+   Because that predicate has a require tag, u2 is discarded.  u4
+   matches the first predicate, earning a score of 1.0.  u4 matches the
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 16]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   second predicate, but since the match is not explicit (the score is
+   0.0, in fact), the score is set to zero (it was already zero, so
+   nothing changes).  u4 does not match the third predicate.
+
+   At this point, u1 and u4 remain.  u1 matched all three Accept-Contact
+   predicates, so its matching set contains all three, with scores of 1,
+   1, and 0.5.  u4 matches the first two predicates, with scores of 1.0
+   and 0.0.  Qa for u1 is 0.83 and Qa for u4 is 0.5.  u5 is added back
+   in with a Qa of 1.0.
+
+   Next, the remaining contacts in the target set are sorted by q-value.
+   u5 has a value of 0.5, u1 has a q-value of 0.2 and so does u4.  There
+   are two equivalence classes.  The first has a q-value of 0.5, and
+   consists of just u5.  Since there is only one member of the class,
+   sorting within the class has no impact.  The second equivalence class
+   has a q-value of 0.2.  Within that class, the two contacts, u1 and
+   u4, are ordered based on their values of Qa.  u1 has a Qa of 0.83,
+   and u4, a Qa of 0.5.  Thus, u1 comes first, followed by u4.  The
+   resulting overall ordered set of contacts in the target set is u5,
+   u1, and then u4.
+
+8.  Mapping Feature Parameters to a Predicate
+
+   Mapping between feature parameters and a feature set predicate,
+   formatted according to the syntax of RFC 2533 [2], is trivial.  It is
+   just the opposite of the process described in Section 5 of [3].
+
+   Starting from a set of feature-param, the procedure is as follows.
+   Construct a conjunction.  Each term in the conjunction derives from
+   one feature-param.  If the feature-param has no value, it is
+   equivalent, in terms of the processing which follows, as if it had a
+   value of "TRUE".
+
+   If the feature-param value is a tag-value-list, the element of the
+   conjunction is a disjunction.  There is one term in the disjunction
+   for each tag-value in the tag-value-list.
+
+   Consider now the construction of a filter from a tag-value.  If the
+   tag-value starts with an exclamation mark (!), the filter is of the
+   form:
+
+   (! <filter from remainder>)
+
+   where "<filter from remainder>" refers to the filter that would be
+   constructed from the tag-value if the exclamation mark had not been
+   present.
+
+
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 17]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   If the tag-value starts with an octothorpe (#), the filter is a
+   numeric comparison.  The comparator is either =, >=, <=, or a range
+   based on the next characters in the phrase.  If the next characters
+   are =, >=, or <=, the filter is of the form:
+
+   (name comparator compare-value)
+
+   where name is the name of the feature parameter after it has been
+   decoded (see below), and the comparator is either =, >=, or <=
+   depending of the initial characters in the phrase.  If the remainder
+   of the text in the tag-value after the equal contains a decimal point
+   (implying a rational number), the decimal point is shifted right N
+   times until it is an integer, I.  Compare-value above is then set to
+   "I / 10**N", where 10**N is the result of computing the number 10 to
+   the Nth power.
+
+   If the value after the octothorpe is a number, the filter is a range.
+   The format of the filter is:
+
+      (name=<remainder>)
+
+   where "name" is the feature-tag after it has been decoded (see
+   below), and "<remainder>" is the remainder of the text in the tag-
+   value after the #, with any decimal numbers converted to a rational
+   form, and the colon replaced by a double dot (..).
+
+   If the tag-value does not begin with an octothorpe (it is a token-
+   nobang or boolean), the filter is of the form:
+
+      (name=tag-value)
+
+   where name is the feature-tag after it has been decoded (see below).
+
+   If the feature-param contains a string-value (based on the fact that
+   it begins with a left angle bracket ("<") and ends with a right angle
+   bracket (">")), the filter is of the form:
+
+      (name="qdtext")
+
+   Note the explicit usage of quotes around the qdtext, which indicate
+   that the value is a string.  In RFC 2533, strings are compared using
+   case sensitive rules, and tokens are compared using case insensitive
+   rules.
+
+   Feature tags, as specified in RFC 2506 [13], cannot be directly
+   represented as header field parameters in the Contact, Accept-
+   Contact, and Reject-Contact header fields.  This is due to an
+   inconsistency in the grammars, and in the need to differentiate
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 18]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   feature parameters from parameters used by other extensions.  As
+   such, feature tag values are encoded from RFC 2506 format to yield an
+   enc-feature-tag, and then are decoded into RFC 2506 format.  The
+   decoding process is simple.  If there is a leading plus (+) sign, it
+   is removed.  Any exclamation point (!) is converted to a colon (:)
+   and any single quote (') is converted to a forward slash (/).  If
+   there was no leading plus sign, and the remainder of the encoded name
+   was "audio", "automata", "class", "duplex", "data", "control",
+   "mobility", "description", "events", "priority", "methods",
+   "schemes", "application", "video", "actor", "isfocus", "extensions"
+   or "text", the prefix "sip." is added to the remainder of the encoded
+   name to compute the feature tag name.
+
+   As an example, the Accept-Contact header field:
+
+      Accept-Contact:*;mobility="fixed"
+        ;events="!presence,message-summary"
+        ;language="en,de";description="<PC>";+sip.newparam
+        ;+rangeparam="#-4:+5.125"
+
+   would be converted to the following feature predicate:
+
+         (& (sip.mobility=fixed)
+            (| (! (sip.events=presence)) (sip.events=message-summary))
+            (| (language=en) (language=de))
+            (sip.description="PC")
+            (sip.newparam=TRUE)
+            (rangeparam=-4..5125/1000))
+
+9.  Header Field Definitions
+
+   This specification defines three new header fields - Accept-Contact,
+   Reject-Contact, and Request-Disposition.
+
+   Figure 2 and Figure 3 are an extension of Tables 2 and 3 in RFC 3261
+   [1] for the Accept-Contact, Reject-Contact, and Request-Disposition
+   header fields.  The column "INF" is for the INFO method [6], "PRA" is
+   for the PRACK method [7], "UPD" is for the UPDATE method [8], "SUB"
+   is for the SUBSCRIBE method [5], "NOT" is for the NOTIFY method [5],
+   "MSG" is for the MESSAGE method [9], and "REF" is for the REFER
+   method [10].
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 19]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   Header field          where  proxy  ACK BYE CAN INV OPT REG
+
+   Accept-Contact          R      ar    o   o   o   o   o   -
+   Reject-Contact          R      ar    o   o   o   o   o   -
+   Request-Disposition     R      ar    o   o   o   o   o   o
+
+   Figure 2: Accept-Contact, Reject-Contact, and Request-Disposition
+             header fields
+
+   Header field          where  proxy  PRA UPD SUB NOT INF MSG REF
+
+   Accept-Contact          R      ar    o   o   o   o   o   o   o
+   Reject-Contact          R      ar    o   o   o   o   o   o   o
+   Request-Disposition     R      ar    o   o   o   o   o   o   o
+
+   Figure 3: Accept-Contact, Reject-Contact, and Request-Disposition
+             header fields
+
+9.1.  Request Disposition
+
+   The Request-Disposition header field specifies caller preferences for
+   how a server should process a request.  Its value is a list of
+   tokens, each of which specifies a particular directive.  Its syntax
+   is specified in Section 10.  Note that a compact form, using the
+   letter d, has been defined.  The directives are grouped into types.
+   There can only be one directive of each type per request (e.g., you
+   cannot have both "proxy" and "redirect" in the same Request-
+   Disposition header field).
+
+   When the caller specifies a directive, the server SHOULD honor that
+   directive.
+
+   The following types of directives are defined:
+
+   proxy-directive: This type of directive indicates whether the caller
+      would like each server to proxy ("proxy") or redirect
+      ("redirect").
+
+   cancel-directive: This type of directive indicates whether the caller
+      would like each proxy server to send a CANCEL request downstream
+      ("cancel") in response to a 200 OK from the downstream server
+      (which is the normal mode of operation, making it redundant), or
+      whether this function should be left to the caller ("no-cancel").
+      If a proxy receives a request with this parameter set to "no-
+      cancel", it SHOULD NOT CANCEL any outstanding branches upon
+      receipt of a 2xx.  However, it would still send CANCEL on any
+      outstanding branches upon receipt of a 6xx.
+
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 20]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   fork-directive: This type of directive indicates whether a proxy
+      should fork a request ("fork"), or proxy to only a single address
+      ("no-fork").  If the server is requested not to fork, the server
+      SHOULD proxy the request to the "best" address (generally the one
+      with the highest q-value).  If there are multiple addresses with
+      the highest q-value, the server chooses one based on its local
+      policy.  The directive is ignored if "redirect" has been
+      requested.
+
+   recurse-directive: This type of directive indicates whether a proxy
+      server receiving a 3xx response should send requests to the
+      addresses listed in the response ("recurse"), or forward the list
+      of addresses upstream towards the caller ("no-recurse").  The
+      directive is ignored if "redirect" has been requested.
+
+   parallel-directive: For a forking proxy server, this type of
+      directive indicates whether the caller would like the proxy server
+      to proxy the request to all known addresses at once ("parallel"),
+      or go through them sequentially, contacting the next address only
+      after it has received a non-2xx or non-6xx final response for the
+      previous one ("sequential").  The directive is ignored if
+      "redirect" has been requested.
+
+   queue-directive: If the called party is temporarily unreachable,
+      e.g., because it is in another call, the caller can indicate that
+      it wants to have its call queued ("queue") or rejected immediately
+      ("no-queue").  If the call is queued, the server returns "182
+      Queued".  A queued call can be terminated as described in [1].
+
+   Example:
+
+      Request-Disposition: proxy, recurse, parallel
+
+   The set of request disposition directives is not extensible on
+   purpose.  This is to avoid a proliferation of new extensions to SIP
+   that are "tunneled" through this header field.
+
+9.2.  Accept-Contact and Reject-Contact Header Fields
+
+   The syntax for these header fields is described in Section 10.  A
+   compact form, with the letter a, has been defined for the Accept-
+   Contact header field, and with the letter j for the Reject-Contact
+   header field.
+
+
+
+
+
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 21]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+10.  Augmented BNF
+
+   The BNF for the Request-Disposition header field is:
+
+   Request-Disposition   =   ( "Request-Disposition" / "d" ) HCOLON
+                             directive *(COMMA directive)
+   directive             =   proxy-directive / cancel-directive /
+                             fork-directive / recurse-directive /
+                             parallel-directive / queue-directive
+   proxy-directive       =  "proxy" / "redirect"
+   cancel-directive      =  "cancel" / "no-cancel"
+   fork-directive        =  "fork" / "no-fork"
+   recurse-directive     =  "recurse" / "no-recurse"
+   parallel-directive    =  "parallel" / "sequential"
+   queue-directive       =  "queue" / "no-queue"
+
+   The BNF for the Accept-Contact and Reject-Contact header fields is:
+
+   Accept-Contact  =  ("Accept-Contact" / "a") HCOLON ac-value
+                      *(COMMA ac-value)
+   Reject-Contact  =  ("Reject-Contact" / "j") HCOLON rc-value
+                      *(COMMA rc-value)
+   ac-value        =  "*" *(SEMI ac-params)
+   rc-value        =  "*" *(SEMI rc-params)
+   ac-params       =  feature-param / req-param
+                         / explicit-param / generic-param
+                       ;;feature param from RFC 3840
+                       ;;generic-param from RFC 3261
+   rc-params       =  feature-param / generic-param
+   req-param       =  "require"
+   explicit-param  =  "explicit"
+
+   Despite the BNF, there MUST NOT be more than one req-param or
+   explicit-param in an ac-params.  Furthermore, there can only be one
+   instance of any feature tag in feature-param.
+
+11.  Security Considerations
+
+   The presence of caller preferences in a request has an effect on the
+   ways in which the request is handled at a server.  As a result,
+   requests with caller preferences SHOULD be integrity-protected with
+   the sips mechanism specified in RFC 3261, Section 26.
+
+   Processing of caller preferences requires set operations and searches
+   which can require some amount of computation.  This enables a DOS
+   attack whereby a user can send requests with substantial numbers of
+
+
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 22]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+   caller preferences, in the hopes of overloading the server.  To
+   counter this, servers SHOULD reject requests with too many rules.  A
+   reasonable number is around 20.
+
+12.  IANA Considerations
+
+   This specification registers three new SIP header fields, according
+   to the process of RFC 3261 [1].
+
+   The following is the registration for the Accept-Contact header
+   field:
+
+   RFC Number: RFC 3841
+
+   Header Field Name: Accept-Contact
+
+   Compact Form: a
+
+   The following is the registration for the Reject-Contact header
+   field:
+
+   RFC Number: RFC 3841
+
+   Header Field Name: Reject-Contact
+
+   Compact Form: j
+
+   The following is the registration for the Request-Disposition header
+   field:
+
+   RFC Number: RFC 3841
+
+   Header Field Name: Request-Disposition
+
+   Compact Form: d
+
+13.  Acknowledgments
+
+   The initial set of media feature tags used by this specification were
+   influenced by Scott Petrack's CMA design.  Jonathan Lennox, Bob
+   Penfield, Ben Campbell, Mary Barnes, Rohan Mahy, and John Hearty
+   provided helpful comments.  Graham Klyne provided assistance on the
+   usage of RFC 2533.
+
+
+
+
+
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 23]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+14.  References
+
+14.1.  Normative References
+
+   [1]   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.
+
+   [2]   Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
+         2533, March 1999.
+
+   [3]   Rosenberg, J., Schulzrinne, J., and P. Kyzivat, "Indicating
+         User Agent Capabilities in the Session Initiation Protocol
+         (SIP)", RFC 3840, August 2004.
+
+   [4]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [5]   Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
+         Notification", RFC 3265, June 2002.
+
+   [6]   Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
+
+   [7]   Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
+         Responses in Session Initiation Protocol (SIP)", RFC 3262, June
+         2002.
+
+   [8]   Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
+         Method", RFC 3311, October 2002.
+
+   [9]   Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C.,
+         and D. Gurle, "Session Initiation Protocol (SIP) Extension for
+         Instant Messaging", RFC 3428, December 2002.
+
+   [10]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
+         Method", RFC 3515, April 2003.
+
+14.2.  Informative References
+
+   [11]  Lennox, J. and H. Schulzrinne, "Call Processing Language
+         Framework and Requirements", RFC 2824, May 2000.
+
+   [12]  Rosenberg, J., "Guidelines for Authors of Extensions to the
+         Session Initiation Protocol  (SIP)", Work in Progress, November
+         2002.
+
+   [13]  Holtman, K., Muntz, A., and T. Hardie, "Media Feature Tag
+         Registration Procedure", BCP 31, RFC 2506, March 1999.
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 24]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+15.  Authors' Addresses
+
+   Jonathan Rosenberg
+   dynamicsoft
+   600 Lanidex Plaza
+   Parsippany, NJ  07054
+   US
+
+   Phone: +1 973 952-5000
+   EMail: jdrosen@dynamicsoft.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
+
+
+   Paul Kyzivat
+   Cisco Systems
+   1414 Massachusetts Avenue
+   BXB500 C2-2
+   Boxboro, MA  01719
+   US
+
+   EMail: pkyzivat@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 25]
+
+RFC 3841               Caller Preferences for SIP            August 2004
+
+
+16.  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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 26]
+