[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-sipping-sos) 00 01 02 03 04 05 06 07 RFC 5031

ECRIT                                                     H. Schulzrinne
Internet-Draft                                               Columbia U.
Expires: February 7, 2007                                 August 6, 2006

               A Uniform Resource Name (URN) for Services

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on February 7, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   The content of many communication services depends on the context,
   such as the user's location.  We describe a 'service' URN that allows
   to identify context-dependent services that can be resolved in a
   distributed manner.

Schulzrinne             Expires February 7, 2007                [Page 1]

Internet-Draft                 Service URN                   August 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Registration Template  . . . . . . . . . . . . . . . . . . . .  5
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
     4.1   New Service-Identifying Labels . . . . . . . . . . . . . .  7
     4.2   Sub-Services for the 'sos' Service . . . . . . . . . . . .  7
     4.3   Sub-Services for the 'counseling' Service  . . . . . . . .  8
     4.4   Initial IANA Registration  . . . . . . . . . . . . . . . .  9
   5.  Internationalization Considerations  . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1   Normative References . . . . . . . . . . . . . . . . . . . 10
     7.2   Informative References . . . . . . . . . . . . . . . . . . 10
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
   A.  Alternative Approaches Considered  . . . . . . . . . . . . . . 12
   B.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
       Intellectual Property and Copyright Statements . . . . . . . . 14

Schulzrinne             Expires February 7, 2007                [Page 2]

Internet-Draft                 Service URN                   August 2006

1.  Introduction

   In existing telecommunications systems, there are many well-known
   communication and information services that are offered by loosely
   coordinated entities across a large geographic region, with well-
   known identifiers.  Some of the services are operated by governments
   or regulated monopolies, others by competing commercial enterprises.
   Examples include emergency services (reached by dialing 911 in North
   America, 112 in Europe), community services and volunteer
   opportunities (211 in some regions of the United States), telephone
   directory and repair services (411 and 611 in the United States and
   Canada), government information services (311 in some cities in the
   United States), lawyer referral services (1-800-LAWYER), car roadside
   assistance (automobile clubs) and pizza delivery services.
   Unfortunately, almost all of them are limited in scope to a single
   country or possibly a group of countries, such as those belonging to
   the North American Numbering Plan or the European Union.  The same
   identifiers are often used for other purposes outside that region,
   making accessing such services difficult when users travel or use
   devices produced outside their home country.

   These services are characterized by long-term stability of user-
   visible identifiers, decentralized administration of the underlying
   service and a well-defined resolution or mapping mechanism.  For
   example, there is no national coordination or call center for "9-1-1"
   in the United States; rather, various local government organizations
   cooperate to provide this service, based on jurisdictions.  We use
   the terms resolution and mapping interchangeably.

   In this document, we propose a URN namespace that, together with
   resolution protocols beyond the scope of this document, allows us to
   define such global, well-known services, while distributing the
   actual implementation across a large number of service-providing
   entities.  There are many ways to divide provision of such services,
   such as dividing responsibility by geographic region or by the
   service provider a user chooses.  In addition, users can choose
   different mapping service providers that in turn manage how
   geographic locations are mapped to service providers.

   Availability of such service identifiers simplifies end system
   configuration.  For example, an IP phone could have a special set of
   short cuts, address book entries or buttons that invoke emergency
   services, as it would not be practical to manually re-configure the
   device with local emergency contacts for each city or town a user
   visits with his or her mobile device.  Also, such identifiers make it
   possible to delegate routing decisions to third parties and to mark
   certain requests as having special characteristics while preventing
   these characteristics to be accidentally invoked on inappropriate

Schulzrinne             Expires February 7, 2007                [Page 3]

Internet-Draft                 Service URN                   August 2006


   This URN identifies services independent of the particular protocol
   that is used to request or deliver the service.  The URN may appear
   in protocols that allow general URIs, such as the Session Initiation
   Protocol (SIP) [5] request URIs, web pages or mapping protocols.

   The service URN is a protocol element and generally not expected to
   be visible to humans.  For example, it is expected that callers will
   still dial '9-1-1' in the United States to reach emergency services.
   In some other cases, speed dial buttons might identify the service,
   as is common practice on hotel phones today.  (Speed dial buttons for
   summoning emergency help are considered inappropriate by most
   emergency services professionals, at least for mobile devices, as
   they are too prone to being triggered accidentally.)  Rather,
   protocols would carry the service URN described here, allowing
   universal identification.  The translation of dial strings or service
   numbers to service URNs is beyond the scope of this document; it is
   likely to depend on the location of the caller and may be many-to-
   one.  For example, a phone for a traveler could recognize the
   emergency number for both the traveler's home location and the
   traveler's visited location, translating both to the same universal
   service URN, urn:service:sos.

   Since service URNs are not routable, a SIP proxy or user agent has to
   translate the service URN into a routable URI for a location-
   appropriate service provider, such as a SIP URL.  LoST [19] is one
   resolution system for mapping service URNs to URLs based on
   geographic location.  It is anticipated that there will be several
   such systems, possibly with different systems for different services.

   Services are described by top-level service type, and may contain a
   hierarchy of sub-services further describing the service, as outlined
   in Section 3.  Mapping protocols SHOULD always provide a mapping just
   for the top-level service even if sub-services are in use.  This
   mapping for the top-level service MAY also be used if an entity is
   presented with an invalid sub-service and presenting an error
   condition to the user is inappropriate, e.g., during an emergency.

   We discuss alternative approaches for creating service identifiers,
   and why they are unsatisfactory, in Appendix A.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [2].

Schulzrinne             Expires February 7, 2007                [Page 4]

Internet-Draft                 Service URN                   August 2006

   Terminology specific to emergency services is defined in [21].

3.  Registration Template

   Below, we include the registration template for the URN scheme
   according to RFC 3406 [13].
   Namespace ID: service
   Registration Information: Registration version: 1; registration date:

   Declared registrant of the namespace: TBD

   Declaration of syntactic structure: The URN consists of a
      hierarchical service identifier, with a sequence of labels
      separated by periods.  The left-most label is the most significant
      one and is called 'top-level service', while names to the right
      are called 'sub-services'.  The set of allowable characters is the
      same as that for domain names [1] and a subset of the labels
      allowed in [6].  Labels are case-insensitive and SHOULD be
      specified in all lower-case.  For any given service URN, service-
      identifiers can be removed right-to-left and the resulting URN is
      still valid, referring a more generic service.  In other words, if
      a service 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid
      service URNs.

     "URN:service:" service
     service      = top-level *("." sub-service)
     let-dig      = ALPHA / DIGIT
     let-dig-hyp  = let-dig / '-'
     sub-service  = let-dig [ *let-dig-hyp let-dig ]
     top-level    = let-dig [ *25let-dig-hyp let-dig ]

   Relevant ancillary documentation: None

   Community considerations: The service URN is believed to be relevant
      to a large cross-section of Internet users, including both
      technical and non-technical users, on a variety of devices, but
      particularly for mobile and nomadic users.  The service URN will
      allow Internet users needing services to identify the service by
      kind, without having to determine manually who provides the
      particular service in the user's current context, e.g., at the
      user's current location.  For example, travelers will be able to
      use their mobile devices to request emergency services without
      having to know the emergency dial string of the visited country.
      The assignment of identifiers is described in the IANA
      Considerations (Section 4).  The service URN does not prescribe a
      particular resolution mechanism, but it is assumed that a number

Schulzrinne             Expires February 7, 2007                [Page 5]

Internet-Draft                 Service URN                   August 2006

      of different entities could operate and offer such mechanisms.

   Namespace considerations: There do not appear to be other URN
      namespaces that serve the same need of uniquely identifying
      widely-available communication and information services.  Unlike
      most other currently registered URN namespaces, the service URN
      does not identify documents and protocol objects (e.g., [10],
      [11], [16], [17]), types of telecommunications equipment [15],
      people or organizations [9]. tel URIs [14] identify telephone
      numbers, but numbers commonly identifying services, such as 911 or
      112, are specific to a particular region or country.

   Identifier uniqueness considerations: A service URN identifies a
      logical service, specified in the service registration (see IANA
      Considerations (Section 4)).  Resolution of the URN, if
      successful, will return a particular instance of the service, and
      this instance may be different even for two users making the same
      request in the same place at the same time; the logical service
      identified by the URN, however, is persistent and unique.  Service
      URNs MUST be unique for each unique service; this is guaranteed
      through the registration of each service within this namespace,
      described in Section 4.

   Identifier persistence considerations: The 'service' URN for the same
      service is expected to be persistent, although there naturally
      cannot be a guarantee that a particular service will continue to
      be available globally or at all times.

   Process of identifier assignment: The process of identifier
      assignment is described in the IANA Considerations (Section 4).

   Process for identifier resolution: 'service' identifiers are resolved
      by mapping protocols, based on the service and the location of the
      person or entity desiring the use of the service.  Each top-level
      service can provide its own distinct set of mapping protocols.
      Within each top-level service, all mapping protocols MUST return
      the same set of mappings.  A resolution service is specified in a
      separate document.

   Rules for Lexical Equivalence: 'service' identifiers are compared
      according to case-insensitive string equality.

   Conformance with URN Syntax: The BNF in the 'Declaration of syntactic
      structure' above constrains the syntax for this URN scheme.

Schulzrinne             Expires February 7, 2007                [Page 6]

Internet-Draft                 Service URN                   August 2006

   Validation mechanism: Validation determines whether a given string is
      currently a validly-assigned URN [13].  Due to the distributed
      nature of the mapping mechanism and since not all services are
      available everywhere and not all mapping servers may be configured
      with all current service registrations, validation in this sense
      is not possible.  Also, the discovery mechanism for the mapping
      mechanism may not be configured with all current top-level

   Scope: The scope for this URN is public and global.

4.  IANA Considerations

4.1  New Service-Identifying Labels

   Services and sub-services are identified by labels managed by IANA,
   according to the processes outlined in [4] in a new registry called
   "Service URN Labels".  Thus, creating a new service requires IANA
   action.  The policy for adding top-level service labels is 'Standards
   Action'.  (This document defines the top-level service 'sos' and
   'counseling'.)  The policy for assigning labels to sub-services may
   differ for each top-level service designation and MUST be defined by
   the document describing the top-level service.

   Entries in the registration table have the following format

   Service  Reference  Description
   foo      RFCxyz     Brief description of the 'foo' top-level service
   foo.bar  RFCabc     Description of the 'foo.bar' service

   To allow use within the constraints of S-NAPTR [6], all top-level
   service names MUST NOT exceed 27 characters.

4.2  Sub-Services for the 'sos' Service

   This section defines the first service registration within the IANA
   registry defined in Section 4.1, using the top-level service label

   The 'sos' service type describes emergency services requiring an
   immediate response, typically offered by various branches of the
   government or other public institutions.  Additional sub-services can
   be added after expert review and must be of general public interest
   and have a similar emergency nature.  The expert is designated by the
   ECRIT working group, its successor, or, in their absence, the IESG.
   The expert review should only approve emergency services that are

Schulzrinne             Expires February 7, 2007                [Page 7]

Internet-Draft                 Service URN                   August 2006

   offered widely and in different countries, with approximately the
   same caller expectation in terms of services rendered.  The 'sos'
   service is not meant to invoke general government, public
   information, counseling or social services.

   urn:service:sos The generic 'sos' service reaches a public safety
      answering point (PSAP) which in turn dispatches aid appropriate to
      the emergency.  It encompasses all of the services listed below.
   urn:service:sos.ambulance This service identifier reaches an
      ambulance service that provides emergency medical assistance and
   urn:service:sos.animal-control Animal control is defined as control
      of dogs, cats, and domesticated or undomesticated animals.
   urn:service:sos.fire The 'fire' service identifier summons the fire
      service, also known as the fire brigade or fire department.
   urn:service:sos.gas The 'gas' service allows the reporting of natural
      gas (and other flammable gas) leaks or other natural gas
   urn:service:sos.marine The 'marine' service refers to maritime search
      and rescue services such as those offered by the coast guard,
      lifeboat or surf lifesavers.
   urn:service:sos.mountain The 'mountain' service refers to mountain
      rescue services, i.e., search and rescue activities that occur in
      a mountainous environment, although the term is sometimes also
      used to apply to search and rescue in other wilderness
   urn:service:sos.physician The 'physician' emergency service connects
      the caller to a physician referral service.
   urn:service:sos.poison The 'poison' service refers to special
      information centers set up to inform citizens about how to respond
      to potential poisoning.  These poison control centers maintain a
      database of poisons and appropriate emergency treatment.
   urn:service:sos.police The 'police' service refers to the police
      department or other law enforcement authorities.
   urn:service:sos.suicide The 'suicide' service refers to the suicide
      prevention hotline.

4.3  Sub-Services for the 'counseling' Service

   The 'counseling' service type describes services where callers can
   receive advice and support, often anonymous, but not requiring an
   emergency response.  (Naturally, such services may transfer callers
   to an emergency service or summon such services if the situation
   warrants.)  Additional sub-services can be added after expert review
   and should be of general public interest.  The expert is chosen in
   the same manner as describe for the 'sos' service.  The expert review
   should take into account whether these services are offered widely
   and in different countries, with approximately the same caller

Schulzrinne             Expires February 7, 2007                [Page 8]

Internet-Draft                 Service URN                   August 2006

   expectation in terms of services rendered.
   urn:service:counseling The generic 'counseling' service reaches a
      call center that transfers the caller based on his or her specific

   urn:service:counseling.children The 'children' service refers to
      counseling and support services that are specifically tailored to
      the needs of children.  Such services may, for example, provide
      advice to run-aways or victims of child abuse.

   urn:service:counseling.mental-health The 'mental-health' service
      refers to the "diagnostic, treatment, and preventive care that
      helps improve how persons with mental illness feel both physically
      and emotionally as well as how they interact with other persons."
      (U.S. Department of Health and Human Services)

4.4  Initial IANA Registration

   The following table contains the initial IANA registration for
   emergency and counseling services.

   Service                   Reference  Description
   counseling                RFC XYZ    Counseling services
   counseling.children       RFC XYZ    Counseling for children
   counseling.mental-health  RFC XYZ    Mental health counseling

   sos                       RFC XYZ    Emergency services
   sos.animal-control        RFC XYZ    Animal control
   sos.fire                  RFC XYZ    Fire service
   sos.gas                   RFC XYZ    Gas leaks and gas emergencies
   sos.marine                RFC XYZ    Maritime search and rescue
   sos.mountain              RFC XYZ    Mountain rescue
   sos.physician             RFC XYZ    Physician referral service
   sos.poison                RFC XYZ    Poison control center
   sos.police                RFC XYZ    Police, law enforcement
   sos.suicide               RFC XYZ    Suicide prevention hotline

5.  Internationalization Considerations

   The service labels are protocol elements [12] and not normally seen
   by users.  Thus, the character set for these elements is restricted,
   as described in Section 3.

Schulzrinne             Expires February 7, 2007                [Page 9]

Internet-Draft                 Service URN                   August 2006

6.  Security Considerations

   As an identifier, the service URN does not appear to raise any
   particular security issues.  The services described by the URN are
   meant to be well-known, even if the particular service instance is
   access-controlled, so privacy considerations do not apply to the URN.
   There are likely no specific privacy issues when including a service
   URN on a web page, for example.  On the other hand, ferrying the URN
   in a signaling protocol can give attackers information on the kind of
   service desired by the caller.  For example, this makes it easier for
   the attacker to automatically find all calls for emergency services
   or directory assistance.  Appropriate, protocol-specific security
   mechanisms need to be implemented for protocols carrying service
   URNs.  The mapping protocol needs to address a number of threats, as
   detailed in [20].

7.  References

7.1  Normative References

   [1]  Braden, R., "Requirements for Internet Hosts - Application and
        Support", STD 3, RFC 1123, October 1989.

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

   [3]  Sollins, K., "Architectural Principles of Uniform Resource Name
        Resolution", RFC 2276, January 1998.

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

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

   [6]  Daigle, L. and A. Newton, "Domain-Based Application Service
        Location Using SRV RRs and the Dynamic Delegation Discovery
        Service (DDDS)", RFC 3958, January 2005.

7.2  Informative References

         FUNCTIONS", RFC 2142, May 1997.

   [8]   Resnick, P., "Internet Message Format", RFC 2822, April 2001.

   [9]   Mealling, M., "The Network Solutions Personal Internet Name

Schulzrinne             Expires February 7, 2007               [Page 10]

Internet-Draft                 Service URN                   August 2006

         (PIN): A URN Namespace for People and Organizations", RFC 3043,
         January 2001.

   [10]  Rozenfeld, S., "Using The ISSN (International Serial Standard
         Number) as URN (Uniform Resource Names) within an ISSN-URN
         Namespace", RFC 3044, January 2001.

   [11]  Hakala, J. and H. Walravens, "Using International Standard Book
         Numbers as Uniform Resource Names", RFC 3187, October 2001.

   [12]  Hoffman, P., "Terminology Used in Internationalization in the
         IETF", RFC 3536, May 2003.

   [13]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
         "Uniform Resource Names (URN) Namespace Definition Mechanisms",
         BCP 66, RFC 3406, October 2002.

   [14]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
         December 2004.

   [15]  Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace
         for the Common Language Equipment Identifier (CLEI) Code",
         RFC 4152, August 2005.

   [16]  Kang, S., "Using Universal Content Identifier (UCI) as Uniform
         Resource Names (URN)", RFC 4179, October 2005.

   [17]  Kameyama, W., "A Uniform Resource Name (URN) Namespace for the
         TV-Anytime Forum", RFC 4195, October 2005.

   [18]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
         Methodology for Network  Address Translator (NAT) Traversal for
         Offer/Answer Protocols", draft-ietf-mmusic-ice-09 (work in
         progress), June 2006.

   [19]  Hardie, T., "LoST: A Location-to-Service Translation Protocol",
         draft-hardie-ecrit-lost-00 (work in progress), March 2006.

   [20]  Taylor, T., "Security Threats and Requirements for Emergency
         Call Marking and Mapping", draft-ietf-ecrit-security-threats-03
         (work in progress), July 2006.

   [21]  Schulzrinne, H. and R. Marshall, "Requirements for Emergency
         Context Resolution with Internet Technologies",
         draft-ietf-ecrit-requirements-10 (work in progress), June 2006.

Schulzrinne             Expires February 7, 2007               [Page 11]

Internet-Draft                 Service URN                   August 2006

Author's Address

   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027

   Phone: +1 212 939 7004
   Email: hgs+ecrit@cs.columbia.edu
   URI:   http://www.cs.columbia.edu

Appendix A.  Alternative Approaches Considered

   The discussions of ways to identify emergency calls has yielded a
   number of proposals.  Since these are occasionally brought up during
   discussions, we briefly summarize why this document chose not to
   pursue these solutions.
   tel:NNN;context=+C This approach uses tel URIs [14].  Here, NNN is
      the national emergency number, where the country is identified by
      the context C. This approach is easy for user agents to implement,
      but hard for proxies and other SIP elements to recognize, as it
      would have to know about all number-context combinations in the
      world and track occasional changes.  In addition, many of these
      numbers are being used for other services.  For example, the
      emergency number in Paraguay (00) is also used to call the
      international operator in the United States.  As another example,
      A number of countries, such as Italy, use 118 as an emergency
      number, but it also connects to directory assistance in Finland.

   tel:sos This solution avoids name conflicts, but is not a valid "tel"
      [14] URI.  It also only works if every outbound proxy knows how to
      route requests to a proxy that can reach emergency services since
      tel URIs.  The SIP URI proposed here only requires a user's home
      domain to be appropriately configured.

   sip:sos@domain Earlier work had defined a special user identifier,
      sos, within the caller's home domain in a SIP URI, for example,
      sip:sos@example.com.  Such a user identifier follows the
      convention of RFC 2142 [7] and the "postmaster" convention
      documented in RFC 2822 [8].  This approach had the advantage that
      dial plans in existing user agents could probably be converted to
      generate such a URI and that only the home proxy for the domain
      has to understand the user naming convention.  However, it
      overloads the user part of the URI with specific semantics rather
      than being opaque, makes routing by the outbound proxy a special
      case that does not conform to normal SIP request-URI handling

Schulzrinne             Expires February 7, 2007               [Page 12]

Internet-Draft                 Service URN                   August 2006

      rules and is SIP-specific.  The mechanism also does not extend
      readily to other services.

   SIP URI user parameter: One could create a special URI, such as "aor-
      domain;user=sos".  This avoids the name conflict problem, but
      requires mechanism-aware user agents that are capable of emitting
      this special URI.  Also, the 'user' parameter is meant to describe
      the format of the user part of the SIP URI, which this usage does
      not do.  Adding other parameters still leaves unclear what, if
      any, conventions should be used for the user and domain part of
      the URL.  Neither solution is likely to be backward-compatible
      with existing clients.

   Special domain: A special domain, such as "sip:fire@sos.int" could be
      used to identify emergency calls.  This has similar properties as
      the "tel:sos" URI, except that it is indeed a valid URI.  To make
      this usable, the special domain would have to be operational and
      point to an appropriate emergency services proxy.  Having a
      single, if logical, emergency services proxy for the whole world
      seems to have undesirable scaling and administrative properties.

Appendix B.  Acknowledgments

   This document is based on discussions with Jonathan Rosenberg and
   benefited from the comments of Leslie Daigle, Keith Drage, Benja
   Fallenstein, Paul Kyzivat, Andrew Newton, Brian Rosen, Jonathan
   Rosenberg, Martin Thomson and Hannes Tschofenig.

Schulzrinne             Expires February 7, 2007               [Page 13]

Internet-Draft                 Service URN                   August 2006

Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Schulzrinne             Expires February 7, 2007               [Page 14]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/