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

[Dan Olivares <[e-mail]>]

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