[occi-wg] Fwd: Structured data over TCP?

[Sam Johnston]

We're not the only ones discussing XML vs JSON it seems... DJB's netstrings
are another interesting (secure/parser friendly) approach and I reckon at
least one implementation will appear which talks OCCI to nodes over protocol
buffers <http://code.google.com/apis/protocolbuffers/docs/overview.html>before
long.

With the current proposal it doesn't matter - it's just key-value pairs and
there's only so many ways you can render them which can trivially be
described in the spec (e.g. "space separated text")

Sam

---------- Forwarded message ----------
From: "Martin J. Dürst" <duerst at it.aoyama.ac.jp>
Date: 2009/5/27
Subject: Re: Structured data over TCP?
To: Patrik Fältström <patrik at frobbit.se>
Cc: apps-discuss at ietf.org


Hello Patrik,

Some points, not necessarily in any particular order:

- I haven't been able to figure out what the trailing ',' in netstrings is
for. Any idea?

- Netstrings don't say what encoding the data is in; that needs to be
settled separately. XML can handle many character encodings if necessary,
with sensible defaults, and there is no chance character encoding issues get
forgotten. Json seems to be UTF-8 only in practice, which in most cases is
about the best you can do these days.

- Json's data types are closer to the data types available in many
(especially dynamic) programming languages when compared with XML. XML has
the advantage that it can represent both data as well as (textual)
documents. The later would have to be done with a hopeless hack in Json.

- Json can be directly interpreted in JavaScript. Some lazy developer may do
it. But it would be an extremely bad idea, because it creates great security
holes.

- Both Json and XML are widely used on the Web, in what's called Ajax. But
there are usually no length prefixes in either case.

- There is RFC 3470 for the use of XML in the IETF. Please have a look if
you haven't already done so. I'm not sure there is something similar for
Json.

- You say "Now, we need some more protocols here", but to me, it looks more
like you want to exchange some more data. Some people might disagree, but I
think there is absolutely no need to invent a new protocol every time some
data has to be transferred.

- Whether you call it "more protocols" or just "more data formats", if I
were at either side of the data exchange, I wouldn't so much care about
whether XML is easier to implement or Json or what, but I'd really hate to
have a ton of different protocols/formats, each with a different technology.
So unless the community involved thinks that this EPP Data Unit Format is
hopelessly broken, I'd use the same scheme for all the other
protocols/formats.

Regards,     Martin.


On 2009/05/27 14:46, Patrik Fältström wrote:

> It was many years ago popular to use line breaks as delimiters in data,
> and on each line have essentially attribute/value pairs.
>
> Then we got XML that today seems to be what people want to use (because
> there are libraries, and tons of programmers that can (not?) implement
> XML parsers). We also have "content-length prefixed" XML data, that make
> things sort of simpler.
>
> Sort of in parallell, we have xmlrpc, that to some degree solve slightly
> different problems.
>
> Personally, I have lately looked at JSON, and after serializing data and
> then use Netstrings (http://cr.yp.to/proto/netstrings.txt), I must say I
> really like it.
>
> For those that do not know Netstrings, here is an example from the spec:
>
>  For example, the string "hello world!" is encoded as <31 32 3a 68 65
>> 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,". The empty
>> string is encoded as "0:,".
>>
>
> Implementing is very simple, and you know how many bytes to read. An
> example JSON-netstring thing can look like (for a 3-object array with a
> hash as the third object, where the hash as one entry):
>
> 29:[1, "info", {"msg": "Hello"}],
>
> In the DNS provisioning world we have come up with epp (RFC 3730) that
> has a binding to TCP (RFC 3734). The binding is a prefixed-based XML
> blob that is passed over the wire:
>
>  EPP Data Unit Format (one tick mark represents one bit position):
>>
>> 0 1 2 3
>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Total Length |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | EPP XML Instance |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>
> Now, we need some more protocols here (between DNS operator and the
> registrar), and the question is whether the same mechanism is
> recommended, or whether one should use something else?
>
>
> Do Apps Area have any general feeling about this?
>
> Patrik
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Apps-Discuss mailing list
> Apps-Discuss at ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst at it.aoyama.ac.jp
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss at ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090527/62945e26/attachment.html