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

[Joshua Bell <[e-mail]>]

Assumptions make me sad - I'd want to be able to explicitly specify the
region service endpoint in the data coming back.

This is necessary in the case where you click on a link in a Web browser
which returns a content-typed blob; the blob could be handed off to a VWRAP
viewer which has no idea where the blob came from.

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

> Scrach that last agent domain in my last e-mail and replace it with
> region domain in the following statement,
> "and the content type handler assumes the agent domain is serving the
> file."
>
> It should have been
> "and the content type handler assumes the region domain is serving the
> file."
>
> Daniel Olivares
>
> On Thu, Jan 21, 2010 at 2:05 PM, Dan Olivares <[e-mail]>
> wrote:
> > If you're saying that implementing new schemes 'vwrap://' is frowned
> > upon by the IETF, then I can see where you are going with this.  You
> > simply think we'll have a better chance of getting through the
> > standards process if we use a file with an appropriate content type.
> >
> > The issue for me, really, is the assumption that mapping service
> > slurl.com is assumed to be the region domain based on the LLIDL.
> > {
> >  region_name : string,
> >  location : [ int, int, int ]
> > }
> >
> > There isn't enough information for a client application to determine
> > otherwise in that LLIDL.    Even for Linden Labs' purposes, it would
> > be reasonable to have a page at sLURL send a LLIDL structure like:
> > {
> >  region_domain : string,
> >  region_name : string,
> >  location : [ int, int, int ]
> > }
> >
> > that would be serialized like;
> >
> > <?xml version="1.0" encoding="utf-8"?>
> > <llsd>
> >  <map>
> >
> >  <key>region_domain</key>
> >  <string>http://agni.secondlife.com/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>
> >
> > otherwise..     a good faith client would have to assume slurl.com as
> > the region domain because there are no other references to region
> > domains..  It couldn't assume agni.   Additionally, that wouldn't work
> > for 'hyperlinking' in world because the file with the proper content
> > type, metaphysically, couldn't be on the agent domain in every
> > circumstance unless you're thinking of adding another layer of
> > complication and single point of failure where by each region domain
> > implements it's own SLURL mapping service and a method of dealing with
> > hyperlinks to it's regions by way of URL parameters or some other
> > variable method and outputs the shortened LLIDL version and the
> > content type handler assumes the agent domain is serving the file.
> >
> > Daniel Olivares
> >
> >
> >
> > On Thu, Jan 21, 2010 at 1:45 PM, Joshua Bell <[e-mail]> wrote:
> >> 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
> >>
> >>
> >> _______________________________________________
> >> ogpx mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ogpx
> >>
> >>
> >
> >
> >
> > --
> > http://www.google.com/profiles/dcolivares
> >
>
>
>
> --
> http://www.google.com/profiles/dcolivares
>