Re: [mmox] LLSD

Charles Krinke <cfk@pacbell.net> Fri, 20 February 2009 15:28 UTC

Return-Path: <cfk@pacbell.net>
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 7DBF73A6B8C for <mmox@core3.amsl.com>; Fri, 20 Feb 2009 07:28:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 5RAfX4KVeJVl for <mmox@core3.amsl.com>; Fri, 20 Feb 2009 07:28:42 -0800 (PST)
Received: from web82608.mail.mud.yahoo.com (web82608.mail.mud.yahoo.com [68.142.201.125]) by core3.amsl.com (Postfix) with SMTP id D547F3A6B91 for <mmox@ietf.org>; Fri, 20 Feb 2009 07:28:41 -0800 (PST)
Received: (qmail 67008 invoked by uid 60001); 20 Feb 2009 15:28:56 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=jHEpTC9dc7umfBZdiibFH732qJac6s9UYtc3K0coxJFYYw0Z+R0Z6KkaPQlogjIMkKxqsCHa69V31wSwtVHwP1b61jtcT6Bw9C3uywsnTjq9IbquMMvD2NCNoGnZv0peZIhupXdIqJZevEy0xr2QX7WVCQL9VoDfXrUmpphhhcI=;
X-YMail-OSG: dCYKhccVM1nKTiwbDFIWvIE9AJDkMGSQvE1DF0q8DTTixPF_06J7dHEZEIuSdsSM9R_QrcPETpFahERG4VWJngdQuvf1Nk.m_QosBAoaMPs.hdo.g1G2_GxDyUXpzvRDZNzk_nX4GsJPyr7dZ8b8CT9UpNFyDRIM_SDBcS2a9QjMHZx.9UvH2u1I1y2xX0.JtLCBDnNeu.pmt4almdeawIg9I3Y-
Received: from [76.222.233.250] by web82608.mail.mud.yahoo.com via HTTP; Fri, 20 Feb 2009 07:28:55 PST
X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1
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> <FC42B493-529E-424B-9411-80781A570B12@lindenlab.com>
Date: Fri, 20 Feb 2009 07:28:55 -0800
From: Charles Krinke <cfk@pacbell.net>
To: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1043640084-1235143735=:66993"
Message-ID: <962799.66993.qm@web82608.mail.mud.yahoo.com>
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 15:28:43 -0000

Perhaps  I am being naive here, but I dont see anything in the draft proposal other then the definition of a few variable types and three mime definitions which seems completely innocuous to me.

Admittedly, follow on draft proposals will undoubtedly favor one teams bias at the expense of another teams bias, but I cannot find a reason not to support this variable definition and mime definition draft.

There is lots of time for us all to argue that our own favorite <whatever> is the best for the world, but it seems that any of the thoughts I have heard can all be built with this variable name and type standard.

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 10:38:46 PM
Subject: Re: [mmox] LLSD

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
> 
>