Re: [ogpx] Feedback to draft-hamrick-vwrap-authentication-00.txt

[Carlo Wood <[e-mail]>]

You reverse things. Second Life CAN be a subset of VWRAP, and
VWRAP still being able to do so much more. So, whatever we
agreed upon that VWRAP will support, that basically doesn't
exclude the current SL protocol to be a subset of it.
It WILL cripple VWRAP however-- in the best case it would
be a new standard full with exceptions and special cases
to support some "other" legacy protocol.

Nevertheless, I don't have a problem with even THAT.

For example, instead of sending:

first: string
last: string

we could define VWRAP to accept either, first/last OR

agentID: string

and then define everything in terms of that string and
define it to be "first last" in the case the former is used.
That way SL would be VWRAP compatible as it is.

However, that is not the way to go: it polutes the protocol.
Now, using ONLY first/last and not accepting agentID just
because there is an existing legacy protocol that needs it
isn't acceptable either. So... what is the proper solution?

Imho, the proper solution is to define VWRAP to demand

agentID: string

and add Protocol Negotiation to allow Linden Lab to add
a (temporary, if they so wish) extension for first/last.
The result will be a smooth transition for them, a well
defined VWRAP protocol and no legacy protocol ten years
from now.

Also, I'm convinced that this Protocol Negotiation will
be handy (needed) many, many time more often. Not foreseeable
now even. It's a must, so why not add it and get rid of
problems like this?

On Sun, Mar 07, 2010 at 05:33:28AM +0000, Morgaine wrote:
> On Sun, Mar 7, 2010 at 12:38 AM, Carlo Wood <[e-mail]> wrote:
> 
> 
>     What also worries me in this is that apparently the current
>     Second Life protocol is considered to be canonical VWRAP, and
>     it is apparently not possible to define a VWRAP that doesn't
>     match the current existing protocol used by Linden Lab.
> 
> 
> 
> Haha, don't even jest about it. :-)
> 
> The Linden goal I suspect is to ensure that VWRAP includes that subset of
> protocol functionality that they intend to use some years in the future, so
> that they will have a good chance of evolving SL to become VWRAP-compatible one
> day.  At least that's what my interest would be if I were in their shoes.
> 
> It's worth pointing out that nobody gets a free ride here though.  Everyone
> will have a large implementation job ahead of them to implement VWRAP even
> minimally, and even more so if they embrace multiple external services and
> multi-world interop.
> 
> Limiting VWRAP to only the subset that a particular party wishes to deploy
> would of course be completely inappropriate, and once we agreed on our scope,
> such a thing became impossible anyway.  After all, VWRAP is to be a virtual
> worlds interop protocol (as we finally ascertained after much heated
> discussion), not a walled garden building protocol, even though building a
> walled garden will be one possible deployment, a subset of its capabilities.
> 
> The article that we wrote for IEEE Internet Computing pretty much says it all
> in its title alone:  "VWRAP for Virtual Worlds Interoperability".  The current
> SL protocol doesn't do that at all, so considering it "canonical VWRAP" isn't
> even an approximation.
> 
> In summary, I think your worry might be slightly too strong.
> 
> 
> Morgaine.
> 
> 
> 
> 
> 
> ===================================
> 
> On Sun, Mar 7, 2010 at 12:38 AM, Carlo Wood <[e-mail]> wrote:
> 
>     On Sat, Mar 06, 2010 at 08:39:32PM +0000, Morgaine wrote:
>     > The {first_name} + {last_name} concept has no place in VWRAP as a
>     requirement
>     > anyway.  That's a particular property of Second Life.
> 
>     +1
> 
>     Meadhbh wrote me back in private (something I don't understand, why
>     not use this list?) that the reason for using first + last name
>     is to accommodate existing implementations like Second Life and
>     Opensim.
> 
>     I think that is not a valid agrument. We're designing a standard
>     here, and there is no place for legacy in a new standard. I already
>     pointed out in my first post that it is extremely simple to switch
>     to a single Agent Identifier string anyway (just catenate first and
>     last with a space in between).
> 
>     What also worries me in this is that apparently the current
>     Second Life protocol is considered to be canonical VWRAP, and
>     it is apparently not possible to define a VWRAP that doesn't
>     match the current existing protocol used by Linden Lab.
> 
>     If Linden Lab thinks that it's hard to switch such things
>     (from First + Last to a single AgentIdentifier), then I'd
>     like to stress again the importance of protocol negotiation!!!
> 
>     --
>     Carlo Wood <[e-mail]>
> 
>     PS With protocol negotiation being a standard part of every
>       VWRAP connection, it would be the simplest of tasks
>       to switch from First+Last to VWRAP, even allowing
>       a few years for viewers to switch (before dropping
>       support for the legacy login).
> 
> 
> 

-- 
Carlo Wood <[e-mail]>