SIPPING                                                   H. Schulzrinne
Internet-Draft                                               Columbia U.
Expires: September 6, 2006                                 March 5, 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 September 6, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


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

Schulzrinne             Expires September 6, 2006               [Page 1]

Internet-Draft                 Service URN                    March 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Registration Template  . . . . . . . . . . . . . . . . . . . .  4
   3.  SIP Media Feature Tag Registration:  Service . . . . . . . . .  6
   4.  The Service Application Specification  . . . . . . . . . . . .  7
     4.1   Application Unique String  . . . . . . . . . . . . . . . .  7
     4.2   First Well Known Rule  . . . . . . . . . . . . . . . . . .  8
     4.3   Valid Databases  . . . . . . . . . . . . . . . . . . . . .  8
     4.4   Expected Output  . . . . . . . . . . . . . . . . . . . . .  8
     4.5   Flags  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.6   Services . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.7   Example  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
     5.1   sos Service Types  . . . . . . . . . . . . . . . . . . . .  9
     5.2   SIP Media Feature Tag Registration:  Service . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1   Normative References . . . . . . . . . . . . . . . . . . . 10
     7.2   Informative References . . . . . . . . . . . . . . . . . . 11
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
   A.  Alternative Approaches Considered  . . . . . . . . . . . . . . 13
   B.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 15

Schulzrinne             Expires September 6, 2006               [Page 2]

Internet-Draft                 Service URN                    March 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 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.)

   In this document, we propose a URN namespace that, together with
   resolution protocols beyond the scope of this document, allows to
   define such global, well-known services, while distributing the
   actual implementation across a large number of service-providing
   entities.  While there are many ways to divide provision of such
   services, we focus on geography as a common way to delineate service
   regions.  In addition, users can choose different directory providers
   that in turn manage how geographic locations are mapped to service

   Availability of such service identifiers simplifies end system
   configuration.  For example, an IP phone could have a special set of
   short cuts 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 allow to delegate routing decisions
   to third parties and mark certain requests as having special
   characteristics while preventing these characteristics to be
   accidentally invoked on inappropriate requests.

Schulzrinne             Expires September 6, 2006               [Page 3]

Internet-Draft                 Service URN                    March 2006

   This URN allows to identify services independent of a particular
   protocol to deliver the services.  It 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 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, protocol elements would carry
   the service URN described here, allowing universal identification.
   The translation of dial strings 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 dial string for both the traveler's
   home location and the traveler's visited location, translating both
   to the same universal service URN, urn:service:sos.

   Existing technologies address the mapping of service identifiers to a
   service for a particular DNS domain (DNS SRV [13], DNS NAPTR [15]) or
   a local area network (SLP [12]).

   We discuss alternative approaches in Appendix A.  For example, the
   tel URI [20] allows to express service codes such as "911" for
   emergency services by adding a context parameter, but does not
   address the problem of global validity.

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

   For SIP, the service URN will likely appear in either the request URI
   or the To header field, depending on which SIP element recognizes the
   request as identifying an emergency call.  If the mapping is done by
   a proxy, the call may no longer be recognizable as an emergency call.
   Section 3 uses the service URN in a new SIP feature tag.

2.  Registration Template

   Below, we include the registration template for the URN scheme
   according to RFC 3406 [19].

Schulzrinne             Expires September 6, 2006               [Page 4]

Internet-Draft                 Service URN                    March 2006

   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] except that there is no
      restriction on the first character being a letter; labels are
      case-insensitive and SHOULD be specified in all lower-case.  Any
      string of service labels can be used to request services that are
      either more generic or more specific.  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-service *("." sub-service)
     top-level-service  = service-identifier
     sub-service        = service-identifier
     service-identifier = 1*(ALPHA / DIGIT / "-")

   Relevant ancillary documentation: None
   Community considerations: The service URN is believe 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 his
      current location.  For example, a traveler will be able to use his
      mobile device to request emergency services without having to know
      the local emergency number.  The assignment of identifiers is
      described in the IANA Considerations (Section 5).  The service URN
      does not prescribe a particular resolution mechanism, but it is
      assumed that a number of different entities could operate and
      offer such mechanisms.  The ECRIT working group is currently
      discussing several approaches, including solutions based on DNS,
      IRIS and a web-services protocol.  Software prototypes for some of
      these are currently already available and are believed to be
      readily developed.
   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., [17],
      [18], [22], [23]), types of telecommunications equipment [21],

Schulzrinne             Expires September 6, 2006               [Page 5]

Internet-Draft                 Service URN                    March 2006

      people or organizations [16]. tel URIs [20] 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).  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.
   Identifier persistence considerations: The 'service' URN for the same
      service is expected to be persisent, 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: Details of the service assignment
      depend on the service and national regulations.  In general, it is
      assumed that providers of services can register through a service
      mapping mechanism for a particular service in a particular
      geographic area.  The provision of some services may be restricted
      by local or national regulations.  (As a hypothetical example,
      providing emergency services may be restricted to government-
      authorized entities, which may limit the region where each entity
      can advertise its services.)  The rules for each service are
      described in a service-specific document.
   Process for identifier resolution: 'service' identifiers are resolved
      by the mapping protocols, an instance of a Resolution Discovery
      System (RDS) as described in RFC 2276 [3].  There could be several
      such mapping protocols in concurrent use, as long as there are
      reasonable guarantees that all services are available in all
      mapping protocols.  Section 4 describes the DDDS service that uses
      DNS NAPTR records to find an instance of a mapping service.
   Rules for Lexical Equivalence: 'service' identifiers are compared
      according to domain name comparison rules.  The use of homographic
      identifiers is NOT RECOMMENDED.
   Conformance with URN Syntax: There are no special considerations.
   Validation mechanism: The RDS mechanism is also used to validate the
      existence of a resource.  As noted, by its design, the
      availability of a resource may depend on where service is desired
      and there may not be service available in all or most locations.
      (For example, roadside assistance service is unlikely to be
      available on about 70% of the earth's surface.)
   Scope: The scope for this URN is public and global.

3.  SIP Media Feature Tag Registration:  Service

   This section is specific to SIP.

   If a user agent recognizes an emergency call, it inserts the service

Schulzrinne             Expires September 6, 2006               [Page 6]

Internet-Draft                 Service URN                    March 2006

   URN into the "To" header field of the INVITE request.  If a proxy
   recognizes a call as an emergency call, but the user agent did not,
   the To header field will contain another URL, such as a tel or SIP
   URL.  As part of the mapping process, the request URI will be
   replaced with the URL of the entity providing the service.  Thus, the
   INVITE request is no longer recognizable as an emergency call,
   although this is desirable to prevent misuse of authorization bypass
   for emergency calls and for appropriate policy and priority handling
   of emergency calls.

   To address this problem, we propose the use of a new media feature
   tag [8], sip.service, that describe the desired communication

   For example, a user agent could request to be routed to marine rescue
   by including the following SIP header field:

     Accept-Contact: *;sip.service="urn:service:sos.marine"

   The IANA registration can be found in Section 5.

4.  The Service Application Specification

   This template defines the service URN DDDS Application according to
   the rules and requirements found in [6].  The DDDS database used by
   this Application is found in [7] which is the document that defines
   the NAPTR DNS Resource Record type.

   In summary, a client that wants to resolve a service URN obtains a
   domain name through a variety of means, looks up the NAPTR record for
   the resolution service and used the regular expression in that record
   to transform the service URN into a protocol URL that leads to the
   mapping service.  This approach allows different domains to offer
   different instances of the mapping server and to have different
   services be handled by different mapping servers.

   [Note:  An alternative is to map the URN to a set of labels, ENUM-
   style, so that becomes
   This only works if the service labels are also valid DNS labels.]

4.1  Application Unique String

   The Application Unique String (AUS) is the service URN.  This URN
   MUST be canonicalized and hex encoded according to the "absolute-uri"
   production found in the Collected ABNF from RFC 2396.

Schulzrinne             Expires September 6, 2006               [Page 7]

Internet-Draft                 Service URN                    March 2006

4.2  First Well Known Rule

   The first well known rule extracts a key from the AUS.  For this
   application, the first well known rule extracts the service portion
   from the URN, i.e., the "service" part described in Declaration of
   Syntactic Structure (Section 2).

4.3  Valid Databases

   The key resulting from the first well known rule is looked up in a
   single database, the DNS [7].  The domain is determined by local
   configuration, including through DHCP [10].  For SIP services, the
   host part of the address-of-record (AOR) SHOULD be a valid NAPTR

4.4  Expected Output

   The result of the application is a DNS record for the server to

4.5  Flags

   Since the NAPTR record provides a URI, the "u" flag is used.

4.6  Services

   The service consists of a token identifying the mapping protocol ,
   followed by a transport identifier.  The string is defined by the
   mapping protocol.

4.7  Example

   The following example maps service URNs to HTTP URLs of the form[service], using the LoST [24] protocol.
   ;      order pref flags service      regexp  replacement
   IN NAPTR 50   50  "u"  "LOST+D2T"
      "!urn:service:(.*)!\1!i"  .

5.  IANA Considerations

   New service-identifying tokens and sub-registrations are to be
   managed by IANA, according to the processes outlined in [4].  The
   policy for top-level service names is 'IETF Consensus'.  The policy
   for assigning names to sub-services may differ for each top-level
   service designation and MUST be defined by the document describing

Schulzrinne             Expires September 6, 2006               [Page 8]

Internet-Draft                 Service URN                    March 2006

   the top-level service.

   This section also registers a new SIP media feature tag.

5.1  sos Service Types

   The 'sos' service type describes emergency services and services
   related to public safety and health, typically offered by various
   branches of the government or other public institutions.  Additional
   sub-services can be added after expert review and should be of
   general public interest.

   urn:service:sos The generic 'sos' service reaches a public safety
      answering point (PSAP), that 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. 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.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.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.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.
   urn:service:sos.mental-health The 'mental-health' service refers to
      the "[d]iagnostic, 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)

Schulzrinne             Expires September 6, 2006               [Page 9]

Internet-Draft                 Service URN                    March 2006

5.2  SIP Media Feature Tag Registration:  Service

   This specification defines an additional media feature tag, extending
   the SIP tree entries described in [8] and following the registration
   process in Section 12.1 of that document.  This section serves as the
   IANA registration for the service feature tags, which are made into
   the SIP media feature tag tree.

   Media feature tag name: sip.service
   ASN.1 Identifier: New assignment by IANA.
   Summary of the media feature indicated by this tag: Each feature tag
      indicates the type of service requested.
   Values appropriate for use with this feature tag: Service URNs, as
      described in this specification, with an equality relationship.
   The feature tag is intended primarily for use in the following
   applications, protocols, services, or negotiation mechanisms: This
      feature tag is most useful in a communications application, for
      describing the capabilities of a user agent providing a particular
      type of communication service.
   Examples of typical use: Routing calls to an appropriate service
      provider, such as a provider of emergency services.
   Related standards or documents: RFC3840.
   Security Considerations: Security considerations for this media
      feature tag are discussed in Section 11.1 of RFC3840.

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 instant 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 [25].  Security considerations for the media feature tag
   are described in [8].

7.  References

7.1  Normative References

   [1]  Mockapetris, P., "Domain names - concepts and facilities",
        STD 13, RFC 1034, November 1987.

Schulzrinne             Expires September 6, 2006              [Page 10]

Internet-Draft                 Service URN                    March 2006

   [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]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Two: The Algorithm", RFC 3402, October 2002.

   [7]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Three: The Domain Name System (DNS) Database", RFC 3403,
        October 2002.

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

   [9]  Duerst, M. and M. Suignard, "Internationalized Resource
        Identifiers (IRIs)", RFC 3987, January 2005.

7.2  Informative References

   [10]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
         March 1997.

         FUNCTIONS", RFC 2142, May 1997.

   [12]  Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service
         Location Protocol, Version 2", RFC 2608, June 1999.

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

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

   [15]  Mealling, M. and R. Daniel, "The Naming Authority Pointer
         (NAPTR) DNS Resource Record", RFC 2915, September 2000.

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

Schulzrinne             Expires September 6, 2006              [Page 11]

Internet-Draft                 Service URN                    March 2006

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

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

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

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

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

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

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

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

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

   [25]  Schulzrinne, H., "Security Threats and Requirements for
         Emergency Call Mapping", draft-taylor-ecrit-security-threats-02
         (work in progress), February 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

Schulzrinne             Expires September 6, 2006              [Page 12]

Internet-Draft                 Service URN                    March 2006

Appendix A.  Alternative Approaches Considered

   The "sos" SIP URI reserved user name proposed here follows the
   convention of RFC 2142 [11] and the "postmaster" convention
   documented in RFC 2822 [14].  The approach has the advantage that
   only the home proxy for a user needs to understand the convention and
   that the mechanism is likely backwards-compatible with most SIP user
   agents, with the only requirement that they have to be able to
   generate alphanumeric URLs.  One drawback is that it may conflict
   with locally assigned addresses of the form "sos@domain".  Also, if
   proxies not affiliated with the domain translate the URL, they
   violate the current SIP protocol conventions.

   There are a number of possible alternatives, each with their own set
   of advantages and problems:

   tel:NNN;context=+C This approach uses tel URIs [20].  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.  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"
      [20] 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,  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
      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

Schulzrinne             Expires September 6, 2006              [Page 13]

Internet-Draft                 Service URN                    March 2006

      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 "" 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
   benefitted from the comments of Leslie Daigle, Benja Fallenstein and
   Paul Kyzivat.

Schulzrinne             Expires September 6, 2006              [Page 14]

Internet-Draft                 Service URN                    March 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 September 6, 2006              [Page 15]