GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3841

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3841.txt · Last modified: 2004/08/12 16:03 (external edit)