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

[Morgaine <[e-mail]>]

I did say that a walled garden would be one potential deployment pattern of
VWRAP ("*a subset of its capabilities*"), so yes, current Second Life
protocols can indeed be a subset of VWRAP.

But that would be a highly degenerate boundary case as it would miss out on
the very clear main thrust and potential of VWRAP, which was very
effectively described in our article as "VWRAP for Virtual Worlds
Interoperability<http://internetmessagingtechnology.org/pubs/VWRAP-for-Virtual-Worlds-Interoperability-mic2010010073.pdf>
".

And it would also miss out on the massive scalability numbers upon which the
whole OGP effort was founded, so I don't think it's a realistic projection
of anyone's intentions.

Regarding agent naming, sure, the current choice in the SL service is not
generic so hardwiring it into VWRAP would not be sensible, nor would it
serve the general interest.

However, don't assume that LL actually *wants* to retain current
restrictions on agent naming long term --- their vision undoubtedly extends
beyond what they have implemented today, and I expect that draft -00 was
just a starting point.  It's to everyone's ultimate benefit to make such
data fields generic.

What seems to have got lost in the discussion here though is the "<world>"
or "<identity_provider>" data field that is a mandatory complement to the
agent name, since agent names will be unique only within a given identity
registrar service.

Morgaine.




===============================

On Sun, Mar 7, 2010 at 2:37 PM, Carlo Wood <[e-mail]> wrote:

> 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]>
>