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

[Dan Olivares <[e-mail]>]

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