MessagePackに関する私案 / An Idea on MessagePack
こんな所に書いても誰も読まないと思うが。また、誰かしらこの程度の発案はしていると思うが。
UTF-8 文字列を既存仕様に追加して相互運用性をなくすのは、時間とコストの無駄だし、がんばってもUTF-8文字列「しか」追加できない。Rawをちゃんと拡張できるようにしたらどうだろうか。つまり、Rawの解釈系をMessagePackの「上に」起く。RFC822に対するMIMEの立場。もちろん、元々のMessagePackのフォーマットでRawを文字列として解釈するのは、非MIMEなRFC822と一緒で、継続して運用可能。
Carsten(@cabo)がからんでるWGにcore WGってのがあり、ここで決めているCoAPに、ちょうどいいことに「Content Type*1をshort identifierで表現する」仕様が含まれている。Rawに簡単なヘッダを作って、このIDを含める、あるいは、CoAPのOption Headerの一部仕様を拝借してきて、RawをCoAP Payloadとして解釈すればいい。そうすれば text/plain; coding=utf-8 を指定しようが、application/senml-exi を指定しようが、好きにできる。
I don't expect this could reach to somebody. This kind of idea should be already proposed by somebody else (I haven't read the github discussions).
Adding UTF-8 string to existing MessagePack format in IETF takes plenty time and cost. It breaks existing 'running code', and that painful cost can afford 'UTF-8 string' _ONLY_. If I'm going to propose something in IETF, I will try to add another layer to parse/decode Raw part of MessagePack. This is thin adaptation layer between application and MessagePack serializer, just same as MIME format on RFC822 series. Of course, current/existing MessagePack implementations work as is.
There is core working group that Carsten serves as a co-chair. CoAP is a product of the working group and this contains spec to describe "Content Type*2" in an integer. Raw format can be annotated by short header with this content format ID, or it may just borrow some part of CoAP options and make it as CoAP payload. This way of extension gives a safe way to use text/plain; coding=utf-8 or even application/senml-exi (not yet registered).
