[ogpx] content negotiation for LLSD over HTTP connections

[Infinity Linden <[e-mail]>]

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