Re: [ogpx] content negotiation for LLSD over HTTP connections

[Infinity Linden <[e-mail]>]

there are actually some OGP constructions that are single
(non-collection) types (and thus, not RFC4627 compliant JSON.)

for what it's worth... none of the browsers we tested (two versions of
firefox, one version of safari, two versions of IE) seemed to reject
non-collections when receiving and evaluating application/json media
types. in other words, there seems to be a fine history in the browser
world of ignoring RFCs.

still... i just noticed that RFC4627 is informational, which _may_
cause a problem in the future as we listed it as a normative reference
in the LLSD draft. maybe i'll write another, normative draft for a
version of JSON that "does the right thing" and lists the encoding in
the "standard" way by adding it to the media type.

at the end of the day, if we can develop an algorithm for identifying
the serialization without peeking at the media type, we'll probably
all be fine. thought i'll ask that developers at Linden "do the right
thing" and properly identify the media type in headers and would ask
you to do the same with developers you work with.

On Fri, Jun 26, 2009 at 6:30 PM, Hurliman, John<[e-mail]> wrote:
> This is how we're using LLSD. It will accept any of the three serializations: XML, JSON, and binary. Notation support was (thankfully) removed when the LLSD/LLIDL draft was posted. It uses a basic algorithm to try and figure out what content type the data is (since no one sets their content type headers correctly or can even agree what the content type string should be). However, only JSON data is sent. The standard "application/json" mime type is used since we're using a subset of LLIDL that is always compliant with the JSON RFC.
>
> John
>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>Infinity Linden
>>Sent: Friday, June 26, 2009 4:48 PM
>>To: [e-mail]
>>Subject: [ogpx] content negotiation for LLSD over HTTP connections
>>
>>so... we have three serialization formats for LLSD messages over HTTP:
>>XML, JSON and Binary. each has it's own uses and constituency.
>>
>>but it _does_ leave implementers and deployers with questions like:
>>
>>* must i support each and every LLSD defined serialization?
>>* under what circumstances should i choose one over the other?
>>* what if i am a server and i only want to use one serialization?
>>* what if i am a client and i only want to use one serialization?
>>
>>i have some opinions (of course). but i wanted to ask implementer's
>>opinions on these questions... so here's a starting point for
>>discussion...
>>
>>THE BACKSTORY
>>
>>way back in the day, some people noticed SL's proto-LLSD "annotation
>>format" looked an aweful lot like JSON. users with a copy of ethereal
>>/ wireshark could see lotsa XML flying around too. so when public
>>discussions of OGP came along, people naturally thought that LLSD
>>SHOULD be serialized using JSON ("cause... you know.. like the whole
>>web is movign to JSON, dude.") well... except those people who thought
>>it should be serialized using XML, since XML was the king of all
>>structured information interchange formats. and then there were the
>>people who said, "oh noes! you have to use a binary format to get
>>efficiency!"
>>
>>all these different stakeholders have valid points. and that's part of
>>why we have LLSD as an abstract type system with three defined
>>serializations today.
>>
>>THE MORE RECENT BACKSTORY
>>
>>then last year when we started the interop work, software engineers
>>had to code message parsers and the like. for the most part, we
>>ignored JSON and binary serializations and focused on XML. but.. we
>>know we can't do that moving forward.
>>
>>THE PROBLEM
>>
>>what we only started handling last year was addressing the questions
>>above: should my service support ALL serializations? what do i do if i
>>get a serialization i don't like? or can't understand?
>>
>>THE SOLUTION (we wanted to implement last year but didn't have time for)
>>
>>inspired by the words "an implementation should be conservative in its
>>sending behavior, and liberal in its receiving behavior," [RFC760] we
>>figured a generally available service SHOULD accept messages
>>serialized with all three defined serializations (XML, JSON & Binary,)
>>but SHOULD probably try to send things using one serialization.
>>
>>we're using the word "SHOULD" here in case you're building a service
>>where you control both the producer and consumer of a service and only
>>want to support one serialization (maybe you have a super-fancy
>>hardware XML parser and you choke when you get JSON or something.) i
>>think there's general agreement that we don't want to force deployers
>>/ implementers in these situations to use a serialization that will be
>>difficult for them.
>>
>>and maybe you're a developer building a new client, and you were able
>>to get the JSON library to build on your system, but expat remains
>>unavailable. we don't want to force you to support XML in this case.
>>
>>but... in all these cases there are probably very good ideas to
>>support the other serializations, but we're going to let you analyze
>>the trade-offs.
>>
>>so... back to the questions above... should a well defined service
>>accept requests using all three LLSD serializations? i vote "yes." it
>>is in keeping with internet tradition and a generally good idea. when
>>a client uses HTTP to transport an OGP message from client to server
>>via PUT or POST, it may include a Content-Type: header to tell the
>>server about the serialization it is using. if the client wants a
>>response using a particular serialization, it can use the Accept:
>>header.
>>
>>so.. question... what should happen if the server doesn't want to use
>>the serialization(s) specified in the Accept: header? or the client
>>identifies a serialization the server just doesn't understand? Maybe a
>>406 or 415 response?
>>
>>anyway. this is just an initial post to get the discussion started.
>>
>>if you have any opinions one way or another, please voice them here.
>>
>>-cheers
>>-meadhbh
>>_______________________________________________
>>ogpx mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ogpx
>>
>