Subject: [mmox] [Fwd: Re: Proposal for small enhancement in the LLSD draft]

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 11 Feb 2009 09:27:05 -0800

hmm... forgot to reply to the list as well. mea culpa.

Subject: Re: [mmox] Proposal for small enhancement in the LLSD draft
From: Meadhbh Hamrick <[email-masked]>
To: Catherine Pfeffer <[email-masked]>
Date: Wed, 11 Feb 2009 09:12:31 -0800

Hey Catherine...

the spec as written was intended to be referenced by the VW/MMO specific 
specs, which is why there's no reference to a grid, virtual worlds or 
MMOs. and since we don't go into details in the LLSD spec about how 
virtual worlds will use the spec, we don't talk about what the default 
serialization would be. this is an example of the "provide mechanism but 
not policy." the spec will probably NEVER tell you which serialization 
schemes to use, but you're right, we should probably mention this 
somewhere so it doesn't look like we forgot about it.

but yes... it's totally something that needs to be mentioned somewhere 
before there's a hope for interoperability. i believe our expectation 
was that each grid provider would be "liberal in what it accepted, but 
conservative in what it produced." realistically, each serialization has 
a specific case in which it is more appropriate. binary serialization is 
probably more appropriate for messages whose hosts care more about how 
long it takes to parse something than how readable the message is over 
the wire (perhaps for mobile clients or for inter-simulator messaging.) 
JSON serialization is probably more appropriate for someone who wants to 
do a lot of web client type work (like managing your inventory from a 
web page.) XML serialization is the "everything else" serialization, 
providing better readability over the wire and the ability to use 
commercial XML tools, but with the drawback that  you're going to have a 
"angle bracket tax."

so to be a little more detailed about interoperability... there are 
several standards out there where the spec defines the "what" and 
individuals using the spec define the "how it's used." X.509 and RTP 
come to mind as examples. There's a lot in PKIX and X.509 that Verisign 
will NEVER use. There's a different set of things that Entrust will 
NEVER use. But the features that each uses isn't defined in the PKIX 
spec, but in the certification policy and certification practice 
statement (sometimes) or in the interfaces each of those organizations 
provide for their customers. RTP (RFC3550) defines an abstract protocol 
for real-time data, but it's RFC3551 that defines how that protocol is 
used to provide VoIP like services.

in other words... we're expecting people to define their own 
interoperability profiles where they list which serializations they'll 
produce and which they'll consume. but we didn't mention that anywhere 
and yes that is an oversight.

i'm also noting that we haven't listed a mechanism for content 
negotiation. we define MIME types in the RFC, and we're talking about 
how we like to layer application protocol on top of HTTP, so maybe it's 
not unreasonable to add a section like "simple content negotiation for 
using LLSD in an HTTP environment." that would say something like...

"if the client doesn't care what serialization it gets back, it SHOULD 
include the 'Accept: */*' header in the request. the server MAY return a 
status code 300 to indicate it won't make a decision on serialization 
for the user. if the client does have a preference, it should be listed 
in the Accept header. The server is REQUIRED to include a Content-Type 
header to identify the serialization used. If the server cannot produce 
the serialization requested by the client, the server MUST return a 406 
error code."

but honestly... we might want to put this in a different document, 
something like "the use of LLSD over HTTP" where we could discuss other 
issues like character sets used, content encodings (we think people like 
gzipped content, and we would like to produce it in a "standard" way.) 
and also.. we all should probably take a closer look at section 12 of 
RFC2616 before writing anything intended to be standardized.

Catherine Pfeffer wrote:
> Hi all,
>
>
> I propose to add to the xxSD draft:
>
>  "Agreement on the type of serialization used is not in the scope of 
> this document"
>
> to show that we've thought about the problem of the negociation of 
> type of serialization.
>
> Or if there is a preferred serialization, like XML, mention it.
> Or if the type of used serialization is hardwired into a given grid, 
> say it.
> Or if all grids are supposed to support all types of serialization, 
> say it.
>
> But my feeling is that currently this point is left in the dark.
>
> Sorry in advance if this point is mentioned in the draft and I have 
> missed it. I tend to read things a bit quickly because of lack of time.
>
> -- 
> Catherine Pfeffer
> ------------------------------------------------------------------------
>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>

---

From: Morgaine Dinova <[email-masked]>
Date: Thu, 12 Feb 2009 03:05:46 +0000

On Wed, Feb 11, 2009 at 5:27 PM, Meadhbh Hamrick <[email-masked]>wrote:

> gzipped content, and we would like to produce it in a "standard" way.) and
> also.. we all should probably take a closer look at section 12 of RFC2616
> before writing anything intended to be standardized.
>
> Yes, that would be exactly right.  The document on Structured Data would be
the wrong place for it.  Options negotiation is a completely different
concern from the definition of data and serializations.

I'd go further and suggest that the three alternative serializations should
be defined in separate documents too (or maybe as external Annexes to the
main spec), otherwise adding a new serialization will require updating the
original specification document, which is a bad thing.  We've already
identified here a fourth serialization that will be desired very strongly,
which is Google Protocol Buffers, so this is an immediate requirement rather
than a hypothetical one.

On that note, the draft Structurd Data spec needs "Binary" serialization to
be renamed to something less generic, since Protocol Buffers is a binary
serialization as well.

Morgaine.