draft-ietf-ecrit-service-urn-00.txt		draft-ietf-ecrit-service-urn-01.txt
	SIPPING H. Schulzrinne		SIPPING H. Schulzrinne
	Internet-Draft Columbia U.		Internet-Draft Columbia U.
	Expires: August 19, 2006 February 15, 2006		Expires: September 6, 2006 March 5, 2006
	A Uniform Resource Name (URN) for Services		A Uniform Resource Name (URN) for Services
	draft-ietf-ecrit-service-urn-00		draft-ietf-ecrit-service-urn-01
	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 33		skipping to change at page 1, line 33
	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 August 19, 2006.		This Internet-Draft will expire on September 6, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	The content of many communication services depend on the context,		The content of many communication services depend 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 register such context-dependent services that can be resolved in a		to register such context-dependent services that can be resolved in a
	distributed manner.		distributed manner.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Registration Template . . . . . . . . . . . . . . . . . . . . 4		2. Registration Template . . . . . . . . . . . . . . . . . . . . 4
	3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. SIP Media Feature Tag Registration: Service . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		4. The Service Application Specification . . . . . . . . . . . . 7
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4.1 Application Unique String . . . . . . . . . . . . . . . . 7
	5.1 Normative References . . . . . . . . . . . . . . . . . . . 6		4.2 First Well Known Rule . . . . . . . . . . . . . . . . . . 8
	5.2 Informative References . . . . . . . . . . . . . . . . . . 7		4.3 Valid Databases . . . . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8		4.4 Expected Output . . . . . . . . . . . . . . . . . . . . . 8
	A. Alternative Approaches Considered . . . . . . . . . . . . . . 8		4.5 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		4.6 Services . . . . . . . . . . . . . . . . . . . . . . . . . 8
	Intellectual Property and Copyright Statements . . . . . . . . 10		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
	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 911 in North America,		Examples include emergency services (reached by dialing 911 in North
	112 in Europe), community services and volunteer opportunities (211		America, 112 in Europe), community services and volunteer
	in some regions of the United States),telephone directory and repair		opportunities (211 in some regions of the United States),telephone
	services (411 and 611 in the United States and Canada), government		directory and repair services (411 and 611 in the United States and
	information services (311 in some cities in the United States),		Canada), government information services (311 in some cities in the
	lawyer referral services (1-800-LAWYER), car roadside assistance		United States), lawyer referral services (1-800-LAWYER), car roadside
	(automobile clubs) and pizza delivery services. Unfortunately,		assistance (automobile clubs) and pizza delivery services.
	almost all of them are limited in scope to a single country or		Unfortunately, almost all of them are limited in scope to a single
	possibly a group of countries, such as those belonging to the North		country or possibly a group of countries, such as those belonging to
	American Numbering Plan or the European Union. The same identifiers		the North American Numbering Plan or the European Union. The same
	are often used for other purposes outside that region, making		identifiers are often used for other purposes outside that region,
	accessing such services difficult when users travel or use devices		making accessing such services difficult when users travel or use
	produced outside their home country.		devices produced outside their home country.
	These services are characterized by long-term stability of user-		These services are characterized by long-term stability of user-
	visible identifiers, decentralized administration of the underlying		visible identifiers, decentralized administration of the underlying
	service and a well-defined resolution mechanism. (For example, there		service and a well-defined resolution mechanism. (For example, there
	is no national coordination or call center for 911; rather, various		is no national coordination or call center for "9-1-1" in the United
	local government organizations cooperate to provide this service,		States; rather, various local government organizations cooperate to
	based on jurisdictions.)		provide this service, based on jurisdictions.)
	In this document, we propose a URN namespace that, together with		In this document, we propose a URN namespace that, together with
	resolution protocols beyond the scope of this document, allows to		resolution protocols beyond the scope of this document, allows to
	define such global, well-known services, while distributing the		define such global, well-known services, while distributing the
	actual implementation across a large number of service-providing		actual implementation across a large number of service-providing
	entities. While there are many ways to divide provision of such		entities. While there are many ways to divide provision of such
	services, we focus on geography as a common way to delineate service		services, we focus on geography as a common way to delineate service
	regions. In addition, users can choose different directory providers		regions. In addition, users can choose different directory providers
	that in turn manage how geographic locations are mapped to service		that in turn manage how geographic locations are mapped to service
	providers.		providers.
	skipping to change at page 4, line 7		skipping to change at page 4, line 7
	short cuts or buttons that invoke emergency services, as it would not		short cuts or buttons that invoke emergency services, as it would not
	be practical to manually re-configure the device with local emergency		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		contacts for each city or town a user visits with his or her mobile
	device. Also, such identifiers allow to delegate routing decisions		device. Also, such identifiers allow to delegate routing decisions
	to third parties and mark certain requests as having special		to third parties and mark certain requests as having special
	characteristics while preventing these characteristics to be		characteristics while preventing these characteristics to be
	accidentally invoked on inappropriate requests.		accidentally invoked on inappropriate requests.
	This URN allows to identify services independent of a particular		This URN allows to identify services independent of a particular
	protocol to deliver the services. It may appear in protocols that		protocol to deliver the services. It may appear in protocols that
	allow general URIs, such as SIP [5] request URIs, web pages or		allow general URIs, such as the Session Initiation Protocol (SIP) [5]
	mapping protocols.		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		Existing technologies address the mapping of service identifiers to a
	service for a particular DNS domain (DNS SRV [9], DNS NAPTR [11]) or		service for a particular DNS domain (DNS SRV [13], DNS NAPTR [15]) or
	a local area network (SLP [8]).		a local area network (SLP [12]).
	The tel URI [16] allows to express service codes such as 911 by		We discuss alternative approaches in Appendix A. For example, the
	adding a context parameter, but does not address the problem of		tel URI [20] allows to express service codes such as "911" for
	global validity.		emergency services by adding a context parameter, but does not
			address the problem of global validity.
	LUMP [20] is a prototype resolution system for mapping URNs to URLs		Since service URNs are not routable, a proxy or user agent has to
	based on geographic location. However, it is anticipated that there		translate the service URN into a routable URL for a location-
	will be several such systems.		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		2. 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 [15].		according to RFC 3406 [19].
	Namespace ID: service		Namespace ID: service
	Registration Information: Registration version: 1; registration date:		Registration Information: Registration version: 1; registration date:
	2005-07-10		2005-07-10
	Declared registrant of the namespace: TBD		Declared registrant of the namespace: TBD
	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 IRIs, that used for domain names [1] except that		same as that for domain names [1] except that there is no
	there is no restriction on the first character being a letter;		restriction on the first character being a letter; labels are
	labels are case-insensitive and SHOULD be specified in all lower-		case-insensitive and SHOULD be specified in all lower-case. Any
	case. Any string of service labels can be used to request		string of service labels can be used to request services that are
	services that are either more generic or more specific. In other		either more generic or more specific. In other words, if a
	words, if a service 'x.y.z' exists, the URNs 'x' and 'x.y' are		service 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid
	also valid service URNs.		service URNs.
	"URN:service:" top-level-service *("." service-identifier)		"URN:service:" service
	top-level-service = ALPHA / DIGIT / "-" /		service = top-level-service *("." sub-service)
	service-identifier = ALPHA / DIGIT / "-" /		top-level-service = service-identifier
			sub-service = service-identifier
			service-identifier = 1*(ALPHA / DIGIT / "-")
	Relevant ancillary documentation: None		Relevant ancillary documentation: None
	Community considerations: The service URN is believe to be relevant		Community considerations: The service URN is believe 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 his		particular service in the user's current context, e.g., at his
	current location. For example, a traveler will be able to use his		current location. For example, a traveler will be able to use his
	mobile device to request emergency services without having to know		mobile device to request emergency services without having to know
	the local emergency number. The assignment of identifiers is		the local emergency number. The assignment of identifiers is
	described in the IANA Considerations (Section 4). The service URN		described in the IANA Considerations (Section 5). The service URN
	does not prescribe a particular resolution mechanism, but it is		does not prescribe a particular resolution mechanism, but it is
	assumed that a number of different entities could operate and		assumed that a number of different entities could operate and
	offer such mechanisms. The ECRIT working group is currently		offer such mechanisms. The ECRIT working group is currently
	discussing several approaches, including solutions based on DNS,		discussing several approaches, including solutions based on DNS,
	IRIS and a web-services protocol. Software prototypes for some of		IRIS and a web-services protocol. Software prototypes for some of
	these are currently already available and are believed to be		these are currently already available and are believed to be
	readily developed.		readily developed.
	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., [13],		does not identify documents and protocol objects (e.g., [17],
	[14], [18], [19]), types of telecommunications equipment [17],		[18], [22], [23]), types of telecommunications equipment [21],
	people or organizations [12]. tel URIs [16] identify telephone		people or organizations [16]. tel URIs [20] identify telephone
	numbers, but numbers commonly identifying services, such as 911 or		numbers, but numbers commonly identifying services, such as 911 or
	112, are 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). Resolution of the URN, if successful, will		considerations). Resolution of the URN, if successful, will
	return a particular instance of the service, and this instance may		return a particular instance of the service, and this instance may
	be different even for two users making the same request in the		be different even for two users making the same request in the
	same place at the same time; the logical service identified by the		same place at the same time; the logical service identified by the
	URN, however, is persistent and unique.		URN, however, is persistent and unique.
	Identifier persistence considerations: The 'service' URN for the same		Identifier persistence considerations: The 'service' URN for the same
	skipping to change at page 5, line 48		skipping to change at page 6, line 29
	depend on the service and national regulations. In general, it is		depend on the service and national regulations. In general, it is
	assumed that providers of services can register through a service		assumed that providers of services can register through a service
	mapping mechanism for a particular service in a particular		mapping mechanism for a particular service in a particular
	geographic area. The provision of some services may be restricted		geographic area. The provision of some services may be restricted
	by local or national regulations. (As a hypothetical example,		by local or national regulations. (As a hypothetical example,
	providing emergency services may be restricted to government-		providing emergency services may be restricted to government-
	authorized entities, which may limit the region where each entity		authorized entities, which may limit the region where each entity
	can advertise its services.) The rules for each service are		can advertise its services.) The rules for each service are
	described in a service-specific document.		described in a service-specific document.
	Process for identifier resolution: 'service' identifiers are resolved		Process for identifier resolution: 'service' identifiers are resolved
	by the TBD mapping protocol, an instance of a Resolution Discovery		by the mapping protocols, an instance of a Resolution Discovery
	System (RDS) as described in RFC 2276 [3]. (In theory, there		System (RDS) as described in RFC 2276 [3]. There could be several
	could be several such mapping protocols in concurrent use, as long		such mapping protocols in concurrent use, as long as there are
	as there are reasonable guarantees that all services are available		reasonable guarantees that all services are available in all
	in all mapping protocols.)		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		Rules for Lexical Equivalence: 'service' identifiers are compared
	according to domain name comparison rules. The use of homographic		according to domain name comparison rules. The use of homographic
	identifiers is NOT RECOMMENDED.		identifiers is NOT RECOMMENDED.
	Conformance with URN Syntax: There are no special considerations.		Conformance with URN Syntax: There are no special considerations.
	Validation mechanism: The RDS mechanism is also used to validate the		Validation mechanism: The RDS mechanism is also used to validate the
	existence of a resource. As noted, by its design, the		existence of a resource. As noted, by its design, the
	availability of a resource may depend on where service is desired		availability of a resource may depend on where service is desired
	and there may not be service available in all or most locations.		and there may not be service available in all or most locations.
	(For example, roadside assistance service is unlikely to be		(For example, roadside assistance service is unlikely to be
	available on about 70% of the earth's surface.)		available on about 70% of the earth's surface.)
	Scope: The scope for this URN is public and global.		Scope: The scope for this URN is public and global.
	3. Example		3. SIP Media Feature Tag Registration: Service
	For discussion and illustration purposes only, we include an example		This section is specific to SIP.
	of a particular service. We choose emergency services as an example,
	with the top-level service identifier 'sos'. A possible list of
	identifiers might include:
	urn:service:sos		If a user agent recognizes an emergency call, it inserts the service
	urn:service:sos.fire		URN into the "To" header field of the INVITE request. If a proxy
	urn:service:sos.police		recognizes a call as an emergency call, but the user agent did not,
	urn:service:sos.marine		the To header field will contain another URL, such as a tel or SIP
	urn:service:sos.mountain		URL. As part of the mapping process, the request URI will be
	urn:service:sos.rescue		replaced with the URL of the entity providing the service. Thus, the
	urn:service:sos.poison		INVITE request is no longer recognizable as an emergency call,
	urn:service:sos.suicide		although this is desirable to prevent misuse of authorization bypass
	urn:service:sos.mental-health		for emergency calls and for appropriate policy and priority handling
	urn:service:sos.animal-control		of emergency calls.
	4. IANA Considerations		To address this problem, we propose the use of a new media feature
			tag [8], sip.service, that describe the desired communication
			service.
			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 urn:service:sos.fire becomes fire.sos.example.com.
			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.
			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
			record.
			4.4 Expected Output
			The result of the application is a DNS record for the server to
			contact.
			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
			http://example.com/map/[service], using the LoST [24] protocol.
			example.com.
			; order pref flags service regexp replacement
			IN NAPTR 50 50 "u" "LOST+D2T"
			"!urn:service:(.*)!http://example.com/map/\1!i" .
			5. IANA Considerations
	New service-identifying tokens and sub-registrations are to be		New service-identifying tokens and sub-registrations are to be
	managed by IANA, according to the processes outlined in [4]. The		managed by IANA, according to the processes outlined in [4]. The
	policy for top-level service names is TBD, but could be		policy for top-level service names is 'IETF Consensus'. The policy
	'specification required', 'IETF Consensus' or 'Standards Action'.		for assigning names to sub-services may differ for each top-level
	The policy for assigning names to sub-services may differ for each		service designation and MUST be defined by the document describing
	top-level service designation and MUST be defined by the document		the top-level service.
	describing the top-level service.
	5. References		This section also registers a new SIP media feature tag.
	5.1 Normative References		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
			transportation.
			urn:service:sos.animal-control Animal control is defined as control
			of dogs, cats, and domesticated or undomesticated animals.
			urn:service:sos.fire The 'fire' service identifier summons the fire
			service, also known as the fire brigade or fire department.
			urn:service:sos.gas The 'gas' service allows the reporting of natural
			gas (and other flammable gas) leaks or other natural gas
			emergencies.
			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.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)
			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",		[1] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, November 1987.		STD 13, RFC 1034, November 1987.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[3] Sollins, K., "Architectural Principles of Uniform Resource Name		[3] Sollins, K., "Architectural Principles of Uniform Resource Name
	Resolution", RFC 2276, January 1998.		Resolution", RFC 2276, January 1998.
	[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.		Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
	[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[5] 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.
	[6] Duerst, M. and M. Suignard, "Internationalized Resource		[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.		Identifiers (IRIs)", RFC 3987, January 2005.
	5.2 Informative References		7.2 Informative References
	[7] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND		[10] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
			March 1997.
			[11] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
	FUNCTIONS", RFC 2142, May 1997.		FUNCTIONS", RFC 2142, May 1997.
	[8] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service		[12] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service
	Location Protocol, Version 2", RFC 2608, June 1999.		Location Protocol, Version 2", RFC 2608, June 1999.
	[9] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for		[13] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
	specifying the location of services (DNS SRV)", RFC 2782,		specifying the location of services (DNS SRV)", RFC 2782,
	February 2000.		February 2000.
	[10] Resnick, P., "Internet Message Format", RFC 2822, April 2001.		[14] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
	[11] Mealling, M. and R. Daniel, "The Naming Authority Pointer		[15] Mealling, M. and R. Daniel, "The Naming Authority Pointer
	(NAPTR) DNS Resource Record", RFC 2915, September 2000.		(NAPTR) DNS Resource Record", RFC 2915, September 2000.
	[12] Mealling, M., "The Network Solutions Personal Internet Name		[16] 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.
	[13] Rozenfeld, S., "Using The ISSN (International Serial Standard		[17] 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.
	[14] Hakala, J. and H. Walravens, "Using International Standard Book		[18] 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.
	[15] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,		[19] 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.
	[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,		[20] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
	December 2004.		December 2004.
	[17] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace		[21] 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.
	[18] Kang, S., "Using Universal Content Identifier (UCI) as Uniform		[22] Kang, S., "Using Universal Content Identifier (UCI) as Uniform
	Resource Names (URN)", RFC 4179, October 2005.		Resource Names (URN)", RFC 4179, October 2005.
	[19] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the		[23] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the
	TV-Anytime Forum", RFC 4195, October 2005.		TV-Anytime Forum", RFC 4195, October 2005.
	[20] Schulzrinne, H., "Location-to-URL Mapping Protocol (LUMP)",		[24] Hardie, T., "LoST: A Location-to-Service Translation Protocol",
	draft-schulzrinne-ecrit-lump-01 (work in progress),		draft-hardie-ecrit-lost-00 (work in progress), March 2006.
	October 2005.
			[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		Author's Address
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building		450 Computer Science Building
	New York, NY 10027		New York, NY 10027
	US		US
	Phone: +1 212 939 7004		Phone: +1 212 939 7004
	Email: hgs+ecrit@cs.columbia.edu		Email: hgs+ecrit@cs.columbia.edu
	URI: http://www.cs.columbia.edu		URI: http://www.cs.columbia.edu
	Appendix A. Alternative Approaches Considered		Appendix A. Alternative Approaches Considered
	The "sos" SIP URI reserved user name proposed here follows the		The "sos" SIP URI reserved user name proposed here follows the
	convention of RFC 2142 [7] and the "postmaster" convention documented		convention of RFC 2142 [11] and the "postmaster" convention
	in RFC 2822 [10]. The approach has the advantage that only the home		documented in RFC 2822 [14]. The approach has the advantage that
	proxy for a user needs to understand the convention and that the		only the home proxy for a user needs to understand the convention and
	mechanism is likely backwards-compatible with most SIP user agents,		that the mechanism is likely backwards-compatible with most SIP user
	with the only requirement that they have to be able to generate		agents, with the only requirement that they have to be able to
	alphanumeric URLs. One drawback is that it may conflict with locally		generate alphanumeric URLs. One drawback is that it may conflict
	assigned addresses of the form "sos@domain". Also, if proxies not		with locally assigned addresses of the form "sos@domain". Also, if
	affiliated with the domain translate the URL, they violate the		proxies not affiliated with the domain translate the URL, they
	current SIP protocol conventions.		violate the current SIP protocol conventions.
	There are a number of possible alternatives, each with their own set		There are a number of possible alternatives, each with their own set
	of advantages and problems:		of advantages and problems:
	tel:NNN;context=+C This approach uses tel URIs [16]. Here, NNN is		tel:NNN;context=+C This approach uses tel URIs [20]. 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. A number of		international operator in the United States. A number of
	countries, such as Italy, use 118 as an emergency number, but it		countries, such as Italy, use 118 as an emergency number, but it
	also connects to directory assistance in Finland.		also connects to directory assistance in Finland.
	tel:sos This solution avoids name conflicts, but is not a valid "tel"		tel:sos This solution avoids name conflicts, but is not a valid "tel"
	[16] URI. It also only works if every outbound proxy knows how to		[20] URI. It also only works if every outbound proxy knows how to
	route requests to a proxy that can reach emergency services since		route requests to a proxy that can reach emergency services since
	tel URIs. The SIP URI proposed here only requires a user's home		tel URIs. The SIP URI proposed here only requires a user's home
	domain to be appropriately configured.		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. This approach had the advantage that dial		sip:sos@example.com. This approach had the advantage that dial
	plans in existing user agents could probably be converted to		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
	skipping to change at page 9, line 52		skipping to change at page 14, line 19
	used to identify emergency calls. This has similar properties as		used to identify emergency calls. This has similar properties as
	the "tel:sos" URI, except that it is indeed a valid URI. To make		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		this usable, the special domain would have to be operational and
	point to an appropriate emergency services proxy. Having a		point to an appropriate emergency services proxy. Having a
	single, if logical, emergency services proxy for the whole world		single, if logical, emergency services proxy for the whole world
	seems to have undesirable scaling and administrative properties.		seems to have undesirable scaling and administrative properties.
	Appendix B. Acknowledgments		Appendix B. Acknowledgments
	This document is based on discussions with Jonathan Rosenberg and		This document is based on discussions with Jonathan Rosenberg and
	benefitted from the comments of Benja Fallenstein and Leslie Daigle.		benefitted from the comments of Leslie Daigle, Benja Fallenstein and
			Paul Kyzivat.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
End of changes. 43 change blocks.
	111 lines changed or deleted		331 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/