< draft-ietf-ecrit-service-urn-06.txt		draft-ietf-ecrit-service-urn-07.txt >
	ECRIT H. Schulzrinne		ECRIT H. Schulzrinne
	Internet-Draft Columbia U.		Internet-Draft Columbia U.
	Intended status: Standards Track March 4, 2007		Intended status: Standards Track August 15, 2007
	Expires: September 5, 2007		Expires: February 16, 2008
	A Uniform Resource Name (URN) for Services		A Uniform Resource Name (URN) for Emergency and Other Well-Known
	draft-ietf-ecrit-service-urn-06		Services
			draft-ietf-ecrit-service-urn-07
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 35 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 5, 2007.		This Internet-Draft will expire on February 16, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The content of many communication services depends on the context,		The content of many communication services depends on the context,
	such as the user's location. We describe a 'service' URN that allows		such as the user's location. We describe a 'service' URN that allows
	to identify context-dependent services that can be resolved in a		to identify well-known context-dependent services that can be
	distributed manner.		resolved in a distributed manner. Examples include emergency
			services, directory assistance and call-before-you-dig hot lines.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Registration Template . . . . . . . . . . . . . . . . . . . . 5		3. Registration Template . . . . . . . . . . . . . . . . . . . . 5
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	4.1. New Service-Identifying Labels . . . . . . . . . . . . . . 7		4.1. New Service-Identifying Labels . . . . . . . . . . . . . . 7
	4.2. Sub-Services for the 'sos' Service . . . . . . . . . . . . 8		4.2. Sub-Services for the 'sos' Service . . . . . . . . . . . . 8
	4.3. Sub-Services for the 'counseling' Service . . . . . . . . 9		4.3. Sub-Services for the 'counseling' Service . . . . . . . . 9
	4.4. Initial IANA Registration . . . . . . . . . . . . . . . . 9		4.4. Initial IANA Registration . . . . . . . . . . . . . . . . 9
	5. Internationalization Considerations . . . . . . . . . . . . . 10		5. Internationalization Considerations . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 11		7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	7.2. Informative References . . . . . . . . . . . . . . . . . . 11		7.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Appendix A. Alternative Approaches Considered . . . . . . . . . . 12		Appendix A. Alternative Approaches Considered . . . . . . . . . . 12
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 13		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Intellectual Property and Copyright Statements . . . . . . . . . . 15		Intellectual Property and Copyright Statements . . . . . . . . . . 15
	1. Introduction		1. Introduction
	In existing telecommunications systems, there are many well-known		In existing telecommunications systems, there are many well-known
	communication and information services that are offered by loosely		communication and information services that are offered by loosely
	coordinated entities across a large geographic region, with well-		coordinated entities across a large geographic region, with well-
	known identifiers. Some of the services are operated by governments		known identifiers. Some of the services are operated by governments
	or regulated monopolies, others by competing commercial enterprises.		or regulated monopolies, others by competing commercial enterprises.
	Examples include emergency services (reached by dialing 9-1-1 in		Examples include emergency services (reached by dialing 9-1-1 in
	skipping to change at page 4, line 34 ¶		skipping to change at page 4, line 34 ¶
	URNs in the end host is beyond the scope of this document. These		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		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		many-to-one, i.e., several service numbers may map to one service
	URN. For example, a phone for a traveler could recognize the		URN. For example, a phone for a traveler could recognize the
	emergency service number for both the traveler's home location and		emergency service number for both the traveler's home location and
	the traveler's visited location, mapping both to the same universal		the traveler's visited location, mapping both to the same universal
	service URN, urn:service:sos.		service URN, urn:service:sos.
	Since service URNs are not routable, a SIP proxy or user agent has to		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-		translate the service URN into a routable URI for a location-
	appropriate service provider, such as a SIP URL. LoST [17] is		appropriate service provider, such as a SIP URL. LoST [18] is
	expected to be used as a resolution system for mapping service URNs		expected to be used as a resolution system for mapping service URNs
	to URLs based on geographic location. In the future, there may be		to URLs based on geographic location. In the future, there may be
	several such protocols, possibly different ones for different		several such protocols, possibly different ones for different
	services.		services.
	Services are described by top-level service type, and may contain a		Services are described by top-level service type, and may contain a
	hierarchy of sub-services further describing the service, as outlined		hierarchy of sub-services further describing the service, as outlined
	in Section 3.		in Section 3.
	We discuss alternative approaches for creating service identifiers,		We discuss alternative approaches for creating service identifiers,
	and why they are unsatisfactory, in Appendix A.		and why they are unsatisfactory, in Appendix A.
	2. Terminology		2. Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" are to be interpreted as described in RFC 2119 [2].		and "OPTIONAL" are to be interpreted as described in RFC 2119 [2].
	Terminology specific to emergency services is defined in [19].		Terminology specific to emergency services is defined in [20].
	3. Registration Template		3. Registration Template
	Below, we include the registration template for the URN scheme		Below, we include the registration template for the URN scheme
	according to RFC 3406 [12].		according to RFC 3406 [13].
	Namespace ID: service		Namespace ID: service
	Registration Information: Registration version: 1; registration		Registration Information: Registration version: 1; registration
	date: 2006-04-02		date: 2006-04-02
	Declared registrant of the namespace:		Declared registrant of the namespace:
	Registering organization: IETF ECRIT Working Group		Registering organization: IETF
	Designated contact: Henning Schulzrinne		Designated contact: Henning Schulzrinne
	Designated contact email: hgs@cs.columbia.edu		Designated contact email: hgs@cs.columbia.edu
	Declaration of syntactic structure: The URN consists of a		Declaration of syntactic structure: The URN consists of a
	hierarchical service identifier, with a sequence of labels		hierarchical service identifier, with a sequence of labels
	separated by periods. The left-most label is the most significant		separated by periods. The left-most label is the most significant
	one and is called 'top-level service', while names to the right		one and is called 'top-level service', while names to the right
	are called 'sub-services'. The set of allowable characters is the		are called 'sub-services'. The set of allowable characters is the
	same as that for domain names [1] and a subset of the labels		same as that for domain names [1] and a subset of the labels
	allowed in [5]. Labels are case-insensitive and MUST be specified		allowed in [5]. Labels are case-insensitive and MUST be specified
	in all lower-case. For any given service URN, service-identifiers		in all lower-case. For any given service URN, service-identifiers
	can be removed right-to-left and the resulting URN is still valid,		can be removed right-to-left and the resulting URN is still valid,
	referring a more generic service. In other words, if a service		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		'x.y.z' exists, the URNs 'x' and 'x.y' are also valid service
	URNs.		URNs. The ABNF [6] is shown below.
	"URN:service:" service		service-URN = "URN:service:" service
	service = top-level *("." sub-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 ]		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		Relevant ancillary documentation: None
	Community considerations: The service URN is believed to be relevant		Community considerations: The service URN is believed to be relevant
	to a large cross-section of Internet users, including both		to a large cross-section of Internet users, including both
	technical and non-technical users, on a variety of devices, but		technical and non-technical users, on a variety of devices, but
	particularly for mobile and nomadic users. The service URN will		particularly for mobile and nomadic users. The service URN will
	allow Internet users needing services to identify the service by		allow Internet users needing services to identify the service by
	kind, without having to determine manually who provides the		kind, without having to determine manually who provides the
	particular service in the user's current context, e.g., at the		particular service in the user's current context, e.g., at the
	skipping to change at page 6, line 16 ¶		skipping to change at page 6, line 18 ¶
	having to know the emergency dial string of the visited country.		having to know the emergency dial string of the visited country.
	The assignment of identifiers is described in the IANA		The assignment of identifiers is described in the IANA
	Considerations (Section 4). The service URN does not prescribe a		Considerations (Section 4). The service URN does not prescribe a
	particular resolution mechanism, but it is assumed that a number		particular resolution mechanism, but it is assumed that a number
	of different entities could operate and offer such mechanisms.		of different entities could operate and offer such mechanisms.
	Namespace considerations: There do not appear to be other URN		Namespace considerations: There do not appear to be other URN
	namespaces that serve the same need of uniquely identifying		namespaces that serve the same need of uniquely identifying
	widely-available communication and information services. Unlike		widely-available communication and information services. Unlike
	most other currently registered URN namespaces, the service URN		most other currently registered URN namespaces, the service URN
	does not identify documents and protocol objects (e.g., [9], [10],		does not identify documents and protocol objects (e.g., [10],
	[15], [16]), types of telecommunications equipment [14], people or		[11], [16], [17]), types of telecommunications equipment [15],
	organizations [8]. tel URIs [13] identify telephone numbers, but		people or organizations [9]. tel URIs [14] identify telephone
	numbers commonly identifying services, such as 911 or 112, are		numbers, but numbers commonly identifying services, such as 911 or
	specific to a particular region or country.		112, are specific to a particular region or country.
	Identifier uniqueness considerations: A service URN identifies a		Identifier uniqueness considerations: A service URN identifies a
	logical service, specified in the service registration (see IANA		logical service, specified in the service registration (see IANA
	Considerations (Section 4)). Resolution of the URN, if		Considerations (Section 4)). Resolution of the URN, if
	successful, will return a particular instance of the service, and		successful, will return a particular instance of the service, and
	this instance may be different even for two users making the same		this instance may be different even for two users making the same
	request in the same place at the same time; the logical service		request in the same place at the same time; the logical service
	identified by the URN, however, is persistent and unique. Service		identified by the URN, however, is persistent and unique. Service
	URNs MUST be unique for each unique service; this is guaranteed		URNs MUST be unique for each unique service; this is guaranteed
	through the registration of each service within this namespace,		through the registration of each service within this namespace,
	skipping to change at page 7, line 10 ¶		skipping to change at page 7, line 13 ¶
	'service' URNs of that service.		'service' URNs of that service.
	Rules for Lexical Equivalence: 'service' identifiers are compared		Rules for Lexical Equivalence: 'service' identifiers are compared
	according to case-insensitive string equality.		according to case-insensitive string equality.
	Conformance with URN Syntax: The BNF in the 'Declaration of		Conformance with URN Syntax: The BNF in the 'Declaration of
	syntactic structure' above constrains the syntax for this URN		syntactic structure' above constrains the syntax for this URN
	scheme.		scheme.
	Validation mechanism: Validation determines whether a given string		Validation mechanism: Validation determines whether a given string
	is currently a validly-assigned URN [12]. Due to the distributed		is currently a validly-assigned URN [13]. Due to the distributed
	nature of the mapping mechanism and since not all services are		nature of the mapping mechanism and since not all services are
	available everywhere and not all mapping servers may be configured		available everywhere and not all mapping servers may be configured
	with all current service registrations, validation in this sense		with all current service registrations, validation in this sense
	is not possible. Also, the discovery mechanism for the mapping		is not possible. Also, the discovery mechanism for the mapping
	mechanism may not be configured with all current top-level		mechanism may not be configured with all current top-level
	services.		services.
	Scope: The scope for this URN is public and global.		Scope: The scope for this URN is public and global.
	4. IANA Considerations		4. IANA Considerations
	skipping to change at page 10, line 27 ¶		skipping to change at page 10, line 27 ¶
	sos.mountain RFC XYZ Mountain rescue		sos.mountain RFC XYZ Mountain rescue
	sos.physician RFC XYZ Physician referral service		sos.physician RFC XYZ Physician referral service
	sos.poison RFC XYZ Poison control center		sos.poison RFC XYZ Poison control center
	sos.police RFC XYZ Police, law enforcement		sos.police RFC XYZ Police, law enforcement
	[[NOTE TO RFC-EDITOR: Please replace above 'RFC XYZ' reference with		[[NOTE TO RFC-EDITOR: Please replace above 'RFC XYZ' reference with
	the RFC number of this document and remove this note.]]		the RFC number of this document and remove this note.]]
	5. Internationalization Considerations		5. Internationalization Considerations
	The service labels are protocol elements [11] and not normally seen		The service labels are protocol elements [12] and not normally seen
	by users. Thus, the character set for these elements is restricted,		by users. Thus, the character set for these elements is restricted,
	as described in Section 3.		as described in Section 3.
	6. Security Considerations		6. Security Considerations
	As an identifier, the service URN does not appear to raise any		As an identifier, the service URN does not appear to raise any
	particular security issues. The services described by the URN are		particular security issues. The services described by the URN are
	meant to be well-known, even if the particular service instance is		meant to be well-known, even if the particular service instance is
	access-controlled, so privacy considerations do not apply to the URN.		access-controlled, so privacy considerations do not apply to the URN.
	There are likely no specific privacy issues when including a service		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		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		in a signaling protocol can give attackers information on the kind of
	service desired by the caller. For example, this makes it easier for		service desired by the caller. For example, this makes it easier for
	the attacker to automatically find all calls for emergency services		the attacker to automatically find all calls for emergency services
	or directory assistance. Appropriate, protocol-specific security		or directory assistance. Appropriate, protocol-specific security
	mechanisms need to be implemented for protocols carrying service		mechanisms need to be implemented for protocols carrying service
	URNs. The mapping protocol needs to address a number of threats, as		URNs. The mapping protocol needs to address a number of threats, as
	detailed in [18]. That document also discusses the security		detailed in [19]. That document also discusses the security
	considerations related to the use of the service URN for emergency		considerations related to the use of the service URN for emergency
	services.		services.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[1] Braden, R., "Requirements for Internet Hosts - Application and		[1] Braden, R., "Requirements for Internet Hosts - Application and
	Support", STD 3, RFC 1123, October 1989.		Support", STD 3, RFC 1123, October 1989.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	skipping to change at page 11, line 24 ¶		skipping to change at page 11, line 24 ¶
	October 1998.		October 1998.
	[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:		Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, June 2002.		Session Initiation Protocol", RFC 3261, June 2002.
	[5] Daigle, L. and A. Newton, "Domain-Based Application Service		[5] Daigle, L. and A. Newton, "Domain-Based Application Service
	Location Using SRV RRs and the Dynamic Delegation Discovery		Location Using SRV RRs and the Dynamic Delegation Discovery
	Service (DDDS)", RFC 3958, January 2005.		Service (DDDS)", RFC 3958, January 2005.
			[6] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
			Specifications: ABNF", RFC 4234, October 2005.
	7.2. Informative References		7.2. Informative References
	[6] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND		[7] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
	FUNCTIONS", RFC 2142, May 1997.		FUNCTIONS", RFC 2142, May 1997.
	[7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.		[8] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
	[8] Mealling, M., "The Network Solutions Personal Internet Name		[9] Mealling, M., "The Network Solutions Personal Internet Name
	(PIN): A URN Namespace for People and Organizations", RFC 3043,		(PIN): A URN Namespace for People and Organizations", RFC 3043,
	January 2001.		January 2001.
	[9] Rozenfeld, S., "Using The ISSN (International Serial Standard		[10] Rozenfeld, S., "Using The ISSN (International Serial Standard
	Number) as URN (Uniform Resource Names) within an ISSN-URN		Number) as URN (Uniform Resource Names) within an ISSN-URN
	Namespace", RFC 3044, January 2001.		Namespace", RFC 3044, January 2001.
	[10] Hakala, J. and H. Walravens, "Using International Standard Book		[11] Hakala, J. and H. Walravens, "Using International Standard Book
	Numbers as Uniform Resource Names", RFC 3187, October 2001.		Numbers as Uniform Resource Names", RFC 3187, October 2001.
	[11] Hoffman, P., "Terminology Used in Internationalization in the		[12] Hoffman, P., "Terminology Used in Internationalization in the
	IETF", RFC 3536, May 2003.		IETF", RFC 3536, May 2003.
	[12] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,		[13] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
	"Uniform Resource Names (URN) Namespace Definition Mechanisms",		"Uniform Resource Names (URN) Namespace Definition Mechanisms",
	BCP 66, RFC 3406, October 2002.		BCP 66, RFC 3406, October 2002.
	[13] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,		[14] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
	December 2004.		December 2004.
	[14] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace		[15] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace
	for the Common Language Equipment Identifier (CLEI) Code",		for the Common Language Equipment Identifier (CLEI) Code",
	RFC 4152, August 2005.		RFC 4152, August 2005.
	[15] Kang, S., "Using Universal Content Identifier (UCI) as Uniform		[16] Kang, S., "Using Universal Content Identifier (UCI) as Uniform
	Resource Names (URN)", RFC 4179, October 2005.		Resource Names (URN)", RFC 4179, October 2005.
	[16] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the		[17] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the
	TV-Anytime Forum", RFC 4195, October 2005.		TV-Anytime Forum", RFC 4195, October 2005.
	[17] Hardie, T., "LoST: A Location-to-Service Translation Protocol",		[18] Hardie, T., "LoST: A Location-to-Service Translation Protocol",
	draft-ietf-ecrit-lost-04 (work in progress), February 2007.		draft-ietf-ecrit-lost-06 (work in progress), August 2007.
	[18] Taylor, T., "Security Threats and Requirements for Emergency		[19] Taylor, T., "Security Threats and Requirements for Emergency
	Call Marking and Mapping", draft-ietf-ecrit-security-threats-03		Call Marking and Mapping", draft-ietf-ecrit-security-threats-04
	(work in progress), July 2006.		(work in progress), April 2007.
	[19] Schulzrinne, H. and R. Marshall, "Requirements for Emergency		[20] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
	Context Resolution with Internet Technologies",		Context Resolution with Internet Technologies",
	draft-ietf-ecrit-requirements-12 (work in progress),		draft-ietf-ecrit-requirements-13 (work in progress),
	August 2006.		March 2007.
	Appendix A. Alternative Approaches Considered		Appendix A. Alternative Approaches Considered
	The discussions of ways to identify emergency calls has yielded a		The discussions of ways to identify emergency calls has yielded a
	number of proposals. Since these are occasionally brought up during		number of proposals. Since these are occasionally brought up during
	discussions, we briefly summarize why this document chose not to		discussions, we briefly summarize why this document chose not to
	pursue these solutions.		pursue these solutions.
	tel:NNN;context=+C This approach uses tel URIs [13]. Here, NNN is		tel:NNN;context=+C This approach uses tel URIs [14]. Here, NNN is
	the national emergency number, where the country is identified by		the national emergency number, where the country is identified by
	the context C. This approach is easy for user agents to implement,		the context C. This approach is easy for user agents to implement,
	but hard for proxies and other SIP elements to recognize, as it		but hard for proxies and other SIP elements to recognize, as it
	would have to know about all number-context combinations in the		would have to know about all number-context combinations in the
	world and track occasional changes. In addition, many of these		world and track occasional changes. In addition, many of these
	numbers are being used for other services. For example, the		numbers are being used for other services. For example, the
	emergency number in Paraguay (00) is also used to call the		emergency number in Paraguay (00) is also used to call the
	international operator in the United States. As another example,		international operator in the United States. As another example,
	A number of countries, such as Italy, use 118 as an emergency		A number of countries, such as Italy, use 118 as an emergency
	number, but it also connects to directory assistance in Finland.		number, but it also connects to directory assistance in Finland.
	tel:sos This solution avoids name conflicts, but is not a valid		tel:sos This solution avoids name conflicts, but is not a valid
	"tel" [13] URI. It also only works if every outbound proxy knows		"tel" [14] URI. It also only works if every outbound proxy knows
	how to route requests to a proxy that can reach emergency services		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		since tel URIs. The SIP URI proposed here only requires a user's
	home domain to be appropriately configured.		home domain to be appropriately configured.
	sip:sos@domain Earlier work had defined a special user identifier,		sip:sos@domain Earlier work had defined a special user identifier,
	sos, within the caller's home domain in a SIP URI, for example,		sos, within the caller's home domain in a SIP URI, for example,
	sip:sos@example.com. Such a user identifier follows the		sip:sos@example.com. Such a user identifier follows the
	convention of RFC 2142 [6] and the "postmaster" convention		convention of RFC 2142 [7] and the "postmaster" convention
	documented in RFC 2822 [7]. This approach had the advantage that		documented in RFC 2822 [8]. This approach had the advantage that
	dial plans in existing user agents could probably be converted to		dial plans in existing user agents could probably be converted to
	generate such a URI and that only the home proxy for the domain		generate such a URI and that only the home proxy for the domain
	has to understand the user naming convention. However, it		has to understand the user naming convention. However, it
	overloads the user part of the URI with specific semantics rather		overloads the user part of the URI with specific semantics rather
	than being opaque, makes routing by the outbound proxy a special		than being opaque, makes routing by the outbound proxy a special
	case that does not conform to normal SIP request-URI handling		case that does not conform to normal SIP request-URI handling
	rules and is SIP-specific. The mechanism also does not extend		rules and is SIP-specific. The mechanism also does not extend
	readily to other services.		readily to other services.
	SIP URI user parameter: One could create a special URI, such as		SIP URI user parameter: One could create a special URI, such as
End of changes. 36 change blocks.
	48 lines changed or deleted		55 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/