Re: [vwrap] is the group still interested in LLSD or DSD?

[Dzonatas Sol <[e-mail]>]

Don't worry, I (we) "get it".

In attempts (to implement and) go forward with both LLSD and DSD, I 
already answered that question. I await your further effort to the 
effort I did to review your previous posts about DSD.

http://www.ietf.org/mail-archive/web/vwrap/current/msg00833.html

http://www.ietf.org/mail-archive/web/vwrap/current/msg00830.html

If you expect yours to remain "out of scope" to this WG, then lets 
continue to go forward with LLSD as-is.

Why use such straw-man to avoid the obvious concern of private 
unencrypted URIs, which breaks this WG if we continue to avoid this big 
elephant in the room. With the LLIDL additions I made for combined 
queries, this at least helps "secure" that insecurity with being able 
pipeline requests over pivotal data. Obviously, any demand to use only 
plain old HTTP leads right back to the elephant.

RFCs shouldn't be used to make people look stupid by default expected 
implementation. I hope no one here is trying to do this, yet the 
avoidance of this issue make this much questionable. There is an obvious 
level of concern about privacy and copybots. This elephant is a 
show-stopper unless you got lawyers already to help protect "the game". 
http://en.wikipedia.org/wiki/The_Game_%28mind_game%29

We're being more serious about simulation and region-agent transistion 
then just games (and its loops) that has been repeated for the last few 
years. The game needs to stop we are trying to address the issue.

Do recognize TLS/STLP as viable or do you continue to recommend to only 
send either LLSD or DSD over simple HTTP?

On 05/04/2011 07:32 AM, Meadhbh Hamrick wrote:
> but the question was... yes or no... do we want LLSD or DSD (it's
> successor) to be part of VWRAP moving forward?
>
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>
>
>
> On Wed, May 4, 2011 at 7:21 AM, Dzonatas Sol<[e-mail]>  wrote:
>    
>> We already know highly abstract data types that have all kinds of
>> extensibility, so there is no need to reinvent that much.
>>
>> We just need "best fit" for the documentation and basic usage of resources
>> as capabilities with LLIDL.
>>
>> Any further extensibility is specific to implementation, and that specific
>> implementation should be expected (as common mode with RFCs). What matters
>> is, can we use these data types to convey the concept? Yes, we have
>> demonstrated we can.
>>
>> Again, I worry less about that and more about the combine queries, which
>> would let you extend in many other ways besides mere serialization,
>> especially when pivotal data is known.
>>
>> Your argument only justifies further reason for me to move and update
>> SNOW-375 ( http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375 ) to
>> the IETF wiki, especially if we expect STLP, which I rather forward-think
>> about, instead of private unencrypted URIs.
>>
>>
>> On 05/04/2011 07:02 AM, Morgaine wrote:
>>      
>>> Extensibility through XML is not extensibility of the types of the
>>> underlying ADT.
>>>
>>> The types of the ADT are expressed through 3 canonical serializations.
>>> �Those serializations merely reflect the types defined by the underlying
>>> ADT, and the XML serialization alone cannot extend the underlying ADT
>>> without breaking the mapping of the ADT to the other serializations.
>>>
>>> It's the type system itself that has to be extensible before you can
>>> validly use extended types in one of its serializations.
>>>
>>>
>>> Morgaine.
>>>
>>>        
>>
>> --
>> --- https://twitter.com/Dzonatas_Sol ---
>> Web Development, Software Engineering, Virtual Reality, Consultant
>>
>> _______________________________________________
>> vwrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>>      
>    


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant