Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)
RFC 3840

Rosenberg, et al.           Standards Track                    [Page 31]
RFC 3840                    SIP Capabilities                 August 2004

   [13]  Rosenberg, J., "A Framework for Conferencing with the Session
         Initiation Protocol", Work in Progress, May 2003.

   [14]  Howes, T. and M. Smith, "LDAP: String Representation of Search
         Filters", Work in Progress, March 2003.

   [15]  Peterson, J., "Enhancements for Authenticated Identity
         Management in the Session  Initiation Protocol (SIP)", Work in
         Progress, March 2003.

   [16]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
         D. Gurle, "Session Initiation Protocol (SIP) Extension for
         Instant Messaging", RFC 3428, December 2002.

   [17]  Klyne, G., "Protocol-independent Content Negotiation
         Framework", RFC 2703, September 1999.

   [18]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434, October
         1998.

Rosenberg, et al.           Standards Track                    [Page 32]
RFC 3840                    SIP Capabilities                 August 2004

Appendix A. Overview of RFC 2533

   This section provides a brief overview of RFC 2533 and related
   specifications that form the content negotiation framework.  This
   section does not represent normative behavior.  In the event of any
   conflict between the tutorial material here and the normative text in
   RFC 2533, RFC 2533 takes precedence.

   A critical concept in the framework is that of a feature set.  A
   feature set is information about an entity (in our case, a UA), which
   describes a set of features it can handle.  A feature set can be
   thought of as a region in N-dimensional space.  Each dimension in
   this space is a different media feature, identified by a media
   feature tag.  For example, one dimension (or axis) might represent
   languages, another might represent methods, and another, MIME types.
   A feature collection represents a single point in this space.  It
   represents a particular rendering or instance of an entity (in our
   case, a UA).  For example, a "rendering" of a UA would define an
   instantaneous mode of operation that it can support.  One such
   rendering would be processing the INVITE method, which carried the
   application/sdp MIME type, sent to a UA for a user that is speaking
   English.

   A feature set can therefore be defined as a set of feature
   collections.  In other words, a feature set is a region of N-
   dimensional feature-space, that region being defined by the set of
   points - feature collections - that make up the space.  If a
   particular feature collection is in the space, it means that the
   rendering described by that feature collection is supported by the
   device with that feature set.

   How does one represent a feature set?  There are many ways to
   describe an N-dimensional space.  One way is to identify mathematical
   functions which identify its contours.  Clearly, that is too complex
   to be useful.  The solution taken in RFC 2533 is to define the space
   with a feature set predicate.  A feature predicate defines a relation
   over an N-dimensional space; its input is any point in that space
   (i.e., a feature collection), and is true for all points that are in
   the region thus defined.

   RFC 2533 describes a syntax for writing down these N-dimensional
   boolean functions, borrowed from LDAP [14].  It uses a prolog-style
   syntax which is fairly self-explanatory.  This representation is
   called a feature set predicate.  The base unit of the predicate is a
   filter, which is a boolean expression encased in round brackets.  A
   filter can be complex, where it contains conjunctions and

Rosenberg, et al.           Standards Track                    [Page 33]
RFC 3840                    SIP Capabilities                 August 2004

   disjunctions of other filters, or it can be simple.  A simple filter
   is one that expresses a comparison operation on a single media
   feature tag.

   For example, consider the feature set predicate:

      (& (foo=A)
         (bar=B)
         (| (baz=C) (& (baz=D) (bif=E))))

   This defines a function over four media features - foo, bar, baz, and
   bif.  Any point in feature space with foo equal to A, bar equal to B,
   and baz equal to either C or D, and bif equal to E, is in the feature
   set defined by this feature set predicate.

   Note that the predicate doesn't say anything about the number of
   dimensions in feature space.  The predicate operates on a feature
   space of any number of dimensions, but only those dimensions labeled
   foo, bar, baz, and bif matter.  The result is that values of other
   media features don't matter.  The feature collection
   {foo=A,bar=B,baz=C,bop=F} is in the feature set described by the
   predicate, even though the media feature tag "bop" isn't mentioned.
   Feature set predicates are therefore inclusive by default.  A feature
   collection is present unless the boolean predicate rules it out.
   This was a conscious design choice in RFC 2533.

   RFC 2533 also talks about matching a preference with a capability
   set.  This is accomplished by representing both with a feature set.
   A preference is a feature set - its a specification of a number of
   feature collections, any one of which would satisfy the requirements
   of the sender.  A capability is also a feature set - its a
   specification of the feature collections that the recipient supports.
   There is a match when the spaces defined by both feature sets
   overlap.  When there is overlap, there exists at least one feature
   collection that exists in both feature sets, and therefore a modality
   or rendering desired by the sender which is supported by the
   recipient.

   This leads directly to the definition of a match.  Two feature sets
   match if there exists at least one feature collection present in both
   feature sets.

   Computing a match for two general feature set predicates is not easy.
   Section 5 of RFC 2533 presents an algorithm for doing it by expanding
   an arbitrary expression into disjunctive normal form.  However, the
   feature set predicates used by this specification are constrained.
   They are always in conjunctive normal form, with each term in the
   conjunction describing values for different media features.  This

Rosenberg, et al.           Standards Track                    [Page 34]
RFC 3840                    SIP Capabilities                 August 2004

   makes computation of a match easy.  It is computed independently for
   each media feature, and then the feature sets overlap if media
   features specified in both sets overlap.  Computing the overlap of a
   single media feature is very straightforward, and is a simple matter
   of computing whether two finite sets overlap.

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 35]
RFC 3840                    SIP Capabilities                 August 2004

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 36]