Hi,
Can it not be both JSON and XML supported? I would vote for that. Future
implementations may prefer XML as it is generic, omni present, easy to
understand and validate. For compactness may be a binary xml option can also
work. JSON I think will necessitate implementation to be native Java and may
not be as friendly with other implementation languages.
Best Regards,
Sajeev Manikkoth
Mobile: +918792292002
Email: [email protected]
http://www.linkedin.com/in/mksajeev
________________________________
From: "[email protected]" <[email protected]>
To: [email protected]; [email protected]; [email protected]
Cc: [email protected]
Sent: Friday, 17 August 2012, 4:55
Subject: Re: [paws] XML schema versus JSON, vCard & iCal
We have not heard any objections for using JSON encoding instead of XML.
Therefore, let's go for JSON, and close this thread.
- Gabor
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of ext
Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: '[email protected]'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal
json is okay with me.
I'd prefer an ISO time stamp rather than a time in seconds since epoch. It's
very easy to parse, and its simpler to use and debug. Don't care a whole lot
about that
Brian <as individual>
-----Original Message-----
From: Vincent Chen [mailto:[email protected]]
Sent: Monday, August 13, 2012 06:04 PM Eastern Standard Time
To: Peter Stanforth
Cc: Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email protected]
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 protected]>
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 protected]> 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.
>
>Assuming a json library can be loaded on a small device is reasonable.
>
>Brian (as individual)
>
>
>
> -----Original Message-----
>From: Peter Stanforth [mailto:[email protected]]
>Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time
>To: Teco Boot; Benjamin A.Rolfe
>Cc: [email protected]
>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 protected]> 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 protected]
>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>
>>>
>>> _______________________________________________
>>> paws mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/paws
>>
>>_______________________________________________
>>paws mailing list
>>[email protected]
>>https://www.ietf.org/mailman/listinfo/paws
>
>_______________________________________________
>paws mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
--
-vince
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
