IETF Logo Mail Archive

Re: [ogpx] state/basic capability?

Suzy Deffeyes <suzyq@pobox.com> Tue, 26 January 2010 14:54 UTC

Return-Path: <suzyque@gmail.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 51A253A67FA for <ogpx@core3.amsl.com>; Tue, 26 Jan 2010 06:54:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.975
X-Spam-Level:
X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, WEIRD_PORT=0.001]
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 3c+ThJSWgaxc for <ogpx@core3.amsl.com>; Tue, 26 Jan 2010 06:54:17 -0800 (PST)
Received: from mail-fx0-f221.google.com (mail-fx0-f221.google.com [209.85.220.221]) by core3.amsl.com (Postfix) with ESMTP id 432693A67B6 for <ogpx@ietf.org>; Tue, 26 Jan 2010 06:54:17 -0800 (PST)
Received: by fxm21 with SMTP id 21so609633fxm.29 for <ogpx@ietf.org>; Tue, 26 Jan 2010 06:54:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=UN36wqZ6R4XlgqiZMmrvf7wW/ZSq//HabU7JLdG+x40=; b=w3qZd6yIJ4LRam9xiGmI03oxLMRAn6FQOf+kPP0NgKUqsoCTLheQ4N1DvZMqxcjhv2 EFKrGSrJdesAmLzzQC/Y9WywbX4I74B0SNZGVChMkEMR87LKXEg2jmgob6QZR5/iAsRs /M/Yp4CbiqRiol/IKlPSvHgXPzyZaOwX1B+RA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=VwmDF0dIyPDqhRy6+T75/zol75tYkgB/mtkqd9OgwdR7hBpqR5T+02TA20O8sUQNCL rsJPPw31mJk1LSXTPM5ifQQwmRJm8QG24Ks2indkViFsJhi6TqVVtP6CXadI5XGQr5Ct 6Wg3GfgPNnq7x++X9e8eVNRq+pGDNIN7TZhj0=
MIME-Version: 1.0
Sender: suzyque@gmail.com
Received: by 10.223.59.3 with SMTP id j3mr2823278fah.46.1264517663275; Tue, 26 Jan 2010 06:54:23 -0800 (PST)
In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933DC7215DD4@rrsmsx506.amr.corp.intel.com>
References: <62BFE5680C037E4DA0B0A08946C0933DC7215DD4@rrsmsx506.amr.corp.intel.com>
Date: Tue, 26 Jan 2010 08:54:23 -0600
X-Google-Sender-Auth: ebbb73e8a7e0cb16
Message-ID: <2bd5b7f11001260654s3c03c781h7c85a19c1dbab114@mail.gmail.com>
From: Suzy Deffeyes <suzyq@pobox.com>
To: "Hurliman, John" <john.hurliman@intel.com>
Content-Type: multipart/alternative; boundary="00151747661821bd10047e12769f"
Cc: "ogpx@ietf.org" <ogpx@ietf.org>
Subject: Re: [ogpx] state/basic capability?
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: suzyq@pobox.com
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: Tue, 26 Jan 2010 14:54:18 -0000

One additional point. In the lovely little LLSD land that we have, it is
really easy to let extra goo go along with LLSD requests and responses.  If
endpoints start to rely on this extra goo, then effectively we have goo
seeping into what is being used into the protocol, without a mechanism for
defining it explicitly as an extension to the core standard, or without
being defined in the standard.


Suzy Deffeyes


On Mon, Jan 25, 2010 at 5:13 PM, Hurliman, John <john.hurliman@intel.com>wrote:

> Public region seed capabilities currently deployed on Linden Lab's vaak
> grid are handling out a capability called "state/basic" that I haven't seen
> documented anywhere. An example of the LLSD is here:
> https://sim1.vaak.lindenlab.com:12043/cap/c6227189-7258-2ec7-f48e-89de064c5d6c
>
> The format is obviously specific to the deployed Linden Lab codebase
> (including parameters such as skip_mono_scripts and
> rccs_quarantine_release_hysteresis) and possibly acts as a replacement for
> the RegionHandshake UDP message, but the importance of this capability is
> unclear. Can it be ignored by clients? Do regions have to serve up that
> capability to get the Snowglobe 1.3 viewer working? Do we need to define a
> more generic version of this capability?
>
> John
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>

v2.23.0 | Report a Bug | By Email