Re: [mmox] LLSD

["Meadhbh Hamrick (Infinity)" <[e-mail]>]

hey jesrad...

conceptually ASN.1 and LLSD are similar, but LLSD is probably more  
appropriate for accessing RESTful accesses over a HTTP(S)-like  
transport.

specifically...

* LLSD was designed to be "less declarative" than ASN.1 . which is to  
say, all LLSD components are optional, so it is never a transport- 
layer error to not include a "required" parameter.
* LLSD (including LLIDL) is considerably smaller.
* the focus of LLSD is actually on the application layer, not on the  
transport syntax; but yes... we spend an awful lot of space in the  
draft talking about serializations, so this focus is sorta obscured  
there.
* LLSD is implementable by mortals in a tractable amount of time and  
without the use of complicated third-party tools (ASN.1 compilers, etc.)
* LLSD uses more consistent serializations (when compared with BER or  
DER)

so to recap ...

LLSD and ASN.1 are similar, but LLSD was designed to transport  
structured data that accepted extra parameters (or missing parameters)  
in a PDU without the need to recompile and deploy new PDU parsers.

-cheers
-meadhbh

On Feb 20, 2009, at 7:41 AM, Jesrad wrote:

> 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
>>
>>
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox