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

[<[e-mail]>]

Agree.

-Raj

From: "<ext Rosen>", "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Monday, August 27, 2012 9:30 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

<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