Network Working Group                                             J. Lee
Internet-Draft                                            H. Schulzrinne
Intended status: Standards Track                             Columbia U.
Expires: August 28, 2007                               February 24, 2007


                 SIP URI Service Discovery using DNS-SD
                      draft-lee-sip-dns-sd-uri-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 28, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Lee & Schulzrinne        Expires August 28, 2007                [Page 1]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


Abstract

   This document describes the Session Initiation Protocol Uniform
   Resource Identifier (SIP URI) advertisement for DNS-based Service
   Discovery (DNS-SD).  Using this mechanism, a SIP user agent (UA) can
   communicate with another UA even when no SIP registrar is available,
   as in a wireless ad-hoc network for example.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  5
   3.  SIP URI Service Instance Name  . . . . . . . . . . . . . . . .  6
   4.  TXT Record Attributes  . . . . . . . . . . . . . . . . . . . .  8
     4.1.  txtvers  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  name . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  contact  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  User Agent Behavior  . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Request-URI and "To" header  . . . . . . . . . . . . . . . 10
     5.2.  Request Destination  . . . . . . . . . . . . . . . . . . . 10
   6.  User Interface Guidelines  . . . . . . . . . . . . . . . . . . 11
   7.  Transport Protocol in Service Instance Name  . . . . . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17























Lee & Schulzrinne        Expires August 28, 2007                [Page 2]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


1.  Introduction

   The Session Initiation Protocol (SIP) [RFC3261] is a comprehensive
   application-layer protocol for controlling multimedia sessions such
   as voice-over-IP calls.  A SIP Uniform Resource Identifier (SIP URI)
   represents who to contact or where to place a call in SIP
   communications.  For example, sip:carol@chicago.com is a SIP URI for
   Carol's logical identity.  Such a SIP URI is called an Address-of-
   Record (AOR).  Another example is sip:carol@cube2214a.chicago.com,
   which indicates the specific host where Carol can be reached at the
   moment.

   Given an AOR, SIP offers a way to discover the SIP URI for the
   physical contact location (Section 10, [RFC3261]).  This is achieved
   by introducing two SIP network elements, registrar and proxy server,
   that cooperatively manage the AOR-to-contact-URI bindings.  Using the
   examples above, Carol registers sip:carol@cube2214a.chicago.com as
   the current contact location for sip:carol@chicago.com using the
   registrar for the chicago.com domain.  When the proxy server for the
   chicago.com domain receives a call request for sip:carol@chicago.com,
   it looks up the binding and routes the request to
   cube2214a.chicago.com.

   However, this mechanism may not be applicable in some situations.
   Consider, for example, a wireless ad-hoc network that is formed for a
   short period of time.  In this case, routing calls using the SIP
   servers is clearly impractical.  What is needed here is a mechanism
   for the SIP UAs in the network to discover each other's URIs without
   relying on the functionality provided by the SIP registrar and proxy.

   This document proposes a way to discover SIP URIs without SIP servers
   using DNS-based Service Discovery (DNS-SD)
   [I-D.cheshire-dnsext-dns-sd].  DNS-SD specifies a set of rules for
   naming and structuring standard DNS records of certain types (SRV,
   TXT and PTR record types in particular).  The resulting system builds
   a service discovery protocol on top of the existing DNS protocol
   without modifying the core DNS protocol.  This makes it possible to
   deploy DNS-SD using the current unicast DNS software implementations.
   The later sections of this document establish the DNS-SD naming
   structure for SIP URIs and specifies the behavior of a SIP user agent
   (UA) processing such a service instance.

   Multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] often
   accompanies DNS-SD. mDNS runs on every host in a local link and it
   sends queries and responses via multicast.  The mDNS instances
   running on each host in a local link form a self-organizing cluster,
   collectively providing the functionality of a conventional unicast
   DNS server.  DNS-SD is compatible with mDNS (but it does not depend



Lee & Schulzrinne        Expires August 28, 2007                [Page 3]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


   on it.)  Furthermore, since DNS-SD and mDNS together satisfy the
   naming and service discovery requirements of Zero Configuration
   Networking [I-D.ietf-zeroconf-reqts], DNS-SD/mDNS implementations are
   widespread today (Section 21, [I-D.cheshire-dnsext-dns-sd]).

   It should be noted that the DNS-SD mechanism described in this
   document and the SIP server mechanism in [RFC3261] are not mutually
   exclusive.  Implementing the SIP URI discovery via DNS-SD will merely
   augment the functionality of a SIP UA, making it more useful in an
   ad-hoc network where the SIP servers are unavailable.  Section
   Section 6 discusses how such enhancements can be presented to the
   user.

   This document describes the advertisement and discovery of the SIP
   URIs only.  The discovery methods of other SIP resources are beyond
   the scope of this specification.



































Lee & Schulzrinne        Expires August 28, 2007                [Page 4]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Lee & Schulzrinne        Expires August 28, 2007                [Page 5]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


3.  SIP URI Service Instance Name

   Section 4.1 of [I-D.cheshire-dnsext-dns-sd] specifies that a service
   instance name in DNS-SD has the following structure:

      <Instance> . <Service> . <Domain>

   The <Domain> portion specifies the DNS sub-domain where the service
   instance is registered.  It may be "local.", indicating the mDNS
   local domain, or it may be a conventional domain name such as
   "example.com.".

   The <Service> portion of the SIP URI service instance name MUST be
   "_sipuri._udp", "_sipuri._tcp", or "_sipuri._sctp", depending on the
   transport protocol desired by the UA advertising the service
   instance.  If a UA supports multiple protocols, it SHOULD advertise
   multiple service instances.  Note that, while this usage with the
   protocol part is in agreement with DNS SRV RR definition ([RFC2782])
   and with the previous usage of SRV RR in SIP (Section 4.1,
   [RFC3263]), it does not agree with the DNS-SD guideline.  This is
   discussed further in Section 7.

   The <Instance> portion is a DNS label, containing UTF-8-encoded text,
   limited to 63 octets in length.  It is meant to be a user-friendly
   description of the service instance, suitable for a menu-like user
   interface display.  Thus it can contain any characters including
   spaces, punctuation, and non-Latin characters as long as they can be
   encoded in UTF-8.

   For the SIP URI service instance, however, there is a required
   format.  The <Instance> portion of the SIP URI service instance MUST
   start with a valid SIP or SIPS URI, optionally followed by a space
   character and an arbitrary text further describing the URI.  In
   Augmented BNF (ABNF) [RFC2234], this is expressed as follows:

      instance = ( SIP-URI / SIPS-URI ) [ SP description ]

   The definition and the ABNF for SIP-URI and SIPS-URI are given in
   Section 19.1 and Section 25.1 of [RFC3261].  SP denotes a space
   character and "description" is an arbitrary UTF-8-encoded text
   string.  The entire instance string cannot be more than 63 octets in
   length.

   For example, the SIP URI service instance names for Bob's two SIP
   devices may be:

      sip:bob@example.com - Softphone._sipuri._udp.local.




Lee & Schulzrinne        Expires August 28, 2007                [Page 6]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


      sip:bob@example.com - PDA._sipuri._udp.local.

   This scheme is also compatible with the automatic name conflict
   resolution of Apple's mDNS implementation, which appends a numerical
   suffix such as " (2)" to a name in order to distinguish it from
   another instance with the same name.  If both of Bob's devices
   advertise themselves as "sip:bob@example.com" in such an environment,
   the resulting service instance names will be:

      sip:bob@example.com._sipuri._udp.local.

      sip:bob@example.com (2)._sipuri._udp.local.

   Both are valid SIP URI service instance names.

   The reason for requiring that the instance name begins with a valid
   SIP URI is that having a SIP URI available in the name makes the
   service advertisement contain sufficient information for a UA to
   initiate a call.  The UA resolves the service instance name and
   obtains the IP address and the port number.  (This is done by issuing
   an SRV query.  See Section 5, [I-D.cheshire-dnsext-dns-sd].)  Then it
   can send a SIP request using the SIP URI from the service name as the
   Request-URI.  This makes the information from the TXT record
   (described in the next section) optional, in accordance with the
   recommendation that the TXT record should be viewed as a performance
   optimization (Section 6.2, [I-D.cheshire-dnsext-dns-sd]).

   The SIP or SIPS URI in the service instance name SHOULD be an
   Address-of-Record (AOR).  It is conceivable that a UA may not be
   configured with an AOR.  A group of UAs in an ad-hoc network may be
   configured only with user names, for example.  In such cases, the UA
   host names or IP addresses may be used to form a valid SIP URI for
   service advertisement.


















Lee & Schulzrinne        Expires August 28, 2007                [Page 7]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


4.  TXT Record Attributes

   In addition to the service instance name, IP address and the port
   number, DNS-SD provides a way to publish other information pertinent
   to the service being advertised.  The additional data can be stored
   as name/value attributes in a TXT record with the same name as the
   SRV record for the service.  Each name/value pair within the TXT
   record is preceded by a single length byte, thereby limiting the
   length of the pair to 255 bytes.  (See Section 6 of
   [I-D.cheshire-dnsext-dns-sd] and Section 3.3.14 of [RFC1035] for
   detail.)

   The following subsections describe the attributes defined for the SIP
   URI service.  Note that, while the presence of any of these
   attributes in a SIP URI advertisement is optional, the presence of
   certain attributes affects the behavior of the UA processing the
   service instance.  (See Section 5 for detail.)

4.1.  txtvers

   This is the version number of the TXT record specification as
   recommended in Section 6.7, [I-D.cheshire-dnsext-dns-sd].  If
   present, this attribute MUST be the first name/value pair in the TXT
   record.  For this specification, it MUST be "txtvers=1".

4.2.  name

   This is the display name of the user.  For example, "name=John Doe".

   It MUST conform to the "display-name" ABNF element in Section 25.1,
   [RFC3261], so that it can be used in the "To" SIP header, as in "To:
   John Doe <sip:john@example.com>".

4.3.  contact

   This attribute contains a SIP or SIPS URI that represents a direct
   route to the user.  The URI usually contains a fully qualified domain
   name (FQDN) or an IP address indicating the physical contact location
   of the user.  For example, "contact=sip:carol@cube2214a.chicago.com".

   Note that, while this attribute is the same in semantics as the
   "Contact" SIP header, the attribute does not allow the full syntax of
   the SIP header.  First, only SIP or SIPS URIs are allowed in the
   attribute, whereas non-SIP URIs are allowed in the Contact header.
   Non-SIP URIs are not applicable in the SIP URI service discovery.
   Second, the attribute can contain only a single URI, whereas the
   Contact header can contain multiple URIs in a comma-separated list.
   We argue that multiple contact locations can (and should) be



Lee & Schulzrinne        Expires August 28, 2007                [Page 8]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


   advertised as multiple service instances.

   [RFC3261] also defines two Contact parameters "q" and "expires".  The
   "q" parameter is only applicable when there are multiple Contact
   locations.  The "expires" parameter is also not relevant in this
   environment since the service instance must be created and removed
   according to the rules of the underlying service discovery system.

   The attribute name/value pair has the following syntax ABNF:

      contact-attr  =  "contact="
                       ( name-addr / uri ) *( SEMI contact-extension )
      name-addr     =  [ display-name ] LAQUOT uri RAQUOT
      uri           =  SIP-URI / SIPS-URI

   SEMI, LAQUOT and RAQUOT denote ";", "<" and ">", respectively.  Note
   that whitespace is often allowed around these characters.  See
   Section 25.1 of [RFC3261] for the precise definitions of these
   elements as well as those of contact-extension and display-name.

   The attribute syntax allows one or more contact-extension elements,
   which are generic name/value parameter provisions for future
   extensions.  Currently, [RFC3840] defines a mechanism by which SIP
   UAs can exchange information about their capabilities and
   characteristics through these parameters.  Such a mechanism is
   particularly germane to service discovery.

























Lee & Schulzrinne        Expires August 28, 2007                [Page 9]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


5.  User Agent Behavior

   This section specifies the behavior of the UA that sends a SIP
   request using the discovered SIP URI service instance.  In
   particular, it specifies how to form the Request-URI and the "To"
   header of the request, and how to determine the destination host to
   which the SIP request should be transported.  Beyond that, Section
   8.1 and 18.1 of [RFC3261] describe in detail the behavior of a UA
   generating and sending a SIP request.

5.1.  Request-URI and "To" header

   The Request-URI and the "To" header MUST be formed using the SIP or
   SIPS URI from the service instance name.  The URI is either the first
   DNS label of the service instance name if it contains no space, or
   the longest prefix in the first DNS label that does not include the
   first space character.  (See Section 3.)

   If the "name" attribute of the TXT record is available, it MAY be
   used as the "display-name" in the "To" header according to the
   formatting rules outlined in Section 20.10 of [RFC3261].

5.2.  Request Destination

   If the "contact" attribute of the TXT record is available, the host
   part MUST be taken as the destination host to which to send the
   request.  For example, if the TXT record contains
   "contact=sip:carol@cube2214a.chicago.com", the request must be sent
   to cube2214a.chicago.com.

   If the "contact" attribute is not available, the UA MUST resolve the
   service instance name to obtain the IP address and port to which to
   send the request.  The resolution is done by sending an SRV query or
   by calling the equivalent API routine in the DNS-SD library
   implementation (Section 5, [I-D.cheshire-dnsext-dns-sd]).
















Lee & Schulzrinne        Expires August 28, 2007               [Page 10]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


6.  User Interface Guidelines

   This section considers the user interface of a UA that implements the
   behavior specified in Section 5.  As a model for our discussion, let
   us consider a typical graphical UA that presents three user interface
   elements: an address book window containing the AORs manually
   maintained by the human user, another window listing the SIP URIs
   currently available through DNS-SD, and a text edit box in which the
   user can directly type in a URI not listed in either window.

   The address book entries and the DNS-SD entries SHOULD be presented
   in a way that makes it clear to the user that they are two separate
   lists.  When the user selects an entry from the DNS-SD list, the UA
   MUST follow the behavior outlined in Section 5.

   When the user selects an entry from the address book window, the UA
   MUST follow the normal user agent client behavior specified in
   Section 8.1 of [RFC3261].  This means that the SIP request is routed
   either using a configured outbound proxy or using the SIP server
   location mechanisms described in [RFC3263].  If such an effort fails,
   due to a network outage or a server failure for example, and there is
   a DNS-SD entry with the same URI as the address book entry that the
   user has selected, then (and only then) the UA MAY try the DNS-SD
   entry with the same URI, following the behavior in Section 5.  In
   this case, the address book entry might indicate that the URI is also
   being announced via DNS-SD advertisement.  The reason for requiring
   that the UA first follows the server mechanisms when processing an
   address book entry is discussed in Section 8.

   A URI directly typed in by the user MUST be processed as if it has
   been selected from the address book window.




















Lee & Schulzrinne        Expires August 28, 2007               [Page 11]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


7.  Transport Protocol in Service Instance Name

   Section 7 of [I-D.cheshire-dnsext-dns-sd] states:

      The "_tcp" or "_udp" should be regarded as little more than
      boilerplate text, and care should be taken not to attach too much
      importance to it.  Some might argue that the "_tcp" or "_udp"
      should not be there at all, but this format is defined by RFC
      2782, and that's not going to change.  In addition, the presence
      of "_tcp" has the useful side-effect that it provides a convenient
      delegation point to hand off responsibility for service discovery
      to a different DNS server, if so desired.

   The web site for DNS-SD service type registration (see Section 9)
   goes further and says:

      Protocols that can run over either UDP or TCP (e.g.  NFS) are
      usually advertised using whichever transport is considered the
      'normal' or 'primary' mode of operation (and clients should
      attempt communication with the service using either or both
      transports, as appropriate for the client).

   This interpretation and policy are reasonable for those application
   protocols that have clear "primary" transport protocols, but they
   present difficulty in a protocol such as SIP that supports multiple
   transports without favoring any particular one.  [RFC3263] specifies
   how NAPTR and SRV records are used to resolve a SIP URI into the IP
   address, port, and transport protocol of the request destination.
   The transport label in the SRV record ("_udp", "_tcp", or "_sctp")
   plays an important role in determining which transport protocol
   should be used.

   It would be inconsistent and confusing for a SIP UA to interpret the
   transport labels in SRV records differently depending on whether it
   is processing a DNS-SD service or not.  This document follows the
   conventional SRV record interpretation that treats the transport
   label as indicating the desired transport protocol (Section 3).  We
   believe the DNS-SD interpretation is an oversight and hope to see a
   change in the subsequent iterations of [I-D.cheshire-dnsext-dns-sd].












Lee & Schulzrinne        Expires August 28, 2007               [Page 12]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


8.  Security Considerations

   In DNS-SD/mDNS environment, there is no restriction on who can
   advertise what services.  An attacker who has gained access to a
   local area network, such as an unsecured wireless network, can
   impersonate any SIP URI simply by advertising it using DNS-SD.  A UA
   must be careful to present the URIs discovered through DNS-SD in a
   way clearly distinguishable from the ones in the user's address book.
   This security concern underlies the user interface guidelines in
   Section 6.









































Lee & Schulzrinne        Expires August 28, 2007               [Page 13]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


9.  IANA Considerations

   Currently, DNS-SD service type names are not managed by IANA.
   Section 19 of [I-D.cheshire-dnsext-dns-sd] proposes an IANA
   allocation policy for unique application protocol or service type
   names.  Until the proposal is adopted and in force, Section 19 points
   to <http://www.dns-sd.org/ServiceTypes.html> for instruction on how
   to register a unique service type name for DNS-SD.

   The service type "sipuri" for the discovery method presented in this
   document will be registered according to the instruction when this
   document gets published as an Internet-Draft.







































Lee & Schulzrinne        Expires August 28, 2007               [Page 14]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


10.  Normative References

   [I-D.cheshire-dnsext-dns-sd]
              Krochmal, M. and S. Cheshire, "DNS-Based Service
              Discovery", draft-cheshire-dnsext-dns-sd-04 (work in
              progress), August 2006.

   [I-D.cheshire-dnsext-multicastdns]
              Cheshire, S. and M. Krochmal, "Multicast DNS",
              draft-cheshire-dnsext-multicastdns-06 (work in progress),
              August 2006.

   [I-D.ietf-zeroconf-reqts]
              Hattig, M., "Requirements for Automatic Configuration of
              IP Hosts", draft-ietf-zeroconf-reqts-12 (work in
              progress), September 2002.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC3261]  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.

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              June 2002.

   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
              "Indicating User Agent Capabilities in the Session
              Initiation Protocol (SIP)", RFC 3840, August 2004.









Lee & Schulzrinne        Expires August 28, 2007               [Page 15]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


Authors' Addresses

   Jae Woo Lee
   Columbia University
   Dept. of Computer Science
   1214 Amsterdam Avenue
   New York, NY  10027
   US

   Email: jae@cs.columbia.edu


   Henning Schulzrinne
   Columbia University
   Dept. of Computer Science
   1214 Amsterdam Avenue
   New York, NY  10027
   US

   Email: schulzrinne@cs.columbia.edu































Lee & Schulzrinne        Expires August 28, 2007               [Page 16]


Internet-Draft   SIP URI Service Discovery using DNS-SD    February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Lee & Schulzrinne        Expires August 28, 2007               [Page 17]