One document matched: draft-polk-dhc-uri-01.txt
Differences from draft-polk-dhc-uri-00.txt
DHC Working Group James Polk
Internet Draft Cisco Systems
Expiration: March 28th, 2006 September 28th, 2005
File: draft-polk-dhc-uri-01.txt
A Dynamic Host Configuration Protocol Option for
Requesting and Receiving Uniform Resource Identifiers
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 6th, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines a new Dynamic Host Configuration Protocol
(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
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
identify the type of URI being requested by the client, or the type
of URI in the DHCP message from the server.
Polk Expires March, 2006 [Page 1]
Internet-Draft DHC URI Option Sept 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions used in this document . . . . . . . . . . . . 4
1.2 Terms, Acronyms and Definitions . . . . . . . . . . . . . 4
1.3 What Changed from Previous Versions . . . . . . . . . . . 5
2. DHC Relay Option Format . . . . . . . . . . . . . . . . . . . 5
2.1 Rules of Usage . . . . . . . . . . . . . . . . . . . . . 6
2.2 Multiple URIs in a message . . . . . . . . . . . . . . . 7
2.3 Requesting a URI of a Server. . . . . . . . . . . . . . . 8
3. Purposes of Different URI Types . . . . . . . . . . . . . . . 8
3.1 Primary SIP/SIPS URI of Public Safety Answering Point . . 9
3.2 Secondary SIP/SIPS URI of Public Safety Answering Point . 9
3.3 Client's Location By-Reference URI . . . . . . . . . . . 9
3.4 SIP/SIPS URI of Emergency Services Gateway (ESGW) . . . . 9
3.5 SIP/SIPS URI of Emergency Services Routing Proxy (ESRP) . 10
3.6 URI of Organization Providing LCI . . . . . . . . . . . . 10
3.7 URI for Geocoding or Reverse Geocoding Function . . . . . 10
3.8 Primary URI for Geo Mapping Service . . . . . . . . . . . 10
3.9 Secondary URI for Geo Mapping Service . . . . . . . . . . 11
3.10 Primary URI for Civic Mapping Service . . . . . . . . . . 11
3.11 Secondary URI for Civic Mapping Service . . . . . . . . . 11
4. Open Items for Discussion . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1 Normative References . . . . . . . . . . . . . . . . . . 13
8.2 Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . 14
1. Introduction
There are times in which a Uniform Resource Identifier (URI) is an
essential part of configuration information necessary for usage by
an endpoint (client) for the particular purpose of contacting what
is at that URI. This document defines a new Dynamic Host
Configuration Protocol (DHC) Option [RFC 2131] to allow URIs of
specific types, or purposes, to be requested by a client of a
server, and transmitted unrequested from a server to a client.
Because URIs can be used for many purposes, and to ensure
extensibility, this client option has a sub-option "purpose" field
to identify the type of URI included in the message.
This document specifies one DHCP Option for all URIs, allowing up to
255 uniquely identified URIs to be defined as sub-options. The
format for this comes from [RFC3396]. This document will IANA
Register each purpose URI for interoperability.
Polk Expires March, 2006 [Page 2]
Internet-Draft DHC URI Option Sept 2005
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
client to gain knowledge of a URI or series of URIs determined
through local configuration, that are considered essential for use
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
particular application launches.
One example of this URI download could be one specifically for the
SIP or SIPS URI of the appropriate Public Safety Answer Point (PSAP)
for the client when the user calls for emergency help (911 or 112-
type of help). This is not a transaction that should take place
when a voice application wants to make such a critical call set-up.
It is more appropriate that this information be downloaded to the
client when the voice (or other) application boots up in case it is
needed at a later time.
A Link Provider (LP) would be in a better position to have knowledge
of where the client is than an Internet Provider (IP); the latter
becoming more divorced from the physical location of the client,
especially in the case of the IP being an Application Provider (AP)
on a regional, national or international scale. This was part of
the motivation for Option 123 (GeoConf) [RFC 3825].
Examples of Link Providers are DSL providers with known endpoints of
their cabling infrastructure, Hybrid Fiber Coax (HFC) Cable
providers with knowledge of where their logical endpoints are, and
small or large enterprise infrastructures. The DSL or HFC Cable
provides are not limited in this context to a single client at the
subscriber's endpoint, but could have few to many clients being
served by an access device of those infrastructures, all with a
common need for the particular URI, or series of URIs.
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
own payload container with an Option number, a length field and a
purpose field. This means that if more than one URI is being
requested or downloaded, there can be more than one DHCP Option XXX
(this document's option number) in the same IP message. Each URI
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.
Awareness of how stale a URI may become is something local
administrators should consider when implementing this Option. DHCP
servers are assumed to periodically query an authoritative source
providing non-stale URIs. How this is accomplished is most likely
not through the use of DHCP and is out of scope for this document.
Section 1.2 reviews the terminology and acronyms used in this
document that are fairly new to DHCP. Section 2.1 discusses the
rules of usage of this Option. Section 3 lists the unique numbering
of the purpose fields to the purpose type that is explained in
Polk Expires March, 2006 [Page 3]
Internet-Draft DHC URI Option Sept 2005
section 3.1 - 3.11. Section 4 discusses open issues to be
addressed. Section 5 is the IANA Considerations section of this DHCP
Option as well as the purpose field sub-options.
1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
1.2 Terms, Acronyms and Definitions
The following terms and acronyms are used within this document:
Application Provider - A Service Provider that has a measure of
control over an application the client uses. An organization
that does voice as an application is one example.
Civic Mapping - the process a server receiving the civic format
location of a client, processing that location to determine the
appropriate PSAP for that location, and returning that PSAP URI
to the client
Emergency Services Gateway - The special IP to circuit-switched
gateway that front-ends an emergency services Selective Router
(which directs all TDM based 911/112 type calls to the
appropriate PSAP)
Emergency Services Routing Proxy - a special instance of a SIP Proxy
that understands emergency routing to a PSAP based on the
location of the caller
ESGW - Emergency Services Gateway
ESRP - Emergency Services Routing Proxy
Geo Mapping - the process a server receiving the geo format location
of a client, processing that location to determine the
appropriate PSAP for that location, and returning that PSAP URI
to the client
Internet Provider - Provides layer 3 connectivity to the Internet to
a client directly or indirectly through another organization such
as an Enterprise network
Link Provider - Provides the MAC layer communications link to the
client
PSAP - Public Safety Answering Point
Public Safety Answering Point - the emergency response call center
Polk Expires March, 2006 [Page 4]
Internet-Draft DHC URI Option Sept 2005
talking the local emergency calls from people in distress. This
facility can be logical, and can transfer (reroute) any request
sent to it to another facility deemed more appropriate to receive
the request.
1.3 What Changed from Previous Versions
This is a list of the changes between versions of this document.
From the individual -00 version to the individual -01 version there
were the following changes:
- added a second URI to the main bit format Figure (1)
- Added several requirements
- Deleted several rules surrounding how to get around RFC3396, which
is no longer necessary
- brought this document in line with RFC3396, including the sub-
option length parameter per URI
- removed the ability to concatenate fields
- modified the doc to limit the size of a URI to 253 bytes max
- Added a section on how multiple URIs are derived
- Added a section on how a client requests one or more URIs
- Edited terms to be more consistent with the ECRIT Reqs ID
- Added new concerns to the Security Considerations
2. DHC Relay Option Format
The format for this Option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code XXX | Length | URI Purpose | URI length +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URI (cont'd) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URI (cont'd to a maximum of 253 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+>| URI Purpose #2| URI length | URI #2 +
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | URI (cont'd) +
Polk Expires March, 2006 [Page 5]
Internet-Draft DHC URI Option Sept 2005
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | URI (cont'd to a maximum of 253 bytes minus URIs above) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+--(This is a second instance of a URI that MAY be in the message;)
(See the section 2.2)
Figure 1. The URI Option Format
Code = The IANA Assigned Option number
Length = This is a variable length value of the number of bytes
in the Option, including this length field
URI Purpose = This is what the URI is used for by applications
within the client
URI Length = The length of the URI associated with a particular
purpose, whether or not there are any other URIs in
the message
URI = This is a variable length field containing the URI
being transmitted, to a maximum of 253 bytes in length
2.1 Rules of Usage
The following are the rules of usage of this DHCP Option:
- Each DHCP Option compliant with this document will have the same
Option number
- The Length field is for the overall length of the Option (there
are URI option fields per purpose)
- Each URI requested for by a client, or transmitted by the server,
MUST have a purpose identifier indicating the intended usage for
this URI by applications within the client
- there MAY be more than one URI requested by the client in the same
message
- If more than one URI is requested for by the client, or
transmitted by the server unsolicited, each MUST be in separate
"purpose" subsection of the message
- Each purpose suboption will have its own URI Length field for
that URI only
- No URI Length field will be more than 253 (bytes), complying with
[RFC2131]
Polk Expires March, 2006 [Page 6]
Internet-Draft DHC URI Option Sept 2005
- [RFC2131] limits the size of an Option to 255 bytes, and this
Option is no different. If there are more than one URI to be sent
to a client, and the aggregate byte count is greater than 255
bytes, the URIs will be sent in more than one message to the
client.
- Clients making a request for one or more URIs will send a
message to the Server with URI length fields set to zero
- Clients MUST NOT request the same purpose more than once in the
same message, but are not limited in how frequently they can make
new requests - even for the same URI purpose
- Clients MUST be prepared to support [RFC3396] for multiple URIs
- Server responses to a request for more than one URI MAY be in
separate messages (i.e. one URI per message), at the server's
discretion
- Certain URI fields MAY be populated with a URL of a server
- Purpose=6 "URI of Organization Providing Location Configuration
Information" SHOULD be included when Option 123 (GeoConf) or the
Option for [ID-CIVIC] is requested of a server and when downloaded
to the client.
- URIs that denote public identifiers, such as for a PSAP, are not
as much at risk as other URIs transmitted to the client. That
said, URIs with specific information of the client, such as its
location by-reference URI SHOULD NOT be transmitted by the server
without being requested by the client first, and SHOULD only be
requested by the client once it learns the specific IP address of
the server.
2.2 Multiple URIs in a message
There MAY be one URI in the message. However, there MAY be more
than one URI - requiring a means to know when one stops and the
other one starts. The code field is the same in either case. The
Option length field is overall message length in bytes, minus the
Option number byte and the Option Length byte. The next byte is a
URI purpose byte, followed by a URI Length byte. If this length
value is not one byte less than the Option Length value, the DHCP
entity knows there is more than one URI in this message. This first
URI Length field determines the exact number of bytes in this first
URI. The next byte after this field is the purpose byte of the next
URI, followed by its URI length field. If the addition of these two
URI length 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. This process continues until the byte counts match, or
they do not - which means there is an length error.
Polk Expires March, 2006 [Page 7]
Internet-Draft DHC URI Option Sept 2005
Here is the pseudo-format of such a message
[code] [length] [purpose] [uri length] [uri text] [purpose] [uri
length] [uri text] [purpose] [uri length] [uri text] [etc]
2.3 Requesting a URI of a Server
Clients can request one or more URIs of a server. Here is the
pseudo-format of such a request:
[code] [length] [purpose] [uri length=0] [purpose] [uri Length=0]
[purpose] [uri length=0] [etc...]
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
limit to the number of URIs a client can request - except:
- the Option maximum length is 253 bytes,
- that the same URI purpose cannot be in the message more than once,
- there is a limit on the number of available purposes to include.
Conceivably though, each available URI purpose MAY be in a DHC
message. The client MUST be prepared to receive each URI requested,
even in separate messages from the server. The client MUST NOT
request the same URI purpose more than once in the same message.
3. Purposes of Different URI Types
This section lists the initial set of purpose fields which can be
used by a client for different requests, or a server for different
transmissions:
Purpose = 1 (Primary PSAP URI)
Purpose = 2 (Secondary PSAP URI)
Purpose = 3 (Location By-Reference URI of Client)
Purpose = 4 (ESGW URI of Client)
Purpose = 5 (ESRP URI of Client)
Purpose = 6 (Organization Providing Location for Client)
Purpose = 7 (URI of Geocoding/Reverse Geocoding)
Purpose = 8 (Primary URI of Geo Mapping Service)
Purpose = 9 (Secondary URI of Geo Mapping Service)
Purpose = 10 (Primary URI of Civic Mapping Service)
Purpose = 11 (Secondary URI of Civic Mapping Service)
Others can be added based on discussion of this document.
Polk Expires March, 2006 [Page 8]
Internet-Draft DHC URI Option Sept 2005
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]
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 emergency help (such as the police or ambulance).
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
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
SIP final failure message. This SHOULD NOT be used if the initial
attempt to contact the PSAP fails for any reason, as many failures
are recoverable within SIP [RFC 3261]. In fact, many non-successful
responses are not uncommon in SIP before a transaction is
successfully responded to.
3.3 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.4 SIP/SIPS URI of Emergency Services Gateway (ESGW)
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
that is not IP enabled. Having this information locally in the
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
Polk Expires March, 2006 [Page 9]
Internet-Draft DHC URI Option Sept 2005
this client, and possibly fail the call set-up during that
determination.
3.5 SIP/SIPS URI of Emergency Services Routing Proxy (ESRP)
This purpose=5 URI is for the Emergency Services Routing Proxy that
is tasked with determining which PSAP the client needs to contact
when attempting to establish a call with a PSAP. In SIP for
example, not all SIP Proxies or intermediaries are expected to have
knowledge of how to determine which is the appropriate PSAP of a
client based on where the client is located. There may be difficult
in a non-updated SIP intermediary in this determination, even in
determining which SIP intermediary knows how to do this function.
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
PIDF-LO [ID-SIP-LOC] in the session set-up message (the SIP INVITE)
to that intermediary.
3.6 URI of Organization Providing Location Configuration Information
This purpose=6 URI is the organization that provided location
configuration information (LCI) to the DHCP client. In building a
proper XML Location Message Body [ID-PIDF-LO], the location
generator [RFC 3693] will include a <provided-by> element indicating
which organization was responsible for delivering this location
information to the client. This URI is used to populate this
<provided-by> element without further interaction.
3.7 URI for Geocoding or Reverse Geocoding Function
This purpose=7 URI of a server that can perform a geocoding or
reverse geocoding function. DHCP has the ability to provide
Location Configuration Information to a client in the geo format
using Option 123 [RFC 3825] or the civic format [ID-CIVIC], or the
client can learn is location through manual configuration or an
internal GPS process. Various applications on a client MAY prefer
one format over another and not possess the ability to geocode or
reverse geocode the available location information. This URI
(purpose=7) provides the client with the server known to have this
ability prior to the client requiring the new format.
3.8 Primary URI for Geo Mapping Service
This purpose=8 URI gives the client the ability to transmit its
location, perhaps downloaded from DHCP Option 123 [RFC3825], and
contact a "primary" server at this URI to perform a location-to-
PSAP-URI mapping function before the client attempts to contact a
PSAP.
Polk Expires March, 2006 [Page 10]
Internet-Draft DHC URI Option Sept 2005
This transmission of client location to the primary mapping server
that includes the request to map this location to the appropriate
PSAP for that location is done with another protocol, and not DHCP.
3.9 Secondary URI for Geo Mapping Service
This purpose=9 URI gives the client the ability to transmit its
location, perhaps downloaded from DHCP Option 123 [RFC3825], and
contact a "secondary" server at this URI to perform a location-to-
PSAP-URI mapping function before the client attempts to contact a
PSAP.
This transmission of client location to the secondary mapping server
that includes the request to map this location to the appropriate
PSAP for that location is done with another protocol, and not DHCP.
3.10 Primary URI for Civic Mapping Service
This purpose=10 URI gives the client the ability to transmit its
location, perhaps downloaded from the civic format DHCP Option [ID-
CIVIC], and contact a "primary" server at this URI to perform a
location-to-PSAP-URI mapping function before the client attempts to
contact a PSAP.
This transmission of client location to the primary mapping server
that includes the request to map this location to the appropriate
PSAP for that location is done with another protocol, and not DHCP.
3.11 Secondary URI for Civic Mapping Service
This purpose=11 URI gives the client the ability to transmit its
location, perhaps downloaded from the civic format DHCP Option [ID-
CIVIC], and contact a "secondary" server at this URI to perform a
location-to-PSAP-URI mapping function before the client attempts to
contact a PSAP.
This transmission of client location to the secondary mapping server
that includes the request to map this location to the appropriate
PSAP for that location is done with another protocol, and not DHCP.
4. Open Items for Discussion
There are several open items that need to be addressed in following
versions of this ID (if it moves forward).
#1 - There is an open question as to whether a URI will ever need to
be longer than 255 bytes (getting into concatenation-required
Polk Expires March, 2006 [Page 11]
Internet-Draft DHC URI Option Sept 2005
language)
5. IANA Considerations
IANA has assigned a DHCP option code of [XXX] for the URI option
defined in this document.
This URI Option defines one field for which IANA maintains a
registry: the Purpose field (see Section 2). The initial values of
the Purpose registry are as follows:
Purpose Description Reference
------- ------------ ---------
1 Primary PSAP URI [This RFC]
2 Secondary PSAP URI [This RFC]
3 Location By-Reference URI of Client [This RFC]
4 ESGW URI of Client [This RFC]
5 ESRP URI of Client [This RFC]
6 Organization Providing Location for Client [This RFC]
7 URI of Geocoding/Reverse Geocoding [This RFC]
8 Primary 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]
11 Secondary URI of Civic Mapping Service [This RFC]
IANA registration of new purpose field values MUST be done in a
standards track RFC.
6. Security Considerations
Where critical decisions might be based on the value of this URI
option, DHCP authentication in [RFC3118] SHOULD be used to protect
the integrity of the DHCP options.
Since there is no privacy protection for DHCP messages, an
eavesdropper who can monitor the link between the client and
destination DHCP server to capture any URIs in transit.
When implementing a DHC server that will serve clients across an
uncontrolled network, one should consider the potential security
risks.
There is a risk of old information being provided by this Option.
Although many wish the Internet to be truly dynamic in its updates
to topology changes (for whatever reason), this does not always
happen as planned. Careful consideration needs to be taken in this
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
become a more universal Option in this regard to provide who it was
Polk Expires March, 2006 [Page 12]
Internet-Draft DHC URI Option Sept 2005
that provided a certain critical piece of information that ended up
needing an update.
7. Acknowledgements
To Andy Newton and Ralph Droms for guidance and assistance in the
shaping of this effort. To Josh Littlefield for his help. To Ted
Lemon and Andre Kostur for their constructive comments.
8. References
8.1 Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
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,
"Geopriv Requirements", RFC 3693, February 2004
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[ID-PIDF-LO] J. Peterson, "Presence Information Data Format - Location
Object", draft-ietf-Geopriv-pidf-lo-03, "work in progress",
Sept 2004
8.2 Informative References
[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf-
sip-location-conveyance-01.txt, "work in progress", June
2005
[ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Polk Expires March, 2006 [Page 13]
Internet-Draft DHC URI Option Sept 2005
Configuration Information ", draft-ietf-geopriv-dhcp-civil-
06, "work in progress", May 2005
Author's Address
James M. Polk
3913 Treemont Circle
Colleyville, Texas 76034
USA
Phone: +1-817-271-3552
Fax: none
Email: jmpolk@cisco.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Polk Expires March, 2006 [Page 14]
Internet-Draft DHC URI Option Sept 2005
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Polk Expires March, 2006 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-22 13:40:52 |