Once upon a time -- in the DHC WG -- I got absolutely plastered for
suggesting more than one URI get requested in a DHCP response. That
WG had a cow about the idea that so many (what is currently called)
sub-options (which are unique URI types each having unique meanings)
*because* , and I'm paraphrasing "you're expecting DHCP to be a
complicated protocol - able to handle each of these sub-options for
each client." What they were trying to tell me is that DHCP is a
simple protocol, and not to clutter it up with so many different
possible combinations - each of which are unique to each client.
DHC may have changed their tune over the years, but consensus was
near unanimous that 1 Option code equals 1 URI type.
What they were saying at the time is they felt they had enough Option
numbers available for each URI purpose. I read below that you are
suggesting at least 2 different URI purposes
- 1 that has unrestricted access
- 1 that provides access to within 50km
DHC WG will - if they haven't changed their collective minds - will
say these two are 2 different DHCP Option codes.
James
At 02:47 PM 4/5/2010, Richard Barnes wrote:
>James,
>
>draft-barnes-geopriv-policy-uri draft describes a really simple
>mechanism for enabling clients to inspect and control what policies
>apply to a URI. Here's an example scenario:
>
>1. LIS provides a client with one URI that provides unrestricted
>access (no policy), and one URI provides access to within 50km, with
>corresponding policy URIs.
>
>2.1. Client sends HTTP GET for policy URI 1
>2.2. Policy server returns 404
>2.3. Client understands no policy == open access
>2.4. (Optional) Client sends HTTP PUT with his own policy
>
>3.1. Client sends HTTP GET for policy URI 2
>3.2. Policy server returns 200 with:
><ruleset>
> <rule>
> <conditions/>
> <actions/>
> <transformations>
> <provide-location profile="geodetic-transformation">
> <provide-geo radius="50000"/>
> </provide-location>
> </transformations>
> </rule>
></ruleset>
>3.3. Client sees that this is a "coarse location" URI
>3.4. (Optional) Client sends HTTP PUT with his own policy
>
>HELD already supports delivering multiple URIs. DHCP could, by
>allowing more sub-options (LURItypes).
>
>--Richard
>
>
>
>On Apr 5, 2010, at 3:25 PM, James M. Polk wrote:
>
>>At 04:50 PM 4/2/2010, Henning Schulzrinne wrote:
>>>I suspect there are shades of gray here. It's clearly used for
>>>pictures (or albums), not so much for larger-scale access (e.g.,
>>>all my Picasa pictures or the whole Facebook profile). Thus, I
>>>suspect a "secret" location URL that reveals where I am at 5 pm
>>>today may not raise much of an eyebrow, but a URL that allows
>>>tracking me from today until next December more so. To their
>>>credit, Picasa also does a pretty decent job of explaining how to
>>>use this URL, e.g., by showing an HTML snippet.
>>
>>That said -- it appears Richard has successfully pointed out how
>>different Location URIs can be used. How exactly is this supposed
>>to be translated into an LCP's delivery of the URIs? Currently DHCP
>>is being proposed to only have 1 Location URI sent to a client about
>>its location. The client isn't really going to be able to tell which
>>resolution (or granularity or accuracy) this URI will provide to a
>>dereferencer. That makes this inconsistent with what this thread is
>>offering.
>>
>>Does HELD have this level of control as an LCP -- i.e., to be able
>>to give an endpoint multiple location URIs, each with differing --
>>but known to the endpoint -- purposes?
>>
>>This level of complication/complexity isn't something I've heard the
>>WG talk about previously.
>>
>>James
>>
>>
>>>Henning
>>>
>>>On Apr 2, 2010, at 5:40 PM, Richard Barnes wrote:
>>>
>>> > Henning,
>>> >
>>> > It seems to me that the the "random stuff in a URI"
>>>authentication scheme is already really used today. For example,
>>>say I post pictures to Picasa. I can mark albums as public or
>>>private, and only the public albums show up on my user page when a
>>>random stranger views it, at a URI of the form:
>>> >
>>> > <http://picasaweb.google.com/username>
>>> >
>>> > However, when I as the owner load a picture or album page, it
>>>provides a URI that I can send to anyone that will show them the
>>>picture (but nothing else) or one that shows the album. These URIs
>>>have the form:
>>> >
>>> >
>>> <http://picasaweb.google.com/username/albumname?authkey=293590D256FBEE1F75E816
>>> >
>>> >
>>> > (Borrowing Henning's random bytes.)
>>> >
>>> > So it seems like the market is refuting your hypothesis about
>>>user preferences.
>>> >
>>> > --Richard
>>> >
>>> >
>>> >
>>> > On Apr 2, 2010, at 5:06 PM, Henning Schulzrinne wrote:
>>> >
>>> >>>
>>> >>> One thing that I believe where some misunderstanding starts is
>>>that
>>> >>> users are expected to hand around new URLs all the time
>>>(whenever they
>>> >>> fetch new onces from their LIS). This is in theory possible but
>>>in
>>> >>> practice that might be difficult. Instead, it is more likely
>>>that one
>>> >>> would want to publish location to a server that fulfills
>>>already other
>>> >>> rules (such as a presence server alike concept; you could even
>>>call
>>> >>> Yahoo's FireEagle, Ovi Chat, Google's Latitude). Other uses
>>>have a
>>> >>> long-term contact point to go to for many reasons already.
>>> >>
>>> >> On a side note: One of the problems with by-possession URLs is
>>>that the semantics are not always clear to the user. In other
>>>words, by looking at the URL, users can't tell that they are giving
>>>away their location, for example. People include URLs in email
>>>messages, Twitter posts and web pages all the time, without fully
>>>understanding the semantics and the consequences. I suspect people
>>>would be upset if
>>> >>
>>> >> http://www.facebook.com/henning.schulzrinne
>>> >>
>>> >> just gave public access (as it does today), while
>>> >>
>>> >> http://www.facebook.com/henning.schulzrinne/293590D256FBEE1F75E816
>>> >>
>>> >> gave full access to everything, without further authentication.
>>> >>
>>> >> Henning
>>> >> _______________________________________________
>>> >> Geopriv mailing list
>>> >> Geopriv@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/geopriv
>>> >
>>> >
>>>
>>>_______________________________________________
>>>Geopriv mailing list
>>>Geopriv@ietf.org
>>>https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
