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

[Don Joslyn <[e-mail]>]

So if you use JSON for LoST, are you really supporting the LoST standard as it's currently written?

Is there any chance that PAWS could use an existing LoST server? Does one exist? If one does not exist, then I'm assuming that someone would need to implement a LoST server for use by PAWS devices, correct? Would it then make sense to implement it with JSON, even though the standard as written uses XML?

Maybe somebody should take a look at the XML messages described in the LoST protocol, to determine how easy it will or will not be to convert them to JSON.

Maybe we should just forget about using LoST, and go with the only discovery proposal that has been formally submitted to PAWS?

Don

From: Rosen, Brian [mailto:[e-mail]]
Sent: Monday, August 27, 2012 10:31 AM
To: [e-mail]
Cc: Don Joslyn; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

<as individual>
You are correct, there is no consensus on discovery.

However, this is the argument I am strongly against - we choose JSON, and then reject LoST because it's not defined with a JSON transport.

I'm against the other side also - we can't have JSON because LoST is XML.  These are independent decisions.  It's possible to do a JSON encoding of LoST.

Brian

On Aug 27, 2012, at 10:14 AM, [e-mail]<mailto:[e-mail]> wrote:



Hi Don,

If the DB discovery follows the approach recommended in  : draft-probasco-paws-discovery,
then you could simply use JSON for the encoding and thereby harmonize the encoding approach for discovery and the query (PAWS) protocol.

I do not believe there is an agreement that DB discovery is done using LoST at this time.

-Raj

From: ext Don Joslyn <[e-mail]<mailto:[e-mail]>>
Date: Monday, August 27, 2012 8:15 AM
To: Basavaraj Patil <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Gabor Bajko <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [paws] XML schema versus JSON, vCard & iCal

Raj,

If LoST requires XML and PAWS requires JSON, wouldn't that mean the master device would need to support both XML and JSON?

Don

From: Don Joslyn
Sent: Saturday, August 25, 2012 8:41 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

If we decide to use LoST for discovery does it require the use of XML in the message format?

Sent from my Verizon Wireless 4G LTE DROID RAZR


[e-mail]<mailto:[e-mail]> wrote:

Pete,

We have not made a decision on whether we will use LoST in the context of
database discovery at this time. It is an option no doubt. I am more
focused on the actual query/response protocol w.r.t the encoding
discussion.
Database discovery can be a separate aspect from the actual
device-2-database protocol and hence the aspect of JSON in the context of
LoST should not even arise.

My view is that having a single mandatory encoding scheme (in this case
JSON) for the device-2-database protocol would ensure interoperability.

-Raj

On 8/24/12 4:11 PM, "ext Peter McCann" <[e-mail]<mailto:[e-mail]>> wrote:

>I think you are mis-representing Brian's point of view.  I share his
>concern about re-inventing encodings for LoST/xCard.
>
>-Pete
>
>
>[e-mail]<mailto:[e-mail]> wrote:
>>
>> +1 to Brian's view on using JSON only.
>>
>> From: "<ext Rosen>", "[e-mail]<mailto:[e-mail]>"
>> <[e-mail]<mailto:[e-mail]>>
>> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko
>> <[e-mail]<mailto:[e-mail]>> Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> Subject: Re:
>> [paws] XML schema versus JSON, vCard & iCal
>>
>>
>> The problem we face with JSON only is the LoST/xCard/... issue.  As
>> long as there is no objection to creating JSON encodings of existing
>> standards in order to use JSON, and no one uses the fact that these
>> encodings don't exist as a reason to roll our own equivalents, I am
>> okay with JSON only.
>>
>> Brian
>>
>> On Aug 24, 2012, at 3:08 PM, [e-mail]<mailto:[e-mail]> wrote:
>>
>>
>>       WiFi world builds on mandating the implementation (and
>> certification) of a base spec, and a set of optional features. If an
>> optional feature is not supported by one of the peers, they can still
>> talk, but not use that feature. That is basically option B) from
>> Brain's list.
>>
>>       I'd like to suggest that we recognize that option A) and B) are valid
>> options, while option C) is invalid, and we should stop debating it.
>>       I'd also like to add the obvious option D) to the list, which is that
>> both the master devices and DBs support one and the same encoding ;)
>>
>>       Option A) seems to be like a good compromise, and would cut
>> discussions short, with the only caveat that if there is no strong
>> technical argument for supporting and specifying two different
>> encodings, then the iesg may send the document back to the wg to pick
>> one of the two specified. As Robert mentioned in his email, this has
>> happened in the past, so it is likely it would happen again. And
>> frankly, I do not see a strong argument in favor of two different
>>encodings.
>>
>>       Is there anyone who has a technical argument against supporting only
>> one encoding, being that either xml or json?
>>
>>       Most people speak in favor of JSON, because it is compact and more
>> efficient. I went through this thread and I saw 2 objections against
>> picking JSON. One said that JSON requires native Java, which is wrong,
>> the other objection gave no real reason. So I am wondering if there is
>> really any valid technical reason against using JSON only?
>>
>>       -          Gabor
>>
>>
>>       From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf
>> Of ext Rosen, Brian
>>       Sent: Friday, August 24, 2012 10:43 AM
>>       To: Benjamin A. Rolfe
>>       Cc: [e-mail]<mailto:[e-mail]>
>>       Subject: Re: [paws] XML schema versus JSON, vCard & iCal
>>
>>       Okay:
>>
>>       So, I implement a database, and I implement XML
>>       You implement a device, and you implement JSON
>>
>>       You query my database (let's not get into how you do that query
>> without deciding XML vs JSON) and discover I implement XML only
>>
>>       What do you do?
>>
>>       Brian
>>
>>       On Aug 24, 2012, at 1:38 PM, "Benjamin A. Rolfe"
>> <[e-mail]<mailto:[e-mail]>> wrote:
>>
>>
>>
>>
>>       There are two ways to achieve interoperability when you have an option.
>>       There are many existence proofs of the third way that I mentioned
>> below.        802.11 + WiFi provide many options and a means for devices to
>> share information about what options each supports, without requiring
>> that any device implement every option.  It works.
>>
>>       That said, I think (A) is the best choice, (B) is not as nice for me,
>> and (C) is more work than either of the other two.
>>
>>
>>
>>
>>       One is that one end implements both choices and the other end
>> implements one or both.
>>
>>       The other is that both ends implement one specific choice ("MUST
>> implement") and both can optionally implement the other choice.  Only
>> if both ends implement the other choice would that be available.
>>
>>       So, in this case we could do one of the following:
>>       A) Databases implement both XML and JSON, devices implement either
>>       B) Both Databases and devices implement one (say XML) and optionally
>> implement the other (say JSON)
>>
>>       You are advocating for A, Richard was suggesting B.
>>
>>       I don't care, but choice C) Both databases and devices have a choice
>> of what to implement doesn't work for me (or Richard).
>>
>>       Brian
>>
>>       On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe <[e-mail]<mailto:[e-mail]>>
>> wrote:
>>
>>
>>       Apparently I was unclear.  I certainly an capable of being wrong as I
>> practice often, but in this case it is quite unlikely :-).
>>
>>       You do not need to choose only one form to achieve
>> interoperability.   If you have two, let the device implementer figure
>> out which is best for their particular device requirements and trade-
>> offs.  This is *preferable* from my perspective.
>>
>>       If you provide more than one form in the database, devices using the
>> database need some means for figuring out which are available. It
>> can't use it if it doesn't no about it. This is an observations, not
>> an argument ;-).
>>
>>       It is my *opinion* at the  moment that if you provide options, to
>> make those useful you need to provide  a protocol by which devices can
>> discover what options the database supports.  If you have such a
>> mechanism and all devices use it (a  bootstrap protocol), everything
>> else could be options.  This requires additional functions in both
>> database and device implementations.
>>       If on the other hand the device can "just know" that the database has
>> two forms available, it won't need to dynamically figure it out.
>> The device implementer has options and simplicity, so I like it.
>>
>>       Since I am focused on the TVWS devices that need access to the
>> database, and not a database implementer, shifting burden onto the
>> database implementer (not me) to reduce the burden on the device
>> implementer (me) is preferred from my perspective.  The database
>> implementer may have another perspective.  Should I point out that
>> there will be a lot more devices than databases?  That might sound
>> like an argument, though, so I won't....:-j
>>
>>       Ben
>>
>>
>>
>>       Brian is right .. sorry but the rest of you are wrong. J
>>
>>       This is why you have MUST and SHOULD in RFC 2119.
>>
>>       This BTW is a classic argument in IETF terms .. but the argument "let
>> the market decide" only holds so much validity.  You actually have to
>> choose SOMETHING to create a baseline of interoperability.
>>
>>       A virtually identical argument  is now playing out in discussions of
>> mandatory audio and codec implementations for WEBRTC like things.
>>
>>       IMHO XML MUST anything else defined SHOULD, but MUST on XML and JSON
>> could work as well. It just leads to a level of complexity in
>> implementations.
>>
>>       End of argument you now can go back to your regularly schedule
>> programming. J
>>
>>
>>       From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf
>> Of [e-mail]<mailto:[e-mail]>
>>       Sent: Thursday, August 23, 2012 5:44 PM
>>       To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
>>       Cc: [e-mail]<mailto:[e-mail]>
>>       Subject: Re: [paws] XML schema versus JSON, vCard & iCal
>>
>>
>>       I agree with Brian.
>>       There needs to be a default mandatory to implement option in order to
>> achieve interoperability.
>>       And this applies to the device and database side of the protocol.
>>
>>       -Raj
>>
>>       From: "<ext Rosen>", "[e-mail]<mailto:[e-mail]>"
>> <[e-mail]<mailto:[e-mail]>>     Date: Thursday, August 23, 2012 2:43 PM  To:
>> Don Joslyn <[e-mail]<mailto:[e-mail]>>      Cc: "[e-mail]<mailto:[e-mail]>"
>> <[e-mail]<mailto:[e-mail]>>       Subject: Re: [paws] XML schema versus JSON, vCard &
>>iCal
>>
>>       One of my favorite IETF expressions is "There are no protocol
>> police".  We apply that in lots of ways, but one of them is that if
>> you don't implement what the document says, you may not get
>> interoperability with other implementations.  On the other hand, the
>> whole point of a protocol document like ours is that two independent
>> implementations who both follow the document will interwork.  If that
>> wasn't true, why do you need a standard?
>>
>>       If you say "either" to both ends, then you don't get interoperability.
>>
>>       By your argument, we should stop working, and the product managers
>> will figure it out using proprietary protocols.  The market will decide.
>>
>>       So, I feel strongly that if one end is "either", the other end must
>> be "both".  It's also acceptable to say both ends implement one choice
>> and the other is optional at both ends.  Here, I think it's server
>> does both and client does either.
>>
>>       It's always possible to build an implementation of a server that only
>> does one: there are no protocol police.
>>
>>       Brian <as individual>
>>
>>
>>
>>
>>       On Aug 23, 2012, at 3:11 PM, Don Joslyn <[e-mail]<mailto:[e-mail]>>
>> wrote:
>>
>>
>>
>>
>>       Hi Ben,  That was my original suggestion, and I still think it makes
>> the most sense.       Thanks for supporting the proposal.      Don
>>
>>       From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf
>> Of Benjamin A. Rolfe
>>       Sent: Thursday, August 23, 2012 3:05 PM
>>       To: [e-mail]<mailto:[e-mail]>
>>       Subject: Re: [paws] XML schema versus JSON, vCard & iCal
>>
>>       Someone suggested that PAWS define both, and let the vendors decide
>> which ones to implement.
>>       That makes the most sense for both DB and device vendors.
>> Markets will probably drive DB vendors to do both. Device vendors will
>> do what fits the market segment they're after. Why over-constrain (or
>> argue when natural selection will take care of it for us?).
>>       B
>>
>>
>>
>>
>>       Sounds good to me.
>>
>>       From: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> [mailto:[e-mail] <mailto:[e-mail]> ] On
>> Behalf Of [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>>       Sent: Tuesday, August 21, 2012 12:42 AM
>>       To: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>>       Subject: Re: [paws] XML schema versus JSON, vCard & iCal
>>
>>       Now I can't see anymore any willingness to agree on one or the other
>> encoding.     To prevent endless discussions on this topic I'd suggest we
>> move forward with supporting both in the DB and either one in the master
>> device.       Any objections?
>>
>>       Gabor
>>
>>
>>       From: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> [mailto:[e-mail] <mailto:[e-mail]> ] On
>> Behalf Of ext Das, Subir
>>       Sent: Monday, August 20, 2012 2:50 PM
>>       To: Don Joslyn; Vincent Chen; Weixinpeng
>>       Cc: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]> ; Manikkoth Sajeev
>>       Subject: Re: [paws] XML schema versus JSON, vCard & iCal
>>
>>       We have a half a dozen or more TVDB radio vendors that use/prefer
>> JSON and we will vote for JSON if we had to pick one.
>>       Also I will copy the following two important points:
>>
>>
>>               *       Simple-to-use libraries exist for all major languages/platforms
>>               *       Don't need a tool chain to work with the data, as is typically
>> needed for XML
>>
>>
>>
>>
>>       From: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> [mailto:[e-mail]] <mailto:[mailto:[e-mail]]>
>> On Behalf Of Don Joslyn
>>       Sent: Monday, August 20, 2012 4:54 PM
>>       To: Vincent Chen; Weixinpeng
>>       Cc: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]> ; Manikkoth Sajeev
>>       Subject: Re: [paws] XML schema versus JSON, vCard & iCal
>>
>>       Please see my comments below...
>>       Thanks,
>>       Don
>>
>>       From: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> [mailto:[e-mail] <mailto:[e-mail]> ] On
>> Behalf Of Vincent Chen
>>       Sent: Monday, August 20, 2012 2:56 PM
>>       To: Weixinpeng
>>       Cc: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]> ; Manikkoth Sajeev
>>       Subject: Re: [paws] XML schema versus JSON, vCard & iCal
>>
>>
>>       *       One of our goals is to strive to lower the cost and
>> complexity for device manufacturers. This lowers the barrier for
>> building a robust ecosystem.
>>
>>       [DJ - The "cost" and complexity of using XML has not been an issue
>> for the half dozen TVBD vendors that have already used XML. Maybe we
>> need to better define "cost"?]
>>
>>       *       To reduce complexity and cost for device makers, supporting
>> 1 encoding is better than both, as Brian points out. WiFi access
>> points that "just work" anywhere in the world serves as a good model.
>>
>>       [DJ - I proposed that the databases support both XML and JSON,
>> devices only need to support one to talk to the database. Our current
>> database supports XML and JSON, but if I'm forced to pick only one,
>> then I will vote for XML because it's the one that we currently use on
>> all embedded devices.]
>>
>>       *       There's a trend for APIs on the web towards JSON (Twitter,
>> FourSquare, Facebook, Google, etc.). One of the major reasons is that
>> developers (client-side) prefer it for its simplicity:
>>
>>               *       Representation closely matches most data models (nested lists and
>> maps)                 *       Simple-to-use libraries exist for all major
>> languages/platforms           *       Don't need a tool chain to work with the data,
>> as is typically needed for XML.
>>
>>       Apparently, the efficiency gains of JSON also matter to the
>> scalability of serving systems.
>>
>>
>>       [DJ - I can't argue against these listed pros for JSON, especially
>> when you're dealing with a lot of data (like Twitter, FourSquare,
>> Facebook and Google does). But I'm assuming that PAWS messages will
>> not be exchanged nearly as often as the applications mentioned above.
>> But again, I know JSON is more efficient, can't argue with that.]
>>
>>       *       At the end of the day, it's the data model that matters,
>> rather than the encoding. We (Google) are actually neutral on XML vs
>> JSON, as long as we're clear on what device makers want. It would be
>> good to get feedback from device makers (especially of embedded
>> devices) regarding experiences supporting XML vs JSON.
>>
>>
>>
>>       Don, can you elaborate on the types of devices that already support
>>XML?
>>
>>
>>
>>       [DJ - We currently support half a dozen TVDB radio vendors (embedded
>> devices) using XML, non using JSON. XML has not been a burden, and the
>> amount of data that needs to be exchanged between device and database
>> is not that much or exchanged that often.]
>>
>>       On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng <[e-mail]
<mailto:[e-mail]%0b>>> <mailto:[e-mail]> > wrote:       Considering of the design of
>> database discovery protocol, the LoST protocol may be used and LoST is
>> based on XML, so I think XML may be preferred.
>>
>>       --Xinpeng Wei
>>
>>       From: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> [mailto:[e-mail] <mailto:[e-mail]> ] On
>> Behalf Of Rosen, Brian
>>
>>       Sent: Friday, August 17, 2012 9:26 PM    To: Manikkoth Sajeev;
>> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]> ;
>> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]> ; [e-mail]<mailto:[e-mail]>
>> <mailto:[e-mail]>
>>
>>       Cc: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>>       Subject: Re: [paws] XML schema versus JSON, vCard & iCal
>>
>>       I don't really care whether we use json or xml as a matter of
>> protocol design or implementation, but I am a big fan of reusing
>> standards rather than defining new ones, and I would not want to see
>> the choice of json mean we then decide to roll our own versus using
>> existing standards based on the idea there is no json representation
>> of an existing standard.  So, if choosing json means folks feel free
>> to ignore existing xml based standards such as xCard and LoST, then I
>> would not want to use json.
>>
>>       I would prefer to not have "both", because of interoperability
>> complications.  If there is rough consensus for both, then I would
>> assert that all servers have to implement both and the client can
>> implement either.
>>
>>       There are json validators, so I don't think that is a big deal.
>>
>>       My experience in protocol design on the Internet is that decisions
>> made solely or even largely because of compactness advantages rarely
>> are good choices.  If you like json because it is smaller, then I
>> believe you need a much better reason.  Binary doesn't work for me, at
>> all.  I have been involved in big binary vs text wars in protocol
>> design.  Text wins, binary loses, in my opinion.
>>
>>       Brian <as individual>
>>
>>       From: Manikkoth Sajeev <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]> >
>>       Reply-To: Manikkoth Sajeev <[e-mail]
<mailto:[e-mail]%0b>>> <mailto:[e-mail]> >
>>       Date: Thu, 16 Aug 2012 22:37:38 -0400
>>       To: "[e-mail]<mailto:[e-mail]> <mailto:[e-mail]> "
>> <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]> >, "Rosen, Brian"
>> <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]> >,
>> "[e-mail]<mailto:[e-mail]> <mailto:[e-mail]> " <[e-mail]
<mailto:[e-mail]%0b>>> <mailto:[e-mail]> >, "[e-mail]<mailto:[e-mail]>
>> <mailto:[e-mail]> " <[e-mail]
<mailto:[e-mail]%0b>>> <mailto:[e-mail]> >
>>       Cc: "[e-mail]<mailto:[e-mail]> <mailto:[e-mail]> " <[e-mail]
<mailto:[e-mail]%0b>>> <mailto:[e-mail]> >
>>       Subject: Re: [paws] XML schema versus JSON, vCard & iCal
>>
>>       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
>> optioncan 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: [phone] <tel:%2B918792292002>      Email:
>> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>>       http://www.linkedin.com/in/mksajeev
>> <http://www.linkedin.com/in/mksajeev>
>>
>>
>>       From: "[e-mail]<mailto:[e-mail]> <mailto:[e-mail]> "
>> <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]> >       To:
>> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]> ;
>> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]> ; [e-mail]<mailto:[e-mail]>
>> <mailto:[e-mail]>     Cc: [e-mail]<mailto:[e-mail]>
>> <mailto:[e-mail]>        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: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> [mailto:[e-mail] <mailto:[e-mail]> ] On
>> Behalf Of ext Rosen, Brian
>>       Sent: Monday, August 13, 2012 3:14 PM
>>       To: 'Vincent Chen'; 'Peter Stanforth'
>>       Cc: '[e-mail]<mailto:'[e-mail]> <mailto:[e-mail]> '
>>       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:[e-mail] <mailto:[e-mail]> ]  Sent:    Monday,
>> August 13, 2012 06:04 PM Eastern Standard Time        To:    Peter Stanforth
>>       Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [e-mail]<mailto:[e-mail]>
>> <mailto:[e-mail]>        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/ <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
>> <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]> > 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"
>>
>>           <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]> > 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:[e-mail]
>> <mailto:[e-mail]> ]       >Sent:  Saturday, August 11,
>> 2012 07:13 AM Eastern Standard Time       >To:    Teco Boot; Benjamin
>> A.Rolfe           >Cc:    [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>      >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" <teco@inf- net.nl<http://net.nl> <mailto:[e-mail]> > 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
>> <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
>> <http://tools.ietf.org/html/rfc3280#section-4.1.2.5>      >>>>      >>>>
>> Teco      >>>> _______________________________________________      >>>>
>> paws mailing list         >>>> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> >>>> https://www.ietf.org/mailman/listinfo/paws
>> <https://www.ietf.org/mailman/listinfo/paws>      >>>>      >>>       >>>
>> _______________________________________________           >>> paws mailing
>> list      >>> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>          >>>
>> https://www.ietf.org/mailman/listinfo/paws
>> <https://www.ietf.org/mailman/listinfo/paws>      >>
>> >>_______________________________________________         >>paws mailing
>> list      >>[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> >>https://www.ietf.org/mailman/listinfo/paws
>> <https://www.ietf.org/mailman/listinfo/paws>      >
>> >_______________________________________________          >paws mailing list
>>           >[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> >https://www.ietf.org/mailman/listinfo/paws
>> <https://www.ietf.org/mailman/listinfo/paws>
>>
>>           _______________________________________________           paws mailing
>

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