Re: [mmox] LLSD

[Charles Krinke <[e-mail]>]

Certainly, and that is an interesting issue in itself. 

My assumption is that the LL team picked the simplist place to start from in the spirit of gaining momentum with an IETF working group.

I can see lots of interesting and spirited discussions on the horizon over all the things that have been mentioned on this list in the last few days including :

1. Identification & Authorization ala OpenID and others.
2. The balance between server side and client side functionality.
3. Avatar definition consistent to render an avatar with and without scripted attachments in various virtual worlds.
4. Objects moving from one virtual world to another with various associated permissions.

But, none of this is described in the draft at all. As I look at it, it seems this is a reasonable way for this group to gain credibility with the ietf with a very basic draft and then this is to be followed up with more structure later. 

Whether or not the variable and mime definitions help innovation for virtual worlds and if they are, how to lay the foundation for the greatest flexibility certainly seems like a more interesting and relevant discussion then whether or not joe can drive is BatMobile through the FarGate between Croquet and Fortrerra and expect all the scripted weapons to be blazing.

Charles




________________________________
From: Jesrad <[e-mail]>
To: Charles Krinke <[e-mail]>; "[e-mail]" <[e-mail]>
Sent: Friday, February 20, 2009 7:41:47 AM
Subject: Re: [mmox] LLSD

Just to be sure: LLSD in the context of MMOX is meant to fulfill
roughly the same goal as ASN.1
(http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One) does in
general communications ?

On Fri, Feb 20, 2009 at 4:28 PM, Charles Krinke <[e-mail]> wrote:
> 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) <[e-mail]>
> To: Charles Krinke <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> 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) <[e-mail]>
>> To: Charles Krinke <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmox
>>
>>
>
>
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox
>
>