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 > >
- [mmox] More LLIDL questions Hurliman, John
- Re: [mmox] More LLIDL questions Mark Lentczner
- Re: [mmox] More LLIDL questions Hurliman, John
- [mmox] LLSD Charles Krinke
- Re: [mmox] LLSD Meadhbh Hamrick (Infinity)
- Re: [mmox] More LLIDL questions Meadhbh Hamrick (Infinity)
- Re: [mmox] LLSD Charles Krinke
- Re: [mmox] LLSD Meadhbh Hamrick (Infinity)
- Re: [mmox] More LLIDL questions Hurliman, John
- Re: [mmox] LLSD Charles Krinke
- Re: [mmox] LLSD Jesrad
- Re: [mmox] LLSD Charles Krinke
- Re: [mmox] More LLIDL questions Mark Lentczner
- Re: [mmox] LLSD Meadhbh Hamrick (Infinity)
- [mmox] LLSD and content schema Jon Watte
- Re: [mmox] LLSD and content schema Morgaine
- Re: [mmox] LLSD and content schema Meadhbh Hamrick (Infinity)
- Re: [mmox] LLSD and content schema Jon Watte
- Re: [mmox] LLSD and content schema Lisa Dusseault
- Re: [mmox] LLSD and content schema Jon Watte