< draft-polk-dhc-uri-02.txt   draft-polk-dhc-uri-03.txt >
DHC Working Group James Polk DHC Working Group James Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration: April 24th, 2006 October 24th, 2005 Expiration: Sept 6th, 2006 March 6th, 2006
File: draft-polk-dhc-uri-02.txt File: draft-polk-dhc-uri-03.txt
A Dynamic Host Configuration Protocol Option for A Dynamic Host Configuration Protocol Option for
Requesting and Receiving Uniform Resource Identifiers Requesting and Receiving Uniform Resource Identifiers
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.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of 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 April 24th, 2006. This Internet-Draft will expire on Sept 6th, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines a new Dynamic Host Configuration Protocol This document defines a new Dynamic Host Configuration Protocol
(DHC) Option to allow one or more URIs to be transmitted from a (DHC) Option to allow one or more URIs to be transmitted from a
server to a client within one or more messages, and for one or more server to a client within one or more messages, and for one or more
URIs, each with a unique purpose, to be specifically requested by a URIs, each with a unique purpose, to be specifically requested by a
client of a server. Included in this Option is a purpose field to client of a server. Included in this Option is a purpose field to
identify the type of URI being requested by the client, or the type identify the type of URI being requested by the client, or the type
of URI in the DHCP message from the server. of URI in the DHCP message from the server.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions used in this document . . . . . . . . . . . . 4 1.1 Conventions used in this document . . . . . . . . . . . . 4
1.2 Terms, Acronyms and Definitions . . . . . . . . . . . . . 4 1.2 Terms, Acronyms and Definitions . . . . . . . . . . . . . 4
1.3 What Changed from Previous Versions . . . . . . . . . . . 5 1.3 What Changed from Previous Versions . . . . . . . . . . . 5
2. DHC Relay Option Format . . . . . . . . . . . . . . . . . . . 5 2. DHC Relay Option Format . . . . . . . . . . . . . . . . . . . 6
2.1 Rules of Usage . . . . . . . . . . . . . . . . . . . . . 6 2.1 Rules of Usage . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Multiple URIs in a message . . . . . . . . . . . . . . . 8 2.2 Multiple URIs in a message . . . . . . . . . . . . . . . . 8
2.3 Requesting a URI of a Server. . . . . . . . . . . . . . . 8 2.3 Requesting a URI of a Server . . . . . . . . . . . . . . . 9
3. Purposes of Different URI Types . . . . . . . . . . . . . . . 9 3. Purposes of Different URI Types . . . . . . . . . . . . . . . 9
3.1 Primary SIP/SIPS URI of Public Safety Answering Point . . 9 3.1 Primary SIP/SIPS URI of Public Safety Answering Point . . 10
3.2 Secondary SIP/SIPS URI of Public Safety Answering Point . 9 3.2 Secondary SIP/SIPS URI of Public Safety Answering Point . 10
3.3 Client's Location By-Reference URI . . . . . . . . . . . 10 3.3 Client's Location By-Reference URI . . . . . . . . . . . . 10
3.4 SIP/SIPS URI of Emergency Services Gateway (ESGW) . . . . 10 3.4 SIP/SIPS URI of Emergency Services Gateway (ESGW) . . . . 10
3.5 SIP/SIPS URI of Emergency Services Routing Proxy (ESRP) . 10 3.5 SIP/SIPS URI of Emergency Services Routing Proxy (ESRP) . 11
3.6 URI of Organization Providing LCI . . . . . . . . . . . . 11 3.6 URI of Organization Providing LCI . . . . . . . . . . . . 11
3.7 URI for Geocoding or Reverse Geocoding Function . . . . . 11 3.7 URI for Geocoding or Reverse Geocoding Function . . . . . 12
3.8 Primary URI for Geo Mapping Service . . . . . . . . . . . 11 3.8 Primary URI for Geo Mapping Service . . . . . . . . . . . 12
3.9 Secondary URI for Geo Mapping Service . . . . . . . . . . 11 3.9 Secondary URI for Geo Mapping Service . . . . . . . . . . 12
3.10 Primary URI for Civic Mapping Service . . . . . . . . . . 11 3.10 Primary URI for Civic Mapping Service . . . . . . . . . . 12
3.11 Secondary URI for Civic Mapping Service . . . . . . . . . 12 3.11 Secondary URI for Civic Mapping Service . . . . . . . . . 13
4. Open Items for Discussion . . . . . . . . . . . . . . . . . . 12 4. Open Items for Discussion . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Operational Considerations . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8.1 Normative References . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.2 Informative References . . . . . . . . . . . . . . . . . 14 9.1 Normative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . 14 9.2 Informative References . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . 16
1. Introduction 1. Introduction
There are times in which a Uniform Resource Identifier (URI) is an There are times in which a Uniform Resource Identifier (URI) is an
essential part of configuration information necessary for usage by essential part of configuration information necessary for usage by
an endpoint (client) for the particular purpose of contacting what an endpoint (client) for the particular purpose of contacting what
is at that URI. This document defines a new Dynamic Host is at that URI. This document defines a new Dynamic Host
Configuration Protocol (DHC) Option [RFC 2131] to allow URIs of Configuration Protocol (DHC) Option [RFC 2131] to allow URIs of
specific types, or purposes, to be requested by a client of a specific types, or purposes, to be requested by a client of a
server, and transmitted unrequested from a server to a client. server, and transmitted unrequested from a server to a client.
Because URIs can be used for many purposes, and to ensure Because URIs can be used for many purposes, and to ensure
extensibility, this client option has a sub-option "purpose" field extensibility, this client option has a sub-option "purpose" field
to identify the type of URI included in the message. to identify the type of URI included in an Option.
This document specifies one DHCP Option for all URIs, allowing up to This document specifies one DHCP Option for all URIs, allowing up to
255 uniquely identified URIs to be defined as sub-options. The 255 uniquely identified types of URIs to be defined as sub-options.
format for this comes from [RFC3396]. This document will IANA The format for this comes from [RFC3396]. This document will IANA
Register each purpose URI for interoperability. Register each type of URI for interoperability.
This document does not limit the means of an client from gaining This document does not limit the means of an client from gaining
knowledge of a URI to DHCP, but provides DHCP as a means for a knowledge of a URI to DHCP, but provides DHCP as a means for a
client to gain knowledge of a URI or series of URIs determined client to gain knowledge of a URI or series of URIs determined
through local configuration, that are considered essential for use through local configuration, that are considered essential for use
by applications within that client. The decision of when one or by applications within that client. The decision of when one or
more URIs are essential MAY be made at client boot-up, or when a more URIs are essential can be made at client boot-up, or when a
particular application launches. particular application launches.
One example of this URI download could be one specifically for the One example of this URI download could be one specifically for the
SIP or SIPS URI of the appropriate Public Safety Answer Point (PSAP) SIP(S) URI of the appropriate Public Safety Answer Point (PSAP)
for the client when the user calls for emergency help (911 or 112- for the client when the user calls for emergency help (911 or 112-
type of help). Emergency calling is highly localized in nature, and type of help). Emergency calling is highly localized in nature, and
requires knowledge of where the caller is. DHCP in [RFC3825] requires knowledge of where the caller is. DHCP in [RFC3825]
already provides this level of knowledge to a client, and can, at already provides this level of knowledge to a client, and can, at
the same time, perhaps in the same packet, provide that client with the same time, perhaps in the same packet, provide that client with
its emergency SIP or SIPS URI. its emergency SIP(S) URI. For additional context, see [ID-MAPPING]
for where this DHCP Option can fit into the larger architecture of
an emergency services infrastructure.
Examples of Link Providers are DSL providers with known endpoints of Examples of Link Providers are DSL providers with known endpoints of
their cabling infrastructure, Hybrid Fiber Coax (HFC) Cable their cabling infrastructure, Hybrid Fiber Coax (HFC) Cable
providers with knowledge of where their logical endpoints are, and providers with knowledge of where their logical endpoints are, and
small or large enterprise infrastructures. The DSL or HFC Cable small or large enterprise infrastructures. The DSL or HFC Cable
providers are not limited in this context to a single client at the providers are not limited in this context to a single client at the
subscriber's endpoint, but could have few to many clients being subscriber's endpoint, but could have a few to many clients being
served by an access device of those infrastructures, all with a served by an access device of those infrastructures, all with a
common need for the particular URI, or series of URIs. common need for the particular URI, or series of URIs. A small
business with a single connection is an example of this. It could
be the case what all devices within this small office could need the
same URIs to access the same services.
A client may request more than one URI be sent to it within the same A client may request more than one URI be sent to it within the same
DHCPDISCOVER or DHCPREQUEST message. Each URI will be inside its DHCPDISCOVER or DHCPREQUEST message. Each URI will be inside its
own payload container with an Option number, a length field and a own payload container within the DHCP URI Option, with a purpose
purpose field. This means that if more than one URI is being field indicating what type of URI it is. This means that more than
requested or downloaded, there can be more than one DHCP Option XXX one URI can be requested or downloaded in one DHCP Option XXX (this
(this document's option number) in the same IP message. Each URI document's option number) in the same IP message. Each URI
will be inside the DHCP Option payload shown in section 2 of this will be inside the DHCP Option payload shown in section 2 of this
document. There is no meaning to the order of URIs in a message. document. There is no order to the URIs in a message.
Awareness of how stale a URI may become is something local Awareness of how stale a URI may become is something local
administrators should consider when implementing this Option. DHCP administrators should consider when implementing this Option. For
servers are assumed to periodically query an authoritative source this particular Option, DHCP servers are assumed to periodically
providing non-stale URIs. How this is accomplished is most likely query an authoritative source providing non-stale or updated URIs.
not through the use of DHCP and is out of scope for this document. How this is accomplished is out of scope for this document.
Section 1.2 reviews the terminology and acronyms used in this Section 1.2 reviews the terminology and acronyms used in this
document that are fairly new to DHCP. Section 2.1 discusses the document that are fairly new to DHCP. Section 2.1 discusses the
rules of usage of this Option. Section 3 lists the unique numbering rules of usage of this Option. Section 3 lists the unique numbering
of the purpose fields to the purpose type that is explained in of the purpose fields to the purpose type that is explained in
section 3.1 - 3.11. Section 4 discusses open issues to be section 3.1 - 3.11. Section 4 discusses open issues to be
addressed. Section 5 is the IANA Considerations section of this DHCP addressed. Section 5 is the IANA Considerations section of this DHCP
Option as well as the purpose field sub-options. Option as well as the purpose field sub-options. Section 6 adds an
Operational Considerations section that was brought up during the
This document does not specify using DHCP in a Location Context last IETF meeting.
Mapping System (LCMS), in which DHCP would be used in a
Request/Response fashion to transmit the location of a client by the
client to the DHCP server to have that information mapped to a
PSAP's jurisdiction, resulting in a specific URI in the DHCP
response.
1.1 Conventions used in this document 1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119]. document are to be interpreted as described in [RFC 2119].
1.2 Terms, Acronyms and Definitions 1.2 Terms, Acronyms and Definitions
The following terms and acronyms are used within this document: The following terms and acronyms are used within this document:
skipping to change at page 4, line 53 skipping to change at page 5, line 4
to the client to the client
Internet Attachment Provider - Provides layer 3 connectivity to the Internet Attachment Provider - Provides layer 3 connectivity to the
Internet to a client directly, or indirectly through another Internet to a client directly, or indirectly through another
organization such as an Enterprise network organization such as an Enterprise network
Link Provider - Provides the MAC layer communications link to the Link Provider - Provides the MAC layer communications link to the
client client
PSAP - Public Safety Answering Point PSAP - Public Safety Answering Point
Public Safety Answering Point - the emergency response call center Public Safety Answering Point - the emergency response call center
talking the local emergency calls from people in distress. This talking the local emergency calls from people in distress. This
facility can be logical, and can transfer (reroute) any request facility can be logical, and can transfer (reroute) any request
sent to it to another facility deemed more appropriate to receive sent to it to another facility deemed more appropriate to receive
the request. the request.
1.3 What Changed from Previous Versions 1.3 What Changed from Previous Versions
This is a list of the changes between versions of this document. This is a list of the changes between versions of this document.
From the individual -01 version to the individual -01 version there From the individual -02 version to the individual -03 version there
were the following changes:
- offered an external applicability statement for URI purpose=1, a
PSAP-URI, in [ID-MAPPING].
- clarified how concatenation functions according to RFC 3396
- Added an Operational Considerations Section (6) as was asked for
in Vancouver.
- rearranged the URI purposes into one group dealing with emergency
services and another dealing with location.
- subtle modifications to text here and there
From the individual -01 version to the individual -02 version there
were the following changes: were the following changes:
- clarified some acronyms and definitions - clarified some acronyms and definitions
- clarified how RFC 3396 and concatenation can be used - allowing - clarified how RFC 3396 and concatenation can be used - allowing
back in some of what was taken out in the -01 version back in some of what was taken out in the -01 version
From the individual -00 version to the individual -01 version there From the individual -00 version to the individual -01 version there
were the following changes: were the following changes:
skipping to change at page 6, line 24 skipping to change at page 6, line 40
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+--(This is a second instance of a URI that MAY be in the message;) +--(This is a second instance of a URI that MAY be in the message;)
(See the section 2.2) (See the section 2.2)
Figure 1. The URI Option Format Figure 1. The URI Option Format
Code = The IANA Assigned Option number Code = The IANA Assigned Option number
Length = This is a variable length value of the number of bytes Length = one octet providing a variable length value of the
in the Option, including this length field number of bytes in the Option, including this length
field
URI Purpose = This is what the URI is used for by applications URI Purpose = one octet providing the URI type in this sub-option to
within the client be used by applications within the client
URI Length = The length of the URI associated with a particular URI Length = one octet providing the length of the URI associated
purpose, whether or not there are any other URIs in with a particular purpose, whether or not there are
the IP packet any other URIs in the message
URI = This is a variable length field containing the URI URI = This is a variable length field containing the URI
being transmitted, to a maximum of 253 bytes in length being transmitted, to a maximum of 253 bytes in length
2.1 Rules of Usage 2.1 Rules of Usage
The following are the rules of usage of this DHCP Option: The following are the rules of usage of this DHCP Option:
- Each DHCP Option compliant with this document will have the same - Each DHCP Option compliant with this document will have the same
Option number Option number
skipping to change at page 7, line 24 skipping to change at page 7, line 43
- [RFC2131] limits the size of any one Option to 255 bytes, and - [RFC2131] limits the size of any one Option to 255 bytes, and
allows for a DHCP message to be at least 576 bytes. Therefore, if allows for a DHCP message to be at least 576 bytes. Therefore, if
the aggregate byte count of all URIs (plus purpose and length the aggregate byte count of all URIs (plus purpose and length
bytes) is greater than 255 bytes, RFC 3396 rules apply here in bytes) is greater than 255 bytes, RFC 3396 rules apply here in
which there would be more than one instance of this DHCP Option in which there would be more than one instance of this DHCP Option in
the same message and each DHCP message would be concatenated into the same message and each DHCP message would be concatenated into
a single message prior to processing. In this case, as [RFC 3396] a single message prior to processing. In this case, as [RFC 3396]
states, there can be more total bytes of this one Option than the states, there can be more total bytes of this one Option than the
255 byte limit. Section 2.2 provides an example of this. 255 byte limit. Section 2.2 provides an example of this.
[RFC3396 clearly states that the end of a fragmented option can be
at a place other than the end of a URI here, because the whole
DHCP option is concatenated prior to processing by the recipient.
- If consecutive DHCP messages have this Option, and these messages - If consecutive DHCP messages have this Option, and these messages
contain another instance of a particular purpose identifier, each contain another instance of a particular purpose identifier, each
instance is to be considered a replacement for what has been instance is to be considered a replacement for what has been
received already by the client. received already by the client.
- Clients making a request for one or more URIs will send a - Clients making a request for one or more URIs will send a
message to the Server with URI length fields set to zero message to the Server with URI length fields set to zero
- Clients MUST NOT request the same purpose more than once in the - Clients MUST NOT request the same purpose more than once in the
skipping to change at page 8, line 33 skipping to change at page 9, line 4
fields is not two bytes less than the Option Length field value, the fields is not two bytes less than the Option Length field value, the
DHCP entity knows there is at least one more URI in this message. DHCP entity knows there is at least one more URI in this message.
This process continues until the byte counts match, or they do not - This process continues until the byte counts match, or they do not -
which means there is an length error. which means there is an length error.
Here is the conceptual format of such a message (where XXX is this Here is the conceptual format of such a message (where XXX is this
Option) that is 253 bytes or less in aggregate length: Option) that is 253 bytes or less in aggregate length:
[code=XXX] [length] [purpose] [uri length] [uri text] [purpose] [uri [code=XXX] [length] [purpose] [uri length] [uri text] [purpose] [uri
length] [uri text] [purpose] [uri length] [uri text] [etc] length] [uri text] [purpose] [uri length] [uri text] [etc]
If the aggregate of the URIs are more than 255 bytes, this would be If the aggregate of the URIs are more than 255 bytes, this would be
a conceptual format for a message (where XXX is this Option): a conceptual format for a message (where XXX is this Option):
[code=XXX] [length] [purpose] [uri length] [uri text] [purpose] [uri [code=XXX] [length] [purpose] [uri length] [uri text] [purpose] [uri
length] [uri text] [code=XXX] [length] [purpose] [uri length] [uri length] [uri text] [code=XXX] [length] [purpose] [uri length] [uri
text] [purpose] [uri length] [uri text] [purpose] [uri length] [uri text] [purpose] [uri length] [uri text] [purpose] [uri length] [uri
text] [etc] text] [etc]
The above is a clean version of complete URIs into separate blocks
of 255 bytes. [RFC3396] states this is not necessary, as the
recipient will concatenate consecutive option blocks prior to
processing for maximum efficiency.
2.3 Requesting a URI of a Server 2.3 Requesting a URI of a Server
Clients can request one or more URIs of a server. Here is the Clients can request one or more URIs of a server. Here is the
pseudo-format of such a request: pseudo-format of such a request:
[code] [length] [purpose] [uri length=0] [purpose] [uri Length=0] [code] [length] [purpose] [uri length=0] [purpose] [uri Length=0]
[purpose] [uri length=0] [etc...] [purpose] [uri length=0] [etc...]
The client builds a proper message and zeros out the uri-length The client builds a proper message and zeros out the uri-length
fields and does not include anything in the uri fields. There is no fields and does not include anything in the uri fields. There is no
skipping to change at page 9, line 44 skipping to change at page 10, line 19
Others can be added based on discussion of this document. Others can be added based on discussion of this document.
3.1 Primary SIP/SIPS URI of Public Safety Answering Point (PSAP) 3.1 Primary SIP/SIPS URI of Public Safety Answering Point (PSAP)
This purpose=1 URI is the primary URI used by a SIP [RFC3261] This purpose=1 URI is the primary URI used by a SIP [RFC3261]
enabled element in the Request-URI field for the appropriate PSAP enabled element in the Request-URI field for the appropriate PSAP
for this client when the SIP user agent (UA) is attempting to call for this client when the SIP user agent (UA) is attempting to call
for emergency help (such as the police or ambulance). for emergency help (such as the police or ambulance).
In many cases, the SIP(S)-URI for the ESRP (purpose=4) will be
considered the same as the SIP(S)-URI for the PSAP (purpose=1). The
client will not know the difference. Why this is not different to
the client is because the ESRP should be the edge boundary of an
emergency services network that will be able to do its own
processing and message routing to the appropriate PSAP. The goal in
these cases was just to get the session set-up message to this
stage.
3.2 Secondary SIP/SIPS URI of Public Safety Answering Point (PSAP) 3.2 Secondary SIP/SIPS URI of Public Safety Answering Point (PSAP)
Related to Purpose=1. This purpose=2 URI is the secondary or backup Related to Purpose=1. This purpose=2 URI is the secondary or backup
SIP or SIPS URI of same PSAP facility or of another PSAP facility to SIP or SIPS URI of same PSAP facility or of another PSAP facility to
be used when the primary URI fails to connect, due to a timeout or a be used when the primary URI fails to connect, due to a timeout or a
SIP final failure message. This SHOULD NOT be used if the initial SIP final failure message. This SHOULD NOT be used if the initial
attempt to contact the PSAP fails for any reason, as many failures attempt to contact the PSAP fails for any reason, as many failures
are recoverable within SIP [RFC 3261]. In fact, many non-successful are recoverable within SIP [RFC 3261]. In fact, many non-successful
responses are not uncommon in SIP before a transaction is responses are not uncommon in SIP before a transaction is
successfully responded to. successfully responded to.
3.3 Client's Location By-Reference URI 3.3 SIP/SIPS URI of Emergency Services Gateway (ESGW)
This purpose=3 URI is the pointer to the client's by-reference
location on a server external to the client [ID-SIP-LOC]. Location
of a client can be signified in two ways:
by-value - meaning the client possesses its location information
locally, and
by-reference - meaning the client's location information is
stored on a remote element such as a server.
Storing location information by-reference external to the client may
be for many reasons, including because the client does not know how
to store its location, because the client chooses to store it
remotely for a URI reference to be given to others to save bandwidth
during transmission, or because a service provider may decide to
keep this information from the client by-value. If the client knows
where its location is by-reference, it merely needs to provide that
reference to another entity when it decides to reveal where it is.
This URI is the retrieval identifier for a protocol to fetch the
client's location from. Examples of usable protocols are: HTTP,
SIP, etc.
3.4 SIP/SIPS URI of Emergency Services Gateway (ESGW)
This purpose=4 URI is for the Emergency Services Gateway that an IP This purpose=4 URI is for the Emergency Services Gateway that an IP
client would contact when setting up an emergency call with a PSAP client would contact when setting up an emergency call with a PSAP
that is not IP enabled. Having this information locally in the that is not IP enabled. Having this information locally in the
client will allow it to contact the ESGW directly and not have to client will allow it to contact the ESGW directly and not have to
rely on an intermediary to determine which ESGW is the right one for rely on an intermediary to determine which ESGW is the right one for
this client, and possibly fail the call set-up during that this client, and possibly fail the call set-up during that
determination. determination.
3.5 SIP/SIPS URI of Emergency Services Routing Proxy (ESRP) 3.4 SIP/SIPS URI of Emergency Services Routing Proxy (ESRP)
This purpose=5 URI is for the Emergency Services Routing Proxy that This purpose=5 URI is for the Emergency Services Routing Proxy that
is tasked with determining which PSAP the client needs to contact is tasked with determining which PSAP the client needs to contact
when attempting to establish a call with a PSAP. In SIP for when attempting to establish a call with a PSAP. In SIP for
example, not all SIP Proxies or intermediaries are expected to have example, not all SIP Proxies or intermediaries are expected to have
knowledge of how to determine which is the appropriate PSAP of a knowledge of how to determine which is the appropriate PSAP of a
client based on where the client is located. There may be difficult client based on where the client is located. There may be difficult
in a non-updated SIP intermediary in this determination, even in in a non-updated SIP intermediary in this determination, even in
determining which SIP intermediary knows how to do this function. determining which SIP intermediary knows how to do this function.
This SIP/SIPS URI is the Request-URI of such a SIP intermediary that This SIP/SIPS URI is the Request-URI of such a SIP intermediary that
knows how to determine which is the correct PSAP given the included knows how to determine which is the correct PSAP given the included
PIDF-LO [ID-SIP-LOC] in the session set-up message (the SIP INVITE) PIDF-LO [ID-SIP-LOC] in the session set-up message (the SIP INVITE)
to that intermediary. to that intermediary.
In many cases, the SIP(S)-URI for the ESRP (purpose=4) will be
considered the same as the SIP(S)-URI for the PSAP (purpose=1). The
client will not know the difference. Why this is not different to
the client is because the ESRP should be the edge boundary of an
emergency services network that will be able to do its own
processing and message routing to the appropriate PSAP. The goal in
these cases was just to get the session set-up message to this
stage.
3.5 Client's Location By-Reference URI
This purpose=3 URI is the pointer to the client's by-reference
location on a server external to the client [ID-SIP-LOC]. Location
of a client can be signified in two ways:
by-value - meaning the client possesses its location information
locally, and
by-reference - meaning the client's location information is
stored on a remote element such as a server.
Storing location information by-reference external to the client may
be for many reasons, including because the client does not know how
to store its location, because the client chooses to store it
remotely for a URI reference to be given to others to save bandwidth
during transmission, or because a service provider may decide to
keep this information from the client by-value. If the client knows
where its location is by-reference, it merely needs to provide that
reference to another entity when it decides to reveal where it is.
This URI is the retrieval identifier for a protocol to fetch the
client's location from. Examples of usable protocols are: HTTP,
SIP, etc.
3.6 URI of Organization Providing Location Configuration Information 3.6 URI of Organization Providing Location Configuration Information
This purpose=6 URI is the organization that provided location This purpose=6 URI is the organization that provided location
configuration information (LCI) to the DHCP client. In building a configuration information (LCI) to the DHCP client. In building a
proper XML Location Message Body [ID-PIDF-LO], the location proper XML Location Message Body [RFC4119], the location
generator [RFC 3693] will include a <provided-by> element indicating generator [RFC 3693] will include a <provided-by> element indicating
which organization was responsible for delivering this location which organization was responsible for delivering this location
information to the client. This URI is used to populate this information to the client. This URI is used to populate this
<provided-by> element without further interaction. <provided-by> element without further interaction.
3.7 URI for Geocoding or Reverse Geocoding Function 3.7 URI for Geocoding or Reverse Geocoding Function
This purpose=7 URI of a server that can perform a geocoding or This purpose=7 URI of a server that can perform a geocoding or
reverse geocoding function. DHCP has the ability to provide reverse geocoding function. DHCP has the ability to provide
Location Configuration Information to a client in the geo format Location Configuration Information to a client in the geo format
skipping to change at page 12, line 31 skipping to change at page 13, line 27
This transmission of client location to the secondary mapping server This transmission of client location to the secondary mapping server
that includes the request to map this location to the appropriate that includes the request to map this location to the appropriate
PSAP for that location is done with another protocol, and not DHCP. PSAP for that location is done with another protocol, and not DHCP.
4. Open Items for Discussion 4. Open Items for Discussion
There are several open items that need to be addressed in following There are several open items that need to be addressed in following
versions of this ID (if it moves forward). versions of this ID (if it moves forward).
#1 - There is an open question as to whether a URI will ever need to #1 - A proposal: to answer Stig's open question during the Vancouver
be longer than 255 bytes (getting into concatenation-required meeting about "not just having an open ended Option in DHCP".
language) These URIs in this ID are in two groups, Location and Emergency
services. Should this effort call for two Options to be
created, each with a specific topic of coverage?
#2 - whether or not to include more applicability statements in this
doc, or to merely reference them - and - how this would change
if the proposal above is agreed to?
#3 - The author needs help understanding the nuances of unsolicited
DHCP messaging to the client.
5. IANA Considerations 5. IANA Considerations
IANA has assigned a DHCP option code of [XXX] for the URI option IANA has assigned a DHCP option code of [XXX] for the URI option
defined in this document. defined in this document.
This URI Option defines one field for which IANA maintains a This URI Option defines one field for which IANA maintains a
registry: the Purpose field (see Section 2). The initial values of registry: the Purpose field (see Section 2). The initial values of
the Purpose registry are as follows: the Purpose registry are as follows:
Purpose Description Reference Purpose Description Reference
------- ------------ --------- ------- ------------ ---------
1 Primary PSAP URI [This RFC] 1 Primary PSAP URI [This RFC]
2 Secondary PSAP URI [This RFC] 2 Secondary PSAP URI [This RFC]
3 Location By-Reference URI of Client [This RFC] 3 ESGW URI of Client [This RFC]
4 ESGW URI of Client [This RFC] 4 ESRP URI of Client [This RFC]
5 ESRP URI of Client [This RFC] 5 Location By-Reference URI of Client [This RFC]
6 Organization Providing Location for Client [This RFC] 6 Organization Providing Location for Client [This RFC]
7 URI of Geocoding/Reverse Geocoding [This RFC] 7 URI of Geocoding/Reverse Geocoding [This RFC]
8 Primary URI of Geo Mapping Service [This RFC] 8 Primary URI of Geo Mapping Service [This RFC]
9 Secondary URI of Geo Mapping Service [This RFC] 9 Secondary URI of Geo Mapping Service [This RFC]
10 Primary URI of Civic Mapping Service [This RFC] 10 Primary URI of Civic Mapping Service [This RFC]
11 Secondary URI of Civic Mapping Service [This RFC] 11 Secondary URI of Civic Mapping Service [This RFC]
IANA registration of new purpose field values MUST be done in a IANA registration of new purpose field values MUST be done in a
standards track RFC. standards track RFC.
6. Security Considerations 6. Operational Considerations
The types of URIs called for within this document can be divided up
into two technology areas: location related (nearest the Geopriv WG
activities) and emergency services related (nearest the ECRIT WG
activities). Each of the URI groups are here to provide information
to a client from the access provider, due to their relationship with
the client - through an implicit or explicit contract for
connectivity. Each of these two groups of URIs are best served by a
service domain that understands the location of the client, or has
implicit knowledge of roughly where the client is from their
connection to the provider.
Supporting an emergency services network means critical information
is right the first time. What is not envisioned here is that DHCP
would be the primary means of message routing an emergency call
set-up, for example a SIP INVITE message to the appropriate PSAP.
DHCP is envisioned to mostly be the backup mechanism, in case the
primary mechanism fails. No one hopes the primary means fails, but
it will on occasion. It is possible that in small cases, DHCP is
considered the best means for a client to learn this information.
This places a burden on the DHCP administrators for valid
information during device boot-times.
Operational considerations for a location service is something DHCP
already has agreed to with the support of RFC 3825 [RFC3825] and the
Civic Location ID [ID-CIVIC].
[NOTE - the author is open to text being sent to modify the above,
or to be added to help with this section]
7. Security Considerations
Where critical decisions might be based on the value of this URI Where critical decisions might be based on the value of this URI
option, DHCP authentication in [RFC3118] SHOULD be used to protect option, DHCP authentication in [RFC3118] SHOULD be used to protect
the integrity of the DHCP options. the integrity of the DHCP options.
Since there is no privacy protection for DHCP messages, an Since there is no privacy protection for DHCP messages, an
eavesdropper who can monitor the link between the client and eavesdropper who can monitor the link between the client and
destination DHCP server to capture any URIs in transit. destination DHCP server to capture any URIs in transit.
When implementing a DHC server that will serve clients across an When implementing a DHC server that will serve clients across an
skipping to change at page 13, line 37 skipping to change at page 15, line 23
There is a risk of old information being provided by this Option. There is a risk of old information being provided by this Option.
Although many wish the Internet to be truly dynamic in its updates Although many wish the Internet to be truly dynamic in its updates
to topology changes (for whatever reason), this does not always to topology changes (for whatever reason), this does not always
happen as planned. Careful consideration needs to be taken in this happen as planned. Careful consideration needs to be taken in this
Option to have some way of leaving a trail of breadcrumbs to find Option to have some way of leaving a trail of breadcrumbs to find
where a problem is related to this Option. URI Option #6 could where a problem is related to this Option. URI Option #6 could
become a more universal Option in this regard to provide who it was become a more universal Option in this regard to provide who it was
that provided a certain critical piece of information that ended up that provided a certain critical piece of information that ended up
needing an update. needing an update.
7. Acknowledgements 8. Acknowledgements
To Andy Newton and Ralph Droms for guidance and assistance in the To Andy Newton and Ralph Droms for guidance and assistance in the
shaping of this effort. To Josh Littlefield for his help. To Ted shaping of this effort. To Josh Littlefield for his help. To Ted
Lemon and Andre Kostur for their constructive comments. Lemon and Andre Kostur for their constructive comments.
8. References 9. References
8.1 Normative References 9.1 Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic
Host Configuration Protocol (DHCPv4)", RFC 3396, November
2002
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004 Configuration Information", RFC 3825, July 2004
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002. Session Initiation Protocol", RFC 3261, May 2002.
[RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic
Host Configuration Protocol (DHCPv4)", RFC 3396, November
2002
[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
"Geopriv Requirements", RFC 3693, February 2004 "Geopriv Requirements", RFC 3693, February 2004
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[ID-PIDF-LO] J. Peterson, "Presence Information Data Format - Location [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
Object", draft-ietf-Geopriv-pidf-lo-03, "work in progress", Format", RFC 4119, December 2006
Sept 2004
8.2 Informative References 9.2 Informative References
[ID-MAPPING] J. Polk, " Analyzing ECRIT Mapping of a Location to an
Emergency URI for Emergency Calling",
draft-polk-ecrit-mapping-events-00.txt, "work in progress",
February 2006
[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf- [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf-
sip-location-conveyance-01.txt, "work in progress", June sip-location-conveyance-02.txt, "work in progress", March
2005 2006
[ID-CIVIC] H. Schulzrinne, "Dynamic Host Configuration Protocol [ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Configuration Information", draft-ietf-geopriv-dhcp-civil- Information ", draft-ietf-geopriv-dhcp-civil-09, "work in
07, "work in progress", Sept 2005 progress", January 2006
Author's Address Author's Address
James M. Polk James M. Polk
3913 Treemont Circle 3913 Treemont Circle
Colleyville, Texas 76034 Colleyville, Texas 76034
USA USA
Phone: +1-817-271-3552 Phone: +1-817-271-3552
Fax: none Fax: none
skipping to change at page 15, line 36 skipping to change at page 17, line 24
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 42 change blocks. 
116 lines changed or deleted 202 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/