Subject: [Geopriv] GeoPriv :- Revised HTTP Enabled Location Delivery Draft

From: "James Winterbottom" <[email-masked]>
Date: Thu, 21 Jul 2005 16:06:32 +1000

Hi,

The HTTP Enabled Location Delivery (HELD) draft has been updated to version
01.
This protocol describes a comprehensive application layer location
acquisition protocol using HTTP over TLS.

http://www.ietf.org/internet-drafts/draft-winterbottom-http-location-deliver
y-01.txt

Cheers
James

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: John Schnizlein <[email-masked]>
Date: Fri, 22 Jul 2005 17:20:30 -0400

Below this line is what I am considering sending - help!
_______________
I am having difficulty understanding just how HELD is supposed to work.

Please answer a few questions to help me interpret the draft:

1) What does the location URI look like?  Since section 6 says:
   "The Location Server MUST be able to uniquely identify the IP-device
    based on a location URI or presentity pseudonym.  Identity matching
    SHOULD occur through internal correlation only; it SHOULD NOT be
    possible to perform a computational transform on these data to
    identify the IP-device."
it seems clear it does not contain the host's name or address.
I could not find and example URI in the appendix.
draft-winterbottom-location-uri-00.txt motivates the URI concept,
but does not define its form or provide an example.

2) What is the purpose for defining the special on behalf of (OBO)
entity, with all its complications?

3) Since the OBO specification includes a pre-arranged trust
relationship between the OBO and Location Server, why doesn't
the Target need a trust relationship for where its location and
location-disclosure policy reside?

4) What sort of relationship is assumed between the operator
of the target's DHCP server and the Location Server?
Without a relationship there, how could we expect the DHCP
server to be configured with the right list of LocServer URIs?

5) In what domain is the proposed SRV record?
In other words, what is the fully-qualified owner?
Similarly to question 4, what compels the zone operator
of this (as yet unspecified) domain to include any
particular Location Server names in these SRV records?

BTW: the syntax of the SRV owner name is _service._tcp.<domain>.
The '_' is on the wrong side of the '.' in the draft.

6) How does the target, or any host for that matter, know what
name (beyond the _locserv+http._tcp prefix) to look up?

7) Why does a host capable of generating its own location
have to provide the Location Server a means of interrogating
it, rather than just providing its location?

8) How is the ruleset URI associated with the location URI?

9) Without knowing the user, how does the Location Server
know that the ruleset URI points to the user's authorized
set of disclosure rules?

10) How is ruleset provided to the Location Server?
    "If a "ruleset" is provided to the Location Server then the Location
    Server MUST adhere to the rules, unless it is also provided with a
    "rulesetURI", in which case the rules referenced by the "rulesetURI"
    are used. "

On Jul 21, 2005, at 2:06 AM, James Winterbottom wrote:
>
> The HTTP Enabled Location Delivery (HELD) draft has been updated to  
> version 01.
> http://www.ietf.org/internet-drafts/draft-winterbottom-http-location- 
> delivery-01.txt

---

From: John Schnizlein <[email-masked]>
Date: Fri, 22 Jul 2005 17:28:17 -0400

Now that I have mistakenly exposed my ignorance to the whole list :-(
I guess I would appreciate answers from everyone.

Not sure Marc would have been able to answer these anyway.
(No offense, Marc.)  Sigh!