Subject: [Geopriv] [geopriv] #49: Review of Deref Protocol document

From: "geopriv issue tracker" <[email-masked]>
Date: Thu, 21 Apr 2011 23:35:12 -0000

#49: Review of Deref Protocol document

 Overall, I think that this document could be clearer that the deref
 protocol defined can be used with any LCP, and that support for generic
 deref via GET is supported (e.g. I'd make that a mandatory to implement).

 Detailed comments:

    Provision of location information by reference [RFC5808] involves the
    creation of a resource that is identified by a "location URI".  A
    "location URI" is a URI [RFC3986] that identifies a resource
    containing the location of an entity.  A location URI might identify
    a temporary resource, created in response to a HTTP-Enabled Location
    Delivery (HELD) [RFC5985] request.

 [BA] might?  This left me wondering what else it might be used for.
 For example, could it represent a temporary resource created in
 response to another protocol request (e.g. DHCP), or maybe a non-temporary
 resource?

    A location URI does not
    intrinsically include location information, instead the URI is
    "dereferenced" by a Location Recipient to acquire location
    information.  This document specifies how a holder of a location URI
    uses that URI to retrieve location information.

 [BA] This raised the question for me of how general the deref mechanism
 is.  Is it just for HELD, or is it a generic mechanism for dereferencing?

    Use of HELD as a dereferencing protocol has the advantage that the
    Location Recipient can indicate the type of location information it
    would like to receive.  This functionality is already available with
    the HELD base specification, described in [RFC5985].  Furthermore,
    the HELD response from the LIS towards the Location Recipient not
    only provides the PIDF-LO but also encapsulates supplementary
    information, such as error messages, back to the Location Recipient.

 [BA] There are other ways of indicating the type of location info that
 the recipient wants to receive (think REST).  Are there benefits of
 using HELD here really worth sacrificing generality?  Personally, I
 think not.  Many of the error cases can probably
 be handled in generic HTTP/TLS.

    Location URIs created for use with HELD dereferencing use the
    "https:" or "http:" scheme.  The behaviour described in this document
    can be used by Location Recipients that are aware of the fact that
    the URI is a location URI.

 [BA] So how does the dereferencer know that HELD is to be used to
 dereference
 rather than generic HTTP??

   1.  The Target acquires a location URI from the LIS.  This might use
        HELD as a location configuration protocol (LCP).

 [BA] "might" again.  If it could be from another LCP, please say so.

        Depending on the URI
        scheme of the location URI dereferencing might, as is the case
        for "https:" or "http:" URIs, be performed as described in this
        document.

 [BA] Are you saying that deferencing of an https: or http: URI might be
 performed in some other way than is described here?  If so, how??

    Using possession as a basis for authorization means that, once
    granted, authorization cannot be easily revoked.

 [BA] Well, at least without changing to the "Access Control" model.

    In order to control access to location information based on the
    identity of the Location Recipient, use of authorization by
    possession is employed.  By controlling which Location Recipients
    receive location URIs, access to location information is controlled.

 [BA] There are other possibilities that come to mind, too (e.g. firewall
 filter rules)

 Section 4.2

    GET is the method assumed by generic HTTP user agents, therefore
    unless context identifies an "https:" URI as a HELD URI, such a user
    agent might simply send an HTTP GET.  Rather than providing an HTTP
    405 (Method Not Allowed) response indicating that POST is the only
    permitted method, this document describes a way for a LIS to provide
    a HELD location response if it receives an HTTP GET request.

 [BA] It's nice that GET is supported, and I suspect that implementation of
 this
 will be quite popular, to enable generic dereferencing.  Given that, I'd
 try to align some of the earlier discussion to point out that generic
 deref via GET is supported.  In particular, I'd make GET support
 mandatory-to-implement.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:     
     Type:  defect                     |      Status:  new
 Priority:  critical                   |   Milestone:     
Component:  deref-protocol             |     Version:  1.0
 Severity:  In WG Last Call            |    Keywords:     
---------------------------------------+------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/geopriv/trac/ticket/49>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 29 Apr 2011 08:34:02 +0800

Good feedback, thanks for the review Bernard.

On 2011-04-22 at 09:35:12, geopriv issue tracker wrote:
> protocol defined can be used with any LCP, and that support for 
> generic deref via GET is supported (e.g. I'd make that a mandatory to 
> implement).

That can be (and has been) done.  The first as part of addressing the next comment, the latter as a new introduction paragraph.

>     [...]  A location URI might 
> identify
> response to another protocol request (e.g. DHCP), or maybe a non- 
> temporary  resource?

There's certainly nothing preventing the resource from being non-temporary, but that's a tricky arrangement to get right without some special access controls.  In either case, I've removed the offending clause and replaced it with:

	A location URI can be acquired using a location configuration protocol, such as HTTP-Enabled Location Delivery (HELD) [RFC5985] or the Dynamic Host Configuration Protocol (DHCP) location URI option [I-D.ietf-geopriv-dhcp-lbyr-uri-option].  

>  [BA] This raised the question for me of how general the deref 
> mechanism  is.  Is it just for HELD, or is it a generic mechanism for 
> dereferencing?

Good point.  We could discuss the use of HTTP to dereference URIs in other schemes, which is theoretically possible and practically infeasible.  Better to properly constrain scope:

  [...]  This document specifies how the holder of an "http:" or "https:" location URI [...]

>  [BA] There are other ways of indicating the type of location info 
> that the recipient wants to receive (think REST).  Are there benefits 
> of using HELD here really worth sacrificing generality?  Personally, I 
> think not.  Many of the error cases can probably  be handled in 
> generic HTTP/TLS.

You are right, content negotiation could be made to work.  Given the composite nature of PIDF, the limitations of content negotiation become evident.  Ultimately, what we're looking for is the richness of expression available in location filters [draft-ietf-geopriv-loc-filters], including the referenced RFC 4661 capabilities.  That becomes unwieldy very quickly when expressing it in a media type.

> dereference  rather than generic HTTP??

They might use the content type of the response entity.  The draft now makes this observation in S4.2, along with the other GET semantics.

   A Location Recipient MAY infer from a response containing the HELD content type, "application/held+xml", that a URI references a resource that supports HELD.

>  [BA] "might" again.  If it could be from another LCP, please say so.

Done.

>  [BA] Are you saying that deferencing of an https: or http: URI might 
> be  performed in some other way than is described here?  If so, how??

Yeah, that's clumsy.  How about:

	An "https:" or "http:" URI is dereferenced as described in this document; other URI schemes might be dereferenced using another method.

>  [BA] Well, at least without changing to the "Access Control" model.

Right.  Or you could say that there is always access control, but use of "possession model" implies an expansively liberal access control policy.  That policy might be changed to become more restrictive, which is exactly what the policy URI document does.

>  [BA] There are other possibilities that come to mind, too (e.g.
> firewall  filter rules)

Sure.  Though describing such options probably doesn't add enough value to justify the extra bytes required.
 
>  [BA] It's nice that GET is supported, and I suspect that 
> implementation of  this  will be quite popular, to enable generic 
> dereferencing.  Given that, I'd  try to align some of the earlier 
> discussion to point out that generic  deref via GET is supported.  In 
> particular, I'd make GET support  mandatory-to-implement.

That's a good point.  I certainly would expect GET to be the most common case, so I've made it mandatory as you suggest.  I think that a similar sentiment was expressed by Julian Reschke as well, but I failed to translate it into a MUST.

--Martin

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 28 Apr 2011 18:31:27 -0700

>    A Location Recipient MAY infer from a response containing the HELD content type, "application/held+xml", that a URI references a resource that supports HELD.

[BA] Thanks.  
Some questions:
a. In the above are you referring to the response in the original HELD exchange, or to a response to a dereference request (e.g. a GET or POST)?  b. If this would apply to a dereference using a GET, is the implication that a HELD-capable client might subsequently choose to upgrade its requests to HELD (for error resilience or other reasons?)c.. Should a de-reference request using GET specify the content types it prefers/is prepared to handle in the GET via an Accept: header?  d. If so, are there content types that could be provided in the de-reference request other than "application/held+xml"? (e.g. to indicate whether the de-reference requester does/doesn't support HELD).    e. Should a LIS be prepared to support content types other than "application/held+xml" in a request Accept: header?

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 29 Apr 2011 09:44:55 +0800

On 2011-04-29 at 11:31:27, Bernard Aboba wrote:
> > A Location Recipient MAY infer from a response containing the HELD
> content type, "application/held+xml", that a URI references a resource 
> that supports HELD.
> 
> 
> [BA] Thanks.
> 
> Some questions:
> 
> a. In the above are you referring to the response in the original HELD 
> exchange, or to a response to a dereference request (e.g. a GET or 
> POST)?

I'm adding this to the discussion on GET, so that would be the implication.  I suppose that if you get a HELD response to a HELD request, then you are pretty safe in assuming that the resource supports HELD.

> b. If this would apply to a dereference using a GET, is the 
> implication that a HELD-capable client might subsequently choose to 
> upgrade its requests to HELD (for error resilience or other reasons?) 

Right.  Say you dereference using GET and get a geodetic location.  You could then upgrade and send a HELD request to get a civic address.

> c.. Should a de-reference request using GET specify the content types 
> it prefers/is prepared to handle in the GET via an Accept: header?

Accept is always optional.  In the absence of Accept:, the server gets to choose content type.  A HELD server should always support application/held+xml, though they might also support application/pidf+xml as noted in S4.2.

> d. If so, are there content types that could be provided in the de- 
> reference request other than "application/held+xml"? (e.g. to indicate 
> whether the de-reference requester does/doesn't support HELD).

If Accept didn't include */* or application/* or application/held+xml, then the server would have to infer that they didn't support HELD and should send a 406 (Not Acceptable) response.  

> e. Should a LIS be prepared to support content types other than 
> "application/held+xml" in a request Accept: header?

A compliant HTTP server should act as above.  I can see this not happening for various reasons (lazy implementation primarily).  Most HTTP clients either send */* or omit Accept entirely so I can see a LIS implementation just ignoring Accept.  RFC 2616 uses SHOULD for the 406 response, so that's arguably permissible behaviour.

--Martin