Re: [vwrap] Why are we standardizing the login handshake? (was RE: one question)

"Hurliman, John" <john.hurliman@intel.com> Fri, 24 September 2010 22:59 UTC

Return-Path: <john.hurliman@intel.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D713A6AF8 for <vwrap@core3.amsl.com>; Fri, 24 Sep 2010 15:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.17
X-Spam-Level:
X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 UHki8uw4YCCl for <vwrap@core3.amsl.com>; Fri, 24 Sep 2010 15:58:54 -0700 (PDT)
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id C772D3A69A8 for <vwrap@ietf.org>; Fri, 24 Sep 2010 15:58:54 -0700 (PDT)
Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 24 Sep 2010 15:59:27 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="4.57,232,1283756400"; d="scan'208,217"; a="610184333"
Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by fmsmga002.fm.intel.com with ESMTP; 24 Sep 2010 15:59:27 -0700
Received: from rrsmsx605.amr.corp.intel.com (10.31.1.129) by rrsmsx602.amr.corp.intel.com (10.31.0.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 24 Sep 2010 16:59:27 -0600
Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by RRSMSX605.amr.corp.intel.com ([10.31.1.129]) with mapi; Fri, 24 Sep 2010 16:59:27 -0600
From: "Hurliman, John" <john.hurliman@intel.com>
To: "vwrap@ietf.org" <vwrap@ietf.org>
Date: Fri, 24 Sep 2010 16:59:27 -0600
Thread-Topic: [vwrap] Why are we standardizing the login handshake? (was RE: one question)
Thread-Index: ActcO5BKVhmRFERwQ9aRVgWrg1zyvQAABLKw
Message-ID: <62BFE5680C037E4DA0B0A08946C0933D012AD7E0F6@rrsmsx506.amr.corp.intel.com>
References: <62BFE5680C037E4DA0B0A08946C0933D012AD7E06A@rrsmsx506.amr.corp.intel.com> <4C9D20F5.2020507@ics.uci.edu> <AANLkTimyffd6xSCKRTySypEDcM=MSsuJZeZVCp3oY3pQ@mail.gmail.com> <4C9D2C3E.2070609@ics.uci.edu>
In-Reply-To: <4C9D2C3E.2070609@ics.uci.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_62BFE5680C037E4DA0B0A08946C0933D012AD7E0F6rrsmsx506amrc_"
MIME-Version: 1.0
Subject: Re: [vwrap] Why are we standardizing the login handshake? (was RE: one question)
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Sep 2010 22:59:01 -0000

I think you're right. Most of the group has been operating under the assumption that intro and foundation docs need to be seriously cleaned up, possibly merged, and brought up to speed with the general consensus that we are sharing on the mailing list right now. But there's an almost even division between people who want the docs rewritten from the ground up and people who want to iterate on the existing docs. I'm in the former camp, but I personally am not going to rewrite the intro and foundation docs so I can't make too many demands.


From: vwrap-bounces@ietf.org [mailto:vwrap-bounces@ietf.org] On Behalf Of Crista Lopes
Sent: Friday, September 24, 2010 3:55 PM
To: Morgaine
Cc: vwrap@ietf.org
Subject: Re: [vwrap] Why are we standardizing the login handshake? (was RE: one question)

I have a feeling I am the only one taking VWRAP for what it says it is in the documents -- intro, authentication, etc.
One of my main assessments was: this is full of irrelevant implementation details that should not be part of any protocol for interoperability.


On 9/24/2010 3:27 PM, Morgaine wrote:
The Intro document is beyond repair, and should be quoted only with extreme caution.

If VWRAP "defines formats for describing objects and avatar shapes" then it will be obsolete on the day it is released, and utterly unable to stay in touch with worlds evolving along a thousand fronts.

That's why we have SERVICES, so that such issues as objects and avatar shapes are entirely external to the core protocol, evolving independently, and negotiated on entry to each new world, or even potentially to each new region.  That's why regions have the capability to handle multiple assets services from multiple worlds, so that no central policy applies.  Defining fixed formats centrally would be an exercise in futility on an Internet scale.

The Intro document represents OGP legacy, and should not be treated as more than that.  You have to remember that OGP was about expanding a centrally managed virtual world.  It bears very little relationship to what we're trying to achieve.  (And for that, I can only apologize --- OGP should have been thrown out much earlier.)


Morgaine.





===================================
On Fri, Sep 24, 2010 at 11:06 PM, Crista Lopes <lopes@ics.uci.edu<mailto:lopes@ics.uci.edu>> wrote:
John,

You may also want to read the intro draft.
http://tools.ietf.org/html/draft-ietf-vwrap-intro-00

This is in 4.4:

"VWRAP defines formats  for describing objects and avatar shapes, but more importantly it
  describes the mechanism by which those digital asset descriptions are
  transferred between client applications, agent domains and region
  domains."
...
"Accessing and manipulating digital assets is  performed via capabilities which expose the state of the asset to an authorized client. "

In other words, assets are fetched by the client. So if my world pushes them to the client, it's not VWRAP-compliant.



_______________________________________________
vwrap mailing list
vwrap@ietf.org<mailto:vwrap@ietf.org>
https://www.ietf.org/mailman/listinfo/vwrap