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

[Jon Watte <[e-mail]>]

Some of this is pretty good. Some of it isn't quite, though, because 
while there is only one Earth, there are zillions of different, 
sometimes-connected virtual worlds. Even the people doing real-world 
terrain may want to do different version of the real-world terrain. If 
the LAPD is running an anti-terrorist exercise, and Paramount Pictures 
are planning a low-flying helicopter chase, they might be in the same 
physical coordinate space, but want to actually be in different logical 
coordinate spaces.

That being said, I agree: let's learn from the past and use what's 
already in the IETF.

Sincerely,

jw


Larry Masinter wrote:
>
> 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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox
>