IETF Logo Mail Archive

[ogpx] Seed capability behavior

"Hurliman, John" <john.hurliman@intel.com> Wed, 20 January 2010 22:17 UTC

Return-Path: <john.hurliman@intel.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 C7E9C3A6948 for <ogpx@core3.amsl.com>; Wed, 20 Jan 2010 14:17:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 veHBT0GnpLxR for <ogpx@core3.amsl.com>; Wed, 20 Jan 2010 14:17:06 -0800 (PST)
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id EFCE93A67D8 for <ogpx@ietf.org>; Wed, 20 Jan 2010 14:17:05 -0800 (PST)
Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 20 Jan 2010 14:16:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="4.49,312,1262592000"; d="scan'208,217"; a="588933614"
Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by orsmga001.jf.intel.com with ESMTP; 20 Jan 2010 14:16:59 -0800
Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by rrsmsx602.amr.corp.intel.com (10.31.0.33) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 20 Jan 2010 15:16:59 -0700
Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Wed, 20 Jan 2010 15:16:59 -0700
From: "Hurliman, John" <john.hurliman@intel.com>
To: "ogpx@ietf.org" <ogpx@ietf.org>
Date: Wed, 20 Jan 2010 15:16:54 -0700
Thread-Topic: Seed capability behavior
Thread-Index: AcqaHkYUtOG5T+YTSRuvY02ZK7jbxQ==
Message-ID: <62BFE5680C037E4DA0B0A08946C0933DC4B2DCF9@rrsmsx506.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-puzzleid: {46256A00-F71F-4653-B83B-A26540E9EBD2}
x-cr-hashedpuzzle: AD4f Anc8 A4Mk BzIN CXOc CiIi DebG D4Y5 GaSM Gt9Z Hvgy H2q+ IQQk LJN3 Lc7R Lrjd; 1; bwBnAHAAeABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {46256A00-F71F-4653-B83B-A26540E9EBD2}; agBvAGgAbgAuAGgAdQByAGwAaQBtAGEAbgBAAGkAbgB0AGUAbAAuAGMAbwBtAA==; Wed, 20 Jan 2010 22:16:54 GMT; UwBlAGUAZAAgAGMAYQBwAGEAYgBpAGwAaQB0AHkAIABiAGUAaABhAHYAaQBvAHIA
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_62BFE5680C037E4DA0B0A08946C0933DC4B2DCF9rrsmsx506amrcor_"
MIME-Version: 1.0
Subject: [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:17:08 -0000

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

v2.23.0 | Report a Bug | By Email