Subject: Re: [paws] XML schema versus JSON, vCard & iCal

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 13 Aug 2012 09:30:19 -0400

Our experience in the IETF over many years is that economizing message size and compromising utility and security in search of efficiency of implementation on small devices is a poor trade off.  I am not advocating being wasteful of resources, but I don't think we should seriously consider the overhead of XML or json to be significant.

Assuming a json library can be loaded on a small device is reasonable.

Brian (as individual)

 -----Original Message-----
From: 	Peter Stanforth [mailto:[email-masked]]
Sent:	Saturday, August 11, 2012 07:13 AM Eastern Standard Time
To:	Teco Boot; Benjamin A.Rolfe
Cc:	[email-masked]
Subject:	Re: [paws] XML schema versus JSON, vCard & iCal

Not all masters run over the core network.
Some of the Use cases have a master talking to another OTA
We should not assume that all Masters are attached to utility power so we
should be sympathetic to processing energy use also.

On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <[email-masked]> wrote:

>
>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe het volgende geschreven:
>
>> Compactness of messages is important, but it is also important (to me
>>at least) to be realizable in an implementation with limited resources,
>>such as embedded devices in what are now popularly called "M2M"
>>applications.  A lot of these devices could use IP all the end to end,
>>but may have a very compact, simple stack and applications (i.e.  no
>>browser).  Is JSON typically implemented when there is no browser?
>>Would it be hard to do in a resource constrained device (i.e. where we
>>talk about memory size in Kilo-bytes still).
>
>In use cases and requirements document, there are no requirements for
>protocol performance. I guess OS/IP/TCP/TLS code size supersedes needs
>for JSON or XML. 
>
>Same for timing: TCP/TLS connection setup will take more than the PAWS
>message exchange, I think. This may be of importance when using satcom
>links.
>
>Because PAWS runs between master and database, over core network,
>performance is not our primary concern. But as always, it is good to keep
>an eye on efficiency.
>
>Teco
>
>> Thanks
>> Ben
>> 
>> 
>>> We had a discussion on XML vs. JSON. I prefer the one with most
>>>compact messages.
>>> 
>>> On vCard and JSON: what is the status of "A JavaScript Object Notation
>>>(JSON) Representation for vCard"?
>>> http://tools.ietf.org/html/draft-bhat-vcarddav-json-00
>>> 
>>> On valid times: can we use same format as certificates? They have
>>>similar simple requirements: valid notBefore&  notAfter.
>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
>>> 
>>> Teco
>>> _______________________________________________
>>> paws mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/paws
>>> 
>> 
>> _______________________________________________
>> paws mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/paws
>
>_______________________________________________
>paws mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/paws

---

From: Peter Stanforth <[email-masked]>
Date: Mon, 13 Aug 2012 09:49:11 -0400

Whenever we built mobile devices we never dealt with IETF, in our sensor
days even an IP stack was a challenge,so I would defer to the device guys
on that one. 

On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"
<[email-masked]> wrote:

>Our experience in the IETF over many years is that economizing message
>size and compromising utility and security in search of efficiency of
>implementation on small devices is a poor trade off.  I am not advocating
>being wasteful of resources, but I don't think we should seriously
>consider the overhead of XML or json to be significant.
>

---

From: Vincent Chen <[email-masked]>
Date: Mon, 13 Aug 2012 15:04:34 -0700

XML vs JSON

Between XML and JSON, JSON messages are more compact and easier to process
(parsing, synthesis). As clarification, JSON does not require JavaScript or
a Browser. It is a text-based representation of data that is language
independent, yet well-matched to all major languages. JSON-handling
libraries exist for numerous languages (see of http://json.org) and seem to
be reasonably light weight.

Timestamps

As for timestamp specifications, should we consider just using seconds
since the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need
for datetime-string parsing on devices, assuming devices already have
native libraries that provide time in this format. Is that a valid
assumption? Of course, this is less human-readable....

-- 
-vince

---

From: Paul Lambert <[email-masked]>
Date: Mon, 13 Aug 2012 16:33:52 -0700

XML vs JSON vs YAML

YAML is structure compatible with JSON and is more readable.  It uses colon delimited tags with indentation instead of brackets. It's a superset of JSON and a subset could be used effectively to provide direct JSON-to-YAML correspondence.

http://www.kuro5hin.org/story/2004/10/29/14225/062

A binary mapping can be defined for any YAML set of tags if efficiency is important.

I find YAML much more readable

Paul

Paul A. Lambert | Marvell | +1-650-787-9141

From: [email-masked] [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: Monday, August 13, 2012 3:05 PM
To: Peter Stanforth
Cc: [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Between XML and JSON, JSON messages are more compact and easier to process (parsing, synthesis). As clarification, JSON does not require JavaScript or a Browser. It is a text-based representation of data that is language independent, yet well-matched to all major languages. JSON-handling libraries exist for numerous languages (see of http://json.org) and seem to be reasonably light weight.

Timestamps

As for timestamp specifications, should we consider just using seconds since the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for datetime-string parsing on devices, assuming devices already have native libraries that provide time in this format. Is that a valid assumption? Of course, this is less human-readable....

On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:
Whenever we built mobile devices we never dealt with IETF, in our sensor
days even an IP stack was a challenge,so I would defer to the device guys
on that one.

On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"
<[email-masked]<mailto:[email-masked]>> wrote:

>From:  Peter Stanforth [mailto:[email-masked]<mailto:[email-masked]>]
>Cc:    [email-masked]<mailto:[email-masked]>
>On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <[email-masked]<mailto:[email-masked]>> wrote:
>
>>
>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

--
-vince

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Tue, 14 Aug 2012 09:29:34 -0700

Thanks Vincent, that's what i didn't know (well one thing from a
vast set of things I don't know, but the one thing most relevant tot
his thread :-).

Thanks Brian, that's what I was looking for.  We're seeing scaled
down IP stacks fitting compactly into embedded devices such as
sensors more commonly, but it is certainly not assured.  When I say
"scaled down", essentially you figure out what the application needs
and leave all the rest of the protocol out. That works for devices
that won't change what the application layer needs from the
protocol. I think some M2M applications could use this model, with a
scaled down IP stack supporting PAWS.  This is the case that is
interesting on this list I would expect.

Some M2M applications will not support IP to the endopoints, so an
intermediate will get involved.  Not much concern to the purpose of
this list, but explains somewhat my unique perspective.

hope that helps.

Ben (as a unique individual ;0).

XML vs JSON

Between XML and JSON, JSON messages are more compact and
easier to process (parsing, synthesis). As clarification, JSON
does not require JavaScript or a Browser. It is a text-based
representation of data that is language independent, yet
well-matched to all major languages. JSON-handling libraries
exist for numerous languages (see of http://json.org) and seem to be
reasonably light weight.

Timestamps

As for timestamp specifications, should we consider just
using seconds since the UNIX Epoch (1970-01-01T00:00:00Z)? This
would eliminate the need for datetime-string parsing on devices,
assuming devices already have native libraries that provide time
in this format. Is that a valid assumption? Of course, this is
less human-readable....

On Mon, Aug 13, 2012 at 6:49 AM, Peter
Stanforth <[email-masked]>
wrote:

Whenever we built mobile devices we
never dealt with IETF, in our sensor

days even an IP stack was a challenge,so I would defer to
the device guys

on that one.

<[email-masked]>

>On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot"
<[email-masked]>
wrote:

>>Op 10 aug. 2012, om 18:10 heeft Benjamin A.
Rolfe het volgende

>>geschreven:

paws mailing list

[email-masked]

--

-vince

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 14 Aug 2012 12:40:34 -0400

I said this in the meeting at IETF84, but I'll repeat it on the list, because we have quite a few members who aren't IETF regulars.

I am a co-chair.  I also am interested in the subject, have some relevant experience, and wish to participate in the creation of the protocol independently of my role as co-chair.

When I send a message to the list, it's useful for readers to know if I'm speaking as chair, or just as an interested participant.  When I write "as individual", it means that it's just a personal view, and not a chair position.  As an individual participant, I have no special status.  I'm just one voice among many.   If I specifically say "as chair", then I'm acting in my co-chair role, and you should treat the message that way.  Co-chairs have limited powers in the IETF, but sometimes, chair assertion is necessary to make the work group function smoothly.

Most of you aren't co-chairs (Gabor of course, is), so you don't have to identify yourself in a role.  I do.

Brian

From: "Benjamin A. Rolfe" <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Aug 2012 12:29:34 -0400
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Thanks Vincent, that's what i didn't know (well one thing from a vast set of things I don't know, but the one thing most relevant tot his thread :-).

Thanks Brian, that's what I was looking for.  We're seeing scaled down IP stacks fitting compactly into embedded devices such as sensors more commonly, but it is certainly not assured.  When I say "scaled down", essentially you figure out what the application needs and leave all the rest of the protocol out. That works for devices that won't change what the application layer needs from the protocol. I think some M2M applications could use this model, with a scaled down IP stack supporting PAWS.  This is the case that is interesting on this list I would expect.

Some M2M applications will not support IP to the endopoints, so an intermediate will get involved.  Not much concern to the purpose of this list, but explains somewhat my unique perspective.

hope that helps.

XML vs JSON

Timestamps

--
-vince