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 368BE3A906F for ; Sat, 6 Mar 2010 21:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-0.022, 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 vituS4wvJf5E for ; Sat, 6 Mar 2010 21:33:28 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 20C873A8EAD for ; Sat, 6 Mar 2010 21:33:27 -0800 (PST) Received: by wwf26 with SMTP id 26so1329443wwf.31 for ; Sat, 06 Mar 2010 21:33:28 -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=jryLtC8gi7hrsH8L5N02cHBXzQ5gFGKndcfUTgXM4fs=; b=Q2Nl1QGQJWbSK2mHzmoZ2Ha7Rm6DmAkKKV853HIaDERaDdDg35lZpggJQFcnKp8I71 +SvMrVPxOeH/OPoNqxFbybtOSC83xfbqPG9TiccydITAGUgnNiG7wLCybk3KBXOAG5pt 2QYIU577MDwxs9VwM9/MxgkH7suyJwXbbgeEY= 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=MOQdIJDA/MdZobxY0HtRRmGxseaUaXDwqQZXCf31L8dPWJd9rlwkDu9kG4w1Dn27Ux aAhbOULd9ZtvmbbjFmk3ATNVgCIgs7dcx7ZJF2Rj6nuF7FIXoqaQRo4uP1PLpD8RJlD+ ce2HQdB/bIOqsV9+3LZx3zEJGh/y5jeOmGq4o= MIME-Version: 1.0 Received: by 10.216.85.9 with SMTP id t9mr1615976wee.79.1267940008046; Sat, 06 Mar 2010 21:33:28 -0800 (PST) In-Reply-To: <20100307003856.GA26690@alinoe.com> References: <20100306142607.GB24621@alinoe.com> <20100307003856.GA26690@alinoe.com> Date: Sun, 7 Mar 2010 05:33:28 +0000 Message-ID: From: Morgaine To: Carlo Wood Content-Type: multipart/alternative; boundary=0016e6d778afc6b0d404812f4965 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 05:33:30 -0000 --0016e6d778afc6b0d404812f4965 Content-Type: text/plain; charset=ISO-8859-1 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). > > --0016e6d778afc6b0d404812f4965 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Mar 7, 2010 at 12:38 AM, Carlo Wood <carlo@alinoe.com> 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 Lin= den 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 th= ey will have a good chance of evolving SL to become VWRAP-compatible one da= y.=A0 At least that's what my interest would be if I were in their shoe= s.

It's worth pointing out that nobody gets a free ride here though.= =A0 Everyone will have a large implementation job ahead of them to implemen= t 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.=A0 After all, V= WRAP is to be a virtual worlds interop protocol (as we finall= y ascertained after much heated discussion), not a walled garden building p= rotocol, even though building a walled garden will be one possible deployme= nt, a subset of its capabilities.

The article that we wrote for IEEE Internet Computing pretty much says = it all in its title alone:=A0 "VWRAP for Virtual Worlds Interoperab= ility".=A0 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.





=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

<= div class=3D"gmail_quote">On Sun, Mar 7, 2010 at 12:38 AM, Carlo Wood <carlo@alinoe.com&g= t; 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 requ= irement
> anyway. =A0That'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 <carlo@= alinoe.com>

PS With protocol negotiation being a standard part of every
=A0 VWRAP connection, it would be the simplest of tasks
=A0 to switch from First+Last to VWRAP, even allowing
=A0 a few years for viewers to switch (before dropping
=A0 support for the legacy login).


--0016e6d778afc6b0d404812f4965--