Re: [ogpx] Seed capability behavior

David W Levine <dwl@us.ibm.com> Wed, 20 January 2010 22:37 UTC

Return-Path: <dwl@us.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 188413A6948; Wed, 20 Jan 2010 14:37:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.513
X-Spam-Level:
X-Spam-Status: No, score=-5.513 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
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 XgE73xYD+D4r; Wed, 20 Jan 2010 14:37:41 -0800 (PST)
Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id ED3993A6904; Wed, 20 Jan 2010 14:37:37 -0800 (PST)
Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e8.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0KIV8HC030937; Wed, 20 Jan 2010 13:31:08 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0KMbRF3126388; Wed, 20 Jan 2010 17:37:27 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0KMbQ6c024029; Wed, 20 Jan 2010 17:37:26 -0500
Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0KMbQL7024026; Wed, 20 Jan 2010 17:37:26 -0500
In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933DC4B2DCF9@rrsmsx506.amr.corp.intel.com>
References: <62BFE5680C037E4DA0B0A08946C0933DC4B2DCF9@rrsmsx506.amr.corp.intel.com>
To: "Hurliman, John" <john.hurliman@intel.com>
MIME-Version: 1.0
X-KeepSent: EDB4A382:947559FB-852576B1:007B59C0; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
Message-ID: <OFEDB4A382.947559FB-ON852576B1.007B59C0-852576B1.007C448C@us.ibm.com>
From: David W Levine <dwl@us.ibm.com>
Date: Wed, 20 Jan 2010 17:37:21 -0500
X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/20/2010 17:37:26, Serialize complete at 01/20/2010 17:37:26
Content-Type: multipart/alternative; boundary="=_alternative 007C4488852576B1_="
Cc: ogpx-bounces@ietf.org, "ogpx@ietf.org" <ogpx@ietf.org>
Subject: Re: [ogpx] Seed capability behavior
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: Wed, 20 Jan 2010 22:37:42 -0000

ogpx-bounces@ietf.org wrote on 01/20/2010 05:16:54 PM:

> [image removed] 
> 
> [ogpx] Seed capability behavior
> 
> Hurliman, John 
> 
> to:
> 
> ogpx@ietf.org
> 
> 01/20/2010 05:17 PM
> 
> Sent by:
> 
> ogpx-bounces@ietf.org
> 
> The current handling of seed capabilities in Second Life is that 
> they are treated like one time capabilities. The viewer knows a list
> of all of the capabilities it wants ahead of time, and makes a 
> single request containing the full requested capabilities list. Are 
> we mandating that VWRAP seedcaps must be one time capabilities or 
> must not be one time capabilities? If it’s up to each 
> implementation, we’ll get a situation where some clients make 
> multiple requests to a seed cap and are incompatible with services 
> that chose to implement one-time seedcaps.
> 
> John_______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx

My (fairly strong) preference is that they be persistent caps. I see no 
reason to force a client into the model of
asking for (and keeping track of) everything when it doesn't need it. 
Making it possible to pull caps as you need
them is upwards compatible with getting them all at once, and allows a 
more flexible usage.

I'd also point out that, if a service provides a "short term" cap which 
expires, we need a way to permit the client
to renew the cap, so that also strongly argues for a persistent cap, and, 
a fine grained one as well. I would
not want to force a re-get of every cap, when any single cap expired. 

- David 
~ Zha