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" <[email protected]> wrote: >I think you are mis-representing Brian's point of view. I share his >concern about re-inventing encodings for LoST/xCard. > >-Pete > > >[email protected] wrote: >> >> +1 to Brian's view on using JSON only. >> >> From: "<ext Rosen>", "[email protected]" >> <[email protected]> >> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko >> <[email protected]> Cc: "[email protected]" <[email protected]> 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, [email protected] 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: [email protected] [mailto:[email protected]] On Behalf >> Of ext Rosen, Brian >> Sent: Friday, August 24, 2012 10:43 AM >> To: Benjamin A. Rolfe >> Cc: [email protected] >> 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" >> <[email protected]> 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 <[email protected]> >> 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: [email protected] [mailto:[email protected]] On Behalf >> Of [email protected] >> Sent: Thursday, August 23, 2012 5:44 PM >> To: [email protected]; [email protected] >> Cc: [email protected] >> 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>", "[email protected]" >> <[email protected]> Date: Thursday, August 23, 2012 2:43 PM >> To: >> Don Joslyn <[email protected]> Cc: "[email protected]" >> <[email protected]> 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 <[email protected]> >> wrote: >> >> >> >> >> Hi Ben, That was my original suggestion, and I still think it >> makes >> the most sense. Thanks for supporting the proposal. Don >> >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Benjamin A. Rolfe >> Sent: Thursday, August 23, 2012 3:05 PM >> To: [email protected] >> 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: [email protected] <mailto:[email protected]> >> [mailto:[email protected] <mailto:[email protected]> ] On >> Behalf Of [email protected] <mailto:[email protected]> >> Sent: Tuesday, August 21, 2012 12:42 AM >> To: [email protected] <mailto:[email protected]> >> 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: [email protected] <mailto:[email protected]> >> [mailto:[email protected] <mailto:[email protected]> ] On >> Behalf Of ext Das, Subir >> Sent: Monday, August 20, 2012 2:50 PM >> To: Don Joslyn; Vincent Chen; Weixinpeng >> Cc: [email protected] <mailto:[email protected]> ; 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: [email protected] <mailto:[email protected]> >> [mailto:[email protected]] <mailto:[mailto:[email protected]]> >> On Behalf Of Don Joslyn >> Sent: Monday, August 20, 2012 4:54 PM >> To: Vincent Chen; Weixinpeng >> Cc: [email protected] <mailto:[email protected]> ; Manikkoth Sajeev >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >> >> Please see my comments below... >> Thanks, >> Don >> >> From: [email protected] <mailto:[email protected]> >> [mailto:[email protected] <mailto:[email protected]> ] On >> Behalf Of Vincent Chen >> Sent: Monday, August 20, 2012 2:56 PM >> To: Weixinpeng >> Cc: [email protected] <mailto:[email protected]> ; 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 <[email protected] >> <mailto:[email protected]> > 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: [email protected] <mailto:[email protected]> >> [mailto:[email protected] <mailto:[email protected]> ] On >> Behalf Of Rosen, Brian >> >> Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; >> [email protected] <mailto:[email protected]> ; >> [email protected] <mailto:[email protected]> ; [email protected] >> <mailto:[email protected]> >> >> Cc: [email protected] <mailto:[email protected]> >> 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 <[email protected] <mailto:[email protected]> > >> Reply-To: Manikkoth Sajeev <[email protected] >> <mailto:[email protected]> > >> Date: Thu, 16 Aug 2012 22:37:38 -0400 >> To: "[email protected] <mailto:[email protected]> " >> <[email protected] <mailto:[email protected]> >, "Rosen, Brian" >> <[email protected] <mailto:[email protected]> >, >> "[email protected] <mailto:[email protected]> " <[email protected] >> <mailto:[email protected]> >, "[email protected] >> <mailto:[email protected]> " <[email protected] >> <mailto:[email protected]> > >> Cc: "[email protected] <mailto:[email protected]> " <[email protected] >> <mailto:[email protected]> > >> 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: +918792292002 <tel:%2B918792292002> >> Email: >> [email protected] <mailto:[email protected]> >> http://www.linkedin.com/in/mksajeev >> <http://www.linkedin.com/in/mksajeev> >> >> >> From: "[email protected] <mailto:[email protected]> " >> <[email protected] <mailto:[email protected]> > To: >> [email protected] <mailto:[email protected]> ; >> [email protected] <mailto:[email protected]> ; [email protected] >> <mailto:[email protected]> Cc: [email protected] >> <mailto:[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]> >> [mailto:[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] <mailto:[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] <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] >> <mailto:[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/ <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] <mailto:[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] <mailto:[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] >> <mailto:[email protected]> ] >Sent: Saturday, August 11, >> 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin >> A.Rolfe >Cc: [email protected] <mailto:[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" <teco@inf- net.nl <mailto:[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 >> <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 >>>> [email protected] <mailto:[email protected]> >> >>>> https://www.ietf.org/mailman/listinfo/paws >> <https://www.ietf.org/mailman/listinfo/paws> >>>> >>> >> >>> >> _______________________________________________ >>> paws mailing >> list >>> [email protected] <mailto:[email protected]> >>> >> https://www.ietf.org/mailman/listinfo/paws >> <https://www.ietf.org/mailman/listinfo/paws> >> >> >>_______________________________________________ >>paws mailing >> list >>[email protected] <mailto:[email protected]> >> >>https://www.ietf.org/mailman/listinfo/paws >> <https://www.ietf.org/mailman/listinfo/paws> > >> >_______________________________________________ >paws mailing list >> >[email protected] <mailto:[email protected]> >> >https://www.ietf.org/mailman/listinfo/paws >> <https://www.ietf.org/mailman/listinfo/paws> >> >> _______________________________________________ paws mailing > _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
