Re: [ogpx] Next Steps for OGPX WG Charter

Avshalom Houri <AVSHALOM@il.ibm.com> Thu, 30 July 2009 10:09 UTC

Return-Path: <AVSHALOM@il.ibm.com>
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 EBDFB3A69E1; Thu, 30 Jul 2009 03:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.133
X-Spam-Level:
X-Spam-Status: No, score=-6.133 tagged_above=-999 required=5 tests=[AWL=0.465, 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 4GhHCtFZ8o4n; Thu, 30 Jul 2009 03:09:36 -0700 (PDT)
Received: from mtagate4.de.ibm.com (mtagate4.de.ibm.com [195.212.29.153]) by core3.amsl.com (Postfix) with ESMTP id 442AD3A691E; Thu, 30 Jul 2009 03:09:20 -0700 (PDT)
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.14.3/8.13.8) with ESMTP id n6UA9451083660; Thu, 30 Jul 2009 10:09:04 GMT
Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n6UA94aK2519214; Thu, 30 Jul 2009 12:09:04 +0200
Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n6UA93AM032230; Thu, 30 Jul 2009 12:09:03 +0200
Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n6UA936P032223; Thu, 30 Jul 2009 12:09:03 +0200
In-Reply-To: <F0487BF6-FBBB-481A-A25E-DE777AC274E2@lindenlab.com>
References: <F0487BF6-FBBB-481A-A25E-DE777AC274E2@lindenlab.com>
To: Joshua Bell <josh@lindenlab.com>
MIME-Version: 1.0
X-KeepSent: 5205B798:BB06D18E-C2257603:003725F1; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
From: Avshalom Houri <AVSHALOM@il.ibm.com>
Message-ID: <OF5205B798.BB06D18E-ONC2257603.003725F1-C2257603.0037C327@il.ibm.com>
Date: Thu, 30 Jul 2009 13:09:03 +0300
X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 30/07/2009 13:09:03, Serialize complete at 30/07/2009 13:09:03
Content-Type: multipart/alternative; boundary="=_alternative 0037736DC2257603_="
Cc: ogpx-bounces@ietf.org, ogpx@ietf.org
Subject: Re: [ogpx] Next Steps for OGPX WG Charter
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2009 10:09:38 -0000

What about VIP - Virtual-worlds Integration Protocol for a name?

Thanks
--Avshalom




From:
Joshua Bell <josh@lindenlab.com>
To:
ogpx@ietf.org
Date:
30/07/2009 10:40 AM
Subject:
[ogpx] Next Steps for OGPX WG Charter
Sent by:
ogpx-bounces@ietf.org



A draft WG charter was discussed at the BOF, the text of which can be 
found here:

http://www.ietf.org/proceedings/75/slides/ogpx-2.txt

Our highest priority goal is to refine the charter. The BOF provided 
us with an excellent set of questions and issues to address. These 
have not yet been incorporated, and are listed below along with open 
questions.

* We are looking for feedback in the form of specific changes to make 
to the proposed charter and rationale for the language used.

* We have an explicit goal of submitting the charter within 2 weeks to 
the ISEG and IAB for approval.


Necessary charter changes:


1. Include a succinct but realistic summary of what the problem space 
and protocol are. At the BOF, Chris Newman made the comment "The 
impression I've got is this is a 3-D multi-vendor Facebook. I think 
that's really cool." (thanks, Chris!). This really helped BOF 
participants unfamiliar with VWs understand what the heck we were 
talking about.

Can mailing list participants come up with something short, accurate, 
educational, and catchy?


2. Larry Masinter and Dave Crocker argued persuasively for a 
functional description of the protocol's uses. Rather than describe 
the protocol only in abstract terms, provide a non-exhaustive list of 
protocol effects. For example: "The protocol produced by this working 
group should provide a mechanism for authenticating a client to a 
server, cause a user's avatar to be placed in the virtual world, move 
the user's avatar, receive a list of objects in the user's avatar, etc."


3. The text of the charter should have a clear list of working group 
deliverables.

The "what is needed" slide from the OGPX Draft Charter Issues 
presentation ( http://www.ietf.org/proceedings/75/slides/ogpx-2.pdf) 
was mentioned as a possible source for this list for both (2) and (3), 
but needs massaging:

(a) a security model describing trust relationships between hosts,
(b) guidelines for the use of existing authentication & 
confidentiality mechanisms,
(c) mechanisms for:
  (i) establishing the user's presence in the virtual world
  (ii) moving a user's presence from one authoritative host to another,
  (iii) for identifying agents, and requesting information about them.
(d) format descriptions for objects and avatars in a virtual world,

Are there any deliverables missing? Have we covered the functional 
needs. When proposing additional deliverables, please describe them in 
sufficient detail to enable discussion.


4. A small number of key terms should be introduced and briefly 
described, especially any used in the functional description (#2, 
above). Suggestions for these terms include agent, avatar, user, 
region, asset, domain, service, resource, agent domain and region 
domain.

Ultimately the list of terms to include will be derived from other 
parts of the charter to make it independent of other texts, but are 
there other terms that must be defined?


5. Should the working group investigate operational aspects of virtual 
worlds? If so, what language should be added to the charter?


6. "OGP" is not an appropriate name for the WG or protocol - "grid" is 
ambiguous. (Our usage plays off the double meaning of a square 
subdivision of regions, and a computing cluster, neither of which are 
expected to be explicit in the protocol.) Suggestions so far include:

* "Region Access Protocol" (RAP) - captures region-based VW specificity
* "Agent/Region Interaction Protocol" (ARIP) - highlights the active 
entities

Are there any other suggestions, preferences, or vetos? Does the 
proposed protocol name need to be reflected in a revised Working Group 
name? Contrariwise, does the WG name need to be reflected in protocols 
it develops? (Strictly: "no" and "no", but in practice...?) Serious 
name suggestions which promote clever acronyms for future IETF 
sessions are encouraged.


7. Explicitly list extant drafts which will be the starting point for 
the WG effort:

* http://tools.ietf.org/html/draft-hamrick-ogp-intro
* http://tools.ietf.org/html/draft-hamrick-llsd-00
* http://tools.ietf.org/html/draft-hamrick-ogp-auth
* http://tools.ietf.org/html/draft-hamrick-ogp-launch
* http://tools.ietf.org/html/draft-lentczner-ogp-base
* http://tools.ietf.org/html/draft-levine-ogp-clientcap
* http://tools.ietf.org/html/draft-levine-ogp-layering

Is this list complete and accurate?


8. The protocols are intended to provide a clear seperation of 
concerns between mechanisms  used to access resources and policies 
controlling use of those mechanisms. Many deployment choices will be 
defined by policy, not protocol. This needs to be clear in the charter.


9. Ensure that while the charter scopes down the Virtual World problem 
space, it does it in an inclusive way rather than focusing on what is 
out of scope and thus indecipherable to non-subject matter experts. It 
is expected that output of the WG may be useful in scenarios beyond 
those specifically under consideration, much as RFC 2068 is not simply 
used for hypertext.


10. Remove references to "wire" in "wire protocol"; this is implicit 
in the scope of work for IETF. The phrase "application-layer 
protocol" (as distinct from a novel transport-layer protocol) is 
accurate and sufficient.


11. Add text specifying: The WG will define interfaces for a set of 
HTTP-based services ("web services") but not provide language specific 
bindings ("API") onto those services.


12. Clarify the charter that we're explicitly targetting HTTP as the 
default transport.

A concern was raised that reusing HTTP will lead to unnecessary and 
tight coupling with that protocol's capabilities and semantics; a 
suggestion was made that if we wish to state that the protocols will 
be transport-neutral, the WG will investigate at least one other 
transport. Should we just target HTTP, or make the effort?

(This may affect the terminology used for #11.)


_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx