HTTP-Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-16

[Ballot discuss]
Updated as per revision -16 and RFC Editor notes added by Cullen:

This is a well written document. There is one relatively minor points that I would like to discuss with authors/shepherd/IESG before recommending approval of this document:

1). I think the reference to [I-D.ietf-ltru-4646bis] is Normative. (Note that this document is in AUTH48, so wouldn't delay publication of your document.)

[Ballot comment]
11.3.  MIME Media Type Registration for 'application/held+xml'

  Interoperability considerations:  This content type provides a basis
      for a protocol

This doesn't really say anything about interoperability.
The write-up implies that there are multiple implementations of the protocol already, so you can just say it here.

[Ballot discuss]
This is a well written document. There are 4 relatively minor points that I would like to discuss with authors/shepherd/IESG before recommending approval of this document:

1).
As per discussion on the call the document should say that the charset is always UTF-8 and that the charset parameter MUST always be specified when sending this MIME body part in various protocols. Nothing should be said about the default charset.

I suggest saying that at the end of 1st paragraph of Section 5:

OLD:
  Messages are defined as XML documents.

NEW:
  Messages are defined as XML documents which are always encoded in UTF-8.
  Note that when "application/held+xml" media type is transported in HTTP
  the charset parameter with value UTF-8 is required.

2). "application/held+xml" MIME type registration was sent to ietf-types@iana.org mailing list for review in April 2008:



One reviewer recommended use of a HELD specific extension (and not .xml).
I agree with this recommendation.

3). I think the reference to [I-D.ietf-ltru-4646bis] is Normative. (Note that this document is in AUTH48, so wouldn't delay publication of your document.)

[Ballot comment]
The document lacks completely any information about how LIS's supporting HELD would be managed. What needs to be configured on a LIS? are there any statistics kept on the number of requests, number of succesful requests, errors, errors distribution, etc. made available to operators that need to include a LIS in his/her network? How can an operator know when a LIS gets near to its capacity and the resulting performance starts to degrade? It would be useful to add a short section to explain these issues, or to refer to other documents that do fill in this task.

[Ballot comment]
6.4.  "message" Parameter

  The "error" message MAY include one or more "message" attributes to
  convey some additional, human-readable information about the result
  of the request.  The message MAY be included in any language, which
  SHOULD be indicated by the "xml:lang", attribute.  The default
  language is assumed to be English.

I suggest added to the end of last sentence:

("en") [RFC4646bis]"



11.3.  MIME Media Type Registration for 'application/held+xml'

  Interoperability considerations:  This content type provides a basis
      for a protocol

This doesn't really say anything about interoperability.
The write-up implies that there are multiple implementations of the protocol already, so you can just say it here.

  Additional Information:  Magic Number(s): (none)
      File extension(s): .xml

I have small preference for picking a new extension for this.

      Macintosh File Type Code(s): (none)

I think this should be the same as in RFC 3023:
Macintosh File Type Code(s): "TEXT"

[Ballot discuss]
This is a well written document. There are 4 relatively minor points that I would like to discuss with authors/shepherd/IESG before recommending approval of this document:

1). The document normatively references RFC 2818 for server TLS identity verification.

RFC 2818, Section 3.1 says:

  Matching is performed using the matching rules specified by
  [RFC2459].  If more than one identity of a given type is present in
  the certificate (e.g., more than one dNSName name, a match in any one
  of the set is considered acceptable.) Names may contain the wildcard
  character * which is considered to match any single domain name
  component or component fragment. E.g., *.a.com matches foo.a.com but
  not bar.foo.a.com. f*.com matches foo.com but not bar.com.

Based on the discussion during the IESG telechat several ADs agreed that f* wildcards shouldn't be allowed anymore. So, the document should say
that it complies with RFC 2818, except for f* type wildcards are not allowed. (wildcards in the leftmost label are still allowed). This is consistent with the advice from RFC 5280.

2). In Section 6.5.2 ("expires" Parameter):

  The "expires" attribute is only included in a "locationResponse"
  message when a "locationUriSet" element is included.  The "expires"
  attribute indicates the date/time at which the Location URIs provided

This doesn't specify if the date/time is in local timezone, in UTC, or is allowed to be either.
I believe local timezone might cause some minor interoperability problems, as the Device would have to discover server's timezone.

I would encourage using the last paragraph of draft-hollenbeck-rfc4930bis-02.txt, Section 5 to address this issue, or argue why other formats should be allowed.

(Note, if you choose to disallow local timezone, you also need to fix your examples).

  by the LIS will expire.  The "expires" attribute does not define the

2b). COMMENT: As fractional seconds seem to be allowed in the "expire" attribute, it would have been nice to have an example of this.


3). In Section 6.3 ("code" Parameter):

  The value of the response code MUST be one of the following tokens:

This make it sound that the list of error codes is not extensible, yet you establish an IANA registry for them.

4). Default charset for the "application/held+xml" MIME type:
  Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.

As per discussion on the call the document should say that the charset is always UTF-8 and that the charset parameter MUST always be specified when sending this MIME body part in various protocols. Nothing should be said about the default charset.

5). "application/held+xml" MIME type registration was sent to ietf-types@iana.org mailing list for review in April 2008:



However none of the comments raised on the mailing list were addressed or responded to:

[Ballot comment]
I found the last statement in section 5.1 confusing:

  The LIS MUST ignore any part of a location request message that it
  does not understand, except the document element.

This begs the obvious question, if you don't recognize the document element and
do not ignore it, what do you do?  I eventually sorted it out from the following code
parameter definition in section 6.3:

  unsupportedMessage:  This code indicates that an element in the XML
      document for the request, was not supported or understood by the
      LIS.  This error code is used when a HELD request contains a
      document element that is not supported by the receiver.

I would suggest either covering this case in the first sentence of section 5.3
or adding a note in 5.1 that points to 6.3.

[Ballot discuss]
The text in section 8 on client authentication seems correct in the context of
the features defined within this specification, but may not be true when HELD
extensions are defined.  Specifically, the recommendations against authentication
are arguably sound so long as the IP address is the only identity type supported.
However, section 5.1 indicates that additional identity types are expected to be
defined in the future.

I believe paragraph 3 of the http bindings text should be revised to apply
this guidance to the case where the device identity is the IP address and
specifically note that extensions to support other Device identities may introduce
new authentication requirements.

[Ballot comment]
I found the last statement in section 5.1 confusing:

  The LIS MUST ignore any part of a location request message that it
  does not understand, except the document element.

This begs the obvious question, if you don't recognize the document element and
do not ignore it, what do you do?  I eventually sorted it out from the following code
parameter definition in section 6.3:

  unsupportedMessage:  This code indicates that an element in the XML
      document for the request, was not supported or understood by the
      LIS.  This error code is used when a HELD request contains a
      document element that is not supported by the receiver.

I would suggest either covering this case in the first sentence of section 5.3
or adding a note in 5.1 that points to 6.3.

[Ballot discuss]
The text in section 8 on client authentication seems correct in the context of
the features defined within this specification, but may not be true when HELD
extensions are defined.  Specifically, the recommendations against authentication
are arguably sound so long as the IP address is the only identity type supported.
However, section 5.1 indicates that additional identity types are expected to be
defined in the future.

I believe paragraph 3 of the security considerations should be revised to apply
this guidance to the case where the device identity is the IP address and
specifically note that extensions to support other Device identities may introduce
new authentication requirements.

[Ballot comment]
1. How can [I-D ietf-geopriv-l7-lcp-ps] be just an Informational Reference? Maybe at least the defibition of a LIS should be replicated here.

2. In 4.1.1

"To minimize the impact of connections or tunnels setup for security
  purposes or to traverse middleboxes, Devices that connect to servers
  such as VPN servers, SOCKS servers and HTTP proxy servers should
  perform their HELD query to the LIS prior to establishing a
  connection to other servers."

I think s/should/SHOULD/

[Ballot discuss]
This is a very well written document and I know a lot of work was invested to make it meet the requirements, and a lot of controversy was overcome on the road. A few items still seem to me to REQUIRE clarification:

1. In a review of a previous version Bernard Aboba raised the issue of client authentication. This resulted in changes which look like did not improve the situation, but quite the opposite.

The previous text related to LIS behavior (e.g. not refusing authorization based on lack of authentication). In athat text, the LIS could challenge the client, but was restricted in its options if the client failed authentication.  In the new text, the LIS is recommended not to even try to authenticate the client. I cannot understand how this can be allowed. A DoS threat from one or several clients choking a LIS with dummy requests is not part of the threat model?

A compromise approach would be for the LIS to make the choice on whether to challenge the device based on the nature of the request. Devices only supporting requests that cannot be challenged (e.g. requests utilizing implicit IP address identification) could omit support for HTTP authentication.  However, if a device were to make a request of another type (e.g. utilizing HELD extensions), the LIS could challenge it and therefore the device would need to support HTTP authentication. This should be at least an option in my view.

2. The document lacks completely any information about how LIS's supporting HELD would be managed. What needs to be configured on a LIS? are there any statistics kept on the number of requests, number of succesful requests, errors, errors distribution, etc. made available to operators that need to include a LIS in his/her network? How can an operator know when a LIS gets near to its capacity and the resulting performance starts to degrade?

3. I have a hard time understanding what the following paragraph in Section 4.1.2 means:

"  LIS operators have a large role in ensuring the best possible
  environment for location determination.  The LIS operator needs to
  ensure that the LIS is properly configured with identifiers that fall
  within NATs and VPNs.  In order to serve a Device on a remote side of
  a NAT or VPN a LIS needs to have a presence on the side of the NAT or
  VPN nearest the Device."

What means 'identifiers that fall within NATs and VPNs'? How 'a presence on the side of the NAT or VPN nearest the Device' is achieved by a LIS?

[Ballot comment]
I found the last statement in section 5.1 confusing:

  The LIS MUST ignore any part of a location request message that it
  does not understand, except the document element.

This begs the obvious question, if you don't recognize the document element and
do not ignore it, what do you do?  I eventually sorted it out from the following code
parameter definition in section 6.3:

  unsupportedMessage:  This code indicates that an element in the XML
      document for the request, was not supported or understood by the
      LIS.  This error code is used when a HELD request contains a
      document element that is not supported by the receiver.

I would suggest either covering this case in the first sentence of section 5.3
or adding a note in 5.1 that points to 6.3.

[Ballot comment]
6.4.  "message" Parameter

  The "error" message MAY include one or more "message" attributes to
  convey some additional, human-readable information about the result
  of the request.  The message MAY be included in any language, which
  SHOULD be indicated by the "xml:lang", attribute.  The default
  language is assumed to be English.

I suggest added to the end of last sentence:

("en") [RFC4646bis]"



11.3.  MIME Media Type Registration for 'application/held+xml'

  Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.

Does this have any interaction with HTTP, which uses ISO-8859-1 by default?

  Interoperability considerations:  This content type provides a basis
      for a protocol

This doesn't really say anything about interoperability.
The write-up implies that there are multiple implementations of the protocol already, so you can just say it here.

  Additional Information:  Magic Number(s): (none)
      File extension(s): .xml
      Macintosh File Type Code(s): (none)

I think this should be the same as in RFC 3023:
Macintosh File Type Code(s): "TEXT"

[Ballot discuss]
This is a well written document. There are 4 relatively minor points that I would like to discuss with authors/shepherd/IESG before recommending approval of this document:

1). The document normatively references RFC 2818 for server TLS identity verification.

RFC 2818, Section 3.1 says:

  Matching is performed using the matching rules specified by
  [RFC2459].  If more than one identity of a given type is present in
  the certificate (e.g., more than one dNSName name, a match in any one
  of the set is considered acceptable.) Names may contain the wildcard
  character * which is considered to match any single domain name
  component or component fragment. E.g., *.a.com matches foo.a.com but
  not bar.foo.a.com. f*.com matches foo.com but not bar.com.

This allows for wildcard like f*.com (i.e. the leftmost component is not just "*"). I don't believe this is a recommended procedure for wildcard matching and other application protocols don't allow it. So I would like to discuss what should be recommended in this case.

2). In Section 6.5.2 ("expires" Parameter):

  The "expires" attribute is only included in a "locationResponse"
  message when a "locationUriSet" element is included.  The "expires"
  attribute indicates the date/time at which the Location URIs provided

This doesn't specify if the date/time is in local timezone, in UTC, or is allowed to be either.
I believe local timezone might cause some minor interoperability problems, as the Device would have to discover server's timezone.

I would encourage using the last paragraph of draft-hollenbeck-rfc4930bis-02.txt, Section 5 to address this issue, or argue why other formats should be allowed.

(Note, if you choose to disallow local timezone, you also need to fix your examples).

  by the LIS will expire.  The "expires" attribute does not define the

2b). COMMENT: As fractional seconds seem to be allowed in the "expire" attribute, it would have been nice to have an example of this.


3). In Section 6.3 ("code" Parameter):

  The value of the response code MUST be one of the following tokens:

This make it sound that the list of error codes is not extensible, yet you establish an IANA registry for them.

4). "application/held+xml" MIME type registration was sent to ietf-types@iana.org mailing list for review in April 2008:



However none of the comments raised on the mailing list were addressed or responded to:

[Ballot comment]
6.4.  "message" Parameter

  The "error" message MAY include one or more "message" attributes to
  convey some additional, human-readable information about the result
  of the request.  The message MAY be included in any language, which
  SHOULD be indicated by the "xml:lang", attribute.  The default
  language is assumed to be English.

I suggest added to the end of last sentence:

("en") [RFC4646bis]"



11.3.  MIME Media Type Registration for 'application/held+xml'

  Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.

Does this have any interaction with HTTP, which uses ISO-8859-1 by default?

  Interoperability considerations:  This content type provides a basis
      for a protocol

This doesn't really say anything about interoperability.
The write-up implies that there are multiple implementations of the protocol already, so you can just say it here.

  Additional Information:  Magic Number(s): (none)
      File extension(s): .xml
      Macintosh File Type Code(s): (none)

I think this should be the same as in RFC 3023:
Macintosh File Type Code(s): "TEXT"

[Ballot discuss]
This is a well written document. There are 4 relatively minor points that I would like to discuss with authors/shepherd/IESG before recommending approval of this document:

1). The document normatively references RFC 2818 for server TLS identity verification.

RFC 2818, Section 3.1 says:

  Matching is performed using the matching rules specified by
  [RFC2459].  If more than one identity of a given type is present in
  the certificate (e.g., more than one dNSName name, a match in any one
  of the set is considered acceptable.) Names may contain the wildcard
  character * which is considered to match any single domain name
  component or component fragment. E.g., *.a.com matches foo.a.com but
  not bar.foo.a.com. f*.com matches foo.com but not bar.com.

This allows for wildcard like f*.com (i.e. the leftmost component is not just "*"). I don't believe this is a recommended procedure for wildcard matching and other application protocols don't allow it. So I would like to discuss what should be recommended in this case.

2). In Section 6.5.2 ("expires" Parameter):

  The "expires" attribute is only included in a "locationResponse"
  message when a "locationUriSet" element is included.  The "expires"
  attribute indicates the date/time at which the Location URIs provided

This doesn't specify if the date/time is in local timezone, in UTC, or is allowed to be either.
I believe local timezone might cause some minor interoperability problems, as the Device would have to discover server's timezone.

I would encourage using the last paragraph of draft-hollenbeck-rfc4930bis-02.txt, Section 5 to address this issue, or argue why other formats should be allowed.

(Note, if you choose to disallow local timezone, you also need to fix your examples).

  by the LIS will expire.  The "expires" attribute does not define the

2b). Are fractional seconds allowed in the "expire" attribute?

3). In Section 6.3 ("code" Parameter):

  The value of the response code MUST be one of the following tokens:

This make it sound that the list of error codes is not extensible, yet you establish an IANA registry for them.

4). "application/held+xml" MIME type registration was sent to ietf-types@iana.org mailing list for review in April 2008:



However none of the comments raised on the mailing list were addressed or responded to:

[Ballot comment]
6.4.  "message" Parameter

  The "error" message MAY include one or more "message" attributes to
  convey some additional, human-readable information about the result
  of the request.  The message MAY be included in any language, which
  SHOULD be indicated by the "xml:lang", attribute.  The default
  language is assumed to be English.

I suggest added to the end of last sentence:

("en") [RFC4646bis]"



11.3.  MIME Media Type Registration for 'application/held+xml'

  Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.

Does this have any interaction with HTTP, which uses ISO-8859-1 by default?

  Interoperability considerations:  This content type provides a basis
      for a protocol

This doesn't really say anything about interoperability.
The write-up implies that there are multiple implementations of the protocol already, so you can just say it here.

  Additional Information:  Magic Number(s): (none)
      File extension(s): .xml
      Macintosh File Type Code(s): (none)

I think this should be the same as in RFC 3023:
Macintosh File Type Code(s): "TEXT"

[Ballot discuss]
This is a well written document. There are 4 relatively minor points that I would like to discuss with authors/shepherd/IESG before recommending approval of this document:

1). The document normatively references RFC 2818 for server TLS identity verification.

RFC 2818, Section 3.1 says:

  Matching is performed using the matching rules specified by
  [RFC2459].  If more than one identity of a given type is present in
  the certificate (e.g., more than one dNSName name, a match in any one
  of the set is considered acceptable.) Names may contain the wildcard
  character * which is considered to match any single domain name
  component or component fragment. E.g., *.a.com matches foo.a.com but
  not bar.foo.a.com. f*.com matches foo.com but not bar.com.

This allows for wildcard like f*.com (i.e. the leftmost component is not just "*"). I don't believe this is a recommended procedure for wildcard matching and other application protocols don't allow it. So I would like to discuss what should be recommended in this case.

2). In Section 6.5.2 ("expires" Parameter):

  The "expires" attribute is only included in a "locationResponse"
  message when a "locationUriSet" element is included.  The "expires"
  attribute indicates the date/time at which the Location URIs provided

This doesn't specify if the date/time is in local timezone, in UTC, or is allowed to be either.
I believe local timezone might cause some minor interoperability problems, as the Device would have to discover server's timezone.

I would encourage using the last paragraph of draft-hollenbeck-rfc4930bis-02.txt, Section 5 to address this issue, or argue why other formats should be allowed.

(Note, if you choose to disallow local timezone, you also need to fix your examples).

  by the LIS will expire.  The "expires" attribute does not define the

2b). Are fractional seconds allowed in the "expire" attribute?

3). In Section 6.3 ("code" Parameter):

  The value of the response code MUST be one of the following tokens:

This make it sound that the list of error codes is not extensible, yet you establish an IANA registry for them.

4). "application/held+xml" MIME type registration was sent to ietf-types@iana.org mailing list for review in April 2008:

http://eikenes.alvestrand.no/pipermail/ietf-types/2008-April/002028.html

However none of the comments raised were addressed or responded to.

[Ballot discuss]
Bernard Aboba suggested that the LIS to make the choice on whether to
  challenge the device based on the nature of the request.  Devices only
  supporting requests that cannot be challenged (e.g. requests utilizing
  implicit IP address identification) could omit support for HTTP
  authentication.  However, if a device were to make a request of
  another type (e.g. utilizing HELD extensions), the LIS could challenge
  it and therefore the device would need to support HTTP authentication.

  This makes a lot of sense to me.  I do not (yet) see RFC Editor notes
  to implement this suggestion.

[Ballot comment]
6.2.  "locationType" Parameter

  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
  case where a Device has a preference for just "geodetic" or "civic",
  it is necessary to make the request without an "exact" attribute,
  including both location types.  In this case, if neither is available
  a LIS SHOULD return a locationURI if available.

Can you explain the last sentence?
I admin I am being ignorant, but my understanding that resolution of
locationURI would result in either geodetic or civic location information.



6.4.  "message" Parameter

  The "error" message MAY include one or more "message" attributes to
  convey some additional, human-readable information about the result
  of the request.  The message MAY be included in any language, which
  SHOULD be indicated by the "xml:lang", attribute.  The default
  language is assumed to be English.

I suggest added to the end of last sentence:

("en") [RFC4646bis]"



Where the meaning of "emergencyRouting" and "emergencyDispatch" values in "responseTimeType" is defined/explained?


10.3.  Location Request Example for Multiple Location Types

  The following Location Request message includes a request for
  geodetic, civic and any Location URIs.

       
         
            geodetic
            civic
            locationURI

This makes me wonder why location types are not separate XML elements, subordinate to

         
         

11.3.  MIME Media Type Registration for 'application/held+xml'

  Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.

Does this have any interaction with HTTP, which uses ISO-8859-1 by default?

  Interoperability considerations:  This content type provides a basis
      for a protocol

This doesn't really say anything about interoperability.
The write-up implies that there are multiple implementations of the protocol already, so you can just say it here.

  Additional Information:  Magic Number(s): (none)
      File extension(s): .xml
      Macintosh File Type Code(s): (none)

I think this should be the same as in RFC 3023:
Macintosh File Type Code(s): "TEXT"

[Ballot discuss]
This is a well written document. There are 4 relatively minor points that I would like to discuss with authors/shepherd/IESG before recommending approval of this document:

1). The document normatively references RFC 2818 for server TLS identity verification.

RFC 2818, Section 3.1 says:

  Matching is performed using the matching rules specified by
  [RFC2459].  If more than one identity of a given type is present in
  the certificate (e.g., more than one dNSName name, a match in any one
  of the set is considered acceptable.) Names may contain the wildcard
  character * which is considered to match any single domain name
  component or component fragment. E.g., *.a.com matches foo.a.com but
  not bar.foo.a.com. f*.com matches foo.com but not bar.com.

This allows for wildcard like f*.com (i.e. the leftmost component is not just "*"). I don't believe this is a recommended procedure for wildcard matching and other application protocols don't allow it. So I would like to discuss what should be recommended in this case.

2). In Section 6.5.2 ("expires" Parameter):

  The "expires" attribute is only included in a "locationResponse"
  message when a "locationUriSet" element is included.  The "expires"
  attribute indicates the date/time at which the Location URIs provided

This doesn't specify if the date/time is in local timezone, in UTC, or is allowed to be either.
I believe local timezone might cause some minor interoperability problems, as the Device would have to discover server's timezone.

I would encourage using the last paragraph of draft-hollenbeck-rfc4930bis-02.txt, Section 5 to address this issue, or argue why other formats should be allowed.

(Note, if you choose to disallow local timezone, you also need to fix your examples).

  by the LIS will expire.  The "expires" attribute does not define the

2b). Are fractional seconds allowed in the "expire" attribute?

3). In Section 6.3 ("code" Parameter):

  The value of the response code MUST be one of the following tokens:

This make it sound that the list of error codes is not extensible, yet you establish an IANA registry for them.

4). Please confirm that "application/held+xml" MIME type registration was sent to ietf-types@iana.org mailing list for 2 weeks review.

(See  for more details.)

If there was no ietf-types@iana.org review yet, I suggest addressing my comments (see the Comment section) first.

[Ballot comment]
6.2.  "locationType" Parameter

[...]

  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
  case where a Device has a preference for just "geodetic" or "civic",
  it is necessary to make the request without an "exact" attribute,
  including both location types.  In this case, if neither is available
  a LIS SHOULD return a locationURI if available.

Can you explain the last sentence?
I admin I am being ignorant, but my understanding that resolution of
locationURI would result in either geodetic or civic location information.



6.4.  "message" Parameter

  The "error" message MAY include one or more "message" attributes to
  convey some additional, human-readable information about the result
  of the request.  The message MAY be included in any language, which
  SHOULD be indicated by the "xml:lang", attribute.  The default
  language is assumed to be English.

I suggest added to the end of last sentence:

("en") [RFC4646bis]"

   
     
       
         
           
           

Where the meaning of these values is explained?

         
       
       
         
           
         
       
     
   


10.3.  Location Request Example for Multiple Location Types

  The following Location Request message includes a request for
  geodetic, civic and any Location URIs.

       
         
            geodetic
            civic
            locationURI

This makes me wonder why location types are not separate XML elements, subordinate to

         
         

11.3.  MIME Media Type Registration for 'application/held+xml'

[...]

  Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.

Does this have any interaction with HTTP, which uses ISO-8859-1 by default?

  Interoperability considerations:  This content type provides a basis
      for a protocol

This doesn't really say anything about interoperability.
The write-up implies that there are multiple implementations of the protocol already, so you can just say it here.

[...]

  Additional Information:  Magic Number(s): (none)
      File extension(s): .xml
      Macintosh File Type Code(s): (none)

I think this should be the same as in RFC 3023:
Macintosh File Type Code(s): "TEXT"

[Ballot discuss]
This is a well written document. There are 4 relatively minor points that I would like to discuss with authors/shepherd/IESG before recommending approval of this document:

1). The document normatively references RFC 2818 for server TLS identity verification.

RFC 2818, Section 3.1 says:

  Matching is performed using the matching rules specified by
  [RFC2459].  If more than one identity of a given type is present in
  the certificate (e.g., more than one dNSName name, a match in any one
  of the set is considered acceptable.) Names may contain the wildcard
  character * which is considered to match any single domain name
  component or component fragment. E.g., *.a.com matches foo.a.com but
  not bar.foo.a.com. f*.com matches foo.com but not bar.com.

This allows for wildcard like f*.com (i.e. the leftmost component is not just "*"). I don't believe this is a recommended procedure for wildcard matching and other application protocols don't allow it. So I would like to discuss what should be recommended in this case.

2). In Section 6.5.2 ("expires" Parameter):

  The "expires" attribute is only included in a "locationResponse"
  message when a "locationUriSet" element is included.  The "expires"
  attribute indicates the date/time at which the Location URIs provided

This doesn't specify if the date/time is in local timezone, in UTC, or is allowed to be either.
I believe local timezone might cause some minor interoperability problems, as the Device would have to discover server's timezone.

I would encourage using the last paragraph of draft-hollenbeck-rfc4930bis-02.txt, Section 5 to address this issue, or argue why other formats should be allowed.

(Note, if you choose to disallow local timezone, you also need to fix your examples).

  by the LIS will expire.  The "expires" attribute does not define the

2b). Are fractional seconds allowed in the "expire" attribute?

3). In Section 6.3 ("code" Parameter):

  The value of the response code MUST be one of the following tokens:

This make it sound that the list of error codes is not extensible, yet you establish an IANA registry for them.

4). Please confirm that "application/held+xml" MIME type registration was sent to ietf-types@iana.org mailing list for 2 weeks review.

(See  for more details.)

If there was no ietf-types@iana.org review yet, I suggest addressing my comments (see the Comment section) first.

The GEOPRIV working group requests publication of
draft-ietf-geopriv-http-location-delivery-13 as a Proposed Standard.

(1.a) Richard Barnes is the document shepherd. Richard has reviewed this
document and believes it is ready for publication.

(1.b) This document has received detailed review from the entire working
group and has had scrutiny from several key advisors outside the working
group.

(1.c) The document has had input from people with good XML, security,
and HTTP skills. Lisa Dusseault has been active in her role as
technical advisor to the GEOPRIV working group during this documents
development. A prior IETF LC raised additional issues from the security
and HTTP communities, which have been addressed in this version. Normal
IETF LC and AD review activities should provide sufficient additional
review.

(1.d) The shepherd has no specific technical concerns with this document
to which to call attention. No IPR disclosures have been filed against
this document.

(1.f) There have been no threatened appeals against this document.
However, achieving consensus on this document has not been a
conflict-free process, and did result in an appeal that has already been
resolved. The environment of conflict in the working group has subsided
and there is group-wide support for the document as it is being
submitted now.

(1.g) The Shepherd has personally verified that the document satisfies
the ID nit requirements. The document received URI and media type
reviews during a previous LC, but text defining a URI scheme has since
been removed.

(1.h) The document's references are appropriately split into normative
and informative. There is two normative references to draft documents:
The first, draft-ietf-geopriv-pdif-lo-profile, is currently in the RFC
Editor's queue. The second, draft-ietf-geopriv-lis-discovery, is close
to consensus in the WG and should be submitted for publication soon.

(1.i) The document has an extensive IANA considerations section. The
requests made of IANA are clearly written. The document requests the
creation of one new registry for error codes. It proposes initial
contents and establishes "Specification Required" for new values. It
proposes a reasonable name for the registry.

(1.j) Martin Thomson verified all the XML code. The shepherd also
verified the XML using the tools at validate.openlaboratory.net. There
are no MIB definitions or BNF. (The document included one line of BNF as
of its last LC, but this line has since been removed.)

(1.k) Announcement Writeup:

Technical Summary:


A Layer 7 Location Configuration Protocol (L7 LCP) is described that is
used for retrieving location information from a server within an access
network. The protocol includes options for retrieving location
information in two forms: by value and by reference. The protocol is an
extensible application-layer protocol that is independent of
session-layer. This document describes the use of Hypertext Transfer
Protocol (HTTP) as a transport for the protocol.

Working Group

This document represents a very strong consensus position of the GEOPRIV
working group. This consensus was unusually difficult to acheive and
carries a long history of conflict and compromise, but is nonetheless
very strong at this point.

Document Quality:

There are multiple interoperable implementations of the protocol
described in this document and strong interest in implementation and
deployment. The protocol described here is referenced in ongoing work in
the ECRIT working group, and in several emerging national standards for
emergency calling. Lisa Dusseault has been active as the GEOPRIV working
group's technical advisor during the development of this document.

IANA Last Call comments:

Action #1:
Upon approval of this document, the IANA will make the following
assignment in the "NS" registry at
http://www.iana.org/assignments/xml-registry/ns.html

ID | URI | Reg Template | Ref
held | urn:ietf:params:xml:ns:geopriv:held |  |
[RFC-geopriv-http-location-
delivery-07]


Action #2:
Upon approval of this document, the IANA will make the following assignment in
the "Schema" registry at
http://www.iana.org/assignments/xml-registry/schema.html

ID | URI | Filename | Ref
held | urn:ietf:params:xml:schema:geopriv:held |  |
[RFC-geopriv-http-location-delivery-07]


Action #3:
Upon approval of this document, the IANA will make the following
assignment in the "Application Media Types" registry at
http://www.iana.org/assignments/media-types/application/

held+xml [RFC-geopriv-http-location-delivery-07]



Action #4:
Upon approval of this document, the IANA will create the following
registry "Geopriv Held Error Codes per [RFC-geopriv-http-location-
delivery-07]" at http://www.iana.org/assignments/TBD

Registration Procedures: Specification Required
Note: Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary
Barnes (mary.barnes@nortel.com).

Registry:
Error name | Description | Reference
-------------------------------------
requestError | This code indicates that the request was badly
formed in some fashion. | [RFC-geopriv-http-location-delivery-07]

xmlError | This code indicates that the XML content of the request
was either badly formed or invalid. | [RFC-geopriv-http-location-delivery-07]

generalLisError | This code indicates that an unspecified error
occurred at the LIS.| [RFC-geopriv-http-location-delivery-07]

locationUnknown | This code indicates that the LIS could not
determine the location of the Device.| [RFC-geopriv-http-location-delivery-07]

unsupportedMessage | This code indicates that the request was not
supported or understood by the LIS. | [RFC-geopriv-http-location-delivery-07]

timeout | This code indicates that the LIS could not satisfy the
request within the time specified in the "responseTime" parameter. |
[RFC-geopriv-http-location-delivery-07]

cannotProvideLiType | This code indicates that the LIS was unable to
provide LI of the type or types requested. This code is used when
the "exact" attribute on the "locationType" parameter is set to
"true".| [RFC-geopriv-http-location-delivery-07]


Action #5

Upon approval of this document, the IANA will make the following
assignments in the "Schema" registry at
http://www.iana.org/assignments/xml-registry/schema.html

ID | URI | Filename | Ref
helds | urn:ietf:params:xml:schema:geopriv:helds |  |
[RFC-geopriv-http-location-delivery-07]


We understand the above to be the only IANA Actions for this
document.

The GEOPRIV working group requests publication of draft-ietf-geopriv-http-location-delivery-07 as a Proposed Standard.

(1.a) Robert Sparks is the document shepherd. Robert has reviewed this document and believes it is ready for publication.

(1.b) This document has received detailed review from the entire working group and has had scrutiny from key advisors outside the working group.

(1.c) The document has had input from people with good XML and security skills.  Lisa Dusseault has been active in her role as technical advisor to the GEOPRIV working group during this documents development. Normal IETF LC and AD review activities should be sufficeint additional review.

(1.d) The shepherd has no specific technical concerns with this document to which to call attention. No IPR disclosures have been filed against this document.

(1.f) There have been no threatened appeals against this document. However, acheiving consensus on this document has not been a conflict-free process, and did result in an appeal that has already been resolved. The environment of conflict in the working group has subsided and there is group-wide support for the document as it is being submitted now.

(1.g) The Shepherd has personally verified that the document satisfies the ID nit requirements.  Cullen Jennings requested media type and URI reviews for this document.

(1.h) The document references are appropriately split into normative and informative.
    There are two normative references to drafts:
    draft-ietf-geopriv-pdif-lo-profile : (publication requested - in AD Evaluation)
    draft-ietf-geopriv-lis-discovery : (still in WG discussion)

(1.i) The document has an extensive IANA considerations section. The requests made of IANA are clearly written. The document requests the creation of one new registry for error codes.  It proposes initial contents and establishes "Specification Required" for new values. It proposes a reasonable name for the registry.

(1.j) Martin Thomson verified all the XML code. The shepherd also verified the XML using the tools at validate.openlaboratory.net. The one line of BNF was tested against Bill Fenner's parser. There are no MIB definitions.

(1.k) Announcement Writeup:

Technical Summary:
  A Layer 7 Location Configuration Protocol (L7 LCP) is described that
  is used for retrieving location information from a server within an
  access network.  The protocol includes options for retrieving
  location information in two forms: by value and by reference.  The
  protocol is an extensible application-layer protocol that is
  independent of session-layer.  This document describes the use of
  Hypertext Transfer Protocol (HTTP) as a transport for the protocol.

Working Group Summary:
  This document represents a very strong consensus position of the GEOPRIV working group.
  This consensus was unusually difficult to acheive and carries a long history of conflict and compromise.

Document Quality:
  There is at least one existing implementations of the protocol described in this document and strong
  interest in implementation and deployment. The protocol described here is referenced in ongoing work
  in the ECRIT working group. Lisa Dusseault has been active as the GEOPRIV working group's technical advisor
  during the development of this document.