Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506D23A8CB8 for ; Sun, 7 Mar 2010 07:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz3fm80-GXHc for ; Sun, 7 Mar 2010 07:41:55 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id A650F3A8708 for ; Sun, 7 Mar 2010 07:41:54 -0800 (PST) Received: by wyb40 with SMTP id 40so2860402wyb.31 for ; Sun, 07 Mar 2010 07:41:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=46lHSU1VDnWFczBCyYYHosWgzXNP4gJvgdlgsu5crK8=; b=Q+xX1FsWeoneH2yACvc//yx5m87ZiGZV4sfRTYWfa61FdgIOeu7RxVp6PrB6Ld1OKI QzBb4vApoHZ20Xv7E3VKKNuSy6oeKDyGg9Dyzrhd3kdoGUBIrxE8tFhRXL1hNtOTQhsL osAt+BBYdAfZdP2RFynzk9ki/iMo+b5ry6wY8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qVH0YkXAmYfdmWKfyXWCSGtpVGBII1CXiZjpyIwaA0cQZ40bXUbexl1bpbzvnHqsfq AxSxjjkbnHT1MSD/8+qjNCLVwhEuEWtK1uELzLS4Bz5X60t4qCaGLgxR9hQ+TV6yTZiY EH75bPiRQ5jzsXDJocZ+PvaL4mQEP3ReSYICo= MIME-Version: 1.0 Received: by 10.216.170.213 with SMTP id p63mr1217949wel.33.1267976513189; Sun, 07 Mar 2010 07:41:53 -0800 (PST) In-Reply-To: <20100307143735.GA20862@alinoe.com> References: <20100306142607.GB24621@alinoe.com> <20100307003856.GA26690@alinoe.com> <20100307143735.GA20862@alinoe.com> Date: Sun, 7 Mar 2010 15:41:53 +0000 Message-ID: From: Morgaine To: Carlo Wood Content-Type: multipart/alternative; boundary=0016363ba666a6f9af048137c923 Cc: ogpx@ietf.org Subject: Re: [ogpx] Feedback to draft-hamrick-vwrap-authentication-00.txt X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 15:41:57 -0000 --0016363ba666a6f9af048137c923 Content-Type: text/plain; charset=ISO-8859-1 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 ". 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 "" or "" 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 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 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 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 > > > > 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 > --0016363ba666a6f9af048137c923 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I did say that a walled garden would be one potential deployment pattern of= VWRAP ("a subset of its capabilities"), so yes, current S= econd 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 clea= r main thrust and potential of VWRAP, which was very effectively described = in our article as "VWRAP for = Virtual Worlds Interoperability".

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

Regarding agent naming, su= re, the current choice in the SL service is not generic so hardwiring it in= to VWRAP would not be sensible, nor would it serve the general interest.
However, don't assume that LL actually wants to retai= n current restrictions on agent naming long term --- their vision undoubted= ly extends beyond what they have implemented today, and I expect that draft= -00 was just a starting point.=A0 It's to everyone's ultimate bene= fit 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 tha= t is a mandatory complement to the agent name, since agent names will be un= ique only within a given identity registrar service.

Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Sun, Mar 7, 2010 at 2:37 PM, Carlo Wood <= ;carlo@alinoe.com> wrote:=
You reverse thing= s. 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 <carlo@alinoe.com> wrote:
>
>
> =A0 =A0 What also worries me in this is that apparently the current > =A0 =A0 Second Life protocol is considered to be canonical VWRAP, and<= br> > =A0 =A0 it is apparently not possible to define a VWRAP that doesn'= ;t
> =A0 =A0 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 futur= e, so
> that they will have a good chance of evolving SL to become VWRAP-compa= tible one
> day. =A0At least that's what my interest would be if I were in the= ir shoes.
>
> It's worth pointing out that nobody gets a free ride here though. = =A0Everyone
> 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 de= ploy
> would of course be completely inappropriate, and once we agreed on our= scope,
> such a thing became impossible anyway. =A0After 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 buildi= ng a
> walled garden will be one possible deployment, a subset of its capabil= ities.
>
> The article that we wrote for IEEE Internet Computing pretty much says= it all
> in its title alone: =A0"VWRAP for Virtual Worlds Interoperability= ". =A0The current
> SL protocol doesn't do that at all, so considering it "canoni= cal VWRAP" isn't
> even an approximation.
>
> In summary, I think your worry might be slightly too strong.
>
>
> Morgaine.
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> On Sun, Mar 7, 2010 at 12:38 AM, Carlo Wood <carlo@alinoe.com> wrote:
>
> =A0 =A0 On Sat, Mar 06, 2010 at 08:39:32PM +0000, Morgaine wrote:
> =A0 =A0 > The {first_name} + {last_name} concept has no place in VW= RAP as a
> =A0 =A0 requirement
> =A0 =A0 > anyway. =A0That's a particular property of Second Lif= e.
>
> =A0 =A0 +1
>
> =A0 =A0 Meadhbh wrote me back in private (something I don't unders= tand, why
> =A0 =A0 not use this list?) that the reason for using first + last nam= e
> =A0 =A0 is to accommodate existing implementations like Second Life an= d
> =A0 =A0 Opensim.
>
> =A0 =A0 I think that is not a valid agrument. We're designing a st= andard
> =A0 =A0 here, and there is no place for legacy in a new standard. I al= ready
> =A0 =A0 pointed out in my first post that it is extremely simple to sw= itch
> =A0 =A0 to a single Agent Identifier string anyway (just catenate firs= t and
> =A0 =A0 last with a space in between).
>
> =A0 =A0 What also worries me in this is that apparently the current > =A0 =A0 Second Life protocol is considered to be canonical VWRAP, and<= br> > =A0 =A0 it is apparently not possible to define a VWRAP that doesn'= ;t
> =A0 =A0 match the current existing protocol used by Linden Lab.
>
> =A0 =A0 If Linden Lab thinks that it's hard to switch such things<= br> > =A0 =A0 (from First + Last to a single AgentIdentifier), then I'd<= br> > =A0 =A0 like to stress again the importance of protocol negotiation!!!=
>
> =A0 =A0 --
> =A0 =A0 Carlo Wood <carlo@alino= e.com>
>
> =A0 =A0 PS With protocol negotiation being a standard part of every > =A0 =A0 =A0 VWRAP connection, it would be the simplest of tasks
> =A0 =A0 =A0 to switch from First+Last to VWRAP, even allowing
> =A0 =A0 =A0 a few years for viewers to switch (before dropping
> =A0 =A0 =A0 support for the legacy login).
>
>
>

--
Carlo Wood <carlo@alinoe.com>

--0016363ba666a6f9af048137c923--