[AWG] further discussions of secondlife:/// (was Re: [sldev] [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues)

[Argent Stonecutter]

> the assumption that secondlife://Grasmere/178/113/27 addresses a  
> location in the LL grid is actually *wrong* --- according to zero  
> the correct URI for that is http://slurl.com/secondlife/Grasmere/ 
> 178/113/27 !

Except it isn't. That addresses a location on a map that provides a  
link to a location in the Second Life grid. The SL client does not  
understand http://slurl.com, it understands secondlife://

> the secondlife: URI scheme name is actually meant to only address  
> the secondlife client and control it, but not to address location  
> in the LL grid

I don't think this distinction is really meaningful. The whole  
context of this discussion is "addressing the secondlife  
application". The "address" *has to be* something that the SL  
application can see.

And I think it it would be a really bad idea to break either existing  
links out in the wild, or to deviate from the common internet name  
syntax (appended, from RFC 1738). That is, if a URL starts with  
"scheme://" the next part should always allow a hostname.

The best solution would be to take advantage of DNS and URL formats.  
Since the new login code is being postponed, it *is* subject to  
change, if necessary, because there's no longer any legacy code that  
isn't going to be modified anyway (when it's revisited) that depends  
on it.

In a previous message I suggested:

>> The perfect solution would be for LL to publish a TXT record for  
>> each of Ahern.grid.secondlife.com, da-boom.grid.secondlife.com,  
>> and so on. That TXT record would contain the actual host and (as  
>> an aside) any other data potentially needed to login to their  
>> grid. The client would simply append ".grid.secondlife.com" to the  
>> host portion if it's not a FQDN. For other grids, they would have  
>> their own TXT records published for their own domains, so for them  
>> you'd log in to secondlife://theirsim.theirdomain.example.com/...


There are other approaches that would avoid invalidating existing  
URLs. For example, overloading the URL 'username' @ 'host' format.

secondlife://Grasmere@grid.secondlife.com/...

But these all involve a deviation to the common internet name syntax.  
Using TXT records wouldn't do that, it's a standard way of doing  
things, AND it's extensible... a TXT record can contain an arbitrary  
number of name-value pairs up to the limit of packet size, though  
typically it's intended to be under 100 bytes.

So let me elaborate on this...

First, the host part of the CINS URL would uniquely encode the  
location and the grid. The usual TXT record meta-syntax would make it  
easy to parse out the grid name without dealing with the TXT record  
lookup if you REALLY needed to:

Grasmere._grid.secondlife.com

The "local_part . _type{1+} . path" makes "._" a unique separator for  
the local_part.

Secondly, the TXT record returned could contain arbitrary grid-local  
information in name-value pairs. It should, at the very least,  
include a "login_server=" string.

Third, this would enable smart load balancing. Eg:  
"login_server=login3.secondlife.zurich.ibm.com".

If the host part is not fully qualified, then it would have  
"._grid.secondlife.com" appended to it, which would allow the legacy  
scheme to work. This string could be hardcoded in the client or be in  
the user's XML file.

If the path part of the URI doesn't start with "app" then the X, Y,  
and Z coordinates follow.

So the full BNF would be:

secondlifeurl = "secondlife://" [ gridspec ] ["/" locpath [ "?"  
parameters ] ]

; Note: if "hostname" is left out, use "_grid.secondlife.com"
gridspec = hostname | regname [ "." hostname ]

; Note: replace "space" with "-" before performing DNS lookup.
regname = alpha *[ alpha | digit | space ]

locpath = slpath | location [ "/" slpath ]

slpath = toplabel "/" *[ hsegment ]

location = digits "/" digits "/" digits

parameters = parameter | parameters "&" parameter

parameter = toplabel "=" unreserved

With the remaining definitions taken from RFC1738 section 5.

I believe this BNF is unambiguous.

------
3.1. Common Internet Scheme Syntax

While the syntax for the rest of the URL may vary depending on the  
particular scheme selected, URL schemes that involve the direct use  
of an IP-based protocol to a specified host on the Internet use a  
common syntax for the scheme-specific data:

         //<user>:<password>@<host>:<port>/<url-path>

Some or all of the parts "<user>:<password>@", ":<password>",  
":<port>", and "/<url-path>" may be excluded. The scheme specific  
data start with a double slash "//" to indicate that it complies with  
the common Internet scheme syntax. The different components obey the  
following rules:

user
     An optional user name. Some schemes (e.g., ftp) allow the  
specification of a user name.

password
     An optional password. If present, it follows the user name  
separated from it by a colon.

The user name (and password), if present, are followed by a  
commercial at-sign "@". Within the user and password field, any ":",  
"@", or "/" must be encoded.

Note that an empty user name or password is different than no user  
name or password; there is no way to specify a password without  
specifying a user name. E.g., <URL:ftp://@host.com/> has an empty  
user name and no password, <URL:ftp://host.com/> has no user name,  
while <URL:ftp://foo:@host.com/> has a user name of "foo" and an  
empty password.

host
     The fully qualified domain name of a network host, or its IP  
address as a set of four decimal digit groups separated by ".". Fully  
qualified domain names take the form as described in Section 3.5 of  
RFC 1034 [13] and Section 2.1 of RFC 1123 [5]: a sequence of domain  
labels separated by ".", each domain label starting and ending with  
an alphanumerical character and possibly also containing "-"  
characters. The rightmost domain label will never start with a digit,  
though, which syntactically distinguishes all domain names from the  
IP addresses.

port
     The port number to connect to. Most schemes designate protocols  
that have a default port number. Another port number may optionally  
be supplied, in decimal, separated from the host by a colon. If the  
port is omitted, the colon is as well.

url-path
     The rest of the locator consists of data specific to the scheme,  
and is known as the "url-path". It supplies the details of how the  
specified resource can be accessed. Note that the "/" between the  
host (or port) and the url-path is NOT part of the url-path.

The url-path syntax depends on the scheme being used, as does the  
manner in which it is interpreted.