draft-ietf-ecrit-service-urn-04.txt   draft-ietf-ecrit-service-urn-05.txt 
ECRIT H. Schulzrinne ECRIT H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Expires: February 7, 2007 August 6, 2006 Expires: February 28, 2007 August 27, 2006
A Uniform Resource Name (URN) for Services A Uniform Resource Name (URN) for Services
draft-ietf-ecrit-service-urn-04 draft-ietf-ecrit-service-urn-05
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 February 7, 2007. This Internet-Draft will expire on February 28, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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 context-dependent services that can be resolved in a
skipping to change at page 3, line 44 skipping to change at page 3, line 44
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 us to resolution protocols beyond the scope of this document, allows us 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. There are many ways to divide provision of such services, entities. There are many ways to divide provision of such services,
such as dividing responsibility by geographic region or by the such as dividing responsibility by geographic region or by the
service provider a user chooses. In addition, users can choose service provider a user chooses. In addition, users can choose
different mapping service providers that in turn manage how different mapping service providers that in turn manage how
geographic locations are mapped to service providers. geographic locations are mapped to service providers.
Availability of such service identifiers simplifies end system Availability of such service identifiers allows end systems to convey
configuration. For example, an IP phone could have a special set of information about the desired service to other network entities. For
short cuts, address book entries or buttons that invoke emergency example, an IP phone could have a special set of short cuts, address
services, as it would not be practical to manually re-configure the book entries or buttons that invoke emergency services. When such a
device with local emergency contacts for each city or town a user service identifier is put into the outgoing SIP message, it allows
visits with his or her mobile device. Also, such identifiers make it 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 possible to delegate routing decisions to third parties and to mark
certain requests as having special characteristics while preventing certain requests as having special characteristics while preventing
these characteristics to be accidentally invoked on inappropriate these characteristics from being accidentally invoked.
requests.
This URN identifies services independent of the particular protocol This URN identifies services independent of the particular protocol
that is used to request or deliver the service. The URN may appear that is used to request or deliver the service. The URN may appear
in protocols that allow general URIs, such as the Session Initiation in protocols that allow general URIs, such as the Session Initiation
Protocol (SIP) [5] request URIs, web pages or mapping protocols. Protocol (SIP) [4] request URIs, web pages or mapping protocols.
The service URN is a protocol element and generally not expected to The service URN is a protocol element and generally not expected to
be visible to humans. For example, it is expected that callers will 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. still dial the emergency number '9-1-1' in the United States to reach
In some other cases, speed dial buttons might identify the service, emergency services. In some other cases, speed dial buttons might
as is common practice on hotel phones today. (Speed dial buttons for identify the service, as is common practice on hotel phones today.
summoning emergency help are considered inappropriate by most (Speed dial buttons for summoning emergency help are considered
emergency services professionals, at least for mobile devices, as inappropriate by most emergency services professionals, at least for
they are too prone to being triggered accidentally.) Rather, mobile devices, as they are too prone to being triggered
protocols would carry the service URN described here, allowing accidentally.) Rather, protocols would carry the service URN
universal identification. The translation of dial strings or service described here, allowing universal identification.
numbers to service URNs is beyond the scope of this document; it is
likely to depend on the location of the caller and may be many-to- The translation of service dial strings or service numbers to service
one. For example, a phone for a traveler could recognize the URNs in the end host is beyond the scope of this document. These
emergency number for both the traveler's home location and the translations likely depend on the location of the caller and may be
traveler's visited location, translating both to the same universal 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. 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 [19] is one appropriate service provider, such as a SIP URL. LoST [17] is
resolution system for mapping service URNs to URLs based on expected to be used as a resolution system for mapping service URNs
geographic location. It is anticipated that there will be several to URLs based on geographic location. In the future, there may be
such systems, possibly with different systems for different services. several such protocols, possibly different ones for different
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. Mapping protocols SHOULD always provide a mapping just in Section 3.
for the top-level service even if sub-services are in use. This
mapping for the top-level service MAY also be used if an entity is
presented with an invalid sub-service and presenting an error
condition to the user is inappropriate, e.g., during an emergency.
We discuss alternative approaches for creating service identifiers, 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 [21]. Terminology specific to emergency services is defined in [19].
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 [13]. according to RFC 3406 [12].
Namespace ID: service Namespace ID: service
Registration Information: Registration version: 1; registration date: Registration Information: Registration version: 1; registration date:
2006-04-02 2006-04-02
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 domain names [1] and a subset of the labels same as that for domain names [1] and a subset of the labels
allowed in [6]. Labels are case-insensitive and SHOULD be allowed in [5]. Labels are case-insensitive and MUST be specified
specified in all lower-case. For any given service URN, service- in all lower-case. For any given service URN, service-identifiers
identifiers can be removed right-to-left and the resulting URN is can be removed right-to-left and the resulting URN is still valid,
still valid, referring a more generic service. In other words, if referring a more generic service. In other words, if a service
a service 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid service
service URNs. URNs.
"URN:service:" service "URN:service:" service
service = top-level *("." sub-service) service = top-level *("." sub-service)
let-dig = ALPHA / DIGIT let-dig = ALPHA / DIGIT
let-dig-hyp = let-dig / '-' let-dig-hyp = let-dig / '-'
sub-service = let-dig [ *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 ]
Relevant ancillary documentation: None Relevant ancillary documentation: None
skipping to change at page 6, line 10 skipping to change at page 6, line 10
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., [10], does not identify documents and protocol objects (e.g., [9], [10],
[11], [16], [17]), types of telecommunications equipment [15], [15], [16]), types of telecommunications equipment [14], people or
people or organizations [9]. tel URIs [14] identify telephone organizations [8]. tel URIs [13] identify telephone numbers, but
numbers, but numbers commonly identifying services, such as 911 or numbers commonly identifying services, such as 911 or 112, are
112, are specific to a particular region or country. 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,
described in Section 4. described in Section 4.
Identifier persistence considerations: The 'service' URN for the same Identifier persistence considerations: The 'service' URN for the same
service is expected to be persistent, although there naturally service is expected to be persistent, although there naturally
cannot be a guarantee that a particular service will continue to cannot be a guarantee that a particular service will continue to
be available globally or at all times. be available globally or at all times.
Process of identifier assignment: The process of identifier Process of identifier assignment: The process of identifier
assignment is described in the IANA Considerations (Section 4). assignment is described in the IANA Considerations (Section 4).
Process for identifier resolution: 'service' identifiers are resolved Process for identifier resolution: There is no single global
by mapping protocols, based on the service and the location of the resolution service for 'service' URNs. However, each top-level
person or entity desiring the use of the service. Each top-level service can provide a set of mapping protocols to be used with
service can provide its own distinct set of mapping protocols. 'service' URNs of that service.
Within each top-level service, all mapping protocols MUST return
the same set of mappings. A resolution service is specified in a
separate document.
Rules for Lexical Equivalence: 'service' identifiers are compared 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 syntactic Conformance with URN Syntax: The BNF in the 'Declaration of syntactic
structure' above constrains the syntax for this URN scheme. structure' above constrains the syntax for this URN scheme.
Validation mechanism: Validation determines whether a given string is Validation mechanism: Validation determines whether a given string is
currently a validly-assigned URN [13]. Due to the distributed currently a validly-assigned URN [12]. 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
4.1 New Service-Identifying Labels 4.1 New Service-Identifying Labels
Services and sub-services are identified by labels managed by IANA, Services and sub-services are identified by labels managed by IANA,
according to the processes outlined in [4] in a new registry called according to the processes outlined in [3] in a new registry called
"Service URN Labels". Thus, creating a new service requires IANA "Service URN Labels". Thus, creating a new service requires IANA
action. The policy for adding top-level service labels is 'Standards action. The policy for adding top-level service labels is 'Standards
Action'. (This document defines the top-level service 'sos' and Action'. (This document defines the top-level service 'sos' and
'counseling'.) The policy for assigning labels to sub-services may 'counseling'.) The policy for assigning labels to sub-services may
differ for each top-level service designation and MUST be defined by differ for each top-level service designation and MUST be defined by
the document describing the top-level service. the document describing the top-level service.
Entries in the registration table have the following format Entries in the registration table have the following format
Service Reference Description Service Reference Description
-------------------------------------------------------------------- --------------------------------------------------------------------
foo RFCxyz Brief description of the 'foo' top-level service foo RFCxyz Brief description of the 'foo' top-level service
foo.bar RFCabc Description of the 'foo.bar' service foo.bar RFCabc Description of the 'foo.bar' service
To allow use within the constraints of S-NAPTR [6], all top-level To allow use within the constraints of S-NAPTR [5], all top-level
service names MUST NOT exceed 27 characters. service names MUST NOT exceed 27 characters.
4.2 Sub-Services for the 'sos' Service 4.2 Sub-Services for the 'sos' Service
This section defines the first service registration within the IANA This section defines the first service registration within the IANA
registry defined in Section 4.1, using the top-level service label registry defined in Section 4.1, using the top-level service label
'sos'. 'sos'.
The 'sos' service type describes emergency services requiring an The 'sos' service type describes emergency services requiring an
immediate response, typically offered by various branches of the immediate response, typically offered by various branches of the
skipping to change at page 8, line 38 skipping to change at page 8, line 34
used to apply to search and rescue in other wilderness used to apply to search and rescue in other wilderness
environments. environments.
urn:service:sos.physician The 'physician' emergency service connects urn:service:sos.physician The 'physician' emergency service connects
the caller to a physician referral service. the caller to a physician referral service.
urn:service:sos.poison The 'poison' service refers to special urn:service:sos.poison The 'poison' service refers to special
information centers set up to inform citizens about how to respond information centers set up to inform citizens about how to respond
to potential poisoning. These poison control centers maintain a to potential poisoning. These poison control centers maintain a
database of poisons and appropriate emergency treatment. database of poisons and appropriate emergency treatment.
urn:service:sos.police The 'police' service refers to the police urn:service:sos.police The 'police' service refers to the police
department or other law enforcement authorities. department or other law enforcement authorities.
urn:service:sos.suicide The 'suicide' service refers to the suicide
prevention hotline.
4.3 Sub-Services for the 'counseling' Service 4.3 Sub-Services for the 'counseling' Service
The 'counseling' service type describes services where callers can The 'counseling' service type describes services where callers can
receive advice and support, often anonymous, but not requiring an receive advice and support, often anonymous, but not requiring an
emergency response. (Naturally, such services may transfer callers emergency response. (Naturally, such services may transfer callers
to an emergency service or summon such services if the situation to an emergency service or summon such services if the situation
warrants.) Additional sub-services can be added after expert review warrants.) Additional sub-services can be added after expert review
and should be of general public interest. The expert is chosen in and should be of general public interest. The expert is chosen in
the same manner as describe for the 'sos' service. The expert review the same manner as describe for the 'sos' service. The expert review
skipping to change at page 9, line 20 skipping to change at page 9, line 16
counseling and support services that are specifically tailored to counseling and support services that are specifically tailored to
the needs of children. Such services may, for example, provide the needs of children. Such services may, for example, provide
advice to run-aways or victims of child abuse. advice to run-aways or victims of child abuse.
urn:service:counseling.mental-health The 'mental-health' service urn:service:counseling.mental-health The 'mental-health' service
refers to the "diagnostic, treatment, and preventive care that refers to the "diagnostic, treatment, and preventive care that
helps improve how persons with mental illness feel both physically helps improve how persons with mental illness feel both physically
and emotionally as well as how they interact with other persons." and emotionally as well as how they interact with other persons."
(U.S. Department of Health and Human Services) (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 4.4 Initial IANA Registration
The following table contains the initial IANA registration for The following table contains the initial IANA registration for
emergency and counseling services. emergency and counseling services.
Service Reference Description Service Reference Description
-------------------------------------------------------------------- --------------------------------------------------------------------
counseling RFC XYZ Counseling services counseling RFC XYZ Counseling services
counseling.children RFC XYZ Counseling for children counseling.children RFC XYZ Counseling for children
counseling.mental-health RFC XYZ Mental health counseling counseling.mental-health RFC XYZ Mental health counseling
counseling.suicide RFC XYZ Suicide prevention hotline
sos RFC XYZ Emergency services sos RFC XYZ Emergency services
sos.animal-control RFC XYZ Animal control sos.animal-control RFC XYZ Animal control
sos.fire RFC XYZ Fire service sos.fire RFC XYZ Fire service
sos.gas RFC XYZ Gas leaks and gas emergencies sos.gas RFC XYZ Gas leaks and gas emergencies
sos.marine RFC XYZ Maritime search and rescue sos.marine RFC XYZ Maritime search and rescue
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
sos.suicide RFC XYZ Suicide prevention hotline
[[NOTE TO RFC-EDITOR: Please replace above 'RFC XYZ' reference with
the RFC number of this document and remove this note.]]
5. Internationalization Considerations 5. Internationalization Considerations
The service labels are protocol elements [12] and not normally seen The service labels are protocol elements [11] 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 [20]. detailed in [18].
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
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Sollins, K., "Architectural Principles of Uniform Resource Name [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Resolution", RFC 2276, January 1998.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] 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.
[6] 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.
7.2 Informative References 7.2 Informative References
[7] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND [6] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS", RFC 2142, May 1997. FUNCTIONS", RFC 2142, May 1997.
[8] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9] Mealling, M., "The Network Solutions Personal Internet Name [8] 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.
[10] Rozenfeld, S., "Using The ISSN (International Serial Standard [9] 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.
[11] Hakala, J. and H. Walravens, "Using International Standard Book [10] 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.
[12] Hoffman, P., "Terminology Used in Internationalization in the [11] Hoffman, P., "Terminology Used in Internationalization in the
IETF", RFC 3536, May 2003. IETF", RFC 3536, May 2003.
[13] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, [12] 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.
[14] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, [13] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004. December 2004.
[15] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace [14] 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.
[16] Kang, S., "Using Universal Content Identifier (UCI) as Uniform [15] Kang, S., "Using Universal Content Identifier (UCI) as Uniform
Resource Names (URN)", RFC 4179, October 2005. Resource Names (URN)", RFC 4179, October 2005.
[17] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the [16] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the
TV-Anytime Forum", RFC 4195, October 2005. TV-Anytime Forum", RFC 4195, October 2005.
[18] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [17] Hardie, T., "LoST: A Location-to-Service Translation Protocol",
Methodology for Network Address Translator (NAT) Traversal for draft-ietf-ecrit-lost-00 (work in progress), June 2006.
Offer/Answer Protocols", draft-ietf-mmusic-ice-09 (work in
progress), June 2006.
[19] Hardie, T., "LoST: A Location-to-Service Translation Protocol",
draft-hardie-ecrit-lost-00 (work in progress), March 2006.
[20] Taylor, T., "Security Threats and Requirements for Emergency [18] 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-03
(work in progress), July 2006. (work in progress), July 2006.
[21] Schulzrinne, H. and R. Marshall, "Requirements for Emergency [19] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-10 (work in progress), June 2006. draft-ietf-ecrit-requirements-11 (work in progress),
August 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 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 [14]. Here, NNN is tel:NNN;context=+C This approach uses tel URIs [13]. 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" tel:sos This solution avoids name conflicts, but is not a valid "tel"
[14] URI. It also only works if every outbound proxy knows how to [13] 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. Such a user identifier follows the sip:sos@example.com. Such a user identifier follows the
convention of RFC 2142 [7] and the "postmaster" convention convention of RFC 2142 [6] and the "postmaster" convention
documented in RFC 2822 [8]. This approach had the advantage that documented in RFC 2822 [7]. 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 "aor- SIP URI user parameter: One could create a special URI, such as "aor-
 End of changes. 44 change blocks. 
93 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/