< draft-ietf-geopriv-http-location-delivery-12.txt   draft-ietf-geopriv-http-location-delivery-13.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: July 31, 2009 Expires: August 29, 2009
January 27, 2009 February 25, 2009
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-12.txt draft-ietf-geopriv-http-location-delivery-13.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 July 31, 2009. This Internet-Draft will expire on August 29, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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) and HTTP over Transport Layer HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer
skipping to change at page 2, line 42 skipping to change at page 2, line 38
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 12 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 12
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 14 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 14
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 15 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 15
6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15
6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15
6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16
6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Assuring that the proper LIS has been contacted . . . . . 23 9.1. Assuring that the proper LIS has been contacted . . . . . 23
9.2. Protecting responses from modification . . . . . . . . . . 23 9.2. Protecting responses from modification . . . . . . . . . . 24
9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 23 9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 24
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 25 10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 25
10.2. Simple Location Request Example . . . . . . . . . . . . . 27 10.2. Simple Location Request Example . . . . . . . . . . . . . 27
10.3. Location Request Example for Multiple Location Types . . . 28 10.3. Location Request Example for Multiple Location Types . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11.1. URN Sub-Namespace Registration for 11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 29 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 29
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 30 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 30
11.3. MIME Media Type Registration for 'application/held+xml' . 30 11.3. MIME Media Type Registration for 'application/held+xml' . 30
11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 31 11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 31
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
14. Changes since last Version . . . . . . . . . . . . . . . . . . 33 14. Changes since last Version . . . . . . . . . . . . . . . . . . 33
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
15.1. Normative References . . . . . . . . . . . . . . . . . . . 39 15.1. Normative References . . . . . . . . . . . . . . . . . . . 39
15.2. Informative References . . . . . . . . . . . . . . . . . . 40 15.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 41 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 41
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 41 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 41
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 41 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 42
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 42 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 42
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 42 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 42
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 43 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 43
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 43 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 43
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 43 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 44
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 44 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 44
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 44 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 44
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 44 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
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 a [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which a
Device might rely on its access network to provide location Device might rely on its access network to provide location
information. The Location Information Server (LIS) service applies information. The Location Information Server (LIS) service applies
to access networks employing both wired technology (e.g. DSL, Cable) to access networks employing both wired technology (e.g. DSL, Cable)
skipping to change at page 13, line 24 skipping to change at page 13, line 24
fail when that location type is unavailable. For example, a notebook fail when that location type is unavailable. For example, a notebook
computer could be configured to retrieve civic addresses, which is computer could be configured to retrieve civic addresses, which is
usually available from typical home or work situations. However, usually available from typical home or work situations. However,
when using a wireless modem, the LIS might be unable to provide a when using a wireless modem, the LIS might be unable to provide a
civic address and thus provides a geodetic address. civic address and thus provides a geodetic address.
The LIS SHOULD return location information in a form that is suited The LIS SHOULD return location information in a form that is suited
for routing and responding to an emergency call in its jurisdiction, for routing and responding to an emergency call in its jurisdiction,
specifically by value. The LIS MAY alternatively or additionally specifically by value. The LIS MAY alternatively or additionally
return a location URI. If the "locationType" element is absent, a return a location URI. If the "locationType" element is absent, a
location URI MUST be assumed as the default. A location URI provided value of "any" MUST be assumed as the default. A location URI
by the LIS is a reference to the most current available LI and is not provided by the LIS is a reference to the most current available LI
a stable reference to a specific location. and is not a stable reference to a specific location.
It should be noted that the protocol does not support a request to It should be noted that the protocol does not support a request to
just receive one of a subset of location types. For example, in the just receive one of a subset of location types. For example, in the
case where a Device has a preference for just "geodetic" or "civic", case where a Device has a preference for just "geodetic" or "civic",
it is necessary to make the request without an "exact" attribute, it is necessary to make the request without an "exact" attribute,
including both location types. In this case, if neither is available including both location types. In this case, if neither is available
a LIS SHOULD return a locationURI if available. a LIS SHOULD return a locationURI if available.
The LIS SHOULD provide the locations in the response in the same The LIS SHOULD provide the locations in the response in the same
order in which they were included in the "locationType" element in order in which they were included in the "locationType" element in
skipping to change at page 16, line 11 skipping to change at page 16, line 11
device that is requesting it. At the time the location URI is device that is requesting it. At the time the location URI is
provided in the response, there is no binding to a specific location provided in the response, there is no binding to a specific location
type and the location URI is totally independent of the specific type type and the location URI is totally independent of the specific type
of location it might reference. The specific location type is of location it might reference. The specific location type is
determined at the time of dereference. determined at the time of dereference.
A "locationURI" SHOULD NOT contain any information that could be used A "locationURI" SHOULD NOT contain any information that could be used
to identify the Device or Target. Thus, it is RECOMMENDED that the to identify the Device or Target. Thus, it is RECOMMENDED that the
"locationURI" element contain a public address for the LIS and an "locationURI" element contain a public address for the LIS and an
anonymous identifier, such as a local identifier or unlinked anonymous identifier, such as a local identifier or unlinked
pseudonym. Further guidelines to ensure the privacy and pseudonym.
confidentiality of the information contained in the
"locationResponse" message, including the "locationURI", are included When a LIS returns a "locationURI" element to a Device, the policy on
in Section 9.3. the "locationURI" is set by the LIS alone. This specification does
not include a mechanism for the HELD client to set access control
policies on a "locationURI". Conversely, there is no mechanism, in
this protocol as defined in this document, for the LIS to provide a
Device the access control policy to be applied to a "locationURI".
Since the Device is not aware of the access controls to be applied to
(subsequent) requests to dereference a "locationURI", the client
SHOULD protect a "locationURI" as if it were a Location Object -
i.e., the Device SHOULD send a "locationURI" over encrypted channels,
and only to entities that are authorized to have access to the
location.
Further guidelines to ensure the privacy and confidentiality of the
information contained in the "locationResponse" message, including
the "locationURI", are included in Section 9.3.
6.5.2. "expires" Parameter 6.5.2. "expires" Parameter
The "expires" attribute is only included in a "locationResponse" The "expires" attribute is only included in a "locationResponse"
message when a "locationUriSet" element is included. The "expires" message when a "locationUriSet" element is included. The "expires"
attribute indicates the date/time at which the Location URIs provided attribute indicates the date/time at which the Location URIs provided
by the LIS will expire. The "expires" attribute does not define the by the LIS will expire. The "expires" attribute does not define the
length of time a location received by dereferencing the location URI length of time a location received by dereferencing the location URI
will be valid. The "expires" attribute is RECOMMENDED not to exceed will be valid. The "expires" attribute is RECOMMENDED not to exceed
24 hours and SHOULD be a minimum of 30 minutes. 24 hours and SHOULD be a minimum of 30 minutes.
skipping to change at page 19, line 22 skipping to change at page 19, line 36
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence/> <xs:sequence/>
<xs:attribute name="responseTime" type="held:responseTimeType" <xs:attribute name="responseTime" type="held:responseTimeType"
use="optional"/> use="optional"/>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="errorType"> <xs:complexType name="errorType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence/> <xs:sequence>
<xs:attribute name="code" type="xs:token" <xs:any namespace="##other" processContents="lax"
use="required"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:attribute name="message" type="xs:string" </xs:sequence>
use="optional"/> <xs:attribute name="code" type="xs:token"
<xs:attribute ref="xml:lang" use="optional"/> use="required"/>
</xs:restriction> <xs:attribute name="message" type="xs:string"
</xs:complexContent> use="optional"/>
</xs:complexType> <xs:attribute ref="xml:lang" use="optional"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="error" type="held:errorType"/> <xs:element name="error" type="held:errorType"/>
<!-- Location Response --> <!-- Location Response -->
<xs:complexType name="locationResponseType"> <xs:complexType name="locationResponseType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="locationUriSet" <xs:element name="locationUriSet"
type="held:returnLocationType" type="held:returnLocationType"
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:restriction> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexContent> </xs:restriction>
</xs:complexType> </xs:complexContent>
</xs:complexType>
<xs:element name="locationResponse" <xs:element name="locationResponse"
type="held:locationResponseType"/> type="held:locationResponseType"/>
<!-- Location Request --> <!-- Location Request -->
<xs:complexType name="locationRequestType"> <xs:complexType name="locationRequestType">
<xs:complexContent> <xs:complexContent>
<xs:extension base="held:baseRequestType"> <xs:extension base="held:baseRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="locationType" <xs:element name="locationType"
skipping to change at page 33, line 15 skipping to change at page 33, line 15
Neil Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Roger Neil Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Roger
Marshall, Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla, Marshall, Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla,
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.
14. Changes since last Version 14. 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 12 to 13 (Post-2nd WGLC):
1) Fixed editorial error in section 6.2 with regards to empty
"locationType" - error was introduced in 06 to 07 changes.
2) Added additional text in section 6.5.1 to improve security
associated with locationURIs.
3) Modified XML schema for errorType and responseType to allow an
attribute to be returned. Also, added extensibility to errorType.
Changes from WG 11 to 12 (Post-2nd WGLC): Changes from WG 11 to 12 (Post-2nd WGLC):
1) Expanded text in section 8 (HTTP binding) to provide more detail 1) Expanded text in section 8 (HTTP binding) to provide more detail
about the requirements for an HTTP implementation supporting HELD. about the requirements for an HTTP implementation supporting HELD.
Clarified the mandatory functionality and specific handling of other Clarified the mandatory functionality and specific handling of other
functionality of HTTP. functionality of HTTP.
2) Clarification in section 9.1 for clients that have external info 2) Clarification in section 9.1 for clients that have external info
wrt the identity or credentials of the LIS. wrt the identity or credentials of the LIS.
skipping to change at page 39, line 45 skipping to change at page 40, line 10
[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.
[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-14 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
(work in progress), November 2008. (work in progress), November 2008.
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-1-20041028]
Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech, Thompson, H., Maloney, M., Beech, D., and N. Mendelsohn,
"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>.
[I-D.ietf-geopriv-lis-discovery] [I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-05 (work in progress), draft-ietf-geopriv-lis-discovery-07 (work in progress),
December 2008. February 2009.
15.2. Informative References 15.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 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
skipping to change at page 40, line 45 skipping to change at page 41, line 10
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[I-D.ietf-geopriv-l7-lcp-ps] [I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-09 (work in
progress), June 2008. progress), February 2009.
[I-D.ietf-geopriv-lbyr-requirements] [I-D.ietf-geopriv-lbyr-requirements]
Marshall, R., "Requirements for a Location-by-Reference Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-05 (work Mechanism", draft-ietf-geopriv-lbyr-requirements-06 (work
in progress), November 2008. in progress), February 2009.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-12 (work in progress), draft-ietf-sip-location-conveyance-12 (work in progress),
November 2008. November 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-02 (work in draft-winterbottom-geopriv-deref-protocol-03 (work in
progress), July 2008. progress), February 2009.
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
skipping to change at page 44, line 37 skipping to change at page 45, line 4
A.10. L7-10: PIDF-LO Creation A.10. L7-10: PIDF-LO Creation
"When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the "When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the
<geopriv> element into the <device> element of the presence document <geopriv> element into the <device> element of the presence document
(see RFC 4479). This ensures that the resulting PIDF-LO document, (see RFC 4479). This ensures that the resulting PIDF-LO document,
which is subsequently distributed to other entities, conforms to the which is subsequently distributed to other entities, conforms to the
rules outlined in ". [I-D.ietf-geopriv-pdif-lo-profile] rules outlined in ". [I-D.ietf-geopriv-pdif-lo-profile]
COMPLY COMPLY
HELD protocol overview (Section 4 ) describes the requirements on the HELD protocol overview (Section 4 ) describes the requirements on the
LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated
by the LIS MUST conform to [I-D.ietf-geopriv-pdif-lo-profile]. by the LIS MUST conform to [I-D.ietf-geopriv-pdif-lo-profile].
Authors' Addresses Authors' Addresses
Mary Barnes (editor) Mary Barnes (editor)
Nortel Nortel
2201 Lakeside Blvd 2201 Lakeside Blvd
Richardson, TX Richardson, TX
USA
Email: mary.barnes@nortel.com Email: mary.barnes@nortel.com
James Winterbottom James Winterbottom
Andrew Andrew
PO Box U40 PO Box U40
Wollongong University Campus, NSW 2500 Wollongong University Campus, NSW 2500
AU AU
Phone: +61 2 4221 2938 Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com Email: james.winterbottom@andrew.com
URI: http://www.andrew.com/ URI: http://www.andrew.com/
 End of changes. 25 change blocks. 
58 lines changed or deleted 90 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/