Re: [mmox] LLSD

"Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com> Fri, 20 February 2009 06:38 UTC

Return-Path: <infinity@lindenlab.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6B13A6960 for <mmox@core3.amsl.com>; Thu, 19 Feb 2009 22:38:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.499
X-Spam-Level:
X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 IxdQnhn5FMUl for <mmox@core3.amsl.com>; Thu, 19 Feb 2009 22:38:34 -0800 (PST)
Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 880693A672F for <mmox@ietf.org>; Thu, 19 Feb 2009 22:38:34 -0800 (PST)
Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id C2BEA3DBC45C; Thu, 19 Feb 2009 22:38:47 -0800 (PST)
Message-Id: <FC42B493-529E-424B-9411-80781A570B12@lindenlab.com>
From: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
To: Charles Krinke <cfk@pacbell.net>
In-Reply-To: <61320.78349.qm@web82607.mail.mud.yahoo.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Thu, 19 Feb 2009 22:38:46 -0800
References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <80E946E9-5C62-4E00-BE8C-A15513898F99@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> <29656.28734.qm@web82607.mail.mud.yahoo.com> <C803B307-0984-40AE-946A-00EDDA664502@lindenlab.com> <61320.78349.qm@web82607.mail.mud.yahoo.com>
X-Mailer: Apple Mail (2.930.3)
Cc: "mmox@ietf.org" <mmox@ietf.org>
Subject: Re: [mmox] LLSD
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2009 06:38:35 -0000

anything that uses LLSD and wants to be considered a "standard" must  
only provide normative references that are also "standards".

essentially the deal here is we think the RFCs that will eventually  
provide the authoritative references for OGP should be put on the IETF  
"standards track." in fact, this is the primary raison d'ĂȘtre for the  
proposed working group. if OGP is to be a "real" IETF standard, all  
the documents it references as "normative" need to be standards as well.

the alternative was to simply continue publishing our interface  
documents on our wiki and perhaps publishing LLSD as an informational  
RFC. however... we thought it better to use our existing OGP work as a  
starting point, put it out in a forum where the expertise of the  
internet engineering community could be utilized to review, comment  
and improve it. our objective is to create a robust, flexible family  
of protocols usable by the widest practical community.

and for what it's worth, in the context of the proposed working group  
OGP/Teleport and HyperGrid are two proposals [1] for doing similar  
things. The two approaches _do_ seem assume different trust models,  
and maybe the future is that both will find wide adoption. the "define  
mechanism, not policy" mantra you sometimes hear some people repeat  
implies that neither approach should preclude implementations from  
implementing both. this is rather like most modern email user agents  
implementing both,POP3 _and_ IMAP. the two protocols do essentially  
the same thing, but there's nothing in either protocol that prevents  
you from using either or both in the same mail client.

but i ramble.

the question as i read it was "would trying to approve the draft of  
LLSD preclude or perturb further protocols?" the answer i would give  
would be "no. it shouldn't."

-cheers
-meadhbh

[1] - yes... actually neither are currently internet drafts, but i  
believe John is working on something HyperGridish and OGP/Teleport was  
listed on the draft charter of the proposed working group.

On Feb 19, 2009, at 8:34 PM, Charles Krinke wrote:

> Ok, Meadhbh:
>
> In looking at this draft *and* hoping I dont make my OpenSim peers  
> too unhappy with me, let me ask a question.
>
> "Is there any reason why trying to approve the draft LLSD spec would  
> preclude or pertubate either OGP, HyperGrid or other similar notions  
> from being supported?"
>
> Charles
>
> From: Meadhbh Hamrick (Infinity) <infinity@lindenlab.com>
> To: Charles Krinke <cfk@pacbell.net>
> Cc: "mmox@ietf.org" <mmox@ietf.org>
> Sent: Thursday, February 19, 2009 8:10:05 PM
> Subject: Re: [mmox] LLSD
>
> http://wiki.secondlife.com/wiki/MMOX is non-authoritative, but yes  
> LLSD is one of the work items we have on the list.
>
> the objective of LLSD is to provide an abstract type system with  
> multiple serializations. it also defines the mime types.
>
> however, to say that the LLSD draft exists only to define the  
> serializations is akin to saying that ASN.1 exists only to provide  
> input into DER or BER encodings. the two are linked, but each has a  
> particular use.
>
> LLSD as an abstract type system allows us to define and reason about  
> the semantics of structured data used in PDUs independent of an  
> existing implementation language. the serialization rules allow us  
> to format structured data prior to transport and later de-serialize  
> it after receipt. the MIME type registrations allow us to identify  
> the serialization scheme used on transports that support the use of  
> MIME types. LLIDL (pronounced "little") defines the set of expected  
> parameters to and responses from a resource access.
>
> LLSD was selected as the first draft to work on as it is used as a  
> building block for other protocol interactions, some of which are  
> published in draft form on the second life wiki. the further  
> development of these protocols is also considered a task of the  
> proposed working group.
>
> -cheers
> -meadhbh
>
> On Feb 19, 2009, at 7:52 PM, Charles Krinke wrote:
>
>> In looking at the secondlife wiki at http://wiki.secondlife.com/wiki/MMOX 
>>  it looks like one of the first proposals for this working group is  
>> the LLSD draft specification.
>>
>> Am I correct in that the gist of the LLSD specification is  
>> essentially to propose three mime formats and thats about it for now?
>>
>> application/llsd+xml
>> application/llsd+json
>> application/llsd+binary
>>
>> Charles
>> _______________________________________________
>> mmox mailing list
>> mmox@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmox
>
>