< draft-ietf-geopriv-http-location-delivery-06.txt   draft-ietf-geopriv-http-location-delivery-07.txt >
GEOPRIV WG M. Barnes, Ed. GEOPRIV WG M. Barnes, Ed.
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Standards Track Intended status: Standards Track
Expires: October 11, 2008 Expires: October 19, 2008
April 9, 2008 April 17, 2008
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-06.txt draft-ietf-geopriv-http-location-delivery-07.txt
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 36 skipping to change at page 1, line 36
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 October 11, 2008. This Internet-Draft will expire on October 19, 2008.
Abstract Abstract
A Layer 7 Location Configuration Protocol (L7 LCP) is described that A Layer 7 Location Configuration Protocol (L7 LCP) is described that
is used for retrieving location information from a server within an is used for retrieving location information from a server within an
access network. The protocol includes options for retrieving access network. The protocol includes options for retrieving
location information in two forms: by value and by reference. The location information in two forms: by value and by reference. The
protocol is an extensible application-layer protocol that is protocol is an extensible application-layer protocol that is
independent of session-layer. This document describes the use of independent of session-layer. This document describes the use of
Hypertext Transfer Protocol (HTTP) as a transport for the protocol. Hypertext Transfer Protocol (HTTP) as a transport for the protocol.
skipping to change at page 2, line 21 skipping to change at page 2, line 21
4.1. Location by Value . . . . . . . . . . . . . . . . . . . . 7 4.1. Location by Value . . . . . . . . . . . . . . . . . . . . 7
4.2. Location by Reference . . . . . . . . . . . . . . . . . . 7 4.2. Location by Reference . . . . . . . . . . . . . . . . . . 7
4.3. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7 4.3. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7
4.3.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 8 4.3.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 8
4.3.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8 4.3.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9 5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9
5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10 5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10
5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10 5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10
5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10 5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 13 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 14 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13
6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 14 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 14
6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 14 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 14
6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 14 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 14
6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 15 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 14
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. HELDS: URI Definition . . . . . . . . . . . . . . . . . . . . 18 8. HELDS: URI Definition . . . . . . . . . . . . . . . . . . . . 18
9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10.1. Assuring that the proper LIS has been contacted . . . . . 21 10.1. Assuring that the proper LIS has been contacted . . . . . 21
10.2. Protecting responses from modification . . . . . . . . . . 21 10.2. Protecting responses from modification . . . . . . . . . . 21
10.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 22 10.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 21
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 23 11.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 23
11.2. Simple Location Request Example . . . . . . . . . . . . . 26 11.2. Simple Location Request Example . . . . . . . . . . . . . 25
11.3. Location Request Example for Multiple Location Types . . . 27 11.3. Location Request Example for Multiple Location Types . . . 26
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12.1. URN Sub-Namespace Registration for 12.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 27
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 28
12.3. MIME Media Type Registration for 'application/held+xml' . 29 12.3. MIME Media Type Registration for 'application/held+xml' . 28
12.4. Error code Registry . . . . . . . . . . . . . . . . . . . 30 12.4. Error code Registry . . . . . . . . . . . . . . . . . . . 29
12.5. URI Registration . . . . . . . . . . . . . . . . . . . . . 31 12.5. URI Registration . . . . . . . . . . . . . . . . . . . . . 30
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
15. Changes since last Version . . . . . . . . . . . . . . . . . . 32 15. Changes since last Version . . . . . . . . . . . . . . . . . . 31
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
16.1. Normative References . . . . . . . . . . . . . . . . . . . 36 16.1. Normative References . . . . . . . . . . . . . . . . . . . 35
16.2. Informative References . . . . . . . . . . . . . . . . . . 37 16.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 38 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 37
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 39 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 38
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 39 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 38
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 39 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 38
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 40 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 39
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 40 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 39
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 41 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 40
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 41 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 40
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 41 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 40
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 41 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 40
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 42 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . . . . 43
1. Introduction 1. Introduction
The location of a Device is information that is useful for a number The location of a Device is information that is useful for a number
of applications. The L7 Location Configuration Protocol (LCP) of applications. The L7 Location Configuration Protocol (LCP)
problem statement and requirements document problem statement and requirements document
[I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which the [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which the
Device might rely on its access network to provide location Device might rely on its access network to provide location
information. The LIS service applies to access networks employing information. The LIS service applies to access networks employing
both wired technology (e.g. DSL, Cable) and wireless technology both wired technology (e.g. DSL, Cable) and wireless technology
skipping to change at page 8, line 34 skipping to change at page 8, line 34
Devices that establish VPN connections for use by other devices Devices that establish VPN connections for use by other devices
inside a LAN or other closed network could serve as a LIS, that inside a LAN or other closed network could serve as a LIS, that
implements the HELD protocol, for those other Devices. Devices implements the HELD protocol, for those other Devices. Devices
within the closed network are not necessarily able to detect the within the closed network are not necessarily able to detect the
presence of the VPN and rely on the VPN device. To this end, a VPN presence of the VPN and rely on the VPN device. To this end, a VPN
device should provide the address of the LIS server it provides, in device should provide the address of the LIS server it provides, in
response to discovery queries, rather than passing such queries response to discovery queries, rather than passing such queries
through the VPN tunnel. through the VPN tunnel.
It could also be useful for a VPN device to serve as a LIS for other
location configuration options such as Dynamic Host Configuration
Protocol (DHCP)[RFC3825] or Link Layer Discovery Protocol - Media
Endpoint Discovery (LLDP-MED) [LLDP-MED]. VPN devices that serve as
a LIS may acquire their own location using HELD.
4.3.2. LIS Handling of NATs and VPNs 4.3.2. LIS Handling of NATs and VPNs
In the cases where the Device connects to the LIS through a VPN or a In the cases where the Device connects to the LIS through a VPN or a
NAT that serves a large geographic area or multiple geographic NAT that serves a large geographic area or multiple geographic
locations (for example, a NAT used by an enterprise to connect their locations (for example, a NAT used by an enterprise to connect their
private network to the Internet), the LIS might not be able to return private network to the Internet), the LIS might not be able to return
an accurate LI. If the LIS cannot determine an accurate LI, it an accurate LI. If the LIS cannot determine an accurate LI, it
should not provide location information to the requesting device. should not provide location information to the requesting device.
The LIS needs to be configured to recognize identifiers that The LIS needs to be configured to recognize identifiers that
represent these conditions. represent these conditions.
skipping to change at page 15, line 48 skipping to change at page 15, line 40
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
This document (RFC xxxx) defines HELD messages. This document (RFC xxxx) defines HELD messages.
<!-- [[NOTE TO RFC-EDITOR: Please replace XXXX <!-- [[NOTE TO RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]] --> with the RFC number for this specification.]] -->
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/> <xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- Return Location --> <!-- Return Location -->
<xs:complexType name="returnLocationType"> <xs:complexType name="returnLocationType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="locationURI" type="xs:anyURI" <xs:element name="locationURI" type="xs:anyURI"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="expires" type="xs:dateTime" <xs:attribute name="expires" type="xs:dateTime"
use="required"/> use="required"/>
skipping to change at page 19, line 9 skipping to change at page 18, line 48
the helds: URI indicates to the Device where to obtain the actual the helds: URI indicates to the Device where to obtain the actual
location information for a Target. In addition, the helds: URI can location information for a Target. In addition, the helds: URI can
be the result of the LIS discovery process be the result of the LIS discovery process
[I-D.ietf-geopriv-lis-discovery] and indicates to the Device the LIS [I-D.ietf-geopriv-lis-discovery] and indicates to the Device the LIS
from which LI should be requested. from which LI should be requested.
The helds: URI is defined using a subset of the URI schema specified The helds: URI is defined using a subset of the URI schema specified
in Appendix A. of RFC3986 [RFC3986] and the associated URI in Appendix A. of RFC3986 [RFC3986] and the associated URI
Guidelines [RFC4395] per the following ABNF syntax: Guidelines [RFC4395] per the following ABNF syntax:
HELD-URI = "helds" ":" "//" host [":" port] [ path-absolute ] [? query] HELD-URI = "helds://" host [ ":" port ] [ path-absolute ] [ "?" query ]
The following summarizes the primary elements comprising the HELD- The following summarizes the primary elements comprising the HELD-
URI: URI:
host: As defined in RFC3986 [RFC3986] host: As defined in RFC3986 [RFC3986]
port: As defined in RFC3986 [RFC3986]. There is no unique port port: As defined in RFC3986 [RFC3986]. There is no unique port
associated with location URIs. associated with location URIs.
path-absolute As defined in RFC3986 [RFC3986]. path-absolute As defined in RFC3986 [RFC3986].
query: As defined in RFC3986 [RFC3986]. This allows for additional query: As defined in RFC3986 [RFC3986]. This allows for additional
information associated with the URIs such as a unique anonymous information associated with the URIs such as a unique anonymous
identifier for the Device associated with the target location. identifier for the Device associated with the target location.
skipping to change at page 25, line 22 skipping to change at page 24, line 22
Date: Tue, 10 Jan 2006 03:42:29 GMT Date: Tue, 10 Jan 2006 03:42:29 GMT
Expires: Tue, 10 Jan 2006 03:42:29 GMT Expires: Tue, 10 Jan 2006 03:42:29 GMT
Cache-control: private Cache-control: private
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 594 Content-Length: 594
<?xml version="1.0"?> <?xml version="1.0"?>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com"> entity="pres:3650n87934c@ls.example.com">
<tuple id="3b650sf789nd"> <tuple id="b650sf789nd">
<status> <status>
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"> <geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">
<location-info> <location-info>
<Point xmlns="http://www.opengis.net/gml" <Point xmlns="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326"> srsName="urn:ogc:def:crs:EPSG::4326">
<pos>-34.407 150.88001</pos> <pos>-34.407 150.88001</pos>
</Point> </Point>
</location-info> </location-info>
<usage-rules> <usage-rules>
<retention-expiry> <retention-expiry>
skipping to change at page 32, line 48 skipping to change at page 31, line 48
Grenier, Ted Hardie, Cullen Jennings, Neil Justusson, Tat Lam, Marc Grenier, Ted Hardie, Cullen Jennings, Neil Justusson, Tat Lam, Marc
Linsner, Patti McCalmont, Roger Marshall, Perry Prozeniuk, Carl Reed, Linsner, Patti McCalmont, Roger Marshall, Perry Prozeniuk, Carl Reed,
Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed
Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf. Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf.
15. Changes since last Version 15. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
Changes from WG 06 to 07 (PROTO review comments):
1) Fix nits: remove unused references, move requirements to
Informational References section, fix long line in ABNF, fix ABNF
(quotes around '?'), add schemaLocation to import namespace in XML
schema.
2) Remove text in Device and VPN section referencing DHCP and LLDP-
MED when a VPN device serves as a LIS, per Issue 1 resolution at
IETF-71. (Editorial oversight in producing version 06).
Changes from WG 05 to 06 (2nd WGLC comments): Changes from WG 05 to 06 (2nd WGLC comments):
1) Updated security section based on WG feedback, including 1) Updated security section based on WG feedback, including
condensing section 10.1.1 (Assuring the proper LIS has been condensing section 10.1.1 (Assuring the proper LIS has been
contacted), restructuring sections by flattening, adding an contacted), restructuring sections by flattening, adding an
additional step to the list that had been in the Accuracy section and additional step to the list that had been in the Accuracy section and
removing summary section. removing summary section.
2) Changed URI schema to "helds" to address concerns over referential 2) Changed URI schema to "helds" to address concerns over referential
integrity and for consistency with mandate of TLS for HELD. integrity and for consistency with mandate of TLS for HELD.
skipping to change at page 36, line 48 skipping to change at page 36, line 12
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[I-D.ietf-geopriv-pdif-lo-profile] [I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11
(work in progress), February 2008. (work in progress), February 2008.
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-1-20041028]
Maloney, M., Thompson, H., Beech, D., and N. Mendelsohn, Mendelsohn, N., Thompson, H., Beech, D., and M. Maloney,
"XML Schema Part 1: Structures Second Edition", World Wide "XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028, Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028] [W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
skipping to change at page 37, line 50 skipping to change at page 36, line 51
December 2007. December 2007.
16.2. Informative References 16.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115, Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006. RFC 4395, February 2006.
[I-D.narten-iana-considerations-rfc2434bis] [I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-09 (work in draft-narten-iana-considerations-rfc2434bis-09 (work in
progress), March 2008. progress), March 2008.
skipping to change at page 38, line 43 skipping to change at page 37, line 44
draft-ietf-sip-location-conveyance-10 (work in progress), draft-ietf-sip-location-conveyance-10 (work in progress),
February 2008. February 2008.
[I-D.winterbottom-geopriv-deref-protocol] [I-D.winterbottom-geopriv-deref-protocol]
Winterbottom, J., Tschofenig, H., Schulzrinne, H., Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
Thomson, M., and M. Dawson, "An HTTPS Location Thomson, M., and M. Dawson, "An HTTPS Location
Dereferencing Protocol Using HELD", Dereferencing Protocol Using HELD",
draft-winterbottom-geopriv-deref-protocol-00 (work in draft-winterbottom-geopriv-deref-protocol-00 (work in
progress), November 2007. progress), November 2007.
[LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery".
Appendix A. HELD Compliance to IETF LCP requirements Appendix A. HELD Compliance to IETF LCP requirements
This appendix describes HELD's compliance to the requirements This appendix describes HELD's compliance to the requirements
specified in the [I-D.ietf-geopriv-l7-lcp-ps]. specified in the [I-D.ietf-geopriv-l7-lcp-ps].
A.1. L7-1: Identifier Choice A.1. L7-1: Identifier Choice
"The L7 LCP MUST be able to carry different identifiers or MUST "The L7 LCP MUST be able to carry different identifiers or MUST
define an identifier that is mandatory to implement. Regarding the define an identifier that is mandatory to implement. Regarding the
latter aspect, such an identifier is only appropriate if it is from latter aspect, such an identifier is only appropriate if it is from
 End of changes. 23 change blocks. 
65 lines changed or deleted 56 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/