Re: [Geopriv] Comments on HELD -04

Hi Richard,

Thanks for taking the time to thoroughly review the document and provide
this summary. I will respond to each of the items in separate threads to
make it easier to track the consensus.

Thanks,
Mary.

-----Original Message-----
From: Richard Barnes [mailto:rbarnes@bbn.com]
Sent: Wednesday, January 30, 2008 6:57 PM
To: 'GEOPRIV'
Subject: [Geopriv] Comments on HELD -04

After a review of HELD -04, I think the document is substantially
complete. That said, I do have some comments in addition to those that
have already been expressed I've discussed a series of nits and
editorial changes with the authors, and I would like to bring the
following questions to the list.

--Richard

1. HELD URI
The specification of a HELD URI scheme in the current draft seems
incomplete, in that it doesn't fully specify a dereference scheme.
However, specifying a dereference scheme would essentially make
draft-winterbottom-geopriv-deref-protocol a part of the HELD
specification. That is, if the HELD URI were completely specified, the
base HELD spec would specify not only an LCP usage of HELD but also a
location-by-reference usage.

On the other hand, I haven't heard a compelling reason that a HELD URI
is necessary if the only supported use case is an LCP. In that case, it
seems sufficient for the endpoint simply to acquire a DNS name or IP
address for the LIS, so that it can send a HELD/HTTP request to port 80
on that interface (the Request-URI could be fixed in the standard, e.g.,
"/"). So if we only want the current draft to support the usage of HELD
as an LCP, the HELD URI can be removed altogether.

So I think there are two alternatives:
a. Completely specify the HELD URI, including dereference by 3rd parties
b. Remove the HELD URI from the draft and only support the LCP usage My
personal preference is for the former, but I don't have any strong
objections to either option. However, we should decide on one of these
two courses.

2. Document structure
Throughout most of the document, HELD is discussed as a single,
integrated protocol, the notable exceptions being Section 5.1 and
Section 8. On the other hand, there are clearly two separate components
to the protocol: The XML syntax, the transport/binding protocol.

The current draft needs to describe better the functions played by these
parts individually as well as together. This is crucial because as HELD
is extended, these two parts will be used with different parts;
different XML (e.g., adding identitifierss or measurements) over HTTP,
or the same XML messages over other bindings (e.g., raw TLS, BEEP).
(Obviously the first case is more likely!) It will be easier to to make
extensions secure and interoperable if the roles of the XML syntax and
the binding are clearly articulated. In addition, I think this will
make the current draft easier to understand.

Consider target identifiers: It isn't clear from the current draft (at
least to me) that the XML has nothing to do with the identifier used for
the target; instead, the identifier is provided by the transport layer.
    If you're implementing a LIS, this tells you to get the identifier
from the whatever transport component you're using. If you're writing
an extension that runs over a new transport, it tells you that you need
to specify an identifier to use. If you're writing
draft-winterbottom-geopriv-held-identity-extensions, it tells you that
you need to explain how your XML identifiers interact with the
identifiers the transport layer provides.

I don't mean to propose a radical re-writing of the document; I think
most of the text is already there. I'd just like to see it organized
differently:
a. Syntax/semantics included in the XML
b. Syntax/semantics included in the binding c. How the HTTP binding
works in particular

3. Identifying information in location URIs Section 6.5 (Location URIs)
says that "A location URI MUST NOT contain any information that could be
used to identify the Device or Target." I certainly agree with the
intent of this statement, but it's hard to say something concrete
because (1) the security objective here is unclear, and (2) the LIS is
inherently incapable of determining what "identifies the Device/Target".
For instance, a LIS operator might think that it's good enough to use a
hash of an IP address instead of the IP address itself. That would
prevent guessing the IP from the URI, but would still allow the URI to
be correlated with a known address, and would allow URIs to be guessed.
I would suggest that we add some more thorough discussion of this to the
Security Considerations (I'll write up some text), and replace this
statement with a pointer to that.

4. Response time parameter
Are people comfortable with the current level of specificity in the
description of the responseTime parameter (Section 6.1)? I have a
little bit of concern over the inherent inability of the LIS to
determine whether it has met the response time, but given that the
language is non-normative, I'm not sure this requires a change to the
text.

5. Caching
Section 8 says that "the "expires" and cache control headers are used to
control the caching of any PIDF-LO document or Location URIs." Should
this say instead that the HTTP header for a locationResponse should
disable caching? I would vote in favor of this, since I don't really
see a need for caching at the HTTP layer, given that the LIS and the
endpoint should be pretty close to each other. The LIS might cache
location results, however.

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
http://www.ietf.org/mailman/listinfo/geopriv
Received on Thu, 31 Jan 2008 14:49:44 -0600