summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5031.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5031.txt')
-rw-r--r--doc/rfc/rfc5031.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc5031.txt b/doc/rfc/rfc5031.txt
new file mode 100644
index 0000000..9614ddb
--- /dev/null
+++ b/doc/rfc/rfc5031.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group H. Schulzrinne
+Request for Comments: 5031 Columbia U.
+Category: Standards Track January 2008
+
+
+ A Uniform Resource Name (URN) for
+ Emergency and Other Well-Known Services
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ The content of many communication services depends on the context,
+ such as the user's location. We describe a 'service' URN that allows
+ well-known context-dependent services that can be resolved in a
+ distributed manner to be identified. Examples include emergency
+ services, directory assistance, and call-before-you-dig hot lines.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Registration Template . . . . . . . . . . . . . . . . . . . . 4
+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
+ 4.1. New Service-Identifying Labels . . . . . . . . . . . . . . 6
+ 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 . . . . . . . . . . . . . . . . . . 11
+ Appendix A. Alternative Approaches Considered . . . . . . . . . . 13
+ Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 14
+
+
+
+
+
+
+
+
+
+
+Schulzrinne Standards Track [Page 1]
+
+RFC 5031 Service URN January 2008
+
+
+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 9-1-1 in
+ North America, 1-1-2 in Europe), community services and volunteer
+ opportunities (2-1-1 in some regions of the United States), telephone
+ directory and repair services (4-1-1 and 6-1-1 in the United States
+ and Canada), government information services (3-1-1 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 access to 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.
+
+ 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 allows end systems to convey
+ information about the desired service to other network entities. For
+ example, an IP phone could have a special set of short cuts, address
+ book entries, or buttons that invoke emergency services. When such a
+ service identifier is put into the outgoing Session Initiation
+ Protocol (SIP) [RFC3261] message, it allows SIP proxies to
+ unambiguously take actions, as it would not be practical to configure
+ them with dial strings and emergency numbers used throughout the
+ world. Hence, such service identifiers make it possible to delegate
+ routing decisions to third parties and to mark certain requests as
+
+
+
+Schulzrinne Standards Track [Page 2]
+
+RFC 5031 Service URN January 2008
+
+
+ having special characteristics while preventing these characteristics
+ from being accidentally invoked.
+
+ 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 SIP [RFC3261]
+ request URIs, web pages, or mapping protocols.
+
+ The service URN is a protocol element and is generally not expected
+ to be visible to humans. For example, it is expected that callers
+ will still dial the emergency number '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.)
+
+ The translation of service dial strings or service numbers to service
+ URNs in the end host is beyond the scope of this document. These
+ translations likely depend on the location of the caller and may be
+ many-to-one, i.e., several service numbers may map to one service
+ URN. For example, a phone for a traveler could recognize the
+ emergency service number for both the traveler's home location and
+ the traveler's visited location, mapping 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. A Location-to-
+ Service Translation Protocol (LoST) [LOST] is expected to be used as
+ a resolution system for mapping service URNs to URLs based on
+ geographic location. In the future, there may be several such
+ protocols, possibly different ones for different services.
+
+ Services are described by top-level service type, and may contain a
+ hierarchy of sub-services that further describe the service, as
+ outlined in Section 3.
+
+ We discuss alternative approaches for creating service identifiers,
+ and why they are unsatisfactory, in Appendix A.
+
+
+
+
+
+
+
+
+
+
+Schulzrinne Standards Track [Page 3]
+
+RFC 5031 Service URN January 2008
+
+
+2. Terminology
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in RFC 2119
+ [RFC2119].
+
+ Terminology specific to emergency services is defined in [RFC5012].
+
+3. Registration Template
+
+ Below, we include the registration template for the URN scheme
+ according to RFC 3406 [RFC3406].
+
+ Namespace ID: service
+
+ Registration Information:
+
+ Registration version: 1
+
+ Registration date: 2006-04-02
+
+ Declared registrant of the namespace:
+
+ Registering organization: IETF
+
+ Designated contact: Henning Schulzrinne
+
+ Designated contact email: hgs@cs.columbia.edu
+
+ 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 [RFC1123] and a subset of the labels
+ allowed in [RFC3958]. Labels are case-insensitive, but MUST be
+ specified in all lower-case. For any given service URN, service-
+ identifiers can be removed right-to-left; the resulting URN is
+ still valid, referring to 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. The ABNF [RFC4234] is shown below.
+
+
+
+
+
+
+
+
+
+Schulzrinne Standards Track [Page 4]
+
+RFC 5031 Service URN January 2008
+
+
+ service-URN = "URN:service:" service
+ service = top-level *("." sub-service)
+ top-level = let-dig [ *25let-dig-hyp let-dig ]
+ sub-service = let-dig [ *let-dig-hyp let-dig ]
+ let-dig-hyp = let-dig / "-"
+ let-dig = ALPHA / DIGIT
+ ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
+ DIGIT = %x30-39 ; 0-9
+
+ 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
+ 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., [RFC3044],
+ [RFC3187], [RFC4179], and [RFC4195]), types of telecommunications
+ equipment [RFC4152], people, or organizations [RFC3043]. tel URIs
+ [RFC3966] 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.
+
+
+
+
+Schulzrinne Standards Track [Page 5]
+
+RFC 5031 Service URN January 2008
+
+
+ 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: There is no single global
+ resolution service for 'service' URNs. However, each top-level
+ service can provide a set of mapping protocols to be used with
+ 'service' URNs of that service.
+
+ 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.
+
+ Validation mechanism: Validation determines whether a given string
+ is currently a validly-assigned URN [RFC3406]. 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 services.
+
+ Scope: The scope for this URN is public and global.
+
+4. IANA Considerations
+
+ This section registers a new URN scheme with the registration
+ template provided in Section 3.
+
+ Below, Section 4.1 details how to register new service-identifying
+ labels. Descriptions of sub-services for the first two services to
+ be registered, sos and counseling, are given in Section 4.2 and
+ Section 4.3, respectively. Finally, Section 4.4 contains the initial
+ registration table.
+
+4.1. New Service-Identifying Labels
+
+ Services and sub-services are identified by labels managed by IANA,
+ according to the processes outlined in [RFC2434] 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
+
+
+
+Schulzrinne Standards Track [Page 6]
+
+RFC 5031 Service URN January 2008
+
+
+ 'Standards Action'. (This document defines the top-level services
+ '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 [RFC3958], 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
+ 'sos'.
+
+ 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
+ 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
+ transportation.
+
+ urn:service:sos.animal-control Animal control typically enforces
+ laws and ordinances pertaining to animal control and management,
+ investigates cases of animal abuse, educates the community in
+ responsible pet ownership and wildlife care, and provides for the
+ housing and care of homeless animals, among other animal-related
+ services.
+
+
+
+Schulzrinne Standards Track [Page 7]
+
+RFC 5031 Service URN January 2008
+
+
+ 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
+ emergencies.
+
+ 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
+ environments.
+
+ 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.
+
+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 described 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
+ 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
+ needs.
+
+
+
+
+
+
+
+Schulzrinne Standards Track [Page 8]
+
+RFC 5031 Service URN January 2008
+
+
+ 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)
+
+ urn:service:counseling.suicide The 'suicide' service refers to the
+ suicide prevention hotline.
+
+4.4. Initial IANA Registration
+
+ The following table contains the initial IANA registration for
+ emergency and counseling services.
+
+ Service Reference Description
+ --------------------------------------------------------------------
+ counseling RFC 5031 Counseling services
+ counseling.children RFC 5031 Counseling for children
+ counseling.mental-health RFC 5031 Mental health counseling
+ counseling.suicide RFC 5031 Suicide prevention hotline
+
+ sos RFC 5031 Emergency services
+ sos.ambulance RFC 5031 Ambulance service
+ sos.animal-control RFC 5031 Animal control
+ sos.fire RFC 5031 Fire service
+ sos.gas RFC 5031 Gas leaks and gas emergencies
+ sos.marine RFC 5031 Maritime search and rescue
+ sos.mountain RFC 5031 Mountain rescue
+ sos.physician RFC 5031 Physician referral service
+ sos.poison RFC 5031 Poison control center
+ sos.police RFC 5031 Police, law enforcement
+
+5. Internationalization Considerations
+
+ The service labels are protocol elements [RFC3536] and are not
+ normally seen by users. Thus, the character set for these elements
+ is restricted, as described in Section 3.
+
+
+
+
+
+
+
+
+
+Schulzrinne Standards Track [Page 9]
+
+RFC 5031 Service URN January 2008
+
+
+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 [RFC5069]. That document also discusses the security
+ considerations related to the use of the service URN for emergency
+ services.
+
+7. References
+
+7.1. Normative References
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
+ and Support", STD 3, RFC 1123, October 1989.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [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.
+
+ [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
+ Service Location Using SRV RRs and the Dynamic Delegation
+ Discovery Service (DDDS)", RFC 3958, January 2005.
+
+ [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+
+
+
+
+
+
+Schulzrinne Standards Track [Page 10]
+
+RFC 5031 Service URN January 2008
+
+
+7.2. Informative References
+
+ [LOST] Hardie, T., "LoST: A Location-to-Service Translation
+ Protocol", Work in Progress, March 2007.
+
+ [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
+ FUNCTIONS", RFC 2142, May 1997.
+
+ [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
+ April 2001.
+
+ [RFC3043] Mealling, M., "The Network Solutions Personal Internet
+ Name (PIN): A URN Namespace for People and Organizations",
+ RFC 3043, January 2001.
+
+ [RFC3044] Rozenfeld, S., "Using The ISSN (International Serial
+ Standard Number) as URN (Uniform Resource Names) within an
+ ISSN-URN Namespace", RFC 3044, January 2001.
+
+ [RFC3187] Hakala, J. and H. Walravens, "Using International Standard
+ Book Numbers as Uniform Resource Names", RFC 3187,
+ October 2001.
+
+ [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
+ "Uniform Resource Names (URN) Namespace Definition
+ Mechanisms", BCP 66, RFC 3406, October 2002.
+
+ [RFC3536] Hoffman, P., "Terminology Used in Internationalization in
+ the IETF", RFC 3536, May 2003.
+
+ [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
+ RFC 3966, December 2004.
+
+ [RFC4152] Tesink, K. and R. Fox, "A Uniform Resource Name (URN)
+ Namespace for the Common Language Equipment Identifier
+ (CLEI) Code", RFC 4152, August 2005.
+
+ [RFC4179] Kang, S., "Using Universal Content Identifier (UCI) as
+ Uniform Resource Names (URN)", RFC 4179, October 2005.
+
+ [RFC4195] Kameyama, W., "A Uniform Resource Name (URN) Namespace for
+ the TV-Anytime Forum", RFC 4195, October 2005.
+
+ [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for
+ Emergency Context Resolution with Internet Technologies",
+ RFC 5012, January 2008.
+
+
+
+
+
+Schulzrinne Standards Track [Page 11]
+
+RFC 5031 Service URN January 2008
+
+
+ [RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M.
+ Shanmugam, "Security Threats and Requirements for
+ Emergency Call Marking and Mapping", RFC 5069,
+ January 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne Standards Track [Page 12]
+
+RFC 5031 Service URN January 2008
+
+
+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 [RFC3966]. 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 requires extending
+ the "tel" URI "tel" [RFC3966]. It also only works if every
+ outbound proxy knows how to route requests to a proxy that can
+ reach emergency services since tel URIs do not identify the
+ destination server.
+
+ 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 [RFC2142] and the "postmaster" convention
+ documented in RFC 2822 [RFC2822]. 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
+ not do. Adding other parameters still leaves unclear what, if
+
+
+
+
+
+Schulzrinne Standards Track [Page 13]
+
+RFC 5031 Service URN January 2008
+
+
+ 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.
+
+Author's Address
+
+ Henning Schulzrinne
+ Columbia University
+ Department of Computer Science
+ 450 Computer Science Building
+ New York, NY 10027
+ US
+
+ Phone: +1 212 939 7004
+ EMail: hgs+ecrit@cs.columbia.edu
+ URI: http://www.cs.columbia.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne Standards Track [Page 14]
+
+RFC 5031 Service URN January 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne Standards Track [Page 15]
+