Re: [ogpx] URI schema for virtual world locations?

[Joshua Bell <[e-mail]>]

I think the point is that rather than defining a URI scheme for
VWRAP-implementing virtual worlds in general - which might imply namespace
management and/or conventions and organization (i.e. you MUST have named
regions, you MUST use x/y/z coordinates, you MUST ...) we allow the service
provider to offer any URI scheme but standardize on a payload that is
compatible with the place-agent-in-region part of VWRAP.

For example, Linden Lab offers SLurl.com for Second Life addressing. The
fact that visiting http://slurl.com/Ahern/128/128/20 provides a redirect to
secondlife:///Ahern/128/128/20 (and the SL client is registered to handle
the secondlife: scheme) is an implementation detail. Implementing new
schemes is frowned upon. The preferred approach is to return a document with
the correct Internet Content Type and have an application register to handle
the content type. (i.e. what Meadhbh said!)

So we *still* have URIs, but the URIs are real honest-to-goodness HTTP(S)
URLs that return actual documents. (You can imagine a trivial redirect site
that transforms the URL structure into an LLSD document for a known
parameter set.)

On Thu, Jan 21, 2010 at 10:23 AM, Dan Olivares <[e-mail]> wrote:

> Counter Proposal:
>
> If we're going to not use URIs..    which were meant as resource
> locators....   and make our own resource locators..   lets at least
> include all of the relevant information to make our own technology
> effective.
>
> ---- Modifications to previous proposal-----
> so rather than have something like:
>
>  secondlife://example.com/Levenhall/128/128/32
>
> we would define a LLIDL map like:
>
> {
>
>  region_protocol: string,
>  region_address : string,
>  region_port: int,
>  region_name : string,
>  location : [ int, int, int ]
> }
>
> and then serialize it as:
>
> <?xml version="1.0" encoding="utf-8"?>
> <llsd>
>  <map>
>    <key>region_protocol</key>
>   <string>OGP</string>
>   <key>region_address</key>
>   <string>myregion.mycoolsimulatorfarm.com</string>
>   <key>region_port</key>
>   <int>94</int>
>    <key>region_name</key>
>   <string>Levenhall</string>
>   <key>location</key>
>   <array>
>     <integer>128</integer>
>     <integer>128</integer>
>     <integer>32</integer>
>   </array>
>  <map>
> </llsd>
>
> Possible protocols could be XMLRPC, OGP/VWrap, <insert another 3rd
> party system here>.
> Instead of the region_address, region_port, and region_protocol, it
> could potentially have the http address to the region domain.
>
> LLIDL map like:
>
> {
>
>  region_domain: string,
>  region_name : string,
>  location : [ int, int, int ]
> }
>
> and then serialize it as:
>
> <?xml version="1.0" encoding="utf-8"?>
> <llsd>
>  <map>
>    <key>region_domain</key>
>   <string>http://www.osgrid.org/VWrap/RegionDomain/put</string>
>    <key>region_name</key>
>   <string>Levenhall</string>
>   <key>location</key>
>   <array>
>     <integer>128</integer>
>     <integer>128</integer>
>     <integer>32</integer>
>   </array>
>  <map>
> </llsd>
> ...
>
> Daniel Olivares
> http://www.google.com/profiles/dcolivares
>
>
> On Thu, Jan 21, 2010 at 1:05 PM, Meadhbh Hamrick
> <[e-mail]> wrote:
> > the seondlife URI scheme is a hack used to automagically launch the SL
> > viewer based on web interaction like with the map @ slurl.com. as i
> > read it, the point of a location URI in the protocol is to provide a
> > mechanism for carrying information in a point in a virtual world.
> > instead of abusing URIs like we have in the past, maybe we should
> > define a LLIDL map for containing information about a location, then
> > use more traditional URLs to point to the location of these services.
> >
> > so rather than have something like:
> >
> >   secondlife://example.com/Levenhall/128/128/32
> >
> > we would define a LLIDL map like:
> >
> > {
> >  region_name : string,
> >  location : [ int, int, int ]
> > }
> >
> > and then serialize it as:
> >
> > <?xml version="1.0" encoding="utf-8"?>
> > <llsd>
> >  <map>
> >    <key>region_name</key>
> >    <string>Levenhall</string>
> >    <key>location</key>
> >    <array>
> >      <integer>128</integer>
> >      <integer>128</integer>
> >      <integer>32</integer>
> >    </array>
> >  <map>
> > </llsd>
> >
> > and maybe make them available at a traditional URL like:
> >
> > http://example.com/regions/3F05D047-B5AF-4332-938E-675A1EA1D784
> >
> > this would have the advantage that implementers could easily stuff
> > experimental new parameters into the serialization. if we used the
> > mime types in the client application launch message draft (
> > http://tools.ietf.org/html/draft-hamrick-ogp-launch-00 ) then we could
> > hack our web browsers to recognize the application/ogpcal+xml content
> > type and pass it to a client application of our choice.
> >
> > so.. to recap.. secondlife style URIs should be deprecated (or at
> > least not used in VWRAP.) we should use URLs that use a well known
> > protocol (like https) that describe a protocol endpoint for retrieving
> > an LLSD blob with the information we're interested in.
> >
> > -cheers
> > -meadhbh
> >
> > On Wed, Jan 20, 2010 at 1:24 PM, Hurliman, John <[e-mail]>
> wrote:
> >> I’ve seen a few places in the I-Ds and OGP wiki documents that refer to
> a
> >> URI schema for a location in a virtual world (home location, requested
> login
> >> location, etc). Has this been defined or discussed yet? I see the SLURL
> >> format of:
> >>
> >>
> >>
> >> secondlife://region%20name/x/y/z
> >>
> >>
> >>
> >> How would this change to accommodate a location in any region domain?
> >>
> >>
> >>
> >> John
> >>
> >> _______________________________________________
> >> ogpx mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ogpx
> >>
> >>
> > _______________________________________________
> > ogpx mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ogpx
> >
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>