Re: [mmox] mmox Digest, Vol 2, Issue 121

[Larry Masinter <[e-mail]>]

There has been extensive (really extensive) work on location information frameworks in the IETF GEOPRIV area, including work on addressing moving targets. It might be necessary to extend their data formats and look at their actual deployment track record (so to speak) but please don't recapitulate the discussions without looking at the work.



Location in virtual worlds would use different coordinate systems, of course, but I'd think quite a bit of the extra infrastructure would be useful.



http://www.ietf.org/html.charters/geopriv-charter.html



which started in 2001.

Internet-Drafts:
Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information <http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-15.txt> (55690 bytes)
Carrying Location Objects in RADIUS and Diameter <http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-19.txt> (124024 bytes)
GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations <http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-11.txt> (56575 bytes)
Binary to Decimal Conversion for Location Configuration Information <http://www.ietf.org/internet-drafts/draft-ietf-geopriv-binary-lci-01.txt> (17124 bytes)
GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements <http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-07.txt> (39533 bytes)
HTTP Enabled Location Delivery (HELD) <http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-07.txt> (95495 bytes)
Requirements for a Location-by-Reference Mechanism <http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lbyr-requirements-02.txt> (32763 bytes)
Discovering the Local Location Information Server (LIS) <http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lis-discovery-00.txt> (44120 bytes)
Dynamic Host Configuration Protocol (DHCP) Option for a Location Uniform Resource Identifier (URI) <http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-00.txt> (26128 bytes)
Request For Comments:

Geopriv requirements (RFC 3693)<http://www.ietf.org/rfc/rfc3693.txt> (68881 bytes)
Threat Analysis of the geopriv Protocol (RFC 3694)<http://www.ietf.org/rfc/rfc3694.txt> (44364 bytes)
Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information (RFC 3825)<http://www.ietf.org/rfc/rfc3825.txt> (31715 bytes)
A Presence Architecture for the Distribution of GEOPRIV Location Objects (RFC 4079)<http://www.ietf.org/rfc/rfc4079.txt> (16718 bytes)
A Presence-based GEOPRIV Location Object Format (RFC 4119)<http://www.ietf.org/rfc/rfc4119.txt> (53522 bytes) updated by RFC 5139
Location Types Registry (RFC 4589)<http://www.ietf.org/rfc/rfc4589.txt> (24037 bytes)
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information (RFC 4676)<http://www.ietf.org/rfc/rfc4676.txt> (45208 bytes) obsoleted by RFC 4776
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information (RFC 4776)<http://www.ietf.org/rfc/rfc4776.txt> (45495 bytes) obsoletes RFC 4676
Common Policy: A Document Format for Expressing Privacy Preferences (RFC 4745)<http://www.ietf.org/rfc/rfc4745.txt> (63602 bytes)
Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO) (RFC 5139)<http://www.ietf.org/rfc/rfc5139.txt> (27470 bytes) updates RFC 4119



Larry

--

http://larry.masinter.net





-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of zedmaster
Sent: Wednesday, April 01, 2009 1:15 AM
To: [e-mail]
Subject: Re: [mmox] mmox Digest, Vol 2, Issue 121



The term "landmark" was used in some early VR systems - a landmark was just

a "named" reference to a coordinate system - could be fixed or can be

relative to another (potentially moving) object.  Just like a hyperlink

(favourite) you clicked on a landmark and you moved to that location.  Tt

was called "landmark" because these systems pre-dated web browsers, so there

wasnt any notion of "favourite" at the time.



Moving landmarks can be useful, but as you point out, you need to be careful

as to where you anchor your landmark - in truth, you really should have set

the landmark on the hotdog stall, not Coit Tower.  The hotdog stall is more

likely to be the moving target here, and if the hot dogs were that good,

you'd want to visit that stall wherever he was located.



-dirk





----- Original Message -----

>>

>>     Do we really want to use the term "landmark" in interop speak?

>>     That sounds a little too SL specific? Else, would you define what

>>     a "landmark" really means?

>>

>>

>>

>> The term "landmark" is in extremely wide use in many applications that

>> involve maps or addresses, as well as in real life

>

> I know of no serious GIS application that uses the term.

>

> But the use in the real world is very different. In the real world, the

> Coit Tower cannot move. In the virtual world, that's just a few mouse

> clicks. If I had a delicious hot dog right next to the Coit Tower, and

> the Coit Tower then moved, in real-world speak, the Coit Tower landmark

> is no longer near anything it was near when I set that as a Landmark.

>

> In general, I like the term "address" more, because it's more akin to,

> say, GPS coordinates. Also, when using Google Maps (arguably the most

> used GIS system ever), they are called Favorites.

>

> But this brings up another use case point: Is the "landmark" referencing

> an object (that can move), or an address (that can't)? And does it even

> matter? Maybe these location favorites can simply be URLs with a known

> type, and the actual words of the URL are specific to the system that

> minted them. Then the only information that is important to the

> destination system is:

> 1) Knowing that this is a location URL, and not some other kind of URL

> 2) Some user-visible description (icon, title, movie, sound, whatever)

> for presentation

> 3) The process by which one of these URLs get turned into an established

> session





_______________________________________________

mmox mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/mmox