Re: [paws] XML schema versus JSON, vCard & iCal
"Rosen, Brian" <Brian.Rosen@neustar.biz> Mon, 27 August 2012 14:30 UTC
Return-Path: <brian.rosen@neustar.biz>
X-Original-To: paws@ietfa.amsl.com
Delivered-To: paws@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8DA21F8647 for <paws@ietfa.amsl.com>; Mon, 27 Aug 2012 07:30:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.049
X-Spam-Level:
X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2pwUxLIkedP for <paws@ietfa.amsl.com>; Mon, 27 Aug 2012 07:30:44 -0700 (PDT)
Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id E005121F8645 for <paws@ietf.org>; Mon, 27 Aug 2012 07:30:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1346077760; x=1661418501; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=5KyJJtuVfP87w93IPJ07idbKRV1oZ/5LFVPdQzX/bVI=; b=idSU7Zs9bVWTFdWhQ6rUcCoLxvuOJ1JVkWhXiA15WvxSz/1h3ROH8zSptLg5M2 Zp5IIwqq49XO31mvpZyK96lQ==
Received: from ([10.31.13.228]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.8659781; Mon, 27 Aug 2012 10:29:19 -0400
Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Mon, 27 Aug 2012 10:30:34 -0400
From: "Rosen, Brian" <Brian.Rosen@neustar.biz>
To: "basavaraj.patil@nokia.com" <basavaraj.patil@nokia.com>
Date: Mon, 27 Aug 2012 10:30:33 -0400
Thread-Topic: [paws] XML schema versus JSON, vCard & iCal
Thread-Index: Ac2EYITIHTSDIDfBQGOLNBKA/lgn9Q==
Message-ID: <A224436C-AA23-4E38-8387-3047ACA1D087@neustar.biz>
References: <CC60E9CF.22976%basavaraj.patil@nokia.com>
In-Reply-To: <CC60E9CF.22976%basavaraj.patil@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA==
x-ems-stamp: jEHF7+wRLPHgFRHkuE7vxw==
Content-Type: multipart/alternative; boundary="_000_A224436CAA234E3883873047ACA1D087neustarbiz_"
MIME-Version: 1.0
Cc: "paws@ietf.org" <paws@ietf.org>, "Peter.McCann@huawei.com" <Peter.McCann@huawei.com>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal
X-BeenThere: paws@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Protocol to Access White Space database \(PAWS\)" <paws.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/paws>, <mailto:paws-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/paws>
List-Post: <mailto:paws@ietf.org>
List-Help: <mailto:paws-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/paws>, <mailto:paws-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Aug 2012 14:30:48 -0000
<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, basavaraj.patil@nokia.com<mailto:basavaraj.patil@nokia.com> 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 <d.joslyn@spectrumbridge.com<mailto:d.joslyn@spectrumbridge.com>> Date: Monday, August 27, 2012 8:15 AM To: Basavaraj Patil <basavaraj.patil@nokia.com<mailto:basavaraj.patil@nokia.com>> Cc: "Peter.McCann@huawei.com<mailto:Peter.McCann@huawei.com>" <Peter.McCann@huawei.com<mailto:Peter.McCann@huawei.com>>, "Brian.Rosen@neustar.biz<mailto:Brian.Rosen@neustar.biz>" <Brian.Rosen@neustar.biz<mailto:Brian.Rosen@neustar.biz>>, Gabor Bajko <gabor.bajko@nokia.com<mailto:gabor.bajko@nokia.com>>, "paws@ietf.org<mailto:paws@ietf.org>" <paws@ietf.org<mailto:paws@ietf.org>> 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: Basavaraj.Patil@nokia.com<mailto:Basavaraj.Patil@nokia.com> Cc: Peter.McCann@huawei.com<mailto:Peter.McCann@huawei.com>; Brian.Rosen@neustar.biz<mailto:Brian.Rosen@neustar.biz>; Gabor.Bajko@nokia.com<mailto:Gabor.Bajko@nokia.com>; paws@ietf.org<mailto:paws@ietf.org> 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 Basavaraj.Patil@nokia.com<mailto:Basavaraj.Patil@nokia.com> 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" <Peter.McCann@huawei.com<mailto:Peter.McCann@huawei.com>> wrote: >I think you are mis-representing Brian's point of view. I share his >concern about re-inventing encodings for LoST/xCard. > >-Pete > > >Basavaraj.Patil@nokia.com<mailto:Basavaraj.Patil@nokia.com> wrote: >> >> +1 to Brian's view on using JSON only. >> >> From: "<ext Rosen>", "Brian.Rosen@neustar.biz<mailto:Brian.Rosen@neustar.biz>" >> <Brian.Rosen@neustar.biz<mailto:Brian.Rosen@neustar.biz>> >> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko >> <gabor.bajko@nokia.com<mailto:gabor.bajko@nokia.com>> Cc: "paws@ietf.org<mailto:paws@ietf.org>" <paws@ietf.org<mailto:paws@ietf.org>> 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, Gabor.Bajko@nokia.com<mailto:Gabor.Bajko@nokia.com> 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: paws-bounces@ietf.org<mailto:paws-bounces@ietf.org> [mailto:paws-bounces@ietf.org] On Behalf >> Of ext Rosen, Brian >> Sent: Friday, August 24, 2012 10:43 AM >> To: Benjamin A. Rolfe >> Cc: paws@ietf.org<mailto:paws@ietf.org> >> 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" >> <ben@blindcreek.com<mailto:ben@blindcreek.com>> 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 <ben@blindcreek.com<mailto:ben@blindcreek.com>> >> 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: paws-bounces@ietf.org<mailto:paws-bounces@ietf.org> [mailto:paws-bounces@ietf.org] On Behalf >> Of Basavaraj.Patil@nokia.com<mailto:Basavaraj.Patil@nokia.com> >> Sent: Thursday, August 23, 2012 5:44 PM >> To: Brian.Rosen@neustar.biz<mailto:Brian.Rosen@neustar.biz>; d.joslyn@spectrumbridge.com<mailto:d.joslyn@spectrumbridge.com> >> Cc: paws@ietf.org<mailto:paws@ietf.org> >> 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>", "Brian.Rosen@neustar.biz<mailto:Brian.Rosen@neustar.biz>" >> <Brian.Rosen@neustar.biz<mailto:Brian.Rosen@neustar.biz>> Date: Thursday, August 23, 2012 2:43 PM To: >> Don Joslyn <d.joslyn@spectrumbridge.com<mailto:d.joslyn@spectrumbridge.com>> Cc: "paws@ietf.org<mailto:paws@ietf.org>" >> <paws@ietf.org<mailto:paws@ietf.org>> 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 <d.joslyn@spectrumbridge.com<mailto:d.joslyn@spectrumbridge.com>> >> wrote: >> >> >> >> >> Hi Ben, That was my original suggestion, and I still think it makes >> the most sense. Thanks for supporting the proposal. Don >> >> From: paws-bounces@ietf.org<mailto:paws-bounces@ietf.org> [mailto:paws-bounces@ietf.org] On Behalf >> Of Benjamin A. Rolfe >> Sent: Thursday, August 23, 2012 3:05 PM >> To: paws@ietf.org<mailto:paws@ietf.org> >> 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: paws-bounces@ietf.org<mailto:paws-bounces@ietf.org> <mailto:paws-bounces@ietf.org> >> [mailto:paws-bounces@ietf.org <mailto:paws-bounces@ietf.org> ] On >> Behalf Of Gabor.Bajko@nokia.com<mailto:Gabor.Bajko@nokia.com> <mailto:Gabor.Bajko@nokia.com> >> Sent: Tuesday, August 21, 2012 12:42 AM >> To: paws@ietf.org<mailto:paws@ietf.org> <mailto:paws@ietf.org> >> 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: paws-bounces@ietf.org<mailto:paws-bounces@ietf.org> <mailto:paws-bounces@ietf.org> >> [mailto:paws-bounces@ietf.org <mailto:paws-bounces@ietf.org> ] On >> Behalf Of ext Das, Subir >> Sent: Monday, August 20, 2012 2:50 PM >> To: Don Joslyn; Vincent Chen; Weixinpeng >> Cc: paws@ietf.org<mailto:paws@ietf.org> <mailto:paws@ietf.org> ; 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: paws-bounces@ietf.org<mailto:paws-bounces@ietf.org> <mailto:paws-bounces@ietf.org> >> [mailto:paws-bounces@ietf.org] <mailto:[mailto:paws-bounces@ietf.org]> >> On Behalf Of Don Joslyn >> Sent: Monday, August 20, 2012 4:54 PM >> To: Vincent Chen; Weixinpeng >> Cc: paws@ietf.org<mailto:paws@ietf.org> <mailto:paws@ietf.org> ; Manikkoth Sajeev >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >> >> Please see my comments below... >> Thanks, >> Don >> >> From: paws-bounces@ietf.org<mailto:paws-bounces@ietf.org> <mailto:paws-bounces@ietf.org> >> [mailto:paws-bounces@ietf.org <mailto:paws-bounces@ietf.org> ] On >> Behalf Of Vincent Chen >> Sent: Monday, August 20, 2012 2:56 PM >> To: Weixinpeng >> Cc: paws@ietf.org<mailto:paws@ietf.org> <mailto:paws@ietf.org> ; 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 <weixinpeng@huawei.com <mailto:weixinpeng@huawei.com%0b>>> <mailto:weixinpeng@huawei.com> > 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: paws-bounces@ietf.org<mailto:paws-bounces@ietf.org> <mailto:paws-bounces@ietf.org> >> [mailto:paws-bounces@ietf.org <mailto:paws-bounces@ietf.org> ] On >> Behalf Of Rosen, Brian >> >> Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; >> gabor.bajko@nokia.com<mailto:gabor.bajko@nokia.com> <mailto:gabor.bajko@nokia.com> ; >> vchen@google.com<mailto:vchen@google.com> <mailto:vchen@google.com> ; peter@spectrumbridge.com<mailto:peter@spectrumbridge.com> >> <mailto:peter@spectrumbridge.com> >> >> Cc: paws@ietf.org<mailto:paws@ietf.org> <mailto:paws@ietf.org> >> 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 <mksaji@yahoo.com<mailto:mksaji@yahoo.com> <mailto:mksaji@yahoo.com> > >> Reply-To: Manikkoth Sajeev <mksaji@yahoo.com <mailto:mksaji@yahoo.com%0b>>> <mailto:mksaji@yahoo.com> > >> Date: Thu, 16 Aug 2012 22:37:38 -0400 >> To: "Gabor.Bajko@nokia.com<mailto:Gabor.Bajko@nokia.com> <mailto:Gabor.Bajko@nokia.com> " >> <Gabor.Bajko@nokia.com<mailto:Gabor.Bajko@nokia.com> <mailto:Gabor.Bajko@nokia.com> >, "Rosen, Brian" >> <brian.rosen@neustar.biz<mailto:brian.rosen@neustar.biz> <mailto:brian.rosen@neustar.biz> >, >> "vchen@google.com<mailto:vchen@google.com> <mailto:vchen@google.com> " <vchen@google.com <mailto:vchen@google.com%0b>>> <mailto:vchen@google.com> >, "peter@spectrumbridge.com<mailto:peter@spectrumbridge.com> >> <mailto:peter@spectrumbridge.com> " <peter@spectrumbridge.com <mailto:peter@spectrumbridge.com%0b>>> <mailto:peter@spectrumbridge.com> > >> Cc: "paws@ietf.org<mailto:paws@ietf.org> <mailto:paws@ietf.org> " <paws@ietf.org <mailto:paws@ietf.org%0b>>> <mailto:paws@ietf.org> > >> 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: >> mksaji@ieee.org<mailto:mksaji@ieee.org> <mailto:mksaji@ieee.org> >> http://www.linkedin.com/in/mksajeev >> <http://www.linkedin.com/in/mksajeev> >> >> >> From: "Gabor.Bajko@nokia.com<mailto:Gabor.Bajko@nokia.com> <mailto:Gabor.Bajko@nokia.com> " >> <Gabor.Bajko@nokia.com<mailto:Gabor.Bajko@nokia.com> <mailto:Gabor.Bajko@nokia.com> > To: >> Brian.Rosen@neustar.biz<mailto:Brian.Rosen@neustar.biz> <mailto:Brian.Rosen@neustar.biz> ; >> vchen@google.com<mailto:vchen@google.com> <mailto:vchen@google.com> ; peter@spectrumbridge.com<mailto:peter@spectrumbridge.com> >> <mailto:peter@spectrumbridge.com> Cc: paws@ietf.org<mailto:paws@ietf.org> >> <mailto:paws@ietf.org> 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: paws-bounces@ietf.org<mailto:paws-bounces@ietf.org> <mailto:paws-bounces@ietf.org> >> [mailto:paws-bounces@ietf.org <mailto:paws-bounces@ietf.org> ] On >> Behalf Of ext Rosen, Brian >> Sent: Monday, August 13, 2012 3:14 PM >> To: 'Vincent Chen'; 'Peter Stanforth' >> Cc: 'paws@ietf.org<mailto:'paws@ietf.org> <mailto:paws@ietf.org> ' >> 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:vchen@google.com <mailto:vchen@google.com> ] Sent: Monday, >> August 13, 2012 06:04 PM Eastern Standard Time To: Peter Stanforth >> Cc: Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org<mailto:paws@ietf.org> >> <mailto:paws@ietf.org> 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 >> <peter@spectrumbridge.com<mailto:peter@spectrumbridge.com> <mailto:peter@spectrumbridge.com> > 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" >> >> <Brian.Rosen@neustar.biz<mailto:Brian.Rosen@neustar.biz> <mailto:Brian.Rosen@neustar.biz> > 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:peter@spectrumbridge.com >> <mailto:peter@spectrumbridge.com> ] >Sent: Saturday, August 11, >> 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin >> A.Rolfe >Cc: paws@ietf.org<mailto:paws@ietf.org> <mailto:paws@ietf.org> >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:teco@inf-net.nl> > 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 >>>> paws@ietf.org<mailto:paws@ietf.org> <mailto:paws@ietf.org> >> >>>> https://www.ietf.org/mailman/listinfo/paws >> <https://www.ietf.org/mailman/listinfo/paws> >>>> >>> >>> >> _______________________________________________ >>> paws mailing >> list >>> paws@ietf.org<mailto:paws@ietf.org> <mailto:paws@ietf.org> >>> >> https://www.ietf.org/mailman/listinfo/paws >> <https://www.ietf.org/mailman/listinfo/paws> >> >> >>_______________________________________________ >>paws mailing >> list >>paws@ietf.org<mailto:paws@ietf.org> <mailto:paws@ietf.org> >> >>https://www.ietf.org/mailman/listinfo/paws >> <https://www.ietf.org/mailman/listinfo/paws> > >> >_______________________________________________ >paws mailing list >> >paws@ietf.org<mailto:paws@ietf.org> <mailto:paws@ietf.org> >> >https://www.ietf.org/mailman/listinfo/paws >> <https://www.ietf.org/mailman/listinfo/paws> >> >> _______________________________________________ paws mailing > _______________________________________________ paws mailing list paws@ietf.org<mailto:paws@ietf.org> https://www.ietf.org/mailman/listinfo/paws
- Re: [paws] XML schema versus JSON, vCard & iCal Rosen, Brian
- [paws] XML schema versus JSON, vCard & iCal Teco Boot
- Re: [paws] XML schema versus JSON, vCard & iCal Gabor.Bajko
- Re: [paws] XML schema versus JSON, vCard & iCal Benjamin A. Rolfe
- Re: [paws] XML schema versus JSON, vCard & iCal Teco Boot
- Re: [paws] XML schema versus JSON, vCard & iCal Peter Stanforth
- Re: [paws] XML schema versus JSON, vCard & iCal Peter Stanforth
- Re: [paws] XML schema versus JSON, vCard & iCal Vincent Chen
- Re: [paws] XML schema versus JSON, vCard & iCal Rosen, Brian
- [paws] YAML -> was -> RE: XML schema versus JSON,… Paul Lambert
- Re: [paws] XML schema versus JSON, vCard & iCal Benjamin A. Rolfe
- Re: [paws] XML schema versus JSON, vCard & iCal Rosen, Brian
- Re: [paws] XML schema versus JSON, vCard & iCal Gabor.Bajko
- Re: [paws] XML schema versus JSON, vCard & iCal Weixinpeng
- Re: [paws] XML schema versus JSON, vCard & iCal Manikkoth Sajeev
- Re: [paws] XML schema versus JSON, vCard & iCal Cuiyang
- Re: [paws] XML schema versus JSON, vCard & iCal Rosen, Brian
- Re: [paws] XML schema versus JSON, vCard & iCal Don Joslyn
- Re: [paws] XML schema versus JSON, vCard & iCal Weixinpeng
- Re: [paws] XML schema versus JSON, vCard & iCal Vincent Chen
- Re: [paws] XML schema versus JSON, vCard & iCal Don Joslyn
- Re: [paws] XML schema versus JSON, vCard & iCal Das, Subir
- Re: [paws] XML schema versus JSON, vCard & iCal Gabor.Bajko
- Re: [paws] XML schema versus JSON, vCard & iCal Don Joslyn
- Re: [paws] XML schema versus JSON, vCard & iCal Benjamin A. Rolfe
- Re: [paws] XML schema versus JSON, vCard & iCal Rosen, Brian
- Re: [paws] XML schema versus JSON, vCard & iCal Don Joslyn
- Re: [paws] XML schema versus JSON, vCard & iCal Rosen, Brian
- Re: [paws] XML schema versus JSON, vCard & iCal Peter McCann
- Re: [paws] XML schema versus JSON, vCard & iCal Robert Smith
- Re: [paws] XML schema versus JSON, vCard & iCal Basavaraj.Patil
- Re: [paws] XML schema versus JSON, vCard & iCal Don Joslyn
- Re: [paws] XML schema versus JSON, vCard & iCal Richard Shockey
- Re: [paws] XML schema versus JSON, vCard & iCal Benjamin A. Rolfe
- Re: [paws] XML schema versus JSON, vCard & iCal Rosen, Brian
- Re: [paws] XML schema versus JSON, vCard & iCal Benjamin A. Rolfe
- Re: [paws] XML schema versus JSON, vCard & iCal Gabor.Bajko
- Re: [paws] XML schema versus JSON, vCard & iCal Rosen, Brian
- Re: [paws] XML schema versus JSON, vCard & iCal Basavaraj.Patil
- Re: [paws] XML schema versus JSON, vCard & iCal Peter McCann
- Re: [paws] XML schema versus JSON, vCard & iCal Gabor.Bajko
- Re: [paws] XML schema versus JSON, vCard & iCal Basavaraj.Patil
- Re: [paws] XML schema versus JSON, vCard & iCal Manikkoth Sajeev
- Re: [paws] XML schema versus JSON, vCard & iCal Vincent Chen
- Re: [paws] XML schema versus JSON, vCard & iCal Cuiyang
- Re: [paws] XML schema versus JSON, vCard & iCal Manikkoth Sajeev
- Re: [paws] XML schema versus JSON, vCard & iCal Don Joslyn
- Re: [paws] XML schema versus JSON, vCard & iCal Das, Subir
- Re: [paws] XML schema versus JSON, vCard & iCal Hannes Tschofenig
- Re: [paws] XML schema versus JSON, vCard & iCal Cuiyang
- Re: [paws] XML schema versus JSON, vCard & iCal Don Joslyn
- Re: [paws] XML schema versus JSON, vCard & iCal Basavaraj.Patil
- Re: [paws] XML schema versus JSON, vCard & iCal Rosen, Brian
- Re: [paws] XML schema versus JSON, vCard & iCal Basavaraj.Patil
- Re: [paws] XML schema versus JSON, vCard & iCal Don Joslyn
- Re: [paws] XML schema versus JSON, vCard & iCal Rosen, Brian
- Re: [paws] XML schema versus JSON, vCard & iCal Benjamin A. Rolfe
- Re: [paws] XML schema versus JSON, vCard & iCal Don Joslyn
- Re: [paws] XML schema versus JSON, vCard & iCal Rosen, Brian
- Re: [paws] XML schema versus JSON, vCard & iCal Paul Lambert