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/>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
