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
