From ietf@meetecho.com Thu Aug 2 10:57:11 2012 Return-Path: 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 3935F11E8072 for ; Thu, 2 Aug 2012 10:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.477 X-Spam-Level: X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ag0xcKYvdoc9 for ; Thu, 2 Aug 2012 10:57:10 -0700 (PDT) Received: from smtplq04.aruba.it (smtplq-out6.aruba.it [62.149.158.26]) by ietfa.amsl.com (Postfix) with SMTP id 871FE21E80C4 for ; Thu, 2 Aug 2012 10:57:09 -0700 (PDT) Received: (qmail 1892 invoked by uid 89); 2 Aug 2012 17:57:07 -0000 Received: from unknown (HELO smtp5.aruba.it) (62.149.158.225) by smtplq04.aruba.it with SMTP; 2 Aug 2012 17:57:07 -0000 Received: (qmail 13289 invoked by uid 89); 2 Aug 2012 17:57:07 -0000 Received: from unknown (HELO ?130.129.21.177?) (alex@meetecho.com@130.129.21.177) by smtp5.ad.aruba.it with ESMTPA; 2 Aug 2012 17:57:07 -0000 Message-ID: <501ABF6C.9070200@meetecho.com> Date: Thu, 02 Aug 2012 19:57:00 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: paws@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Subject: [paws] Meetecho session recording available X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:57:11 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of PAWS session at IETF-84 is available. You can watch it by accessing the following URL: http://ietf84.conf.meetecho.com/index.php/Recorded_Sessions#IETF84_PAWS For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From Gabor.Bajko@nokia.com Wed Aug 8 16:14:05 2012 Return-Path: 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 A063621F854A for ; Wed, 8 Aug 2012 16:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzhauIibUplx for ; Wed, 8 Aug 2012 16:14:05 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id C0D2921F8548 for ; Wed, 8 Aug 2012 16:14:04 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q78NE0td021964 for ; Thu, 9 Aug 2012 02:14:01 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Aug 2012 02:14:56 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0283.004; Thu, 9 Aug 2012 01:13:59 +0200 From: To: Thread-Topic: Vancouver F2F minutes uploaded Thread-Index: Ac11uUrPnjtGYSLVTmKY2j75nBa4Yw== Date: Wed, 8 Aug 2012 23:13:58 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAF96C@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.117.26] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FAF96C008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 08 Aug 2012 23:14:56.0712 (UTC) FILETIME=[9FFD3C80:01CD75BB] X-Nokia-AV: Clean Subject: [paws] Vancouver F2F minutes uploaded X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 23:14:05 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FAF96C008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/proceedings/84/minutes/minutes-84-paws Thanks Pete and Dorothy for the minutes. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FAF96C008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.ietf.org/proceedings/84/minutes/minutes-84-pa= ws

 

Thanks Pete and Dorothy for the minutes.<= /p>

 

-     &= nbsp;    Gabor

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FAF96C008AM1MPN1006mg_-- From Gabor.Bajko@nokia.com Thu Aug 9 12:55:09 2012 Return-Path: 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 E671421F86B3 for ; Thu, 9 Aug 2012 12:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWrpSLw18grT for ; Thu, 9 Aug 2012 12:55:07 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 23DCC21F8694 for ; Thu, 9 Aug 2012 12:55:06 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q79Jt2w4025332 for ; Thu, 9 Aug 2012 22:55:03 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Aug 2012 22:55:59 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0283.004; Thu, 9 Aug 2012 21:55:01 +0200 From: To: Thread-Topic: use cases and requirements document Thread-Index: Ac12Z+2NbbG4lfLAT8aeYHhnRNTamA== Date: Thu, 9 Aug 2012 19:55:01 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFD8F@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FAFD8F008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Aug 2012 19:55:59.0836 (UTC) FILETIME=[FF7841C0:01CD7668] X-Nokia-AV: Clean Subject: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:55:09 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FAFD8F008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, During the last F2F meeting, there was an agreement to make a slight update= to requirement D.7 in http://www.ietf.org/id/draft-ietf-paws-problem-stmt-= usecases-rqmts-06.txt, to make channel numbers optional to be supported. Ie= , change the current D.7 "The Data Model MUST support specifying a list of available channels. The D= ata Model MUST support specification of this information by channel numbers= and by start and stop frequencies. The Data Model MUST support a channel a= vailability schedule and maximum power level for each channel in the list." to "The Data Model MUST support specifying a list of available channels. The D= ata Model MUST support specification of this information by start and stop = frequencies and MAY include channel numbers. The Data Model MUST support a = channel availability schedule and maximum power level for each channel in t= he list." I'd like to confirm this change on the list. If anyone has any objections, = let me know. Otherwise I'll plan to send the document to the iesg after thi= s change is implemented. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FAFD8F008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

During the last F2F meeting, there was an agreement = to make a slight update to requirement D.7 in http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.txt, to make channel numbers optional to be supported. Ie, change the curren= t D.7

“The Data Model MUST support specifying a list= of available channels. The Data Model MUST support specification of this i= nformation by channel numbers and by start and stop frequencies. The Data M= odel MUST support a channel availability schedule and maximum power level for each channel in the list.”=

to

“The Data Model MUST support specifying a list= of available channels. The Data Model MUST support specification of this i= nformation by start and stop frequencies and MAY include channel numbers. T= he Data Model MUST support a channel availability schedule and maximum power level for each channel in the list.”=

 

I’d like to confirm this change on the list. I= f anyone has any objections, let me know. Otherwise I’ll plan to send= the document to the iesg after this change is implemented.

 

-     &= nbsp;    Gabor

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FAFD8F008AM1MPN1006mg_-- From Peter.McCann@huawei.com Thu Aug 9 13:00:04 2012 Return-Path: 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 D481721F86F8 for ; Thu, 9 Aug 2012 13:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.463 X-Spam-Level: X-Spam-Status: No, score=-5.463 tagged_above=-999 required=5 tests=[AWL=1.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PnUPxhdU+XX for ; Thu, 9 Aug 2012 13:00:04 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4799521F86EB for ; Thu, 9 Aug 2012 13:00:04 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIR92280; Thu, 09 Aug 2012 12:00:03 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 9 Aug 2012 12:57:52 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.75]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Thu, 9 Aug 2012 12:57:48 -0700 From: Peter McCann To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: use cases and requirements document Thread-Index: Ac12Z+2NbbG4lfLAT8aeYHhnRNTamAAASkZw Date: Thu, 9 Aug 2012 19:57:48 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E1A8F1@dfweml512-mbx.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFD8F@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFD8F@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 20:00:04 -0000 I think "MAY include channel numbers" is somewhat ambiguous. I would prefer "MAY support specification of this information by channel number". -Pete Gabor.Bajko@nokia.com wrote: > Folks, >=20 >=20 >=20 > During the last F2F meeting, there was an agreement to make a slight=20 > update to requirement D.7 in http://www.ietf.org/id/draft-ietf-paws- > problem-stmt-usecases-rqmts-06.txt paws-problem-stmt-usecases-rqmts-06.txt> , to make channel numbers=20 > optional to be supported. Ie, change the current D.7 >=20 > "The Data Model MUST support specifying a list of available channels. > The Data Model MUST support specification of this information by=20 > channel numbers and by start and stop frequencies. The Data Model MUST=20 > support a channel availability schedule and maximum power level for=20 > each channel in the list." >=20 > to >=20 > "The Data Model MUST support specifying a list of available channels. > The Data Model MUST support specification of this information by start=20 > and stop frequencies and MAY include channel numbers. The Data Model=20 > MUST support a channel availability schedule and maximum power level=20 > for each channel in the list." >=20 >=20 >=20 > I'd like to confirm this change on the list. If anyone has any=20 > objections, let me know. Otherwise I'll plan to send the document to=20 > the iesg after this change is implemented. >=20 >=20 >=20 > - Gabor From brian.rosen@neustar.biz Thu Aug 9 15:24:54 2012 Return-Path: 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 83B0621F86FE for ; Thu, 9 Aug 2012 15:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.062 X-Spam-Level: X-Spam-Status: No, score=-6.062 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvfAkaqfwUft for ; Thu, 9 Aug 2012 15:24:53 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id AF4A821F86D3 for ; Thu, 9 Aug 2012 15:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1344551356; x=1659909006; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=QpJeWLaOgRiN3zV/vnnkS t64QPFFqkkK2kpLOfuPSd0=; b=jJ10iylJeaYYwYgsQK8saQSN56f+74VUF6cUr 4aNHvKV4wYJlIUTd7WrbahGAApoRCLWY02EOF/w+UoB9/fLKQ== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.12894881; Thu, 09 Aug 2012 18:29:15 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 9 Aug 2012 18:24:43 -0400 From: "Rosen, Brian" Date: Thu, 9 Aug 2012 18:24:44 -0400 Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac12fcZMfhcoQLVqRh+PepsnhkGzGA== Message-ID: <5A02A514-1CA7-4AB8-8CA7-C9D1214D3F5C@neustar.biz> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFD8F@008-AM1MPN1-006.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E1A8F1@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E1A8F1@dfweml512-mbx.china.huawei.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: V9gspJRa9b+EoHIqovTVBQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Peter McCann Cc: "paws@ietf.org" Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 22:24:54 -0000 I would like to suggest a more radical change I would like to define the term: spectrum unit as a unit of spectrum define= d by a low and high frequency and optionally a channel identifier. Then I = would like to use "spectrum unit" wherever the word "channel" would occur t= hroughout the document. In the definition, I would observe that while it = is common to have "channels" that are defined with some identifier, the pro= tocol does not depend on such an arrangement, but can manage any swath of s= pectrum defined by an upper and lower frequency. I'm not attached to the specific term "spectrum unit" but I don't want to u= se "channel" as that implies something that we are not limited by. Brian On Aug 9, 2012, at 3:57 PM, Peter McCann wrote: > I think "MAY include channel numbers" is somewhat ambiguous. I would > prefer "MAY support specification of this information by channel number". >=20 > -Pete >=20 > Gabor.Bajko@nokia.com wrote: >> Folks, >>=20 >>=20 >>=20 >> During the last F2F meeting, there was an agreement to make a slight=20 >> update to requirement D.7 in http://www.ietf.org/id/draft-ietf-paws- >> problem-stmt-usecases-rqmts-06.txt > paws-problem-stmt-usecases-rqmts-06.txt> , to make channel numbers=20 >> optional to be supported. Ie, change the current D.7 >>=20 >> "The Data Model MUST support specifying a list of available channels. >> The Data Model MUST support specification of this information by=20 >> channel numbers and by start and stop frequencies. The Data Model MUST=20 >> support a channel availability schedule and maximum power level for=20 >> each channel in the list." >>=20 >> to >>=20 >> "The Data Model MUST support specifying a list of available channels. >> The Data Model MUST support specification of this information by start=20 >> and stop frequencies and MAY include channel numbers. The Data Model=20 >> MUST support a channel availability schedule and maximum power level=20 >> for each channel in the list." >>=20 >>=20 >>=20 >> I'd like to confirm this change on the list. If anyone has any=20 >> objections, let me know. Otherwise I'll plan to send the document to=20 >> the iesg after this change is implemented. >>=20 >>=20 >>=20 >> - Gabor >=20 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From peter@spectrumbridge.com Thu Aug 9 15:37:49 2012 Return-Path: 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 EF8F121F86B8 for ; Thu, 9 Aug 2012 15:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-YRDDblkm8N for ; Thu, 9 Aug 2012 15:37:49 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id E457421F8690 for ; Thu, 9 Aug 2012 15:37:48 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Thu, 9 Aug 2012 18:37:47 -0400 From: Peter Stanforth To: "Rosen, Brian" , Peter McCann Date: Thu, 9 Aug 2012 18:37:42 -0400 Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac12f5l2MJtkV92PQsutJmdFIz3Mow== Message-ID: In-Reply-To: <5A02A514-1CA7-4AB8-8CA7-C9D1214D3F5C@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 22:37:50 -0000 I suggest we take a look at the work MITRE has been doing on Model-Based Spectrum Management (MBSM). A lot of this is related to defining a spectrum commodity which is, I think, the basis of what we are trying to do here. http://www.mitre.org/work/tech_papers/2011/11_2071/ On the same text I have a question, Where it says "The Data Model MUST support a channel availability schedule and maximum power level for each channel in the list." What does this mean? The reason I ask is the FCC does not allow for variable power and some Regulators are suggesting channel allocation duration only be as long as the shortest available, negating the need for an availability map. Does the current wording allow for these two cases? Peter S. =20 On ThuAug/9/12 Thu Aug 9, 6:24 PM, "Rosen, Brian" wrote: > >I would like to suggest a more radical change > >I would like to define the term: spectrum unit as a unit of spectrum >defined by a low and high frequency and optionally a channel identifier. >Then I would like to use "spectrum unit" wherever the word "channel" >would occur throughout the document. In the definition, I would observe >that while it is common to have "channels" that are defined with some >identifier, the protocol does not depend on such an arrangement, but can >manage any swath of spectrum defined by an upper and lower frequency. > >I'm not attached to the specific term "spectrum unit" but I don't want to >use "channel" as that implies something that we are not limited by. > >Brian > >On Aug 9, 2012, at 3:57 PM, Peter McCann wrote: > >> I think "MAY include channel numbers" is somewhat ambiguous. I would >> prefer "MAY support specification of this information by channel >>number". >>=20 >> -Pete >>=20 >> Gabor.Bajko@nokia.com wrote: >>> Folks, >>>=20 >>>=20 >>>=20 >>> During the last F2F meeting, there was an agreement to make a slight >>> update to requirement D.7 in http://www.ietf.org/id/draft-ietf-paws- >>> problem-stmt-usecases-rqmts-06.txt >> paws-problem-stmt-usecases-rqmts-06.txt> , to make channel numbers >>> optional to be supported. Ie, change the current D.7 >>>=20 >>> "The Data Model MUST support specifying a list of available channels. >>> The Data Model MUST support specification of this information by >>> channel numbers and by start and stop frequencies. The Data Model MUST >>> support a channel availability schedule and maximum power level for >>> each channel in the list." >>>=20 >>> to >>>=20 >>> "The Data Model MUST support specifying a list of available channels. >>> The Data Model MUST support specification of this information by start >>> and stop frequencies and MAY include channel numbers. The Data Model >>> MUST support a channel availability schedule and maximum power level >>> for each channel in the list." >>>=20 >>>=20 >>>=20 >>> I'd like to confirm this change on the list. If anyone has any >>> objections, let me know. Otherwise I'll plan to send the document to >>> the iesg after this change is implemented. >>>=20 >>>=20 >>>=20 >>> - Gabor >>=20 >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Thu Aug 9 15:56:36 2012 Return-Path: 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 D702411E8072 for ; Thu, 9 Aug 2012 15:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFnnfDvwSXyb for ; Thu, 9 Aug 2012 15:56:36 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id C0F0F21F85E4 for ; Thu, 9 Aug 2012 15:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1344553100; x=1659912564; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=xJ4r341OSN1ohLxG/noWb VB0x528sIrzpgBH/54ftkc=; b=p8M8gztiTvSGskjOU0jSDKz0lvaYBoj0+3JGE 8ymHFXkhahEV8fGZoqmIxnbJdwf95xG9d90mRlMuTxp4zNujQ== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.12450268; Thu, 09 Aug 2012 18:58:19 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 9 Aug 2012 18:56:23 -0400 From: "Rosen, Brian" To: Peter Stanforth Date: Thu, 9 Aug 2012 18:56:22 -0400 Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac12gjIoYPLaOQI8QB28KO670gFtww== Message-ID: <0161A077-3C8C-4234-93AE-E99A40A64AA3@neustar.biz> References: In-Reply-To: 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: uA504nwouv61bvdRDbhv9w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 22:56:37 -0000 Usually when we use the words "MUST support" we imply options. If we didn'= t, we would usually say MUST specify or MUST require" or something like it.= So I would say, yes, the protocol must allow no schedule and no power lim= its, but it must also allow one or both of them. Brian On Aug 9, 2012, at 6:37 PM, Peter Stanforth wrot= e: > I suggest we take a look at the work MITRE has been doing on Model-Based > Spectrum Management (MBSM). A lot of this is related to defining a > spectrum commodity which is, I think, the basis of what we are trying to > do here. > http://www.mitre.org/work/tech_papers/2011/11_2071/ >=20 > On the same text I have a question, Where it says "The Data Model MUST > support a channel availability schedule and maximum power level for each > channel in the list." What does this mean? The reason I ask is the FCC > does not allow for variable power and some Regulators are suggesting > channel allocation duration only be as long as the shortest available, > negating the need for an availability map. Does the current wording allo= w > for these two cases? > Peter S. >=20 >=20 >=20 > On ThuAug/9/12 Thu Aug 9, 6:24 PM, "Rosen, Brian" > wrote: >=20 >> >> I would like to suggest a more radical change >>=20 >> I would like to define the term: spectrum unit as a unit of spectrum >> defined by a low and high frequency and optionally a channel identifier. >> Then I would like to use "spectrum unit" wherever the word "channel" >> would occur throughout the document. In the definition, I would observ= e >> that while it is common to have "channels" that are defined with some >> identifier, the protocol does not depend on such an arrangement, but can >> manage any swath of spectrum defined by an upper and lower frequency. >>=20 >> I'm not attached to the specific term "spectrum unit" but I don't want t= o >> use "channel" as that implies something that we are not limited by. >>=20 >> Brian >>=20 >> On Aug 9, 2012, at 3:57 PM, Peter McCann wrote= : >>=20 >>> I think "MAY include channel numbers" is somewhat ambiguous. I would >>> prefer "MAY support specification of this information by channel >>> number". >>>=20 >>> -Pete >>>=20 >>> Gabor.Bajko@nokia.com wrote: >>>> Folks, >>>>=20 >>>>=20 >>>>=20 >>>> During the last F2F meeting, there was an agreement to make a slight >>>> update to requirement D.7 in http://www.ietf.org/id/draft-ietf-paws- >>>> problem-stmt-usecases-rqmts-06.txt >>> paws-problem-stmt-usecases-rqmts-06.txt> , to make channel numbers >>>> optional to be supported. Ie, change the current D.7 >>>>=20 >>>> "The Data Model MUST support specifying a list of available channels. >>>> The Data Model MUST support specification of this information by >>>> channel numbers and by start and stop frequencies. The Data Model MUST >>>> support a channel availability schedule and maximum power level for >>>> each channel in the list." >>>>=20 >>>> to >>>>=20 >>>> "The Data Model MUST support specifying a list of available channels. >>>> The Data Model MUST support specification of this information by start >>>> and stop frequencies and MAY include channel numbers. The Data Model >>>> MUST support a channel availability schedule and maximum power level >>>> for each channel in the list." >>>>=20 >>>>=20 >>>>=20 >>>> I'd like to confirm this change on the list. If anyone has any >>>> objections, let me know. Otherwise I'll plan to send the document to >>>> the iesg after this change is implemented. >>>>=20 >>>>=20 >>>>=20 >>>> - Gabor >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 From nbravin@earthlink.net Thu Aug 9 16:13:17 2012 Return-Path: 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 ADF8F11E808E for ; Thu, 9 Aug 2012 16:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQyhr0DpveBB for ; Thu, 9 Aug 2012 16:13:16 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id BFA7711E808A for ; Thu, 9 Aug 2012 16:13:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=I6EKrMG0Bm/0qeevvjtMWuODFOIdbM59tYe6X91yhiqCVABEuiR8N9U4Vj/KXGZv; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [71.46.198.120] (helo=[10.0.1.2]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1SzbuW-000651-K3; Thu, 09 Aug 2012 19:13:00 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Nancy Bravin In-Reply-To: <0161A077-3C8C-4234-93AE-E99A40A64AA3@neustar.biz> Date: Thu, 9 Aug 2012 16:12:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9FA9A822-663B-4198-A5E2-6D298106A03F@earthlink.net> References: <0161A077-3C8C-4234-93AE-E99A40A64AA3@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1278) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86e5908b2f8f10426f2d9f2d3c06b4d30e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 23:13:17 -0000 Hi Guys=20 So then in the section for terms there will be an explanation of when a Must demands something, or offers one of two solutions, or?=20 So it will need to be defined as to not be confusing as to when a "MUST" = carries no other choices? "Must Support" implies options "Must specify"=20 "Must require" , ETC. Sincerely, Nancy On Aug 9, 2012, at 3:56 PM, Rosen, Brian wrote: > Usually when we use the words "MUST support" we imply options. If we = didn't, we would usually say MUST specify or MUST require" or something = like it. So I would say, yes, the protocol must allow no schedule and = no power limits, but it must also allow one or both of them. >=20 > Brian >=20 > On Aug 9, 2012, at 6:37 PM, Peter Stanforth = wrote: >=20 >> I suggest we take a look at the work MITRE has been doing on = Model-Based >> Spectrum Management (MBSM). A lot of this is related to defining a >> spectrum commodity which is, I think, the basis of what we are trying = to >> do here. >> http://www.mitre.org/work/tech_papers/2011/11_2071/ >>=20 >> On the same text I have a question, Where it says "The Data Model = MUST >> support a channel availability schedule and maximum power level for = each >> channel in the list." What does this mean? The reason I ask is the = FCC >> does not allow for variable power and some Regulators are suggesting >> channel allocation duration only be as long as the shortest = available, >> negating the need for an availability map. Does the current wording = allow >> for these two cases? >> Peter S. >>=20 >>=20 >>=20 >> On ThuAug/9/12 Thu Aug 9, 6:24 PM, "Rosen, Brian" >> wrote: >>=20 >>> >>> I would like to suggest a more radical change >>>=20 >>> I would like to define the term: spectrum unit as a unit of spectrum >>> defined by a low and high frequency and optionally a channel = identifier. >>> Then I would like to use "spectrum unit" wherever the word "channel" >>> would occur throughout the document. In the definition, I would = observe >>> that while it is common to have "channels" that are defined with = some >>> identifier, the protocol does not depend on such an arrangement, but = can >>> manage any swath of spectrum defined by an upper and lower = frequency. >>>=20 >>> I'm not attached to the specific term "spectrum unit" but I don't = want to >>> use "channel" as that implies something that we are not limited by. >>>=20 >>> Brian >>>=20 >>> On Aug 9, 2012, at 3:57 PM, Peter McCann = wrote: >>>=20 >>>> I think "MAY include channel numbers" is somewhat ambiguous. I = would >>>> prefer "MAY support specification of this information by channel >>>> number". >>>>=20 >>>> -Pete >>>>=20 >>>> Gabor.Bajko@nokia.com wrote: >>>>> Folks, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> During the last F2F meeting, there was an agreement to make a = slight >>>>> update to requirement D.7 in = http://www.ietf.org/id/draft-ietf-paws- >>>>> problem-stmt-usecases-rqmts-06.txt = >>>> paws-problem-stmt-usecases-rqmts-06.txt> , to make channel numbers >>>>> optional to be supported. Ie, change the current D.7 >>>>>=20 >>>>> "The Data Model MUST support specifying a list of available = channels. >>>>> The Data Model MUST support specification of this information by >>>>> channel numbers and by start and stop frequencies. The Data Model = MUST >>>>> support a channel availability schedule and maximum power level = for >>>>> each channel in the list." >>>>>=20 >>>>> to >>>>>=20 >>>>> "The Data Model MUST support specifying a list of available = channels. >>>>> The Data Model MUST support specification of this information by = start >>>>> and stop frequencies and MAY include channel numbers. The Data = Model >>>>> MUST support a channel availability schedule and maximum power = level >>>>> for each channel in the list." >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I'd like to confirm this change on the list. If anyone has any >>>>> objections, let me know. Otherwise I'll plan to send the document = to >>>>> the iesg after this change is implemented. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> - Gabor >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Thu Aug 9 16:22:01 2012 Return-Path: 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 ED22021F85E6 for ; Thu, 9 Aug 2012 16:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYZr7ztsn1Hc for ; Thu, 9 Aug 2012 16:22:01 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 08A0121F85C7 for ; Thu, 9 Aug 2012 16:22:00 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q79NLwxI024474 for ; Fri, 10 Aug 2012 02:21:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Aug 2012 02:22:56 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0283.004; Fri, 10 Aug 2012 01:21:45 +0200 From: To: Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac12Z+2NbbG4lfLAT8aeYHhnRNTamAAASkZwAAD7IAAAAHPuAAAFjh0w Date: Thu, 9 Aug 2012 23:21:44 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFEF8@008-AM1MPN1-006.mgdnok.nokia.com> References: <5A02A514-1CA7-4AB8-8CA7-C9D1214D3F5C@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Aug 2012 23:22:56.0138 (UTC) FILETIME=[E82996A0:01CD7685] X-Nokia-AV: Clean Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 23:22:02 -0000 The Data Model MUST support means that the data blob must be able to encode= it, but it doesn't say anything about whether the db has to send it or not= . In FCC case, I'd say that the data model would encode the shortest availabl= e duration and the allowed power level. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Peter Stanforth Sent: Thursday, August 09, 2012 3:38 PM To: Rosen, Brian; Peter McCann Cc: paws@ietf.org Subject: Re: [paws] use cases and requirements document I suggest we take a look at the work MITRE has been doing on Model-Based Sp= ectrum Management (MBSM). A lot of this is related to defining a spectrum c= ommodity which is, I think, the basis of what we are trying to do here. http://www.mitre.org/work/tech_papers/2011/11_2071/ On the same text I have a question, Where it says "The Data Model MUST supp= ort a channel availability schedule and maximum power level for each channe= l in the list." What does this mean? The reason I ask is the FCC does not = allow for variable power and some Regulators are suggesting channel allocat= ion duration only be as long as the shortest available, negating the need f= or an availability map. Does the current wording allow for these two cases= ? Peter S. =20 On ThuAug/9/12 Thu Aug 9, 6:24 PM, "Rosen, Brian" wrote: > >I would like to suggest a more radical change > >I would like to define the term: spectrum unit as a unit of spectrum=20 >defined by a low and high frequency and optionally a channel identifier. >Then I would like to use "spectrum unit" wherever the word "channel" >would occur throughout the document. In the definition, I would observe >that while it is common to have "channels" that are defined with some=20 >identifier, the protocol does not depend on such an arrangement, but=20 >can manage any swath of spectrum defined by an upper and lower frequency. > >I'm not attached to the specific term "spectrum unit" but I don't want=20 >to use "channel" as that implies something that we are not limited by. > >Brian > >On Aug 9, 2012, at 3:57 PM, Peter McCann wrote: > >> I think "MAY include channel numbers" is somewhat ambiguous. I would =20 >>prefer "MAY support specification of this information by channel=20 >>number". >>=20 >> -Pete >>=20 >> Gabor.Bajko@nokia.com wrote: >>> Folks, >>>=20 >>>=20 >>>=20 >>> During the last F2F meeting, there was an agreement to make a slight=20 >>> update to requirement D.7 in http://www.ietf.org/id/draft-ietf-paws- >>> problem-stmt-usecases-rqmts-06.txt=20 >>> >> paws-problem-stmt-usecases-rqmts-06.txt> , to make channel numbers=20 >>> optional to be supported. Ie, change the current D.7 >>>=20 >>> "The Data Model MUST support specifying a list of available channels. >>> The Data Model MUST support specification of this information by=20 >>> channel numbers and by start and stop frequencies. The Data Model=20 >>> MUST support a channel availability schedule and maximum power level=20 >>> for each channel in the list." >>>=20 >>> to >>>=20 >>> "The Data Model MUST support specifying a list of available channels. >>> The Data Model MUST support specification of this information by=20 >>> start and stop frequencies and MAY include channel numbers. The Data=20 >>> Model MUST support a channel availability schedule and maximum power=20 >>> level for each channel in the list." >>>=20 >>>=20 >>>=20 >>> I'd like to confirm this change on the list. If anyone has any=20 >>> objections, let me know. Otherwise I'll plan to send the document to=20 >>> the iesg after this change is implemented. >>>=20 >>>=20 >>>=20 >>> - Gabor >>=20 >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Thu Aug 9 17:02:07 2012 Return-Path: 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 3E6E121F846A for ; Thu, 9 Aug 2012 17:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaDpwIhIsGj9 for ; Thu, 9 Aug 2012 17:02:05 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id A3B9A21F8464 for ; Thu, 9 Aug 2012 17:02:04 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7A022Ft000588 for ; Fri, 10 Aug 2012 03:02:02 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Aug 2012 03:02:59 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0283.004; Fri, 10 Aug 2012 02:02:01 +0200 From: To: Thread-Topic: need for DB initialization message Thread-Index: Ac12he0A+5h4j+uqT6e4F6BpK7EzXw== Date: Fri, 10 Aug 2012 00:02:01 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 10 Aug 2012 00:02:59.0490 (UTC) FILETIME=[80AC0020:01CD768B] X-Nokia-AV: Clean Subject: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 00:02:07 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, During the Vancouver F2F discussions we had some good discussions, but no a= greement on whether an initialization message, as proposed in draft-das is = necessary or not. You may check the minutes to see what was said at the mike: http://www.ietf= .org/proceedings/84/minutes/minutes-84-paws People spoke mostly in favor, but there were people who also said that this= message is redundant with registration message. Question#1: need for an initialization message Unfortunately we did not have time to discuss the DB discovery aspect, and = that may be related to this topic. The only DB discovery document available= currently, http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, pr= oposes, that the master device contacts a pre-provisioned discovery server = and provides its location, and in return the discovery server returns the U= RI of the DB for that regulatory domain. At this point, the master device k= nows which DB to contact, but it does not necessarily know what regulatory = domain that DB belongs to. Thus, it doesn't know what are the operating rul= es, whether it has to authenticate, or register, etc. Thus, it seems logical to me that the master device first queries the DB to= find out the regulatory domain. We even have such a requirement in the req= uirement draft, requirement: "P.3: The protocol MUST support determination of regulatory d= omain governing its current location." The information about the regulatory domain may be cached, and the master d= evice may not need to place that query every time, but this message exchang= e may be necessary in certain cases. Any comments to this point? Question#2 Then, it is a slightly separate issue, if this message exchange has to take= place, then what additional information the DB returns. draft-das proposes= that regulatory domain specific information be returned to the master devi= ce. Question#3 Yet another separate point is that draft-das proposes to use this initializ= ation message also to initiate client authentication (putting shared secret= vs cert issue aside for the time being). In cases when the master device d= oes not know the regulatory domain it is in, then it does not know whether = authentication is required in that regulatory domain or not; so why would i= nitiate authentication then? Similar comment applies to draft-wei, where it= is proposed that after DB discovery the master device authenticates at TLS= layer and performs registration; how does it know that it has to authentic= ate and register, if it doesn't know the regulatory domain? In my opinion (chair hat off), the sequence of events should be sg like thi= s: 1. DB discovery (may be skipped if cached information available) 2. Regulatory domain query (may be skipped if cached information avai= lable) 3. Authentication (if required) 4. Registration (if required) 5. Channel availability query (may be combined with registration?) Comments are welcome and expected. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

During the Vancouver F2F discussions we had some goo= d discussions, but no agreement on whether an initialization message, as pr= oposed in draft-das is necessary or not.

You may check the minutes to see what was said at th= e mike: http://www.ietf.org/proceedings/84/minutes/minutes-84-paws

 

People spoke mostly in favor, but there were people = who also said that this message is redundant with registration message.

 

Question#1: need for an initialization message<= /o:p>

Unfortunately we did not have time to discuss the DB= discovery aspect, and that may be related to this topic. The only DB disco= very document available currently, htt= p://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, proposes, tha= t the master device contacts a pre-provisioned discovery server and provide= s its location, and in return the discovery server returns the URI of the DB for that regulatory domain. At = this point, the master device knows which DB to contact, but it does not ne= cessarily know what regulatory domain that DB belongs to. Thus, it doesn= 217;t know what are the operating rules, whether it has to authenticate, or register, etc.

Thus, it seems logical to me that the master device = first queries the DB to find out the regulatory domain. We even have such a= requirement in the requirement draft, requirement:

“P.3:   The protocol MUST support de= termination of regulatory        &n= bsp;    domain governing its current location.”

The information about the regulatory domain may be c= ached, and the master device may not need to place that query every time, b= ut this message exchange may be necessary in certain cases. Any comments to= this point?

 

Question#2

Then, it is a slightly separate issue, if this messa= ge exchange has to take place, then what additional information the DB retu= rns. draft-das proposes that regulatory domain specific information be retu= rned to the master device.

 

Question#3

Yet another separate point is that draft-das propose= s to use this initialization message also to initiate client authentication= (putting shared secret vs cert issue aside for the time being). In cases w= hen the master device does not know the regulatory domain it is in, then it does not know whether authenticati= on is required in that regulatory domain or not; so why would initiate auth= entication then? Similar comment applies to draft-wei, where it is proposed= that after DB discovery the master device authenticates at TLS layer and performs registration; how does it k= now that it has to authenticate and register, if it doesn’t know the = regulatory domain?

 

In my opinion (chair hat off), the sequence of event= s should be sg like this:

 

1.     &= nbsp; DB discovery (may be skipped if cached information = available)

2.     &= nbsp; Regulatory domain query (may be skipped if cached i= nformation available)

3.     &= nbsp; Authentication (if required)

4.     &= nbsp; Registration (if required)

5.     &= nbsp; Channel availability query (may be combined with re= gistration?)

 

Comments are welcome and expected.

 

-     &= nbsp;    Gabor

 

 

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F008AM1MPN1006mg_-- From brian.rosen@neustar.biz Thu Aug 9 17:14:56 2012 Return-Path: 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 8D4CC11E8099 for ; Thu, 9 Aug 2012 17:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9eoLzLgXSa9 for ; Thu, 9 Aug 2012 17:14:55 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 33ACD11E808A for ; Thu, 9 Aug 2012 17:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1344557453; x=1659909986; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=Y5Pys2+JcGA5ieVNEGLsutgTtb7/c1JN0XMSuw+V/4c=; b=WjgOeBET8XWhc/cw0rPjDgwop4PZnDxCisp5qFQ+g/ygxM7LvSg5vcU1agnlFM JXUzfoT7gr2dFaSKiQvfI5CA== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.9703077; Thu, 09 Aug 2012 20:10:51 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 9 Aug 2012 20:14:51 -0400 From: "Rosen, Brian" Date: Thu, 9 Aug 2012 20:14:50 -0400 Thread-Topic: [paws] need for DB initialization message Thread-Index: Ac12jSjIPSE3Q7O2SZWEcurTAtBH8w== Message-ID: <7EE3F6BC-E8AB-4C28-B221-1D6E64324D0A@neustar.biz> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F@008-AM1MPN1-006.mgdnok.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: /zeQfDztaOXienRtyf8hbw== Content-Type: multipart/alternative; boundary="_000_7EE3F6BCE8AB4C28B2211D6E64324D0Aneustarbiz_" MIME-Version: 1.0 To: "" Cc: "paws@ietf.org" Subject: Re: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 00:14:56 -0000 --_000_7EE3F6BCE8AB4C28B2211D6E64324D0Aneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'm not so sure you need something separate for domain. ISTM that the DB d= iscovery could return it (possibly as a parameter on the DB URI). OTOH, yo= u might very well want to receive from the DB some kind of data specificati= on (that is, what is required to be provided in the registration), rather t= han having it totally wired in to domain. That means, to me, that the regi= stration is a 4 way message exchange: 1. Device to DB: Authenticate me please 2. DB to device: Authentication accepted, send me this data 3. Device to DB: Here is my registration data 4. DB to device: Registration succeeded. Now, having said that, you might just get authentication out of the TLS ses= sion establishment, this not needing step 1. Brian On Aug 9, 2012, at 8:02 PM, > wrote: Folks, During the Vancouver F2F discussions we had some good discussions, but no a= greement on whether an initialization message, as proposed in draft-das is = necessary or not. You may check the minutes to see what was said at the mike: http://www.ietf= .org/proceedings/84/minutes/minutes-84-paws People spoke mostly in favor, but there were people who also said that this= message is redundant with registration message. Question#1: need for an initialization message Unfortunately we did not have time to discuss the DB discovery aspect, and = that may be related to this topic. The only DB discovery document available= currently, http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, pr= oposes, that the master device contacts a pre-provisioned discovery server = and provides its location, and in return the discovery server returns the U= RI of the DB for that regulatory domain. At this point, the master device k= nows which DB to contact, but it does not necessarily know what regulatory = domain that DB belongs to. Thus, it doesn=92t know what are the operating r= ules, whether it has to authenticate, or register, etc. Thus, it seems logical to me that the master device first queries the DB to= find out the regulatory domain. We even have such a requirement in the req= uirement draft, requirement: =93P.3: The protocol MUST support determination of regulatory = domain governing its current location.=94 The information about the regulatory domain may be cached, and the master d= evice may not need to place that query every time, but this message exchang= e may be necessary in certain cases. Any comments to this point? Question#2 Then, it is a slightly separate issue, if this message exchange has to take= place, then what additional information the DB returns. draft-das proposes= that regulatory domain specific information be returned to the master devi= ce. Question#3 Yet another separate point is that draft-das proposes to use this initializ= ation message also to initiate client authentication (putting shared secret= vs cert issue aside for the time being). In cases when the master device d= oes not know the regulatory domain it is in, then it does not know whether = authentication is required in that regulatory domain or not; so why would i= nitiate authentication then? Similar comment applies to draft-wei, where it= is proposed that after DB discovery the master device authenticates at TLS= layer and performs registration; how does it know that it has to authentic= ate and register, if it doesn=92t know the regulatory domain? In my opinion (chair hat off), the sequence of events should be sg like thi= s: 1. DB discovery (may be skipped if cached information available) 2. Regulatory domain query (may be skipped if cached information avai= lable) 3. Authentication (if required) 4. Registration (if required) 5. Channel availability query (may be combined with registration?) Comments are welcome and expected. - Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_7EE3F6BCE8AB4C28B2211D6E64324D0Aneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <as individual>
I'm not so sure you need something separate= for domain.  ISTM that the DB discovery could return it (possibly as = a parameter on the DB URI).  OTOH, you might very well want to receive= from the DB some kind of data specification (that is, what is required to = be provided in the registration), rather than having it totally wired in to= domain.  That means, to me, that the registration is a 4 way message = exchange:
1. Device to DB: Authenticate me please
2. DB= to device: Authentication accepted, send me this data
3. Device = to DB: Here is my registration data
4. DB to device: Registration= succeeded.

Now, having said that, you might just = get authentication out of the TLS session establishment, this not needing s= tep 1.

Brian

On= Aug 9, 2012, at 8:02 PM, <Gabo= r.Bajko@nokia.com> wrote:

Folks,
 
During= the Vancouver F2F discussions we had some good discussions, but no agreeme= nt on whether an initialization message, as proposed in draft-das is necess= ary or not.
You may check the minutes to = see what was said at the mike: <= /span>http://www.ietf.org= /proceedings/84/minutes/minutes-84-paws
People spoke mostly in favor, b= ut there were people who also said that this message is redundant with regi= stration message.
 
=
Question#1: need for an initialization message=
Unfortunately we did not have time to discuss the D= B discovery aspect, and that may be related to this topic. The only DB disc= overy document available currently,&n= bsp;http://www.ie= tf.org/id/draft-probasco-paws-discovery-01.txt, proposes, that the mast= er device contacts a pre-provisioned discovery server and provides its loca= tion, and in return the discovery server returns the URI of the DB for that= regulatory domain. At this point, the master device knows which DB to cont= act, but it does not necessarily know what regulatory domain that DB belong= s to. Thus, it doesn=92t know what are the operating rules, whether it has = to authenticate, or register, etc.
Thus, = it seems logical to me that the master device first queries the DB to find = out the regulatory domain. We even have such a requirement in the requireme= nt draft, requirement:
=93P.3:  = ; The protocol MUST support determination of regulatory   &n= bsp;         domain governing its c= urrent location.=94
The information about= the regulatory domain may be cached, and the master device may not need to= place that query every time, but this message exchange may be necessary in= certain cases. Any comments to this point?
Question#2
Then, it is a slightly separate issue, if this message exchan= ge has to take place, then what additional information the DB returns. draf= t-das proposes that regulatory domain specific information be returned to t= he master device.
 
=
Question#3
Yet another = separate point is that draft-das proposes to use this initialization messag= e also to initiate client authentication (putting shared secret vs cert iss= ue aside for the time being). In cases when the master device does not know= the regulatory domain it is in, then it does not know whether authenticati= on is required in that regulatory domain or not; so why would initiate auth= entication then? Similar comment applies to draft-wei, where it is proposed= that after DB discovery the master device authenticates at TLS layer and p= erforms registration; how does it know that it has to authenticate and regi= ster, if it doesn=92t know the regulatory domain?
 
In my opinion (chair hat = off), the sequence of events should be sg like this:
 
1.       DB discovery (may be skipped if cach= ed information available)
2.       Regulatory domain query (may = be skipped if cached information available)
3.      <= span class=3D"Apple-converted-space"> Authenticat= ion (if required)
4.       Registration (if required)=
5.  &nbs= p;    Channel availability query (may be combined with registration?)
 
C= omments are welcome and expected.
&n= bsp;
- &= nbsp;        Gabor
 
 
_____________________________________= __________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws=

= --_000_7EE3F6BCE8AB4C28B2211D6E64324D0Aneustarbiz_-- From jmh@joelhalpern.com Thu Aug 9 18:25:21 2012 Return-Path: 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 4E8E421F85CC for ; Thu, 9 Aug 2012 18:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUIb482Q0ptt for ; Thu, 9 Aug 2012 18:25:20 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id A588421F857E for ; Thu, 9 Aug 2012 18:25:20 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 5C62BA382B for ; Thu, 9 Aug 2012 18:25:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id CA168161756; Thu, 9 Aug 2012 18:25:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.1.2] (c-71-204-207-35.hsd1.de.comcast.net [71.204.207.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C32B3161754; Thu, 9 Aug 2012 18:25:18 -0700 (PDT) Message-ID: <502462F4.8000002@joelhalpern.com> Date: Thu, 09 Aug 2012 21:25:08 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Gabor.Bajko@nokia.com References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F@008-AM1MPN1-006.mgdnok.nokia.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: paws@ietf.org Subject: Re: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 01:25:21 -0000 Related suggestion: Assuming we have a discovery protocol which can return a URI, the protocol semantics should be such that the URI can be the final DB URI, or another intermediary in the process. Thus, the protocol should not lock in that there can be only 0 or 1 intermediaries in the resolution, but should allow several. (We already have suggested cases where at least two are needed, one to determine where you are by asking your vendor, and one to determine who you can talk to by asking your local regulator.) Yours, Joel On 8/9/2012 8:02 PM, Gabor.Bajko@nokia.com wrote: > Folks, > > During the Vancouver F2F discussions we had some good discussions, but > no agreement on whether an initialization message, as proposed in > draft-das is necessary or not. > > You may check the minutes to see what was said at the mike: > http://www.ietf.org/proceedings/84/minutes/minutes-84-paws > > People spoke mostly in favor, but there were people who also said that > this message is redundant with registration message. > > Question#1: need for an initialization message > > Unfortunately we did not have time to discuss the DB discovery aspect, > and that may be related to this topic. The only DB discovery document > available currently, > http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, proposes, > that the master device contacts a pre-provisioned discovery server and > provides its location, and in return the discovery server returns the > URI of the DB for that regulatory domain. At this point, the master > device knows which DB to contact, but it does not necessarily know what > regulatory domain that DB belongs to. Thus, it doesn’t know what are the > operating rules, whether it has to authenticate, or register, etc. > > Thus, it seems logical to me that the master device first queries the DB > to find out the regulatory domain. We even have such a requirement in > the requirement draft, requirement: > > “P.3: The protocol MUST support determination of > regulatory domain governing its current location.” > > The information about the regulatory domain may be cached, and the > master device may not need to place that query every time, but this > message exchange may be necessary in certain cases. Any comments to this > point? > > Question#2 > > Then, it is a slightly separate issue, if this message exchange has to > take place, then what additional information the DB returns. draft-das > proposes that regulatory domain specific information be returned to the > master device. > > Question#3 > > Yet another separate point is that draft-das proposes to use this > initialization message also to initiate client authentication (putting > shared secret vs cert issue aside for the time being). In cases when the > master device does not know the regulatory domain it is in, then it does > not know whether authentication is required in that regulatory domain or > not; so why would initiate authentication then? Similar comment applies > to draft-wei, where it is proposed that after DB discovery the master > device authenticates at TLS layer and performs registration; how does it > know that it has to authenticate and register, if it doesn’t know the > regulatory domain? > > In my opinion (chair hat off), the sequence of events should be sg like > this: > > 1.DB discovery (may be skipped if cached information available) > > 2.Regulatory domain query (may be skipped if cached information available) > > 3.Authentication (if required) > > 4.Registration (if required) > > 5.Channel availability query (may be combined with registration?) > > Comments are welcome and expected. > > -Gabor > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From brian.rosen@neustar.biz Thu Aug 9 18:27:12 2012 Return-Path: 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 A343B21F85FC for ; Thu, 9 Aug 2012 18:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK4xc+L5Y7aM for ; Thu, 9 Aug 2012 18:27:11 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id A86A821F85F0 for ; Thu, 9 Aug 2012 18:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1344561789; x=1659919027; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=SJmObhACfFFU0OJu8v+hW po5bT3jTEzfW8gsAq+LFbE=; b=MELcbvkeb4t4+6oF+OtPx6nsBLRQLG2wwp/w7 +W51OukUtNWPtR/y7u/mfQpqkovW1l1SOzUAXMinSKomptWMQ== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.9704789; Thu, 09 Aug 2012 21:23:08 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 9 Aug 2012 21:27:08 -0400 From: "Rosen, Brian" Date: Thu, 9 Aug 2012 21:27:07 -0400 Thread-Topic: [paws] need for DB initialization message Thread-Index: Ac12l0GlZCXWd6pLROONS/t0aUZPIw== Message-ID: <645E8354-AC28-4DE6-85FC-025F1FEA5FCE@neustar.biz> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F@008-AM1MPN1-006.mgdnok.nokia.com> <502462F4.8000002@joelhalpern.com> In-Reply-To: <502462F4.8000002@joelhalpern.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: bhdL/7B5D0prtRX1a4YcDw== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: "Joel M. Halpern" Cc: "paws@ietf.org" Subject: Re: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 01:27:12 -0000 Yeah, that also handles the situation where discovery gets you the national= list and then you choose one from the list. Brian On Aug 9, 2012, at 9:25 PM, "Joel M. Halpern" wrote: > Related suggestion: Assuming we have a discovery protocol which can=20 > return a URI, the protocol semantics should be such that the URI can be=20 > the final DB URI, or another intermediary in the process. Thus, the=20 > protocol should not lock in that there can be only 0 or 1 intermediaries= =20 > in the resolution, but should allow several. (We already have suggested= =20 > cases where at least two are needed, one to determine where you are by=20 > asking your vendor, and one to determine who you can talk to by asking=20 > your local regulator.) >=20 > Yours, > Joel >=20 > On 8/9/2012 8:02 PM, Gabor.Bajko@nokia.com wrote: >> Folks, >>=20 >> During the Vancouver F2F discussions we had some good discussions, but >> no agreement on whether an initialization message, as proposed in >> draft-das is necessary or not. >>=20 >> You may check the minutes to see what was said at the mike: >> http://www.ietf.org/proceedings/84/minutes/minutes-84-paws >>=20 >> People spoke mostly in favor, but there were people who also said that >> this message is redundant with registration message. >>=20 >> Question#1: need for an initialization message >>=20 >> Unfortunately we did not have time to discuss the DB discovery aspect, >> and that may be related to this topic. The only DB discovery document >> available currently, >> http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, proposes, >> that the master device contacts a pre-provisioned discovery server and >> provides its location, and in return the discovery server returns the >> URI of the DB for that regulatory domain. At this point, the master >> device knows which DB to contact, but it does not necessarily know what >> regulatory domain that DB belongs to. Thus, it doesn=92t know what are t= he >> operating rules, whether it has to authenticate, or register, etc. >>=20 >> Thus, it seems logical to me that the master device first queries the DB >> to find out the regulatory domain. We even have such a requirement in >> the requirement draft, requirement: >>=20 >> =93P.3: The protocol MUST support determination of >> regulatory domain governing its current location.=94 >>=20 >> The information about the regulatory domain may be cached, and the >> master device may not need to place that query every time, but this >> message exchange may be necessary in certain cases. Any comments to this >> point? >>=20 >> Question#2 >>=20 >> Then, it is a slightly separate issue, if this message exchange has to >> take place, then what additional information the DB returns. draft-das >> proposes that regulatory domain specific information be returned to the >> master device. >>=20 >> Question#3 >>=20 >> Yet another separate point is that draft-das proposes to use this >> initialization message also to initiate client authentication (putting >> shared secret vs cert issue aside for the time being). In cases when the >> master device does not know the regulatory domain it is in, then it does >> not know whether authentication is required in that regulatory domain or >> not; so why would initiate authentication then? Similar comment applies >> to draft-wei, where it is proposed that after DB discovery the master >> device authenticates at TLS layer and performs registration; how does it >> know that it has to authenticate and register, if it doesn=92t know the >> regulatory domain? >>=20 >> In my opinion (chair hat off), the sequence of events should be sg like >> this: >>=20 >> 1.DB discovery (may be skipped if cached information available) >>=20 >> 2.Regulatory domain query (may be skipped if cached information availabl= e) >>=20 >> 3.Authentication (if required) >>=20 >> 4.Registration (if required) >>=20 >> 5.Channel availability query (may be combined with registration?) >>=20 >> Comments are welcome and expected. >>=20 >> -Gabor >>=20 >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >>=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From mksaji@yahoo.com Thu Aug 9 20:32:36 2012 Return-Path: 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 BC3BE11E809A for ; Thu, 9 Aug 2012 20:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[AWL=1.609, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8V-cynXHW9C for ; Thu, 9 Aug 2012 20:32:36 -0700 (PDT) Received: from nm7-vm2.bullet.mail.ne1.yahoo.com (nm7-vm2.bullet.mail.ne1.yahoo.com [98.138.90.155]) by ietfa.amsl.com (Postfix) with ESMTP id C40D911E8087 for ; Thu, 9 Aug 2012 20:32:35 -0700 (PDT) Received: from [98.138.90.52] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 10 Aug 2012 03:32:32 -0000 Received: from [98.138.89.245] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 10 Aug 2012 03:32:32 -0000 Received: from [127.0.0.1] by omp1059.mail.ne1.yahoo.com with NNFMP; 10 Aug 2012 03:32:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 785736.29923.bm@omp1059.mail.ne1.yahoo.com Received: (qmail 78794 invoked by uid 60001); 10 Aug 2012 03:32:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344569552; bh=kj0bLMSmVeHM9iGu66qZmdOMtSmU+r3x3s0pi/d9JJU=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kkZRQTMMSyByRcl5Bb+4a/IhipbTvAicyGizirPNoA919eGILOUGdYgs6xDD3GpfUtSMrHQkXVTH8fZiuT9KOx49pzdOh54VqIRdSpESbb3W9OhguGOLY0tcxIdPLLFqoIOGfohCEdvLG6b3IqGadXij140z1ub2/4ydFwWtqg0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QDNhPYTq6XIFVXnhm5u2obp2CzebevmKttt7GN/EX0BlrD5MatTHtTfaKW0tGsj77/w8su5FViCI0tA+INQ5CZq+MfoSLMah5W5pNteeAriHmmOZSlCP9PGUe934039jOPivX/CPKJxJdVZPYrrAdzB9E4n18iqTpng4OKHCwac=; X-YMail-OSG: FjVH.0AVM1kxyUtX3bvVspp2ki.PvEURdVvrDfozhp.vSJ9 lr1bbK6O.JqV_R2byn06laa2PQVxMiaKOF9EFRzo2RJ0zMb_skM4NYLbYM5u TfLd3AGqfw4MaKlsn5666tbClKHTBpl.K8vpwBTzydqpF3ir1C4rjzQScMwO lZSOvNI88_CJg8vFY6Ebt9X082_OJumCJXL7TJS2aR6rFw0BCmFNyOEs_UHT K7kcSwGkk_pvpay9gQf5u3c1.PCLaKs0sWeFW1R6_NU.TdpaoYOE17WJoKsu fWC7g.dp5TWFGYKa7xSxnKjVw07pDYgZfISqR3hJiTwnJhL13dFfWnmwupVA gd357quhd_Ont7wycfdfgdaTA8KzkpnY31w8TTcblc37WI60ElRm6mOvM_LZ lkfrsMzSkP6uwTaPIbnOsAprDHOmLF2dBr51hDy8K1jS.EdYVyaVFClkV5tN 8rwgzt1r7aDXagd9ITViH0cjKdGrcqgZqz4Oi Received: from [117.192.9.27] by web120301.mail.ne1.yahoo.com via HTTP; Thu, 09 Aug 2012 20:32:32 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFD8F@008-AM1MPN1-006.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E1A8F1@dfweml512-mbx.china.huawei.com> <5A02A514-1CA7-4AB8-8CA7-C9D1214D3F5C@neustar.biz> Message-ID: <1344569552.63088.YahooMailNeo@web120301.mail.ne1.yahoo.com> Date: Thu, 9 Aug 2012 20:32:32 -0700 (PDT) From: Manikkoth Sajeev To: "Rosen, Brian" , Peter McCann In-Reply-To: <5A02A514-1CA7-4AB8-8CA7-C9D1214D3F5C@neustar.biz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1415095519-2110634395-1344569552=:63088" Cc: "paws@ietf.org" Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Manikkoth Sajeev List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 03:32:36 -0000 ---1415095519-2110634395-1344569552=:63088 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =A0=0A'spectrum unit' is it synonymous to 'band' which is a small section o= f spectrum?=0AI too support for the change of wording, as current mobile ra= dio technologies use and switch frequencies, and channels in their regular = operation.=0A=0ABest Regards,=0A=A0=0ASajeev Manikkoth=0AMobile: +918792292= 002=0A=0A =0A=0A________________________________=0A From: "Rosen, Brian" =0ATo: Peter McCann =0ACc:= "paws@ietf.org" =0ASent: Friday, 10 August 2012, 3:54=0ASu= bject: Re: [paws] use cases and requirements document=0A =0A=0AI would like to suggest a more radical change=0A=0AI would like to defi= ne the term: spectrum unit as a unit of spectrum defined by a low and high = frequency and optionally a channel identifier.=A0 Then I would like to use = "spectrum unit" wherever the word "channel" would occur throughout the docu= ment.=A0 In the definition, I would observe that while it is common to hav= e "channels" that are defined with some identifier, the protocol does not d= epend on such an arrangement, but can manage any swath of spectrum defined = by an upper and lower frequency.=0A=0AI'm not attached to the specific term= "spectrum unit" but I don't want to use "channel" as that implies somethin= g that we are not limited by.=0A=0ABrian=0A=0AOn Aug 9, 2012, at 3:57 PM, P= eter McCann wrote:=0A=0A> I think "MAY include ch= annel numbers" is somewhat ambiguous.=A0 I would=0A> prefer "MAY support sp= ecification of this information by channel number".=0A> =0A> -Pete=0A> =0A>= Gabor.Bajko@nokia.com wrote:=0A>> Folks,=0A>> =0A>> =0A>> =0A>> During the= last F2F meeting, there was an agreement to make a slight =0A>> update to = requirement D.7 in http://www.ietf.org/id/draft-ietf-paws-=0A>> problem-stm= t-usecases-rqmts-06.txt > paws-probl= em-stmt-usecases-rqmts-06.txt> , to make channel numbers =0A>> optional to = be supported. Ie, change the current D.7=0A>> =0A>> "The Data Model MUST su= pport specifying a list of available channels.=0A>> The Data Model MUST sup= port specification of this information by =0A>> channel numbers and by star= t and stop frequencies. The Data Model MUST =0A>> support a channel availab= ility schedule and maximum power level for =0A>> each channel in the list."= =0A>> =0A>> to=0A>> =0A>> "The Data Model MUST support specifying a list of= available channels.=0A>> The Data Model MUST support specification of this= information by start =0A>> and stop frequencies and MAY include channel nu= mbers. The Data Model =0A>> MUST support a channel availability schedule an= d maximum power level =0A>> for each channel in the list."=0A>> =0A>> =0A>>= =0A>> I'd like to confirm this change on the list. If anyone has any =0A>>= objections, let me know. Otherwise I'll plan to send the document to =0A>>= the iesg after this change is implemented.=0A>> =0A>> =0A>> =0A>> -=A0 =A0= =A0 =A0 =A0 Gabor=0A> =0A> =0A> =0A> _____________________________________= __________=0A> paws mailing list=0A> paws@ietf.org=0A> https://www.ietf.org= /mailman/listinfo/paws=0A=0A_______________________________________________= =0Apaws mailing list=0Apaws@ietf.org=0Ahttps://www.ietf.org/mailman/listinf= o/paws ---1415095519-2110634395-1344569552=:63088 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
 
'spectrum unit' is it synonymous to 'band' which is a small sec= tion of spectrum?
I too support for the change of= wording, as current mobile radio technologies use and switch frequencies, = and channels in their regular operation.
 
= Best Regards,
 
= Sajeev Manikkoth
Mobile: +918792292002

= From: "Rosen, Brian" <Bria= n.Rosen@neustar.biz>
To: Peter McCann <peter.mccann@huawei.com>
Cc: "paws@ietf.org" <paws@ietf.org>
= Sent: Friday, 10 August 2= 012, 3:54
Subject: Re:= [paws] use cases and requirements document

<as i= ndividual>
I would like to suggest a more radical change

I wou= ld like to define the term: spectrum unit as a unit of spectrum defined by a low and high fr= equency and optionally a channel identifier.  Then I would like to use= "spectrum unit" wherever the word "channel" would occur throughout the doc= ument.  In the definition, I would observe that while it is common to= have "channels" that are defined with some identifier, the protocol does n= ot depend on such an arrangement, but can manage any swath of spectrum defi= ned by an upper and lower frequency.

I'm not attached to the specifi= c term "spectrum unit" but I don't want to use "channel" as that implies so= mething that we are not limited by.

Brian

On Aug 9, 2012, at = 3:57 PM, Peter McCann <Peter.McCann@huawei.com> wrote:=

> I think "MAY include channel numbers" is somewhat ambiguous.&n= bsp; I would
> prefer "MAY support specification of this information by channel number".
>
> -Pete
>
> Gabor.Bajko@nokia.com wrote:
>> Folks,
>>
&g= t;>
>>
>> During the last F2F meeting, there was an = agreement to make a slight
>> update to requirement D.7 in http://www.= ietf.org/id/draft-ietf-paws-
>> problem-stmt-usecases-rqmts-06= .txt <h= ttp://www.ietf.org/id/draft-ietf-
>> paws-problem-stmt-usecase= s-rqmts-06.txt> , to make channel numbers
>> optional to be su= pported. Ie, change the current D.7
>>
>> "The Data Mode= l MUST support specifying a list of available channels.
>> The Dat= a Model MUST support specification of this information by
>> chan= nel numbers and by start and stop frequencies. The Data Model MUST
>>= ; support a channel availability schedule and maximum power level for
&= gt;> each channel in the list."
>>
>> to
>> =
>> "The Data Model MUST support specifying a list of available ch= annels.
>> The Data Model MUST support specification of this infor= mation by start
>> and stop frequencies and MAY include channel n= umbers. The Data Model
>> MUST support a channel availability sch= edule and maximum power level
>> for each channel in the list.">>
>>
>>
>> I'd like to confirm this = change on the list. If anyone has any
>> objections, let me know.= Otherwise I'll plan to send the document to
>> the iesg after th= is change is implemented.
>>
>>
>>
>>= ; -          Gabor
>
>
>
> _______________________________________________
> = paws mailing list
> paws@ietf.org
> https://www.ietf.org/mailman/listi= nfo/paws

_______________________________________________
paws= mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

---1415095519-2110634395-1344569552=:63088-- From teco@inf-net.nl Thu Aug 9 23:37:28 2012 Return-Path: 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 2A2EB21F8621 for ; Thu, 9 Aug 2012 23:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDXOvn8Tq1up for ; Thu, 9 Aug 2012 23:37:27 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 216B921F861E for ; Thu, 9 Aug 2012 23:37:26 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so719112wgb.13 for ; Thu, 09 Aug 2012 23:37:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=JBdFxkxq4hjzwzPdwn/1PDr8h7A02BDNhzIzlb6UMlc=; b=KvSBuGcwZJXA2bZwp0fc/osuCSfukRZ6wjfcovhtAAGb0cyP7PRB6lXK+O5TYKDIkV SygH9TFCK9qLln0tYFkiERa0KdqpczRO8F2ecpwZ7xr54INoceqxL536FTZLLojy1mnh zSE6uwNfHzGzc5rWaJTuo9hsfRx+rN8d7xg5ywyIOnR8x/kXz7XbU6U/KhytbCDe2ui6 x2g7E1exfswsImw1AVrAK+T+UEYw9dIwgUJ9opgeDwx8p9FugdrczzTXQOcFjBUNUFYZ mA8tapyPhgrmtTX2Q+8J08hZ2naqJDHOego4EN6+WnKLi3tsnSl5MY3Tom2kEik7dJcL RYJg== Received: by 10.216.59.7 with SMTP id r7mr1163064wec.19.1344580645456; Thu, 09 Aug 2012 23:37:25 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id fb20sm8944341wid.1.2012.08.09.23.37.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Aug 2012 23:37:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_800CBF7F-788C-4EDE-A1D3-59FC491528BA" From: Teco Boot In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFD8F@008-AM1MPN1-006.mgdnok.nokia.com> Date: Fri, 10 Aug 2012 08:37:23 +0200 Message-Id: <5001C969-0201-46A4-9D6C-C5963A83697E@inf-net.nl> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFD8F@008-AM1MPN1-006.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmQgK6DxGqTHcdtdr/bhnrcoQ3uiMYVZQWdGz5NtG+wlGGitKqxHhGTadU95HlMvGeec1Zg Cc: paws@ietf.org Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 06:37:28 -0000 --Apple-Mail=_800CBF7F-788C-4EDE-A1D3-59FC491528BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 (somewhat late response) A center frequency and channel width is functional equivalent to = start/stop frequencies. So is channel number, with ref to channel number = assignment scheme. For a requirements document, we just need to specify = what is needed. How it is encoded (Hz, wave length, channel ID) is = solution space. Seen our goal to make PAWS somewhat universal (not limited to US TVWS), = I do not prefer using channel numbers. Teco Op 9 aug. 2012, om 21:55 heeft = het volgende geschreven: > Folks, > =20 > During the last F2F meeting, there was an agreement to make a slight = update to requirement D.7 in = http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.txt,= to make channel numbers optional to be supported. Ie, change the = current D.7 > =93The Data Model MUST support specifying a list of available = channels. The Data Model MUST support specification of this information = by channel numbers and by start and stop frequencies. The Data Model = MUST support a channel availability schedule and maximum power level for = each channel in the list.=94 > to > =93The Data Model MUST support specifying a list of available = channels. The Data Model MUST support specification of this information = by start and stop frequencies and MAY include channel numbers. The Data = Model MUST support a channel availability schedule and maximum power = level for each channel in the list.=94 > =20 > I=92d like to confirm this change on the list. If anyone has any = objections, let me know. Otherwise I=92ll plan to send the document to = the iesg after this change is implemented. > =20 > - Gabor > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --Apple-Mail=_800CBF7F-788C-4EDE-A1D3-59FC491528BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 (somewhat late response)

A = center frequency and channel width is functional equivalent to = start/stop frequencies. So is channel number, with ref to channel number = assignment scheme. For a requirements document, we just need to specify = what is needed. How it is encoded (Hz, wave length, channel ID) is = solution space.

Seen our goal to make PAWS = somewhat universal (not limited to US TVWS), I do not prefer using = channel = numbers.

Teco


<= div>Op 9 aug. 2012, om 21:55 heeft <Gabor.Bajko@nokia.com> = <Gabor.Bajko@nokia.com>= het volgende geschreven:

Folks,
 
_______________________________________________
paws = mailing list
paws@ietf.org
Date: Fri, 10 Aug 2012 07:57:03 -0400 Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac1270G36T6rCusXQOOeBuRti150Ew== Message-ID: <69B0F9E9-22DE-4AB0-9DF8-8C859A447186@neustar.biz> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFD8F@008-AM1MPN1-006.mgdnok.nokia.com> <5001C969-0201-46A4-9D6C-C5963A83697E@inf-net.nl> In-Reply-To: <5001C969-0201-46A4-9D6C-C5963A83697E@inf-net.nl> 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: Iplp5AVTNp9rvaF3llr5/w== Content-Type: multipart/alternative; boundary="_000_69B0F9E922DE4AB09DF88C859A447186neustarbiz_" MIME-Version: 1.0 To: Teco Boot Cc: "paws@ietf.org" Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 11:57:07 -0000 --_000_69B0F9E922DE4AB09DF88C859A447186neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable While I don't care if it's center and width or upper/lower, I do think we w= ill define the format in the protocol for interoperability reasons, but don= 't need to do that in requirements. It wouldn't hurt to decide now and use= consistent terms, but we don't need to. I think "band" won't work, as it usually implies a much wider piece of spec= trum that has a common purpose. The TV Band is all the channels. On Aug 10, 2012, at 2:37 AM, Teco Boot > wrote: (somewhat late response) A center frequency and channel width is functional equivalent to start/stop= frequencies. So is channel number, with ref to channel number assignment s= cheme. For a requirements document, we just need to specify what is needed.= How it is encoded (Hz, wave length, channel ID) is solution space. Seen our goal to make PAWS somewhat universal (not limited to US TVWS), I d= o not prefer using channel numbers. Teco Op 9 aug. 2012, om 21:55 heeft > > het volgend= e geschreven: Folks, During the last F2F meeting, there was an agreement to make a slight update= to requirement D.7 in http://www.ietf.org/id/draft-ietf-paws-problem-stmt-= usecases-rqmts-06.txt, to make channel numbers optional to be supported. Ie= , change the current D.7 =93The Data Model MUST support specifying a list of available channels. The= Data Model MUST support specification of this information by channel numbe= rs and by start and stop frequencies. The Data Model MUST support a channel= availability schedule and maximum power level for each channel in the list= .=94 to =93The Data Model MUST support specifying a list of available channels. The= Data Model MUST support specification of this information by start and sto= p frequencies and MAY include channel numbers. The Data Model MUST support = a channel availability schedule and maximum power level for each channel in= the list.=94 I=92d like to confirm this change on the list. If anyone has any objections= , let me know. Otherwise I=92ll plan to send the document to the iesg after= this change is implemented. - Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_69B0F9E922DE4AB09DF88C859A447186neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <as individual>=
While I don't care if it's center and width or upper/lower, I do think= we will define the format in the protocol for interoperability reasons, bu= t don't need to do that in requirements.  It wouldn't hurt to decide n= ow and use consistent terms, but we don't need to.

I thi= nk "band" won't work, as it usually implies a much wider piece of spectrum = that has a common purpose.  The TV Band is all the channels.


<= br class=3D"Apple-interchange-newline">
(somewhat late response)
=
A center frequency and channel width is functional equivalen= t to start/stop frequencies. So is channel number, with ref to channel numb= er assignment scheme. For a requirements document, we just need to specify = what is needed. How it is encoded (Hz, wave length, channel ID) is sol= ution space.

Seen our goal to make PAWS somewhat u= niversal (not limited to US TVWS), I do not prefer using channel numbers.

Teco


Op 9 au= g. 2012, om 21:55 heeft <Gabor.= Bajko@nokia.com> <Gabor.= Bajko@nokia.com> het volgende geschreven:

Folks,
 
During the last F2F meetin= g, there was an agreement to make a slight update to requirement D.7 in http://www.ietf.org/id/draft-ietf-paws-p= roblem-stmt-usecases-rqmts-06.txt, to make channel numbers optional to = be supported. Ie, change the current D.7
=93The Data Model MUST= support specifying a list of available channels. The Data Model MUST suppo= rt specification of this information by channel numbers and by start and st= op frequencies. The Data Model MUST support a channel availability schedule= and maximum power level for each channel in the list.=94
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-b= ottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">to
=93The Data Model MUST support specifying a list of available cha= nnels. The Data Model MUST support specification of this information by sta= rt and stop frequencies and MAY include channel numbers. The Data Model MUS= T support a channel availability schedule and maximum power level for each = channel in the list.=94
 
I=92d like to confir= m this change on the list. If anyone has any objections, let me know. Other= wise I=92ll plan to send the document to the iesg after this change is impl= emented.
 
- = ;         Gabor
________= _______________________________________
paws mailing list
p= aws@ietf.org
https://www.ietf.org/ma= ilman/listinfo/paws

= _______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mai= lman/listinfo/paws

= --_000_69B0F9E922DE4AB09DF88C859A447186neustarbiz_-- From teco@inf-net.nl Fri Aug 10 05:48:50 2012 Return-Path: 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 4A9F221F85FC for ; Fri, 10 Aug 2012 05:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdRK7TnsRP1e for ; Fri, 10 Aug 2012 05:48:49 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1918021F85E7 for ; Fri, 10 Aug 2012 05:48:48 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1024134wib.13 for ; Fri, 10 Aug 2012 05:48:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=fSyxngFqSsFunRZym1AR1mBD9hVa9xLP1RMZ4MGukII=; b=WcPsY+rF/P/5bfjJYEttedSravl0KjXYChrrnZzH5k4dxKZ2udyh1R6HIScAdUsy8I AvxFyEzQw3z+V+VhepMBtvvteKYpbLnUbDD4jILfDsEN2IF98iIwnSMiVuctqf9ZnVD2 jdPxkiTzEk8lH+I3VN/+a0HfzF7An6DCZvf1+dgTB9tFlC8T3H+QE6BCUO5L2jmcI7K7 9j+Ov2G9p0DBU8xLb14x52BauSQ7HzYwWorrnxYc/Kh3jCN5Z2hH6p91fpPyDyl6YdmN KW2RcVoJ+DD27LH9/wVJN2Zley8FRDHUmjnL8fq5uqnpzhYHDSFR+ETTWbcSgDz1sjFc gucg== Received: by 10.180.78.4 with SMTP id x4mr5724972wiw.19.1344602927420; Fri, 10 Aug 2012 05:48:47 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id bc2sm11274080wib.0.2012.08.10.05.48.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 05:48:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_FAC138C3-9079-4074-9F5A-9B9D54102DC5" From: Teco Boot In-Reply-To: <69B0F9E9-22DE-4AB0-9DF8-8C859A447186@neustar.biz> Date: Fri, 10 Aug 2012 14:48:45 +0200 Message-Id: <788E1086-CA18-477F-BE8E-AB90F71E2BA6@inf-net.nl> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFD8F@008-AM1MPN1-006.mgdnok.nokia.com> <5001C969-0201-46A4-9D6C-C5963A83697E@inf-net.nl> <69B0F9E9-22DE-4AB0-9DF8-8C859A447186@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnfHpErMUd1g+1iT/7xbvvwRMtuDRJi+937DO5Urwm6yg6wRjNhjvHS6GKErw9iCkHgRsBm Cc: "paws@ietf.org" Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 12:48:50 -0000 --Apple-Mail=_FAC138C3-9079-4074-9F5A-9B9D54102DC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 What about this: =93The Data Model MUST support specifying a list of available channels. = The Data Model MUST support specification of this information by start = and stop frequencies, or equivalents such as center frequencies with = channel width or channel numbers with channel nummer allocation scheme . = The Data Model MUST support a channel availability schedule and maximum = power level for each channel in the list.=94 More thoughts on channel numbers: we likely run into problems in bands = without a channel numbering scheme, or for example sub channels in TV = bands. Teco Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende geschreven: > > While I don't care if it's center and width or upper/lower, I do think = we will define the format in the protocol for interoperability reasons, = but don't need to do that in requirements. It wouldn't hurt to decide = now and use consistent terms, but we don't need to. >=20 > I think "band" won't work, as it usually implies a much wider piece of = spectrum that has a common purpose. The TV Band is all the channels. >=20 >=20 > On Aug 10, 2012, at 2:37 AM, Teco Boot wrote: >=20 >> (somewhat late response) >>=20 >> A center frequency and channel width is functional equivalent to = start/stop frequencies. So is channel number, with ref to channel number = assignment scheme. For a requirements document, we just need to specify = what is needed. How it is encoded (Hz, wave length, channel ID) is = solution space. >>=20 >> Seen our goal to make PAWS somewhat universal (not limited to US = TVWS), I do not prefer using channel numbers. >>=20 >> Teco >>=20 >>=20 >> Op 9 aug. 2012, om 21:55 heeft = het volgende geschreven: >>=20 >>> Folks, >>> =20 >>> During the last F2F meeting, there was an agreement to make a slight = update to requirement D.7 in = http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.txt,= to make channel numbers optional to be supported. Ie, change the = current D.7 >>> =93The Data Model MUST support specifying a list of available = channels. The Data Model MUST support specification of this information = by channel numbers and by start and stop frequencies. The Data Model = MUST support a channel availability schedule and maximum power level for = each channel in the list.=94 >>> to >>> =93The Data Model MUST support specifying a list of available = channels. The Data Model MUST support specification of this information = by start and stop frequencies and MAY include channel numbers. The Data = Model MUST support a channel availability schedule and maximum power = level for each channel in the list.=94 >>> =20 >>> I=92d like to confirm this change on the list. If anyone has any = objections, let me know. Otherwise I=92ll plan to send the document to = the iesg after this change is implemented. >>> =20 >>> - Gabor >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 --Apple-Mail=_FAC138C3-9079-4074-9F5A-9B9D54102DC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
=93The Data Model MUST support = specifying a list of available channels. The Data Model MUST support = specification of this information by start and stop frequencies, or = equivalents such as center frequencies with channel width or channel = numbers with channel nummer allocation scheme . The Data Model MUST = support a channel availability schedule and maximum power level for each = channel in the = list.=94

More thoughts on channel numbers: we likely = run into problems in bands without a channel numbering scheme, or for = example sub channels in TV = bands.

Teco


Op = 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende = geschreven:



On Aug 10, 2012, = at 2:37 AM, Teco Boot <teco@inf-net.nl> wrote:

Gabor.Bajko@nokia.com> = <Gabor.Bajko@nokia.com>= het volgende geschreven:

Folks,
 
_______________________________________________
paws = mailing list
paws@ietf.org
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws


= --Apple-Mail=_FAC138C3-9079-4074-9F5A-9B9D54102DC5-- From teco@inf-net.nl Fri Aug 10 06:02:35 2012 Return-Path: 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 1217421F857D for ; Fri, 10 Aug 2012 06:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.263 X-Spam-Level: X-Spam-Status: No, score=-3.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIMZS3hTjcoZ for ; Fri, 10 Aug 2012 06:02:34 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4911821F8564 for ; Fri, 10 Aug 2012 06:02:34 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1033029wib.13 for ; Fri, 10 Aug 2012 06:02:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer:x-gm-message-state; bh=FXznMejkSaXJqjWiJcPmn/YcYQ621Fn8bb7+uvbMGKk=; b=OFWYL37tIR1q7RGrYA2GOperCMfjUfsQ4urnSxBUGWMYgO/mBQHRoBRp6lCf/R4Ilr TB19LSoKiA6+sp0Swq1GrW8IChNCtLt09f8T0es67w/WPtGP/d+Q7p5p29LhMyfGjeXc kgVlAkFAqAyKVpm86PeGpmoH6jHz4ZzrkZRWCZEnv2VQP9rV8WlYZi68kn+f1/icETdd d67GZP1xkLkDdcrFVGMNXpyt+uigds72Ap758Lcsc2f+Af7hmxkbNN34Qf/TAn9dTSQn MEYyVTLKVuIPcYMhKlNzftpKZyuGOGjwOwMVLRK1rNRJNbyYVSHClZUP5XJUsu+Z1zjS xRWw== Received: by 10.217.3.129 with SMTP id r1mr1532262wes.22.1344603753070; Fri, 10 Aug 2012 06:02:33 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id dc3sm7632282wib.7.2012.08.10.06.02.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 06:02:32 -0700 (PDT) From: Teco Boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Aug 2012 15:02:31 +0200 Message-Id: <3C0D804F-2866-4063-828A-CA840F88161E@inf-net.nl> To: paws@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnC1dI0x3TX6jJYqcJ8aqD77rBdFOb1aIdsSAdA/A5y6lTUqB0QYnczeXEZcTzIwiZSMATE Subject: [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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 13:02:35 -0000 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 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 Teco= From ben@blindcreek.com Fri Aug 10 08:25:48 2012 Return-Path: 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 C36D421F8501 for ; Fri, 10 Aug 2012 08:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7E1Oqhb7BlJ for ; Fri, 10 Aug 2012 08:25:48 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAAD21F84F6 for ; Fri, 10 Aug 2012 08:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=WAJJxr7L8xlPL4H9ChIkrQ2UEm2vIdW3G2Nyw3edplU=; b=KJGANzDXgVxLVjp5kId4TG6jZfBHYRcpaXi2RBoNo7NQbxXYPx5MlPlsWjpK7545+UNzLiKU6NpMpM4QUfd+Hsvnh15z6CFcx0Sk2x4eXaclSS+fqzpjObnShhKSSwjz; Received: from [64.74.213.174] (port=51555 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1Szr5l-00073w-5K for paws@ietf.org; Fri, 10 Aug 2012 10:25:37 -0500 Message-ID: <502527F5.2040305@blindcreek.com> Date: Fri, 10 Aug 2012 08:25:41 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: paws@ietf.org References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFD8F@008-AM1MPN1-006.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E1A8F1@dfweml512-mbx.china.huawei.com> <5A02A514-1CA7-4AB8-8CA7-C9D1214D3F5C@neustar.biz> <1344569552.63088.YahooMailNeo@web120301.mail.ne1.yahoo.com> In-Reply-To: <1344569552.63088.YahooMailNeo@web120301.mail.ne1.yahoo.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 15:25:48 -0000 "spectrum unit" if it is precisely defined as suggested has the advantage of being non-obvious enough people may not assume they know what it means  and so may actually read the definition :-).   Specifying a "spectrum unit" by start and end frequency is adequate, as it accommodates the current FCC requirements (TV channels), with flexibility to handle more granular specification which may be needed in the future.   Alternatively I could offer "chunk of spectrum" but I suspect that is less appropriate sounding for a standard ;-).

Avoid the word "channel" without further qualification (like "TV channel" as in FCC 15.70x), where ever possible, as it is overloaded so much that people ofte assume a meaning different than what you mean.

Regards
-Ben



 
'spectrum unit' is it synonymous to 'band' which is a small section of spectrum?
I too support for the change of wording, as current mobile radio technologies use and switch frequencies, and channels in their regular operation.
 
Best Regards,
 
Sajeev Manikkoth
Mobile: +918792292002

From: "Rosen, Brian" <Brian.Rosen@neustar.biz>
To: Peter McCann <peter.mccann@huawei.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Sent: Friday, 10 August 2012, 3:54
Subject: Re: [paws] use cases and requirements document

<as individual>
I would like to suggest a more radical change

I would like to define the term: spectrum unit as a unit of spectrum defined by a low and high frequency and optionally a channel identifier.  Then I would like to use "spectrum unit" wherever the word "channel" would occur throughout the document.  In the definition, I would observe that while it is common to have "channels" that are defined with some identifier, the protocol does not depend on such an arrangement, but can manage any swath of spectrum defined by an upper and lower frequency.

I'm not attached to the specific term "spectrum unit" but I don't want to use "channel" as that implies something that we are not limited by.

Brian

On Aug 9, 2012, at 3:57 PM, Peter McCann <Peter.McCann@huawei.com> wrote:

> I think "MAY include channel numbers" is somewhat ambiguous.  I would
> prefer "MAY support specification of this information by channel number".
>
> -Pete
>
> Gabor.Bajko@nokia.com wrote:
>> Folks,
>>
>>
>>
>> During the last F2F meeting, there was an agreement to make a slight
>> update to requirement D.7 in http://www.ietf.org/id/draft-ietf-paws-
>> problem-stmt-usecases-rqmts-06.txt <http://www.ietf.org/id/draft-ietf-
>> paws-problem-stmt-usecases-rqmts-06.txt> , to make channel numbers
>> optional to be supported. Ie, change the current D.7
>>
>> "The Data Model MUST support specifying a list of available channels.
>> The Data Model MUST support specification of this information by
>> channel numbers and by start and stop frequencies. The Data Model MUST
>> support a channel availability schedule and maximum power level for
>> each channel in the list."
>>
>> to
>>
>> "The Data Model MUST support specifying a list of available channels.
>> The Data Model MUST support specification of this information by start
>> and stop frequencies and MAY include channel numbers. The Data Model
>> MUST support a channel availability schedule and maximum power level
>> for each channel in the list."
>>
>>
>>
>> I'd like to confirm this change on the list. If anyone has any
>> objections, let me know. Otherwise I'll plan to send the document to
>> the iesg after this change is implemented.
>>
>>
>>
>> -          Gabor
>
>
>
> _______________________________________________
> paws mailing list
> paws@ietf.org
> https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws



_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

From Gabor.Bajko@nokia.com Fri Aug 10 08:43:35 2012 Return-Path: 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 7808821F875A for ; Fri, 10 Aug 2012 08:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj4kqEIsg9-5 for ; Fri, 10 Aug 2012 08:43:35 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7159221F8749 for ; Fri, 10 Aug 2012 08:43:33 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7AFhVRM028680; Fri, 10 Aug 2012 18:43:32 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Aug 2012 18:44:29 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0283.004; Fri, 10 Aug 2012 17:43:31 +0200 From: To: , Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: AQHNdvhu7Nd2WNzPm0+85/tpR52R7ZdTK50g Date: Fri, 10 Aug 2012 15:43:30 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB0637@008-AM1MPN1-006.mgdnok.nokia.com> References: <3C0D804F-2866-4063-828A-CA840F88161E@inf-net.nl> In-Reply-To: <3C0D804F-2866-4063-828A-CA840F88161E@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.113.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Aug 2012 15:44:29.0471 (UTC) FILETIME=[07530AF0:01CD770F] X-Nokia-AV: Clean 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 15:43:35 -0000 Yes, there was a discussion on what representation/encoding we should use, = JSON or XML. We took hums in the room to see preferences, and there was str= ong preference towards using JSON. One technical issue which came up: not all data structures we may want to r= euse have a JSON representation, some only have XML. Can JSON include XML d= ata structures, if yes, can someone point to a doc describing it? Otherwis= e we'll have to redefine them in JSON (this is what draft-das is actually d= oing). Let me ask this: are there any objections to using JSON representation for = the data format? Does anyone think that XML would be a better choice, and w= hy? - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Teco Boot Sent: Friday, August 10, 2012 6:03 AM To: paws@ietf.org Subject: [paws] XML schema versus JSON, vCard & iCal We had a discussion on XML vs. JSON. I prefer the one with most compact mes= sages. On vCard and JSON: what is the status of "A JavaScript Object Notation (JSO= N) Representation for vCard"? http://tools.ietf.org/html/draft-bhat-vcarddav-json-00 On valid times: can we use same format as certificates? They have similar s= imple requirements: valid notBefore & notAfter. http://tools.ietf.org/html/rfc3280#section-4.1.2.5 Teco _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From ben@blindcreek.com Fri Aug 10 09:10:20 2012 Return-Path: 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 9E60721F87AD for ; Fri, 10 Aug 2012 09:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPiBMggNcgso for ; Fri, 10 Aug 2012 09:10:20 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id D226021F87A3 for ; Fri, 10 Aug 2012 09:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=k3QGsOhLv1QMgh5aFZWfYsgdn9e+38Hk6uGYEKBG/4c=; b=wSCC0PVjlAfRyPwu6kF4g9KtYddQyPr/azRA1YBOLcAHuC9eHBznBldFE53rucg9HgsV0Lgqne1j7uJEvw/4BxIRVHfc5bGJ0obgT+SKQZTfbojevFn5hIVHlmBcicHm; Received: from [64.74.213.174] (port=51257 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1Szrmz-0006S1-2L for paws@ietf.org; Fri, 10 Aug 2012 11:10:17 -0500 Message-ID: <5025326D.8090000@blindcreek.com> Date: Fri, 10 Aug 2012 09:10:21 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: paws@ietf.org References: <3C0D804F-2866-4063-828A-CA840F88161E@inf-net.nl> In-Reply-To: <3C0D804F-2866-4063-828A-CA840F88161E@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:10:20 -0000 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). 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 > > 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 > > Teco > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From Gabor.Bajko@nokia.com Fri Aug 10 16:33:23 2012 Return-Path: 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 87B5E11E80BF for ; Fri, 10 Aug 2012 16:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCxL2BZcQWDg for ; Fri, 10 Aug 2012 16:33:22 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8126211E80A3 for ; Fri, 10 Aug 2012 16:33:22 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7ANXKPw018050 for ; Sat, 11 Aug 2012 02:33:20 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 Aug 2012 02:34:19 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0283.004; Sat, 11 Aug 2012 01:33:19 +0200 From: To: Thread-Topic: [paws] need for DB initialization message Thread-Index: Ac12he0A+5h4j+uqT6e4F6BpK7EzXwAAEnAAADHrtdA= Date: Fri, 10 Aug 2012 23:33:18 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB0839@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F@008-AM1MPN1-006.mgdnok.nokia.com> <502462F4.8000002@joelhalpern.com> In-Reply-To: <502462F4.8000002@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.243.187.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Aug 2012 23:34:19.0074 (UTC) FILETIME=[A9A31A20:01CD7750] X-Nokia-AV: Clean Subject: Re: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 23:33:23 -0000 While I agree that re-direction from an intermediary to the final recipient= should not be disallowed, I don't think the use case you are describing is= a valid one. The master needs to know its location before engaging into DB= discovery. If it doesn't, then it can use some existing mechanism to find = it out (eg, RFC5985) prior to the DB discovery process, but that for me is = a separate transaction. The current DB discovery mechanism described in http://www.ietf.org/id/draf= t-probasco-paws-discovery-01.txt assumes that the master knows its location= before performing DB discovery; after which it needs to do a regulatory do= main discovery as well. Brian suggested regulatory domain could be a parame= ter of the DB URI, thus no need for separate regulatory domain discovery. A= ny other suggestions? - Gabor=20 -----Original Message----- From: ext Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Thursday, August 09, 2012 6:25 PM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: paws@ietf.org Subject: Re: [paws] need for DB initialization message Related suggestion: Assuming we have a discovery protocol which can return= a URI, the protocol semantics should be such that the URI can be the final= DB URI, or another intermediary in the process. Thus, the protocol should= not lock in that there can be only 0 or 1 intermediaries in the resolution= , but should allow several. (We already have suggested cases where at leas= t two are needed, one to determine where you are by asking your vendor, and= one to determine who you can talk to by asking your local regulator.) Yours, Joel On 8/9/2012 8:02 PM, Gabor.Bajko@nokia.com wrote: > Folks, > > During the Vancouver F2F discussions we had some good discussions, but > no agreement on wether an initialization message, as proposed in > draft-das is necessary or not. > > You may check the minutes to see what was said at the mike: > http://www.ietf.org/proceedings/84/minutes/minutes-84-paws > > People spoke mostly in favor, but there were people who also said that > this message is redundant with registration message. > > Question#1: need for an initialization message > > Unfortunately we did not have time to discuss the DB discovery aspect, > and that may be related to this topic. The only DB discovery document > available currently, > http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, proposes, > that the master device contacts a pre-provisioned discovery server and > provides its location, and in return the discovery server returns the > URI of the DB for that regulatory domain. At this point, the master > device knows which DB to contact, but it does not necessarily know what > regulatory domain that DB belongs to. Thus, it doesn't know what are the > operating rules, whether it has to authenticate, or register, etc. > > Thus, it seems logical to me that the master device first queries the DB > to find out the regulatory domain. We even have such a requirement in > the requirement draft, requirement: > > "P.3: The protocol MUST support determination of > regulatory domain governing its current location." > > The information about the regulatory domain may be cached, and the > master device may not need to place that query every time, but this > message exchange may be necessary in certain cases. Any comments to this > point? > > Question#2 > > Then, it is a slightly separate issue, if this message exchange has to > take place, then what additional information the DB returns. draft-das > proposes that regulatory domain specific information be returned to the > master device. > > Question#3 > > Yet another separate point is that draft-das proposes to use this > initialization message also to initiate client authentication (putting > shared secret vs cert issue aside for the time being). In cases when the > master device does not know the regulatory domain it is in, then it does > not know whether authentication is required in that regulatory domain or > not; so why would initiate authentication then? Similar comment applies > to draft-wei, where it is proposed that after DB discovery the master > device authenticates at TLS layer and performs registration; how does it > know that it has to authenticate and register, if it doesn't know the > regulatory domain? > > In my opinion (chair hat off), the sequence of events should be sg like > this: > > 1.DB discovery (may be skipped if cached information available) > > 2.Regulatory domain query (may be skipped if cached information available= ) > > 3.Authentication (if required) > > 4.Registration (if required) > > 5.Channel availability query (may be combined with registration?) > > Comments are welcome and expected. > > -Gabor > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From jmh@joelhalpern.com Fri Aug 10 17:17:35 2012 Return-Path: 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 2DFC321F8497 for ; Fri, 10 Aug 2012 17:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYhdkQr3JaqN for ; Fri, 10 Aug 2012 17:17:34 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6479821F8496 for ; Fri, 10 Aug 2012 17:17:34 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 03618A3764 for ; Fri, 10 Aug 2012 17:17:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 69DF71C07EA; Fri, 10 Aug 2012 17:17:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.1.7] (c-71-204-207-35.hsd1.de.comcast.net [71.204.207.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 65CA51C0179; Fri, 10 Aug 2012 17:17:30 -0700 (PDT) Message-ID: <5025A48C.2090009@joelhalpern.com> Date: Fri, 10 Aug 2012 20:17:16 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Gabor.Bajko@nokia.com References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F@008-AM1MPN1-006.mgdnok.nokia.com> <502462F4.8000002@joelhalpern.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB0839@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB0839@008-AM1MPN1-006.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 00:17:35 -0000 The master has to know its location in geographic coordinates (GPS, etc.) As far as I know, we have not assumed that the maps to translate that into political domains are known to the master a priori. There are deployment scenarios (cell towers come to mind) where the master can probably be provisioned with the right administrative information. There are other scenarios where that is not obviously achievable. Yours, Joel On 8/10/2012 7:33 PM, Gabor.Bajko@nokia.com wrote: > While I agree that re-direction from an intermediary to the final recipient should not be disallowed, I don't think the use case you are describing is a valid one. The master needs to know its location before engaging into DB discovery. If it doesn't, then it can use some existing mechanism to find it out (eg, RFC5985) prior to the DB discovery process, but that for me is a separate transaction. > > The current DB discovery mechanism described in http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt assumes that the master knows its location before performing DB discovery; after which it needs to do a regulatory domain discovery as well. Brian suggested regulatory domain could be a parameter of the DB URI, thus no need for separate regulatory domain discovery. Any other suggestions? > > - Gabor > > -----Original Message----- > From: ext Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Thursday, August 09, 2012 6:25 PM > To: Bajko Gabor (Nokia-CIC/SiliconValley) > Cc: paws@ietf.org > Subject: Re: [paws] need for DB initialization message > > Related suggestion: Assuming we have a discovery protocol which can return a URI, the protocol semantics should be such that the URI can be the final DB URI, or another intermediary in the process. Thus, the protocol should not lock in that there can be only 0 or 1 intermediaries in the resolution, but should allow several. (We already have suggested cases where at least two are needed, one to determine where you are by asking your vendor, and one to determine who you can talk to by asking your local regulator.) > > Yours, > Joel > > On 8/9/2012 8:02 PM, Gabor.Bajko@nokia.com wrote: >> Folks, >> >> During the Vancouver F2F discussions we had some good discussions, but >> no agreement on wether an initialization message, as proposed in >> draft-das is necessary or not. >> >> You may check the minutes to see what was said at the mike: >> http://www.ietf.org/proceedings/84/minutes/minutes-84-paws >> >> People spoke mostly in favor, but there were people who also said that >> this message is redundant with registration message. >> >> Question#1: need for an initialization message >> >> Unfortunately we did not have time to discuss the DB discovery aspect, >> and that may be related to this topic. The only DB discovery document >> available currently, >> http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, proposes, >> that the master device contacts a pre-provisioned discovery server and >> provides its location, and in return the discovery server returns the >> URI of the DB for that regulatory domain. At this point, the master >> device knows which DB to contact, but it does not necessarily know what >> regulatory domain that DB belongs to. Thus, it doesn't know what are the >> operating rules, whether it has to authenticate, or register, etc. >> >> Thus, it seems logical to me that the master device first queries the DB >> to find out the regulatory domain. We even have such a requirement in >> the requirement draft, requirement: >> >> "P.3: The protocol MUST support determination of >> regulatory domain governing its current location." >> >> The information about the regulatory domain may be cached, and the >> master device may not need to place that query every time, but this >> message exchange may be necessary in certain cases. Any comments to this >> point? >> >> Question#2 >> >> Then, it is a slightly separate issue, if this message exchange has to >> take place, then what additional information the DB returns. draft-das >> proposes that regulatory domain specific information be returned to the >> master device. >> >> Question#3 >> >> Yet another separate point is that draft-das proposes to use this >> initialization message also to initiate client authentication (putting >> shared secret vs cert issue aside for the time being). In cases when the >> master device does not know the regulatory domain it is in, then it does >> not know whether authentication is required in that regulatory domain or >> not; so why would initiate authentication then? Similar comment applies >> to draft-wei, where it is proposed that after DB discovery the master >> device authenticates at TLS layer and performs registration; how does it >> know that it has to authenticate and register, if it doesn't know the >> regulatory domain? >> >> In my opinion (chair hat off), the sequence of events should be sg like >> this: >> >> 1.DB discovery (may be skipped if cached information available) >> >> 2.Regulatory domain query (may be skipped if cached information available) >> >> 3.Authentication (if required) >> >> 4.Registration (if required) >> >> 5.Channel availability query (may be combined with registration?) >> >> Comments are welcome and expected. >> >> -Gabor >> >> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From teco@inf-net.nl Sat Aug 11 02:30:41 2012 Return-Path: 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 D770721F8464 for ; Sat, 11 Aug 2012 02:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.257 X-Spam-Level: X-Spam-Status: No, score=-3.257 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQ0XF00UgVth for ; Sat, 11 Aug 2012 02:30:41 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF5721F845C for ; Sat, 11 Aug 2012 02:30:40 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1351460wgb.13 for ; Sat, 11 Aug 2012 02:30:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=d4BLRpCToM6jt9K4Q+n4q1Xc9eEl6dN/OmQvowGZ8io=; b=RUZocMXPi0ldw7UBapX+QwA0FUWZfdnEHz9mlUdOf09feY8emd6dc5sfM/zRzus5ik lSEGFkTWUAHUsWrkp1IKOJTrHGAE7FNbmH+XmM6Q181dGw5tiMdeYWZ3XHb2p+FimouR cke/oCLlsqh5WzQh/PmPSyVCXbOQ+7Tmz9QbM7yZF5IaHv1JEE2Xe6NT5Fau7IK2WCQZ K+pAcKcAjVjPGg/X6IF66mcr/aZnwt6B4/avKBZg2h1Xz1xNC598TzdbZvJ6MhRe7MXK 8aR5Jz5BA5p5C3autXYMIlkVFiAw5wYKxl2BZI7i9Dc5v0gRbWQIIgCPMy2lsTZzXM4b fBcg== Received: by 10.180.80.134 with SMTP id r6mr2779246wix.1.1344677439038; Sat, 11 Aug 2012 02:30:39 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id bc2sm4245863wib.0.2012.08.11.02.30.38 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Aug 2012 02:30:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <5025326D.8090000@blindcreek.com> Date: Sat, 11 Aug 2012 11:30:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C0D804F-2866-4063-828A-CA840F88161E@inf-net.nl> <5025326D.8090000@blindcreek.com> To: Benjamin A. Rolfe X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnpsI48VSIY8YxJ55gsSTRzKTyc0u7PbVvMBZpP8XhHXcHzwn6Gx8WxUYXAExnJlQwhriGK Cc: paws@ietf.org 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 09:30:42 -0000 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.=20 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 >=20 >=20 >> We had a discussion on XML vs. JSON. I prefer the one with most = compact messages. >>=20 >> 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 >>=20 >> 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 >>=20 >> Teco >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >>=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From peter@spectrumbridge.com Sat Aug 11 04:13:00 2012 Return-Path: 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 7DB1421F855B for ; Sat, 11 Aug 2012 04:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGkbRQANS9jq for ; Sat, 11 Aug 2012 04:13:00 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id C423F21F8517 for ; Sat, 11 Aug 2012 04:12:59 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Sat, 11 Aug 2012 07:12:58 -0400 From: Peter Stanforth To: Teco Boot , Benjamin A.Rolfe Date: Sat, 11 Aug 2012 07:12:55 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac13skMHMqAV0sU4SmysFmOfQFQHnA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 11:13:00 -0000 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" 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.=20 > >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 >>=20 >>=20 >>> We had a discussion on XML vs. JSON. I prefer the one with most >>>compact messages. >>>=20 >>> 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 >>>=20 >>> 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 >>>=20 >>> Teco >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From ericchu@google.com Sat Aug 11 08:43:31 2012 Return-Path: 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 5138A21F85DA for ; Sat, 11 Aug 2012 08:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1rZxCVr-HhL for ; Sat, 11 Aug 2012 08:43:28 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD3D21F8585 for ; Sat, 11 Aug 2012 08:43:28 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4517064pbb.31 for ; Sat, 11 Aug 2012 08:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Cn7jlq1TQUYKPFJnneQXICOcbPeaOCrBoy/HeqyWLEU=; b=omDrm+5KiPSGbtRfFvRstyRthyrT/Q/2NKpyxrBMfS7v0x4biwSpTMuXiR8mVUMYcX ZhlXH1noCBcLgs/nL4M9hKGsvhTt8Ne/zx5GQV0yG/HIH0xzaayYNuXBjpJu97xdnEKd 2w8Nr4s17US3uahjhZrQqTDQJZCudx5BBvpkorzUvS2Q8WcycIhzrBIX3FwfoCeIlT6n uMyseJzKgxmeNVj+t1KM3flVuV1pGXD7RL056igaCl+LZWMQaH36oU43xyYumYudok0N UDYwDs20yy8CSJBto6FPPStyMV1Hg348QH9zqircfzAdKMoLGFd38cDDEmg5MnmUDjiV deIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=Cn7jlq1TQUYKPFJnneQXICOcbPeaOCrBoy/HeqyWLEU=; b=fAuxDS+9yW2GWIhtYvEJKOKER9wYJ5eBbqNdwQB10J6TQMEF1HXOyQLd/djynbq2Xn s/CyWZUHxFlP7xz9pcAPn1E/m9HwRhto1pm/80mzfP0L4Dgyo6dQZ9Bs6curq+by6yQa WGti9wJ5oV/jc5GrAEPeop34LwddH31ni8MQd0+AebBUr1CUch8NEE/j0KJHm4U+IP/q 5/lvP0XPLfSodfmhFawdjtjgdwe+ChuRDgcifSm+GR89plli70DliMWCLf1OjM/yOgvY OwUjKaQRHiiUk/FMb57GkPDDLDS2nOQf0LT9fgPcGfAS8nvM344XhiGMaIgYET8Mac3U ZrZg== Received: by 10.68.116.48 with SMTP id jt16mr21190990pbb.101.1344699807980; Sat, 11 Aug 2012 08:43:27 -0700 (PDT) Received: by 10.68.116.48 with SMTP id jt16mr21190956pbb.101.1344699807672; Sat, 11 Aug 2012 08:43:27 -0700 (PDT) Received: from ericchu-macbookair.local (c-24-4-109-42.hsd1.ca.comcast.net. [24.4.109.42]) by mx.google.com with ESMTPS id oj8sm1580325pbb.54.2012.08.11.08.43.26 (version=SSLv3 cipher=OTHER); Sat, 11 Aug 2012 08:43:26 -0700 (PDT) Message-ID: <50267D9F.6000703@google.com> Date: Sat, 11 Aug 2012 08:43:27 -0700 From: Eric Chu User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Teco Boot References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFD8F@008-AM1MPN1-006.mgdnok.nokia.com> <5001C969-0201-46A4-9D6C-C5963A83697E@inf-net.nl> <69B0F9E9-22DE-4AB0-9DF8-8C859A447186@neustar.biz> <788E1086-CA18-477F-BE8E-AB90F71E2BA6@inf-net.nl> In-Reply-To: <788E1086-CA18-477F-BE8E-AB90F71E2BA6@inf-net.nl> Content-Type: multipart/alternative; boundary="------------070103060908010502090706" X-Gm-Message-State: ALoCoQlSvhz6AXbqYtLg49OOLr5R+hh+1/W/H5BTrKs5858YLPN829rfgVW+vuXfWmSIwT2GE+4+vRWGcMGCY5hAf/HfCvM+OLL3KB7nzR4ag+kwMhixIzPoRphUx4NoMp+JWM5AL2saXS64qWP1fPJp2dsWXOhN/mHp1WbnkEUxV/EMB7VqXXxb4OHKd+AehTiHDnhpgEUC Cc: "paws@ietf.org" Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 15:43:31 -0000 This is a multi-part message in MIME format. --------------070103060908010502090706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit *Hi everyone, Gathering all the shared points from everyone... I believe below is the complete list so far: * What's the best consistent representation of the words "channel numbers" for non-TV spectrum * Should we update the entire doc on the topic of "channel" or "channel numbers" * What's the best way to reduce vagueness in whether/how to include "channel numbers" * Is the reference to variable power required * What does channel availability schedule mean Brian's suggestion of replacing every instance of "channel" is technically correctly. However, it is important for us to focus moving forward. I would suggest we only work on the normative part of the spec. The section Gabor is proposing for us to modify... On what's the best generic label for the words "channel numbers", channel identifier might be the most accurate and neutral "label". Thoughts? On the question whether variable power is required, based on FCC adjacent-channel rules, the database may limit the Mode II devices to 100mW for some channels and 40mW for others. Therefore, the data model needs to support specification of maximum power levels. Lastly, with regards to "schedule", the intent is to have a way of informing devices when to operate for each frequency range. As long as the data model supports, for example, a list of time ranges, it does not prevent an implementation from providing a list with 1 entry which corresponds to the "shortest available". The word "schedule" should be sufficient to capture this intent? We would like to propose the following text to address these points: "The Data Model MUST support specifying available spectrum. The Data Model MUST support specification of this information by start and stop frequencies and MAY also support specification of this information by channel identifiers. The Data Model MUST support a spectrum-availability schedule and maximum power levels for each frequency range."** **Thoughts? Eric * On 8/10/12 5:48 AM, Teco Boot wrote: > What about this: > > "The Data Model MUST support specifying a list of available channels. > The Data Model MUST support specification of this information by start > and stop frequencies, or equivalents such as center frequencies with > channel width or channel numbers with channel nummer allocation scheme > . The Data Model MUST support a channel availability schedule and > maximum power level for each channel in the list." > > More thoughts on channel numbers: we likely run into problems in bands > without a channel numbering scheme, or for example sub channels in TV > bands. > > Teco > > > Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende geschreven: > >> >> While I don't care if it's center and width or upper/lower, I do >> think we will define the format in the protocol for interoperability >> reasons, but don't need to do that in requirements. It wouldn't hurt >> to decide now and use consistent terms, but we don't need to. >> >> I think "band" won't work, as it usually implies a much wider piece >> of spectrum that has a common purpose. The TV Band is all the channels. >> >> >> On Aug 10, 2012, at 2:37 AM, Teco Boot > > wrote: >> >>> (somewhat late response) >>> >>> A center frequency and channel width is functional equivalent to >>> start/stop frequencies. So is channel number, with ref to channel >>> number assignment scheme. For a requirements document, we just need >>> to specify what is needed. How it is encoded (Hz, wave length, >>> channel ID) is solution space. >>> >>> Seen our goal to make PAWS somewhat universal (not limited to US >>> TVWS), I do not prefer using channel numbers. >>> >>> Teco >>> >>> >>> Op 9 aug. 2012, om 21:55 heeft >> > >> > het volgende geschreven: >>> >>>> Folks, >>>> During the last F2F meeting, there was an agreement to make a >>>> slight update to requirement D.7 >>>> inhttp://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.txt, >>>> to make channel numbers optional to be supported. Ie, change the >>>> current D.7 >>>> "The Data Model MUST support specifying a list of available >>>> channels. The Data Model MUST support specification of this >>>> information by channel numbers and by start and stop frequencies. >>>> The Data Model MUST support a channel availability schedule and >>>> maximum power level for each channel in the list." >>>> to >>>> "The Data Model MUST support specifying a list of available >>>> channels. The Data Model MUST support specification of this >>>> information by start and stop frequencies and MAY include channel >>>> numbers. The Data Model MUST support a channel availability >>>> schedule and maximum power level for each channel in the list." >>>> I'd like to confirm this change on the list. If anyone has any >>>> objections, let me know. Otherwise I'll plan to send the document >>>> to the iesg after this change is implemented. >>>> -Gabor >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --------------070103060908010502090706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi everyone,

Gathering all the shared points from everyone... I believe below is the complete list so far:

  • What's the best consistent representation of the words "channel numbers" for non-TV spectrum
  • Should we update the entire doc on the topic of “channel” or “channel numbers”
  • What’s the best way to reduce vagueness in whether/how to include "channel numbers"
  • Is the reference to variable power required
  • What does channel availability schedule mean

Brian's suggestion of replacing every instance of "channel" is technically correctly. However, it is important for us to focus moving forward.  I would suggest we only work on the normative part of the spec.  The section Gabor is proposing for us to modify...  

On what's the best generic label for the words "channel numbers", channel identifier might be the most accurate and neutral "label".  Thoughts?

On the question whether variable power is required, based on FCC adjacent-channel rules, the database may limit the Mode II devices to 100mW for some channels and 40mW for others. Therefore, the data model needs to support specification of maximum power levels.

Lastly, with regards to "schedule", the intent is to have a way of informing devices when to operate for each frequency range. As long as the data model supports, for example, a list of time ranges, it does not prevent an implementation from providing a list with 1 entry which corresponds to the "shortest available".  The word "schedule" should be sufficient to capture this intent?

We would like to propose the following text to address these points:

"The Data Model MUST support specifying available spectrum. The Data Model MUST support specification of this information by start and stop frequencies and MAY also support specification of this information by channel identifiers. The Data Model MUST support a spectrum-availability schedule and maximum power levels for each frequency range."


Thoughts?
Eric



On 8/10/12 5:48 AM, Teco Boot wrote:
What about this:

“The Data Model MUST support specifying a list of available channels. The Data Model MUST support specification of this information by start and stop frequencies, or equivalents such as center frequencies with channel width or channel numbers with channel nummer allocation scheme . The Data Model MUST support a channel availability schedule and maximum power level for each channel in the list.”

More thoughts on channel numbers: we likely run into problems in bands without a channel numbering scheme, or for example sub channels in TV bands.

Teco


Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende geschreven:

<as individual>
While I don't care if it's center and width or upper/lower, I do think we will define the format in the protocol for interoperability reasons, but don't need to do that in requirements.  It wouldn't hurt to decide now and use consistent terms, but we don't need to.

I think "band" won't work, as it usually implies a much wider piece of spectrum that has a common purpose.  The TV Band is all the channels.


On Aug 10, 2012, at 2:37 AM, Teco Boot <teco@inf-net.nl> wrote:

(somewhat late response)

A center frequency and channel width is functional equivalent to start/stop frequencies. So is channel number, with ref to channel number assignment scheme. For a requirements document, we just need to specify what is needed. How it is encoded (Hz, wave length, channel ID) is solution space.

Seen our goal to make PAWS somewhat universal (not limited to US TVWS), I do not prefer using channel numbers.

Teco


Op 9 aug. 2012, om 21:55 heeft <Gabor.Bajko@nokia.com> <Gabor.Bajko@nokia.com> het volgende geschreven:

Folks,
 
During the last F2F meeting, there was an agreement to make a slight update to requirement D.7 in http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.txt, to make channel numbers optional to be supported. Ie, change the current D.7
“The Data Model MUST support specifying a list of available channels. The Data Model MUST support specification of this information by channel numbers and by start and stop frequencies. The Data Model MUST support a channel availability schedule and maximum power level for each channel in the list.”
to
“The Data Model MUST support specifying a list of available channels. The Data Model MUST support specification of this information by start and stop frequencies and MAY include channel numbers. The Data Model MUST support a channel availability schedule and maximum power level for each channel in the list.”
 
I’d like to confirm this change on the list. If anyone has any objections, let me know. Otherwise I’ll plan to send the document to the iesg after this change is implemented.
 
-          Gabor
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws




_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

--------------070103060908010502090706-- From jmalyar@telcordia.com Sat Aug 11 09:10:37 2012 Return-Path: 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 B646B21F846C for ; Sat, 11 Aug 2012 09:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utSR17S0qLpP for ; Sat, 11 Aug 2012 09:10:36 -0700 (PDT) Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF3321F8460 for ; Sat, 11 Aug 2012 09:10:35 -0700 (PDT) Received: from pya-dte-bms01.telcordia.com (pya-dte-bms01.cc.telcordia.com [128.96.37.48]) by dnsmx1rrc.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id q7BGAX9l015629; Sat, 11 Aug 2012 12:10:33 -0400 (EDT) X-AuditID: 80602530-b7f726d000000e4c-19-502683f8063a Received: from rrc-dte-exhb1.dte.telcordia.com (rrc-dte-exhb1.cc.telcordia.com [128.96.20.12]) by pya-dte-bms01.telcordia.com (Symantec Messaging Gateway) with SMTP id 87.97.03660.8F386205; Sat, 11 Aug 2012 12:10:33 -0400 (EDT) Received: from RRC-DTE-EXHB3.dte.telcordia.com (128.96.105.72) by rrc-dte-exhb1.dte.telcordia.com (128.96.20.12) with Microsoft SMTP Server (TLS) id 8.3.245.1; Sat, 11 Aug 2012 12:10:32 -0400 Received: from RRC-DTE-EXMB4.dte.telcordia.com ([fe80::8ad:5ccb:8fe0:2314]) by rrc-dte-exhb3.dte.telcordia.com ([2002:8060:6948::8060:6948]) with mapi id 14.01.0339.001; Sat, 11 Aug 2012 12:10:32 -0400 From: "Malyar, John P" To: "'ericchu@google.com'" , "'teco@inf-net.nl'" Thread-Topic: [paws] use cases and requirements document Thread-Index: AQHNd9vUdWGVgNutbUm61P7toXjryA== Date: Sat, 11 Aug 2012 16:10:31 +0000 Message-ID: In-Reply-To: <50267D9F.6000703@google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2002:8060:9608::8060:9608] Content-Type: multipart/alternative; boundary="_000_E7916FF82420BB40A104D4CAAB11C78809FECBrrcdteexmb4dtetel_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsXSkCDCo/uzWS3A4MZEdosdvSoWB3rmMltc +bqByYHZY8GmUo8lS34yeezfvpIpgDmKyyYlNSezLLVI3y6BK+PF8e/sBX9OMFV0POhnbWDc cICpi5GTQ0LAROLHp8PMELaYxIV769m6GLk4hASeMko8nHWRBSQhJHCYUeL8HSeIxFlGiV/9 U9lAEmwCehK3/nWyg9giAhESL/c+B4szC6hK7LndBrZBWMBcYsmsFcwQNRYST4+sZ4Ww9SRu tG8Ci7MA1a94NhOsnlcgRGLOs6VgNqeAlsSslqdgRzACXff91BomiPniEreezIf6QEBiyZ7z UB+ISrx8/I8VwtaV2N6/CeqefIntm7ewQcwXlDg58wnUY0oS//+fYZvAKDYLydhZSFpmIWmZ xcgBFNeUWL9LH6JEUWJK90N2CFtDonXOXHZk8QWM7KsYpQsqE3VTSlJ1k3KLDQz1SlJzkvOL UjIT9ZLzczcxguNU1WAH4+5f6ocYBTgYlXh4FXxUA4RYE8uKK3MPMUpwMCuJ8GaVqQUI8aYk VlalFuXHF5XmpBYfYpTmYFES592i7+8jJJCeWJKanZpakFoEk2Xi4JRqYBTjm+e9R3ctx3Ym 9f5/S55cWFsRvULar53jy5qJ1VMsdpvP7cwuEvhb9bFh2ePKmJs+7U9rVvioyHBdmd7nX9Wf mPm0qGKmj7bhjemVy6Z7Fzg8ez1zSuvN+kMyHw8t9Evg3tUR4S6ynjPgy69iv93FUS/2LLTf u/a2z9Rvvy8ffxhu5evd91GJpTgj0VCLuag4EQBviTllzwIAAA== Cc: "'paws@ietf.org'" Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 16:10:37 -0000 --_000_E7916FF82420BB40A104D4CAAB11C78809FECBrrcdteexmb4dtetel_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpYw0KDQpUaGFuayB5b3UuIEkgYWdyZWUgd2l0aCB5b3VyIHN1Z2dlc3RlZCB1cGRhdGVzLiBJ dCBpcyBjb25zaXN0ZW50IHdpdGggbXkgcHJldmlvdXMgdW5kZXJzdGFuZGluZyByZWdhcmRpbmcg cmVxdWlyZW1lbnRzIGZvciB0aGUgaW50ZXJmYWNlLg0KDQpSZWdhcmRzDQoNCkpvaG4gTWFseWFy DQoNCkZyb206IEVyaWMgQ2h1IFttYWlsdG86ZXJpY2NodUBnb29nbGUuY29tXQ0KU2VudDogU2F0 dXJkYXksIEF1Z3VzdCAxMSwgMjAxMiAxMTo0MyBBTQ0KVG86IFRlY28gQm9vdCA8dGVjb0BpbmYt bmV0Lm5sPg0KQ2M6IHBhd3NAaWV0Zi5vcmcgPHBhd3NAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W3Bhd3NdIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGRvY3VtZW50DQoNCg0KSGkgZXZlcnlv bmUsDQoNCkdhdGhlcmluZyBhbGwgdGhlIHNoYXJlZCBwb2ludHMgZnJvbSBldmVyeW9uZS4uLiBJ IGJlbGlldmUgYmVsb3cgaXMgdGhlIGNvbXBsZXRlIGxpc3Qgc28gZmFyOg0KDQoNCiAgKiAgIFdo YXQncyB0aGUgYmVzdCBjb25zaXN0ZW50IHJlcHJlc2VudGF0aW9uIG9mIHRoZSB3b3JkcyAiY2hh bm5lbCBudW1iZXJzIiBmb3Igbm9uLVRWIHNwZWN0cnVtDQogICogICBTaG91bGQgd2UgdXBkYXRl IHRoZSBlbnRpcmUgZG9jIG9uIHRoZSB0b3BpYyBvZiDigJxjaGFubmVs4oCdIG9yIOKAnGNoYW5u ZWwgbnVtYmVyc+KAnQ0KICAqICAgV2hhdOKAmXMgdGhlIGJlc3Qgd2F5IHRvIHJlZHVjZSB2YWd1 ZW5lc3MgaW4gd2hldGhlci9ob3cgdG8gaW5jbHVkZSAiY2hhbm5lbCBudW1iZXJzIg0KICAqICAg SXMgdGhlIHJlZmVyZW5jZSB0byB2YXJpYWJsZSBwb3dlciByZXF1aXJlZA0KICAqICAgV2hhdCBk b2VzIGNoYW5uZWwgYXZhaWxhYmlsaXR5IHNjaGVkdWxlIG1lYW4NCg0KQnJpYW4ncyBzdWdnZXN0 aW9uIG9mIHJlcGxhY2luZyBldmVyeSBpbnN0YW5jZSBvZiAiY2hhbm5lbCIgaXMgdGVjaG5pY2Fs bHkgY29ycmVjdGx5LiBIb3dldmVyLCBpdCBpcyBpbXBvcnRhbnQgZm9yIHVzIHRvIGZvY3VzIG1v dmluZyBmb3J3YXJkLiAgSSB3b3VsZCBzdWdnZXN0IHdlIG9ubHkgd29yayBvbiB0aGUgbm9ybWF0 aXZlIHBhcnQgb2YgdGhlIHNwZWMuICBUaGUgc2VjdGlvbiBHYWJvciBpcyBwcm9wb3NpbmcgZm9y IHVzIHRvIG1vZGlmeS4uLg0KDQpPbiB3aGF0J3MgdGhlIGJlc3QgZ2VuZXJpYyBsYWJlbCBmb3Ig dGhlIHdvcmRzICJjaGFubmVsIG51bWJlcnMiLCBjaGFubmVsIGlkZW50aWZpZXIgbWlnaHQgYmUg dGhlIG1vc3QgYWNjdXJhdGUgYW5kIG5ldXRyYWwgImxhYmVsIi4gIFRob3VnaHRzPw0KDQpPbiB0 aGUgcXVlc3Rpb24gd2hldGhlciB2YXJpYWJsZSBwb3dlciBpcyByZXF1aXJlZCwgYmFzZWQgb24g RkNDIGFkamFjZW50LWNoYW5uZWwgcnVsZXMsIHRoZSBkYXRhYmFzZSBtYXkgbGltaXQgdGhlIE1v ZGUgSUkgZGV2aWNlcyB0byAxMDBtVyBmb3Igc29tZSBjaGFubmVscyBhbmQgNDBtVyBmb3Igb3Ro ZXJzLiBUaGVyZWZvcmUsIHRoZSBkYXRhIG1vZGVsIG5lZWRzIHRvIHN1cHBvcnQgc3BlY2lmaWNh dGlvbiBvZiBtYXhpbXVtIHBvd2VyIGxldmVscy4NCg0KTGFzdGx5LCB3aXRoIHJlZ2FyZHMgdG8g InNjaGVkdWxlIiwgdGhlIGludGVudCBpcyB0byBoYXZlIGEgd2F5IG9mIGluZm9ybWluZyBkZXZp Y2VzIHdoZW4gdG8gb3BlcmF0ZSBmb3IgZWFjaCBmcmVxdWVuY3kgcmFuZ2UuIEFzIGxvbmcgYXMg dGhlIGRhdGEgbW9kZWwgc3VwcG9ydHMsIGZvciBleGFtcGxlLCBhIGxpc3Qgb2YgdGltZSByYW5n ZXMsIGl0IGRvZXMgbm90IHByZXZlbnQgYW4gaW1wbGVtZW50YXRpb24gZnJvbSBwcm92aWRpbmcg YSBsaXN0IHdpdGggMSBlbnRyeSB3aGljaCBjb3JyZXNwb25kcyB0byB0aGUgInNob3J0ZXN0IGF2 YWlsYWJsZSIuICBUaGUgd29yZCAic2NoZWR1bGUiIHNob3VsZCBiZSBzdWZmaWNpZW50IHRvIGNh cHR1cmUgdGhpcyBpbnRlbnQ/DQoNCldlIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93 aW5nIHRleHQgdG8gYWRkcmVzcyB0aGVzZSBwb2ludHM6DQoNCiJUaGUgRGF0YSBNb2RlbCBNVVNU IHN1cHBvcnQgc3BlY2lmeWluZyBhdmFpbGFibGUgc3BlY3RydW0uIFRoZSBEYXRhIE1vZGVsIE1V U1Qgc3VwcG9ydCBzcGVjaWZpY2F0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgc3RhcnQgYW5k IHN0b3AgZnJlcXVlbmNpZXMgYW5kIE1BWSBhbHNvIHN1cHBvcnQgc3BlY2lmaWNhdGlvbiBvZiB0 aGlzIGluZm9ybWF0aW9uIGJ5IGNoYW5uZWwgaWRlbnRpZmllcnMuIFRoZSBEYXRhIE1vZGVsIE1V U1Qgc3VwcG9ydCBhIHNwZWN0cnVtLWF2YWlsYWJpbGl0eSBzY2hlZHVsZSBhbmQgbWF4aW11bSBw b3dlciBsZXZlbHMgZm9yIGVhY2ggZnJlcXVlbmN5IHJhbmdlLiINCg0KDQpUaG91Z2h0cz8NCkVy aWMNCg0KDQoNCk9uIDgvMTAvMTIgNTo0OCBBTSwgVGVjbyBCb290IHdyb3RlOg0KV2hhdCBhYm91 dCB0aGlzOg0KDQrigJxUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyBhIGxp c3Qgb2YgYXZhaWxhYmxlIGNoYW5uZWxzLiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3Bl Y2lmaWNhdGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IHN0YXJ0IGFuZCBzdG9wIGZyZXF1ZW5j aWVzLCBvciBlcXVpdmFsZW50cyBzdWNoIGFzIGNlbnRlciBmcmVxdWVuY2llcyB3aXRoIGNoYW5u ZWwgd2lkdGggb3IgY2hhbm5lbCBudW1iZXJzIHdpdGggY2hhbm5lbCBudW1tZXIgYWxsb2NhdGlv biBzY2hlbWUgLiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIGF2YWlsYWJp bGl0eSBzY2hlZHVsZSBhbmQgbWF4aW11bSBwb3dlciBsZXZlbCBmb3IgZWFjaCBjaGFubmVsIGlu IHRoZSBsaXN0LuKAnQ0KDQpNb3JlIHRob3VnaHRzIG9uIGNoYW5uZWwgbnVtYmVyczogd2UgbGlr ZWx5IHJ1biBpbnRvIHByb2JsZW1zIGluIGJhbmRzIHdpdGhvdXQgYSBjaGFubmVsIG51bWJlcmlu ZyBzY2hlbWUsIG9yIGZvciBleGFtcGxlIHN1YiBjaGFubmVscyBpbiBUViBiYW5kcy4NCg0KVGVj bw0KDQoNCk9wIDEwIGF1Zy4gMjAxMiwgb20gMTM6NTcgaGVlZnQgUm9zZW4sIEJyaWFuIGhldCB2 b2xnZW5kZSBnZXNjaHJldmVuOg0KDQo8YXMgaW5kaXZpZHVhbD4NCldoaWxlIEkgZG9uJ3QgY2Fy ZSBpZiBpdCdzIGNlbnRlciBhbmQgd2lkdGggb3IgdXBwZXIvbG93ZXIsIEkgZG8gdGhpbmsgd2Ug d2lsbCBkZWZpbmUgdGhlIGZvcm1hdCBpbiB0aGUgcHJvdG9jb2wgZm9yIGludGVyb3BlcmFiaWxp dHkgcmVhc29ucywgYnV0IGRvbid0IG5lZWQgdG8gZG8gdGhhdCBpbiByZXF1aXJlbWVudHMuICBJ dCB3b3VsZG4ndCBodXJ0IHRvIGRlY2lkZSBub3cgYW5kIHVzZSBjb25zaXN0ZW50IHRlcm1zLCBi dXQgd2UgZG9uJ3QgbmVlZCB0by4NCg0KSSB0aGluayAiYmFuZCIgd29uJ3Qgd29yaywgYXMgaXQg dXN1YWxseSBpbXBsaWVzIGEgbXVjaCB3aWRlciBwaWVjZSBvZiBzcGVjdHJ1bSB0aGF0IGhhcyBh IGNvbW1vbiBwdXJwb3NlLiAgVGhlIFRWIEJhbmQgaXMgYWxsIHRoZSBjaGFubmVscy4NCg0KDQpP biBBdWcgMTAsIDIwMTIsIGF0IDI6MzcgQU0sIFRlY28gQm9vdCA8dGVjb0BpbmYtbmV0Lm5sPG1h aWx0bzp0ZWNvQGluZi1uZXQubmw+PiB3cm90ZToNCg0KKHNvbWV3aGF0IGxhdGUgcmVzcG9uc2Up DQoNCkEgY2VudGVyIGZyZXF1ZW5jeSBhbmQgY2hhbm5lbCB3aWR0aCBpcyBmdW5jdGlvbmFsIGVx dWl2YWxlbnQgdG8gc3RhcnQvc3RvcCBmcmVxdWVuY2llcy4gU28gaXMgY2hhbm5lbCBudW1iZXIs IHdpdGggcmVmIHRvIGNoYW5uZWwgbnVtYmVyIGFzc2lnbm1lbnQgc2NoZW1lLiBGb3IgYSByZXF1 aXJlbWVudHMgZG9jdW1lbnQsIHdlIGp1c3QgbmVlZCB0byBzcGVjaWZ5IHdoYXQgaXMgbmVlZGVk LiBIb3cgaXQgaXMgZW5jb2RlZCAoSHosIHdhdmUgbGVuZ3RoLCBjaGFubmVsIElEKSBpcyBzb2x1 dGlvbiBzcGFjZS4NCg0KU2VlbiBvdXIgZ29hbCB0byBtYWtlIFBBV1Mgc29tZXdoYXQgdW5pdmVy c2FsIChub3QgbGltaXRlZCB0byBVUyBUVldTKSwgSSBkbyBub3QgcHJlZmVyIHVzaW5nIGNoYW5u ZWwgbnVtYmVycy4NCg0KVGVjbw0KDQoNCk9wIDkgYXVnLiAyMDEyLCBvbSAyMTo1NSBoZWVmdCA8 R2Fib3IuQmFqa29Abm9raWEuY29tPG1haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb20+PiA8R2Fi b3IuQmFqa29Abm9raWEuY29tPG1haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb20+PiBoZXQgdm9s Z2VuZGUgZ2VzY2hyZXZlbjoNCg0KRm9sa3MsDQoNCkR1cmluZyB0aGUgbGFzdCBGMkYgbWVldGlu ZywgdGhlcmUgd2FzIGFuIGFncmVlbWVudCB0byBtYWtlIGEgc2xpZ2h0IHVwZGF0ZSB0byByZXF1 aXJlbWVudCBELjcgaW4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXBhd3MtcHJv YmxlbS1zdG10LXVzZWNhc2VzLXJxbXRzLTA2LnR4dCwgdG8gbWFrZSBjaGFubmVsIG51bWJlcnMg b3B0aW9uYWwgdG8gYmUgc3VwcG9ydGVkLiBJZSwgY2hhbmdlIHRoZSBjdXJyZW50IEQuNw0K4oCc VGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgYSBsaXN0IG9mIGF2YWlsYWJs ZSBjaGFubmVscy4gVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZmljYXRpb24gb2Yg dGhpcyBpbmZvcm1hdGlvbiBieSBjaGFubmVsIG51bWJlcnMgYW5kIGJ5IHN0YXJ0IGFuZCBzdG9w IGZyZXF1ZW5jaWVzLiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIGF2YWls YWJpbGl0eSBzY2hlZHVsZSBhbmQgbWF4aW11bSBwb3dlciBsZXZlbCBmb3IgZWFjaCBjaGFubmVs IGluIHRoZSBsaXN0LuKAnQ0KdG8NCuKAnFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVj aWZ5aW5nIGEgbGlzdCBvZiBhdmFpbGFibGUgY2hhbm5lbHMuIFRoZSBEYXRhIE1vZGVsIE1VU1Qg c3VwcG9ydCBzcGVjaWZpY2F0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgc3RhcnQgYW5kIHN0 b3AgZnJlcXVlbmNpZXMgYW5kIE1BWSBpbmNsdWRlIGNoYW5uZWwgbnVtYmVycy4gVGhlIERhdGEg TW9kZWwgTVVTVCBzdXBwb3J0IGEgY2hhbm5lbCBhdmFpbGFiaWxpdHkgc2NoZWR1bGUgYW5kIG1h eGltdW0gcG93ZXIgbGV2ZWwgZm9yIGVhY2ggY2hhbm5lbCBpbiB0aGUgbGlzdC7igJ0NCg0KSeKA mWQgbGlrZSB0byBjb25maXJtIHRoaXMgY2hhbmdlIG9uIHRoZSBsaXN0LiBJZiBhbnlvbmUgaGFz IGFueSBvYmplY3Rpb25zLCBsZXQgbWUga25vdy4gT3RoZXJ3aXNlIEnigJlsbCBwbGFuIHRvIHNl bmQgdGhlIGRvY3VtZW50IHRvIHRoZSBpZXNnIGFmdGVyIHRoaXMgY2hhbmdlIGlzIGltcGxlbWVu dGVkLg0KDQotICAgICAgICAgIEdhYm9yDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KcGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NAaWV0Zi5vcmc8bWFpbHRv OnBhd3NAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bh d3MNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBh d3MgbWFpbGluZyBsaXN0DQpwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBhd3MgbWFpbGluZyBs aXN0DQpwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg0K --_000_E7916FF82420BB40A104D4CAAB11C78809FECBrrcdteexmb4dtetel_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiIHRleHQ9IiMwMDAwMDAiPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkVyaWM8YnI+DQo8YnI+DQpUaGFuayB5b3UuIEkgYWdyZWUgd2l0aCB5b3VyIHN1Z2dl c3RlZCB1cGRhdGVzLiBJdCBpcyBjb25zaXN0ZW50IHdpdGggbXkgcHJldmlvdXMgdW5kZXJzdGFu ZGluZyByZWdhcmRpbmcgcmVxdWlyZW1lbnRzIGZvciB0aGUgaW50ZXJmYWNlLg0KPGJyPg0KPGJy Pg0KUmVnYXJkczxicj4NCjxicj4NCkpvaG4gTWFseWFyPC9mb250Pjxicj4NCiZuYnNwOzxicj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxmb250IHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 Yj5Gcm9tPC9iPjogRXJpYyBDaHUgW21haWx0bzplcmljY2h1QGdvb2dsZS5jb21dDQo8YnI+DQo8 Yj5TZW50PC9iPjogU2F0dXJkYXksIEF1Z3VzdCAxMSwgMjAxMiAxMTo0MyBBTTxicj4NCjxiPlRv PC9iPjogVGVjbyBCb290ICZsdDt0ZWNvQGluZi1uZXQubmwmZ3Q7IDxicj4NCjxiPkNjPC9iPjog cGF3c0BpZXRmLm9yZyAmbHQ7cGF3c0BpZXRmLm9yZyZndDsgPGJyPg0KPGI+U3ViamVjdDwvYj46 IFJlOiBbcGF3c10gdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgZG9jdW1lbnQgPGJyPg0KPC9m b250PiZuYnNwOzxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij48YnI+ DQo8YiBpZD0iaW50ZXJuYWwtc291cmNlLW1hcmtlcl8wLjI1MjQzNDMwNzk0MjE2NjkiIHN0eWxl PSJjb2xvcjoNCiAgICAgICAgcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogVGltZXM7IGZvbnQt c2l6ZTogbWVkaXVtOyBmb250LXN0eWxlOg0KICAgICAgICBub3JtYWw7IGZvbnQtdmFyaWFudDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOw0KICAgICAgICBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6DQogICAgICAg IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog MjsNCiAgICAgICAgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzsNCiAgICAgICAgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmb250LXdlaWdo dDogbm9ybWFsOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE1cHg7IGZvbnQtZmFtaWx5OiBB cmlhbDsgY29sb3I6IHJnYigwLCAwLA0KICAgICAgICAgIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0 cmFuc3BhcmVudDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAgICAgICAgICBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRlY29yYXRpb246DQogICAgICAgICAg bm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7ICI+ SGkNCiBldmVyeW9uZSw8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTVweDsg Zm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsDQogICAgICAgICAgMCwgMCk7IGJhY2tn cm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBmb250LXdlaWdodDogbm9ybWFsOw0KICAgICAgICAg IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlv bjoNCiAgICAgICAgICBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNl OiBwcmUtd3JhcDsgIj48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTVweDsg Zm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsDQogICAgICAgICAgMCwgMCk7IGJhY2tn cm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBmb250LXdlaWdodDogbm9ybWFsOw0KICAgICAgICAg IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlv bjoNCiAgICAgICAgICBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNl OiBwcmUtd3JhcDsgIj5HYXRoZXJpbmcNCiBhbGwgdGhlIHNoYXJlZCBwb2ludHMgZnJvbSBldmVy eW9uZS4uLiBJIGJlbGlldmUgYmVsb3cgaXMgdGhlIGNvbXBsZXRlIGxpc3Qgc28gZmFyOjwvc3Bh bj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNXB4OyBmb250LWZhbWlseTogQXJpYWw7 IGNvbG9yOiByZ2IoMCwNCiAgICAgICAgICAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNw YXJlbnQ7IGZvbnQtd2VpZ2h0OiBub3JtYWw7DQogICAgICAgICAgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOg0KICAgICAgICAgIG5vbmU7 IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyAiPjwvc3Bh bj48YnI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6IDBwdDsgbWFyZ2luLWJvdHRvbTogMHB0OyAi Pg0KPGxpIHN0eWxlPSJsaXN0LXN0eWxlLXR5cGU6IGRpc2M7IGZvbnQtc2l6ZTogMTVweDsNCiAg ICAgICAgICAgIGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dy b3VuZC1jb2xvcjoNCiAgICAgICAgICAgIHRyYW5zcGFyZW50OyBmb250LXdlaWdodDogbm9ybWFs OyBmb250LXN0eWxlOiBub3JtYWw7DQogICAgICAgICAgICBmb250LXZhcmlhbnQ6IG5vcm1hbDsg dGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjoNCiAgICAgICAgICAgIGJhc2Vs aW5lOyAiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTVweDsgZm9udC1mYW1pbHk6DQogICAg ICAgICAgICAgIEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0 cmFuc3BhcmVudDsNCiAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6DQogICAgICAgICAgICAgIG5vcm1hbDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7DQogICAgICAgICAgICAgIHdo aXRlLXNwYWNlOiBwcmUtd3JhcDsgIj5XaGF0J3MNCiB0aGUgYmVzdCBjb25zaXN0ZW50IHJlcHJl c2VudGF0aW9uIG9mIHRoZSB3b3JkcyAmcXVvdDtjaGFubmVsIG51bWJlcnMmcXVvdDsgZm9yIG5v bi1UViBzcGVjdHJ1bTwvc3Bhbj4NCjwvbGk+PGxpIHN0eWxlPSJsaXN0LXN0eWxlLXR5cGU6IGRp c2M7IGZvbnQtc2l6ZTogMTVweDsNCiAgICAgICAgICAgIGZvbnQtZmFtaWx5OiBBcmlhbDsgY29s b3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjoNCiAgICAgICAgICAgIHRyYW5zcGFy ZW50OyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXN0eWxlOiBub3JtYWw7DQogICAgICAgICAg ICBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1h bGlnbjoNCiAgICAgICAgICAgIGJhc2VsaW5lOyAiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTVweDsgZm9udC1mYW1pbHk6DQogICAgICAgICAgICAgIEFyaWFsOyBjb2xvcjogcmdiKDAsIDAs IDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsNCiAgICAgICAgICAgICAgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6DQogICAgICAg ICAgICAgIG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFz ZWxpbmU7DQogICAgICAgICAgICAgIHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgIj5TaG91bGQNCiB3 ZSB1cGRhdGUgdGhlIGVudGlyZSBkb2Mgb24gdGhlIHRvcGljIG9mIOKAnGNoYW5uZWzigJ0gb3Ig 4oCcY2hhbm5lbCBudW1iZXJz4oCdPC9zcGFuPiA8L2xpPjxsaSBzdHlsZT0ibGlzdC1zdHlsZS10 eXBlOiBkaXNjOyBmb250LXNpemU6IDE1cHg7DQogICAgICAgICAgICBmb250LWZhbWlseTogQXJp YWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6DQogICAgICAgICAgICB0 cmFuc3BhcmVudDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zdHlsZTogbm9ybWFsOw0KICAg ICAgICAgICAgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVy dGljYWwtYWxpZ246DQogICAgICAgICAgICBiYXNlbGluZTsgIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDE1cHg7IGZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICBBcmlhbDsgY29sb3I6IHJn YigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7DQogICAgICAgICAgICAg IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50Og0K ICAgICAgICAgICAgICBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxp Z246IGJhc2VsaW5lOw0KICAgICAgICAgICAgICB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7ICI+V2hh dOKAmXMNCiB0aGUgYmVzdCB3YXkgdG8gcmVkdWNlIHZhZ3VlbmVzcyBpbiB3aGV0aGVyL2hvdyB0 byBpbmNsdWRlICZxdW90O2NoYW5uZWwgbnVtYmVycyZxdW90Ozwvc3Bhbj4NCjwvbGk+PGxpIHN0 eWxlPSJsaXN0LXN0eWxlLXR5cGU6IGRpc2M7IGZvbnQtc2l6ZTogMTVweDsNCiAgICAgICAgICAg IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xv cjoNCiAgICAgICAgICAgIHRyYW5zcGFyZW50OyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXN0 eWxlOiBub3JtYWw7DQogICAgICAgICAgICBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjoNCiAgICAgICAgICAgIGJhc2VsaW5lOyAiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTVweDsgZm9udC1mYW1pbHk6DQogICAgICAgICAgICAg IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVu dDsNCiAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6DQogICAgICAgICAgICAgIG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7DQogICAgICAgICAgICAgIHdoaXRlLXNwYWNl OiBwcmUtd3JhcDsgIj5Jcw0KIHRoZSByZWZlcmVuY2UgdG8gdmFyaWFibGUgcG93ZXIgcmVxdWly ZWQ8L3NwYW4+IDwvbGk+PGxpIHN0eWxlPSJsaXN0LXN0eWxlLXR5cGU6IGRpc2M7IGZvbnQtc2l6 ZTogMTVweDsNCiAgICAgICAgICAgIGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAw LCAwKTsgYmFja2dyb3VuZC1jb2xvcjoNCiAgICAgICAgICAgIHRyYW5zcGFyZW50OyBmb250LXdl aWdodDogbm9ybWFsOyBmb250LXN0eWxlOiBub3JtYWw7DQogICAgICAgICAgICBmb250LXZhcmlh bnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjoNCiAgICAg ICAgICAgIGJhc2VsaW5lOyAiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTVweDsgZm9udC1m YW1pbHk6DQogICAgICAgICAgICAgIEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3Jv dW5kLWNvbG9yOiB0cmFuc3BhcmVudDsNCiAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IG5vcm1h bDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6DQogICAgICAgICAgICAgIG5vcm1h bDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7DQogICAg ICAgICAgICAgIHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgIj5XaGF0DQogZG9lcyBjaGFubmVsIGF2 YWlsYWJpbGl0eSBzY2hlZHVsZSBtZWFuPC9zcGFuPiA8L2xpPjwvdWw+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxM3B4OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMzQsDQogICAg ICAgICAgMzQsIDM0KTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyBmb250 LXdlaWdodDoNCiAgICAgICAgICBub3JtYWw7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50OiBub3JtYWw7DQogICAgICAgICAgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1h bGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOg0KICAgICAgICAgIHByZS13cmFwOyAiPjwvc3Bh bj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNXB4OyBmb250LWZhbWlseTogQXJpYWw7 IGNvbG9yOiByZ2IoMCwNCiAgICAgICAgICAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNw YXJlbnQ7IGZvbnQtd2VpZ2h0OiBub3JtYWw7DQogICAgICAgICAgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOg0KICAgICAgICAgIG5vbmU7 IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyAiPkJyaWFu J3MNCiBzdWdnZXN0aW9uIG9mIHJlcGxhY2luZyBldmVyeSBpbnN0YW5jZSBvZiAmcXVvdDtjaGFu bmVsJnF1b3Q7IGlzIHRlY2huaWNhbGx5IGNvcnJlY3RseS4gSG93ZXZlciwgaXQgaXMgaW1wb3J0 YW50IGZvciB1cyB0byBmb2N1cyBtb3ZpbmcgZm9yd2FyZC4gJm5ic3A7SSB3b3VsZCBzdWdnZXN0 IHdlIG9ubHkgd29yayBvbiB0aGUgbm9ybWF0aXZlIHBhcnQgb2YgdGhlIHNwZWMuICZuYnNwO1Ro ZSBzZWN0aW9uIEdhYm9yIGlzIHByb3Bvc2luZyBmb3IgdXMgdG8gbW9kaWZ5Li4uICZuYnNwOzwv c3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNXB4OyBmb250LWZhbWlseTogQXJp YWw7IGNvbG9yOiByZ2IoMCwNCiAgICAgICAgICAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJh bnNwYXJlbnQ7IGZvbnQtd2VpZ2h0OiBub3JtYWw7DQogICAgICAgICAgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOg0KICAgICAgICAgIG5v bmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyAiPjwv c3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNXB4OyBmb250LWZhbWlseTogQXJp YWw7IGNvbG9yOiByZ2IoMCwNCiAgICAgICAgICAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJh bnNwYXJlbnQ7IGZvbnQtd2VpZ2h0OiBub3JtYWw7DQogICAgICAgICAgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOg0KICAgICAgICAgIG5v bmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyAiPk9u DQogd2hhdCdzIHRoZSBiZXN0IGdlbmVyaWMgbGFiZWwgZm9yIHRoZSB3b3JkcyAmcXVvdDtjaGFu bmVsIG51bWJlcnMmcXVvdDssIGNoYW5uZWwgaWRlbnRpZmllciBtaWdodCBiZSB0aGUgbW9zdCBh Y2N1cmF0ZSBhbmQgbmV1dHJhbCAmcXVvdDtsYWJlbCZxdW90Oy4gJm5ic3A7VGhvdWdodHM/PC9z cGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE1cHg7IGZvbnQtZmFtaWx5OiBBcmlh bDsgY29sb3I6IHJnYigwLA0KICAgICAgICAgIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFu c3BhcmVudDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAgICAgICAgICBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRlY29yYXRpb246DQogICAgICAgICAgbm9u ZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7ICI+PC9z cGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE1cHg7IGZvbnQtZmFtaWx5OiBBcmlh bDsgY29sb3I6IHJnYigwLA0KICAgICAgICAgIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFu c3BhcmVudDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAgICAgICAgICBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRlY29yYXRpb246DQogICAgICAgICAgbm9u ZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7ICI+T24N CiB0aGUgcXVlc3Rpb24gd2hldGhlciB2YXJpYWJsZSBwb3dlciBpcyByZXF1aXJlZCwgYmFzZWQg b24gRkNDIGFkamFjZW50LWNoYW5uZWwgcnVsZXMsIHRoZSBkYXRhYmFzZSBtYXkgbGltaXQgdGhl IE1vZGUgSUkgZGV2aWNlcyB0byAxMDBtVyBmb3Igc29tZSBjaGFubmVscyBhbmQgNDBtVyBmb3Ig b3RoZXJzLiBUaGVyZWZvcmUsIHRoZSBkYXRhIG1vZGVsIG5lZWRzIHRvIHN1cHBvcnQgc3BlY2lm aWNhdGlvbiBvZiBtYXhpbXVtIHBvd2VyIGxldmVscy48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTVweDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsDQogICAg ICAgICAgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBmb250LXdlaWdodDog bm9ybWFsOw0KICAgICAgICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IHRleHQtZGVjb3JhdGlvbjoNCiAgICAgICAgICBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFz ZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgIj48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTVweDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsDQogICAg ICAgICAgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBmb250LXdlaWdodDog bm9ybWFsOw0KICAgICAgICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IHRleHQtZGVjb3JhdGlvbjoNCiAgICAgICAgICBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFz ZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgIj5MYXN0bHksDQogd2l0aCByZWdhcmRzIHRv ICZxdW90O3NjaGVkdWxlJnF1b3Q7LCB0aGUgaW50ZW50IGlzIHRvIGhhdmUgYSB3YXkgb2YgaW5m b3JtaW5nIGRldmljZXMgd2hlbiB0byBvcGVyYXRlIGZvciBlYWNoIGZyZXF1ZW5jeSByYW5nZS4g QXMgbG9uZyBhcyB0aGUgZGF0YSBtb2RlbCBzdXBwb3J0cywgZm9yIGV4YW1wbGUsIGEgbGlzdCBv ZiB0aW1lIHJhbmdlcywgaXQgZG9lcyBub3QgcHJldmVudCBhbiBpbXBsZW1lbnRhdGlvbiBmcm9t IHByb3ZpZGluZyBhIGxpc3Qgd2l0aA0KIDEgZW50cnkgd2hpY2ggY29ycmVzcG9uZHMgdG8gdGhl ICZxdW90O3Nob3J0ZXN0IGF2YWlsYWJsZSZxdW90Oy4gJm5ic3A7VGhlIHdvcmQgJnF1b3Q7c2No ZWR1bGUmcXVvdDsgc2hvdWxkIGJlIHN1ZmZpY2llbnQgdG8gY2FwdHVyZSB0aGlzIGludGVudD88 YnIgY2xhc3M9ImtpeC1saW5lLWJyZWFrIj4NCjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxNXB4OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwNCiAgICAgICAg ICAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7DQogICAgICAgICAgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg dGV4dC1kZWNvcmF0aW9uOg0KICAgICAgICAgIG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGlu ZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyAiPldlDQogd291bGQgbGlrZSB0byBwcm9wb3NlIHRo ZSBmb2xsb3dpbmcgdGV4dCB0byBhZGRyZXNzIHRoZXNlIHBvaW50czo8L3NwYW4+PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTVweDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdi KDAsDQogICAgICAgICAgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBmb250 LXdlaWdodDogbm9ybWFsOw0KICAgICAgICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjoNCiAgICAgICAgICBub25lOyB2ZXJ0aWNhbC1h bGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgIj48L3NwYW4+PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTNweDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdi KDM0LA0KICAgICAgICAgIDM0LCAzNCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwg MjU1KTsgZm9udC13ZWlnaHQ6DQogICAgICAgICAgbm9ybWFsOyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudDogbm9ybWFsOw0KICAgICAgICAgIHRleHQtZGVjb3JhdGlvbjogbm9uZTsg dmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZToNCiAgICAgICAgICBwcmUtd3Jh cDsgIj4mcXVvdDtUaGUNCiBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZ5aW5nIGF2YWls YWJsZSBzcGVjdHJ1bS4gVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZmljYXRpb24g b2YgdGhpcyBpbmZvcm1hdGlvbiBieSBzdGFydCBhbmQgc3RvcCBmcmVxdWVuY2llcyBhbmQgTUFZ IGFsc28gc3VwcG9ydCBzcGVjaWZpY2F0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgY2hhbm5l bCBpZGVudGlmaWVycy4gVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IGENCiBzcGVjdHJ1bS1h dmFpbGFiaWxpdHkgc2NoZWR1bGUgYW5kIG1heGltdW0gcG93ZXIgbGV2ZWxzIGZvciBlYWNoIGZy ZXF1ZW5jeSByYW5nZS4mcXVvdDs8L3NwYW4+PC9iPjxiIGlkPSJpbnRlcm5hbC1zb3VyY2UtbWFy a2VyXzAuMjUyNDM0MzA3OTQyMTY2OSIgc3R5bGU9ImNvbG9yOg0KICAgICAgICByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBUaW1lczsgZm9udC1zaXplOiBtZWRpdW07IGZvbnQtc3R5bGU6DQog ICAgICAgIG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7DQogICAgICAgIGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDoNCiAgICAgICAgMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOw0KICAgICAgICB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOw0KICAgICAgICAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IGZvbnQtd2VpZ2h0OiBub3JtYWw7ICI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTVweDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsDQogICAg ICAgICAgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBmb250LXdlaWdodDogbm9y bWFsOw0KICAgICAgICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IHRleHQtZGVjb3JhdGlvbjoNCiAgICAgICAgICBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxp bmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTNweDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDM0LCAzNCwNCiAgICAgICAg ICAzNCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgZm9udC13ZWlnaHQ6 DQogICAgICAgICAgbm9ybWFsOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9y bWFsOw0KICAgICAgICAgIHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJh c2VsaW5lOyB3aGl0ZS1zcGFjZToNCiAgICAgICAgICBwcmUtd3JhcDsgIj48YnI+DQo8YnI+DQo8 YnI+DQo8L3NwYW4+PC9iPjxiIGlkPSJpbnRlcm5hbC1zb3VyY2UtbWFya2VyXzAuMjUyNDM0MzA3 OTQyMTY2OSIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBUaW1lczsg Zm9udC1zaXplOg0KICAgICAgICBtZWRpdW07IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50OiBub3JtYWw7DQogICAgICAgIGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IG9ycGhhbnM6IDI7DQogICAgICAgIHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsNCiAgICAgICAgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsNCiAgICAgICAgLXdlYmtpdC10ZXh0 LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7DQogICAg ICAgIGZvbnQtd2VpZ2h0OiBub3JtYWw7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTVweDsN CiAgICAgICAgICBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tn cm91bmQtY29sb3I6DQogICAgICAgICAgdHJhbnNwYXJlbnQ7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGZvbnQtc3R5bGU6IG5vcm1hbDsNCiAgICAgICAgICBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjoNCiAgICAgICAgICBiYXNlbGluZTsg d2hpdGUtc3BhY2U6IHByZS13cmFwOyAiPlRob3VnaHRzPzxicj4NCkVyaWM8YnI+DQo8YnI+DQo8 YnI+DQo8L3NwYW4+PC9iPjxicj4NCk9uIDgvMTAvMTIgNTo0OCBBTSwgVGVjbyBCb290IHdyb3Rl Ojxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOjc4OEUxMDg2LUNBMTgtNDc3Ri1C RThFLUFCOTBGNzFFMkJBNkBpbmYtbmV0Lm5sIiB0eXBlPSJjaXRlIj4NCjxkaXY+V2hhdCBhYm91 dCB0aGlzOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsNCiAgICAgICAgICAt d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1u YnNwLW1vZGU6DQogICAgICAgICAgICAgICAgICAgIHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSJB cHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXN0eWxl OiBub3JtYWw7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC12YXJpYW50OiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiAtd2Via2l0LWF1dG87DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiAyOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdvcmQtc3BhY2luZzogMHB4 Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwt c3BhY2luZzogMHB4Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIC13ZWJraXQtYm9yZGVy LXZlcnRpY2FsLXNwYWNpbmc6IDBweDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAtd2Vi a2l0LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBub25lOw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZvbnQtc2l6ZToN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBtZWRpdW07ICI+DQo8ZGl2IGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiIGxhbmc9IkVOLVVTIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIg c3R5bGU9InBhZ2U6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFdvcmRTZWN0aW9u MTsgIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9u dC1zaXplOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNhbnMtc2Vy aWY7ICI+DQrigJxUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyBhIGxpc3Qg b2YgYXZhaWxhYmxlIGNoYW5uZWxzLiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lm aWNhdGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IHN0YXJ0IGFuZCBzdG9wIGZyZXF1ZW5jaWVz LCBvciBlcXVpdmFsZW50cyBzdWNoIGFzIGNlbnRlciBmcmVxdWVuY2llcyB3aXRoIGNoYW5uZWwg d2lkdGggb3IgY2hhbm5lbCBudW1iZXJzIHdpdGggY2hhbm5lbCBudW1tZXINCiBhbGxvY2F0aW9u IHNjaGVtZSAuIFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBhIGNoYW5uZWwgYXZhaWxhYmls aXR5IHNjaGVkdWxlIGFuZCBtYXhpbXVtIHBvd2VyIGxldmVsIGZvciBlYWNoIGNoYW5uZWwgaW4g dGhlIGxpc3Qu4oCdPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N Cjxicj4NCjwvZGl2Pg0KPGRpdj5Nb3JlIHRob3VnaHRzIG9uIGNoYW5uZWwgbnVtYmVyczogd2Ug bGlrZWx5IHJ1biBpbnRvIHByb2JsZW1zIGluIGJhbmRzIHdpdGhvdXQgYSBjaGFubmVsIG51bWJl cmluZyBzY2hlbWUsIG9yIGZvciBleGFtcGxlIHN1YiBjaGFubmVscyBpbiBUViBiYW5kcy48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRlY288L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8YnI+DQo8ZGl2Pg0KPGRpdj5PcCAxMCBhdWcuIDIwMTIsIG9tIDEzOjU3IGhlZWZ0IFJvc2Vu LCBCcmlhbiBoZXQgdm9sZ2VuZGUgZ2VzY2hyZXZlbjo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5 bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOw0KICAg ICAgICAgICAgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCiZsdDth cyBpbmRpdmlkdWFsJmd0Ow0KPGRpdj5XaGlsZSBJIGRvbid0IGNhcmUgaWYgaXQncyBjZW50ZXIg YW5kIHdpZHRoIG9yIHVwcGVyL2xvd2VyLCBJIGRvIHRoaW5rIHdlIHdpbGwgZGVmaW5lIHRoZSBm b3JtYXQgaW4gdGhlIHByb3RvY29sIGZvciBpbnRlcm9wZXJhYmlsaXR5IHJlYXNvbnMsIGJ1dCBk b24ndCBuZWVkIHRvIGRvIHRoYXQgaW4gcmVxdWlyZW1lbnRzLiAmbmJzcDtJdCB3b3VsZG4ndCBo dXJ0IHRvIGRlY2lkZSBub3cgYW5kIHVzZSBjb25zaXN0ZW50IHRlcm1zLCBidXQgd2UgZG9uJ3QN CiBuZWVkIHRvLg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSB0aGluayAmcXVvdDtiYW5kJnF1 b3Q7IHdvbid0IHdvcmssIGFzIGl0IHVzdWFsbHkgaW1wbGllcyBhIG11Y2ggd2lkZXIgcGllY2Ug b2Ygc3BlY3RydW0gdGhhdCBoYXMgYSBjb21tb24gcHVycG9zZS4gJm5ic3A7VGhlIFRWIEJhbmQg aXMgYWxsIHRoZSBjaGFubmVscy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj5PbiBBdWcgMTAsIDIwMTIsIGF0IDI6MzcgQU0sIFRlY28gQm9v dCAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86dGVjb0BpbmYtbmV0 Lm5sIj50ZWNvQGluZi1uZXQubmw8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBw bGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmFzZSBo cmVmPSJ4LW1zZzovLzcwLyI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7DQog ICAgICAgICAgICAgICAgICAgICAgICAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQt bGluZS1icmVhazoNCiAgICAgICAgICAgICAgICAgICAgICAgIGFmdGVyLXdoaXRlLXNwYWNlOyAi Pg0KKHNvbWV3aGF0IGxhdGUgcmVzcG9uc2UpDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BIGNl bnRlciBmcmVxdWVuY3kgYW5kIGNoYW5uZWwgd2lkdGggaXMgZnVuY3Rpb25hbCBlcXVpdmFsZW50 IHRvIHN0YXJ0L3N0b3AgZnJlcXVlbmNpZXMuIFNvIGlzIGNoYW5uZWwgbnVtYmVyLCB3aXRoIHJl ZiB0byBjaGFubmVsIG51bWJlciBhc3NpZ25tZW50IHNjaGVtZS4gRm9yIGEgcmVxdWlyZW1lbnRz IGRvY3VtZW50LCB3ZSBqdXN0IG5lZWQgdG8gc3BlY2lmeSB3aGF0IGlzIG5lZWRlZC4gSG93IGl0 IGlzIGVuY29kZWQgKEh6LCB3YXZlDQogbGVuZ3RoLCBjaGFubmVsIElEKSZuYnNwO2lzIHNvbHV0 aW9uIHNwYWNlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2VlbiBvdXIgZ29hbCB0 byBtYWtlIFBBV1Mgc29tZXdoYXQgdW5pdmVyc2FsIChub3QgbGltaXRlZCB0byBVUyBUVldTKSwg SSBkbyBub3QgcHJlZmVyIHVzaW5nIGNoYW5uZWwgbnVtYmVycy48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlRlY288L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjxk aXY+DQo8ZGl2Pk9wIDkgYXVnLiAyMDEyLCBvbSAyMTo1NSBoZWVmdCAmbHQ7PGEgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tIj5HYWJvci5C YWprb0Bub2tpYS5jb208L2E+Jmd0OyAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVm PSJtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tIj5HYWJvci5CYWprb0Bub2tpYS5jb208L2E+ Jmd0OyBoZXQgdm9sZ2VuZGUgZ2VzY2hyZXZlbjo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50 ZXJjaGFuZ2UtbmV3bGluZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3BhbiBjbGFzcz0i QXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c3R5bGU6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vcm1hbDsgZm9udC12YXJp YW50OiBub3JtYWw7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHRleHQtYWxpZ246IC13ZWJraXQtYXV0bzsgdGV4dC1pbmRlbnQ6 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBub3JtYWw7 IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwtc3BhY2luZzogMHB4Ow0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtd2Via2l0LWJvcmRlci12ZXJ0aWNhbC1zcGFjaW5nOiAw cHg7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC13ZWJraXQtdGV4dC1kZWNvcmF0 aW9ucy1pbi1lZmZlY3Q6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vbmU7IC13 ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4Ow0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBmb250LXNpemU6IG1lZGl1bTsgIj4NCjxkaXYgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSIgbGFuZz0iRU4tVVMiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHls ZT0icGFnZToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFdvcmRTZWN0aW9u MTsgIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0Og0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAw MXB0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBD YWxpYnJpLCBzYW5zLXNlcmlmOyAiPg0KRm9sa3MsPG86cD48L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi10b3A6IDBpbjsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0Og0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0Ow0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDYWxpYnJpLCBzYW5zLXNl cmlmOyAiPg0KPG86cD4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6 IDBpbjsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0Ow0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5Og0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPg0KRHVyaW5n IHRoZSBsYXN0IEYyRiBtZWV0aW5nLCB0aGVyZSB3YXMgYW4gYWdyZWVtZW50IHRvIG1ha2UgYSBz bGlnaHQgdXBkYXRlIHRvIHJlcXVpcmVtZW50IEQuNyBpbjxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9 Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11c2Vj YXNlcy1ycW10cy0wNi50eHQiIHN0eWxlPSJjb2xvcjogYmx1ZTsNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5odHRw Oi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMt cnFtdHMtMDYudHh0PC9hPiwNCiB0byBtYWtlIGNoYW5uZWwgbnVtYmVycyBvcHRpb25hbCB0byBi ZSBzdXBwb3J0ZWQuIEllLCBjaGFuZ2UgdGhlIGN1cnJlbnQgRC43PG86cD48L286cD48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0Og0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0Ow0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDYWxpYnJp LCBzYW5zLXNlcmlmOyAiPg0K4oCcVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlp bmcgYSBsaXN0IG9mIGF2YWlsYWJsZSBjaGFubmVscy4gVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBw b3J0IHNwZWNpZmljYXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBjaGFubmVsIG51bWJlcnMg YW5kIGJ5IHN0YXJ0IGFuZCBzdG9wIGZyZXF1ZW5jaWVzLiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1 cHBvcnQgYSBjaGFubmVsIGF2YWlsYWJpbGl0eSBzY2hlZHVsZSBhbmQgbWF4aW11bQ0KIHBvd2Vy IGxldmVsIGZvciBlYWNoIGNoYW5uZWwgaW4gdGhlIGxpc3Qu4oCdPG86cD48L286cD48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0Og0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0Ow0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDYWxpYnJp LCBzYW5zLXNlcmlmOyAiPg0KdG88bzpwPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LXRvcDogMGluOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYXJnaW4t cmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENhbGlicmksIHNhbnMtc2VyaWY7ICI+DQri gJxUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyBhIGxpc3Qgb2YgYXZhaWxh YmxlIGNoYW5uZWxzLiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmaWNhdGlvbiBv ZiB0aGlzIGluZm9ybWF0aW9uIGJ5IHN0YXJ0IGFuZCBzdG9wIGZyZXF1ZW5jaWVzIGFuZCBNQVkg aW5jbHVkZSBjaGFubmVsIG51bWJlcnMuIFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBhIGNo YW5uZWwgYXZhaWxhYmlsaXR5IHNjaGVkdWxlIGFuZA0KIG1heGltdW0gcG93ZXIgbGV2ZWwgZm9y IGVhY2ggY2hhbm5lbCBpbiB0aGUgbGlzdC7igJ08bzpwPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLXRvcDogMGluOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENhbGlicmksIHNhbnMtc2Vy aWY7ICI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDog MGluOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYXJnaW4tcmlnaHQ6 IDBpbjsgbWFyZ2luLWxlZnQ6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIENhbGlicmksIHNhbnMtc2VyaWY7ICI+DQpJ4oCZZCBs aWtlIHRvIGNvbmZpcm0gdGhpcyBjaGFuZ2Ugb24gdGhlIGxpc3QuIElmIGFueW9uZSBoYXMgYW55 IG9iamVjdGlvbnMsIGxldCBtZSBrbm93LiBPdGhlcndpc2UgSeKAmWxsIHBsYW4gdG8gc2VuZCB0 aGUgZG9jdW1lbnQgdG8gdGhlIGllc2cgYWZ0ZXIgdGhpcyBjaGFuZ2UgaXMgaW1wbGVtZW50ZWQu PG86cD48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1s ZWZ0Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPg0KPG86cD4mbmJzcDs8L286cD48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0Og0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwLjVpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAx cHQ7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENh bGlicmksIHNhbnMtc2VyaWY7IHRleHQtaW5kZW50Og0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtMC4yNWluOyAiPg0KPHNwYW4+LTxzcGFuIHN0eWxlPSJmb250OiBub3Jt YWwgbm9ybWFsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBub3Jt YWwgN3B0L25vcm1hbCAnVGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBSb21hbic7ICI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48L3NwYW4+R2Fib3I8bzpwPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnBhd3Mg bWFpbGluZyBsaXN0PGJyPg0KPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86 cGF3c0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bmRlcmxpbmU7ICI+cGF3c0BpZXRmLm9y ZzwvYT48YnI+DQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cyIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRl Y29yYXRpb246DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bmRlcmxpbmU7 ICI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzPC9hPjxicj4NCjwv ZGl2Pg0KPC9zcGFuPjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcGF3 cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0 bzpwYXdzQGlldGYub3JnIj5wYXdzQGlldGYub3JnPC9hPjxicj4NCjxhIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdz Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3M8L2E+PGJyPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPGJyPg0KPGZpZWxkc2V0IGNsYXNzPSJtaW1l QXR0YWNobWVudEhlYWRlciI+PC9maWVsZHNldD4gPGJyPg0KPHByZSB3cmFwPSIiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwYXdzIG1haWxpbmcgbGlz dA0KPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOnBhd3NA aWV0Zi5vcmciPnBhd3NAaWV0Zi5vcmc8L2E+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0 ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3czwvYT4NCjwvcHJlPg0KPC9i bG9ja3F1b3RlPg0KPGJyPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E7916FF82420BB40A104D4CAAB11C78809FECBrrcdteexmb4dtetel_-- From brian.rosen@neustar.biz Mon Aug 13 06:24:26 2012 Return-Path: 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 2B05E21F869A for ; Mon, 13 Aug 2012 06:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.39 X-Spam-Level: X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42usruM1Hiqa for ; Mon, 13 Aug 2012 06:24:25 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC8521F875E for ; Mon, 13 Aug 2012 06:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1344864180; x=1660220180; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=vZW55fadqqwnqEhRqPNjc ITpDLvwjSnMAgDMveqLxVI=; b=hAH0BoUim3K2qgvC4KrqJ4/Jo7/jbPEYeXOIE v8zmjH3Iz4l8FAa6FV9pHtQy80RG0Xvg8qwu1TIN3M65YJxfw== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.8263432; Mon, 13 Aug 2012 09:22:59 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 13 Aug 2012 09:24:22 -0400 From: "Rosen, Brian" To: 'Eric Chu' , 'Teco Boot' Date: Mon, 13 Aug 2012 09:24:21 -0400 Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac132A+ffelSOaw+RnKMzGb0JigJLwBfuNkz Message-ID: <55A5A9A87506CB4BA580BF9D531957DA690227B5@STNTEXCH01.cis.neustar.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: SEA6N1DkLEf9rIXqj+qiow== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'paws@ietf.org'" Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 13:24:26 -0000 PGFzIGluZGl2aWR1YWw+Ckkgd291bGQgcHJlZmVyIHRvIG5vdCB1c2UgdGhlIHdvcmQgImNoYW5u ZWwiIGluIG91ciBkb2N1bWVudHMgYXQgYWxsIGV4Y2VwdCBmb3IgdGhlIHRlcm0gImNoYW5uZWwg aWRlbnRpZmllciIuICBJIHByb3Bvc2VkICJzcGVjdHJ1bSB1bml0IiwgYWx0aG91Z2ggYW55IG90 aGVyIHRlcm0gd2lsbCBkby4gICJDaGFubmVsIiBoYXMgdG9vIG11Y2ggYmFnZ2FnZSwgIEEgc2lt cGxlIGVkaXRvcmlhbCBjaGFuZ2UgbGlrZSB0aGlzIGlzIHNpbXBsZSwgYW5kIGl0J3MgbXVjaCBi ZXR0ZXIgdG8gZG8gaXQgbm93LgoKSSB0aGluayB3ZSBuZWVkIHBvd2VyIGluIGJvdGggdGhlIHF1 ZXJ5IGFuZCB0aGUgcmVzcG9uc2UuICBJbiBzb21lIGRvbWFpbnMsIGl0IG1heSBiZSB0aGF0IHlv dSBzcGVjaWZ5IHdoYXQgcG93ZXIgeW91IHdhbnQgdG8gdXNlIGFuZCB0aGUgREIgdGVsbHMgeW91 IHdoYXQgc3BlY3RydW0geW91IGNhbiB1c2UgYXQgdGhhdCBwb3dlci4gIEluIG90aGVyLCBhIFVT LWxpa2UgcnVsZSBtYXkgYmUgaW4gcGxhY2UuICBBbHNvIGluIGVpdGhlciB0aGUgcXVlcnkgb3Ig dGhlIHJlZ2lzdHJhdGlvbiwgd2UgbmVlZCBhIGRldmljZSB0eXBlLCB3aGljaCBzaG91bGQgYmUg YW4gZW50cnkgZnJvbSBhbiBJQU5BIHJlZ2lzdHJ5LiAgVGhpcyBpcyBob3cgeW91IGdldCB0aGUg VVMgIk1vZGUgSUkiIGluZm9ybWF0aW9uLgoKV2l0aCByZWdhcmQgdG8gc2NoZWR1bGUsIEkgd291 bGQgbGlrZSB0byBzZWUgdHdvIG1lY2hhbmlzbXMKMSkgYSB0aW1lIGJ5IHdoaWNoIHRoZSBkYXRh YmFzZSBzaG91bGQgYmUgcXVlcmllZCBhZ2FpbiAod2hpY2ggY291bGQgcmVwcmVzZW50IHRoZSBu ZXh0IGNoYW5nZSBpbiBzY2hlZHVsZSkKMikgc3RhcnQvc3RvcCB0aW1lcyBmb3IgZWFjaCBzcGVj dHJ1bSB1bml0IGF2YWlsYWJsZQoKQm90aCB0aGVzZSBzaG91bGQgYmUgb3B0aW9uYWwgaW4gdGhl IHJlc3BvbnNlLgoKTXkgdGV4dAoKVGhlIGRhdGEgbW9kZWwgbXVzdCBzdXBwb3J0IHNwZWNpZnlp bmcgc3BlY3RydW0gYXZhaWxhYmlsaXR5LiAgU3BlY3RydW0gdW5pdHMgYXJlIHNwZWNpZmllZCBi eSBsb3cgYW5kIGhpZ2ggZnJlcXVlbmNpZXMgYW5kIG1heSBoYXZlIGFuIG9wdGlvbmFsIGNoYW5u ZWwgaWRlbnRpZmllci4KClRoZSBkYXRhIG1vZGVsIG11c3Qgc3VwcG9ydCBhIHNjaGVkdWxlIGZv ciBzcGVjdHJ1bSB1bml0IGF2YWlsYWJpbGl0eS4gIFR3byBtZWNoYW5pc21zIG11c3QgYmUgc3Vw cG9ydGVkLiAgVGhlIHJlc3BvbnNlIHRvIHNwZWN0cnVtIGF2YWlsYWJpbGl0eSBxdWVyeSBtYXkg aW5jbHVkZSBhIHRpbWUgYnkgd2hpY2ggdGhlIGRhdGFiYXNlIG11c3QgYmUgcmVxdWVyaWVkLiAg RWFjaCBzcGVjdHJ1bSB1bml0IG1lbnRpb25lZCBpbiB0aGUgcmVzcG9uc2UgbWF5IGJlIGFubm90 YXRlZCB3aXRoIHN0YXJ0IGFuZCBzdG9wIHRpbWUvZGF0ZS4gIAoKDQoNCiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogCUVyaWMgQ2h1IFttYWlsdG86ZXJpY2NodUBnb29nbGUuY29t XQ0KU2VudDoJU2F0dXJkYXksIEF1Z3VzdCAxMSwgMjAxMiAxMTo0MyBBTSBFYXN0ZXJuIFN0YW5k YXJkIFRpbWUNClRvOglUZWNvIEJvb3QNCkNjOglSb3NlbiwgQnJpYW47IHBhd3NAaWV0Zi5vcmcN ClN1YmplY3Q6CVJlOiBbcGF3c10gdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgZG9jdW1lbnQN Cg0KDQpIaSBldmVyeW9uZSwNCg0KR2F0aGVyaW5nIGFsbCB0aGUgc2hhcmVkIHBvaW50cyBmcm9t IGV2ZXJ5b25lLi4uIEkgYmVsaWV2ZSBiZWxvdyBpcyB0aGUgY29tcGxldGUgbGlzdCBzbyBmYXI6 DQoNCg0KDQoqCVdoYXQncyB0aGUgYmVzdCBjb25zaXN0ZW50IHJlcHJlc2VudGF0aW9uIG9mIHRo ZSB3b3JkcyAiY2hhbm5lbCBudW1iZXJzIiBmb3Igbm9uLVRWIHNwZWN0cnVtDQoqCVNob3VsZCB3 ZSB1cGRhdGUgdGhlIGVudGlyZSBkb2Mgb24gdGhlIHRvcGljIG9mIOKAnGNoYW5uZWzigJ0gb3Ig 4oCcY2hhbm5lbCBudW1iZXJz4oCdDQoqCVdoYXTigJlzIHRoZSBiZXN0IHdheSB0byByZWR1Y2Ug dmFndWVuZXNzIGluIHdoZXRoZXIvaG93IHRvIGluY2x1ZGUgImNoYW5uZWwgbnVtYmVycyINCioJ SXMgdGhlIHJlZmVyZW5jZSB0byB2YXJpYWJsZSBwb3dlciByZXF1aXJlZA0KKglXaGF0IGRvZXMg Y2hhbm5lbCBhdmFpbGFiaWxpdHkgc2NoZWR1bGUgbWVhbg0KDQoNCkJyaWFuJ3Mgc3VnZ2VzdGlv biBvZiByZXBsYWNpbmcgZXZlcnkgaW5zdGFuY2Ugb2YgImNoYW5uZWwiIGlzIHRlY2huaWNhbGx5 IGNvcnJlY3RseS4gSG93ZXZlciwgaXQgaXMgaW1wb3J0YW50IGZvciB1cyB0byBmb2N1cyBtb3Zp bmcgZm9yd2FyZC4gIEkgd291bGQgc3VnZ2VzdCB3ZSBvbmx5IHdvcmsgb24gdGhlIG5vcm1hdGl2 ZSBwYXJ0IG9mIHRoZSBzcGVjLiAgVGhlIHNlY3Rpb24gR2Fib3IgaXMgcHJvcG9zaW5nIGZvciB1 cyB0byBtb2RpZnkuLi4gIA0KDQpPbiB3aGF0J3MgdGhlIGJlc3QgZ2VuZXJpYyBsYWJlbCBmb3Ig dGhlIHdvcmRzICJjaGFubmVsIG51bWJlcnMiLCBjaGFubmVsIGlkZW50aWZpZXIgbWlnaHQgYmUg dGhlIG1vc3QgYWNjdXJhdGUgYW5kIG5ldXRyYWwgImxhYmVsIi4gIFRob3VnaHRzPw0KDQpPbiB0 aGUgcXVlc3Rpb24gd2hldGhlciB2YXJpYWJsZSBwb3dlciBpcyByZXF1aXJlZCwgYmFzZWQgb24g RkNDIGFkamFjZW50LWNoYW5uZWwgcnVsZXMsIHRoZSBkYXRhYmFzZSBtYXkgbGltaXQgdGhlIE1v ZGUgSUkgZGV2aWNlcyB0byAxMDBtVyBmb3Igc29tZSBjaGFubmVscyBhbmQgNDBtVyBmb3Igb3Ro ZXJzLiBUaGVyZWZvcmUsIHRoZSBkYXRhIG1vZGVsIG5lZWRzIHRvIHN1cHBvcnQgc3BlY2lmaWNh dGlvbiBvZiBtYXhpbXVtIHBvd2VyIGxldmVscy4NCg0KTGFzdGx5LCB3aXRoIHJlZ2FyZHMgdG8g InNjaGVkdWxlIiwgdGhlIGludGVudCBpcyB0byBoYXZlIGEgd2F5IG9mIGluZm9ybWluZyBkZXZp Y2VzIHdoZW4gdG8gb3BlcmF0ZSBmb3IgZWFjaCBmcmVxdWVuY3kgcmFuZ2UuIEFzIGxvbmcgYXMg dGhlIGRhdGEgbW9kZWwgc3VwcG9ydHMsIGZvciBleGFtcGxlLCBhIGxpc3Qgb2YgdGltZSByYW5n ZXMsIGl0IGRvZXMgbm90IHByZXZlbnQgYW4gaW1wbGVtZW50YXRpb24gZnJvbSBwcm92aWRpbmcg YSBsaXN0IHdpdGggMSBlbnRyeSB3aGljaCBjb3JyZXNwb25kcyB0byB0aGUgInNob3J0ZXN0IGF2 YWlsYWJsZSIuICBUaGUgd29yZCAic2NoZWR1bGUiIHNob3VsZCBiZSBzdWZmaWNpZW50IHRvIGNh cHR1cmUgdGhpcyBpbnRlbnQ/DQoNCldlIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93 aW5nIHRleHQgdG8gYWRkcmVzcyB0aGVzZSBwb2ludHM6DQoNCiJUaGUgRGF0YSBNb2RlbCBNVVNU IHN1cHBvcnQgc3BlY2lmeWluZyBhdmFpbGFibGUgc3BlY3RydW0uIFRoZSBEYXRhIE1vZGVsIE1V U1Qgc3VwcG9ydCBzcGVjaWZpY2F0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgc3RhcnQgYW5k IHN0b3AgZnJlcXVlbmNpZXMgYW5kIE1BWSBhbHNvIHN1cHBvcnQgc3BlY2lmaWNhdGlvbiBvZiB0 aGlzIGluZm9ybWF0aW9uIGJ5IGNoYW5uZWwgaWRlbnRpZmllcnMuIFRoZSBEYXRhIE1vZGVsIE1V U1Qgc3VwcG9ydCBhIHNwZWN0cnVtLWF2YWlsYWJpbGl0eSBzY2hlZHVsZSBhbmQgbWF4aW11bSBw b3dlciBsZXZlbHMgZm9yIGVhY2ggZnJlcXVlbmN5IHJhbmdlLiINCg0KDQpUaG91Z2h0cz8NCkVy aWMNCg0KDQoNCk9uIDgvMTAvMTIgNTo0OCBBTSwgVGVjbyBCb290IHdyb3RlOg0KDQoNCglXaGF0 IGFib3V0IHRoaXM6DQoNCgkJ4oCcVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlp bmcgYSBsaXN0IG9mIGF2YWlsYWJsZSBjaGFubmVscy4gVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBw b3J0IHNwZWNpZmljYXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBzdGFydCBhbmQgc3RvcCBm cmVxdWVuY2llcywgb3IgZXF1aXZhbGVudHMgc3VjaCBhcyBjZW50ZXIgZnJlcXVlbmNpZXMgd2l0 aCBjaGFubmVsIHdpZHRoIG9yIGNoYW5uZWwgbnVtYmVycyB3aXRoIGNoYW5uZWwgbnVtbWVyIGFs bG9jYXRpb24gc2NoZW1lIC4gVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IGEgY2hhbm5lbCBh dmFpbGFiaWxpdHkgc2NoZWR1bGUgYW5kIG1heGltdW0gcG93ZXIgbGV2ZWwgZm9yIGVhY2ggY2hh bm5lbCBpbiB0aGUgbGlzdC7igJ0NCgkNCglNb3JlIHRob3VnaHRzIG9uIGNoYW5uZWwgbnVtYmVy czogd2UgbGlrZWx5IHJ1biBpbnRvIHByb2JsZW1zIGluIGJhbmRzIHdpdGhvdXQgYSBjaGFubmVs IG51bWJlcmluZyBzY2hlbWUsIG9yIGZvciBleGFtcGxlIHN1YiBjaGFubmVscyBpbiBUViBiYW5k cy4NCg0KCVRlY28NCg0KDQoJT3AgMTAgYXVnLiAyMDEyLCBvbSAxMzo1NyBoZWVmdCBSb3Nlbiwg QnJpYW4gaGV0IHZvbGdlbmRlIGdlc2NocmV2ZW46DQoNCg0KCQk8YXMgaW5kaXZpZHVhbD4gDQoJ CVdoaWxlIEkgZG9uJ3QgY2FyZSBpZiBpdCdzIGNlbnRlciBhbmQgd2lkdGggb3IgdXBwZXIvbG93 ZXIsIEkgZG8gdGhpbmsgd2Ugd2lsbCBkZWZpbmUgdGhlIGZvcm1hdCBpbiB0aGUgcHJvdG9jb2wg Zm9yIGludGVyb3BlcmFiaWxpdHkgcmVhc29ucywgYnV0IGRvbid0IG5lZWQgdG8gZG8gdGhhdCBp biByZXF1aXJlbWVudHMuICBJdCB3b3VsZG4ndCBodXJ0IHRvIGRlY2lkZSBub3cgYW5kIHVzZSBj b25zaXN0ZW50IHRlcm1zLCBidXQgd2UgZG9uJ3QgbmVlZCB0by4gDQoNCgkJSSB0aGluayAiYmFu ZCIgd29uJ3Qgd29yaywgYXMgaXQgdXN1YWxseSBpbXBsaWVzIGEgbXVjaCB3aWRlciBwaWVjZSBv ZiBzcGVjdHJ1bSB0aGF0IGhhcyBhIGNvbW1vbiBwdXJwb3NlLiAgVGhlIFRWIEJhbmQgaXMgYWxs IHRoZSBjaGFubmVscy4NCg0KDQoJCU9uIEF1ZyAxMCwgMjAxMiwgYXQgMjozNyBBTSwgVGVjbyBC b290IDx0ZWNvQGluZi1uZXQubmw+IHdyb3RlOg0KDQoNCgkJCShzb21ld2hhdCBsYXRlIHJlc3Bv bnNlKSANCg0KCQkJQSBjZW50ZXIgZnJlcXVlbmN5IGFuZCBjaGFubmVsIHdpZHRoIGlzIGZ1bmN0 aW9uYWwgZXF1aXZhbGVudCB0byBzdGFydC9zdG9wIGZyZXF1ZW5jaWVzLiBTbyBpcyBjaGFubmVs IG51bWJlciwgd2l0aCByZWYgdG8gY2hhbm5lbCBudW1iZXIgYXNzaWdubWVudCBzY2hlbWUuIEZv ciBhIHJlcXVpcmVtZW50cyBkb2N1bWVudCwgd2UganVzdCBuZWVkIHRvIHNwZWNpZnkgd2hhdCBp cyBuZWVkZWQuIEhvdyBpdCBpcyBlbmNvZGVkIChIeiwgd2F2ZSBsZW5ndGgsIGNoYW5uZWwgSUQp IGlzIHNvbHV0aW9uIHNwYWNlLg0KDQoJCQlTZWVuIG91ciBnb2FsIHRvIG1ha2UgUEFXUyBzb21l d2hhdCB1bml2ZXJzYWwgKG5vdCBsaW1pdGVkIHRvIFVTIFRWV1MpLCBJIGRvIG5vdCBwcmVmZXIg dXNpbmcgY2hhbm5lbCBudW1iZXJzLg0KDQoJCQlUZWNvDQoNCg0KCQkJT3AgOSBhdWcuIDIwMTIs IG9tIDIxOjU1IGhlZWZ0IDxHYWJvci5CYWprb0Bub2tpYS5jb20+IDxHYWJvci5CYWprb0Bub2tp YS5jb20+IGhldCB2b2xnZW5kZSBnZXNjaHJldmVuOg0KDQoNCgkJCQkJCQkJRm9sa3MsDQoJCQkJ IA0KCQkJCUR1cmluZyB0aGUgbGFzdCBGMkYgbWVldGluZywgdGhlcmUgd2FzIGFuIGFncmVlbWVu dCB0byBtYWtlIGEgc2xpZ2h0IHVwZGF0ZSB0byByZXF1aXJlbWVudCBELjcgaW4gaHR0cDovL3d3 dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXRz LTA2LnR4dCwgdG8gbWFrZSBjaGFubmVsIG51bWJlcnMgb3B0aW9uYWwgdG8gYmUgc3VwcG9ydGVk LiBJZSwgY2hhbmdlIHRoZSBjdXJyZW50IEQuNw0KCQkJCeKAnFRoZSBEYXRhIE1vZGVsIE1VU1Qg c3VwcG9ydCBzcGVjaWZ5aW5nIGEgbGlzdCBvZiBhdmFpbGFibGUgY2hhbm5lbHMuIFRoZSBEYXRh IE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZpY2F0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkg Y2hhbm5lbCBudW1iZXJzIGFuZCBieSBzdGFydCBhbmQgc3RvcCBmcmVxdWVuY2llcy4gVGhlIERh dGEgTW9kZWwgTVVTVCBzdXBwb3J0IGEgY2hhbm5lbCBhdmFpbGFiaWxpdHkgc2NoZWR1bGUgYW5k IG1heGltdW0gcG93ZXIgbGV2ZWwgZm9yIGVhY2ggY2hhbm5lbCBpbiB0aGUgbGlzdC7igJ0NCgkJ CQl0bw0KCQkJCeKAnFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZ5aW5nIGEgbGlz dCBvZiBhdmFpbGFibGUgY2hhbm5lbHMuIFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVj aWZpY2F0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgc3RhcnQgYW5kIHN0b3AgZnJlcXVlbmNp ZXMgYW5kIE1BWSBpbmNsdWRlIGNoYW5uZWwgbnVtYmVycy4gVGhlIERhdGEgTW9kZWwgTVVTVCBz dXBwb3J0IGEgY2hhbm5lbCBhdmFpbGFiaWxpdHkgc2NoZWR1bGUgYW5kIG1heGltdW0gcG93ZXIg bGV2ZWwgZm9yIGVhY2ggY2hhbm5lbCBpbiB0aGUgbGlzdC7igJ0NCgkJCQkgDQoJCQkJSeKAmWQg bGlrZSB0byBjb25maXJtIHRoaXMgY2hhbmdlIG9uIHRoZSBsaXN0LiBJZiBhbnlvbmUgaGFzIGFu eSBvYmplY3Rpb25zLCBsZXQgbWUga25vdy4gT3RoZXJ3aXNlIEnigJlsbCBwbGFuIHRvIHNlbmQg dGhlIGRvY3VtZW50IHRvIHRoZSBpZXNnIGFmdGVyIHRoaXMgY2hhbmdlIGlzIGltcGxlbWVudGVk Lg0KCQkJCSANCgkJCQktICAgICAgICAgIEdhYm9yDQoJCQkJX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCgkJCQlwYXdzIG1haWxpbmcgbGlzdA0KCQkJCXBh d3NAaWV0Zi5vcmcNCgkJCQlodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bh d3MNCgkJCQkNCgkJCQkNCg0KCQkJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCgkJCXBhd3MgbWFpbGluZyBsaXN0DQoJCQlwYXdzQGlldGYub3JnDQoJCQlo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCgkJCQ0KDQoNCg0KDQoJ IA0KCQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJ cGF3cyBtYWlsaW5nIGxpc3QNCglwYXdzQGlldGYub3JnDQoJaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wYXdzDQoJDQoNCg0K From brian.rosen@neustar.biz Mon Aug 13 06:31:26 2012 Return-Path: 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 50AA221F874F for ; Mon, 13 Aug 2012 06:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hu6htggBgyNF for ; Mon, 13 Aug 2012 06:31:25 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3E07E21F86B4 for ; Mon, 13 Aug 2012 06:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1344864736; x=1660220407; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=SgvXBh7v2WyKS6a56gHk3 WMXqQySuF9jLSFq4ve/B+M=; b=Xs2kbreadBU7gw7U0IZa+MN9yyJ/XcrNj6499 nLWwoX8NHsJ8r4AGWWpOmFxhv44Y3MQBdvfx9U+6J/1IAmfFw== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.12578619; Mon, 13 Aug 2012 09:32:15 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 13 Aug 2012 09:30:19 -0400 From: "Rosen, Brian" To: 'Peter Stanforth' , 'Teco Boot' , 'Benjamin A.Rolfe' Date: Mon, 13 Aug 2012 09:30:19 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac13skMHMqAV0sU4SmysFmOfQFQHnABpYTql Message-ID: <55A5A9A87506CB4BA580BF9D531957DA690227B6@STNTEXCH01.cis.neustar.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: +8OUjJPdZbr1Puk1yrSK7Q== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'paws@ietf.org'" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 13:31:26 -0000 T3VyIGV4cGVyaWVuY2UgaW4gdGhlIElFVEYgb3ZlciBtYW55IHllYXJzIGlzIHRoYXQgZWNvbm9t aXppbmcgbWVzc2FnZSBzaXplIGFuZCBjb21wcm9taXNpbmcgdXRpbGl0eSBhbmQgc2VjdXJpdHkg aW4gc2VhcmNoIG9mIGVmZmljaWVuY3kgb2YgaW1wbGVtZW50YXRpb24gb24gc21hbGwgZGV2aWNl cyBpcyBhIHBvb3IgdHJhZGUgb2ZmLiAgSSBhbSBub3QgYWR2b2NhdGluZyBiZWluZyB3YXN0ZWZ1 bCBvZiByZXNvdXJjZXMsIGJ1dCBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBzZXJpb3VzbHkgY29u c2lkZXIgdGhlIG92ZXJoZWFkIG9mIFhNTCBvciBqc29uIHRvIGJlIHNpZ25pZmljYW50LgoKQXNz dW1pbmcgYSBqc29uIGxpYnJhcnkgY2FuIGJlIGxvYWRlZCBvbiBhIHNtYWxsIGRldmljZSBpcyBy ZWFzb25hYmxlLgoKQnJpYW4gKGFzIGluZGl2aWR1YWwpCgoNCg0KIC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiAJUGV0ZXIgU3RhbmZvcnRoIFttYWlsdG86cGV0ZXJAc3BlY3RydW1i cmlkZ2UuY29tXQ0KU2VudDoJU2F0dXJkYXksIEF1Z3VzdCAxMSwgMjAxMiAwNzoxMyBBTSBFYXN0 ZXJuIFN0YW5kYXJkIFRpbWUNClRvOglUZWNvIEJvb3Q7IEJlbmphbWluIEEuUm9sZmUNCkNjOglw YXdzQGlldGYub3JnDQpTdWJqZWN0OglSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04s IHZDYXJkICYgaUNhbA0KDQpOb3QgYWxsIG1hc3RlcnMgcnVuIG92ZXIgdGhlIGNvcmUgbmV0d29y ay4NClNvbWUgb2YgdGhlIFVzZSBjYXNlcyBoYXZlIGEgbWFzdGVyIHRhbGtpbmcgdG8gYW5vdGhl ciBPVEENCldlIHNob3VsZCBub3QgYXNzdW1lIHRoYXQgYWxsIE1hc3RlcnMgYXJlIGF0dGFjaGVk IHRvIHV0aWxpdHkgcG93ZXIgc28gd2UNCnNob3VsZCBiZSBzeW1wYXRoZXRpYyB0byBwcm9jZXNz aW5nIGVuZXJneSB1c2UgYWxzby4NCg0KT24gU2F0QXVnLzExLzEyIFNhdCBBdWcgMTEsIDU6MzAg QU0sICJUZWNvIEJvb3QiIDx0ZWNvQGluZi1uZXQubmw+IHdyb3RlOg0KDQo+DQo+T3AgMTAgYXVn LiAyMDEyLCBvbSAxODoxMCBoZWVmdCBCZW5qYW1pbiBBLiBSb2xmZSBoZXQgdm9sZ2VuZGUgZ2Vz Y2hyZXZlbjoNCj4NCj4+IENvbXBhY3RuZXNzIG9mIG1lc3NhZ2VzIGlzIGltcG9ydGFudCwgYnV0 IGl0IGlzIGFsc28gaW1wb3J0YW50ICh0byBtZQ0KPj5hdCBsZWFzdCkgdG8gYmUgcmVhbGl6YWJs ZSBpbiBhbiBpbXBsZW1lbnRhdGlvbiB3aXRoIGxpbWl0ZWQgcmVzb3VyY2VzLA0KPj5zdWNoIGFz IGVtYmVkZGVkIGRldmljZXMgaW4gd2hhdCBhcmUgbm93IHBvcHVsYXJseSBjYWxsZWQgIk0yTSIN Cj4+YXBwbGljYXRpb25zLiAgQSBsb3Qgb2YgdGhlc2UgZGV2aWNlcyBjb3VsZCB1c2UgSVAgYWxs IHRoZSBlbmQgdG8gZW5kLA0KPj5idXQgbWF5IGhhdmUgYSB2ZXJ5IGNvbXBhY3QsIHNpbXBsZSBz dGFjayBhbmQgYXBwbGljYXRpb25zIChpLmUuICBubw0KPj5icm93c2VyKS4gIElzIEpTT04gdHlw aWNhbGx5IGltcGxlbWVudGVkIHdoZW4gdGhlcmUgaXMgbm8gYnJvd3Nlcj8NCj4+V291bGQgaXQg YmUgaGFyZCB0byBkbyBpbiBhIHJlc291cmNlIGNvbnN0cmFpbmVkIGRldmljZSAoaS5lLiB3aGVy ZSB3ZQ0KPj50YWxrIGFib3V0IG1lbW9yeSBzaXplIGluIEtpbG8tYnl0ZXMgc3RpbGwpLg0KPg0K PkluIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGRvY3VtZW50LCB0aGVyZSBhcmUgbm8gcmVx dWlyZW1lbnRzIGZvcg0KPnByb3RvY29sIHBlcmZvcm1hbmNlLiBJIGd1ZXNzIE9TL0lQL1RDUC9U TFMgY29kZSBzaXplIHN1cGVyc2VkZXMgbmVlZHMNCj5mb3IgSlNPTiBvciBYTUwuIA0KPg0KPlNh bWUgZm9yIHRpbWluZzogVENQL1RMUyBjb25uZWN0aW9uIHNldHVwIHdpbGwgdGFrZSBtb3JlIHRo YW4gdGhlIFBBV1MNCj5tZXNzYWdlIGV4Y2hhbmdlLCBJIHRoaW5rLiBUaGlzIG1heSBiZSBvZiBp bXBvcnRhbmNlIHdoZW4gdXNpbmcgc2F0Y29tDQo+bGlua3MuDQo+DQo+QmVjYXVzZSBQQVdTIHJ1 bnMgYmV0d2VlbiBtYXN0ZXIgYW5kIGRhdGFiYXNlLCBvdmVyIGNvcmUgbmV0d29yaywNCj5wZXJm b3JtYW5jZSBpcyBub3Qgb3VyIHByaW1hcnkgY29uY2Vybi4gQnV0IGFzIGFsd2F5cywgaXQgaXMg Z29vZCB0byBrZWVwDQo+YW4gZXllIG9uIGVmZmljaWVuY3kuDQo+DQo+VGVjbw0KPg0KPj4gVGhh bmtzDQo+PiBCZW4NCj4+IA0KPj4gDQo+Pj4gV2UgaGFkIGEgZGlzY3Vzc2lvbiBvbiBYTUwgdnMu IEpTT04uIEkgcHJlZmVyIHRoZSBvbmUgd2l0aCBtb3N0DQo+Pj5jb21wYWN0IG1lc3NhZ2VzLg0K Pj4+IA0KPj4+IE9uIHZDYXJkIGFuZCBKU09OOiB3aGF0IGlzIHRoZSBzdGF0dXMgb2YgIkEgSmF2 YVNjcmlwdCBPYmplY3QgTm90YXRpb24NCj4+PihKU09OKSBSZXByZXNlbnRhdGlvbiBmb3IgdkNh cmQiPw0KPj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJoYXQtdmNhcmRkYXYt anNvbi0wMA0KPj4+IA0KPj4+IE9uIHZhbGlkIHRpbWVzOiBjYW4gd2UgdXNlIHNhbWUgZm9ybWF0 IGFzIGNlcnRpZmljYXRlcz8gVGhleSBoYXZlDQo+Pj5zaW1pbGFyIHNpbXBsZSByZXF1aXJlbWVu dHM6IHZhbGlkIG5vdEJlZm9yZSYgIG5vdEFmdGVyLg0KPj4+IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzMyODAjc2VjdGlvbi00LjEuMi41DQo+Pj4gDQo+Pj4gVGVjbw0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gcGF3cyBtYWls aW5nIGxpc3QNCj4+PiBwYXdzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wYXdzDQo+Pj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4gcGF3c0Bp ZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5wYXdz IG1haWxpbmcgbGlzdA0KPnBhd3NAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Bhd3MNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnBhd3MgbWFpbGluZyBsaXN0DQpwYXdzQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg== From peter@spectrumbridge.com Mon Aug 13 06:49:18 2012 Return-Path: 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 229CA21F84D5 for ; Mon, 13 Aug 2012 06:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfUn1bdluyvD for ; Mon, 13 Aug 2012 06:49:17 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6401721F86B0 for ; Mon, 13 Aug 2012 06:49:17 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 13 Aug 2012 09:49:16 -0400 From: Peter Stanforth To: "Rosen, Brian" , 'Teco Boot' , 'Benjamin A.Rolfe' Date: Mon, 13 Aug 2012 09:49:11 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15Wm2jY7Dvrw33Q82iqTV5XDWItg== Message-ID: In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA690227B6@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'paws@ietf.org'" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 13:49:18 -0000 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.=20 On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" 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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" 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.=20 >> >>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 >>>=20 >>>=20 >>>> We had a discussion on XML vs. JSON. I prefer the one with most >>>>compact messages. >>>>=20 >>>> 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 >>>>=20 >>>> 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 >>>>=20 >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>>=20 >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From Peter.McCann@huawei.com Mon Aug 13 07:47:20 2012 Return-Path: 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 DE55321F8516 for ; Mon, 13 Aug 2012 07:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.691 X-Spam-Level: X-Spam-Status: No, score=-5.691 tagged_above=-999 required=5 tests=[AWL=0.908, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1TAv9QZdeK6 for ; Mon, 13 Aug 2012 07:47:19 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B679A21F85A5 for ; Mon, 13 Aug 2012 07:47:18 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIV26820; Mon, 13 Aug 2012 06:47:18 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 07:45:09 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.75]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Mon, 13 Aug 2012 07:45:09 -0700 From: Peter McCann To: "Joel M. Halpern" , "Gabor.Bajko@nokia.com" Thread-Topic: [paws] need for DB initialization message Thread-Index: Ac12he0A+5h4j+uqT6e4F6BpK7EzXwAAEnAAADHrtdAAENwZAAB0JGqA Date: Mon, 13 Aug 2012 14:45:08 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E1AF75@dfweml512-mbx.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F@008-AM1MPN1-006.mgdnok.nokia.com> <502462F4.8000002@joelhalpern.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB0839@008-AM1MPN1-006.mgdnok.nokia.com> <5025A48C.2090009@joelhalpern.com> In-Reply-To: <5025A48C.2090009@joelhalpern.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" Subject: Re: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 14:47:21 -0000 Agree with Joel. I think a LOST-style service (a) is good for discovering a server associate= d with a regulatory domain. After that, you can query the regulator (b) to f= ind approved databases. Then, you can choose one of those databases with which you have a relationship or that you know through some means will service your request (c). The protocol for (b) and (c) could both be PAWS, if we just add some sort of indirection to our specification. -Pete Joel M. Halpern wrote: > The master has to know its location in geographic coordinates (GPS, > etc.) As far as I know, we have not assumed that the maps to translate > that into political domains are known to the master a priori. >=20 > There are deployment scenarios (cell towers come to mind) where the > master can probably be provisioned with the right administrative > information. There are other scenarios where that is not obviously > achievable. >=20 > Yours, > Joel >=20 > On 8/10/2012 7:33 PM, Gabor.Bajko@nokia.com wrote: >> While I agree that re-direction from an intermediary to the final > recipient should not be disallowed, I don't think the use case you are > describing is a valid one. The master needs to know its location > before engaging into DB discovery. If it doesn't, then it can use some > existing mechanism to find it out (eg, RFC5985) prior to the DB > discovery process, but that for me is a separate transaction. >>=20 >> The current DB discovery mechanism described in > http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt assumes > that the master knows its location before performing DB discovery; > after which it needs to do a regulatory domain discovery as well. > Brian suggested regulatory domain could be a parameter of the DB URI, > thus no need for separate regulatory domain discovery. Any other suggesti= ons? >>=20 >> - Gabor >>=20 >> -----Original Message----- >> From: ext Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Thursday, August 09, 2012 6:25 PM >> To: Bajko Gabor (Nokia-CIC/SiliconValley) >> Cc: paws@ietf.org >> Subject: Re: [paws] need for DB initialization message >>=20 >> Related suggestion: Assuming we have a discovery protocol which can >> return a URI, the protocol semantics should be such that the URI can >> be the final DB URI, or another intermediary in the process. Thus, >> the protocol should not lock in that there can be only 0 or 1 >> intermediaries in the resolution, but should allow several. (We >> already have suggested cases where at least two are needed, one to >> determine where you are by asking your vendor, and one to determine >> who you can talk to by asking your local regulator.) >>=20 >> Yours, >> Joel >>=20 >> On 8/9/2012 8:02 PM, Gabor.Bajko@nokia.com wrote: >>> Folks, >>>=20 >>> During the Vancouver F2F discussions we had some good discussions, >>> but no agreement on wether an initialization message, as proposed >>> in draft-das is necessary or not. >>>=20 >>> You may check the minutes to see what was said at the mike: >>> http://www.ietf.org/proceedings/84/minutes/minutes-84-paws >>>=20 >>> People spoke mostly in favor, but there were people who also said >>> that this message is redundant with registration message. >>>=20 >>> Question#1: need for an initialization message >>>=20 >>> Unfortunately we did not have time to discuss the DB discovery aspect, >>> and that may be related to this topic. The only DB discovery document >>> available currently, >>> http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, proposes, >>> that the master device contacts a pre-provisioned discovery server and >>> provides its location, and in return the discovery server returns the >>> URI of the DB for that regulatory domain. At this point, the master >>> device knows which DB to contact, but it does not necessarily know >>> what regulatory domain that DB belongs to. Thus, it doesn't know what >>> are the operating rules, whether it has to authenticate, or register, >>> etc. >>>=20 >>> Thus, it seems logical to me that the master device first queries the >>> DB to find out the regulatory domain. We even have such a requirement >>> in the requirement draft, requirement: >>>=20 >>> "P.3: The protocol MUST support determination of >>> regulatory domain governing its current location." >>>=20 >>> The information about the regulatory domain may be cached, and the >>> master device may not need to place that query every time, but this >>> message exchange may be necessary in certain cases. Any comments to >>> this point? >>>=20 >>> Question#2 >>>=20 >>> Then, it is a slightly separate issue, if this message exchange has >>> to take place, then what additional information the DB returns. >>> draft-das proposes that regulatory domain specific information be >>> returned to the master device. >>>=20 >>> Question#3 >>>=20 >>> Yet another separate point is that draft-das proposes to use this >>> initialization message also to initiate client authentication (putting >>> shared secret vs cert issue aside for the time being). In cases when >>> the master device does not know the regulatory domain it is in, then >>> it does not know whether authentication is required in that regulatory >>> domain or not; so why would initiate authentication then? Similar >>> comment applies to draft-wei, where it is proposed that after DB >>> discovery the master device authenticates at TLS layer and performs >>> registration; how does it know that it has to authenticate and >>> register, if it doesn't know the regulatory domain? >>>=20 >>> In my opinion (chair hat off), the sequence of events should be sg >>> like >>> this: >>>=20 >>> 1.DB discovery (may be skipped if cached information available) >>>=20 >>> 2.Regulatory domain query (may be skipped if cached information >>> available) >>>=20 >>> 3.Authentication (if required) >>>=20 >>> 4.Registration (if required) >>>=20 >>> 5.Channel availability query (may be combined with registration?) >>>=20 >>> Comments are welcome and expected. >>>=20 >>> -Gabor >>>=20 From brian.rosen@neustar.biz Mon Aug 13 07:55:36 2012 Return-Path: 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 0025721F877C for ; Mon, 13 Aug 2012 07:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.397 X-Spam-Level: X-Spam-Status: No, score=-6.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArJIgJgKXFpn for ; Mon, 13 Aug 2012 07:55:35 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B1AD021F853F for ; Mon, 13 Aug 2012 07:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1344869845; x=1660220407; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=wv+4vcJIAphuT+LENInTZ NgM229Y3Dzc4igd5dPfcEU=; b=C2LPpH2Hrg9AoGJYgXwYdDB7nibMiZh9V57q8 HhaagKu+uiz/IIw07+b/sdZTcHTust9YqIvCIyyr4cSNliwfw== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.12581626; Mon, 13 Aug 2012 10:57:24 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 13 Aug 2012 10:55:27 -0400 From: "Rosen, Brian" Date: Mon, 13 Aug 2012 10:55:27 -0400 Thread-Topic: [paws] need for DB initialization message Thread-Index: Ac12he0A+5h4j+uqT6e4F6BpK7EzXwAAEnAAADHrtdAAENwZAAB0JGqAAABxXLg= Message-ID: <55A5A9A87506CB4BA580BF9D531957DA690227B7@STNTEXCH01.cis.neustar.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: kl9X8m4VyCMnLnHsnvuE4A== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 To: 'Peter McCann' , "'Joel M. Halpern'" , "'gabor.bajko@nokia.com'" Cc: "'paws@ietf.org'" Subject: Re: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 14:55:36 -0000 PGFzIGluZGl2aWR1YWw+CkkgcHJlZmVyIExvU1QgZm9yIGRpc2NvdmVyeS4gIExvU1QgY2FuIGRv IHJlY3VyL2l0ZXJhdGUgbGlrZSBETlMsIGFuZCBpdCBjYW4gcmV0dXJuIG1vcmUgdGhhbiBvbmUg VVJJLiAgVGhhdCB3b3VsZCBhbGxvdyB0aGUgYmFzZSBMb1NUIGRpc2NvdmVyeSB0byBmaW5kIGEg c2VydmVyIHRoYXQgcmV0dXJuZWQgdGhlIGxpc3QuICBUaGUgaW5pdGlhbCBMb1NUIHF1ZXJ5IHJl dHVybnMgdGhlIGxpc3Qgc2VydmVyLCBhbmQgYSByZWN1ciBvciBpdGVyYXRlIHJldHVybnMgdGhl IGxpc3QuCgpCcmlhbgoKDQoNCiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogCVBl dGVyIE1jQ2FubiBbbWFpbHRvOlBldGVyLk1jQ2FubkBodWF3ZWkuY29tXQ0KU2VudDoJTW9uZGF5 LCBBdWd1c3QgMTMsIDIwMTIgMTA6NDcgQU0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQpUbzoJSm9l bCBNLiBIYWxwZXJuOyBHYWJvci5CYWprb0Bub2tpYS5jb20NCkNjOglwYXdzQGlldGYub3JnDQpT dWJqZWN0OglSZTogW3Bhd3NdIG5lZWQgZm9yIERCIGluaXRpYWxpemF0aW9uIG1lc3NhZ2UNCg0K QWdyZWUgd2l0aCBKb2VsLg0KDQpJIHRoaW5rIGEgTE9TVC1zdHlsZSBzZXJ2aWNlIChhKSBpcyBn b29kIGZvciBkaXNjb3ZlcmluZyBhIHNlcnZlciBhc3NvY2lhdGVkDQp3aXRoIGEgcmVndWxhdG9y eSBkb21haW4uICBBZnRlciB0aGF0LCB5b3UgY2FuIHF1ZXJ5IHRoZSByZWd1bGF0b3IgKGIpIHRv IGZpbmQNCmFwcHJvdmVkIGRhdGFiYXNlcy4gIFRoZW4sIHlvdSBjYW4gY2hvb3NlIG9uZSBvZiB0 aG9zZSBkYXRhYmFzZXMgd2l0aCB3aGljaA0KeW91IGhhdmUgYSByZWxhdGlvbnNoaXAgb3IgdGhh dCB5b3Uga25vdyB0aHJvdWdoIHNvbWUgbWVhbnMgd2lsbCBzZXJ2aWNlDQp5b3VyIHJlcXVlc3Qg KGMpLiAgVGhlIHByb3RvY29sIGZvciAoYikgYW5kIChjKSBjb3VsZCBib3RoIGJlIFBBV1MsIGlm IHdlDQpqdXN0IGFkZCBzb21lIHNvcnQgb2YgaW5kaXJlY3Rpb24gdG8gb3VyIHNwZWNpZmljYXRp b24uDQoNCi1QZXRlDQoNCg0KSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPiBUaGUgbWFzdGVyIGhh cyB0byBrbm93IGl0cyBsb2NhdGlvbiBpbiBnZW9ncmFwaGljIGNvb3JkaW5hdGVzIChHUFMsDQo+ IGV0Yy4pICAgQXMgZmFyIGFzIEkga25vdywgd2UgaGF2ZSBub3QgYXNzdW1lZCB0aGF0IHRoZSBt YXBzIHRvIHRyYW5zbGF0ZQ0KPiB0aGF0IGludG8gcG9saXRpY2FsIGRvbWFpbnMgYXJlIGtub3du IHRvIHRoZSBtYXN0ZXIgYSBwcmlvcmkuDQo+IA0KPiBUaGVyZSBhcmUgZGVwbG95bWVudCBzY2Vu YXJpb3MgKGNlbGwgdG93ZXJzIGNvbWUgdG8gbWluZCkgd2hlcmUgdGhlDQo+IG1hc3RlciBjYW4g cHJvYmFibHkgYmUgcHJvdmlzaW9uZWQgd2l0aCB0aGUgcmlnaHQgYWRtaW5pc3RyYXRpdmUNCj4g aW5mb3JtYXRpb24uICBUaGVyZSBhcmUgb3RoZXIgc2NlbmFyaW9zIHdoZXJlIHRoYXQgaXMgbm90 IG9idmlvdXNseQ0KPiBhY2hpZXZhYmxlLg0KPiANCj4gWW91cnMsDQo+IEpvZWwNCj4gDQo+IE9u IDgvMTAvMjAxMiA3OjMzIFBNLCBHYWJvci5CYWprb0Bub2tpYS5jb20gd3JvdGU6DQo+PiBXaGls ZSBJIGFncmVlIHRoYXQgcmUtZGlyZWN0aW9uIGZyb20gYW4gaW50ZXJtZWRpYXJ5IHRvIHRoZSBm aW5hbA0KPiByZWNpcGllbnQgc2hvdWxkIG5vdCBiZSBkaXNhbGxvd2VkLCBJIGRvbid0IHRoaW5r IHRoZSB1c2UgY2FzZSB5b3UgYXJlDQo+IGRlc2NyaWJpbmcgaXMgYSB2YWxpZCBvbmUuIFRoZSBt YXN0ZXIgbmVlZHMgdG8ga25vdyBpdHMgbG9jYXRpb24NCj4gYmVmb3JlIGVuZ2FnaW5nIGludG8g REIgZGlzY292ZXJ5LiBJZiBpdCBkb2Vzbid0LCB0aGVuIGl0IGNhbiB1c2Ugc29tZQ0KPiBleGlz dGluZyBtZWNoYW5pc20gdG8gZmluZCBpdCBvdXQgKGVnLCBSRkM1OTg1KSBwcmlvciB0byB0aGUg REINCj4gZGlzY292ZXJ5IHByb2Nlc3MsIGJ1dCB0aGF0IGZvciBtZSBpcyBhIHNlcGFyYXRlIHRy YW5zYWN0aW9uLg0KPj4gDQo+PiBUaGUgY3VycmVudCBEQiBkaXNjb3ZlcnkgbWVjaGFuaXNtIGRl c2NyaWJlZCBpbg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXByb2Jhc2NvLXBhd3Mt ZGlzY292ZXJ5LTAxLnR4dCBhc3N1bWVzDQo+IHRoYXQgdGhlIG1hc3RlciBrbm93cyBpdHMgbG9j YXRpb24gYmVmb3JlIHBlcmZvcm1pbmcgREIgZGlzY292ZXJ5Ow0KPiBhZnRlciB3aGljaCBpdCBu ZWVkcyB0byBkbyBhIHJlZ3VsYXRvcnkgZG9tYWluIGRpc2NvdmVyeSBhcyB3ZWxsLg0KPiBCcmlh biBzdWdnZXN0ZWQgcmVndWxhdG9yeSBkb21haW4gY291bGQgYmUgYSBwYXJhbWV0ZXIgb2YgdGhl IERCIFVSSSwNCj4gdGh1cyBubyBuZWVkIGZvciBzZXBhcmF0ZSByZWd1bGF0b3J5IGRvbWFpbiBk aXNjb3ZlcnkuIEFueSBvdGhlciBzdWdnZXN0aW9ucz8NCj4+IA0KPj4gLSBHYWJvcg0KPj4gDQo+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogZXh0IEpvZWwgTS4gSGFscGVy biBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+PiBTZW50OiBUaHVyc2RheSwgQXVndXN0 IDA5LCAyMDEyIDY6MjUgUE0NCj4+IFRvOiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1NpbGljb25W YWxsZXkpDQo+PiBDYzogcGF3c0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtwYXdzXSBuZWVk IGZvciBEQiBpbml0aWFsaXphdGlvbiBtZXNzYWdlDQo+PiANCj4+IFJlbGF0ZWQgc3VnZ2VzdGlv bjogIEFzc3VtaW5nIHdlIGhhdmUgYSBkaXNjb3ZlcnkgcHJvdG9jb2wgd2hpY2ggY2FuDQo+PiBy ZXR1cm4gYSBVUkksIHRoZSBwcm90b2NvbCBzZW1hbnRpY3Mgc2hvdWxkIGJlIHN1Y2ggdGhhdCB0 aGUgVVJJIGNhbg0KPj4gYmUgdGhlIGZpbmFsIERCIFVSSSwgb3IgYW5vdGhlciBpbnRlcm1lZGlh cnkgaW4gdGhlIHByb2Nlc3MuICBUaHVzLA0KPj4gdGhlIHByb3RvY29sIHNob3VsZCBub3QgbG9j ayBpbiB0aGF0IHRoZXJlIGNhbiBiZSBvbmx5IDAgb3IgMQ0KPj4gaW50ZXJtZWRpYXJpZXMgaW4g dGhlIHJlc29sdXRpb24sIGJ1dCBzaG91bGQgYWxsb3cgc2V2ZXJhbC4gIChXZQ0KPj4gYWxyZWFk eSBoYXZlIHN1Z2dlc3RlZCBjYXNlcyB3aGVyZSBhdCBsZWFzdCB0d28gYXJlIG5lZWRlZCwgb25l IHRvDQo+PiBkZXRlcm1pbmUgd2hlcmUgeW91IGFyZSBieSBhc2tpbmcgeW91ciB2ZW5kb3IsIGFu ZCBvbmUgdG8gZGV0ZXJtaW5lDQo+PiB3aG8geW91IGNhbiB0YWxrIHRvIGJ5IGFza2luZyB5b3Vy IGxvY2FsIHJlZ3VsYXRvci4pDQo+PiANCj4+IFlvdXJzLA0KPj4gSm9lbA0KPj4gDQo+PiBPbiA4 LzkvMjAxMiA4OjAyIFBNLCBHYWJvci5CYWprb0Bub2tpYS5jb20gd3JvdGU6DQo+Pj4gRm9sa3Ms DQo+Pj4gDQo+Pj4gRHVyaW5nIHRoZSBWYW5jb3V2ZXIgRjJGIGRpc2N1c3Npb25zIHdlIGhhZCBz b21lIGdvb2QgZGlzY3Vzc2lvbnMsDQo+Pj4gYnV0IG5vIGFncmVlbWVudCBvbiB3ZXRoZXIgYW4g aW5pdGlhbGl6YXRpb24gbWVzc2FnZSwgYXMgcHJvcG9zZWQNCj4+PiBpbiBkcmFmdC1kYXMgaXMg bmVjZXNzYXJ5IG9yIG5vdC4NCj4+PiANCj4+PiBZb3UgbWF5IGNoZWNrIHRoZSBtaW51dGVzIHRv IHNlZSB3aGF0IHdhcyBzYWlkIGF0IHRoZSBtaWtlOg0KPj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvODQvbWludXRlcy9taW51dGVzLTg0LXBhd3MNCj4+PiANCj4+PiBQZW9wbGUg c3Bva2UgbW9zdGx5IGluIGZhdm9yLCBidXQgdGhlcmUgd2VyZSBwZW9wbGUgd2hvIGFsc28gc2Fp ZA0KPj4+IHRoYXQgdGhpcyBtZXNzYWdlIGlzIHJlZHVuZGFudCB3aXRoIHJlZ2lzdHJhdGlvbiBt ZXNzYWdlLg0KPj4+IA0KPj4+IFF1ZXN0aW9uIzE6IG5lZWQgZm9yIGFuIGluaXRpYWxpemF0aW9u IG1lc3NhZ2UNCj4+PiANCj4+PiBVbmZvcnR1bmF0ZWx5IHdlIGRpZCBub3QgaGF2ZSB0aW1lIHRv IGRpc2N1c3MgdGhlIERCIGRpc2NvdmVyeSBhc3BlY3QsDQo+Pj4gYW5kIHRoYXQgbWF5IGJlIHJl bGF0ZWQgdG8gdGhpcyB0b3BpYy4gVGhlIG9ubHkgREIgZGlzY292ZXJ5IGRvY3VtZW50DQo+Pj4g YXZhaWxhYmxlIGN1cnJlbnRseSwNCj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXBy b2Jhc2NvLXBhd3MtZGlzY292ZXJ5LTAxLnR4dCwgcHJvcG9zZXMsDQo+Pj4gdGhhdCB0aGUgbWFz dGVyIGRldmljZSBjb250YWN0cyBhIHByZS1wcm92aXNpb25lZCBkaXNjb3Zlcnkgc2VydmVyIGFu ZA0KPj4+IHByb3ZpZGVzIGl0cyBsb2NhdGlvbiwgYW5kIGluIHJldHVybiB0aGUgZGlzY292ZXJ5 IHNlcnZlciByZXR1cm5zIHRoZQ0KPj4+IFVSSSBvZiB0aGUgREIgZm9yIHRoYXQgcmVndWxhdG9y eSBkb21haW4uIEF0IHRoaXMgcG9pbnQsIHRoZSBtYXN0ZXINCj4+PiBkZXZpY2Uga25vd3Mgd2hp Y2ggREIgdG8gY29udGFjdCwgYnV0IGl0IGRvZXMgbm90IG5lY2Vzc2FyaWx5IGtub3cNCj4+PiB3 aGF0IHJlZ3VsYXRvcnkgZG9tYWluIHRoYXQgREIgYmVsb25ncyB0by4gVGh1cywgaXQgZG9lc24n dCBrbm93IHdoYXQNCj4+PiBhcmUgdGhlIG9wZXJhdGluZyBydWxlcywgd2hldGhlciBpdCBoYXMg dG8gYXV0aGVudGljYXRlLCBvciByZWdpc3RlciwNCj4+PiBldGMuDQo+Pj4gDQo+Pj4gVGh1cywg aXQgc2VlbXMgbG9naWNhbCB0byBtZSB0aGF0IHRoZSBtYXN0ZXIgZGV2aWNlIGZpcnN0IHF1ZXJp ZXMgdGhlDQo+Pj4gREIgdG8gZmluZCBvdXQgdGhlIHJlZ3VsYXRvcnkgZG9tYWluLiBXZSBldmVu IGhhdmUgc3VjaCBhIHJlcXVpcmVtZW50DQo+Pj4gaW4gdGhlIHJlcXVpcmVtZW50IGRyYWZ0LCBy ZXF1aXJlbWVudDoNCj4+PiANCj4+PiAiUC4zOiAgIFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQg ZGV0ZXJtaW5hdGlvbiBvZg0KPj4+IHJlZ3VsYXRvcnkgICAgICAgICAgICAgZG9tYWluIGdvdmVy bmluZyBpdHMgY3VycmVudCBsb2NhdGlvbi4iDQo+Pj4gDQo+Pj4gVGhlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSByZWd1bGF0b3J5IGRvbWFpbiBtYXkgYmUgY2FjaGVkLCBhbmQgdGhlDQo+Pj4gbWFz dGVyIGRldmljZSBtYXkgbm90IG5lZWQgdG8gcGxhY2UgdGhhdCBxdWVyeSBldmVyeSB0aW1lLCBi dXQgdGhpcw0KPj4+IG1lc3NhZ2UgZXhjaGFuZ2UgbWF5IGJlIG5lY2Vzc2FyeSBpbiBjZXJ0YWlu IGNhc2VzLiBBbnkgY29tbWVudHMgdG8NCj4+PiB0aGlzIHBvaW50Pw0KPj4+IA0KPj4+IFF1ZXN0 aW9uIzINCj4+PiANCj4+PiBUaGVuLCBpdCBpcyBhIHNsaWdodGx5IHNlcGFyYXRlIGlzc3VlLCBp ZiB0aGlzIG1lc3NhZ2UgZXhjaGFuZ2UgaGFzDQo+Pj4gdG8gdGFrZSBwbGFjZSwgdGhlbiB3aGF0 IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdGhlIERCIHJldHVybnMuDQo+Pj4gZHJhZnQtZGFzIHBy b3Bvc2VzIHRoYXQgcmVndWxhdG9yeSBkb21haW4gc3BlY2lmaWMgaW5mb3JtYXRpb24gYmUNCj4+ PiByZXR1cm5lZCB0byB0aGUgbWFzdGVyIGRldmljZS4NCj4+PiANCj4+PiBRdWVzdGlvbiMzDQo+ Pj4gDQo+Pj4gWWV0IGFub3RoZXIgc2VwYXJhdGUgcG9pbnQgaXMgdGhhdCBkcmFmdC1kYXMgcHJv cG9zZXMgdG8gdXNlIHRoaXMNCj4+PiBpbml0aWFsaXphdGlvbiBtZXNzYWdlIGFsc28gdG8gaW5p dGlhdGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIChwdXR0aW5nDQo+Pj4gc2hhcmVkIHNlY3JldCB2 cyBjZXJ0IGlzc3VlIGFzaWRlIGZvciB0aGUgdGltZSBiZWluZykuIEluIGNhc2VzIHdoZW4NCj4+ PiB0aGUgbWFzdGVyIGRldmljZSBkb2VzIG5vdCBrbm93IHRoZSByZWd1bGF0b3J5IGRvbWFpbiBp dCBpcyBpbiwgdGhlbg0KPj4+IGl0IGRvZXMgbm90IGtub3cgd2hldGhlciBhdXRoZW50aWNhdGlv biBpcyByZXF1aXJlZCBpbiB0aGF0IHJlZ3VsYXRvcnkNCj4+PiBkb21haW4gb3Igbm90OyBzbyB3 aHkgd291bGQgaW5pdGlhdGUgYXV0aGVudGljYXRpb24gdGhlbj8gU2ltaWxhcg0KPj4+IGNvbW1l bnQgYXBwbGllcyB0byBkcmFmdC13ZWksIHdoZXJlIGl0IGlzIHByb3Bvc2VkIHRoYXQgYWZ0ZXIg REINCj4+PiBkaXNjb3ZlcnkgdGhlIG1hc3RlciBkZXZpY2UgYXV0aGVudGljYXRlcyBhdCBUTFMg bGF5ZXIgYW5kIHBlcmZvcm1zDQo+Pj4gcmVnaXN0cmF0aW9uOyBob3cgZG9lcyBpdCBrbm93IHRo YXQgaXQgaGFzIHRvIGF1dGhlbnRpY2F0ZSBhbmQNCj4+PiByZWdpc3RlciwgaWYgaXQgZG9lc24n dCBrbm93IHRoZSByZWd1bGF0b3J5IGRvbWFpbj8NCj4+PiANCj4+PiBJbiBteSBvcGluaW9uIChj aGFpciBoYXQgb2ZmKSwgdGhlIHNlcXVlbmNlIG9mIGV2ZW50cyBzaG91bGQgYmUgc2cNCj4+PiBs aWtlDQo+Pj4gdGhpczoNCj4+PiANCj4+PiAxLkRCIGRpc2NvdmVyeSAobWF5IGJlIHNraXBwZWQg aWYgY2FjaGVkIGluZm9ybWF0aW9uIGF2YWlsYWJsZSkNCj4+PiANCj4+PiAyLlJlZ3VsYXRvcnkg ZG9tYWluIHF1ZXJ5IChtYXkgYmUgc2tpcHBlZCBpZiBjYWNoZWQgaW5mb3JtYXRpb24NCj4+PiBh dmFpbGFibGUpDQo+Pj4gDQo+Pj4gMy5BdXRoZW50aWNhdGlvbiAoaWYgcmVxdWlyZWQpDQo+Pj4g DQo+Pj4gNC5SZWdpc3RyYXRpb24gKGlmIHJlcXVpcmVkKQ0KPj4+IA0KPj4+IDUuQ2hhbm5lbCBh dmFpbGFiaWxpdHkgcXVlcnkgKG1heSBiZSBjb21iaW5lZCB3aXRoIHJlZ2lzdHJhdGlvbj8pDQo+ Pj4gDQo+Pj4gQ29tbWVudHMgYXJlIHdlbGNvbWUgYW5kIGV4cGVjdGVkLg0KPj4+IA0KPj4+IC1H YWJvcg0KPj4+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KcGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0K From Peter.McCann@huawei.com Mon Aug 13 08:06:50 2012 Return-Path: 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 0426E21F85D1 for ; Mon, 13 Aug 2012 08:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.842 X-Spam-Level: X-Spam-Status: No, score=-5.842 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sm9xNnedOZ6Q for ; Mon, 13 Aug 2012 08:06:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0F70621F85ED for ; Mon, 13 Aug 2012 08:06:34 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJG19876; Mon, 13 Aug 2012 07:06:33 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 08:04:07 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.75]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Mon, 13 Aug 2012 08:04:02 -0700 From: Peter McCann To: "Rosen, Brian" , "'Joel M. Halpern'" , "'gabor.bajko@nokia.com'" Thread-Topic: [paws] need for DB initialization message Thread-Index: Ac12he0A+5h4j+uqT6e4F6BpK7EzXwAAEnAAADHrtdAAENwZAAB0JGqAAABxXLgAAEoioA== Date: Mon, 13 Aug 2012 15:04:01 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E1AF96@dfweml512-mbx.china.huawei.com> References: <55A5A9A87506CB4BA580BF9D531957DA690227B7@STNTEXCH01.cis.neustar.com> In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA690227B7@STNTEXCH01.cis.neustar.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.96] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'paws@ietf.org'" Subject: Re: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 15:06:50 -0000 VGhhdCB3b3VsZCB3b3JrIHRvby4NCg0KLVBldGUNCg0KUm9zZW4sIEJyaWFuIHdyb3RlOg0KPiA8 YXMgaW5kaXZpZHVhbD4NCj4gSSBwcmVmZXIgTG9TVCBmb3IgZGlzY292ZXJ5LiAgTG9TVCBjYW4g ZG8gcmVjdXIvaXRlcmF0ZSBsaWtlIEROUywgYW5kDQo+IGl0IGNhbiByZXR1cm4gbW9yZSB0aGFu IG9uZSBVUkkuICBUaGF0IHdvdWxkIGFsbG93IHRoZSBiYXNlIExvU1QNCj4gZGlzY292ZXJ5IHRv IGZpbmQgYSBzZXJ2ZXIgdGhhdCByZXR1cm5lZCB0aGUgbGlzdC4gIFRoZSBpbml0aWFsIExvU1QN Cj4gcXVlcnkgcmV0dXJucyB0aGUgbGlzdCBzZXJ2ZXIsIGFuZCBhIHJlY3VyIG9yIGl0ZXJhdGUg cmV0dXJucyB0aGUgbGlzdC4NCj4gDQo+IEJyaWFuDQo+IA0KPiANCj4gDQo+ICAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiAJUGV0ZXIgTWNDYW5uIFttYWlsdG86UGV0ZXIuTWND YW5uQGh1YXdlaS5jb21dDQo+IFNlbnQ6CU1vbmRheSwgQXVndXN0IDEzLCAyMDEyIDEwOjQ3IEFN IEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KPiBUbzoJSm9lbCBNLiBIYWxwZXJuOyBHYWJvci5CYWpr b0Bub2tpYS5jb20NCj4gQ2M6CXBhd3NAaWV0Zi5vcmcNCj4gU3ViamVjdDoJUmU6IFtwYXdzXSBu ZWVkIGZvciBEQiBpbml0aWFsaXphdGlvbiBtZXNzYWdlDQo+IA0KPiBBZ3JlZSB3aXRoIEpvZWwu DQo+IA0KPiBJIHRoaW5rIGEgTE9TVC1zdHlsZSBzZXJ2aWNlIChhKSBpcyBnb29kIGZvciBkaXNj b3ZlcmluZyBhIHNlcnZlcg0KPiBhc3NvY2lhdGVkIHdpdGggYSByZWd1bGF0b3J5IGRvbWFpbi4g IEFmdGVyIHRoYXQsIHlvdSBjYW4gcXVlcnkgdGhlDQo+IHJlZ3VsYXRvciAoYikgdG8gZmluZCBh cHByb3ZlZCBkYXRhYmFzZXMuICBUaGVuLCB5b3UgY2FuIGNob29zZSBvbmUgb2YNCj4gdGhvc2Ug ZGF0YWJhc2VzIHdpdGggd2hpY2ggeW91IGhhdmUgYSByZWxhdGlvbnNoaXAgb3IgdGhhdCB5b3Ug a25vdw0KPiB0aHJvdWdoIHNvbWUgbWVhbnMgd2lsbCBzZXJ2aWNlIHlvdXIgcmVxdWVzdCAoYyku ICBUaGUgcHJvdG9jb2wgZm9yDQo+IChiKSBhbmQgKGMpIGNvdWxkIGJvdGggYmUgUEFXUywgaWYg d2UganVzdCBhZGQgc29tZSBzb3J0IG9mDQo+IGluZGlyZWN0aW9uIHRvIG91ciBzcGVjaWZpY2F0 aW9uLg0KPiANCj4gLVBldGUNCj4gDQo+IA0KPiBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+PiBU aGUgbWFzdGVyIGhhcyB0byBrbm93IGl0cyBsb2NhdGlvbiBpbiBnZW9ncmFwaGljIGNvb3JkaW5h dGVzIChHUFMsDQo+PiBldGMuKSAgIEFzIGZhciBhcyBJIGtub3csIHdlIGhhdmUgbm90IGFzc3Vt ZWQgdGhhdCB0aGUgbWFwcyB0bw0KPj4gdHJhbnNsYXRlIHRoYXQgaW50byBwb2xpdGljYWwgZG9t YWlucyBhcmUga25vd24gdG8gdGhlIG1hc3RlciBhIHByaW9yaS4NCj4+IA0KPj4gVGhlcmUgYXJl IGRlcGxveW1lbnQgc2NlbmFyaW9zIChjZWxsIHRvd2VycyBjb21lIHRvIG1pbmQpIHdoZXJlIHRo ZQ0KPj4gbWFzdGVyIGNhbiBwcm9iYWJseSBiZSBwcm92aXNpb25lZCB3aXRoIHRoZSByaWdodCBh ZG1pbmlzdHJhdGl2ZQ0KPj4gaW5mb3JtYXRpb24uICBUaGVyZSBhcmUgb3RoZXIgc2NlbmFyaW9z IHdoZXJlIHRoYXQgaXMgbm90IG9idmlvdXNseQ0KPj4gYWNoaWV2YWJsZS4NCj4+IA0KPj4gWW91 cnMsDQo+PiBKb2VsDQo+PiANCj4+IE9uIDgvMTAvMjAxMiA3OjMzIFBNLCBHYWJvci5CYWprb0Bu b2tpYS5jb20gd3JvdGU6DQo+Pj4gV2hpbGUgSSBhZ3JlZSB0aGF0IHJlLWRpcmVjdGlvbiBmcm9t IGFuIGludGVybWVkaWFyeSB0byB0aGUgZmluYWwNCj4+IHJlY2lwaWVudCBzaG91bGQgbm90IGJl IGRpc2FsbG93ZWQsIEkgZG9uJ3QgdGhpbmsgdGhlIHVzZSBjYXNlIHlvdSBhcmUNCj4+IGRlc2Ny aWJpbmcgaXMgYSB2YWxpZCBvbmUuIFRoZSBtYXN0ZXIgbmVlZHMgdG8ga25vdyBpdHMgbG9jYXRp b24gYmVmb3JlDQo+PiBlbmdhZ2luZyBpbnRvIERCIGRpc2NvdmVyeS4gSWYgaXQgZG9lc24ndCwg dGhlbiBpdCBjYW4gdXNlIHNvbWUNCj4+IGV4aXN0aW5nIG1lY2hhbmlzbSB0byBmaW5kIGl0IG91 dCAoZWcsIFJGQzU5ODUpIHByaW9yIHRvIHRoZSBEQg0KPj4gZGlzY292ZXJ5IHByb2Nlc3MsIGJ1 dCB0aGF0IGZvciBtZSBpcyBhIHNlcGFyYXRlIHRyYW5zYWN0aW9uLg0KPj4+IA0KPj4+IFRoZSBj dXJyZW50IERCIGRpc2NvdmVyeSBtZWNoYW5pc20gZGVzY3JpYmVkIGluDQo+PiBodHRwOi8vd3d3 LmlldGYub3JnL2lkL2RyYWZ0LXByb2Jhc2NvLXBhd3MtZGlzY292ZXJ5LTAxLnR4dCBhc3N1bWVz DQo+PiB0aGF0IHRoZSBtYXN0ZXIga25vd3MgaXRzIGxvY2F0aW9uIGJlZm9yZSBwZXJmb3JtaW5n IERCIGRpc2NvdmVyeTsNCj4+IGFmdGVyIHdoaWNoIGl0IG5lZWRzIHRvIGRvIGEgcmVndWxhdG9y eSBkb21haW4gZGlzY292ZXJ5IGFzIHdlbGwuDQo+PiBCcmlhbiBzdWdnZXN0ZWQgcmVndWxhdG9y eSBkb21haW4gY291bGQgYmUgYSBwYXJhbWV0ZXIgb2YgdGhlIERCDQo+PiBVUkksIHRodXMgbm8g bmVlZCBmb3Igc2VwYXJhdGUgcmVndWxhdG9yeSBkb21haW4gZGlzY292ZXJ5LiBBbnkNCj4+IG90 aGVyDQo+IHN1Z2dlc3Rpb25zPw0KPj4+IA0KPj4+IC0gR2Fib3INCj4+PiANCj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IGV4dCBKb2VsIE0uIEhhbHBlcm4gW21haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPj4+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMDksIDIw MTIgNjoyNSBQTQ0KPj4+IFRvOiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkp DQo+Pj4gQ2M6IHBhd3NAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSZTogW3Bhd3NdIG5lZWQgZm9y IERCIGluaXRpYWxpemF0aW9uIG1lc3NhZ2UNCj4+PiANCj4+PiBSZWxhdGVkIHN1Z2dlc3Rpb246 ICBBc3N1bWluZyB3ZSBoYXZlIGEgZGlzY292ZXJ5IHByb3RvY29sIHdoaWNoDQo+Pj4gY2FuIHJl dHVybiBhIFVSSSwgdGhlIHByb3RvY29sIHNlbWFudGljcyBzaG91bGQgYmUgc3VjaCB0aGF0IHRo ZQ0KPj4+IFVSSSBjYW4gYmUgdGhlIGZpbmFsIERCIFVSSSwgb3IgYW5vdGhlciBpbnRlcm1lZGlh cnkgaW4gdGhlDQo+Pj4gcHJvY2Vzcy4gIFRodXMsIHRoZSBwcm90b2NvbCBzaG91bGQgbm90IGxv Y2sgaW4gdGhhdCB0aGVyZSBjYW4gYmUNCj4+PiBvbmx5IDAgb3IgMSBpbnRlcm1lZGlhcmllcyBp biB0aGUgcmVzb2x1dGlvbiwgYnV0IHNob3VsZCBhbGxvdw0KPj4+IHNldmVyYWwuICAoV2UgYWxy ZWFkeSBoYXZlIHN1Z2dlc3RlZCBjYXNlcyB3aGVyZSBhdCBsZWFzdCB0d28gYXJlDQo+Pj4gbmVl ZGVkLCBvbmUgdG8gZGV0ZXJtaW5lIHdoZXJlIHlvdSBhcmUgYnkgYXNraW5nIHlvdXIgdmVuZG9y LCBhbmQNCj4+PiBvbmUgdG8gZGV0ZXJtaW5lIHdobyB5b3UgY2FuIHRhbGsgdG8gYnkgYXNraW5n IHlvdXIgbG9jYWwNCj4+PiByZWd1bGF0b3IuKQ0KPj4+IA0KPj4+IFlvdXJzLA0KPj4+IEpvZWwN Cj4+PiANCj4+PiBPbiA4LzkvMjAxMiA4OjAyIFBNLCBHYWJvci5CYWprb0Bub2tpYS5jb20gd3Jv dGU6DQo+Pj4+IEZvbGtzLA0KPj4+PiANCj4+Pj4gRHVyaW5nIHRoZSBWYW5jb3V2ZXIgRjJGIGRp c2N1c3Npb25zIHdlIGhhZCBzb21lIGdvb2QgZGlzY3Vzc2lvbnMsDQo+Pj4+IGJ1dCBubyBhZ3Jl ZW1lbnQgb24gd2V0aGVyIGFuIGluaXRpYWxpemF0aW9uIG1lc3NhZ2UsIGFzIHByb3Bvc2VkIGlu DQo+Pj4+IGRyYWZ0LWRhcyBpcyBuZWNlc3Nhcnkgb3Igbm90Lg0KPj4+PiANCj4+Pj4gWW91IG1h eSBjaGVjayB0aGUgbWludXRlcyB0byBzZWUgd2hhdCB3YXMgc2FpZCBhdCB0aGUgbWlrZToNCj4+ Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84NC9taW51dGVzL21pbnV0ZXMtODQt cGF3cw0KPj4+PiANCj4+Pj4gUGVvcGxlIHNwb2tlIG1vc3RseSBpbiBmYXZvciwgYnV0IHRoZXJl IHdlcmUgcGVvcGxlIHdobyBhbHNvIHNhaWQNCj4+Pj4gdGhhdCB0aGlzIG1lc3NhZ2UgaXMgcmVk dW5kYW50IHdpdGggcmVnaXN0cmF0aW9uIG1lc3NhZ2UuDQo+Pj4+IA0KPj4+PiBRdWVzdGlvbiMx OiBuZWVkIGZvciBhbiBpbml0aWFsaXphdGlvbiBtZXNzYWdlDQo+Pj4+IA0KPj4+PiBVbmZvcnR1 bmF0ZWx5IHdlIGRpZCBub3QgaGF2ZSB0aW1lIHRvIGRpc2N1c3MgdGhlIERCIGRpc2NvdmVyeQ0K Pj4+PiBhc3BlY3QsIGFuZCB0aGF0IG1heSBiZSByZWxhdGVkIHRvIHRoaXMgdG9waWMuIFRoZSBv bmx5IERCIGRpc2NvdmVyeQ0KPj4+PiBkb2N1bWVudCBhdmFpbGFibGUgY3VycmVudGx5LA0KPj4+ PiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXByb2Jhc2NvLXBhd3MtZGlzY292ZXJ5LTAx LnR4dCwNCj4+Pj4gcHJvcG9zZXMsIHRoYXQgdGhlIG1hc3RlciBkZXZpY2UgY29udGFjdHMgYSBw cmUtcHJvdmlzaW9uZWQgZGlzY292ZXJ5DQo+Pj4+IHNlcnZlciBhbmQgcHJvdmlkZXMgaXRzIGxv Y2F0aW9uLCBhbmQgaW4gcmV0dXJuIHRoZSBkaXNjb3Zlcnkgc2VydmVyDQo+Pj4+IHJldHVybnMg dGhlIFVSSSBvZiB0aGUgREIgZm9yIHRoYXQgcmVndWxhdG9yeSBkb21haW4uIEF0IHRoaXMgcG9p bnQsDQo+Pj4+IHRoZSBtYXN0ZXIgZGV2aWNlIGtub3dzIHdoaWNoIERCIHRvIGNvbnRhY3QsIGJ1 dCBpdCBkb2VzIG5vdA0KPj4+PiBuZWNlc3NhcmlseSBrbm93IHdoYXQgcmVndWxhdG9yeSBkb21h aW4gdGhhdCBEQiBiZWxvbmdzIHRvLiBUaHVzLCBpdA0KPj4+PiBkb2Vzbid0IGtub3cgd2hhdCBh cmUgdGhlIG9wZXJhdGluZyBydWxlcywgd2hldGhlciBpdCBoYXMgdG8NCj4+Pj4gYXV0aGVudGlj YXRlLCBvciByZWdpc3RlciwgZXRjLg0KPj4+PiANCj4+Pj4gVGh1cywgaXQgc2VlbXMgbG9naWNh bCB0byBtZSB0aGF0IHRoZSBtYXN0ZXIgZGV2aWNlIGZpcnN0IHF1ZXJpZXMNCj4+Pj4gdGhlIERC IHRvIGZpbmQgb3V0IHRoZSByZWd1bGF0b3J5IGRvbWFpbi4gV2UgZXZlbiBoYXZlIHN1Y2ggYQ0K Pj4+PiByZXF1aXJlbWVudCBpbiB0aGUgcmVxdWlyZW1lbnQgZHJhZnQsIHJlcXVpcmVtZW50Og0K Pj4+PiANCj4+Pj4gIlAuMzogICBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGRldGVybWluYXRp b24gb2YNCj4+Pj4gcmVndWxhdG9yeSAgICAgICAgICAgICBkb21haW4gZ292ZXJuaW5nIGl0cyBj dXJyZW50IGxvY2F0aW9uLiINCj4+Pj4gDQo+Pj4+IFRoZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUg cmVndWxhdG9yeSBkb21haW4gbWF5IGJlIGNhY2hlZCwgYW5kIHRoZQ0KPj4+PiBtYXN0ZXIgZGV2 aWNlIG1heSBub3QgbmVlZCB0byBwbGFjZSB0aGF0IHF1ZXJ5IGV2ZXJ5IHRpbWUsIGJ1dA0KPj4+ PiB0aGlzIG1lc3NhZ2UgZXhjaGFuZ2UgbWF5IGJlIG5lY2Vzc2FyeSBpbiBjZXJ0YWluIGNhc2Vz LiBBbnkNCj4+Pj4gY29tbWVudHMgdG8gdGhpcyBwb2ludD8NCj4+Pj4gDQo+Pj4+IFF1ZXN0aW9u IzINCj4+Pj4gDQo+Pj4+IFRoZW4sIGl0IGlzIGEgc2xpZ2h0bHkgc2VwYXJhdGUgaXNzdWUsIGlm IHRoaXMgbWVzc2FnZSBleGNoYW5nZQ0KPj4+PiBoYXMgdG8gdGFrZSBwbGFjZSwgdGhlbiB3aGF0 IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdGhlIERCIHJldHVybnMuDQo+Pj4+IGRyYWZ0LWRhcyBw cm9wb3NlcyB0aGF0IHJlZ3VsYXRvcnkgZG9tYWluIHNwZWNpZmljIGluZm9ybWF0aW9uIGJlDQo+ Pj4+IHJldHVybmVkIHRvIHRoZSBtYXN0ZXIgZGV2aWNlLg0KPj4+PiANCj4+Pj4gUXVlc3Rpb24j Mw0KPj4+PiANCj4+Pj4gWWV0IGFub3RoZXIgc2VwYXJhdGUgcG9pbnQgaXMgdGhhdCBkcmFmdC1k YXMgcHJvcG9zZXMgdG8gdXNlIHRoaXMNCj4+Pj4gaW5pdGlhbGl6YXRpb24gbWVzc2FnZSBhbHNv IHRvIGluaXRpYXRlIGNsaWVudCBhdXRoZW50aWNhdGlvbg0KPj4+PiAocHV0dGluZyBzaGFyZWQg c2VjcmV0IHZzIGNlcnQgaXNzdWUgYXNpZGUgZm9yIHRoZSB0aW1lIGJlaW5nKS4gSW4NCj4+Pj4g Y2FzZXMgd2hlbiB0aGUgbWFzdGVyIGRldmljZSBkb2VzIG5vdCBrbm93IHRoZSByZWd1bGF0b3J5 IGRvbWFpbiBpdA0KPj4+PiBpcyBpbiwgdGhlbiBpdCBkb2VzIG5vdCBrbm93IHdoZXRoZXIgYXV0 aGVudGljYXRpb24gaXMgcmVxdWlyZWQgaW4NCj4+Pj4gdGhhdCByZWd1bGF0b3J5IGRvbWFpbiBv ciBub3Q7IHNvIHdoeSB3b3VsZCBpbml0aWF0ZSBhdXRoZW50aWNhdGlvbg0KPj4+PiB0aGVuPyBT aW1pbGFyIGNvbW1lbnQgYXBwbGllcyB0byBkcmFmdC13ZWksIHdoZXJlIGl0IGlzIHByb3Bvc2Vk IHRoYXQNCj4+Pj4gYWZ0ZXIgREIgZGlzY292ZXJ5IHRoZSBtYXN0ZXIgZGV2aWNlIGF1dGhlbnRp Y2F0ZXMgYXQgVExTIGxheWVyIGFuZA0KPj4+PiBwZXJmb3JtcyByZWdpc3RyYXRpb247IGhvdyBk b2VzIGl0IGtub3cgdGhhdCBpdCBoYXMgdG8gYXV0aGVudGljYXRlDQo+Pj4+IGFuZCByZWdpc3Rl ciwgaWYgaXQgZG9lc24ndCBrbm93IHRoZSByZWd1bGF0b3J5IGRvbWFpbj8NCj4+Pj4gDQo+Pj4+ IEluIG15IG9waW5pb24gKGNoYWlyIGhhdCBvZmYpLCB0aGUgc2VxdWVuY2Ugb2YgZXZlbnRzIHNo b3VsZCBiZSBzZw0KPj4+PiBsaWtlDQo+Pj4+IHRoaXM6DQo+Pj4+IA0KPj4+PiAxLkRCIGRpc2Nv dmVyeSAobWF5IGJlIHNraXBwZWQgaWYgY2FjaGVkIGluZm9ybWF0aW9uIGF2YWlsYWJsZSkNCj4+ Pj4gDQo+Pj4+IDIuUmVndWxhdG9yeSBkb21haW4gcXVlcnkgKG1heSBiZSBza2lwcGVkIGlmIGNh Y2hlZCBpbmZvcm1hdGlvbg0KPj4+PiBhdmFpbGFibGUpDQo+Pj4+IA0KPj4+PiAzLkF1dGhlbnRp Y2F0aW9uIChpZiByZXF1aXJlZCkNCj4+Pj4gDQo+Pj4+IDQuUmVnaXN0cmF0aW9uIChpZiByZXF1 aXJlZCkNCj4+Pj4gDQo+Pj4+IDUuQ2hhbm5lbCBhdmFpbGFiaWxpdHkgcXVlcnkgKG1heSBiZSBj b21iaW5lZCB3aXRoIHJlZ2lzdHJhdGlvbj8pDQo+Pj4+IA0KPj4+PiBDb21tZW50cyBhcmUgd2Vs Y29tZSBhbmQgZXhwZWN0ZWQuDQo+Pj4+IA0KPj4+PiAtR2Fib3INCj4+Pj4gDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBwYXdzIG1haWxp bmcgbGlzdA0KPiBwYXdzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcGF3cw0KDQoNCg0K From Basavaraj.Patil@nokia.com Mon Aug 13 09:56:46 2012 Return-Path: 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 A418721F8703 for ; Mon, 13 Aug 2012 09:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ30GOgCs5Zb for ; Mon, 13 Aug 2012 09:56:46 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8C11921F8700 for ; Mon, 13 Aug 2012 09:56:45 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7DGuB29021703 for ; Mon, 13 Aug 2012 19:56:44 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Aug 2012 19:57:19 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.02.0283.004; Mon, 13 Aug 2012 18:56:17 +0200 From: To: , Thread-Topic: [paws] need for DB initialization message Thread-Index: Ac12he0A+5h4j+uqT6e4F6BpK7EzXwAAEnAAADHrtdAAev5HAA== Date: Mon, 13 Aug 2012 16:56:17 +0000 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB0839@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [87.254.201.157] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Aug 2012 16:57:20.0039 (UTC) FILETIME=[B3A00B70:01CD7974] X-Nokia-AV: Clean Subject: Re: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 16:56:46 -0000 Hi Gabor, You stated below: >The current DB discovery mechanism described in >http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt assumes that >the master knows its location before performing DB discovery; That=B9s not how we intended it in the I-D. The master device knows about the address associated with a database discovery server. The master device has awareness such as CellIDs or SSIDs or GPS co-ordinates etc which it sends to the database discovery server. The database discovery server can use such information to identify the devices current location and/or regulatory domain. -Raj=20 On 8/10/12 6:33 PM, "Bajko Gabor (Nokia-CIC/SiliconValley)" wrote: >While I agree that re-direction from an intermediary to the final >recipient should not be disallowed, I don't think the use case you are >describing is a valid one. The master needs to know its location before >engaging into DB discovery. If it doesn't, then it can use some existing >mechanism to find it out (eg, RFC5985) prior to the DB discovery process, >but that for me is a separate transaction. > >The current DB discovery mechanism described in >http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt assumes that >the master knows its location before performing DB discovery; after which >it needs to do a regulatory domain discovery as well. Brian suggested >regulatory domain could be a parameter of the DB URI, thus no need for >separate regulatory domain discovery. Any other suggestions? > >- Gabor=20 > >-----Original Message----- >From: ext Joel M. Halpern [mailto:jmh@joelhalpern.com] >Sent: Thursday, August 09, 2012 6:25 PM >To: Bajko Gabor (Nokia-CIC/SiliconValley) >Cc: paws@ietf.org >Subject: Re: [paws] need for DB initialization message > >Related suggestion: Assuming we have a discovery protocol which can >return a URI, the protocol semantics should be such that the URI can be >the final DB URI, or another intermediary in the process. Thus, the >protocol should not lock in that there can be only 0 or 1 intermediaries >in the resolution, but should allow several. (We already have suggested >cases where at least two are needed, one to determine where you are by >asking your vendor, and one to determine who you can talk to by asking >your local regulator.) > >Yours, >Joel > >On 8/9/2012 8:02 PM, Gabor.Bajko@nokia.com wrote: >> Folks, >> >> During the Vancouver F2F discussions we had some good discussions, but >> no agreement on wether an initialization message, as proposed in >> draft-das is necessary or not. >> >> You may check the minutes to see what was said at the mike: >> http://www.ietf.org/proceedings/84/minutes/minutes-84-paws >> >> People spoke mostly in favor, but there were people who also said that >> this message is redundant with registration message. >> >> Question#1: need for an initialization message >> >> Unfortunately we did not have time to discuss the DB discovery aspect, >> and that may be related to this topic. The only DB discovery document >> available currently, >> http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, proposes, >> that the master device contacts a pre-provisioned discovery server and >> provides its location, and in return the discovery server returns the >> URI of the DB for that regulatory domain. At this point, the master >> device knows which DB to contact, but it does not necessarily know what >> regulatory domain that DB belongs to. Thus, it doesn't know what are the >> operating rules, whether it has to authenticate, or register, etc. >> >> Thus, it seems logical to me that the master device first queries the DB >> to find out the regulatory domain. We even have such a requirement in >> the requirement draft, requirement: >> >> "P.3: The protocol MUST support determination of >> regulatory domain governing its current location." >> >> The information about the regulatory domain may be cached, and the >> master device may not need to place that query every time, but this >> message exchange may be necessary in certain cases. Any comments to this >> point? >> >> Question#2 >> >> Then, it is a slightly separate issue, if this message exchange has to >> take place, then what additional information the DB returns. draft-das >> proposes that regulatory domain specific information be returned to the >> master device. >> >> Question#3 >> >> Yet another separate point is that draft-das proposes to use this >> initialization message also to initiate client authentication (putting >> shared secret vs cert issue aside for the time being). In cases when the >> master device does not know the regulatory domain it is in, then it does >> not know whether authentication is required in that regulatory domain or >> not; so why would initiate authentication then? Similar comment applies >> to draft-wei, where it is proposed that after DB discovery the master >> device authenticates at TLS layer and performs registration; how does it >> know that it has to authenticate and register, if it doesn't know the >> regulatory domain? >> >> In my opinion (chair hat off), the sequence of events should be sg like >> this: >> >> 1.DB discovery (may be skipped if cached information available) >> >> 2.Regulatory domain query (may be skipped if cached information >>available) >> >> 3.Authentication (if required) >> >> 4.Registration (if required) >> >> 5.Channel availability query (may be combined with registration?) >> >> Comments are welcome and expected. >> >> -Gabor >> >> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Mon Aug 13 10:11:50 2012 Return-Path: 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 532D221F86DA for ; Mon, 13 Aug 2012 10:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT9QcYJQ3Vge for ; Mon, 13 Aug 2012 10:11:49 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA2621F8582 for ; Mon, 13 Aug 2012 10:11:48 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7DHBhxx008102 for ; Mon, 13 Aug 2012 20:11:46 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Aug 2012 20:12:35 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.192]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0283.004; Mon, 13 Aug 2012 19:11:33 +0200 From: To: Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac132A+fbbG4lfLAT8aeYHhnRNTamABfuNkz///KeYA= Date: Mon, 13 Aug 2012 17:11:32 +0000 Message-ID: In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA690227B5@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [10.184.34.13] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Aug 2012 17:12:35.0336 (UTC) FILETIME=[D52F4880:01CD7976] X-Nokia-AV: Clean Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 17:11:50 -0000 Hi All, Given that we have completed two Working Group Last Call cycles and this next version will go to the IESG, I hope we could agree on minimal changes to the document, i.e. changes only to D.7 for this topic. This will ensure the proper requirements are established for the developing PAWS protocol. I believe Brian's proposed text captures the essential requirements. Kind Regards, Scott On 8/13/12 8:24 AM, "ext Rosen, Brian" wrote: > >I would prefer to not use the word "channel" in our documents at all >except for the term "channel identifier". I proposed "spectrum unit", >although any other term will do. "Channel" has too much baggage, A >simple editorial change like this is simple, and it's much better to do >it now. > >I think we need power in both the query and the response. In some >domains, it may be that you specify what power you want to use and the DB >tells you what spectrum you can use at that power. In other, a US-like >rule may be in place. Also in either the query or the registration, we >need a device type, which should be an entry from an IANA registry. This >is how you get the US "Mode II" information. > >With regard to schedule, I would like to see two mechanisms >1) a time by which the database should be queried again (which could >represent the next change in schedule) >2) start/stop times for each spectrum unit available > >Both these should be optional in the response. > >My text > >The data model must support specifying spectrum availability. Spectrum >units are specified by low and high frequencies and may have an optional >channel identifier. > >The data model must support a schedule for spectrum unit availability. >Two mechanisms must be supported. The response to spectrum availability >query may include a time by which the database must be requeried. Each >spectrum unit mentioned in the response may be annotated with start and >stop time/date. =20 > > > > -----Original Message----- >From: Eric Chu [mailto:ericchu@google.com] >Sent: Saturday, August 11, 2012 11:43 AM Eastern Standard Time >To: Teco Boot >Cc: Rosen, Brian; paws@ietf.org >Subject: Re: [paws] use cases and requirements document > > >Hi everyone, > >Gathering all the shared points from everyone... I believe below is the >complete list so far: > > > >* What's the best consistent representation of the words "channel >numbers" for non-TV spectrum >* Should we update the entire doc on the topic of =B3channel=B2 or >=B3channel numbers=B2 >* What=B9s the best way to reduce vagueness in whether/how to include >"channel numbers" >* Is the reference to variable power required >* What does channel availability schedule mean > > >Brian's suggestion of replacing every instance of "channel" is >technically correctly. However, it is important for us to focus moving >forward. I would suggest we only work on the normative part of the spec. > The section Gabor is proposing for us to modify... > >On what's the best generic label for the words "channel numbers", channel >identifier might be the most accurate and neutral "label". Thoughts? > >On the question whether variable power is required, based on FCC >adjacent-channel rules, the database may limit the Mode II devices to >100mW for some channels and 40mW for others. Therefore, the data model >needs to support specification of maximum power levels. > >Lastly, with regards to "schedule", the intent is to have a way of >informing devices when to operate for each frequency range. As long as >the data model supports, for example, a list of time ranges, it does not >prevent an implementation from providing a list with 1 entry which >corresponds to the "shortest available". The word "schedule" should be >sufficient to capture this intent? > >We would like to propose the following text to address these points: > >"The Data Model MUST support specifying available spectrum. The Data >Model MUST support specification of this information by start and stop >frequencies and MAY also support specification of this information by >channel identifiers. The Data Model MUST support a spectrum-availability >schedule and maximum power levels for each frequency range." > > >Thoughts? >Eric > > > >On 8/10/12 5:48 AM, Teco Boot wrote: > > > What about this: > > =B3The Data Model MUST support specifying a list of available >channels. The Data Model MUST support specification of this information >by start and stop frequencies, or equivalents such as center frequencies >with channel width or channel numbers with channel nummer allocation >scheme . The Data Model MUST support a channel availability schedule and >maximum power level for each channel in the list.=B2 > =20 > More thoughts on channel numbers: we likely run into problems in >bands without a channel numbering scheme, or for example sub channels in >TV bands. > > Teco > > > Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende geschreven: > > > > While I don't care if it's center and width or upper/lower, I do >think we will define the format in the protocol for interoperability >reasons, but don't need to do that in requirements. It wouldn't hurt to >decide now and use consistent terms, but we don't need to. > > I think "band" won't work, as it usually implies a much wider >piece of spectrum that has a common purpose. The TV Band is all the >channels. > > > On Aug 10, 2012, at 2:37 AM, Teco Boot wrote: > > > (somewhat late response) > > A center frequency and channel width is functional equivalent >to start/stop frequencies. So is channel number, with ref to channel >number assignment scheme. For a requirements document, we just need to >specify what is needed. How it is encoded (Hz, wave length, channel ID) >is solution space. > > Seen our goal to make PAWS somewhat universal (not limited to >US TVWS), I do not prefer using channel numbers. > > Teco > > > Op 9 aug. 2012, om 21:55 heeft > het volgende geschreven: > > > Folks, > =20 > During the last F2F meeting, there was an agreement to >make a slight update to requirement D.7 in >http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.txt, > to make channel numbers optional to be supported. Ie, change the current >D.7 > =B3The Data Model MUST support specifying a list of >available channels. The Data Model MUST support specification of this >information by channel numbers and by start and stop frequencies. The >Data Model MUST support a channel availability schedule and maximum power >level for each channel in the list.=B2 > to > =B3The Data Model MUST support specifying a list of >available channels. The Data Model MUST support specification of this >information by start and stop frequencies and MAY include channel >numbers. The Data Model MUST support a channel availability schedule and >maximum power level for each channel in the list.=B2 > =20 > I=B9d like to confirm this change on the list. If anyone >has any objections, let me know. Otherwise I=B9ll plan to send the documen= t >to the iesg after this change is implemented. > =20 > - Gabor > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > =20 > =20 > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > =20 > > > > > =20 > =20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > =20 > > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From jstine@mitre.org Mon Aug 13 10:26:22 2012 Return-Path: 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 6478D21F8527 for ; Mon, 13 Aug 2012 10:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwIrhMYioZMl for ; Mon, 13 Aug 2012 10:26:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1786321F8510 for ; Mon, 13 Aug 2012 10:26:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 51CD821B1AE6; Mon, 13 Aug 2012 13:26:20 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 41EB721B0857; Mon, 13 Aug 2012 13:26:20 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.151]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0309.002; Mon, 13 Aug 2012 13:26:20 -0400 From: "Stine, John A." To: Peter Stanforth , "Rosen, Brian" , Peter McCann Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac12Z+2NbbG4lfLAT8aeYHhnRNTamAAASkZwAA2NxwAAAHPuAAClPoeg Date: Mon, 13 Aug 2012 17:26:19 +0000 Message-ID: <2782C93FD2244441893673F3F9128192066839F3@IMCMBX01.MITRE.ORG> References: <5A02A514-1CA7-4AB8-8CA7-C9D1214D3F5C@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.59] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 17:26:22 -0000 Sorry I am a little late to this discussion. As Peter points out we are do= ing work that attempts to commoditize spectrum. This work is already in a = standards process through the IEEE DySPAN SC 1900.5 WG. The goal is to cre= ate a means to define the boundaries of spectrum use, all types of uses! T= he subsequent models enable management of coexistence among multiple databa= se administrators. I recognized early that the PAWS work would focus on meeting the minimum ne= eds of the regulatory administrations allowing sharing and would not be loo= king too far forward where WS DB administration will go. That is the reaso= n that in my previous inputs I have pushed for the separation of the busine= ss parts of the data model from the spectrum definition part of the data mo= del. The spectrum consumption models that are used in MBSM are only concern= ed with defining the boundaries of spectrum use. It does not cover matters= such as which database to use, how frequently the DB should be checked, ho= w to identify the user of the spectrum, and what certificates should be use= d for authorizations. This narrower focus allows the models to be used for = most sharing scenarios such as ad hoc sharing among government and commerci= al users. First, I recommend that you elevate the goal of separating the business mod= el and data model to a requirement. Second, I recommend that you make the= requirements for defining spectrum vague, and so "spectrum unit as require= d by the applicable regulatory administration" may be the best way to go. = Identifying spectrum as a channel or as a start and stop frequency are all = na=EFve. At some time in the future you will want to change this. You wil= l do yourself a big favor if you create a standard with that in mind. John -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Pet= er Stanforth Sent: Thursday, August 09, 2012 6:38 PM To: Rosen, Brian; Peter McCann Cc: paws@ietf.org Subject: Re: [paws] use cases and requirements document I suggest we take a look at the work MITRE has been doing on Model-Based Spectrum Management (MBSM). A lot of this is related to defining a spectrum commodity which is, I think, the basis of what we are trying to do here. http://www.mitre.org/work/tech_papers/2011/11_2071/ On the same text I have a question, Where it says "The Data Model MUST support a channel availability schedule and maximum power level for each channel in the list." What does this mean? The reason I ask is the FCC does not allow for variable power and some Regulators are suggesting channel allocation duration only be as long as the shortest available, negating the need for an availability map. Does the current wording allow for these two cases? Peter S. =20 On ThuAug/9/12 Thu Aug 9, 6:24 PM, "Rosen, Brian" wrote: > >I would like to suggest a more radical change > >I would like to define the term: spectrum unit as a unit of spectrum >defined by a low and high frequency and optionally a channel identifier. >Then I would like to use "spectrum unit" wherever the word "channel" >would occur throughout the document. In the definition, I would observe >that while it is common to have "channels" that are defined with some >identifier, the protocol does not depend on such an arrangement, but can >manage any swath of spectrum defined by an upper and lower frequency. > >I'm not attached to the specific term "spectrum unit" but I don't want to >use "channel" as that implies something that we are not limited by. > >Brian > >On Aug 9, 2012, at 3:57 PM, Peter McCann wrote: > >> I think "MAY include channel numbers" is somewhat ambiguous. I would >> prefer "MAY support specification of this information by channel >>number". >>=20 >> -Pete >>=20 >> Gabor.Bajko@nokia.com wrote: >>> Folks, >>>=20 >>>=20 >>>=20 >>> During the last F2F meeting, there was an agreement to make a slight >>> update to requirement D.7 in http://www.ietf.org/id/draft-ietf-paws- >>> problem-stmt-usecases-rqmts-06.txt >> paws-problem-stmt-usecases-rqmts-06.txt> , to make channel numbers >>> optional to be supported. Ie, change the current D.7 >>>=20 >>> "The Data Model MUST support specifying a list of available channels. >>> The Data Model MUST support specification of this information by >>> channel numbers and by start and stop frequencies. The Data Model MUST >>> support a channel availability schedule and maximum power level for >>> each channel in the list." >>>=20 >>> to >>>=20 >>> "The Data Model MUST support specifying a list of available channels. >>> The Data Model MUST support specification of this information by start >>> and stop frequencies and MAY include channel numbers. The Data Model >>> MUST support a channel availability schedule and maximum power level >>> for each channel in the list." >>>=20 >>>=20 >>>=20 >>> I'd like to confirm this change on the list. If anyone has any >>> objections, let me know. Otherwise I'll plan to send the document to >>> the iesg after this change is implemented. >>>=20 >>>=20 >>>=20 >>> - Gabor >>=20 >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Mon Aug 13 10:49:09 2012 Return-Path: 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 8F49021F8627 for ; Mon, 13 Aug 2012 10:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDLeWP1J8I4U for ; Mon, 13 Aug 2012 10:49:08 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4860E21F8605 for ; Mon, 13 Aug 2012 10:49:07 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7DHmrVA001379; Mon, 13 Aug 2012 20:48:54 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Aug 2012 20:49:54 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0283.004; Mon, 13 Aug 2012 19:48:52 +0200 From: To: , , , Thread-Topic: [paws] need for DB initialization message Thread-Index: Ac12he0A+5h4j+uqT6e4F6BpK7EzXwAAEnAAADHrtdAAENwZAAB0JGqAAABxXLj//7sdgA== Date: Mon, 13 Aug 2012 17:48:51 +0000 Message-ID: In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA690227B7@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.49] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Aug 2012 17:49:54.0571 (UTC) FILETIME=[0BDF6DB0:01CD797C] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 17:49:09 -0000 I think that LoST is a bit of an overkill for what is really needed in the context of PAWS for database discovery. The WSDB discovery server (as per draft-probasco-paws-discovery-01.txt) can provide the master device with information about the relevant WSDB (or list of DBs) to query as well as the regulatory domain that it is currently located in. -Raj=20 =20 On 8/13/12 9:55 AM, "ext Rosen, Brian" wrote: > >I prefer LoST for discovery. LoST can do recur/iterate like DNS, and it >can return more than one URI. That would allow the base LoST discovery >to find a server that returned the list. The initial LoST query returns >the list server, and a recur or iterate returns the list. > >Brian > > > > -----Original Message----- >From: Peter McCann [mailto:Peter.McCann@huawei.com] >Sent: Monday, August 13, 2012 10:47 AM Eastern Standard Time >To: Joel M. Halpern; Gabor.Bajko@nokia.com >Cc: paws@ietf.org >Subject: Re: [paws] need for DB initialization message > >Agree with Joel. > >I think a LOST-style service (a) is good for discovering a server >associated >with a regulatory domain. After that, you can query the regulator (b) to >find >approved databases. Then, you can choose one of those databases with >which >you have a relationship or that you know through some means will service >your request (c). The protocol for (b) and (c) could both be PAWS, if we >just add some sort of indirection to our specification. > >-Pete > > >Joel M. Halpern wrote: >> The master has to know its location in geographic coordinates (GPS, >> etc.) As far as I know, we have not assumed that the maps to translate >> that into political domains are known to the master a priori. >>=20 >> There are deployment scenarios (cell towers come to mind) where the >> master can probably be provisioned with the right administrative >> information. There are other scenarios where that is not obviously >> achievable. >>=20 >> Yours, >> Joel >>=20 >> On 8/10/2012 7:33 PM, Gabor.Bajko@nokia.com wrote: >>> While I agree that re-direction from an intermediary to the final >> recipient should not be disallowed, I don't think the use case you are >> describing is a valid one. The master needs to know its location >> before engaging into DB discovery. If it doesn't, then it can use some >> existing mechanism to find it out (eg, RFC5985) prior to the DB >> discovery process, but that for me is a separate transaction. >>>=20 >>> The current DB discovery mechanism described in >> http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt assumes >> that the master knows its location before performing DB discovery; >> after which it needs to do a regulatory domain discovery as well. >> Brian suggested regulatory domain could be a parameter of the DB URI, >> thus no need for separate regulatory domain discovery. Any other >>suggestions? >>>=20 >>> - Gabor >>>=20 >>> -----Original Message----- >>> From: ext Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Thursday, August 09, 2012 6:25 PM >>> To: Bajko Gabor (Nokia-CIC/SiliconValley) >>> Cc: paws@ietf.org >>> Subject: Re: [paws] need for DB initialization message >>>=20 >>> Related suggestion: Assuming we have a discovery protocol which can >>> return a URI, the protocol semantics should be such that the URI can >>> be the final DB URI, or another intermediary in the process. Thus, >>> the protocol should not lock in that there can be only 0 or 1 >>> intermediaries in the resolution, but should allow several. (We >>> already have suggested cases where at least two are needed, one to >>> determine where you are by asking your vendor, and one to determine >>> who you can talk to by asking your local regulator.) >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 8/9/2012 8:02 PM, Gabor.Bajko@nokia.com wrote: >>>> Folks, >>>>=20 >>>> During the Vancouver F2F discussions we had some good discussions, >>>> but no agreement on wether an initialization message, as proposed >>>> in draft-das is necessary or not. >>>>=20 >>>> You may check the minutes to see what was said at the mike: >>>> http://www.ietf.org/proceedings/84/minutes/minutes-84-paws >>>>=20 >>>> People spoke mostly in favor, but there were people who also said >>>> that this message is redundant with registration message. >>>>=20 >>>> Question#1: need for an initialization message >>>>=20 >>>> Unfortunately we did not have time to discuss the DB discovery aspect, >>>> and that may be related to this topic. The only DB discovery document >>>> available currently, >>>> http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, proposes, >>>> that the master device contacts a pre-provisioned discovery server and >>>> provides its location, and in return the discovery server returns the >>>> URI of the DB for that regulatory domain. At this point, the master >>>> device knows which DB to contact, but it does not necessarily know >>>> what regulatory domain that DB belongs to. Thus, it doesn't know what >>>> are the operating rules, whether it has to authenticate, or register, >>>> etc. >>>>=20 >>>> Thus, it seems logical to me that the master device first queries the >>>> DB to find out the regulatory domain. We even have such a requirement >>>> in the requirement draft, requirement: >>>>=20 >>>> "P.3: The protocol MUST support determination of >>>> regulatory domain governing its current location." >>>>=20 >>>> The information about the regulatory domain may be cached, and the >>>> master device may not need to place that query every time, but this >>>> message exchange may be necessary in certain cases. Any comments to >>>> this point? >>>>=20 >>>> Question#2 >>>>=20 >>>> Then, it is a slightly separate issue, if this message exchange has >>>> to take place, then what additional information the DB returns. >>>> draft-das proposes that regulatory domain specific information be >>>> returned to the master device. >>>>=20 >>>> Question#3 >>>>=20 >>>> Yet another separate point is that draft-das proposes to use this >>>> initialization message also to initiate client authentication (putting >>>> shared secret vs cert issue aside for the time being). In cases when >>>> the master device does not know the regulatory domain it is in, then >>>> it does not know whether authentication is required in that regulatory >>>> domain or not; so why would initiate authentication then? Similar >>>> comment applies to draft-wei, where it is proposed that after DB >>>> discovery the master device authenticates at TLS layer and performs >>>> registration; how does it know that it has to authenticate and >>>> register, if it doesn't know the regulatory domain? >>>>=20 >>>> In my opinion (chair hat off), the sequence of events should be sg >>>> like >>>> this: >>>>=20 >>>> 1.DB discovery (may be skipped if cached information available) >>>>=20 >>>> 2.Regulatory domain query (may be skipped if cached information >>>> available) >>>>=20 >>>> 3.Authentication (if required) >>>>=20 >>>> 4.Registration (if required) >>>>=20 >>>> 5.Channel availability query (may be combined with registration?) >>>>=20 >>>> Comments are welcome and expected. >>>>=20 >>>> -Gabor >>>>=20 > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Mon Aug 13 10:58:48 2012 Return-Path: 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 8879C21F8722 for ; Mon, 13 Aug 2012 10:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.13 X-Spam-Level: X-Spam-Status: No, score=-6.13 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH44btWIDqvX for ; Mon, 13 Aug 2012 10:58:47 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7D321F8717 for ; Mon, 13 Aug 2012 10:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1344880828; x=1660236644; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=KfGkyaHnZ/aacHj8UdK/H tI9oHIOqN+sinnmoAL+c/o=; b=CSKrq/BwBnx0ubbGXh6dhUFu+PnMbVakJ6nQ7 8ldIYE9n/PEqmdEoXHl+dDWi3DQic+6iho34Q3tF4LaQqyqTw== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.12588253; Mon, 13 Aug 2012 14:00:27 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 13 Aug 2012 13:58:30 -0400 From: "Rosen, Brian" Date: Mon, 13 Aug 2012 13:58:30 -0400 Thread-Topic: [paws] need for DB initialization message Thread-Index: Ac12he0A+5h4j+uqT6e4F6BpK7EzXwAAEnAAADHrtdAAENwZAAB0JGqAAABxXLj//7sdgP//h/i+ Message-ID: <55A5A9A87506CB4BA580BF9D531957DA690227B8@STNTEXCH01.cis.neustar.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: coh4EqUIIzrDAVZAckIxrw== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 To: "'basavaraj.patil@nokia.com'" , "'peter.mccann@huawei.com'" , "'jmh@joelhalpern.com'" , "'gabor.bajko@nokia.com'" Cc: "'paws@ietf.org'" Subject: Re: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 17:58:48 -0000 aW4gd2hhdCB3YXkgaXMgaXQgb3ZlcmtpbGw/ICBZb3UgcGFzcyBhIGxvY2F0aW9uIGFuZCBhIHNo b3J0IFVSTiBpbiwgdXNpbmcgYSBzaW1wbGUgSFRUUCBleGNoYW5nZSwgYW5kIHlvdSBnZXQgYSAo c2V0IG9mKSBVUklzIG91dC4gIFRoZSBleHRyYSBzdHVmZiBpdCBkb2VzIChsaWtlIHJlY3VyL2l0 ZXJhdGUpIGlzIHVzZWZ1bC4gIEFib3V0IHRoZSBvbmx5IGZlYXR1cmUgd2UgZG9uJ3QgbmVlZCBp cyB2YWxpZGF0ZSwgd2hpY2ggaXMgdHJpdmlhbCB0byBub3Qgc3VwcG9ydCAoc2luY2UgaXQncyBv cHRpb25hbCkuICAKClBsZWFzZSBjaXRlIGEgc3BlY2lmaWMgYXNwZWN0IG9mIExvU1Qgd2hpY2gg aXMgb3ZlcmtpbGwgZm9yIHVzLgoKQnJpYW4gPGFzIGluZGl2aWR1YWw+CgoNCg0KIC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAJQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbSBbbWFp bHRvOkJhc2F2YXJhai5QYXRpbEBub2tpYS5jb21dDQpTZW50OglNb25kYXksIEF1Z3VzdCAxMywg MjAxMiAwMTo0OSBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNClRvOglSb3NlbiwgQnJpYW47IHBl dGVyLm1jY2FubkBodWF3ZWkuY29tOyBqbWhAam9lbGhhbHBlcm4uY29tOyBHYWJvci5CYWprb0Bu b2tpYS5jb20NCkNjOglwYXdzQGlldGYub3JnDQpTdWJqZWN0OglSZTogW3Bhd3NdIG5lZWQgZm9y IERCIGluaXRpYWxpemF0aW9uIG1lc3NhZ2UNCg0KDQpJIHRoaW5rIHRoYXQgTG9TVCBpcyBhIGJp dCBvZiBhbiBvdmVya2lsbCBmb3Igd2hhdCBpcyByZWFsbHkgbmVlZGVkIGluIHRoZQ0KY29udGV4 dCBvZiBQQVdTIGZvciBkYXRhYmFzZSBkaXNjb3ZlcnkuDQpUaGUgV1NEQiBkaXNjb3Zlcnkgc2Vy dmVyIChhcyBwZXIgZHJhZnQtcHJvYmFzY28tcGF3cy1kaXNjb3ZlcnktMDEudHh0KQ0KY2FuIHBy b3ZpZGUgdGhlIG1hc3RlciBkZXZpY2Ugd2l0aCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgcmVsZXZh bnQgV1NEQiAob3INCmxpc3Qgb2YgREJzKSB0byBxdWVyeSBhcyB3ZWxsIGFzIHRoZSByZWd1bGF0 b3J5IGRvbWFpbiB0aGF0IGl0IGlzDQpjdXJyZW50bHkgbG9jYXRlZCBpbi4NCg0KLVJhaiANCiAN Cg0KDQpPbiA4LzEzLzEyIDk6NTUgQU0sICJleHQgUm9zZW4sIEJyaWFuIiA8QnJpYW4uUm9zZW5A bmV1c3Rhci5iaXo+IHdyb3RlOg0KDQo+PGFzIGluZGl2aWR1YWw+DQo+SSBwcmVmZXIgTG9TVCBm b3IgZGlzY292ZXJ5LiAgTG9TVCBjYW4gZG8gcmVjdXIvaXRlcmF0ZSBsaWtlIEROUywgYW5kIGl0 DQo+Y2FuIHJldHVybiBtb3JlIHRoYW4gb25lIFVSSS4gIFRoYXQgd291bGQgYWxsb3cgdGhlIGJh c2UgTG9TVCBkaXNjb3ZlcnkNCj50byBmaW5kIGEgc2VydmVyIHRoYXQgcmV0dXJuZWQgdGhlIGxp c3QuICBUaGUgaW5pdGlhbCBMb1NUIHF1ZXJ5IHJldHVybnMNCj50aGUgbGlzdCBzZXJ2ZXIsIGFu ZCBhIHJlY3VyIG9yIGl0ZXJhdGUgcmV0dXJucyB0aGUgbGlzdC4NCj4NCj5Ccmlhbg0KPg0KPg0K Pg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IAlQZXRlciBNY0Nhbm4gW21h aWx0bzpQZXRlci5NY0Nhbm5AaHVhd2VpLmNvbV0NCj5TZW50OglNb25kYXksIEF1Z3VzdCAxMywg MjAxMiAxMDo0NyBBTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNCj5UbzoJSm9lbCBNLiBIYWxwZXJu OyBHYWJvci5CYWprb0Bub2tpYS5jb20NCj5DYzoJcGF3c0BpZXRmLm9yZw0KPlN1YmplY3Q6CVJl OiBbcGF3c10gbmVlZCBmb3IgREIgaW5pdGlhbGl6YXRpb24gbWVzc2FnZQ0KPg0KPkFncmVlIHdp dGggSm9lbC4NCj4NCj5JIHRoaW5rIGEgTE9TVC1zdHlsZSBzZXJ2aWNlIChhKSBpcyBnb29kIGZv ciBkaXNjb3ZlcmluZyBhIHNlcnZlcg0KPmFzc29jaWF0ZWQNCj53aXRoIGEgcmVndWxhdG9yeSBk b21haW4uICBBZnRlciB0aGF0LCB5b3UgY2FuIHF1ZXJ5IHRoZSByZWd1bGF0b3IgKGIpIHRvDQo+ ZmluZA0KPmFwcHJvdmVkIGRhdGFiYXNlcy4gIFRoZW4sIHlvdSBjYW4gY2hvb3NlIG9uZSBvZiB0 aG9zZSBkYXRhYmFzZXMgd2l0aA0KPndoaWNoDQo+eW91IGhhdmUgYSByZWxhdGlvbnNoaXAgb3Ig dGhhdCB5b3Uga25vdyB0aHJvdWdoIHNvbWUgbWVhbnMgd2lsbCBzZXJ2aWNlDQo+eW91ciByZXF1 ZXN0IChjKS4gIFRoZSBwcm90b2NvbCBmb3IgKGIpIGFuZCAoYykgY291bGQgYm90aCBiZSBQQVdT LCBpZiB3ZQ0KPmp1c3QgYWRkIHNvbWUgc29ydCBvZiBpbmRpcmVjdGlvbiB0byBvdXIgc3BlY2lm aWNhdGlvbi4NCj4NCj4tUGV0ZQ0KPg0KPg0KPkpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4+IFRo ZSBtYXN0ZXIgaGFzIHRvIGtub3cgaXRzIGxvY2F0aW9uIGluIGdlb2dyYXBoaWMgY29vcmRpbmF0 ZXMgKEdQUywNCj4+IGV0Yy4pICAgQXMgZmFyIGFzIEkga25vdywgd2UgaGF2ZSBub3QgYXNzdW1l ZCB0aGF0IHRoZSBtYXBzIHRvIHRyYW5zbGF0ZQ0KPj4gdGhhdCBpbnRvIHBvbGl0aWNhbCBkb21h aW5zIGFyZSBrbm93biB0byB0aGUgbWFzdGVyIGEgcHJpb3JpLg0KPj4gDQo+PiBUaGVyZSBhcmUg ZGVwbG95bWVudCBzY2VuYXJpb3MgKGNlbGwgdG93ZXJzIGNvbWUgdG8gbWluZCkgd2hlcmUgdGhl DQo+PiBtYXN0ZXIgY2FuIHByb2JhYmx5IGJlIHByb3Zpc2lvbmVkIHdpdGggdGhlIHJpZ2h0IGFk bWluaXN0cmF0aXZlDQo+PiBpbmZvcm1hdGlvbi4gIFRoZXJlIGFyZSBvdGhlciBzY2VuYXJpb3Mg d2hlcmUgdGhhdCBpcyBub3Qgb2J2aW91c2x5DQo+PiBhY2hpZXZhYmxlLg0KPj4gDQo+PiBZb3Vy cywNCj4+IEpvZWwNCj4+IA0KPj4gT24gOC8xMC8yMDEyIDc6MzMgUE0sIEdhYm9yLkJhamtvQG5v a2lhLmNvbSB3cm90ZToNCj4+PiBXaGlsZSBJIGFncmVlIHRoYXQgcmUtZGlyZWN0aW9uIGZyb20g YW4gaW50ZXJtZWRpYXJ5IHRvIHRoZSBmaW5hbA0KPj4gcmVjaXBpZW50IHNob3VsZCBub3QgYmUg ZGlzYWxsb3dlZCwgSSBkb24ndCB0aGluayB0aGUgdXNlIGNhc2UgeW91IGFyZQ0KPj4gZGVzY3Jp YmluZyBpcyBhIHZhbGlkIG9uZS4gVGhlIG1hc3RlciBuZWVkcyB0byBrbm93IGl0cyBsb2NhdGlv bg0KPj4gYmVmb3JlIGVuZ2FnaW5nIGludG8gREIgZGlzY292ZXJ5LiBJZiBpdCBkb2Vzbid0LCB0 aGVuIGl0IGNhbiB1c2Ugc29tZQ0KPj4gZXhpc3RpbmcgbWVjaGFuaXNtIHRvIGZpbmQgaXQgb3V0 IChlZywgUkZDNTk4NSkgcHJpb3IgdG8gdGhlIERCDQo+PiBkaXNjb3ZlcnkgcHJvY2VzcywgYnV0 IHRoYXQgZm9yIG1lIGlzIGEgc2VwYXJhdGUgdHJhbnNhY3Rpb24uDQo+Pj4gDQo+Pj4gVGhlIGN1 cnJlbnQgREIgZGlzY292ZXJ5IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4NCj4+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvaWQvZHJhZnQtcHJvYmFzY28tcGF3cy1kaXNjb3ZlcnktMDEudHh0IGFzc3VtZXMN Cj4+IHRoYXQgdGhlIG1hc3RlciBrbm93cyBpdHMgbG9jYXRpb24gYmVmb3JlIHBlcmZvcm1pbmcg REIgZGlzY292ZXJ5Ow0KPj4gYWZ0ZXIgd2hpY2ggaXQgbmVlZHMgdG8gZG8gYSByZWd1bGF0b3J5 IGRvbWFpbiBkaXNjb3ZlcnkgYXMgd2VsbC4NCj4+IEJyaWFuIHN1Z2dlc3RlZCByZWd1bGF0b3J5 IGRvbWFpbiBjb3VsZCBiZSBhIHBhcmFtZXRlciBvZiB0aGUgREIgVVJJLA0KPj4gdGh1cyBubyBu ZWVkIGZvciBzZXBhcmF0ZSByZWd1bGF0b3J5IGRvbWFpbiBkaXNjb3ZlcnkuIEFueSBvdGhlcg0K Pj5zdWdnZXN0aW9ucz8NCj4+PiANCj4+PiAtIEdhYm9yDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBleHQgSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbV0NCj4+PiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDA5LCAyMDEyIDY6 MjUgUE0NCj4+PiBUbzogQmFqa28gR2Fib3IgKE5va2lhLUNJQy9TaWxpY29uVmFsbGV5KQ0KPj4+ IENjOiBwYXdzQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtwYXdzXSBuZWVkIGZvciBEQiBp bml0aWFsaXphdGlvbiBtZXNzYWdlDQo+Pj4gDQo+Pj4gUmVsYXRlZCBzdWdnZXN0aW9uOiAgQXNz dW1pbmcgd2UgaGF2ZSBhIGRpc2NvdmVyeSBwcm90b2NvbCB3aGljaCBjYW4NCj4+PiByZXR1cm4g YSBVUkksIHRoZSBwcm90b2NvbCBzZW1hbnRpY3Mgc2hvdWxkIGJlIHN1Y2ggdGhhdCB0aGUgVVJJ IGNhbg0KPj4+IGJlIHRoZSBmaW5hbCBEQiBVUkksIG9yIGFub3RoZXIgaW50ZXJtZWRpYXJ5IGlu IHRoZSBwcm9jZXNzLiAgVGh1cywNCj4+PiB0aGUgcHJvdG9jb2wgc2hvdWxkIG5vdCBsb2NrIGlu IHRoYXQgdGhlcmUgY2FuIGJlIG9ubHkgMCBvciAxDQo+Pj4gaW50ZXJtZWRpYXJpZXMgaW4gdGhl IHJlc29sdXRpb24sIGJ1dCBzaG91bGQgYWxsb3cgc2V2ZXJhbC4gIChXZQ0KPj4+IGFscmVhZHkg aGF2ZSBzdWdnZXN0ZWQgY2FzZXMgd2hlcmUgYXQgbGVhc3QgdHdvIGFyZSBuZWVkZWQsIG9uZSB0 bw0KPj4+IGRldGVybWluZSB3aGVyZSB5b3UgYXJlIGJ5IGFza2luZyB5b3VyIHZlbmRvciwgYW5k IG9uZSB0byBkZXRlcm1pbmUNCj4+PiB3aG8geW91IGNhbiB0YWxrIHRvIGJ5IGFza2luZyB5b3Vy IGxvY2FsIHJlZ3VsYXRvci4pDQo+Pj4gDQo+Pj4gWW91cnMsDQo+Pj4gSm9lbA0KPj4+IA0KPj4+ IE9uIDgvOS8yMDEyIDg6MDIgUE0sIEdhYm9yLkJhamtvQG5va2lhLmNvbSB3cm90ZToNCj4+Pj4g Rm9sa3MsDQo+Pj4+IA0KPj4+PiBEdXJpbmcgdGhlIFZhbmNvdXZlciBGMkYgZGlzY3Vzc2lvbnMg d2UgaGFkIHNvbWUgZ29vZCBkaXNjdXNzaW9ucywNCj4+Pj4gYnV0IG5vIGFncmVlbWVudCBvbiB3 ZXRoZXIgYW4gaW5pdGlhbGl6YXRpb24gbWVzc2FnZSwgYXMgcHJvcG9zZWQNCj4+Pj4gaW4gZHJh ZnQtZGFzIGlzIG5lY2Vzc2FyeSBvciBub3QuDQo+Pj4+IA0KPj4+PiBZb3UgbWF5IGNoZWNrIHRo ZSBtaW51dGVzIHRvIHNlZSB3aGF0IHdhcyBzYWlkIGF0IHRoZSBtaWtlOg0KPj4+PiBodHRwOi8v d3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg0L21pbnV0ZXMvbWludXRlcy04NC1wYXdzDQo+Pj4+ IA0KPj4+PiBQZW9wbGUgc3Bva2UgbW9zdGx5IGluIGZhdm9yLCBidXQgdGhlcmUgd2VyZSBwZW9w bGUgd2hvIGFsc28gc2FpZA0KPj4+PiB0aGF0IHRoaXMgbWVzc2FnZSBpcyByZWR1bmRhbnQgd2l0 aCByZWdpc3RyYXRpb24gbWVzc2FnZS4NCj4+Pj4gDQo+Pj4+IFF1ZXN0aW9uIzE6IG5lZWQgZm9y IGFuIGluaXRpYWxpemF0aW9uIG1lc3NhZ2UNCj4+Pj4gDQo+Pj4+IFVuZm9ydHVuYXRlbHkgd2Ug ZGlkIG5vdCBoYXZlIHRpbWUgdG8gZGlzY3VzcyB0aGUgREIgZGlzY292ZXJ5IGFzcGVjdCwNCj4+ Pj4gYW5kIHRoYXQgbWF5IGJlIHJlbGF0ZWQgdG8gdGhpcyB0b3BpYy4gVGhlIG9ubHkgREIgZGlz Y292ZXJ5IGRvY3VtZW50DQo+Pj4+IGF2YWlsYWJsZSBjdXJyZW50bHksDQo+Pj4+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcHJvYmFzY28tcGF3cy1kaXNjb3ZlcnktMDEudHh0LCBwcm9w b3NlcywNCj4+Pj4gdGhhdCB0aGUgbWFzdGVyIGRldmljZSBjb250YWN0cyBhIHByZS1wcm92aXNp b25lZCBkaXNjb3Zlcnkgc2VydmVyIGFuZA0KPj4+PiBwcm92aWRlcyBpdHMgbG9jYXRpb24sIGFu ZCBpbiByZXR1cm4gdGhlIGRpc2NvdmVyeSBzZXJ2ZXIgcmV0dXJucyB0aGUNCj4+Pj4gVVJJIG9m IHRoZSBEQiBmb3IgdGhhdCByZWd1bGF0b3J5IGRvbWFpbi4gQXQgdGhpcyBwb2ludCwgdGhlIG1h c3Rlcg0KPj4+PiBkZXZpY2Uga25vd3Mgd2hpY2ggREIgdG8gY29udGFjdCwgYnV0IGl0IGRvZXMg bm90IG5lY2Vzc2FyaWx5IGtub3cNCj4+Pj4gd2hhdCByZWd1bGF0b3J5IGRvbWFpbiB0aGF0IERC IGJlbG9uZ3MgdG8uIFRodXMsIGl0IGRvZXNuJ3Qga25vdyB3aGF0DQo+Pj4+IGFyZSB0aGUgb3Bl cmF0aW5nIHJ1bGVzLCB3aGV0aGVyIGl0IGhhcyB0byBhdXRoZW50aWNhdGUsIG9yIHJlZ2lzdGVy LA0KPj4+PiBldGMuDQo+Pj4+IA0KPj4+PiBUaHVzLCBpdCBzZWVtcyBsb2dpY2FsIHRvIG1lIHRo YXQgdGhlIG1hc3RlciBkZXZpY2UgZmlyc3QgcXVlcmllcyB0aGUNCj4+Pj4gREIgdG8gZmluZCBv dXQgdGhlIHJlZ3VsYXRvcnkgZG9tYWluLiBXZSBldmVuIGhhdmUgc3VjaCBhIHJlcXVpcmVtZW50 DQo+Pj4+IGluIHRoZSByZXF1aXJlbWVudCBkcmFmdCwgcmVxdWlyZW1lbnQ6DQo+Pj4+IA0KPj4+ PiAiUC4zOiAgIFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgZGV0ZXJtaW5hdGlvbiBvZg0KPj4+ PiByZWd1bGF0b3J5ICAgICAgICAgICAgIGRvbWFpbiBnb3Zlcm5pbmcgaXRzIGN1cnJlbnQgbG9j YXRpb24uIg0KPj4+PiANCj4+Pj4gVGhlIGluZm9ybWF0aW9uIGFib3V0IHRoZSByZWd1bGF0b3J5 IGRvbWFpbiBtYXkgYmUgY2FjaGVkLCBhbmQgdGhlDQo+Pj4+IG1hc3RlciBkZXZpY2UgbWF5IG5v dCBuZWVkIHRvIHBsYWNlIHRoYXQgcXVlcnkgZXZlcnkgdGltZSwgYnV0IHRoaXMNCj4+Pj4gbWVz c2FnZSBleGNoYW5nZSBtYXkgYmUgbmVjZXNzYXJ5IGluIGNlcnRhaW4gY2FzZXMuIEFueSBjb21t ZW50cyB0bw0KPj4+PiB0aGlzIHBvaW50Pw0KPj4+PiANCj4+Pj4gUXVlc3Rpb24jMg0KPj4+PiAN Cj4+Pj4gVGhlbiwgaXQgaXMgYSBzbGlnaHRseSBzZXBhcmF0ZSBpc3N1ZSwgaWYgdGhpcyBtZXNz YWdlIGV4Y2hhbmdlIGhhcw0KPj4+PiB0byB0YWtlIHBsYWNlLCB0aGVuIHdoYXQgYWRkaXRpb25h bCBpbmZvcm1hdGlvbiB0aGUgREIgcmV0dXJucy4NCj4+Pj4gZHJhZnQtZGFzIHByb3Bvc2VzIHRo YXQgcmVndWxhdG9yeSBkb21haW4gc3BlY2lmaWMgaW5mb3JtYXRpb24gYmUNCj4+Pj4gcmV0dXJu ZWQgdG8gdGhlIG1hc3RlciBkZXZpY2UuDQo+Pj4+IA0KPj4+PiBRdWVzdGlvbiMzDQo+Pj4+IA0K Pj4+PiBZZXQgYW5vdGhlciBzZXBhcmF0ZSBwb2ludCBpcyB0aGF0IGRyYWZ0LWRhcyBwcm9wb3Nl cyB0byB1c2UgdGhpcw0KPj4+PiBpbml0aWFsaXphdGlvbiBtZXNzYWdlIGFsc28gdG8gaW5pdGlh dGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIChwdXR0aW5nDQo+Pj4+IHNoYXJlZCBzZWNyZXQgdnMg Y2VydCBpc3N1ZSBhc2lkZSBmb3IgdGhlIHRpbWUgYmVpbmcpLiBJbiBjYXNlcyB3aGVuDQo+Pj4+ IHRoZSBtYXN0ZXIgZGV2aWNlIGRvZXMgbm90IGtub3cgdGhlIHJlZ3VsYXRvcnkgZG9tYWluIGl0 IGlzIGluLCB0aGVuDQo+Pj4+IGl0IGRvZXMgbm90IGtub3cgd2hldGhlciBhdXRoZW50aWNhdGlv biBpcyByZXF1aXJlZCBpbiB0aGF0IHJlZ3VsYXRvcnkNCj4+Pj4gZG9tYWluIG9yIG5vdDsgc28g d2h5IHdvdWxkIGluaXRpYXRlIGF1dGhlbnRpY2F0aW9uIHRoZW4/IFNpbWlsYXINCj4+Pj4gY29t bWVudCBhcHBsaWVzIHRvIGRyYWZ0LXdlaSwgd2hlcmUgaXQgaXMgcHJvcG9zZWQgdGhhdCBhZnRl ciBEQg0KPj4+PiBkaXNjb3ZlcnkgdGhlIG1hc3RlciBkZXZpY2UgYXV0aGVudGljYXRlcyBhdCBU TFMgbGF5ZXIgYW5kIHBlcmZvcm1zDQo+Pj4+IHJlZ2lzdHJhdGlvbjsgaG93IGRvZXMgaXQga25v dyB0aGF0IGl0IGhhcyB0byBhdXRoZW50aWNhdGUgYW5kDQo+Pj4+IHJlZ2lzdGVyLCBpZiBpdCBk b2Vzbid0IGtub3cgdGhlIHJlZ3VsYXRvcnkgZG9tYWluPw0KPj4+PiANCj4+Pj4gSW4gbXkgb3Bp bmlvbiAoY2hhaXIgaGF0IG9mZiksIHRoZSBzZXF1ZW5jZSBvZiBldmVudHMgc2hvdWxkIGJlIHNn DQo+Pj4+IGxpa2UNCj4+Pj4gdGhpczoNCj4+Pj4gDQo+Pj4+IDEuREIgZGlzY292ZXJ5IChtYXkg YmUgc2tpcHBlZCBpZiBjYWNoZWQgaW5mb3JtYXRpb24gYXZhaWxhYmxlKQ0KPj4+PiANCj4+Pj4g Mi5SZWd1bGF0b3J5IGRvbWFpbiBxdWVyeSAobWF5IGJlIHNraXBwZWQgaWYgY2FjaGVkIGluZm9y bWF0aW9uDQo+Pj4+IGF2YWlsYWJsZSkNCj4+Pj4gDQo+Pj4+IDMuQXV0aGVudGljYXRpb24gKGlm IHJlcXVpcmVkKQ0KPj4+PiANCj4+Pj4gNC5SZWdpc3RyYXRpb24gKGlmIHJlcXVpcmVkKQ0KPj4+ PiANCj4+Pj4gNS5DaGFubmVsIGF2YWlsYWJpbGl0eSBxdWVyeSAobWF5IGJlIGNvbWJpbmVkIHdp dGggcmVnaXN0cmF0aW9uPykNCj4+Pj4gDQo+Pj4+IENvbW1lbnRzIGFyZSB3ZWxjb21lIGFuZCBl eHBlY3RlZC4NCj4+Pj4gDQo+Pj4+IC1HYWJvcg0KPj4+PiANCj4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnBhd3MgbWFpbGluZyBsaXN0DQo+cGF3 c0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0K Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+cGF3cyBt YWlsaW5nIGxpc3QNCj5wYXdzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wYXdzDQoNCg== From Gabor.Bajko@nokia.com Mon Aug 13 11:46:08 2012 Return-Path: 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 41A0021F862A for ; Mon, 13 Aug 2012 11:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSjdx39gDXdQ for ; Mon, 13 Aug 2012 11:46:07 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEE021F8628 for ; Mon, 13 Aug 2012 11:46:06 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7DIjvW1009423; Mon, 13 Aug 2012 21:45:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Aug 2012 21:46:59 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.02.0283.004; Mon, 13 Aug 2012 20:45:56 +0200 From: To: , , , Thread-Topic: DB discovery [was: RE: [paws] need for DB initialization message] Thread-Index: Ac15gqFNItaZd90nQoOT2JXoMeeCoQ== Date: Mon, 13 Aug 2012 18:45:55 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB100C@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 13 Aug 2012 18:46:59.0314 (UTC) FILETIME=[052DBD20:01CD7984] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: [paws] DB discovery [was: RE: need for DB initialization message] X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 18:46:08 -0000 SSBjb3VsZCBhbHNvIHNlZSBhIGZldyB0aGluZ3Mgd2h5IExvU1QgbWlnaHQgbm90IGJlIHRoZSBi ZXN0IGZpdCBmb3IgV1NEQiBkaXNjb3Zlcnk6DQoNCkxvU1QgZG9lcyBub3Qgc3BlY2lmeSBMb1NU IHNlcnZlciBkaXNjb3ZlcnkuIFRoZXJlIGlzIGEgc2VwYXJhdGUgUkZDIG9uIGRpc2NvdmVyaW5n IExvU1QgdXNpbmcgREhDUCwgYnV0IHRoYXQncyBub3QgZGVwbG95bWVudCBmcmllbmRseS4gU28g YSBkaXNjb3ZlcnkgbWVjaGFuaXNtLCBlZyB0aGUgb25lIGRlc2NyaWJlZCBpbiBSYWoncyBkb2N1 bWVudCwgaXMgbmVlZGVkIGFueXdheS4NCg0KTG9TVCByZWxpZXMgb24gVS1OQVBUUiwgYW5kIHdl IGFsbCBrbm93IGhvdyBkaWZmaWN1bHQgaXMgdG8gZ2V0IEROUyBhZG1pbnMgYWRkIG5ldyByZWNv cmRzIHRvIHRoZWlyIHpvbmVzLg0KDQpUaGUgV0cgc2VlbXMgdG8gcHJlZmVyIEpTT04gZW5jb2Rp bmcgdG8gWE1MLCB0byBiZSBhYmxlIHRvIHN1cHBvcnQgbGlnaHR3ZWlnaHQgZGV2aWNlcywgTG9T VCB1c2VzIFhNTC4NCg0KVGhlcmUgaXMgYSBsb3Qgb2Ygc3R1ZmYgaW4gTG9TVCwgd2Ugd291bGQg bmVlZCBhIHZlcnkgc21hbGwgc3Vic2V0IG9mIGl0Lg0KDQotIEdhYm9yDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBleHQgUm9zZW4sIEJyaWFuIFttYWlsdG86QnJpYW4uUm9z ZW5AbmV1c3Rhci5iaXpdIA0KU2VudDogTW9uZGF5LCBBdWd1c3QgMTMsIDIwMTIgMTA6NTkgQU0N ClRvOiBQYXRpbCBCYXNhdmFyYWogKE5va2lhLUNJQy9EYWxsYXMpOyAncGV0ZXIubWNjYW5uQGh1 YXdlaS5jb20nOyAnam1oQGpvZWxoYWxwZXJuLmNvbSc7IEJhamtvIEdhYm9yIChOb2tpYS1DSUMv U2lsaWNvblZhbGxleSkNCkNjOiAncGF3c0BpZXRmLm9yZycNClN1YmplY3Q6IFJFOiBbcGF3c10g bmVlZCBmb3IgREIgaW5pdGlhbGl6YXRpb24gbWVzc2FnZQ0KDQppbiB3aGF0IHdheSBpcyBpdCBv dmVya2lsbD8gIFlvdSBwYXNzIGEgbG9jYXRpb24gYW5kIGEgc2hvcnQgVVJOIGluLCB1c2luZyBh IHNpbXBsZSBIVFRQIGV4Y2hhbmdlLCBhbmQgeW91IGdldCBhIChzZXQgb2YpIFVSSXMgb3V0LiAg VGhlIGV4dHJhIHN0dWZmIGl0IGRvZXMgKGxpa2UgcmVjdXIvaXRlcmF0ZSkgaXMgdXNlZnVsLiAg QWJvdXQgdGhlIG9ubHkgZmVhdHVyZSB3ZSBkb24ndCBuZWVkIGlzIHZhbGlkYXRlLCB3aGljaCBp cyB0cml2aWFsIHRvIG5vdCBzdXBwb3J0IChzaW5jZSBpdCdzIG9wdGlvbmFsKS4gIA0KDQpQbGVh c2UgY2l0ZSBhIHNwZWNpZmljIGFzcGVjdCBvZiBMb1NUIHdoaWNoIGlzIG92ZXJraWxsIGZvciB1 cy4NCg0KQnJpYW4gPGFzIGluZGl2aWR1YWw+DQoNCg0KDQogLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IAlCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tIFttYWlsdG86QmFzYXZhcmFq LlBhdGlsQG5va2lhLmNvbV0NClNlbnQ6CU1vbmRheSwgQXVndXN0IDEzLCAyMDEyIDAxOjQ5IFBN IEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86CVJvc2VuLCBCcmlhbjsgcGV0ZXIubWNjYW5uQGh1 YXdlaS5jb207IGptaEBqb2VsaGFscGVybi5jb207IEdhYm9yLkJhamtvQG5va2lhLmNvbQ0KQ2M6 CXBhd3NAaWV0Zi5vcmcNClN1YmplY3Q6CVJlOiBbcGF3c10gbmVlZCBmb3IgREIgaW5pdGlhbGl6 YXRpb24gbWVzc2FnZQ0KDQoNCkkgdGhpbmsgdGhhdCBMb1NUIGlzIGEgYml0IG9mIGFuIG92ZXJr aWxsIGZvciB3aGF0IGlzIHJlYWxseSBuZWVkZWQgaW4gdGhlIGNvbnRleHQgb2YgUEFXUyBmb3Ig ZGF0YWJhc2UgZGlzY292ZXJ5Lg0KVGhlIFdTREIgZGlzY292ZXJ5IHNlcnZlciAoYXMgcGVyIGRy YWZ0LXByb2Jhc2NvLXBhd3MtZGlzY292ZXJ5LTAxLnR4dCkNCmNhbiBwcm92aWRlIHRoZSBtYXN0 ZXIgZGV2aWNlIHdpdGggaW5mb3JtYXRpb24gYWJvdXQgdGhlIHJlbGV2YW50IFdTREIgKG9yIGxp c3Qgb2YgREJzKSB0byBxdWVyeSBhcyB3ZWxsIGFzIHRoZSByZWd1bGF0b3J5IGRvbWFpbiB0aGF0 IGl0IGlzIGN1cnJlbnRseSBsb2NhdGVkIGluLg0KDQotUmFqIA0KIA0KDQoNCk9uIDgvMTMvMTIg OTo1NSBBTSwgImV4dCBSb3NlbiwgQnJpYW4iIDxCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej4gd3Jv dGU6DQoNCj48YXMgaW5kaXZpZHVhbD4NCj5JIHByZWZlciBMb1NUIGZvciBkaXNjb3ZlcnkuICBM b1NUIGNhbiBkbyByZWN1ci9pdGVyYXRlIGxpa2UgRE5TLCBhbmQgDQo+aXQgY2FuIHJldHVybiBt b3JlIHRoYW4gb25lIFVSSS4gIFRoYXQgd291bGQgYWxsb3cgdGhlIGJhc2UgTG9TVCANCj5kaXNj b3ZlcnkgdG8gZmluZCBhIHNlcnZlciB0aGF0IHJldHVybmVkIHRoZSBsaXN0LiAgVGhlIGluaXRp YWwgTG9TVCANCj5xdWVyeSByZXR1cm5zIHRoZSBsaXN0IHNlcnZlciwgYW5kIGEgcmVjdXIgb3Ig aXRlcmF0ZSByZXR1cm5zIHRoZSBsaXN0Lg0KPg0KPkJyaWFuDQo+DQo+DQo+DQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogCVBldGVyIE1jQ2FubiBbbWFpbHRvOlBldGVyLk1j Q2FubkBodWF3ZWkuY29tXQ0KPlNlbnQ6CU1vbmRheSwgQXVndXN0IDEzLCAyMDEyIDEwOjQ3IEFN IEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KPlRvOglKb2VsIE0uIEhhbHBlcm47IEdhYm9yLkJhamtv QG5va2lhLmNvbQ0KPkNjOglwYXdzQGlldGYub3JnDQo+U3ViamVjdDoJUmU6IFtwYXdzXSBuZWVk IGZvciBEQiBpbml0aWFsaXphdGlvbiBtZXNzYWdlDQo+DQo+QWdyZWUgd2l0aCBKb2VsLg0KPg0K PkkgdGhpbmsgYSBMT1NULXN0eWxlIHNlcnZpY2UgKGEpIGlzIGdvb2QgZm9yIGRpc2NvdmVyaW5n IGEgc2VydmVyIA0KPmFzc29jaWF0ZWQgd2l0aCBhIHJlZ3VsYXRvcnkgZG9tYWluLiAgQWZ0ZXIg dGhhdCwgeW91IGNhbiBxdWVyeSB0aGUgDQo+cmVndWxhdG9yIChiKSB0byBmaW5kIGFwcHJvdmVk IGRhdGFiYXNlcy4gIFRoZW4sIHlvdSBjYW4gY2hvb3NlIG9uZSBvZiANCj50aG9zZSBkYXRhYmFz ZXMgd2l0aCB3aGljaCB5b3UgaGF2ZSBhIHJlbGF0aW9uc2hpcCBvciB0aGF0IHlvdSBrbm93IA0K PnRocm91Z2ggc29tZSBtZWFucyB3aWxsIHNlcnZpY2UgeW91ciByZXF1ZXN0IChjKS4gIFRoZSBw cm90b2NvbCBmb3IgKGIpIA0KPmFuZCAoYykgY291bGQgYm90aCBiZSBQQVdTLCBpZiB3ZSBqdXN0 IGFkZCBzb21lIHNvcnQgb2YgaW5kaXJlY3Rpb24gdG8gDQo+b3VyIHNwZWNpZmljYXRpb24uDQo+ DQo+LVBldGUNCj4NCj4NCj5Kb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+PiBUaGUgbWFzdGVyIGhh cyB0byBrbm93IGl0cyBsb2NhdGlvbiBpbiBnZW9ncmFwaGljIGNvb3JkaW5hdGVzIChHUFMsDQo+ PiBldGMuKSAgIEFzIGZhciBhcyBJIGtub3csIHdlIGhhdmUgbm90IGFzc3VtZWQgdGhhdCB0aGUg bWFwcyB0byB0cmFuc2xhdGUNCj4+IHRoYXQgaW50byBwb2xpdGljYWwgZG9tYWlucyBhcmUga25v d24gdG8gdGhlIG1hc3RlciBhIHByaW9yaS4NCj4+IA0KPj4gVGhlcmUgYXJlIGRlcGxveW1lbnQg c2NlbmFyaW9zIChjZWxsIHRvd2VycyBjb21lIHRvIG1pbmQpIHdoZXJlIHRoZSANCj4+IG1hc3Rl ciBjYW4gcHJvYmFibHkgYmUgcHJvdmlzaW9uZWQgd2l0aCB0aGUgcmlnaHQgYWRtaW5pc3RyYXRp dmUgDQo+PiBpbmZvcm1hdGlvbi4gIFRoZXJlIGFyZSBvdGhlciBzY2VuYXJpb3Mgd2hlcmUgdGhh dCBpcyBub3Qgb2J2aW91c2x5IA0KPj4gYWNoaWV2YWJsZS4NCj4+IA0KPj4gWW91cnMsDQo+PiBK b2VsDQo+PiANCj4+IE9uIDgvMTAvMjAxMiA3OjMzIFBNLCBHYWJvci5CYWprb0Bub2tpYS5jb20g d3JvdGU6DQo+Pj4gV2hpbGUgSSBhZ3JlZSB0aGF0IHJlLWRpcmVjdGlvbiBmcm9tIGFuIGludGVy bWVkaWFyeSB0byB0aGUgZmluYWwNCj4+IHJlY2lwaWVudCBzaG91bGQgbm90IGJlIGRpc2FsbG93 ZWQsIEkgZG9uJ3QgdGhpbmsgdGhlIHVzZSBjYXNlIHlvdSANCj4+IGFyZSBkZXNjcmliaW5nIGlz IGEgdmFsaWQgb25lLiBUaGUgbWFzdGVyIG5lZWRzIHRvIGtub3cgaXRzIGxvY2F0aW9uIA0KPj4g YmVmb3JlIGVuZ2FnaW5nIGludG8gREIgZGlzY292ZXJ5LiBJZiBpdCBkb2Vzbid0LCB0aGVuIGl0 IGNhbiB1c2UgDQo+PiBzb21lIGV4aXN0aW5nIG1lY2hhbmlzbSB0byBmaW5kIGl0IG91dCAoZWcs IFJGQzU5ODUpIHByaW9yIHRvIHRoZSBEQiANCj4+IGRpc2NvdmVyeSBwcm9jZXNzLCBidXQgdGhh dCBmb3IgbWUgaXMgYSBzZXBhcmF0ZSB0cmFuc2FjdGlvbi4NCj4+PiANCj4+PiBUaGUgY3VycmVu dCBEQiBkaXNjb3ZlcnkgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbg0KPj4gaHR0cDovL3d3dy5pZXRm Lm9yZy9pZC9kcmFmdC1wcm9iYXNjby1wYXdzLWRpc2NvdmVyeS0wMS50eHQgYXNzdW1lcyAgDQo+ PnRoYXQgdGhlIG1hc3RlciBrbm93cyBpdHMgbG9jYXRpb24gYmVmb3JlIHBlcmZvcm1pbmcgREIg ZGlzY292ZXJ5OyAgDQo+PmFmdGVyIHdoaWNoIGl0IG5lZWRzIHRvIGRvIGEgcmVndWxhdG9yeSBk b21haW4gZGlzY292ZXJ5IGFzIHdlbGwuDQo+PiBCcmlhbiBzdWdnZXN0ZWQgcmVndWxhdG9yeSBk b21haW4gY291bGQgYmUgYSBwYXJhbWV0ZXIgb2YgdGhlIERCIFVSSSwgIA0KPj50aHVzIG5vIG5l ZWQgZm9yIHNlcGFyYXRlIHJlZ3VsYXRvcnkgZG9tYWluIGRpc2NvdmVyeS4gQW55IG90aGVyIA0K Pj5zdWdnZXN0aW9ucz8NCj4+PiANCj4+PiAtIEdhYm9yDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBleHQgSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbV0NCj4+PiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDA5LCAyMDEyIDY6 MjUgUE0NCj4+PiBUbzogQmFqa28gR2Fib3IgKE5va2lhLUNJQy9TaWxpY29uVmFsbGV5KQ0KPj4+ IENjOiBwYXdzQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtwYXdzXSBuZWVkIGZvciBEQiBp bml0aWFsaXphdGlvbiBtZXNzYWdlDQo+Pj4gDQo+Pj4gUmVsYXRlZCBzdWdnZXN0aW9uOiAgQXNz dW1pbmcgd2UgaGF2ZSBhIGRpc2NvdmVyeSBwcm90b2NvbCB3aGljaCBjYW4gDQo+Pj4gcmV0dXJu IGEgVVJJLCB0aGUgcHJvdG9jb2wgc2VtYW50aWNzIHNob3VsZCBiZSBzdWNoIHRoYXQgdGhlIFVS SSBjYW4gDQo+Pj4gYmUgdGhlIGZpbmFsIERCIFVSSSwgb3IgYW5vdGhlciBpbnRlcm1lZGlhcnkg aW4gdGhlIHByb2Nlc3MuICBUaHVzLCANCj4+PiB0aGUgcHJvdG9jb2wgc2hvdWxkIG5vdCBsb2Nr IGluIHRoYXQgdGhlcmUgY2FuIGJlIG9ubHkgMCBvciAxIA0KPj4+IGludGVybWVkaWFyaWVzIGlu IHRoZSByZXNvbHV0aW9uLCBidXQgc2hvdWxkIGFsbG93IHNldmVyYWwuICAoV2UgDQo+Pj4gYWxy ZWFkeSBoYXZlIHN1Z2dlc3RlZCBjYXNlcyB3aGVyZSBhdCBsZWFzdCB0d28gYXJlIG5lZWRlZCwg b25lIHRvIA0KPj4+IGRldGVybWluZSB3aGVyZSB5b3UgYXJlIGJ5IGFza2luZyB5b3VyIHZlbmRv ciwgYW5kIG9uZSB0byBkZXRlcm1pbmUgDQo+Pj4gd2hvIHlvdSBjYW4gdGFsayB0byBieSBhc2tp bmcgeW91ciBsb2NhbCByZWd1bGF0b3IuKQ0KPj4+IA0KPj4+IFlvdXJzLA0KPj4+IEpvZWwNCj4+ PiANCj4+PiBPbiA4LzkvMjAxMiA4OjAyIFBNLCBHYWJvci5CYWprb0Bub2tpYS5jb20gd3JvdGU6 DQo+Pj4+IEZvbGtzLA0KPj4+PiANCj4+Pj4gRHVyaW5nIHRoZSBWYW5jb3V2ZXIgRjJGIGRpc2N1 c3Npb25zIHdlIGhhZCBzb21lIGdvb2QgZGlzY3Vzc2lvbnMsIA0KPj4+PiBidXQgbm8gYWdyZWVt ZW50IG9uIHdldGhlciBhbiBpbml0aWFsaXphdGlvbiBtZXNzYWdlLCBhcyBwcm9wb3NlZCANCj4+ Pj4gaW4gZHJhZnQtZGFzIGlzIG5lY2Vzc2FyeSBvciBub3QuDQo+Pj4+IA0KPj4+PiBZb3UgbWF5 IGNoZWNrIHRoZSBtaW51dGVzIHRvIHNlZSB3aGF0IHdhcyBzYWlkIGF0IHRoZSBtaWtlOg0KPj4+ PiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg0L21pbnV0ZXMvbWludXRlcy04NC1w YXdzDQo+Pj4+IA0KPj4+PiBQZW9wbGUgc3Bva2UgbW9zdGx5IGluIGZhdm9yLCBidXQgdGhlcmUg d2VyZSBwZW9wbGUgd2hvIGFsc28gc2FpZCANCj4+Pj4gdGhhdCB0aGlzIG1lc3NhZ2UgaXMgcmVk dW5kYW50IHdpdGggcmVnaXN0cmF0aW9uIG1lc3NhZ2UuDQo+Pj4+IA0KPj4+PiBRdWVzdGlvbiMx OiBuZWVkIGZvciBhbiBpbml0aWFsaXphdGlvbiBtZXNzYWdlDQo+Pj4+IA0KPj4+PiBVbmZvcnR1 bmF0ZWx5IHdlIGRpZCBub3QgaGF2ZSB0aW1lIHRvIGRpc2N1c3MgdGhlIERCIGRpc2NvdmVyeSAN Cj4+Pj4gYXNwZWN0LCBhbmQgdGhhdCBtYXkgYmUgcmVsYXRlZCB0byB0aGlzIHRvcGljLiBUaGUg b25seSBEQiANCj4+Pj4gZGlzY292ZXJ5IGRvY3VtZW50IGF2YWlsYWJsZSBjdXJyZW50bHksIA0K Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXByb2Jhc2NvLXBhd3MtZGlzY292ZXJ5 LTAxLnR4dCwgDQo+Pj4+IHByb3Bvc2VzLCB0aGF0IHRoZSBtYXN0ZXIgZGV2aWNlIGNvbnRhY3Rz IGEgcHJlLXByb3Zpc2lvbmVkIA0KPj4+PiBkaXNjb3Zlcnkgc2VydmVyIGFuZCBwcm92aWRlcyBp dHMgbG9jYXRpb24sIGFuZCBpbiByZXR1cm4gdGhlIA0KPj4+PiBkaXNjb3Zlcnkgc2VydmVyIHJl dHVybnMgdGhlIFVSSSBvZiB0aGUgREIgZm9yIHRoYXQgcmVndWxhdG9yeSANCj4+Pj4gZG9tYWlu LiBBdCB0aGlzIHBvaW50LCB0aGUgbWFzdGVyIGRldmljZSBrbm93cyB3aGljaCBEQiB0byBjb250 YWN0LCANCj4+Pj4gYnV0IGl0IGRvZXMgbm90IG5lY2Vzc2FyaWx5IGtub3cgd2hhdCByZWd1bGF0 b3J5IGRvbWFpbiB0aGF0IERCIA0KPj4+PiBiZWxvbmdzIHRvLiBUaHVzLCBpdCBkb2Vzbid0IGtu b3cgd2hhdCBhcmUgdGhlIG9wZXJhdGluZyBydWxlcywgDQo+Pj4+IHdoZXRoZXIgaXQgaGFzIHRv IGF1dGhlbnRpY2F0ZSwgb3IgcmVnaXN0ZXIsIGV0Yy4NCj4+Pj4gDQo+Pj4+IFRodXMsIGl0IHNl ZW1zIGxvZ2ljYWwgdG8gbWUgdGhhdCB0aGUgbWFzdGVyIGRldmljZSBmaXJzdCBxdWVyaWVzIA0K Pj4+PiB0aGUgREIgdG8gZmluZCBvdXQgdGhlIHJlZ3VsYXRvcnkgZG9tYWluLiBXZSBldmVuIGhh dmUgc3VjaCBhIA0KPj4+PiByZXF1aXJlbWVudCBpbiB0aGUgcmVxdWlyZW1lbnQgZHJhZnQsIHJl cXVpcmVtZW50Og0KPj4+PiANCj4+Pj4gIlAuMzogICBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0 IGRldGVybWluYXRpb24gb2YNCj4+Pj4gcmVndWxhdG9yeSAgICAgICAgICAgICBkb21haW4gZ292 ZXJuaW5nIGl0cyBjdXJyZW50IGxvY2F0aW9uLiINCj4+Pj4gDQo+Pj4+IFRoZSBpbmZvcm1hdGlv biBhYm91dCB0aGUgcmVndWxhdG9yeSBkb21haW4gbWF5IGJlIGNhY2hlZCwgYW5kIHRoZSANCj4+ Pj4gbWFzdGVyIGRldmljZSBtYXkgbm90IG5lZWQgdG8gcGxhY2UgdGhhdCBxdWVyeSBldmVyeSB0 aW1lLCBidXQgdGhpcyANCj4+Pj4gbWVzc2FnZSBleGNoYW5nZSBtYXkgYmUgbmVjZXNzYXJ5IGlu IGNlcnRhaW4gY2FzZXMuIEFueSBjb21tZW50cyB0byANCj4+Pj4gdGhpcyBwb2ludD8NCj4+Pj4g DQo+Pj4+IFF1ZXN0aW9uIzINCj4+Pj4gDQo+Pj4+IFRoZW4sIGl0IGlzIGEgc2xpZ2h0bHkgc2Vw YXJhdGUgaXNzdWUsIGlmIHRoaXMgbWVzc2FnZSBleGNoYW5nZSBoYXMgDQo+Pj4+IHRvIHRha2Ug cGxhY2UsIHRoZW4gd2hhdCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRoZSBEQiByZXR1cm5zLg0K Pj4+PiBkcmFmdC1kYXMgcHJvcG9zZXMgdGhhdCByZWd1bGF0b3J5IGRvbWFpbiBzcGVjaWZpYyBp bmZvcm1hdGlvbiBiZSANCj4+Pj4gcmV0dXJuZWQgdG8gdGhlIG1hc3RlciBkZXZpY2UuDQo+Pj4+ IA0KPj4+PiBRdWVzdGlvbiMzDQo+Pj4+IA0KPj4+PiBZZXQgYW5vdGhlciBzZXBhcmF0ZSBwb2lu dCBpcyB0aGF0IGRyYWZ0LWRhcyBwcm9wb3NlcyB0byB1c2UgdGhpcyANCj4+Pj4gaW5pdGlhbGl6 YXRpb24gbWVzc2FnZSBhbHNvIHRvIGluaXRpYXRlIGNsaWVudCBhdXRoZW50aWNhdGlvbiANCj4+ Pj4gKHB1dHRpbmcgc2hhcmVkIHNlY3JldCB2cyBjZXJ0IGlzc3VlIGFzaWRlIGZvciB0aGUgdGlt ZSBiZWluZykuIEluIA0KPj4+PiBjYXNlcyB3aGVuIHRoZSBtYXN0ZXIgZGV2aWNlIGRvZXMgbm90 IGtub3cgdGhlIHJlZ3VsYXRvcnkgZG9tYWluIGl0IA0KPj4+PiBpcyBpbiwgdGhlbiBpdCBkb2Vz IG5vdCBrbm93IHdoZXRoZXIgYXV0aGVudGljYXRpb24gaXMgcmVxdWlyZWQgaW4gDQo+Pj4+IHRo YXQgcmVndWxhdG9yeSBkb21haW4gb3Igbm90OyBzbyB3aHkgd291bGQgaW5pdGlhdGUgYXV0aGVu dGljYXRpb24gDQo+Pj4+IHRoZW4/IFNpbWlsYXIgY29tbWVudCBhcHBsaWVzIHRvIGRyYWZ0LXdl aSwgd2hlcmUgaXQgaXMgcHJvcG9zZWQgDQo+Pj4+IHRoYXQgYWZ0ZXIgREIgZGlzY292ZXJ5IHRo ZSBtYXN0ZXIgZGV2aWNlIGF1dGhlbnRpY2F0ZXMgYXQgVExTIA0KPj4+PiBsYXllciBhbmQgcGVy Zm9ybXMgcmVnaXN0cmF0aW9uOyBob3cgZG9lcyBpdCBrbm93IHRoYXQgaXQgaGFzIHRvIA0KPj4+ PiBhdXRoZW50aWNhdGUgYW5kIHJlZ2lzdGVyLCBpZiBpdCBkb2Vzbid0IGtub3cgdGhlIHJlZ3Vs YXRvcnkgZG9tYWluPw0KPj4+PiANCj4+Pj4gSW4gbXkgb3BpbmlvbiAoY2hhaXIgaGF0IG9mZiks IHRoZSBzZXF1ZW5jZSBvZiBldmVudHMgc2hvdWxkIGJlIHNnIA0KPj4+PiBsaWtlDQo+Pj4+IHRo aXM6DQo+Pj4+IA0KPj4+PiAxLkRCIGRpc2NvdmVyeSAobWF5IGJlIHNraXBwZWQgaWYgY2FjaGVk IGluZm9ybWF0aW9uIGF2YWlsYWJsZSkNCj4+Pj4gDQo+Pj4+IDIuUmVndWxhdG9yeSBkb21haW4g cXVlcnkgKG1heSBiZSBza2lwcGVkIGlmIGNhY2hlZCBpbmZvcm1hdGlvbg0KPj4+PiBhdmFpbGFi bGUpDQo+Pj4+IA0KPj4+PiAzLkF1dGhlbnRpY2F0aW9uIChpZiByZXF1aXJlZCkNCj4+Pj4gDQo+ Pj4+IDQuUmVnaXN0cmF0aW9uIChpZiByZXF1aXJlZCkNCj4+Pj4gDQo+Pj4+IDUuQ2hhbm5lbCBh dmFpbGFiaWxpdHkgcXVlcnkgKG1heSBiZSBjb21iaW5lZCB3aXRoIHJlZ2lzdHJhdGlvbj8pDQo+ Pj4+IA0KPj4+PiBDb21tZW50cyBhcmUgd2VsY29tZSBhbmQgZXhwZWN0ZWQuDQo+Pj4+IA0KPj4+ PiAtR2Fib3INCj4+Pj4gDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5wYXdzIG1haWxpbmcgbGlzdA0KPnBhd3NAaWV0Zi5vcmcNCj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnBhd3MgbWFpbGluZyBsaXN0DQo+cGF3c0Bp ZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQo= From brian.rosen@neustar.biz Mon Aug 13 12:11:40 2012 Return-Path: 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 5F88E21F84E1 for ; Mon, 13 Aug 2012 12:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shM8tPkDTQa2 for ; Mon, 13 Aug 2012 12:11:39 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id CE1B321F84D9 for ; Mon, 13 Aug 2012 12:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1344885210; x=1660236644; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=9mvewOECt++qTDO0LyjC2 /z9qdFYY+gXQ8dc/CC9wTo=; b=ZekDtAr90glfvxLV3NFKYRz4moHkoHCvg0lwU rMNKBfxELTlTvxEO+dOYgOrsCBUPZeVdFLOr4s/eH4zAfURaA== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.12590958; Mon, 13 Aug 2012 15:13:28 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 13 Aug 2012 15:11:32 -0400 From: "Rosen, Brian" Date: Mon, 13 Aug 2012 15:11:31 -0400 Thread-Topic: DB discovery [was: RE: [paws] need for DB initialization message] Thread-Index: Ac15gqFNItaZd90nQoOT2JXoMeeCoQABNFzr Message-ID: <55A5A9A87506CB4BA580BF9D531957DA690227B9@STNTEXCH01.cis.neustar.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: TjSF62YlQ192mnS1kX+E3g== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 To: "'gabor.bajko@nokia.com'" , "'basavaraj.patil@nokia.com'" , "'peter.mccann@huawei.com'" , "'jmh@joelhalpern.com'" Cc: "'paws@ietf.org'" Subject: Re: [paws] DB discovery [was: RE: need for DB initialization message] X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 19:11:40 -0000 VGhlIFUtTkFQVFIgaXMgb25seSBwYXJ0IG9mIExvU1QgZGlzY292ZXJ5LiAgSWYgeW91IGRvbid0 IGxpa2UgaXQsIHlvdXIgb25seSBhbHRlcm5hdGl2ZSBpcyBwcm92aXNpb25pbmcsIGJ1dCBzb21l IGZvbGtzIHNlZW0gdG8gbGlrZSBwcm92aXNpb25pbmcuICBXZSBoYXZlIGEgd2hvbGUgbG90IG9m IGV4cGVyaWVuY2Ugd2l0aCBzZXJ2aWNlIGRpc2NvdmVyeS4gIFRoZXJlIGFyZSBubyBzaW1wbGUg bWVjaGFuaXNtcyB0aGF0IHdvcmsgZ2xvYmFsbHkgd2l0aG91dCBzdXBwb3J0IGZyb20gc29tZSBr aW5kIG9mIGluZnJhc3RydWN0dXJlLiAgVG8gbWUsIHRoZSBub3Rpb24gdGhhdCBhIGRldmljZSBt YW51ZmFjdHVyZXIgd2lsbCBzdXBwb3J0IGEgZGlzY292ZXJ5IHNlcnZpY2UgZm9yIHRoZSBsaWZl dGltZSBvZiB0aGUgZGV2aWNlIGlzIGxlc3MgbGlrZWx5IGFzIElTUCBzdXBwb3J0IGZvciBMb1NU LCBzaW5jZSB0aGUgbGF0dGVyIHdpbGwgYmUgbmVlZGVkIGZvciBlbWVyZ2VuY3kgY2FsbGluZy4K CklmIHdlIG5lZWRlZCB0byBkbyBhIGpzb24gZW5jb2Rpbmcgb2YgTG9TVCwgbm8gb25lIHdpbGwg b2JqZWN0LgoKVGhlIG9ubHkgc3Vic2V0IHdlIG5lZWQgaXMgYSBzaW5nbGUgVVJOIChhbHRob3Vn aCB5b3UgY291bGQgaW1hZ2luZSBhIGNvdW50cnkgc3BlY2lmaWMgVVJOKSwgYW5kIG5vIHZhbGlk YXRpb24uClRoZSBzZXJ2aWNlIGJvdW5kYXJ5IHBhcnQgaXMgdmVyeSBoYW5keSBmb3IgYSBtb2Jp bGUgZGV2aWNlIHRvIGRldGVybWluZSB3aGVuIGl0IGhhcyBtb3ZlZCBiZXlvbmQgdGhlIGJvdW5k YXJ5IHNlcnZlZCBieSB0aGUgc2FtZSBVUk4uICBUaGlzIHdvdWxkIGhhcHBlbiBpZiB5b3Ugcm9h bWVkIGFjcm9zcyBhIGJvcmRlci4gIEl0J3Mgbm90IGEgcmVxdWlyZWQgZWxlbWVudCBvbiB0aGUg c2VydmVyLCBhbmQgdGhlIGNsaWVudCBjYW4gaWdub3JlIGl0LgoKQnJpYW4gPGFzIGluZGl2aWR1 YWw+CgoNCg0KIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAJR2Fib3IuQmFqa29A bm9raWEuY29tIFttYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tXQ0KU2VudDoJTW9uZGF5LCBB dWd1c3QgMTMsIDIwMTIgMDI6NDYgUE0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQpUbzoJUm9zZW4s IEJyaWFuOyBCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tOyBwZXRlci5tY2Nhbm5AaHVhd2VpLmNv bTsgam1oQGpvZWxoYWxwZXJuLmNvbQ0KQ2M6CXBhd3NAaWV0Zi5vcmcNClN1YmplY3Q6CURCIGRp c2NvdmVyeSBbd2FzOiBSRTogW3Bhd3NdIG5lZWQgZm9yIERCIGluaXRpYWxpemF0aW9uIG1lc3Nh Z2VdDQoNCkkgY291bGQgYWxzbyBzZWUgYSBmZXcgdGhpbmdzIHdoeSBMb1NUIG1pZ2h0IG5vdCBi ZSB0aGUgYmVzdCBmaXQgZm9yIFdTREIgZGlzY292ZXJ5Og0KDQpMb1NUIGRvZXMgbm90IHNwZWNp ZnkgTG9TVCBzZXJ2ZXIgZGlzY292ZXJ5LiBUaGVyZSBpcyBhIHNlcGFyYXRlIFJGQyBvbiBkaXNj b3ZlcmluZyBMb1NUIHVzaW5nIERIQ1AsIGJ1dCB0aGF0J3Mgbm90IGRlcGxveW1lbnQgZnJpZW5k bHkuIFNvIGEgZGlzY292ZXJ5IG1lY2hhbmlzbSwgZWcgdGhlIG9uZSBkZXNjcmliZWQgaW4gUmFq J3MgZG9jdW1lbnQsIGlzIG5lZWRlZCBhbnl3YXkuDQoNCkxvU1QgcmVsaWVzIG9uIFUtTkFQVFIs IGFuZCB3ZSBhbGwga25vdyBob3cgZGlmZmljdWx0IGlzIHRvIGdldCBETlMgYWRtaW5zIGFkZCBu ZXcgcmVjb3JkcyB0byB0aGVpciB6b25lcy4NCg0KVGhlIFdHIHNlZW1zIHRvIHByZWZlciBKU09O IGVuY29kaW5nIHRvIFhNTCwgdG8gYmUgYWJsZSB0byBzdXBwb3J0IGxpZ2h0d2VpZ2h0IGRldmlj ZXMsIExvU1QgdXNlcyBYTUwuDQoNClRoZXJlIGlzIGEgbG90IG9mIHN0dWZmIGluIExvU1QsIHdl IHdvdWxkIG5lZWQgYSB2ZXJ5IHNtYWxsIHN1YnNldCBvZiBpdC4NCg0KLSBHYWJvcg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZXh0IFJvc2VuLCBCcmlhbiBbbWFpbHRvOkJy aWFuLlJvc2VuQG5ldXN0YXIuYml6XSANClNlbnQ6IE1vbmRheSwgQXVndXN0IDEzLCAyMDEyIDEw OjU5IEFNDQpUbzogUGF0aWwgQmFzYXZhcmFqIChOb2tpYS1DSUMvRGFsbGFzKTsgJ3BldGVyLm1j Y2FubkBodWF3ZWkuY29tJzsgJ2ptaEBqb2VsaGFscGVybi5jb20nOyBCYWprbyBHYWJvciAoTm9r aWEtQ0lDL1NpbGljb25WYWxsZXkpDQpDYzogJ3Bhd3NAaWV0Zi5vcmcnDQpTdWJqZWN0OiBSRTog W3Bhd3NdIG5lZWQgZm9yIERCIGluaXRpYWxpemF0aW9uIG1lc3NhZ2UNCg0KaW4gd2hhdCB3YXkg aXMgaXQgb3ZlcmtpbGw/ICBZb3UgcGFzcyBhIGxvY2F0aW9uIGFuZCBhIHNob3J0IFVSTiBpbiwg dXNpbmcgYSBzaW1wbGUgSFRUUCBleGNoYW5nZSwgYW5kIHlvdSBnZXQgYSAoc2V0IG9mKSBVUklz IG91dC4gIFRoZSBleHRyYSBzdHVmZiBpdCBkb2VzIChsaWtlIHJlY3VyL2l0ZXJhdGUpIGlzIHVz ZWZ1bC4gIEFib3V0IHRoZSBvbmx5IGZlYXR1cmUgd2UgZG9uJ3QgbmVlZCBpcyB2YWxpZGF0ZSwg d2hpY2ggaXMgdHJpdmlhbCB0byBub3Qgc3VwcG9ydCAoc2luY2UgaXQncyBvcHRpb25hbCkuICAN Cg0KUGxlYXNlIGNpdGUgYSBzcGVjaWZpYyBhc3BlY3Qgb2YgTG9TVCB3aGljaCBpcyBvdmVya2ls bCBmb3IgdXMuDQoNCkJyaWFuIDxhcyBpbmRpdmlkdWFsPg0KDQoNCg0KIC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiAJQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbSBbbWFpbHRvOkJh c2F2YXJhai5QYXRpbEBub2tpYS5jb21dDQpTZW50OglNb25kYXksIEF1Z3VzdCAxMywgMjAxMiAw MTo0OSBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNClRvOglSb3NlbiwgQnJpYW47IHBldGVyLm1j Y2FubkBodWF3ZWkuY29tOyBqbWhAam9lbGhhbHBlcm4uY29tOyBHYWJvci5CYWprb0Bub2tpYS5j b20NCkNjOglwYXdzQGlldGYub3JnDQpTdWJqZWN0OglSZTogW3Bhd3NdIG5lZWQgZm9yIERCIGlu aXRpYWxpemF0aW9uIG1lc3NhZ2UNCg0KDQpJIHRoaW5rIHRoYXQgTG9TVCBpcyBhIGJpdCBvZiBh biBvdmVya2lsbCBmb3Igd2hhdCBpcyByZWFsbHkgbmVlZGVkIGluIHRoZSBjb250ZXh0IG9mIFBB V1MgZm9yIGRhdGFiYXNlIGRpc2NvdmVyeS4NClRoZSBXU0RCIGRpc2NvdmVyeSBzZXJ2ZXIgKGFz IHBlciBkcmFmdC1wcm9iYXNjby1wYXdzLWRpc2NvdmVyeS0wMS50eHQpDQpjYW4gcHJvdmlkZSB0 aGUgbWFzdGVyIGRldmljZSB3aXRoIGluZm9ybWF0aW9uIGFib3V0IHRoZSByZWxldmFudCBXU0RC IChvciBsaXN0IG9mIERCcykgdG8gcXVlcnkgYXMgd2VsbCBhcyB0aGUgcmVndWxhdG9yeSBkb21h aW4gdGhhdCBpdCBpcyBjdXJyZW50bHkgbG9jYXRlZCBpbi4NCg0KLVJhaiANCiANCg0KDQpPbiA4 LzEzLzEyIDk6NTUgQU0sICJleHQgUm9zZW4sIEJyaWFuIiA8QnJpYW4uUm9zZW5AbmV1c3Rhci5i aXo+IHdyb3RlOg0KDQo+PGFzIGluZGl2aWR1YWw+DQo+SSBwcmVmZXIgTG9TVCBmb3IgZGlzY292 ZXJ5LiAgTG9TVCBjYW4gZG8gcmVjdXIvaXRlcmF0ZSBsaWtlIEROUywgYW5kIA0KPml0IGNhbiBy ZXR1cm4gbW9yZSB0aGFuIG9uZSBVUkkuICBUaGF0IHdvdWxkIGFsbG93IHRoZSBiYXNlIExvU1Qg DQo+ZGlzY292ZXJ5IHRvIGZpbmQgYSBzZXJ2ZXIgdGhhdCByZXR1cm5lZCB0aGUgbGlzdC4gIFRo ZSBpbml0aWFsIExvU1QgDQo+cXVlcnkgcmV0dXJucyB0aGUgbGlzdCBzZXJ2ZXIsIGFuZCBhIHJl Y3VyIG9yIGl0ZXJhdGUgcmV0dXJucyB0aGUgbGlzdC4NCj4NCj5Ccmlhbg0KPg0KPg0KPg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IAlQZXRlciBNY0Nhbm4gW21haWx0bzpQ ZXRlci5NY0Nhbm5AaHVhd2VpLmNvbV0NCj5TZW50OglNb25kYXksIEF1Z3VzdCAxMywgMjAxMiAx MDo0NyBBTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNCj5UbzoJSm9lbCBNLiBIYWxwZXJuOyBHYWJv ci5CYWprb0Bub2tpYS5jb20NCj5DYzoJcGF3c0BpZXRmLm9yZw0KPlN1YmplY3Q6CVJlOiBbcGF3 c10gbmVlZCBmb3IgREIgaW5pdGlhbGl6YXRpb24gbWVzc2FnZQ0KPg0KPkFncmVlIHdpdGggSm9l bC4NCj4NCj5JIHRoaW5rIGEgTE9TVC1zdHlsZSBzZXJ2aWNlIChhKSBpcyBnb29kIGZvciBkaXNj b3ZlcmluZyBhIHNlcnZlciANCj5hc3NvY2lhdGVkIHdpdGggYSByZWd1bGF0b3J5IGRvbWFpbi4g IEFmdGVyIHRoYXQsIHlvdSBjYW4gcXVlcnkgdGhlIA0KPnJlZ3VsYXRvciAoYikgdG8gZmluZCBh cHByb3ZlZCBkYXRhYmFzZXMuICBUaGVuLCB5b3UgY2FuIGNob29zZSBvbmUgb2YgDQo+dGhvc2Ug ZGF0YWJhc2VzIHdpdGggd2hpY2ggeW91IGhhdmUgYSByZWxhdGlvbnNoaXAgb3IgdGhhdCB5b3Ug a25vdyANCj50aHJvdWdoIHNvbWUgbWVhbnMgd2lsbCBzZXJ2aWNlIHlvdXIgcmVxdWVzdCAoYyku ICBUaGUgcHJvdG9jb2wgZm9yIChiKSANCj5hbmQgKGMpIGNvdWxkIGJvdGggYmUgUEFXUywgaWYg d2UganVzdCBhZGQgc29tZSBzb3J0IG9mIGluZGlyZWN0aW9uIHRvIA0KPm91ciBzcGVjaWZpY2F0 aW9uLg0KPg0KPi1QZXRlDQo+DQo+DQo+Sm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4gVGhlIG1h c3RlciBoYXMgdG8ga25vdyBpdHMgbG9jYXRpb24gaW4gZ2VvZ3JhcGhpYyBjb29yZGluYXRlcyAo R1BTLA0KPj4gZXRjLikgICBBcyBmYXIgYXMgSSBrbm93LCB3ZSBoYXZlIG5vdCBhc3N1bWVkIHRo YXQgdGhlIG1hcHMgdG8gdHJhbnNsYXRlDQo+PiB0aGF0IGludG8gcG9saXRpY2FsIGRvbWFpbnMg YXJlIGtub3duIHRvIHRoZSBtYXN0ZXIgYSBwcmlvcmkuDQo+PiANCj4+IFRoZXJlIGFyZSBkZXBs b3ltZW50IHNjZW5hcmlvcyAoY2VsbCB0b3dlcnMgY29tZSB0byBtaW5kKSB3aGVyZSB0aGUgDQo+ PiBtYXN0ZXIgY2FuIHByb2JhYmx5IGJlIHByb3Zpc2lvbmVkIHdpdGggdGhlIHJpZ2h0IGFkbWlu aXN0cmF0aXZlIA0KPj4gaW5mb3JtYXRpb24uICBUaGVyZSBhcmUgb3RoZXIgc2NlbmFyaW9zIHdo ZXJlIHRoYXQgaXMgbm90IG9idmlvdXNseSANCj4+IGFjaGlldmFibGUuDQo+PiANCj4+IFlvdXJz LA0KPj4gSm9lbA0KPj4gDQo+PiBPbiA4LzEwLzIwMTIgNzozMyBQTSwgR2Fib3IuQmFqa29Abm9r aWEuY29tIHdyb3RlOg0KPj4+IFdoaWxlIEkgYWdyZWUgdGhhdCByZS1kaXJlY3Rpb24gZnJvbSBh biBpbnRlcm1lZGlhcnkgdG8gdGhlIGZpbmFsDQo+PiByZWNpcGllbnQgc2hvdWxkIG5vdCBiZSBk aXNhbGxvd2VkLCBJIGRvbid0IHRoaW5rIHRoZSB1c2UgY2FzZSB5b3UgDQo+PiBhcmUgZGVzY3Jp YmluZyBpcyBhIHZhbGlkIG9uZS4gVGhlIG1hc3RlciBuZWVkcyB0byBrbm93IGl0cyBsb2NhdGlv biANCj4+IGJlZm9yZSBlbmdhZ2luZyBpbnRvIERCIGRpc2NvdmVyeS4gSWYgaXQgZG9lc24ndCwg dGhlbiBpdCBjYW4gdXNlIA0KPj4gc29tZSBleGlzdGluZyBtZWNoYW5pc20gdG8gZmluZCBpdCBv dXQgKGVnLCBSRkM1OTg1KSBwcmlvciB0byB0aGUgREIgDQo+PiBkaXNjb3ZlcnkgcHJvY2Vzcywg YnV0IHRoYXQgZm9yIG1lIGlzIGEgc2VwYXJhdGUgdHJhbnNhY3Rpb24uDQo+Pj4gDQo+Pj4gVGhl IGN1cnJlbnQgREIgZGlzY292ZXJ5IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4NCj4+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcHJvYmFzY28tcGF3cy1kaXNjb3ZlcnktMDEudHh0IGFzc3Vt ZXMgIA0KPj50aGF0IHRoZSBtYXN0ZXIga25vd3MgaXRzIGxvY2F0aW9uIGJlZm9yZSBwZXJmb3Jt aW5nIERCIGRpc2NvdmVyeTsgIA0KPj5hZnRlciB3aGljaCBpdCBuZWVkcyB0byBkbyBhIHJlZ3Vs YXRvcnkgZG9tYWluIGRpc2NvdmVyeSBhcyB3ZWxsLg0KPj4gQnJpYW4gc3VnZ2VzdGVkIHJlZ3Vs YXRvcnkgZG9tYWluIGNvdWxkIGJlIGEgcGFyYW1ldGVyIG9mIHRoZSBEQiBVUkksICANCj4+dGh1 cyBubyBuZWVkIGZvciBzZXBhcmF0ZSByZWd1bGF0b3J5IGRvbWFpbiBkaXNjb3ZlcnkuIEFueSBv dGhlciANCj4+c3VnZ2VzdGlvbnM/DQo+Pj4gDQo+Pj4gLSBHYWJvcg0KPj4+IA0KPj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogZXh0IEpvZWwgTS4gSGFscGVybiBbbWFp bHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+Pj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwOSwg MjAxMiA2OjI1IFBNDQo+Pj4gVG86IEJhamtvIEdhYm9yIChOb2tpYS1DSUMvU2lsaWNvblZhbGxl eSkNCj4+PiBDYzogcGF3c0BpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBbcGF3c10gbmVlZCBm b3IgREIgaW5pdGlhbGl6YXRpb24gbWVzc2FnZQ0KPj4+IA0KPj4+IFJlbGF0ZWQgc3VnZ2VzdGlv bjogIEFzc3VtaW5nIHdlIGhhdmUgYSBkaXNjb3ZlcnkgcHJvdG9jb2wgd2hpY2ggY2FuIA0KPj4+ IHJldHVybiBhIFVSSSwgdGhlIHByb3RvY29sIHNlbWFudGljcyBzaG91bGQgYmUgc3VjaCB0aGF0 IHRoZSBVUkkgY2FuIA0KPj4+IGJlIHRoZSBmaW5hbCBEQiBVUkksIG9yIGFub3RoZXIgaW50ZXJt ZWRpYXJ5IGluIHRoZSBwcm9jZXNzLiAgVGh1cywgDQo+Pj4gdGhlIHByb3RvY29sIHNob3VsZCBu b3QgbG9jayBpbiB0aGF0IHRoZXJlIGNhbiBiZSBvbmx5IDAgb3IgMSANCj4+PiBpbnRlcm1lZGlh cmllcyBpbiB0aGUgcmVzb2x1dGlvbiwgYnV0IHNob3VsZCBhbGxvdyBzZXZlcmFsLiAgKFdlIA0K Pj4+IGFscmVhZHkgaGF2ZSBzdWdnZXN0ZWQgY2FzZXMgd2hlcmUgYXQgbGVhc3QgdHdvIGFyZSBu ZWVkZWQsIG9uZSB0byANCj4+PiBkZXRlcm1pbmUgd2hlcmUgeW91IGFyZSBieSBhc2tpbmcgeW91 ciB2ZW5kb3IsIGFuZCBvbmUgdG8gZGV0ZXJtaW5lIA0KPj4+IHdobyB5b3UgY2FuIHRhbGsgdG8g YnkgYXNraW5nIHlvdXIgbG9jYWwgcmVndWxhdG9yLikNCj4+PiANCj4+PiBZb3VycywNCj4+PiBK b2VsDQo+Pj4gDQo+Pj4gT24gOC85LzIwMTIgODowMiBQTSwgR2Fib3IuQmFqa29Abm9raWEuY29t IHdyb3RlOg0KPj4+PiBGb2xrcywNCj4+Pj4gDQo+Pj4+IER1cmluZyB0aGUgVmFuY291dmVyIEYy RiBkaXNjdXNzaW9ucyB3ZSBoYWQgc29tZSBnb29kIGRpc2N1c3Npb25zLCANCj4+Pj4gYnV0IG5v IGFncmVlbWVudCBvbiB3ZXRoZXIgYW4gaW5pdGlhbGl6YXRpb24gbWVzc2FnZSwgYXMgcHJvcG9z ZWQgDQo+Pj4+IGluIGRyYWZ0LWRhcyBpcyBuZWNlc3Nhcnkgb3Igbm90Lg0KPj4+PiANCj4+Pj4g WW91IG1heSBjaGVjayB0aGUgbWludXRlcyB0byBzZWUgd2hhdCB3YXMgc2FpZCBhdCB0aGUgbWlr ZToNCj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84NC9taW51dGVzL21pbnV0 ZXMtODQtcGF3cw0KPj4+PiANCj4+Pj4gUGVvcGxlIHNwb2tlIG1vc3RseSBpbiBmYXZvciwgYnV0 IHRoZXJlIHdlcmUgcGVvcGxlIHdobyBhbHNvIHNhaWQgDQo+Pj4+IHRoYXQgdGhpcyBtZXNzYWdl IGlzIHJlZHVuZGFudCB3aXRoIHJlZ2lzdHJhdGlvbiBtZXNzYWdlLg0KPj4+PiANCj4+Pj4gUXVl c3Rpb24jMTogbmVlZCBmb3IgYW4gaW5pdGlhbGl6YXRpb24gbWVzc2FnZQ0KPj4+PiANCj4+Pj4g VW5mb3J0dW5hdGVseSB3ZSBkaWQgbm90IGhhdmUgdGltZSB0byBkaXNjdXNzIHRoZSBEQiBkaXNj b3ZlcnkgDQo+Pj4+IGFzcGVjdCwgYW5kIHRoYXQgbWF5IGJlIHJlbGF0ZWQgdG8gdGhpcyB0b3Bp Yy4gVGhlIG9ubHkgREIgDQo+Pj4+IGRpc2NvdmVyeSBkb2N1bWVudCBhdmFpbGFibGUgY3VycmVu dGx5LCANCj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1wcm9iYXNjby1wYXdzLWRp c2NvdmVyeS0wMS50eHQsIA0KPj4+PiBwcm9wb3NlcywgdGhhdCB0aGUgbWFzdGVyIGRldmljZSBj b250YWN0cyBhIHByZS1wcm92aXNpb25lZCANCj4+Pj4gZGlzY292ZXJ5IHNlcnZlciBhbmQgcHJv dmlkZXMgaXRzIGxvY2F0aW9uLCBhbmQgaW4gcmV0dXJuIHRoZSANCj4+Pj4gZGlzY292ZXJ5IHNl cnZlciByZXR1cm5zIHRoZSBVUkkgb2YgdGhlIERCIGZvciB0aGF0IHJlZ3VsYXRvcnkgDQo+Pj4+ IGRvbWFpbi4gQXQgdGhpcyBwb2ludCwgdGhlIG1hc3RlciBkZXZpY2Uga25vd3Mgd2hpY2ggREIg dG8gY29udGFjdCwgDQo+Pj4+IGJ1dCBpdCBkb2VzIG5vdCBuZWNlc3NhcmlseSBrbm93IHdoYXQg cmVndWxhdG9yeSBkb21haW4gdGhhdCBEQiANCj4+Pj4gYmVsb25ncyB0by4gVGh1cywgaXQgZG9l c24ndCBrbm93IHdoYXQgYXJlIHRoZSBvcGVyYXRpbmcgcnVsZXMsIA0KPj4+PiB3aGV0aGVyIGl0 IGhhcyB0byBhdXRoZW50aWNhdGUsIG9yIHJlZ2lzdGVyLCBldGMuDQo+Pj4+IA0KPj4+PiBUaHVz LCBpdCBzZWVtcyBsb2dpY2FsIHRvIG1lIHRoYXQgdGhlIG1hc3RlciBkZXZpY2UgZmlyc3QgcXVl cmllcyANCj4+Pj4gdGhlIERCIHRvIGZpbmQgb3V0IHRoZSByZWd1bGF0b3J5IGRvbWFpbi4gV2Ug ZXZlbiBoYXZlIHN1Y2ggYSANCj4+Pj4gcmVxdWlyZW1lbnQgaW4gdGhlIHJlcXVpcmVtZW50IGRy YWZ0LCByZXF1aXJlbWVudDoNCj4+Pj4gDQo+Pj4+ICJQLjM6ICAgVGhlIHByb3RvY29sIE1VU1Qg c3VwcG9ydCBkZXRlcm1pbmF0aW9uIG9mDQo+Pj4+IHJlZ3VsYXRvcnkgICAgICAgICAgICAgZG9t YWluIGdvdmVybmluZyBpdHMgY3VycmVudCBsb2NhdGlvbi4iDQo+Pj4+IA0KPj4+PiBUaGUgaW5m b3JtYXRpb24gYWJvdXQgdGhlIHJlZ3VsYXRvcnkgZG9tYWluIG1heSBiZSBjYWNoZWQsIGFuZCB0 aGUgDQo+Pj4+IG1hc3RlciBkZXZpY2UgbWF5IG5vdCBuZWVkIHRvIHBsYWNlIHRoYXQgcXVlcnkg ZXZlcnkgdGltZSwgYnV0IHRoaXMgDQo+Pj4+IG1lc3NhZ2UgZXhjaGFuZ2UgbWF5IGJlIG5lY2Vz c2FyeSBpbiBjZXJ0YWluIGNhc2VzLiBBbnkgY29tbWVudHMgdG8gDQo+Pj4+IHRoaXMgcG9pbnQ/ DQo+Pj4+IA0KPj4+PiBRdWVzdGlvbiMyDQo+Pj4+IA0KPj4+PiBUaGVuLCBpdCBpcyBhIHNsaWdo dGx5IHNlcGFyYXRlIGlzc3VlLCBpZiB0aGlzIG1lc3NhZ2UgZXhjaGFuZ2UgaGFzIA0KPj4+PiB0 byB0YWtlIHBsYWNlLCB0aGVuIHdoYXQgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0aGUgREIgcmV0 dXJucy4NCj4+Pj4gZHJhZnQtZGFzIHByb3Bvc2VzIHRoYXQgcmVndWxhdG9yeSBkb21haW4gc3Bl Y2lmaWMgaW5mb3JtYXRpb24gYmUgDQo+Pj4+IHJldHVybmVkIHRvIHRoZSBtYXN0ZXIgZGV2aWNl Lg0KPj4+PiANCj4+Pj4gUXVlc3Rpb24jMw0KPj4+PiANCj4+Pj4gWWV0IGFub3RoZXIgc2VwYXJh dGUgcG9pbnQgaXMgdGhhdCBkcmFmdC1kYXMgcHJvcG9zZXMgdG8gdXNlIHRoaXMgDQo+Pj4+IGlu aXRpYWxpemF0aW9uIG1lc3NhZ2UgYWxzbyB0byBpbml0aWF0ZSBjbGllbnQgYXV0aGVudGljYXRp b24gDQo+Pj4+IChwdXR0aW5nIHNoYXJlZCBzZWNyZXQgdnMgY2VydCBpc3N1ZSBhc2lkZSBmb3Ig dGhlIHRpbWUgYmVpbmcpLiBJbiANCj4+Pj4gY2FzZXMgd2hlbiB0aGUgbWFzdGVyIGRldmljZSBk b2VzIG5vdCBrbm93IHRoZSByZWd1bGF0b3J5IGRvbWFpbiBpdCANCj4+Pj4gaXMgaW4sIHRoZW4g aXQgZG9lcyBub3Qga25vdyB3aGV0aGVyIGF1dGhlbnRpY2F0aW9uIGlzIHJlcXVpcmVkIGluIA0K Pj4+PiB0aGF0IHJlZ3VsYXRvcnkgZG9tYWluIG9yIG5vdDsgc28gd2h5IHdvdWxkIGluaXRpYXRl IGF1dGhlbnRpY2F0aW9uIA0KPj4+PiB0aGVuPyBTaW1pbGFyIGNvbW1lbnQgYXBwbGllcyB0byBk cmFmdC13ZWksIHdoZXJlIGl0IGlzIHByb3Bvc2VkIA0KPj4+PiB0aGF0IGFmdGVyIERCIGRpc2Nv dmVyeSB0aGUgbWFzdGVyIGRldmljZSBhdXRoZW50aWNhdGVzIGF0IFRMUyANCj4+Pj4gbGF5ZXIg YW5kIHBlcmZvcm1zIHJlZ2lzdHJhdGlvbjsgaG93IGRvZXMgaXQga25vdyB0aGF0IGl0IGhhcyB0 byANCj4+Pj4gYXV0aGVudGljYXRlIGFuZCByZWdpc3RlciwgaWYgaXQgZG9lc24ndCBrbm93IHRo ZSByZWd1bGF0b3J5IGRvbWFpbj8NCj4+Pj4gDQo+Pj4+IEluIG15IG9waW5pb24gKGNoYWlyIGhh dCBvZmYpLCB0aGUgc2VxdWVuY2Ugb2YgZXZlbnRzIHNob3VsZCBiZSBzZyANCj4+Pj4gbGlrZQ0K Pj4+PiB0aGlzOg0KPj4+PiANCj4+Pj4gMS5EQiBkaXNjb3ZlcnkgKG1heSBiZSBza2lwcGVkIGlm IGNhY2hlZCBpbmZvcm1hdGlvbiBhdmFpbGFibGUpDQo+Pj4+IA0KPj4+PiAyLlJlZ3VsYXRvcnkg ZG9tYWluIHF1ZXJ5IChtYXkgYmUgc2tpcHBlZCBpZiBjYWNoZWQgaW5mb3JtYXRpb24NCj4+Pj4g YXZhaWxhYmxlKQ0KPj4+PiANCj4+Pj4gMy5BdXRoZW50aWNhdGlvbiAoaWYgcmVxdWlyZWQpDQo+ Pj4+IA0KPj4+PiA0LlJlZ2lzdHJhdGlvbiAoaWYgcmVxdWlyZWQpDQo+Pj4+IA0KPj4+PiA1LkNo YW5uZWwgYXZhaWxhYmlsaXR5IHF1ZXJ5IChtYXkgYmUgY29tYmluZWQgd2l0aCByZWdpc3RyYXRp b24/KQ0KPj4+PiANCj4+Pj4gQ29tbWVudHMgYXJlIHdlbGNvbWUgYW5kIGV4cGVjdGVkLg0KPj4+ PiANCj4+Pj4gLUdhYm9yDQo+Pj4+IA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+cGF3cyBtYWlsaW5nIGxpc3QNCj5wYXdzQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5wYXdzIG1haWxpbmcgbGlzdA0K PnBhd3NAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bh d3MNCg0K From vchen@google.com Mon Aug 13 15:04:36 2012 Return-Path: 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 9E2A921F86B4 for ; Mon, 13 Aug 2012 15:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHYnnjXCtLSx for ; Mon, 13 Aug 2012 15:04:35 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 843D121F86B3 for ; Mon, 13 Aug 2012 15:04:35 -0700 (PDT) Received: by qcac10 with SMTP id c10so3099196qca.31 for ; Mon, 13 Aug 2012 15:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=9stek0WhTODZhqhGVyUs33xGEBkrjpKOiVjZXy/+2YY=; b=YvQYPR+lO50evh0AFIaKq7DbUxuV4BBs9XUoU482O7fjACyPhSrD+SpX6SgWBVvl02 4Y9c3ueTMM0h9+W4caKTQEBhM8h2fKY9cyFAgJ7OjUjHaHziJr7qcp/9ZZER3M/1AOY6 M9a3QFq0QZc6eXPfUBsHBkzi3LkQg1vvVrkPO+nnLJAwDZ6+dqEUH7AdSmifaKACQOUY lY8ZOa5uGv6egKfKOdJkJxrfmwY6qUrAaNAAvoPr+3CwUYCLPsNSL2Nm8Hf7aYCCYzet S++GmPnskwUktFSeotoJGeFJmlOLr9EVUMP1do4uZ8jdZSOC4PrVXibuLvEIqQmysex0 UvmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=9stek0WhTODZhqhGVyUs33xGEBkrjpKOiVjZXy/+2YY=; b=Or236CIuck4o7oHw4Ei1FFBeFY6KlF3CYgWVycSWiDgjEjwf9hlEvnRGismC2X35Nf oyhd6jRI81n43qMHWMtn/YkRPLQ/AnHVqkh/zkxs8BF0FULpsdZg6cXkRELoUO/Mp/8l 4Q22wTlCOO2qssLw8wCYvaPeE3m7g545XRjHo0qBWE/NsbFOyophU5KFDVSwSaOuboOX wrMjRAgUN8iIPAtAx3rioB/wocnOkBoym9qHTz9v+YzqPpCRfODTR9xeB6T/K0LGPs2z Rwtj5L+SXZRx8VvmqDvZ0FUi3mKifmAZ5TeTU27oLLdCZSfadlyh2J1X5NjzQffCeXlf DBRg== Received: by 10.224.10.71 with SMTP id o7mr3074211qao.13.1344895474942; Mon, 13 Aug 2012 15:04:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.10.71 with SMTP id o7mr3074178qao.13.1344895474692; Mon, 13 Aug 2012 15:04:34 -0700 (PDT) Received: by 10.229.64.149 with HTTP; Mon, 13 Aug 2012 15:04:34 -0700 (PDT) In-Reply-To: References: <55A5A9A87506CB4BA580BF9D531957DA690227B6@STNTEXCH01.cis.neustar.com> Date: Mon, 13 Aug 2012 15:04:34 -0700 Message-ID: From: Vincent Chen To: Peter Stanforth Content-Type: multipart/alternative; boundary=14dae93995f90773b204c72ce12e X-System-Of-Record: true X-Gm-Message-State: ALoCoQkWa+jCAw/+Ib4xRFywlnE9xYh498/HGhf2clA3Ai/OWD9EqTcOc1qZiKdHtTA1urrgDfTgbQcLNMHgDBytd/n8e7A+Ui+HQMz+sVnZZe4/RJPl9YTXgN8uiJBO80OUc+kPm1d56PiU56BUlgsTTcBDoQcDfLL+IeSkfuGHYrz0guFapYWweRXgCKEO95KRlgH4jsMq Cc: "paws@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 22:04:36 -0000 --14dae93995f90773b204c72ce12e Content-Type: text/plain; charset=ISO-8859-1 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) 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 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" > 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] > >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time > >To: Teco Boot; Benjamin A.Rolfe > >Cc: 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" 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 > >>>> > >>>> 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 > >>>> > >>>> Teco > >>>> _______________________________________________ > >>>> paws mailing list > >>>> paws@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/paws > >>>> > >>> > >>> _______________________________________________ > >>> paws mailing list > >>> paws@ietf.org > >>> https://www.ietf.org/mailman/listinfo/paws > >> > >>_______________________________________________ > >>paws mailing list > >>paws@ietf.org > >>https://www.ietf.org/mailman/listinfo/paws > > > >_______________________________________________ > >paws mailing list > >paws@ietf.org > >https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- -vince --14dae93995f90773b204c72ce12e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
XML vs JSON

Between XML and JSON, JSON messag= es are more compact and easier to process (parsing, synthesis). As clarific= ation, JSON does not require JavaScript or a Browser. It is a text-based re= presentation 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) and seem to be reasonab= ly light weight.

Timestamps

As for timestamp sp= ecifications, should we consider just using seconds since the UNIX Epoch (1= 970-01-01T00:00:00Z)? This would eliminate the need for datetime-string par= sing on devices, assuming devices already have native libraries that provid= e time in this format. Is that a valid assumption? Of course, this is less = human-readable....


On Mon, Aug 1= 3, 2012 at 6:49 AM, Peter Stanforth <peter@spectrumbridge.com&g= t; wrote:
Whenever we built mobile devices we never de= alt 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> wrote:

>Our experience in the IETF over many years is that economizing message<= br> >size and compromising utility and security in search of efficiency of >implementation on small devices is a poor trade off. =A0I am not advoca= ting
>being wasteful of resources, but I don't think we should seriously<= br> >consider the overhead of XML or json to be significant.
>
>Assuming a json library can be loaded on a small device is reasonable.<= br> >
>Brian (as individual)
>
>
>
> -----Original Message-----
>From: =A0Peter Stanforth [mailto:peter@spectrumbridge.com]
>Sent: =A0Saturday, August 11, 2012 07:13 AM Eastern Standard Time
>To: =A0 =A0Teco Boot; Benjamin A.Rolfe
>Cc: =A0 =A0paws@ietf.org
>Subject: =A0 =A0 =A0 Re: [paws] XML schema versus JSON, vCard & iCa= l
>
>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> 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 re= sources,
>>>such as embedded devices in what are now popularly called "= ;M2M"
>>>applications. =A0A lot of these devices could use IP all the en= d to end,
>>>but may have a very compact, simple stack and applications (i.e= . =A0no
>>>browser). =A0Is JSON typically implemented when there is no bro= wser?
>>>Would it be hard to do in a resource constrained device (i.e. w= here we
>>>talk about memory size in Kilo-bytes still).
>>
>>In use cases and requirements document, there are no requirements f= or
>>protocol performance. I guess OS/IP/TCP/TLS code size supersedes ne= eds
>>for JSON or XML.
>>
>>Same for timing: TCP/TLS connection setup will take more than the P= AWS
>>message exchange, I think. This may be of importance when using sat= com
>>links.
>>
>>Because PAWS runs between master and database, over core network, >>performance is not our primary concern. But as always, it is good t= o 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 JavaScrip= t Object Notation
>>>>(JSON) Representation for vCard"?
>>>> http://tools.ietf.org/html/draft-bhat-vcarddav-j= son-00
>>>>
>>>> On valid times: can we use same format as certificates? Th= ey have
>>>>similar simple requirements: valid notBefore& =A0notAft= er.
>>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
>>>>
>>>> Teco
>>>> _______________________________________________
>>>> paws mailing list
>>>> paws@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>
>>>
>>> _______________________________________________
>>> paws mailing list
>>> paws@ietf.org
>>> https://www.ietf.org/mailman/listinfo/paws
>>
>>_______________________________________________
>>paws mailing list
>>paws@ietf.org
>>https://www.ietf.org/mailman/listinfo/paws
>
>_______________________________________________
>paws mailing list
>paws@ietf.org
>https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws



--
= -vince
--14dae93995f90773b204c72ce12e-- From brian.rosen@neustar.biz Mon Aug 13 15:14:14 2012 Return-Path: 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 34F9F21F870B for ; Mon, 13 Aug 2012 15:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.834 X-Spam-Level: X-Spam-Status: No, score=-5.834 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gntfvw0woEVn for ; Mon, 13 Aug 2012 15:14:13 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3058B21F8705 for ; Mon, 13 Aug 2012 15:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1344896318; x=1660249361; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=lrOkvxbCj8O7cQY7cisxl n2QAsIoWKPReZ/MTBvv0xk=; b=LxgUCj/0CvXRzoh90TPY6nge3BzAOBHSKuk/B IIjQ2zYUhQ8sMLbCPgj0bMWqgnOa+bTQmW5YXBMlStXeWD2BQ== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.13027627; Mon, 13 Aug 2012 18:18:37 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 13 Aug 2012 18:14:03 -0400 From: "Rosen, Brian" To: 'Vincent Chen' , 'Peter Stanforth' Date: Mon, 13 Aug 2012 18:14:02 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6IeIIEEYccaRsaWXsg5JnqSHQAAU/5D Message-ID: <55A5A9A87506CB4BA580BF9D531957DA690227BD@STNTEXCH01.cis.neustar.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: 7Vc/XUocUyfJvvKxrAnJsw== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'paws@ietf.org'" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 22:14:14 -0000 anNvbiBpcyBva2F5IHdpdGggbWUuICAKSSdkIHByZWZlciBhbiBJU08gdGltZSBzdGFtcCByYXRo ZXIgdGhhbiBhIHRpbWUgaW4gc2Vjb25kcyBzaW5jZSBlcG9jaC4gIEl0J3MgdmVyeSBlYXN5IHRv IHBhcnNlLCBhbmQgaXRzIHNpbXBsZXIgdG8gdXNlIGFuZCBkZWJ1Zy4gIERvbid0IGNhcmUgYSB3 aG9sZSBsb3QgYWJvdXQgdGhhdAoKQnJpYW4gPGFzIGluZGl2aWR1YWw+CgoNCg0KIC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAJVmluY2VudCBDaGVuIFttYWlsdG86dmNoZW5AZ29v Z2xlLmNvbV0NClNlbnQ6CU1vbmRheSwgQXVndXN0IDEzLCAyMDEyIDA2OjA0IFBNIEVhc3Rlcm4g U3RhbmRhcmQgVGltZQ0KVG86CVBldGVyIFN0YW5mb3J0aA0KQ2M6CVJvc2VuLCBCcmlhbjsgVGVj byBCb290OyBCZW5qYW1pbiBBLlJvbGZlOyBwYXdzQGlldGYub3JnDQpTdWJqZWN0OglSZTogW3Bh d3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJkICYgaUNhbA0KDQpYTUwgdnMgSlNPTg0K DQpCZXR3ZWVuIFhNTCBhbmQgSlNPTiwgSlNPTiBtZXNzYWdlcyBhcmUgbW9yZSBjb21wYWN0IGFu ZCBlYXNpZXIgdG8gcHJvY2VzcyAocGFyc2luZywgc3ludGhlc2lzKS4gQXMgY2xhcmlmaWNhdGlv biwgSlNPTiBkb2VzIG5vdCByZXF1aXJlIEphdmFTY3JpcHQgb3IgYSBCcm93c2VyLiBJdCBpcyBh IHRleHQtYmFzZWQgcmVwcmVzZW50YXRpb24gb2YgZGF0YSB0aGF0IGlzIGxhbmd1YWdlIGluZGVw ZW5kZW50LCB5ZXQgd2VsbC1tYXRjaGVkIHRvIGFsbCBtYWpvciBsYW5ndWFnZXMuIEpTT04taGFu ZGxpbmcgbGlicmFyaWVzIGV4aXN0IGZvciBudW1lcm91cyBsYW5ndWFnZXMgKHNlZSBvZiBodHRw Oi8vanNvbi5vcmcpIGFuZCBzZWVtIHRvIGJlIHJlYXNvbmFibHkgbGlnaHQgd2VpZ2h0Lg0KDQpU aW1lc3RhbXBzDQoNCkFzIGZvciB0aW1lc3RhbXAgc3BlY2lmaWNhdGlvbnMsIHNob3VsZCB3ZSBj b25zaWRlciBqdXN0IHVzaW5nIHNlY29uZHMgc2luY2UgdGhlIFVOSVggRXBvY2ggKDE5NzAtMDEt MDFUMDA6MDA6MDBaKT8gVGhpcyB3b3VsZCBlbGltaW5hdGUgdGhlIG5lZWQgZm9yIGRhdGV0aW1l LXN0cmluZyBwYXJzaW5nIG9uIGRldmljZXMsIGFzc3VtaW5nIGRldmljZXMgYWxyZWFkeSBoYXZl IG5hdGl2ZSBsaWJyYXJpZXMgdGhhdCBwcm92aWRlIHRpbWUgaW4gdGhpcyBmb3JtYXQuIElzIHRo YXQgYSB2YWxpZCBhc3N1bXB0aW9uPyBPZiBjb3Vyc2UsIHRoaXMgaXMgbGVzcyBodW1hbi1yZWFk YWJsZS4uLi4NCg0KDQpPbiBNb24sIEF1ZyAxMywgMjAxMiBhdCA2OjQ5IEFNLCBQZXRlciBTdGFu Zm9ydGggPHBldGVyQHNwZWN0cnVtYnJpZGdlLmNvbT4gd3JvdGU6DQoNCg0KCVdoZW5ldmVyIHdl IGJ1aWx0IG1vYmlsZSBkZXZpY2VzIHdlIG5ldmVyIGRlYWx0IHdpdGggSUVURiwgaW4gb3VyIHNl bnNvcg0KCWRheXMgZXZlbiBhbiBJUCBzdGFjayB3YXMgYSBjaGFsbGVuZ2Usc28gSSB3b3VsZCBk ZWZlciB0byB0aGUgZGV2aWNlIGd1eXMNCglvbiB0aGF0IG9uZS4NCgkNCglPbiBNb25BdWcvMTMv MTIgTW9uIEF1ZyAxMywgOTozMCBBTSwgIlJvc2VuLCBCcmlhbiINCgkNCgk8QnJpYW4uUm9zZW5A bmV1c3Rhci5iaXo+IHdyb3RlOg0KCQ0KCT5PdXIgZXhwZXJpZW5jZSBpbiB0aGUgSUVURiBvdmVy IG1hbnkgeWVhcnMgaXMgdGhhdCBlY29ub21pemluZyBtZXNzYWdlDQoJPnNpemUgYW5kIGNvbXBy b21pc2luZyB1dGlsaXR5IGFuZCBzZWN1cml0eSBpbiBzZWFyY2ggb2YgZWZmaWNpZW5jeSBvZg0K CT5pbXBsZW1lbnRhdGlvbiBvbiBzbWFsbCBkZXZpY2VzIGlzIGEgcG9vciB0cmFkZSBvZmYuICBJ IGFtIG5vdCBhZHZvY2F0aW5nDQoJPmJlaW5nIHdhc3RlZnVsIG9mIHJlc291cmNlcywgYnV0IEkg ZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIHNlcmlvdXNseQ0KCT5jb25zaWRlciB0aGUgb3ZlcmhlYWQg b2YgWE1MIG9yIGpzb24gdG8gYmUgc2lnbmlmaWNhbnQuDQoJPg0KCT5Bc3N1bWluZyBhIGpzb24g bGlicmFyeSBjYW4gYmUgbG9hZGVkIG9uIGEgc21hbGwgZGV2aWNlIGlzIHJlYXNvbmFibGUuDQoJ Pg0KCT5CcmlhbiAoYXMgaW5kaXZpZHVhbCkNCgk+DQoJPg0KCT4NCgk+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQoJPkZyb206ICBQZXRlciBTdGFuZm9ydGggW21haWx0bzpwZXRlckBzcGVj dHJ1bWJyaWRnZS5jb21dDQoJPlNlbnQ6ICBTYXR1cmRheSwgQXVndXN0IDExLCAyMDEyIDA3OjEz IEFNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KCT5UbzogICAgVGVjbyBCb290OyBCZW5qYW1pbiBB LlJvbGZlDQoJPkNjOiAgICBwYXdzQGlldGYub3JnDQoJPlN1YmplY3Q6ICAgICAgIFJlOiBbcGF3 c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJiBpQ2FsDQoJPg0KCT5Ob3QgYWxsIG1h c3RlcnMgcnVuIG92ZXIgdGhlIGNvcmUgbmV0d29yay4NCgk+U29tZSBvZiB0aGUgVXNlIGNhc2Vz IGhhdmUgYSBtYXN0ZXIgdGFsa2luZyB0byBhbm90aGVyIE9UQQ0KCT5XZSBzaG91bGQgbm90IGFz c3VtZSB0aGF0IGFsbCBNYXN0ZXJzIGFyZSBhdHRhY2hlZCB0byB1dGlsaXR5IHBvd2VyIHNvIHdl DQoJPnNob3VsZCBiZSBzeW1wYXRoZXRpYyB0byBwcm9jZXNzaW5nIGVuZXJneSB1c2UgYWxzby4N Cgk+DQoJPk9uIFNhdEF1Zy8xMS8xMiBTYXQgQXVnIDExLCA1OjMwIEFNLCAiVGVjbyBCb290IiA8 dGVjb0BpbmYtbmV0Lm5sPiB3cm90ZToNCgk+DQoJPj4NCgk+Pk9wIDEwIGF1Zy4gMjAxMiwgb20g MTg6MTAgaGVlZnQgQmVuamFtaW4gQS4gUm9sZmUgaGV0IHZvbGdlbmRlDQoJPj5nZXNjaHJldmVu Og0KCT4+DQoJPj4+IENvbXBhY3RuZXNzIG9mIG1lc3NhZ2VzIGlzIGltcG9ydGFudCwgYnV0IGl0 IGlzIGFsc28gaW1wb3J0YW50ICh0byBtZQ0KCT4+PmF0IGxlYXN0KSB0byBiZSByZWFsaXphYmxl IGluIGFuIGltcGxlbWVudGF0aW9uIHdpdGggbGltaXRlZCByZXNvdXJjZXMsDQoJPj4+c3VjaCBh cyBlbWJlZGRlZCBkZXZpY2VzIGluIHdoYXQgYXJlIG5vdyBwb3B1bGFybHkgY2FsbGVkICJNMk0i DQoJPj4+YXBwbGljYXRpb25zLiAgQSBsb3Qgb2YgdGhlc2UgZGV2aWNlcyBjb3VsZCB1c2UgSVAg YWxsIHRoZSBlbmQgdG8gZW5kLA0KCT4+PmJ1dCBtYXkgaGF2ZSBhIHZlcnkgY29tcGFjdCwgc2lt cGxlIHN0YWNrIGFuZCBhcHBsaWNhdGlvbnMgKGkuZS4gIG5vDQoJPj4+YnJvd3NlcikuICBJcyBK U09OIHR5cGljYWxseSBpbXBsZW1lbnRlZCB3aGVuIHRoZXJlIGlzIG5vIGJyb3dzZXI/DQoJPj4+ V291bGQgaXQgYmUgaGFyZCB0byBkbyBpbiBhIHJlc291cmNlIGNvbnN0cmFpbmVkIGRldmljZSAo aS5lLiB3aGVyZSB3ZQ0KCT4+PnRhbGsgYWJvdXQgbWVtb3J5IHNpemUgaW4gS2lsby1ieXRlcyBz dGlsbCkuDQoJPj4NCgk+PkluIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGRvY3VtZW50LCB0 aGVyZSBhcmUgbm8gcmVxdWlyZW1lbnRzIGZvcg0KCT4+cHJvdG9jb2wgcGVyZm9ybWFuY2UuIEkg Z3Vlc3MgT1MvSVAvVENQL1RMUyBjb2RlIHNpemUgc3VwZXJzZWRlcyBuZWVkcw0KCT4+Zm9yIEpT T04gb3IgWE1MLg0KCT4+DQoJPj5TYW1lIGZvciB0aW1pbmc6IFRDUC9UTFMgY29ubmVjdGlvbiBz ZXR1cCB3aWxsIHRha2UgbW9yZSB0aGFuIHRoZSBQQVdTDQoJPj5tZXNzYWdlIGV4Y2hhbmdlLCBJ IHRoaW5rLiBUaGlzIG1heSBiZSBvZiBpbXBvcnRhbmNlIHdoZW4gdXNpbmcgc2F0Y29tDQoJPj5s aW5rcy4NCgk+Pg0KCT4+QmVjYXVzZSBQQVdTIHJ1bnMgYmV0d2VlbiBtYXN0ZXIgYW5kIGRhdGFi YXNlLCBvdmVyIGNvcmUgbmV0d29yaywNCgk+PnBlcmZvcm1hbmNlIGlzIG5vdCBvdXIgcHJpbWFy eSBjb25jZXJuLiBCdXQgYXMgYWx3YXlzLCBpdCBpcyBnb29kIHRvIGtlZXANCgk+PmFuIGV5ZSBv biBlZmZpY2llbmN5Lg0KCT4+DQoJPj5UZWNvDQoJPj4NCgk+Pj4gVGhhbmtzDQoJPj4+IEJlbg0K CT4+Pg0KCT4+Pg0KCT4+Pj4gV2UgaGFkIGEgZGlzY3Vzc2lvbiBvbiBYTUwgdnMuIEpTT04uIEkg cHJlZmVyIHRoZSBvbmUgd2l0aCBtb3N0DQoJPj4+PmNvbXBhY3QgbWVzc2FnZXMuDQoJPj4+Pg0K CT4+Pj4gT24gdkNhcmQgYW5kIEpTT046IHdoYXQgaXMgdGhlIHN0YXR1cyBvZiAiQSBKYXZhU2Ny aXB0IE9iamVjdCBOb3RhdGlvbg0KCT4+Pj4oSlNPTikgUmVwcmVzZW50YXRpb24gZm9yIHZDYXJk Ij8NCgk+Pj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJoYXQtdmNhcmRkYXYt anNvbi0wMA0KCT4+Pj4NCgk+Pj4+IE9uIHZhbGlkIHRpbWVzOiBjYW4gd2UgdXNlIHNhbWUgZm9y bWF0IGFzIGNlcnRpZmljYXRlcz8gVGhleSBoYXZlDQoJPj4+PnNpbWlsYXIgc2ltcGxlIHJlcXVp cmVtZW50czogdmFsaWQgbm90QmVmb3JlJiAgbm90QWZ0ZXIuDQoJPj4+PiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmMzMjgwI3NlY3Rpb24tNC4xLjIuNQ0KCT4+Pj4NCgk+Pj4+IFRlY28N Cgk+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJ Pj4+PiBwYXdzIG1haWxpbmcgbGlzdA0KCT4+Pj4gcGF3c0BpZXRmLm9yZw0KCT4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoJPj4+Pg0KCT4+Pg0KCT4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCT4+PiBwYXdz IG1haWxpbmcgbGlzdA0KCT4+PiBwYXdzQGlldGYub3JnDQoJPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KCT4+DQoJPj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KCT4+cGF3cyBtYWlsaW5nIGxpc3QNCgk+PnBhd3NA aWV0Zi5vcmcNCgk+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0K CT4NCgk+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+ cGF3cyBtYWlsaW5nIGxpc3QNCgk+cGF3c0BpZXRmLm9yZw0KCT5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KCXBhd3MgbWFpbGluZyBsaXN0DQoJcGF3c0BpZXRmLm9yZw0K CWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KCQ0KDQoNCg0KDQot LSANCi12aW5jZQ0KDQo= From paul@marvell.com Mon Aug 13 16:33:53 2012 Return-Path: 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 A77DE21F8694 for ; Mon, 13 Aug 2012 16:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcxtaZf200wr for ; Mon, 13 Aug 2012 16:33:51 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 87FDA21F8692 for ; Mon, 13 Aug 2012 16:33:50 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKUCmO3JIpNQV8HRPE3wKceRIWaMZt93Qu@postini.com; Mon, 13 Aug 2012 16:33:50 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 13 Aug 2012 16:33:47 -0700 From: Paul Lambert To: Vincent Chen , Peter Stanforth Date: Mon, 13 Aug 2012 16:33:52 -0700 Thread-Topic: YAML -> was -> RE: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6M19r7UFBQSSXW21z0lC+MwHQAC5eeQ Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D015E43DFA1F@SC-VEXCH2.marvell.com> References: <55A5A9A87506CB4BA580BF9D531957DA690227B6@STNTEXCH01.cis.neustar.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7BAC95F5A7E67643AAFB2C31BEE662D015E43DFA1FSCVEXCH2marve_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: [paws] YAML -> was -> RE: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 23:33:53 -0000 --_000_7BAC95F5A7E67643AAFB2C31BEE662D015E43DFA1FSCVEXCH2marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable XML vs JSON vs YAML YAML is structure compatible with JSON and is more readable. It uses colon= delimited tags with indentation instead of brackets. It's a superset of JS= ON and a subset could be used effectively to provide direct JSON-to-YAML co= rrespondence. http://www.kuro5hin.org/story/2004/10/29/14225/062 A binary mapping can be defined for any YAML set of tags if efficiency is i= mportant. I find YAML much more readable Paul Paul A. Lambert | Marvell | +1-650-787-9141 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vin= cent Chen Sent: Monday, August 13, 2012 3:05 PM To: Peter Stanforth Cc: 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org) and seem to be reasona= bly light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > 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" > 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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 >>>> >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_7BAC95F5A7E67643AAFB2C31BEE662D015E43DFA1FSCVEXCH2marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

XML vs JSON= vs YAML

 

YAML is structure compatible with JSON a= nd is more readable.  It uses colon delimited tags with indentation in= stead of brackets. It’s a superset of JSON and a subset could be used= effectively to provide direct JSON-to-YAML correspondence.

 

h= ttp://www.kuro5hin.org/story/2004/10/29/14225/062

=

 

= A binary mapping can be defined for any YAML set of tags if efficiency= is important.

 

I find YAML much more readable

 

Paul

=  

 

Paul A. Lambert | Marvell | +1-650-787-9= 141

&nb= sp;

From: paws-boun= ces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Che= n
Sent: Monday, August 13, 2012 3:05 PM
To: Peter Stanf= orth
Cc: paws@ietf.org
Subject: Re: [paws] XML schema v= ersus JSON, vCard & iCal

 

XML vs JSON

 

Between XML and JSON, JSON messages are more compact and ea= sier to process (parsing, synthesis). As clarification, JSON does not requi= re JavaScript or a Browser. It is a text-based representation of data that = is language independent, yet well-matched to all major languages. JSON-hand= ling libraries exist for numerous languages (see of http://json.org) and seem to be reasonably light weight.

 

Timestamps

 

As for timestamp specific= ations, should we consider just using seconds since the UNIX Epoch (1970-01= -01T00:00:00Z)? This would eliminate the need for datetime-string parsing o= n 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 1= 3, 2012 at 6:49 AM, Peter Stanforth <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 woul= d defer to the device guys
on that one.

On MonAug/13/12 Mon Aug 1= 3, 9:30 AM, "Rosen, Brian"

<Brian.Rosen@neustar.b= iz> 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, b= ut I don't think we should seriously
>consider the overhead of XML or= json to be significant.
>
>Assuming a json library can be load= ed on a small device is reasonable.
>
>Brian (as individual)>
>
>
> -----Original Message-----
>From:  = ;Peter Stanforth [mailto:peter@= spectrumbridge.com]
>Sent:  Saturday, August 11, 2012 07:13 = AM Eastern Standard Time
>To:    Teco Boot; Benjamin A.Rolf= e
>Cc:    paws@ietf.org
>Subject:       Re: [paws] XML schema versus JSON, v= Card & 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
&= gt;should be sympathetic to processing energy use also.
>
>On S= atAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <teco@inf-net.nl> wrote:
>
>>
&g= t;>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe het volgende
>= ;>geschreven:
>>
>>> Compactness of messages is imp= ortant, but it is also important (to me
>>>at least) to be real= izable in an implementation with limited resources,
>>>such as = embedded devices in what are now popularly called "M2M"
>&g= t;>applications.  A lot of these devices could use IP all the end t= o end,
>>>but may have a very compact, simple stack and applica= tions (i.e.  no
>>>browser).  Is JSON typically imple= mented when there is no browser?
>>>Would it be hard to do in a= resource constrained device (i.e. where we
>>>talk about memor= y size in Kilo-bytes still).
>>
>>In use cases and requir= ements document, there are no requirements for
>>protocol performa= nce. I guess OS/IP/TCP/TLS code size supersedes needs
>>for JSON o= r XML.
>>
>>Same for timing: TCP/TLS connection setup wil= l take more than the PAWS
>>message exchange, I think. This may be= of importance when using satcom
>>links.
>>
>>B= ecause PAWS runs between master and database, over core network,
>>= ;performance is not our primary concern. But as always, it is good to keep<= br>>>an eye on efficiency.
>>
>>Teco
>>>>> Thanks
>>> Ben
>>>
>>>>>>> We had a discussion on XML vs. JSON. I prefer the one wit= h 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
>>>>
>>>> On valid times: can we use s= ame format as certificates? They have
>>>>similar simple req= uirements: valid notBefore&  notAfter.
>>>> h= ttp://tools.ietf.org/html/rfc3280#section-4.1.2.5
>>>>>>>> Teco
>>>> _______________________________= ________________
>>>> paws mailing list
>>>> = paws@ietf.org
>>>> https:= //www.ietf.org/mailman/listinfo/paws
>>>>
>>>= ;
>>> _______________________________________________
>&g= t;> paws mailing list
>>> p= aws@ietf.org
>>> https://www.ietf.org/mailman/listinfo/paws
>>
>>_______________________________________________>>paws mailing list
>>paw= s@ietf.org
>>https://www.ietf.org/mailman/listinfo/paws
&= gt;
>_______________________________________________
>paws mail= ing list
>paws@ietf.org
><= a href=3D"https://www.ietf.org/mailman/listinfo/paws" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/paws

________________________= _______________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws



=

 

--
-vince

= --_000_7BAC95F5A7E67643AAFB2C31BEE662D015E43DFA1FSCVEXCH2marve_-- From ben@blindcreek.com Tue Aug 14 09:29:42 2012 Return-Path: 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 D672021F8709 for ; Tue, 14 Aug 2012 09:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcVXPDS9MyYZ for ; Tue, 14 Aug 2012 09:29:39 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id 911BC21F8772 for ; Tue, 14 Aug 2012 09:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=W3MXSX5shp3AqbhHbwVgRubPDmZAAC4dkd35uwVmXxw=; b=lQUBjE2FDZbzorK7/GnboNJLo9ugPh9ki7Qt46jweMsxR/CFGULFZHWuseA+uitMncehUlJ0BRSGbWyXNcdn1kSF8D6p8E8QnQhQ+/rtFQHLDIjmyoyB1P1dyeGn8BVc; Received: from [64.74.213.174] (port=56037 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1T1Jzq-0004lh-3g for paws@ietf.org; Tue, 14 Aug 2012 11:29:34 -0500 Message-ID: <502A7CEE.6090200@blindcreek.com> Date: Tue, 14 Aug 2012 09:29:34 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: paws@ietf.org References: <55A5A9A87506CB4BA580BF9D531957DA690227B6@STNTEXCH01.cis.neustar.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 16:29:42 -0000 Thanks Vincent, that's what i didn't know (well one thing from a vast set of things I don't know, but the one thing most relevant tot his thread :-).

Thanks Brian, that's what I was looking for.  We're seeing scaled down IP stacks fitting compactly into embedded devices such as sensors more commonly, but it is certainly not assured.  When I say "scaled down", essentially you figure out what the application needs and leave all the rest of the protocol out. That works for devices that won't change what the application layer needs from the protocol. I think some M2M applications could use this model, with a scaled down IP stack supporting PAWS.  This is the case that is interesting on this list I would expect.

Some M2M applications will not support IP to the endopoints, so an intermediate will get involved.  Not much concern to the purpose of this list, but explains somewhat my unique perspective.

hope that helps.

Ben (as a unique individual ;0).


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) 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> 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> 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]
>Sent:  Saturday, August 11, 2012 07:13 AM Eastern Standard Time
>To:    Teco Boot; Benjamin A.Rolfe
>Cc:    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> 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
>>>>
>>>> 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
>>>>
>>>> Teco
>>>> _______________________________________________
>>>> paws mailing list
>>>> paws@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>
>>>
>>> _______________________________________________
>>> paws mailing list
>>> paws@ietf.org
>>> https://www.ietf.org/mailman/listinfo/paws
>>
>>_______________________________________________
>>paws mailing list
>>paws@ietf.org
>>https://www.ietf.org/mailman/listinfo/paws
>
>_______________________________________________
>paws mailing list
>paws@ietf.org
>https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws



--
-vince

From brian.rosen@neustar.biz Tue Aug 14 09:40:46 2012 Return-Path: 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 AD50F21F862A for ; Tue, 14 Aug 2012 09:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.818 X-Spam-Level: X-Spam-Status: No, score=-5.818 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsczCaBqKmFJ for ; Tue, 14 Aug 2012 09:40:45 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8974521F8623 for ; Tue, 14 Aug 2012 09:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1344962554; x=1660313963; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=mnlbliY+uwCTafGqYe70TBZOZAW+jda52+0lNbhNq6g=; b=TO+h1XERBoTDyFb7WepDa2B+xsGzT4cA3JHhnPxwvVDM7lPTKn91WO3scbGAmo p2z8s1JW/jDBvjpvFIhpbe4g== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.12622482; Tue, 14 Aug 2012 12:42:33 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Tue, 14 Aug 2012 12:40:36 -0400 From: "Rosen, Brian" To: "Benjamin A. Rolfe" , "paws@ietf.org" Date: Tue, 14 Aug 2012 12:40:34 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac16O4eYxzc5ccjTTuS22jbS0KW/3A== Message-ID: In-Reply-To: <502A7CEE.6090200@blindcreek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: GrgllQYsZNRLW8E2Zc1C2g== Content-Type: multipart/alternative; boundary="_000_CC4FF59D9578brianrosenneustarbiz_" MIME-Version: 1.0 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 16:40:46 -0000 --_000_CC4FF59D9578brianrosenneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I said this in the meeting at IETF84, but I'll repeat it on the list, becau= se we have quite a few members who aren't IETF regulars. I am a co-chair. I also am interested in the subject, have some relevant e= xperience, and wish to participate in the creation of the protocol independ= ently of my role as co-chair. When I send a message to the list, it's useful for readers to know if I'm s= peaking as chair, or just as an interested participant. When I write "as i= ndividual", it means that it's just a personal view, and not a chair positi= on. As an individual participant, I have no special status. I'm just one = voice among many. If I specifically say "as chair", then I'm acting in my= co-chair role, and you should treat the message that way. Co-chairs have = limited powers in the IETF, but sometimes, chair assertion is necessary to = make the work group function smoothly. Most of you aren't co-chairs (Gabor of course, is), so you don't have to id= entify yourself in a role. I do. Brian From: "Benjamin A. Rolfe" > Date: Tue, 14 Aug 2012 12:29:34 -0400 To: "paws@ietf.org" > Subject: Re: [paws] XML schema versus JSON, vCard & iCal Thanks Vincent, that's what i didn't know (well one thing from a vast set o= f things I don't know, but the one thing most relevant tot his thread :-). Thanks Brian, that's what I was looking for. We're seeing scaled down IP s= tacks fitting compactly into embedded devices such as sensors more commonly= , but it is certainly not assured. When I say "scaled down", essentially y= ou figure out what the application needs and leave all the rest of the prot= ocol out. That works for devices that won't change what the application lay= er needs from the protocol. I think some M2M applications could use this mo= del, with a scaled down IP stack supporting PAWS. This is the case that is= interesting on this list I would expect. Some M2M applications will not support IP to the endopoints, so an intermed= iate will get involved. Not much concern to the purpose of this list, but = explains somewhat my unique perspective. hope that helps. Ben (as a unique individual ;0). 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org) and seem to be reasona= bly light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > 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" > 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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 >>>> >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_CC4FF59D9578brianrosenneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I said this in the meeti= ng at IETF84, but I'll repeat it on the list, because we have quite a few m= embers who aren't IETF regulars.

I am a co-chair. =  I also am interested in the subject, have some relevant experience, a= nd wish to participate in the creation of the protocol independently of my = role as co-chair.

When I send a message to the lis= t, it's useful for readers to know if I'm speaking as chair, or just as an = interested participant.  When I write "as individual", it means that i= t's just a personal view, and not a chair position.  As an individual = participant, I have no special status.  I'm just one voice among many.=   If I specifically say "as chair", then I'm acting in my co-chair ro= le, and you should treat the message that way.  Co-chairs have limited= powers in the IETF, but sometimes, chair assertion is necessary to make th= e work group function smoothly.

Most of you aren't= co-chairs (Gabor of course, is), so you don't have to identify yourself in= a role.  I do.

Brian

From: "Benjamin A. Rolfe" <ben@blindcreek.com>
Date: Tue, 14 Aug 2012 12:29:34 -0400
To: "paws@ietf.org" <paws@ietf.org= >
Subject: Re: [paws] XML sc= hema versus JSON, vCard & iCal

=20 =20
Thanks Vincent, that's what i didn't know (well one thing from a vast set of things I don't know, but the one thing most relevant tot his thread :-).

Thanks Brian, that's what I was looking for.  We're seeing scaled down IP stacks fitting compactly into embedded devices such as sensors more commonly, but it is certainly not assured.  When I sa= y "scaled down", essentially you figure out what the application needs and leave all the rest of the protocol out. That works for devices that won't change what the application layer needs from the protocol. I think some M2M applications could use this model, with a scaled down IP stack supporting PAWS.  This is the case that is interesting on this list I would expect.

Some M2M applications will not support IP to the endopoints, so an intermediate will get involved.  Not much concern to the purpose o= f this list, but explains somewhat my unique perspective.

hope that helps.

Ben (as a unique individual ;0).


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) 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> 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> 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= ]
>Sent:  Saturday, August 11, 2012 07:13 AM Eastern Standard Time
>To:    Teco Boot; Benjamin A.Rolfe
>Cc:    paws@ietf.org
>Subject:       Re: [paws] XML schema ver= sus 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> 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 coul= d 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
>>>>
>>>> On valid times: can we use same format as certificates? They have
>>>>similar simple requirements: valid notBefore&  notAfter.
>>>> http://tool= s.ietf.org/html/rfc3280#section-4.1.2.5
>>>>
>>>> Teco
>>>> _______________________________________________
>>>> paws mailing list
>>>> paws@ietf.org
>>>> https://www.ietf.or= g/mailman/listinfo/paws
>>>>
>>>
>>> _______________________________________________
>>> paws mailing list
>>> paws@ietf.org
>>> https://www.ietf.org/ma= ilman/listinfo/paws
>>
>>_______________________________________________
= >>paws mailing list
>>paws@ietf.org
>>https://www.ietf.org/mailman= /listinfo/paws
>
>_______________________________________________
>paws mailing list
>paws@ietf.org
>https://www.ietf.org/mailman/lis= tinfo/paws

_______________________________________________
paws mailing list
p= aws@ietf.org
https://www.ietf.org/mailman/listinf= o/paws



--
-vince

--_000_CC4FF59D9578brianrosenneustarbiz_-- From Gabor.Bajko@nokia.com Thu Aug 16 12:06:05 2012 Return-Path: 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 5F9DE21F856F for ; Thu, 16 Aug 2012 12:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 ARbqhZbOgRiB for ; Thu, 16 Aug 2012 12:06:04 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id CC7E221F8574 for ; Thu, 16 Aug 2012 12:05:58 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7GJ5sVg016733 for ; Thu, 16 Aug 2012 22:05:56 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Aug 2012 22:06:59 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0283.004; Thu, 16 Aug 2012 21:05:53 +0200 From: To: Thread-Topic: DB discovery [was: RE: [paws] need for DB initialization message] Thread-Index: Ac15gqFNItaZd90nQoOT2JXoMeeCoQABNFzrAJZ8+1A= Date: Thu, 16 Aug 2012 19:05:52 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB416E@008-AM1MPN1-006.mgdnok.nokia.com> References: <55A5A9A87506CB4BA580BF9D531957DA690227B9@STNTEXCH01.cis.neustar.com> In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA690227B9@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 16 Aug 2012 19:06:59.0135 (UTC) FILETIME=[4F9124F0:01CD7BE2] X-Nokia-AV: Clean Subject: Re: [paws] DB discovery [was: RE: need for DB initialization message] X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 19:06:05 -0000 VGhlIGRpc2NvdmVyeSBzZXJ2aWNlIHdvdWxkIG5vdCBuZWNlc3NhcmlseSBiZSBvcGVyYXRlZCBi eSB0aGUgbWFudWZhY3R1cmVyLCBpdCBjb3VsZCBlZyBiZSB0aGUgcmVndWxhdG9yIGl0c2VsZiwg b3IgdGhlIGRiIGFkbWluLiBBRkFJSywgY3VycmVudGx5IHRoZXJlIGlzIG5vIExvU1Qgc2VydmVy IGRpc2NvdmVyeSBtZWNoYW5pc20gc3VwcG9ydGVkIGluIHRoZSBhY2Nlc3MgbmV0d29ya3MsLCB0 aHVzIHdlIG5lZWQgdG8gZG8gc2cgYWJvdXQgaXQgaWYgd2Ugd2FudCB0aGlzIGVjb3N5c3RlbSB0 byB0YWtlIG9mZiBpbiB0aGUgbmVhciBmdXR1cmUuDQpXaGF0IGNvbWVzIHRvIHN1cHBvcnRpbmcg TG9TVCBmb3IgZW1lcmdlbmN5IGNhbGxpbmcgcHVycG9zZXMsIG5vdGUgdGhhdCBXUyBtYXN0ZXIg ZGV2aWNlcyBtYXkgbm90IGJlIHRoZSBvbmVzIG1ha2luZyBlbWVyZ2VuY3kgY2FsbHMsIHRodXMg dGhleSB3b24ndCBjb21lIHdpdGggTG9TVCBzdXBwb3J0Lg0KLSBHYWJvcg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZXh0IFJvc2VuLCBCcmlhbiBbbWFpbHRvOkJyaWFuLlJv c2VuQG5ldXN0YXIuYml6XSANClNlbnQ6IE1vbmRheSwgQXVndXN0IDEzLCAyMDEyIDEyOjEyIFBN DQpUbzogQmFqa28gR2Fib3IgKE5va2lhLUNJQy9TaWxpY29uVmFsbGV5KTsgUGF0aWwgQmFzYXZh cmFqIChOb2tpYS1DSUMvRGFsbGFzKTsgJ3BldGVyLm1jY2FubkBodWF3ZWkuY29tJzsgJ2ptaEBq b2VsaGFscGVybi5jb20nDQpDYzogJ3Bhd3NAaWV0Zi5vcmcnDQpTdWJqZWN0OiBSRTogREIgZGlz Y292ZXJ5IFt3YXM6IFJFOiBbcGF3c10gbmVlZCBmb3IgREIgaW5pdGlhbGl6YXRpb24gbWVzc2Fn ZV0NCg0KVGhlIFUtTkFQVFIgaXMgb25seSBwYXJ0IG9mIExvU1QgZGlzY292ZXJ5LiAgSWYgeW91 IGRvbid0IGxpa2UgaXQsIHlvdXIgb25seSBhbHRlcm5hdGl2ZSBpcyBwcm92aXNpb25pbmcsIGJ1 dCBzb21lIGZvbGtzIHNlZW0gdG8gbGlrZSBwcm92aXNpb25pbmcuICBXZSBoYXZlIGEgd2hvbGUg bG90IG9mIGV4cGVyaWVuY2Ugd2l0aCBzZXJ2aWNlIGRpc2NvdmVyeS4gIFRoZXJlIGFyZSBubyBz aW1wbGUgbWVjaGFuaXNtcyB0aGF0IHdvcmsgZ2xvYmFsbHkgd2l0aG91dCBzdXBwb3J0IGZyb20g c29tZSBraW5kIG9mIGluZnJhc3RydWN0dXJlLiAgVG8gbWUsIHRoZSBub3Rpb24gdGhhdCBhIGRl dmljZSBtYW51ZmFjdHVyZXIgd2lsbCBzdXBwb3J0IGEgZGlzY292ZXJ5IHNlcnZpY2UgZm9yIHRo ZSBsaWZldGltZSBvZiB0aGUgZGV2aWNlIGlzIGxlc3MgbGlrZWx5IGFzIElTUCBzdXBwb3J0IGZv ciBMb1NULCBzaW5jZSB0aGUgbGF0dGVyIHdpbGwgYmUgbmVlZGVkIGZvciBlbWVyZ2VuY3kgY2Fs bGluZy4NCg0KSWYgd2UgbmVlZGVkIHRvIGRvIGEganNvbiBlbmNvZGluZyBvZiBMb1NULCBubyBv bmUgd2lsbCBvYmplY3QuDQoNClRoZSBvbmx5IHN1YnNldCB3ZSBuZWVkIGlzIGEgc2luZ2xlIFVS TiAoYWx0aG91Z2ggeW91IGNvdWxkIGltYWdpbmUgYSBjb3VudHJ5IHNwZWNpZmljIFVSTiksIGFu ZCBubyB2YWxpZGF0aW9uLg0KVGhlIHNlcnZpY2UgYm91bmRhcnkgcGFydCBpcyB2ZXJ5IGhhbmR5 IGZvciBhIG1vYmlsZSBkZXZpY2UgdG8gZGV0ZXJtaW5lIHdoZW4gaXQgaGFzIG1vdmVkIGJleW9u ZCB0aGUgYm91bmRhcnkgc2VydmVkIGJ5IHRoZSBzYW1lIFVSTi4gIFRoaXMgd291bGQgaGFwcGVu IGlmIHlvdSByb2FtZWQgYWNyb3NzIGEgYm9yZGVyLiAgSXQncyBub3QgYSByZXF1aXJlZCBlbGVt ZW50IG9uIHRoZSBzZXJ2ZXIsIGFuZCB0aGUgY2xpZW50IGNhbiBpZ25vcmUgaXQuDQoNCkJyaWFu IDxhcyBpbmRpdmlkdWFsPg0KDQoNCg0KIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiAJR2Fib3IuQmFqa29Abm9raWEuY29tIFttYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tXQ0K U2VudDoJTW9uZGF5LCBBdWd1c3QgMTMsIDIwMTIgMDI6NDYgUE0gRWFzdGVybiBTdGFuZGFyZCBU aW1lDQpUbzoJUm9zZW4sIEJyaWFuOyBCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tOyBwZXRlci5t Y2Nhbm5AaHVhd2VpLmNvbTsgam1oQGpvZWxoYWxwZXJuLmNvbQ0KQ2M6CXBhd3NAaWV0Zi5vcmcN ClN1YmplY3Q6CURCIGRpc2NvdmVyeSBbd2FzOiBSRTogW3Bhd3NdIG5lZWQgZm9yIERCIGluaXRp YWxpemF0aW9uIG1lc3NhZ2VdDQoNCkkgY291bGQgYWxzbyBzZWUgYSBmZXcgdGhpbmdzIHdoeSBM b1NUIG1pZ2h0IG5vdCBiZSB0aGUgYmVzdCBmaXQgZm9yIFdTREIgZGlzY292ZXJ5Og0KDQpMb1NU IGRvZXMgbm90IHNwZWNpZnkgTG9TVCBzZXJ2ZXIgZGlzY292ZXJ5LiBUaGVyZSBpcyBhIHNlcGFy YXRlIFJGQyBvbiBkaXNjb3ZlcmluZyBMb1NUIHVzaW5nIERIQ1AsIGJ1dCB0aGF0J3Mgbm90IGRl cGxveW1lbnQgZnJpZW5kbHkuIFNvIGEgZGlzY292ZXJ5IG1lY2hhbmlzbSwgZWcgdGhlIG9uZSBk ZXNjcmliZWQgaW4gUmFqJ3MgZG9jdW1lbnQsIGlzIG5lZWRlZCBhbnl3YXkuDQoNCkxvU1QgcmVs aWVzIG9uIFUtTkFQVFIsIGFuZCB3ZSBhbGwga25vdyBob3cgZGlmZmljdWx0IGlzIHRvIGdldCBE TlMgYWRtaW5zIGFkZCBuZXcgcmVjb3JkcyB0byB0aGVpciB6b25lcy4NCg0KVGhlIFdHIHNlZW1z IHRvIHByZWZlciBKU09OIGVuY29kaW5nIHRvIFhNTCwgdG8gYmUgYWJsZSB0byBzdXBwb3J0IGxp Z2h0d2VpZ2h0IGRldmljZXMsIExvU1QgdXNlcyBYTUwuDQoNClRoZXJlIGlzIGEgbG90IG9mIHN0 dWZmIGluIExvU1QsIHdlIHdvdWxkIG5lZWQgYSB2ZXJ5IHNtYWxsIHN1YnNldCBvZiBpdC4NCg0K LSBHYWJvcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZXh0IFJvc2VuLCBC cmlhbiBbbWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6XQ0KU2VudDogTW9uZGF5LCBBdWd1 c3QgMTMsIDIwMTIgMTA6NTkgQU0NClRvOiBQYXRpbCBCYXNhdmFyYWogKE5va2lhLUNJQy9EYWxs YXMpOyAncGV0ZXIubWNjYW5uQGh1YXdlaS5jb20nOyAnam1oQGpvZWxoYWxwZXJuLmNvbSc7IEJh amtvIEdhYm9yIChOb2tpYS1DSUMvU2lsaWNvblZhbGxleSkNCkNjOiAncGF3c0BpZXRmLm9yZycN ClN1YmplY3Q6IFJFOiBbcGF3c10gbmVlZCBmb3IgREIgaW5pdGlhbGl6YXRpb24gbWVzc2FnZQ0K DQppbiB3aGF0IHdheSBpcyBpdCBvdmVya2lsbD8gIFlvdSBwYXNzIGEgbG9jYXRpb24gYW5kIGEg c2hvcnQgVVJOIGluLCB1c2luZyBhIHNpbXBsZSBIVFRQIGV4Y2hhbmdlLCBhbmQgeW91IGdldCBh IChzZXQgb2YpIFVSSXMgb3V0LiAgVGhlIGV4dHJhIHN0dWZmIGl0IGRvZXMgKGxpa2UgcmVjdXIv aXRlcmF0ZSkgaXMgdXNlZnVsLiAgQWJvdXQgdGhlIG9ubHkgZmVhdHVyZSB3ZSBkb24ndCBuZWVk IGlzIHZhbGlkYXRlLCB3aGljaCBpcyB0cml2aWFsIHRvIG5vdCBzdXBwb3J0IChzaW5jZSBpdCdz IG9wdGlvbmFsKS4gIA0KDQpQbGVhc2UgY2l0ZSBhIHNwZWNpZmljIGFzcGVjdCBvZiBMb1NUIHdo aWNoIGlzIG92ZXJraWxsIGZvciB1cy4NCg0KQnJpYW4gPGFzIGluZGl2aWR1YWw+DQoNCg0KDQog LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IAlCYXNhdmFyYWouUGF0aWxAbm9raWEu Y29tIFttYWlsdG86QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbV0NClNlbnQ6CU1vbmRheSwgQXVn dXN0IDEzLCAyMDEyIDAxOjQ5IFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86CVJvc2VuLCBC cmlhbjsgcGV0ZXIubWNjYW5uQGh1YXdlaS5jb207IGptaEBqb2VsaGFscGVybi5jb207IEdhYm9y LkJhamtvQG5va2lhLmNvbQ0KQ2M6CXBhd3NAaWV0Zi5vcmcNClN1YmplY3Q6CVJlOiBbcGF3c10g bmVlZCBmb3IgREIgaW5pdGlhbGl6YXRpb24gbWVzc2FnZQ0KDQoNCkkgdGhpbmsgdGhhdCBMb1NU IGlzIGEgYml0IG9mIGFuIG92ZXJraWxsIGZvciB3aGF0IGlzIHJlYWxseSBuZWVkZWQgaW4gdGhl IGNvbnRleHQgb2YgUEFXUyBmb3IgZGF0YWJhc2UgZGlzY292ZXJ5Lg0KVGhlIFdTREIgZGlzY292 ZXJ5IHNlcnZlciAoYXMgcGVyIGRyYWZ0LXByb2Jhc2NvLXBhd3MtZGlzY292ZXJ5LTAxLnR4dCkN CmNhbiBwcm92aWRlIHRoZSBtYXN0ZXIgZGV2aWNlIHdpdGggaW5mb3JtYXRpb24gYWJvdXQgdGhl IHJlbGV2YW50IFdTREIgKG9yIGxpc3Qgb2YgREJzKSB0byBxdWVyeSBhcyB3ZWxsIGFzIHRoZSBy ZWd1bGF0b3J5IGRvbWFpbiB0aGF0IGl0IGlzIGN1cnJlbnRseSBsb2NhdGVkIGluLg0KDQotUmFq IA0KIA0KDQoNCk9uIDgvMTMvMTIgOTo1NSBBTSwgImV4dCBSb3NlbiwgQnJpYW4iIDxCcmlhbi5S b3NlbkBuZXVzdGFyLmJpej4gd3JvdGU6DQoNCj48YXMgaW5kaXZpZHVhbD4NCj5JIHByZWZlciBM b1NUIGZvciBkaXNjb3ZlcnkuICBMb1NUIGNhbiBkbyByZWN1ci9pdGVyYXRlIGxpa2UgRE5TLCBh bmQgDQo+aXQgY2FuIHJldHVybiBtb3JlIHRoYW4gb25lIFVSSS4gIFRoYXQgd291bGQgYWxsb3cg dGhlIGJhc2UgTG9TVCANCj5kaXNjb3ZlcnkgdG8gZmluZCBhIHNlcnZlciB0aGF0IHJldHVybmVk IHRoZSBsaXN0LiAgVGhlIGluaXRpYWwgTG9TVCANCj5xdWVyeSByZXR1cm5zIHRoZSBsaXN0IHNl cnZlciwgYW5kIGEgcmVjdXIgb3IgaXRlcmF0ZSByZXR1cm5zIHRoZSBsaXN0Lg0KPg0KPkJyaWFu DQo+DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogCVBldGVyIE1j Q2FubiBbbWFpbHRvOlBldGVyLk1jQ2FubkBodWF3ZWkuY29tXQ0KPlNlbnQ6CU1vbmRheSwgQXVn dXN0IDEzLCAyMDEyIDEwOjQ3IEFNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KPlRvOglKb2VsIE0u IEhhbHBlcm47IEdhYm9yLkJhamtvQG5va2lhLmNvbQ0KPkNjOglwYXdzQGlldGYub3JnDQo+U3Vi amVjdDoJUmU6IFtwYXdzXSBuZWVkIGZvciBEQiBpbml0aWFsaXphdGlvbiBtZXNzYWdlDQo+DQo+ QWdyZWUgd2l0aCBKb2VsLg0KPg0KPkkgdGhpbmsgYSBMT1NULXN0eWxlIHNlcnZpY2UgKGEpIGlz IGdvb2QgZm9yIGRpc2NvdmVyaW5nIGEgc2VydmVyIA0KPmFzc29jaWF0ZWQgd2l0aCBhIHJlZ3Vs YXRvcnkgZG9tYWluLiAgQWZ0ZXIgdGhhdCwgeW91IGNhbiBxdWVyeSB0aGUgDQo+cmVndWxhdG9y IChiKSB0byBmaW5kIGFwcHJvdmVkIGRhdGFiYXNlcy4gIFRoZW4sIHlvdSBjYW4gY2hvb3NlIG9u ZSBvZiANCj50aG9zZSBkYXRhYmFzZXMgd2l0aCB3aGljaCB5b3UgaGF2ZSBhIHJlbGF0aW9uc2hp cCBvciB0aGF0IHlvdSBrbm93IA0KPnRocm91Z2ggc29tZSBtZWFucyB3aWxsIHNlcnZpY2UgeW91 ciByZXF1ZXN0IChjKS4gIFRoZSBwcm90b2NvbCBmb3IgKGIpIA0KPmFuZCAoYykgY291bGQgYm90 aCBiZSBQQVdTLCBpZiB3ZSBqdXN0IGFkZCBzb21lIHNvcnQgb2YgaW5kaXJlY3Rpb24gdG8gDQo+ b3VyIHNwZWNpZmljYXRpb24uDQo+DQo+LVBldGUNCj4NCj4NCj5Kb2VsIE0uIEhhbHBlcm4gd3Jv dGU6DQo+PiBUaGUgbWFzdGVyIGhhcyB0byBrbm93IGl0cyBsb2NhdGlvbiBpbiBnZW9ncmFwaGlj IGNvb3JkaW5hdGVzIChHUFMsDQo+PiBldGMuKSAgIEFzIGZhciBhcyBJIGtub3csIHdlIGhhdmUg bm90IGFzc3VtZWQgdGhhdCB0aGUgbWFwcyB0byB0cmFuc2xhdGUNCj4+IHRoYXQgaW50byBwb2xp dGljYWwgZG9tYWlucyBhcmUga25vd24gdG8gdGhlIG1hc3RlciBhIHByaW9yaS4NCj4+IA0KPj4g VGhlcmUgYXJlIGRlcGxveW1lbnQgc2NlbmFyaW9zIChjZWxsIHRvd2VycyBjb21lIHRvIG1pbmQp IHdoZXJlIHRoZSANCj4+IG1hc3RlciBjYW4gcHJvYmFibHkgYmUgcHJvdmlzaW9uZWQgd2l0aCB0 aGUgcmlnaHQgYWRtaW5pc3RyYXRpdmUgDQo+PiBpbmZvcm1hdGlvbi4gIFRoZXJlIGFyZSBvdGhl ciBzY2VuYXJpb3Mgd2hlcmUgdGhhdCBpcyBub3Qgb2J2aW91c2x5IA0KPj4gYWNoaWV2YWJsZS4N Cj4+IA0KPj4gWW91cnMsDQo+PiBKb2VsDQo+PiANCj4+IE9uIDgvMTAvMjAxMiA3OjMzIFBNLCBH YWJvci5CYWprb0Bub2tpYS5jb20gd3JvdGU6DQo+Pj4gV2hpbGUgSSBhZ3JlZSB0aGF0IHJlLWRp cmVjdGlvbiBmcm9tIGFuIGludGVybWVkaWFyeSB0byB0aGUgZmluYWwNCj4+IHJlY2lwaWVudCBz aG91bGQgbm90IGJlIGRpc2FsbG93ZWQsIEkgZG9uJ3QgdGhpbmsgdGhlIHVzZSBjYXNlIHlvdSAN Cj4+IGFyZSBkZXNjcmliaW5nIGlzIGEgdmFsaWQgb25lLiBUaGUgbWFzdGVyIG5lZWRzIHRvIGtu b3cgaXRzIGxvY2F0aW9uIA0KPj4gYmVmb3JlIGVuZ2FnaW5nIGludG8gREIgZGlzY292ZXJ5LiBJ ZiBpdCBkb2Vzbid0LCB0aGVuIGl0IGNhbiB1c2UgDQo+PiBzb21lIGV4aXN0aW5nIG1lY2hhbmlz bSB0byBmaW5kIGl0IG91dCAoZWcsIFJGQzU5ODUpIHByaW9yIHRvIHRoZSBEQiANCj4+IGRpc2Nv dmVyeSBwcm9jZXNzLCBidXQgdGhhdCBmb3IgbWUgaXMgYSBzZXBhcmF0ZSB0cmFuc2FjdGlvbi4N Cj4+PiANCj4+PiBUaGUgY3VycmVudCBEQiBkaXNjb3ZlcnkgbWVjaGFuaXNtIGRlc2NyaWJlZCBp bg0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1wcm9iYXNjby1wYXdzLWRpc2NvdmVy eS0wMS50eHQgYXNzdW1lcyANCj4+dGhhdCB0aGUgbWFzdGVyIGtub3dzIGl0cyBsb2NhdGlvbiBi ZWZvcmUgcGVyZm9ybWluZyBEQiBkaXNjb3Zlcnk7IA0KPj5hZnRlciB3aGljaCBpdCBuZWVkcyB0 byBkbyBhIHJlZ3VsYXRvcnkgZG9tYWluIGRpc2NvdmVyeSBhcyB3ZWxsLg0KPj4gQnJpYW4gc3Vn Z2VzdGVkIHJlZ3VsYXRvcnkgZG9tYWluIGNvdWxkIGJlIGEgcGFyYW1ldGVyIG9mIHRoZSBEQiBV UkksIA0KPj50aHVzIG5vIG5lZWQgZm9yIHNlcGFyYXRlIHJlZ3VsYXRvcnkgZG9tYWluIGRpc2Nv dmVyeS4gQW55IG90aGVyIA0KPj5zdWdnZXN0aW9ucz8NCj4+PiANCj4+PiAtIEdhYm9yDQo+Pj4g DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBleHQgSm9lbCBNLiBI YWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0NCj4+PiBTZW50OiBUaHVyc2RheSwg QXVndXN0IDA5LCAyMDEyIDY6MjUgUE0NCj4+PiBUbzogQmFqa28gR2Fib3IgKE5va2lhLUNJQy9T aWxpY29uVmFsbGV5KQ0KPj4+IENjOiBwYXdzQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtw YXdzXSBuZWVkIGZvciBEQiBpbml0aWFsaXphdGlvbiBtZXNzYWdlDQo+Pj4gDQo+Pj4gUmVsYXRl ZCBzdWdnZXN0aW9uOiAgQXNzdW1pbmcgd2UgaGF2ZSBhIGRpc2NvdmVyeSBwcm90b2NvbCB3aGlj aCBjYW4gDQo+Pj4gcmV0dXJuIGEgVVJJLCB0aGUgcHJvdG9jb2wgc2VtYW50aWNzIHNob3VsZCBi ZSBzdWNoIHRoYXQgdGhlIFVSSSBjYW4gDQo+Pj4gYmUgdGhlIGZpbmFsIERCIFVSSSwgb3IgYW5v dGhlciBpbnRlcm1lZGlhcnkgaW4gdGhlIHByb2Nlc3MuICBUaHVzLCANCj4+PiB0aGUgcHJvdG9j b2wgc2hvdWxkIG5vdCBsb2NrIGluIHRoYXQgdGhlcmUgY2FuIGJlIG9ubHkgMCBvciAxIA0KPj4+ IGludGVybWVkaWFyaWVzIGluIHRoZSByZXNvbHV0aW9uLCBidXQgc2hvdWxkIGFsbG93IHNldmVy YWwuICAoV2UgDQo+Pj4gYWxyZWFkeSBoYXZlIHN1Z2dlc3RlZCBjYXNlcyB3aGVyZSBhdCBsZWFz dCB0d28gYXJlIG5lZWRlZCwgb25lIHRvIA0KPj4+IGRldGVybWluZSB3aGVyZSB5b3UgYXJlIGJ5 IGFza2luZyB5b3VyIHZlbmRvciwgYW5kIG9uZSB0byBkZXRlcm1pbmUgDQo+Pj4gd2hvIHlvdSBj YW4gdGFsayB0byBieSBhc2tpbmcgeW91ciBsb2NhbCByZWd1bGF0b3IuKQ0KPj4+IA0KPj4+IFlv dXJzLA0KPj4+IEpvZWwNCj4+PiANCj4+PiBPbiA4LzkvMjAxMiA4OjAyIFBNLCBHYWJvci5CYWpr b0Bub2tpYS5jb20gd3JvdGU6DQo+Pj4+IEZvbGtzLA0KPj4+PiANCj4+Pj4gRHVyaW5nIHRoZSBW YW5jb3V2ZXIgRjJGIGRpc2N1c3Npb25zIHdlIGhhZCBzb21lIGdvb2QgZGlzY3Vzc2lvbnMsIA0K Pj4+PiBidXQgbm8gYWdyZWVtZW50IG9uIHdldGhlciBhbiBpbml0aWFsaXphdGlvbiBtZXNzYWdl LCBhcyBwcm9wb3NlZCANCj4+Pj4gaW4gZHJhZnQtZGFzIGlzIG5lY2Vzc2FyeSBvciBub3QuDQo+ Pj4+IA0KPj4+PiBZb3UgbWF5IGNoZWNrIHRoZSBtaW51dGVzIHRvIHNlZSB3aGF0IHdhcyBzYWlk IGF0IHRoZSBtaWtlOg0KPj4+PiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg0L21p bnV0ZXMvbWludXRlcy04NC1wYXdzDQo+Pj4+IA0KPj4+PiBQZW9wbGUgc3Bva2UgbW9zdGx5IGlu IGZhdm9yLCBidXQgdGhlcmUgd2VyZSBwZW9wbGUgd2hvIGFsc28gc2FpZCANCj4+Pj4gdGhhdCB0 aGlzIG1lc3NhZ2UgaXMgcmVkdW5kYW50IHdpdGggcmVnaXN0cmF0aW9uIG1lc3NhZ2UuDQo+Pj4+ IA0KPj4+PiBRdWVzdGlvbiMxOiBuZWVkIGZvciBhbiBpbml0aWFsaXphdGlvbiBtZXNzYWdlDQo+ Pj4+IA0KPj4+PiBVbmZvcnR1bmF0ZWx5IHdlIGRpZCBub3QgaGF2ZSB0aW1lIHRvIGRpc2N1c3Mg dGhlIERCIGRpc2NvdmVyeSANCj4+Pj4gYXNwZWN0LCBhbmQgdGhhdCBtYXkgYmUgcmVsYXRlZCB0 byB0aGlzIHRvcGljLiBUaGUgb25seSBEQiANCj4+Pj4gZGlzY292ZXJ5IGRvY3VtZW50IGF2YWls YWJsZSBjdXJyZW50bHksIA0KPj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXByb2Jh c2NvLXBhd3MtZGlzY292ZXJ5LTAxLnR4dCwNCj4+Pj4gcHJvcG9zZXMsIHRoYXQgdGhlIG1hc3Rl ciBkZXZpY2UgY29udGFjdHMgYSBwcmUtcHJvdmlzaW9uZWQgDQo+Pj4+IGRpc2NvdmVyeSBzZXJ2 ZXIgYW5kIHByb3ZpZGVzIGl0cyBsb2NhdGlvbiwgYW5kIGluIHJldHVybiB0aGUgDQo+Pj4+IGRp c2NvdmVyeSBzZXJ2ZXIgcmV0dXJucyB0aGUgVVJJIG9mIHRoZSBEQiBmb3IgdGhhdCByZWd1bGF0 b3J5IA0KPj4+PiBkb21haW4uIEF0IHRoaXMgcG9pbnQsIHRoZSBtYXN0ZXIgZGV2aWNlIGtub3dz IHdoaWNoIERCIHRvIGNvbnRhY3QsIA0KPj4+PiBidXQgaXQgZG9lcyBub3QgbmVjZXNzYXJpbHkg a25vdyB3aGF0IHJlZ3VsYXRvcnkgZG9tYWluIHRoYXQgREIgDQo+Pj4+IGJlbG9uZ3MgdG8uIFRo dXMsIGl0IGRvZXNuJ3Qga25vdyB3aGF0IGFyZSB0aGUgb3BlcmF0aW5nIHJ1bGVzLCANCj4+Pj4g d2hldGhlciBpdCBoYXMgdG8gYXV0aGVudGljYXRlLCBvciByZWdpc3RlciwgZXRjLg0KPj4+PiAN Cj4+Pj4gVGh1cywgaXQgc2VlbXMgbG9naWNhbCB0byBtZSB0aGF0IHRoZSBtYXN0ZXIgZGV2aWNl IGZpcnN0IHF1ZXJpZXMgDQo+Pj4+IHRoZSBEQiB0byBmaW5kIG91dCB0aGUgcmVndWxhdG9yeSBk b21haW4uIFdlIGV2ZW4gaGF2ZSBzdWNoIGEgDQo+Pj4+IHJlcXVpcmVtZW50IGluIHRoZSByZXF1 aXJlbWVudCBkcmFmdCwgcmVxdWlyZW1lbnQ6DQo+Pj4+IA0KPj4+PiAiUC4zOiAgIFRoZSBwcm90 b2NvbCBNVVNUIHN1cHBvcnQgZGV0ZXJtaW5hdGlvbiBvZg0KPj4+PiByZWd1bGF0b3J5ICAgICAg ICAgICAgIGRvbWFpbiBnb3Zlcm5pbmcgaXRzIGN1cnJlbnQgbG9jYXRpb24uIg0KPj4+PiANCj4+ Pj4gVGhlIGluZm9ybWF0aW9uIGFib3V0IHRoZSByZWd1bGF0b3J5IGRvbWFpbiBtYXkgYmUgY2Fj aGVkLCBhbmQgdGhlIA0KPj4+PiBtYXN0ZXIgZGV2aWNlIG1heSBub3QgbmVlZCB0byBwbGFjZSB0 aGF0IHF1ZXJ5IGV2ZXJ5IHRpbWUsIGJ1dCB0aGlzIA0KPj4+PiBtZXNzYWdlIGV4Y2hhbmdlIG1h eSBiZSBuZWNlc3NhcnkgaW4gY2VydGFpbiBjYXNlcy4gQW55IGNvbW1lbnRzIHRvIA0KPj4+PiB0 aGlzIHBvaW50Pw0KPj4+PiANCj4+Pj4gUXVlc3Rpb24jMg0KPj4+PiANCj4+Pj4gVGhlbiwgaXQg aXMgYSBzbGlnaHRseSBzZXBhcmF0ZSBpc3N1ZSwgaWYgdGhpcyBtZXNzYWdlIGV4Y2hhbmdlIGhh cyANCj4+Pj4gdG8gdGFrZSBwbGFjZSwgdGhlbiB3aGF0IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24g dGhlIERCIHJldHVybnMuDQo+Pj4+IGRyYWZ0LWRhcyBwcm9wb3NlcyB0aGF0IHJlZ3VsYXRvcnkg ZG9tYWluIHNwZWNpZmljIGluZm9ybWF0aW9uIGJlIA0KPj4+PiByZXR1cm5lZCB0byB0aGUgbWFz dGVyIGRldmljZS4NCj4+Pj4gDQo+Pj4+IFF1ZXN0aW9uIzMNCj4+Pj4gDQo+Pj4+IFlldCBhbm90 aGVyIHNlcGFyYXRlIHBvaW50IGlzIHRoYXQgZHJhZnQtZGFzIHByb3Bvc2VzIHRvIHVzZSB0aGlz IA0KPj4+PiBpbml0aWFsaXphdGlvbiBtZXNzYWdlIGFsc28gdG8gaW5pdGlhdGUgY2xpZW50IGF1 dGhlbnRpY2F0aW9uIA0KPj4+PiAocHV0dGluZyBzaGFyZWQgc2VjcmV0IHZzIGNlcnQgaXNzdWUg YXNpZGUgZm9yIHRoZSB0aW1lIGJlaW5nKS4gSW4gDQo+Pj4+IGNhc2VzIHdoZW4gdGhlIG1hc3Rl ciBkZXZpY2UgZG9lcyBub3Qga25vdyB0aGUgcmVndWxhdG9yeSBkb21haW4gaXQgDQo+Pj4+IGlz IGluLCB0aGVuIGl0IGRvZXMgbm90IGtub3cgd2hldGhlciBhdXRoZW50aWNhdGlvbiBpcyByZXF1 aXJlZCBpbiANCj4+Pj4gdGhhdCByZWd1bGF0b3J5IGRvbWFpbiBvciBub3Q7IHNvIHdoeSB3b3Vs ZCBpbml0aWF0ZSBhdXRoZW50aWNhdGlvbiANCj4+Pj4gdGhlbj8gU2ltaWxhciBjb21tZW50IGFw cGxpZXMgdG8gZHJhZnQtd2VpLCB3aGVyZSBpdCBpcyBwcm9wb3NlZCANCj4+Pj4gdGhhdCBhZnRl ciBEQiBkaXNjb3ZlcnkgdGhlIG1hc3RlciBkZXZpY2UgYXV0aGVudGljYXRlcyBhdCBUTFMgDQo+ Pj4+IGxheWVyIGFuZCBwZXJmb3JtcyByZWdpc3RyYXRpb247IGhvdyBkb2VzIGl0IGtub3cgdGhh dCBpdCBoYXMgdG8gDQo+Pj4+IGF1dGhlbnRpY2F0ZSBhbmQgcmVnaXN0ZXIsIGlmIGl0IGRvZXNu J3Qga25vdyB0aGUgcmVndWxhdG9yeSBkb21haW4/DQo+Pj4+IA0KPj4+PiBJbiBteSBvcGluaW9u IChjaGFpciBoYXQgb2ZmKSwgdGhlIHNlcXVlbmNlIG9mIGV2ZW50cyBzaG91bGQgYmUgc2cgDQo+ Pj4+IGxpa2UNCj4+Pj4gdGhpczoNCj4+Pj4gDQo+Pj4+IDEuREIgZGlzY292ZXJ5IChtYXkgYmUg c2tpcHBlZCBpZiBjYWNoZWQgaW5mb3JtYXRpb24gYXZhaWxhYmxlKQ0KPj4+PiANCj4+Pj4gMi5S ZWd1bGF0b3J5IGRvbWFpbiBxdWVyeSAobWF5IGJlIHNraXBwZWQgaWYgY2FjaGVkIGluZm9ybWF0 aW9uDQo+Pj4+IGF2YWlsYWJsZSkNCj4+Pj4gDQo+Pj4+IDMuQXV0aGVudGljYXRpb24gKGlmIHJl cXVpcmVkKQ0KPj4+PiANCj4+Pj4gNC5SZWdpc3RyYXRpb24gKGlmIHJlcXVpcmVkKQ0KPj4+PiAN Cj4+Pj4gNS5DaGFubmVsIGF2YWlsYWJpbGl0eSBxdWVyeSAobWF5IGJlIGNvbWJpbmVkIHdpdGgg cmVnaXN0cmF0aW9uPykNCj4+Pj4gDQo+Pj4+IENvbW1lbnRzIGFyZSB3ZWxjb21lIGFuZCBleHBl Y3RlZC4NCj4+Pj4gDQo+Pj4+IC1HYWJvcg0KPj4+PiANCj4NCj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnBhd3MgbWFpbGluZyBsaXN0DQo+cGF3c0Bp ZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+cGF3cyBtYWls aW5nIGxpc3QNCj5wYXdzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wYXdzDQoNCg== From brian.rosen@neustar.biz Thu Aug 16 12:27:44 2012 Return-Path: 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 D8ED821F8593 for ; Thu, 16 Aug 2012 12:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, 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 Nb7O5rbeXs5z for ; Thu, 16 Aug 2012 12:27:43 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5029421F8518 for ; Thu, 16 Aug 2012 12:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1345145027; x=1660500687; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=oyBb96MQ2eiRbR3i4J6Hk PaMsjrXHf2lm2Cnhcws0jw=; b=C0rj12LexiKj3nu13Bt+eiC0ADNMKYAAT3OXO zW16A5Ygkai/lbRaCARNxbjiC/ORV8QD/KnedAONor4vEVxvA== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.9960196; Thu, 16 Aug 2012 15:23:46 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 16 Aug 2012 15:27:41 -0400 From: "Rosen, Brian" Date: Thu, 16 Aug 2012 15:27:39 -0400 Thread-Topic: [paws] DB discovery [was: RE: need for DB initialization message] Thread-Index: Ac175TPgzfZRTcL3QPexdXaeYt6AjA== Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB416E@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: yY1SenhKO+Sf7YIHBi3zng== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: "gabor.bajko@nokia.com" , "paws@ietf.org" Subject: Re: [paws] DB discovery [was: RE: need for DB initialization message] X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 19:27:45 -0000 Discovery HAS to be independent of regulator or a device would be hard wired to a country. The first step is to figure out what country you are in, then the path is dependent on how that regulatory domain works - and some may require you query a regulator operated (or contracted) mechanism that lists available DBs in that domain. But first, you need to figure out what country you are in, and then you need to contact something inside that country. So, the first step discovery isn't something national, and it has to have polygons for countries. That is what LoST does. You can reinvent LoST, but that=B9s what it does - keep a set of polygons, and have a list of URIs associated with each polygon, plus the equivalent if you have a street address instead of a lat/lon. You are (rightly) worried about how you find that server. As far as I know, there are three choices, and only 3. 1. Some entity runs a "root" server that everyone uses - the URI to it is ("well known") 2. Every device is provisioned with a root server that someone runs ("provisioned") 3. The local environment provides the URI of a root server like other local services (DHCP or some equivalent of it) ("local discovery") Any one regulator won't run the root server. Trying to decide on a single well known one takes something along the lines of ITU-T and some funding mechanism So, you get to provisioning and local discovery. If we choose provisioning, who runs it (or at least who chooses it, which has the "who pays for it" problem) If we choose local discovery, then how do we get it deployed? And, the master lives on some access network. Whether or not the master can make emergency calls is not relevant - the basic notion is that ISPs of any sort can't control devices connected to it directly OR INDIRECTLY, and thus they all have to support emergency calls, which means LoST. But the time frame for deployment IS an issue. Brian On 8/16/12 3:05 PM, "Gabor.Bajko@nokia.com" wrote: >The discovery service would not necessarily be operated by the >manufacturer, it could eg be the regulator itself, or the db admin. >AFAIK, currently there is no LoST server discovery mechanism supported in >the access networks,, thus we need to do sg about it if we want this >ecosystem to take off in the near future. >What comes to supporting LoST for emergency calling purposes, note that >WS master devices may not be the ones making emergency calls, thus they >won't come with LoST support. >- Gabor > >-----Original Message----- >From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >Sent: Monday, August 13, 2012 12:12 PM >To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil Basavaraj >(Nokia-CIC/Dallas); 'peter.mccann@huawei.com'; 'jmh@joelhalpern.com' >Cc: 'paws@ietf.org' >Subject: RE: DB discovery [was: RE: [paws] need for DB initialization >message] > >The U-NAPTR is only part of LoST discovery. If you don't like it, your >only alternative is provisioning, but some folks seem to like >provisioning. We have a whole lot of experience with service discovery. >There are no simple mechanisms that work globally without support from >some kind of infrastructure. To me, the notion that a device >manufacturer will support a discovery service for the lifetime of the >device is less likely as ISP support for LoST, since the latter will be >needed for emergency calling. > >If we needed to do a json encoding of LoST, no one will object. > >The only subset we need is a single URN (although you could imagine a >country specific URN), and no validation. >The service boundary part is very handy for a mobile device to determine >when it has moved beyond the boundary served by the same URN. This would >happen if you roamed across a border. It's not a required element on the >server, and the client can ignore it. > >Brian > > > > -----Original Message----- >From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] >Sent: Monday, August 13, 2012 02:46 PM Eastern Standard Time >To: Rosen, Brian; Basavaraj.Patil@nokia.com; peter.mccann@huawei.com; >jmh@joelhalpern.com >Cc: paws@ietf.org >Subject: DB discovery [was: RE: [paws] need for DB initialization >message] > >I could also see a few things why LoST might not be the best fit for WSDB >discovery: > >LoST does not specify LoST server discovery. There is a separate RFC on >discovering LoST using DHCP, but that's not deployment friendly. So a >discovery mechanism, eg the one described in Raj's document, is needed >anyway. > >LoST relies on U-NAPTR, and we all know how difficult is to get DNS >admins add new records to their zones. > >The WG seems to prefer JSON encoding to XML, to be able to support >lightweight devices, LoST uses XML. > >There is a lot of stuff in LoST, we would need a very small subset of it. > >- Gabor > >-----Original Message----- >From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >Sent: Monday, August 13, 2012 10:59 AM >To: Patil Basavaraj (Nokia-CIC/Dallas); 'peter.mccann@huawei.com'; >'jmh@joelhalpern.com'; Bajko Gabor (Nokia-CIC/SiliconValley) >Cc: 'paws@ietf.org' >Subject: RE: [paws] need for DB initialization message > >in what way is it overkill? You pass a location and a short URN in, >using a simple HTTP exchange, and you get a (set of) URIs out. The extra >stuff it does (like recur/iterate) is useful. About the only feature we >don't need is validate, which is trivial to not support (since it's >optional). > >Please cite a specific aspect of LoST which is overkill for us. > >Brian > > > > -----Original Message----- >From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >Sent: Monday, August 13, 2012 01:49 PM Eastern Standard Time >To: Rosen, Brian; peter.mccann@huawei.com; jmh@joelhalpern.com; >Gabor.Bajko@nokia.com >Cc: paws@ietf.org >Subject: Re: [paws] need for DB initialization message > > >I think that LoST is a bit of an overkill for what is really needed in >the context of PAWS for database discovery. >The WSDB discovery server (as per draft-probasco-paws-discovery-01.txt) >can provide the master device with information about the relevant WSDB >(or list of DBs) to query as well as the regulatory domain that it is >currently located in. > >-Raj > > > >On 8/13/12 9:55 AM, "ext Rosen, Brian" wrote: > >> >>I prefer LoST for discovery. LoST can do recur/iterate like DNS, and >>it can return more than one URI. That would allow the base LoST >>discovery to find a server that returned the list. The initial LoST >>query returns the list server, and a recur or iterate returns the list. >> >>Brian >> >> >> >> -----Original Message----- >>From: Peter McCann [mailto:Peter.McCann@huawei.com] >>Sent: Monday, August 13, 2012 10:47 AM Eastern Standard Time >>To: Joel M. Halpern; Gabor.Bajko@nokia.com >>Cc: paws@ietf.org >>Subject: Re: [paws] need for DB initialization message >> >>Agree with Joel. >> >>I think a LOST-style service (a) is good for discovering a server >>associated with a regulatory domain. After that, you can query the >>regulator (b) to find approved databases. Then, you can choose one of >>those databases with which you have a relationship or that you know >>through some means will service your request (c). The protocol for (b) >>and (c) could both be PAWS, if we just add some sort of indirection to >>our specification. >> >>-Pete >> >> >>Joel M. Halpern wrote: >>> The master has to know its location in geographic coordinates (GPS, >>> etc.) As far as I know, we have not assumed that the maps to >>>translate >>> that into political domains are known to the master a priori. >>> >>> There are deployment scenarios (cell towers come to mind) where the >>> master can probably be provisioned with the right administrative >>> information. There are other scenarios where that is not obviously >>> achievable. >>> >>> Yours, >>> Joel >>> >>> On 8/10/2012 7:33 PM, Gabor.Bajko@nokia.com wrote: >>>> While I agree that re-direction from an intermediary to the final >>> recipient should not be disallowed, I don't think the use case you >>> are describing is a valid one. The master needs to know its location >>> before engaging into DB discovery. If it doesn't, then it can use >>> some existing mechanism to find it out (eg, RFC5985) prior to the DB >>> discovery process, but that for me is a separate transaction. >>>> >>>> The current DB discovery mechanism described in >>> http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt assumes >>>that the master knows its location before performing DB discovery; >>>after which it needs to do a regulatory domain discovery as well. >>> Brian suggested regulatory domain could be a parameter of the DB URI, >>>thus no need for separate regulatory domain discovery. Any other >>>suggestions? >>>> >>>> - Gabor >>>> >>>> -----Original Message----- >>>> From: ext Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Thursday, August 09, 2012 6:25 PM >>>> To: Bajko Gabor (Nokia-CIC/SiliconValley) >>>> Cc: paws@ietf.org >>>> Subject: Re: [paws] need for DB initialization message >>>> >>>> Related suggestion: Assuming we have a discovery protocol which can >>>> return a URI, the protocol semantics should be such that the URI can >>>> be the final DB URI, or another intermediary in the process. Thus, >>>> the protocol should not lock in that there can be only 0 or 1 >>>> intermediaries in the resolution, but should allow several. (We >>>> already have suggested cases where at least two are needed, one to >>>> determine where you are by asking your vendor, and one to determine >>>> who you can talk to by asking your local regulator.) >>>> >>>> Yours, >>>> Joel >>>> >>>> On 8/9/2012 8:02 PM, Gabor.Bajko@nokia.com wrote: >>>>> Folks, >>>>> >>>>> During the Vancouver F2F discussions we had some good discussions, >>>>> but no agreement on wether an initialization message, as proposed >>>>> in draft-das is necessary or not. >>>>> >>>>> You may check the minutes to see what was said at the mike: >>>>> http://www.ietf.org/proceedings/84/minutes/minutes-84-paws >>>>> >>>>> People spoke mostly in favor, but there were people who also said >>>>> that this message is redundant with registration message. >>>>> >>>>> Question#1: need for an initialization message >>>>> >>>>> Unfortunately we did not have time to discuss the DB discovery >>>>> aspect, and that may be related to this topic. The only DB >>>>> discovery document available currently, >>>>> http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, >>>>> proposes, that the master device contacts a pre-provisioned >>>>> discovery server and provides its location, and in return the >>>>> discovery server returns the URI of the DB for that regulatory >>>>> domain. At this point, the master device knows which DB to contact, >>>>> but it does not necessarily know what regulatory domain that DB >>>>> belongs to. Thus, it doesn't know what are the operating rules, >>>>> whether it has to authenticate, or register, etc. >>>>> >>>>> Thus, it seems logical to me that the master device first queries >>>>> the DB to find out the regulatory domain. We even have such a >>>>> requirement in the requirement draft, requirement: >>>>> >>>>> "P.3: The protocol MUST support determination of >>>>> regulatory domain governing its current location." >>>>> >>>>> The information about the regulatory domain may be cached, and the >>>>> master device may not need to place that query every time, but this >>>>> message exchange may be necessary in certain cases. Any comments to >>>>> this point? >>>>> >>>>> Question#2 >>>>> >>>>> Then, it is a slightly separate issue, if this message exchange has >>>>> to take place, then what additional information the DB returns. >>>>> draft-das proposes that regulatory domain specific information be >>>>> returned to the master device. >>>>> >>>>> Question#3 >>>>> >>>>> Yet another separate point is that draft-das proposes to use this >>>>> initialization message also to initiate client authentication >>>>> (putting shared secret vs cert issue aside for the time being). In >>>>> cases when the master device does not know the regulatory domain it >>>>> is in, then it does not know whether authentication is required in >>>>> that regulatory domain or not; so why would initiate authentication >>>>> then? Similar comment applies to draft-wei, where it is proposed >>>>> that after DB discovery the master device authenticates at TLS >>>>> layer and performs registration; how does it know that it has to >>>>> authenticate and register, if it doesn't know the regulatory domain? >>>>> >>>>> In my opinion (chair hat off), the sequence of events should be sg >>>>> like >>>>> this: >>>>> >>>>> 1.DB discovery (may be skipped if cached information available) >>>>> >>>>> 2.Regulatory domain query (may be skipped if cached information >>>>> available) >>>>> >>>>> 3.Authentication (if required) >>>>> >>>>> 4.Registration (if required) >>>>> >>>>> 5.Channel availability query (may be combined with registration?) >>>>> >>>>> Comments are welcome and expected. >>>>> >>>>> -Gabor >>>>> >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Thu Aug 16 15:35:21 2012 Return-Path: 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 4D07021F8585 for ; Thu, 16 Aug 2012 15:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 RKKCdziulxgz for ; Thu, 16 Aug 2012 15:35:20 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4010021F8533 for ; Thu, 16 Aug 2012 15:35:18 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7GMZ4GX030279; Fri, 17 Aug 2012 01:35:05 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Aug 2012 01:36:09 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Fri, 17 Aug 2012 00:35:03 +0200 From: To: , Thread-Topic: [paws] DB discovery [was: RE: need for DB initialization message] Thread-Index: AQHNe+U5cVVv2hr0Y0q892yena21Fpdc/tkw Date: Thu, 16 Aug 2012 22:35:02 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB423A@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB416E@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Aug 2012 22:36:09.0672 (UTC) FILETIME=[88451C80:01CD7BFF] X-Nokia-AV: Clean Subject: Re: [paws] DB discovery [was: RE: need for DB initialization message] X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 22:35:21 -0000 I think we are saying the same thing. As you summarize, we can only choose = between provisioning or discovery; if we choose discovery, we have to make = sure the discovery mechanism is supported in all access networks where a ma= ster may be present. Since usually deployment is outside of ietf's control,= this would be hard to achieve.=20 If we choose provisioning, we only need a root server and that being provis= ioned in the masters. Wrt to the use of LoST, if we anyway need an I-D to describe the DB provisi= oning, change the encoding to JSON, and profile it down to the minimum set = of messages required, then it doesn't make much difference to me whether we= reference the LoST RFC, or come up with our own protocol.=20 What Scott described in the discovery document is in line with your point 2= . below (what you call provisioning), so perhaps it could be a good start. = But we need to hear other people's opinion as well. So please comment. - Gabor -----Original Message----- From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Thursday, August 16, 2012 12:28 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); paws@ietf.org Subject: Re: [paws] DB discovery [was: RE: need for DB initialization messa= ge] Discovery HAS to be independent of regulator or a device would be hard wire= d to a country. The first step is to figure out what country you are in, t= hen the path is dependent on how that regulatory domain works - and some ma= y require you query a regulator operated (or contracted) mechanism that lis= ts available DBs in that domain. But first, you need to figure out what cou= ntry you are in, and then you need to contact something inside that country= . So, the first step discovery isn't something national, and it has to have p= olygons for countries. That is what LoST does. You can reinvent LoST, but= that=B9s what it does - keep a set of polygons, and have a list of URIs as= sociated with each polygon, plus the equivalent if you have a street addres= s instead of a lat/lon. You are (rightly) worried about how you find that server. As far as I know= , there are three choices, and only 3. 1. Some entity runs a "root" server that everyone uses - the URI to it is (= "well known") 2. Every device is provisioned with a root server that someon= e runs ("provisioned") 3. The local environment provides the URI of a root server like other local= services (DHCP or some equivalent of it) ("local discovery") Any one regulator won't run the root server. Trying to decide on a single well known one takes something along the lines= of ITU-T and some funding mechanism So, you get to provisioning and local discovery. If we choose provisioning, who runs it (or at least who chooses it, which h= as the "who pays for it" problem) If we choose local discovery, then how do= we get it deployed? And, the master lives on some access network. Whether or not the master ca= n make emergency calls is not relevant - the basic notion is that ISPs of a= ny sort can't control devices connected to it directly OR INDIRECTLY, and t= hus they all have to support emergency calls, which means LoST. But the ti= me frame for deployment IS an issue. Brian On 8/16/12 3:05 PM, "Gabor.Bajko@nokia.com" wrote: >The discovery service would not necessarily be operated by the=20 >manufacturer, it could eg be the regulator itself, or the db admin. >AFAIK, currently there is no LoST server discovery mechanism supported=20 >in the access networks,, thus we need to do sg about it if we want this=20 >ecosystem to take off in the near future. >What comes to supporting LoST for emergency calling purposes, note that=20 >WS master devices may not be the ones making emergency calls, thus they=20 >won't come with LoST support. >- Gabor > >-----Original Message----- >From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >Sent: Monday, August 13, 2012 12:12 PM >To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil Basavaraj=20 >(Nokia-CIC/Dallas); 'peter.mccann@huawei.com'; 'jmh@joelhalpern.com' >Cc: 'paws@ietf.org' >Subject: RE: DB discovery [was: RE: [paws] need for DB initialization=20 >message] > >The U-NAPTR is only part of LoST discovery. If you don't like it, your=20 >only alternative is provisioning, but some folks seem to like=20 >provisioning. We have a whole lot of experience with service discovery. >There are no simple mechanisms that work globally without support from=20 >some kind of infrastructure. To me, the notion that a device=20 >manufacturer will support a discovery service for the lifetime of the=20 >device is less likely as ISP support for LoST, since the latter will be=20 >needed for emergency calling. > >If we needed to do a json encoding of LoST, no one will object. > >The only subset we need is a single URN (although you could imagine a=20 >country specific URN), and no validation. >The service boundary part is very handy for a mobile device to=20 >determine when it has moved beyond the boundary served by the same URN. =20 >This would happen if you roamed across a border. It's not a required=20 >element on the server, and the client can ignore it. > >Brian > > > > -----Original Message----- >From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] >Sent: Monday, August 13, 2012 02:46 PM Eastern Standard Time >To: Rosen, Brian; Basavaraj.Patil@nokia.com; peter.mccann@huawei.com; >jmh@joelhalpern.com >Cc: paws@ietf.org >Subject: DB discovery [was: RE: [paws] need for DB initialization >message] > >I could also see a few things why LoST might not be the best fit for=20 >WSDB >discovery: > >LoST does not specify LoST server discovery. There is a separate RFC on=20 >discovering LoST using DHCP, but that's not deployment friendly. So a=20 >discovery mechanism, eg the one described in Raj's document, is needed=20 >anyway. > >LoST relies on U-NAPTR, and we all know how difficult is to get DNS=20 >admins add new records to their zones. > >The WG seems to prefer JSON encoding to XML, to be able to support=20 >lightweight devices, LoST uses XML. > >There is a lot of stuff in LoST, we would need a very small subset of it. > >- Gabor > >-----Original Message----- >From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >Sent: Monday, August 13, 2012 10:59 AM >To: Patil Basavaraj (Nokia-CIC/Dallas); 'peter.mccann@huawei.com';=20 >'jmh@joelhalpern.com'; Bajko Gabor (Nokia-CIC/SiliconValley) >Cc: 'paws@ietf.org' >Subject: RE: [paws] need for DB initialization message > >in what way is it overkill? You pass a location and a short URN in,=20 >using a simple HTTP exchange, and you get a (set of) URIs out. The=20 >extra stuff it does (like recur/iterate) is useful. About the only=20 >feature we don't need is validate, which is trivial to not support=20 >(since it's optional). > >Please cite a specific aspect of LoST which is overkill for us. > >Brian > > > > -----Original Message----- >From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >Sent: Monday, August 13, 2012 01:49 PM Eastern Standard Time >To: Rosen, Brian; peter.mccann@huawei.com; jmh@joelhalpern.com; >Gabor.Bajko@nokia.com >Cc: paws@ietf.org >Subject: Re: [paws] need for DB initialization message > > >I think that LoST is a bit of an overkill for what is really needed in=20 >the context of PAWS for database discovery. >The WSDB discovery server (as per draft-probasco-paws-discovery-01.txt) >can provide the master device with information about the relevant WSDB=20 >(or list of DBs) to query as well as the regulatory domain that it is=20 >currently located in. > >-Raj > > > >On 8/13/12 9:55 AM, "ext Rosen, Brian" wrote: > >> >>I prefer LoST for discovery. LoST can do recur/iterate like DNS, and=20 >>it can return more than one URI. That would allow the base LoST=20 >>discovery to find a server that returned the list. The initial LoST=20 >>query returns the list server, and a recur or iterate returns the list. >> >>Brian >> >> >> >> -----Original Message----- >>From: Peter McCann [mailto:Peter.McCann@huawei.com] >>Sent: Monday, August 13, 2012 10:47 AM Eastern Standard Time >>To: Joel M. Halpern; Gabor.Bajko@nokia.com >>Cc: paws@ietf.org >>Subject: Re: [paws] need for DB initialization message >> >>Agree with Joel. >> >>I think a LOST-style service (a) is good for discovering a server=20 >>associated with a regulatory domain. After that, you can query the=20 >>regulator (b) to find approved databases. Then, you can choose one of=20 >>those databases with which you have a relationship or that you know=20 >>through some means will service your request (c). The protocol for=20 >>(b) and (c) could both be PAWS, if we just add some sort of=20 >>indirection to our specification. >> >>-Pete >> >> >>Joel M. Halpern wrote: >>> The master has to know its location in geographic coordinates (GPS, >>> etc.) As far as I know, we have not assumed that the maps to >>>translate >>> that into political domains are known to the master a priori. >>> >>> There are deployment scenarios (cell towers come to mind) where the=20 >>> master can probably be provisioned with the right administrative=20 >>> information. There are other scenarios where that is not obviously=20 >>> achievable. >>> >>> Yours, >>> Joel >>> >>> On 8/10/2012 7:33 PM, Gabor.Bajko@nokia.com wrote: >>>> While I agree that re-direction from an intermediary to the final >>> recipient should not be disallowed, I don't think the use case you=20 >>> are describing is a valid one. The master needs to know its location=20 >>> before engaging into DB discovery. If it doesn't, then it can use=20 >>> some existing mechanism to find it out (eg, RFC5985) prior to the DB=20 >>> discovery process, but that for me is a separate transaction. >>>> >>>> The current DB discovery mechanism described in >>> http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt assumes=20 >>>that the master knows its location before performing DB discovery;=20 >>>after which it needs to do a regulatory domain discovery as well. >>> Brian suggested regulatory domain could be a parameter of the DB=20 >>>URI, thus no need for separate regulatory domain discovery. Any other=20 >>>suggestions? >>>> >>>> - Gabor >>>> >>>> -----Original Message----- >>>> From: ext Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Thursday, August 09, 2012 6:25 PM >>>> To: Bajko Gabor (Nokia-CIC/SiliconValley) >>>> Cc: paws@ietf.org >>>> Subject: Re: [paws] need for DB initialization message >>>> >>>> Related suggestion: Assuming we have a discovery protocol which=20 >>>> can return a URI, the protocol semantics should be such that the=20 >>>> URI can be the final DB URI, or another intermediary in the=20 >>>> process. Thus, the protocol should not lock in that there can be=20 >>>> only 0 or 1 intermediaries in the resolution, but should allow=20 >>>> several. (We already have suggested cases where at least two are=20 >>>> needed, one to determine where you are by asking your vendor, and=20 >>>> one to determine who you can talk to by asking your local=20 >>>> regulator.) >>>> >>>> Yours, >>>> Joel >>>> >>>> On 8/9/2012 8:02 PM, Gabor.Bajko@nokia.com wrote: >>>>> Folks, >>>>> >>>>> During the Vancouver F2F discussions we had some good discussions,=20 >>>>> but no agreement on wether an initialization message, as proposed=20 >>>>> in draft-das is necessary or not. >>>>> >>>>> You may check the minutes to see what was said at the mike: >>>>> http://www.ietf.org/proceedings/84/minutes/minutes-84-paws >>>>> >>>>> People spoke mostly in favor, but there were people who also said=20 >>>>> that this message is redundant with registration message. >>>>> >>>>> Question#1: need for an initialization message >>>>> >>>>> Unfortunately we did not have time to discuss the DB discovery=20 >>>>> aspect, and that may be related to this topic. The only DB=20 >>>>> discovery document available currently,=20 >>>>> http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, >>>>> proposes, that the master device contacts a pre-provisioned=20 >>>>> discovery server and provides its location, and in return the=20 >>>>> discovery server returns the URI of the DB for that regulatory=20 >>>>> domain. At this point, the master device knows which DB to=20 >>>>> contact, but it does not necessarily know what regulatory domain=20 >>>>> that DB belongs to. Thus, it doesn't know what are the operating=20 >>>>> rules, whether it has to authenticate, or register, etc. >>>>> >>>>> Thus, it seems logical to me that the master device first queries=20 >>>>> the DB to find out the regulatory domain. We even have such a=20 >>>>> requirement in the requirement draft, requirement: >>>>> >>>>> "P.3: The protocol MUST support determination of >>>>> regulatory domain governing its current location." >>>>> >>>>> The information about the regulatory domain may be cached, and the=20 >>>>> master device may not need to place that query every time, but=20 >>>>> this message exchange may be necessary in certain cases. Any=20 >>>>> comments to this point? >>>>> >>>>> Question#2 >>>>> >>>>> Then, it is a slightly separate issue, if this message exchange=20 >>>>> has to take place, then what additional information the DB returns. >>>>> draft-das proposes that regulatory domain specific information be=20 >>>>> returned to the master device. >>>>> >>>>> Question#3 >>>>> >>>>> Yet another separate point is that draft-das proposes to use this=20 >>>>> initialization message also to initiate client authentication=20 >>>>> (putting shared secret vs cert issue aside for the time being). In=20 >>>>> cases when the master device does not know the regulatory domain=20 >>>>> it is in, then it does not know whether authentication is required=20 >>>>> in that regulatory domain or not; so why would initiate=20 >>>>> authentication then? Similar comment applies to draft-wei, where=20 >>>>> it is proposed that after DB discovery the master device=20 >>>>> authenticates at TLS layer and performs registration; how does it=20 >>>>> know that it has to authenticate and register, if it doesn't know the= regulatory domain? >>>>> >>>>> In my opinion (chair hat off), the sequence of events should be sg=20 >>>>> like >>>>> this: >>>>> >>>>> 1.DB discovery (may be skipped if cached information available) >>>>> >>>>> 2.Regulatory domain query (may be skipped if cached information >>>>> available) >>>>> >>>>> 3.Authentication (if required) >>>>> >>>>> 4.Registration (if required) >>>>> >>>>> 5.Channel availability query (may be combined with registration?) >>>>> >>>>> Comments are welcome and expected. >>>>> >>>>> -Gabor >>>>> >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Thu Aug 16 15:45:49 2012 Return-Path: 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 E947111E808A for ; Thu, 16 Aug 2012 15:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 L4jECxuyzjIN for ; Thu, 16 Aug 2012 15:45:47 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id C650821F8557 for ; Thu, 16 Aug 2012 15:45:44 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7GMjgT2004224 for ; Fri, 17 Aug 2012 01:45:43 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Aug 2012 01:46:47 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0283.004; Fri, 17 Aug 2012 00:45:41 +0200 From: To: , Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac132A+fbbG4lfLAT8aeYHhnRNTamABfuNkz///KeYD/+nkpcA== Date: Thu, 16 Aug 2012 22:45:40 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB427D@008-AM1MPN1-006.mgdnok.nokia.com> References: <55A5A9A87506CB4BA580BF9D531957DA690227B5@STNTEXCH01.cis.neustar.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Aug 2012 22:46:47.0489 (UTC) FILETIME=[04704310:01CD7C01] X-Nokia-AV: Clean Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 22:45:50 -0000 It seems we have an agreement on the requirement to identify the spectrum, = by using the start/stop frequencies, with optional channel identifiers. Wrt to the schedule, we have so far two proposals, one from Brian proposing= the use of start/stop times for each spectrum unit available, and one from= Vincent proposing to use of Unix Epoch time in seconds. We need to decide = on this, so please send your preference on this topic to the list. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Pro= basco Scott (Nokia-CIC/Dallas) Sent: Monday, August 13, 2012 10:12 AM To: paws@ietf.org Subject: Re: [paws] use cases and requirements document Hi All, Given that we have completed two Working Group Last Call cycles and this ne= xt version will go to the IESG, I hope we could agree on minimal changes to= the document, i.e. changes only to D.7 for this topic. This will ensure th= e proper requirements are established for the developing PAWS protocol. I believe Brian's proposed text captures the essential requirements. Kind Regards, Scott On 8/13/12 8:24 AM, "ext Rosen, Brian" wrote: > >I would prefer to not use the word "channel" in our documents at all=20 >except for the term "channel identifier". I proposed "spectrum unit",=20 >although any other term will do. "Channel" has too much baggage, A=20 >simple editorial change like this is simple, and it's much better to do=20 >it now. > >I think we need power in both the query and the response. In some=20 >domains, it may be that you specify what power you want to use and the=20 >DB tells you what spectrum you can use at that power. In other, a=20 >US-like rule may be in place. Also in either the query or the=20 >registration, we need a device type, which should be an entry from an=20 >IANA registry. This is how you get the US "Mode II" information. > >With regard to schedule, I would like to see two mechanisms >1) a time by which the database should be queried again (which could=20 >represent the next change in schedule) >2) start/stop times for each spectrum unit available > >Both these should be optional in the response. > >My text > >The data model must support specifying spectrum availability. Spectrum=20 >units are specified by low and high frequencies and may have an=20 >optional channel identifier. > >The data model must support a schedule for spectrum unit availability. >Two mechanisms must be supported. The response to spectrum=20 >availability query may include a time by which the database must be=20 >requeried. Each spectrum unit mentioned in the response may be=20 >annotated with start and stop time/date. > > > > -----Original Message----- >From: Eric Chu [mailto:ericchu@google.com] >Sent: Saturday, August 11, 2012 11:43 AM Eastern Standard Time >To: Teco Boot >Cc: Rosen, Brian; paws@ietf.org >Subject: Re: [paws] use cases and requirements document > > >Hi everyone, > >Gathering all the shared points from everyone... I believe below is the=20 >complete list so far: > > > >* What's the best consistent representation of the words "channel >numbers" for non-TV spectrum >* Should we update the entire doc on the topic of =B3channel=B2 or >=B3channel numbers=B2 >* What=B9s the best way to reduce vagueness in whether/how to include >"channel numbers" >* Is the reference to variable power required >* What does channel availability schedule mean > > >Brian's suggestion of replacing every instance of "channel" is=20 >technically correctly. However, it is important for us to focus moving=20 >forward. I would suggest we only work on the normative part of the spec. > The section Gabor is proposing for us to modify... > >On what's the best generic label for the words "channel numbers",=20 >channel identifier might be the most accurate and neutral "label". Though= ts? > >On the question whether variable power is required, based on FCC=20 >adjacent-channel rules, the database may limit the Mode II devices to=20 >100mW for some channels and 40mW for others. Therefore, the data model=20 >needs to support specification of maximum power levels. > >Lastly, with regards to "schedule", the intent is to have a way of=20 >informing devices when to operate for each frequency range. As long as=20 >the data model supports, for example, a list of time ranges, it does=20 >not prevent an implementation from providing a list with 1 entry which=20 >corresponds to the "shortest available". The word "schedule" should be=20 >sufficient to capture this intent? > >We would like to propose the following text to address these points: > >"The Data Model MUST support specifying available spectrum. The Data=20 >Model MUST support specification of this information by start and stop=20 >frequencies and MAY also support specification of this information by=20 >channel identifiers. The Data Model MUST support a=20 >spectrum-availability schedule and maximum power levels for each frequency= range." > > >Thoughts? >Eric > > > >On 8/10/12 5:48 AM, Teco Boot wrote: > > > What about this: > > =B3The Data Model MUST support specifying a list of available=20 >channels. The Data Model MUST support specification of this information=20 >by start and stop frequencies, or equivalents such as center=20 >frequencies with channel width or channel numbers with channel nummer=20 >allocation scheme . The Data Model MUST support a channel availability=20 >schedule and maximum power level for each channel in the list.=B2 > =20 > More thoughts on channel numbers: we likely run into problems in=20 >bands without a channel numbering scheme, or for example sub channels=20 >in TV bands. > > Teco > > > Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende geschreven: > > > > While I don't care if it's center and width or upper/lower, I=20 >do think we will define the format in the protocol for interoperability=20 >reasons, but don't need to do that in requirements. It wouldn't hurt=20 >to decide now and use consistent terms, but we don't need to. > > I think "band" won't work, as it usually implies a much wider=20 >piece of spectrum that has a common purpose. The TV Band is all the=20 >channels. > > > On Aug 10, 2012, at 2:37 AM, Teco Boot wrote: > > > (somewhat late response) > > A center frequency and channel width is functional=20 >equivalent to start/stop frequencies. So is channel number, with ref to=20 >channel number assignment scheme. For a requirements document, we just=20 >need to specify what is needed. How it is encoded (Hz, wave length,=20 >channel ID) is solution space. > > Seen our goal to make PAWS somewhat universal (not limited=20 >to US TVWS), I do not prefer using channel numbers. > > Teco > > > Op 9 aug. 2012, om 21:55 heeft =20 > het volgende geschreven: > > > Folks, > =20 > During the last F2F meeting, there was an agreement to=20 >make a slight update to requirement D.7 in=20 >http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.t >xt, to make channel numbers optional to be supported. Ie, change the=20 >current >D.7 > =B3The Data Model MUST support specifying a list of=20 >available channels. The Data Model MUST support specification of this=20 >information by channel numbers and by start and stop frequencies. The=20 >Data Model MUST support a channel availability schedule and maximum=20 >power level for each channel in the list.=B2 > to > =B3The Data Model MUST support specifying a list of=20 >available channels. The Data Model MUST support specification of this=20 >information by start and stop frequencies and MAY include channel=20 >numbers. The Data Model MUST support a channel availability schedule=20 >and maximum power level for each channel in the list.=B2 > =20 > I=B9d like to confirm this change on the list. If anyone=20 >has any objections, let me know. Otherwise I=B9ll plan to send the=20 >document to the iesg after this change is implemented. > =20 > - Gabor > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > =20 > =20 > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > =20 > > > > > =20 > =20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > =20 > > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Thu Aug 16 16:11:51 2012 Return-Path: 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 1FEE321E803F for ; Thu, 16 Aug 2012 16:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 VaSPsFTgtwgV for ; Thu, 16 Aug 2012 16:11:47 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 42CAB11E809A for ; Thu, 16 Aug 2012 16:11:46 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7GNBgJ2015670 for ; Fri, 17 Aug 2012 02:11:43 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Aug 2012 02:12:46 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0283.004; Fri, 17 Aug 2012 01:11:40 +0200 From: To: Thread-Topic: [paws] need for DB initialization message Thread-Index: Ac12he0A+5h4j+uqT6e4F6BpK7EzX///7O8A//TyocA= Date: Thu, 16 Aug 2012 23:11:40 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB4298@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F@008-AM1MPN1-006.mgdnok.nokia.com> <7EE3F6BC-E8AB-4C28-B221-1D6E64324D0A@neustar.biz> In-Reply-To: <7EE3F6BC-E8AB-4C28-B221-1D6E64324D0A@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB4298008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 16 Aug 2012 23:12:46.0856 (UTC) FILETIME=[A5E4C880:01CD7C04] X-Nokia-AV: Clean Subject: Re: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 23:11:51 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB4298008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This thread was a bit derailed, so I'd like to get back to the original que= stion, which was whether we need a DB initialization message as proposed in= draft-das or not. We seem to converge on the discovery of the regulatory domain, ie that the = regulatory domain can be discovered during the DB discovery process, and we= do not need a separate message to ask the DB what regulatory domain the ma= ster is in. Then, the question is whether the masters need to contact the DB prior to a= ny other communication, to learn the operating rules for that regulatory do= main. The alternative would be that the masters are preconfigured with the = operating rules for the regulatory domains they are going to operate in. In the F2F, there were opinions on both sides, but not enough to call a con= sensus. So, please send your preference on the need for DB initialization, = to the list. We need to make a decision on this and some other issues, so w= e could move forward creating a wg document. - Gabor From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Thursday, August 09, 2012 5:15 PM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: paws@ietf.org Subject: Re: [paws] need for DB initialization message I'm not so sure you need something separate for domain. ISTM that the DB d= iscovery could return it (possibly as a parameter on the DB URI). OTOH, yo= u might very well want to receive from the DB some kind of data specificati= on (that is, what is required to be provided in the registration), rather t= han having it totally wired in to domain. That means, to me, that the regi= stration is a 4 way message exchange: 1. Device to DB: Authenticate me please 2. DB to device: Authentication accepted, send me this data 3. Device to DB: Here is my registration data 4. DB to device: Registration succeeded. Now, having said that, you might just get authentication out of the TLS ses= sion establishment, this not needing step 1. Brian On Aug 9, 2012, at 8:02 PM, > wrote: Folks, During the Vancouver F2F discussions we had some good discussions, but no a= greement on whether an initialization message, as proposed in draft-das is = necessary or not. You may check the minutes to see what was said at the mike: http://www.ietf= .org/proceedings/84/minutes/minutes-84-paws People spoke mostly in favor, but there were people who also said that this= message is redundant with registration message. Question#1: need for an initialization message Unfortunately we did not have time to discuss the DB discovery aspect, and = that may be related to this topic. The only DB discovery document available= currently, http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, pr= oposes, that the master device contacts a pre-provisioned discovery server = and provides its location, and in return the discovery server returns the U= RI of the DB for that regulatory domain. At this point, the master device k= nows which DB to contact, but it does not necessarily know what regulatory = domain that DB belongs to. Thus, it doesn't know what are the operating rul= es, whether it has to authenticate, or register, etc. Thus, it seems logical to me that the master device first queries the DB to= find out the regulatory domain. We even have such a requirement in the req= uirement draft, requirement: "P.3: The protocol MUST support determination of regulatory d= omain governing its current location." The information about the regulatory domain may be cached, and the master d= evice may not need to place that query every time, but this message exchang= e may be necessary in certain cases. Any comments to this point? Question#2 Then, it is a slightly separate issue, if this message exchange has to take= place, then what additional information the DB returns. draft-das proposes= that regulatory domain specific information be returned to the master devi= ce. Question#3 Yet another separate point is that draft-das proposes to use this initializ= ation message also to initiate client authentication (putting shared secret= vs cert issue aside for the time being). In cases when the master device d= oes not know the regulatory domain it is in, then it does not know whether = authentication is required in that regulatory domain or not; so why would i= nitiate authentication then? Similar comment applies to draft-wei, where it= is proposed that after DB discovery the master device authenticates at TLS= layer and performs registration; how does it know that it has to authentic= ate and register, if it doesn't know the regulatory domain? In my opinion (chair hat off), the sequence of events should be sg like thi= s: 1. DB discovery (may be skipped if cached information available) 2. Regulatory domain query (may be skipped if cached information avai= lable) 3. Authentication (if required) 4. Registration (if required) 5. Channel availability query (may be combined with registration?) Comments are welcome and expected. - Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB4298008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This thread was a bit der= ailed, so I’d like to get back to the original question, which was wh= ether we need a DB initialization message as proposed in draft-das or not.

 <= /p>

We seem to converge on th= e discovery of the regulatory domain, ie that the regulatory domain can be = discovered during the DB discovery process, and we do not need a separate message to ask the DB what regulatory domain the master is= in.

 <= /p>

Then, the question is whe= ther the masters need to contact the DB prior to any other communication, t= o learn the operating rules for that regulatory domain. The alternative would be that the masters are preconfigured with the opera= ting rules for the regulatory domains they are going to operate in.

 <= /p>

In the F2F, there were op= inions on both sides, but not enough to call a consensus. So, please send y= our preference on the need for DB initialization, to the list. We need to make a decision on this and some other issues, so we coul= d move forward creating a wg document.

 <= /p>

- =          Gabor<= /span>

 <= /p>

From: ext Rose= n, Brian [mailto:Brian.Rosen@neustar.biz]
Sent: Thursday, August 09, 2012 5:15 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: paws@ietf.org
Subject: Re: [paws] need for DB initialization message

 

<as individual>

I'm not so sure you need something separate for doma= in.  ISTM that the DB discovery could return it (possibly as a paramet= er on the DB URI).  OTOH, you might very well want to receive from the= DB some kind of data specification (that is, what is required to be provided in the registration), rather than having i= t totally wired in to domain.  That means, to me, that the registratio= n is a 4 way message exchange:

1. Device to DB: Authenticate me please

2. DB to device: Authentication accepted, send me th= is data

3. Device to DB: Here is my registration data

4. DB to device: Registration succeeded.<= /p>

 

Now, having said that, you might just get authentica= tion out of the TLS session establishment, this not needing step 1.

 

Brian

 

On Aug 9, 2012, at 8:02 PM, <Gabor.Bajko@nokia.com> wrote:



Folks,

 

During the Vancouver F2F discussions we= had some good discussions, but no agreement on whether an initialization m= essage, as proposed in draft-das is necessary or not.

You may check the minutes to see what w= as said at the mike: http://www.ietf.org/proceedings/84/minutes/minutes-84-= paws

 

People spoke mostly in favor, but there= were people who also said that this message is redundant with registration= message.

 

Question#1: need for an initialization = message

Unfortunately we did not have time to d= iscuss the DB discovery aspect, and that may be related to this topic. The = only DB discovery document available currently, http://www.ietf.org/id/dra= ft-probasco-paws-discovery-01.txt, proposes, that the master device contacts a pre-provisioned discovery serv= er and provides its location, and in return the discovery server returns th= e URI of the DB for that regulatory domain. At this point, the master devic= e knows which DB to contact, but it does not necessarily know what regulatory domain that DB belongs to. Th= us, it doesn’t know what are the operating rules, whether it has to a= uthenticate, or register, etc.

Thus, it seems logical to me that the m= aster device first queries the DB to find out the regulatory domain. We eve= n have such a requirement in the requirement draft, requirement:=

“P.3:   The protocol MU= ST support determination of regulatory      &= nbsp;      domain governing its current location.&= #8221;

The information about the regulatory do= main may be cached, and the master device may not need to place that query = every time, but this message exchange may be necessary in certain cases. Any comments to this point?

 

Question#2

Then, it is a slightly separate issue, = if this message exchange has to take place, then what additional informatio= n the DB returns. draft-das proposes that regulatory domain specific information be returned to the master device.

 

Question#3

Yet another separate point is that draf= t-das proposes to use this initialization message also to initiate client a= uthentication (putting shared secret vs cert issue aside for the time being). In cases when the master device does not know the reg= ulatory domain it is in, then it does not know whether authentication is re= quired in that regulatory domain or not; so why would initiate authenticati= on then? Similar comment applies to draft-wei, where it is proposed that after DB discovery the master devi= ce authenticates at TLS layer and performs registration; how does it know t= hat it has to authenticate and register, if it doesn’t know the regul= atory domain?

 

In my opinion (chair hat off), the sequ= ence of events should be sg like this:

 

1.<= span style=3D"font-size:7.0pt">       DB discovery (may be skipped if cached information available)

2.<= span style=3D"font-size:7.0pt">       Regulatory domain query (may be skipped if cached information available)

3.<= span style=3D"font-size:7.0pt">       Authenticati= on (if required)

4.<= span style=3D"font-size:7.0pt">       Registration (if required)

5.<= span style=3D"font-size:7.0pt">       Channel availability query (may be combined with registration?)<= /p>

 

Comments are welcome and expected.=

 

-       &nb= sp;  Gabor

 

 

 

_____________________________________= __________
paws mailing list
paws@ietf.org=
https://www.ietf.org/mailman/listinfo/paws

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB4298008AM1MPN1006mg_-- From Gabor.Bajko@nokia.com Thu Aug 16 16:26:08 2012 Return-Path: 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 CB97021F8582 for ; Thu, 16 Aug 2012 16:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, 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 j7iUY+lvYgLC for ; Thu, 16 Aug 2012 16:26:08 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id BBA7421F8569 for ; Thu, 16 Aug 2012 16:26:07 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7GNPuxv009728; Fri, 17 Aug 2012 02:25:58 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Aug 2012 02:27:01 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Fri, 17 Aug 2012 01:25:55 +0200 From: To: , , Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Ie7Nd2WNzPm0+85/tpR52R7QAAU/5DAJlUv6A= Date: Thu, 16 Aug 2012 23:25:54 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB42CD@008-AM1MPN1-006.mgdnok.nokia.com> References: <55A5A9A87506CB4BA580BF9D531957DA690227BD@STNTEXCH01.cis.neustar.com> In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA690227BD@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Aug 2012 23:27:01.0806 (UTC) FILETIME=[A37BCCE0:01CD7C06] X-Nokia-AV: Clean Cc: paws@ietf.org 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 23:26:08 -0000 We have not heard any objections for using JSON encoding instead of XML.=20 Therefore, let's go for JSON, and close this thread. - Gabor -----Original Message----- From: 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' Subject: Re: [paws] XML schema versus JSON, vCard & iCal json is okay with me. =20 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org) and seem to be reasona= bly light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth = 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. =09 On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" =09 wrote: =09 >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" 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 kee= p >>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 Notatio= n >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws =09 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws =09 --=20 -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From weixinpeng@huawei.com Thu Aug 16 18:31:25 2012 Return-Path: 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 A5CAA21F84D5 for ; Thu, 16 Aug 2012 18:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[AWL=1.971, BAYES_00=-2.599, 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 aYf9BsjzToVN for ; Thu, 16 Aug 2012 18:31:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E3E5B21F84D4 for ; Thu, 16 Aug 2012 18:31:21 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJM08294; Thu, 16 Aug 2012 17:31:21 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 18:30:25 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 18:30:23 -0700 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.130]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Fri, 17 Aug 2012 09:28:35 +0800 From: Weixinpeng To: "Gabor.Bajko@nokia.com" , "Brian.Rosen@neustar.biz" , "vchen@google.com" , "peter@spectrumbridge.com" Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Ie7Nd2WNzPm0+85/tpR52R7QAAU/5DAJlUv6AAA5y+MA== Date: Fri, 17 Aug 2012 01:28:34 +0000 Message-ID: References: <55A5A9A87506CB4BA580BF9D531957DA690227BD@STNTEXCH01.cis.neustar.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB42CD@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB42CD@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 01:31:25 -0000 Hi all,=20 I am not sure whether there is something in JSON to define the value type = or the range of value, because in XML=20 the type and the value range of every element can be defined exactly. Is it= necessary to deal this in XML/JSON ? --Xinpeng Wei -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gab= or.Bajko@nokia.com Sent: Friday, August 17, 2012 7:26 AM To: Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com Cc: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal We have not heard any objections for using JSON encoding instead of XML.=20 Therefore, let's go for JSON, and close this thread. - Gabor -----Original Message----- From: 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' Subject: Re: [paws] XML schema versus JSON, vCard & iCal json is okay with me. =20 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org) and seem to be reasona= bly light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth = 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. =09 On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" =09 wrote: =09 >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" 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 kee= p >>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 Notatio= n >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws =09 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws =09 --=20 -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From mksaji@yahoo.com Thu Aug 16 19:37:49 2012 Return-Path: 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 F1E2A21F84C4 for ; Thu, 16 Aug 2012 19:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] 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 cPkB1jBsMV8W for ; Thu, 16 Aug 2012 19:37:47 -0700 (PDT) Received: from nm2-vm0.bullet.mail.ne1.yahoo.com (nm2-vm0.bullet.mail.ne1.yahoo.com [98.138.91.39]) by ietfa.amsl.com (Postfix) with ESMTP id 80B9421F84B6 for ; Thu, 16 Aug 2012 19:37:47 -0700 (PDT) Received: from [98.138.90.50] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 17 Aug 2012 02:37:38 -0000 Received: from [98.138.89.234] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 17 Aug 2012 02:37:38 -0000 Received: from [127.0.0.1] by omp1049.mail.ne1.yahoo.com with NNFMP; 17 Aug 2012 02:37:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 773586.38857.bm@omp1049.mail.ne1.yahoo.com Received: (qmail 310 invoked by uid 60001); 17 Aug 2012 02:37:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345171058; bh=q4d0qzjL3yxnpH27Wm9jBKrotH/nLnJm1Rq82k19qe0=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=O88MesUNbV+VEhRy3CipRKyWK3216KwJZ0NvttM8jmxLN+PyGW31wpUoL3w/M+lmszFDX1ibL6h77VJVcnzIvTKyko46k4/tnUbb9zlE9wblF3D0KwOXA/80GCKj1bGDic262yIk+O64lVgL2JRNMZ1ysyTWTaa5ZaZ59DaHQH0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ezJ0AoADOWmM6PosFkyWISc3cjmV4DtRgpuCvoH4IpRW2pQWgEHm4+LSWXadntl6zu4H/REPJZTZh6v0K8mbzdpHvlkODeC2F1OSa1ZtaBx0UeRB6SpyET6jUfc0WhCRjeoiae/iylfMGZ3Qvymg1dVhLDnAv4o1G8nCIOYH1xw=; X-YMail-OSG: IC.FtzYVM1mPfCAbx0KdOQ43ZFgLT4j2aPuKr37SMhGLyBc R9cvGBW.c7H1y.PRyJ.w_yCj7rn6WMX5S2ydxwOi4ibUyeSOZy69Iqkhe7Xn aCzYJKVy_R_jaurTcYsqb8bywRnfI8ZnQd.JT8BxVV3znP94CdR43GiHjH13 .KRXtxSWvsrVf5ABKFQIh1E4RNXORnuX96NUwvlVp2MmtRystFGaTK.ey1JY 5tZHcm.nPuQpvTsNRMxKym1Rn8v0LyPBXU_1l3GjJ7ak3nB9oMTIovJeOvDX gP94hi0mcdLouvBMx8ieftrPkTMOUYjEXFlvtM.TAuBSOJ.Ugtpve9lDiR3z Y7MdJZbjYjSKMnFnNDhjgfTcIAdh7LSOWnmpR40t0zaO871zLofi7dvbxqx. OXLcGZeMaEWeL1s5.8OD9Y.PTnGV6_zVyhpOG3v7FAoWlha9lgwSuMyFH6Pc 2OKQPrXAiSkj6CVXeX4.t.6zxkkU0ts7e3Gu_WtR2OsRWWJasCBehpndc0hf wFRw8B_ScC42FYqj10wgLqnZi2pC9eaF2zIvdDoXXcCAFmlCAi69ypXG8yzw qKp0cqCK7O7PwsfZAKt8SZfwNce71iRNbJQ-- Received: from [117.192.27.110] by web120305.mail.ne1.yahoo.com via HTTP; Thu, 16 Aug 2012 19:37:38 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <55A5A9A87506CB4BA580BF9D531957DA690227BD@STNTEXCH01.cis.neustar.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB42CD@008-AM1MPN1-006.mgdnok.nokia.com> Message-ID: <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com> Date: Thu, 16 Aug 2012 19:37:38 -0700 (PDT) From: Manikkoth Sajeev To: "Gabor.Bajko@nokia.com" , "Brian.Rosen@neustar.biz" , "vchen@google.com" , "peter@spectrumbridge.com" In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB42CD@008-AM1MPN1-006.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1278015569-1293688795-1345171058=:97121" Cc: "paws@ietf.org" Subject: Re: [paws] XML schema versus JSON, vCard & iCal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Manikkoth Sajeev List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 02:37:49 -0000 ---1278015569-1293688795-1345171058=:97121 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0A=A0=0ACan it not be both JSON and XML supported? I would vote for tha= t. Future implementations may prefer XML as it is generic,=A0omni present, = easy to understand and validate. For compactness may be a=A0 binary xml opt= ion can also work. JSON I think will necessitate implementation to be nativ= e Java and may not be as friendly with other implementation languages.=0A= =0ABest Regards,=0ASajeev Manikkoth=0AMobile: +918792292002=0AEmail: mksaji= @ieee.org=0Ahttp://www.linkedin.com/in/mksajeev=0A=0A=0A =0A=0A____________= ____________________=0A From: "Gabor.Bajko@nokia.com" =0ATo: Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.co= m =0ACc: paws@ietf.org =0ASent: Friday, 17 August 2012, 4:55=0ASubject: Re:= [paws] XML schema versus JSON, vCard & iCal=0A =0AWe have not heard any o= bjections for using JSON encoding instead of XML. =0ATherefore, let's go fo= r JSON, and close this thread.=0A=0A- Gabor=0A=0A-----Original Message-----= =0AFrom: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = ext Rosen, Brian=0ASent: Monday, August 13, 2012 3:14 PM=0ATo: 'Vincent Che= n'; 'Peter Stanforth'=0ACc: 'paws@ietf.org'=0ASubject: Re: [paws] XML schem= a versus JSON, vCard & iCal=0A=0Ajson is okay with me.=A0 =0AI'd prefer an = ISO time stamp rather than a time in seconds since epoch.=A0 It's very easy= to parse, and its simpler to use and debug.=A0 Don't care a whole lot abou= t that=0A=0ABrian =0A=0A=0A=0A-----Original Message-----=0AF= rom: =A0=A0=A0 Vincent Chen [mailto:vchen@google.com]=0ASent:=A0=A0=A0 Mond= ay, August 13, 2012 06:04 PM Eastern Standard Time=0ATo:=A0=A0=A0 Peter Sta= nforth=0ACc:=A0=A0=A0 Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.= org=0ASubject:=A0=A0=A0 Re: [paws] XML schema versus JSON, vCard & iCal=0A= =0AXML vs JSON=0A=0ABetween XML and JSON, JSON messages are more compact an= d easier to process (parsing, synthesis). As clarification, JSON does not r= equire JavaScript or a Browser. It is a text-based representation of data t= hat is language independent, yet well-matched to all major languages. JSON-= handling libraries exist for numerous languages (see of http://json.org/) a= nd seem to be reasonably light weight.=0A=0ATimestamps=0A=0AAs for timestam= p specifications, should we consider just using seconds since the UNIX Epoc= h (1970-01-01T00:00:00Z)? This would eliminate the need for datetime-string= parsing on devices, assuming devices already have native libraries that pr= ovide time in this format. Is that a valid assumption? Of course, this is l= ess human-readable....=0A=0A=0AOn Mon, Aug 13, 2012 at 6:49 AM, Peter Stanf= orth wrote:=0A=0A=0A=A0=A0=A0 Whenever we built = mobile devices we never dealt with IETF, in our sensor=0A=A0=A0=A0 days eve= n an IP stack was a challenge,so I would defer to the device guys=0A=A0=A0= =A0 on that one.=0A=A0=A0=A0 =0A=A0=A0=A0 On MonAug/13/12 Mon Aug 13, 9:30 = AM, "Rosen, Brian"=0A=A0=A0=A0 =0A=A0=A0=A0 wrote= :=0A=A0=A0=A0 =0A=A0=A0=A0 >Our experience in the IETF over many years is t= hat economizing message=0A=A0=A0=A0 >size and compromising utility and secu= rity in search of efficiency of=0A=A0=A0=A0 >implementation on small device= s is a poor trade off.=A0 I am not advocating=0A=A0=A0=A0 >being wasteful o= f resources, but I don't think we should seriously=0A=A0=A0=A0 >consider th= e overhead of XML or json to be significant.=0A=A0=A0=A0 >=0A=A0=A0=A0 >Ass= uming a json library can be loaded on a small device is reasonable.=0A=A0= =A0=A0 >=0A=A0=A0=A0 >Brian (as individual)=0A=A0=A0=A0 >=0A=A0=A0=A0 >=0A= =A0=A0=A0 >=0A=A0=A0=A0 > -----Original Message-----=0A=A0=A0=A0 >From:=A0 = Peter Stanforth [mailto:peter@spectrumbridge.com]=0A=A0=A0=A0 >Sent:=A0 Sat= urday, August 11, 2012 07:13 AM Eastern Standard Time=0A=A0=A0=A0 >To:=A0 = =A0 Teco Boot; Benjamin A.Rolfe=0A=A0=A0=A0 >Cc:=A0 =A0 paws@ietf.org=0A=A0= =A0=A0 >Subject:=A0 =A0 =A0 Re: [paws] XML schema versus JSON, vCard & iCa= l=0A=A0=A0=A0 >=0A=A0=A0=A0 >Not all masters run over the core network.=0A= =A0=A0=A0 >Some of the Use cases have a master talking to another OTA=0A=A0= =A0=A0 >We should not assume that all Masters are attached to utility power= so we=0A=A0=A0=A0 >should be sympathetic to processing energy use also.=0A= =A0=A0=A0 >=0A=A0=A0=A0 >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <= teco@inf-net.nl> wrote:=0A=A0=A0=A0 >=0A=A0=A0=A0 >>=0A=A0=A0=A0 >>Op 10 au= g. 2012, om 18:10 heeft Benjamin A. Rolfe het volgende=0A=A0=A0=A0 >>geschr= even:=0A=A0=A0=A0 >>=0A=A0=A0=A0 >>> Compactness of messages is important, = but it is also important (to me=0A=A0=A0=A0 >>>at least) to be realizable i= n an implementation with limited resources,=0A=A0=A0=A0 >>>such as embedded= devices in what are now popularly called "M2M"=0A=A0=A0=A0 >>>applications= .=A0 A lot of these devices could use IP all the end to end,=0A=A0=A0=A0 >>= >but may have a very compact, simple stack and applications (i.e.=A0 no=0A= =A0=A0=A0 >>>browser).=A0 Is JSON typically implemented when there is no br= owser?=0A=A0=A0=A0 >>>Would it be hard to do in a resource constrained devi= ce (i.e. where we=0A=A0=A0=A0 >>>talk about memory size in Kilo-bytes still= ).=0A=A0=A0=A0 >>=0A=A0=A0=A0 >>In use cases and requirements document, the= re are no requirements for=0A=A0=A0=A0 >>protocol performance. I guess OS/I= P/TCP/TLS code size supersedes needs=0A=A0=A0=A0 >>for JSON or XML.=0A=A0= =A0=A0 >>=0A=A0=A0=A0 >>Same for timing: TCP/TLS connection setup will take= more than the PAWS=0A=A0=A0=A0 >>message exchange, I think. This may be of= importance when using satcom=0A=A0=A0=A0 >>links.=0A=A0=A0=A0 >>=0A=A0=A0= =A0 >>Because PAWS runs between master and database, over core network,=0A= =A0=A0=A0 >>performance is not our primary concern. But as always, it is go= od to keep=0A=A0=A0=A0 >>an eye on efficiency.=0A=A0=A0=A0 >>=0A=A0=A0=A0 >= >Teco=0A=A0=A0=A0 >>=0A=A0=A0=A0 >>> Thanks=0A=A0=A0=A0 >>> Ben=0A=A0=A0=A0= >>>=0A=A0=A0=A0 >>>=0A=A0=A0=A0 >>>> We had a discussion on XML vs. JSON. = I prefer the one with most=0A=A0=A0=A0 >>>>compact messages.=0A=A0=A0=A0 >>= >>=0A=A0=A0=A0 >>>> On vCard and JSON: what is the status of "A JavaScript = Object Notation=0A=A0=A0=A0 >>>>(JSON) Representation for vCard"?=0A=A0=A0= =A0 >>>> http://tools.ietf.org/html/draft-bhat-vcarddav-json-00=0A=A0=A0=A0= >>>>=0A=A0=A0=A0 >>>> On valid times: can we use same format as certificat= es? They have=0A=A0=A0=A0 >>>>similar simple requirements: valid notBefore&= =A0 notAfter.=0A=A0=A0=A0 >>>> http://tools.ietf.org/html/rfc3280#section-4= .1.2.5=0A=A0=A0=A0 >>>>=0A=A0=A0=A0 >>>> Teco=0A=A0=A0=A0 >>>> ____________= ___________________________________=0A=A0=A0=A0 >>>> paws mailing list=0A= =A0=A0=A0 >>>> paws@ietf.org=0A=A0=A0=A0 >>>> https://www.ietf.org/mailman/= listinfo/paws=0A=A0=A0=A0 >>>>=0A=A0=A0=A0 >>>=0A=A0=A0=A0 >>> ____________= ___________________________________=0A=A0=A0=A0 >>> paws mailing list=0A=A0= =A0=A0 >>> paws@ietf.org=0A=A0=A0=A0 >>> https://www.ietf.org/mailman/listi= nfo/paws=0A=A0=A0=A0 >>=0A=A0=A0=A0 >>_____________________________________= __________=0A=A0=A0=A0 >>paws mailing list=0A=A0=A0=A0 >>paws@ietf.org=0A= =A0=A0=A0 >>https://www.ietf.org/mailman/listinfo/paws=0A=A0=A0=A0 >=0A=A0= =A0=A0 >_______________________________________________=0A=A0=A0=A0 >paws m= ailing list=0A=A0=A0=A0 >paws@ietf.org=0A=A0=A0=A0 >https://www.ietf.org/ma= ilman/listinfo/paws=0A=A0=A0=A0 =0A=A0=A0=A0 ______________________________= _________________=0A=A0=A0=A0 paws mailing list=0A=A0=A0=A0 paws@ietf.org= =0A=A0=A0=A0 https://www.ietf.org/mailman/listinfo/paws=0A=A0=A0=A0 =0A=0A= =0A=0A=0A-- =0A-vince=0A=0A_______________________________________________= =0Apaws mailing list=0Apaws@ietf.org=0Ahttps://www.ietf.org/mailman/listinf= o/paws=0A_______________________________________________=0Apaws mailing lis= t=0Apaws@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/paws ---1278015569-1293688795-1345171058=:97121 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
 
Can it not be both JSON and XML supported? I would vote for that. Futur= e implementations may prefer XML as it is generic, omni presen= t, easy to understand and validate. For compactness may be a = binary xml option can also work. JSON I think will necess= itate implementation to be native Java and may not be as friendly with othe= r implementation languages.
 
Best Regards,
Sajeev Ma= nikkoth
Mobile: +918792292002
Email: mksaji@ieee.org
http://www.linkedin.com/in/mksajeev

From: "Gabor.Bajko@nokia.com" &l= t;Gabor.Bajko@nokia.com>
To: Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.c= om
Cc: paws@ietf.org <= br> Sent: Friday, 17 Augus= t 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 Messa= ge-----
From: paws-bounces@ietf.org [mailto:paws-bounc= es@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'
= 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:  &= nbsp;  Vincent Chen [mailto:vchen@google.com]
Sent:  &nb= sp; Monday, August 13, 2012 06:04 PM Eastern Standard Time
To: &nbs= p;  Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; = Benjamin A.Rolfe; paws@ietf.org
Subject:    Re: [paws] XML sch= ema versus JSON, vCard & iCal

XML vs JSON

Between XML and= JSON, JSON messages are more compact and easier to process (parsing, synth= esis). As clarification, JSON does not require JavaScript or a Browser. It = is a text-based representation of data that is language independent, yet we= ll-matched to all major languages. JSON-handling libraries exist for numero= us languages (see of http://json.org/) and seem to be reasonably light we= ight.

Timestamps

As for timestamp specifications, should we c= onsider just using seconds since the UNIX Epoch (1970-01-01T00:00:00Z)? Thi= s 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 <pete= r@spectrumbridge.com> wrote:


    Whenever = we built mobile devices we never dealt with IETF, in our sensor
 &n= bsp;  days even an IP stack was a challenge,so I would defer to the de= vice guys
    on that one.
   
&nbs= p;   On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"
   
    <Brian.R= osen@neustar.biz> wrote:
   
   = ; >Our experience in the IETF over many years is that economizing messag= e
    >size and compromising utility and security in s= earch of efficiency of
    >implementation on small de= vices is a poor trade off.  I am not advocating
    = >being wasteful of resources, but I don't think we should seriously
&= nbsp;   >consider the overhead of XML or json to be significan= t.
    >
    >Assuming a json lib= rary can be loaded on a small device is reasonable.
    &= gt;
    >Brian (as individual)
    &= gt;
    >
    >
    > -----Original Message-----
  =   >From:  Peter Stanforth [mailto:peter@spectrumb= ridge.com]
    >Sent:  Saturday, August 11, 2= 012 07:13 AM Eastern Standard Time
    >To:  &nbs= p; Teco Boot; Benjamin A.Rolfe
    >Cc:    <= a href=3D"mailto:paws@ietf.org" ymailto=3D"mailto:paws@ietf.org">paws@ietf.= org
    >Subject:      Re: [paws] = XML schema versus JSON, vCard & iCal
    >
&nbs= p;   >Not all masters run over the core network.
 &nbs= p;  >Some of the Use cases have a master talking to another OTA
=     >We should not assume that all Masters are attached t= o utility power so we
    >should be sympathetic to processing energy use also.
    >
  &nbs= p; >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <teco@inf-net.nl&= gt; wrote:
    >
    >>
&nb= sp;   >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe h= et volgende
    >>geschreven:
   = >>
    >>> Compactness of messages is imp= ortant, but it is also important (to me
    >>>a= t least) to be realizable in an implementation with limited resources,
&= nbsp;   >>>such as embedded devices in what are now popu= larly 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 t= ypically implemented when there is no browser?
    >&g= t;>Would it be hard to do in a resource constrained device (i.e. where w= e
    >>>talk about memory size in Kilo-bytes st= ill).
    >>
    >>In use c= ases and requirements document, there are no requirements for
 &nbs= p;  >>protocol performance. I guess OS/IP/TCP/TLS code size supe= rsedes needs
    >>for JSON or XML.
  =   >>
    >>Same for timing: TCP/TLS conn= ection setup will take more than the PAWS
    >>mes= sage exchange, I think. This may be of importance when using satcom
&nbs= p;   >>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
    >>a= n eye on efficiency.
    >>
    &= gt;>Teco
    >>
    >>&g= t; Thanks
    >>> Ben
    >= >>
    >>>
    >>&= gt;> 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
    &= gt;>>>(JSON) Representation for vCard"?
    >= >>> 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 notBe= fore&  notAfter.
    >>>> http= ://tools.ietf.org/html/rfc3280#section-4.1.2.5
    &g= t;>>>
    >>>> Teco
  &= nbsp; >>>> _______________________________________________
&= nbsp;   >>>> paws mailing list
    = >>>> paws@ietf.org
    >>>> https://www.ietf.org/mailman/listinfo/paws
 =    >>>>
    >>>
 &= nbsp;  >>> _______________________________________________    >>> paws mailing list
    &g= t;>> paws@ietf.org
    >>> https://www.ietf.org/m= ailman/listinfo/paws
    >>
  &nbs= p; >>_______________________________________________
  &= nbsp; >>paws mailing list
    >>paws@ietf.org
&= nbsp;   >>https://www.ietf.org/mailman/listinfo/paws
 =    >
    >_______________________________= ________________
    >paws mailing list
  = ;  >paws@ietf.org
    >https://www.ietf.org/mailman/l= istinfo/paws
   
    _____________= __________________________________
    paws mailing list<= br>    paws@ietf.org
    https://www.ietf.org/mai= lman/listinfo/paws
   




--
-vi= nce

_______________________________________________
paws mailing = list
paws@ietf.o= rg
https://www.ietf.org/mailman/listinfo/paws
_________________= ______________________________
paws mailing list
paws@ietf.org
https://w= ww.ietf.org/mailman/listinfo/paws


---1278015569-1293688795-1345171058=:97121-- From mksaji@yahoo.com Thu Aug 16 19:41:49 2012 Return-Path: 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 3633D21F848A for ; Thu, 16 Aug 2012 19:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 s2XLGVxd5NPI for ; Thu, 16 Aug 2012 19:41:32 -0700 (PDT) Received: from nm4-vm1.bullet.mail.ne1.yahoo.com (nm4-vm1.bullet.mail.ne1.yahoo.com [98.138.91.44]) by ietfa.amsl.com (Postfix) with SMTP id 30C6521F8471 for ; Thu, 16 Aug 2012 19:41:32 -0700 (PDT) Received: from [98.138.90.50] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 17 Aug 2012 02:41:28 -0000 Received: from [98.138.89.233] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 17 Aug 2012 02:41:28 -0000 Received: from [127.0.0.1] by omp1048.mail.ne1.yahoo.com with NNFMP; 17 Aug 2012 02:41:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 439963.99340.bm@omp1048.mail.ne1.yahoo.com Received: (qmail 29888 invoked by uid 60001); 17 Aug 2012 02:41:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345171288; bh=X4ntsiIdrqlIb6gaYw/UxoS3lWiMhpstLNNKzpfaE5U=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=NeIl2VG/oDPDVRNdtFKy8bo0EreniAvJAtFfM+6rZJzfM6OS7GNoyaxjGMaR3QwNQqIeAX4hFzcOO3bqYjJXIK6xE0yBlKgfbxzhMaZsF3fBe8YT2S6CGF7jN/ziPACCKjv3JisO8Xj9aBdDX0dbF0mtQFrsw0QCi4EC5qxqT7k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=g9utiazyx65z2OpCakgIci+QVmIOv28KBxEtCZQrDM/g1XxaQD6A+TJViYq2wDdlDe8lyau4e1ygV4alcddQg3mrQ2wy+nRXt1yH6yJrLhl3laSlFHkikDDf3AWXcWdui2aEcmpqKltf8/d8nFNZbMnPR98XEjFbtN/zGH2X0+M=; X-YMail-OSG: pTUfjpAVM1l9d0xpdO0d34MSvLYepGeo6Hxn6Og2W96p34C o1QSbZFpnnwaClefGQEffEkfYZ0l8LE3W6Hf.OPWum.te9LglwmsxHjOZVkA BTZTQRNZlcFOA7poLqT2LJYCQ.9yrWyICR75Kv9XBxd0j4Rfsopr8y18ZUEz LIhIWGyXOgq9lgcYxqUtml7F2iM_4XlZ_k.7vMKXMHakWNP_9h6CmmtWL64E YKhEFHZgmOHdcNB1ZxdvxIvmPpRCq2IOD7TOSaoj7waT4hzNPPdpTBetCJ2N ryHib68aVz5L5xlx4EzZ62LW77hmOyc723mY4tDZXTCsAEf5.H7wx_dUnk3I 8rKv_nPRWNpSWA2jG8FXTlJg4wzsLMto_fW9dtZRyvaKMp0nRQztaLhYDoOG jC9_Mswk7ZstfZCqfaw34aarYK7FDkGBMLPvRNacR8Z6y9PYeSKkBMgLN4m3 8Asam3R0jGdrI4mfu2nYa1i3ppefslZRwdPS1thMyXnsuLg8mrIJ4JbiCMAa sItj4n2EVj2BEclC2bHwNDmCrceE3Jl3dyItGNIU3Zn_1SwTo4jPN8vHC9hI _rA-- Received: from [117.192.27.110] by web120304.mail.ne1.yahoo.com via HTTP; Thu, 16 Aug 2012 19:41:28 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F@008-AM1MPN1-006.mgdnok.nokia.com> <7EE3F6BC-E8AB-4C28-B221-1D6E64324D0A@neustar.biz> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB4298@008-AM1MPN1-006.mgdnok.nokia.com> Message-ID: <1345171288.4064.YahooMailNeo@web120304.mail.ne1.yahoo.com> Date: Thu, 16 Aug 2012 19:41:28 -0700 (PDT) From: Manikkoth Sajeev To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB4298@008-AM1MPN1-006.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="877965879-872311508-1345171288=:4064" Subject: Re: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Manikkoth Sajeev List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 02:41:49 -0000 --877965879-872311508-1345171288=:4064 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable My vote for DB initialization to be present. As I understand initialization= message can be sent upon initial pwer on and reboot scenarios followed by = a registration message. And a registration only message when ever otherwise= required, typically a link failure, or any other updates from master. Many= protocols retain messages this way.=0A=0A=0ABest Regards,=0ASajeev Manikko= th=0AMobile: +918792292002=0AEmail: mksaji@ieee.org=0Ahttp://www.linkedin.c= om/in/mksajeev=0A=0A=0A =0A=0A________________________________=0A From: "Ga= bor.Bajko@nokia.com" =0ATo: paws@ietf.org =0ASent: F= riday, 17 August 2012, 4:41=0ASubject: Re: [paws] need for DB initializatio= n message=0A =0A=0A =0AThis thread was a bit derailed, so I=E2=80=99d like= to get back to the original question, which was whether we need a DB initi= alization message as proposed in draft-das or not. =0A=C2=A0 =0AWe seem to = converge on the discovery of the regulatory domain, ie that the regulatory = domain can be discovered during the DB discovery process, and we do not nee= d a separate message to ask the DB what regulatory domain the master is in.= =0A=C2=A0 =0AThen, the question is whether the masters need to contact th= e DB prior to any other communication, to learn the operating rules for tha= t regulatory domain. The alternative would be that the masters are preconfi= gured with the operating rules for the regulatory domains they are going to= operate in. =0A=C2=A0 =0AIn the F2F, there were opinions on both sides, bu= t not enough to call a consensus. So, please send your preference on the ne= ed for DB initialization, to the list. We need to make a decision on this a= nd some other issues, so we could move forward creating a wg document. =0A= =C2=A0 =0A-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Gabor =0A= =C2=A0 =0AFrom:ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz] =0ASent: T= hursday, August 09, 2012 5:15 PM=0ATo: Bajko Gabor (Nokia-CIC/SiliconValley= )=0ACc: paws@ietf.org=0ASubject: Re: [paws] need for DB initialization mess= age =0A=C2=A0 =0A =0AI'm not so sure you need something se= parate for domain. =C2=A0ISTM that the DB discovery could return it (possib= ly as a parameter on the DB URI). =C2=A0OTOH, you might very well want to r= eceive from the DB some kind of data specification (that is, what is requir= ed to be provided in the registration), rather than having it totally wired= in to domain. =C2=A0That means, to me, that the registration is a 4 way me= ssage exchange: =0A1. Device to DB: Authenticate me please =0A2. DB to de= vice: Authentication accepted, send me this data =0A3. Device to DB: Here = is my registration data =0A4. DB to device: Registration succeeded. =0A= =C2=A0 =0ANow, having said that, you might just get authentication out of = the TLS session establishment, this not needing step 1. =0A=C2=A0 =0ABria= n =0A=C2=A0 =0AOn Aug 9, 2012, at 8:02 PM, wrote:= =0A=0A =0AFolks, =0A=C2=A0 =0ADuring the Vancouver F2F discussions we h= ad some good discussions, but no agreement on whether an initialization mes= sage, as proposed in draft-das is necessary or not. =0AYou may check the m= inutes to see what was said at the mike:=C2=A0http://www.ietf.org/proceedin= gs/84/minutes/minutes-84-paws =0A=C2=A0 =0APeople spoke mostly in favor, = but there were people who also said that this message is redundant with reg= istration message. =0A=C2=A0 =0AQuestion#1: need for an initialization me= ssage =0AUnfortunately we did not have time to discuss the DB discovery as= pect, and that may be related to this topic. The only DB discovery document= available currently,=C2=A0http://www.ietf.org/id/draft-probasco-paws-disco= very-01.txt, proposes, that the master device contacts a pre-provisioned di= scovery server and provides its location, and in return the discovery serve= r returns the URI of the DB for that regulatory domain. At this point, the = master device knows which DB to contact, but it does not necessarily know w= hat regulatory domain that DB belongs to. Thus, it doesn=E2=80=99t know wha= t are the operating rules, whether it has to authenticate, or register, etc= . =0AThus, it seems logical to me that the master device first queries the= DB to find out the regulatory domain. We even have such a requirement in t= he requirement draft, requirement: =0A=E2=80=9CP.3:=C2=A0=C2=A0 The protoc= ol MUST support determination of regulatory=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 domain governing its current loc= ation.=E2=80=9D =0AThe information about the regulatory domain may be cach= ed, and the master device may not need to place that query every time, but = this message exchange may be necessary in certain cases. Any comments to th= is point? =0A=C2=A0 =0AQuestion#2 =0AThen, it is a slightly separate iss= ue, if this message exchange has to take place, then what additional inform= ation the DB returns. draft-das proposes that regulatory domain specific in= formation be returned to the master device. =0A=C2=A0 =0AQuestion#3 =0AY= et another separate point is that draft-das proposes to use this initializa= tion message also to initiate client authentication (putting shared secret = vs cert issue aside for the time being). In cases when the master device do= es not know the regulatory domain it is in, then it does not know whether a= uthentication is required in that regulatory domain or not; so why would in= itiate authentication then? Similar comment applies to draft-wei, where it = is proposed that after DB discovery the master device authenticates at TLS = layer and performs registration; how does it know that it has to authentica= te and register, if it doesn=E2=80=99t know the regulatory domain? =0A=C2= =A0 =0AIn my opinion (chair hat off), the sequence of events should be sg = like this: =0A=C2=A0 =0A1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0DB di= scovery (may be skipped if cached information available) =0A2.=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Regulatory domain query (may be skipped if ca= ched information available) =0A3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0Authentication (if required) =0A4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Registration (if required) =0A5.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Channel availability query (may be combined with registration?) =0A= =C2=A0 =0AComments are welcome and expected. =0A=C2=A0 =0A-=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Gabor =0A=C2=A0 =0A=C2=A0= =0A=C2=A0 =0A_______________________________________________=0Apaws mail= ing list=0Apaws@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/paws =0A= =C2=A0 =0A_______________________________________________=0Apaws mailing= list=0Apaws@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/paws --877965879-872311508-1345171288=:4064 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
My vote fo= r DB initialization to be present. As I understand initialization message c= an be sent upon initial pwer on and reboot scenarios followed by a registra= tion message. And a registration only message when ever otherwise required,= typically a link failure, or any other updates from master. Many protocols= retain messages this way.
 
Best Regards,
= Sajeev Manikkoth
M= obile: +918792292002
Email: mksaji@ieee.org
http://www.linked= in.com/in/mksajeev


From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
To: paws@ietf.org
Sent: Friday, 17 August 2012, 4:41
= Subject: Re: [paws] need = for DB initialization message

=0A=0A =0A =0A=0A=0A
=0A
=0A
= This thread was a= bit derailed, so I=E2=80=99d like to get back to the original question, wh= ich was whether we need a DB initialization message as proposed in draft-da= s=0A or not.
=0A
 
=0AWe seem to converge on the discovery of the regulatory do= main, ie that the regulatory domain can be discovered during the DB discove= ry process, and we do not=0A need a separate message to ask the DB what reg= ulatory domain the master is in. =0A
=0A
&= nbsp;
=0A
Then, the question is whether the= masters need to contact the DB prior to any other communication, to learn = the operating rules for that regulatory domain.=0A The alternative would be= that the masters are preconfigured with the operating rules for the regula= tory domains they are going to operate in.
=0A
 
=0A
In the F2F, there were opin= ions on both sides, but not enough to call a consensus. So, please send you= r preference on the need for DB initialization, to the=0A list. We need to = make a decision on this and some other issues, so we could move forward cre= ating a wg document.
=0A
<= span style=3D"color: rgb(31, 73, 125); font-size: 11pt;">   =0A
-     = ;    =0AGabor
=0A
=  
=0A
=0A
=0A
From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=0A
= =0ASent: Thursday, August 09, 2012 5:15 PM
=0ATo: Bajko Ga= bor (Nokia-CIC/SiliconValley)
=0ACc: paws@ietf.org
=0ASubje= ct: Re: [paws] need for DB initialization message
=0A=0A
=0A
 
=0A
<as individual>
=0A
=0A
I'm not so sure you need something separate f= or domain.  ISTM that the DB discovery could return it (possibly as a = parameter on the DB URI).  OTOH, you might very well want to receive f= rom the DB some kind of data specification (that is,=0A what is required to= be provided in the registration), rather than having it totally wired in t= o domain.  That means, to me, that the registration is a 4 way message= exchange:
=0A
=0A
=0A
1= . Device to DB: Authenticate me please
=0A
=0A
=0A
2. DB to device: Authentication accepted, send m= e this data
=0A
=0A
=0A
= 3. Device to DB: Here is my registration data
=0A
=0A
=0A4. DB to device: Registration succeeded.<= /div> =0A
=0A
=0A
  =0A
=0A
=0A
Now, having said= that, you might just get authentication out of the TLS session establishme= nt, this not needing step 1.
=0A
=0A
=0A
 
=0A
=0A
=0A
Brian
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
On Aug 9, 2012, at 8:02 PM, <Gabor.Bajko@nokia.com> wrote:
=0A
=0A
=0A
=0A
=0A
=0A
=0A=
Folks= ,
=0A
=0A
=0A
 
=0A
=0A
=0A
During the= Vancouver F2F discussions we had some good discussions, but no agreement o= n whether an initialization message, as proposed in draft-das is necessary = or not.
=0A
=0A
=0A
You may check the minutes to see what w= as said at the mike: = ;http:= //www.ietf.org/proceedings/84/minutes/minutes-84-paws =0A
=0A
=0A
 
=0A
=0A
=0A
People spoke mostly in= favor, but there were people who also said that this message is redundant = with registration message.
=0A
=0A
=0A
 
= =0A
=0A
=0A
Question#1: need for an initialization message
= =0A
=0A
=0A
Unfortunately we did not have time to discuss the DB discove= ry aspect, and that may be related to this topic. The only DB discovery doc= ument available currently, Thus, it seems logical to me that the master device= first queries the DB to find out the regulatory domain. We even have such = a requirement in the requirement draft, requirement:
=0A
= =0A
=0A
=E2=80=9CP.3:   The protocol MUST support determination of = regulatory           = ;  domain governing its current location.=E2=80=9D
=0A=0A
=0A
The information about the regulatory domain may be cached, and the= master device may not need to place that query every time, but this messag= e exchange may be necessary in=0A certain cases. Any comments to this point= ?
=0A
=0A
=0A
 
=0A
=0A
=0A
Question#2=
=0A
=0A
=0A
Then, it is a slightly separate issue, if this= message exchange has to take place, then what additional information the D= B returns. draft-das proposes that regulatory domain=0A specific informatio= n be returned to the master device.
=0A
=0A
=0A
 
=0A
=0A
=0A
Question#3
=0A
=0A
=0A
Yet another = separate point is that draft-das proposes to use this initialization messag= e also to initiate client authentication (putting shared secret vs cert iss= ue aside=0A for the time being). In cases when the master device does not k= now the regulatory domain it is in, then it does not know whether authentic= ation is required in that regulatory domain or not; so why would initiate a= uthentication then? Similar comment applies=0A to draft-wei, where it is pr= oposed that after DB discovery the master device authenticates at TLS layer= and performs registration; how does it know that it has to authenticate an= d register, if it doesn=E2=80=99t know the regulatory domain?
= =0A
=0A
=0A
 
=0A
=0A
=0A
In my opinion (chair hat = off), the sequence of events should be sg like this:
=0A
= =0A
=0A
 
=0A
=0A
= =0A
1.=       =  DB=0A discovery (may be skipped if cached infor= mation available)
=0A
=0A
=0A
2.     &nb= sp; Regulatory=0A domain query (may be skipped i= f cached information available)
=0A
=0A
=0A
3.   &= nbsp;   Authentication=0A (if required= )
=0A
=0A
=0A
4.       Registration=0A (if required)
=0A
=0A=0A
5.&nbs= p;      Channel=0A avai= lability query (may be combined with registration?)
=0A
= =0A
=0A
 
=0A
=0A
=0A
Comments are welcome and expected.=
=0A
=0A
=0A
 
=0A
=0A
=0A
-  &nbs= p;       Gabor
=0A
=0A
=0A
 
=0A
=0A=0A
=0A
 
=0A
=0A
=0A
=0A=0A

____= ___________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws


=
--877965879-872311508-1345171288=:4064-- From cuiyang@huawei.com Thu Aug 16 19:51:31 2012 Return-Path: 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 4525611E808D for ; Thu, 16 Aug 2012 19:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 2hTcE8e9431O for ; Thu, 16 Aug 2012 19:51:29 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5E31111E80D1 for ; Thu, 16 Aug 2012 19:51:29 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIY20649; Thu, 16 Aug 2012 18:51:29 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 19:49:43 -0700 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 19:49:48 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.245]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Fri, 17 Aug 2012 10:49:42 +0800 From: Cuiyang To: Manikkoth Sajeev , "Gabor.Bajko@nokia.com" , "Brian.Rosen@neustar.biz" , "vchen@google.com" , "peter@spectrumbridge.com" Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Iet+vcHW33FkKtiTDiFeYExQAAU/5DAIietgAABrI6AAARCycg Date: Fri, 17 Aug 2012 02:49:40 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE21636850EFB@SZXEML508-MBS.china.huawei.com> References: <55A5A9A87506CB4BA580BF9D531957DA690227BD@STNTEXCH01.cis.neustar.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB42CD@008-AM1MPN1-006.mgdnok.nokia.com> <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com> In-Reply-To: <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.48.119] Content-Type: multipart/alternative; boundary="_000_8CC0CB0BCAE52F46882E17828A9AE21636850EFBSZXEML508MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 02:51:31 -0000 --_000_8CC0CB0BCAE52F46882E17828A9AE21636850EFBSZXEML508MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFNhamVldg0KDQpJIHByZWZlciB0byB0aGUgc3VwcG9ydCBvZiBib3RoIHhtbCBhbmQganNv biwgdG9vLg0KDQpCZXN0IFJlZ2FyZHMsDQpZYW5nDQo9PT09PT09PT09PT09PT09PT0NCllhbmcg Q3VpLCAgUGguRC4NCkh1YXdlaSBUZWNobm9sb2dpZXMNCmN1aXlhbmdAaHVhd2VpLmNvbQ0KDQq3 orz+yMs6IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9y Z10gtPqx7SBNYW5pa2tvdGggU2FqZWV2DQq3osvNyrG85DogMjAxMsTqONTCMTfI1SAxMDozOA0K ytW8/sjLOiBHYWJvci5CYWprb0Bub2tpYS5jb207IEJyaWFuLlJvc2VuQG5ldXN0YXIuYml6OyB2 Y2hlbkBnb29nbGUuY29tOyBwZXRlckBzcGVjdHJ1bWJyaWRnZS5jb20NCrOty806IHBhd3NAaWV0 Zi5vcmcNCtb3zOI6IFJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJiBp Q2FsDQoNCkhpLA0KDQpDYW4gaXQgbm90IGJlIGJvdGggSlNPTiBhbmQgWE1MIHN1cHBvcnRlZD8g SSB3b3VsZCB2b3RlIGZvciB0aGF0LiBGdXR1cmUgaW1wbGVtZW50YXRpb25zIG1heSBwcmVmZXIg WE1MIGFzIGl0IGlzIGdlbmVyaWMsIG9tbmkgcHJlc2VudCwgZWFzeSB0byB1bmRlcnN0YW5kIGFu ZCB2YWxpZGF0ZS4gRm9yIGNvbXBhY3RuZXNzIG1heSBiZSBhICBiaW5hcnkgeG1sIG9wdGlvbiBj YW4gYWxzbyB3b3JrLiBKU09OIEkgdGhpbmsgd2lsbCBuZWNlc3NpdGF0ZSBpbXBsZW1lbnRhdGlv biB0byBiZSBuYXRpdmUgSmF2YSBhbmQgbWF5IG5vdCBiZSBhcyBmcmllbmRseSB3aXRoIG90aGVy IGltcGxlbWVudGF0aW9uIGxhbmd1YWdlcy4NCg0KQmVzdCBSZWdhcmRzLA0KU2FqZWV2IE1hbmlr a290aA0KTW9iaWxlOiArOTE4NzkyMjkyMDAyDQpFbWFpbDogbWtzYWppQGllZWUub3JnDQpodHRw Oi8vd3d3LmxpbmtlZGluLmNvbS9pbi9ta3NhamVldg0KDQpGcm9tOiAiR2Fib3IuQmFqa29Abm9r aWEuY29tIiA8R2Fib3IuQmFqa29Abm9raWEuY29tPg0KVG86IEJyaWFuLlJvc2VuQG5ldXN0YXIu Yml6OyB2Y2hlbkBnb29nbGUuY29tOyBwZXRlckBzcGVjdHJ1bWJyaWRnZS5jb20NCkNjOiBwYXdz QGlldGYub3JnDQpTZW50OiBGcmlkYXksIDE3IEF1Z3VzdCAyMDEyLCA0OjU1DQpTdWJqZWN0OiBS ZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJkICYgaUNhbA0KDQpXZSBoYXZl IG5vdCBoZWFyZCBhbnkgb2JqZWN0aW9ucyBmb3IgdXNpbmcgSlNPTiBlbmNvZGluZyBpbnN0ZWFk IG9mIFhNTC4NClRoZXJlZm9yZSwgbGV0J3MgZ28gZm9yIEpTT04sIGFuZCBjbG9zZSB0aGlzIHRo cmVhZC4NCg0KLSBHYWJvcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGF3 cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86 cGF3cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBC ZWhhbGYgT2YgZXh0IFJvc2VuLCBCcmlhbg0KU2VudDogTW9uZGF5LCBBdWd1c3QgMTMsIDIwMTIg MzoxNCBQTQ0KVG86ICdWaW5jZW50IENoZW4nOyAnUGV0ZXIgU3RhbmZvcnRoJw0KQ2M6ICdwYXdz QGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPicNClN1YmplY3Q6IFJlOiBbcGF3c10gWE1M IHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJiBpQ2FsDQoNCmpzb24gaXMgb2theSB3aXRoIG1l Lg0KSSdkIHByZWZlciBhbiBJU08gdGltZSBzdGFtcCByYXRoZXIgdGhhbiBhIHRpbWUgaW4gc2Vj b25kcyBzaW5jZSBlcG9jaC4gIEl0J3MgdmVyeSBlYXN5IHRvIHBhcnNlLCBhbmQgaXRzIHNpbXBs ZXIgdG8gdXNlIGFuZCBkZWJ1Zy4gIERvbid0IGNhcmUgYSB3aG9sZSBsb3QgYWJvdXQgdGhhdA0K DQpCcmlhbiA8YXMgaW5kaXZpZHVhbD4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiAgICAgVmluY2VudCBDaGVuIFttYWlsdG86dmNoZW5AZ29vZ2xlLmNvbTxtYWlsdG86 dmNoZW5AZ29vZ2xlLmNvbT5dDQpTZW50OiAgICBNb25kYXksIEF1Z3VzdCAxMywgMjAxMiAwNjow NCBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNClRvOiAgICBQZXRlciBTdGFuZm9ydGgNCkNjOiAg ICBSb3NlbiwgQnJpYW47IFRlY28gQm9vdDsgQmVuamFtaW4gQS5Sb2xmZTsgcGF3c0BpZXRmLm9y ZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NClN1YmplY3Q6ICAgIFJlOiBbcGF3c10gWE1MIHNjaGVt YSB2ZXJzdXMgSlNPTiwgdkNhcmQgJiBpQ2FsDQoNClhNTCB2cyBKU09ODQoNCkJldHdlZW4gWE1M IGFuZCBKU09OLCBKU09OIG1lc3NhZ2VzIGFyZSBtb3JlIGNvbXBhY3QgYW5kIGVhc2llciB0byBw cm9jZXNzIChwYXJzaW5nLCBzeW50aGVzaXMpLiBBcyBjbGFyaWZpY2F0aW9uLCBKU09OIGRvZXMg bm90IHJlcXVpcmUgSmF2YVNjcmlwdCBvciBhIEJyb3dzZXIuIEl0IGlzIGEgdGV4dC1iYXNlZCBy ZXByZXNlbnRhdGlvbiBvZiBkYXRhIHRoYXQgaXMgbGFuZ3VhZ2UgaW5kZXBlbmRlbnQsIHlldCB3 ZWxsLW1hdGNoZWQgdG8gYWxsIG1ham9yIGxhbmd1YWdlcy4gSlNPTi1oYW5kbGluZyBsaWJyYXJp ZXMgZXhpc3QgZm9yIG51bWVyb3VzIGxhbmd1YWdlcyAoc2VlIG9mIGh0dHA6Ly9qc29uLm9yZy8p IGFuZCBzZWVtIHRvIGJlIHJlYXNvbmFibHkgbGlnaHQgd2VpZ2h0Lg0KDQpUaW1lc3RhbXBzDQoN CkFzIGZvciB0aW1lc3RhbXAgc3BlY2lmaWNhdGlvbnMsIHNob3VsZCB3ZSBjb25zaWRlciBqdXN0 IHVzaW5nIHNlY29uZHMgc2luY2UgdGhlIFVOSVggRXBvY2ggKDE5NzAtMDEtMDFUMDA6MDA6MDBa KT8gVGhpcyB3b3VsZCBlbGltaW5hdGUgdGhlIG5lZWQgZm9yIGRhdGV0aW1lLXN0cmluZyBwYXJz aW5nIG9uIGRldmljZXMsIGFzc3VtaW5nIGRldmljZXMgYWxyZWFkeSBoYXZlIG5hdGl2ZSBsaWJy YXJpZXMgdGhhdCBwcm92aWRlIHRpbWUgaW4gdGhpcyBmb3JtYXQuIElzIHRoYXQgYSB2YWxpZCBh c3N1bXB0aW9uPyBPZiBjb3Vyc2UsIHRoaXMgaXMgbGVzcyBodW1hbi1yZWFkYWJsZS4uLi4NCg0K DQpPbiBNb24sIEF1ZyAxMywgMjAxMiBhdCA2OjQ5IEFNLCBQZXRlciBTdGFuZm9ydGggPHBldGVy QHNwZWN0cnVtYnJpZGdlLmNvbTxtYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tPj4gd3Jv dGU6DQoNCg0KICAgIFdoZW5ldmVyIHdlIGJ1aWx0IG1vYmlsZSBkZXZpY2VzIHdlIG5ldmVyIGRl YWx0IHdpdGggSUVURiwgaW4gb3VyIHNlbnNvcg0KICAgIGRheXMgZXZlbiBhbiBJUCBzdGFjayB3 YXMgYSBjaGFsbGVuZ2Usc28gSSB3b3VsZCBkZWZlciB0byB0aGUgZGV2aWNlIGd1eXMNCiAgICBv biB0aGF0IG9uZS4NCg0KICAgIE9uIE1vbkF1Zy8xMy8xMiBNb24gQXVnIDEzLCA5OjMwIEFNLCAi Um9zZW4sIEJyaWFuIg0KDQogICAgPEJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PG1haWx0bzpCcmlh bi5Sb3NlbkBuZXVzdGFyLmJpej4+IHdyb3RlOg0KDQogICAgPk91ciBleHBlcmllbmNlIGluIHRo ZSBJRVRGIG92ZXIgbWFueSB5ZWFycyBpcyB0aGF0IGVjb25vbWl6aW5nIG1lc3NhZ2UNCiAgICA+ c2l6ZSBhbmQgY29tcHJvbWlzaW5nIHV0aWxpdHkgYW5kIHNlY3VyaXR5IGluIHNlYXJjaCBvZiBl ZmZpY2llbmN5IG9mDQogICAgPmltcGxlbWVudGF0aW9uIG9uIHNtYWxsIGRldmljZXMgaXMgYSBw b29yIHRyYWRlIG9mZi4gIEkgYW0gbm90IGFkdm9jYXRpbmcNCiAgICA+YmVpbmcgd2FzdGVmdWwg b2YgcmVzb3VyY2VzLCBidXQgSSBkb24ndCB0aGluayB3ZSBzaG91bGQgc2VyaW91c2x5DQogICAg PmNvbnNpZGVyIHRoZSBvdmVyaGVhZCBvZiBYTUwgb3IganNvbiB0byBiZSBzaWduaWZpY2FudC4N CiAgICA+DQogICAgPkFzc3VtaW5nIGEganNvbiBsaWJyYXJ5IGNhbiBiZSBsb2FkZWQgb24gYSBz bWFsbCBkZXZpY2UgaXMgcmVhc29uYWJsZS4NCiAgICA+DQogICAgPkJyaWFuIChhcyBpbmRpdmlk dWFsKQ0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCiAgICA+RnJvbTogIFBldGVyIFN0YW5mb3J0aCBbbWFpbHRvOnBldGVyQHNwZWN0cnVtYnJp ZGdlLmNvbTxtYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tPl0NCiAgICA+U2VudDogIFNh dHVyZGF5LCBBdWd1c3QgMTEsIDIwMTIgMDc6MTMgQU0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQog ICAgPlRvOiAgICBUZWNvIEJvb3Q7IEJlbmphbWluIEEuUm9sZmUNCiAgICA+Q2M6ICAgIHBhd3NA aWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQogICAgPlN1YmplY3Q6ICAgICAgUmU6IFtw YXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmIGlDYWwNCiAgICA+DQogICAgPk5v dCBhbGwgbWFzdGVycyBydW4gb3ZlciB0aGUgY29yZSBuZXR3b3JrLg0KICAgID5Tb21lIG9mIHRo ZSBVc2UgY2FzZXMgaGF2ZSBhIG1hc3RlciB0YWxraW5nIHRvIGFub3RoZXIgT1RBDQogICAgPldl IHNob3VsZCBub3QgYXNzdW1lIHRoYXQgYWxsIE1hc3RlcnMgYXJlIGF0dGFjaGVkIHRvIHV0aWxp dHkgcG93ZXIgc28gd2UNCiAgICA+c2hvdWxkIGJlIHN5bXBhdGhldGljIHRvIHByb2Nlc3Npbmcg ZW5lcmd5IHVzZSBhbHNvLg0KICAgID4NCiAgICA+T24gU2F0QXVnLzExLzEyIFNhdCBBdWcgMTEs IDU6MzAgQU0sICJUZWNvIEJvb3QiIDx0ZWNvQGluZi1uZXQubmw8bWFpbHRvOnRlY29AaW5mLW5l dC5ubD4+IHdyb3RlOg0KICAgID4NCiAgICA+Pg0KICAgID4+T3AgMTAgYXVnLiAyMDEyLCBvbSAx ODoxMCBoZWVmdCBCZW5qYW1pbiBBLiBSb2xmZSBoZXQgdm9sZ2VuZGUNCiAgICA+Pmdlc2NocmV2 ZW46DQogICAgPj4NCiAgICA+Pj4gQ29tcGFjdG5lc3Mgb2YgbWVzc2FnZXMgaXMgaW1wb3J0YW50 LCBidXQgaXQgaXMgYWxzbyBpbXBvcnRhbnQgKHRvIG1lDQogICAgPj4+YXQgbGVhc3QpIHRvIGJl IHJlYWxpemFibGUgaW4gYW4gaW1wbGVtZW50YXRpb24gd2l0aCBsaW1pdGVkIHJlc291cmNlcywN CiAgICA+Pj5zdWNoIGFzIGVtYmVkZGVkIGRldmljZXMgaW4gd2hhdCBhcmUgbm93IHBvcHVsYXJs eSBjYWxsZWQgIk0yTSINCiAgICA+Pj5hcHBsaWNhdGlvbnMuICBBIGxvdCBvZiB0aGVzZSBkZXZp Y2VzIGNvdWxkIHVzZSBJUCBhbGwgdGhlIGVuZCB0byBlbmQsDQogICAgPj4+YnV0IG1heSBoYXZl IGEgdmVyeSBjb21wYWN0LCBzaW1wbGUgc3RhY2sgYW5kIGFwcGxpY2F0aW9ucyAoaS5lLiAgbm8N CiAgICA+Pj5icm93c2VyKS4gIElzIEpTT04gdHlwaWNhbGx5IGltcGxlbWVudGVkIHdoZW4gdGhl cmUgaXMgbm8gYnJvd3Nlcj8NCiAgICA+Pj5Xb3VsZCBpdCBiZSBoYXJkIHRvIGRvIGluIGEgcmVz b3VyY2UgY29uc3RyYWluZWQgZGV2aWNlIChpLmUuIHdoZXJlIHdlDQogICAgPj4+dGFsayBhYm91 dCBtZW1vcnkgc2l6ZSBpbiBLaWxvLWJ5dGVzIHN0aWxsKS4NCiAgICA+Pg0KICAgID4+SW4gdXNl IGNhc2VzIGFuZCByZXF1aXJlbWVudHMgZG9jdW1lbnQsIHRoZXJlIGFyZSBubyByZXF1aXJlbWVu dHMgZm9yDQogICAgPj5wcm90b2NvbCBwZXJmb3JtYW5jZS4gSSBndWVzcyBPUy9JUC9UQ1AvVExT IGNvZGUgc2l6ZSBzdXBlcnNlZGVzIG5lZWRzDQogICAgPj5mb3IgSlNPTiBvciBYTUwuDQogICAg Pj4NCiAgICA+PlNhbWUgZm9yIHRpbWluZzogVENQL1RMUyBjb25uZWN0aW9uIHNldHVwIHdpbGwg dGFrZSBtb3JlIHRoYW4gdGhlIFBBV1MNCiAgICA+Pm1lc3NhZ2UgZXhjaGFuZ2UsIEkgdGhpbmsu IFRoaXMgbWF5IGJlIG9mIGltcG9ydGFuY2Ugd2hlbiB1c2luZyBzYXRjb20NCiAgICA+Pmxpbmtz Lg0KICAgID4+DQogICAgPj5CZWNhdXNlIFBBV1MgcnVucyBiZXR3ZWVuIG1hc3RlciBhbmQgZGF0 YWJhc2UsIG92ZXIgY29yZSBuZXR3b3JrLA0KICAgID4+cGVyZm9ybWFuY2UgaXMgbm90IG91ciBw cmltYXJ5IGNvbmNlcm4uIEJ1dCBhcyBhbHdheXMsIGl0IGlzIGdvb2QgdG8ga2VlcA0KICAgID4+ YW4gZXllIG9uIGVmZmljaWVuY3kuDQogICAgPj4NCiAgICA+PlRlY28NCiAgICA+Pg0KICAgID4+ PiBUaGFua3MNCiAgICA+Pj4gQmVuDQogICAgPj4+DQogICAgPj4+DQogICAgPj4+PiBXZSBoYWQg YSBkaXNjdXNzaW9uIG9uIFhNTCB2cy4gSlNPTi4gSSBwcmVmZXIgdGhlIG9uZSB3aXRoIG1vc3QN CiAgICA+Pj4+Y29tcGFjdCBtZXNzYWdlcy4NCiAgICA+Pj4+DQogICAgPj4+PiBPbiB2Q2FyZCBh bmQgSlNPTjogd2hhdCBpcyB0aGUgc3RhdHVzIG9mICJBIEphdmFTY3JpcHQgT2JqZWN0IE5vdGF0 aW9uDQogICAgPj4+PihKU09OKSBSZXByZXNlbnRhdGlvbiBmb3IgdkNhcmQiPw0KICAgID4+Pj4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmhhdC12Y2FyZGRhdi1qc29uLTAwDQog ICAgPj4+Pg0KICAgID4+Pj4gT24gdmFsaWQgdGltZXM6IGNhbiB3ZSB1c2Ugc2FtZSBmb3JtYXQg YXMgY2VydGlmaWNhdGVzPyBUaGV5IGhhdmUNCiAgICA+Pj4+c2ltaWxhciBzaW1wbGUgcmVxdWly ZW1lbnRzOiB2YWxpZCBub3RCZWZvcmUmICBub3RBZnRlci4NCiAgICA+Pj4+IGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzMyODAjc2VjdGlvbi00LjEuMi41DQogICAgPj4+Pg0KICAgID4+ Pj4gVGVjbw0KICAgID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCiAgICA+Pj4+IHBhd3MgbWFpbGluZyBsaXN0DQogICAgPj4+PiBwYXdzQGlldGYu b3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KICAgID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wYXdzDQogICAgPj4+Pg0KICAgID4+Pg0KICAgID4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+PiBwYXdzIG1h aWxpbmcgbGlzdA0KICAgID4+PiBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0K ICAgID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCiAgICA+ Pg0KICAgID4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICA+PnBhd3MgbWFpbGluZyBsaXN0DQogICAgPj5wYXdzQGlldGYub3JnPG1haWx0bzpwYXdz QGlldGYub3JnPg0KICAgID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w YXdzDQogICAgPg0KICAgID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KICAgID5wYXdzIG1haWxpbmcgbGlzdA0KICAgID5wYXdzQGlldGYub3JnPG1haWx0 bzpwYXdzQGlldGYub3JnPg0KICAgID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Bhd3MNCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQogICAgcGF3cyBtYWlsaW5nIGxpc3QNCiAgICBwYXdzQGlldGYub3JnPG1haWx0bzpw YXdzQGlldGYub3JnPg0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGF3cw0KDQoNCg0KDQoNCi0tDQotdmluY2UNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnBhd3MgbWFpbGluZyBsaXN0DQpwYXdzQGlldGYub3JnPG1h aWx0bzpwYXdzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9wYXdzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K cGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg0K --_000_8CC0CB0BCAE52F46882E17828A9AE21636850EFBSZXEML508MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Sajeev=

 = ;

I prefer t= o the support of both xml and json, too.

 = ;

Best Regar= ds,

Yang<= /o:p>

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Yang Cui,  Ph.D.<= /o:p>

Huawei Technologies

cuiyang@huawei.com

 = ;

=B7=A2=BC=FE=C8=CB: paws-bo= unces@ietf.org [mailto:paws-bounces@ietf.org] =B4=FA= =B1=ED Manikkoth Sajeev
=B7=A2= =CB=CD=CA=B1=BC=E4: 2012=C4=EA8=D4=C217=C8=D5 10:38
=CA=D5=BC=FE=C8=CB: Gabor.Bajko@nokia.com; Brian.Rosen@neustar.biz; vchen@google.com; p= eter@spectrumbridge.com
=B3=AD=CB=CD: paws@ietf.org
=D6=F7=CC=E2: Re: [paws] XML schema versus JSON, vCard & iCal

 

Hi,

 

Can it not be both JSON and XML supported? I would vote f= or that. Future implementations may prefer XML as it is generic, omni present, easy to understand and val= idate. For compactness may be a  binary xml option can also work. JSON I think will necessi= tate implementation to be native Java and may not be as friendly with other= implementation languages.

 

Best Regards,

<= span lang=3D"EN-US" style=3D"color:#C00000">Sajeev Manikkoth
Mobile: +918792292002
Email: mksaji@ieee.org
http://ww= w.linkedin.com/in/mksajeev

 

From: &quo= t;Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
To: Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.= com
Cc: paws@ietf.org
Sent: Friday, 17 August 2012, 4:55
Subject: Re: [paws] XML schema versus JSON, vCard & iCal<= span lang=3D"EN-US" style=3D"color:black">


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 [m= ailto:paws-bounces@ietf.org] O= n Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: '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.&nbs= p; It's very easy to parse, and its simpler to use and debug.  Don't c= are a whole lot about that

Brian <as individual>



-----Original Message-----
From:     Vincent Chen [mailto:vchen@google.com]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard T= ime
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
Subject:    Re: [paws] XML schema versus JSON, vCard & i= Cal

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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries exist for numerous languages (see= of http://json.org/) and seem to be reasonably light weight.

Timestamps

As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries 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> wrote:


    Whenever we built mobile devices we never dealt with IET= F, in our sensor
    days even an IP stack was a challenge,so I would defer t= o the device guys
    on that one.
   
    On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian&= quot;
   
    <Brian.Ros= en@neustar.biz> wrote:
   
    >Our experience in the IETF over many years is that e= conomizing 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 sh= ould seriously
    >consider the overhead of XML or json to be significa= nt.
    >
    >Assuming a json library can be loaded on a small dev= ice is reasonable.
    >
    >Brian (as individual)
    >
    >
    >
    > -----Original Message-----
    >From:  Peter Stanforth [mailto:peter@spectrumbridge.com]
    >Sent:  Saturday, August 11, 2012 07:13 AM Easte= rn Standard Time
    >To:    Teco Boot; Benjamin A.Rolfe
    >Cc:    pa= ws@ietf.org
    >Subject:      Re: [paws] XML schema v= ersus JSON, vCard & iCal
    >
    >Not all masters run over the core network.
    >Some of the Use cases have a master talking to anoth= er OTA
    >We should not assume that all Masters are attached t= o 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> wrote= :
    >
    >>
    >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolf= e het volgende
    >>geschreven:
    >>
    >>> Compactness of messages is important, but i= t is also important (to me
    >>>at least) to be realizable in an implementat= ion with limited resources,
    >>>such as embedded devices in what are now pop= ularly called "M2M"
    >>>applications.  A lot of these devices c= ould use IP all the end to end,
    >>>but may have a very compact, simple stack an= d applications (i.e.  no
    >>>browser).  Is JSON typically implemente= d when there is no browser?
    >>>Would it be hard to do in a resource constra= ined device (i.e. where we
    >>>talk about memory size in Kilo-bytes still).=
    >>
    >>In use cases and requirements document, there ar= e 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 t= ake more than the PAWS
    >>message exchange, I think. This may be of import= ance when using satcom
    >>links.
    >>
    >>Because PAWS runs between master and database, o= ver core network,
    >>performance is not our primary concern. But as a= lways, 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 o= f "A JavaScript Object Notation
    >>>>(JSON) Representation for vCard"?     >>>> 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 notBe= fore&  notAfter.
    >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
    >>>>
    >>>> Teco
    >>>> _______________________________________= ________
    >>>> paws mailing list
    >>>> paws@i= etf.org
    >>>> https://www.ietf.org/mailman/listinfo/paw= s
    >>>>
    >>>
    >>> ___________________________________________= ____
    >>> paws mailing list
    >>> paws@ietf.= org
    >>> https://www.ietf.org/mailman/listinfo/paws
    >>
    >>_______________________________________________<= br>     >>paws mailing list
    >>paws@ietf.org
    >>https://www.ietf.org/mailman/listinfo/paws
    >
    >_______________________________________________
    >paws mailing list
    >paws@ietf.org     >https://www.ietf.org/mailman/listinfo/paws
   
    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws
   




--
-vince

_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws

--_000_8CC0CB0BCAE52F46882E17828A9AE21636850EFBSZXEML508MBSchi_-- From brian.rosen@neustar.biz Fri Aug 17 06:00:47 2012 Return-Path: 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 F1B9821F8575 for ; Fri, 17 Aug 2012 06:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YSjX+3MbVcHC for ; Fri, 17 Aug 2012 06:00:45 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAA421F84FB for ; Fri, 17 Aug 2012 06:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1345208559; x=1660546402; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=T7PhG4U/QQKHpgF8knVvoIJxRGupGyeAJapYT5Ilj/c=; b=bmemvQJfzoeAhMmsIcaHbfFofgsNMSqKZBRO2H2PX8jszhvaRSdnDA/wyvsLSa LJ0tKYOuHhGIXX+u6toYqkoQ== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.12722149; Fri, 17 Aug 2012 09:02:38 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Fri, 17 Aug 2012 09:00:41 -0400 From: "Rosen, Brian" Date: Fri, 17 Aug 2012 09:00:37 -0400 Thread-Topic: [paws] need for DB initialization message Thread-Index: Ac18eE3qXPQMbT6zTwqZWeS/L7qTMQ== Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB4298@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: s4XELWiU05fr2YNVQ9Hwag== Content-Type: multipart/alternative; boundary="_000_CC53B4EFAFE0brianrosenneustarbiz_" MIME-Version: 1.0 To: "gabor.bajko@nokia.com" , "paws@ietf.org" Subject: Re: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 13:00:47 -0000 --_000_CC53B4EFAFE0brianrosenneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What I notice when I look at regulations is how we see different classes of= information required at different points in the regulation-required interc= hanges that wouldn't occur to us protocol designers. I think it is foolis= h to hard wire any specific piece of information to any specific protocol e= xchange, because some regulator will do something we would classify as sill= y, but the implementations are stuck. As an example, in the US regulations= , there is information that we would classify as "registration" data requir= ed to be in the "spectrum query" message exchange. So, I do see that a great deal of information exchanged will need to be fle= xible where it goes. In this regard, I think that when a device first connects to a database, th= ere will be information exchanged, and I'll bet there will be circumstances= where the information the client sends will depend in some way on informat= ion the server has. I think this may also happen on the spectrum query. T= herefore, I would like to make sure that it's possible to have 3 way exchan= ges in all circumstances. Client to server, server to client, client to se= rver. This is not a 3 way message exchange on an unreliable transport. I= t lets the client send information dependent on what it gets from the serve= r. So, my answer is more complex. I don't think we need a separate message to= ask about the regulatory domain. I think the "registration" message excha= nge is a 3 way exchange. If you wanted to send regulatory domain in the se= cond message, and get regulatory required information not sent in the first= message sent in the third message of the transaction, that would work for = me. Brian From: "Gabor.Bajko@nokia.com" > Date: Thu, 16 Aug 2012 19:11:40 -0400 To: "paws@ietf.org" > Subject: Re: [paws] need for DB initialization message This thread was a bit derailed, so I=92d like to get back to the original q= uestion, which was whether we need a DB initialization message as proposed = in draft-das or not. We seem to converge on the discovery of the regulatory domain, ie that the = regulatory domain can be discovered during the DB discovery process, and we= do not need a separate message to ask the DB what regulatory domain the ma= ster is in. Then, the question is whether the masters need to contact the DB prior to a= ny other communication, to learn the operating rules for that regulatory do= main. The alternative would be that the masters are preconfigured with the = operating rules for the regulatory domains they are going to operate in. In the F2F, there were opinions on both sides, but not enough to call a con= sensus. So, please send your preference on the need for DB initialization, = to the list. We need to make a decision on this and some other issues, so w= e could move forward creating a wg document. - Gabor From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Thursday, August 09, 2012 5:15 PM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: paws@ietf.org Subject: Re: [paws] need for DB initialization message I'm not so sure you need something separate for domain. ISTM that the DB d= iscovery could return it (possibly as a parameter on the DB URI). OTOH, yo= u might very well want to receive from the DB some kind of data specificati= on (that is, what is required to be provided in the registration), rather t= han having it totally wired in to domain. That means, to me, that the regi= stration is a 4 way message exchange: 1. Device to DB: Authenticate me please 2. DB to device: Authentication accepted, send me this data 3. Device to DB: Here is my registration data 4. DB to device: Registration succeeded. Now, having said that, you might just get authentication out of the TLS ses= sion establishment, this not needing step 1. Brian On Aug 9, 2012, at 8:02 PM, > wrote: Folks, During the Vancouver F2F discussions we had some good discussions, but no a= greement on whether an initialization message, as proposed in draft-das is = necessary or not. You may check the minutes to see what was said at the mike: http://www.ietf= .org/proceedings/84/minutes/minutes-84-paws People spoke mostly in favor, but there were people who also said that this= message is redundant with registration message. Question#1: need for an initialization message Unfortunately we did not have time to discuss the DB discovery aspect, and = that may be related to this topic. The only DB discovery document available= currently, http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, pr= oposes, that the master device contacts a pre-provisioned discovery server = and provides its location, and in return the discovery server returns the U= RI of the DB for that regulatory domain. At this point, the master device k= nows which DB to contact, but it does not necessarily know what regulatory = domain that DB belongs to. Thus, it doesn=92t know what are the operating r= ules, whether it has to authenticate, or register, etc. Thus, it seems logical to me that the master device first queries the DB to= find out the regulatory domain. We even have such a requirement in the req= uirement draft, requirement: =93P.3: The protocol MUST support determination of regulatory = domain governing its current location.=94 The information about the regulatory domain may be cached, and the master d= evice may not need to place that query every time, but this message exchang= e may be necessary in certain cases. Any comments to this point? Question#2 Then, it is a slightly separate issue, if this message exchange has to take= place, then what additional information the DB returns. draft-das proposes= that regulatory domain specific information be returned to the master devi= ce. Question#3 Yet another separate point is that draft-das proposes to use this initializ= ation message also to initiate client authentication (putting shared secret= vs cert issue aside for the time being). In cases when the master device d= oes not know the regulatory domain it is in, then it does not know whether = authentication is required in that regulatory domain or not; so why would i= nitiate authentication then? Similar comment applies to draft-wei, where it= is proposed that after DB discovery the master device authenticates at TLS= layer and performs registration; how does it know that it has to authentic= ate and register, if it doesn=92t know the regulatory domain? In my opinion (chair hat off), the sequence of events should be sg like thi= s: 1. DB discovery (may be skipped if cached information available) 2. Regulatory domain query (may be skipped if cached information avai= lable) 3. Authentication (if required) 4. Registration (if required) 5. Channel availability query (may be combined with registration?) Comments are welcome and expected. - Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CC53B4EFAFE0brianrosenneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
What I notice when I look at re= gulations is how we see different classes of information required at differ= ent points in the regulation-required interchanges  that wouldn't occu= r to us protocol designers.  I think it is foolish to hard wire any sp= ecific piece of information to any specific protocol exchange, because some= regulator will do something we would classify as silly, but the implementa= tions are stuck.  As an example, in the US regulations, there is infor= mation that we would classify as "registration" data required to = be in the "spectrum query" message exchange.

=
So, I do see that a great deal of information exchanged will need to b= e flexible where it goes.

In this regard, I think = that when a device first connects to a database, there will be information = exchanged, and I'll bet there will be circumstances where the information t= he client sends will depend in some way on information the server has. &nbs= p;I think this may also happen on the spectrum query.  Therefore, I wo= uld like to make sure that it's possible to have 3 way exchanges in all cir= cumstances.  Client to server, server to client, client to server. &nb= sp; This is not a 3 way message exchange on an unreliable transport.  = It lets the client send information dependent on what it gets from the serv= er.

So, my answer is more complex.  I don't t= hink we need a separate message to ask about the regulatory domain.  I= think the "registration" message exchange is a 3 way exchange. &= nbsp;If you wanted to send regulatory domain in the second message, and get= regulatory required information not sent in the first message sent in the = third message of the transaction, that would work for me.

Brian <as individual>

From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
Da= te: Thu, 16 Aug 2012 19:11:40 -0400
To: "paws@ietf.org&q= uot; <paws@ietf.org>
Subject: Re: [paws] need for DB initializa= tion message

This thread was a bit derailed, so I=92d like to get back to the ori= ginal question, which was whether we need a DB initialization message as pr= oposed in draft-das or not.

 

We seem to= converge on the discovery of the regulatory domain, ie that the regulatory= domain can be discovered during the DB discovery process, and we do not need a separate message to ask the DB what regulatory domain the master is= in.

&n= bsp;

Then, the que= stion is whether the masters need to contact the DB prior to any other comm= unication, to learn the operating rules for that regulatory domain. The alternative would be that the masters are preconfigured with the opera= ting rules for the regulatory domains they are going to operate in.

 

In the F2F, there were opi= nions on both sides, but not enough to call a consensus. So, please send yo= ur preference on the need for DB initialization, to the list. We need to make a decision on this and some other issues, so we coul= d move forward creating a wg document.

 

-    = ;      Gabor

 

<= div>

From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
Sent: Thursday, August 09, 2012 5:15 PM
To: Bajko Gabo= r (Nokia-CIC/SiliconValley)
Cc: = paws@ietf.org
Subject: Re: [paws] need for DB initialization = message

 =

<as individual>

<= p class=3D"MsoNormal">I'm not so sure you need something separate for domai= n.  ISTM that the DB discovery could return it (possibly as a paramete= r on the DB URI).  OTOH, you might very well want to receive from the = DB some kind of data specification (that is, what is required to be provided in the registration), rather than having i= t totally wired in to domain.  That means, to me, that the registratio= n is a 4 way message exchange:

1. Device to DB: Authenticate me please

2. DB to device: Authentication accepted, send me this dat= a

3. Device to DB: Here is = my registration data

4. DB = to device: Registration succeeded.

 

Now, having = said that, you might just get authentication out of the TLS session establi= shment, this not needing step 1.

 

Brian

 

On Aug 9, 2012, at 8:02 PM, <Gabor.Bajko@nokia.com> wrote:=



Folks,

 <= /o:p>

During the Vancouver F2F discuss= ions we had some good discussions, but no agreement on whether an initializ= ation message, as proposed in draft-das is necessary or not.

You may check the minutes to see what was= said at the mike: http://www.ietf.org/proceedings/84/minutes/minutes-84-pa= ws

 

People spoke mostly in favor, but= there were people who also said that this message is redundant with regist= ration message.

 =

Question#1: need for an initial= ization message

Unfortunate= ly we did not have time to discuss the DB discovery aspect, and that may be= related to this topic. The only DB discovery document available currently,=  http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, proposes, that the master device contacts a pre-provisioned discovery serv= er and provides its location, and in return the discovery server returns th= e URI of the DB for that regulatory domain. At this point, the master devic= e knows which DB to contact, but it does not necessarily know what regulatory domain that DB belongs to. Th= us, it doesn=92t know what are the operating rules, whether it has to authe= nticate, or register, etc.

= Thus, it seems logical to me that the master device first queries the DB to= find out the regulatory domain. We even have such a requirement in the req= uirement draft, requirement:

The information about the regulatory domain may be cached, and= the master device may not need to place that query every time, but this me= ssage exchange may be necessary in certain cases. Any comments to this point?

 

Que= stion#2

Then, it is a slig= htly separate issue, if this message exchange has to take place, then what = additional information the DB returns. draft-das proposes that regulatory d= omain specific information be returned to the master device.

 

Question#3

= Yet ano= ther separate point is that draft-das proposes to use this initialization m= essage also to initiate client authentication (putting shared secret vs cer= t issue aside for the time being). In cases when the master device does not know the reg= ulatory domain it is in, then it does not know whether authentication is re= quired in that regulatory domain or not; so why would initiate authenticati= on then? Similar comment applies to draft-wei, where it is proposed that after DB discovery the master devi= ce authenticates at TLS layer and performs registration; how does it know t= hat it has to authenticate and register, if it doesn=92t know the regulator= y domain?

 =

In my opinion (chair hat off), the se= quence of events should be sg like this:

 

1.       DB discovery (may be skipped if cached information available)

2.   &n= bsp;   <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; ">Regulato= ry domain query (may be skipped if cached information available)

3.   = ;    Authe= ntication (if required)

<= p class=3D"MsoNormal" style=3D"text-indent:-.25in">4.       Registration (if required)

<= p class=3D"MsoNormal" style=3D"text-indent:-.25in">5.       Channel availability query (may be combined with registration?)<= /p>

 

Comments are welcome and expected.

 

-         =  Gabor<= /p>

 

 

 

_______________________________= ________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/l= istinfo/paws

 

--_000_CC53B4EFAFE0brianrosenneustarbiz_-- From brian.rosen@neustar.biz Fri Aug 17 06:08:43 2012 Return-Path: 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 74A0521F8589 for ; Fri, 17 Aug 2012 06:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.243 X-Spam-Level: X-Spam-Status: No, score=-5.243 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, 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 bqa58FB0YmnE for ; Fri, 17 Aug 2012 06:08:42 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD6921F84B3 for ; Fri, 17 Aug 2012 06:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1345209195; x=1660568122; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=9gi6h4DMJ9rTAHaMUHHkX u3bgoOZLecDhbQnpi9mLpM=; b=o7G5hMGAToL7/35dfpEgz+SbzKy2A+TVnJON6 gaKlu5pRs9H9g0gNTpYjBxGXea+ZILcUM+JF2YdDyg59F07ww== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.13179186; Fri, 17 Aug 2012 09:13:14 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Fri, 17 Aug 2012 09:08:38 -0400 From: "Rosen, Brian" Date: Fri, 17 Aug 2012 09:08:37 -0400 Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac18eWo57RZXkm8FS5GMslnWLPKh5w== Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB427D@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 3UMlcDkXrTvFsKBfJiB2lg== Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 To: "gabor.bajko@nokia.com" , "scott.probasco@nokia.com" , "paws@ietf.org" Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 13:08:43 -0000 VWgsIHRoZSBkaWZmZXJlbmNlIGlzIHJlcHJlc2VudGF0aW9uIG9mIHN0YXJ0L3N0b3AgdGltZXMu ICBXZSBib3RoIHByb3Bvc2UNCnRvIHNlbmQgc3RhcnQvc3RvcCB0aW1lcy4gIFZpbmNlbnQgcHJv cG9zZXMgdGhhdCB0aGUgcmVwcmVzZW50YXRpb24gb2YNCnRpbWUgYmUgYSBsb25nIGludGVnZXIg c2Vjb25kcyBzaW5jZSBhbiBlcG9jaC4gIEhlIHdvdWxkIHNlbmQgdHdvIHN1Y2gNCmxvbmcgaW50 ZWdlcnMuICBJIHByb3Bvc2UgaXQgYmUgYW4gSVNPIDg2MDEgdGltZSBzdHJpbmcuICBTcGVjaWZp Y2FsbHksIEkNCndvdWxkIHByb3Bvc2UgYW4gSVNPIDg2MDEgaW50ZXJ2YWwgbGltaXRlZCB0byBz dGFydC9lbmQsIGUuZy4NCjIwMTEtMDMtMDFUMTM6MDA6MDBaLzIwMTItMDUtMTFUMTU6MzA6MDBa Lg0KDQpPbiA4LzE2LzEyIDY6NDUgUE0sICJHYWJvci5CYWprb0Bub2tpYS5jb20iIDxHYWJvci5C YWprb0Bub2tpYS5jb20+IHdyb3RlOg0KDQo+SXQgc2VlbXMgd2UgaGF2ZSBhbiBhZ3JlZW1lbnQg b24gdGhlIHJlcXVpcmVtZW50IHRvIGlkZW50aWZ5IHRoZQ0KPnNwZWN0cnVtLCBieSB1c2luZyB0 aGUgc3RhcnQvc3RvcCBmcmVxdWVuY2llcywgd2l0aCBvcHRpb25hbCBjaGFubmVsDQo+aWRlbnRp ZmllcnMuDQo+DQo+V3J0IHRvIHRoZSBzY2hlZHVsZSwgd2UgaGF2ZSBzbyBmYXIgdHdvIHByb3Bv c2Fscywgb25lIGZyb20gQnJpYW4NCj5wcm9wb3NpbmcgdGhlIHVzZSBvZiBzdGFydC9zdG9wIHRp bWVzIGZvciBlYWNoIHNwZWN0cnVtIHVuaXQgYXZhaWxhYmxlLA0KPmFuZCBvbmUgZnJvbSBWaW5j ZW50IHByb3Bvc2luZyB0byB1c2Ugb2YgVW5peCBFcG9jaCB0aW1lIGluIHNlY29uZHMuIFdlDQo+ bmVlZCB0byBkZWNpZGUgb24gdGhpcywgc28gcGxlYXNlIHNlbmQgeW91ciBwcmVmZXJlbmNlIG9u IHRoaXMgdG9waWMgdG8NCj50aGUgbGlzdC4NCj4NCj4tIEdhYm9yDQo+DQo+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPlByb2Jhc2NvIFNjb3R0IChOb2tpYS1D SUMvRGFsbGFzKQ0KPlNlbnQ6IE1vbmRheSwgQXVndXN0IDEzLCAyMDEyIDEwOjEyIEFNDQo+VG86 IHBhd3NAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3Bhd3NdIHVzZSBjYXNlcyBhbmQgcmVxdWly ZW1lbnRzIGRvY3VtZW50DQo+DQo+SGkgQWxsLA0KPg0KPkdpdmVuIHRoYXQgd2UgaGF2ZSBjb21w bGV0ZWQgdHdvIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGN5Y2xlcyBhbmQgdGhpcw0KPm5leHQg dmVyc2lvbiB3aWxsIGdvIHRvIHRoZSBJRVNHLCBJIGhvcGUgd2UgY291bGQgYWdyZWUgb24gbWlu aW1hbA0KPmNoYW5nZXMgdG8gdGhlIGRvY3VtZW50LCBpLmUuIGNoYW5nZXMgb25seSB0byBELjcg Zm9yIHRoaXMgdG9waWMuIFRoaXMNCj53aWxsIGVuc3VyZSB0aGUgcHJvcGVyIHJlcXVpcmVtZW50 cyBhcmUgZXN0YWJsaXNoZWQgZm9yIHRoZSBkZXZlbG9waW5nDQo+UEFXUyBwcm90b2NvbC4NCj5J IGJlbGlldmUgQnJpYW4ncyBwcm9wb3NlZCB0ZXh0IGNhcHR1cmVzIHRoZSBlc3NlbnRpYWwgcmVx dWlyZW1lbnRzLg0KPg0KPktpbmQgUmVnYXJkcywNCj5TY290dA0KPg0KPg0KPk9uIDgvMTMvMTIg ODoyNCBBTSwgImV4dCBSb3NlbiwgQnJpYW4iIDxCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej4gd3Jv dGU6DQo+DQo+PjxhcyBpbmRpdmlkdWFsPg0KPj5JIHdvdWxkIHByZWZlciB0byBub3QgdXNlIHRo ZSB3b3JkICJjaGFubmVsIiBpbiBvdXIgZG9jdW1lbnRzIGF0IGFsbA0KPj5leGNlcHQgZm9yIHRo ZSB0ZXJtICJjaGFubmVsIGlkZW50aWZpZXIiLiAgSSBwcm9wb3NlZCAic3BlY3RydW0gdW5pdCIs DQo+PmFsdGhvdWdoIGFueSBvdGhlciB0ZXJtIHdpbGwgZG8uICAiQ2hhbm5lbCIgaGFzIHRvbyBt dWNoIGJhZ2dhZ2UsICBBDQo+PnNpbXBsZSBlZGl0b3JpYWwgY2hhbmdlIGxpa2UgdGhpcyBpcyBz aW1wbGUsIGFuZCBpdCdzIG11Y2ggYmV0dGVyIHRvIGRvDQo+Pml0IG5vdy4NCj4+DQo+PkkgdGhp bmsgd2UgbmVlZCBwb3dlciBpbiBib3RoIHRoZSBxdWVyeSBhbmQgdGhlIHJlc3BvbnNlLiAgSW4g c29tZQ0KPj5kb21haW5zLCBpdCBtYXkgYmUgdGhhdCB5b3Ugc3BlY2lmeSB3aGF0IHBvd2VyIHlv dSB3YW50IHRvIHVzZSBhbmQgdGhlDQo+PkRCIHRlbGxzIHlvdSB3aGF0IHNwZWN0cnVtIHlvdSBj YW4gdXNlIGF0IHRoYXQgcG93ZXIuICBJbiBvdGhlciwgYQ0KPj5VUy1saWtlIHJ1bGUgbWF5IGJl IGluIHBsYWNlLiAgQWxzbyBpbiBlaXRoZXIgdGhlIHF1ZXJ5IG9yIHRoZQ0KPj5yZWdpc3RyYXRp b24sIHdlIG5lZWQgYSBkZXZpY2UgdHlwZSwgd2hpY2ggc2hvdWxkIGJlIGFuIGVudHJ5IGZyb20g YW4NCj4+SUFOQSByZWdpc3RyeS4gIFRoaXMgaXMgaG93IHlvdSBnZXQgdGhlIFVTICJNb2RlIElJ IiBpbmZvcm1hdGlvbi4NCj4+DQo+PldpdGggcmVnYXJkIHRvIHNjaGVkdWxlLCBJIHdvdWxkIGxp a2UgdG8gc2VlIHR3byBtZWNoYW5pc21zDQo+PjEpIGEgdGltZSBieSB3aGljaCB0aGUgZGF0YWJh c2Ugc2hvdWxkIGJlIHF1ZXJpZWQgYWdhaW4gKHdoaWNoIGNvdWxkDQo+PnJlcHJlc2VudCB0aGUg bmV4dCBjaGFuZ2UgaW4gc2NoZWR1bGUpDQo+PjIpIHN0YXJ0L3N0b3AgdGltZXMgZm9yIGVhY2gg c3BlY3RydW0gdW5pdCBhdmFpbGFibGUNCj4+DQo+PkJvdGggdGhlc2Ugc2hvdWxkIGJlIG9wdGlv bmFsIGluIHRoZSByZXNwb25zZS4NCj4+DQo+Pk15IHRleHQNCj4+DQo+PlRoZSBkYXRhIG1vZGVs IG11c3Qgc3VwcG9ydCBzcGVjaWZ5aW5nIHNwZWN0cnVtIGF2YWlsYWJpbGl0eS4gIFNwZWN0cnVt DQo+PnVuaXRzIGFyZSBzcGVjaWZpZWQgYnkgbG93IGFuZCBoaWdoIGZyZXF1ZW5jaWVzIGFuZCBt YXkgaGF2ZSBhbg0KPj5vcHRpb25hbCBjaGFubmVsIGlkZW50aWZpZXIuDQo+Pg0KPj5UaGUgZGF0 YSBtb2RlbCBtdXN0IHN1cHBvcnQgYSBzY2hlZHVsZSBmb3Igc3BlY3RydW0gdW5pdCBhdmFpbGFi aWxpdHkuDQo+PlR3byBtZWNoYW5pc21zIG11c3QgYmUgc3VwcG9ydGVkLiAgVGhlIHJlc3BvbnNl IHRvIHNwZWN0cnVtDQo+PmF2YWlsYWJpbGl0eSBxdWVyeSBtYXkgaW5jbHVkZSBhIHRpbWUgYnkg d2hpY2ggdGhlIGRhdGFiYXNlIG11c3QgYmUNCj4+cmVxdWVyaWVkLiAgRWFjaCBzcGVjdHJ1bSB1 bml0IG1lbnRpb25lZCBpbiB0aGUgcmVzcG9uc2UgbWF5IGJlDQo+PmFubm90YXRlZCB3aXRoIHN0 YXJ0IGFuZCBzdG9wIHRpbWUvZGF0ZS4NCj4+DQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PkZyb206ICAgICBFcmljIENodSBbbWFpbHRvOmVyaWNjaHVAZ29vZ2xlLmNv bV0NCj4+U2VudDogICAgU2F0dXJkYXksIEF1Z3VzdCAxMSwgMjAxMiAxMTo0MyBBTSBFYXN0ZXJu IFN0YW5kYXJkIFRpbWUNCj4+VG86ICAgIFRlY28gQm9vdA0KPj5DYzogICAgUm9zZW4sIEJyaWFu OyBwYXdzQGlldGYub3JnDQo+PlN1YmplY3Q6ICAgIFJlOiBbcGF3c10gdXNlIGNhc2VzIGFuZCBy ZXF1aXJlbWVudHMgZG9jdW1lbnQNCj4+DQo+Pg0KPj5IaSBldmVyeW9uZSwNCj4+DQo+PkdhdGhl cmluZyBhbGwgdGhlIHNoYXJlZCBwb2ludHMgZnJvbSBldmVyeW9uZS4uLiBJIGJlbGlldmUgYmVs b3cgaXMgdGhlDQo+PmNvbXBsZXRlIGxpc3Qgc28gZmFyOg0KPj4NCj4+DQo+Pg0KPj4qICAgIFdo YXQncyB0aGUgYmVzdCBjb25zaXN0ZW50IHJlcHJlc2VudGF0aW9uIG9mIHRoZSB3b3JkcyAiY2hh bm5lbA0KPj5udW1iZXJzIiBmb3Igbm9uLVRWIHNwZWN0cnVtDQo+PiogICAgU2hvdWxkIHdlIHVw ZGF0ZSB0aGUgZW50aXJlIGRvYyBvbiB0aGUgdG9waWMgb2YgqfhjaGFubmVsqfcgb3INCj4+qfhj aGFubmVsIG51bWJlcnOp9w0KPj4qICAgIFdoYXSp9nMgdGhlIGJlc3Qgd2F5IHRvIHJlZHVjZSB2 YWd1ZW5lc3MgaW4gd2hldGhlci9ob3cgdG8gaW5jbHVkZQ0KPj4iY2hhbm5lbCBudW1iZXJzIg0K Pj4qICAgIElzIHRoZSByZWZlcmVuY2UgdG8gdmFyaWFibGUgcG93ZXIgcmVxdWlyZWQNCj4+KiAg ICBXaGF0IGRvZXMgY2hhbm5lbCBhdmFpbGFiaWxpdHkgc2NoZWR1bGUgbWVhbg0KPj4NCj4+DQo+ PkJyaWFuJ3Mgc3VnZ2VzdGlvbiBvZiByZXBsYWNpbmcgZXZlcnkgaW5zdGFuY2Ugb2YgImNoYW5u ZWwiIGlzDQo+PnRlY2huaWNhbGx5IGNvcnJlY3RseS4gSG93ZXZlciwgaXQgaXMgaW1wb3J0YW50 IGZvciB1cyB0byBmb2N1cyBtb3ZpbmcNCj4+Zm9yd2FyZC4gIEkgd291bGQgc3VnZ2VzdCB3ZSBv bmx5IHdvcmsgb24gdGhlIG5vcm1hdGl2ZSBwYXJ0IG9mIHRoZSBzcGVjLg0KPj4gVGhlIHNlY3Rp b24gR2Fib3IgaXMgcHJvcG9zaW5nIGZvciB1cyB0byBtb2RpZnkuLi4NCj4+DQo+Pk9uIHdoYXQn cyB0aGUgYmVzdCBnZW5lcmljIGxhYmVsIGZvciB0aGUgd29yZHMgImNoYW5uZWwgbnVtYmVycyIs DQo+PmNoYW5uZWwgaWRlbnRpZmllciBtaWdodCBiZSB0aGUgbW9zdCBhY2N1cmF0ZSBhbmQgbmV1 dHJhbCAibGFiZWwiLg0KPj5UaG91Z2h0cz8NCj4+DQo+Pk9uIHRoZSBxdWVzdGlvbiB3aGV0aGVy IHZhcmlhYmxlIHBvd2VyIGlzIHJlcXVpcmVkLCBiYXNlZCBvbiBGQ0MNCj4+YWRqYWNlbnQtY2hh bm5lbCBydWxlcywgdGhlIGRhdGFiYXNlIG1heSBsaW1pdCB0aGUgTW9kZSBJSSBkZXZpY2VzIHRv DQo+PjEwMG1XIGZvciBzb21lIGNoYW5uZWxzIGFuZCA0MG1XIGZvciBvdGhlcnMuIFRoZXJlZm9y ZSwgdGhlIGRhdGEgbW9kZWwNCj4+bmVlZHMgdG8gc3VwcG9ydCBzcGVjaWZpY2F0aW9uIG9mIG1h eGltdW0gcG93ZXIgbGV2ZWxzLg0KPj4NCj4+TGFzdGx5LCB3aXRoIHJlZ2FyZHMgdG8gInNjaGVk dWxlIiwgdGhlIGludGVudCBpcyB0byBoYXZlIGEgd2F5IG9mDQo+PmluZm9ybWluZyBkZXZpY2Vz IHdoZW4gdG8gb3BlcmF0ZSBmb3IgZWFjaCBmcmVxdWVuY3kgcmFuZ2UuIEFzIGxvbmcgYXMNCj4+ dGhlIGRhdGEgbW9kZWwgc3VwcG9ydHMsIGZvciBleGFtcGxlLCBhIGxpc3Qgb2YgdGltZSByYW5n ZXMsIGl0IGRvZXMNCj4+bm90IHByZXZlbnQgYW4gaW1wbGVtZW50YXRpb24gZnJvbSBwcm92aWRp bmcgYSBsaXN0IHdpdGggMSBlbnRyeSB3aGljaA0KPj5jb3JyZXNwb25kcyB0byB0aGUgInNob3J0 ZXN0IGF2YWlsYWJsZSIuICBUaGUgd29yZCAic2NoZWR1bGUiIHNob3VsZCBiZQ0KPj5zdWZmaWNp ZW50IHRvIGNhcHR1cmUgdGhpcyBpbnRlbnQ/DQo+Pg0KPj5XZSB3b3VsZCBsaWtlIHRvIHByb3Bv c2UgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIGFkZHJlc3MgdGhlc2UgcG9pbnRzOg0KPj4NCj4+IlRo ZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZ5aW5nIGF2YWlsYWJsZSBzcGVjdHJ1bS4g VGhlIERhdGENCj4+TW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZmljYXRpb24gb2YgdGhpcyBpbmZv cm1hdGlvbiBieSBzdGFydCBhbmQgc3RvcA0KPj5mcmVxdWVuY2llcyBhbmQgTUFZIGFsc28gc3Vw cG9ydCBzcGVjaWZpY2F0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkNCj4+Y2hhbm5lbCBpZGVu dGlmaWVycy4gVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IGENCj4+c3BlY3RydW0tYXZhaWxh YmlsaXR5IHNjaGVkdWxlIGFuZCBtYXhpbXVtIHBvd2VyIGxldmVscyBmb3IgZWFjaA0KPj5mcmVx dWVuY3kgcmFuZ2UuIg0KPj4NCj4+DQo+PlRob3VnaHRzPw0KPj5FcmljDQo+Pg0KPj4NCj4+DQo+ Pk9uIDgvMTAvMTIgNTo0OCBBTSwgVGVjbyBCb290IHdyb3RlOg0KPj4NCj4+DQo+PiAgICBXaGF0 IGFib3V0IHRoaXM6DQo+Pg0KPj4gICAgICAgIKn4VGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0 IHNwZWNpZnlpbmcgYSBsaXN0IG9mIGF2YWlsYWJsZQ0KPj5jaGFubmVscy4gVGhlIERhdGEgTW9k ZWwgTVVTVCBzdXBwb3J0IHNwZWNpZmljYXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbg0KPj5ieSBz dGFydCBhbmQgc3RvcCBmcmVxdWVuY2llcywgb3IgZXF1aXZhbGVudHMgc3VjaCBhcyBjZW50ZXIN Cj4+ZnJlcXVlbmNpZXMgd2l0aCBjaGFubmVsIHdpZHRoIG9yIGNoYW5uZWwgbnVtYmVycyB3aXRo IGNoYW5uZWwgbnVtbWVyDQo+PmFsbG9jYXRpb24gc2NoZW1lIC4gVGhlIERhdGEgTW9kZWwgTVVT VCBzdXBwb3J0IGEgY2hhbm5lbCBhdmFpbGFiaWxpdHkNCj4+c2NoZWR1bGUgYW5kIG1heGltdW0g cG93ZXIgbGV2ZWwgZm9yIGVhY2ggY2hhbm5lbCBpbiB0aGUgbGlzdC6p9w0KPj4gICAgDQo+PiAg ICBNb3JlIHRob3VnaHRzIG9uIGNoYW5uZWwgbnVtYmVyczogd2UgbGlrZWx5IHJ1biBpbnRvIHBy b2JsZW1zIGluDQo+PmJhbmRzIHdpdGhvdXQgYSBjaGFubmVsIG51bWJlcmluZyBzY2hlbWUsIG9y IGZvciBleGFtcGxlIHN1YiBjaGFubmVscw0KPj5pbiBUViBiYW5kcy4NCj4+DQo+PiAgICBUZWNv DQo+Pg0KPj4NCj4+ICAgIE9wIDEwIGF1Zy4gMjAxMiwgb20gMTM6NTcgaGVlZnQgUm9zZW4sIEJy aWFuIGhldCB2b2xnZW5kZSBnZXNjaHJldmVuOg0KPj4NCj4+DQo+PiAgICAgICAgPGFzIGluZGl2 aWR1YWw+DQo+PiAgICAgICAgV2hpbGUgSSBkb24ndCBjYXJlIGlmIGl0J3MgY2VudGVyIGFuZCB3 aWR0aCBvciB1cHBlci9sb3dlciwgSQ0KPj5kbyB0aGluayB3ZSB3aWxsIGRlZmluZSB0aGUgZm9y bWF0IGluIHRoZSBwcm90b2NvbCBmb3IgaW50ZXJvcGVyYWJpbGl0eQ0KPj5yZWFzb25zLCBidXQg ZG9uJ3QgbmVlZCB0byBkbyB0aGF0IGluIHJlcXVpcmVtZW50cy4gIEl0IHdvdWxkbid0IGh1cnQN Cj4+dG8gZGVjaWRlIG5vdyBhbmQgdXNlIGNvbnNpc3RlbnQgdGVybXMsIGJ1dCB3ZSBkb24ndCBu ZWVkIHRvLg0KPj4NCj4+ICAgICAgICBJIHRoaW5rICJiYW5kIiB3b24ndCB3b3JrLCBhcyBpdCB1 c3VhbGx5IGltcGxpZXMgYSBtdWNoIHdpZGVyDQo+PnBpZWNlIG9mIHNwZWN0cnVtIHRoYXQgaGFz IGEgY29tbW9uIHB1cnBvc2UuICBUaGUgVFYgQmFuZCBpcyBhbGwgdGhlDQo+PmNoYW5uZWxzLg0K Pj4NCj4+DQo+PiAgICAgICAgT24gQXVnIDEwLCAyMDEyLCBhdCAyOjM3IEFNLCBUZWNvIEJvb3Qg PHRlY29AaW5mLW5ldC5ubD4gd3JvdGU6DQo+Pg0KPj4NCj4+ICAgICAgICAgICAgKHNvbWV3aGF0 IGxhdGUgcmVzcG9uc2UpDQo+Pg0KPj4gICAgICAgICAgICBBIGNlbnRlciBmcmVxdWVuY3kgYW5k IGNoYW5uZWwgd2lkdGggaXMgZnVuY3Rpb25hbA0KPj5lcXVpdmFsZW50IHRvIHN0YXJ0L3N0b3Ag ZnJlcXVlbmNpZXMuIFNvIGlzIGNoYW5uZWwgbnVtYmVyLCB3aXRoIHJlZiB0bw0KPj5jaGFubmVs IG51bWJlciBhc3NpZ25tZW50IHNjaGVtZS4gRm9yIGEgcmVxdWlyZW1lbnRzIGRvY3VtZW50LCB3 ZSBqdXN0DQo+Pm5lZWQgdG8gc3BlY2lmeSB3aGF0IGlzIG5lZWRlZC4gSG93IGl0IGlzIGVuY29k ZWQgKEh6LCB3YXZlIGxlbmd0aCwNCj4+Y2hhbm5lbCBJRCkgaXMgc29sdXRpb24gc3BhY2UuDQo+ Pg0KPj4gICAgICAgICAgICBTZWVuIG91ciBnb2FsIHRvIG1ha2UgUEFXUyBzb21ld2hhdCB1bml2 ZXJzYWwgKG5vdCBsaW1pdGVkDQo+PnRvIFVTIFRWV1MpLCBJIGRvIG5vdCBwcmVmZXIgdXNpbmcg Y2hhbm5lbCBudW1iZXJzLg0KPj4NCj4+ICAgICAgICAgICAgVGVjbw0KPj4NCj4+DQo+PiAgICAg ICAgICAgIE9wIDkgYXVnLiAyMDEyLCBvbSAyMTo1NSBoZWVmdCA8R2Fib3IuQmFqa29Abm9raWEu Y29tPg0KPj48R2Fib3IuQmFqa29Abm9raWEuY29tPiBoZXQgdm9sZ2VuZGUgZ2VzY2hyZXZlbjoN Cj4+DQo+Pg0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZvbGtzLA0KPj4gICAg ICAgICAgICAgICAgIA0KPj4gICAgICAgICAgICAgICAgRHVyaW5nIHRoZSBsYXN0IEYyRiBtZWV0 aW5nLCB0aGVyZSB3YXMgYW4gYWdyZWVtZW50IHRvDQo+Pm1ha2UgYSBzbGlnaHQgdXBkYXRlIHRv IHJlcXVpcmVtZW50IEQuNyBpbg0KPj5odHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYt cGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdHMtMDYudA0KPj54dCwgIHRvIG1ha2UgY2hh bm5lbCBudW1iZXJzIG9wdGlvbmFsIHRvIGJlIHN1cHBvcnRlZC4gSWUsIGNoYW5nZSB0aGUNCj4+ Y3VycmVudA0KPj5ELjcNCj4+ICAgICAgICAgICAgICAgIKn4VGhlIERhdGEgTW9kZWwgTVVTVCBz dXBwb3J0IHNwZWNpZnlpbmcgYSBsaXN0IG9mDQo+PmF2YWlsYWJsZSBjaGFubmVscy4gVGhlIERh dGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZmljYXRpb24gb2YgdGhpcw0KPj5pbmZvcm1hdGlv biBieSBjaGFubmVsIG51bWJlcnMgYW5kIGJ5IHN0YXJ0IGFuZCBzdG9wIGZyZXF1ZW5jaWVzLiBU aGUNCj4+RGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIGF2YWlsYWJpbGl0eSBzY2hl ZHVsZSBhbmQgbWF4aW11bQ0KPj5wb3dlciBsZXZlbCBmb3IgZWFjaCBjaGFubmVsIGluIHRoZSBs aXN0Lqn3DQo+PiAgICAgICAgICAgICAgICB0bw0KPj4gICAgICAgICAgICAgICAgqfhUaGUgRGF0 YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyBhIGxpc3Qgb2YNCj4+YXZhaWxhYmxlIGNo YW5uZWxzLiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmaWNhdGlvbiBvZiB0aGlz DQo+PmluZm9ybWF0aW9uIGJ5IHN0YXJ0IGFuZCBzdG9wIGZyZXF1ZW5jaWVzIGFuZCBNQVkgaW5j bHVkZSBjaGFubmVsDQo+Pm51bWJlcnMuIFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBhIGNo YW5uZWwgYXZhaWxhYmlsaXR5IHNjaGVkdWxlDQo+PmFuZCBtYXhpbXVtIHBvd2VyIGxldmVsIGZv ciBlYWNoIGNoYW5uZWwgaW4gdGhlIGxpc3QuqfcNCj4+ICAgICAgICAgICAgICAgICANCj4+ICAg ICAgICAgICAgICAgIEmp9mQgbGlrZSB0byBjb25maXJtIHRoaXMgY2hhbmdlIG9uIHRoZSBsaXN0 LiBJZiBhbnlvbmUNCj4+aGFzIGFueSBvYmplY3Rpb25zLCBsZXQgbWUga25vdy4gT3RoZXJ3aXNl IEmp9mxsIHBsYW4gdG8gc2VuZCB0aGUNCj4+ZG9jdW1lbnQgdG8gdGhlIGllc2cgYWZ0ZXIgdGhp cyBjaGFuZ2UgaXMgaW1wbGVtZW50ZWQuDQo+PiAgICAgICAgICAgICAgICAgDQo+PiAgICAgICAg ICAgICAgICAtICAgICAgICAgIEdhYm9yDQo+PiAgICAgICAgICAgICAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gICAgICAgICAgICAgICAgcGF3 cyBtYWlsaW5nIGxpc3QNCj4+ICAgICAgICAgICAgICAgIHBhd3NAaWV0Zi5vcmcNCj4+ICAgICAg ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4g ICAgICAgICAgICAgICAgDQo+PiAgICAgICAgICAgICAgICANCj4+DQo+PiAgICAgICAgICAgIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiAgICAgICAg ICAgIHBhd3MgbWFpbGluZyBsaXN0DQo+PiAgICAgICAgICAgIHBhd3NAaWV0Zi5vcmcNCj4+ICAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+PiAg ICAgICAgICAgIA0KPj4NCj4+DQo+Pg0KPj4NCj4+ICAgICANCj4+ICAgIA0KPj4gICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ICAgIHBhd3MgbWFp bGluZyBsaXN0DQo+PiAgICBwYXdzQGlldGYub3JnDQo+PiAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+ICAgIA0KPj4NCj4+DQo+Pl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PnBhd3MgbWFpbGluZyBsaXN0DQo+ PnBhd3NAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w YXdzDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5wYXdzIG1haWxpbmcgbGlzdA0KPnBhd3NAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPnBhd3MgbWFpbGluZyBsaXN0DQo+cGF3c0BpZXRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQo= From brian.rosen@neustar.biz Fri Aug 17 06:25:54 2012 Return-Path: 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 1B49E21F8468 for ; Fri, 17 Aug 2012 06:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.063 X-Spam-Level: X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 Dx1QSuZfmz5r for ; Fri, 17 Aug 2012 06:25:52 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id DFC1B21F84B2 for ; Fri, 17 Aug 2012 06:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1345210064; x=1660546402; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=3MCS2sBHv+3wAS4V9Lc84UChmsvCV54GbxYy869UREA=; b=SAZyFASDDEgSl+vFeu9fHdnnnUkwNFCcR3Nyu5LWIOe4m199ChOqZB+gPgq747 WspRunsenvxWc1TpSeSdOCUA== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.12722719; Fri, 17 Aug 2012 09:27:43 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 17 Aug 2012 09:25:47 -0400 From: "Rosen, Brian" Date: Fri, 17 Aug 2012 09:25:44 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac18e88u8ul4qxerT660/QDqozGuFw== Message-ID: In-Reply-To: <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: YRlmKvYahRmOda3jIBk2BA== Content-Type: multipart/alternative; boundary="_000_CC53BAB1B014brianrosenneustarbiz_" MIME-Version: 1.0 To: Manikkoth Sajeev , "gabor.bajko@nokia.com" , "vchen@google.com" , "peter@spectrumbridge.com" Cc: "paws@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 13:25:54 -0000 --_000_CC53BAB1B014brianrosenneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't really care whether we use json or xml as a matter of protocol desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml option can also wor= k. JSON I think will necessitate implementation to be native Java and may n= ot be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CC53BAB1B014brianrosenneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I don't really care whet= her we use json or xml as a matter of protocol design or implementation, bu= t 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 ow= n versus using existing standards based on the idea there is no json repres= entation of an existing standard.  So, if choosing json means folks fe= el free to ignore existing xml based standards such as xCard and LoST, then= I would not want to use json.

I would prefer to n= ot have "both", because of interoperability complications.  If there i= s rough consensus for both, then I would assert that all servers have to im= plement 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 th= at 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.

<= div>Brian <as individual>


Hi,
 
Can it not = be both JSON and XML supported? I would vote for that. Future implementatio= ns may prefer XML as it is generic, omni present, easy to unde= rstand and validate. For compactness may be a  binary= xml option can also work. JSON I think will necessitate implement= ation to be native Java and may not be as friendly with other implementatio= n languages.
 
Best Regards,

From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
To: Brian.R= osen@neustar.biz; vchen@google.com<= /a>; peter@spectrumbridge.com
Cc: 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 Messa= ge-----
From: paws-bounces@ietf.org [mailto:paws-bounc= es@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'
= 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:  &= nbsp;  Vincent Chen [mailto:vchen@google.com]
Sent:  &nb= sp; Monday, August 13, 2012 06:04 PM Eastern Standard Time
To: &nbs= p;  Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; = Benjamin A.Rolfe; paws@ietf.org
Subject:    Re: [paws] XML sch= ema versus JSON, vCard & iCal

XML vs JSON

Between XML and= JSON, JSON messages are more compact and easier to process (parsing, synth= esis). As clarification, JSON does not require JavaScript or a Browser. It = is a text-based representation of data that is language independent, yet we= ll-matched to all major languages. JSON-handling libraries exist for numero= us languages (see of 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 nati= ve 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&g= t; 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
  &= nbsp; on that one.
   
    On MonAug/1= 3/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"
   
    <Brian.R= osen@neustar.biz> wrote:
   
   = ; >Our experience in the IETF over many years is that economizing messag= e
    >size and compromising utility and security in s= earch of efficiency of
    >implementation on small de= vices is a poor trade off.  I am not advocating
    = >being wasteful of resources, but I don't think we should seriously
&= nbsp;   >consider the overhead of XML or json to be significan= t.
    >
    >Assuming a json lib= rary can be loaded on a small device is reasonable.
    &= gt;
    >Brian (as individual)
    &= gt;
    >
    >
    > -----Original Message-----
  =   >From:  Peter Stanforth [mailto:peter@spectrumb= ridge.com]
    >Sent:  Saturday, August 11, 2= 012 07:13 AM Eastern Standard Time
    >To:  &nbs= p; Teco Boot; Benjamin A.Rolfe
    >Cc:    <= a href=3D"mailto:paws@ietf.org" ymailto=3D"mailto:paws@ietf.org">paws@ietf.= org
    >Subject:      Re: [paws] = XML schema versus JSON, vCard & iCal
    >
&nbs= p;   >Not all masters run over the core network.
 &nbs= p;  >Some of the Use cases have a master talking to another OTA
=     >We should not assume that all Masters are attached t= o utility power so we
    >should be sympathetic to processing energy use also.
    >
  &nbs= p; >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <teco@inf-net.nl&= gt; wrote:
    >
    >>
&nb= sp;   >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe h= et volgende
    >>geschreven:
   = >>
    >>> Compactness of messages is imp= ortant, but it is also important (to me
    >>>a= t least) to be realizable in an implementation with limited resources,
&= nbsp;   >>>such as embedded devices in what are now popu= larly 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 t= ypically implemented when there is no browser?
    >&g= t;>Would it be hard to do in a resource constrained device (i.e. where w= e
    >>>talk about memory size in Kilo-bytes st= ill).
    >>
    >>In use c= ases and requirements document, there are no requirements for
 &nbs= p;  >>protocol performance. I guess OS/IP/TCP/TLS code size supe= rsedes needs
    >>for JSON or XML.
  =   >>
    >>Same for timing: TCP/TLS conn= ection setup will take more than the PAWS
    >>mes= sage exchange, I think. This may be of importance when using satcom
&nbs= p;   >>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
    >>a= n eye on efficiency.
    >>
    &= gt;>Teco
    >>
    >>&g= t; Thanks
    >>> Ben
    >= >>
    >>>
    >>&= gt;> 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
    &= gt;>>>(JSON) Representation for vCard"?
    >= >>> 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 n= otBefore&  notAfter.
    >>>> = http://tools.ietf.org/html/rfc3280#section-4.1.2.5
   = ; >>>>
    >>>> Teco
 &nb= sp;  >>>> _______________________________________________<= br>    >>>> paws mailing list
  &nb= sp; >>>> paws@ietf.org
    >>>> https://= www.ietf.org/mailman/listinfo/paws
    >>>&g= t;
    >>>
    >>> __= _____________________________________________
    >>= ;> paws mailing list
    >>> paws@ietf.org
&nbs= p;   >>> https://www.ietf.org/mailman/listinfo/paws    >>
    >>________________= _______________________________
    >>paws mailing = list
    >>paws@ietf.org
    >><= a href=3D"https://www.ietf.org/mailman/listinfo/paws" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/paws
    >
&= nbsp;   >_______________________________________________
&n= bsp;   >paws mailing list
    >paws@ietf.org    >https://www.ietf.org/mailman/listinfo/paws
&n= bsp;  
    ___________________________________= ____________
    paws mailing list
    = paws@ietf= .org
    https://www.ietf.org/mailman/listinfo/paws=
   




--
-vince

___________= ____________________________________
paws mailing list
paws@ietf.org
http= s://www.ietf.org/mailman/listinfo/paws
_____________________________= __________________
paws mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws


--_000_CC53BAB1B014brianrosenneustarbiz_-- From vchen@google.com Fri Aug 17 09:01:33 2012 Return-Path: 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 29CDA21F846D for ; Fri, 17 Aug 2012 09:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 NZ150TSWKK65 for ; Fri, 17 Aug 2012 09:01:31 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDD521F846A for ; Fri, 17 Aug 2012 09:01:31 -0700 (PDT) Received: by qcac10 with SMTP id c10so3605635qca.31 for ; Fri, 17 Aug 2012 09:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=5ubjtVFSlURGmO8OzVMsTJZykxv+bLFhjTK8lqDjD5o=; b=kxt+1YnYeB7ccs8YE0BhpItRI7OQ3pBWIXXy13wmBYlTRPB5oCPPZYzMVMAPFpvVcb 4g5Hw1gmA+6HnVOvzqRie/fBun/6aQpyCcv7fDU+Jx+OITENbc4Lg84+lto+FQ7kFTuY 4H41LTrfYJSTdAYoxks+493e5RxlIR4JegdneP1lEamZN+OgfF8Awj74vMgMt5ehrpah FC/b/7dUQW7MtQOtwahKN9f01LwMeQ+13b1HPVNMjdbNzQFNTXpjwkjUy6wORjrAOAdd vQNkaJP+J0ZDwMbmmRBGSqcuVfkm26VDrEs0xZO0v2lWIZrO1ZtcLXwda7PGKdu7heO/ A2Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=5ubjtVFSlURGmO8OzVMsTJZykxv+bLFhjTK8lqDjD5o=; b=FD0Fcr04d8OIZ53QmfiDudsr8d1gcvfLWS8hFTNNLCWelcpiB9H9bIRhnpK0yny5ag uNiw3gxGIyK9IrzJJ+jrv6Slhq76EChZdvsKk5Wql4MXbDRy8NolbSN5OlLTaWyHnRtf oVmyjo28SbYdgm/BgChmFwehquk6wlAWWsVESDZYer2+eDjYBTNeprR9fvfls76sfPqt Av99SAzF1t37LO+E8KoaDNFJPD46Dyjla+aYh09xBypR23z9WHpvH8IjTCIY3G6gKPB+ ifXSiFHy33Ne6W+UG4u9gCpfzTkqjknIYzrtGTfVtFa/uxjBbaMd4DDLXkcoDS58HNCy c1dg== Received: by 10.229.136.83 with SMTP id q19mr4104059qct.47.1345219290384; Fri, 17 Aug 2012 09:01:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.136.83 with SMTP id q19mr4104033qct.47.1345219289964; Fri, 17 Aug 2012 09:01:29 -0700 (PDT) Received: by 10.229.64.149 with HTTP; Fri, 17 Aug 2012 09:01:29 -0700 (PDT) In-Reply-To: References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB427D@008-AM1MPN1-006.mgdnok.nokia.com> Date: Fri, 17 Aug 2012 09:01:29 -0700 Message-ID: From: Vincent Chen To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=00248c768f6aec607c04c77845b7 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlHvDvEBfKhpK+IgZY0ja+CRqIIU4yE/qYaJFv9OVjh1iGZbwZNsRAefcAj+G6h7xOVROAXU6lLENKaa4Yp5+G1OIaAH6lVsHpxdPtSw8uveNfNtpPe/zwIukWZmX6wKkpBvbvdRuFmB+QhZ0BeGWvtR+r9jWRcvE2EpPP2ccQDSL9xfHZraF1RCNEyYANMK3e55L7y Cc: "paws@ietf.org" Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 16:01:33 -0000 --00248c768f6aec607c04c77845b7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Comments: - The proposal for long-integer seconds was to gauge preference from the device folks - If we use ISO 8601, could we restrict it to be only in UTC? :) On Fri, Aug 17, 2012 at 6:08 AM, Rosen, Brian wrot= e: > Uh, the difference is representation of start/stop times. We both propos= e > to send start/stop times. Vincent proposes that the representation of > time be a long integer seconds since an epoch. He would send two such > long integers. I propose it be an ISO 8601 time string. Specifically, I > would propose an ISO 8601 interval limited to start/end, e.g. > 2011-03-01T13:00:00Z/2012-05-11T15:30:00Z. > > On 8/16/12 6:45 PM, "Gabor.Bajko@nokia.com" wrote= : > > >It seems we have an agreement on the requirement to identify the > >spectrum, by using the start/stop frequencies, with optional channel > >identifiers. > > > >Wrt to the schedule, we have so far two proposals, one from Brian > >proposing the use of start/stop times for each spectrum unit available, > >and one from Vincent proposing to use of Unix Epoch time in seconds. We > >need to decide on this, so please send your preference on this topic to > >the list. > > > >- Gabor > > > >-----Original Message----- > >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > >Probasco Scott (Nokia-CIC/Dallas) > >Sent: Monday, August 13, 2012 10:12 AM > >To: paws@ietf.org > >Subject: Re: [paws] use cases and requirements document > > > >Hi All, > > > >Given that we have completed two Working Group Last Call cycles and this > >next version will go to the IESG, I hope we could agree on minimal > >changes to the document, i.e. changes only to D.7 for this topic. This > >will ensure the proper requirements are established for the developing > >PAWS protocol. > >I believe Brian's proposed text captures the essential requirements. > > > >Kind Regards, > >Scott > > > > > >On 8/13/12 8:24 AM, "ext Rosen, Brian" wrote: > > > >> > >>I would prefer to not use the word "channel" in our documents at all > >>except for the term "channel identifier". I proposed "spectrum unit", > >>although any other term will do. "Channel" has too much baggage, A > >>simple editorial change like this is simple, and it's much better to do > >>it now. > >> > >>I think we need power in both the query and the response. In some > >>domains, it may be that you specify what power you want to use and the > >>DB tells you what spectrum you can use at that power. In other, a > >>US-like rule may be in place. Also in either the query or the > >>registration, we need a device type, which should be an entry from an > >>IANA registry. This is how you get the US "Mode II" information. > >> > >>With regard to schedule, I would like to see two mechanisms > >>1) a time by which the database should be queried again (which could > >>represent the next change in schedule) > >>2) start/stop times for each spectrum unit available > >> > >>Both these should be optional in the response. > >> > >>My text > >> > >>The data model must support specifying spectrum availability. Spectrum > >>units are specified by low and high frequencies and may have an > >>optional channel identifier. > >> > >>The data model must support a schedule for spectrum unit availability. > >>Two mechanisms must be supported. The response to spectrum > >>availability query may include a time by which the database must be > >>requeried. Each spectrum unit mentioned in the response may be > >>annotated with start and stop time/date. > >> > >> > >> > >> -----Original Message----- > >>From: Eric Chu [mailto:ericchu@google.com] > >>Sent: Saturday, August 11, 2012 11:43 AM Eastern Standard Time > >>To: Teco Boot > >>Cc: Rosen, Brian; paws@ietf.org > >>Subject: Re: [paws] use cases and requirements document > >> > >> > >>Hi everyone, > >> > >>Gathering all the shared points from everyone... I believe below is the > >>complete list so far: > >> > >> > >> > >>* What's the best consistent representation of the words "channel > >>numbers" for non-TV spectrum > >>* Should we update the entire doc on the topic of =B3channel=B2 or > >>=B3channel numbers=B2 > >>* What=B9s the best way to reduce vagueness in whether/how to includ= e > >>"channel numbers" > >>* Is the reference to variable power required > >>* What does channel availability schedule mean > >> > >> > >>Brian's suggestion of replacing every instance of "channel" is > >>technically correctly. However, it is important for us to focus moving > >>forward. I would suggest we only work on the normative part of the spe= c. > >> The section Gabor is proposing for us to modify... > >> > >>On what's the best generic label for the words "channel numbers", > >>channel identifier might be the most accurate and neutral "label". > >>Thoughts? > >> > >>On the question whether variable power is required, based on FCC > >>adjacent-channel rules, the database may limit the Mode II devices to > >>100mW for some channels and 40mW for others. Therefore, the data model > >>needs to support specification of maximum power levels. > >> > >>Lastly, with regards to "schedule", the intent is to have a way of > >>informing devices when to operate for each frequency range. As long as > >>the data model supports, for example, a list of time ranges, it does > >>not prevent an implementation from providing a list with 1 entry which > >>corresponds to the "shortest available". The word "schedule" should be > >>sufficient to capture this intent? > >> > >>We would like to propose the following text to address these points: > >> > >>"The Data Model MUST support specifying available spectrum. The Data > >>Model MUST support specification of this information by start and stop > >>frequencies and MAY also support specification of this information by > >>channel identifiers. The Data Model MUST support a > >>spectrum-availability schedule and maximum power levels for each > >>frequency range." > >> > >> > >>Thoughts? > >>Eric > >> > >> > >> > >>On 8/10/12 5:48 AM, Teco Boot wrote: > >> > >> > >> What about this: > >> > >> =B3The Data Model MUST support specifying a list of available > >>channels. The Data Model MUST support specification of this information > >>by start and stop frequencies, or equivalents such as center > >>frequencies with channel width or channel numbers with channel nummer > >>allocation scheme . The Data Model MUST support a channel availability > >>schedule and maximum power level for each channel in the list.=B2 > >> > >> More thoughts on channel numbers: we likely run into problems in > >>bands without a channel numbering scheme, or for example sub channels > >>in TV bands. > >> > >> Teco > >> > >> > >> Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende geschreve= n: > >> > >> > >> > >> While I don't care if it's center and width or upper/lower, I > >>do think we will define the format in the protocol for interoperability > >>reasons, but don't need to do that in requirements. It wouldn't hurt > >>to decide now and use consistent terms, but we don't need to. > >> > >> I think "band" won't work, as it usually implies a much wider > >>piece of spectrum that has a common purpose. The TV Band is all the > >>channels. > >> > >> > >> On Aug 10, 2012, at 2:37 AM, Teco Boot wrote: > >> > >> > >> (somewhat late response) > >> > >> A center frequency and channel width is functional > >>equivalent to start/stop frequencies. So is channel number, with ref to > >>channel number assignment scheme. For a requirements document, we just > >>need to specify what is needed. How it is encoded (Hz, wave length, > >>channel ID) is solution space. > >> > >> Seen our goal to make PAWS somewhat universal (not limited > >>to US TVWS), I do not prefer using channel numbers. > >> > >> Teco > >> > >> > >> Op 9 aug. 2012, om 21:55 heeft > >> het volgende geschreven: > >> > >> > >> Folks, > >> > >> During the last F2F meeting, there was an agreement to > >>make a slight update to requirement D.7 in > >>http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.t > >>xt, to make channel numbers optional to be supported. Ie, change the > >>current > >>D.7 > >> =B3The Data Model MUST support specifying a list of > >>available channels. The Data Model MUST support specification of this > >>information by channel numbers and by start and stop frequencies. The > >>Data Model MUST support a channel availability schedule and maximum > >>power level for each channel in the list.=B2 > >> to > >> =B3The Data Model MUST support specifying a list of > >>available channels. The Data Model MUST support specification of this > >>information by start and stop frequencies and MAY include channel > >>numbers. The Data Model MUST support a channel availability schedule > >>and maximum power level for each channel in the list.=B2 > >> > >> I=B9d like to confirm this change on the list. If anyon= e > >>has any objections, let me know. Otherwise I=B9ll plan to send the > >>document to the iesg after this change is implemented. > >> > >> - Gabor > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >> > >> > >> > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >> > >> > >> > >>_______________________________________________ > >>paws mailing list > >>paws@ietf.org > >>https://www.ietf.org/mailman/listinfo/paws > > > >_______________________________________________ > >paws mailing list > >paws@ietf.org > >https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ > >paws mailing list > >paws@ietf.org > >https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > --=20 -vince --00248c768f6aec607c04c77845b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Comments:
- The proposal for long-integer seconds was to gauge pr= eference from the device folks

- If we use ISO 8601, cou= ld we restrict it to be only in UTC? :)=A0




On Fri,= Aug 17, 2012 at 6:08 AM, Rosen, Brian <Brian.Rosen@neustar.biz&= gt; wrote:
Uh, the difference is representation of star= t/stop times. =A0We both propose
to send start/stop times. =A0Vincent proposes that the representation of time be a long integer seconds since an epoch. =A0He would send two such long integers. =A0I propose it be an ISO 8601 time string. =A0Specifically,= I
would propose an ISO 8601 interval limited to start/end, e.g.
2011-03-01T13:00:00Z/2012-05-11T15:30:00Z.

On 8/16/12 6:45 PM, "Gabor.Ba= jko@nokia.com" <Gabor.= Bajko@nokia.com> wrote:

>It seems we have an agreement on the requirement to identify the
>spectrum, by using the start/stop frequencies, with optional channel >identifiers.
>
>Wrt to the schedule, we have so far two proposals, one from Brian
>proposing the use of start/stop times for each spectrum unit available,=
>and one from Vincent proposing to use of Unix Epoch time in seconds. We=
>need to decide on this, so please send your preference on this topic to=
>the list.
>
>- Gabor
>
>-----Original Message-----
>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of
>Probasco Scott (Nokia-CIC/Dallas)
>Sent: Monday, August 13, 2012 10:12 AM
>To: paws@ietf.org
>Subject: Re: [paws] use cases and requirements document
>
>Hi All,
>
>Given that we have completed two Working Group Last Call cycles and thi= s
>next version will go to the IESG, I hope we could agree on minimal
>changes to the document, i.e. changes only to D.7 for this topic. This<= br> >will ensure the proper requirements are established for the developing<= br> >PAWS protocol.
>I believe Brian's proposed text captures the essential requirements= .
>
>Kind Regards,
>Scott
>
>
>On 8/13/12 8:24 AM, "ext Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:
>
>><as individual>
>>I would prefer to not use the word "channel" in our docum= ents at all
>>except for the term "channel identifier". =A0I proposed &= quot;spectrum unit",
>>although any other term will do. =A0"Channel" has too muc= h baggage, =A0A
>>simple editorial change like this is simple, and it's much bett= er to do
>>it now.
>>
>>I think we need power in both the query and the response. =A0In som= e
>>domains, it may be that you specify what power you want to use and = the
>>DB tells you what spectrum you can use at that power. =A0In other, = a
>>US-like rule may be in place. =A0Also in either the query or the >>registration, we need a device type, which should be an entry from = an
>>IANA registry. =A0This is how you get the US "Mode II" in= formation.
>>
>>With regard to schedule, I would like to see two mechanisms
>>1) a time by which the database should be queried again (which coul= d
>>represent the next change in schedule)
>>2) start/stop times for each spectrum unit available
>>
>>Both these should be optional in the response.
>>
>>My text
>>
>>The data model must support specifying spectrum availability. =A0Sp= ectrum
>>units are specified by low and high frequencies and may have an
>>optional channel identifier.
>>
>>The data model must support a schedule for spectrum unit availabili= ty.
>>Two mechanisms must be supported. =A0The response to spectrum
>>availability query may include a time by which the database must be=
>>requeried. =A0Each spectrum unit mentioned in the response may be >>annotated with start and stop time/date.
>>
>>
>>
>> -----Original Message-----
>>From: =A0 =A0 Eric Chu [mailto:ericchu@google.com]
>>Sent: =A0 =A0Saturday, August 11, 2012 11:43 AM Eastern Standard Ti= me
>>To: =A0 =A0Teco Boot
>>Cc: =A0 =A0Rosen, Brian; paws@ietf= .org
>>Subject: =A0 =A0Re: [paws] use cases and requirements document
>>
>>
>>Hi everyone,
>>
>>Gathering all the shared points from everyone... I believe below is= the
>>complete list so far:
>>
>>
>>
>>* =A0 =A0What's the best consistent representation of the words= "channel
>>numbers" for non-TV spectrum
>>* =A0 =A0Should we update the entire doc on the topic of =B3channel= =B2 or
>>=B3channel numbers=B2
>>* =A0 =A0What=B9s the best way to reduce vagueness in whether/how t= o include
>>"channel numbers"
>>* =A0 =A0Is the reference to variable power required
>>* =A0 =A0What does channel availability schedule mean
>>
>>
>>Brian's suggestion of replacing every instance of "channel= " is
>>technically correctly. However, it is important for us to focus mov= ing
>>forward. =A0I would suggest we only work on the normative part of t= he spec.
>> The section Gabor is proposing for us to modify...
>>
>>On what's the best generic label for the words "channel nu= mbers",
>>channel identifier might be the most accurate and neutral "lab= el".
>>Thoughts?
>>
>>On the question whether variable power is required, based on FCC >>adjacent-channel rules, the database may limit the Mode II devices = to
>>100mW for some channels and 40mW for others. Therefore, the data mo= del
>>needs to support specification of maximum power levels.
>>
>>Lastly, with regards to "schedule", the intent is to have= a way of
>>informing devices when to operate for each frequency range. As long= as
>>the data model supports, for example, a list of time ranges, it doe= s
>>not prevent an implementation from providing a list with 1 entry wh= ich
>>corresponds to the "shortest available". =A0The word &quo= t;schedule" should be
>>sufficient to capture this intent?
>>
>>We would like to propose the following text to address these points= :
>>
>>"The Data Model MUST support specifying available spectrum. Th= e Data
>>Model MUST support specification of this information by start and s= top
>>frequencies and MAY also support specification of this information = by
>>channel identifiers. The Data Model MUST support a
>>spectrum-availability schedule and maximum power levels for each >>frequency range."
>>
>>
>>Thoughts?
>>Eric
>>
>>
>>
>>On 8/10/12 5:48 AM, Teco Boot wrote:
>>
>>
>> =A0 =A0What about this:
>>
>> =A0 =A0 =A0 =A0=B3The Data Model MUST support specifying a list of= available
>>channels. The Data Model MUST support specification of this informa= tion
>>by start and stop frequencies, or equivalents such as center
>>frequencies with channel width or channel numbers with channel numm= er
>>allocation scheme . The Data Model MUST support a channel availabil= ity
>>schedule and maximum power level for each channel in the list.=B2 >>
>> =A0 =A0More thoughts on channel numbers: we likely run into proble= ms in
>>bands without a channel numbering scheme, or for example sub channe= ls
>>in TV bands.
>>
>> =A0 =A0Teco
>>
>>
>> =A0 =A0Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende g= eschreven:
>>
>>
>> =A0 =A0 =A0 =A0<as individual>
>> =A0 =A0 =A0 =A0While I don't care if it's center and width= or upper/lower, I
>>do think we will define the format in the protocol for interoperabi= lity
>>reasons, but don't need to do that in requirements. =A0It would= n't hurt
>>to decide now and use consistent terms, but we don't need to. >>
>> =A0 =A0 =A0 =A0I think "band" won't work, as it usua= lly implies a much wider
>>piece of spectrum that has a common purpose. =A0The TV Band is all = the
>>channels.
>>
>>
>> =A0 =A0 =A0 =A0On Aug 10, 2012, at 2:37 AM, Teco Boot <teco@inf-net.nl> wrote:
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0(somewhat late response)
>>
>> =A0 =A0 =A0 =A0 =A0 =A0A center frequency and channel width is fun= ctional
>>equivalent to start/stop frequencies. So is channel number, with re= f to
>>channel number assignment scheme. For a requirements document, we j= ust
>>need to specify what is needed. How it is encoded (Hz, wave length,=
>>channel ID) is solution space.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0Seen our goal to make PAWS somewhat univers= al (not limited
>>to US TVWS), I do not prefer using channel numbers.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0Teco
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0Op 9 aug. 2012, om 21:55 heeft <Gabor.Bajko@nokia.com>
>><Gabor.Bajko@nokia.com<= /a>> het volgende geschreven:
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Fol= ks,
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0During the last F2F meeting, there = was an agreement to
>>make a slight update to requirement D.7 in
>>http://www.ietf.org/id/draft-ietf-paws-p= roblem-stmt-usecases-rqmts-06.t
>>xt, =A0to make channel numbers optional to be supported. Ie, change= the
>>current
>>D.7
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=B3The Data Model MUST support spec= ifying a list of
>>available channels. The Data Model MUST support specification of th= is
>>information by channel numbers and by start and stop frequencies. T= he
>>Data Model MUST support a channel availability schedule and maximum=
>>power level for each channel in the list.=B2
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=B3The Data Model MUST support spec= ifying a list of
>>available channels. The Data Model MUST support specification of th= is
>>information by start and stop frequencies and MAY include channel >>numbers. The Data Model MUST support a channel availability schedul= e
>>and maximum power level for each channel in the list.=B2
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I=B9d like to confirm this change o= n the list. If anyone
>>has any objections, let me know. Otherwise I=B9ll plan to send the<= br> >>document to the iesg after this change is implemented.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- =A0 =A0 =A0 =A0 =A0Gabor
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0___________________________________= ____________
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0paws mailing list
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pa= ws@ietf.org
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo= /paws
>>
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0___________________________________________= ____
>> =A0 =A0 =A0 =A0 =A0 =A0paws mailing list
>> =A0 =A0 =A0 =A0 =A0 =A0paws@ietf.= org
>> =A0 =A0 =A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/paws
>>
>>
>>
>>
>>
>>
>>
>> =A0 =A0_______________________________________________
>> =A0 =A0paws mailing list
>> =A0 =A0paws@ietf.org
>> =A0 =A0https://www.ietf.org/mailman/listinfo/paws
>>
>>
>>
>>_______________________________________________
>>paws mailing list
>>paws@ietf.org
>>https://www.ietf.org/mailman/listinfo/paws
>
>_______________________________________________
>paws mailing list
>paws@ietf.org
>https://www.ietf.org/mailman/listinfo/paws
>_______________________________________________
>paws mailing list
>paws@ietf.org
>https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws



--
= -vince
--00248c768f6aec607c04c77845b7-- From Basavaraj.Patil@nokia.com Fri Aug 17 09:13:29 2012 Return-Path: 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 075C121F84EC for ; Fri, 17 Aug 2012 09:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.722 X-Spam-Level: X-Spam-Status: No, score=-105.722 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 rD49CSd0msj3 for ; Fri, 17 Aug 2012 09:13:27 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD6021F84DF for ; Fri, 17 Aug 2012 09:13:26 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7HGDJqU002501; Fri, 17 Aug 2012 19:13:21 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Aug 2012 19:14:25 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0283.004; Fri, 17 Aug 2012 18:13:18 +0200 From: To: , Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac132A+fbbG4lfLAT8aeYHhnRNTamABfuNkz///KeYD/+nkpcIAL38SAgAAwTID//6+CgA== Date: Fri, 17 Aug 2012 16:13:18 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [72.64.105.77] Content-Type: multipart/alternative; boundary="_000_CC53D7B8226B6basavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 17 Aug 2012 16:14:25.0098 (UTC) FILETIME=[5E7E3AA0:01CD7C93] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 16:13:29 -0000 --_000_CC53D7B8226B6basavarajpatilnokiacom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 DQpGV0lXLCBJIHdvdWxkIHByZWZlciB0byB1c2UgdGhlIHNlY29uZHMgc2luY2UgZXBvY2ggYXBw cm9hY2guDQoNCi1SYWoNCg0KRnJvbTogZXh0IFZpbmNlbnQgQ2hlbiA8dmNoZW5AZ29vZ2xlLmNv bTxtYWlsdG86dmNoZW5AZ29vZ2xlLmNvbT4+DQpEYXRlOiBGcmlkYXksIEF1Z3VzdCAxNywgMjAx MiAxMTowMSBBTQ0KVG86ICJCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpejxtYWlsdG86QnJpYW4uUm9z ZW5AbmV1c3Rhci5iaXo+IiA8QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo8bWFpbHRvOkJyaWFuLlJv c2VuQG5ldXN0YXIuYml6Pj4NCkNjOiAicGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9y Zz4iIDxwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBb cGF3c10gdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgZG9jdW1lbnQNCg0KQ29tbWVudHM6DQot IFRoZSBwcm9wb3NhbCBmb3IgbG9uZy1pbnRlZ2VyIHNlY29uZHMgd2FzIHRvIGdhdWdlIHByZWZl cmVuY2UgZnJvbSB0aGUgZGV2aWNlIGZvbGtzDQoNCi0gSWYgd2UgdXNlIElTTyA4NjAxLCBjb3Vs ZCB3ZSByZXN0cmljdCBpdCB0byBiZSBvbmx5IGluIFVUQz8gOikNCg0KDQoNCg0KT24gRnJpLCBB dWcgMTcsIDIwMTIgYXQgNjowOCBBTSwgUm9zZW4sIEJyaWFuIDxCcmlhbi5Sb3NlbkBuZXVzdGFy LmJpejxtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo+PiB3cm90ZToNClVoLCB0aGUgZGlm ZmVyZW5jZSBpcyByZXByZXNlbnRhdGlvbiBvZiBzdGFydC9zdG9wIHRpbWVzLiAgV2UgYm90aCBw cm9wb3NlDQp0byBzZW5kIHN0YXJ0L3N0b3AgdGltZXMuICBWaW5jZW50IHByb3Bvc2VzIHRoYXQg dGhlIHJlcHJlc2VudGF0aW9uIG9mDQp0aW1lIGJlIGEgbG9uZyBpbnRlZ2VyIHNlY29uZHMgc2lu Y2UgYW4gZXBvY2guICBIZSB3b3VsZCBzZW5kIHR3byBzdWNoDQpsb25nIGludGVnZXJzLiAgSSBw cm9wb3NlIGl0IGJlIGFuIElTTyA4NjAxIHRpbWUgc3RyaW5nLiAgU3BlY2lmaWNhbGx5LCBJDQp3 b3VsZCBwcm9wb3NlIGFuIElTTyA4NjAxIGludGVydmFsIGxpbWl0ZWQgdG8gc3RhcnQvZW5kLCBl LmcuDQoyMDExLTAzLTAxVDEzOjAwOjAwWi8yMDEyLTA1LTExVDE1OjMwOjAwWi4NCg0KT24gOC8x Ni8xMiA2OjQ1IFBNLCAiR2Fib3IuQmFqa29Abm9raWEuY29tPG1haWx0bzpHYWJvci5CYWprb0Bu b2tpYS5jb20+IiA8R2Fib3IuQmFqa29Abm9raWEuY29tPG1haWx0bzpHYWJvci5CYWprb0Bub2tp YS5jb20+PiB3cm90ZToNCg0KPkl0IHNlZW1zIHdlIGhhdmUgYW4gYWdyZWVtZW50IG9uIHRoZSBy ZXF1aXJlbWVudCB0byBpZGVudGlmeSB0aGUNCj5zcGVjdHJ1bSwgYnkgdXNpbmcgdGhlIHN0YXJ0 L3N0b3AgZnJlcXVlbmNpZXMsIHdpdGggb3B0aW9uYWwgY2hhbm5lbA0KPmlkZW50aWZpZXJzLg0K Pg0KPldydCB0byB0aGUgc2NoZWR1bGUsIHdlIGhhdmUgc28gZmFyIHR3byBwcm9wb3NhbHMsIG9u ZSBmcm9tIEJyaWFuDQo+cHJvcG9zaW5nIHRoZSB1c2Ugb2Ygc3RhcnQvc3RvcCB0aW1lcyBmb3Ig ZWFjaCBzcGVjdHJ1bSB1bml0IGF2YWlsYWJsZSwNCj5hbmQgb25lIGZyb20gVmluY2VudCBwcm9w b3NpbmcgdG8gdXNlIG9mIFVuaXggRXBvY2ggdGltZSBpbiBzZWNvbmRzLiBXZQ0KPm5lZWQgdG8g ZGVjaWRlIG9uIHRoaXMsIHNvIHBsZWFzZSBzZW5kIHlvdXIgcHJlZmVyZW5jZSBvbiB0aGlzIHRv cGljIHRvDQo+dGhlIGxpc3QuDQo+DQo+LSBHYWJvcg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+RnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwYXdzLWJvdW5jZXNA aWV0Zi5vcmc+IFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwYXdzLWJvdW5j ZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YNCj5Qcm9iYXNjbyBTY290dCAoTm9raWEtQ0lDL0Rh bGxhcykNCj5TZW50OiBNb25kYXksIEF1Z3VzdCAxMywgMjAxMiAxMDoxMiBBTQ0KPlRvOiBwYXdz QGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KPlN1YmplY3Q6IFJlOiBbcGF3c10gdXNl IGNhc2VzIGFuZCByZXF1aXJlbWVudHMgZG9jdW1lbnQNCj4NCj5IaSBBbGwsDQo+DQo+R2l2ZW4g dGhhdCB3ZSBoYXZlIGNvbXBsZXRlZCB0d28gV29ya2luZyBHcm91cCBMYXN0IENhbGwgY3ljbGVz IGFuZCB0aGlzDQo+bmV4dCB2ZXJzaW9uIHdpbGwgZ28gdG8gdGhlIElFU0csIEkgaG9wZSB3ZSBj b3VsZCBhZ3JlZSBvbiBtaW5pbWFsDQo+Y2hhbmdlcyB0byB0aGUgZG9jdW1lbnQsIGkuZS4gY2hh bmdlcyBvbmx5IHRvIEQuNyBmb3IgdGhpcyB0b3BpYy4gVGhpcw0KPndpbGwgZW5zdXJlIHRoZSBw cm9wZXIgcmVxdWlyZW1lbnRzIGFyZSBlc3RhYmxpc2hlZCBmb3IgdGhlIGRldmVsb3BpbmcNCj5Q QVdTIHByb3RvY29sLg0KPkkgYmVsaWV2ZSBCcmlhbidzIHByb3Bvc2VkIHRleHQgY2FwdHVyZXMg dGhlIGVzc2VudGlhbCByZXF1aXJlbWVudHMuDQo+DQo+S2luZCBSZWdhcmRzLA0KPlNjb3R0DQo+ DQo+DQo+T24gOC8xMy8xMiA4OjI0IEFNLCAiZXh0IFJvc2VuLCBCcmlhbiIgPEJyaWFuLlJvc2Vu QG5ldXN0YXIuYml6PG1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej4+IHdyb3RlOg0KPg0K Pj48YXMgaW5kaXZpZHVhbD4NCj4+SSB3b3VsZCBwcmVmZXIgdG8gbm90IHVzZSB0aGUgd29yZCAi Y2hhbm5lbCIgaW4gb3VyIGRvY3VtZW50cyBhdCBhbGwNCj4+ZXhjZXB0IGZvciB0aGUgdGVybSAi Y2hhbm5lbCBpZGVudGlmaWVyIi4gIEkgcHJvcG9zZWQgInNwZWN0cnVtIHVuaXQiLA0KPj5hbHRo b3VnaCBhbnkgb3RoZXIgdGVybSB3aWxsIGRvLiAgIkNoYW5uZWwiIGhhcyB0b28gbXVjaCBiYWdn YWdlLCAgQQ0KPj5zaW1wbGUgZWRpdG9yaWFsIGNoYW5nZSBsaWtlIHRoaXMgaXMgc2ltcGxlLCBh bmQgaXQncyBtdWNoIGJldHRlciB0byBkbw0KPj5pdCBub3cuDQo+Pg0KPj5JIHRoaW5rIHdlIG5l ZWQgcG93ZXIgaW4gYm90aCB0aGUgcXVlcnkgYW5kIHRoZSByZXNwb25zZS4gIEluIHNvbWUNCj4+ ZG9tYWlucywgaXQgbWF5IGJlIHRoYXQgeW91IHNwZWNpZnkgd2hhdCBwb3dlciB5b3Ugd2FudCB0 byB1c2UgYW5kIHRoZQ0KPj5EQiB0ZWxscyB5b3Ugd2hhdCBzcGVjdHJ1bSB5b3UgY2FuIHVzZSBh dCB0aGF0IHBvd2VyLiAgSW4gb3RoZXIsIGENCj4+VVMtbGlrZSBydWxlIG1heSBiZSBpbiBwbGFj ZS4gIEFsc28gaW4gZWl0aGVyIHRoZSBxdWVyeSBvciB0aGUNCj4+cmVnaXN0cmF0aW9uLCB3ZSBu ZWVkIGEgZGV2aWNlIHR5cGUsIHdoaWNoIHNob3VsZCBiZSBhbiBlbnRyeSBmcm9tIGFuDQo+PklB TkEgcmVnaXN0cnkuICBUaGlzIGlzIGhvdyB5b3UgZ2V0IHRoZSBVUyAiTW9kZSBJSSIgaW5mb3Jt YXRpb24uDQo+Pg0KPj5XaXRoIHJlZ2FyZCB0byBzY2hlZHVsZSwgSSB3b3VsZCBsaWtlIHRvIHNl ZSB0d28gbWVjaGFuaXNtcw0KPj4xKSBhIHRpbWUgYnkgd2hpY2ggdGhlIGRhdGFiYXNlIHNob3Vs ZCBiZSBxdWVyaWVkIGFnYWluICh3aGljaCBjb3VsZA0KPj5yZXByZXNlbnQgdGhlIG5leHQgY2hh bmdlIGluIHNjaGVkdWxlKQ0KPj4yKSBzdGFydC9zdG9wIHRpbWVzIGZvciBlYWNoIHNwZWN0cnVt IHVuaXQgYXZhaWxhYmxlDQo+Pg0KPj5Cb3RoIHRoZXNlIHNob3VsZCBiZSBvcHRpb25hbCBpbiB0 aGUgcmVzcG9uc2UuDQo+Pg0KPj5NeSB0ZXh0DQo+Pg0KPj5UaGUgZGF0YSBtb2RlbCBtdXN0IHN1 cHBvcnQgc3BlY2lmeWluZyBzcGVjdHJ1bSBhdmFpbGFiaWxpdHkuICBTcGVjdHJ1bQ0KPj51bml0 cyBhcmUgc3BlY2lmaWVkIGJ5IGxvdyBhbmQgaGlnaCBmcmVxdWVuY2llcyBhbmQgbWF5IGhhdmUg YW4NCj4+b3B0aW9uYWwgY2hhbm5lbCBpZGVudGlmaWVyLg0KPj4NCj4+VGhlIGRhdGEgbW9kZWwg bXVzdCBzdXBwb3J0IGEgc2NoZWR1bGUgZm9yIHNwZWN0cnVtIHVuaXQgYXZhaWxhYmlsaXR5Lg0K Pj5Ud28gbWVjaGFuaXNtcyBtdXN0IGJlIHN1cHBvcnRlZC4gIFRoZSByZXNwb25zZSB0byBzcGVj dHJ1bQ0KPj5hdmFpbGFiaWxpdHkgcXVlcnkgbWF5IGluY2x1ZGUgYSB0aW1lIGJ5IHdoaWNoIHRo ZSBkYXRhYmFzZSBtdXN0IGJlDQo+PnJlcXVlcmllZC4gIEVhY2ggc3BlY3RydW0gdW5pdCBtZW50 aW9uZWQgaW4gdGhlIHJlc3BvbnNlIG1heSBiZQ0KPj5hbm5vdGF0ZWQgd2l0aCBzdGFydCBhbmQg c3RvcCB0aW1lL2RhdGUuDQo+Pg0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj5Gcm9tOiAgICAgRXJpYyBDaHUgW21haWx0bzplcmljY2h1QGdvb2dsZS5jb208bWFpbHRv OmVyaWNjaHVAZ29vZ2xlLmNvbT5dDQo+PlNlbnQ6ICAgIFNhdHVyZGF5LCBBdWd1c3QgMTEsIDIw MTIgMTE6NDMgQU0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQo+PlRvOiAgICBUZWNvIEJvb3QNCj4+ Q2M6ICAgIFJvc2VuLCBCcmlhbjsgcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4N Cj4+U3ViamVjdDogICAgUmU6IFtwYXdzXSB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cyBkb2N1 bWVudA0KPj4NCj4+DQo+PkhpIGV2ZXJ5b25lLA0KPj4NCj4+R2F0aGVyaW5nIGFsbCB0aGUgc2hh cmVkIHBvaW50cyBmcm9tIGV2ZXJ5b25lLi4uIEkgYmVsaWV2ZSBiZWxvdyBpcyB0aGUNCj4+Y29t cGxldGUgbGlzdCBzbyBmYXI6DQo+Pg0KPj4NCj4+DQo+PiogICAgV2hhdCdzIHRoZSBiZXN0IGNv bnNpc3RlbnQgcmVwcmVzZW50YXRpb24gb2YgdGhlIHdvcmRzICJjaGFubmVsDQo+Pm51bWJlcnMi IGZvciBub24tVFYgc3BlY3RydW0NCj4+KiAgICBTaG91bGQgd2UgdXBkYXRlIHRoZSBlbnRpcmUg ZG9jIG9uIHRoZSB0b3BpYyBvZiCp+GNoYW5uZWyp9yBvcg0KPj6p+GNoYW5uZWwgbnVtYmVyc6n3 DQo+PiogICAgV2hhdKn2cyB0aGUgYmVzdCB3YXkgdG8gcmVkdWNlIHZhZ3VlbmVzcyBpbiB3aGV0 aGVyL2hvdyB0byBpbmNsdWRlDQo+PiJjaGFubmVsIG51bWJlcnMiDQo+PiogICAgSXMgdGhlIHJl ZmVyZW5jZSB0byB2YXJpYWJsZSBwb3dlciByZXF1aXJlZA0KPj4qICAgIFdoYXQgZG9lcyBjaGFu bmVsIGF2YWlsYWJpbGl0eSBzY2hlZHVsZSBtZWFuDQo+Pg0KPj4NCj4+QnJpYW4ncyBzdWdnZXN0 aW9uIG9mIHJlcGxhY2luZyBldmVyeSBpbnN0YW5jZSBvZiAiY2hhbm5lbCIgaXMNCj4+dGVjaG5p Y2FsbHkgY29ycmVjdGx5LiBIb3dldmVyLCBpdCBpcyBpbXBvcnRhbnQgZm9yIHVzIHRvIGZvY3Vz IG1vdmluZw0KPj5mb3J3YXJkLiAgSSB3b3VsZCBzdWdnZXN0IHdlIG9ubHkgd29yayBvbiB0aGUg bm9ybWF0aXZlIHBhcnQgb2YgdGhlIHNwZWMuDQo+PiBUaGUgc2VjdGlvbiBHYWJvciBpcyBwcm9w b3NpbmcgZm9yIHVzIHRvIG1vZGlmeS4uLg0KPj4NCj4+T24gd2hhdCdzIHRoZSBiZXN0IGdlbmVy aWMgbGFiZWwgZm9yIHRoZSB3b3JkcyAiY2hhbm5lbCBudW1iZXJzIiwNCj4+Y2hhbm5lbCBpZGVu dGlmaWVyIG1pZ2h0IGJlIHRoZSBtb3N0IGFjY3VyYXRlIGFuZCBuZXV0cmFsICJsYWJlbCIuDQo+ PlRob3VnaHRzPw0KPj4NCj4+T24gdGhlIHF1ZXN0aW9uIHdoZXRoZXIgdmFyaWFibGUgcG93ZXIg aXMgcmVxdWlyZWQsIGJhc2VkIG9uIEZDQw0KPj5hZGphY2VudC1jaGFubmVsIHJ1bGVzLCB0aGUg ZGF0YWJhc2UgbWF5IGxpbWl0IHRoZSBNb2RlIElJIGRldmljZXMgdG8NCj4+MTAwbVcgZm9yIHNv bWUgY2hhbm5lbHMgYW5kIDQwbVcgZm9yIG90aGVycy4gVGhlcmVmb3JlLCB0aGUgZGF0YSBtb2Rl bA0KPj5uZWVkcyB0byBzdXBwb3J0IHNwZWNpZmljYXRpb24gb2YgbWF4aW11bSBwb3dlciBsZXZl bHMuDQo+Pg0KPj5MYXN0bHksIHdpdGggcmVnYXJkcyB0byAic2NoZWR1bGUiLCB0aGUgaW50ZW50 IGlzIHRvIGhhdmUgYSB3YXkgb2YNCj4+aW5mb3JtaW5nIGRldmljZXMgd2hlbiB0byBvcGVyYXRl IGZvciBlYWNoIGZyZXF1ZW5jeSByYW5nZS4gQXMgbG9uZyBhcw0KPj50aGUgZGF0YSBtb2RlbCBz dXBwb3J0cywgZm9yIGV4YW1wbGUsIGEgbGlzdCBvZiB0aW1lIHJhbmdlcywgaXQgZG9lcw0KPj5u b3QgcHJldmVudCBhbiBpbXBsZW1lbnRhdGlvbiBmcm9tIHByb3ZpZGluZyBhIGxpc3Qgd2l0aCAx IGVudHJ5IHdoaWNoDQo+PmNvcnJlc3BvbmRzIHRvIHRoZSAic2hvcnRlc3QgYXZhaWxhYmxlIi4g IFRoZSB3b3JkICJzY2hlZHVsZSIgc2hvdWxkIGJlDQo+PnN1ZmZpY2llbnQgdG8gY2FwdHVyZSB0 aGlzIGludGVudD8NCj4+DQo+PldlIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93aW5n IHRleHQgdG8gYWRkcmVzcyB0aGVzZSBwb2ludHM6DQo+Pg0KPj4iVGhlIERhdGEgTW9kZWwgTVVT VCBzdXBwb3J0IHNwZWNpZnlpbmcgYXZhaWxhYmxlIHNwZWN0cnVtLiBUaGUgRGF0YQ0KPj5Nb2Rl bCBNVVNUIHN1cHBvcnQgc3BlY2lmaWNhdGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IHN0YXJ0 IGFuZCBzdG9wDQo+PmZyZXF1ZW5jaWVzIGFuZCBNQVkgYWxzbyBzdXBwb3J0IHNwZWNpZmljYXRp b24gb2YgdGhpcyBpbmZvcm1hdGlvbiBieQ0KPj5jaGFubmVsIGlkZW50aWZpZXJzLiBUaGUgRGF0 YSBNb2RlbCBNVVNUIHN1cHBvcnQgYQ0KPj5zcGVjdHJ1bS1hdmFpbGFiaWxpdHkgc2NoZWR1bGUg YW5kIG1heGltdW0gcG93ZXIgbGV2ZWxzIGZvciBlYWNoDQo+PmZyZXF1ZW5jeSByYW5nZS4iDQo+ Pg0KPj4NCj4+VGhvdWdodHM/DQo+PkVyaWMNCj4+DQo+Pg0KPj4NCj4+T24gOC8xMC8xMiA1OjQ4 IEFNLCBUZWNvIEJvb3Qgd3JvdGU6DQo+Pg0KPj4NCj4+ICAgIFdoYXQgYWJvdXQgdGhpczoNCj4+ DQo+PiAgICAgICAgqfhUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyBhIGxp c3Qgb2YgYXZhaWxhYmxlDQo+PmNoYW5uZWxzLiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQg c3BlY2lmaWNhdGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uDQo+PmJ5IHN0YXJ0IGFuZCBzdG9wIGZy ZXF1ZW5jaWVzLCBvciBlcXVpdmFsZW50cyBzdWNoIGFzIGNlbnRlcg0KPj5mcmVxdWVuY2llcyB3 aXRoIGNoYW5uZWwgd2lkdGggb3IgY2hhbm5lbCBudW1iZXJzIHdpdGggY2hhbm5lbCBudW1tZXIN Cj4+YWxsb2NhdGlvbiBzY2hlbWUgLiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgYSBjaGFu bmVsIGF2YWlsYWJpbGl0eQ0KPj5zY2hlZHVsZSBhbmQgbWF4aW11bSBwb3dlciBsZXZlbCBmb3Ig ZWFjaCBjaGFubmVsIGluIHRoZSBsaXN0Lqn3DQo+Pg0KPj4gICAgTW9yZSB0aG91Z2h0cyBvbiBj aGFubmVsIG51bWJlcnM6IHdlIGxpa2VseSBydW4gaW50byBwcm9ibGVtcyBpbg0KPj5iYW5kcyB3 aXRob3V0IGEgY2hhbm5lbCBudW1iZXJpbmcgc2NoZW1lLCBvciBmb3IgZXhhbXBsZSBzdWIgY2hh bm5lbHMNCj4+aW4gVFYgYmFuZHMuDQo+Pg0KPj4gICAgVGVjbw0KPj4NCj4+DQo+PiAgICBPcCAx MCBhdWcuIDIwMTIsIG9tIDEzOjU3IGhlZWZ0IFJvc2VuLCBCcmlhbiBoZXQgdm9sZ2VuZGUgZ2Vz Y2hyZXZlbjoNCj4+DQo+Pg0KPj4gICAgICAgIDxhcyBpbmRpdmlkdWFsPg0KPj4gICAgICAgIFdo aWxlIEkgZG9uJ3QgY2FyZSBpZiBpdCdzIGNlbnRlciBhbmQgd2lkdGggb3IgdXBwZXIvbG93ZXIs IEkNCj4+ZG8gdGhpbmsgd2Ugd2lsbCBkZWZpbmUgdGhlIGZvcm1hdCBpbiB0aGUgcHJvdG9jb2wg Zm9yIGludGVyb3BlcmFiaWxpdHkNCj4+cmVhc29ucywgYnV0IGRvbid0IG5lZWQgdG8gZG8gdGhh dCBpbiByZXF1aXJlbWVudHMuICBJdCB3b3VsZG4ndCBodXJ0DQo+PnRvIGRlY2lkZSBub3cgYW5k IHVzZSBjb25zaXN0ZW50IHRlcm1zLCBidXQgd2UgZG9uJ3QgbmVlZCB0by4NCj4+DQo+PiAgICAg ICAgSSB0aGluayAiYmFuZCIgd29uJ3Qgd29yaywgYXMgaXQgdXN1YWxseSBpbXBsaWVzIGEgbXVj aCB3aWRlcg0KPj5waWVjZSBvZiBzcGVjdHJ1bSB0aGF0IGhhcyBhIGNvbW1vbiBwdXJwb3NlLiAg VGhlIFRWIEJhbmQgaXMgYWxsIHRoZQ0KPj5jaGFubmVscy4NCj4+DQo+Pg0KPj4gICAgICAgIE9u IEF1ZyAxMCwgMjAxMiwgYXQgMjozNyBBTSwgVGVjbyBCb290IDx0ZWNvQGluZi1uZXQubmw8bWFp bHRvOnRlY29AaW5mLW5ldC5ubD4+IHdyb3RlOg0KPj4NCj4+DQo+PiAgICAgICAgICAgIChzb21l d2hhdCBsYXRlIHJlc3BvbnNlKQ0KPj4NCj4+ICAgICAgICAgICAgQSBjZW50ZXIgZnJlcXVlbmN5 IGFuZCBjaGFubmVsIHdpZHRoIGlzIGZ1bmN0aW9uYWwNCj4+ZXF1aXZhbGVudCB0byBzdGFydC9z dG9wIGZyZXF1ZW5jaWVzLiBTbyBpcyBjaGFubmVsIG51bWJlciwgd2l0aCByZWYgdG8NCj4+Y2hh bm5lbCBudW1iZXIgYXNzaWdubWVudCBzY2hlbWUuIEZvciBhIHJlcXVpcmVtZW50cyBkb2N1bWVu dCwgd2UganVzdA0KPj5uZWVkIHRvIHNwZWNpZnkgd2hhdCBpcyBuZWVkZWQuIEhvdyBpdCBpcyBl bmNvZGVkIChIeiwgd2F2ZSBsZW5ndGgsDQo+PmNoYW5uZWwgSUQpIGlzIHNvbHV0aW9uIHNwYWNl Lg0KPj4NCj4+ICAgICAgICAgICAgU2VlbiBvdXIgZ29hbCB0byBtYWtlIFBBV1Mgc29tZXdoYXQg dW5pdmVyc2FsIChub3QgbGltaXRlZA0KPj50byBVUyBUVldTKSwgSSBkbyBub3QgcHJlZmVyIHVz aW5nIGNoYW5uZWwgbnVtYmVycy4NCj4+DQo+PiAgICAgICAgICAgIFRlY28NCj4+DQo+Pg0KPj4g ICAgICAgICAgICBPcCA5IGF1Zy4gMjAxMiwgb20gMjE6NTUgaGVlZnQgPEdhYm9yLkJhamtvQG5v a2lhLmNvbTxtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tPj4NCj4+PEdhYm9yLkJhamtvQG5v a2lhLmNvbTxtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tPj4gaGV0IHZvbGdlbmRlIGdlc2No cmV2ZW46DQo+Pg0KPj4NCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGb2xrcywN Cj4+DQo+PiAgICAgICAgICAgICAgICBEdXJpbmcgdGhlIGxhc3QgRjJGIG1lZXRpbmcsIHRoZXJl IHdhcyBhbiBhZ3JlZW1lbnQgdG8NCj4+bWFrZSBhIHNsaWdodCB1cGRhdGUgdG8gcmVxdWlyZW1l bnQgRC43IGluDQo+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1wYXdzLXByb2Js ZW0tc3RtdC11c2VjYXNlcy1ycW10cy0wNi50DQo+Pnh0LCAgdG8gbWFrZSBjaGFubmVsIG51bWJl cnMgb3B0aW9uYWwgdG8gYmUgc3VwcG9ydGVkLiBJZSwgY2hhbmdlIHRoZQ0KPj5jdXJyZW50DQo+ PkQuNw0KPj4gICAgICAgICAgICAgICAgqfhUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3Bl Y2lmeWluZyBhIGxpc3Qgb2YNCj4+YXZhaWxhYmxlIGNoYW5uZWxzLiBUaGUgRGF0YSBNb2RlbCBN VVNUIHN1cHBvcnQgc3BlY2lmaWNhdGlvbiBvZiB0aGlzDQo+PmluZm9ybWF0aW9uIGJ5IGNoYW5u ZWwgbnVtYmVycyBhbmQgYnkgc3RhcnQgYW5kIHN0b3AgZnJlcXVlbmNpZXMuIFRoZQ0KPj5EYXRh IE1vZGVsIE1VU1Qgc3VwcG9ydCBhIGNoYW5uZWwgYXZhaWxhYmlsaXR5IHNjaGVkdWxlIGFuZCBt YXhpbXVtDQo+PnBvd2VyIGxldmVsIGZvciBlYWNoIGNoYW5uZWwgaW4gdGhlIGxpc3QuqfcNCj4+ ICAgICAgICAgICAgICAgIHRvDQo+PiAgICAgICAgICAgICAgICCp+FRoZSBEYXRhIE1vZGVsIE1V U1Qgc3VwcG9ydCBzcGVjaWZ5aW5nIGEgbGlzdCBvZg0KPj5hdmFpbGFibGUgY2hhbm5lbHMuIFRo ZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZpY2F0aW9uIG9mIHRoaXMNCj4+aW5mb3Jt YXRpb24gYnkgc3RhcnQgYW5kIHN0b3AgZnJlcXVlbmNpZXMgYW5kIE1BWSBpbmNsdWRlIGNoYW5u ZWwNCj4+bnVtYmVycy4gVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IGEgY2hhbm5lbCBhdmFp bGFiaWxpdHkgc2NoZWR1bGUNCj4+YW5kIG1heGltdW0gcG93ZXIgbGV2ZWwgZm9yIGVhY2ggY2hh bm5lbCBpbiB0aGUgbGlzdC6p9w0KPj4NCj4+ICAgICAgICAgICAgICAgIEmp9mQgbGlrZSB0byBj b25maXJtIHRoaXMgY2hhbmdlIG9uIHRoZSBsaXN0LiBJZiBhbnlvbmUNCj4+aGFzIGFueSBvYmpl Y3Rpb25zLCBsZXQgbWUga25vdy4gT3RoZXJ3aXNlIEmp9mxsIHBsYW4gdG8gc2VuZCB0aGUNCj4+ ZG9jdW1lbnQgdG8gdGhlIGllc2cgYWZ0ZXIgdGhpcyBjaGFuZ2UgaXMgaW1wbGVtZW50ZWQuDQo+ Pg0KPj4gICAgICAgICAgICAgICAgLSAgICAgICAgICBHYWJvcg0KPj4gICAgICAgICAgICAgICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ICAgICAg ICAgICAgICAgIHBhd3MgbWFpbGluZyBsaXN0DQo+PiAgICAgICAgICAgICAgICBwYXdzQGlldGYu b3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KPj4gICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+Pg0KPj4NCj4+DQo+PiAgICAgICAgICAg IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiAgICAg ICAgICAgIHBhd3MgbWFpbGluZyBsaXN0DQo+PiAgICAgICAgICAgIHBhd3NAaWV0Zi5vcmc8bWFp bHRvOnBhd3NAaWV0Zi5vcmc+DQo+PiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcGF3cw0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+ICAgIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiAgICBwYXdz IG1haWxpbmcgbGlzdA0KPj4gICAgcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4N Cj4+ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4NCj4+ DQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj5wYXdzIG1haWxpbmcgbGlzdA0KPj5wYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3Jn Pg0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4NCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnBhd3MgbWFpbGlu ZyBsaXN0DQo+cGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPnBhd3MgbWFpbGluZyBsaXN0DQo+cGF3c0BpZXRm Lm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Bhd3MNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnBhd3MgbWFpbGluZyBsaXN0DQpwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg0K DQotLQ0KLXZpbmNlDQo= --_000_CC53D7B8226B6basavarajpatilnokiacom_ Content-Type: text/html; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5GV0lXLCBJIHdvdWxkIHByZWZlciB0byB1c2UgdGhlIHNlY29uZHMgc2luY2Ug ZXBvY2ggYXBwcm9hY2guPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tUmFqPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWdu OmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxF RlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsg UEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVS LVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPmV4dCBWaW5jZW50IENoZW4gJmx0OzxhIGhyZWY9 Im1haWx0bzp2Y2hlbkBnb29nbGUuY29tIj52Y2hlbkBnb29nbGUuY29tPC9hPiZndDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPkZyaWRheSwgQXVndXN0 IDE3LCAyMDEyIDExOjAxIEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRv OiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6Ij5C cmlhbi5Sb3NlbkBuZXVzdGFyLmJpejwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpCcmlh bi5Sb3NlbkBuZXVzdGFyLmJpeiI+QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo8L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9 Im1haWx0bzpwYXdzQGlldGYub3JnIj5wYXdzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciPnBhd3NAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtwYXdzXSB1c2Ug Y2FzZXMgYW5kIHJlcXVpcmVtZW50cyBkb2N1bWVudDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj5Db21tZW50czo8L2Rpdj4NCi0gVGhlIHByb3Bvc2Fs IGZvciBsb25nLWludGVnZXIgc2Vjb25kcyB3YXMgdG8gZ2F1Z2UgcHJlZmVyZW5jZSBmcm9tIHRo ZSBkZXZpY2UgZm9sa3MNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi0gSWYgd2UgdXNlIElTTyA4 NjAxLCBjb3VsZCB3ZSByZXN0cmljdCBpdCB0byBiZSBvbmx5IGluIFVUQz8gOikmbmJzcDs8YnI+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZXh0cmEiPjxicj4NCjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBG cmksIEF1ZyAxNywgMjAxMiBhdCA2OjA4IEFNLCBSb3NlbiwgQnJpYW4gPHNwYW4gZGlyPSJsdHIi Pg0KJmx0OzxhIGhyZWY9Im1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpeiIgdGFyZ2V0PSJf YmxhbmsiPkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4N CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4 O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KVWgsIHRoZSBk aWZmZXJlbmNlIGlzIHJlcHJlc2VudGF0aW9uIG9mIHN0YXJ0L3N0b3AgdGltZXMuICZuYnNwO1dl IGJvdGggcHJvcG9zZTxicj4NCnRvIHNlbmQgc3RhcnQvc3RvcCB0aW1lcy4gJm5ic3A7VmluY2Vu dCBwcm9wb3NlcyB0aGF0IHRoZSByZXByZXNlbnRhdGlvbiBvZjxicj4NCnRpbWUgYmUgYSBsb25n IGludGVnZXIgc2Vjb25kcyBzaW5jZSBhbiBlcG9jaC4gJm5ic3A7SGUgd291bGQgc2VuZCB0d28g c3VjaDxicj4NCmxvbmcgaW50ZWdlcnMuICZuYnNwO0kgcHJvcG9zZSBpdCBiZSBhbiBJU08gODYw MSB0aW1lIHN0cmluZy4gJm5ic3A7U3BlY2lmaWNhbGx5LCBJPGJyPg0Kd291bGQgcHJvcG9zZSBh biBJU08gODYwMSBpbnRlcnZhbCBsaW1pdGVkIHRvIHN0YXJ0L2VuZCwgZS5nLjxicj4NCjIwMTEt MDMtMDFUMTM6MDA6MDBaLzIwMTItMDUtMTFUMTU6MzA6MDBaLjxicj4NCjxkaXYgY2xhc3M9IkhP RW5aYiI+DQo8ZGl2IGNsYXNzPSJoNSI+PGJyPg0KT24gOC8xNi8xMiA2OjQ1IFBNLCAmcXVvdDs8 YSBocmVmPSJtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tIj5HYWJvci5CYWprb0Bub2tpYS5j b208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tIj5H YWJvci5CYWprb0Bub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7SXQgc2Vl bXMgd2UgaGF2ZSBhbiBhZ3JlZW1lbnQgb24gdGhlIHJlcXVpcmVtZW50IHRvIGlkZW50aWZ5IHRo ZTxicj4NCiZndDtzcGVjdHJ1bSwgYnkgdXNpbmcgdGhlIHN0YXJ0L3N0b3AgZnJlcXVlbmNpZXMs IHdpdGggb3B0aW9uYWwgY2hhbm5lbDxicj4NCiZndDtpZGVudGlmaWVycy48YnI+DQomZ3Q7PGJy Pg0KJmd0O1dydCB0byB0aGUgc2NoZWR1bGUsIHdlIGhhdmUgc28gZmFyIHR3byBwcm9wb3NhbHMs IG9uZSBmcm9tIEJyaWFuPGJyPg0KJmd0O3Byb3Bvc2luZyB0aGUgdXNlIG9mIHN0YXJ0L3N0b3Ag dGltZXMgZm9yIGVhY2ggc3BlY3RydW0gdW5pdCBhdmFpbGFibGUsPGJyPg0KJmd0O2FuZCBvbmUg ZnJvbSBWaW5jZW50IHByb3Bvc2luZyB0byB1c2Ugb2YgVW5peCBFcG9jaCB0aW1lIGluIHNlY29u ZHMuIFdlPGJyPg0KJmd0O25lZWQgdG8gZGVjaWRlIG9uIHRoaXMsIHNvIHBsZWFzZSBzZW5kIHlv dXIgcHJlZmVyZW5jZSBvbiB0aGlzIHRvcGljIHRvPGJyPg0KJmd0O3RoZSBsaXN0Ljxicj4NCiZn dDs8YnI+DQomZ3Q7LSBHYWJvcjxicj4NCiZndDs8YnI+DQomZ3Q7LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQomZ3Q7RnJvbTogPGEgaHJlZj0ibWFpbHRvOnBhd3MtYm91bmNlc0BpZXRm Lm9yZyI+cGF3cy1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpw YXdzLWJvdW5jZXNAaWV0Zi5vcmciPnBhd3MtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFs ZiBPZjxicj4NCiZndDtQcm9iYXNjbyBTY290dCAoTm9raWEtQ0lDL0RhbGxhcyk8YnI+DQomZ3Q7 U2VudDogTW9uZGF5LCBBdWd1c3QgMTMsIDIwMTIgMTA6MTIgQU08YnI+DQomZ3Q7VG86IDxhIGhy ZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIj5wYXdzQGlldGYub3JnPC9hPjxicj4NCiZndDtTdWJq ZWN0OiBSZTogW3Bhd3NdIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGRvY3VtZW50PGJyPg0K Jmd0Ozxicj4NCiZndDtIaSBBbGwsPGJyPg0KJmd0Ozxicj4NCiZndDtHaXZlbiB0aGF0IHdlIGhh dmUgY29tcGxldGVkIHR3byBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBjeWNsZXMgYW5kIHRoaXM8 YnI+DQomZ3Q7bmV4dCB2ZXJzaW9uIHdpbGwgZ28gdG8gdGhlIElFU0csIEkgaG9wZSB3ZSBjb3Vs ZCBhZ3JlZSBvbiBtaW5pbWFsPGJyPg0KJmd0O2NoYW5nZXMgdG8gdGhlIGRvY3VtZW50LCBpLmUu IGNoYW5nZXMgb25seSB0byBELjcgZm9yIHRoaXMgdG9waWMuIFRoaXM8YnI+DQomZ3Q7d2lsbCBl bnN1cmUgdGhlIHByb3BlciByZXF1aXJlbWVudHMgYXJlIGVzdGFibGlzaGVkIGZvciB0aGUgZGV2 ZWxvcGluZzxicj4NCiZndDtQQVdTIHByb3RvY29sLjxicj4NCiZndDtJIGJlbGlldmUgQnJpYW4n cyBwcm9wb3NlZCB0ZXh0IGNhcHR1cmVzIHRoZSBlc3NlbnRpYWwgcmVxdWlyZW1lbnRzLjxicj4N CiZndDs8YnI+DQomZ3Q7S2luZCBSZWdhcmRzLDxicj4NCiZndDtTY290dDxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0O09uIDgvMTMvMTIgODoyNCBBTSwgJnF1b3Q7ZXh0IFJvc2VuLCBCcmlh biZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6Ij5Ccmlh bi5Sb3NlbkBuZXVzdGFyLmJpejwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0 OyZsdDthcyBpbmRpdmlkdWFsJmd0Ozxicj4NCiZndDsmZ3Q7SSB3b3VsZCBwcmVmZXIgdG8gbm90 IHVzZSB0aGUgd29yZCAmcXVvdDtjaGFubmVsJnF1b3Q7IGluIG91ciBkb2N1bWVudHMgYXQgYWxs PGJyPg0KJmd0OyZndDtleGNlcHQgZm9yIHRoZSB0ZXJtICZxdW90O2NoYW5uZWwgaWRlbnRpZmll ciZxdW90Oy4gJm5ic3A7SSBwcm9wb3NlZCAmcXVvdDtzcGVjdHJ1bSB1bml0JnF1b3Q7LDxicj4N CiZndDsmZ3Q7YWx0aG91Z2ggYW55IG90aGVyIHRlcm0gd2lsbCBkby4gJm5ic3A7JnF1b3Q7Q2hh bm5lbCZxdW90OyBoYXMgdG9vIG11Y2ggYmFnZ2FnZSwgJm5ic3A7QTxicj4NCiZndDsmZ3Q7c2lt cGxlIGVkaXRvcmlhbCBjaGFuZ2UgbGlrZSB0aGlzIGlzIHNpbXBsZSwgYW5kIGl0J3MgbXVjaCBi ZXR0ZXIgdG8gZG88YnI+DQomZ3Q7Jmd0O2l0IG5vdy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7SSB0aGluayB3ZSBuZWVkIHBvd2VyIGluIGJvdGggdGhlIHF1ZXJ5IGFuZCB0aGUgcmVzcG9u c2UuICZuYnNwO0luIHNvbWU8YnI+DQomZ3Q7Jmd0O2RvbWFpbnMsIGl0IG1heSBiZSB0aGF0IHlv dSBzcGVjaWZ5IHdoYXQgcG93ZXIgeW91IHdhbnQgdG8gdXNlIGFuZCB0aGU8YnI+DQomZ3Q7Jmd0 O0RCIHRlbGxzIHlvdSB3aGF0IHNwZWN0cnVtIHlvdSBjYW4gdXNlIGF0IHRoYXQgcG93ZXIuICZu YnNwO0luIG90aGVyLCBhPGJyPg0KJmd0OyZndDtVUy1saWtlIHJ1bGUgbWF5IGJlIGluIHBsYWNl LiAmbmJzcDtBbHNvIGluIGVpdGhlciB0aGUgcXVlcnkgb3IgdGhlPGJyPg0KJmd0OyZndDtyZWdp c3RyYXRpb24sIHdlIG5lZWQgYSBkZXZpY2UgdHlwZSwgd2hpY2ggc2hvdWxkIGJlIGFuIGVudHJ5 IGZyb20gYW48YnI+DQomZ3Q7Jmd0O0lBTkEgcmVnaXN0cnkuICZuYnNwO1RoaXMgaXMgaG93IHlv dSBnZXQgdGhlIFVTICZxdW90O01vZGUgSUkmcXVvdDsgaW5mb3JtYXRpb24uPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0O1dpdGggcmVnYXJkIHRvIHNjaGVkdWxlLCBJIHdvdWxkIGxpa2UgdG8g c2VlIHR3byBtZWNoYW5pc21zPGJyPg0KJmd0OyZndDsxKSBhIHRpbWUgYnkgd2hpY2ggdGhlIGRh dGFiYXNlIHNob3VsZCBiZSBxdWVyaWVkIGFnYWluICh3aGljaCBjb3VsZDxicj4NCiZndDsmZ3Q7 cmVwcmVzZW50IHRoZSBuZXh0IGNoYW5nZSBpbiBzY2hlZHVsZSk8YnI+DQomZ3Q7Jmd0OzIpIHN0 YXJ0L3N0b3AgdGltZXMgZm9yIGVhY2ggc3BlY3RydW0gdW5pdCBhdmFpbGFibGU8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Qm90aCB0aGVzZSBzaG91bGQgYmUgb3B0aW9uYWwgaW4gdGhlIHJl c3BvbnNlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtNeSB0ZXh0PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0O1RoZSBkYXRhIG1vZGVsIG11c3Qgc3VwcG9ydCBzcGVjaWZ5aW5nIHNwZWN0 cnVtIGF2YWlsYWJpbGl0eS4gJm5ic3A7U3BlY3RydW08YnI+DQomZ3Q7Jmd0O3VuaXRzIGFyZSBz cGVjaWZpZWQgYnkgbG93IGFuZCBoaWdoIGZyZXF1ZW5jaWVzIGFuZCBtYXkgaGF2ZSBhbjxicj4N CiZndDsmZ3Q7b3B0aW9uYWwgY2hhbm5lbCBpZGVudGlmaWVyLjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDtUaGUgZGF0YSBtb2RlbCBtdXN0IHN1cHBvcnQgYSBzY2hlZHVsZSBmb3Igc3BlY3Ry dW0gdW5pdCBhdmFpbGFiaWxpdHkuPGJyPg0KJmd0OyZndDtUd28gbWVjaGFuaXNtcyBtdXN0IGJl IHN1cHBvcnRlZC4gJm5ic3A7VGhlIHJlc3BvbnNlIHRvIHNwZWN0cnVtPGJyPg0KJmd0OyZndDth dmFpbGFiaWxpdHkgcXVlcnkgbWF5IGluY2x1ZGUgYSB0aW1lIGJ5IHdoaWNoIHRoZSBkYXRhYmFz ZSBtdXN0IGJlPGJyPg0KJmd0OyZndDtyZXF1ZXJpZWQuICZuYnNwO0VhY2ggc3BlY3RydW0gdW5p dCBtZW50aW9uZWQgaW4gdGhlIHJlc3BvbnNlIG1heSBiZTxicj4NCiZndDsmZ3Q7YW5ub3RhdGVk IHdpdGggc3RhcnQgYW5kIHN0b3AgdGltZS9kYXRlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KJmd0OyZndDtGcm9tOiAmbmJzcDsgJm5ic3A7IEVyaWMgQ2h1IFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOmVyaWNjaHVAZ29vZ2xlLmNvbSI+ZXJpY2NodUBnb29nbGUuY29tPC9hPl08YnI+ DQomZ3Q7Jmd0O1NlbnQ6ICZuYnNwOyAmbmJzcDtTYXR1cmRheSwgQXVndXN0IDExLCAyMDEyIDEx OjQzIEFNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZTxicj4NCiZndDsmZ3Q7VG86ICZuYnNwOyAmbmJz cDtUZWNvIEJvb3Q8YnI+DQomZ3Q7Jmd0O0NjOiAmbmJzcDsgJm5ic3A7Um9zZW4sIEJyaWFuOyA8 YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyI+cGF3c0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 Jmd0O1N1YmplY3Q6ICZuYnNwOyAmbmJzcDtSZTogW3Bhd3NdIHVzZSBjYXNlcyBhbmQgcmVxdWly ZW1lbnRzIGRvY3VtZW50PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 SGkgZXZlcnlvbmUsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O0dhdGhlcmluZyBhbGwgdGhl IHNoYXJlZCBwb2ludHMgZnJvbSBldmVyeW9uZS4uLiBJIGJlbGlldmUgYmVsb3cgaXMgdGhlPGJy Pg0KJmd0OyZndDtjb21wbGV0ZSBsaXN0IHNvIGZhcjo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyogJm5ic3A7ICZuYnNwO1doYXQncyB0aGUg YmVzdCBjb25zaXN0ZW50IHJlcHJlc2VudGF0aW9uIG9mIHRoZSB3b3JkcyAmcXVvdDtjaGFubmVs PGJyPg0KJmd0OyZndDtudW1iZXJzJnF1b3Q7IGZvciBub24tVFYgc3BlY3RydW08YnI+DQomZ3Q7 Jmd0OyogJm5ic3A7ICZuYnNwO1Nob3VsZCB3ZSB1cGRhdGUgdGhlIGVudGlyZSBkb2Mgb24gdGhl IHRvcGljIG9mIKn4Y2hhbm5lbKn3IG9yPGJyPg0KJmd0OyZndDup+GNoYW5uZWwgbnVtYmVyc6n3 PGJyPg0KJmd0OyZndDsqICZuYnNwOyAmbmJzcDtXaGF0qfZzIHRoZSBiZXN0IHdheSB0byByZWR1 Y2UgdmFndWVuZXNzIGluIHdoZXRoZXIvaG93IHRvIGluY2x1ZGU8YnI+DQomZ3Q7Jmd0OyZxdW90 O2NoYW5uZWwgbnVtYmVycyZxdW90Ozxicj4NCiZndDsmZ3Q7KiAmbmJzcDsgJm5ic3A7SXMgdGhl IHJlZmVyZW5jZSB0byB2YXJpYWJsZSBwb3dlciByZXF1aXJlZDxicj4NCiZndDsmZ3Q7KiAmbmJz cDsgJm5ic3A7V2hhdCBkb2VzIGNoYW5uZWwgYXZhaWxhYmlsaXR5IHNjaGVkdWxlIG1lYW48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtCcmlhbidzIHN1Z2dlc3Rpb24g b2YgcmVwbGFjaW5nIGV2ZXJ5IGluc3RhbmNlIG9mICZxdW90O2NoYW5uZWwmcXVvdDsgaXM8YnI+ DQomZ3Q7Jmd0O3RlY2huaWNhbGx5IGNvcnJlY3RseS4gSG93ZXZlciwgaXQgaXMgaW1wb3J0YW50 IGZvciB1cyB0byBmb2N1cyBtb3Zpbmc8YnI+DQomZ3Q7Jmd0O2ZvcndhcmQuICZuYnNwO0kgd291 bGQgc3VnZ2VzdCB3ZSBvbmx5IHdvcmsgb24gdGhlIG5vcm1hdGl2ZSBwYXJ0IG9mIHRoZSBzcGVj Ljxicj4NCiZndDsmZ3Q7IFRoZSBzZWN0aW9uIEdhYm9yIGlzIHByb3Bvc2luZyBmb3IgdXMgdG8g bW9kaWZ5Li4uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O09uIHdoYXQncyB0aGUgYmVzdCBn ZW5lcmljIGxhYmVsIGZvciB0aGUgd29yZHMgJnF1b3Q7Y2hhbm5lbCBudW1iZXJzJnF1b3Q7LDxi cj4NCiZndDsmZ3Q7Y2hhbm5lbCBpZGVudGlmaWVyIG1pZ2h0IGJlIHRoZSBtb3N0IGFjY3VyYXRl IGFuZCBuZXV0cmFsICZxdW90O2xhYmVsJnF1b3Q7Ljxicj4NCiZndDsmZ3Q7VGhvdWdodHM/PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O09uIHRoZSBxdWVzdGlvbiB3aGV0aGVyIHZhcmlhYmxl IHBvd2VyIGlzIHJlcXVpcmVkLCBiYXNlZCBvbiBGQ0M8YnI+DQomZ3Q7Jmd0O2FkamFjZW50LWNo YW5uZWwgcnVsZXMsIHRoZSBkYXRhYmFzZSBtYXkgbGltaXQgdGhlIE1vZGUgSUkgZGV2aWNlcyB0 bzxicj4NCiZndDsmZ3Q7MTAwbVcgZm9yIHNvbWUgY2hhbm5lbHMgYW5kIDQwbVcgZm9yIG90aGVy cy4gVGhlcmVmb3JlLCB0aGUgZGF0YSBtb2RlbDxicj4NCiZndDsmZ3Q7bmVlZHMgdG8gc3VwcG9y dCBzcGVjaWZpY2F0aW9uIG9mIG1heGltdW0gcG93ZXIgbGV2ZWxzLjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDtMYXN0bHksIHdpdGggcmVnYXJkcyB0byAmcXVvdDtzY2hlZHVsZSZxdW90Oywg dGhlIGludGVudCBpcyB0byBoYXZlIGEgd2F5IG9mPGJyPg0KJmd0OyZndDtpbmZvcm1pbmcgZGV2 aWNlcyB3aGVuIHRvIG9wZXJhdGUgZm9yIGVhY2ggZnJlcXVlbmN5IHJhbmdlLiBBcyBsb25nIGFz PGJyPg0KJmd0OyZndDt0aGUgZGF0YSBtb2RlbCBzdXBwb3J0cywgZm9yIGV4YW1wbGUsIGEgbGlz dCBvZiB0aW1lIHJhbmdlcywgaXQgZG9lczxicj4NCiZndDsmZ3Q7bm90IHByZXZlbnQgYW4gaW1w bGVtZW50YXRpb24gZnJvbSBwcm92aWRpbmcgYSBsaXN0IHdpdGggMSBlbnRyeSB3aGljaDxicj4N CiZndDsmZ3Q7Y29ycmVzcG9uZHMgdG8gdGhlICZxdW90O3Nob3J0ZXN0IGF2YWlsYWJsZSZxdW90 Oy4gJm5ic3A7VGhlIHdvcmQgJnF1b3Q7c2NoZWR1bGUmcXVvdDsgc2hvdWxkIGJlPGJyPg0KJmd0 OyZndDtzdWZmaWNpZW50IHRvIGNhcHR1cmUgdGhpcyBpbnRlbnQ/PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0O1dlIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93aW5nIHRleHQgdG8g YWRkcmVzcyB0aGVzZSBwb2ludHM6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZxdW90O1Ro ZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZ5aW5nIGF2YWlsYWJsZSBzcGVjdHJ1bS4g VGhlIERhdGE8YnI+DQomZ3Q7Jmd0O01vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZpY2F0aW9uIG9m IHRoaXMgaW5mb3JtYXRpb24gYnkgc3RhcnQgYW5kIHN0b3A8YnI+DQomZ3Q7Jmd0O2ZyZXF1ZW5j aWVzIGFuZCBNQVkgYWxzbyBzdXBwb3J0IHNwZWNpZmljYXRpb24gb2YgdGhpcyBpbmZvcm1hdGlv biBieTxicj4NCiZndDsmZ3Q7Y2hhbm5lbCBpZGVudGlmaWVycy4gVGhlIERhdGEgTW9kZWwgTVVT VCBzdXBwb3J0IGE8YnI+DQomZ3Q7Jmd0O3NwZWN0cnVtLWF2YWlsYWJpbGl0eSBzY2hlZHVsZSBh bmQgbWF4aW11bSBwb3dlciBsZXZlbHMgZm9yIGVhY2g8YnI+DQomZ3Q7Jmd0O2ZyZXF1ZW5jeSBy YW5nZS4mcXVvdDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtUaG91 Z2h0cz88YnI+DQomZ3Q7Jmd0O0VyaWM8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0O09uIDgvMTAvMTIgNTo0OCBBTSwgVGVjbyBCb290IHdyb3Rl Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7 V2hhdCBhYm91dCB0aGlzOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7qfhUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyBh IGxpc3Qgb2YgYXZhaWxhYmxlPGJyPg0KJmd0OyZndDtjaGFubmVscy4gVGhlIERhdGEgTW9kZWwg TVVTVCBzdXBwb3J0IHNwZWNpZmljYXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbjxicj4NCiZndDsm Z3Q7Ynkgc3RhcnQgYW5kIHN0b3AgZnJlcXVlbmNpZXMsIG9yIGVxdWl2YWxlbnRzIHN1Y2ggYXMg Y2VudGVyPGJyPg0KJmd0OyZndDtmcmVxdWVuY2llcyB3aXRoIGNoYW5uZWwgd2lkdGggb3IgY2hh bm5lbCBudW1iZXJzIHdpdGggY2hhbm5lbCBudW1tZXI8YnI+DQomZ3Q7Jmd0O2FsbG9jYXRpb24g c2NoZW1lIC4gVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IGEgY2hhbm5lbCBhdmFpbGFiaWxp dHk8YnI+DQomZ3Q7Jmd0O3NjaGVkdWxlIGFuZCBtYXhpbXVtIHBvd2VyIGxldmVsIGZvciBlYWNo IGNoYW5uZWwgaW4gdGhlIGxpc3Quqfc8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNw OyAmbmJzcDtNb3JlIHRob3VnaHRzIG9uIGNoYW5uZWwgbnVtYmVyczogd2UgbGlrZWx5IHJ1biBp bnRvIHByb2JsZW1zIGluPGJyPg0KJmd0OyZndDtiYW5kcyB3aXRob3V0IGEgY2hhbm5lbCBudW1i ZXJpbmcgc2NoZW1lLCBvciBmb3IgZXhhbXBsZSBzdWIgY2hhbm5lbHM8YnI+DQomZ3Q7Jmd0O2lu IFRWIGJhbmRzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO1RlY288 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO09w IDEwIGF1Zy4gMjAxMiwgb20gMTM6NTcgaGVlZnQgUm9zZW4sIEJyaWFuIGhldCB2b2xnZW5kZSBn ZXNjaHJldmVuOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7YXMgaW5kaXZpZHVhbCZndDs8YnI+DQomZ3Q7Jmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtXaGlsZSBJIGRvbid0IGNhcmUgaWYgaXQncyBj ZW50ZXIgYW5kIHdpZHRoIG9yIHVwcGVyL2xvd2VyLCBJPGJyPg0KJmd0OyZndDtkbyB0aGluayB3 ZSB3aWxsIGRlZmluZSB0aGUgZm9ybWF0IGluIHRoZSBwcm90b2NvbCBmb3IgaW50ZXJvcGVyYWJp bGl0eTxicj4NCiZndDsmZ3Q7cmVhc29ucywgYnV0IGRvbid0IG5lZWQgdG8gZG8gdGhhdCBpbiBy ZXF1aXJlbWVudHMuICZuYnNwO0l0IHdvdWxkbid0IGh1cnQ8YnI+DQomZ3Q7Jmd0O3RvIGRlY2lk ZSBub3cgYW5kIHVzZSBjb25zaXN0ZW50IHRlcm1zLCBidXQgd2UgZG9uJ3QgbmVlZCB0by48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0kgdGhp bmsgJnF1b3Q7YmFuZCZxdW90OyB3b24ndCB3b3JrLCBhcyBpdCB1c3VhbGx5IGltcGxpZXMgYSBt dWNoIHdpZGVyPGJyPg0KJmd0OyZndDtwaWVjZSBvZiBzcGVjdHJ1bSB0aGF0IGhhcyBhIGNvbW1v biBwdXJwb3NlLiAmbmJzcDtUaGUgVFYgQmFuZCBpcyBhbGwgdGhlPGJyPg0KJmd0OyZndDtjaGFu bmVscy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7T24gQXVnIDEwLCAyMDEyLCBhdCAyOjM3IEFNLCBUZWNvIEJvb3Qg Jmx0OzxhIGhyZWY9Im1haWx0bzp0ZWNvQGluZi1uZXQubmwiPnRlY29AaW5mLW5ldC5ubDwvYT4m Z3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyhzb21ld2hhdCBsYXRlIHJlc3Bv bnNlKTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtBIGNlbnRlciBmcmVxdWVuY3kgYW5kIGNoYW5uZWwgd2lkdGggaXMg ZnVuY3Rpb25hbDxicj4NCiZndDsmZ3Q7ZXF1aXZhbGVudCB0byBzdGFydC9zdG9wIGZyZXF1ZW5j aWVzLiBTbyBpcyBjaGFubmVsIG51bWJlciwgd2l0aCByZWYgdG88YnI+DQomZ3Q7Jmd0O2NoYW5u ZWwgbnVtYmVyIGFzc2lnbm1lbnQgc2NoZW1lLiBGb3IgYSByZXF1aXJlbWVudHMgZG9jdW1lbnQs IHdlIGp1c3Q8YnI+DQomZ3Q7Jmd0O25lZWQgdG8gc3BlY2lmeSB3aGF0IGlzIG5lZWRlZC4gSG93 IGl0IGlzIGVuY29kZWQgKEh6LCB3YXZlIGxlbmd0aCw8YnI+DQomZ3Q7Jmd0O2NoYW5uZWwgSUQp IGlzIHNvbHV0aW9uIHNwYWNlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTZWVuIG91ciBnb2FsIHRvIG1ha2UgUEFX UyBzb21ld2hhdCB1bml2ZXJzYWwgKG5vdCBsaW1pdGVkPGJyPg0KJmd0OyZndDt0byBVUyBUVldT KSwgSSBkbyBub3QgcHJlZmVyIHVzaW5nIGNoYW5uZWwgbnVtYmVycy48YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGVj bzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO09wIDkgYXVnLiAyMDEyLCBvbSAyMTo1NSBoZWVm dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkdhYm9yLkJhamtvQG5va2lhLmNvbSI+R2Fib3IuQmFqa29A bm9raWEuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZsdDs8YSBocmVmPSJtYWlsdG86R2Fib3Iu QmFqa29Abm9raWEuY29tIj5HYWJvci5CYWprb0Bub2tpYS5jb208L2E+Jmd0OyBoZXQgdm9sZ2Vu ZGUgZ2VzY2hyZXZlbjo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Rm9s a3MsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RHVyaW5nIHRoZSBsYXN0IEYyRiBtZWV0aW5n LCB0aGVyZSB3YXMgYW4gYWdyZWVtZW50IHRvPGJyPg0KJmd0OyZndDttYWtlIGEgc2xpZ2h0IHVw ZGF0ZSB0byByZXF1aXJlbWVudCBELjcgaW48YnI+DQomZ3Q7Jmd0OzxhIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11c2VjYXNlcy1ycW10 cy0wNi50IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRm LXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXRzLTA2LnQ8L2E+PGJyPg0KJmd0OyZndDt4 dCwgJm5ic3A7dG8gbWFrZSBjaGFubmVsIG51bWJlcnMgb3B0aW9uYWwgdG8gYmUgc3VwcG9ydGVk LiBJZSwgY2hhbmdlIHRoZTxicj4NCiZndDsmZ3Q7Y3VycmVudDxicj4NCiZndDsmZ3Q7RC43PGJy Pg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO6n4VGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgYSBsaXN0 IG9mPGJyPg0KJmd0OyZndDthdmFpbGFibGUgY2hhbm5lbHMuIFRoZSBEYXRhIE1vZGVsIE1VU1Qg c3VwcG9ydCBzcGVjaWZpY2F0aW9uIG9mIHRoaXM8YnI+DQomZ3Q7Jmd0O2luZm9ybWF0aW9uIGJ5 IGNoYW5uZWwgbnVtYmVycyBhbmQgYnkgc3RhcnQgYW5kIHN0b3AgZnJlcXVlbmNpZXMuIFRoZTxi cj4NCiZndDsmZ3Q7RGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIGF2YWlsYWJpbGl0 eSBzY2hlZHVsZSBhbmQgbWF4aW11bTxicj4NCiZndDsmZ3Q7cG93ZXIgbGV2ZWwgZm9yIGVhY2gg Y2hhbm5lbCBpbiB0aGUgbGlzdC6p9zxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0bzxicj4NCiZndDsmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDup+FRoZSBE YXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZ5aW5nIGEgbGlzdCBvZjxicj4NCiZndDsmZ3Q7 YXZhaWxhYmxlIGNoYW5uZWxzLiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmaWNh dGlvbiBvZiB0aGlzPGJyPg0KJmd0OyZndDtpbmZvcm1hdGlvbiBieSBzdGFydCBhbmQgc3RvcCBm cmVxdWVuY2llcyBhbmQgTUFZIGluY2x1ZGUgY2hhbm5lbDxicj4NCiZndDsmZ3Q7bnVtYmVycy4g VGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IGEgY2hhbm5lbCBhdmFpbGFiaWxpdHkgc2NoZWR1 bGU8YnI+DQomZ3Q7Jmd0O2FuZCBtYXhpbXVtIHBvd2VyIGxldmVsIGZvciBlYWNoIGNoYW5uZWwg aW4gdGhlIGxpc3Quqfc8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJqfZkIGxpa2UgdG8gY29u ZmlybSB0aGlzIGNoYW5nZSBvbiB0aGUgbGlzdC4gSWYgYW55b25lPGJyPg0KJmd0OyZndDtoYXMg YW55IG9iamVjdGlvbnMsIGxldCBtZSBrbm93LiBPdGhlcndpc2UgSan2bGwgcGxhbiB0byBzZW5k IHRoZTxicj4NCiZndDsmZ3Q7ZG9jdW1lbnQgdG8gdGhlIGllc2cgYWZ0ZXIgdGhpcyBjaGFuZ2Ug aXMgaW1wbGVtZW50ZWQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LSAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7R2Fib3I8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGF3cyBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciPnBhd3NAaWV0Zi5v cmc8L2E+PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcGF3cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGF3czwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYXdzIG1h aWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciPnBhd3NAaWV0Zi5vcmc8L2E+ PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3M8L2E+ PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm bmJzcDsgJm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7cGF3cyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 Jmd0OyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciPnBhd3NAaWV0 Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3czwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDtwYXdzIG1haWxpbmcgbGlz dDxicj4NCiZndDsmZ3Q7PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciPnBhd3NAaWV0Zi5v cmc8L2E+PGJyPg0KJmd0OyZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Bhd3MiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Bhd3M8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDtfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDtwYXdzIG1haWxpbmcgbGlz dDxicj4NCiZndDs8YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyI+cGF3c0BpZXRmLm9yZzwv YT48YnI+DQomZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9wYXdzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9wYXdzPC9hPjxicj4NCiZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDtwYXdzIG1haWxpbmcgbGlzdDxicj4NCiZndDs8YSBocmVm PSJtYWlsdG86cGF3c0BpZXRmLm9yZyI+cGF3c0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzPC9hPjxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KcGF3cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyI+ cGF3c0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Bhd3MiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Bhd3M8L2E+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCi0t IDxicj4NCi12aW5jZTxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_CC53D7B8226B6basavarajpatilnokiacom_-- From warren@kumari.net Fri Aug 17 10:20:41 2012 Return-Path: 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 4D85711E809B for ; Fri, 17 Aug 2012 10:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 EoH0+9-5vx9H for ; Fri, 17 Aug 2012 10:20:40 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1076921F8493 for ; Fri, 17 Aug 2012 10:20:39 -0700 (PDT) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 9A4161B4017A; Fri, 17 Aug 2012 13:20:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=euc-kr From: Warren Kumari In-Reply-To: Date: Fri, 17 Aug 2012 13:20:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8B74D20B-6759-4956-875E-3305B8FC2A87@kumari.net> References: To: X-Mailer: Apple Mail (2.1278) Cc: paws@ietf.org Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 17:20:41 -0000 On Aug 17, 2012, at 12:13 PM, wrote: >=20 > FWIW, I would prefer to use the seconds since epoch approach. >=20 Seconds since epoch is much simpler to deal with on small / embedded = type devices, right up until you overflow -- can we suggest / remind = implementors that this number may exceed 32 bits? ISO is easier to read for humans, and libraries exist to deal with = parsing it in basically all languages, etc... My personal preference is ISO 8601, unless we think that really small = devices are going to have to parse this for any reason? W > -Raj >=20 > From: ext Vincent Chen > Date: Friday, August 17, 2012 11:01 AM > To: "Brian.Rosen@neustar.biz" > Cc: "paws@ietf.org" > Subject: Re: [paws] use cases and requirements document >=20 > Comments: > - The proposal for long-integer seconds was to gauge preference from = the device folks >=20 > - If we use ISO 8601, could we restrict it to be only in UTC? :)=20 >=20 >=20 >=20 >=20 > On Fri, Aug 17, 2012 at 6:08 AM, Rosen, Brian = wrote: >> Uh, the difference is representation of start/stop times. We both = propose >> to send start/stop times. Vincent proposes that the representation = of >> time be a long integer seconds since an epoch. He would send two = such >> long integers. I propose it be an ISO 8601 time string. = Specifically, I >> would propose an ISO 8601 interval limited to start/end, e.g. >> 2011-03-01T13:00:00Z/2012-05-11T15:30:00Z. >>=20 >> On 8/16/12 6:45 PM, "Gabor.Bajko@nokia.com" = wrote: >>=20 >> >It seems we have an agreement on the requirement to identify the >> >spectrum, by using the start/stop frequencies, with optional channel >> >identifiers. >> > >> >Wrt to the schedule, we have so far two proposals, one from Brian >> >proposing the use of start/stop times for each spectrum unit = available, >> >and one from Vincent proposing to use of Unix Epoch time in seconds. = We >> >need to decide on this, so please send your preference on this topic = to >> >the list. >> > >> >- Gabor >> > >> >-----Original Message----- >> >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of >> >Probasco Scott (Nokia-CIC/Dallas) >> >Sent: Monday, August 13, 2012 10:12 AM >> >To: paws@ietf.org >> >Subject: Re: [paws] use cases and requirements document >> > >> >Hi All, >> > >> >Given that we have completed two Working Group Last Call cycles and = this >> >next version will go to the IESG, I hope we could agree on minimal >> >changes to the document, i.e. changes only to D.7 for this topic. = This >> >will ensure the proper requirements are established for the = developing >> >PAWS protocol. >> >I believe Brian's proposed text captures the essential requirements. >> > >> >Kind Regards, >> >Scott >> > >> > >> >On 8/13/12 8:24 AM, "ext Rosen, Brian" = wrote: >> > >> >> >> >>I would prefer to not use the word "channel" in our documents at = all >> >>except for the term "channel identifier". I proposed "spectrum = unit", >> >>although any other term will do. "Channel" has too much baggage, = A >> >>simple editorial change like this is simple, and it's much better = to do >> >>it now. >> >> >> >>I think we need power in both the query and the response. In some >> >>domains, it may be that you specify what power you want to use and = the >> >>DB tells you what spectrum you can use at that power. In other, a >> >>US-like rule may be in place. Also in either the query or the >> >>registration, we need a device type, which should be an entry from = an >> >>IANA registry. This is how you get the US "Mode II" information. >> >> >> >>With regard to schedule, I would like to see two mechanisms >> >>1) a time by which the database should be queried again (which = could >> >>represent the next change in schedule) >> >>2) start/stop times for each spectrum unit available >> >> >> >>Both these should be optional in the response. >> >> >> >>My text >> >> >> >>The data model must support specifying spectrum availability. = Spectrum >> >>units are specified by low and high frequencies and may have an >> >>optional channel identifier. >> >> >> >>The data model must support a schedule for spectrum unit = availability. >> >>Two mechanisms must be supported. The response to spectrum >> >>availability query may include a time by which the database must be >> >>requeried. Each spectrum unit mentioned in the response may be >> >>annotated with start and stop time/date. >> >> >> >> >> >> >> >> -----Original Message----- >> >>From: Eric Chu [mailto:ericchu@google.com] >> >>Sent: Saturday, August 11, 2012 11:43 AM Eastern Standard Time >> >>To: Teco Boot >> >>Cc: Rosen, Brian; paws@ietf.org >> >>Subject: Re: [paws] use cases and requirements document >> >> >> >> >> >>Hi everyone, >> >> >> >>Gathering all the shared points from everyone... I believe below is = the >> >>complete list so far: >> >> >> >> >> >> >> >>* What's the best consistent representation of the words = "channel >> >>numbers" for non-TV spectrum >> >>* Should we update the entire doc on the topic of =A9=F8channel=A9= =F7 or >> >>=A9=F8channel numbers=A9=F7 >> >>* What=A9=F6s the best way to reduce vagueness in whether/how to = include >> >>"channel numbers" >> >>* Is the reference to variable power required >> >>* What does channel availability schedule mean >> >> >> >> >> >>Brian's suggestion of replacing every instance of "channel" is >> >>technically correctly. However, it is important for us to focus = moving >> >>forward. I would suggest we only work on the normative part of the = spec. >> >> The section Gabor is proposing for us to modify... >> >> >> >>On what's the best generic label for the words "channel numbers", >> >>channel identifier might be the most accurate and neutral "label". >> >>Thoughts? >> >> >> >>On the question whether variable power is required, based on FCC >> >>adjacent-channel rules, the database may limit the Mode II devices = to >> >>100mW for some channels and 40mW for others. Therefore, the data = model >> >>needs to support specification of maximum power levels. >> >> >> >>Lastly, with regards to "schedule", the intent is to have a way of >> >>informing devices when to operate for each frequency range. As long = as >> >>the data model supports, for example, a list of time ranges, it = does >> >>not prevent an implementation from providing a list with 1 entry = which >> >>corresponds to the "shortest available". The word "schedule" = should be >> >>sufficient to capture this intent? >> >> >> >>We would like to propose the following text to address these = points: >> >> >> >>"The Data Model MUST support specifying available spectrum. The = Data >> >>Model MUST support specification of this information by start and = stop >> >>frequencies and MAY also support specification of this information = by >> >>channel identifiers. The Data Model MUST support a >> >>spectrum-availability schedule and maximum power levels for each >> >>frequency range." >> >> >> >> >> >>Thoughts? >> >>Eric >> >> >> >> >> >> >> >>On 8/10/12 5:48 AM, Teco Boot wrote: >> >> >> >> >> >> What about this: >> >> >> >> =A9=F8The Data Model MUST support specifying a list of = available >> >>channels. The Data Model MUST support specification of this = information >> >>by start and stop frequencies, or equivalents such as center >> >>frequencies with channel width or channel numbers with channel = nummer >> >>allocation scheme . The Data Model MUST support a channel = availability >> >>schedule and maximum power level for each channel in the list.=A9=F7 >> >> >> >> More thoughts on channel numbers: we likely run into problems = in >> >>bands without a channel numbering scheme, or for example sub = channels >> >>in TV bands. >> >> >> >> Teco >> >> >> >> >> >> Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende = geschreven: >> >> >> >> >> >> >> >> While I don't care if it's center and width or upper/lower, = I >> >>do think we will define the format in the protocol for = interoperability >> >>reasons, but don't need to do that in requirements. It wouldn't = hurt >> >>to decide now and use consistent terms, but we don't need to. >> >> >> >> I think "band" won't work, as it usually implies a much = wider >> >>piece of spectrum that has a common purpose. The TV Band is all = the >> >>channels. >> >> >> >> >> >> On Aug 10, 2012, at 2:37 AM, Teco Boot = wrote: >> >> >> >> >> >> (somewhat late response) >> >> >> >> A center frequency and channel width is functional >> >>equivalent to start/stop frequencies. So is channel number, with = ref to >> >>channel number assignment scheme. For a requirements document, we = just >> >>need to specify what is needed. How it is encoded (Hz, wave length, >> >>channel ID) is solution space. >> >> >> >> Seen our goal to make PAWS somewhat universal (not = limited >> >>to US TVWS), I do not prefer using channel numbers. >> >> >> >> Teco >> >> >> >> >> >> Op 9 aug. 2012, om 21:55 heeft >> >> het volgende geschreven: >> >> >> >> >> >> Folks, >> >> >> >> During the last F2F meeting, there was an agreement = to >> >>make a slight update to requirement D.7 in >> = >>http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.t >> >>xt, to make channel numbers optional to be supported. Ie, change = the >> >>current >> >>D.7 >> >> =A9=F8The Data Model MUST support specifying a list = of >> >>available channels. The Data Model MUST support specification of = this >> >>information by channel numbers and by start and stop frequencies. = The >> >>Data Model MUST support a channel availability schedule and maximum >> >>power level for each channel in the list.=A9=F7 >> >> to >> >> =A9=F8The Data Model MUST support specifying a list = of >> >>available channels. The Data Model MUST support specification of = this >> >>information by start and stop frequencies and MAY include channel >> >>numbers. The Data Model MUST support a channel availability = schedule >> >>and maximum power level for each channel in the list.=A9=F7 >> >> >> >> I=A9=F6d like to confirm this change on the list. = If anyone >> >>has any objections, let me know. Otherwise I=A9=F6ll plan to send = the >> >>document to the iesg after this change is implemented. >> >> >> >> - Gabor >> >> _______________________________________________ >> >> paws mailing list >> >> paws@ietf.org >> >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >> >> >> >> >> _______________________________________________ >> >> paws mailing list >> >> paws@ietf.org >> >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> paws mailing list >> >> paws@ietf.org >> >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >> >> >> >> >>_______________________________________________ >> >>paws mailing list >> >>paws@ietf.org >> >>https://www.ietf.org/mailman/listinfo/paws >> > >> >_______________________________________________ >> >paws mailing list >> >paws@ietf.org >> >https://www.ietf.org/mailman/listinfo/paws >> >_______________________________________________ >> >paws mailing list >> >paws@ietf.org >> >https://www.ietf.org/mailman/listinfo/paws >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 >=20 >=20 > --=20 > -vince > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws -- She'd even given herself a middle initial - X - which stood for "someone = who has a cool and exciting middle name". -- (Terry Pratchett, Maskerade) From d.joslyn@spectrumbridge.com Fri Aug 17 11:22:53 2012 Return-Path: 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 B561121F8467 for ; Fri, 17 Aug 2012 11:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] 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 QG7kNP+MIr9T for ; Fri, 17 Aug 2012 11:22:49 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id B9EE121F8466 for ; Fri, 17 Aug 2012 11:22:48 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Fri, 17 Aug 2012 14:22:47 -0400 From: Don Joslyn To: "Rosen, Brian" , Manikkoth Sajeev , "gabor.bajko@nokia.com" , "vchen@google.com" , Peter Stanforth Date: Fri, 17 Aug 2012 14:22:47 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac18e88u8ul4qxerT660/QDqozGuFwAJPkRA Message-ID: <8375F6DAEFB09F48815203F1FE23B797117AA6D86F@shelby> References: <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B797117AA6D86Fshelby_" MIME-Version: 1.0 Cc: "paws@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 18:22:53 -0000 --_000_8375F6DAEFB09F48815203F1FE23B797117AA6D86Fshelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I vote for supporting both XML and JSON. From a database perspective, it's = not that much trouble supporting both (I'm speaking from experience), and s= upporting both provides the radio vendors with more than one option to chos= e from. We have already worked with 6 different radio vendors that have successfull= y used XML parsers in their devices to support whitespace messaging via XML= . I would NOT make it a requirement that every database MUST implement both X= ML and JSON. Let that be a business decision; If you implement both, you po= tentially get more customers. The regulators don't care which format we use= . If for some very good reason it's impossible for PAWS to support both, let = me know and I'll vote for only one. Don From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ros= en, Brian Sent: Friday, August 17, 2012 9:26 AM To: Manikkoth Sajeev; gabor.bajko@nokia.com; vchen@google.com; Peter Stanfo= rth Cc: 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 desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml option can also wor= k. JSON I think will necessitate implementation to be native Java and may n= ot be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_8375F6DAEFB09F48815203F1FE23B797117AA6D86Fshelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I vote fo= r supporting both XML and JSON. From a database perspective, it’s not= that much trouble supporting both (I’m speaking from experience), an= d supporting both provides the radio vendors with more than one option to c= hose from.

We have alread= y worked with 6 different radio vendors that have successfully used XML par= sers in their devices to support whitespace messaging via XML.

 

I would NOT make it a requirement that every database M= UST implement both XML and JSON. Let that be a business decision; If you im= plement both, you potentially get more customers. The regulators don’= t care which format we use.

 

If for some very= good reason it’s impossible for PAWS to support both, let me know an= d I’ll vote for only one.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

Don

 

From: paws-bounces@ietf.org [mailto:paws-bounces@= ietf.org] On Behalf Of Rosen, Brian
Sent: Friday, August 1= 7, 2012 9:26 AM
To: Manikkoth Sajeev; gabor.bajko@nokia.com; vche= n@google.com; Peter Stanforth
Cc: 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 pro= tocol design or implementation, but I am a big fan of reusing standards rat= her 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 o= n the idea there is no json representation of an existing standard.  S= o, if choosing json means folks feel free to ignore existing xml based stan= dards 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.

<= p class=3DMsoNormal> 

There are json validators, so I don't think that is a big de= al.  

&= nbsp;

My experience in= protocol design on the Internet is that decisions made solely or even larg= ely because of compactness advantages rarely are good choices.  If you= like json because it is smaller, then I believe you need a much better rea= son.  Binary doesn't work for me, at all.  I have been involved i= n big binary vs text wars in protocol design.  Text wins, binary loses= , in my opinion.

=  

Brian <= as individual>

 

Fr= om: Manikkoth Sajeev <mksaji@yahoo.com>
Reply-To: Manikkoth Sajeev <mksaji@yahoo.com>
Date: Thu, = 16 Aug 2012 22:37:38 -0400
To: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>, "Rosen, Brian" <= brian.rosen@neustar.biz>,= "vchen@google.com" <<= a href=3D"mailto:vchen@google.com">vchen@google.com>, "peter@spectrumbridge.com" <= ;peter@spectrumbridge.com&g= t;
Cc: "paws@ietf.org&q= uot; <paws@ietf.org>
Subje= ct: 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 gene= ric, omni present, easy to understand and validate. For compa= ctness may be a  binary xml option can also work. JSO= N 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
Email: mksaji@ieee.org
http://www.linkedin.com/in/mksaje= ev

 

From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
To: Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com
Cc: 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 encodi= ng 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] On Behalf Of ext Rosen,= Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Pet= er Stanforth'
Cc: '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 u= se and debug.  Don't care a whole lot about that

Brian <as i= ndividual>



-----Original Message-----
From:  &nbs= p;  Vincent Chen [mailto:vchen@goo= gle.com]
Sent:    Monday, August 13, 2012 06:04 PM Ea= stern Standard Time
To:    Peter Stanforth
Cc: &n= bsp;  Rosen, Brian; Teco Boot; Benjamin A.Rolfe; 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, sy= nthesis). 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 num= erous languages (see of http= ://json.org/) and seem to be reasonably light weight.

Timestamps=

As for timestamp specifications, should we consider just using seco= nds since the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the n= eed for datetime-string parsing on devices, assuming devices already have n= ative libraries that provide time in this format. Is that a valid assumptio= n? Of course, this is less human-readable....


On Mon, Aug 13, 20= 12 at 6:49 AM, Peter Stanforth <peter@spectrumbridge.com> wrote:


    W= henever we built mobile devices we never dealt with IETF, in our sensor
=     days even an IP stack was a challenge,so I would defer t= o the device guys
    on that one.
    =
    On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Br= ian"
   
    <Brian.Rosen@neustar.biz> wrote:
 =   
    >Our experience in the IETF over man= y years is that economizing message
    >size and comp= romising utility and security in search of efficiency of
  &nb= sp; >implementation on small devices is a poor trade off.  I am not= advocating
    >being wasteful of resources, but I do= n't think we should seriously
    >consider the overhe= ad of XML or json to be significant.
    >
 &n= bsp;  >Assuming a json library can be loaded on a small device is r= easonable.
    >
    >Brian (as i= ndividual)
    >
    >
 &= nbsp;  >
    > -----Original Message-----
&= nbsp;   >From:  Peter Stanforth [mailto:peter@spectrumbridge.com]
  &nb= sp; >Sent:  Saturday, August 11, 2012 07:13 AM Eastern Standard Tim= e
    >To:    Teco Boot; Benjamin A.Rolfe    >Cc:    p= aws@ietf.org
    >Subject:      Re:= [paws] XML schema versus JSON, vCard & iCal
    >=
    >Not all masters run over the core network.
&n= bsp;   >Some of the Use cases have a master talking to another= OTA
    >We should not assume that all Masters are at= tached to utility power so we
    >should be sympathet= ic to processing energy use also.
    >
  = ;  >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <= teco@inf-net.nl> wrote:
 =    >
    >>
    >= >Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe het volgende
 = ;   >>geschreven:
    >>
 &= nbsp;  >>> Compactness of messages is important, but it is al= so important (to me
    >>>at least) to be reali= zable in an implementation with limited resources,
    &g= t;>>such as embedded devices in what are now popularly called "M= 2M"
    >>>applications.  A lot of the= se devices could use IP all the end to end,
    >>&= gt;but may have a very compact, simple stack and applications (i.e.  n= o
    >>>browser).  Is JSON typically imple= mented when there is no browser?
    >>>Would it= be hard to do in a resource constrained device (i.e. where we
 &nb= sp;  >>>talk about memory size in Kilo-bytes still).
 = ;   >>
    >>In use cases and requi= rements document, there are no requirements for
    >&= gt;protocol performance. I guess OS/IP/TCP/TLS code size supersedes needs    >>for JSON or XML.
    >>= ;
    >>Same for timing: TCP/TLS connection setup w= ill take more than the PAWS
    >>message exchange,= I think. This may be of importance when using satcom
   = >>links.
    >>
    >&g= t;Because PAWS runs between master and database, over core network,
&nbs= p;   >>performance is not our primary concern. But as alway= s, it is good to keep
    >>an eye on efficiency.    >>
    >>Teco
 &= nbsp;  >>
    >>> Thanks
 &nb= sp;  >>> Ben
    >>>
 &nbs= p;  >>>
    >>>> We had a discu= ssion on XML vs. JSON. I prefer the one with most
    >= ;>>>compact messages.
    >>>>
&n= bsp;   >>>> On vCard and JSON: what is the status of = "A JavaScript Object Notation
    >>>>(J= SON) Representation for vCard"?
    >>>>= http://tools.ietf.org/html/draft-bhat-vcarddav-json-00
&= nbsp;   >>>>
    >>>> O= n valid times: can we use same format as certificates? They have
 &= nbsp;  >>>>similar simple requirements: valid notBefore&am= p;  notAfter.
    >>>> http://tool= s.ietf.org/html/rfc3280#section-4.1.2.5
    >>&= gt;>
    >>>> Teco
    &= gt;>>> _______________________________________________
 &n= bsp;  >>>> paws mailing list
    >>= ;>> paws@ietf.org
  = ;  >>>> https://www.ietf.org/mailman/listinfo/paws
&n= bsp;   >>>>
    >>>
&nb= sp;   >>> ______________________________________________= _
    >>> paws mailing list
   = ; >>> paws@ietf.org
 =    >>> https://www.ietf.org/mailman/listinfo/paws
&= nbsp;   >>
    >>__________________= _____________________________
    >>paws mailing li= st
    >>paws@ietf= .org
    >>https://www.ietf.org/mailman/listinfo/= paws
    >
    >_____________= __________________________________
    >paws mailing l= ist
    >paws@ietf.or= g
    >https://www.ietf.org/mailman/listinfo/paws
   
    ____________________________= ___________________
    paws mailing list
  =   paws@ietf.org
  &n= bsp; https://www.ietf.org/mailman/listinfo/paws
   



--
-vince

_____________________________________= __________
paws mailing list
paws@ie= tf.org
https://www.ietf.org/mailman/listinfo/paws
_____________= __________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/p= aws

= --_000_8375F6DAEFB09F48815203F1FE23B797117AA6D86Fshelby_-- From weixinpeng@huawei.com Fri Aug 17 18:07:41 2012 Return-Path: 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 8036E21F8495 for ; Fri, 17 Aug 2012 18:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.013 X-Spam-Level: X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[AWL=0.985, 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 5LYctiNApY4O for ; Fri, 17 Aug 2012 18:07:39 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A6D3E21F8471 for ; Fri, 17 Aug 2012 18:07:39 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJM74733; Fri, 17 Aug 2012 17:07:38 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Aug 2012 18:06:05 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Aug 2012 18:06:12 -0700 Received: from SZXEML519-MBX.china.huawei.com ([169.254.3.2]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Sat, 18 Aug 2012 09:06:06 +0800 From: Weixinpeng To: "Rosen, Brian" , Manikkoth Sajeev , "gabor.bajko@nokia.com" , "vchen@google.com" , "peter@spectrumbridge.com" Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac18e88u7Nd2WNzPm0+85/tpR52R7QAYYRlw Date: Sat, 18 Aug 2012 01:06:05 +0000 Message-ID: References: <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.64] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B43BE42492SZXEML519MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 01:07:41 -0000 --_000_C5C3BB522B1DDF478AA09545169155B43BE42492SZXEML519MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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] On Behalf Of Ros= en, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; gabor.bajko@nokia.com; vchen@google.com; peter@spectr= umbridge.com Cc: 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 desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml option can also wor= k. JSON I think will necessitate implementation to be native Java and may n= ot be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_C5C3BB522B1DDF478AA09545169155B43BE42492SZXEML519MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Considerin= g of the design of database discovery protocol, the LoST protocol may be us= ed 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] On Behalf Of Rosen, Brian
Sent: Friday, August 17, 2012 9:26 PM
To: Manikkoth Sajeev; gabor.bajko@nokia.com; vchen@google.com; peter= @spectrumbridge.com
Cc: paws@ietf.org
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

 

I don't real= ly care whether we use json or xml as a matter of protocol design or implem= entation, 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 id= ea there is no json representation of an existing standard.  So, if ch= oosing json means folks feel free to ignore existing xml based standards such as xCard and LoST, then I would n= ot want to use json.

 <= /o:p>

I would pref= er 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.

 <= /o:p>

There are js= on validators, so I don't think that is a big deal.  

 <= /o:p>

My experienc= e 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.  T= ext wins, binary loses, in my opinion.

 <= /o:p>

Brian <as= individual>

 <= /o:p>

From: Manikkoth Sajeev <mksaji@yahoo.com>
Reply-To: Manikkoth Sajeev <m= ksaji@yahoo.com>
Date: Thu, 16 Aug 2012 22:37:38 -0400
To: "Gabor.Bajko@nokia= .com" <Gabor.Bajko@nok= ia.com>, "Rosen, Brian" <brian.rosen@neustar.biz>, "vchen@google.com" <vchen@google.com>, "peter@spectrumbridge.com"= ; <peter@spectrumbridge.com<= /a>>
Cc: "paws@ietf.org" &= lt;paws@ietf.org>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

 <= /o:p>

Hi,

 

Can it not be both JSON and XML supported? I would vote f= or that. Future implementations may prefer XML as it is generic, omni present, easy to understand and val= idate. For compactness may be a  binary xml option can also work. JSON I think will necessi= tate implementation to be native Java and may not be as friendly with other= implementation languages.

 

Best Regards,

<= span lang=3D"EN-US" style=3D"color:#C00000">Sajeev Manikkoth
Mobile: +918792292002
Email: mksaji@ieee.org
http://ww= w.linkedin.com/in/mksajeev

 

From: &quo= t;Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>=
To: Brian.Rosen@neustar.b= iz; vchen@google.com; peter@spe= ctrumbridge.com
Cc: paws@ietf.org
Sent: Friday, 17 August 2012, 4:55
Subject: Re: [paws] XML schema versus JSON, vCard & iCal<= span lang=3D"EN-US" style=3D"color:black">


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 [m= ailto:paws-bounces@ietf.org] O= n Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: '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.&nbs= p; It's very easy to parse, and its simpler to use and debug.  Don't c= are a whole lot about that

Brian <as individual>



-----Original Message-----
From:     Vincent Chen [mailto:vchen@google.com]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard T= ime
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
Subject:    Re: [paws] XML schema versus JSON, vCard & i= Cal

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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries exist for numerous languages (see= of http://json.org/) and seem to be reasonably light weight.

Timestamps

As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries 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> wrote:


    Whenever we built mobile devices we never dealt with IET= F, in our sensor
    days even an IP stack was a challenge,so I would defer t= o the device guys
    on that one.
   
    On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian&= quot;
   
    <Brian.Ros= en@neustar.biz> wrote:
   
    >Our experience in the IETF over many years is that e= conomizing 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 sh= ould seriously
    >consider the overhead of XML or json to be significa= nt.
    >
    >Assuming a json library can be loaded on a small dev= ice is reasonable.
    >
    >Brian (as individual)
    >
    >
    >
    > -----Original Message-----
    >From:  Peter Stanforth [mailto:peter@spectrumbridge.com]
    >Sent:  Saturday, August 11, 2012 07:13 AM Easte= rn Standard Time
    >To:    Teco Boot; Benjamin A.Rolfe
    >Cc:    pa= ws@ietf.org
    >Subject:      Re: [paws] XML schema v= ersus JSON, vCard & iCal
    >
    >Not all masters run over the core network.
    >Some of the Use cases have a master talking to anoth= er OTA
    >We should not assume that all Masters are attached t= o 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> wrote= :
    >
    >>
    >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolf= e het volgende
    >>geschreven:
    >>
    >>> Compactness of messages is important, but i= t is also important (to me
    >>>at least) to be realizable in an implementat= ion with limited resources,
    >>>such as embedded devices in what are now pop= ularly called "M2M"
    >>>applications.  A lot of these devices c= ould use IP all the end to end,
    >>>but may have a very compact, simple stack an= d applications (i.e.  no
    >>>browser).  Is JSON typically implemente= d when there is no browser?
    >>>Would it be hard to do in a resource constra= ined device (i.e. where we
    >>>talk about memory size in Kilo-bytes still).=
    >>
    >>In use cases and requirements document, there ar= e 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 t= ake more than the PAWS
    >>message exchange, I think. This may be of import= ance when using satcom
    >>links.
    >>
    >>Because PAWS runs between master and database, o= ver core network,
    >>performance is not our primary concern. But as a= lways, 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 o= f "A JavaScript Object Notation
    >>>>(JSON) Representation for vCard"?     >>>> 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 notBe= fore&  notAfter.
    >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
    >>>>
    >>>> Teco
    >>>> _______________________________________= ________
    >>>> paws mailing list
    >>>> paws@i= etf.org
    >>>> https://www.ietf.org/mailman/listinfo/paw= s
    >>>>
    >>>
    >>> ___________________________________________= ____
    >>> paws mailing list
    >>> paws@ietf.= org
    >>> https://www.ietf.org/mailman/listinfo/paws
    >>
    >>_______________________________________________<= br>     >>paws mailing list
    >>paws@ietf.org
    >>https://www.ietf.org/mailman/listinfo/paws
    >
    >_______________________________________________
    >paws mailing list
    >paws@ietf.org     >https://www.ietf.org/mailman/listinfo/paws
   
    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws
   




--
-vince

_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws

--_000_C5C3BB522B1DDF478AA09545169155B43BE42492SZXEML519MBXchi_-- From ben@blindcreek.com Mon Aug 20 08:15:16 2012 Return-Path: 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 4895721F86B2 for ; Mon, 20 Aug 2012 08:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599] 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 LSqJnQVMPd2y for ; Mon, 20 Aug 2012 08:15:12 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id 221B821F85B4 for ; Mon, 20 Aug 2012 08:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=Eel8g7VakY30rIjr7UMkkQuVgbWKq6FHTIt7cnENKnc=; b=OK8MykvrtTBkkQDzFRPKB1z51MsvYcHVmv3LaIwVQ8WH6zCyFvVQHqweHesm02BfLAFcFMVYoiXh3VTP76myyEbK58ZGQ0QrxzRIbwLrevbHVTAKC8hUCqomVk5T9Sgq; Received: from [64.74.213.174] (port=57137 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1T3Th5-0005Ah-Lz for paws@ietf.org; Mon, 20 Aug 2012 10:15:08 -0500 Message-ID: <5032547E.1020305@blindcreek.com> Date: Mon, 20 Aug 2012 08:15:10 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: paws@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 15:15:16 -0000 Thanks for the clarification. There are also two notions of what "schedule" means, at least in the FCC rules. There is the notion that the current channel availability data has a expiration time, and thus there is a time in the future when updating will be necessary. This is at most a day. Based on FCC rules, this could be a local time determined by the device using the channel data, and if that device is acting as a source for dependent device "using" includes providing it to other dependent devices (and it would have to provide the "valid until" time). I can imagine that other regulatory bodies (and perhaps the FCC in the future) will require that channel availability data provided by the data base also be tagged with the "valid until" information. This does not require a start time, as "now" is implied. The other notion of schedule time is that the database contains a predictive guess as to what channels will be available for the next 48 hours into the future. This is required by FCC (though the device must still check at least once a day if what it is using is still valid). A start/stop pair is required for this. I think either format can be used to represent time in both cases. It is also possible that the 48-hour schedule is all that PAWS needs to provide to meet the regulations and the "valid until" can be derived from that by the using device. Hope that helps. -Ben > Uh, the difference is representation of start/stop times. We both propose > to send start/stop times. Vincent proposes that the representation of > time be a long integer seconds since an epoch. He would send two such > long integers. I propose it be an ISO 8601 time string. Specifically, I > would propose an ISO 8601 interval limited to start/end, e.g. > 2011-03-01T13:00:00Z/2012-05-11T15:30:00Z. > > On 8/16/12 6:45 PM, "Gabor.Bajko@nokia.com" wrote: > >> It seems we have an agreement on the requirement to identify the >> spectrum, by using the start/stop frequencies, with optional channel >> identifiers. >> >> Wrt to the schedule, we have so far two proposals, one from Brian >> proposing the use of start/stop times for each spectrum unit available, >> and one from Vincent proposing to use of Unix Epoch time in seconds. We >> need to decide on this, so please send your preference on this topic to >> the list. >> >> - Gabor >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> Probasco Scott (Nokia-CIC/Dallas) >> Sent: Monday, August 13, 2012 10:12 AM >> To: paws@ietf.org >> Subject: Re: [paws] use cases and requirements document >> >> Hi All, >> >> Given that we have completed two Working Group Last Call cycles and this >> next version will go to the IESG, I hope we could agree on minimal >> changes to the document, i.e. changes only to D.7 for this topic. This >> will ensure the proper requirements are established for the developing >> PAWS protocol. >> I believe Brian's proposed text captures the essential requirements. >> >> Kind Regards, >> Scott >> >> >> On 8/13/12 8:24 AM, "ext Rosen, Brian" wrote: >> >>> >>> I would prefer to not use the word "channel" in our documents at all >>> except for the term "channel identifier". I proposed "spectrum unit", >>> although any other term will do. "Channel" has too much baggage, A >>> simple editorial change like this is simple, and it's much better to do >>> it now. >>> >>> I think we need power in both the query and the response. In some >>> domains, it may be that you specify what power you want to use and the >>> DB tells you what spectrum you can use at that power. In other, a >>> US-like rule may be in place. Also in either the query or the >>> registration, we need a device type, which should be an entry from an >>> IANA registry. This is how you get the US "Mode II" information. >>> >>> With regard to schedule, I would like to see two mechanisms >>> 1) a time by which the database should be queried again (which could >>> represent the next change in schedule) >>> 2) start/stop times for each spectrum unit available >>> >>> Both these should be optional in the response. >>> >>> My text >>> >>> The data model must support specifying spectrum availability. Spectrum >>> units are specified by low and high frequencies and may have an >>> optional channel identifier. >>> >>> The data model must support a schedule for spectrum unit availability. >>> Two mechanisms must be supported. The response to spectrum >>> availability query may include a time by which the database must be >>> requeried. Each spectrum unit mentioned in the response may be >>> annotated with start and stop time/date. >>> >>> >>> >>> -----Original Message----- >>> From: Eric Chu [mailto:ericchu@google.com] >>> Sent: Saturday, August 11, 2012 11:43 AM Eastern Standard Time >>> To: Teco Boot >>> Cc: Rosen, Brian; paws@ietf.org >>> Subject: Re: [paws] use cases and requirements document >>> >>> >>> Hi everyone, >>> >>> Gathering all the shared points from everyone... I believe below is the >>> complete list so far: >>> >>> >>> >>> * What's the best consistent representation of the words "channel >>> numbers" for non-TV spectrum >>> * Should we update the entire doc on the topic of ©øchannel©÷ or >>> ©øchannel numbers©÷ >>> * What©ös the best way to reduce vagueness in whether/how to include >>> "channel numbers" >>> * Is the reference to variable power required >>> * What does channel availability schedule mean >>> >>> >>> Brian's suggestion of replacing every instance of "channel" is >>> technically correctly. However, it is important for us to focus moving >>> forward. I would suggest we only work on the normative part of the spec. >>> The section Gabor is proposing for us to modify... >>> >>> On what's the best generic label for the words "channel numbers", >>> channel identifier might be the most accurate and neutral "label". >>> Thoughts? >>> >>> On the question whether variable power is required, based on FCC >>> adjacent-channel rules, the database may limit the Mode II devices to >>> 100mW for some channels and 40mW for others. Therefore, the data model >>> needs to support specification of maximum power levels. >>> >>> Lastly, with regards to "schedule", the intent is to have a way of >>> informing devices when to operate for each frequency range. As long as >>> the data model supports, for example, a list of time ranges, it does >>> not prevent an implementation from providing a list with 1 entry which >>> corresponds to the "shortest available". The word "schedule" should be >>> sufficient to capture this intent? >>> >>> We would like to propose the following text to address these points: >>> >>> "The Data Model MUST support specifying available spectrum. The Data >>> Model MUST support specification of this information by start and stop >>> frequencies and MAY also support specification of this information by >>> channel identifiers. The Data Model MUST support a >>> spectrum-availability schedule and maximum power levels for each >>> frequency range." >>> >>> >>> Thoughts? >>> Eric >>> >>> >>> >>> On 8/10/12 5:48 AM, Teco Boot wrote: >>> >>> >>> What about this: >>> >>> ©øThe Data Model MUST support specifying a list of available >>> channels. The Data Model MUST support specification of this information >>> by start and stop frequencies, or equivalents such as center >>> frequencies with channel width or channel numbers with channel nummer >>> allocation scheme . The Data Model MUST support a channel availability >>> schedule and maximum power level for each channel in the list.©÷ >>> >>> More thoughts on channel numbers: we likely run into problems in >>> bands without a channel numbering scheme, or for example sub channels >>> in TV bands. >>> >>> Teco >>> >>> >>> Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende geschreven: >>> >>> >>> >>> While I don't care if it's center and width or upper/lower, I >>> do think we will define the format in the protocol for interoperability >>> reasons, but don't need to do that in requirements. It wouldn't hurt >>> to decide now and use consistent terms, but we don't need to. >>> >>> I think "band" won't work, as it usually implies a much wider >>> piece of spectrum that has a common purpose. The TV Band is all the >>> channels. >>> >>> >>> On Aug 10, 2012, at 2:37 AM, Teco Boot wrote: >>> >>> >>> (somewhat late response) >>> >>> A center frequency and channel width is functional >>> equivalent to start/stop frequencies. So is channel number, with ref to >>> channel number assignment scheme. For a requirements document, we just >>> need to specify what is needed. How it is encoded (Hz, wave length, >>> channel ID) is solution space. >>> >>> Seen our goal to make PAWS somewhat universal (not limited >>> to US TVWS), I do not prefer using channel numbers. >>> >>> Teco >>> >>> >>> Op 9 aug. 2012, om 21:55 heeft >>> het volgende geschreven: >>> >>> >>> Folks, >>> >>> During the last F2F meeting, there was an agreement to >>> make a slight update to requirement D.7 in >>> http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.t >>> xt, to make channel numbers optional to be supported. Ie, change the >>> current >>> D.7 >>> ©øThe Data Model MUST support specifying a list of >>> available channels. The Data Model MUST support specification of this >>> information by channel numbers and by start and stop frequencies. The >>> Data Model MUST support a channel availability schedule and maximum >>> power level for each channel in the list.©÷ >>> to >>> ©øThe Data Model MUST support specifying a list of >>> available channels. The Data Model MUST support specification of this >>> information by start and stop frequencies and MAY include channel >>> numbers. The Data Model MUST support a channel availability schedule >>> and maximum power level for each channel in the list.©÷ >>> >>> I©öd like to confirm this change on the list. If anyone >>> has any objections, let me know. Otherwise I©öll plan to send the >>> document to the iesg after this change is implemented. >>> >>> - Gabor >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> >>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> >>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From ben@blindcreek.com Mon Aug 20 08:29:53 2012 Return-Path: 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 E31FC21F8616 for ; Mon, 20 Aug 2012 08:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 B1xqf6hgM8AD for ; Mon, 20 Aug 2012 08:29:52 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id 73B4B21F8613 for ; Mon, 20 Aug 2012 08:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=nkkBBFb5hbGRfgucXoLy7NeKA5gj9It7yF6iCx6hHWw=; b=hFh61y4ayw2WaoPYgYlLv7Z9O/7bTnG9iHqfYQ8zzZ3DQledSUnE65BQURIjXO7+6J7IyjbJOGGSrHheAVsFz1kS25gNJETvV4xpqSQDZ/sc31f1KK4C4wySe29sYrBw; Received: from [64.74.213.174] (port=60091 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1T3TvJ-0007ZA-Ic for paws@ietf.org; Mon, 20 Aug 2012 10:29:50 -0500 Message-ID: <503257F2.3050502@blindcreek.com> Date: Mon, 20 Aug 2012 08:29:54 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: paws@ietf.org References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB427D@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 15:29:54 -0000 One "device folk" persons opinion:
Comments:
- The proposal for long-integer seconds was to gauge preference from the device folks
For some TVWS devices bandwidth will be scarce and compact representations will be essential. In such cases over the air protocols will be developed with this optimization focus and we won't see IP and PAWS all the way to the device. In such cases there will be a compression and conversion process in between. Either representation is easily parsed. The device doing this process will typically have the resources to run a full PAWS/HTTP/TCP/IP stack so the extra processing to go from ISO date time to binary form is not a major impact, so either works as well. For the case where bandwidth is less scarce and all devices are capable of running PAWS end to end, is there actual complexity savings from one over the other? Will ISO 8601 be required as part of the HTTP/TCP stack and/or for security anyway?  

- If we use ISO 8601, could we restrict it to be only in UTC? :)
That seems like a good idea to me.  And more easily implemented than flattening the earth to put everyone in the same timezone (though the latter would simplify my teleconference scheduling problem  ;-).




On Fri, Aug 17, 2012 at 6:08 AM, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:
Uh, the difference is representation of start/stop times.  We both propose
to send start/stop times.  Vincent proposes that the representation of
time be a long integer seconds since an epoch.  He would send two such
long integers.  I propose it be an ISO 8601 time string.  Specifically, I
would propose an ISO 8601 interval limited to start/end, e.g.
2011-03-01T13:00:00Z/2012-05-11T15:30:00Z.

On 8/16/12 6:45 PM, "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com> wrote:

>It seems we have an agreement on the requirement to identify the
>spectrum, by using the start/stop frequencies, with optional channel
>identifiers.
>
>Wrt to the schedule, we have so far two proposals, one from Brian
>proposing the use of start/stop times for each spectrum unit available,
>and one from Vincent proposing to use of Unix Epoch time in seconds. We
>need to decide on this, so please send your preference on this topic to
>the list.
>
>- Gabor
>
>-----Original Message-----
>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of
>Probasco Scott (Nokia-CIC/Dallas)
>Sent: Monday, August 13, 2012 10:12 AM
>To: paws@ietf.org
>Subject: Re: [paws] use cases and requirements document
>
>Hi All,
>
>Given that we have completed two Working Group Last Call cycles and this
>next version will go to the IESG, I hope we could agree on minimal
>changes to the document, i.e. changes only to D.7 for this topic. This
>will ensure the proper requirements are established for the developing
>PAWS protocol.
>I believe Brian's proposed text captures the essential requirements.
>
>Kind Regards,
>Scott
>
>
>On 8/13/12 8:24 AM, "ext Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:
>
>><as individual>
>>I would prefer to not use the word "channel" in our documents at all
>>except for the term "channel identifier".  I proposed "spectrum unit",
>>although any other term will do.  "Channel" has too much baggage,  A
>>simple editorial change like this is simple, and it's much better to do
>>it now.
>>
>>I think we need power in both the query and the response.  In some
>>domains, it may be that you specify what power you want to use and the
>>DB tells you what spectrum you can use at that power.  In other, a
>>US-like rule may be in place.  Also in either the query or the
>>registration, we need a device type, which should be an entry from an
>>IANA registry.  This is how you get the US "Mode II" information.
>>
>>With regard to schedule, I would like to see two mechanisms
>>1) a time by which the database should be queried again (which could
>>represent the next change in schedule)
>>2) start/stop times for each spectrum unit available
>>
>>Both these should be optional in the response.
>>
>>My text
>>
>>The data model must support specifying spectrum availability.  Spectrum
>>units are specified by low and high frequencies and may have an
>>optional channel identifier.
>>
>>The data model must support a schedule for spectrum unit availability.
>>Two mechanisms must be supported.  The response to spectrum
>>availability query may include a time by which the database must be
>>requeried.  Each spectrum unit mentioned in the response may be
>>annotated with start and stop time/date.
>>
>>
>>
>> -----Original Message-----
>>From:     Eric Chu [mailto:ericchu@google.com]
>>Sent:    Saturday, August 11, 2012 11:43 AM Eastern Standard Time
>>To:    Teco Boot
>>Cc:    Rosen, Brian; paws@ietf.org
>>Subject:    Re: [paws] use cases and requirements document
>>
>>
>>Hi everyone,
>>
>>Gathering all the shared points from everyone... I believe below is the
>>complete list so far:
>>
>>
>>
>>*    What's the best consistent representation of the words "channel
>>numbers" for non-TV spectrum
>>*    Should we update the entire doc on the topic of ³channel² or
>>³channel numbers²
>>*    What¹s the best way to reduce vagueness in whether/how to include
>>"channel numbers"
>>*    Is the reference to variable power required
>>*    What does channel availability schedule mean
>>
>>
>>Brian's suggestion of replacing every instance of "channel" is
>>technically correctly. However, it is important for us to focus moving
>>forward.  I would suggest we only work on the normative part of the spec.
>> The section Gabor is proposing for us to modify...
>>
>>On what's the best generic label for the words "channel numbers",
>>channel identifier might be the most accurate and neutral "label".
>>Thoughts?
>>
>>On the question whether variable power is required, based on FCC
>>adjacent-channel rules, the database may limit the Mode II devices to
>>100mW for some channels and 40mW for others. Therefore, the data model
>>needs to support specification of maximum power levels.
>>
>>Lastly, with regards to "schedule", the intent is to have a way of
>>informing devices when to operate for each frequency range. As long as
>>the data model supports, for example, a list of time ranges, it does
>>not prevent an implementation from providing a list with 1 entry which
>>corresponds to the "shortest available".  The word "schedule" should be
>>sufficient to capture this intent?
>>
>>We would like to propose the following text to address these points:
>>
>>"The Data Model MUST support specifying available spectrum. The Data
>>Model MUST support specification of this information by start and stop
>>frequencies and MAY also support specification of this information by
>>channel identifiers. The Data Model MUST support a
>>spectrum-availability schedule and maximum power levels for each
>>frequency range."
>>
>>
>>Thoughts?
>>Eric
>>
>>
>>
>>On 8/10/12 5:48 AM, Teco Boot wrote:
>>
>>
>>    What about this:
>>
>>        ³The Data Model MUST support specifying a list of available
>>channels. The Data Model MUST support specification of this information
>>by start and stop frequencies, or equivalents such as center
>>frequencies with channel width or channel numbers with channel nummer
>>allocation scheme . The Data Model MUST support a channel availability
>>schedule and maximum power level for each channel in the list.²
>>
>>    More thoughts on channel numbers: we likely run into problems in
>>bands without a channel numbering scheme, or for example sub channels
>>in TV bands.
>>
>>    Teco
>>
>>
>>    Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende geschreven:
>>
>>
>>        <as individual>
>>        While I don't care if it's center and width or upper/lower, I
>>do think we will define the format in the protocol for interoperability
>>reasons, but don't need to do that in requirements.  It wouldn't hurt
>>to decide now and use consistent terms, but we don't need to.
>>
>>        I think "band" won't work, as it usually implies a much wider
>>piece of spectrum that has a common purpose.  The TV Band is all the
>>channels.
>>
>>
>>        On Aug 10, 2012, at 2:37 AM, Teco Boot <teco@inf-net.nl> wrote:
>>
>>
>>            (somewhat late response)
>>
>>            A center frequency and channel width is functional
>>equivalent to start/stop frequencies. So is channel number, with ref to
>>channel number assignment scheme. For a requirements document, we just
>>need to specify what is needed. How it is encoded (Hz, wave length,
>>channel ID) is solution space.
>>
>>            Seen our goal to make PAWS somewhat universal (not limited
>>to US TVWS), I do not prefer using channel numbers.
>>
>>            Teco
>>
>>
>>            Op 9 aug. 2012, om 21:55 heeft <Gabor.Bajko@nokia.com>
>><Gabor.Bajko@nokia.com> het volgende geschreven:
>>
>>
>>                                Folks,
>>
>>                During the last F2F meeting, there was an agreement to
>>make a slight update to requirement D.7 in
>>http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.t
>>xt,  to make channel numbers optional to be supported. Ie, change the
>>current
>>D.7
>>                ³The Data Model MUST support specifying a list of
>>available channels. The Data Model MUST support specification of this
>>information by channel numbers and by start and stop frequencies. The
>>Data Model MUST support a channel availability schedule and maximum
>>power level for each channel in the list.²
>>                to
>>                ³The Data Model MUST support specifying a list of
>>available channels. The Data Model MUST support specification of this
>>information by start and stop frequencies and MAY include channel
>>numbers. The Data Model MUST support a channel availability schedule
>>and maximum power level for each channel in the list.²
>>
>>                I¹d like to confirm this change on the list. If anyone
>>has any objections, let me know. Otherwise I¹ll plan to send the
>>document to the iesg after this change is implemented.
>>
>>                -          Gabor
>>                _______________________________________________
>>                paws mailing list
>>                paws@ietf.org
>>                https://www.ietf.org/mailman/listinfo/paws
>>
>>
>>
>>            _______________________________________________
>>            paws mailing list
>>            paws@ietf.org
>>            https://www.ietf.org/mailman/listinfo/paws
>>
>>
>>
>>
>>
>>
>>
>>    _______________________________________________
>>    paws mailing list
>>    paws@ietf.org
>>    https://www.ietf.org/mailman/listinfo/paws
>>
>>
>>
>>_______________________________________________
>>paws mailing list
>>paws@ietf.org
>>https://www.ietf.org/mailman/listinfo/paws
>
>_______________________________________________
>paws mailing list
>paws@ietf.org
>https://www.ietf.org/mailman/listinfo/paws
>_______________________________________________
>paws mailing list
>paws@ietf.org
>https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws



--
-vince

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

From peter@spectrumbridge.com Mon Aug 20 09:59:29 2012 Return-Path: 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 A461521F852E for ; Mon, 20 Aug 2012 09:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=-0.826, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] 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 Ic+bCTNBYMSa for ; Mon, 20 Aug 2012 09:59:28 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 25D5821F852B for ; Mon, 20 Aug 2012 09:59:27 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 20 Aug 2012 12:59:27 -0400 From: Peter Stanforth To: "Benjamin A. Rolfe" , "paws@ietf.org" Date: Mon, 20 Aug 2012 12:59:21 -0400 Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac1+9SesDylQ8KUGRuuZYzi9L5wEvA== Message-ID: In-Reply-To: <5032547E.1020305@blindcreek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 16:59:29 -0000 QmVuLA0KRkNDIHJ1bGVzIGRvIGFzc3VtZSB0aGF0IGEgY2hhbm5lbCBhc3NpZ25tZW50IGlmIGZy b20gbm93IHVudGlsIHNvbWUgdGltZQ0KaW4gdGhlIGZ1dHVyZSwgdGhlIGN1cnJlbnQgZGVmYXVs dCBpcyAyNCBob3VycyAtIHVubGVzcyB0aGUgZGV2aWNlIG1vdmVzLg0KSXQgaXMgc2FtZSB0byBh c3N1bWUgdGhhdCB0aGUgZHVyYXRpb24gd2lsbCBiZWNvbWUgbXVjaCBzaG9ydGVyDQpldmVudHVh bGx5LiBTbyAiVmFsaWQgdW50aWwiIGlzIGEgcmVhc29uYWJsZSBwcm9wb3NpdGlvbi4gIEhvd2V2 ZXIgdGhlIEZDQw0KZG9lcyBub3QgcHJlY2x1ZGUgYSByYWRpbyBmcm9tIGdldHRpbmcgYSBjaGFu bmVsIGxpc3QgaW4gYWR2YW5jZS4gSW4gbWFueQ0Kd2F5cyBpdCBtYWtlcyBtb3JlIHNlbnNlIGZv ciBhIGRldmljZSB0byBhc2sgZm9yIGEgbmV3IGNoYW5uZWwgbGlzdCBiZWZvcmUNCml0J3MgY3Vy cmVudCBsaXN0IGV4cGlyZXMgc28gc3RhcnQgdGltZSBtaWdodCBiZSByZWxldmFudCBpbiB0aGlz IGNhc2UuDQoNCkkgZG9uJ3QgdGhpbmsgdGhlIEZDQyB3YXMgcHJvcG9zaW5nIGEgInByZWRpY3Rp dmUgZ3Vlc3MiLiBUaGUgYWN0dWFsIEZDQw0KcnVsZSBpcyB0aGF0IGEgY2hhbm5lbCBsaXN0IGlz IHZhbGlkIGZvciAyNGhvdXJzLCBidXQgaWYgYSBkZXZpY2UgY2Fubm90DQpjb250YWN0IGEgZGF0 YWJhc2UgYXQgdGhhdCB0aW1lIGl0IGhhcyBwZXJtaXNzaW9uIHRvIGtlZXAgdXNpbmcgdGhlDQpj aGFubmVsIGxpc3QgZm9yIGEgZnVydGhlciAyNGhvdXJzICg0OGhvdXJzIHRvdGFsKSBJIGRvbid0 IHRoaW5rIHRoaXMgaXMgYQ0KZ29vZCBpZGVhIGFzIGl0IHByZWNsdWRlcyBhIGJyb2FkY2FzdGVy IHJlc2VydmluZyBjaGFubmVscyBpbnNpZGUgdGhhdA0Kd2luZG93LCBhbmQsIGFzIG1lbnRpb25l ZCBhYm92ZSB0aGVyZSBpcyBzb21lIGRpc2N1c3Npb24gYWJvdXQgbWFraW5nIHRoZQ0Kd2luZG93 IG11Y2ggc2hvcnRlciB0byBhY2NvbW1vZGF0ZSBzaXR1YXRpb25zIHdoZXJlIGJyb2FkY2FzdGVy cyBjYW5ub3QNCnBsYW4gMjQsIG9yIHdvcnN0IGNhc2UgNDggaG91cnMsIGluIGFkdmFuY2UuIFBl cnNvbmFsbHkgSSBwcmVmZXIgdGhhdCB0aGUNCmRldmljZSBnZXQgYSBjaGFubmVsIGxpc3QgdGhh dCBpcyBnb29kIGZvciBzb21lIHBlcmlvZCwgd2l0aG91dCBhbnkgaWZzDQpidXRzIG9yIG1heWJl cywgYW5kIHRoZW4gaXQgaGFzIHRvIHF1ZXJ5IGFnYWluLiBUaGlzIGlzIG11Y2ggc2ltcGxlciB0 aGFuDQp0cnlpbmcgdG8gbWFwIG1hdHJpY2VzIG9mIHN0YXJ0L3N0b3AgdGltZXMgZm9yIHZhcmlv dXMgY2hhbm5lbHMgKG1heWJlDQp3aXRoIHZhcmlhYmxlIHBvd2VyIGxpbWl0cykgb3ZlciBhbiBl eHRlbmRlZCBwZXJpb2QuDQpQZXRlciBTLg0KDQpPbiBNb25BdWcvMjAvMTIgTW9uIEF1ZyAyMCwg MTE6MTUgQU0sICJCZW5qYW1pbiBBLiBSb2xmZSINCjxiZW5AYmxpbmRjcmVlay5jb20+IHdyb3Rl Og0KDQo+VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCj5UaGVyZSBhcmUgYWxzbyB0d28g bm90aW9ucyBvZiB3aGF0ICJzY2hlZHVsZSIgbWVhbnMsIGF0IGxlYXN0IGluIHRoZSBGQ0MNCj5y dWxlcy4gVGhlcmUgaXMgdGhlIG5vdGlvbiB0aGF0IHRoZSBjdXJyZW50IGNoYW5uZWwgYXZhaWxh YmlsaXR5IGRhdGENCj5oYXMgYSBleHBpcmF0aW9uIHRpbWUsIGFuZCB0aHVzIHRoZXJlIGlzIGEg dGltZSBpbiB0aGUgZnV0dXJlIHdoZW4NCj51cGRhdGluZyB3aWxsIGJlIG5lY2Vzc2FyeS4gVGhp cyBpcyBhdCBtb3N0IGEgZGF5LiBCYXNlZCBvbiBGQ0MgcnVsZXMsDQo+dGhpcyBjb3VsZCBiZSBh IGxvY2FsIHRpbWUgZGV0ZXJtaW5lZCBieSB0aGUgZGV2aWNlIHVzaW5nIHRoZSBjaGFubmVsDQo+ ZGF0YSwgYW5kIGlmIHRoYXQgZGV2aWNlIGlzIGFjdGluZyBhcyBhIHNvdXJjZSBmb3IgZGVwZW5k ZW50IGRldmljZQ0KPiJ1c2luZyIgaW5jbHVkZXMgcHJvdmlkaW5nIGl0IHRvIG90aGVyIGRlcGVu ZGVudCBkZXZpY2VzIChhbmQgaXQgd291bGQNCj5oYXZlIHRvIHByb3ZpZGUgdGhlICJ2YWxpZCB1 bnRpbCIgdGltZSkuIEkgY2FuIGltYWdpbmUgdGhhdCBvdGhlcg0KPnJlZ3VsYXRvcnkgYm9kaWVz IChhbmQgcGVyaGFwcyB0aGUgRkNDIGluIHRoZSBmdXR1cmUpIHdpbGwgcmVxdWlyZSB0aGF0DQo+ Y2hhbm5lbCBhdmFpbGFiaWxpdHkgZGF0YSBwcm92aWRlZCBieSB0aGUgZGF0YSBiYXNlIGFsc28g YmUgdGFnZ2VkIHdpdGgNCj50aGUgInZhbGlkIHVudGlsIiBpbmZvcm1hdGlvbi4gVGhpcyBkb2Vz IG5vdCByZXF1aXJlIGEgc3RhcnQgdGltZSwgYXMNCj4ibm93IiBpcyBpbXBsaWVkLg0KPg0KPlRo ZSBvdGhlciBub3Rpb24gb2Ygc2NoZWR1bGUgdGltZSBpcyB0aGF0IHRoZSBkYXRhYmFzZSBjb250 YWlucyBhDQo+cHJlZGljdGl2ZSBndWVzcyBhcyB0byB3aGF0IGNoYW5uZWxzIHdpbGwgYmUgYXZh aWxhYmxlIGZvciB0aGUgbmV4dCA0OA0KPmhvdXJzIGludG8gdGhlIGZ1dHVyZS4gVGhpcyBpcyBy ZXF1aXJlZCBieSBGQ0MgKHRob3VnaCB0aGUgZGV2aWNlIG11c3QNCj5zdGlsbCBjaGVjayBhdCBs ZWFzdCBvbmNlIGEgZGF5IGlmIHdoYXQgaXQgaXMgdXNpbmcgaXMgc3RpbGwgdmFsaWQpLiBBDQo+ c3RhcnQvc3RvcCBwYWlyIGlzIHJlcXVpcmVkIGZvciB0aGlzLg0KPg0KPkkgdGhpbmsgZWl0aGVy IGZvcm1hdCBjYW4gYmUgdXNlZCB0byByZXByZXNlbnQgdGltZSBpbiBib3RoIGNhc2VzLiBJdCBp cw0KPmFsc28gcG9zc2libGUgdGhhdCB0aGUgNDgtaG91ciBzY2hlZHVsZSBpcyBhbGwgdGhhdCBQ QVdTIG5lZWRzIHRvDQo+cHJvdmlkZSB0byBtZWV0IHRoZSByZWd1bGF0aW9ucyBhbmQgdGhlICJ2 YWxpZCB1bnRpbCIgY2FuIGJlIGRlcml2ZWQNCj5mcm9tIHRoYXQgYnkgdGhlIHVzaW5nIGRldmlj ZS4NCj4NCj5Ib3BlIHRoYXQgaGVscHMuDQo+LUJlbg0KPg0KPj4gVWgsIHRoZSBkaWZmZXJlbmNl IGlzIHJlcHJlc2VudGF0aW9uIG9mIHN0YXJ0L3N0b3AgdGltZXMuICBXZSBib3RoDQo+PnByb3Bv c2UNCj4+IHRvIHNlbmQgc3RhcnQvc3RvcCB0aW1lcy4gIFZpbmNlbnQgcHJvcG9zZXMgdGhhdCB0 aGUgcmVwcmVzZW50YXRpb24gb2YNCj4+IHRpbWUgYmUgYSBsb25nIGludGVnZXIgc2Vjb25kcyBz aW5jZSBhbiBlcG9jaC4gIEhlIHdvdWxkIHNlbmQgdHdvIHN1Y2gNCj4+IGxvbmcgaW50ZWdlcnMu ICBJIHByb3Bvc2UgaXQgYmUgYW4gSVNPIDg2MDEgdGltZSBzdHJpbmcuICBTcGVjaWZpY2FsbHks DQo+PkkNCj4+IHdvdWxkIHByb3Bvc2UgYW4gSVNPIDg2MDEgaW50ZXJ2YWwgbGltaXRlZCB0byBz dGFydC9lbmQsIGUuZy4NCj4+IDIwMTEtMDMtMDFUMTM6MDA6MDBaLzIwMTItMDUtMTFUMTU6MzA6 MDBaLg0KPj4NCj4+IE9uIDgvMTYvMTIgNjo0NSBQTSwgIkdhYm9yLkJhamtvQG5va2lhLmNvbSIg PEdhYm9yLkJhamtvQG5va2lhLmNvbT4NCj4+d3JvdGU6DQo+Pg0KPj4+IEl0IHNlZW1zIHdlIGhh dmUgYW4gYWdyZWVtZW50IG9uIHRoZSByZXF1aXJlbWVudCB0byBpZGVudGlmeSB0aGUNCj4+PiBz cGVjdHJ1bSwgYnkgdXNpbmcgdGhlIHN0YXJ0L3N0b3AgZnJlcXVlbmNpZXMsIHdpdGggb3B0aW9u YWwgY2hhbm5lbA0KPj4+IGlkZW50aWZpZXJzLg0KPj4+DQo+Pj4gV3J0IHRvIHRoZSBzY2hlZHVs ZSwgd2UgaGF2ZSBzbyBmYXIgdHdvIHByb3Bvc2Fscywgb25lIGZyb20gQnJpYW4NCj4+PiBwcm9w b3NpbmcgdGhlIHVzZSBvZiBzdGFydC9zdG9wIHRpbWVzIGZvciBlYWNoIHNwZWN0cnVtIHVuaXQg YXZhaWxhYmxlLA0KPj4+IGFuZCBvbmUgZnJvbSBWaW5jZW50IHByb3Bvc2luZyB0byB1c2Ugb2Yg VW5peCBFcG9jaCB0aW1lIGluIHNlY29uZHMuIFdlDQo+Pj4gbmVlZCB0byBkZWNpZGUgb24gdGhp cywgc28gcGxlYXNlIHNlbmQgeW91ciBwcmVmZXJlbmNlIG9uIHRoaXMgdG9waWMgdG8NCj4+PiB0 aGUgbGlzdC4NCj4+Pg0KPj4+IC0gR2Fib3INCj4+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4gRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGF3cy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4+PiBQcm9iYXNjbyBTY290dCAoTm9raWEtQ0lD L0RhbGxhcykNCj4+PiBTZW50OiBNb25kYXksIEF1Z3VzdCAxMywgMjAxMiAxMDoxMiBBTQ0KPj4+ IFRvOiBwYXdzQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtwYXdzXSB1c2UgY2FzZXMgYW5k IHJlcXVpcmVtZW50cyBkb2N1bWVudA0KPj4+DQo+Pj4gSGkgQWxsLA0KPj4+DQo+Pj4gR2l2ZW4g dGhhdCB3ZSBoYXZlIGNvbXBsZXRlZCB0d28gV29ya2luZyBHcm91cCBMYXN0IENhbGwgY3ljbGVz IGFuZA0KPj4+dGhpcw0KPj4+IG5leHQgdmVyc2lvbiB3aWxsIGdvIHRvIHRoZSBJRVNHLCBJIGhv cGUgd2UgY291bGQgYWdyZWUgb24gbWluaW1hbA0KPj4+IGNoYW5nZXMgdG8gdGhlIGRvY3VtZW50 LCBpLmUuIGNoYW5nZXMgb25seSB0byBELjcgZm9yIHRoaXMgdG9waWMuIFRoaXMNCj4+PiB3aWxs IGVuc3VyZSB0aGUgcHJvcGVyIHJlcXVpcmVtZW50cyBhcmUgZXN0YWJsaXNoZWQgZm9yIHRoZSBk ZXZlbG9waW5nDQo+Pj4gUEFXUyBwcm90b2NvbC4NCj4+PiBJIGJlbGlldmUgQnJpYW4ncyBwcm9w b3NlZCB0ZXh0IGNhcHR1cmVzIHRoZSBlc3NlbnRpYWwgcmVxdWlyZW1lbnRzLg0KPj4+DQo+Pj4g S2luZCBSZWdhcmRzLA0KPj4+IFNjb3R0DQo+Pj4NCj4+Pg0KPj4+IE9uIDgvMTMvMTIgODoyNCBB TSwgImV4dCBSb3NlbiwgQnJpYW4iIDxCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej4gd3JvdGU6DQo+ Pj4NCj4+Pj4gPGFzIGluZGl2aWR1YWw+DQo+Pj4+IEkgd291bGQgcHJlZmVyIHRvIG5vdCB1c2Ug dGhlIHdvcmQgImNoYW5uZWwiIGluIG91ciBkb2N1bWVudHMgYXQgYWxsDQo+Pj4+IGV4Y2VwdCBm b3IgdGhlIHRlcm0gImNoYW5uZWwgaWRlbnRpZmllciIuICBJIHByb3Bvc2VkICJzcGVjdHJ1bSB1 bml0IiwNCj4+Pj4gYWx0aG91Z2ggYW55IG90aGVyIHRlcm0gd2lsbCBkby4gICJDaGFubmVsIiBo YXMgdG9vIG11Y2ggYmFnZ2FnZSwgIEENCj4+Pj4gc2ltcGxlIGVkaXRvcmlhbCBjaGFuZ2UgbGlr ZSB0aGlzIGlzIHNpbXBsZSwgYW5kIGl0J3MgbXVjaCBiZXR0ZXIgdG8NCj4+Pj5kbw0KPj4+PiBp dCBub3cuDQo+Pj4+DQo+Pj4+IEkgdGhpbmsgd2UgbmVlZCBwb3dlciBpbiBib3RoIHRoZSBxdWVy eSBhbmQgdGhlIHJlc3BvbnNlLiAgSW4gc29tZQ0KPj4+PiBkb21haW5zLCBpdCBtYXkgYmUgdGhh dCB5b3Ugc3BlY2lmeSB3aGF0IHBvd2VyIHlvdSB3YW50IHRvIHVzZSBhbmQgdGhlDQo+Pj4+IERC IHRlbGxzIHlvdSB3aGF0IHNwZWN0cnVtIHlvdSBjYW4gdXNlIGF0IHRoYXQgcG93ZXIuICBJbiBv dGhlciwgYQ0KPj4+PiBVUy1saWtlIHJ1bGUgbWF5IGJlIGluIHBsYWNlLiAgQWxzbyBpbiBlaXRo ZXIgdGhlIHF1ZXJ5IG9yIHRoZQ0KPj4+PiByZWdpc3RyYXRpb24sIHdlIG5lZWQgYSBkZXZpY2Ug dHlwZSwgd2hpY2ggc2hvdWxkIGJlIGFuIGVudHJ5IGZyb20gYW4NCj4+Pj4gSUFOQSByZWdpc3Ry eS4gIFRoaXMgaXMgaG93IHlvdSBnZXQgdGhlIFVTICJNb2RlIElJIiBpbmZvcm1hdGlvbi4NCj4+ Pj4NCj4+Pj4gV2l0aCByZWdhcmQgdG8gc2NoZWR1bGUsIEkgd291bGQgbGlrZSB0byBzZWUgdHdv IG1lY2hhbmlzbXMNCj4+Pj4gMSkgYSB0aW1lIGJ5IHdoaWNoIHRoZSBkYXRhYmFzZSBzaG91bGQg YmUgcXVlcmllZCBhZ2FpbiAod2hpY2ggY291bGQNCj4+Pj4gcmVwcmVzZW50IHRoZSBuZXh0IGNo YW5nZSBpbiBzY2hlZHVsZSkNCj4+Pj4gMikgc3RhcnQvc3RvcCB0aW1lcyBmb3IgZWFjaCBzcGVj dHJ1bSB1bml0IGF2YWlsYWJsZQ0KPj4+Pg0KPj4+PiBCb3RoIHRoZXNlIHNob3VsZCBiZSBvcHRp b25hbCBpbiB0aGUgcmVzcG9uc2UuDQo+Pj4+DQo+Pj4+IE15IHRleHQNCj4+Pj4NCj4+Pj4gVGhl IGRhdGEgbW9kZWwgbXVzdCBzdXBwb3J0IHNwZWNpZnlpbmcgc3BlY3RydW0gYXZhaWxhYmlsaXR5 Lg0KPj4+PlNwZWN0cnVtDQo+Pj4+IHVuaXRzIGFyZSBzcGVjaWZpZWQgYnkgbG93IGFuZCBoaWdo IGZyZXF1ZW5jaWVzIGFuZCBtYXkgaGF2ZSBhbg0KPj4+PiBvcHRpb25hbCBjaGFubmVsIGlkZW50 aWZpZXIuDQo+Pj4+DQo+Pj4+IFRoZSBkYXRhIG1vZGVsIG11c3Qgc3VwcG9ydCBhIHNjaGVkdWxl IGZvciBzcGVjdHJ1bSB1bml0IGF2YWlsYWJpbGl0eS4NCj4+Pj4gVHdvIG1lY2hhbmlzbXMgbXVz dCBiZSBzdXBwb3J0ZWQuICBUaGUgcmVzcG9uc2UgdG8gc3BlY3RydW0NCj4+Pj4gYXZhaWxhYmls aXR5IHF1ZXJ5IG1heSBpbmNsdWRlIGEgdGltZSBieSB3aGljaCB0aGUgZGF0YWJhc2UgbXVzdCBi ZQ0KPj4+PiByZXF1ZXJpZWQuICBFYWNoIHNwZWN0cnVtIHVuaXQgbWVudGlvbmVkIGluIHRoZSBy ZXNwb25zZSBtYXkgYmUNCj4+Pj4gYW5ub3RhdGVkIHdpdGggc3RhcnQgYW5kIHN0b3AgdGltZS9k YXRlLg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4+PiBGcm9tOiAgICAgRXJpYyBDaHUgW21haWx0bzplcmljY2h1QGdvb2dsZS5jb21dDQo+Pj4+ IFNlbnQ6ICAgIFNhdHVyZGF5LCBBdWd1c3QgMTEsIDIwMTIgMTE6NDMgQU0gRWFzdGVybiBTdGFu ZGFyZCBUaW1lDQo+Pj4+IFRvOiAgICBUZWNvIEJvb3QNCj4+Pj4gQ2M6ICAgIFJvc2VuLCBCcmlh bjsgcGF3c0BpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiAgICBSZTogW3Bhd3NdIHVzZSBjYXNlcyBh bmQgcmVxdWlyZW1lbnRzIGRvY3VtZW50DQo+Pj4+DQo+Pj4+DQo+Pj4+IEhpIGV2ZXJ5b25lLA0K Pj4+Pg0KPj4+PiBHYXRoZXJpbmcgYWxsIHRoZSBzaGFyZWQgcG9pbnRzIGZyb20gZXZlcnlvbmUu Li4gSSBiZWxpZXZlIGJlbG93IGlzDQo+Pj4+dGhlDQo+Pj4+IGNvbXBsZXRlIGxpc3Qgc28gZmFy Og0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiAqICAgIFdoYXQncyB0aGUgYmVzdCBjb25zaXN0ZW50 IHJlcHJlc2VudGF0aW9uIG9mIHRoZSB3b3JkcyAiY2hhbm5lbA0KPj4+PiBudW1iZXJzIiBmb3Ig bm9uLVRWIHNwZWN0cnVtDQo+Pj4+ICogICAgU2hvdWxkIHdlIHVwZGF0ZSB0aGUgZW50aXJlIGRv YyBvbiB0aGUgdG9waWMgb2YgqfhjaGFubmVsqfcgb3INCj4+Pj4gqfhjaGFubmVsIG51bWJlcnOp 9w0KPj4+PiAqICAgIFdoYXSp9nMgdGhlIGJlc3Qgd2F5IHRvIHJlZHVjZSB2YWd1ZW5lc3MgaW4g d2hldGhlci9ob3cgdG8gaW5jbHVkZQ0KPj4+PiAiY2hhbm5lbCBudW1iZXJzIg0KPj4+PiAqICAg IElzIHRoZSByZWZlcmVuY2UgdG8gdmFyaWFibGUgcG93ZXIgcmVxdWlyZWQNCj4+Pj4gKiAgICBX aGF0IGRvZXMgY2hhbm5lbCBhdmFpbGFiaWxpdHkgc2NoZWR1bGUgbWVhbg0KPj4+Pg0KPj4+Pg0K Pj4+PiBCcmlhbidzIHN1Z2dlc3Rpb24gb2YgcmVwbGFjaW5nIGV2ZXJ5IGluc3RhbmNlIG9mICJj aGFubmVsIiBpcw0KPj4+PiB0ZWNobmljYWxseSBjb3JyZWN0bHkuIEhvd2V2ZXIsIGl0IGlzIGlt cG9ydGFudCBmb3IgdXMgdG8gZm9jdXMgbW92aW5nDQo+Pj4+IGZvcndhcmQuICBJIHdvdWxkIHN1 Z2dlc3Qgd2Ugb25seSB3b3JrIG9uIHRoZSBub3JtYXRpdmUgcGFydCBvZiB0aGUNCj4+Pj5zcGVj Lg0KPj4+PiBUaGUgc2VjdGlvbiBHYWJvciBpcyBwcm9wb3NpbmcgZm9yIHVzIHRvIG1vZGlmeS4u Lg0KPj4+Pg0KPj4+PiBPbiB3aGF0J3MgdGhlIGJlc3QgZ2VuZXJpYyBsYWJlbCBmb3IgdGhlIHdv cmRzICJjaGFubmVsIG51bWJlcnMiLA0KPj4+PiBjaGFubmVsIGlkZW50aWZpZXIgbWlnaHQgYmUg dGhlIG1vc3QgYWNjdXJhdGUgYW5kIG5ldXRyYWwgImxhYmVsIi4NCj4+Pj4gVGhvdWdodHM/DQo+ Pj4+DQo+Pj4+IE9uIHRoZSBxdWVzdGlvbiB3aGV0aGVyIHZhcmlhYmxlIHBvd2VyIGlzIHJlcXVp cmVkLCBiYXNlZCBvbiBGQ0MNCj4+Pj4gYWRqYWNlbnQtY2hhbm5lbCBydWxlcywgdGhlIGRhdGFi YXNlIG1heSBsaW1pdCB0aGUgTW9kZSBJSSBkZXZpY2VzIHRvDQo+Pj4+IDEwMG1XIGZvciBzb21l IGNoYW5uZWxzIGFuZCA0MG1XIGZvciBvdGhlcnMuIFRoZXJlZm9yZSwgdGhlIGRhdGEgbW9kZWwN Cj4+Pj4gbmVlZHMgdG8gc3VwcG9ydCBzcGVjaWZpY2F0aW9uIG9mIG1heGltdW0gcG93ZXIgbGV2 ZWxzLg0KPj4+Pg0KPj4+PiBMYXN0bHksIHdpdGggcmVnYXJkcyB0byAic2NoZWR1bGUiLCB0aGUg aW50ZW50IGlzIHRvIGhhdmUgYSB3YXkgb2YNCj4+Pj4gaW5mb3JtaW5nIGRldmljZXMgd2hlbiB0 byBvcGVyYXRlIGZvciBlYWNoIGZyZXF1ZW5jeSByYW5nZS4gQXMgbG9uZyBhcw0KPj4+PiB0aGUg ZGF0YSBtb2RlbCBzdXBwb3J0cywgZm9yIGV4YW1wbGUsIGEgbGlzdCBvZiB0aW1lIHJhbmdlcywg aXQgZG9lcw0KPj4+PiBub3QgcHJldmVudCBhbiBpbXBsZW1lbnRhdGlvbiBmcm9tIHByb3ZpZGlu ZyBhIGxpc3Qgd2l0aCAxIGVudHJ5IHdoaWNoDQo+Pj4+IGNvcnJlc3BvbmRzIHRvIHRoZSAic2hv cnRlc3QgYXZhaWxhYmxlIi4gIFRoZSB3b3JkICJzY2hlZHVsZSIgc2hvdWxkDQo+Pj4+YmUNCj4+ Pj4gc3VmZmljaWVudCB0byBjYXB0dXJlIHRoaXMgaW50ZW50Pw0KPj4+Pg0KPj4+PiBXZSB3b3Vs ZCBsaWtlIHRvIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIGFkZHJlc3MgdGhlc2UgcG9p bnRzOg0KPj4+Pg0KPj4+PiAiVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcg YXZhaWxhYmxlIHNwZWN0cnVtLiBUaGUgRGF0YQ0KPj4+PiBNb2RlbCBNVVNUIHN1cHBvcnQgc3Bl Y2lmaWNhdGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IHN0YXJ0IGFuZCBzdG9wDQo+Pj4+IGZy ZXF1ZW5jaWVzIGFuZCBNQVkgYWxzbyBzdXBwb3J0IHNwZWNpZmljYXRpb24gb2YgdGhpcyBpbmZv cm1hdGlvbiBieQ0KPj4+PiBjaGFubmVsIGlkZW50aWZpZXJzLiBUaGUgRGF0YSBNb2RlbCBNVVNU IHN1cHBvcnQgYQ0KPj4+PiBzcGVjdHJ1bS1hdmFpbGFiaWxpdHkgc2NoZWR1bGUgYW5kIG1heGlt dW0gcG93ZXIgbGV2ZWxzIGZvciBlYWNoDQo+Pj4+IGZyZXF1ZW5jeSByYW5nZS4iDQo+Pj4+DQo+ Pj4+DQo+Pj4+IFRob3VnaHRzPw0KPj4+PiBFcmljDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IE9u IDgvMTAvMTIgNTo0OCBBTSwgVGVjbyBCb290IHdyb3RlOg0KPj4+Pg0KPj4+Pg0KPj4+PiAgICBX aGF0IGFib3V0IHRoaXM6DQo+Pj4+DQo+Pj4+ICAgICAgICCp+FRoZSBEYXRhIE1vZGVsIE1VU1Qg c3VwcG9ydCBzcGVjaWZ5aW5nIGEgbGlzdCBvZiBhdmFpbGFibGUNCj4+Pj4gY2hhbm5lbHMuIFRo ZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZpY2F0aW9uIG9mIHRoaXMNCj4+Pj5pbmZv cm1hdGlvbg0KPj4+PiBieSBzdGFydCBhbmQgc3RvcCBmcmVxdWVuY2llcywgb3IgZXF1aXZhbGVu dHMgc3VjaCBhcyBjZW50ZXINCj4+Pj4gZnJlcXVlbmNpZXMgd2l0aCBjaGFubmVsIHdpZHRoIG9y IGNoYW5uZWwgbnVtYmVycyB3aXRoIGNoYW5uZWwgbnVtbWVyDQo+Pj4+IGFsbG9jYXRpb24gc2No ZW1lIC4gVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IGEgY2hhbm5lbCBhdmFpbGFiaWxpdHkN Cj4+Pj4gc2NoZWR1bGUgYW5kIG1heGltdW0gcG93ZXIgbGV2ZWwgZm9yIGVhY2ggY2hhbm5lbCBp biB0aGUgbGlzdC6p9w0KPj4+PiAgICANCj4+Pj4gICAgTW9yZSB0aG91Z2h0cyBvbiBjaGFubmVs IG51bWJlcnM6IHdlIGxpa2VseSBydW4gaW50byBwcm9ibGVtcyBpbg0KPj4+PiBiYW5kcyB3aXRo b3V0IGEgY2hhbm5lbCBudW1iZXJpbmcgc2NoZW1lLCBvciBmb3IgZXhhbXBsZSBzdWIgY2hhbm5l bHMNCj4+Pj4gaW4gVFYgYmFuZHMuDQo+Pj4+DQo+Pj4+ICAgIFRlY28NCj4+Pj4NCj4+Pj4NCj4+ Pj4gICAgT3AgMTAgYXVnLiAyMDEyLCBvbSAxMzo1NyBoZWVmdCBSb3NlbiwgQnJpYW4gaGV0IHZv bGdlbmRlDQo+Pj4+Z2VzY2hyZXZlbjoNCj4+Pj4NCj4+Pj4NCj4+Pj4gICAgICAgIDxhcyBpbmRp dmlkdWFsPg0KPj4+PiAgICAgICAgV2hpbGUgSSBkb24ndCBjYXJlIGlmIGl0J3MgY2VudGVyIGFu ZCB3aWR0aCBvciB1cHBlci9sb3dlciwgSQ0KPj4+PiBkbyB0aGluayB3ZSB3aWxsIGRlZmluZSB0 aGUgZm9ybWF0IGluIHRoZSBwcm90b2NvbCBmb3INCj4+Pj5pbnRlcm9wZXJhYmlsaXR5DQo+Pj4+ IHJlYXNvbnMsIGJ1dCBkb24ndCBuZWVkIHRvIGRvIHRoYXQgaW4gcmVxdWlyZW1lbnRzLiAgSXQg d291bGRuJ3QgaHVydA0KPj4+PiB0byBkZWNpZGUgbm93IGFuZCB1c2UgY29uc2lzdGVudCB0ZXJt cywgYnV0IHdlIGRvbid0IG5lZWQgdG8uDQo+Pj4+DQo+Pj4+ICAgICAgICBJIHRoaW5rICJiYW5k IiB3b24ndCB3b3JrLCBhcyBpdCB1c3VhbGx5IGltcGxpZXMgYSBtdWNoIHdpZGVyDQo+Pj4+IHBp ZWNlIG9mIHNwZWN0cnVtIHRoYXQgaGFzIGEgY29tbW9uIHB1cnBvc2UuICBUaGUgVFYgQmFuZCBp cyBhbGwgdGhlDQo+Pj4+IGNoYW5uZWxzLg0KPj4+Pg0KPj4+Pg0KPj4+PiAgICAgICAgT24gQXVn IDEwLCAyMDEyLCBhdCAyOjM3IEFNLCBUZWNvIEJvb3QgPHRlY29AaW5mLW5ldC5ubD4gd3JvdGU6 DQo+Pj4+DQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgKHNvbWV3aGF0IGxhdGUgcmVzcG9uc2UpDQo+ Pj4+DQo+Pj4+ICAgICAgICAgICAgQSBjZW50ZXIgZnJlcXVlbmN5IGFuZCBjaGFubmVsIHdpZHRo IGlzIGZ1bmN0aW9uYWwNCj4+Pj4gZXF1aXZhbGVudCB0byBzdGFydC9zdG9wIGZyZXF1ZW5jaWVz LiBTbyBpcyBjaGFubmVsIG51bWJlciwgd2l0aCByZWYNCj4+Pj50bw0KPj4+PiBjaGFubmVsIG51 bWJlciBhc3NpZ25tZW50IHNjaGVtZS4gRm9yIGEgcmVxdWlyZW1lbnRzIGRvY3VtZW50LCB3ZSBq dXN0DQo+Pj4+IG5lZWQgdG8gc3BlY2lmeSB3aGF0IGlzIG5lZWRlZC4gSG93IGl0IGlzIGVuY29k ZWQgKEh6LCB3YXZlIGxlbmd0aCwNCj4+Pj4gY2hhbm5lbCBJRCkgaXMgc29sdXRpb24gc3BhY2Uu DQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgU2VlbiBvdXIgZ29hbCB0byBtYWtlIFBBV1Mgc29tZXdo YXQgdW5pdmVyc2FsIChub3QgbGltaXRlZA0KPj4+PiB0byBVUyBUVldTKSwgSSBkbyBub3QgcHJl ZmVyIHVzaW5nIGNoYW5uZWwgbnVtYmVycy4NCj4+Pj4NCj4+Pj4gICAgICAgICAgICBUZWNvDQo+ Pj4+DQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgT3AgOSBhdWcuIDIwMTIsIG9tIDIxOjU1IGhlZWZ0 IDxHYWJvci5CYWprb0Bub2tpYS5jb20+DQo+Pj4+IDxHYWJvci5CYWprb0Bub2tpYS5jb20+IGhl dCB2b2xnZW5kZSBnZXNjaHJldmVuOg0KPj4+Pg0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRm9sa3MsDQo+Pj4+ICAgICAgICAgICAgICAgDQo+Pj4+ICAgICAgICAg ICAgICAgIER1cmluZyB0aGUgbGFzdCBGMkYgbWVldGluZywgdGhlcmUgd2FzIGFuIGFncmVlbWVu dCB0bw0KPj4+PiBtYWtlIGEgc2xpZ2h0IHVwZGF0ZSB0byByZXF1aXJlbWVudCBELjcgaW4NCj4+ Pj4gDQo+Pj4+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXBhd3MtcHJvYmxlbS1z dG10LXVzZWNhc2VzLXJxbXRzLTA2LnQNCj4+Pj4geHQsICB0byBtYWtlIGNoYW5uZWwgbnVtYmVy cyBvcHRpb25hbCB0byBiZSBzdXBwb3J0ZWQuIEllLCBjaGFuZ2UgdGhlDQo+Pj4+IGN1cnJlbnQN Cj4+Pj4gRC43DQo+Pj4+ICAgICAgICAgICAgICAgIKn4VGhlIERhdGEgTW9kZWwgTVVTVCBzdXBw b3J0IHNwZWNpZnlpbmcgYSBsaXN0IG9mDQo+Pj4+IGF2YWlsYWJsZSBjaGFubmVscy4gVGhlIERh dGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZmljYXRpb24gb2YgdGhpcw0KPj4+PiBpbmZvcm1h dGlvbiBieSBjaGFubmVsIG51bWJlcnMgYW5kIGJ5IHN0YXJ0IGFuZCBzdG9wIGZyZXF1ZW5jaWVz LiBUaGUNCj4+Pj4gRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIGF2YWlsYWJpbGl0 eSBzY2hlZHVsZSBhbmQgbWF4aW11bQ0KPj4+PiBwb3dlciBsZXZlbCBmb3IgZWFjaCBjaGFubmVs IGluIHRoZSBsaXN0Lqn3DQo+Pj4+ICAgICAgICAgICAgICAgIHRvDQo+Pj4+ICAgICAgICAgICAg ICAgIKn4VGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgYSBsaXN0IG9mDQo+ Pj4+IGF2YWlsYWJsZSBjaGFubmVscy4gVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNp ZmljYXRpb24gb2YgdGhpcw0KPj4+PiBpbmZvcm1hdGlvbiBieSBzdGFydCBhbmQgc3RvcCBmcmVx dWVuY2llcyBhbmQgTUFZIGluY2x1ZGUgY2hhbm5lbA0KPj4+PiBudW1iZXJzLiBUaGUgRGF0YSBN b2RlbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIGF2YWlsYWJpbGl0eSBzY2hlZHVsZQ0KPj4+PiBh bmQgbWF4aW11bSBwb3dlciBsZXZlbCBmb3IgZWFjaCBjaGFubmVsIGluIHRoZSBsaXN0Lqn3DQo+ Pj4+ICAgICAgICAgICAgICAgDQo+Pj4+ICAgICAgICAgICAgICAgIEmp9mQgbGlrZSB0byBjb25m aXJtIHRoaXMgY2hhbmdlIG9uIHRoZSBsaXN0LiBJZiBhbnlvbmUNCj4+Pj4gaGFzIGFueSBvYmpl Y3Rpb25zLCBsZXQgbWUga25vdy4gT3RoZXJ3aXNlIEmp9mxsIHBsYW4gdG8gc2VuZCB0aGUNCj4+ Pj4gZG9jdW1lbnQgdG8gdGhlIGllc2cgYWZ0ZXIgdGhpcyBjaGFuZ2UgaXMgaW1wbGVtZW50ZWQu DQo+Pj4+ICAgICAgICAgICAgICAgDQo+Pj4+ICAgICAgICAgICAgICAgIC0gICAgICAgICAgR2Fi b3INCj4+Pj4gICAgICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+Pj4gICAgICAgICAgICAgICAgcGF3cyBtYWlsaW5nIGxpc3QNCj4+ Pj4gICAgICAgICAgICAgICAgcGF3c0BpZXRmLm9yZw0KPj4+PiAgICAgICAgICAgICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+Pj4gICAgICAgICAgICAg ICANCj4+Pj4gICAgICAgICAgICAgICANCj4+Pj4NCj4+Pj4gICAgICAgICAgICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiAgICAgICAgICAgIHBh d3MgbWFpbGluZyBsaXN0DQo+Pj4+ICAgICAgICAgICAgcGF3c0BpZXRmLm9yZw0KPj4+PiAgICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4+PiAg ICAgICAgICAgIA0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiAgICAgDQo+Pj4+ICAgIA0K Pj4+PiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+PiAgICBwYXdzIG1haWxpbmcgbGlzdA0KPj4+PiAgICBwYXdzQGlldGYub3JnDQo+Pj4+ICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4+PiAgICANCj4+ Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHBhd3MgbWFpbGluZyBs aXN0DQo+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcGF3cw0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4+PiBwYXdzQGlldGYub3JnDQo+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gcGF3cyBtYWlsaW5nIGxp c3QNCj4+IHBhd3NAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcGF3cw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+cGF3cyBtYWlsaW5nIGxpc3QNCj5wYXdzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg== From d.joslyn@spectrumbridge.com Mon Aug 20 10:14:09 2012 Return-Path: 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 33C8F21F86BE for ; Mon, 20 Aug 2012 10:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 AE2YboYbsAyw for ; Mon, 20 Aug 2012 10:14:08 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id E4AD221F86C6 for ; Mon, 20 Aug 2012 10:14:07 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 20 Aug 2012 13:14:07 -0400 From: Don Joslyn To: "Rosen, Brian" , "gabor.bajko@nokia.com" , "scott.probasco@nokia.com" , "paws@ietf.org" Date: Mon, 20 Aug 2012 13:14:09 -0400 Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac18eWo57RZXkm8FS5GMslnWLPKh5wCfWNVQ Message-ID: <8375F6DAEFB09F48815203F1FE23B797117AA6D8AF@shelby> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB427D@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 17:14:09 -0000 I agree with Brian's suggestion to use ISO 8601 interval format. This plain= text representation makes it easier to debug messages, and it includes tim= ezone information. -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ros= en, Brian Sent: Friday, August 17, 2012 9:09 AM To: gabor.bajko@nokia.com; scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] use cases and requirements document Uh, the difference is representation of start/stop times. We both propose = to send start/stop times. Vincent proposes that the representation of time= be a long integer seconds since an epoch. He would send two such long int= egers. I propose it be an ISO 8601 time string. Specifically, I would pro= pose an ISO 8601 interval limited to start/end, e.g. 2011-03-01T13:00:00Z/2012-05-11T15:30:00Z. On 8/16/12 6:45 PM, "Gabor.Bajko@nokia.com" wrote: >It seems we have an agreement on the requirement to identify the=20 >spectrum, by using the start/stop frequencies, with optional channel=20 >identifiers. > >Wrt to the schedule, we have so far two proposals, one from Brian=20 >proposing the use of start/stop times for each spectrum unit available,=20 >and one from Vincent proposing to use of Unix Epoch time in seconds. We=20 >need to decide on this, so please send your preference on this topic to=20 >the list. > >- Gabor > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of=20 >Probasco Scott (Nokia-CIC/Dallas) >Sent: Monday, August 13, 2012 10:12 AM >To: paws@ietf.org >Subject: Re: [paws] use cases and requirements document > >Hi All, > >Given that we have completed two Working Group Last Call cycles and=20 >this next version will go to the IESG, I hope we could agree on minimal=20 >changes to the document, i.e. changes only to D.7 for this topic. This=20 >will ensure the proper requirements are established for the developing=20 >PAWS protocol. >I believe Brian's proposed text captures the essential requirements. > >Kind Regards, >Scott > > >On 8/13/12 8:24 AM, "ext Rosen, Brian" wrote: > >> >>I would prefer to not use the word "channel" in our documents at all=20 >>except for the term "channel identifier". I proposed "spectrum unit",=20 >>although any other term will do. "Channel" has too much baggage, A=20 >>simple editorial change like this is simple, and it's much better to=20 >>do it now. >> >>I think we need power in both the query and the response. In some=20 >>domains, it may be that you specify what power you want to use and the=20 >>DB tells you what spectrum you can use at that power. In other, a=20 >>US-like rule may be in place. Also in either the query or the=20 >>registration, we need a device type, which should be an entry from an=20 >>IANA registry. This is how you get the US "Mode II" information. >> >>With regard to schedule, I would like to see two mechanisms >>1) a time by which the database should be queried again (which could=20 >>represent the next change in schedule) >>2) start/stop times for each spectrum unit available >> >>Both these should be optional in the response. >> >>My text >> >>The data model must support specifying spectrum availability. =20 >>Spectrum units are specified by low and high frequencies and may have=20 >>an optional channel identifier. >> >>The data model must support a schedule for spectrum unit availability. >>Two mechanisms must be supported. The response to spectrum=20 >>availability query may include a time by which the database must be=20 >>requeried. Each spectrum unit mentioned in the response may be=20 >>annotated with start and stop time/date. >> >> >> >> -----Original Message----- >>From: Eric Chu [mailto:ericchu@google.com] >>Sent: Saturday, August 11, 2012 11:43 AM Eastern Standard Time >>To: Teco Boot >>Cc: Rosen, Brian; paws@ietf.org >>Subject: Re: [paws] use cases and requirements document >> >> >>Hi everyone, >> >>Gathering all the shared points from everyone... I believe below is=20 >>the complete list so far: >> >> >> >>* What's the best consistent representation of the words "channel >>numbers" for non-TV spectrum >>* Should we update the entire doc on the topic of =B3channel=B2 or >>=B3channel numbers=B2 >>* What=B9s the best way to reduce vagueness in whether/how to include >>"channel numbers" >>* Is the reference to variable power required >>* What does channel availability schedule mean >> >> >>Brian's suggestion of replacing every instance of "channel" is=20 >>technically correctly. However, it is important for us to focus moving=20 >>forward. I would suggest we only work on the normative part of the spec. >> The section Gabor is proposing for us to modify... >> >>On what's the best generic label for the words "channel numbers",=20 >>channel identifier might be the most accurate and neutral "label". >>Thoughts? >> >>On the question whether variable power is required, based on FCC=20 >>adjacent-channel rules, the database may limit the Mode II devices to=20 >>100mW for some channels and 40mW for others. Therefore, the data model=20 >>needs to support specification of maximum power levels. >> >>Lastly, with regards to "schedule", the intent is to have a way of=20 >>informing devices when to operate for each frequency range. As long as=20 >>the data model supports, for example, a list of time ranges, it does=20 >>not prevent an implementation from providing a list with 1 entry which=20 >>corresponds to the "shortest available". The word "schedule" should=20 >>be sufficient to capture this intent? >> >>We would like to propose the following text to address these points: >> >>"The Data Model MUST support specifying available spectrum. The Data=20 >>Model MUST support specification of this information by start and stop=20 >>frequencies and MAY also support specification of this information by=20 >>channel identifiers. The Data Model MUST support a=20 >>spectrum-availability schedule and maximum power levels for each=20 >>frequency range." >> >> >>Thoughts? >>Eric >> >> >> >>On 8/10/12 5:48 AM, Teco Boot wrote: >> >> >> What about this: >> >> =B3The Data Model MUST support specifying a list of available=20 >>channels. The Data Model MUST support specification of this=20 >>information by start and stop frequencies, or equivalents such as=20 >>center frequencies with channel width or channel numbers with channel=20 >>nummer allocation scheme . The Data Model MUST support a channel=20 >>availability schedule and maximum power level for each channel in the=20 >>list.=B2 >> =20 >> More thoughts on channel numbers: we likely run into problems in=20 >>bands without a channel numbering scheme, or for example sub channels=20 >>in TV bands. >> >> Teco >> >> >> Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende geschreven: >> >> >> >> While I don't care if it's center and width or upper/lower, I=20 >>do think we will define the format in the protocol for=20 >>interoperability reasons, but don't need to do that in requirements. =20 >>It wouldn't hurt to decide now and use consistent terms, but we don't nee= d to. >> >> I think "band" won't work, as it usually implies a much wider=20 >>piece of spectrum that has a common purpose. The TV Band is all the=20 >>channels. >> >> >> On Aug 10, 2012, at 2:37 AM, Teco Boot wrote: >> >> >> (somewhat late response) >> >> A center frequency and channel width is functional=20 >>equivalent to start/stop frequencies. So is channel number, with ref=20 >>to channel number assignment scheme. For a requirements document, we=20 >>just need to specify what is needed. How it is encoded (Hz, wave=20 >>length, channel ID) is solution space. >> >> Seen our goal to make PAWS somewhat universal (not limited=20 >>to US TVWS), I do not prefer using channel numbers. >> >> Teco >> >> >> Op 9 aug. 2012, om 21:55 heeft =20 >> het volgende geschreven: >> >> >> Folks, >> =20 >> During the last F2F meeting, there was an agreement to=20 >>make a slight update to requirement D.7 in=20 >>http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06. >>t xt, to make channel numbers optional to be supported. Ie, change=20 >>the current >>D.7 >> =B3The Data Model MUST support specifying a list of=20 >>available channels. The Data Model MUST support specification of this=20 >>information by channel numbers and by start and stop frequencies. The=20 >>Data Model MUST support a channel availability schedule and maximum=20 >>power level for each channel in the list.=B2 >> to >> =B3The Data Model MUST support specifying a list of=20 >>available channels. The Data Model MUST support specification of this=20 >>information by start and stop frequencies and MAY include channel=20 >>numbers. The Data Model MUST support a channel availability schedule=20 >>and maximum power level for each channel in the list.=B2 >> =20 >> I=B9d like to confirm this change on the list. If anyone= =20 >>has any objections, let me know. Otherwise I=B9ll plan to send the=20 >>document to the iesg after this change is implemented. >> =20 >> - Gabor >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> =20 >> =20 >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> =20 >> >> >> >> >> =20 >> =20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> =20 >> >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From vchen@google.com Mon Aug 20 11:56:25 2012 Return-Path: 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 DD47F21F84FE for ; Mon, 20 Aug 2012 11:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.226 X-Spam-Level: X-Spam-Status: No, score=-102.226 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 bvTob67VglEL for ; Mon, 20 Aug 2012 11:56:24 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF2121F84F5 for ; Mon, 20 Aug 2012 11:56:23 -0700 (PDT) Received: by qadb17 with SMTP id b17so3066907qad.10 for ; Mon, 20 Aug 2012 11:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=PmJuiPD3wPPeXayA2G699ZHO5LKlcr1Dc2H74zn4YJ0=; b=dhgkBIEGjOtWPXABAO2G8UWhv4w/OcFpm9l5WSO22iru+HNE55vGtE+i1UzIWbPfNg X7mXkkYeBbaMEi7ps5NAocU4L72VKJlyjOIaMTWokY2SghFfMN7tHtlGuKi3DGMW0fuE 8HGOPkifrh13p6vXmcUjGC7TvLz8Ed0Xmqr8jTvytWOigdK8QEAlHnvxxXOuWxLRV8OU 3Zh4W2KTpgd1X4vwph6UW7S6WPL6qwlfhiADtZDCXDIJ8YcNXSrb7jbHpzlCHHHizUbu HdZuYMFgfX8cEgOH4sXHjBAOs+VVUlqkwf4Gk70YBM7FYvorMu+rYp4ilaAaXX8ezB6V sflg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=PmJuiPD3wPPeXayA2G699ZHO5LKlcr1Dc2H74zn4YJ0=; b=AEVpD5VjRQTc5oyu9eUiEov63OzH9U5NdGeMgV0ttVEa+9Zsksyj9LbjKeDGIVUcnB k2Fjg2VAclAN/TI3isUx19qi78A4eQ7C4R7O4B60LzdhkfZ6Q+DHFL3eA03vqI8kytyP B6oWG4ODq906areFDp+Ju3yMhlzMCgYNUOPUQRwxlOSjzLL9JNbvPtPw3/Ger8aNIgmO dlflKeonPHwqztCMTyRyRJwd/Yg1kTa45JbB498Ck4qd0ubR8uYviGMonmjQrvHi1ENy tOYsOajr50NYTq0qpe9xye4SwPJWNy+19t3IlVj8sRvEG5gCDBjYgoijWPpnEgS7p1au aMpQ== Received: by 10.229.136.83 with SMTP id q19mr13565059qct.47.1345488983122; Mon, 20 Aug 2012 11:56:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.136.83 with SMTP id q19mr13565034qct.47.1345488982704; Mon, 20 Aug 2012 11:56:22 -0700 (PDT) Received: by 10.229.64.149 with HTTP; Mon, 20 Aug 2012 11:56:22 -0700 (PDT) In-Reply-To: References: <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com> Date: Mon, 20 Aug 2012 11:56:22 -0700 Message-ID: From: Vincent Chen To: Weixinpeng Content-Type: multipart/alternative; boundary=00248c768f6add04d404c7b710f7 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnhFc4M5yu9ACurlLfIDVQ1nFlbYQTSLz4qIiXxaShpR1RcC1+tWee2RTR6JOPnpNHioEb6hTUurOoeidRbA44Ue2gLal8MJJkxvJ0yjvb4tAVu6d8pmfv9LdulJ6ipnKAxxRMZoE9RebUWMf/hFEFCEYT1VD7Iww8k/QqhzqGozsA5TAYo2xoCPCRMEK96fDiZ+JQm Cc: "paws@ietf.org" , Manikkoth Sajeev 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 18:56:26 -0000 --00248c768f6add04d404c7b710f7 Content-Type: text/plain; charset=ISO-8859-1 * - 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. - 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. - 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. - 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? * On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng 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] *On Behalf > Of *Rosen, Brian > > *Sent:* Friday, August 17, 2012 9:26 PM > *To:* Manikkoth Sajeev; gabor.bajko@nokia.com; vchen@google.com; > peter@spectrumbridge.com > > *Cc:* 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 **** > > ** ** > > *From: *Manikkoth Sajeev > *Reply-To: *Manikkoth Sajeev > *Date: *Thu, 16 Aug 2012 22:37:38 -0400 > *To: *"Gabor.Bajko@nokia.com" , "Rosen, Brian" < > brian.rosen@neustar.biz>, "vchen@google.com" , " > peter@spectrumbridge.com" > *Cc: *"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 option*can 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 > Email: mksaji@ieee.org > http://www.linkedin.com/in/mksajeev***** > > ** ** > > *From:* "Gabor.Bajko@nokia.com" > *To:* Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com > *Cc:* 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] On Behalf Of > ext Rosen, Brian > Sent: Monday, August 13, 2012 3:14 PM > To: 'Vincent Chen'; 'Peter Stanforth' > Cc: '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 > > > > -----Original Message----- > From: Vincent Chen [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 > 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/) 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 > 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" > > 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] > >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time > >To: Teco Boot; Benjamin A.Rolfe > >Cc: 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" > 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 > >>>> > >>>> 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 > >>>> > >>>> Teco > >>>> _______________________________________________ > >>>> paws mailing list > >>>> paws@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/paws > >>>> > >>> > >>> _______________________________________________ > >>> paws mailing list > >>> paws@ietf.org > >>> https://www.ietf.org/mailman/listinfo/paws > >> > >>_______________________________________________ > >>paws mailing list > >>paws@ietf.org > >>https://www.ietf.org/mailman/listinfo/paws > > > >_______________________________________________ > >paws mailing list > >paws@ietf.org > >https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > > > -- > -vince > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > **** > -- -vince --00248c768f6add04d404c7b710f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
  • One of our goals is to strive to lower the cost and complexi= ty for device manufacturers. This lowers the barrier for building a robust = ecosystem.

  • To reduce complexity and cost for device makers, supporting = 1 encoding is better than both, as Brian points out. WiFi access points tha= t "just work" anywhere in the world serves as a good model.

  • There's a trend for APIs on the web towards JSON (Twitte= r, FourSquare, Facebook, Google, etc.). One of the major reasons is that de= velopers (client-side) prefer it for its simplicity:
    • Representation closely matches most data= models (nested lists and maps)
    • Simple-to-us= e libraries exist for all major languages/platforms
    • Don't ne= ed a tool chain to work with the data, as is typically needed for XML.

Apparently, the e= fficiency gains of JSON also matter to the scalability of serving systems.<= /span>


  • 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 ela= borate on the types of devices that already support XML?


<= div class=3D"gmail_extra">

On Fri, Aug 17= , 2012 at 6:06 PM, Weixinpeng <weixinpeng@huawei.com> wr= ote:

Considerin= g of the design of database discovery protocol, the LoST protocol may be us= ed and LoST is based on XML, so I think XML may be preferred.=

=A0=

--Xinpeng = Wei

=A0=

From: 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; vchen@google.com; peter@spectrumbridge.com

Cc: paws@ietf.org=
Subject: Re: [paws] XML schema versus JSON, vCard & iCal<= u>

=A0

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 id= ea there is no json representation of an existing standard. =A0So, if choos= ing json means folks feel free to ignore existing xml based standards such as xCard and LoST, then I would n= ot want to use json.

=A0=

I would prefer to not ha= ve "both", because of interoperability complications. =A0If there= is rough consensus for both, then I would assert that all servers have to implement both and the client can implement either.=

=A0=

There are json validator= s, so I don't think that is a big deal. =A0

=A0=

My experience in protoco= l design on the Internet is that decisions made solely or even largely beca= use of compactness advantages rarely are good choices. =A0If you like json because it is smaller, then I believe you nee= d a much better reason. =A0Binary doesn't work for me, at all. =A0I hav= e been involved in big binary vs text wars in protocol design. =A0Text wins= , binary loses, in my opinion.

=A0=

Brian <as individual&= gt;

=A0=

From: Manikkoth Sajeev <mksaji@yahoo.com>
Reply-To: Manikkoth Sajeev <mksaji@yahoo.com>
Date: Thu, 16 Aug 2012 22:37:38 -0400
To: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>, "Rosen, Brian"= ; <brian.ro= sen@neustar.biz>, "vchen@google.com" <vchen@google.com= >, "peter@spectrumbridge.com" <peter@spectrumbridge.com>
Cc: "paws@ie= tf.org" <paw= s@ietf.org>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal<= u>

=A0=

Hi,

=A0

Can it not be both JSON and XML supported? I would vote for that. Future = implementations may prefer XML as it is generic,=A0omni present, easy to understand and valida= te. For compactness may be a=A0 binary xml option can also work. JSON I think will necessi= tate implementation to be native Java and may not be as friendly with other= implementation languages.

=A0

Best Regards,<= u>

<= span lang=3D"EN-US" style=3D"color:#c00000">Sajeev Manikkoth
Mobile: +918792292002
Email: mksaji@ieee.org=
http://ww= w.linkedin.com/in/mksajeev=

=A0

From: "Gabor.Bajko@nokia.com" <Gabor.Bajko= @nokia.com>
To: Bri= an.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com
Cc: paws@ietf.org=
Sent: Friday, 17 August 2012, 4:55
Subject: Re: [paws] XML schema versus JSON, vCard & iCal<= span lang=3D"EN-US" style>


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-bounc= es@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'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.=A0
I'd prefer an ISO time stamp rather than a time in seconds since epoch.= =A0 It's very easy to parse, and its simpler to use and debug.=A0 Don&#= 39;t care a whole lot about that

Brian <as individual>



-----Original Message-----
From: =A0=A0=A0 Vincent Chen [mailto:vchen@google.com]
Sent:=A0=A0=A0 Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:=A0=A0=A0 Peter Stanforth
Cc:=A0=A0=A0 Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
Subject:=A0=A0=A0 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries exist for numerous languages (see= of http://json.org/) and seem to be reasonably light weight.

Timestamps

As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries 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> wr= ote:


=A0=A0=A0 Whenever we built mobile devices we never dealt with IETF, in our= sensor
=A0=A0=A0 days even an IP stack was a challenge,so I would defer to the dev= ice guys
=A0=A0=A0 on that one.
=A0=A0=A0
=A0=A0=A0 On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"
=A0=A0=A0
=A0=A0=A0 <= Brian.Rosen@neustar.biz> wrote:
=A0=A0=A0
=A0=A0=A0 >Our experience in the IETF over many years is that economizin= g message
=A0=A0=A0 >size and compromising utility and security in search of effic= iency of
=A0=A0=A0 >implementation on small devices is a poor trade off.=A0 I am = not advocating
=A0=A0=A0 >being wasteful of resources, but I don't think we should = seriously
=A0=A0=A0 >consider the overhead of XML or json to be significant.
=A0=A0=A0 >
=A0=A0=A0 >Assuming a json library can be loaded on a small device is re= asonable.
=A0=A0=A0 >
=A0=A0=A0 >Brian (as individual)
=A0=A0=A0 >
=A0=A0=A0 >
=A0=A0=A0 >
=A0=A0=A0 > -----Original Message-----
=A0=A0=A0 >From:=A0 Peter Stanforth [mailto:peter@spectrumbridge.com]
=A0=A0=A0 >Sent:=A0 Saturday, August 11, 2012 07:13 AM Eastern Standard = Time
=A0=A0=A0 >To:=A0 =A0 Teco Boot; Benjamin A.Rolfe
=A0=A0=A0 >Cc:=A0 =A0 paws@ietf.org
=A0=A0=A0 >Subject:=A0 =A0 =A0 Re: [paws] XML schema versus JSON, vCard = & iCal
=A0=A0=A0 >
=A0=A0=A0 >Not all masters run over the core network.
=A0=A0=A0 >Some of the Use cases have a master talking to another OTA =A0=A0=A0 >We should not assume that all Masters are attached to utility= power so we
=A0=A0=A0 >should be sympathetic to processing energy use also.
=A0=A0=A0 >
=A0=A0=A0 >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" &l= t;teco@inf-net.nl&= gt; wrote:
=A0=A0=A0 >
=A0=A0=A0 >>
=A0=A0=A0 >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe het vol= gende
=A0=A0=A0 >>geschreven:
=A0=A0=A0 >>
=A0=A0=A0 >>> Compactness of messages is important, but it is also= important (to me
=A0=A0=A0 >>>at least) to be realizable in an implementation with = limited resources,
=A0=A0=A0 >>>such as embedded devices in what are now popularly ca= lled "M2M"
=A0=A0=A0 >>>applications.=A0 A lot of these devices could use IP = all the end to end,
=A0=A0=A0 >>>but may have a very compact, simple stack and applica= tions (i.e.=A0 no
=A0=A0=A0 >>>browser).=A0 Is JSON typically implemented when there= is no browser?
=A0=A0=A0 >>>Would it be hard to do in a resource constrained devi= ce (i.e. where we
=A0=A0=A0 >>>talk about memory size in Kilo-bytes still).
=A0=A0=A0 >>
=A0=A0=A0 >>In use cases and requirements document, there are no requ= irements for
=A0=A0=A0 >>protocol performance. I guess OS/IP/TCP/TLS code size sup= ersedes needs
=A0=A0=A0 >>for JSON or XML.
=A0=A0=A0 >>
=A0=A0=A0 >>Same for timing: TCP/TLS connection setup will take more = than the PAWS
=A0=A0=A0 >>message exchange, I think. This may be of importance when= using satcom
=A0=A0=A0 >>links.
=A0=A0=A0 >>
=A0=A0=A0 >>Because PAWS runs between master and database, over core = network,
=A0=A0=A0 >>performance is not our primary concern. But as always, it= is good to keep
=A0=A0=A0 >>an eye on efficiency.
=A0=A0=A0 >>
=A0=A0=A0 >>Teco
=A0=A0=A0 >>
=A0=A0=A0 >>> Thanks
=A0=A0=A0 >>> Ben
=A0=A0=A0 >>>
=A0=A0=A0 >>>
=A0=A0=A0 >>>> We had a discussion on XML vs. JSON. I prefer th= e one with most
=A0=A0=A0 >>>>compact messages.
=A0=A0=A0 >>>>
=A0=A0=A0 >>>> On vCard and JSON: what is the status of "A= JavaScript Object Notation
=A0=A0=A0 >>>>(JSON) Representation for vCard"?
=A0=A0=A0 >>>> http://tools.ietf.org/html/draft-bhat-vcarddav-json-00
=A0=A0=A0 >>>>
=A0=A0=A0 >>>> On valid times: can we use same format as certif= icates? They have
=A0=A0=A0 >>>>similar simple requirements: valid notBefore&= =A0 notAfter.
=A0=A0=A0 >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
=A0=A0=A0 >>>>
=A0=A0=A0 >>>> Teco
=A0=A0=A0 >>>> _______________________________________________<= br> =A0=A0=A0 >>>> paws mailing list
=A0=A0=A0 >>>> paws@ietf.org
=A0=A0=A0 >>>> https://www.ietf.org/mailman/listinfo/paws
=A0=A0=A0 >>>>
=A0=A0=A0 >>>
=A0=A0=A0 >>> _______________________________________________
=A0=A0=A0 >>> paws mailing list
=A0=A0=A0 >>> p= aws@ietf.org
=A0=A0=A0 >>> https://www.ietf.org/mailman/listinfo/paws
=A0=A0=A0 >>
=A0=A0=A0 >>_______________________________________________
=A0=A0=A0 >>paws mailing list
=A0=A0=A0 >>paws@i= etf.org
=A0=A0=A0 >>https://www.ietf.org/mailman/listinfo/paws
=A0=A0=A0 >
=A0=A0=A0 >_______________________________________________
=A0=A0=A0 >paws mailing list
=A0=A0=A0 >paws@ietf.= org
=A0=A0=A0 >https://www.ietf.org/mailman/listinfo/paws
=A0=A0=A0
=A0=A0=A0 _______________________________________________
=A0=A0=A0 paws mailing list
=A0=A0=A0 paws@ietf.org<= /a>
=A0=A0=A0 https://www.ietf.org/mailman/listinfo/paws
=A0=A0=A0




--
-vince

_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
-vince
--00248c768f6add04d404c7b710f7-- From ben@blindcreek.com Mon Aug 20 12:55:03 2012 Return-Path: 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 DBC6421F856C for ; Mon, 20 Aug 2012 12:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599] 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 P1J5lXkAuvbZ for ; Mon, 20 Aug 2012 12:55:02 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id 7581821F85B8 for ; Mon, 20 Aug 2012 12:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=BRfs3vb78O2DYO/1RUXlu6PKhjhKJ3Ri5c5nUi5FRc0=; b=m/BZQZ6hvpvENLTyawO97NibZqMdeNMJdR4V8H/Ctr4xelwQWwkkO6+8r0Li14M2+Kj5gYlt5fdw/7FPi0bbRmrrZO6nXt3cdHMtdg9p/HR82S0QdoWqY8x89Uuc/oL9; Received: from [64.74.213.174] (port=58921 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1T3Y3u-0000IH-UD for paws@ietf.org; Mon, 20 Aug 2012 14:55:00 -0500 Message-ID: <50329616.3030207@blindcreek.com> Date: Mon, 20 Aug 2012 12:55:02 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: "paws@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 19:55:04 -0000 Peter makes a good point. The rules will allow a device to use channel availability data for as much as 48 hours - it allows that the device must access the database at least once per day, but if it tries and fails it can use the data until 11:59pm of the follow day. That wasn't the 48 hours I was thinking about though, I was thinking about the paragraph before that: ¡× 15.711 (b)(3)(i) ... Fixed TVBD must adjust their use of channels in accordance with channel availability schedule information provided by their database for the 48-hour period beginning at the time of the device last accessed the database for a list of available channels. So in addition to providing what is available now, plus how things are expected to change over the next 48 hour period. I shouldn't have said "guess" since the requirements for notice from the priority users are greater than 48 hours. Having now discussed it "out loud" so to speak, it really does not need to be two distinct notions. The The "start/end" on a per channel basis provides what you need; and the database has to provide a schedule at the time of request that shows everything from now until now + 48 hours. I also agree enthusiastically with Peter that we should expect changes in the requirements (and that is a guess, but an educated one ;-). Ben > Ben, > FCC rules do assume that a channel assignment if from now until some time > in the future, the current default is 24 hours - unless the device moves. > It is same to assume that the duration will become much shorter > eventually. So "Valid until" is a reasonable proposition. However the FCC > does not preclude a radio from getting a channel list in advance. In many > ways it makes more sense for a device to ask for a new channel list before > it's current list expires so start time might be relevant in this case. > > I don't think the FCC was proposing a "predictive guess". The actual FCC > rule is that a channel list is valid for 24hours, but if a device cannot > contact a database at that time it has permission to keep using the > channel list for a further 24hours (48hours total) I don't think this is a > good idea as it precludes a broadcaster reserving channels inside that > window, and, as mentioned above there is some discussion about making the > window much shorter to accommodate situations where broadcasters cannot > plan 24, or worst case 48 hours, in advance. Personally I prefer that the > device get a channel list that is good for some period, without any ifs > buts or maybes, and then it has to query again. This is much simpler than > trying to map matrices of start/stop times for various channels (maybe > with variable power limits) over an extended period. > Peter S. > > On MonAug/20/12 Mon Aug 20, 11:15 AM, "Benjamin A. Rolfe" > wrote: > >> Thanks for the clarification. >> There are also two notions of what "schedule" means, at least in the FCC >> rules. There is the notion that the current channel availability data >> has a expiration time, and thus there is a time in the future when >> updating will be necessary. This is at most a day. Based on FCC rules, >> this could be a local time determined by the device using the channel >> data, and if that device is acting as a source for dependent device >> "using" includes providing it to other dependent devices (and it would >> have to provide the "valid until" time). I can imagine that other >> regulatory bodies (and perhaps the FCC in the future) will require that >> channel availability data provided by the data base also be tagged with >> the "valid until" information. This does not require a start time, as >> "now" is implied. >> >> The other notion of schedule time is that the database contains a >> predictive guess as to what channels will be available for the next 48 >> hours into the future. This is required by FCC (though the device must >> still check at least once a day if what it is using is still valid). A >> start/stop pair is required for this. >> >> I think either format can be used to represent time in both cases. It is >> also possible that the 48-hour schedule is all that PAWS needs to >> provide to meet the regulations and the "valid until" can be derived > >from that by the using device. >> Hope that helps. >> -Ben >> >>> Uh, the difference is representation of start/stop times. We both >>> propose >>> to send start/stop times. Vincent proposes that the representation of >>> time be a long integer seconds since an epoch. He would send two such >>> long integers. I propose it be an ISO 8601 time string. Specifically, >>> I >>> would propose an ISO 8601 interval limited to start/end, e.g. >>> 2011-03-01T13:00:00Z/2012-05-11T15:30:00Z. >>> >>> On 8/16/12 6:45 PM, "Gabor.Bajko@nokia.com" >>> wrote: >>> >>>> It seems we have an agreement on the requirement to identify the >>>> spectrum, by using the start/stop frequencies, with optional channel >>>> identifiers. >>>> >>>> Wrt to the schedule, we have so far two proposals, one from Brian >>>> proposing the use of start/stop times for each spectrum unit available, >>>> and one from Vincent proposing to use of Unix Epoch time in seconds. We >>>> need to decide on this, so please send your preference on this topic to >>>> the list. >>>> >>>> - Gabor >>>> >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>>> Probasco Scott (Nokia-CIC/Dallas) >>>> Sent: Monday, August 13, 2012 10:12 AM >>>> To: paws@ietf.org >>>> Subject: Re: [paws] use cases and requirements document >>>> >>>> Hi All, >>>> >>>> Given that we have completed two Working Group Last Call cycles and >>>> this >>>> next version will go to the IESG, I hope we could agree on minimal >>>> changes to the document, i.e. changes only to D.7 for this topic. This >>>> will ensure the proper requirements are established for the developing >>>> PAWS protocol. >>>> I believe Brian's proposed text captures the essential requirements. >>>> >>>> Kind Regards, >>>> Scott >>>> >>>> >>>> On 8/13/12 8:24 AM, "ext Rosen, Brian" wrote: >>>> >>>>> >>>>> I would prefer to not use the word "channel" in our documents at all >>>>> except for the term "channel identifier". I proposed "spectrum unit", >>>>> although any other term will do. "Channel" has too much baggage, A >>>>> simple editorial change like this is simple, and it's much better to >>>>> do >>>>> it now. >>>>> >>>>> I think we need power in both the query and the response. In some >>>>> domains, it may be that you specify what power you want to use and the >>>>> DB tells you what spectrum you can use at that power. In other, a >>>>> US-like rule may be in place. Also in either the query or the >>>>> registration, we need a device type, which should be an entry from an >>>>> IANA registry. This is how you get the US "Mode II" information. >>>>> >>>>> With regard to schedule, I would like to see two mechanisms >>>>> 1) a time by which the database should be queried again (which could >>>>> represent the next change in schedule) >>>>> 2) start/stop times for each spectrum unit available >>>>> >>>>> Both these should be optional in the response. >>>>> >>>>> My text >>>>> >>>>> The data model must support specifying spectrum availability. >>>>> Spectrum >>>>> units are specified by low and high frequencies and may have an >>>>> optional channel identifier. >>>>> >>>>> The data model must support a schedule for spectrum unit availability. >>>>> Two mechanisms must be supported. The response to spectrum >>>>> availability query may include a time by which the database must be >>>>> requeried. Each spectrum unit mentioned in the response may be >>>>> annotated with start and stop time/date. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Eric Chu [mailto:ericchu@google.com] >>>>> Sent: Saturday, August 11, 2012 11:43 AM Eastern Standard Time >>>>> To: Teco Boot >>>>> Cc: Rosen, Brian; paws@ietf.org >>>>> Subject: Re: [paws] use cases and requirements document >>>>> >>>>> >>>>> Hi everyone, >>>>> >>>>> Gathering all the shared points from everyone... I believe below is >>>>> the >>>>> complete list so far: >>>>> >>>>> >>>>> >>>>> * What's the best consistent representation of the words "channel >>>>> numbers" for non-TV spectrum >>>>> * Should we update the entire doc on the topic of ©øchannel©÷ or >>>>> ©øchannel numbers©÷ >>>>> * What©ös the best way to reduce vagueness in whether/how to include >>>>> "channel numbers" >>>>> * Is the reference to variable power required >>>>> * What does channel availability schedule mean >>>>> >>>>> >>>>> Brian's suggestion of replacing every instance of "channel" is >>>>> technically correctly. However, it is important for us to focus moving >>>>> forward. I would suggest we only work on the normative part of the >>>>> spec. >>>>> The section Gabor is proposing for us to modify... >>>>> >>>>> On what's the best generic label for the words "channel numbers", >>>>> channel identifier might be the most accurate and neutral "label". >>>>> Thoughts? >>>>> >>>>> On the question whether variable power is required, based on FCC >>>>> adjacent-channel rules, the database may limit the Mode II devices to >>>>> 100mW for some channels and 40mW for others. Therefore, the data model >>>>> needs to support specification of maximum power levels. >>>>> >>>>> Lastly, with regards to "schedule", the intent is to have a way of >>>>> informing devices when to operate for each frequency range. As long as >>>>> the data model supports, for example, a list of time ranges, it does >>>>> not prevent an implementation from providing a list with 1 entry which >>>>> corresponds to the "shortest available". The word "schedule" should >>>>> be >>>>> sufficient to capture this intent? >>>>> >>>>> We would like to propose the following text to address these points: >>>>> >>>>> "The Data Model MUST support specifying available spectrum. The Data >>>>> Model MUST support specification of this information by start and stop >>>>> frequencies and MAY also support specification of this information by >>>>> channel identifiers. The Data Model MUST support a >>>>> spectrum-availability schedule and maximum power levels for each >>>>> frequency range." >>>>> >>>>> >>>>> Thoughts? >>>>> Eric >>>>> >>>>> >>>>> >>>>> On 8/10/12 5:48 AM, Teco Boot wrote: >>>>> >>>>> >>>>> What about this: >>>>> >>>>> ©øThe Data Model MUST support specifying a list of available >>>>> channels. The Data Model MUST support specification of this >>>>> information >>>>> by start and stop frequencies, or equivalents such as center >>>>> frequencies with channel width or channel numbers with channel nummer >>>>> allocation scheme . The Data Model MUST support a channel availability >>>>> schedule and maximum power level for each channel in the list.©÷ >>>>> >>>>> More thoughts on channel numbers: we likely run into problems in >>>>> bands without a channel numbering scheme, or for example sub channels >>>>> in TV bands. >>>>> >>>>> Teco >>>>> >>>>> >>>>> Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende >>>>> geschreven: >>>>> >>>>> >>>>> >>>>> While I don't care if it's center and width or upper/lower, I >>>>> do think we will define the format in the protocol for >>>>> interoperability >>>>> reasons, but don't need to do that in requirements. It wouldn't hurt >>>>> to decide now and use consistent terms, but we don't need to. >>>>> >>>>> I think "band" won't work, as it usually implies a much wider >>>>> piece of spectrum that has a common purpose. The TV Band is all the >>>>> channels. >>>>> >>>>> >>>>> On Aug 10, 2012, at 2:37 AM, Teco Boot wrote: >>>>> >>>>> >>>>> (somewhat late response) >>>>> >>>>> A center frequency and channel width is functional >>>>> equivalent to start/stop frequencies. So is channel number, with ref >>>>> to >>>>> channel number assignment scheme. For a requirements document, we just >>>>> need to specify what is needed. How it is encoded (Hz, wave length, >>>>> channel ID) is solution space. >>>>> >>>>> Seen our goal to make PAWS somewhat universal (not limited >>>>> to US TVWS), I do not prefer using channel numbers. >>>>> >>>>> Teco >>>>> >>>>> >>>>> Op 9 aug. 2012, om 21:55 heeft >>>>> het volgende geschreven: >>>>> >>>>> >>>>> Folks, >>>>> >>>>> During the last F2F meeting, there was an agreement to >>>>> make a slight update to requirement D.7 in >>>>> >>>>> http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.t >>>>> xt, to make channel numbers optional to be supported. Ie, change the >>>>> current >>>>> D.7 >>>>> ©øThe Data Model MUST support specifying a list of >>>>> available channels. The Data Model MUST support specification of this >>>>> information by channel numbers and by start and stop frequencies. The >>>>> Data Model MUST support a channel availability schedule and maximum >>>>> power level for each channel in the list.©÷ >>>>> to >>>>> ©øThe Data Model MUST support specifying a list of >>>>> available channels. The Data Model MUST support specification of this >>>>> information by start and stop frequencies and MAY include channel >>>>> numbers. The Data Model MUST support a channel availability schedule >>>>> and maximum power level for each channel in the list.©÷ >>>>> >>>>> I©öd like to confirm this change on the list. If anyone >>>>> has any objections, let me know. Otherwise I©öll plan to send the >>>>> document to the iesg after this change is implemented. >>>>> >>>>> - Gabor >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Mon Aug 20 13:11:46 2012 Return-Path: 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 CCA4411E8099 for ; Mon, 20 Aug 2012 13:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.485 X-Spam-Level: X-Spam-Status: No, score=-5.485 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 n92N5Yuu6ezM for ; Mon, 20 Aug 2012 13:11:45 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id AED6511E8098 for ; Mon, 20 Aug 2012 13:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1345493401; x=1660846899; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=/jL2OtnwqXlPbfF9ApcXO 6MPkMwZf2JWjT18gw5993U=; b=J4DXdtxWcLWAOW6xiHfBW2f5eJPapYJcA7yQT CCARifA7kcD/5WjQgL1iD7YxZsFJMAlWVAxrSlMtfP4Mi9RHA== Received: from ([10.31.13.228]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.8500825; Mon, 20 Aug 2012 16:10:00 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Mon, 20 Aug 2012 16:11:19 -0400 From: "Rosen, Brian" To: "Benjamin A. Rolfe" Date: Mon, 20 Aug 2012 16:11:18 -0400 Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac1/D/XidZwOFbRfQRWSWO4O3vXx1A== Message-ID: <0FCA100D-7C67-47F6-A0C2-03B27F60545E@neustar.biz> References: <50329616.3030207@blindcreek.com> In-Reply-To: <50329616.3030207@blindcreek.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: Vucca6RlSy/KuQVpp7cqhA== Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 20:11:47 -0000 PGFzIGluZGl2aWR1YWw+DQpJIHRoaW5rIHlvdSBnZXQgYSBzZXQgb2Ygc3RhcnQvc3RvcCB0aW1l cyBmb3IgYSBnaXZlbiBzcGVjdHJ1bSB1bml0LiAgVGhhdCdzIGFsbCB5b3UgbmVlZC4NCg0KVGhl cmUgaXMgYSB0cmFkZW9mZiBpbiB0aGUgY29tcGxleGl0eSBvZiBhIHNjaGVkdWxlIHJlY2VpdmVk IGFuZCBob3cgb2Z0ZW4geW91IGhhdmUgdG8gY29tZSBiYWNrIHRvIHRoZSBkYXRhYmFzZS4gIFRo ZSBVUyBydWxlcyBwcm92aWRlIG9uZSBzZXQgb2YgdHJhZGVvZmZzLiAgSXQncyBub3QgY2xlYXIg dG8gYmUgdGhleSBhcmUgZ3JlYXQsIGJ1dCB0aGV5IGFyZSB3aGF0IHRoZXkgYXJlLg0KDQpJbWFn aW5lIGEgZGV2aWNlIHN1cnJvdW5kZWQgYnkgbG90cyBvZiB0ZW1wb3JhcnkgdXNlIHdpcmVsZXNz IG1pY3JvcGhvbmVzLiAgVGhlIFUuUy4gcnVsZXMgbWF5IHJlc3VsdCBpbiBhIHJlc3BvbnNlIG9m IGRvemVucyBvZiBzY2hlZHVsZSBpdGVtcywgYXMgdGhlIHVzZSBjb21lcyBhbmQgZ29lcyBvbiBt dWx0aXBsZSBjaGFubmVscy4gIEl0IGNvdWxkIHRoZW9yZXRpY2FsbHkgYmUgaHVnZSAtIGh1bmRy ZWRzIGlmIG5vdCB0aG91c2FuZHMgb2Ygc2NoZWR1bGUgaXRlbXMuICBXaGlsZSBJIGRvdWJ0IHRo aXMgd291bGQgaGFwcGVuIHZlcnkgb2Z0ZW4sIEkgdGhpbmsgaXQgd2lsbCBiZSB2ZXJ5IGRpZmZp Y3VsdCB0byBwdXQgYW55IGtpbmQgb2YgdXBwZXIgYm91bmQgb24gdGhlIG51bWJlciBvZiBzY2hl ZHVsZSBpdGVtcyAoc3BlY3RydW0gdW5pdCwgc3RhcnQgYW5kIHN0b3AgdGltZXMpIGEgZGV2aWNl IG1heSBoYXZlIHRvIGNvbnRlbmQgd2l0aC4NCg0KVGhhdCBtYWtlcyBmb3IgYSBjb21wbGV4IGlt cGxlbWVudGF0aW9uLiAgV2UgYXJlIG5vIGRvdWJ0IHN0dWNrIHdpdGggaXQgaW4gdGVybXMgb2Yg d2hhdCB0aGUgcHJvdG9jb2wgbXVzdCBiZSBhYmxlIHRvIGRvLg0KDQpBIGJldHRlciBkZXNpZ24g d291bGQgbGltaXQgdGhlIG51bWJlciBvZiBzY2hlZHVsZSBpdGVtcyB0byBlaXRoZXIgYSBmaXhl ZCBsaW1pdCwgb3Igc29tZSBsaW1pdCBleHByZXNzZWQgYnkgdGhlIGNsaWVudC4gIFRoZSBjbGll bnQgd291bGQgdGhlbiBoYXZlIHRvIGdldCBiYWNrIHRvIHRoZSBkYXRhYmFzZSBzb29uZXIsIHRv IGdldCBtb3JlIHNjaGVkdWxlLg0KDQpJdCBtYXkgYmUgdGhhdCBjbGllbnRzIHByZWZlciB0byBk byB0aGF0ICh0aGF0IGlzLCBsaW1pdCBzY2hlZHVsZSBpbiBleGNoYW5nZSBmb3Igc2hvcnRlciB0 aW1lIHRvIHJlcXVlcnkpLiAgVGhhdCB3b3VsZCBub3QgdmlvbGF0ZSBydWxlcyBhcyBsb25nIGFz IHRoZSBkZXZpY2UgZGlkbid0IHVzZSBjaGFubmVscyBmb3Igd2hpY2ggaXQgZGlkIG5vdCBoYXZl IGFjY3VyYXRlIHNjaGVkdWxlLg0KDQpJIHRoaW5rIHRoZXJlIG1pZ2h0IGJlIGEgcmVxdWlyZW1l bnQgdGhlcmU6IHRoZSBhYmlsaXR5IHRvIGxpbWl0IHRoZSBudW1iZXIgb2Ygc2NoZWR1bGUgaXRl bXMgcmV0dXJuZWQsIGFzIHdlbGwgYXMgYSByZXF1aXJlbWVudCB0byByZXR1cm4gd2hlbiB0aGUg cmV0dXJuZWQgc2NoZWR1bGUgZW5kcyAoaS5lLiB3aGVuIHRoZSBkYXRhYmFzZSBtdXN0IGJlIHJl cXVpcmVkIHRvIGdldCBtb3JlIHNjaGVkdWxlKS4NCg0KQnJpYW4NCg0KT24gQXVnIDIwLCAyMDEy LCBhdCAzOjU1IFBNLCBCZW5qYW1pbiBBLiBSb2xmZSA8YmVuQGJsaW5kY3JlZWsuY29tPiB3cm90 ZToNCg0KPiBQZXRlciBtYWtlcyBhIGdvb2QgcG9pbnQuIFRoZSBydWxlcyB3aWxsIGFsbG93IGEg ZGV2aWNlIHRvIHVzZSBjaGFubmVsDQo+IGF2YWlsYWJpbGl0eSBkYXRhIGZvciBhcyBtdWNoIGFz IDQ4IGhvdXJzIC0gaXQgYWxsb3dzIHRoYXQgdGhlIGRldmljZQ0KPiBtdXN0IGFjY2VzcyB0aGUg ZGF0YWJhc2UgYXQgbGVhc3Qgb25jZSBwZXIgZGF5LCBidXQgaWYgaXQgdHJpZXMgYW5kDQo+IGZh aWxzIGl0IGNhbiB1c2UgdGhlIGRhdGEgdW50aWwgMTE6NTlwbSBvZiB0aGUgZm9sbG93IGRheS4N Cj4NCj4gVGhhdCB3YXNuJ3QgdGhlIDQ4IGhvdXJzIEkgd2FzIHRoaW5raW5nIGFib3V0IHRob3Vn aCwgSSB3YXMgdGhpbmtpbmcNCj4gYWJvdXQgdGhlIHBhcmFncmFwaCBiZWZvcmUgdGhhdDoNCj4g odcgMTUuNzExIChiKSgzKShpKQ0KPiAuLi4gRml4ZWQgVFZCRCBtdXN0IGFkanVzdCB0aGVpciB1 c2Ugb2YgY2hhbm5lbHMgaW4gYWNjb3JkYW5jZSB3aXRoDQo+IGNoYW5uZWwgYXZhaWxhYmlsaXR5 IHNjaGVkdWxlIGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHRoZWlyIGRhdGFiYXNlIGZvcg0KPiB0 aGUgNDgtaG91ciBwZXJpb2QgYmVnaW5uaW5nIGF0IHRoZSB0aW1lIG9mIHRoZSBkZXZpY2UgbGFz dCBhY2Nlc3NlZCB0aGUNCj4gZGF0YWJhc2UgZm9yIGEgbGlzdCBvZiBhdmFpbGFibGUgY2hhbm5l bHMuDQo+DQo+IFNvIGluIGFkZGl0aW9uIHRvIHByb3ZpZGluZyB3aGF0IGlzIGF2YWlsYWJsZSBu b3csIHBsdXMgaG93IHRoaW5ncyBhcmUNCj4gZXhwZWN0ZWQgdG8gY2hhbmdlIG92ZXIgdGhlIG5l eHQgNDggaG91ciBwZXJpb2QuIEkgc2hvdWxkbid0IGhhdmUgc2FpZA0KPiAiZ3Vlc3MiIHNpbmNl IHRoZSByZXF1aXJlbWVudHMgZm9yIG5vdGljZSBmcm9tIHRoZSBwcmlvcml0eSB1c2VycyBhcmUN Cj4gZ3JlYXRlciB0aGFuIDQ4IGhvdXJzLg0KPg0KPiBIYXZpbmcgbm93IGRpc2N1c3NlZCBpdCAi b3V0IGxvdWQiIHNvIHRvIHNwZWFrLCBpdCByZWFsbHkgZG9lcyBub3QgbmVlZA0KPiB0byBiZSB0 d28gZGlzdGluY3Qgbm90aW9ucy4gVGhlIFRoZSAic3RhcnQvZW5kIiBvbiBhIHBlciBjaGFubmVs IGJhc2lzDQo+IHByb3ZpZGVzIHdoYXQgeW91IG5lZWQ7IGFuZCB0aGUgZGF0YWJhc2UgaGFzIHRv IHByb3ZpZGUgYSBzY2hlZHVsZSBhdA0KPiB0aGUgdGltZSBvZiByZXF1ZXN0IHRoYXQgc2hvd3Mg ZXZlcnl0aGluZyBmcm9tIG5vdyB1bnRpbCBub3cgKyA0OCBob3Vycy4NCj4NCj4gSSBhbHNvIGFn cmVlIGVudGh1c2lhc3RpY2FsbHkgd2l0aCBQZXRlciB0aGF0IHdlIHNob3VsZCBleHBlY3QgY2hh bmdlcw0KPiBpbiB0aGUgcmVxdWlyZW1lbnRzIChhbmQgdGhhdCBpcyBhIGd1ZXNzLCBidXQgYW4g ZWR1Y2F0ZWQgb25lIDstKS4NCj4NCj4gQmVuDQo+DQo+PiBCZW4sDQo+PiBGQ0MgcnVsZXMgZG8g YXNzdW1lIHRoYXQgYSBjaGFubmVsIGFzc2lnbm1lbnQgaWYgZnJvbSBub3cgdW50aWwgc29tZSB0 aW1lDQo+PiBpbiB0aGUgZnV0dXJlLCB0aGUgY3VycmVudCBkZWZhdWx0IGlzIDI0IGhvdXJzIC0g dW5sZXNzIHRoZSBkZXZpY2UgbW92ZXMuDQo+PiBJdCBpcyBzYW1lIHRvIGFzc3VtZSB0aGF0IHRo ZSBkdXJhdGlvbiB3aWxsIGJlY29tZSBtdWNoIHNob3J0ZXINCj4+IGV2ZW50dWFsbHkuIFNvICJW YWxpZCB1bnRpbCIgaXMgYSByZWFzb25hYmxlIHByb3Bvc2l0aW9uLiAgSG93ZXZlciB0aGUgRkND DQo+PiBkb2VzIG5vdCBwcmVjbHVkZSBhIHJhZGlvIGZyb20gZ2V0dGluZyBhIGNoYW5uZWwgbGlz dCBpbiBhZHZhbmNlLiBJbiBtYW55DQo+PiB3YXlzIGl0IG1ha2VzIG1vcmUgc2Vuc2UgZm9yIGEg ZGV2aWNlIHRvIGFzayBmb3IgYSBuZXcgY2hhbm5lbCBsaXN0IGJlZm9yZQ0KPj4gaXQncyBjdXJy ZW50IGxpc3QgZXhwaXJlcyBzbyBzdGFydCB0aW1lIG1pZ2h0IGJlIHJlbGV2YW50IGluIHRoaXMg Y2FzZS4NCj4+DQo+PiBJIGRvbid0IHRoaW5rIHRoZSBGQ0Mgd2FzIHByb3Bvc2luZyBhICJwcmVk aWN0aXZlIGd1ZXNzIi4gVGhlIGFjdHVhbCBGQ0MNCj4+IHJ1bGUgaXMgdGhhdCBhIGNoYW5uZWwg bGlzdCBpcyB2YWxpZCBmb3IgMjRob3VycywgYnV0IGlmIGEgZGV2aWNlIGNhbm5vdA0KPj4gY29u dGFjdCBhIGRhdGFiYXNlIGF0IHRoYXQgdGltZSBpdCBoYXMgcGVybWlzc2lvbiB0byBrZWVwIHVz aW5nIHRoZQ0KPj4gY2hhbm5lbCBsaXN0IGZvciBhIGZ1cnRoZXIgMjRob3VycyAoNDhob3VycyB0 b3RhbCkgSSBkb24ndCB0aGluayB0aGlzIGlzIGENCj4+IGdvb2QgaWRlYSBhcyBpdCBwcmVjbHVk ZXMgYSBicm9hZGNhc3RlciByZXNlcnZpbmcgY2hhbm5lbHMgaW5zaWRlIHRoYXQNCj4+IHdpbmRv dywgYW5kLCBhcyBtZW50aW9uZWQgYWJvdmUgdGhlcmUgaXMgc29tZSBkaXNjdXNzaW9uIGFib3V0 IG1ha2luZyB0aGUNCj4+IHdpbmRvdyBtdWNoIHNob3J0ZXIgdG8gYWNjb21tb2RhdGUgc2l0dWF0 aW9ucyB3aGVyZSBicm9hZGNhc3RlcnMgY2Fubm90DQo+PiBwbGFuIDI0LCBvciB3b3JzdCBjYXNl IDQ4IGhvdXJzLCBpbiBhZHZhbmNlLiBQZXJzb25hbGx5IEkgcHJlZmVyIHRoYXQgdGhlDQo+PiBk ZXZpY2UgZ2V0IGEgY2hhbm5lbCBsaXN0IHRoYXQgaXMgZ29vZCBmb3Igc29tZSBwZXJpb2QsIHdp dGhvdXQgYW55IGlmcw0KPj4gYnV0cyBvciBtYXliZXMsIGFuZCB0aGVuIGl0IGhhcyB0byBxdWVy eSBhZ2Fpbi4gVGhpcyBpcyBtdWNoIHNpbXBsZXIgdGhhbg0KPj4gdHJ5aW5nIHRvIG1hcCBtYXRy aWNlcyBvZiBzdGFydC9zdG9wIHRpbWVzIGZvciB2YXJpb3VzIGNoYW5uZWxzIChtYXliZQ0KPj4g d2l0aCB2YXJpYWJsZSBwb3dlciBsaW1pdHMpIG92ZXIgYW4gZXh0ZW5kZWQgcGVyaW9kLg0KPj4g UGV0ZXIgUy4NCj4+DQo+PiBPbiBNb25BdWcvMjAvMTIgTW9uIEF1ZyAyMCwgMTE6MTUgQU0sICJC ZW5qYW1pbiBBLiBSb2xmZSINCj4+IDxiZW5AYmxpbmRjcmVlay5jb20+IHdyb3RlOg0KPj4NCj4+ PiBUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLg0KPj4+IFRoZXJlIGFyZSBhbHNvIHR3byBu b3Rpb25zIG9mIHdoYXQgInNjaGVkdWxlIiBtZWFucywgYXQgbGVhc3QgaW4gdGhlIEZDQw0KPj4+ IHJ1bGVzLiBUaGVyZSBpcyB0aGUgbm90aW9uIHRoYXQgdGhlIGN1cnJlbnQgY2hhbm5lbCBhdmFp bGFiaWxpdHkgZGF0YQ0KPj4+IGhhcyBhIGV4cGlyYXRpb24gdGltZSwgYW5kIHRodXMgdGhlcmUg aXMgYSB0aW1lIGluIHRoZSBmdXR1cmUgd2hlbg0KPj4+IHVwZGF0aW5nIHdpbGwgYmUgbmVjZXNz YXJ5LiBUaGlzIGlzIGF0IG1vc3QgYSBkYXkuIEJhc2VkIG9uIEZDQyBydWxlcywNCj4+PiB0aGlz IGNvdWxkIGJlIGEgbG9jYWwgdGltZSBkZXRlcm1pbmVkIGJ5IHRoZSBkZXZpY2UgdXNpbmcgdGhl IGNoYW5uZWwNCj4+PiBkYXRhLCBhbmQgaWYgdGhhdCBkZXZpY2UgaXMgYWN0aW5nIGFzIGEgc291 cmNlIGZvciBkZXBlbmRlbnQgZGV2aWNlDQo+Pj4gInVzaW5nIiBpbmNsdWRlcyBwcm92aWRpbmcg aXQgdG8gb3RoZXIgZGVwZW5kZW50IGRldmljZXMgKGFuZCBpdCB3b3VsZA0KPj4+IGhhdmUgdG8g cHJvdmlkZSB0aGUgInZhbGlkIHVudGlsIiB0aW1lKS4gSSBjYW4gaW1hZ2luZSB0aGF0IG90aGVy DQo+Pj4gcmVndWxhdG9yeSBib2RpZXMgKGFuZCBwZXJoYXBzIHRoZSBGQ0MgaW4gdGhlIGZ1dHVy ZSkgd2lsbCByZXF1aXJlIHRoYXQNCj4+PiBjaGFubmVsIGF2YWlsYWJpbGl0eSBkYXRhIHByb3Zp ZGVkIGJ5IHRoZSBkYXRhIGJhc2UgYWxzbyBiZSB0YWdnZWQgd2l0aA0KPj4+IHRoZSAidmFsaWQg dW50aWwiIGluZm9ybWF0aW9uLiBUaGlzIGRvZXMgbm90IHJlcXVpcmUgYSBzdGFydCB0aW1lLCBh cw0KPj4+ICJub3ciIGlzIGltcGxpZWQuDQo+Pj4NCj4+PiBUaGUgb3RoZXIgbm90aW9uIG9mIHNj aGVkdWxlIHRpbWUgaXMgdGhhdCB0aGUgZGF0YWJhc2UgY29udGFpbnMgYQ0KPj4+IHByZWRpY3Rp dmUgZ3Vlc3MgYXMgdG8gd2hhdCBjaGFubmVscyB3aWxsIGJlIGF2YWlsYWJsZSBmb3IgdGhlIG5l eHQgNDgNCj4+PiBob3VycyBpbnRvIHRoZSBmdXR1cmUuIFRoaXMgaXMgcmVxdWlyZWQgYnkgRkND ICh0aG91Z2ggdGhlIGRldmljZSBtdXN0DQo+Pj4gc3RpbGwgY2hlY2sgYXQgbGVhc3Qgb25jZSBh IGRheSBpZiB3aGF0IGl0IGlzIHVzaW5nIGlzIHN0aWxsIHZhbGlkKS4gQQ0KPj4+IHN0YXJ0L3N0 b3AgcGFpciBpcyByZXF1aXJlZCBmb3IgdGhpcy4NCj4+Pg0KPj4+IEkgdGhpbmsgZWl0aGVyIGZv cm1hdCBjYW4gYmUgdXNlZCB0byByZXByZXNlbnQgdGltZSBpbiBib3RoIGNhc2VzLiBJdCBpcw0K Pj4+IGFsc28gcG9zc2libGUgdGhhdCB0aGUgNDgtaG91ciBzY2hlZHVsZSBpcyBhbGwgdGhhdCBQ QVdTIG5lZWRzIHRvDQo+Pj4gcHJvdmlkZSB0byBtZWV0IHRoZSByZWd1bGF0aW9ucyBhbmQgdGhl ICJ2YWxpZCB1bnRpbCIgY2FuIGJlIGRlcml2ZWQNCj4+PiBmcm9tIHRoYXQgYnkgdGhlIHVzaW5n IGRldmljZS4NCj4+PiBIb3BlIHRoYXQgaGVscHMuDQo+Pj4gLUJlbg0KPj4+DQo+Pj4+IFVoLCB0 aGUgZGlmZmVyZW5jZSBpcyByZXByZXNlbnRhdGlvbiBvZiBzdGFydC9zdG9wIHRpbWVzLiAgV2Ug Ym90aA0KPj4+PiBwcm9wb3NlDQo+Pj4+IHRvIHNlbmQgc3RhcnQvc3RvcCB0aW1lcy4gIFZpbmNl bnQgcHJvcG9zZXMgdGhhdCB0aGUgcmVwcmVzZW50YXRpb24gb2YNCj4+Pj4gdGltZSBiZSBhIGxv bmcgaW50ZWdlciBzZWNvbmRzIHNpbmNlIGFuIGVwb2NoLiAgSGUgd291bGQgc2VuZCB0d28gc3Vj aA0KPj4+PiBsb25nIGludGVnZXJzLiAgSSBwcm9wb3NlIGl0IGJlIGFuIElTTyA4NjAxIHRpbWUg c3RyaW5nLiAgU3BlY2lmaWNhbGx5LA0KPj4+PiBJDQo+Pj4+IHdvdWxkIHByb3Bvc2UgYW4gSVNP IDg2MDEgaW50ZXJ2YWwgbGltaXRlZCB0byBzdGFydC9lbmQsIGUuZy4NCj4+Pj4gMjAxMS0wMy0w MVQxMzowMDowMFovMjAxMi0wNS0xMVQxNTozMDowMFouDQo+Pj4+DQo+Pj4+IE9uIDgvMTYvMTIg Njo0NSBQTSwgIkdhYm9yLkJhamtvQG5va2lhLmNvbSIgPEdhYm9yLkJhamtvQG5va2lhLmNvbT4N Cj4+Pj4gd3JvdGU6DQo+Pj4+DQo+Pj4+PiBJdCBzZWVtcyB3ZSBoYXZlIGFuIGFncmVlbWVudCBv biB0aGUgcmVxdWlyZW1lbnQgdG8gaWRlbnRpZnkgdGhlDQo+Pj4+PiBzcGVjdHJ1bSwgYnkgdXNp bmcgdGhlIHN0YXJ0L3N0b3AgZnJlcXVlbmNpZXMsIHdpdGggb3B0aW9uYWwgY2hhbm5lbA0KPj4+ Pj4gaWRlbnRpZmllcnMuDQo+Pj4+Pg0KPj4+Pj4gV3J0IHRvIHRoZSBzY2hlZHVsZSwgd2UgaGF2 ZSBzbyBmYXIgdHdvIHByb3Bvc2Fscywgb25lIGZyb20gQnJpYW4NCj4+Pj4+IHByb3Bvc2luZyB0 aGUgdXNlIG9mIHN0YXJ0L3N0b3AgdGltZXMgZm9yIGVhY2ggc3BlY3RydW0gdW5pdCBhdmFpbGFi bGUsDQo+Pj4+PiBhbmQgb25lIGZyb20gVmluY2VudCBwcm9wb3NpbmcgdG8gdXNlIG9mIFVuaXgg RXBvY2ggdGltZSBpbiBzZWNvbmRzLiBXZQ0KPj4+Pj4gbmVlZCB0byBkZWNpZGUgb24gdGhpcywg c28gcGxlYXNlIHNlbmQgeW91ciBwcmVmZXJlbmNlIG9uIHRoaXMgdG9waWMgdG8NCj4+Pj4+IHRo ZSBsaXN0Lg0KPj4+Pj4NCj4+Pj4+IC0gR2Fib3INCj4+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4+Pj4+IFByb2Jhc2NvIFNjb3R0 IChOb2tpYS1DSUMvRGFsbGFzKQ0KPj4+Pj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMTMsIDIwMTIg MTA6MTIgQU0NCj4+Pj4+IFRvOiBwYXdzQGlldGYub3JnDQo+Pj4+PiBTdWJqZWN0OiBSZTogW3Bh d3NdIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGRvY3VtZW50DQo+Pj4+Pg0KPj4+Pj4gSGkg QWxsLA0KPj4+Pj4NCj4+Pj4+IEdpdmVuIHRoYXQgd2UgaGF2ZSBjb21wbGV0ZWQgdHdvIFdvcmtp bmcgR3JvdXAgTGFzdCBDYWxsIGN5Y2xlcyBhbmQNCj4+Pj4+IHRoaXMNCj4+Pj4+IG5leHQgdmVy c2lvbiB3aWxsIGdvIHRvIHRoZSBJRVNHLCBJIGhvcGUgd2UgY291bGQgYWdyZWUgb24gbWluaW1h bA0KPj4+Pj4gY2hhbmdlcyB0byB0aGUgZG9jdW1lbnQsIGkuZS4gY2hhbmdlcyBvbmx5IHRvIEQu NyBmb3IgdGhpcyB0b3BpYy4gVGhpcw0KPj4+Pj4gd2lsbCBlbnN1cmUgdGhlIHByb3BlciByZXF1 aXJlbWVudHMgYXJlIGVzdGFibGlzaGVkIGZvciB0aGUgZGV2ZWxvcGluZw0KPj4+Pj4gUEFXUyBw cm90b2NvbC4NCj4+Pj4+IEkgYmVsaWV2ZSBCcmlhbidzIHByb3Bvc2VkIHRleHQgY2FwdHVyZXMg dGhlIGVzc2VudGlhbCByZXF1aXJlbWVudHMuDQo+Pj4+Pg0KPj4+Pj4gS2luZCBSZWdhcmRzLA0K Pj4+Pj4gU2NvdHQNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gT24gOC8xMy8xMiA4OjI0IEFNLCAiZXh0 IFJvc2VuLCBCcmlhbiIgPEJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PiB3cm90ZToNCj4+Pj4+DQo+ Pj4+Pj4gPGFzIGluZGl2aWR1YWw+DQo+Pj4+Pj4gSSB3b3VsZCBwcmVmZXIgdG8gbm90IHVzZSB0 aGUgd29yZCAiY2hhbm5lbCIgaW4gb3VyIGRvY3VtZW50cyBhdCBhbGwNCj4+Pj4+PiBleGNlcHQg Zm9yIHRoZSB0ZXJtICJjaGFubmVsIGlkZW50aWZpZXIiLiAgSSBwcm9wb3NlZCAic3BlY3RydW0g dW5pdCIsDQo+Pj4+Pj4gYWx0aG91Z2ggYW55IG90aGVyIHRlcm0gd2lsbCBkby4gICJDaGFubmVs IiBoYXMgdG9vIG11Y2ggYmFnZ2FnZSwgIEENCj4+Pj4+PiBzaW1wbGUgZWRpdG9yaWFsIGNoYW5n ZSBsaWtlIHRoaXMgaXMgc2ltcGxlLCBhbmQgaXQncyBtdWNoIGJldHRlciB0bw0KPj4+Pj4+IGRv DQo+Pj4+Pj4gaXQgbm93Lg0KPj4+Pj4+DQo+Pj4+Pj4gSSB0aGluayB3ZSBuZWVkIHBvd2VyIGlu IGJvdGggdGhlIHF1ZXJ5IGFuZCB0aGUgcmVzcG9uc2UuICBJbiBzb21lDQo+Pj4+Pj4gZG9tYWlu cywgaXQgbWF5IGJlIHRoYXQgeW91IHNwZWNpZnkgd2hhdCBwb3dlciB5b3Ugd2FudCB0byB1c2Ug YW5kIHRoZQ0KPj4+Pj4+IERCIHRlbGxzIHlvdSB3aGF0IHNwZWN0cnVtIHlvdSBjYW4gdXNlIGF0 IHRoYXQgcG93ZXIuICBJbiBvdGhlciwgYQ0KPj4+Pj4+IFVTLWxpa2UgcnVsZSBtYXkgYmUgaW4g cGxhY2UuICBBbHNvIGluIGVpdGhlciB0aGUgcXVlcnkgb3IgdGhlDQo+Pj4+Pj4gcmVnaXN0cmF0 aW9uLCB3ZSBuZWVkIGEgZGV2aWNlIHR5cGUsIHdoaWNoIHNob3VsZCBiZSBhbiBlbnRyeSBmcm9t IGFuDQo+Pj4+Pj4gSUFOQSByZWdpc3RyeS4gIFRoaXMgaXMgaG93IHlvdSBnZXQgdGhlIFVTICJN b2RlIElJIiBpbmZvcm1hdGlvbi4NCj4+Pj4+Pg0KPj4+Pj4+IFdpdGggcmVnYXJkIHRvIHNjaGVk dWxlLCBJIHdvdWxkIGxpa2UgdG8gc2VlIHR3byBtZWNoYW5pc21zDQo+Pj4+Pj4gMSkgYSB0aW1l IGJ5IHdoaWNoIHRoZSBkYXRhYmFzZSBzaG91bGQgYmUgcXVlcmllZCBhZ2FpbiAod2hpY2ggY291 bGQNCj4+Pj4+PiByZXByZXNlbnQgdGhlIG5leHQgY2hhbmdlIGluIHNjaGVkdWxlKQ0KPj4+Pj4+ IDIpIHN0YXJ0L3N0b3AgdGltZXMgZm9yIGVhY2ggc3BlY3RydW0gdW5pdCBhdmFpbGFibGUNCj4+ Pj4+Pg0KPj4+Pj4+IEJvdGggdGhlc2Ugc2hvdWxkIGJlIG9wdGlvbmFsIGluIHRoZSByZXNwb25z ZS4NCj4+Pj4+Pg0KPj4+Pj4+IE15IHRleHQNCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBkYXRhIG1vZGVs IG11c3Qgc3VwcG9ydCBzcGVjaWZ5aW5nIHNwZWN0cnVtIGF2YWlsYWJpbGl0eS4NCj4+Pj4+PiBT cGVjdHJ1bQ0KPj4+Pj4+IHVuaXRzIGFyZSBzcGVjaWZpZWQgYnkgbG93IGFuZCBoaWdoIGZyZXF1 ZW5jaWVzIGFuZCBtYXkgaGF2ZSBhbg0KPj4+Pj4+IG9wdGlvbmFsIGNoYW5uZWwgaWRlbnRpZmll ci4NCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBkYXRhIG1vZGVsIG11c3Qgc3VwcG9ydCBhIHNjaGVkdWxl IGZvciBzcGVjdHJ1bSB1bml0IGF2YWlsYWJpbGl0eS4NCj4+Pj4+PiBUd28gbWVjaGFuaXNtcyBt dXN0IGJlIHN1cHBvcnRlZC4gIFRoZSByZXNwb25zZSB0byBzcGVjdHJ1bQ0KPj4+Pj4+IGF2YWls YWJpbGl0eSBxdWVyeSBtYXkgaW5jbHVkZSBhIHRpbWUgYnkgd2hpY2ggdGhlIGRhdGFiYXNlIG11 c3QgYmUNCj4+Pj4+PiByZXF1ZXJpZWQuICBFYWNoIHNwZWN0cnVtIHVuaXQgbWVudGlvbmVkIGlu IHRoZSByZXNwb25zZSBtYXkgYmUNCj4+Pj4+PiBhbm5vdGF0ZWQgd2l0aCBzdGFydCBhbmQgc3Rv cCB0aW1lL2RhdGUuDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+Pj4+PiBGcm9tOiAgICAgRXJpYyBDaHUgW21haWx0bzplcmljY2h1 QGdvb2dsZS5jb21dDQo+Pj4+Pj4gU2VudDogICAgU2F0dXJkYXksIEF1Z3VzdCAxMSwgMjAxMiAx MTo0MyBBTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNCj4+Pj4+PiBUbzogICAgVGVjbyBCb290DQo+ Pj4+Pj4gQ2M6ICAgIFJvc2VuLCBCcmlhbjsgcGF3c0BpZXRmLm9yZw0KPj4+Pj4+IFN1YmplY3Q6 ICAgIFJlOiBbcGF3c10gdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgZG9jdW1lbnQNCj4+Pj4+ Pg0KPj4+Pj4+DQo+Pj4+Pj4gSGkgZXZlcnlvbmUsDQo+Pj4+Pj4NCj4+Pj4+PiBHYXRoZXJpbmcg YWxsIHRoZSBzaGFyZWQgcG9pbnRzIGZyb20gZXZlcnlvbmUuLi4gSSBiZWxpZXZlIGJlbG93IGlz DQo+Pj4+Pj4gdGhlDQo+Pj4+Pj4gY29tcGxldGUgbGlzdCBzbyBmYXI6DQo+Pj4+Pj4NCj4+Pj4+ Pg0KPj4+Pj4+DQo+Pj4+Pj4gKiAgICBXaGF0J3MgdGhlIGJlc3QgY29uc2lzdGVudCByZXByZXNl bnRhdGlvbiBvZiB0aGUgd29yZHMgImNoYW5uZWwNCj4+Pj4+PiBudW1iZXJzIiBmb3Igbm9uLVRW IHNwZWN0cnVtDQo+Pj4+Pj4gKiAgICBTaG91bGQgd2UgdXBkYXRlIHRoZSBlbnRpcmUgZG9jIG9u IHRoZSB0b3BpYyBvZiCp+GNoYW5uZWyp9yBvcg0KPj4+Pj4+IKn4Y2hhbm5lbCBudW1iZXJzqfcN Cj4+Pj4+PiAqICAgIFdoYXSp9nMgdGhlIGJlc3Qgd2F5IHRvIHJlZHVjZSB2YWd1ZW5lc3MgaW4g d2hldGhlci9ob3cgdG8gaW5jbHVkZQ0KPj4+Pj4+ICJjaGFubmVsIG51bWJlcnMiDQo+Pj4+Pj4g KiAgICBJcyB0aGUgcmVmZXJlbmNlIHRvIHZhcmlhYmxlIHBvd2VyIHJlcXVpcmVkDQo+Pj4+Pj4g KiAgICBXaGF0IGRvZXMgY2hhbm5lbCBhdmFpbGFiaWxpdHkgc2NoZWR1bGUgbWVhbg0KPj4+Pj4+ DQo+Pj4+Pj4NCj4+Pj4+PiBCcmlhbidzIHN1Z2dlc3Rpb24gb2YgcmVwbGFjaW5nIGV2ZXJ5IGlu c3RhbmNlIG9mICJjaGFubmVsIiBpcw0KPj4+Pj4+IHRlY2huaWNhbGx5IGNvcnJlY3RseS4gSG93 ZXZlciwgaXQgaXMgaW1wb3J0YW50IGZvciB1cyB0byBmb2N1cyBtb3ZpbmcNCj4+Pj4+PiBmb3J3 YXJkLiAgSSB3b3VsZCBzdWdnZXN0IHdlIG9ubHkgd29yayBvbiB0aGUgbm9ybWF0aXZlIHBhcnQg b2YgdGhlDQo+Pj4+Pj4gc3BlYy4NCj4+Pj4+PiBUaGUgc2VjdGlvbiBHYWJvciBpcyBwcm9wb3Np bmcgZm9yIHVzIHRvIG1vZGlmeS4uLg0KPj4+Pj4+DQo+Pj4+Pj4gT24gd2hhdCdzIHRoZSBiZXN0 IGdlbmVyaWMgbGFiZWwgZm9yIHRoZSB3b3JkcyAiY2hhbm5lbCBudW1iZXJzIiwNCj4+Pj4+PiBj aGFubmVsIGlkZW50aWZpZXIgbWlnaHQgYmUgdGhlIG1vc3QgYWNjdXJhdGUgYW5kIG5ldXRyYWwg ImxhYmVsIi4NCj4+Pj4+PiBUaG91Z2h0cz8NCj4+Pj4+Pg0KPj4+Pj4+IE9uIHRoZSBxdWVzdGlv biB3aGV0aGVyIHZhcmlhYmxlIHBvd2VyIGlzIHJlcXVpcmVkLCBiYXNlZCBvbiBGQ0MNCj4+Pj4+ PiBhZGphY2VudC1jaGFubmVsIHJ1bGVzLCB0aGUgZGF0YWJhc2UgbWF5IGxpbWl0IHRoZSBNb2Rl IElJIGRldmljZXMgdG8NCj4+Pj4+PiAxMDBtVyBmb3Igc29tZSBjaGFubmVscyBhbmQgNDBtVyBm b3Igb3RoZXJzLiBUaGVyZWZvcmUsIHRoZSBkYXRhIG1vZGVsDQo+Pj4+Pj4gbmVlZHMgdG8gc3Vw cG9ydCBzcGVjaWZpY2F0aW9uIG9mIG1heGltdW0gcG93ZXIgbGV2ZWxzLg0KPj4+Pj4+DQo+Pj4+ Pj4gTGFzdGx5LCB3aXRoIHJlZ2FyZHMgdG8gInNjaGVkdWxlIiwgdGhlIGludGVudCBpcyB0byBo YXZlIGEgd2F5IG9mDQo+Pj4+Pj4gaW5mb3JtaW5nIGRldmljZXMgd2hlbiB0byBvcGVyYXRlIGZv ciBlYWNoIGZyZXF1ZW5jeSByYW5nZS4gQXMgbG9uZyBhcw0KPj4+Pj4+IHRoZSBkYXRhIG1vZGVs IHN1cHBvcnRzLCBmb3IgZXhhbXBsZSwgYSBsaXN0IG9mIHRpbWUgcmFuZ2VzLCBpdCBkb2VzDQo+ Pj4+Pj4gbm90IHByZXZlbnQgYW4gaW1wbGVtZW50YXRpb24gZnJvbSBwcm92aWRpbmcgYSBsaXN0 IHdpdGggMSBlbnRyeSB3aGljaA0KPj4+Pj4+IGNvcnJlc3BvbmRzIHRvIHRoZSAic2hvcnRlc3Qg YXZhaWxhYmxlIi4gIFRoZSB3b3JkICJzY2hlZHVsZSIgc2hvdWxkDQo+Pj4+Pj4gYmUNCj4+Pj4+ PiBzdWZmaWNpZW50IHRvIGNhcHR1cmUgdGhpcyBpbnRlbnQ/DQo+Pj4+Pj4NCj4+Pj4+PiBXZSB3 b3VsZCBsaWtlIHRvIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIGFkZHJlc3MgdGhlc2Ug cG9pbnRzOg0KPj4+Pj4+DQo+Pj4+Pj4gIlRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVj aWZ5aW5nIGF2YWlsYWJsZSBzcGVjdHJ1bS4gVGhlIERhdGENCj4+Pj4+PiBNb2RlbCBNVVNUIHN1 cHBvcnQgc3BlY2lmaWNhdGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IHN0YXJ0IGFuZCBzdG9w DQo+Pj4+Pj4gZnJlcXVlbmNpZXMgYW5kIE1BWSBhbHNvIHN1cHBvcnQgc3BlY2lmaWNhdGlvbiBv ZiB0aGlzIGluZm9ybWF0aW9uIGJ5DQo+Pj4+Pj4gY2hhbm5lbCBpZGVudGlmaWVycy4gVGhlIERh dGEgTW9kZWwgTVVTVCBzdXBwb3J0IGENCj4+Pj4+PiBzcGVjdHJ1bS1hdmFpbGFiaWxpdHkgc2No ZWR1bGUgYW5kIG1heGltdW0gcG93ZXIgbGV2ZWxzIGZvciBlYWNoDQo+Pj4+Pj4gZnJlcXVlbmN5 IHJhbmdlLiINCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gVGhvdWdodHM/DQo+Pj4+Pj4gRXJpYw0K Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IE9uIDgvMTAvMTIgNTo0OCBBTSwgVGVjbyBC b290IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiAgIFdoYXQgYWJvdXQgdGhpczoNCj4+ Pj4+Pg0KPj4+Pj4+ICAgICAgIKn4VGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlp bmcgYSBsaXN0IG9mIGF2YWlsYWJsZQ0KPj4+Pj4+IGNoYW5uZWxzLiBUaGUgRGF0YSBNb2RlbCBN VVNUIHN1cHBvcnQgc3BlY2lmaWNhdGlvbiBvZiB0aGlzDQo+Pj4+Pj4gaW5mb3JtYXRpb24NCj4+ Pj4+PiBieSBzdGFydCBhbmQgc3RvcCBmcmVxdWVuY2llcywgb3IgZXF1aXZhbGVudHMgc3VjaCBh cyBjZW50ZXINCj4+Pj4+PiBmcmVxdWVuY2llcyB3aXRoIGNoYW5uZWwgd2lkdGggb3IgY2hhbm5l bCBudW1iZXJzIHdpdGggY2hhbm5lbCBudW1tZXINCj4+Pj4+PiBhbGxvY2F0aW9uIHNjaGVtZSAu IFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBhIGNoYW5uZWwgYXZhaWxhYmlsaXR5DQo+Pj4+ Pj4gc2NoZWR1bGUgYW5kIG1heGltdW0gcG93ZXIgbGV2ZWwgZm9yIGVhY2ggY2hhbm5lbCBpbiB0 aGUgbGlzdC6p9w0KPj4+Pj4+DQo+Pj4+Pj4gICBNb3JlIHRob3VnaHRzIG9uIGNoYW5uZWwgbnVt YmVyczogd2UgbGlrZWx5IHJ1biBpbnRvIHByb2JsZW1zIGluDQo+Pj4+Pj4gYmFuZHMgd2l0aG91 dCBhIGNoYW5uZWwgbnVtYmVyaW5nIHNjaGVtZSwgb3IgZm9yIGV4YW1wbGUgc3ViIGNoYW5uZWxz DQo+Pj4+Pj4gaW4gVFYgYmFuZHMuDQo+Pj4+Pj4NCj4+Pj4+PiAgIFRlY28NCj4+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+Pj4gICBPcCAxMCBhdWcuIDIwMTIsIG9tIDEzOjU3IGhlZWZ0IFJvc2VuLCBCcmlh biBoZXQgdm9sZ2VuZGUNCj4+Pj4+PiBnZXNjaHJldmVuOg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+ PiAgICAgICA8YXMgaW5kaXZpZHVhbD4NCj4+Pj4+PiAgICAgICBXaGlsZSBJIGRvbid0IGNhcmUg aWYgaXQncyBjZW50ZXIgYW5kIHdpZHRoIG9yIHVwcGVyL2xvd2VyLCBJDQo+Pj4+Pj4gZG8gdGhp bmsgd2Ugd2lsbCBkZWZpbmUgdGhlIGZvcm1hdCBpbiB0aGUgcHJvdG9jb2wgZm9yDQo+Pj4+Pj4g aW50ZXJvcGVyYWJpbGl0eQ0KPj4+Pj4+IHJlYXNvbnMsIGJ1dCBkb24ndCBuZWVkIHRvIGRvIHRo YXQgaW4gcmVxdWlyZW1lbnRzLiAgSXQgd291bGRuJ3QgaHVydA0KPj4+Pj4+IHRvIGRlY2lkZSBu b3cgYW5kIHVzZSBjb25zaXN0ZW50IHRlcm1zLCBidXQgd2UgZG9uJ3QgbmVlZCB0by4NCj4+Pj4+ Pg0KPj4+Pj4+ICAgICAgIEkgdGhpbmsgImJhbmQiIHdvbid0IHdvcmssIGFzIGl0IHVzdWFsbHkg aW1wbGllcyBhIG11Y2ggd2lkZXINCj4+Pj4+PiBwaWVjZSBvZiBzcGVjdHJ1bSB0aGF0IGhhcyBh IGNvbW1vbiBwdXJwb3NlLiAgVGhlIFRWIEJhbmQgaXMgYWxsIHRoZQ0KPj4+Pj4+IGNoYW5uZWxz Lg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiAgICAgICBPbiBBdWcgMTAsIDIwMTIsIGF0IDI6Mzcg QU0sIFRlY28gQm9vdCA8dGVjb0BpbmYtbmV0Lm5sPiB3cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+DQo+ Pj4+Pj4gICAgICAgICAgIChzb21ld2hhdCBsYXRlIHJlc3BvbnNlKQ0KPj4+Pj4+DQo+Pj4+Pj4g ICAgICAgICAgIEEgY2VudGVyIGZyZXF1ZW5jeSBhbmQgY2hhbm5lbCB3aWR0aCBpcyBmdW5jdGlv bmFsDQo+Pj4+Pj4gZXF1aXZhbGVudCB0byBzdGFydC9zdG9wIGZyZXF1ZW5jaWVzLiBTbyBpcyBj aGFubmVsIG51bWJlciwgd2l0aCByZWYNCj4+Pj4+PiB0bw0KPj4+Pj4+IGNoYW5uZWwgbnVtYmVy IGFzc2lnbm1lbnQgc2NoZW1lLiBGb3IgYSByZXF1aXJlbWVudHMgZG9jdW1lbnQsIHdlIGp1c3QN Cj4+Pj4+PiBuZWVkIHRvIHNwZWNpZnkgd2hhdCBpcyBuZWVkZWQuIEhvdyBpdCBpcyBlbmNvZGVk IChIeiwgd2F2ZSBsZW5ndGgsDQo+Pj4+Pj4gY2hhbm5lbCBJRCkgaXMgc29sdXRpb24gc3BhY2Uu DQo+Pj4+Pj4NCj4+Pj4+PiAgICAgICAgICAgU2VlbiBvdXIgZ29hbCB0byBtYWtlIFBBV1Mgc29t ZXdoYXQgdW5pdmVyc2FsIChub3QgbGltaXRlZA0KPj4+Pj4+IHRvIFVTIFRWV1MpLCBJIGRvIG5v dCBwcmVmZXIgdXNpbmcgY2hhbm5lbCBudW1iZXJzLg0KPj4+Pj4+DQo+Pj4+Pj4gICAgICAgICAg IFRlY28NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gICAgICAgICAgIE9wIDkgYXVnLiAyMDEyLCBv bSAyMTo1NSBoZWVmdCA8R2Fib3IuQmFqa29Abm9raWEuY29tPg0KPj4+Pj4+IDxHYWJvci5CYWpr b0Bub2tpYS5jb20+IGhldCB2b2xnZW5kZSBnZXNjaHJldmVuOg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGb2xrcywNCj4+Pj4+Pg0KPj4+Pj4+ ICAgICAgICAgICAgICAgRHVyaW5nIHRoZSBsYXN0IEYyRiBtZWV0aW5nLCB0aGVyZSB3YXMgYW4g YWdyZWVtZW50IHRvDQo+Pj4+Pj4gbWFrZSBhIHNsaWdodCB1cGRhdGUgdG8gcmVxdWlyZW1lbnQg RC43IGluDQo+Pj4+Pj4NCj4+Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYt cGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdHMtMDYudA0KPj4+Pj4+IHh0LCAgdG8gbWFr ZSBjaGFubmVsIG51bWJlcnMgb3B0aW9uYWwgdG8gYmUgc3VwcG9ydGVkLiBJZSwgY2hhbmdlIHRo ZQ0KPj4+Pj4+IGN1cnJlbnQNCj4+Pj4+PiBELjcNCj4+Pj4+PiAgICAgICAgICAgICAgIKn4VGhl IERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgYSBsaXN0IG9mDQo+Pj4+Pj4gYXZh aWxhYmxlIGNoYW5uZWxzLiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmaWNhdGlv biBvZiB0aGlzDQo+Pj4+Pj4gaW5mb3JtYXRpb24gYnkgY2hhbm5lbCBudW1iZXJzIGFuZCBieSBz dGFydCBhbmQgc3RvcCBmcmVxdWVuY2llcy4gVGhlDQo+Pj4+Pj4gRGF0YSBNb2RlbCBNVVNUIHN1 cHBvcnQgYSBjaGFubmVsIGF2YWlsYWJpbGl0eSBzY2hlZHVsZSBhbmQgbWF4aW11bQ0KPj4+Pj4+ IHBvd2VyIGxldmVsIGZvciBlYWNoIGNoYW5uZWwgaW4gdGhlIGxpc3QuqfcNCj4+Pj4+PiAgICAg ICAgICAgICAgIHRvDQo+Pj4+Pj4gICAgICAgICAgICAgICCp+FRoZSBEYXRhIE1vZGVsIE1VU1Qg c3VwcG9ydCBzcGVjaWZ5aW5nIGEgbGlzdCBvZg0KPj4+Pj4+IGF2YWlsYWJsZSBjaGFubmVscy4g VGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZmljYXRpb24gb2YgdGhpcw0KPj4+Pj4+ IGluZm9ybWF0aW9uIGJ5IHN0YXJ0IGFuZCBzdG9wIGZyZXF1ZW5jaWVzIGFuZCBNQVkgaW5jbHVk ZSBjaGFubmVsDQo+Pj4+Pj4gbnVtYmVycy4gVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IGEg Y2hhbm5lbCBhdmFpbGFiaWxpdHkgc2NoZWR1bGUNCj4+Pj4+PiBhbmQgbWF4aW11bSBwb3dlciBs ZXZlbCBmb3IgZWFjaCBjaGFubmVsIGluIHRoZSBsaXN0Lqn3DQo+Pj4+Pj4NCj4+Pj4+PiAgICAg ICAgICAgICAgIEmp9mQgbGlrZSB0byBjb25maXJtIHRoaXMgY2hhbmdlIG9uIHRoZSBsaXN0LiBJ ZiBhbnlvbmUNCj4+Pj4+PiBoYXMgYW55IG9iamVjdGlvbnMsIGxldCBtZSBrbm93LiBPdGhlcndp c2UgSan2bGwgcGxhbiB0byBzZW5kIHRoZQ0KPj4+Pj4+IGRvY3VtZW50IHRvIHRoZSBpZXNnIGFm dGVyIHRoaXMgY2hhbmdlIGlzIGltcGxlbWVudGVkLg0KPj4+Pj4+DQo+Pj4+Pj4gICAgICAgICAg ICAgICAtICAgICAgICAgIEdhYm9yDQo+Pj4+Pj4gICAgICAgICAgICAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+ICAgICAgICAgICAgICAg cGF3cyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiAgICAgICAgICAgICAgIHBhd3NAaWV0Zi5vcmcNCj4+ Pj4+PiAgICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGF3cw0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgICAgICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+ICAgICAgICAgICBw YXdzIG1haWxpbmcgbGlzdA0KPj4+Pj4+ICAgICAgICAgICBwYXdzQGlldGYub3JnDQo+Pj4+Pj4g ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4+ Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+ Pj4gICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4+ICAgcGF3cyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiAgIHBhd3NAaWV0Zi5vcmcNCj4+Pj4+PiAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4+Pj4+DQo+Pj4+ Pj4NCj4+Pj4+Pg0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+Pj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBwYXdzQGlldGYub3Jn DQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4g cGF3cyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHBhd3NAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+ Pj4+PiBwYXdzQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Bhd3MNCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+Pj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHBhd3MgbWFpbGlu ZyBsaXN0DQo+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGF3cw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBwYXdzIG1haWxpbmcgbGlzdA0KPiBwYXdzQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQo= From d.joslyn@spectrumbridge.com Mon Aug 20 13:54:30 2012 Return-Path: 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 EB2F921F8629 for ; Mon, 20 Aug 2012 13:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] 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 MCP4T0LRYroh for ; Mon, 20 Aug 2012 13:54:25 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id B477221F85A8 for ; Mon, 20 Aug 2012 13:54:24 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 20 Aug 2012 16:54:21 -0400 From: Don Joslyn To: Vincent Chen , Weixinpeng Date: Mon, 20 Aug 2012 16:54:21 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac1/BYH2SZp+fj3yRoicZSZO3h1fTAAAY59w Message-ID: <8375F6DAEFB09F48815203F1FE23B797117AA6D8CF@shelby> References: <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B797117AA6D8CFshelby_" MIME-Version: 1.0 Cc: "paws@ietf.org" , Manikkoth Sajeev 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 20:54:31 -0000 --_000_8375F6DAEFB09F48815203F1FE23B797117AA6D8CFshelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see my comments below... Thanks, Don From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vin= cent Chen Sent: Monday, August 20, 2012 2:56 PM To: Weixinpeng Cc: 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 dev= ice 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 wo= rk" 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 (clie= nt-side) prefer it for its simplicity: * Representation closely matches most data models (nested lists and m= aps) * Simple-to-use libraries exist for all major languages/platforms * Don't need a tool chain to work with the data, as is typically need= ed 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 Goog= le 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 mor= e efficient, can't argue with that.] * At the end of the day, it's the data model that matters, rather than t= he 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 suppo= rting 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 device= s) 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 muc= h or exchanged that often.] On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > 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-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; gabor.bajko@nokia.com; = vchen@google.com; peter@spectrumbridge.com Cc: 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 desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml option can also wor= k. JSON I think will necessitate implementation to be native Java and may n= ot be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_8375F6DAEFB09F48815203F1FE23B797117AA6D8CFshelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please se= e my comments below…

Thanks,

Don

 

<= p class=3DMsoNormal>From: 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; Manikkoth Saj= eev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal<= o:p>

 

  • One of= our goals is to strive to lower the cost and complexity for device manufac= turers. This lowers the barrier for building a robust ecosystem.=

[DJ - T= he “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 b= etter define “cost”?]

  • To reduce complexity and cost for device makers, supporting = 1 encoding is better than both, as Brian points out. WiFi access points tha= t "just work" anywhere in the world serves as a good model.<= /o:p>

[D= J - I proposed that the databases support both XML and JSON, devices only n= eed to support one to talk to the database. Our current database supports X= ML 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 devic= es.]

  • There's a tren= d 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 exis= t for all major languages/platforms
    • Don't need a tool chain to work w= ith the data, as is typically needed for XML.

    Apparently, the efficiency gains o= f JSON also matter to the scalability of serving systems.

     

    [DJ – I can̵= 7;t argue against these listed pros for JSON, especially when you’re = dealing with a lot of data (like Twitter, FourSquare, Facebook and Google d= oes). But I’m assuming that PAWS messages will not be exchanged nearl= y as often as the applications mentioned above. But again, I know JSON is m= ore efficient, can’t argue with that.]

    • At the e= nd 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 maker= s (especially of embedded devices) regarding experiences supporting XML vs = JSON.

     

    Don, can you elaborate on the types of device= s that already support XML?

     

    [DJ - W= e currently support half a dozen TVDB radio vendors (embedded devices) usin= g XML, non using JSON. XML has not been a burden, and the amount of data th= at needs to be exchanged between device and database is not that much or ex= changed that often.]

    On Fri,= Aug 17, 2012 at 6:06 PM, Weixinpeng <weixinpeng@huawei.com> wrote:

    Considering of the design of database discovery pr= otocol, the LoST protocol may be used and LoST is based on XML, so I think = XML may be preferred.

     =

    --Xinpeng Wei

    &n= bsp;

    From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org<= /a>] On Behalf Of Rosen, Brian

     

    <= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"'>I don't = really care whether we use json or xml as a matter of protocol design or im= plementation, 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 decid= e to roll our own versus using existing standards based on the idea there i= s no json representation of an existing standard.  So, if choosing jso= n means folks feel free to ignore existing xml based standards such as xCar= d and LoST, then I would not want to use json.

    <= div>

     

    I would prefer to not have "= ;both", because of interoperability complications.  If there is r= ough consensus for both, then I would assert that all servers have to imple= ment both and the client can implement either.

    <= div>

     

    There are json validators, so I = don't think that is a big deal.  

    &nbs= p;

    My experience in protocol design on the = Internet is that decisions made solely or even largely because of compactne= ss 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 war= s in protocol design.  Text wins, binary loses, in my opinion.<= o:p>

     

    Brian <a= s individual>

     

    From: Manikkoth Sajeev <mksaji@yahoo.com>
    Reply-To: = Manikkoth Sajeev <= mksaji@yahoo.com>
    Date: Thu, 16 Aug 2012 22:37:38 -0400To: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>, "Rosen, Brian&quo= t; <brian.r= osen@neustar.biz>, "vchen@google.com" <vchen@google.com>, "peter@spectrumbridge.com"= <peter@sp= ectrumbridge.com>
    Cc: "paws@ietf.org" <paws@ietf.org>
    Subject: Re: [paws= ] XML schema versus JSON, vCard & iCal

    =

    =  

    Hi,

     

    Can it not be both JSON and XML suppor= ted? I would vote for that. Future implementations may prefer XML a= s it is generic, omni present, easy to understand and validate. For compactness may be a  binary xml option can al= so work. JSON I think will necessitate implementation to be native Java and= may not be as friendly with other implementation languages.

    =

     

    Best Regards,

     

    =

    From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
    To:     Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com
    Cc: paws@ietf.org
    Sent:<= /b> Friday, 17 August 2012, 4:55
    Subject: Re: [paws] XML schema v= ersus JSON, vCard & iCal

    <= br>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] On Be= half Of ext Rosen, Brian
    Sent: Monday, August 13, 2012 3:14 PM
    To: 'V= incent Chen'; 'Peter Stanforth'
    Cc: 'paws@ietf.org'
    Subject: Re: [paws] XML schema versus= JSON, vCard & iCal

    json is okay with me. 
    I'd prefer a= n 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>



    -----Origi= nal Message-----
    From:     Vincent Chen [mailto:vchen@google.com]
    Sen= t:    Monday, August 13, 2012 06:04 PM Eastern Standard Time=
    To:    Peter Stanforth
    Cc:    Rosen, B= rian; Teco Boot; Benjamin A.Rolfe; 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, sy= nthesis). 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 num= erous languages (see of http= ://json.org/) and seem to be reasonably light weight.

    Timestamps=

    As for timestamp specifications, should we consider just using seco= nds since the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the n= eed for datetime-string parsing on devices, assuming devices already have n= ative libraries that provide time in this format. Is that a valid assumptio= n? Of course, this is less human-readable....


    On Mon, Aug 13, 20= 12 at 6:49 AM, Peter Stanforth <peter@spectrumbridge.com> wrote:


    &n= bsp;   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.
    &= nbsp;  
        On MonAug/13/12 Mon Aug 13, 9:30 A= M, "Rosen, Brian"
       
        &l= t;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
        >b= eing 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]
        >Sent:  S= aturday, August 11, 2012 07:13 AM Eastern Standard Time
      &nbs= p; >To:    Teco Boot; Benjamin A.Rolfe
        &= gt;Cc:    paws= @ietf.org
        >Subject:      Re: [p= aws] 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 OT= A
        >We should not assume that all Masters are attac= hed to utility power so we
        >should be sympathetic = to processing energy use also.
        >
      &n= bsp; >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <teco@inf-net.nl> w= rote:
        >
        >>
     &n= bsp;  >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe het vo= lgende
        >>geschreven:
        >= >
        >>> Compactness of messages is importan= t, but it is also important (to me
        >>>at lea= st) to be realizable in an implementation with limited resources,
     =    >>>such as embedded devices in what are now popularly= called "M2M"
        >>>applications.&nbs= p; A lot of these devices could use IP all the end to end,
      &= nbsp; >>>but may have a very compact, simple stack and application= s (i.e.  no
        >>>browser).  Is JSON = typically implemented when there is no browser?
        >&= gt;>Would it be hard to do in a resource constrained device (i.e. where = we
        >>>talk about memory size in Kilo-bytes s= till).
        >>
        >>In use = cases and requirements document, there are no requirements for
     &nb= sp;  >>protocol performance. I guess OS/IP/TCP/TLS code size sup= ersedes needs
        >>for JSON or XML.
      = ;  >>
        >>Same for timing: TCP/TLS con= nection setup will take more than the PAWS
        >>me= ssage exchange, I think. This may be of importance when using satcom
    &nb= sp;   >>links.
        >>
     &nbs= p;  >>Because PAWS runs between master and database, over core n= etwork,
        >>performance is not our primary concer= n. But as always, it is good to keep
        >>an eye o= n efficiency.
        >>
        >>= Teco
        >>
        >>> Than= ks
        >>> Ben
        >>>= ;
        >>>
        >>>>= We had a discussion on XML vs. JSON. I prefer the one with most
     &= nbsp;  >>>>compact messages.
        >>= ;>>
        >>>> On vCard and JSON: what is= the status of "A JavaScript Object Notation
        >= ;>>>(JSON) Representation for vCard"?
        &= gt;>>> http://tools.ietf.org/html/draft-bhat-vcarddav-js= on-00
        >>>>
        >= >>> On valid times: can we use same format as certificates? They h= ave
        >>>>similar simple requirements: vali= d notBefore&  notAfter.
        >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
      &n= bsp; >>>>
        >>>> Teco
     =    >>>> _____________________________________________= __
        >>>> paws mailing list
      =   >>>> = paws@ietf.org
        >>>> https://www.ietf.org= /mailman/listinfo/paws
        >>>>
     =    >>>
        >>> ______________= _________________________________
        >>> paws m= ailing list
        >>> paws@ietf.org
        >>>= h= ttps://www.ietf.org/mailman/listinfo/paws
        >>= ;
        >>___________________________________________= ____
        >>paws mailing list
        = >>paws@ietf.org
        >>    https://www.ietf.org/mailman/listinfo/paws
        >
        >____________________= ___________________________
        >paws mailing list
    =     >    p= aws@ietf.org
        >https://www.ietf.org/mailman/listi= nfo/paws
       
        _________________= ______________________________
        paws mailing list
    &= nbsp;   paws@i= etf.org
        https://www.ietf.org/mailman/listinfo/paws<= /a>
       




    --
    -vince

    ________= _______________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf= .org/mailman/listinfo/paws
    _________________________________________= ______
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws



     

    --
    -vince

= --_000_8375F6DAEFB09F48815203F1FE23B797117AA6D8CFshelby_-- From sdas@appcomsci.com Mon Aug 20 14:50:14 2012 Return-Path: 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 5521221F85AF for ; Mon, 20 Aug 2012 14:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=0.791, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] 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 L1YZOpMwA1wa for ; Mon, 20 Aug 2012 14:50:08 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 9D72E21F85AE for ; Mon, 20 Aug 2012 14:50:07 -0700 (PDT) Received: from bambi.research.telcordia.com (bambi.appcomsci.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q7KLnvsM017969; Mon, 20 Aug 2012 17:49:57 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q7KLnuZw013867; Mon, 20 Aug 2012 17:49:56 -0400 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at bambi Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Mon, 20 Aug 2012 17:49:56 -0400 From: "Das, Subir" To: Don Joslyn , Vincent Chen , Weixinpeng Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Ie/mfIJuS0gUKZuEsiwN7sRAAAU/5DAKHEAwAABrI7AAAWoncAABh1noAAifZJAAAEHtqAAAZ1W8A= Date: Mon, 20 Aug 2012 21:49:54 +0000 Message-ID: References: <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com> <8375F6DAEFB09F48815203F1FE23B797117AA6D8CF@shelby> In-Reply-To: <8375F6DAEFB09F48815203F1FE23B797117AA6D8CF@shelby> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.4.1.249] Content-Type: multipart/alternative; boundary="_000_AAC987F0CC2C7845A9FBD8A36D52E12D954986rrcatsexmb1_" MIME-Version: 1.0 Cc: "paws@ietf.org" , Manikkoth Sajeev 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 21:50:14 -0000 --_000_AAC987F0CC2C7845A9FBD8A36D52E12D954986rrcatsexmb1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 nee= ded for XML From: paws-bounces@ietf.org [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; 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-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: Monday, August 20, 2012 2:56 PM To: Weixinpeng Cc: 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 de= vice 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 encodin= g is better than both, as Brian points out. WiFi access points that "just w= ork" 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 (cli= ent-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 nee= ded 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 Goog= le 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 mor= e 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 w= e're clear on what device makers want. It would be good to get feedback fro= m device makers (especially of embedded devices) regarding experiences supp= orting 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 device= s) 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 muc= h or exchanged that often.] On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > 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-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; gabor.bajko@nokia.com; = vchen@google.com; peter@spectrumbridge.com Cc: 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 desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml option can also wor= k. JSON I think will necessitate implementation to be native Java and may n= ot be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_AAC987F0CC2C7845A9FBD8A36D52E12D954986rrcatsexmb1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 foll= owing two important points:

 <= /p>

    • Simple-to-use libraries exist for all major languages/platforms
    • Don't need a tool chain to work with the dat= a, as is typically needed for XML

 <= /p>

 <= /p>

 <= /p>

From: paws-bou= nces@ietf.org [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; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

 

Please see my comments be= low…

Thanks,=

Don

 <= /p>

From: 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; Manikkoth Sa= jeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

 

  • One of our goals is to strive to lower the cost and complexity f= or device manufacturers. This lowers the barrier for building a robust ecos= ystem.

[DJ - The “cost&= #8221; 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 &#= 8220;cost”?]

  • To reduce complexity and cost for device makers, supporting 1 en= coding is better than both, as Brian points out. WiFi access points that &q= uot;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 t= o 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, FourS= quare, 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 an= d maps)
    • Simple-to-use libraries exist for all major languages/platforms<= o:p>
    • Don't need a tool chain to work with the data, as is typically n= eeded for XML.

Apparently, the efficiency gains of JSON also matter= to the scalability of serving systems.

=  

[DJ – I can̵= 7;t argue against these listed pros for JSON, especially when you’re = dealing with a lot of data (like Twitter, FourSquare, Facebook and Google d= oes). 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) r= egarding experiences supporting XML vs JSON.

 

Don, can you elaborate on the types of devices that = already support XML?

&n= bsp;

[DJ - We currently support half a dozen TVDB radio vendors (embedd= ed devices) using XML, non using JSON. XML has not been a burden, and the a= mount 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.co= m> wrote:

Considering of the design of database d= iscovery 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@iet= f.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; vchen@google.com; peter@spectru= mbridge.com


Cc: 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 m= atter of protocol design or implementation, but I am a big fan of reusing standards rather than defining new ones, and I would not wa= nt to see the choice of json mean we then decide to roll our own versus usi= ng 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 t= hat decisions made solely or even largely because of compactness advantages rarely are good choices.  If you like json because it is s= maller, 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>
Reply-To: Manikkoth Sajeev <mksaji@yahoo.com>
Date: Thu, 16 Aug 2012 22:37:38 -0400
To: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>, "Rosen, Brian"= ; <brian.ro= sen@neustar.biz>, "vchen@google.c= om" <vche= n@google.com>, "peter@spectrumbridge.com" <peter@spectrumbridge.com> Cc: "paws@ie= tf.org" <paw= s@ietf.org>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal<= o:p>

 

Hi,

 

Can it not be both JSON and XML supported? I would vote for that. Future im= plementations may prefer XML as it is generic, omni present, easy to understand and val= idate. For compactness may be a  binary xml option can also work. JSON I think will necessi= tate implementation to be native Java and may not be as friendly with other= implementation languages.

 

Best Regards,

 

From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
To: Bri= an.Rosen@neustar.biz; vchen@google.com;= peter@spectrumbridge.com
Cc: paws@ietf.org=
Sent: Friday, 17 August 2012, 4:55
Subject: Re: [paws] XML schema versus JSON, vCard & iCal<= o:p>


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-bounc= es@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'<= br> 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.&nbs= p; It's very easy to parse, and its simpler to use and debug.  Don't c= are a whole lot about that

Brian <as individual>



-----Original Message-----
From:     Vincent Chen [mailto:vchen@google.com]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard T= ime
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
Subject:    Re: [paws] XML schema versus JSON, vCard & i= Cal

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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries exist for numerous languages (see= of http://json.org/) and seem to be reasonably light weight.

Timestamps

As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries 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> wr= ote:


    Whenever we built mobile devices we never dealt with IET= F, in our sensor
    days even an IP stack was a challenge,so I would defer t= o the device guys
    on that one.
   
    On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian&= quot;
   
    <Brian.Rosen@neustar.biz> wrote:
   
    >Our experience in the IETF over many years is that e= conomizing 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 sh= ould seriously
    >consider the overhead of XML or json to be significa= nt.
    >
    >Assuming a json library can be loaded on a small dev= ice is reasonable.
    >
    >Brian (as individual)
    >
    >
    >
    > -----Original Message-----
    >From:  Peter Stanforth [mailto:peter@spectrumbridge.com]=
    >Sent:  Saturday, August 11, 2012 07:13 AM Easte= rn Standard Time
    >To:    Teco Boot; Benjamin A.Rolfe
    >Cc:    paws@ietf.org
    >Subject:      Re: [paws] XML schema v= ersus JSON, vCard & iCal
    >
    >Not all masters run over the core network.
    >Some of the Use cases have a master talking to anoth= er OTA
    >We should not assume that all Masters are attached t= o 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-ne= t.nl> wrote:
    >
    >>
    >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolf= e het volgende
    >>geschreven:
    >>
    >>> Compactness of messages is important, but i= t is also important (to me
    >>>at least) to be realizable in an implementat= ion with limited resources,
    >>>such as embedded devices in what are now pop= ularly called "M2M"
    >>>applications.  A lot of these devices c= ould use IP all the end to end,
    >>>but may have a very compact, simple stack an= d applications (i.e.  no
    >>>browser).  Is JSON typically implemente= d when there is no browser?
    >>>Would it be hard to do in a resource constra= ined device (i.e. where we
    >>>talk about memory size in Kilo-bytes still).=
    >>
    >>In use cases and requirements document, there ar= e 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 t= ake more than the PAWS
    >>message exchange, I think. This may be of import= ance when using satcom
    >>links.
    >>
    >>Because PAWS runs between master and database, o= ver core network,
    >>performance is not our primary concern. But as a= lways, 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 o= f "A JavaScript Object Notation
    >>>>(JSON) Representation for vCard"?     >>>> 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 notBe= fore&  notAfter.
    >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
    >>>>
    >>>> Teco
    >>>> _______________________________________= ________
    >>>> paws mailing list
    >>>> paws@ietf.org
    >>>> https://www.ietf.org/mailman/listinfo/paw= s
    >>>>
    >>>
    >>> ___________________________________________= ____
    >>> paws mailing list
    >>> paws@ietf.org
    >>> https://www.ietf.org/mailman/listinfo/paws
    >>
    >>_______________________________________________<= br>     >>paws mailing list
    >>paws@ietf.org
    >>https://www.ietf.org/mailman/listinfo/paws
    >
    >_______________________________________________
    >paws mailing list
    >p= aws@ietf.org
    >https://www.ietf.org/mailman/listinfo/paws
   
    _______________________________________________
    paws mailing list
    paws@= ietf.org
    https://www.ietf.org/mailman/listinfo/paws
   




--
-vince

_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws



 

--
-vince

--_000_AAC987F0CC2C7845A9FBD8A36D52E12D954986rrcatsexmb1_-- From ben@blindcreek.com Mon Aug 20 17:10:53 2012 Return-Path: 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 DCF3821F8574 for ; Mon, 20 Aug 2012 17:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599] 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 t7kJz58Aj8Dr for ; Mon, 20 Aug 2012 17:10:52 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id 258CA21F8567 for ; Mon, 20 Aug 2012 17:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=5VFhuzAaKnnzvW8x9Ye6WbnPHafXVz1XbaZJx4/AF5s=; b=OTt3sK6//Pfj//j5Y9Qw/MlRpOFa9UWLxBfSgshYJmlbb4APdoaqWHSzHIGOjhIS3M3ZxDzKv+fGzbQXtD+NhN4nQ3T64ZXKd8jbEu9O6ONLmN9K3S0mTTgVJkwgJwL7; Received: from [64.74.213.174] (port=64046 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1T3c3U-0002Jn-Ke for paws@ietf.org; Mon, 20 Aug 2012 19:10:49 -0500 Message-ID: <5032D20A.1050008@blindcreek.com> Date: Mon, 20 Aug 2012 17:10:50 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: "paws@ietf.org" References: <50329616.3030207@blindcreek.com> <0FCA100D-7C67-47F6-A0C2-03B27F60545E@neustar.biz> In-Reply-To: <0FCA100D-7C67-47F6-A0C2-03B27F60545E@neustar.biz> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 00:10:54 -0000 I agree there is a requirement there. I also agree that the US rules are ... what they are (and the rest :-). I think the wireless microphone example is an interesting situation. The scenario with a lot of microphones is likely at a large event. My understanding is that microphones are narrow band device, with a lot of sub-channels in a single TV channel (makes sense - can do a lot of audio channels in 6 MHz0). I'm still fuzzy on the granularity of the database information - what I have seen just gives the availability in TV channel resolution, in which case a lot of microphones might translate into a couple TV channels. But like I said, I'm not at all sure, can someone elaborate? Thanks > > I think you get a set of start/stop times for a given spectrum unit. That's all you need. > > There is a tradeoff in the complexity of a schedule received and how often you have to come back to the database. The US rules provide one set of tradeoffs. It's not clear to be they are great, but they are what they are. > > Imagine a device surrounded by lots of temporary use wireless microphones. The U.S. rules may result in a response of dozens of schedule items, as the use comes and goes on multiple channels. It could theoretically be huge - hundreds if not thousands of schedule items. While I doubt this would happen very often, I think it will be very difficult to put any kind of upper bound on the number of schedule items (spectrum unit, start and stop times) a device may have to contend with. > > That makes for a complex implementation. We are no doubt stuck with it in terms of what the protocol must be able to do. > > A better design would limit the number of schedule items to either a fixed limit, or some limit expressed by the client. The client would then have to get back to the database sooner, to get more schedule. > > It may be that clients prefer to do that (that is, limit schedule in exchange for shorter time to requery). That would not violate rules as long as the device didn't use channels for which it did not have accurate schedule. > > I think there might be a requirement there: the ability to limit the number of schedule items returned, as well as a requirement to return when the returned schedule ends (i.e. when the database must be required to get more schedule). > > Brian > > On Aug 20, 2012, at 3:55 PM, Benjamin A. Rolfe wrote: > >> Peter makes a good point. The rules will allow a device to use channel >> availability data for as much as 48 hours - it allows that the device >> must access the database at least once per day, but if it tries and >> fails it can use the data until 11:59pm of the follow day. >> >> That wasn't the 48 hours I was thinking about though, I was thinking >> about the paragraph before that: >> ¡× 15.711 (b)(3)(i) >> ... Fixed TVBD must adjust their use of channels in accordance with >> channel availability schedule information provided by their database for >> the 48-hour period beginning at the time of the device last accessed the >> database for a list of available channels. >> >> So in addition to providing what is available now, plus how things are >> expected to change over the next 48 hour period. I shouldn't have said >> "guess" since the requirements for notice from the priority users are >> greater than 48 hours. >> >> Having now discussed it "out loud" so to speak, it really does not need >> to be two distinct notions. The The "start/end" on a per channel basis >> provides what you need; and the database has to provide a schedule at >> the time of request that shows everything from now until now + 48 hours. >> >> I also agree enthusiastically with Peter that we should expect changes >> in the requirements (and that is a guess, but an educated one ;-). >> >> Ben >> >>> Ben, >>> FCC rules do assume that a channel assignment if from now until some time >>> in the future, the current default is 24 hours - unless the device moves. >>> It is same to assume that the duration will become much shorter >>> eventually. So "Valid until" is a reasonable proposition. However the FCC >>> does not preclude a radio from getting a channel list in advance. In many >>> ways it makes more sense for a device to ask for a new channel list before >>> it's current list expires so start time might be relevant in this case. >>> >>> I don't think the FCC was proposing a "predictive guess". The actual FCC >>> rule is that a channel list is valid for 24hours, but if a device cannot >>> contact a database at that time it has permission to keep using the >>> channel list for a further 24hours (48hours total) I don't think this is a >>> good idea as it precludes a broadcaster reserving channels inside that >>> window, and, as mentioned above there is some discussion about making the >>> window much shorter to accommodate situations where broadcasters cannot >>> plan 24, or worst case 48 hours, in advance. Personally I prefer that the >>> device get a channel list that is good for some period, without any ifs >>> buts or maybes, and then it has to query again. This is much simpler than >>> trying to map matrices of start/stop times for various channels (maybe >>> with variable power limits) over an extended period. >>> Peter S. >>> >>> On MonAug/20/12 Mon Aug 20, 11:15 AM, "Benjamin A. Rolfe" >>> wrote: >>> >>>> Thanks for the clarification. >>>> There are also two notions of what "schedule" means, at least in the FCC >>>> rules. There is the notion that the current channel availability data >>>> has a expiration time, and thus there is a time in the future when >>>> updating will be necessary. This is at most a day. Based on FCC rules, >>>> this could be a local time determined by the device using the channel >>>> data, and if that device is acting as a source for dependent device >>>> "using" includes providing it to other dependent devices (and it would >>>> have to provide the "valid until" time). I can imagine that other >>>> regulatory bodies (and perhaps the FCC in the future) will require that >>>> channel availability data provided by the data base also be tagged with >>>> the "valid until" information. This does not require a start time, as >>>> "now" is implied. >>>> >>>> The other notion of schedule time is that the database contains a >>>> predictive guess as to what channels will be available for the next 48 >>>> hours into the future. This is required by FCC (though the device must >>>> still check at least once a day if what it is using is still valid). A >>>> start/stop pair is required for this. >>>> >>>> I think either format can be used to represent time in both cases. It is >>>> also possible that the 48-hour schedule is all that PAWS needs to >>>> provide to meet the regulations and the "valid until" can be derived >>>> from that by the using device. >>>> Hope that helps. >>>> -Ben >>>> >>>>> Uh, the difference is representation of start/stop times. We both >>>>> propose >>>>> to send start/stop times. Vincent proposes that the representation of >>>>> time be a long integer seconds since an epoch. He would send two such >>>>> long integers. I propose it be an ISO 8601 time string. Specifically, >>>>> I >>>>> would propose an ISO 8601 interval limited to start/end, e.g. >>>>> 2011-03-01T13:00:00Z/2012-05-11T15:30:00Z. >>>>> >>>>> On 8/16/12 6:45 PM, "Gabor.Bajko@nokia.com" >>>>> wrote: >>>>> >>>>>> It seems we have an agreement on the requirement to identify the >>>>>> spectrum, by using the start/stop frequencies, with optional channel >>>>>> identifiers. >>>>>> >>>>>> Wrt to the schedule, we have so far two proposals, one from Brian >>>>>> proposing the use of start/stop times for each spectrum unit available, >>>>>> and one from Vincent proposing to use of Unix Epoch time in seconds. We >>>>>> need to decide on this, so please send your preference on this topic to >>>>>> the list. >>>>>> >>>>>> - Gabor >>>>>> >>>>>> -----Original Message----- >>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>>>>> Probasco Scott (Nokia-CIC/Dallas) >>>>>> Sent: Monday, August 13, 2012 10:12 AM >>>>>> To: paws@ietf.org >>>>>> Subject: Re: [paws] use cases and requirements document >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Given that we have completed two Working Group Last Call cycles and >>>>>> this >>>>>> next version will go to the IESG, I hope we could agree on minimal >>>>>> changes to the document, i.e. changes only to D.7 for this topic. This >>>>>> will ensure the proper requirements are established for the developing >>>>>> PAWS protocol. >>>>>> I believe Brian's proposed text captures the essential requirements. >>>>>> >>>>>> Kind Regards, >>>>>> Scott >>>>>> >>>>>> >>>>>> On 8/13/12 8:24 AM, "ext Rosen, Brian" wrote: >>>>>> >>>>>>> >>>>>>> I would prefer to not use the word "channel" in our documents at all >>>>>>> except for the term "channel identifier". I proposed "spectrum unit", >>>>>>> although any other term will do. "Channel" has too much baggage, A >>>>>>> simple editorial change like this is simple, and it's much better to >>>>>>> do >>>>>>> it now. >>>>>>> >>>>>>> I think we need power in both the query and the response. In some >>>>>>> domains, it may be that you specify what power you want to use and the >>>>>>> DB tells you what spectrum you can use at that power. In other, a >>>>>>> US-like rule may be in place. Also in either the query or the >>>>>>> registration, we need a device type, which should be an entry from an >>>>>>> IANA registry. This is how you get the US "Mode II" information. >>>>>>> >>>>>>> With regard to schedule, I would like to see two mechanisms >>>>>>> 1) a time by which the database should be queried again (which could >>>>>>> represent the next change in schedule) >>>>>>> 2) start/stop times for each spectrum unit available >>>>>>> >>>>>>> Both these should be optional in the response. >>>>>>> >>>>>>> My text >>>>>>> >>>>>>> The data model must support specifying spectrum availability. >>>>>>> Spectrum >>>>>>> units are specified by low and high frequencies and may have an >>>>>>> optional channel identifier. >>>>>>> >>>>>>> The data model must support a schedule for spectrum unit availability. >>>>>>> Two mechanisms must be supported. The response to spectrum >>>>>>> availability query may include a time by which the database must be >>>>>>> requeried. Each spectrum unit mentioned in the response may be >>>>>>> annotated with start and stop time/date. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Eric Chu [mailto:ericchu@google.com] >>>>>>> Sent: Saturday, August 11, 2012 11:43 AM Eastern Standard Time >>>>>>> To: Teco Boot >>>>>>> Cc: Rosen, Brian; paws@ietf.org >>>>>>> Subject: Re: [paws] use cases and requirements document >>>>>>> >>>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> Gathering all the shared points from everyone... I believe below is >>>>>>> the >>>>>>> complete list so far: >>>>>>> >>>>>>> >>>>>>> >>>>>>> * What's the best consistent representation of the words "channel >>>>>>> numbers" for non-TV spectrum >>>>>>> * Should we update the entire doc on the topic of ©øchannel©÷ or >>>>>>> ©øchannel numbers©÷ >>>>>>> * What©ös the best way to reduce vagueness in whether/how to include >>>>>>> "channel numbers" >>>>>>> * Is the reference to variable power required >>>>>>> * What does channel availability schedule mean >>>>>>> >>>>>>> >>>>>>> Brian's suggestion of replacing every instance of "channel" is >>>>>>> technically correctly. However, it is important for us to focus moving >>>>>>> forward. I would suggest we only work on the normative part of the >>>>>>> spec. >>>>>>> The section Gabor is proposing for us to modify... >>>>>>> >>>>>>> On what's the best generic label for the words "channel numbers", >>>>>>> channel identifier might be the most accurate and neutral "label". >>>>>>> Thoughts? >>>>>>> >>>>>>> On the question whether variable power is required, based on FCC >>>>>>> adjacent-channel rules, the database may limit the Mode II devices to >>>>>>> 100mW for some channels and 40mW for others. Therefore, the data model >>>>>>> needs to support specification of maximum power levels. >>>>>>> >>>>>>> Lastly, with regards to "schedule", the intent is to have a way of >>>>>>> informing devices when to operate for each frequency range. As long as >>>>>>> the data model supports, for example, a list of time ranges, it does >>>>>>> not prevent an implementation from providing a list with 1 entry which >>>>>>> corresponds to the "shortest available". The word "schedule" should >>>>>>> be >>>>>>> sufficient to capture this intent? >>>>>>> >>>>>>> We would like to propose the following text to address these points: >>>>>>> >>>>>>> "The Data Model MUST support specifying available spectrum. The Data >>>>>>> Model MUST support specification of this information by start and stop >>>>>>> frequencies and MAY also support specification of this information by >>>>>>> channel identifiers. The Data Model MUST support a >>>>>>> spectrum-availability schedule and maximum power levels for each >>>>>>> frequency range." >>>>>>> >>>>>>> >>>>>>> Thoughts? >>>>>>> Eric >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 8/10/12 5:48 AM, Teco Boot wrote: >>>>>>> >>>>>>> >>>>>>> What about this: >>>>>>> >>>>>>> ©øThe Data Model MUST support specifying a list of available >>>>>>> channels. The Data Model MUST support specification of this >>>>>>> information >>>>>>> by start and stop frequencies, or equivalents such as center >>>>>>> frequencies with channel width or channel numbers with channel nummer >>>>>>> allocation scheme . The Data Model MUST support a channel availability >>>>>>> schedule and maximum power level for each channel in the list.©÷ >>>>>>> >>>>>>> More thoughts on channel numbers: we likely run into problems in >>>>>>> bands without a channel numbering scheme, or for example sub channels >>>>>>> in TV bands. >>>>>>> >>>>>>> Teco >>>>>>> >>>>>>> >>>>>>> Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende >>>>>>> geschreven: >>>>>>> >>>>>>> >>>>>>> >>>>>>> While I don't care if it's center and width or upper/lower, I >>>>>>> do think we will define the format in the protocol for >>>>>>> interoperability >>>>>>> reasons, but don't need to do that in requirements. It wouldn't hurt >>>>>>> to decide now and use consistent terms, but we don't need to. >>>>>>> >>>>>>> I think "band" won't work, as it usually implies a much wider >>>>>>> piece of spectrum that has a common purpose. The TV Band is all the >>>>>>> channels. >>>>>>> >>>>>>> >>>>>>> On Aug 10, 2012, at 2:37 AM, Teco Boot wrote: >>>>>>> >>>>>>> >>>>>>> (somewhat late response) >>>>>>> >>>>>>> A center frequency and channel width is functional >>>>>>> equivalent to start/stop frequencies. So is channel number, with ref >>>>>>> to >>>>>>> channel number assignment scheme. For a requirements document, we just >>>>>>> need to specify what is needed. How it is encoded (Hz, wave length, >>>>>>> channel ID) is solution space. >>>>>>> >>>>>>> Seen our goal to make PAWS somewhat universal (not limited >>>>>>> to US TVWS), I do not prefer using channel numbers. >>>>>>> >>>>>>> Teco >>>>>>> >>>>>>> >>>>>>> Op 9 aug. 2012, om 21:55 heeft >>>>>>> het volgende geschreven: >>>>>>> >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> During the last F2F meeting, there was an agreement to >>>>>>> make a slight update to requirement D.7 in >>>>>>> >>>>>>> http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.t >>>>>>> xt, to make channel numbers optional to be supported. Ie, change the >>>>>>> current >>>>>>> D.7 >>>>>>> ©øThe Data Model MUST support specifying a list of >>>>>>> available channels. The Data Model MUST support specification of this >>>>>>> information by channel numbers and by start and stop frequencies. The >>>>>>> Data Model MUST support a channel availability schedule and maximum >>>>>>> power level for each channel in the list.©÷ >>>>>>> to >>>>>>> ©øThe Data Model MUST support specifying a list of >>>>>>> available channels. The Data Model MUST support specification of this >>>>>>> information by start and stop frequencies and MAY include channel >>>>>>> numbers. The Data Model MUST support a channel availability schedule >>>>>>> and maximum power level for each channel in the list.©÷ >>>>>>> >>>>>>> I©öd like to confirm this change on the list. If anyone >>>>>>> has any objections, let me know. Otherwise I©öll plan to send the >>>>>>> document to the iesg after this change is implemented. >>>>>>> >>>>>>> - Gabor >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Mon Aug 20 21:26:28 2012 Return-Path: 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 8484C21F84D1 for ; Mon, 20 Aug 2012 21:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, 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 6HVdhl6fw-AU for ; Mon, 20 Aug 2012 21:26:27 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 50E8121F84C8 for ; Mon, 20 Aug 2012 21:26:25 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7L4QDZr025469; Tue, 21 Aug 2012 07:26:16 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Aug 2012 07:26:15 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0283.004; Tue, 21 Aug 2012 06:26:14 +0200 From: To: , Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac132A+fbbG4lfLAT8aeYHhnRNTamABfuNkz///KeYD/+nkpcIAL38SAgATaWgCAAB0cgIAAMRUAgAAEjAD//1WqEA== Date: Tue, 21 Aug 2012 04:26:13 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB5D8D@008-AM1MPN1-006.mgdnok.nokia.com> References: <50329616.3030207@blindcreek.com> <0FCA100D-7C67-47F6-A0C2-03B27F60545E@neustar.biz> In-Reply-To: <0FCA100D-7C67-47F6-A0C2-03B27F60545E@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Aug 2012 04:26:15.0700 (UTC) FILETIME=[1A7D9D40:01CD7F55] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 04:26:28 -0000 Let's conclude this topic with agreeing on using start/stop times for each = spectrum unit available in ISO8601 format. I'll ask the editor to implement the two points we agreed on, namely: Requirement to identify the spectrum, by using the start/stop frequencies, = with optional channel identifiers; and Requirement to use start/stop times for each spectrum unit available in ISO= 8601 format and submit a new version of the use cases and requirements I-D, which the c= hairs will send to the iesg. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Rosen, Brian Sent: Monday, August 20, 2012 1:11 PM To: Benjamin A. Rolfe Cc: paws@ietf.org Subject: Re: [paws] use cases and requirements document I think you get a set of start/stop times for a given spectrum unit. That'= s all you need. There is a tradeoff in the complexity of a schedule received and how often = you have to come back to the database. The US rules provide one set of tra= deoffs. It's not clear to be they are great, but they are what they are. Imagine a device surrounded by lots of temporary use wireless microphones. = The U.S. rules may result in a response of dozens of schedule items, as th= e use comes and goes on multiple channels. It could theoretically be huge = - hundreds if not thousands of schedule items. While I doubt this would ha= ppen very often, I think it will be very difficult to put any kind of upper= bound on the number of schedule items (spectrum unit, start and stop times= ) a device may have to contend with. That makes for a complex implementation. We are no doubt stuck with it in = terms of what the protocol must be able to do. A better design would limit the number of schedule items to either a fixed = limit, or some limit expressed by the client. The client would then have t= o get back to the database sooner, to get more schedule. It may be that clients prefer to do that (that is, limit schedule in exchan= ge for shorter time to requery). That would not violate rules as long as t= he device didn't use channels for which it did not have accurate schedule. I think there might be a requirement there: the ability to limit the number= of schedule items returned, as well as a requirement to return when the re= turned schedule ends (i.e. when the database must be required to get more s= chedule). Brian On Aug 20, 2012, at 3:55 PM, Benjamin A. Rolfe wrote: > Peter makes a good point. The rules will allow a device to use channel=20 > availability data for as much as 48 hours - it allows that the device=20 > must access the database at least once per day, but if it tries and=20 > fails it can use the data until 11:59pm of the follow day. > > That wasn't the 48 hours I was thinking about though, I was thinking=20 > about the paragraph before that: > =A7 15.711 (b)(3)(i) > ... Fixed TVBD must adjust their use of channels in accordance with=20 > channel availability schedule information provided by their database=20 > for the 48-hour period beginning at the time of the device last=20 > accessed the database for a list of available channels. > > So in addition to providing what is available now, plus how things are=20 > expected to change over the next 48 hour period. I shouldn't have said=20 > "guess" since the requirements for notice from the priority users are=20 > greater than 48 hours. > > Having now discussed it "out loud" so to speak, it really does not=20 > need to be two distinct notions. The The "start/end" on a per channel=20 > basis provides what you need; and the database has to provide a=20 > schedule at the time of request that shows everything from now until now = + 48 hours. > > I also agree enthusiastically with Peter that we should expect changes=20 > in the requirements (and that is a guess, but an educated one ;-). > > Ben > >> Ben, >> FCC rules do assume that a channel assignment if from now until some=20 >> time in the future, the current default is 24 hours - unless the device = moves. >> It is same to assume that the duration will become much shorter=20 >> eventually. So "Valid until" is a reasonable proposition. However=20 >> the FCC does not preclude a radio from getting a channel list in=20 >> advance. In many ways it makes more sense for a device to ask for a=20 >> new channel list before it's current list expires so start time might be= relevant in this case. >> >> I don't think the FCC was proposing a "predictive guess". The actual=20 >> FCC rule is that a channel list is valid for 24hours, but if a device=20 >> cannot contact a database at that time it has permission to keep=20 >> using the channel list for a further 24hours (48hours total) I don't=20 >> think this is a good idea as it precludes a broadcaster reserving=20 >> channels inside that window, and, as mentioned above there is some=20 >> discussion about making the window much shorter to accommodate=20 >> situations where broadcasters cannot plan 24, or worst case 48 hours,=20 >> in advance. Personally I prefer that the device get a channel list=20 >> that is good for some period, without any ifs buts or maybes, and=20 >> then it has to query again. This is much simpler than trying to map=20 >> matrices of start/stop times for various channels (maybe with variable p= ower limits) over an extended period. >> Peter S. >> >> On MonAug/20/12 Mon Aug 20, 11:15 AM, "Benjamin A. Rolfe" >> wrote: >> >>> Thanks for the clarification. >>> There are also two notions of what "schedule" means, at least in the=20 >>> FCC rules. There is the notion that the current channel availability=20 >>> data has a expiration time, and thus there is a time in the future=20 >>> when updating will be necessary. This is at most a day. Based on FCC=20 >>> rules, this could be a local time determined by the device using the=20 >>> channel data, and if that device is acting as a source for dependent=20 >>> device "using" includes providing it to other dependent devices (and=20 >>> it would have to provide the "valid until" time). I can imagine that=20 >>> other regulatory bodies (and perhaps the FCC in the future) will=20 >>> require that channel availability data provided by the data base=20 >>> also be tagged with the "valid until" information. This does not=20 >>> require a start time, as "now" is implied. >>> >>> The other notion of schedule time is that the database contains a=20 >>> predictive guess as to what channels will be available for the next=20 >>> 48 hours into the future. This is required by FCC (though the device=20 >>> must still check at least once a day if what it is using is still=20 >>> valid). A start/stop pair is required for this. >>> >>> I think either format can be used to represent time in both cases.=20 >>> It is also possible that the 48-hour schedule is all that PAWS needs=20 >>> to provide to meet the regulations and the "valid until" can be=20 >>> derived from that by the using device. >>> Hope that helps. >>> -Ben >>> >>>> Uh, the difference is representation of start/stop times. We both=20 >>>> propose to send start/stop times. Vincent proposes that the=20 >>>> representation of time be a long integer seconds since an epoch. =20 >>>> He would send two such long integers. I propose it be an ISO 8601=20 >>>> time string. Specifically, I would propose an ISO 8601 interval=20 >>>> limited to start/end, e.g. >>>> 2011-03-01T13:00:00Z/2012-05-11T15:30:00Z. >>>> >>>> On 8/16/12 6:45 PM, "Gabor.Bajko@nokia.com" >>>> wrote: >>>> >>>>> It seems we have an agreement on the requirement to identify the=20 >>>>> spectrum, by using the start/stop frequencies, with optional=20 >>>>> channel identifiers. >>>>> >>>>> Wrt to the schedule, we have so far two proposals, one from Brian=20 >>>>> proposing the use of start/stop times for each spectrum unit=20 >>>>> available, and one from Vincent proposing to use of Unix Epoch=20 >>>>> time in seconds. We need to decide on this, so please send your=20 >>>>> preference on this topic to the list. >>>>> >>>>> - Gabor >>>>> >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=20 >>>>> Behalf Of Probasco Scott (Nokia-CIC/Dallas) >>>>> Sent: Monday, August 13, 2012 10:12 AM >>>>> To: paws@ietf.org >>>>> Subject: Re: [paws] use cases and requirements document >>>>> >>>>> Hi All, >>>>> >>>>> Given that we have completed two Working Group Last Call cycles=20 >>>>> and this next version will go to the IESG, I hope we could agree=20 >>>>> on minimal changes to the document, i.e. changes only to D.7 for=20 >>>>> this topic. This will ensure the proper requirements are=20 >>>>> established for the developing PAWS protocol. >>>>> I believe Brian's proposed text captures the essential requirements. >>>>> >>>>> Kind Regards, >>>>> Scott >>>>> >>>>> >>>>> On 8/13/12 8:24 AM, "ext Rosen, Brian" wrot= e: >>>>> >>>>>> >>>>>> I would prefer to not use the word "channel" in our documents at=20 >>>>>> all except for the term "channel identifier". I proposed=20 >>>>>> "spectrum unit", although any other term will do. "Channel" has=20 >>>>>> too much baggage, A simple editorial change like this is simple,=20 >>>>>> and it's much better to do it now. >>>>>> >>>>>> I think we need power in both the query and the response. In=20 >>>>>> some domains, it may be that you specify what power you want to=20 >>>>>> use and the DB tells you what spectrum you can use at that power. =20 >>>>>> In other, a US-like rule may be in place. Also in either the=20 >>>>>> query or the registration, we need a device type, which should be=20 >>>>>> an entry from an IANA registry. This is how you get the US "Mode II= " information. >>>>>> >>>>>> With regard to schedule, I would like to see two mechanisms >>>>>> 1) a time by which the database should be queried again (which=20 >>>>>> could represent the next change in schedule) >>>>>> 2) start/stop times for each spectrum unit available >>>>>> >>>>>> Both these should be optional in the response. >>>>>> >>>>>> My text >>>>>> >>>>>> The data model must support specifying spectrum availability. >>>>>> Spectrum >>>>>> units are specified by low and high frequencies and may have an=20 >>>>>> optional channel identifier. >>>>>> >>>>>> The data model must support a schedule for spectrum unit availabilit= y. >>>>>> Two mechanisms must be supported. The response to spectrum=20 >>>>>> availability query may include a time by which the database must=20 >>>>>> be requeried. Each spectrum unit mentioned in the response may=20 >>>>>> be annotated with start and stop time/date. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Eric Chu [mailto:ericchu@google.com] >>>>>> Sent: Saturday, August 11, 2012 11:43 AM Eastern Standard Time >>>>>> To: Teco Boot >>>>>> Cc: Rosen, Brian; paws@ietf.org >>>>>> Subject: Re: [paws] use cases and requirements document >>>>>> >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> Gathering all the shared points from everyone... I believe below=20 >>>>>> is the complete list so far: >>>>>> >>>>>> >>>>>> >>>>>> * What's the best consistent representation of the words "channel >>>>>> numbers" for non-TV spectrum >>>>>> * Should we update the entire doc on the topic of =B3channel=B2 o= r >>>>>> =B3channel numbers=B2 >>>>>> * What=B9s the best way to reduce vagueness in whether/how to inc= lude >>>>>> "channel numbers" >>>>>> * Is the reference to variable power required >>>>>> * What does channel availability schedule mean >>>>>> >>>>>> >>>>>> Brian's suggestion of replacing every instance of "channel" is=20 >>>>>> technically correctly. However, it is important for us to focus=20 >>>>>> moving forward. I would suggest we only work on the normative=20 >>>>>> part of the spec. >>>>>> The section Gabor is proposing for us to modify... >>>>>> >>>>>> On what's the best generic label for the words "channel numbers",=20 >>>>>> channel identifier might be the most accurate and neutral "label". >>>>>> Thoughts? >>>>>> >>>>>> On the question whether variable power is required, based on FCC=20 >>>>>> adjacent-channel rules, the database may limit the Mode II=20 >>>>>> devices to 100mW for some channels and 40mW for others.=20 >>>>>> Therefore, the data model needs to support specification of maximum = power levels. >>>>>> >>>>>> Lastly, with regards to "schedule", the intent is to have a way=20 >>>>>> of informing devices when to operate for each frequency range. As=20 >>>>>> long as the data model supports, for example, a list of time=20 >>>>>> ranges, it does not prevent an implementation from providing a=20 >>>>>> list with 1 entry which corresponds to the "shortest available". =20 >>>>>> The word "schedule" should be sufficient to capture this intent? >>>>>> >>>>>> We would like to propose the following text to address these points: >>>>>> >>>>>> "The Data Model MUST support specifying available spectrum. The=20 >>>>>> Data Model MUST support specification of this information by=20 >>>>>> start and stop frequencies and MAY also support specification of=20 >>>>>> this information by channel identifiers. The Data Model MUST=20 >>>>>> support a spectrum-availability schedule and maximum power levels=20 >>>>>> for each frequency range." >>>>>> >>>>>> >>>>>> Thoughts? >>>>>> Eric >>>>>> >>>>>> >>>>>> >>>>>> On 8/10/12 5:48 AM, Teco Boot wrote: >>>>>> >>>>>> >>>>>> What about this: >>>>>> >>>>>> =B3The Data Model MUST support specifying a list of available= =20 >>>>>> channels. The Data Model MUST support specification of this=20 >>>>>> information by start and stop frequencies, or equivalents such as=20 >>>>>> center frequencies with channel width or channel numbers with=20 >>>>>> channel nummer allocation scheme . The Data Model MUST support a=20 >>>>>> channel availability schedule and maximum power level for each=20 >>>>>> channel in the list.=B2 >>>>>> >>>>>> More thoughts on channel numbers: we likely run into problems=20 >>>>>> in bands without a channel numbering scheme, or for example sub=20 >>>>>> channels in TV bands. >>>>>> >>>>>> Teco >>>>>> >>>>>> >>>>>> Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende >>>>>> geschreven: >>>>>> >>>>>> >>>>>> >>>>>> While I don't care if it's center and width or upper/lower,=20 >>>>>> I do think we will define the format in the protocol for=20 >>>>>> interoperability reasons, but don't need to do that in=20 >>>>>> requirements. It wouldn't hurt to decide now and use consistent=20 >>>>>> terms, but we don't need to. >>>>>> >>>>>> I think "band" won't work, as it usually implies a much=20 >>>>>> wider piece of spectrum that has a common purpose. The TV Band=20 >>>>>> is all the channels. >>>>>> >>>>>> >>>>>> On Aug 10, 2012, at 2:37 AM, Teco Boot wrote= : >>>>>> >>>>>> >>>>>> (somewhat late response) >>>>>> >>>>>> A center frequency and channel width is functional=20 >>>>>> equivalent to start/stop frequencies. So is channel number, with=20 >>>>>> ref to channel number assignment scheme. For a requirements=20 >>>>>> document, we just need to specify what is needed. How it is=20 >>>>>> encoded (Hz, wave length, channel ID) is solution space. >>>>>> >>>>>> Seen our goal to make PAWS somewhat universal (not=20 >>>>>> limited to US TVWS), I do not prefer using channel numbers. >>>>>> >>>>>> Teco >>>>>> >>>>>> >>>>>> Op 9 aug. 2012, om 21:55 heeft =20 >>>>>> het volgende geschreven: >>>>>> >>>>>> >>>>>> Folks, >>>>>> >>>>>> During the last F2F meeting, there was an agreement=20 >>>>>> to make a slight update to requirement D.7 in >>>>>> >>>>>> http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmt >>>>>> s-06.t xt, to make channel numbers optional to be supported. Ie,=20 >>>>>> change the current >>>>>> D.7 >>>>>> =B3The Data Model MUST support specifying a list of=20 >>>>>> available channels. The Data Model MUST support specification of=20 >>>>>> this information by channel numbers and by start and stop=20 >>>>>> frequencies. The Data Model MUST support a channel availability=20 >>>>>> schedule and maximum power level for each channel in the list.=B2 >>>>>> to >>>>>> =B3The Data Model MUST support specifying a list of=20 >>>>>> available channels. The Data Model MUST support specification of=20 >>>>>> this information by start and stop frequencies and MAY include=20 >>>>>> channel numbers. The Data Model MUST support a channel=20 >>>>>> availability schedule and maximum power level for each channel in=20 >>>>>> the list.=B2 >>>>>> >>>>>> I=B9d like to confirm this change on the list. If=20 >>>>>> anyone has any objections, let me know. Otherwise I=B9ll plan to=20 >>>>>> send the document to the iesg after this change is implemented. >>>>>> >>>>>> - Gabor >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Mon Aug 20 21:37:59 2012 Return-Path: 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 DE0F611E80DB for ; Mon, 20 Aug 2012 21:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TEwlf8ONOYX3 for ; Mon, 20 Aug 2012 21:37:53 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id DC1AF21F851E for ; Mon, 20 Aug 2012 21:37:52 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7L4blL6007718; Tue, 21 Aug 2012 07:37:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Aug 2012 07:37:49 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.02.0283.004; Tue, 21 Aug 2012 06:37:47 +0200 From: To: , Thread-Topic: [paws] need for DB initialization message Thread-Index: Ac12he0A+5h4j+uqT6e4F6BpK7EzX///7O8A//TyocCAFuOmgP/6JMyw Date: Tue, 21 Aug 2012 04:37:46 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DA9@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB4298@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DA9008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 21 Aug 2012 04:37:49.0240 (UTC) FILETIME=[B7DF6B80:01CD7F56] X-Nokia-AV: Clean Subject: Re: [paws] need for DB initialization message X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 04:37:59 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DA9008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We've seen no objections in having a DB initialization message, for the pur= pose of learning the operating rules for the regulatory domain. My take is = that this message is sent by the master device on a need basis. I am assuming we have agreement on this, so let's take this into considerat= ion for the wg document, and move forward. - Gabor From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Friday, August 17, 2012 6:01 AM To: Bajko Gabor (Nokia-CIC/SiliconValley); paws@ietf.org Subject: Re: [paws] need for DB initialization message What I notice when I look at regulations is how we see different classes of= information required at different points in the regulation-required interc= hanges that wouldn't occur to us protocol designers. I think it is foolis= h to hard wire any specific piece of information to any specific protocol e= xchange, because some regulator will do something we would classify as sill= y, but the implementations are stuck. As an example, in the US regulations= , there is information that we would classify as "registration" data requir= ed to be in the "spectrum query" message exchange. So, I do see that a great deal of information exchanged will need to be fle= xible where it goes. In this regard, I think that when a device first connects to a database, th= ere will be information exchanged, and I'll bet there will be circumstances= where the information the client sends will depend in some way on informat= ion the server has. I think this may also happen on the spectrum query. T= herefore, I would like to make sure that it's possible to have 3 way exchan= ges in all circumstances. Client to server, server to client, client to se= rver. This is not a 3 way message exchange on an unreliable transport. I= t lets the client send information dependent on what it gets from the serve= r. So, my answer is more complex. I don't think we need a separate message to= ask about the regulatory domain. I think the "registration" message excha= nge is a 3 way exchange. If you wanted to send regulatory domain in the se= cond message, and get regulatory required information not sent in the first= message sent in the third message of the transaction, that would work for = me. Brian From: "Gabor.Bajko@nokia.com" > Date: Thu, 16 Aug 2012 19:11:40 -0400 To: "paws@ietf.org" > Subject: Re: [paws] need for DB initialization message This thread was a bit derailed, so I'd like to get back to the original que= stion, which was whether we need a DB initialization message as proposed in= draft-das or not. We seem to converge on the discovery of the regulatory domain, ie that the = regulatory domain can be discovered during the DB discovery process, and we= do not need a separate message to ask the DB what regulatory domain the ma= ster is in. Then, the question is whether the masters need to contact the DB prior to a= ny other communication, to learn the operating rules for that regulatory do= main. The alternative would be that the masters are preconfigured with the = operating rules for the regulatory domains they are going to operate in. In the F2F, there were opinions on both sides, but not enough to call a con= sensus. So, please send your preference on the need for DB initialization, = to the list. We need to make a decision on this and some other issues, so w= e could move forward creating a wg document. - Gabor From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Thursday, August 09, 2012 5:15 PM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: paws@ietf.org Subject: Re: [paws] need for DB initialization message I'm not so sure you need something separate for domain. ISTM that the DB d= iscovery could return it (possibly as a parameter on the DB URI). OTOH, yo= u might very well want to receive from the DB some kind of data specificati= on (that is, what is required to be provided in the registration), rather t= han having it totally wired in to domain. That means, to me, that the regi= stration is a 4 way message exchange: 1. Device to DB: Authenticate me please 2. DB to device: Authentication accepted, send me this data 3. Device to DB: Here is my registration data 4. DB to device: Registration succeeded. Now, having said that, you might just get authentication out of the TLS ses= sion establishment, this not needing step 1. Brian On Aug 9, 2012, at 8:02 PM, > wrote: Folks, During the Vancouver F2F discussions we had some good discussions, but no a= greement on whether an initialization message, as proposed in draft-das is = necessary or not. You may check the minutes to see what was said at the mike: http://www.ietf= .org/proceedings/84/minutes/minutes-84-paws People spoke mostly in favor, but there were people who also said that this= message is redundant with registration message. Question#1: need for an initialization message Unfortunately we did not have time to discuss the DB discovery aspect, and = that may be related to this topic. The only DB discovery document available= currently, http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, pr= oposes, that the master device contacts a pre-provisioned discovery server = and provides its location, and in return the discovery server returns the U= RI of the DB for that regulatory domain. At this point, the master device k= nows which DB to contact, but it does not necessarily know what regulatory = domain that DB belongs to. Thus, it doesn't know what are the operating rul= es, whether it has to authenticate, or register, etc. Thus, it seems logical to me that the master device first queries the DB to= find out the regulatory domain. We even have such a requirement in the req= uirement draft, requirement: "P.3: The protocol MUST support determination of regulatory d= omain governing its current location." The information about the regulatory domain may be cached, and the master d= evice may not need to place that query every time, but this message exchang= e may be necessary in certain cases. Any comments to this point? Question#2 Then, it is a slightly separate issue, if this message exchange has to take= place, then what additional information the DB returns. draft-das proposes= that regulatory domain specific information be returned to the master devi= ce. Question#3 Yet another separate point is that draft-das proposes to use this initializ= ation message also to initiate client authentication (putting shared secret= vs cert issue aside for the time being). In cases when the master device d= oes not know the regulatory domain it is in, then it does not know whether = authentication is required in that regulatory domain or not; so why would i= nitiate authentication then? Similar comment applies to draft-wei, where it= is proposed that after DB discovery the master device authenticates at TLS= layer and performs registration; how does it know that it has to authentic= ate and register, if it doesn't know the regulatory domain? In my opinion (chair hat off), the sequence of events should be sg like thi= s: 1. DB discovery (may be skipped if cached information available) 2. Regulatory domain query (may be skipped if cached information avai= lable) 3. Authentication (if required) 4. Registration (if required) 5. Channel availability query (may be combined with registration?) Comments are welcome and expected. - Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DA9008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’ve seen no objec= tions in having a DB initialization message, for the purpose of learning the operating rules for the regu= latory domain. My take is that this message is sent by the master device on= a need basis.

I am assuming we have agr= eement on this, so let’s take this into consideration for the wg docu= ment, and move forward.

 <= /p>

- =          Gabor<= /span>

 <= /p>

From: ext Rose= n, Brian [mailto:Brian.Rosen@neustar.biz]
Sent: Friday, August 17, 2012 6:01 AM
To: Bajko Gabor (Nokia-CIC/SiliconValley); paws@ietf.org
Subject: Re: [paws] need for DB initialization message

 

What I notice when I look a= t regulations is how we see different classes of information required at di= fferent points in the regulation-required interchanges  that wouldn't occur to us protocol designers.  I think it is foolish to ha= rd wire any specific piece of information to any specific protocol exchange= , because some regulator will do something we would classify as silly, but = the implementations are stuck.  As an example, in the US regulations, there is information that we would classif= y as "registration" data required to be in the "spectrum que= ry" message exchange.

 

So, I do see that a great d= eal of information exchanged will need to be flexible where it goes.

 

In this regard, I think tha= t when a device first connects to a database, there will be information exc= hanged, and I'll bet there will be circumstances where the information the client sends will depend in some way on information the se= rver has.  I think this may also happen on the spectrum query.  T= herefore, I would like to make sure that it's possible to have 3 way exchan= ges in all circumstances.  Client to server, server to client, client to server.   This is not a 3 way message exc= hange on an unreliable transport.  It lets the client send information= dependent on what it gets from the server.

 

So, my answer is more compl= ex.  I don't think we need a separate message to ask about the regulat= ory domain.  I think the "registration" message exchange is = a 3 way exchange.  If you wanted to send regulatory domain in the secon= d message, and get regulatory required information not sent in the first me= ssage sent in the third message of the transaction, that would work for me.=

 

Brian <as individual>=

 

From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
Date: Thu, 16 Aug 2012 19:11:40 -0400
To: "paws@ietf.org" &= lt;paws@ietf.org>
Subject: Re: [paws] need for DB initialization message

 

This thread was a bit der= ailed, so I’d like to get back to the original question, which was wh= ether we need a DB initialization message as proposed in draft-das or not.

 

We seem to converge on th= e discovery of the regulatory domain, ie that the regulatory domain can be = discovered during the DB discovery process, and we do not need a separate message to ask the DB what regulatory domain the master is= in.

 

Then, the question is whe= ther the masters need to contact the DB prior to any other communication, t= o learn the operating rules for that regulatory domain. The alternative would be that the masters are preconfigured with the opera= ting rules for the regulatory domains they are going to operate in.<= span style=3D"color:black">

 

In the F2F, there were op= inions on both sides, but not enough to call a consensus. So, please send y= our preference on the need for DB initialization, to the list. We need to make a decision on this and some other issues, so we coul= d move forward creating a wg document.

 

-    &= nbsp;     Gabor

 

From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
Sent: Thursday, August 09, 2012 5:15 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: paws@ietf.org
Subject: Re: [paws] need for DB initialization message

 =

<as individual>

I'm not so sure you need= something separate for domain.  ISTM that the DB discovery could retu= rn it (possibly as a parameter on the DB URI).  OTOH, you might very w= ell want to receive from the DB some kind of data specification (that is, what is required to be provided in the registratio= n), rather than having it totally wired in to domain.  That means, to = me, that the registration is a 4 way message exchange:

1. Device to DB: Authent= icate me please

2. DB to device: Authent= ication accepted, send me this data

3. Device to DB: Here is= my registration data

4. DB to device: Registr= ation succeeded.

 =

Now, having said that, y= ou might just get authentication out of the TLS session establishment, this= not needing step 1.

 =

Brian<= /p>

 =

On Aug 9, 2012, at 8:02 = PM, <Gabor.Bajko@nokia.com&= gt; wrote:




Folks,

 

During the Vancouver F2F di= scussions we had some good discussions, but no agreement on whether an init= ialization message, as proposed in draft-das is necessary or not.

You may check the minutes t= o see what was said at the mike: = ;http://www.ietf.org/proceedings/84/minutes= /minutes-84-paws

 

People spoke mostly in favo= r, but there were people who also said that this message is redundant with = registration message.<= /p>

 

Question#1: need for an ini= tialization message

Unfortunately we did not ha= ve time to discuss the DB discovery aspect, and that may be related to this= topic. The only DB discovery document available currently, http://www.iet= f.org/id/draft-probasco-paws-discovery-01.txt, proposes, that the master device contacts a pre-provisioned discovery serv= er and provides its location, and in return the discovery server returns th= e URI of the DB for that regulatory domain. At this point, the master devic= e knows which DB to contact, but it does not necessarily know what regulatory domain that DB belongs to. Th= us, it doesn’t know what are the operating rules, whether it has to a= uthenticate, or register, etc.

Thus, it seems logical to m= e that the master device first queries the DB to find out the regulatory do= main. We even have such a requirement in the requirement draft, requirement:

“P.3:   The= protocol MUST support determination of regulatory    &= nbsp;        domain governing its curren= t location.”

The information about the r= egulatory domain may be cached, and the master device may not need to place= that query every time, but this message exchange may be necessary in certain cases. Any comments to this point?

 

Question#2

Then, it is a slightly sepa= rate issue, if this message exchange has to take place, then what additiona= l information the DB returns. draft-das proposes that regulatory domain specific information be returned to the master device.

 

Question#3

Yet another separate point = is that draft-das proposes to use this initialization message also to initi= ate client authentication (putting shared secret vs cert issue aside for the time being). In cases when the master device does not = know the regulatory domain it is in, then it does not know whether authenti= cation is required in that regulatory domain or not; so why would initiate = authentication then? Similar comment applies to draft-wei, where it is proposed that after DB discovery the mas= ter device authenticates at TLS layer and performs registration; how does i= t know that it has to authenticate and register, if it doesn’t know t= he regulatory domain?<= /p>

 

In my opinion (chair hat of= f), the sequence of events should be sg like this:

 

   &n= bsp;   <= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:black">DB discovery (may be skipped if cached information available)

   &n= bsp;   <= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:black">Regulatory domain query (may be skipped if cached information available)

   &n= bsp;   <= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:black">Authentication (if required)

   &n= bsp;   <= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:black">Registration (if required)

   &n= bsp;   <= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:black">Channel availability query (may be combined with registration?)

 

Comments are welcome and ex= pected.

 

   &nb= sp;     &nbs= p;Gabor

 

 

 

_________________________= ______________________
paws mailing list
paws@ietf.org=
https://www.ietf.org/mailman/listinfo/paws

 =

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DA9008AM1MPN1006mg_-- From Gabor.Bajko@nokia.com Mon Aug 20 21:41:57 2012 Return-Path: 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 F333721F8532 for ; Mon, 20 Aug 2012 21:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.271 X-Spam-Level: X-Spam-Status: No, score=-6.271 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 5dM-dBYtw4O8 for ; Mon, 20 Aug 2012 21:41:46 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF6D21F8530 for ; Mon, 20 Aug 2012 21:41:45 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7L4ff8A009888 for ; Tue, 21 Aug 2012 07:41:43 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Aug 2012 07:41:40 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0283.004; Tue, 21 Aug 2012 06:41:39 +0200 From: To: Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Ie7Nd2WNzPm0+85/tpR52R7QAAU/5DAJlUv6AAAo7YAAAWoncAABh1noAAifZJAAAEHtqAAAHwqAAAEnPn8A== Date: Tue, 21 Aug 2012 04:41:38 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DBC@008-AM1MPN1-006.mgdnok.nokia.com> References: <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com> <8375F6DAEFB09F48815203F1FE23B797117AA6D8CF@shelby> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DBC008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 21 Aug 2012 04:41:40.0902 (UTC) FILETIME=[41F43C60:01CD7F57] X-Nokia-AV: Clean 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 04:41:57 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DBC008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Now I can't see anymore any willingness to agree on one or the other encodi= ng. To prevent endless discussions on this topic I'd suggest we move forward wi= th 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] On Behalf Of ext= Das, Subir Sent: Monday, August 20, 2012 2:50 PM To: Don Joslyn; Vincent Chen; Weixinpeng Cc: 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 nee= ded for XML From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Don Josly= n Sent: Monday, August 20, 2012 4:54 PM To: Vincent Chen; Weixinpeng Cc: 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-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: Monday, August 20, 2012 2:56 PM To: Weixinpeng Cc: 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 de= vice 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 encodin= g is better than both, as Brian points out. WiFi access points that "just w= ork" 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 (cli= ent-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 nee= ded 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 Goog= le 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 mor= e 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 w= e're clear on what device makers want. It would be good to get feedback fro= m device makers (especially of embedded devices) regarding experiences supp= orting 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 device= s) 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 muc= h or exchanged that often.] On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > 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-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; gabor.bajko@nokia.com; = vchen@google.com; peter@spectrumbridge.com Cc: 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 desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml option can also wor= k. JSON I think will necessitate implementation to be native Java and may n= ot be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DBC008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Now I can’t see any= more any willingness to agree on one or the other encoding.

To prevent endless discus= sions on this topic I’d suggest we move forward with supporting both = in the DB and either one in the master device.

Any objections?

 <= /p>

- =          Gabor<= /span>

 <= /p>

 <= /p>

From: paws-bou= nces@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; 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 foll= owing two important points:

 <= /p>

    • Simple-to-use libraries exist for all major languages/platforms
    • Don't need a tool chain to work with the dat= a, as is typically needed for XML

 <= /p>

 <= /p>

 <= /p>

From: paws-bounces@ietf.org [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; Manikkoth Sa= jeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

 

Please see my comments be= low…

Thanks,=

Don

 <= /p>

From: 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; Manikkoth Sa= jeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

 

  • One of our goals is to strive to lower the cost and complexity f= or device manufacturers. This lowers the barrier for building a robust ecos= ystem.

[DJ - The “cost&= #8221; 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 &#= 8220;cost”?]

  • To reduce complexity and cost for device makers, supporting 1 en= coding is better than both, as Brian points out. WiFi access points that &q= uot;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 t= o 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, FourS= quare, 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 an= d maps)
    • Simple-to-use libraries exist for all major languages/platforms<= o:p>
    • Don't need a tool chain to work with the data, as is typically n= eeded for XML.

Apparently, the efficiency gains of JSON also matter= to the scalability of serving systems.

=  

[DJ – I can̵= 7;t argue against these listed pros for JSON, especially when you’re = dealing with a lot of data (like Twitter, FourSquare, Facebook and Google d= oes). 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) r= egarding experiences supporting XML vs JSON.

 

Don, can you elaborate on the types of devices that = already support XML?

&n= bsp;

[DJ - We currently support half a dozen TVDB radio vendors (embedd= ed devices) using XML, non using JSON. XML has not been a burden, and the a= mount 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.co= m> wrote:

Considering of the design of database d= iscovery 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@iet= f.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; vchen@google.com; peter@spectru= mbridge.com


Cc: 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 m= atter of protocol design or implementation, but I am a big fan of reusing standards rather than defining new ones, and I would not wa= nt to see the choice of json mean we then decide to roll our own versus usi= ng 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 t= hat decisions made solely or even largely because of compactness advantages rarely are good choices.  If you like json because it is s= maller, 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>
Reply-To: Manikkoth Sajeev <mksaji@yahoo.com>
Date: Thu, 16 Aug 2012 22:37:38 -0400
To: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>, "Rosen, Brian"= ; <brian.ro= sen@neustar.biz>, "vchen@google.c= om" <vche= n@google.com>, "peter@spectrumbridge.com" <peter@spectrumbridge.com> Cc: "paws@ie= tf.org" <paw= s@ietf.org>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal<= o:p>

 

Hi,

 

Can it not be both JSON and XML supported? I would vote for that. Future im= plementations may prefer XML as it is generic, omni present, easy to understand and val= idate. For compactness may be a  binary xml option can also work. JSON I think will necessi= tate implementation to be native Java and may not be as friendly with other= implementation languages.

 

Best Regards,

 

From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
To: Bri= an.Rosen@neustar.biz; vchen@google.com;= peter@spectrumbridge.com
Cc: paws@ietf.org=
Sent: Friday, 17 August 2012, 4:55
Subject: Re: [paws] XML schema versus JSON, vCard & iCal<= o:p>


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-bounc= es@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'<= br> 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.&nbs= p; It's very easy to parse, and its simpler to use and debug.  Don't c= are a whole lot about that

Brian <as individual>



-----Original Message-----
From:     Vincent Chen [mailto:vchen@google.com]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard T= ime
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
Subject:    Re: [paws] XML schema versus JSON, vCard & i= Cal

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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries exist for numerous languages (see= of http://json.org/) and seem to be reasonably light weight.

Timestamps

As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries 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> wr= ote:


    Whenever we built mobile devices we never dealt with IET= F, in our sensor
    days even an IP stack was a challenge,so I would defer t= o the device guys
    on that one.
   
    On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian&= quot;
   
    <Brian.Rosen@neustar.biz> wrote:
   
    >Our experience in the IETF over many years is that e= conomizing 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 sh= ould seriously
    >consider the overhead of XML or json to be significa= nt.
    >
    >Assuming a json library can be loaded on a small dev= ice is reasonable.
    >
    >Brian (as individual)
    >
    >
    >
    > -----Original Message-----
    >From:  Peter Stanforth [mailto:peter@spectrumbridge.com]=
    >Sent:  Saturday, August 11, 2012 07:13 AM Easte= rn Standard Time
    >To:    Teco Boot; Benjamin A.Rolfe
    >Cc:    paws@ietf.org
    >Subject:      Re: [paws] XML schema v= ersus JSON, vCard & iCal
    >
    >Not all masters run over the core network.
    >Some of the Use cases have a master talking to anoth= er OTA
    >We should not assume that all Masters are attached t= o 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-ne= t.nl> wrote:
    >
    >>
    >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolf= e het volgende
    >>geschreven:
    >>
    >>> Compactness of messages is important, but i= t is also important (to me
    >>>at least) to be realizable in an implementat= ion with limited resources,
    >>>such as embedded devices in what are now pop= ularly called "M2M"
    >>>applications.  A lot of these devices c= ould use IP all the end to end,
    >>>but may have a very compact, simple stack an= d applications (i.e.  no
    >>>browser).  Is JSON typically implemente= d when there is no browser?
    >>>Would it be hard to do in a resource constra= ined device (i.e. where we
    >>>talk about memory size in Kilo-bytes still).=
    >>
    >>In use cases and requirements document, there ar= e 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 t= ake more than the PAWS
    >>message exchange, I think. This may be of import= ance when using satcom
    >>links.
    >>
    >>Because PAWS runs between master and database, o= ver core network,
    >>performance is not our primary concern. But as a= lways, 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 o= f "A JavaScript Object Notation
    >>>>(JSON) Representation for vCard"?     >>>> 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 notBe= fore&  notAfter.
    >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
    >>>>
    >>>> Teco
    >>>> _______________________________________= ________
    >>>> paws mailing list
    >>>> paws@ietf.org
    >>>> https://www.ietf.org/mailman/listinfo/paw= s
    >>>>
    >>>
    >>> ___________________________________________= ____
    >>> paws mailing list
    >>> paws@ietf.org
    >>> https://www.ietf.org/mailman/listinfo/paws
    >>
    >>_______________________________________________<= br>     >>paws mailing list
    >>paws@ietf.org
    >>https://www.ietf.org/mailman/listinfo/paws
    >
    >_______________________________________________
    >paws mailing list
    >p= aws@ietf.org
    >https://www.ietf.org/mailman/listinfo/paws
   
    _______________________________________________
    paws mailing list
    paws@= ietf.org
    https://www.ietf.org/mailman/listinfo/paws
   




--
-vince

_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws



 

--
-vince

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DBC008AM1MPN1006mg_-- From jstine@mitre.org Tue Aug 21 02:45:27 2012 Return-Path: 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 BB99521F86B4 for ; Tue, 21 Aug 2012 02:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 QGX2zywD0GCf for ; Tue, 21 Aug 2012 02:45:26 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B48A721F861D for ; Tue, 21 Aug 2012 02:45:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E67D721B09EC; Tue, 21 Aug 2012 05:45:24 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C103021B1546; Tue, 21 Aug 2012 05:45:24 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.151]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0309.002; Tue, 21 Aug 2012 05:45:24 -0400 From: "Stine, John A." To: "Gabor.Bajko@nokia.com" , "Brian.Rosen@neustar.biz" , "ben@blindcreek.com" Thread-Topic: [paws] use cases and requirements document Thread-Index: Ac132A+fbbG4lfLAT8aeYHhnRNTamABfuNkz///KeYD/+nkpcIAL38SAgATaWgCAAB0cgIAAMRUAgAAEjAD//1WqEP/+U5Dw Date: Tue, 21 Aug 2012 09:45:23 +0000 Message-ID: <2782C93FD2244441893673F3F912819206685893@IMCMBX01.MITRE.ORG> References: <50329616.3030207@blindcreek.com> <0FCA100D-7C67-47F6-A0C2-03B27F60545E@neustar.biz> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB5D8D@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB5D8D@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 09:45:27 -0000 Given a start and stop frequency, what are the constraints on the power spe= ctral flux density of out-of-band emissions? What is the criteria for a st= art and a stop frequency? Given start and stop times how would you convey periodic availability? Bei= ng available every day from say 12 to 6 AM may be perfect for a M2M applica= tions, for example meter reading. John -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gab= or.Bajko@nokia.com Sent: Tuesday, August 21, 2012 12:26 AM To: Brian.Rosen@neustar.biz; ben@blindcreek.com Cc: paws@ietf.org Subject: Re: [paws] use cases and requirements document Let's conclude this topic with agreeing on using start/stop times for each = spectrum unit available in ISO8601 format. I'll ask the editor to implement the two points we agreed on, namely: Requirement to identify the spectrum, by using the start/stop frequencies, = with optional channel identifiers; and Requirement to use start/stop times for each spectrum unit available in ISO= 8601 format and submit a new version of the use cases and requirements I-D, which the c= hairs will send to the iesg. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Rosen, Brian Sent: Monday, August 20, 2012 1:11 PM To: Benjamin A. Rolfe Cc: paws@ietf.org Subject: Re: [paws] use cases and requirements document I think you get a set of start/stop times for a given spectrum unit. That'= s all you need. There is a tradeoff in the complexity of a schedule received and how often = you have to come back to the database. The US rules provide one set of tra= deoffs. It's not clear to be they are great, but they are what they are. Imagine a device surrounded by lots of temporary use wireless microphones. = The U.S. rules may result in a response of dozens of schedule items, as th= e use comes and goes on multiple channels. It could theoretically be huge = - hundreds if not thousands of schedule items. While I doubt this would ha= ppen very often, I think it will be very difficult to put any kind of upper= bound on the number of schedule items (spectrum unit, start and stop times= ) a device may have to contend with. That makes for a complex implementation. We are no doubt stuck with it in = terms of what the protocol must be able to do. A better design would limit the number of schedule items to either a fixed = limit, or some limit expressed by the client. The client would then have t= o get back to the database sooner, to get more schedule. It may be that clients prefer to do that (that is, limit schedule in exchan= ge for shorter time to requery). That would not violate rules as long as t= he device didn't use channels for which it did not have accurate schedule. I think there might be a requirement there: the ability to limit the number= of schedule items returned, as well as a requirement to return when the re= turned schedule ends (i.e. when the database must be required to get more s= chedule). Brian On Aug 20, 2012, at 3:55 PM, Benjamin A. Rolfe wrote: > Peter makes a good point. The rules will allow a device to use channel=20 > availability data for as much as 48 hours - it allows that the device=20 > must access the database at least once per day, but if it tries and=20 > fails it can use the data until 11:59pm of the follow day. > > That wasn't the 48 hours I was thinking about though, I was thinking=20 > about the paragraph before that: > =A7 15.711 (b)(3)(i) > ... Fixed TVBD must adjust their use of channels in accordance with=20 > channel availability schedule information provided by their database=20 > for the 48-hour period beginning at the time of the device last=20 > accessed the database for a list of available channels. > > So in addition to providing what is available now, plus how things are=20 > expected to change over the next 48 hour period. I shouldn't have said=20 > "guess" since the requirements for notice from the priority users are=20 > greater than 48 hours. > > Having now discussed it "out loud" so to speak, it really does not=20 > need to be two distinct notions. The The "start/end" on a per channel=20 > basis provides what you need; and the database has to provide a=20 > schedule at the time of request that shows everything from now until now = + 48 hours. > > I also agree enthusiastically with Peter that we should expect changes=20 > in the requirements (and that is a guess, but an educated one ;-). > > Ben > >> Ben, >> FCC rules do assume that a channel assignment if from now until some=20 >> time in the future, the current default is 24 hours - unless the device = moves. >> It is same to assume that the duration will become much shorter=20 >> eventually. So "Valid until" is a reasonable proposition. However=20 >> the FCC does not preclude a radio from getting a channel list in=20 >> advance. In many ways it makes more sense for a device to ask for a=20 >> new channel list before it's current list expires so start time might be= relevant in this case. >> >> I don't think the FCC was proposing a "predictive guess". The actual=20 >> FCC rule is that a channel list is valid for 24hours, but if a device=20 >> cannot contact a database at that time it has permission to keep=20 >> using the channel list for a further 24hours (48hours total) I don't=20 >> think this is a good idea as it precludes a broadcaster reserving=20 >> channels inside that window, and, as mentioned above there is some=20 >> discussion about making the window much shorter to accommodate=20 >> situations where broadcasters cannot plan 24, or worst case 48 hours,=20 >> in advance. Personally I prefer that the device get a channel list=20 >> that is good for some period, without any ifs buts or maybes, and=20 >> then it has to query again. This is much simpler than trying to map=20 >> matrices of start/stop times for various channels (maybe with variable p= ower limits) over an extended period. >> Peter S. >> >> On MonAug/20/12 Mon Aug 20, 11:15 AM, "Benjamin A. Rolfe" >> wrote: >> >>> Thanks for the clarification. >>> There are also two notions of what "schedule" means, at least in the=20 >>> FCC rules. There is the notion that the current channel availability=20 >>> data has a expiration time, and thus there is a time in the future=20 >>> when updating will be necessary. This is at most a day. Based on FCC=20 >>> rules, this could be a local time determined by the device using the=20 >>> channel data, and if that device is acting as a source for dependent=20 >>> device "using" includes providing it to other dependent devices (and=20 >>> it would have to provide the "valid until" time). I can imagine that=20 >>> other regulatory bodies (and perhaps the FCC in the future) will=20 >>> require that channel availability data provided by the data base=20 >>> also be tagged with the "valid until" information. This does not=20 >>> require a start time, as "now" is implied. >>> >>> The other notion of schedule time is that the database contains a=20 >>> predictive guess as to what channels will be available for the next=20 >>> 48 hours into the future. This is required by FCC (though the device=20 >>> must still check at least once a day if what it is using is still=20 >>> valid). A start/stop pair is required for this. >>> >>> I think either format can be used to represent time in both cases.=20 >>> It is also possible that the 48-hour schedule is all that PAWS needs=20 >>> to provide to meet the regulations and the "valid until" can be=20 >>> derived from that by the using device. >>> Hope that helps. >>> -Ben >>> >>>> Uh, the difference is representation of start/stop times. We both=20 >>>> propose to send start/stop times. Vincent proposes that the=20 >>>> representation of time be a long integer seconds since an epoch. =20 >>>> He would send two such long integers. I propose it be an ISO 8601=20 >>>> time string. Specifically, I would propose an ISO 8601 interval=20 >>>> limited to start/end, e.g. >>>> 2011-03-01T13:00:00Z/2012-05-11T15:30:00Z. >>>> >>>> On 8/16/12 6:45 PM, "Gabor.Bajko@nokia.com" >>>> wrote: >>>> >>>>> It seems we have an agreement on the requirement to identify the=20 >>>>> spectrum, by using the start/stop frequencies, with optional=20 >>>>> channel identifiers. >>>>> >>>>> Wrt to the schedule, we have so far two proposals, one from Brian=20 >>>>> proposing the use of start/stop times for each spectrum unit=20 >>>>> available, and one from Vincent proposing to use of Unix Epoch=20 >>>>> time in seconds. We need to decide on this, so please send your=20 >>>>> preference on this topic to the list. >>>>> >>>>> - Gabor >>>>> >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=20 >>>>> Behalf Of Probasco Scott (Nokia-CIC/Dallas) >>>>> Sent: Monday, August 13, 2012 10:12 AM >>>>> To: paws@ietf.org >>>>> Subject: Re: [paws] use cases and requirements document >>>>> >>>>> Hi All, >>>>> >>>>> Given that we have completed two Working Group Last Call cycles=20 >>>>> and this next version will go to the IESG, I hope we could agree=20 >>>>> on minimal changes to the document, i.e. changes only to D.7 for=20 >>>>> this topic. This will ensure the proper requirements are=20 >>>>> established for the developing PAWS protocol. >>>>> I believe Brian's proposed text captures the essential requirements. >>>>> >>>>> Kind Regards, >>>>> Scott >>>>> >>>>> >>>>> On 8/13/12 8:24 AM, "ext Rosen, Brian" wrot= e: >>>>> >>>>>> >>>>>> I would prefer to not use the word "channel" in our documents at=20 >>>>>> all except for the term "channel identifier". I proposed=20 >>>>>> "spectrum unit", although any other term will do. "Channel" has=20 >>>>>> too much baggage, A simple editorial change like this is simple,=20 >>>>>> and it's much better to do it now. >>>>>> >>>>>> I think we need power in both the query and the response. In=20 >>>>>> some domains, it may be that you specify what power you want to=20 >>>>>> use and the DB tells you what spectrum you can use at that power. =20 >>>>>> In other, a US-like rule may be in place. Also in either the=20 >>>>>> query or the registration, we need a device type, which should be=20 >>>>>> an entry from an IANA registry. This is how you get the US "Mode II= " information. >>>>>> >>>>>> With regard to schedule, I would like to see two mechanisms >>>>>> 1) a time by which the database should be queried again (which=20 >>>>>> could represent the next change in schedule) >>>>>> 2) start/stop times for each spectrum unit available >>>>>> >>>>>> Both these should be optional in the response. >>>>>> >>>>>> My text >>>>>> >>>>>> The data model must support specifying spectrum availability. >>>>>> Spectrum >>>>>> units are specified by low and high frequencies and may have an=20 >>>>>> optional channel identifier. >>>>>> >>>>>> The data model must support a schedule for spectrum unit availabilit= y. >>>>>> Two mechanisms must be supported. The response to spectrum=20 >>>>>> availability query may include a time by which the database must=20 >>>>>> be requeried. Each spectrum unit mentioned in the response may=20 >>>>>> be annotated with start and stop time/date. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Eric Chu [mailto:ericchu@google.com] >>>>>> Sent: Saturday, August 11, 2012 11:43 AM Eastern Standard Time >>>>>> To: Teco Boot >>>>>> Cc: Rosen, Brian; paws@ietf.org >>>>>> Subject: Re: [paws] use cases and requirements document >>>>>> >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> Gathering all the shared points from everyone... I believe below=20 >>>>>> is the complete list so far: >>>>>> >>>>>> >>>>>> >>>>>> * What's the best consistent representation of the words "channel >>>>>> numbers" for non-TV spectrum >>>>>> * Should we update the entire doc on the topic of =B3channel=B2 o= r >>>>>> =B3channel numbers=B2 >>>>>> * What=B9s the best way to reduce vagueness in whether/how to inc= lude >>>>>> "channel numbers" >>>>>> * Is the reference to variable power required >>>>>> * What does channel availability schedule mean >>>>>> >>>>>> >>>>>> Brian's suggestion of replacing every instance of "channel" is=20 >>>>>> technically correctly. However, it is important for us to focus=20 >>>>>> moving forward. I would suggest we only work on the normative=20 >>>>>> part of the spec. >>>>>> The section Gabor is proposing for us to modify... >>>>>> >>>>>> On what's the best generic label for the words "channel numbers",=20 >>>>>> channel identifier might be the most accurate and neutral "label". >>>>>> Thoughts? >>>>>> >>>>>> On the question whether variable power is required, based on FCC=20 >>>>>> adjacent-channel rules, the database may limit the Mode II=20 >>>>>> devices to 100mW for some channels and 40mW for others.=20 >>>>>> Therefore, the data model needs to support specification of maximum = power levels. >>>>>> >>>>>> Lastly, with regards to "schedule", the intent is to have a way=20 >>>>>> of informing devices when to operate for each frequency range. As=20 >>>>>> long as the data model supports, for example, a list of time=20 >>>>>> ranges, it does not prevent an implementation from providing a=20 >>>>>> list with 1 entry which corresponds to the "shortest available". =20 >>>>>> The word "schedule" should be sufficient to capture this intent? >>>>>> >>>>>> We would like to propose the following text to address these points: >>>>>> >>>>>> "The Data Model MUST support specifying available spectrum. The=20 >>>>>> Data Model MUST support specification of this information by=20 >>>>>> start and stop frequencies and MAY also support specification of=20 >>>>>> this information by channel identifiers. The Data Model MUST=20 >>>>>> support a spectrum-availability schedule and maximum power levels=20 >>>>>> for each frequency range." >>>>>> >>>>>> >>>>>> Thoughts? >>>>>> Eric >>>>>> >>>>>> >>>>>> >>>>>> On 8/10/12 5:48 AM, Teco Boot wrote: >>>>>> >>>>>> >>>>>> What about this: >>>>>> >>>>>> =B3The Data Model MUST support specifying a list of available= =20 >>>>>> channels. The Data Model MUST support specification of this=20 >>>>>> information by start and stop frequencies, or equivalents such as=20 >>>>>> center frequencies with channel width or channel numbers with=20 >>>>>> channel nummer allocation scheme . The Data Model MUST support a=20 >>>>>> channel availability schedule and maximum power level for each=20 >>>>>> channel in the list.=B2 >>>>>> >>>>>> More thoughts on channel numbers: we likely run into problems=20 >>>>>> in bands without a channel numbering scheme, or for example sub=20 >>>>>> channels in TV bands. >>>>>> >>>>>> Teco >>>>>> >>>>>> >>>>>> Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende >>>>>> geschreven: >>>>>> >>>>>> >>>>>> >>>>>> While I don't care if it's center and width or upper/lower,=20 >>>>>> I do think we will define the format in the protocol for=20 >>>>>> interoperability reasons, but don't need to do that in=20 >>>>>> requirements. It wouldn't hurt to decide now and use consistent=20 >>>>>> terms, but we don't need to. >>>>>> >>>>>> I think "band" won't work, as it usually implies a much=20 >>>>>> wider piece of spectrum that has a common purpose. The TV Band=20 >>>>>> is all the channels. >>>>>> >>>>>> >>>>>> On Aug 10, 2012, at 2:37 AM, Teco Boot wrote= : >>>>>> >>>>>> >>>>>> (somewhat late response) >>>>>> >>>>>> A center frequency and channel width is functional=20 >>>>>> equivalent to start/stop frequencies. So is channel number, with=20 >>>>>> ref to channel number assignment scheme. For a requirements=20 >>>>>> document, we just need to specify what is needed. How it is=20 >>>>>> encoded (Hz, wave length, channel ID) is solution space. >>>>>> >>>>>> Seen our goal to make PAWS somewhat universal (not=20 >>>>>> limited to US TVWS), I do not prefer using channel numbers. >>>>>> >>>>>> Teco >>>>>> >>>>>> >>>>>> Op 9 aug. 2012, om 21:55 heeft =20 >>>>>> het volgende geschreven: >>>>>> >>>>>> >>>>>> Folks, >>>>>> >>>>>> During the last F2F meeting, there was an agreement=20 >>>>>> to make a slight update to requirement D.7 in >>>>>> >>>>>> http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmt >>>>>> s-06.t xt, to make channel numbers optional to be supported. Ie,=20 >>>>>> change the current >>>>>> D.7 >>>>>> =B3The Data Model MUST support specifying a list of=20 >>>>>> available channels. The Data Model MUST support specification of=20 >>>>>> this information by channel numbers and by start and stop=20 >>>>>> frequencies. The Data Model MUST support a channel availability=20 >>>>>> schedule and maximum power level for each channel in the list.=B2 >>>>>> to >>>>>> =B3The Data Model MUST support specifying a list of=20 >>>>>> available channels. The Data Model MUST support specification of=20 >>>>>> this information by start and stop frequencies and MAY include=20 >>>>>> channel numbers. The Data Model MUST support a channel=20 >>>>>> availability schedule and maximum power level for each channel in=20 >>>>>> the list.=B2 >>>>>> >>>>>> I=B9d like to confirm this change on the list. If=20 >>>>>> anyone has any objections, let me know. Otherwise I=B9ll plan to=20 >>>>>> send the document to the iesg after this change is implemented. >>>>>> >>>>>> - Gabor >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From ben@blindcreek.com Tue Aug 21 08:37:55 2012 Return-Path: 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 D9D6121F8551 for ; Tue, 21 Aug 2012 08:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599] 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 kZoaZcj9wycL for ; Tue, 21 Aug 2012 08:37:54 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id ED25C21F8516 for ; Tue, 21 Aug 2012 08:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=LGgzd823ByVnMYcj+RJfIeM9Zl4DfkceJUoruFypRpY=; b=jyO9bKpWbKNkHzxb5uKbyHjfxAN3U4XN4XWzFlX3ZKzQqIOivyOhxfvn53W/5Oqzws+ebVURiTPD5SCnlHY/jGe7JEsVHohQuLTCqgW3yHfePk8YuegMWQlmbvSk/lmE; Received: from [64.74.213.174] (port=61739 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1T3qWd-0003K4-5y for paws@ietf.org; Tue, 21 Aug 2012 10:37:51 -0500 Message-ID: <5033AB55.10205@blindcreek.com> Date: Tue, 21 Aug 2012 08:37:57 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: "paws@ietf.org" References: <50329616.3030207@blindcreek.com> <0FCA100D-7C67-47F6-A0C2-03B27F60545E@neustar.biz> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB5D8D@008-AM1MPN1-006.mgdnok.nokia.com> <2782C93FD2244441893673F3F912819206685893@IMCMBX01.MITRE.ORG> In-Reply-To: <2782C93FD2244441893673F3F912819206685893@IMCMBX01.MITRE.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:37:56 -0000 Based on the FCC rules, the isn't a need for "every day at" since the WS device must access the database at least once per day (with the exception mentioned). My reading of the OfCom recommendation has similar requirements to check with the database and what I have seen presented for work by other regulatory domains it will be more frequently still. The transitory protected users (wireless microphones) may, though, have a scheduled time of use that may be less than a day. If we specify when the channel IS available, you could see the need for multiple times: if there is an event makes the TV channel unavailable for 4 hours out of a 24 hour period, the inverse (available) would be two blocks around that 4 hour period. So perhaps for each channel we have a spectrum unit definition and a list of available times which spans the scheduled period required by the regulatory domain (48 hours in the US, probably less elsewhere in the future). For a device that may be active once a day for a period as John describes, it would have to refresh it's channel data at each "wake up" if it's been sleeping for a day or more. This is very likely in M2M applications. When we look at this scenario, the assumption we have made that the process for acquiring channel availability schedule will be "infrequent" becomes false from the perspective of the sleepy device, as it will have to be done every time it wakes up. In some M2M applications, it is quite likely that the device may wake up once per day, exchange a handful of octets of data, and then resume sleeping. In this scenario the PAWS exchange would be the majority of time on air. I don't think this is the dominant use case for PAWS though, and other protocols are being developed specifically to address this sort of situation effectively (and assume an intermediate device does the internet access). just another two cents worth... > Given a start and stop frequency, what are the constraints on the power spectral flux density of out-of-band emissions? What is the criteria for a start and a stop frequency? > > Given start and stop times how would you convey periodic availability? Being available every day from say 12 to 6 AM may be perfect for a M2M applications, for example meter reading. > > John > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com > Sent: Tuesday, August 21, 2012 12:26 AM > To: Brian.Rosen@neustar.biz; ben@blindcreek.com > Cc: paws@ietf.org > Subject: Re: [paws] use cases and requirements document > > Let's conclude this topic with agreeing on using start/stop times for each spectrum unit available in ISO8601 format. > I'll ask the editor to implement the two points we agreed on, namely: > > Requirement to identify the spectrum, by using the start/stop frequencies, with optional channel identifiers; and > Requirement to use start/stop times for each spectrum unit available in ISO8601 format > > and submit a new version of the use cases and requirements I-D, which the chairs will send to the iesg. > > - Gabor > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Rosen, Brian > Sent: Monday, August 20, 2012 1:11 PM > To: Benjamin A. Rolfe > Cc: paws@ietf.org > Subject: Re: [paws] use cases and requirements document > > > I think you get a set of start/stop times for a given spectrum unit. That's all you need. > > There is a tradeoff in the complexity of a schedule received and how often you have to come back to the database. The US rules provide one set of tradeoffs. It's not clear to be they are great, but they are what they are. > > Imagine a device surrounded by lots of temporary use wireless microphones. The U.S. rules may result in a response of dozens of schedule items, as the use comes and goes on multiple channels. It could theoretically be huge - hundreds if not thousands of schedule items. While I doubt this would happen very often, I think it will be very difficult to put any kind of upper bound on the number of schedule items (spectrum unit, start and stop times) a device may have to contend with. > > That makes for a complex implementation. We are no doubt stuck with it in terms of what the protocol must be able to do. > > A better design would limit the number of schedule items to either a fixed limit, or some limit expressed by the client. The client would then have to get back to the database sooner, to get more schedule. > > It may be that clients prefer to do that (that is, limit schedule in exchange for shorter time to requery). That would not violate rules as long as the device didn't use channels for which it did not have accurate schedule. > > I think there might be a requirement there: the ability to limit the number of schedule items returned, as well as a requirement to return when the returned schedule ends (i.e. when the database must be required to get more schedule). > > Brian > > On Aug 20, 2012, at 3:55 PM, Benjamin A. Rolfe wrote: > >> Peter makes a good point. The rules will allow a device to use channel >> availability data for as much as 48 hours - it allows that the device >> must access the database at least once per day, but if it tries and >> fails it can use the data until 11:59pm of the follow day. >> >> That wasn't the 48 hours I was thinking about though, I was thinking >> about the paragraph before that: >> § 15.711 (b)(3)(i) >> ... Fixed TVBD must adjust their use of channels in accordance with >> channel availability schedule information provided by their database >> for the 48-hour period beginning at the time of the device last >> accessed the database for a list of available channels. >> >> So in addition to providing what is available now, plus how things are >> expected to change over the next 48 hour period. I shouldn't have said >> "guess" since the requirements for notice from the priority users are >> greater than 48 hours. >> >> Having now discussed it "out loud" so to speak, it really does not >> need to be two distinct notions. The The "start/end" on a per channel >> basis provides what you need; and the database has to provide a >> schedule at the time of request that shows everything from now until now + 48 hours. >> >> I also agree enthusiastically with Peter that we should expect changes >> in the requirements (and that is a guess, but an educated one ;-). >> >> Ben >> >>> Ben, >>> FCC rules do assume that a channel assignment if from now until some >>> time in the future, the current default is 24 hours - unless the device moves. >>> It is same to assume that the duration will become much shorter >>> eventually. So "Valid until" is a reasonable proposition. However >>> the FCC does not preclude a radio from getting a channel list in >>> advance. In many ways it makes more sense for a device to ask for a >>> new channel list before it's current list expires so start time might be relevant in this case. >>> >>> I don't think the FCC was proposing a "predictive guess". The actual >>> FCC rule is that a channel list is valid for 24hours, but if a device >>> cannot contact a database at that time it has permission to keep >>> using the channel list for a further 24hours (48hours total) I don't >>> think this is a good idea as it precludes a broadcaster reserving >>> channels inside that window, and, as mentioned above there is some >>> discussion about making the window much shorter to accommodate >>> situations where broadcasters cannot plan 24, or worst case 48 hours, >>> in advance. Personally I prefer that the device get a channel list >>> that is good for some period, without any ifs buts or maybes, and >>> then it has to query again. This is much simpler than trying to map >>> matrices of start/stop times for various channels (maybe with variable power limits) over an extended period. >>> Peter S. >>> >>> On MonAug/20/12 Mon Aug 20, 11:15 AM, "Benjamin A. Rolfe" >>> wrote: >>> >>>> Thanks for the clarification. >>>> There are also two notions of what "schedule" means, at least in the >>>> FCC rules. There is the notion that the current channel availability >>>> data has a expiration time, and thus there is a time in the future >>>> when updating will be necessary. This is at most a day. Based on FCC >>>> rules, this could be a local time determined by the device using the >>>> channel data, and if that device is acting as a source for dependent >>>> device "using" includes providing it to other dependent devices (and >>>> it would have to provide the "valid until" time). I can imagine that >>>> other regulatory bodies (and perhaps the FCC in the future) will >>>> require that channel availability data provided by the data base >>>> also be tagged with the "valid until" information. This does not >>>> require a start time, as "now" is implied. >>>> >>>> The other notion of schedule time is that the database contains a >>>> predictive guess as to what channels will be available for the next >>>> 48 hours into the future. This is required by FCC (though the device >>>> must still check at least once a day if what it is using is still >>>> valid). A start/stop pair is required for this. >>>> >>>> I think either format can be used to represent time in both cases. >>>> It is also possible that the 48-hour schedule is all that PAWS needs >>>> to provide to meet the regulations and the "valid until" can be >>>> derived from that by the using device. >>>> Hope that helps. >>>> -Ben >>>> >>>>> Uh, the difference is representation of start/stop times. We both >>>>> propose to send start/stop times. Vincent proposes that the >>>>> representation of time be a long integer seconds since an epoch. >>>>> He would send two such long integers. I propose it be an ISO 8601 >>>>> time string. Specifically, I would propose an ISO 8601 interval >>>>> limited to start/end, e.g. >>>>> 2011-03-01T13:00:00Z/2012-05-11T15:30:00Z. >>>>> >>>>> On 8/16/12 6:45 PM, "Gabor.Bajko@nokia.com" >>>>> wrote: >>>>> >>>>>> It seems we have an agreement on the requirement to identify the >>>>>> spectrum, by using the start/stop frequencies, with optional >>>>>> channel identifiers. >>>>>> >>>>>> Wrt to the schedule, we have so far two proposals, one from Brian >>>>>> proposing the use of start/stop times for each spectrum unit >>>>>> available, and one from Vincent proposing to use of Unix Epoch >>>>>> time in seconds. We need to decide on this, so please send your >>>>>> preference on this topic to the list. >>>>>> >>>>>> - Gabor >>>>>> >>>>>> -----Original Message----- >>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>> Behalf Of Probasco Scott (Nokia-CIC/Dallas) >>>>>> Sent: Monday, August 13, 2012 10:12 AM >>>>>> To: paws@ietf.org >>>>>> Subject: Re: [paws] use cases and requirements document >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Given that we have completed two Working Group Last Call cycles >>>>>> and this next version will go to the IESG, I hope we could agree >>>>>> on minimal changes to the document, i.e. changes only to D.7 for >>>>>> this topic. This will ensure the proper requirements are >>>>>> established for the developing PAWS protocol. >>>>>> I believe Brian's proposed text captures the essential requirements. >>>>>> >>>>>> Kind Regards, >>>>>> Scott >>>>>> >>>>>> >>>>>> On 8/13/12 8:24 AM, "ext Rosen, Brian" wrote: >>>>>> >>>>>>> >>>>>>> I would prefer to not use the word "channel" in our documents at >>>>>>> all except for the term "channel identifier". I proposed >>>>>>> "spectrum unit", although any other term will do. "Channel" has >>>>>>> too much baggage, A simple editorial change like this is simple, >>>>>>> and it's much better to do it now. >>>>>>> >>>>>>> I think we need power in both the query and the response. In >>>>>>> some domains, it may be that you specify what power you want to >>>>>>> use and the DB tells you what spectrum you can use at that power. >>>>>>> In other, a US-like rule may be in place. Also in either the >>>>>>> query or the registration, we need a device type, which should be >>>>>>> an entry from an IANA registry. This is how you get the US "Mode II" information. >>>>>>> >>>>>>> With regard to schedule, I would like to see two mechanisms >>>>>>> 1) a time by which the database should be queried again (which >>>>>>> could represent the next change in schedule) >>>>>>> 2) start/stop times for each spectrum unit available >>>>>>> >>>>>>> Both these should be optional in the response. >>>>>>> >>>>>>> My text >>>>>>> >>>>>>> The data model must support specifying spectrum availability. >>>>>>> Spectrum >>>>>>> units are specified by low and high frequencies and may have an >>>>>>> optional channel identifier. >>>>>>> >>>>>>> The data model must support a schedule for spectrum unit availability. >>>>>>> Two mechanisms must be supported. The response to spectrum >>>>>>> availability query may include a time by which the database must >>>>>>> be requeried. Each spectrum unit mentioned in the response may >>>>>>> be annotated with start and stop time/date. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Eric Chu [mailto:ericchu@google.com] >>>>>>> Sent: Saturday, August 11, 2012 11:43 AM Eastern Standard Time >>>>>>> To: Teco Boot >>>>>>> Cc: Rosen, Brian; paws@ietf.org >>>>>>> Subject: Re: [paws] use cases and requirements document >>>>>>> >>>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> Gathering all the shared points from everyone... I believe below >>>>>>> is the complete list so far: >>>>>>> >>>>>>> >>>>>>> >>>>>>> * What's the best consistent representation of the words "channel >>>>>>> numbers" for non-TV spectrum >>>>>>> * Should we update the entire doc on the topic of ³channel² or >>>>>>> ³channel numbers² >>>>>>> * What¹s the best way to reduce vagueness in whether/how to include >>>>>>> "channel numbers" >>>>>>> * Is the reference to variable power required >>>>>>> * What does channel availability schedule mean >>>>>>> >>>>>>> >>>>>>> Brian's suggestion of replacing every instance of "channel" is >>>>>>> technically correctly. However, it is important for us to focus >>>>>>> moving forward. I would suggest we only work on the normative >>>>>>> part of the spec. >>>>>>> The section Gabor is proposing for us to modify... >>>>>>> >>>>>>> On what's the best generic label for the words "channel numbers", >>>>>>> channel identifier might be the most accurate and neutral "label". >>>>>>> Thoughts? >>>>>>> >>>>>>> On the question whether variable power is required, based on FCC >>>>>>> adjacent-channel rules, the database may limit the Mode II >>>>>>> devices to 100mW for some channels and 40mW for others. >>>>>>> Therefore, the data model needs to support specification of maximum power levels. >>>>>>> >>>>>>> Lastly, with regards to "schedule", the intent is to have a way >>>>>>> of informing devices when to operate for each frequency range. As >>>>>>> long as the data model supports, for example, a list of time >>>>>>> ranges, it does not prevent an implementation from providing a >>>>>>> list with 1 entry which corresponds to the "shortest available". >>>>>>> The word "schedule" should be sufficient to capture this intent? >>>>>>> >>>>>>> We would like to propose the following text to address these points: >>>>>>> >>>>>>> "The Data Model MUST support specifying available spectrum. The >>>>>>> Data Model MUST support specification of this information by >>>>>>> start and stop frequencies and MAY also support specification of >>>>>>> this information by channel identifiers. The Data Model MUST >>>>>>> support a spectrum-availability schedule and maximum power levels >>>>>>> for each frequency range." >>>>>>> >>>>>>> >>>>>>> Thoughts? >>>>>>> Eric >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 8/10/12 5:48 AM, Teco Boot wrote: >>>>>>> >>>>>>> >>>>>>> What about this: >>>>>>> >>>>>>> ³The Data Model MUST support specifying a list of available >>>>>>> channels. The Data Model MUST support specification of this >>>>>>> information by start and stop frequencies, or equivalents such as >>>>>>> center frequencies with channel width or channel numbers with >>>>>>> channel nummer allocation scheme . The Data Model MUST support a >>>>>>> channel availability schedule and maximum power level for each >>>>>>> channel in the list.² >>>>>>> >>>>>>> More thoughts on channel numbers: we likely run into problems >>>>>>> in bands without a channel numbering scheme, or for example sub >>>>>>> channels in TV bands. >>>>>>> >>>>>>> Teco >>>>>>> >>>>>>> >>>>>>> Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende >>>>>>> geschreven: >>>>>>> >>>>>>> >>>>>>> >>>>>>> While I don't care if it's center and width or upper/lower, >>>>>>> I do think we will define the format in the protocol for >>>>>>> interoperability reasons, but don't need to do that in >>>>>>> requirements. It wouldn't hurt to decide now and use consistent >>>>>>> terms, but we don't need to. >>>>>>> >>>>>>> I think "band" won't work, as it usually implies a much >>>>>>> wider piece of spectrum that has a common purpose. The TV Band >>>>>>> is all the channels. >>>>>>> >>>>>>> >>>>>>> On Aug 10, 2012, at 2:37 AM, Teco Boot wrote: >>>>>>> >>>>>>> >>>>>>> (somewhat late response) >>>>>>> >>>>>>> A center frequency and channel width is functional >>>>>>> equivalent to start/stop frequencies. So is channel number, with >>>>>>> ref to channel number assignment scheme. For a requirements >>>>>>> document, we just need to specify what is needed. How it is >>>>>>> encoded (Hz, wave length, channel ID) is solution space. >>>>>>> >>>>>>> Seen our goal to make PAWS somewhat universal (not >>>>>>> limited to US TVWS), I do not prefer using channel numbers. >>>>>>> >>>>>>> Teco >>>>>>> >>>>>>> >>>>>>> Op 9 aug. 2012, om 21:55 heeft >>>>>>> het volgende geschreven: >>>>>>> >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> During the last F2F meeting, there was an agreement >>>>>>> to make a slight update to requirement D.7 in >>>>>>> >>>>>>> http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmt >>>>>>> s-06.t xt, to make channel numbers optional to be supported. Ie, >>>>>>> change the current >>>>>>> D.7 >>>>>>> ³The Data Model MUST support specifying a list of >>>>>>> available channels. The Data Model MUST support specification of >>>>>>> this information by channel numbers and by start and stop >>>>>>> frequencies. The Data Model MUST support a channel availability >>>>>>> schedule and maximum power level for each channel in the list.² >>>>>>> to >>>>>>> ³The Data Model MUST support specifying a list of >>>>>>> available channels. The Data Model MUST support specification of >>>>>>> this information by start and stop frequencies and MAY include >>>>>>> channel numbers. The Data Model MUST support a channel >>>>>>> availability schedule and maximum power level for each channel in >>>>>>> the list.² >>>>>>> >>>>>>> I¹d like to confirm this change on the list. If >>>>>>> anyone has any objections, let me know. Otherwise I¹ll plan to >>>>>>> send the document to the iesg after this change is implemented. >>>>>>> >>>>>>> - Gabor >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From d.joslyn@spectrumbridge.com Thu Aug 23 11:15:18 2012 Return-Path: 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 6085621F8504 for ; Thu, 23 Aug 2012 11:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] 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 S2g7Zp9MQzfo for ; Thu, 23 Aug 2012 11:15:11 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id EC77E21F8565 for ; Thu, 23 Aug 2012 11:15:08 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Thu, 23 Aug 2012 14:15:07 -0400 From: Don Joslyn To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Date: Thu, 23 Aug 2012 14:15:06 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Ie7Nd2WNzPm0+85/tpR52R7QAAU/5DAJlUv6AAAo7YAAAWoncAABh1noAAifZJAAAEHtqAAAHwqAAAEnPn8ACBGaEA Message-ID: <8375F6DAEFB09F48815203F1FE23B797117AA6D9E1@shelby> References: <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com> <8375F6DAEFB09F48815203F1FE23B797117AA6D8CF@shelby> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DBC@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DBC@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B797117AA6D9E1shelby_" MIME-Version: 1.0 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 18:15:18 -0000 --_000_8375F6DAEFB09F48815203F1FE23B797117AA6D9E1shelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sounds good to me. From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gab= or.Bajko@nokia.com Sent: Tuesday, August 21, 2012 12:42 AM To: 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 encodi= ng. To prevent endless discussions on this topic I'd suggest we move forward wi= th supporting both in the DB and either one in the master device. Any objections? - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@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; 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 need= ed for XML From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Don Josly= n Sent: Monday, August 20, 2012 4:54 PM To: Vincent Chen; Weixinpeng Cc: 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-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: Monday, August 20, 2012 2:56 PM To: Weixinpeng Cc: 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 dev= ice 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 wo= rk" 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 (clie= nt-side) prefer it for its simplicity: * Representation closely matches most data models (nested lists and m= aps) * Simple-to-use libraries exist for all major languages/platforms * Don't need a tool chain to work with the data, as is typically need= ed 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 Goog= le 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 mor= e efficient, can't argue with that.] * At the end of the day, it's the data model that matters, rather than t= he 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 suppo= rting 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 device= s) 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 muc= h or exchanged that often.] On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > 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-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; gabor.bajko@nokia.com; = vchen@google.com; peter@spectrumbridge.com Cc: 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 desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml option can also wor= k. JSON I think will necessitate implementation to be native Java and may n= ot be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_8375F6DAEFB09F48815203F1FE23B797117AA6D9E1shelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sounds go= od to me.

 

From: paws-bounces@ietf.org [m= ailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
<= b>Sent: Tuesday, August 21, 2012 12:42 AM
To: paws@ietf.orgSubject: Re: [paws] XML schema versus JSON, vCard & iCal<= /o:p>

 

Now I can’t see anymore any willingness to agr= ee on one or the other encoding.

To prevent endless discussions on this topic I’d suggest we m= ove forward with supporting both in the DB and either one in the master dev= ice.

Any objections?<= /o:p>

 

-       = ;   Gabor=

 

 

From= : 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; Manikkoth Sajeev
Subj= ect: Re: [paws] XML schema versus JSON, vCard & iCal

 

We have a half a dozen or more TVDB radio vendors that use/pr= efer JSON and we will vote for JSON if we had to pick one.

Also I will copy the following two import= ant 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 n= eeded for XML

<= o:p> 

 

 

From: paws-b= ounces@ietf.org [mail= to:paws-bounces@ietf.org] On Behalf Of Don Joslyn
Sent: Monday, August 20, 2012 4:54 PM
To: Vincent Chen; WeixinpengCc: paws@ietf.org; Manikkoth S= ajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCa= l

 

Please see my comments below…

Thanks,

Don

=  

From: 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= ; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vC= ard & iCal

 <= /o:p>

  • One of our goals is to strive to lower the cost and complexity for= device manufacturers. This lowers the barrier for building a robust ecosys= tem.

[DJ - The “cost” and complexity of using XML has not be= en an issue for the half dozen TVBD vendors that have already used XML. May= be we need to better define “cost”?]

  • To reduce complexity and cost for device ma= kers, 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 JSO= N, devices only need to support one to talk to the database. Our current da= tabase supports XML and JSON, but if I’m forced to pick only one, the= n I will vote for XML because it’s the one that we currently use on a= ll embedded devices.]<= /p>

  • There's a trend for APIs on the web towards JSON (Twitter, FourSquare, F= acebook, 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)<= /li>
    • Simple-to-us= e libraries exist for all major languages/platforms
      • <= li class=3DMsoNormal style=3D'color:black;mso-margin-top-alt:auto;mso-margi= n-bottom-alt:auto;mso-list:l4 level2 lfo5;vertical-align:baseline'>Don't need a tool= chain to work with the data, as is typically needed for XML.

Apparently, the ef= ficiency gains of JSON also matter to the scalability of serving systems.

 = ;

[DJ &#= 8211; I can’t argue against these listed pros for JSON, especially wh= en you’re dealing with a lot of data (like Twitter, FourSquare, Faceb= ook 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 fr= om device makers (especially of embedded devices) regarding experiences sup= porting XML vs JSON.

 

Don, can you elaborate on the t= ypes 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 amo= unt of data that needs to be exchanged between device and database is not t= hat much or exchanged that often.]

On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng <weixinpeng@huawei.com> wrote:=

Considering of the design of databas= e discovery protocol, the LoST protocol may be used and LoST is based on XM= L, so I think XML may be preferred.

&nbs= p;

--Xinpeng Wei

 

From: paws-bounces@ietf.org = [mailto:paws-bou= nces@ietf.org] On Behalf Of Rosen, Brian


Sent: Friday, August 17, 2012 9:26 PM

To: Manikkoth Sajeev; gabor.bajko@nokia.com; vchen@google.com<= /a>; peter@sp= ectrumbridge.com


Cc= : paws@ietf.org<= br>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 de= sign 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 id= ea there is no json representation of an existing standard.  So, if ch= oosing json means folks feel free to ignore existing xml based standards su= ch as xCard and LoST, then I would not want to use json.<= /p>

 

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 hav= e to implement both and the client can implement either.<= /p>

 

There are json validat= ors, so I don't think that is a big deal.  

 

My experience in protocol desi= gn on the Internet is that decisions made solely or even largely because of= compactness advantages rarely are good choices.  If you like json bec= ause it is smaller, then I believe you need a much better reason.  Bin= ary doesn't work for me, at all.  I have been involved in big binary v= s text wars in protocol design.  Text wins, binary loses, in my opinio= n.

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>B= rian <as individual>

 

From: Manikkoth Sajeev <mksaji@yahoo.com>
Repl= y-To: Manikkoth Sajeev <mksaji@yahoo.com>
Date: Thu, 16 Aug 2012 22:37= :38 -0400
To: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>, "Rose= n, Brian" <brian.rosen@neustar.biz>, "vchen@google.com" <vchen@google.com>, "peter@spectrumbridge.co= m" <peter@spectrumbridge.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

=

 

Hi,

 =

Can it not be both JSON a= nd XML supported? I would vote for that. Future implementations may prefer = XML as it is generic, omni present, easy to understand and val= idate. For compactness may be a  binary xml option can also work. JSON I think will necessitate implementation to be na= tive Java and may not be as friendly with other implementation languages.

 

=

Best Regards,=

 

From: "Gabor.Bajko@nokia.com&quo= t; <Gabor.Baj= ko@nokia.com>
To: Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com
C= c: 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 i= nstead 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] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:1= 4 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: '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.&n= bsp; 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 [ma= ilto:vchen@google.com= ]
Sent:    Monday, August 13, 2012 06:04 PM Eastern S= tandard Time
To:    Peter Stanforth
Cc:  &nb= sp; Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
Subject:    Re: = [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

B= etween 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 indep= endent, yet well-matched to all major languages. JSON-handling libraries ex= ist for numerous languages (see of 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 elim= inate the need for datetime-string parsing on devices, assuming devices alr= eady have native libraries that provide time in this format. Is that a vali= d assumption? Of course, this is less human-readable....


On Mon,= Aug 13, 2012 at 6:49 AM, Peter Stanforth <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 tha= t one.
   
    On MonAug/13/12 Mon Aug= 13, 9:30 AM, "Rosen, Brian"
   
 &nbs= p;  <B= rian.Rosen@neustar.biz> wrote:
   
  = ;  >Our experience in the IETF over many years is that economizing = message
    >size and compromising utility and securit= y in search of efficiency of
    >implementation on sm= all devices is a poor trade off.  I am not advocating
  &= nbsp; >being wasteful of resources, but I don't think we should seriousl= y
    >consider the overhead of XML or json to be sign= ificant.
    >
    >Assuming a js= on library can be loaded on a small device is reasonable.
  &n= bsp; >
    >Brian (as individual)
  &n= bsp; >
    >
    >
 &n= bsp;  > -----Original Message-----
    >From:&= nbsp; Peter Stanforth [mailto:peter@spectrumbridge.com]
    >Se= nt:  Saturday, August 11, 2012 07:13 AM Eastern Standard Time
 = ;   >To:    Teco Boot; Benjamin A.Rolfe
 &nb= sp;  >Cc:    paws@ietf.org
    >Subject:    &n= bsp; Re: [paws] XML schema versus JSON, vCard & iCal
  &nb= sp; >
    >Not all masters run over the core networ= k.
    >Some of the Use cases have a master talking to= another OTA
    >We should not assume that all Master= s are attached to utility power so we
    >should be s= ympathetic to processing energy use also.
    >
&nb= sp;   >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot&qu= ot; <teco@inf-net.n= l> wrote:
    >
    >><= br>    >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. R= olfe 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 no= w popularly called "M2M"
    >>>applic= ations.  A lot of these devices could use IP all the end to end,
&n= bsp;   >>>but may have a very compact, simple stack and = applications (i.e.  no
    >>>browser).&nbs= p; Is JSON typically implemented when there is no browser?
  &= nbsp; >>>Would it be hard to do in a resource constrained device (= i.e. where we
    >>>talk about memory size in K= ilo-bytes still).
    >>
    >= >In use cases and requirements document, there are no requirements for    >>protocol performance. I guess OS/IP/TCP/TLS co= de 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 sa= tcom
    >>links.
    >>    >>Because PAWS runs between master and database, = over core network,
    >>performance is not our pri= mary concern. But as always, it is good to keep
    >&= gt;an eye on efficiency.
    >>
  &nbs= p; >>Teco
    >>
    >&g= t;> Thanks
    >>> Ben
    = >>>
    >>>
    >&= gt;>> We had a discussion on XML vs. JSON. I prefer the one with most=
    >>>>compact messages.
  &nb= sp; >>>>
    >>>> On vCard and JS= ON: what is the status of "A JavaScript Object Notation
  = ;  >>>>(JSON) Representation for vCard"?
 &nb= sp;  >>>> http://tools.ietf.org/html/draft-bhat-= vcarddav-json-00
    >>>>
  =   >>>> On valid times: can we use same format as certifica= tes? They have
    >>>>similar simple require= ments: valid notBefore&  notAfter.
    >>&= gt;> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
&nb= sp;   >>>>
    >>>> Tec= o
    >>>> __________________________________= _____________
    >>>> paws mailing list
&= nbsp;   >>>> paws@ietf.org
    >>>> https://= www.ietf.org/mailman/listinfo/paws
    >>>&g= t;
    >>>
    >>> __= _____________________________________________
    >>= ;> paws mailing list
    >>> paws@ietf.org
    = >>> https://www.ietf.org/mailman/listinfo/paws
  &= nbsp; >>
    >>______________________________= _________________
    >>paws mailing list
 =    >>paw= s@ietf.org
    >>https://www.ietf.org/mailman/lis= tinfo/paws
    >
    >_______= ________________________________________
    >paws mai= ling list
    >paws@ietf.org
    >https://www.ietf.org/= mailman/listinfo/paws
   
    ____= ___________________________________________
    paws mail= ing list
    paws@ietf.org
    https://www.ietf.org/mailman/l= istinfo/paws
   




--
-vince
_______________________________________________
paws mailing listpaws@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/paws" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/paws
____________________________= ___________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinf= o/paws



 

--
-vi= nce

= --_000_8375F6DAEFB09F48815203F1FE23B797117AA6D9E1shelby_-- From ben@blindcreek.com Thu Aug 23 12:05:19 2012 Return-Path: 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 2AAE821F869A for ; Thu, 23 Aug 2012 12:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, MIME_HTML_ONLY=1.457] 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 4Wj+KkajWeXD for ; Thu, 23 Aug 2012 12:05:15 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id 581BC21F8699 for ; Thu, 23 Aug 2012 12:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=L/JBD+w2jftCsoAZy0NcnVOEZQVJ3l7/ZlKyDc4yO+0=; b=ZPoH1uyfgf1rh2PqmQUOXjEzt3lEDEecS2p9nemud/0/0ZwgfAh1w/H9kwX7rEt5I0OejWoGQohVaObmgoabLZXWysscHFOCOwIP3+aU7LUZLnBVg1GrqYVPH+pYb3aa; Received: from [64.74.213.174] (port=64341 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1T4ciJ-0001GU-EB for paws@ietf.org; Thu, 23 Aug 2012 14:05:11 -0500 Message-ID: <50367EE8.4080106@blindcreek.com> Date: Thu, 23 Aug 2012 12:05:12 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: paws@ietf.org References: <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com> <8375F6DAEFB09F48815203F1FE23B797117AA6D8CF@shelby> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DBC@008-AM1MPN1-006.mgdnok.nokia.com> <8375F6DAEFB09F48815203F1FE23B797117AA6D9E1@shelby> In-Reply-To: <8375F6DAEFB09F48815203F1FE23B797117AA6D9E1@shelby> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 19:05:19 -0000 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] On Behalf Of Gabor.Bajko@nokia.com
Sent: Tuesday, August 21, 2012 12:42 AM
To: 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] On Behalf Of ext Das, Subir
Sent: Monday, August 20, 2012 2:50 PM
To: Don Joslyn; Vincent Chen; Weixinpeng
Cc: 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] On Behalf Of Don Joslyn
Sent: Monday, August 20, 2012 4:54 PM
To: Vincent Chen; Weixinpeng
Cc: 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] On Behalf Of Vincent Chen
Sent: Monday, August 20, 2012 2:56 PM
To: Weixinpeng
Cc: 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> 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] On Behalf Of Rosen, Brian


Sent: Friday, August 17, 2012 9:26 PM

To: Manikkoth Sajeev; gabor.bajko@nokia.com; vchen@google.com; peter@spectrumbridge.com


Cc: 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>
Reply-To: Manikkoth Sajeev <mksaji@yahoo.com>
Date: Thu, 16 Aug 2012 22:37:38 -0400
To: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>, "Rosen, Brian" <brian.rosen@neustar.biz>, "vchen@google.com" <vchen@google.com>, "peter@spectrumbridge.com" <peter@spectrumbridge.com>
Cc: "paws@ietf.org" <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 option can also work. JSON I think will necessitate implementation to be native Java and may not be as friendly with other implementation languages.

 

Best Regards,

 

From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
To: Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com
Cc: 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] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: '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]
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
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/) 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> 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> 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]
    >Sent:  Saturday, August 11, 2012 07:13 AM Eastern Standard Time
    >To:    Teco Boot; Benjamin A.Rolfe
    >Cc:    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> 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
    >>>>
    >>>> 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
    >>>>
    >>>> Teco
    >>>> _______________________________________________
    >>>> paws mailing list
    >>>> paws@ietf.org
    >>>> https://www.ietf.org/mailman/listinfo/paws
    >>>>
    >>>
    >>> _______________________________________________
    >>> paws mailing list
    >>> paws@ietf.org
    >>> https://www.ietf.org/mailman/listinfo/paws
    >>
    >>_______________________________________________
    >>paws mailing list
    >>paws@ietf.org
    >>https://www.ietf.org/mailman/listinfo/paws
    >
    >_______________________________________________
    >paws mailing list
    >paws@ietf.org
    >https://www.ietf.org/mailman/listinfo/paws
   
    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws
   




--
-vince

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws



 

--
-vince


_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

From d.joslyn@spectrumbridge.com Thu Aug 23 12:11:18 2012 Return-Path: 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 1B2F811E808A for ; Thu, 23 Aug 2012 12:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] 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 jPzHJAf35k4l for ; Thu, 23 Aug 2012 12:11:11 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 864B921F862B for ; Thu, 23 Aug 2012 12:11:10 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Thu, 23 Aug 2012 15:11:09 -0400 From: Don Joslyn To: "Benjamin A. Rolfe" , "paws@ietf.org" Date: Thu, 23 Aug 2012 15:11:17 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac2BYkGq7sZ8qnexRtuW3owkmP6ipwAAJJ7Q Message-ID: <8375F6DAEFB09F48815203F1FE23B797117AA6D9ED@shelby> References: <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com> <8375F6DAEFB09F48815203F1FE23B797117AA6D8CF@shelby> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DBC@008-AM1MPN1-006.mgdnok.nokia.com> <8375F6DAEFB09F48815203F1FE23B797117AA6D9E1@shelby> <50367EE8.4080106@blindcreek.com> In-Reply-To: <50367EE8.4080106@blindcreek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B797117AA6D9EDshelby_" MIME-Version: 1.0 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 19:11:18 -0000 --_000_8375F6DAEFB09F48815203F1FE23B797117AA6D9EDshelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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] On Behalf Of Ben= jamin A. Rolfe Sent: Thursday, August 23, 2012 3:05 PM To: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal Someone suggested that PAWS define both, and let the vendors decide which o= nes to implement. That makes the most sense for both DB and device vendors. Markets will pro= bably drive DB vendors to do both. Device vendors will do what fits the mar= ket segment they're after. Why over-constrain (or argue when natural select= ion will take care of it for us?). B Sounds good to me. From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Tuesday, August 21, 2012 12:42 AM To: 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 encodi= ng. To prevent endless discussions on this topic I'd suggest we move forward wi= th supporting both in the DB and either one in the master device. Any objections? Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@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; 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 need= ed for XML From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Don Josly= n Sent: Monday, August 20, 2012 4:54 PM To: Vincent Chen; Weixinpeng Cc: 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-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: Monday, August 20, 2012 2:56 PM To: Weixinpeng Cc: 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 dev= ice 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 wo= rk" 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 (clie= nt-side) prefer it for its simplicity: * Representation closely matches most data models (nested lists and m= aps) * Simple-to-use libraries exist for all major languages/platforms * Don't need a tool chain to work with the data, as is typically need= ed 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 Goog= le 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 mor= e efficient, can't argue with that.] * At the end of the day, it's the data model that matters, rather than t= he 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 suppo= rting 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 device= s) 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 muc= h or exchanged that often.] On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > 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-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; gabor.bajko@nokia.com; = vchen@google.com; peter@spectrumbridge.com Cc: 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 desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml option can also wor= k. JSON I think will necessitate implementation to be native Java and may n= ot be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_8375F6DAEFB09F48815203F1FE23B797117AA6D9EDshelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Ben,

That was my= original suggestion, and I still think it makes the most sense.=

Thanks for supporting the proposal.<= o:p>

Don

<= p class=3DMsoNormal> 

From: 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
= 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 an= d 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?).<= br>B

Sounds good to me.

 

From:= paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf O= f Gabor.Bajko@nokia.comSent: Tuesday, August 21, 2012 12:42 AM
To: paws@ietf.org
Subject: Re: [paws] XML sch= ema versus JSON, vCard & iCal

 

Now I can’t see anymo= re any willingness to agree on one or the other encoding.

To prevent endless discussions on this topic I’d s= uggest we move forward with supporting both in the DB and either one in the= master device.

Any objections?

 

Gabor

&nbs= p;

 

 

We have a half a dozen or more TVDB radio vendors that use/prefer JSO= N 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 t= o work with the data, as is typically needed for XML
      • =

 

 

 

Fro= m: paws-bounces@ietf.org [mailto:paws-bounces@ietf.o= rg] On Behalf Of Don Joslyn
Sent: Monday, August 20, 2= 012 4:54 PM
To: Vincent Chen; Weixinpeng
Cc: paws@ietf.org; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

 

Please= see my comments below…

Thanks,

Don

&nb= sp;

<= b>From:<= /span> paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] O= n Behalf Of Vincent Chen
Sent: Monday, August 20, 2012 2:56 P= M
To: Weixinpeng
Cc: p= aws@ietf.org; Manikkoth Sajeev
Subject: Re: [paws] XML schema= versus JSON, vCard & iCal

 

  • One of our go= als is to strive to lower the cost and complexity for device manufacturers.= This lowers the barrier for building a robust ecosystem.=

[DJ - The R= 20;cost” and complexity of using XML has not been an issue for the ha= lf dozen TVBD vendors that have already used XML. Maybe we need to better d= efine “cost”?]

  • To reduce complexity and cost for device makers, supporting 1 enc= oding is better than both, as Brian points out. WiFi access points that &qu= ot;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 t= o support one to talk to the database. Our current database supports XML an= d 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.]<= /span>

  • There's a trend f= or 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 map= s)
    • 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 th= e scalability of serving systems.

 

[DJ – I can’= ;t argue against these listed pros for JSON, especially when you’re d= ealing with a lot of data (like Twitter, FourSquare, Facebook and Google do= es). 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 mo= re 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 go= od to get feedback from device makers (especially of embedded devices) rega= rding experiences supporting XML vs JSON.

 

Don, can you elaborate on the = types of devices that already support XML?

 

 
 
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws
 
=

--_000_8375F6DAEFB09F48815203F1FE23B797117AA6D9EDshelby_--

From brian.rosen@neustar.biz  Thu Aug 23 12:44:02 2012
Return-Path: 
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 256BA21F8501 for ; Thu, 23 Aug 2012 12:44:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.055
X-Spam-Level: 
X-Spam-Status: No, score=-6.055 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 QciudHA7fQRe for ; Thu, 23 Aug 2012 12:43:58 -0700 (PDT)
Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id A3BED21F86A2 for ; Thu, 23 Aug 2012 12:43:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1345750800; x=1661109932; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=BqI0MaqA0QhUB6OGRBDdlypwjlMj5DE4lk6V9KMFX3Q=; b=RAi0GoyOk8OZxcVts87vPQB4oTl5HP1OpXHabA0/OJnR6Wu1cQJpDnbMM8p6mS 0OoinmJ4tySGl4d8c1dxw7UA==
Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.10266894;  Thu, 23 Aug 2012 15:39:58 -0400
Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 23 Aug 2012 15:43:50 -0400
From: "Rosen, Brian" 
To: Don Joslyn 
Date: Thu, 23 Aug 2012 15:43:49 -0400
Thread-Topic: [paws] XML schema versus JSON, vCard & iCal
Thread-Index: Ac2BZ535J7EY3yiPTg2gvfigHb0Gkw==
Message-ID: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz>
References: <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com>    <8375F6DAEFB09F48815203F1FE23B797117AA6D8CF@shelby>  <1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DBC@008-AM1MPN1-006.mgdnok.nokia.com> <8375F6DAEFB09F48815203F1FE23B797117AA6D9E1@shelby> <50367EE8.4080106@blindcreek.com> <8375F6DAEFB09F48815203F1FE23B797117AA6D9ED@shelby>
In-Reply-To: <8375F6DAEFB09F48815203F1FE23B797117AA6D9ED@shelby>
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: ac3iAC8T+Xi0FIxBlafVOw==
Content-Type: multipart/alternative; boundary="_000_1DBBA0CFDF2641E2BFED8A5FABC60A0Fneustarbiz_"
MIME-Version: 1.0
Cc: "paws@ietf.org" 
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\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Aug 2012 19:44:02 -0000

--_000_1DBBA0CFDF2641E2BFED8A5FABC60A0Fneustarbiz_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

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 impleme=
ntations.  On the other hand, the whole point of a protocol document like o=
urs is that two independent implementations who both follow the document wi=
ll 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 fig=
ure it out using proprietary protocols.  The market will decide.

So, I feel strongly that if one end is "either", the other end must be "bot=
h".  It's also acceptable to say both ends implement one choice and the oth=
er is optional at both ends.  Here, I think it's server does both and clien=
t does either.

It's always possible to build an implementation of a server that only does =
one: there are no protocol police.

Brian 




On Aug 23, 2012, at 3:11 PM, Don Joslyn > 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-boun=
ces@ietf.org] On Behalf Of Benjamin A. Rolfe
Sent: Thursday, August 23, 2012 3:05 PM
To: paws@ietf.org
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Someone suggested that PAWS define both, and let the vendors decide which o=
nes to implement.
That makes the most sense for both DB and device vendors.  Markets will pro=
bably drive DB vendors to do both. Device vendors will do what fits the mar=
ket segment they're after. Why over-constrain (or argue when natural select=
ion will take care of it for us?).
B

Sounds good to me.

From: paws-bounces@ietf.org [mailto:paws-boun=
ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Tuesday, August 21, 2012 12:42 AM
To: paws@ietf.org
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Now I can=92t see anymore any willingness to agree on one or the other enco=
ding.
To prevent endless discussions on this topic I=92d 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-boun=
ces@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; 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 need=
ed for XML




From: paws-bounces@ietf.org [mailto:paws-boun=
ces@ietf.org] On Behalf Of Don Josly=
n
Sent: Monday, August 20, 2012 4:54 PM
To: Vincent Chen; Weixinpeng
Cc: paws@ietf.org; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Please see my comments below=85
Thanks,
Don

From: paws-bounces@ietf.org [mailto:paws-boun=
ces@ietf.org] On Behalf Of Vincent Chen
Sent: Monday, August 20, 2012 2:56 PM
To: Weixinpeng
Cc: 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 dev=
ice manufacturers. This lowers the barrier for building a robust ecosystem.

[DJ - The =93cost=94 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 be=
tter define =93cost=94?]

 *   To reduce complexity and cost for device makers, supporting 1 encoding=
 is better than both, as Brian points out. WiFi access points that "just wo=
rk" 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=92m forced to pick only one, then I will vote for X=
ML because it=92s 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 (clie=
nt-side) prefer it for its simplicity:
    *   Representation closely matches most data models (nested lists and m=
aps)
    *   Simple-to-use libraries exist for all major languages/platforms
    *   Don't need a tool chain to work with the data, as is typically need=
ed for XML.

Apparently, the efficiency gains of JSON also matter to the scalability of =
serving systems.


[DJ =96 I can=92t argue against these listed pros for JSON, especially when=
 you=92re dealing with a lot of data (like Twitter, FourSquare, Facebook an=
d Google does). But I=92m assuming that PAWS messages will not be exchanged=
 nearly as often as the applications mentioned above. But again, I know JSO=
N is more efficient, can=92t argue with that.]

 *   At the end of the day, it's the data model that matters, rather than t=
he 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 suppo=
rting 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 device=
s) 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 muc=
h or exchanged that often.]
On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > 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-boun=
ces@ietf.org] On Behalf Of Rosen, Brian

Sent: Friday, August 17, 2012 9:26 PM
To: Manikkoth Sajeev; gabor.bajko@nokia.com; =
vchen@google.com; peter@spectrumbridge.com

Cc: 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 desi=
gn or implementation, but I am a big fan of reusing standards rather than d=
efining new ones, and I would not want to see the choice of json mean we th=
en 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 x=
Card and LoST, then I would not want to use json.

I would prefer to not have "both", because of interoperability complication=
s.  If there is rough consensus for both, then I would assert that all serv=
ers 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 sol=
ely or even largely because of compactness advantages rarely are good choic=
es.  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 

From: Manikkoth Sajeev >
Reply-To: Manikkoth Sajeev >
Date: Thu, 16 Aug 2012 22:37:38 -0400
To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co=
m" >
Cc: "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 im=
plementations may prefer XML as it is generic, omni present, easy to unders=
tand and validate. For compactness may be a  binary xml optioncan also work=
. JSON I think will necessitate implementation to be native Java and may no=
t be as friendly with other implementation languages.

Best Regards,
Sajeev Manikkoth
Mobile: +918792292002
Email: mksaji@ieee.org
http://www.linkedin.com/in/mksajeev

From: "Gabor.Bajko@nokia.com" >
To: Brian.Rosen@neustar.biz; vchen@google.c=
om; peter@spectrumbridge.com
Cc: 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-boun=
ces@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'
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 whol=
e lot about that

Brian 



-----Original Message-----
From:     Vincent Chen [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
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 inde=
pendent, yet well-matched to all major languages. JSON-handling libraries e=
xist for numerous languages (see of http://json.org/) and seem to be reason=
ably light weight.

Timestamps

As for timestamp specifications, should we consider just using seconds sinc=
e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for =
datetime-string parsing on devices, assuming devices already have native li=
braries that provide time in this format. Is that a valid assumption? Of co=
urse, this is less human-readable....


On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote:


    Whenever we built mobile devices we never dealt with IETF, in our senso=
r
    days even an IP stack was a challenge,so I would defer to the device gu=
ys
    on that one.

    On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"

    > 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 advocat=
ing
    >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]
    >Sent:  Saturday, August 11, 2012 07:13 AM Eastern Standard Time
    >To:    Teco Boot; Benjamin A.Rolfe
    >Cc:    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" > 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 resourc=
es,
    >>>such as embedded devices in what are now popularly called "M2M"
    >>>applications.  A lot of these devices could use IP all the end to en=
d,
    >>>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 need=
s
    >>for JSON or XML.
    >>
    >>Same for timing: TCP/TLS connection setup will take more than the PAW=
S
    >>message exchange, I think. This may be of importance when using satco=
m
    >>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 Nota=
tion
    >>>>(JSON) Representation for vCard"?
    >>>> 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
    >>>>
    >>>> Teco
    >>>> _______________________________________________
    >>>> paws mailing list
    >>>> paws@ietf.org
    >>>> https://www.ietf.org/mailman/listinfo/paws
    >>>>
    >>>
    >>> _______________________________________________
    >>> paws mailing list
    >>> paws@ietf.org
    >>> https://www.ietf.org/mailman/listinfo/paws
    >>
    >>_______________________________________________
    >>paws mailing list
    >>paws@ietf.org
    >>https://www.ietf.org/mailman/listinfo/paws
    >
    >_______________________________________________
    >paws mailing list
    >paws@ietf.org
    >https://www.ietf.org/mailman/listinfo/paws

    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws





--
-vince

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws



--
-vince





_______________________________________________

paws mailing list

paws@ietf.org

https://www.ietf.org/mailman/listinfo/paws


_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws


--_000_1DBBA0CFDF2641E2BFED8A5FABC60A0Fneustarbiz_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

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 o=
ther implementations.  On the other hand, the whole point of a protoco=
l document like ours is that two independent implementations who both follo=
w the document will interwork.  If that wasn't true, why do you need a=
 standard?

If you say "either" to both ends, then you do=
n'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 b=
oth and client does either. 

It's always poss=
ible to build an implementation of a server that only does one: there are n=
o protocol police.

Brian <as individual>




On A=
ug 23, 2012, at 3:11 PM, Don Joslyn <d.joslyn@spectrumbridge.com> wrote:

Hi Ben,=

That was my original suggest=
ion, and I still think it makes the most sense.
Thanks for supporting the proposal.
Don
 
<=
div>
From: paws-bounc=
es@ietf.org [mailto:paws-bounces@ie=
tf.org] On Behalf =
Of Benjamin A. Rolfe<=
br>Sent: Thursday,=
 August 23, 2012 3:05 PM
To: paws@ietf.org
Subj=
ect: Re: [paws] XML s=
chema versus JSON, vCard & iCal
 
Someone su=
ggested that PAWS define both, and let the vendors decide which ones to imp=
lement.
That makes the most sense for both DB and device vendors.  =
Markets will probably drive DB vendors to do both. Device vendors will do w=
hat fits the market segment they're after. Why over-constrain (or argue whe=
n natural selection will take care of it for us?).
B

<=
/div>
Sounds good to me.
 
From: paws-bounces@ietf.org [mailto:paws-bounce=
s@ietf.org] On Beh=
alf Of Gabor.Bajko@nokia.com
Sent: Tuesday, August 21, 2012 12:42 AM
To: paws@ietf.org=

Subject: Re: [=
paws] XML schema versus JSON, vCard & iCal
 
Now I =
can=92t see anymore any willingness to agree on one or the other encoding.<=
/span>
To prevent endless discussions on th=
is topic I=92d suggest we move forward with supporting both in the DB and e=
ither one in the master device.
Any =
objections?
 =

Gabor
 
 
From: =
paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]=
 On Behalf Of ext Das, Subir
Sent: Monday, August 20, 2012=
 2:50 PM
To: Do=
n Joslyn; Vincent Chen; Weixinpeng
Cc: 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 vo=
te for JSON if we had to pick one.
A=
lso I will copy the following two important points:
=

 
    • Simple-to-use libraries exist for all major languages/platfo=
rms
    • Don't need a tool chain to work with the data, as is typically n=
eeded for XML
 =

 
 
From: paws-bounces@ietf.org [mailto:pa=
ws-bounces@ietf.org] =
On Behalf Of Don J=
oslyn
Sent: Mon=
day, August 20, 2012 4:54 PM
To: Vincent Chen; Weixinpeng
Cc: paws@ietf.org; Manikkoth Sa=
jeev
Subject: R=
e: [paws] XML schema versus JSON, vCard & iCal
<=
/div>
 
Pl=
ease see my comments below=85
Thanks=
,
Don
 
From:=
 paws-bounces@ietf.org [mailto:paws-bounces@=
ietf.org] On Behal=
f Of Vincent Chen
=
Sent: Monday, Augu=
st 20, 2012 2:56 PM
To:&nbs=
p;Weixinpeng
Cc:&nbs=
p;paws@ietf.org; Manikkoth Sajeev
Subject:=
 Re: [paws] XML schema ve=
rsus JSON, vCard & iCal
 
  • One of our goals is to strive to lower the cost and complexity for dev=
ice manufacturers. This lowers the barrier for building a robust ecosystem.=

[DJ - The =93cost=94 and complexity of using XML has not =
been an issue for the half dozen TVBD vendors that have already used XML. M=
aybe we need to better define =93cost=94?]
  • To reduce complexity and cost f=
or device makers, supporting 1 encoding is better than both, as Brian point=
s 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=92m forced to pick o=
nly one, then I will vote for XML because it=92s 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 reaso=
ns is that developers (client-side) prefer it for its simplicity:
    • <=
span style=3D"font-size: 11.5pt; font-family: Arial, sans-serif; ">Represen=
tation closely matches most data models (nested lists and maps)=

    • Sim=
ple-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 scalabil=
ity of serving systems.
 
[=
DJ =96 I can=92t argue against these listed pros for JSON, especially when =
you=92re dealing with a lot of data (like Twitter, FourSquare, Facebook and=
 Google does). But I=92m 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=92t argue with that.]
  • At the end of the day, it's t=
he data model that matters, rather than the encoding. We (Google) are actua=
lly neutral on XML vs JSON, as long as we're clear on what device makers wa=
nt. It would be good to get feedback from device makers (especially of embe=
dded 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> wrote:=

Considering of the de=
sign of database discovery protocol, the LoST protocol may be used and LoST=
 is based on XML, so I think XML may be preferred.
<=
div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times=
 New Roman', serif; "> 
--Xinpeng Wei
 
=

=
From:=
 paws-bounces@ietf.org [mailto:paws-boun=
ces@ietf.org] On B=
ehalf Of Rosen, Brian=


Sent: Friday, August 17, 2012 9:26 PM=


Cc: 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 reusi=
ng 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 s=
tandards based on the idea there is no json representation of an existing s=
tandard.  So, if choosing json means folks feel free to ignore existin=
g 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 conse=
nsus for both, then I would assert that all servers have to implement both =
and the client can implement either.
 
Th=
ere are json validators, so I don't think that is a big deal.  =

 
My experience in protocol design on the Inter=
net is that decisions made solely or even largely because of compactness ad=
vantages rarely are good choices.  If you like json because it is smal=
ler, then I believe you need a much better reason.  Binary doesn't wor=
k for me, at all.  I have been involved in big binary vs text wars in =
protocol design.  Text wins, binary loses, in my opinion.<=
/o:p>
 
Brian <as individual>
=

 
From: Manikkoth Sajeev <mksaji@yahoo.com>
Reply-To: Manikkoth Sajeev <mksaji@yahoo.com>
Date: Thu, 16 Aug 2012 22:37:38 -0400
<=
b>To: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>, "Rosen, Brian" <brian.rosen@neustar.biz>, "vchen@google.com" <vchen@google.com>, " "paws@ietf.org" =
<paws@ietf.org>
Subject: Re: [paws] XML schema ver=
sus 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 xm=
l optioncan also work. JSON I think will necessitate implementatio=
n to be native Java and may not be as friendly with other implementation la=
nguages.
 <=
o:p>
Best Regards,
 <=
o:p>
From:<=
span style=3D"font-size: 10pt; font-family: Arial, sans-serif; "> "Gabor.Bajko@nokia.com" <G=
abor.Bajko@nokia.com>
To: Brian.Rosen@neust=
ar.biz; vchen@google.com; peter@spectrumbri=
dge.com 
Cc: paws@ietf.org =

Sent: Friday, =
17 August 2012, 4:55
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

We h=
ave not heard any objections for using JSON encoding instead of XML. 
Therefore, let's go for JSO=
N, and close this thread.

- Gabor

-----Original Message-----<=
br>From: paws-bounces@ietf.org [mailto:paws-b=
ounces@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'
Subject: Re: [paws] XML schema=
 versus JSON, vCard & iCal

json is okay with me.  
I'd prefer an ISO time stamp r=
ather than a time in seconds since epoch.  It's very easy to parse, an=
d 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]
Sent:    Monday, August 13, 2=
012 06:04 PM Eastern Standard Time
To:    Peter Stanforth=

Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; p=
aws@ietf.org
Subject:    Re: [paws] XML schema versus=
 JSON, vCard & iCal

XML vs JSON

Between XML and JSON, JSO=
N 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 languag=
es (see of 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 device=
s 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> wrote:


 &=
nbsp;  Whenever we built mobile devices we never dealt with IETF, in o=
ur sensor
    days even an IP stack was a challenge,so I =
would defer to the device guys
    on that one.
 =
   
 &n=
bsp;  On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"
 &nb=
sp;  
  =
;  <Brian.Rosen@neustar.biz=
> wrote:
   =
 
    >Our experience in the IETF over man=
y years is that economizing message
    >size and comp=
romising utility and security in search of efficiency of
  &nb=
sp; >implementation on small devices is a poor trade off.  I am not=
 advocating
    >being wasteful of resources, but I do=
n't think we should seriously
    >consider the overhe=
ad of XML or json to be significant.
    >
 &n=
bsp;  >Assuming a json library can be loaded on a small device is r=
easonable.
    >
    >Brian (as i=
ndividual)
    >
    >
 &=
nbsp;  >
    > -----Original Message-----
&=
nbsp;   >From:  Peter Stanforth [mailto:peter@spectrumbridge.com]
   =
 >Sent:  Saturday, August 11, 2012 07:13 AM Eastern Standard Time    >To:    Teco Boot; Benjamin A.Rolfe
&n=
bsp;   >Cc:   =
 paws@ietf.org
  =
;  >Subject:      Re: [paws] XML schema versus JSON,=
 vCard & iCal
    >
    >Not =
all masters run over the core network.
    >Some of th=
e 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 als=
o.
    >
    >On SatAug/11/12 Sat=
 Aug 11, 5:30 AM, "Teco Boot" <teco@inf-=
net.nl> wrote:
    >
    >=
>
    >>Op 10 aug. 2012, om 18:10 heeft Benjamin=
 A. Rolfe het volgende
    >>geschreven:
 &=
nbsp;  >>
    >>> Compactness of mess=
ages is important, but it is also important (to me
    &g=
t;>>at least) to be realizable in an implementation with limited reso=
urces,
    >>>such as embedded devices in what a=
re now popularly called "M2M"
    >>>application=
s.  A lot of these devices could use IP all the end to end,
 &=
nbsp;  >>>but may have a very compact, simple stack and appli=
cations (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-b=
ytes still).
    >>
    >>I=
n use cases and requirements document, there are no requirements for
&nb=
sp;   >>protocol performance. I guess OS/IP/TCP/TLS code si=
ze supersedes needs
    >>for JSON or XML.
 =
;   >>
    >>Same for timing: TCP/T=
LS connection setup will take more than the PAWS
    >=
>message exchange, I think. This may be of importance when using satcom<=
br>    >>links.
    >>
&nbs=
p;   >>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.
    >>
    &g=
t;>Teco
    >>
    >>>=
; Thanks
    >>> Ben
    >&=
gt;>
    >>>
    >>&g=
t;> We had a discussion on XML vs. JSON. I prefer the one with most
&=
nbsp;   >>>>compact messages.
    &=
gt;>>>
    >>>> On vCard and JSON: w=
hat is the status of "A JavaScript Object Notation
    &g=
t;>>>(JSON) Representation for vCard"?
    >&=
gt;>> http://tools.ietf.org/ht=
ml/draft-bhat-vcarddav-json-00
    >>>>    >>>> On valid times: can we use same forma=
t as certificates? They have
    >>>>similar =
simple requirements: valid notBefore&  notAfter.
  &n=
bsp; >>>> http://tools.ietf.=
org/html/rfc3280#section-4.1.2.5
    >>>>=

    >>>> Teco
    >>=
>> _______________________________________________
  &nb=
sp; >>>> paws mailing list
    >>>&g=
t; paws@ietf.org
    >>>> https://www.ietf.org/mailman/listinfo/paws
 &n=
bsp;  >>>>
    >>>
 &nb=
sp;  >>> _______________________________________________
&=
nbsp;   >>> paws mailing list
    >=
>> paws@ietf.org
    >>> https://www.ietf.org/mailman/listinfo/paws
 =
   >>
    >>_______________________=
________________________
    >>paws mailing list    >>paws@ietf.org=

    >>https://www.ietf.org/mailman/listinfo/paws
   =
; >
    >__________________________________________=
_____
    >paws mailing list
    >=
;paws@ietf.org
    >=
https://www.ietf.org/ma=
ilman/listinfo/paws
    
    _______________________________=
________________
    paws mailing list
  &nb=
sp; paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws
    




-- 
-vince

______________=
_________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws
______________=
_________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws


 
-- -vince
 
______________________________________=
_________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws
 
________= _______________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/lis= tinfo/paws
= --_000_1DBBA0CFDF2641E2BFED8A5FABC60A0Fneustarbiz_-- From Peter.McCann@huawei.com Thu Aug 23 12:49:07 2012 Return-Path: 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 D8E2421F86A4 for ; Thu, 23 Aug 2012 12:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.65 X-Spam-Level: X-Spam-Status: No, score=-5.65 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, 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 F57P8p3ec3Tj for ; Thu, 23 Aug 2012 12:49:06 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 21A9321F86A2 for ; Thu, 23 Aug 2012 12:49:06 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp03-ep.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJW56728; Thu, 23 Aug 2012 11:49:05 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 23 Aug 2012 12:44:10 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.151]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Thu, 23 Aug 2012 12:44:06 -0700 From: Peter McCann To: Don Joslyn , "Benjamin A. Rolfe" , "paws@ietf.org" Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Ie7Nd2WNzPm0+85/tpR52R7QAAU/5DAJlUv6AAAo7YAAAWoncAABh1noAAifZJAAAEHtqAAAHwqAAAEnPn8ACBGaEAABBtuQAAADZkgAANmbqw Date: Thu, 23 Aug 2012 19:44:06 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E283EC@dfweml512-mbx.china.huawei.com> References: <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com> <8375F6DAEFB09F48815203F1FE23B797117AA6D8CF@shelby> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DBC@008-AM1MPN1-006.mgdnok.nokia.com> <8375F6DAEFB09F48815203F1FE23B797117AA6D9E1@shelby> <50367EE8.4080106@blindcreek.com> <8375F6DAEFB09F48815203F1FE23B797117AA6D9ED@shelby> In-Reply-To: <8375F6DAEFB09F48815203F1FE23B797117AA6D9ED@shelby> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 19:49:08 -0000 We should be defining requirements that lead to interoperable implementatio= ns. If we specify both encodings, but allow both the DB and the master device t= o implement only one, there will be instances of master device/database pairs that won't interoperate. In my opinion, we should standardize on a single encoding. Failing that,=20 we should require the DB to implement both and allow the master device to choose one. This will achieve our goal of interoperable implementations. -Pete Don Joslyn wrote: > Hi Ben, >=20 > That was my original suggestion, and I still think it makes the most=20 > sense. >=20 > Thanks for supporting the proposal. >=20 > Don >=20 >=20 >=20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of Benjamin A. Rolfe > Sent: Thursday, August 23, 2012 3:05 PM > To: paws@ietf.org > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 >=20 >=20 > Someone suggested that PAWS define both, and let the vendors decide=20 > which ones to implement. > That makes the most sense for both DB and device vendors. Markets=20 > will probably drive DB vendors to do both. Device vendors will do what=20 > fits the market segment they're after. Why over-constrain (or argue=20 > when natural selection will take care of it for us?). > B >=20 >=20 >=20 > Sounds good to me. >=20 >=20 >=20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of Gabor.Bajko@nokia.com > Sent: Tuesday, August 21, 2012 12:42 AM > To: paws@ietf.org > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 >=20 >=20 > Now I can't see anymore any willingness to agree on one or the other=20 > encoding. >=20 > To prevent endless discussions on this topic I'd suggest we move=20 > forward with supporting both in the DB and either one in the master devic= e. >=20 > Any objections? >=20 >=20 >=20 > Gabor >=20 >=20 >=20 >=20 >=20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of ext Das, Subir > Sent: Monday, August 20, 2012 2:50 PM > To: Don Joslyn; Vincent Chen; Weixinpeng > Cc: paws@ietf.org; Manikkoth Sajeev > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 >=20 >=20 > We have a half a dozen or more TVDB radio vendors that use/prefer JSON=20 > and we will vote for JSON if we had to pick one. >=20 > Also I will copy the following two important points: >=20 >=20 >=20 > * 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 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of Don Joslyn > Sent: Monday, August 20, 2012 4:54 PM > To: Vincent Chen; Weixinpeng > Cc: paws@ietf.org; Manikkoth Sajeev > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 >=20 >=20 > Please see my comments below... >=20 > Thanks, >=20 > Don >=20 >=20 >=20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of Vincent Chen > Sent: Monday, August 20, 2012 2:56 PM > To: Weixinpeng > Cc: paws@ietf.org; Manikkoth Sajeev > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 >=20 >=20 > * One of our goals is to strive to lower the cost and complexity > for device manufacturers. This lowers the barrier for building a=20 > robust ecosystem. >=20 > [DJ - The "cost" and complexity of using XML has not been an issue for=20 > the half dozen TVBD vendors that have already used XML. Maybe we need=20 > to better define "cost"?] >=20 > * To reduce complexity and cost for device makers, supporting 1 > encoding is better than both, as Brian points out. WiFi access points=20 > that "just work" anywhere in the world serves as a good model. >=20 > [DJ - I proposed that the databases support both XML and JSON, devices=20 > only need to support one to talk to the database. Our current database=20 > supports XML and JSON, but if I'm forced to pick only one, then I will=20 > vote for XML because it's the one that we currently use on all=20 > embedded devices.] >=20 > * There's a trend for APIs on the web towards JSON (Twitter, > FourSquare, Facebook, Google, etc.). One of the major reasons is that=20 > developers (client-side) prefer it for its simplicity: >=20 > * 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. >=20 > Apparently, the efficiency gains of JSON also matter to the=20 > scalability of serving systems. >=20 >=20 >=20 > [DJ - I can't argue against these listed pros for JSON, especially=20 > when you're dealing with a lot of data (like Twitter, FourSquare,=20 > Facebook and Google does). But I'm assuming that PAWS messages will=20 > not be exchanged nearly as often as the applications mentioned above. > But again, I know JSON is more efficient, can't argue with that.] >=20 > * 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=20 > long as we're clear on what device makers want. It would be good to=20 > get feedback from device makers (especially of embedded devices)=20 > regarding experiences supporting XML vs JSON. >=20 >=20 >=20 > Don, can you elaborate on the types of devices that already support XML? >=20 >=20 >=20 > [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=20 > amount of data that needs to be exchanged between device and database=20 > is not that much or exchanged that often.] >=20 > On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > wrote: >=20 > Considering of the design of database discovery protocol, the LoST=20 > protocol may be used and LoST is based on XML, so I think XML may be=20 > preferred. >=20 >=20 >=20 > --Xinpeng Wei >=20 >=20 >=20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of Rosen, Brian >=20 >=20 > Sent: Friday, August 17, 2012 9:26 PM >=20 > To: Manikkoth Sajeev; gabor.bajko@nokia.com; vchen@google.com;=20 > peter@spectrumbridge.com >=20 >=20 > Cc: paws@ietf.org > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 >=20 >=20 > I don't really care whether we use json or xml as a matter of protocol=20 > design or implementation, but I am a big fan of reusing standards=20 > rather than defining new ones, and I would not want to see the choice=20 > of json mean we then decide to roll our own versus using existing=20 > standards based on the idea there is no json representation of an=20 > existing standard. So, if choosing json means folks feel free to=20 > ignore existing xml based standards such as xCard and LoST, then I=20 > would not want to use json. >=20 >=20 >=20 > I would prefer to not have "both", because of interoperability=20 > complications. If there is rough consensus for both, then I would=20 > assert that all servers have to implement both and the client can=20 > implement either. >=20 >=20 >=20 > There are json validators, so I don't think that is a big deal. >=20 >=20 >=20 > My experience in protocol design on the Internet is that decisions=20 > made solely or even largely because of compactness advantages rarely=20 > are good choices. If you like json because it is smaller, then I=20 > believe you need a much better reason. Binary doesn't work for me, at=20 > all. I have been involved in big binary vs text wars in protocol=20 > design. Text wins, binary loses, in my opinion. >=20 >=20 >=20 > Brian >=20 >=20 >=20 > From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 > To: "Gabor.Bajko@nokia.com" , "Rosen, Brian" > , "vchen@google.com" ,=20 > "peter@spectrumbridge.com" > Cc: "paws@ietf.org" > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 >=20 >=20 > Hi, >=20 >=20 >=20 > Can it not be both JSON and XML supported? I would vote for that.=20 > Future implementations may prefer XML as it is generic, omni present,=20 > easy to understand and validate. For compactness may be a binary xml=20 > option can also work. JSON I think will necessitate implementation to=20 > be native Java and may not be as friendly with other implementation langu= ages. >=20 >=20 >=20 > Best Regards, >=20 > Sajeev Manikkoth > Mobile: +918792292002 > Email: mksaji@ieee.org > http://www.linkedin.com/in/mksajeev >=20 >=20 >=20 > From: "Gabor.Bajko@nokia.com" To: > Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com Cc: > paws@ietf.org Sent: Friday, 17 August 2012, 4:55 Subject: Re: [paws]=20 > XML schema versus JSON, vCard & iCal >=20 >=20 > We have not heard any objections for using JSON encoding instead of XML. > Therefore, let's go for JSON, and close this thread. >=20 > - Gabor >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of ext Rosen, Brian > Sent: Monday, August 13, 2012 3:14 PM > To: 'Vincent Chen'; 'Peter Stanforth' > Cc: 'paws@ietf.org' > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > 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=20 > a whole lot about that >=20 > Brian >=20 >=20 >=20 > -----Original Message----- > From: Vincent Chen [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 > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > XML vs JSON >=20 > Between XML and JSON, JSON messages are more compact and easier to=20 > process (parsing, synthesis). As clarification, JSON does not require=20 > JavaScript or a Browser. It is a text-based representation of data=20 > that is language independent, yet well-matched to all major languages. > JSON- handling libraries exist for numerous languages (see of > http://json.org/) and seem to be reasonably light weight. >=20 > Timestamps >=20 > As for timestamp specifications, should we consider just using seconds=20 > since the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the=20 > need for datetime-string parsing on devices, assuming devices already=20 > have native libraries that provide time in this format. Is that a=20 > valid assumption? Of course, this is less human-readable.... >=20 >=20 > On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth=20 > wrote: >=20 >=20 > 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. > =20 > On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > =20 > wrote: >> Our experience in the IETF over many years is that economizing=20 >> message size and compromising utility and security in search of=20 >> efficiency of implementation on small devices is a poor trade off. I=20 >> am not advocating being wasteful of resources, but I don't think we=20 >> should seriously consider the overhead of XML or json to be significant. >>=20 >> Assuming a json library can be loaded on a small device is reasonable. >>=20 >> Brian (as individual) >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Peter Stanforth [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 >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >>=20 >> Not all masters run over the core network. Some of the Use cases have=20 >> a master talking to another OTA We should not assume that all Masters=20 >> are attached to utility power so we should be sympathetic to=20 >> processing energy use also. >>=20 >> On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" > > wrote: >>=20 >>>=20 >>> Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe het volgende >>> geschreven: >>>=20 >>>> Compactness of messages is important, but it is also important (to=20 >>>> me at least) to be realizable in an implementation with limited=20 >>>> resources, such as embedded devices in what are now popularly=20 >>>> called "M2M" applications. A lot of these devices could use IP all=20 >>>> the end to end, but may have a very compact, simple stack and=20 >>>> applications (i.e. no browser). Is JSON typically implemented when=20 >>>> there is no browser? Would it be hard to do in a resource=20 >>>> constrained device (i.e. where we talk about memory size in Kilo-bytes= still). >>>=20 >>> In use cases and requirements document, there are no requirements=20 >>> for protocol performance. I guess OS/IP/TCP/TLS code size supersedes=20 >>> needs for JSON or XML. >>>=20 >>> Same for timing: TCP/TLS connection setup will take more than the=20 >>> PAWS message exchange, I think. This may be of importance when using=20 >>> satcom links. >>>=20 >>> Because PAWS runs between master and database, over core network,=20 >>> performance is not our primary concern. But as always, it is good to=20 >>> keep an eye on efficiency. >>>=20 >>> Teco >>>=20 >>>> Thanks >>>> Ben >>>>=20 >>>>=20 >>>>> We had a discussion on XML vs. JSON. I prefer the one with most=20 >>>>> compact messages. >>>>>=20 >>>>> On vCard and JSON: what is the status of "A JavaScript Object=20 >>>>> Notation (JSON) Representation for vCard"? >>>>> http://tools.ietf.org/html/draft-bhat-vcarddav-json-00 >>>>>=20 >>>>> On valid times: can we use same format as certificates? They have=20 >>>>> similar simple requirements: valid notBefore& notAfter. >>>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5 >>>>>=20 >>>>> Teco From royersoftwareandservices@gmail.com Thu Aug 23 13:57:41 2012 Return-Path: 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 EA84A21F84FD for ; Thu, 23 Aug 2012 13:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Ep7iZrkJrvgk for ; Thu, 23 Aug 2012 13:57:41 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A99621F8448 for ; Thu, 23 Aug 2012 13:57:41 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so2110139pbb.31 for ; Thu, 23 Aug 2012 13:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QbV9ii3+6cMcpkQsbHelYPXSvhubqCjW7Xfu8EFAShw=; b=gfU8dzLJ6fFjVzGvGJRMfHFK5DqHMwYleZmzjnQoFSTuuOt5lRNe0cJXQz7iyT2X27 J3G90i9x91mCgUNI0VDFDUeIqVf5Je9D8pYNjpYOLQjlujoE5mvlH+n6EI6oXA2k5qbH jvTYLRsOON4r+sJ8pSQqHMbODPl7XLpcq20sDVMmqF4UP3rV0zpT0mDKoYs/r/YgJ0TT p1xG0FVOeOOE15jUmlhoxUSOGErHZKYAejjohGAaWMqAeaaWZDWRSK7S3bVP/KnyvLXY VJH5r7jUh/U0ZyJ6Y+hC9jT9MI8qqYjTX63CnBGOqsYsRfTanXtz+AqS+8Rfr1Mlk4+y XmHQ== Received: by 10.68.224.161 with SMTP id rd1mr7652241pbc.133.1345755461042; Thu, 23 Aug 2012 13:57:41 -0700 (PDT) Received: from [192.168.15.4] (184-76-96-188.war.clearwire-wmx.net. [184.76.96.188]) by mx.google.com with ESMTPS id io1sm6687247pbc.67.2012.08.23.13.57.39 (version=SSLv3 cipher=OTHER); Thu, 23 Aug 2012 13:57:40 -0700 (PDT) Message-ID: <50369943.1050706@gmail.com> Date: Thu, 23 Aug 2012 14:57:39 -0600 From: Robert Smith Organization: Software and Services User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: paws@ietf.org References: <1345171058.97121.YahooMailNeo@web120305.mail.ne1.yahoo.com> <8375F6DAEFB09F48815203F1FE23B797117AA6D8CF@shelby> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB5DBC@008-AM1MPN1-006.mgdnok.nokia.com> <8375F6DAEFB09F48815203F1FE23B797117AA6D9E1@shelby> <50367EE8.4080106@blindcreek.com> <8375F6DAEFB09F48815203F1FE23B797117AA6D9ED@shelby> <5963DDF1F751474D8DEEFDCDBEE43AE716E283EC@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E283EC@dfweml512-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 20:57:42 -0000 In my experience with the IETF at the final levels of RFC acceptance they reject duplicate implementations of objects or protocols. We tried that with CALSCH, (xml and iCal/vCard format). They rejected it in both formats. We had to pick only one. In a separate draft that never went to RFC status we proposed a translation guide (iCal data translation to/from XML). However only one could be the 'standard' format. I mostly just follow this WG. I would suggest that the WG leads check with the IETF to make sure that they will accept a specification that has 2 formats for the same data. - From Basavaraj.Patil@nokia.com Thu Aug 23 14:43:43 2012 Return-Path: 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 6F10F21F8527 for ; Thu, 23 Aug 2012 14:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.006 X-Spam-Level: X-Spam-Status: No, score=-106.006 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 GnCpSOVw14FJ for ; Thu, 23 Aug 2012 14:43:37 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 04E8F21F849B for ; Thu, 23 Aug 2012 14:43:36 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7NLhXPk006002; Fri, 24 Aug 2012 00:43:34 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Aug 2012 00:43:33 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0283.004; Thu, 23 Aug 2012 23:43:32 +0200 From: To: , Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Iej7JadvAx8UahySbuq9n2zQAAU/5DAJUxXAAABrI7AAAWoncAABh1noAAifZJAAAEHtqAAAHwqAAADmEvAACA/ioAAAG/7gAAADZkgAABIt+A///NtAA= Date: Thu, 23 Aug 2012 21:43:31 +0000 Message-ID: In-Reply-To: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [72.64.105.77] Content-Type: multipart/alternative; boundary="_000_CC5C0E0D22872basavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 23 Aug 2012 21:43:33.0202 (UTC) FILETIME=[57C24320:01CD8178] X-Nokia-AV: Clean Cc: paws@ietf.org 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 21:43:43 -0000 --_000_CC5C0E0D22872basavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree with Brian. There needs to be a default mandatory to implement option in order to achie= ve interoperability. And this applies to the device and database side of the protocol. -Raj From: "", "Brian.Rosen@neustar.biz" > Date: Thursday, August 23, 2012 2:43 PM To: Don Joslyn > Cc: "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 impleme= ntations. On the other hand, the whole point of a protocol document like o= urs is that two independent implementations who both follow the document wi= ll 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 fig= ure it out using proprietary protocols. The market will decide. So, I feel strongly that if one end is "either", the other end must be "bot= h". It's also acceptable to say both ends implement one choice and the oth= er is optional at both ends. Here, I think it's server does both and clien= t does either. It's always possible to build an implementation of a server that only does = one: there are no protocol police. Brian On Aug 23, 2012, at 3:11 PM, Don Joslyn > 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-boun= ces@ietf.org] On Behalf Of Benjamin A. Rolfe Sent: Thursday, August 23, 2012 3:05 PM To: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal Someone suggested that PAWS define both, and let the vendors decide which o= nes to implement. That makes the most sense for both DB and device vendors. Markets will pro= bably drive DB vendors to do both. Device vendors will do what fits the mar= ket segment they're after. Why over-constrain (or argue when natural select= ion will take care of it for us?). B Sounds good to me. From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Tuesday, August 21, 2012 12:42 AM To: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal Now I can=92t see anymore any willingness to agree on one or the other enco= ding. To prevent endless discussions on this topic I=92d 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-boun= ces@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; 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 nee= ded for XML From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Don Josly= n Sent: Monday, August 20, 2012 4:54 PM To: Vincent Chen; Weixinpeng Cc: paws@ietf.org; Manikkoth Sajeev Subject: Re: [paws] XML schema versus JSON, vCard & iCal Please see my comments below=85 Thanks, Don From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: Monday, August 20, 2012 2:56 PM To: Weixinpeng Cc: 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 de= vice manufacturers. This lowers the barrier for building a robust ecosystem= . [DJ - The =93cost=94 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 be= tter define =93cost=94?] * To reduce complexity and cost for device makers, supporting 1 encodin= g is better than both, as Brian points out. WiFi access points that "just w= ork" 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=92m forced to pick only one, then I will vote for X= ML because it=92s 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 (cli= ent-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 nee= ded for XML. Apparently, the efficiency gains of JSON also matter to the scalability of = serving systems. [DJ =96 I can=92t argue against these listed pros for JSON, especially when= you=92re dealing with a lot of data (like Twitter, FourSquare, Facebook an= d Google does). But I=92m assuming that PAWS messages will not be exchanged= nearly as often as the applications mentioned above. But again, I know JSO= N is more efficient, can=92t 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 w= e're clear on what device makers want. It would be good to get feedback fro= m device makers (especially of embedded devices) regarding experiences supp= orting 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 device= s) 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 muc= h or exchanged that often.] On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > 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-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; gabor.bajko@nokia.com; = vchen@google.com; peter@spectrumbridge.com Cc: 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 desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml optioncan also work= . JSON I think will necessitate implementation to be native Java and may no= t be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CC5C0E0D22872basavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9B03EB733B6AF747A057F9D2DBA1C4E8@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable

I agree with Brian.
There needs to be a default mandatory to implement option in order to = achieve interoperability. 

[DJ - We currently support half a dozen TVDB radio vendo= rs (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 datab= ase is not that much or exchanged that often.]

On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng <weixinpeng@huawei.com> wrote:

Consideri= ng of the design of database discovery protocol, the LoST protocol may be u= sed and LoST is based on XML, so I think XML may be preferred.<= /o:p>

 

--Xinpeng Wei

 

From: paws-b= ounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Rosen, Brian


Sent: Friday, August= 17, 2012 9:26 PM

To: Manik= koth Sajeev; gab= or.bajko@nokia.com; vchen@google.com; peter@spectrumbridge.com


Cc: paws@ietf.org
Subject: Re: [paws] XML schema versus JSON,= vCard & iCal

 

I don't really care wh= ether 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 repr= esentation of an existing standard.  So, if choosing json means folks = feel free to ignore existing xml based standards such as xCard and LoST, th= en I would not want to use json.

 

I would prefer t= o not have "both", because of interoperability complications. &nb= sp;If there is rough consensus for both, then I would assert that all serve= rs have to implement both and the client can implement either.<= /o:p>

 

There are json validators, so I don't think that is a big deal.=  

 

My experience in protocol design on the Int= ernet is that decisions made solely or even largely because of compactness = advantages rarely are good choices.  If you like json because it is sm= aller, then I believe you need a much better reason.  Binary doesn't w= ork for me, at all.  I have been involved in big binary vs text wars i= n protocol design.  Text wins, binary loses, in my opinion.

 

=

Brian <as individual>

<= p class=3DMsoNormal> 

Sajeev Mani= kkoth
Mobile: +9187922= 92002
Email: mk= saji@ieee.org
http://www.linkedin.com/in/mksajeev

 =

From= : "Gabor.= Bajko@nokia.com" <Gabor.Bajko@nokia.com>
To: Brian.Rosen@neustar.biz; vchen@google.com; <= a href=3D"mailto:peter@spectrumbridge.com" target=3D"_blank">peter@spectrum= bridge.com
Cc: 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 encodin= g instead of XML.
Therefore, let's go for JSON, and close this thread.<= br>
- Gabor

-----Original Message-----
From: paws-bounces@ietf.org [mailto= :paws-bounces@ie= tf.org] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 = 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: '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.  Do= n't care a whole lot about that

Brian <as individual>

<= br>
-----Original Message-----
From:     Vincent Chen = [mailto:vchen@google.= com]
Sent:    Monday, August 13, 2012 06:04 PM Easter= n Standard Time
To:    Peter Stanforth
Cc:  =   Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
Subject:    R= e: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON
Between XML and JSON, JSON messages are more compact and easier to proces= s (parsing, synthesis). As clarification, JSON does not require JavaScript = or a Browser. It is a text-based representation of data that is language in= dependent, yet well-matched to all major languages. JSON-handling libraries= exist for numerous languages (see of 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 device= s 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> wrot= e:


    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
    o= n that one.
   
    On MonAug/13/12 Mo= n Aug 13, 9:30 AM, "Rosen, Brian"
   
 = ;   <Brian.Rosen@neustar.biz> wrote:
   
 =    >Our experience in the IETF over many years is that economi= zing message
    >size and compromising utility and se= curity in search of efficiency of
    >implementation = on small devices is a poor trade off.  I am not advocating
 &n= bsp;  >being wasteful of resources, but I don't think we should ser= iously
    >consider the overhead of XML or json to be= significant.
    >
    >Assuming= a json library can be loaded on a small device is reasonable.
 &nb= sp;  >
    >Brian (as individual)
 &nb= sp;  >
    >
    >
&nb= sp;   > -----Original Message-----
    >F= rom:  Peter Stanforth [mailto:peter@spectrumbridge.com]
    &= gt;Sent:  Saturday, August 11, 2012 07:13 AM Eastern Standard Time
=     >To:    Teco Boot; Benjamin A.Rolfe
&nbs= p;   >Cc:    paws@ietf.org
    >Subject:  &nbs= p;   Re: [paws] XML schema versus JSON, vCard & iCal
 &nbs= p;  >
    >Not all masters run over the core n= etwork.
    >Some of the Use cases have a master talki= ng to another OTA
    >We should not assume that all M= asters 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 Bo= ot" <teco@inf-= net.nl> wrote:
    >
    >= >
    >>Op 10 aug. 2012, om 18:10 heeft Benjamin= A. Rolfe het volgende
    >>geschreven:
 &= nbsp;  >>
    >>> Compactness of mess= ages is important, but it is also important (to me
    &g= t;>>at least) to be realizable in an implementation with limited reso= urces,
    >>>such as embedded devices in what a= re now popularly called "M2M"
    >>>a= pplications.  A lot of these devices could use IP all the end to end,<= br>    >>>but may have a very compact, simple stack= and applications (i.e.  no
    >>>browser)= .  Is JSON typically implemented when there is no browser?
 &n= bsp;  >>>Would it be hard to do in a resource constrained dev= ice (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/T= LS code size supersedes needs
    >>for JSON or XML= .
    >>
    >>Same for tim= ing: TCP/TLS connection setup will take more than the PAWS
  &= nbsp; >>message exchange, I think. This may be of importance when usi= ng satcom
    >>links.
    >&g= t;
    >>Because PAWS runs between master and datab= ase, over core network,
    >>performance is not ou= r primary concern. But as always, it is good to keep
    = >>an eye on efficiency.
    >>
  = ;  >>Teco
    >>
    &= gt;>> Thanks
    >>> Ben
  &n= bsp; >>>
    >>>
    = >>>> We had a discussion on XML vs. JSON. I prefer the one with= most
    >>>>compact messages.
 &nbs= p;  >>>>
    >>>> On vCard a= nd JSON: what is the status of "A JavaScript Object Notation
 =    >>>>(JSON) Representation for vCard"?
&nbs= p;   >>>> http://tools.ietf.org/html/draft-= bhat-vcarddav-json-00
    >>>>
 &= nbsp;  >>>> On valid times: can we use same format as cert= ificates? They have
    >>>>similar simple re= quirements: valid notBefore&  notAfter.
    >= >>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5    >>>>
    >>>>= ; Teco
    >>>> _____________________________= __________________
    >>>> paws mailing list=
    >>>> paws@ietf.org
    >>>> http= s://www.ietf.org/mailman/listinfo/paws
    >>&g= t;>
    >>>
    >>>= ; _______________________________________________
    >= ;>> paws mailing list
    >>> paws@ietf.org
  &nb= sp; >>> https://www.ietf.org/mailman/listinfo/paws
 &nbs= p;  >>
    >>___________________________= ____________________
    >>paws mailing list
&nb= sp;   >>= paws@ietf.org
    >>https://www.ietf.org/mailman/= listinfo/paws
    >
    >____= ___________________________________________
    >paws = mailing list
    >paws@ietf.org
    >https://www.ietf.o= rg/mailman/listinfo/paws
   
    _= ______________________________________________
    paws m= ailing list
    paws@ietf.org
    https://www.ietf.org/mail= man/listinfo/paws
   




--
-vin= ce

_______________________________________________
paws mailing l= ist
paws@ietf.org=
https://www.ietf.org/mailman/listinfo/paws
_______________________= ________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/li= stinfo/paws



 

-- -vince

And this applies to the device and database side of the protocol.

-Raj

From: "<ext Rosen>"= , "Brian.Rosen@neustar.biz<= /a>" <Brian.Rosen@neusta= r.biz>
Date: Thursday, August 23, 2012 2:4= 3 PM
To: Don Joslyn <d.joslyn@spectrumbridge.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] XML schema vers= us JSON, vCard & iCal

One of my favorite IETF expressions is "There are no protocol police&q= uot;.  We apply that in lots of ways, but one of them is that if you d= on't implement what the document says, you may not get interoperability wit= h other implementations.  On the other hand, the whole point of a protocol document like ours is that two independent imple= mentations 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 interop= erability.  

By your argument, we should stop working, and the product managers wil= l figure it out using proprietary protocols.  The market will decide.<= /div>

So, I feel strongly that if one end is "either", the other e= nd must be "both".  It's also acceptable to say both ends im= plement one choice and the other is optional at both ends.  Here, I th= ink 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> wrote:

Hi Ben,
That was my original suggestion, and I still think it mak= es the most sense.
Thanks for supporting the proposal.
Don
 
From: paws-bounces@ietf= .org [mailto:paws-bounces@ietf.org] On Behalf Of Benj= amin A. Rolfe
Sent: Thursday, Au= gust 23, 2012 3:05 PM
To: paws@ietf.org
Subject: Re: [paws= ] XML schema versus JSON, vCard & iCal
 
Someone suggested that PAWS define both, and let the vendors decide which o= nes to implement.
That makes the most sense for both DB and device vendors.  Markets wil= l probably drive DB vendors to do both. Device vendors will do what fits th= e market segment they're after. Why over-constrain (or argue when natural s= election will take care of it for us?).
B

Sounds = good to me.
 <= /span>
From:=  p= aws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Tuesday, Aug= ust 21, 2012 12:42 AM
To: pa= ws@ietf.org
Subject: Re: [paws= ] XML schema versus JSON, vCard & iCal
 
Now I c= an=92t see anymore any willingness to agree on one or the other encoding.
To prev= ent endless discussions on this topic I=92d suggest we move forward with su= pporting both in the DB and either one in the master device.
Any obj= ections?
 <= /span>
Gabor
 <= /span>
 <= /span>
From:=  p= aws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] On Behalf Of ext Das, S= ubir
Sent: Monday, Augu= st 20, 2012 2:50 PM
To: Don Joslyn; Vi= ncent Chen; Weixinpeng
Cc: pa= ws@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:
 <= /span>
    • Simple-= to-use libraries exist for all major languages/platforms<= /li>
    • Don't n= eed a tool chain to work with the data, as is typically needed for XML
 <= /span>
 <= /span>
 <= /span>
From:=  p= aws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] On Behalf Of Don Joslyn=
Sent: Monday, Augu= st 20, 2012 4:54 PM
To: Vincent Chen; = Weixinpeng
Cc: pa= ws@ietf.org; Manikkoth Sajeev
Subject: Re: [paws= ] XML schema versus JSON, vCard & iCal
 
Please = see my comments below=85
Thanks,=
Don
 <= /span>
From:=  p= aws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Ch= en
Sent: Monday, Augu= st 20, 2012 2:56 PM
To: Weixinpeng
Cc: pa= ws@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 manufact= urers. This lowers the barrier for building a robust ecosystem.=
[DJ - The =93cost=94 and complexi= ty 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 =93cost=94?]
  • To redu= ce complexity and cost for device makers, supporting 1 encoding is better t= han 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 databas= es support both XML and JSON, devices only need to support one to talk to t= he database. Our current database supports XML and JSON, but if I=92m force= d to pick only one, then I will vote for XML because it=92s the one that we currently use on all embedded devic= es.]
  • There's= a trend for APIs on the web towards JSON (Twitter, FourSquare, Facebook, G= oogle, etc.). One of the major reasons is that developers (client-side) pre= fer it for its simplicity:
    • Represe= ntation closely matches most data models (nested lists and maps)
    • Simple-= to-use libraries exist for all major languages/platforms<= /li>
    • Don't n= eed a tool chain to work with the data, as is typically needed for XML.

Apparen= tly, the efficiency gains of JSON also matter to the scalability of serving= systems.

 <= o:p>
[DJ =96 I can=92t argue against t= hese listed pros for JSON, especially when you=92re dealing with a lot of d= ata (like Twitter, FourSquare, Facebook and Google does). But I=92m assumin= g that PAWS messages will not be exchanged nearly as often as the applications mentioned above. But again, I know JSO= N is more efficient, can=92t 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, ca= n 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 b= etween device and database is not that much or exchanged that often.]

On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng <weixinpeng@huawei.com> wrote:
Considering of the design of database discovery protoco= l, the LoST protocol may be used and LoST is based on XML, so I think XML m= ay be preferred.
 
--Xinpeng Wei
 
From:=  paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Rosen, Bri= an

Sent: Friday, Augu= st 17, 2012 9:26 PM

Cc: 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 defini= ng 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 ign= ore existing xml based standards such as xCard and LoST, then I would not want to use json.
 = ;
I wou= ld prefer to not have "both", because of interoperability complic= ations.  If there is rough consensus for both, then I would assert tha= t 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 ex= perience in protocol design on the Internet is that decisions made solely o= r even largely because of compactness advantages rarely are good choices. &= nbsp;If you like json because it is smaller, then I believe you need a much better reason.  Binary doesn't work fo= r me, at all.  I have been involved in big binary vs text wars in prot= ocol design.  Text wins, binary loses, in my opinion.
 = ;
Brian= <as individual>
 = ;
From= : Manikkoth Sajeev &= lt;mksaji@yahoo.com>
Reply-To: Manikkot= h Sajeev <mksaji@yahoo.com>
Date: Thu, 16 Aug = 2012 22:37:38 -0400
To: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>, "Rosen, Brian" <brian= .rosen@neustar.biz>, "vchen@go= ogle.com" <vchen@google.com>, "peter@spectrumbridge.com" <peter@spectrumbridge.com&= gt;
Cc: "paws@ietf.org" <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 im= plementations may prefer = XML as it is generic, omni present, easy to understand and val= idate. For compactness may be a  binary xml optioncan also work. JSON I think will neces= sitate implementation to be native Java and may not be as friendly with oth= er implementation languages.
 
Best Regards,
 
From:<= /span> "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com> To: Brian.Rosen@neustar.biz; vchen@google= .com; peter@spectrumbridge.com 
Cc: paws@ietf.org&nbs= p;
Sent: Friday, 17 A= ugust 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-boun= ces@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'
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.&nbs= p; It's very easy to parse, and its simpler to use and debug.  Don't c= are a whole lot about that

Brian <as individual>



-----Original Message-----
From:     Vincent Chen [mailto:vchen@google.com]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard T= ime
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@= ietf.org
Subject:    Re: [paws] XML schema versus JSON, vCard & i= Cal

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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries exist for numerous languages (see= of http://json.org/) and seem to be reasonably light weight.

Timestamps

As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries 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> wrote:


    Whenever we built mobile devices we never dealt with IET= F, in our sensor
    days even an IP stack was a challenge,so I would defer t= o the device guys
    on that one.
    
    On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian&= quot;
    
    <Brian.Rosen@= neustar.biz> wrote:
    
    >Our experience in the IETF over many years is that e= conomizing 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 sh= ould seriously
    >consider the overhead of XML or json to be significa= nt.
    >
    >Assuming a json library can be loaded on a small dev= ice is reasonable.
    >
    >Brian (as individual)
    >
    >
    >
    > -----Original Message-----
    >From:  Peter Stanforth [mailto:peter@spectrumbridge.com]
    >Sent:  Saturday, August 11, 2012 07:13 AM Easte= rn Standard Time
    >To:    Teco Boot; Benjamin A.Rolfe
    >Cc:    paws@ietf.org
    >Subject:      Re: [paws] XML schema v= ersus JSON, vCard & iCal
    >
    >Not all masters run over the core network.
    >Some of the Use cases have a master talking to anoth= er OTA
    >We should not assume that all Masters are attached t= o 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> wrote:     >
    >>
    >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolf= e het volgende
    >>geschreven:
    >>
    >>> Compactness of messages is important, but i= t is also important (to me
    >>>at least) to be realizable in an implementat= ion with limited resources,
    >>>such as embedded devices in what are now pop= ularly called "M2M"
    >>>applications.  A lot of these devices c= ould use IP all the end to end,
    >>>but may have a very compact, simple stack an= d applications (i.e.  no
    >>>browser).  Is JSON typically implemente= d when there is no browser?
    >>>Would it be hard to do in a resource constra= ined device (i.e. where we
    >>>talk about memory size in Kilo-bytes still).=
    >>
    >>In use cases and requirements document, there ar= e 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 t= ake more than the PAWS
    >>message exchange, I think. This may be of import= ance when using satcom
    >>links.
    >>
    >>Because PAWS runs between master and database, o= ver core network,
    >>performance is not our primary concern. But as a= lways, 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 o= f "A JavaScript Object Notation
    >>>>(JSON) Representation for vCard"?     >>>>&n= bsp;= 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 notBe= fore&  notAfter.
    >>>>&n= bsp;http= ://tools.ietf.org/html/rfc3280#section-4.1.2.5
    >>>>
    >>>> Teco
    >>>> _______________________________________= ________
    >>>> paws mailing list
    >>>>&n= bsp;paws@ietf.org
    >>>>&n= bsp;https://www.= ietf.org/mailman/listinfo/paws
    >>>>
    >>>
    >>> ___________________________________________= ____
    >>> paws mailing list
    >>> = paws@ietf.org
    >>> = https://www.ietf= .org/mailman/listinfo/paws
    >>
    >>_______________________________________________<= br>     >>paws mailing list
    >>paws@ietf.org<= br>     >>https://www.ietf.org/mailman/listinfo/paws
    >
    >_______________________________________________
    >paws mailing list
    >paws@ietf.org
    >= https://www.ietf.org/mailman/listinfo/paws
    
    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/= listinfo/paws
    




-- 
-vince

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/ma= ilman/listinfo/paws
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/ma= ilman/listinfo/paws



 
-- 
-vince
 
 
_______________________________________________

paws mailing list


paws@ietf.org


https://www.ietf.org/mailman/=
listinfo/paws



 
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org= /mailman/listinfo/paws

--_000_CC5C0E0D22872basavarajpatilnokiacom_-- From d.joslyn@spectrumbridge.com Fri Aug 24 07:52:16 2012 Return-Path: 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 A521F21F86DB for ; Fri, 24 Aug 2012 07:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] 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 9hy87-f31kBr for ; Fri, 24 Aug 2012 07:52:06 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4939021F86CB for ; Fri, 24 Aug 2012 07:52:01 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Fri, 24 Aug 2012 10:51:59 -0400 From: Don Joslyn To: "Basavaraj.Patil@nokia.com" , "Brian.Rosen@neustar.biz" , Peter McCann , "paws@ietf.org" Date: Fri, 24 Aug 2012 10:51:59 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Iej7JadvAx8UahySbuq9n2zQAAU/5DAJUxXAAABrI7AAAWoncAABh1noAAifZJAAAEHtqAAAHwqAAADmEvAACA/ioAAAG/7gAAADZkgAABIt+A///NtAD//m7VcA== Message-ID: <8375F6DAEFB09F48815203F1FE23B797117AA6DA32@shelby> References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B797117AA6DA32shelby_" MIME-Version: 1.0 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 14:52:17 -0000 --_000_8375F6DAEFB09F48815203F1FE23B797117AA6DA32shelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It appears that we have a growing consensus that the database must support = both formats while allowing the device to support either format (or both). = I agree with this decision. As Gabor originally suggested, let's move forwa= rd with supporting both in the DB and either one in the master device. Regards, Don From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: Thursday, August 23, 2012 5:44 PM To: Brian.Rosen@neustar.biz; Don Joslyn Cc: 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 achie= ve interoperability. And this applies to the device and database side of the protocol. -Raj From: "", "Brian.Rosen@neustar.biz" > Date: Thursday, August 23, 2012 2:43 PM To: Don Joslyn > Cc: "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 impleme= ntations. On the other hand, the whole point of a protocol document like o= urs is that two independent implementations who both follow the document wi= ll 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 fig= ure it out using proprietary protocols. The market will decide. So, I feel strongly that if one end is "either", the other end must be "bot= h". It's also acceptable to say both ends implement one choice and the oth= er is optional at both ends. Here, I think it's server does both and clien= t does either. It's always possible to build an implementation of a server that only does = one: there are no protocol police. Brian On Aug 23, 2012, at 3:11 PM, Don Joslyn > 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-boun= ces@ietf.org] On Behalf Of Benjamin A. Rolfe Sent: Thursday, August 23, 2012 3:05 PM To: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal Someone suggested that PAWS define both, and let the vendors decide which o= nes to implement. That makes the most sense for both DB and device vendors. Markets will pro= bably drive DB vendors to do both. Device vendors will do what fits the mar= ket segment they're after. Why over-constrain (or argue when natural select= ion will take care of it for us?). B Sounds good to me. From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Tuesday, August 21, 2012 12:42 AM To: 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 encodi= ng. To prevent endless discussions on this topic I'd suggest we move forward wi= th supporting both in the DB and either one in the master device. Any objections? Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@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; 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 need= ed for XML From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Don Josly= n Sent: Monday, August 20, 2012 4:54 PM To: Vincent Chen; Weixinpeng Cc: 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-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: Monday, August 20, 2012 2:56 PM To: Weixinpeng Cc: 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 dev= ice 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 wo= rk" 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 (clie= nt-side) prefer it for its simplicity: * Representation closely matches most data models (nested lists and m= aps) * Simple-to-use libraries exist for all major languages/platforms * Don't need a tool chain to work with the data, as is typically need= ed 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 Goog= le 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 mor= e efficient, can't argue with that.] * At the end of the day, it's the data model that matters, rather than t= he 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 suppo= rting 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 device= s) 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 muc= h or exchanged that often.] On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > 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-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; gabor.bajko@nokia.com; = vchen@google.com; peter@spectrumbridge.com Cc: 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 desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml optioncan also work= . JSON I think will necessitate implementation to be native Java and may no= t be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_8375F6DAEFB09F48815203F1FE23B797117AA6DA32shelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It appear= s that we have a growing consensus that the database must support both form= ats while allowing the device to support either format (or both). I agree w= ith this decision. As Gabor originally suggested, let’s move forward = with supporting both in the DB and either one in the master device.

 

Regards, Don

 

From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]
Sent:= Thursday, August 23, 2012 5:44 PM
To: Brian.Rosen@neustar.bi= z; Don Joslyn
Cc: paws@ietf.org
Subject: Re: [paws] XML= schema versus JSON, vCard & iCal

 

&= nbsp;

I agree with Bri= an.

There needs t= o be a default mandatory to implement option in order to achieve interopera= bility. 

And= this applies to the device and database side of the protocol.

 

<= /div>

-Raj

 

From: "<ext Rosen>", &= quot;Brian.Rosen@neustar.biz= " <Brian.Rosen@neustar.b= iz>
Date: Thursday, August 23, 2012 2:43 PM
To: = Don Joslyn <d.joslyn@spec= trumbridge.com>
Cc: "paws@ietf.org" <paws@ietf.org= >
Subject: Re: [paws] XML schema versus JSON, vCard & = iCal

 <= /o:p>

One of my favorit= e IETF expressions is "There are no protocol police".  We ap= ply that in lots of ways, but one of them is that if you don't implement wh= at the document says, you may not get interoperability with other implement= ations.  On the other hand, the whole point of a protocol document lik= e ours is that two independent implementations who both follow the document= will interwork.  If that wasn't true, why do you need a standard?

 <= /p>

If you say "either" to bo= th ends, then you don't get interoperability.  

<= /div>

 

=

By your argument, we should stop working, and the= product managers will figure it out using proprietary protocols.  The= market will decide.

<= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:bla= ck'> 

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 se= rver does both and client does either. 

 

It's always possible to build an implementation of a serv= er that only does one: there are no protocol police.

<= /div>

 

=

Brian <as individual>

=

 

 

 

 

On Aug 23, 2012, at 3:11 PM, Don Joslyn <d.joslyn@spectrumbridge.com> wrote:



<= div>

Hi Ben,<= o:p>

That was my ori= ginal suggestion, and I still think it makes the most sense.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>Thanks for supporting the proposal.

Don

 

<= /div>

From: paws-bounces@= ietf.org [mailto:paws-bounces@ietf.org]&n= bsp;On Behalf Of = Benjamin A. Rolfe
Sent:&n= bsp;Thursday, August 23, 2012 3:05 PM
To: paws@ietf.= org
Subject: = Re: [paws] XML schema versus JSON, vCard & iCal

 

Someone suggested that PAWS defi= ne 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 se= gment they're after. Why over-constrain (or argue when natural selection wi= ll take care of it for us?).
B


Sounds good to me.

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
= Sent: Tuesday, Augus= t 21, 2012 12:42 AM
To: = paws@i= etf.org
Subject:&n= bsp;Re: [paws] XML schema versus JSON, vCard & iCal

 

=

Now I can’t see anymore any willingnes= s to agree on one or the other encoding.=

To prevent endle= ss discussions on this topic I’d suggest we move forward with support= ing both in the DB and either one in the master device.

Any objections?

 

Gabor

 

 <= /p>

From:=  paws-bounces@iet= f.org [mailto:paws-= bounces@ietf.org] On Behalf Of ext D= as, Subir
Sent: M= onday, August 20, 2012 2:50 PM
To: Don Joslyn; Vincent Chen; Weixinpeng
Cc: = 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.

Als= o I will copy the following two important points:

 =

      Simple-to-use l= ibraries exist for all major languages/platforms
    • Don't need a too= l chain to work with the data, as is typically needed for XML

 

 

=

 

From:=  = paws-= bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of&nbs= p;Don Joslyn
Sent:=  Monday, August 20, 2012 4:54 PM
To: Vincent Chen; Weixinpeng
Cc: paws@ietf.org; Manikkoth SajeevSubject: Re: [paws= ] XML schema versus JSON, vCard & iCal

 

Please see my comments below…

Thanks,

Don<= /p>

 

= From: paws-bounces@ietf.org&nb= sp;[mailto:paws-bounces@ietf.org] On Behalf Of&nbs= p;Vincent Chen
Sent: Monday, August 20, 2012 2:56 PM
To: Weixinpeng
Cc: 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 f= or device manufacturers. This lowers the barrier for building a robust ecos= ystem.

[DJ - The “cost” and complexity of using XML has= not been an issue for the half dozen TVBD vendors that have already used X= ML. Maybe we need to better define “cost”?]

  • To reduce complexity and cost for device makers, support= ing 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, devic= es only need to support one to talk to the database. Our current database s= upports 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 embed= ded 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 sim= plicity:
    • Representation clos= ely 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, a= s is typically needed for XML.

Apparently, the efficiency gains of JSON also m= atter to the scalability of serving systems.

 

[= DJ – I can’t argue against these listed pros for JSON, especial= ly when you’re dealing with a lot of data (like Twitter, FourSquare, = Facebook and Google does). But I’m assuming that PAWS messages will n= ot be exchanged nearly as often as the applications mentioned above. But ag= ain, 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 goo= d to get feedback from device makers (especially of embedded devices) regar= ding 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 vend= ors (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 data= base is not that much or exchanged that often.]

On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng <w= eixinpeng@huawei.com> wrote:

=

Considering of the design of database disc= overy protocol, the LoST protocol may be used and LoST is based on XML, so = I think XML may be preferred.=

 

--Xinpeng Wei

 

<= b>From: = paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Rosen, Brian


Sent: Friday, August 17, 2012 9:26 PM<= /p>


Cc: paws@ietf.org<= br>Subject: Re: [paw= s] XML schema versus JSON, vCard & iCal

&n= bsp;

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 definin= g new ones, and I would not want to see the choice of json mean we then dec= ide to roll our own versus using existing standards based on the idea there= is no json representation of an existing standard.  So, if choosing j= son means folks feel free to ignore existing xml based standards such as xC= ard and LoST, then I would not want to use json.

 

I would prefer to not have "bot= h", 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.

&nb= sp;

There are json validators, so I don't thin= k that is a big deal.  <= /span>

 

My experience in protocol design on the Internet is that= decisions made solely or even largely because of compactness advantages ra= rely 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, a= t all.  I have been involved in big binary vs text wars in protocol de= sign.  Text wins, binary loses, in my opinion.

 

=

Brian <as individual>

 

From:=  Manikkoth = Sajeev <mksaji@yahoo.com>
Reply-To: Manikkoth Sajeev <mk= saji@yahoo.com>
Date: Thu, 16 Aug 2012 22:37:38 -0400
To: "Gabor.Bajko@nokia.= com" <Gabor.Bajko@nokia.com>,= "Rosen, Brian" <brian.rosen@neustar.biz= >, "vchen@google.com" <vchen= @google.com>, "peter@spectrumbridge.com<= /span>" <peter@spectrumbridge.com>= ;
Cc: "= paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] XM= L schema versus JSON, vCard & iCal

 =

<= div>

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 pre= sent, easy to understand and validate. For compactness may be a  binary xml optioncan also work. J= SON I think will necessitate implementation to be native Java and may not b= e as friendly with other implementation languages.

 

Best Regards,

=

Sajeev Manikkoth
Mobile: +918792292002=
Email: mksaji@ie= ee.org
http://www.linkedin.com/in/mksajee= v

 

From: "Ga= bor.Bajko@nokia.com" <Gabor.Bajko@nokia.com= >
To: Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.= com 
Cc: paws@ietf.org 
Sent: Friday, 17 August 2012, 4:55Subject: Re: [paws]= XML schema versus JSON, vCard & iCal


We have no= t heard any objections for using JSON encoding instead of XML. 
Therefore, let's go for JSON, and= close this thread.

- Gabor

-----Original Message-----
Fro= m: paws-bounce= s@ietf.org [mail= to:paws-bounces@ietf.org] On Behalf Of ext Rosen,= Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Pet= er Stanforth'
Cc: 'paws@ietf.org'
Subject: Re: [paws]= XML schema versus JSON, vCard & iCal

json is okay with me. = ; 
I'd prefer an ISO tim= e 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 Messa= ge-----
From:     Vincent Chen [mailto:vchen@goog= le.com]
Sent:    Monday, August 13, 2012 06:04= PM Eastern Standard Time
To:    Peter Stanforth
Cc:&n= bsp;   Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
Subject:&= nbsp;   Re: [paws] XML schema versus JSON, vCard & iCal
XML vs JSON

Between XML and JSON, JSON messages are more compact a= nd 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/) and seem to be = reasonably light weight.

Timestamps

As for timestamp specific= ations, should we consider just using seconds since the UNIX Epoch (1970-01= -01T00:00:00Z)? This would eliminate the need for datetime-string parsing o= n 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 &l= t;peter@spectrumbridge.com> wrote:

    Whenever we built mobile devices we never dealt with IE= TF, in our sensor
    days even an IP stack was a challen= ge,so I would defer to the device guys
    on that one.    
&n= bsp;   On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian&qu= ot;
    <= br>    <Brian.Rosen@neustar.biz= > wrote:
    =
    >Our experience in the IETF over many year= s is that economizing message
    >size and compromisi= ng utility and security in search of efficiency of
    &g= t;implementation on small devices is a poor trade off.  I am not advoc= ating
    >being wasteful of resources, but I don't th= ink we should seriously
    >consider the overhead of = XML or json to be significant.
    >
  &n= bsp; >Assuming a json library can be loaded on a small device is reasona= ble.
    >
    >Brian (as individ= ual)
    >
    >
  &= nbsp; >
    > -----Original Message-----
 &= nbsp;  >From:  Peter Stanforth [mailto:peter@s= pectrumbridge.com]
    >Sent:  Saturda= y, August 11, 2012 07:13 AM Eastern Standard Time
    >= ;To:    Teco Boot; Benjamin A.Rolfe
    >Cc:=     paws@iet= f.org
    >Subject:      Re:= [paws] XML schema versus JSON, vCard & iCal
    >=
    >Not all masters run over the core network.
&n= bsp;   >Some of the Use cases have a master talking to another= OTA
    >We should not assume that all Masters are at= tached to utility power so we
    >should be sympathet= ic to processing energy use also.
    >
  = ;  >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <= teco@inf-net.nl> wrote:
    >
=     >>
    >>Op 10 aug. 2012, = om 18:10 heeft Benjamin A. Rolfe het volgende
    >>= ;geschreven:
    >>
    >>&= gt; Compactness of messages is important, but it is also important (to me    >>>at least) to be realizable in an implement= ation with limited resources,
    >>>such as emb= edded devices in what are now popularly called "M2M"
 &nb= sp;  >>>applications.  A lot of these devices could use = IP all the end to end,
    >>>but may have a ver= y compact, simple stack and applications (i.e.  no
  &nbs= p; >>>browser).  Is JSON typically implemented when there is = no browser?
    >>>Would it be hard to do in a r= esource constrained device (i.e. where we
    >>>= ;talk about memory size in Kilo-bytes still).
    >>= ;
    >>In use cases and requirements document, the= re are no requirements for
    >>protocol performan= ce. I guess OS/IP/TCP/TLS code size supersedes needs
    = >>for JSON or XML.
    >>
  &nbs= p; >>Same for timing: TCP/TLS connection setup will take more than th= e PAWS
    >>message exchange, I think. This may be= of importance when using satcom
    >>links.
&n= bsp;   >>
    >>Because PAWS runs b= etween master and database, over core network,
    >&g= t;performance is not our primary concern. But as always, it is good to keep=
    >>an eye on efficiency.
    = >>
    >>Teco
    >><= br>    >>> 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 Ob= ject Notation
    >>>>(JSON) Representation f= or vCard"?
    >>>> http://t= ools.ietf.org/html/draft-bhat-vcarddav-json-00
  &n= bsp; >>>>
    >>>> On valid times= : can we use same format as certificates? They have
    &= gt;>>>similar simple requirements: valid notBefore&  notA= fter.
    >>>> http://tools.ietf.org/= html/rfc3280#section-4.1.2.5
    >>>&= gt;
    >>>> Teco
    >&= gt;>> _______________________________________________
  =   >>>> paws mailing list
    >>>= ;> paws@ietf.org
    >>>> https://www.ietf.org/mailma= n/listinfo/paws
    >>>>
 =    >>>
    >>> ______________= _________________________________
    >>> paws m= ailing list
    >>> paws@ietf.org
    >= ;>> https://www.ietf.org/mailman/listinfo/paws
 &n= bsp;  >>
    >>_________________________= ______________________
    >>paws mailing list
&= nbsp;   >>paws@ietf.org
  &nbs= p; >>https://www.ietf.org/mailman/listinfo= /paws
    >
    >_____= __________________________________________
    >paws m= ailing list
    >paws@ietf.org
&nbs= p;   >https://www.ietf.org/mailman/= listinfo/paws
    
    ________________________________= _______________
    paws mailing list
  &nbs= p; paws@ietf.org
    <= span style=3D'color:purple'>https://www.ietf.org/mailman/listinfo/paws
    




-- -vince

_______________________________________________
paws mai= ling list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws
____________________= ___________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/= paws



 

-- -vince

=
 
 <=
/o:p>
________________________=
_______________________
paws mailing list
paws@ietf=
.org
https://www.ietf.org/mailman/listinfo/paws

 

__________________________= _____________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

 

= --_000_8375F6DAEFB09F48815203F1FE23B797117AA6DA32shelby_-- From richard@shockey.us Fri Aug 24 08:16:27 2012 Return-Path: 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 D4C9A21F86FE for ; Fri, 24 Aug 2012 08:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.355 X-Spam-Level: X-Spam-Status: No, score=-100.355 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Dk9zvkSr8xV1 for ; Fri, 24 Aug 2012 08:16:19 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 1189821F86CB for ; Fri, 24 Aug 2012 08:16:19 -0700 (PDT) Received: (qmail 29287 invoked by uid 0); 24 Aug 2012 15:16:18 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy11.bluehost.com with SMTP; 24 Aug 2012 15:16:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=51DLXIBBxlv/3H7gZ/7De+elKw0vHBr8+1Yi7ds9iKo=; b=fG6q901XGrYAo6bBoCHDY2cJGnFaOeAtgknNBmOAz9r4WzxPYBonKLUElkIJ9195yL+EhiG3qqquxgJS4/KRMWr6yPLB83Ba4BjrRLtCR4DUpu2ebg3ZRedyY8xERD3/; Received: from [71.191.243.130] (port=50406 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T4vcP-0001W5-88; Fri, 24 Aug 2012 09:16:18 -0600 From: "Richard Shockey" To: , , References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> In-Reply-To: Date: Fri, 24 Aug 2012 11:16:14 -0400 Message-ID: <00c601cd820b$67b97170$372c5450$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C7_01CD81E9.E0A7D170" X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac15n6Iej7JadvAx8UahySbuq9n2zQAAU/5DAJUxXAAABrI7AAAWoncAABh1noAAifZJAAAEHtqAAAHwqAAADmEvAACA/ioAAAG/7gAAADZkgAABIt+A///NtAD//meaQA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Cc: paws@ietf.org 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 15:16:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C7_01CD81E9.E0A7D170 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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] On Behalf Of Basavaraj.Patil@nokia.com Sent: Thursday, August 23, 2012 5:44 PM To: Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com Cc: 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: "", "Brian.Rosen@neustar.biz" Date: Thursday, August 23, 2012 2:43 PM To: Don Joslyn Cc: "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 On Aug 23, 2012, at 3:11 PM, Don Joslyn 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] On Behalf Of Benjamin A. Rolfe Sent: Thursday, August 23, 2012 3:05 PM To: 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] On Behalf Of Gabor.Bajko@nokia.com Sent: Tuesday, August 21, 2012 12:42 AM To: 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] On Behalf Of ext Das, Subir Sent: Monday, August 20, 2012 2:50 PM To: Don Joslyn; Vincent Chen; Weixinpeng Cc: 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] On Behalf Of Don Joslyn Sent: Monday, August 20, 2012 4:54 PM To: Vincent Chen; Weixinpeng Cc: 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] On Behalf Of Vincent Chen Sent: Monday, August 20, 2012 2:56 PM To: Weixinpeng Cc: 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> 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] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; gabor.bajko@nokia.com; vchen@google.com; peter@spectrumbridge.com Cc: 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 From: Manikkoth Sajeev < mksaji@yahoo.com> Reply-To: Manikkoth Sajeev < mksaji@yahoo.com> Date: Thu, 16 Aug 2012 22:37:38 -0400 To: " Gabor.Bajko@nokia.com" < Gabor.Bajko@nokia.com>, "Rosen, Brian" < brian.rosen@neustar.biz>, " vchen@google.com" < vchen@google.com>, " peter@spectrumbridge.com" < peter@spectrumbridge.com> Cc: " paws@ietf.org" < 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 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: " Gabor.Bajko@nokia.com" < Gabor.Bajko@nokia.com> To: Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com Cc: 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] On Behalf Of ext Rosen, Brian Sent: Monday, August 13, 2012 3:14 PM To: 'Vincent Chen'; 'Peter Stanforth' Cc: ' 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 -----Original Message----- From: Vincent Chen [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 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/) 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> 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> 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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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> 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 >>>> >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws ------=_NextPart_000_00C7_01CD81E9.E0A7D170 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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] On Behalf Of = Basavaraj.Patil@nokia.com
Sent: Thursday, August 23, 2012 = 5:44 PM
To: Brian.Rosen@neustar.biz; = d.joslyn@spectrumbridge.com
Cc: = 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"= <Brian.Rosen@neustar.biz>Date: Thursday, August 23, 2012 2:43 PM
To: Don = Joslyn <d.joslyn@spectrumbridge.com>
Cc: "paws@ietf.org" <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> wrote:

=

From:=  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
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] On Behalf Of Gabor.Bajko@nokia.com
Sent: Tuesday, August 21, 2012 = 12:42 AM
To: 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] On Behalf Of ext Das, = Subir
Sent: Monday, August 20, 2012 2:50 = PM
To: Don = Joslyn; Vincent Chen; Weixinpeng
Cc: 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-u= se 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] On Behalf Of Don = Joslyn
Sent: Monday, August 20, 2012 4:54 = PM
To: Vincent = Chen; Weixinpeng
Cc: 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] On Behalf Of Vincent = Chen
Sent: Monday, August 20, 2012 2:56 = PM
To: Weixinpeng
Cc: 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:
    • Representatio= n 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.

A= pparently, 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.

 

D= on, 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> = 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] On Behalf Of Rosen, Brian


Sent: Friday, August 17, 2012 9:26 = PM


Cc: 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>
Reply-To: Manikkoth Sajeev = <mksaji@yahoo.com>
Date: Thu, 16 Aug 2012 22:37:38 = -0400
To: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>, = "Rosen, Brian" <brian.rosen@neustar.biz>, "vchen@google.com" <vchen@google.com>, "peter@spectrumbridge.com" <peter@spectrumbridge.com>
Cc:<= span class=3Dapple-converted-space> "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] XML schema = versus JSON, vCard & iCal

 

Hi,

 

<= p class=3DMsoNormal style=3D'background:white'>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.

 

<= p class=3DMsoNormal style=3D'background:white'>Best Regards,

 

<= div>

F= rom:&= nbsp;&= quot;Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
To:=  Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com 
Cc: 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] On Behalf Of = ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: = 'Vincent Chen'; 'Peter Stanforth'
Cc: '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]
Sent:  &= nbsp; Monday, August 13, 2012 06:04 PM Eastern Standard = Time
To:    Peter Stanforth
Cc:    = Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
Subject:  &n= bsp; 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/) 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> = 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> = 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]
 &nbs= p;  >Sent:  Saturday, August 11, 2012 07:13 AM Eastern = Standard Time
    >To:    Teco Boot; = Benjamin A.Rolfe
    >Cc:    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> = 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-jso= n-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=
    >>>>
    = >>>> Teco
    >>>> = _______________________________________________
    = >>>> paws mailing list
    = >>>> paws@ietf.org
    = >>>> https://www.ietf.org/mailman/listinfo/paws<= /a>
    >>>>
    = >>>
    >>> = _______________________________________________
    = >>> paws mailing list
    >>> paws@ietf.org
    = >>> https://www.ietf.org/mailman/listinfo/paws<= /a>
    >>
    = >>_______________________________________________
  &n= bsp; >>paws mailing list
    >>paws@ietf.org
    = >>https://www.ietf.org/mailman/listinfo/paws<= /a>
    >
    = >_______________________________________________
   = >paws mailing list
    >paws@ietf.org
    = >https://www.ietf.org/mailman/listinfo/paws<= /a>
    
    = _______________________________________________
    = paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws<= /a>
    




-- 
-vince

____________= ___________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws<= /a>
_______________________________________________
paws mailing = list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws<= /a>



 
 
_______________________________________________
paws mailing =
list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws<= /a>

_______________________________________________
paws mailing = list
paws@ietf.org
https://www.ietf.org/= mailman/listinfo/paws

=  

------=_NextPart_000_00C7_01CD81E9.E0A7D170-- From ben@blindcreek.com Fri Aug 24 09:57:51 2012 Return-Path: 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 CAF0221F84FB for ; Fri, 24 Aug 2012 09:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, MIME_HTML_ONLY=1.457] 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 8gRBMcFp+7Xj for ; Fri, 24 Aug 2012 09:57:46 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id C17D421F8464 for ; Fri, 24 Aug 2012 09:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=CIiul0WiUf2Jo9OqWyXMnFTbkctb5DM2dgq1ISOwftw=; b=ZlRotj8FdNukYLg+PEdBPQChBpjp/MkqNfc3delLnyqWoZKd0nJrorpv7RghFrO4uoe84p6J8Gj70tG3LzB7ll/xLjhkG2b4Jwkv5ZgnRs0VANxa9EveqzaX40t31Fxd; Received: from [64.74.213.174] (port=56961 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1T4xCU-0004Pz-Tp for paws@ietf.org; Fri, 24 Aug 2012 11:57:40 -0500 Message-ID: <5037B28B.70501@blindcreek.com> Date: Fri, 24 Aug 2012 09:57:47 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: paws@ietf.org References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> <00c601cd820b$67b97170$372c5450$@us> In-Reply-To: <00c601cd820b$67b97170$372c5450$@us> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 16:57:52 -0000 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] On Behalf Of Basavaraj.Patil@nokia.com
Sent: Thursday, August 23, 2012 5:44 PM
To: Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com
Cc: 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" <Brian.Rosen@neustar.biz>
Date: Thursday, August 23, 2012 2:43 PM
To: Don Joslyn <d.joslyn@spectrumbridge.com>
Cc: "paws@ietf.org" <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> 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] On Behalf Of Benjamin A. Rolfe
Sent: Thursday, August 23, 2012 3:05 PM
To: 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] On Behalf Of Gabor.Bajko@nokia.com
Sent: Tuesday, August 21, 2012 12:42 AM
To: 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] On Behalf Of ext Das, Subir
Sent: Monday, August 20, 2012 2:50 PM
To: Don Joslyn; Vincent Chen; Weixinpeng
Cc: 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] On Behalf Of Don Joslyn
Sent: Monday, August 20, 2012 4:54 PM
To: Vincent Chen; Weixinpeng
Cc: 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] On Behalf Of Vincent Chen
Sent: Monday, August 20, 2012 2:56 PM
To: Weixinpeng
Cc: 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> 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] On Behalf Of Rosen, Brian


Sent: Friday, August 17, 2012 9:26 PM


Cc: 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>
Reply-To: Manikkoth Sajeev <mksaji@yahoo.com>
Date: Thu, 16 Aug 2012 22:37:38 -0400
To: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>, "Rosen, Brian" <brian.rosen@neustar.biz>, "vchen@google.com" <vchen@google.com>, "peter@spectrumbridge.com" <peter@spectrumbridge.com>
Cc: "paws@ietf.org" <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,

 

From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
To: Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com 
Cc: 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] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: '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]
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
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/) 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> 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> 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]
    >Sent:  Saturday, August 11, 2012 07:13 AM Eastern Standard Time
    >To:    Teco Boot; Benjamin A.Rolfe
    >Cc:    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> 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
    >>>>
    >>>> 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
    >>>>
    >>>> Teco
    >>>> _______________________________________________
    >>>> paws mailing list
    >>>> paws@ietf.org
    >>>> https://www.ietf.org/mailman/listinfo/paws
    >>>>
    >>>
    >>> _______________________________________________
    >>> paws mailing list
    >>> paws@ietf.org
    >>> https://www.ietf.org/mailman/listinfo/paws
    >>
    >>_______________________________________________
    >>paws mailing list
    >>paws@ietf.org
    >>https://www.ietf.org/mailman/listinfo/paws
    >
    >_______________________________________________
    >paws mailing list
    >paws@ietf.org
    >https://www.ietf.org/mailman/listinfo/paws
    
    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws
    




-- 
-vince

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws



 

-- 
-vince

 
 
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

 

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

 


_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

From brian.rosen@neustar.biz Fri Aug 24 10:09:46 2012 Return-Path: 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 1412D21F867D for ; Fri, 24 Aug 2012 10:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.053 X-Spam-Level: X-Spam-Status: No, score=-6.053 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 V6RyExkUud18 for ; Fri, 24 Aug 2012 10:09:42 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B26F721F861D for ; Fri, 24 Aug 2012 10:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1345828454; x=1661184862; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=6uWR5Um0q0vVSgchEv2Tk/TX51YrEkbbbg5jihOMmXc=; b=cwktkkr+A5+IdiAf48HNxRBabBAOwkfVOTWcOM2s5OULz293Yn5iwdwnm6pMQW C6W/NlIblMZucWZ6UWz/mqQQ== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.13467292; Fri, 24 Aug 2012 13:14:13 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 24 Aug 2012 13:09:34 -0400 From: "Rosen, Brian" To: "Benjamin A. Rolfe" Date: Fri, 24 Aug 2012 13:09:33 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac2CGzutzG66SIq+QlaLvASdgLUPFQ== Message-ID: <5D0B1E63-79FE-4BC6-A446-3470931D1043@neustar.biz> References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> <00c601cd820b$67b97170$372c5450$@us> <5037B28B.70501@blindcreek.com> In-Reply-To: <5037B28B.70501@blindcreek.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: xWRvk2hBvHQZaFqTdOOVEA== Content-Type: multipart/alternative; boundary="_000_5D0B1E6379FE4BC6A4463470931D1043neustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:09:46 -0000 --_000_5D0B1E6379FE4BC6A4463470931D1043neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There are two ways to achieve interoperability when you have an option. One is that one end implements both choices and the other end implements on= e 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 im= plement 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 implem= ent 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 wha= t to implement doesn't work for me (or Richard). Brian On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe > wrote: Apparently I was unclear. I certainly an capable of being wrong as I pract= ice often, but in this case it is quite unlikely :-). You do not need to choose only one form to achieve interoperability. If y= ou have two, let the device implementer figure out which is best for their = particular device requirements and trade-offs. This is *preferable* from m= y perspective. If you provide more than one form in the database, devices using the databa= se 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 thos= e 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 devic= es 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 f= orms available, it won't need to dynamically figure it out. The device impl= ementer has options and simplicity, so I like it. Since I am focused on the TVWS devices that need access to the database, an= d 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. :) This is why you have MUST and SHOULD in RFC 2119. This BTW is a classic argument in IETF terms .. but the argument =93let the= market decide=94 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 mandat= ory 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.= :) From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com Sent: Thursday, August 23, 2012 5:44 PM To: Brian.Rosen@neustar.biz; d.joslyn@spect= rumbridge.com Cc: 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 achie= ve interoperability. And this applies to the device and database side of the protocol. -Raj From: "", "Brian.Rosen@neustar.biz" > Date: Thursday, August 23, 2012 2:43 PM To: Don Joslyn > Cc: "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 impleme= ntations. On the other hand, the whole point of a protocol document like o= urs is that two independent implementations who both follow the document wi= ll 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 fig= ure it out using proprietary protocols. The market will decide. So, I feel strongly that if one end is "either", the other end must be "bot= h". It's also acceptable to say both ends implement one choice and the oth= er is optional at both ends. Here, I think it's server does both and clien= t does either. It's always possible to build an implementation of a server that only does = one: there are no protocol police. Brian On Aug 23, 2012, at 3:11 PM, Don Joslyn > 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-boun= ces@ietf.org] On Behalf Of Benjamin A. Rolfe Sent: Thursday, August 23, 2012 3:05 PM To: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal Someone suggested that PAWS define both, and let the vendors decide which o= nes to implement. That makes the most sense for both DB and device vendors. Markets will pro= bably drive DB vendors to do both. Device vendors will do what fits the mar= ket segment they're after. Why over-constrain (or argue when natural select= ion will take care of it for us?). B Sounds good to me. From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Tuesday, August 21, 2012 12:42 AM To: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal Now I can=92t see anymore any willingness to agree on one or the other enco= ding. To prevent endless discussions on this topic I=92d 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-boun= ces@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; 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 need= ed for XML From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Don Josly= n Sent: Monday, August 20, 2012 4:54 PM To: Vincent Chen; Weixinpeng Cc: paws@ietf.org; Manikkoth Sajeev Subject: Re: [paws] XML schema versus JSON, vCard & iCal Please see my comments below=85 Thanks, Don From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: Monday, August 20, 2012 2:56 PM To: Weixinpeng Cc: 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 dev= ice manufacturers. This lowers the barrier for building a robust ecosystem. [DJ - The =93cost=94 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 be= tter define =93cost=94?] * To reduce complexity and cost for device makers, supporting 1 encoding= is better than both, as Brian points out. WiFi access points that "just wo= rk" 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=92m forced to pick only one, then I will vote for X= ML because it=92s 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 (clie= nt-side) prefer it for its simplicity: * Representation closely matches most data models (nested lists and m= aps) * Simple-to-use libraries exist for all major languages/platforms * Don't need a tool chain to work with the data, as is typically need= ed for XML. Apparently, the efficiency gains of JSON also matter to the scalability of = serving systems. [DJ =96 I can=92t argue against these listed pros for JSON, especially when= you=92re dealing with a lot of data (like Twitter, FourSquare, Facebook an= d Google does). But I=92m assuming that PAWS messages will not be exchanged= nearly as often as the applications mentioned above. But again, I know JSO= N is more efficient, can=92t argue with that.] * At the end of the day, it's the data model that matters, rather than t= he 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 suppo= rting 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 device= s) 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 muc= h or exchanged that often.] On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > 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-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; gabor.bajko@nokia.com; = vchen@google.com; peter@spectrumbridge.com Cc: 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 desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml optioncan also work= . JSON I think will necessitate implementation to be native Java and may no= t be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_5D0B1E6379FE4BC6A4463470931D1043neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There are two ways to= achieve interoperability when you have an option.

One i= s that one end implements both choices and the other end implements one or = both.

The other is that both ends implement one sp= ecific choice ("MUST implement") and both can optionally implement the othe= r 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 imp= lement either
B) Both Databases and devices implement one (say XM= L) and optionally implement the other (say JSON)

Y= ou are advocating for A, Richard was suggesting B.

I don't care, but choice C) Both databases and devices have a choice of wh= at to implement doesn't work for me (or Richard).

= Brian

On Aug 24, 2012, at 12:57 PM, Benj= amin A. Rolfe <ben@blindcreek.com<= /a>> wrote:

=20
Apparently I was unclear.  I certainly an capable of being wrong a= s 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 implement= er 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), everythi= ng 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

=20

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 =93let the market decide=94 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.

<= p class=3D"MsoNormal"> 

End of argument you now can go back to your regularly schedule programming. J

 

 

From:<= /b> paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]= On Behalf Of Basavaraj.Patil@nokia.com
Sent: Thursday, August 23, 2012 5:44 PM
To: Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com
Cc: 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. <= o:p>

And this applies to the device and database side of the protocol.

 

-Raj

 

From: "<ext Rosen>", "Brian.Rosen@neustar.biz" <Brian.Rosen@neustar.biz>
Date: Thursday, August 23, 2012 2:43 PM
To: Don Joslyn <d.joslyn@spectrumbridge.com> Cc: "paws@ietf.org" <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 yo= u 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. <= /o:p>

 

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> wrote:



Hi Ben,

That was my original suggestion, and I still think it makes the most sense.

Thanks for supporting the proposal.<= o:p>

Don

 

From: <= a moz-do-not-send=3D"true" href=3D"mailto:paws-bounces@ietf.org">paws-bounc= es@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Benjamin A. Rolfe
Sent: Thursday, August 23, 2012 3:05 PM
To: p= aws@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<= /span> [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com=
Sent: Tuesday, August 21, 2012 12:42 AM
To: <= span style=3D"color: purple;">paws@ietf.org
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

 

Now I can=92t see anymore any willingness to agree on one or the other encoding.

To prevent endless discussions on this topic I=92d 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<= /span> [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: <= span style=3D"color: purple;">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.<= span style=3D"">

Also I will copy the following two important points:

 

    • Si= mple-to-use libraries exist for all major languages/platforms
    • Do= n't need a tool chain to work with the data, as is typically needed for XML

 

 

 

From: paws-bounces@ietf.org<= /span> [mailto:paws-bounces@ietf.org] On Behalf Of Don Joslyn
Sent: Monday, August 20, 2012 4:54 PM
To: Vincent Chen; Weixinpeng
Cc: <= span style=3D"color: purple;">paws@ietf.org; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

 

Please see my comments below=85

Thanks,

Don

 

From: 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; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal<= /p>

 

  • 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 =93cost=94 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 =93cost=94?]

  • 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=92m forced to pick only one, then I will vote for XML because it=92s 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:
    • Repr= esentation closely matches most data models (nested lists and maps)
    • Simp= le-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.<= /li>

Apparently, the efficiency gains o= f JSON also matter to the scalability of serving systems.<= /p>

 

[DJ =96 I can=92t argue against these listed pros for JSON, especially when you=92re dealing with a lot of data (like Twitter, FourSquare, Facebook and Google does). But I=92m 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=92t argue with that.]<= span style=3D"">

  • 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 type= s 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= > 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&nbs= p;[mailto:paws-bounces@ietf.= org] On Behalf Of Rosen, Brian


Sent: Friday, August 17, 2012 9:26 PM


Cc: paws@ietf.org
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

&n= bsp;

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.  I= f 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><= o:p>

 

From: Manikkoth Sajeev <mksaji@yahoo.com>
Reply-To: Manikkoth Sajeev <mksaji@yahoo.com>
Date: Thu, 16 Aug 2012 22:37:38 -0400
To: "Gabor.Bajko@= nokia.com" <Gabor.Bajko@nokia.com>, "Rosen, Brian" <brian.rosen@neustar.biz>, "vch= en@google.com" <= vchen@google.com>, "peter@spectrumbridge.com" <peter@spectrumbridge.com>
Cc: "paws@ietf.org= " <paw= s@ietf.org>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal=

 

H= i,

&= nbsp;

C= an 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.

&= nbsp;

Best Regards,

&= nbsp;

From: "Gabor.Bajko@nokia.com>
To: Brian.R= osen@neustar.biz; vchen@google.com; peter@spectrumbridge.com 
Cc: 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] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: '= 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.&nbs= p; 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]
Sent:    Monday, August = 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth Cc:    Rosen, Brian; Tec= o Boot; Benjamin A.Rolfe; paws@ietf.org<= /span>
Subject:    Re: [paws] X= ML 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/) 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> wrote:


    Whenever we built mo= bile devices we never dealt with IETF, in our sensor
    days even an IP stac= k 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> wrote:
    
    >Our experience i= n the IETF over many years is that economizing message
    >size and comprom= ising utility and security in search of efficiency of
    >implementation o= n small devices is a poor trade off.  I am not advocating
    >being wasteful o= f resources, but I don't think we should seriously
    >consider the ove= rhead of XML or json to be significant.
    >
    >Assuming a json = library can be loaded on a small device is reasonable.
    >
    >Brian (as indivi= dual)
    >
    >
    >
    > -----Original M= essage-----
    >From:  Pete= r Stanforth [mailto:peter@spectrumbridge.com]
    >Sent:  Satu= rday, August 11, 2012 07:13 AM Eastern Standard Time
    >To:   = Teco Boot; Benjamin A.Rolfe
    >Cc:   =  paws@ietf.org
    >Subject:  &= nbsp;   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 as= sume that all Masters are attached to utility power so we
    >should be sympat= hetic to processing energy use also.
    >
    >On SatAug/11/12 = Sat Aug 11, 5:30 AM, "Teco Boot" <teco@inf-net.nl> wrote:
    >
    >>
    >>Op 10 aug. 2= 012, om 18:10 heeft Benjamin A. Rolfe het volgende
    >>geschreven:<= br>     >>
    >>> Compact= ness 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"
    >>>applicat= ions.  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 abo= ut memory size in Kilo-bytes still).
    >>
    >>In use cases= and requirements document, there are no requirements for
    >>protocol per= formance. I guess OS/IP/TCP/TLS code size supersedes needs
    >>for JSON or = XML.
    >>
    >>Same for tim= ing: TCP/TLS connection setup will take more than the PAWS
    >>message exch= ange, 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 ef= ficiency.
    >>
    >>Teco
    >>
    >>> Thanks<= br>     >>> Ben
    >>>
    >>>
    >>>> We = had a discussion on XML vs. JSON. I prefer the one with most
    >>>>comp= act messages.
    >>>>
    >>>> On = vCard and JSON: what is the status of "A JavaScript Object Notation
    >>>>(JSO= N) Representation for vCard"?
    >>>> http://tools.ietf.org/html/draft-bhat= -vcarddav-json-00
    >>>>
    >>>> On = valid times: can we use same format as certificates? They have
    >>>>simi= lar simple requirements: valid notBefore& = ; notAfter.
    >>>> http://tools.ietf.org/html/rfc3280#sectio= n-4.1.2.5
    >>>>
    >>>> Tec= o
    >>>> _______________________________________= ________
    >>>> paw= s mailing list
    >>>> paws@ietf.org
    >>>> https://www.ietf.org/mailman/listinfo/paws=
    >>>>
    >>>
    >>> _______________________________________= ________
    >>> paws ma= iling list
    >>> = paws@ietf.org
    >>> https://www.ietf.org/mailman/listinfo/paws=
    >>
    >>_______________________________= ________________
    >>paws mailing= list
    >>paws@ietf.org
    >>https://www.ietf.org/mailman/lis= tinfo/paws
    >
    >___________________________________= ____________
    >paws mailing lis= t
    >paws@ietf.org
    >https://www.ietf.org/mailman/listinfo= /paws
    
    _______________________________________= ________
    paws mailing list     paws@ietf.org=
    https://www.ietf.org/mailman/listinfo/paws
    




-- 
-vince

_______________________________________________
paws mailing list
paws@ie= tf.org
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
paws@ie= tf.org
https://www.ietf.org/mailman/listinfo/paws



 =

-- 
-vince

 
 
_________________________________=
______________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws=

 

_____________________________= __________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws=

 


_______________________________________________
paws mailing list
paws@ie=
tf.org
https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mai= lman/listinfo/paws

= --_000_5D0B1E6379FE4BC6A4463470931D1043neustarbiz_-- From ben@blindcreek.com Fri Aug 24 10:38:51 2012 Return-Path: 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 514A821F8611 for ; Fri, 24 Aug 2012 10:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.147 X-Spam-Level: X-Spam-Status: No, score=-1.147 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, MIME_HTML_ONLY=1.457] 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 CQGV+cn42yny for ; Fri, 24 Aug 2012 10:38:49 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id AE07321F8608 for ; Fri, 24 Aug 2012 10:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=uDlSfMbIVlEKOtTrRiuP+B1itplbKNxly4fHohOj9h8=; b=Np5SSIu3q9Nos9YudgIPGS+wiBClJFOIKC52/cVy9286nnYIWQDJSP+1Mmrs01vH7p0db5dHo2BOvl6gA79jpIT5r4fYF7QsMiDjSYO4GJCzXEKoHUk740MbECtkBUQQ; Received: from [64.74.213.174] (port=52028 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1T4xqE-0002p4-Tn; Fri, 24 Aug 2012 12:38:45 -0500 Message-ID: <5037BC2B.7010008@blindcreek.com> Date: Fri, 24 Aug 2012 10:38:51 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Rosen, Brian" References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> <00c601cd820b$67b97170$372c5450$@us> <5037B28B.70501@blindcreek.com> <5D0B1E63-79FE-4BC6-A446-3470931D1043@neustar.biz> In-Reply-To: <5D0B1E63-79FE-4BC6-A446-3470931D1043@neustar.biz> Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Cc: "paws@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:38:51 -0000
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> 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] On Behalf Of Basavaraj.Patil@nokia.com
Sent: Thursday, August 23, 2012 5:44 PM
To: Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com
Cc: 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" <Brian.Rosen@neustar.biz>
Date: Thursday, August 23, 2012 2:43 PM
To: Don Joslyn <d.joslyn@spectrumbridge.com>
Cc: "paws@ietf.org" <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> 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] On Behalf Of Benjamin A. Rolfe
Sent: Thursday, August 23, 2012 3:05 PM
To: 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] On Behalf Of Gabor.Bajko@nokia.com
Sent: Tuesday, August 21, 2012 12:42 AM
To: 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] On Behalf Of ext Das, Subir
Sent: Monday, August 20, 2012 2:50 PM
To: Don Joslyn; Vincent Chen; Weixinpeng
Cc: 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] On Behalf Of Don Joslyn
Sent: Monday, August 20, 2012 4:54 PM
To: Vincent Chen; Weixinpeng
Cc: 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] On Behalf Of Vincent Chen
Sent: Monday, August 20, 2012 2:56 PM
To: Weixinpeng
Cc: 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> 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] On Behalf Of Rosen, Brian


Sent: Friday, August 17, 2012 9:26 PM


Cc: 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>
Reply-To: Manikkoth Sajeev <mksaji@yahoo.com>
Date: Thu, 16 Aug 2012 22:37:38 -0400
To: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>, "Rosen, Brian" <brian.rosen@neustar.biz>, "vchen@google.com" <vchen@google.com>, "peter@spectrumbridge.com" <peter@spectrumbridge.com>
Cc: "paws@ietf.org" <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,

 

From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
To: Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com 
Cc: 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] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: '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]
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
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/) 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> 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> 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]
    >Sent:  Saturday, August 11, 2012 07:13 AM Eastern Standard Time
    >To:    Teco Boot; Benjamin A.Rolfe
    >Cc:    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> 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
    >>>>
    >>>> 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
    >>>>
    >>>> Teco
    >>>> _______________________________________________
    >>>> paws mailing list
    >>>> paws@ietf.org
    >>>> https://www.ietf.org/mailman/listinfo/paws
    >>>>
    >>>
    >>> _______________________________________________
    >>> paws mailing list
    >>> paws@ietf.org
    >>> https://www.ietf.org/mailman/listinfo/paws
    >>
    >>_______________________________________________
    >>paws mailing list
    >>paws@ietf.org
    >>https://www.ietf.org/mailman/listinfo/paws
    >
    >_______________________________________________
    >paws mailing list
    >paws@ietf.org
    >https://www.ietf.org/mailman/listinfo/paws
    
    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws
    




-- 
-vince

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws



 

-- 
-vince

 
 
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

 

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

 


_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws


From brian.rosen@neustar.biz Fri Aug 24 10:43:15 2012 Return-Path: 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 DC67221F8646 for ; Fri, 24 Aug 2012 10:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.052 X-Spam-Level: X-Spam-Status: No, score=-6.052 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 v3KhlNjqWRgH for ; Fri, 24 Aug 2012 10:43:11 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id D430C21F861D for ; Fri, 24 Aug 2012 10:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1345830097; x=1661190032; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=FY9n2njwJm1qwH29bmfa1QBU/1ynVtaW8YUwynyGXK8=; b=LV2ZI+yT1Lxez0dk5fY5BlD70JwiCCsSKTtrRJccQC71HR6mDrS1uBisqWovkG 50Q6O7oF6NUcRJXihvN8AnDw== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.8577967; Fri, 24 Aug 2012 13:41:36 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 24 Aug 2012 13:42:53 -0400 From: "Rosen, Brian" To: "Benjamin A. Rolfe" Date: Fri, 24 Aug 2012 13:42:51 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac2CH+LOOhrYu/OtRGa4+utTc3YU+g== Message-ID: References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> <00c601cd820b$67b97170$372c5450$@us> <5037B28B.70501@blindcreek.com> <5D0B1E63-79FE-4BC6-A446-3470931D1043@neustar.biz> <5037BC2B.7010008@blindcreek.com> In-Reply-To: <5037BC2B.7010008@blindcreek.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: 2UKURYjAFm0Onw+Qkx7jUg== Content-Type: multipart/alternative; boundary="_000_A8F0F6EB75BB4FAB866F04D593FAA4C0neustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:43:15 -0000 --_000_A8F0F6EB75BB4FAB866F04D593FAA4C0neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 dec= iding 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" > 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 informa= tion about what options each supports, without requiring that any device im= plement 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 on= e 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 im= plement 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 implem= ent 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 wha= t to implement doesn't work for me (or Richard). Brian On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe > wrote: Apparently I was unclear. I certainly an capable of being wrong as I pract= ice often, but in this case it is quite unlikely :-). You do not need to choose only one form to achieve interoperability. If y= ou have two, let the device implementer figure out which is best for their = particular device requirements and trade-offs. This is *preferable* from m= y perspective. If you provide more than one form in the database, devices using the databa= se 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 thos= e 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 devic= es 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 f= orms available, it won't need to dynamically figure it out. The device impl= ementer has options and simplicity, so I like it. Since I am focused on the TVWS devices that need access to the database, an= d 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. :) This is why you have MUST and SHOULD in RFC 2119. This BTW is a classic argument in IETF terms .. but the argument =93let the= market decide=94 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 mandat= ory 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.= :) From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com Sent: Thursday, August 23, 2012 5:44 PM To: Brian.Rosen@neustar.biz; d.joslyn@spect= rumbridge.com Cc: 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 achie= ve interoperability. And this applies to the device and database side of the protocol. -Raj From: "", "Brian.Rosen@neustar.biz" > Date: Thursday, August 23, 2012 2:43 PM To: Don Joslyn > Cc: "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 impleme= ntations. On the other hand, the whole point of a protocol document like o= urs is that two independent implementations who both follow the document wi= ll 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 fig= ure it out using proprietary protocols. The market will decide. So, I feel strongly that if one end is "either", the other end must be "bot= h". It's also acceptable to say both ends implement one choice and the oth= er is optional at both ends. Here, I think it's server does both and clien= t does either. It's always possible to build an implementation of a server that only does = one: there are no protocol police. Brian On Aug 23, 2012, at 3:11 PM, Don Joslyn > 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-boun= ces@ietf.org] On Behalf Of Benjamin A. Rolfe Sent: Thursday, August 23, 2012 3:05 PM To: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal Someone suggested that PAWS define both, and let the vendors decide which o= nes to implement. That makes the most sense for both DB and device vendors. Markets will pro= bably drive DB vendors to do both. Device vendors will do what fits the mar= ket segment they're after. Why over-constrain (or argue when natural select= ion will take care of it for us?). B Sounds good to me. From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Tuesday, August 21, 2012 12:42 AM To: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal Now I can=92t see anymore any willingness to agree on one or the other enco= ding. To prevent endless discussions on this topic I=92d 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-boun= ces@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; 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 need= ed for XML From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Don Josly= n Sent: Monday, August 20, 2012 4:54 PM To: Vincent Chen; Weixinpeng Cc: paws@ietf.org; Manikkoth Sajeev Subject: Re: [paws] XML schema versus JSON, vCard & iCal Please see my comments below=85 Thanks, Don From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: Monday, August 20, 2012 2:56 PM To: Weixinpeng Cc: 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 dev= ice manufacturers. This lowers the barrier for building a robust ecosystem. [DJ - The =93cost=94 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 be= tter define =93cost=94?] * To reduce complexity and cost for device makers, supporting 1 encoding= is better than both, as Brian points out. WiFi access points that "just wo= rk" 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=92m forced to pick only one, then I will vote for X= ML because it=92s 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 (clie= nt-side) prefer it for its simplicity: * Representation closely matches most data models (nested lists and m= aps) * Simple-to-use libraries exist for all major languages/platforms * Don't need a tool chain to work with the data, as is typically need= ed for XML. Apparently, the efficiency gains of JSON also matter to the scalability of = serving systems. [DJ =96 I can=92t argue against these listed pros for JSON, especially when= you=92re dealing with a lot of data (like Twitter, FourSquare, Facebook an= d Google does). But I=92m assuming that PAWS messages will not be exchanged= nearly as often as the applications mentioned above. But again, I know JSO= N is more efficient, can=92t argue with that.] * At the end of the day, it's the data model that matters, rather than t= he 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 suppo= rting 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 device= s) 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 muc= h or exchanged that often.] On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > 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-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; gabor.bajko@nokia.com; = vchen@google.com; peter@spectrumbridge.com Cc: 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 desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml optioncan also work= . JSON I think will necessitate implementation to be native Java and may no= t be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_A8F0F6EB75BB4FAB866F04D593FAA4C0neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Okay:

<= div>So, I implement a database, and I implement XML
You implement= a device, and you implement JSON

You query my dat= abase (let's not get into how you do that query without deciding XML vs JSO= N) and discover I implement XML only

What do you d= o?

Brian

On Aug= 24, 2012, at 1:38 PM, "Benjamin A. Rolfe" <ben@blindcreek.com> wrote:

=20 =20

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 th= at 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> 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 =93let the market decide=94 only holds so much validity.  You actu= ally 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. <= span style=3D"font-size: 11pt; font-family: Wingdings; color: rgb(31, 73, 125);">J

 
 

Fro= m: paws-bounces@ietf.org [mailto:paws-bounces@ietf.= org] On Behalf Of Basavaraj.Patil@nokia.com
Sent: Thursday, August 23, 2012 5:44 PM To: Brian.Rose= n@neustar.biz; d.joslyn@spectrum= bridge.com
Cc: 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" <Brian.Rosen@neustar.biz>
Date: Thursday, August 23, 2012 2:43 PM
To: Don Joslyn <d.joslyn@spectrumbridge.com<= /a>>
Cc: "paws@ietf.org" <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 who= le 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>

 =
 =
 =
&nbs= p;

On Aug 23, 2012, at 3:11 PM, Don Joslyn <d.joslyn@spectrum= bridge.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] On Behalf Of Benjamin A. Rolfe
Sent: Thursday, August 23, 2012 3:05 PM
To: 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 wi= ll 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.<= /span>

 

From:<= /b> = paws-bounces@ietf.org [mailto:paws-bounces@ietf= .org] On Behalf Of Gabor.Bajko@nokia.com<= /span>
Sent: Tuesday, August 21, 2012 12:42 AM
To: paws@ietf.org
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

=  

Now I can=92t see anymore any willingness to agree on one or the other encoding.

To prevent endless discussions on this topic I=92d suggest we move forward with supporting both in the DB and either one in the master device.

Any objections?

 

Gabor

 

 

From:<= /b> = 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; 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:<= /b> = paws-bounces@ietf.org [mailto:paws-bou= nces@ietf.org] On Behalf Of Don Joslyn
Sent: Monday, August 20, 2012 4:54 PM
To: Vincent Chen; Weixinpeng
Cc: paws@ietf.org; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

=  

Please see my comments below=85

Thanks,

Don

 

Fr= om:&n= bsp;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; 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 =93cost=94 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 =93cost=94?]

  • 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=92m forced to pick only one, then I will vote for XML because it=92s the one that we currently use on all embedded devices.]<= /o:p>

  • 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 =96 I can=92t argue against these listed pros for JSON, especially when you=92re dealing with a lot of data (like Twitter, FourSquare, Facebook and Google does). But I=92m 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=92t 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> wrote:

Conside= ring 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.

 <= /span>

--Xinpe= ng Wei<= /o:p>

 <= /span>

From: <= /span>= paws-bounces@ietf.org [mailto:paws-bounces@iet= f.org] On B= ehalf Of Rosen, Brian=


Sent: Friday, August 17, 2012 9:26 PM


Cc: 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 becaus= e it is smaller, then I believe you need a much better reason.  Binary doesn't work for me, at all.  I have been involv= ed in big binary vs text wars in protocol design.  Tex= t wins, binary loses, in my opinion.

 

Brian <as individual><= span style=3D"">

 

From:<= span class=3D"apple-converted-space"> Manikkot= h Sajeev <mksaji@yahoo.com>
Reply-To: Manikkoth Sajeev <mksaji@yahoo.com>
Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Ga= bor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>, "Rosen, Brian" <brian.rosen@neustar.biz>, "vchen@google.com= " <vchen@google.com>, "peter@spectrumbridge.com" <peter@spectrumbridge.com>
Cc: "paws@ietf.= org" <paws@ietf.org>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal=

 

Hi,<= o:p>

&nbs= p;

Can it not be both JSON and XML supported? I would vote for that. Future implementations may prefer XML as it is generic, om= ni present, easy to understand and validate. For compactness may be a <= span class=3D"apple-converted-space"> 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.

&nbs= p;

Best Regards,

&nbs= p;

From= :&nbs= p;"Gabor.Bajko@= nokia.com" <Gabor.Bajko@= nokia.com>
To: Brian.Rosen@= neustar.biz; <= a moz-do-not-send=3D"true" href=3D"mailto:vchen@google.com" target=3D"_blan= k">vchen@google= .com; peter@spectr= umbridge.com <= br> Cc: paws@ietf.or= g 
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-bou= nces@ietf.org = [mailto:paws-bounces@iet= f.org] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: '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 who= le lot about that

Brian <as individual>



-----Original Message----- From:     Vinc= ent Chen [mailto:vchen@google.com]
Sent:    Monda= y, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter S= tanforth
Cc:    Rosen, = Brian; Teco Boot; Benjamin A.Rolfe;  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> wrote:


    Whenever w= e 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 on= e.
    
    On MonAug/= 13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"
    
    <Brian.Rosen@neustar.biz> wrote:
    
    >Our ex= perience in the IETF over many years is that economizing message
    >size a= nd compromising utility and security in search of efficiency of
    >implem= entation on small devices is a poor trade off.  I am not advocating
    >being = wasteful of resources, but I don't think we should seriously
    >consid= er the overhead of XML or json to be significant.
    >
    >Assumi= ng a json library can be loaded on a small device is reasonable.
    >
    >Brian = (as individual)
    >
    >
    >
    > -----= Original Message-----
    >From:&= nbsp; Peter Stanforth [mailto:peter@spectrumbridge.com]
    >Sent:&= nbsp; Saturday, August 11, 2012 07:13 AM Eastern Standard Time
    >To:&nb= sp;   Teco Boot; Benjamin A.Rolfe
    >Cc:&nb= sp;   paws@ietf.org
    >Subjec= t:      Re: [paws] XML schema versus JSON, vCard & iCal
    >
    >Not al= l masters run over the core network.     >Some o= f the Use cases have a master talking to another OTA
    >We sho= uld not assume that all Masters are attached to utility power so we
    >should= be sympathetic to processing energy use also.
    >
    >On Sat= Aug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <teco@inf-net.nl> wrote:
    >
    >>     >>Op= 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe het volgende
    >>ge= schreven:
    >>     >>&g= t; Compactness of messages is important, but it is also important (to me
    >>&g= t;at least) to be realizable in an implementation with limited resources,
    >>&g= t;such as embedded devices in what are now popularly called "M2M"
    >>>applications.&nbs= p; A lot of these devices could use IP all the end to end,
    >>&g= t;but may have a very compact, simple stack and applications (i.e.  no     >>&g= t;browser).  Is JSON typically implemented when there is no browser?
    >>&g= t;Would it be hard to do in a resource constrained device (i.e. where we
    >>&g= t;talk about memory size in Kilo-bytes still).
    >>     >>In= use cases and requirements document, there are no requirements for
    >>pr= otocol performance. I guess OS/IP/TCP/TLS code size supersedes needs
    >>fo= r JSON or XML.
    >>     >>Sa= me for timing: TCP/TLS connection setup will take more than the PAWS
    >>me= ssage exchange, I think. This may be of importance when using satcom
    >>li= nks.
    >>     >>Be= cause PAWS runs between master and database, over core network,
    >>pe= rformance is not our primary concern. But as always, it is good to keep
    >>an= eye on efficiency.
    >>     >>Te= co
    >>     >>&g= t; Thanks
    >>&g= t; Ben
    >>&g= t;
    >>&g= t;
    >>&g= t;> We had a discussion on XML vs. JSON. I prefer the one with most
    >>>>compact messages.
    >>&g= t;>
    >>&g= t;> On vCard and JSON: what is the status of "A JavaScript Object Notation     >>&g= t;>(JSON) Representation for vCard"?     >>&g= t;> http://tools.ietf.org/html/= draft-bhat-vcarddav-json-00
    >>&g= t;>
    >>&g= t;> On valid times: can we use same format as certificates? They have
    >>>>similar simple requirements: valid notBefore&  notAfter= .
    >>&g= t;> http://tools.ietf.org/html/rfc3= 280#section-4.1.2.5
    >>&g= t;>
    >>&g= t;> Teco
    >>&g= t;> _____________________________= __________________
    >>&g= t;> paws mailing list
    >>&g= t;> paws@ietf.org
    >>&g= t;> https://www.ietf.org/mailman/listinfo/p= aws
    >>&g= t;>
    >>&g= t;
    >>&g= t; _____________________________= __________________
    >>&g= t; paws mailing list
    >>&g= t; paws@ietf.org
    >>&g= t; https://www.ietf.org/mailman/listinfo/paws<= /span>
    >>     >>_____________________= __________________________
    >>pa= ws mailing list
    >><= span style=3D"color: purple;">paws@ietf.org
    >>https://www.ietf.org/ma= ilman/listinfo/paws
    >
    >_________________________= ______________________
    >paws m= ailing list
    >paws@ietf.org
    >https://www.ietf.org/mailma= n/listinfo/paws
    
    _____________________________= __________________
    paws maili= ng list
    paw= s@ietf.org
    https://www.ietf.org/mailman/listinfo/paws     




-- 
-vince

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws<= /a>
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws<= /a>



 

-- 
-vince

 
 
_______________________=
________________________
paws mailing list<=
/o:p>
paws@ietf=
.org
https://www.ietf.org/mailman/listinfo/paws

=  

__________________= _____________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinf= o/paws

&nbs= p;

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/=
paws

_______________________________________________
paws mailing list
paws@= ietf.org
https://www.ietf.org/mailman/listinfo/paws



= --_000_A8F0F6EB75BB4FAB866F04D593FAA4C0neustarbiz_-- From Gabor.Bajko@nokia.com Fri Aug 24 12:09:15 2012 Return-Path: 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 4EEA421F8523 for ; Fri, 24 Aug 2012 12:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 Kne8tsh9qflm for ; Fri, 24 Aug 2012 12:09:03 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3765421F851E for ; Fri, 24 Aug 2012 12:09:02 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7OJ8Xbm018622; Fri, 24 Aug 2012 22:08:34 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Aug 2012 22:08:32 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0283.004; Fri, 24 Aug 2012 21:08:32 +0200 From: To: , Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Ie7Nd2WNzPm0+85/tpR52R7QAAU/5DAJlUv6AAAo7YAAAWoncAABh1noAAifZJAAAEHtqAAAHwqAAAEnPn8ACBGaEA///sjQCAAAG0gIAACReAgAAhcYCAASYgAIAAHGCAgAADSYCAAAgwgIAAAR6A///OdSA= Date: Fri, 24 Aug 2012 19:08:31 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724@008-AM1MPN1-006.mgdnok.nokia.com> References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> <00c601cd820b$67b97170$372c5450$@us> <5037B28B.70501@blindcreek.com> <5D0B1E63-79FE-4BC6-A446-3470931D1043@neustar.biz> <5037BC2B.7010008@blindcreek.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.243.187.52] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 24 Aug 2012 19:08:32.0989 (UTC) FILETIME=[DAD020D0:01CD822B] X-Nokia-AV: Clean Cc: paws@ietf.org 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 19:09:15 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 su= pported 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 optio= ns, 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 sho= rt, with the only caveat that if there is no strong technical argument for = supporting and specifying two different encodings, then the iesg may send t= he document back to the wg to pick one of the two specified. As Robert ment= ioned 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 en= coding, being that either xml or json? Most people speak in favor of JSON, because it is compact and more efficien= t. 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 objectio= n gave no real reason. So I am wondering if there is really any valid techn= ical reason against using JSON only? - Gabor From: 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 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 dec= iding 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" > 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 informa= tion about what options each supports, without requiring that any device im= plement 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 on= e 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 im= plement 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 implem= ent 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 wha= t to implement doesn't work for me (or Richard). Brian On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe > wrote: Apparently I was unclear. I certainly an capable of being wrong as I pract= ice often, but in this case it is quite unlikely :-). You do not need to choose only one form to achieve interoperability. If y= ou have two, let the device implementer figure out which is best for their = particular device requirements and trade-offs. This is *preferable* from m= y perspective. If you provide more than one form in the database, devices using the databa= se 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 thos= e 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 devic= es 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 f= orms available, it won't need to dynamically figure it out. The device impl= ementer has options and simplicity, so I like it. Since I am focused on the TVWS devices that need access to the database, an= d 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. :) 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 m= arket decide" only holds so much validity. You actually have to choose SOM= ETHING to create a baseline of interoperability. A virtually identical argument is now playing out in discussions of mandat= ory 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.= :) From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com Sent: Thursday, August 23, 2012 5:44 PM To: Brian.Rosen@neustar.biz; d.joslyn@spect= rumbridge.com Cc: 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 achie= ve interoperability. And this applies to the device and database side of the protocol. -Raj From: "", "Brian.Rosen@neustar.biz" > Date: Thursday, August 23, 2012 2:43 PM To: Don Joslyn > Cc: "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 impleme= ntations. On the other hand, the whole point of a protocol document like o= urs is that two independent implementations who both follow the document wi= ll 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 fig= ure it out using proprietary protocols. The market will decide. So, I feel strongly that if one end is "either", the other end must be "bot= h". It's also acceptable to say both ends implement one choice and the oth= er is optional at both ends. Here, I think it's server does both and clien= t does either. It's always possible to build an implementation of a server that only does = one: there are no protocol police. Brian On Aug 23, 2012, at 3:11 PM, Don Joslyn > 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-boun= ces@ietf.org] On Behalf Of Benjamin A. Rolfe Sent: Thursday, August 23, 2012 3:05 PM To: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal Someone suggested that PAWS define both, and let the vendors decide which o= nes to implement. That makes the most sense for both DB and device vendors. Markets will pro= bably drive DB vendors to do both. Device vendors will do what fits the mar= ket segment they're after. Why over-constrain (or argue when natural select= ion will take care of it for us?). B Sounds good to me. From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Tuesday, August 21, 2012 12:42 AM To: 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 encodi= ng. To prevent endless discussions on this topic I'd suggest we move forward wi= th supporting both in the DB and either one in the master device. Any objections? Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@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; 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 nee= ded for XML From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Don Josly= n Sent: Monday, August 20, 2012 4:54 PM To: Vincent Chen; Weixinpeng Cc: 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-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: Monday, August 20, 2012 2:56 PM To: Weixinpeng Cc: 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 de= vice 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 encodin= g is better than both, as Brian points out. WiFi access points that "just w= ork" 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 (cli= ent-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 nee= ded 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 Goog= le 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 mor= e 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 w= e're clear on what device makers want. It would be good to get feedback fro= m device makers (especially of embedded devices) regarding experiences supp= orting 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 device= s) 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 muc= h or exchanged that often.] On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > 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-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; gabor.bajko@nokia.com; = vchen@google.com; peter@spectrumbridge.com Cc: 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 desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml optioncan also work= . JSON I think will necessitate implementation to be native Java and may no= t be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WiFi world builds on mand= ating the implementation (and certification) of a base spec, and a set of o= ptional features. If an optional feature is not supported by one of the peers, they can still talk, but not use that feature. That i= s basically option B) from Brain’s list.

 <= /p>

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 ad= d the obvious option D) to the list, which is that both the master devices = and DBs support one and the same encoding ;)

 <= /p>

Option A) seems to be lik= e 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 documen= t back to the wg to pick one of the two specified. As Robert mentioned in h= is email, this has happened in the past, so it is likely it would happen ag= ain. And frankly, I do not see a strong argument in favor of two different encodings.

 <= /p>

Is there anyone who has a= technical argument against supporting only one encoding, being that either= xml or json?

 <= /p>

Most people speak in favo= r of JSON, because it is compact and more efficient. I went through this th= read and I saw 2 objections against picking JSON. One said that JSON requires native Java, which is wrong, the other objection gave n= o real reason. So I am wondering if there is really any valid technical rea= son against using JSON only?

 <= /p>

- =          Gabor<= /span>

 <= /p>

 <= /p>

From: paws-bou= nces@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
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<= /o:p>

 

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>= wrote:





There are two ways to achieve interoperability when = you have an option.

There are many existence proofs of the third way tha= t I mentioned below.
802.11 + WiFi provide many options and a means for devices to share inf= ormation about what options each supports, without requiring that any devic= e 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 c= hoice ("MUST implement") and both can optionally implement the ot= her choice.  Only if both ends implement the other choice would that b= e available.

 

So, in this case we could do one of the following:

A) Databases implement both XML and JSON, devices im= plement 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.<= o:p>

 

I don't care, but choice C) Both databases and devic= es 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> wrote:



Apparently I was unclear.  I certainly an capab= le of being wrong as I practice often, but in this case it is quite unlikel= y :-).

You do not need to choose only one form to achieve interoperability. &= nbsp; If you have two, let the device implementer figure out which is best = for their particular device requirements and trade-offs.  This is *pre= ferable* from my perspective.

If you provide more than one form in the database, devices using the databa= se 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 dis= cover what options the database supports.  If you have such a mechanis= m 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 d= evice implementer has options and simplicity, so I like it.

Since I am focused on the TVWS devices that need access to the database, an= d 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 th= ere 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 b= ut the rest of you are wrong. J

 <= /p>

This is why you have MUST= and SHOULD in RFC 2119.  

 <= /p>

This BTW is a classic arg= ument 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.

 <= /p>

A virtually identical arg= ument  is now playing out in discussions of mandatory audio and codec = implementations for WEBRTC like things.

 <= /p>

IMHO XML MUST anything el= se defined SHOULD, but MUST on XML and JSON could work as well. It just lea= ds to a level of complexity in implementations.

 <= /p>

End of argument you now c= an go back to your regularly schedule programming. J

 <= /p>

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Basavaraj.= Patil@nokia.com
Sent: Thursday, August 23, 2012 5:44 PM
To: Brian.Rosen@neustar.b= iz; d.joslyn@spectrumbridge.com
Cc: paws@ietf.org
Subject: Re: [paws] XML schema versus JSON, vCard & iCal<= o:p>

 

 

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 datab= ase side of the protocol.

 

-Raj

 

From: "<ext Rosen>", "Brian.Rosen@neustar.biz" <Brian.Rosen@neustar.biz>
Date: Thursday, August 23, 2012 2:43 PM
To: Don Joslyn <d.= joslyn@spectrumbridge.com>
Cc: "paws@ietf.org" &= lt;paws@ietf.org>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal<= o:p>

 

One of my favorite IETF expressions is &= quot;There are no protocol police".  We apply that in lots of way= s, 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 in= dependent implementations who both follow the document will interwork. &nbs= p;If that wasn't true, why do you need a standard?

 

If you say "either" to both en= ds, 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 &= quot;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.&nb= sp;

 

It's always possible to build an impleme= ntation of a server that only does one: there are no protocol police.

 

Brian <as individual><= /o:p>

 

 

 

 

On Aug 23, 2012, at 3:11 PM, Don Joslyn = <d.joslyn@spectrumbridge.= com> wrote:




Hi Ben,=

That was my original sugg= estion, and I still think it makes the most sense.

Thanks for supporting the= proposal.

Don

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Benj= amin A. Rolfe
Sent: Thursday, Au= gust 23, 2012 3:05 PM
To: 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 wil= l probably drive DB vendors to do both. Device vendors will do what fits th= e market segment they're after. Why over-constrain (or argue when natural s= election will take care of it for us?).
B



Sounds good to me.

 

From: paws-bounces@ietf.o= rg [mailto:paws-bou= nces@ietf.org] On Behalf Of Gabor.Bajko@nok= ia.com
Sent: Tuesday, Aug= ust 21, 2012 12:42 AM
To: paws@ietf.org Subject: Re: [paws= ] XML schema versus JSON, vCard & iCal

 

Now I can’t see anymore any willi= ngness 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.o= rg [mailto:paws-bou= nces@ietf.org] On Behalf Of ext Das, S= ubir
Sent: Monday, Augu= st 20, 2012 2:50 PM
To: Don Joslyn; Vi= ncent Chen; Weixinpeng
Cc: paws@ietf.org; M= anikkoth Sajeev
Subject: Re: [paws= ] XML schema versus JSON, vCard & iCal

 

We have a half a dozen or more TVDB rad= io vendors that use/prefer JSON and we will vote for JSON if we had to pick= one.

Also I will copy the following two impo= rtant points:

 

    • Simple-to-use libraries exist for all major languages/platforms
    • Don't need a tool chain to work with the dat= a, as is typically needed for XML

 

 

 

From: paws-bounces@ietf.o= rg [mailto= :paws-bounces@ietf.org]&nb= sp;On Behalf Of Don Joslyn=
Sent: Monday, Augu= st 20, 2012 4:54 PM
To: Vincent Chen; = Weixinpeng
Cc: paws@ietf.org; M= anikkoth Sajeev
Subject: Re: [paws= ] XML schema versus JSON, vCard & iCal

 

Please see my comments below…

Thanks,

Don

 

From: paws-bounces@ietf.o= rg [mailto:paws-bou= nces@ietf.org] On Behalf Of Vincent Ch= en
Sent: Monday, Augu= st 20, 2012 2:56 PM
To: Weixinpeng
Cc: paws@ietf.org; M= anikkoth Sajeev
Subject: Re: [paws= ] XML schema versus JSON, vCard & iCal

 

  • One of our goals is to strive to lower the cost and compl= exity for device manufacturers. This lowers the barrier for building a robust ecosystem.

[DJ - The “cost&= #8221; 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 &#= 8220;cost”?]

  • To reduce complexity and cost for device makers, supporti= ng 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 t= o 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 l= ists and maps)
    • Simple-to-use librar= ies exist for all major languages/platforms
    • Don't need a tool chain to work with the data, as is typically nee= ded for XML.

Apparently, the efficiency gains of JSON also matter to the scal= ability of serving systems.

 = ;

[DJ – I can̵= 7;t argue against these listed pros for JSON, especially when you’re = dealing with a lot of data (like Twitter, FourSquare, Facebook and Google d= oes). 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 woul= d be good to get feedback from device makers (especially of embedded device= s) regarding experiences supporting XML vs JSON.

    •  

    Don, can you elaborate on the types of devices that already supp= ort XML?

     <= /o:p>

    [DJ - We currently support half a dozen TVDB radio vendors (embedd= ed devices) using XML, non using JSON. XML has not been a burden, and the a= mount 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> 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.

     <= /p>

    --Xinpeng Wei=

     <= /p>

    From: p= aws-bounces@ietf.org = [mailto:<= span style=3D"color:purple">paws-bounces@ietf.org] On Behalf Of Rosen, Bri= an


    Sent: Friday, Augu= st 17, 2012 9:26 PM


    Cc: 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 fa= n 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 rep= resentation 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&q= uot;, because of interoperability complications.  If there is rough co= nsensus 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 t= hink that is a big deal.  

     

    My experience in protocol design on the= Internet is that decisions made solely or even largely because of compactn= ess 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 bina= ry vs text wars in protocol design.  Text wins, binary loses, in my op= inion.

     

    Brian <as individual>=

     

    From: Manikkoth Sajeev <mk= saji@yahoo.com>
    Reply-To: Manikkot= h Sajeev <mksaji@yahoo.com>
    Date: Thu, 16 Aug = 2012 22:37:38 -0400
    To: "Gabor.Bajko@nokia.com" <Gabor.Bajko@n= okia.com>, "Rosen, Brian" <brian.rosen@neustar.biz= >, "vchen@google.com    " <vchen= @google.com>, "peter@spectrumbridge.com" <peter@spectrumbridge.com>
    Cc: "pa= ws@ietf.org" <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 im= plementations may prefer = XML as it is generic, omni present, easy to understand and val= idate. For compactness may be a  binary xml optioncan also work. JSON I think will neces= sitate implementation to be native Java and may not be as friendly with oth= er implementation languages.

     

    Best Regards,

     

    From: "Gabor.Bajko@nokia.com= " <Gabor.Bajko@nokia.com>
    To: Brian.Rosen@neustar.biz;&= nbsp;vchen@google.com; peter@spectrumbridge.com 
    Cc:     paws@ietf= .org 
    Sent: Friday, 17 A= ugust 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-b= ounces@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'
    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.&nbs= p; It's very easy to parse, and its simpler to use and debug.  Don't c= are a whole lot about that

    Brian <as individual>



    -----Original Message-----
    From:     Vincent Chen [mailto:vchen@google.com]
    Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard T= ime
    To:    Peter Stanforth
    Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
    Subject:    Re: [paws] XML schema versus JSON, vCard & i= Cal

    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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries exist for numerous languages (see= of http://json.org/) and seem to be reasonably light weight.

    Timestamps

    As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries 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> wrote:


        Whenever we built mobile devices we never dealt with IET= F, in our sensor
        days even an IP stack was a challenge,so I would defer t= o the device guys
        on that one.
        
        On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian&= quot;
        
        <Brian.Rosen@neustar.biz>= ; wrote:
        
        >Our experience in the IETF over many years is that e= conomizing 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 sh= ould seriously
        >consider the overhead of XML or json to be significa= nt.
        >
        >Assuming a json library can be loaded on a small dev= ice is reasonable.
        >
        >Brian (as individual)
        >
        >
        >
        > -----Original Message-----
        >From:  Peter Stanforth [mailto:= peter@spectrumbridge.com]
        >Sent:  Saturday, August 11, 2012 07:13 AM Easte= rn Standard Time
        >To:    Teco Boot; Benjamin A.Rolfe
        >Cc:    paws@ietf.org
        >Subject:      Re: [paws] XML schema v= ersus JSON, vCard & iCal
        >
        >Not all masters run over the core network.
        >Some of the Use cases have a master talking to anoth= er OTA
        >We should not assume that all Masters are attached t= o 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> wrote:
        >
        >>
        >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolf= e het volgende
        >>geschreven:
        >>
        >>> Compactness of messages is important, but i= t is also important (to me
        >>>at least) to be realizable in an implementat= ion with limited resources,
        >>>such as embedded devices in what are now pop= ularly called "M2M"
        >>>applications.  A lot of these devices c= ould use IP all the end to end,
        >>>but may have a very compact, simple stack an= d applications (i.e.  no
        >>>browser).  Is JSON typically implemente= d when there is no browser?
        >>>Would it be hard to do in a resource constra= ined device (i.e. where we
        >>>talk about memory size in Kilo-bytes still).=
        >>
        >>In use cases and requirements document, there ar= e 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 t= ake more than the PAWS
        >>message exchange, I think. This may be of import= ance when using satcom
        >>links.
        >>
        >>Because PAWS runs between master and database, o= ver core network,
        >>performance is not our primary concern. But as a= lways, 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 o= f "A JavaScript Object Notation
        >>>>(JSON) Representation for vCard"?     >>>>&n= bsp;http://tools.ietf.org/htm= l/draft-bhat-vcarddav-json-00
        >>>>
        >>>> On valid times: can we use same format = as certificates? They have
        >>>>similar simple requirements: valid notBe= fore&  notAfter.
        >>>>&n= bsp;http://tools.ietf.org/html/rf= c3280#section-4.1.2.5
        >>>>
        >>>> Teco
        >>>> _______________________________________= ________
        >>>> paws mailing list
        >>>>&n= bsp;paws@ietf.org
        >>>>&n= bsp;https://www.ietf.org/mailman/listinfo= /paws
        >>>>
        >>>
        >>> ___________________________________________= ____
        >>> paws mailing list
        >>> = paws@ietf.org
        >>> = https://www.ietf.org/mailman/listinfo/paw= s
        >>
        >>_______________________________________________<= br>     >>paws mailing list
        >>paws@ietf.org
        >>https://www.ietf.org/= mailman/listinfo/paws
        >
        >_______________________________________________
        >paws mailing list
        ><= span style=3D"color:purple">paws@ietf.org
        >https://www.ietf.org/mail= man/listinfo/paws
        
        _______________________________________________
        paws mailing list
        p= aws@ietf.org
        https://www.ietf.org/mailman/listinfo/paws<= br>     




    -- 
    -vince

    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws
    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws



     

    -- 
    -vince

     
     
    _______________________________________________
    paws mailing list
    paws@iet=
f.org
    https://www.ietf.org/mailman/listinfo/paws

     

    _____________________________________= __________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org= /mailman/listinfo/paws

 

 
_______________________________________________
paws mailing list
paws@ietf.org
https://www.iet=
f.org/mailman/listinfo/paws

 

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org= /mailman/listinfo/paws

 

 

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724008AM1MPN1006mg_-- From brian.rosen@neustar.biz Fri Aug 24 12:48:36 2012 Return-Path: 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 4CDBB21F85B4 for ; Fri, 24 Aug 2012 12:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.05 X-Spam-Level: X-Spam-Status: No, score=-6.05 tagged_above=-999 required=5 tests=[AWL=-0.052, 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 EQ7j1RO2M7+S for ; Fri, 24 Aug 2012 12:48:32 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC9A21F85A8 for ; Fri, 24 Aug 2012 12:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1345837474; x=1661197307; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=EYGWlxgqobIhRNtWDCZDO6BAQjs/sdbb0/qVs+q93qo=; b=Dmc056DcPlkzp0902jVuG1CXfd6iGUMWOLrl8w+Ih2IZoQ53wlglcVTrLKq8Zc w2k5rOtVsf0MQU4qUMP2ow6Q== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.10300571; Fri, 24 Aug 2012 15:44:33 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 24 Aug 2012 15:48:23 -0400 From: "Rosen, Brian" Date: Fri, 24 Aug 2012 15:48:22 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac2CMWtq5FWaigijRjuW7t3LJ0ouPg== Message-ID: References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> <00c601cd820b$67b97170$372c5450$@us> <5037B28B.70501@blindcreek.com> <5D0B1E63-79FE-4BC6-A446-3470931D1043@neustar.biz> <5037BC2B.7010008@blindcreek.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724@008-AM1MPN1-006.mgdnok.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: 12CZ+xj8CDGsgvuK/pATPA== Content-Type: multipart/alternative; boundary="_000_C2DD64057EC54162B7D06535FC205CD7neustarbiz_" MIME-Version: 1.0 To: "gabor.bajko@nokia.com" Cc: "paws@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 19:48:36 -0000 --_000_C2DD64057EC54162B7D06535FC205CD7neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 exis= t 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 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 su= pported by one of the peers, they can still talk, but not use that feature.= That is basically option B) from Brain=92s list. I=92d like to suggest that we recognize that option A) and B) are valid opt= ions, while option C) is invalid, and we should stop debating it. I=92d also like to add the obvious option D) to the list, which is that bot= h the master devices and DBs support one and the same encoding ;) Option A) seems to be like a good compromise, and would cut discussions sho= rt, with the only caveat that if there is no strong technical argument for = supporting and specifying two different encodings, then the iesg may send t= he document back to the wg to pick one of the two specified. As Robert ment= ioned 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 en= coding, being that either xml or json? Most people speak in favor of JSON, because it is compact and more efficien= t. 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 objectio= n gave no real reason. So I am wondering if there is really any valid techn= ical reason against using JSON only? - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Rosen, Brian Sent: Friday, August 24, 2012 10:43 AM To: Benjamin A. Rolfe Cc: 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 dec= iding 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" > 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 informa= tion about what options each supports, without requiring that any device im= plement 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 on= e 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 im= plement 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 implem= ent 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 wha= t to implement doesn't work for me (or Richard). Brian On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe > wrote: Apparently I was unclear. I certainly an capable of being wrong as I pract= ice often, but in this case it is quite unlikely :-). You do not need to choose only one form to achieve interoperability. If y= ou have two, let the device implementer figure out which is best for their = particular device requirements and trade-offs. This is *preferable* from m= y perspective. If you provide more than one form in the database, devices using the databa= se 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 thos= e 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 devic= es 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 f= orms available, it won't need to dynamically figure it out. The device impl= ementer has options and simplicity, so I like it. Since I am focused on the TVWS devices that need access to the database, an= d 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. :) This is why you have MUST and SHOULD in RFC 2119. This BTW is a classic argument in IETF terms .. but the argument =93let the= market decide=94 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 mandat= ory 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.= :) From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com Sent: Thursday, August 23, 2012 5:44 PM To: Brian.Rosen@neustar.biz; d.joslyn@spect= rumbridge.com Cc: 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 achie= ve interoperability. And this applies to the device and database side of the protocol. -Raj From: "", "Brian.Rosen@neustar.biz" > Date: Thursday, August 23, 2012 2:43 PM To: Don Joslyn > Cc: "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 impleme= ntations. On the other hand, the whole point of a protocol document like o= urs is that two independent implementations who both follow the document wi= ll 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 fig= ure it out using proprietary protocols. The market will decide. So, I feel strongly that if one end is "either", the other end must be "bot= h". It's also acceptable to say both ends implement one choice and the oth= er is optional at both ends. Here, I think it's server does both and clien= t does either. It's always possible to build an implementation of a server that only does = one: there are no protocol police. Brian On Aug 23, 2012, at 3:11 PM, Don Joslyn > 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-boun= ces@ietf.org] On Behalf Of Benjamin A. Rolfe Sent: Thursday, August 23, 2012 3:05 PM To: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal Someone suggested that PAWS define both, and let the vendors decide which o= nes to implement. That makes the most sense for both DB and device vendors. Markets will pro= bably drive DB vendors to do both. Device vendors will do what fits the mar= ket segment they're after. Why over-constrain (or argue when natural select= ion will take care of it for us?). B Sounds good to me. From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Tuesday, August 21, 2012 12:42 AM To: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal Now I can=92t see anymore any willingness to agree on one or the other enco= ding. To prevent endless discussions on this topic I=92d 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-boun= ces@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; 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 need= ed for XML From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Don Josly= n Sent: Monday, August 20, 2012 4:54 PM To: Vincent Chen; Weixinpeng Cc: paws@ietf.org; Manikkoth Sajeev Subject: Re: [paws] XML schema versus JSON, vCard & iCal Please see my comments below=85 Thanks, Don From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: Monday, August 20, 2012 2:56 PM To: Weixinpeng Cc: 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 dev= ice manufacturers. This lowers the barrier for building a robust ecosystem. [DJ - The =93cost=94 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 be= tter define =93cost=94?] * To reduce complexity and cost for device makers, supporting 1 encoding= is better than both, as Brian points out. WiFi access points that "just wo= rk" 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=92m forced to pick only one, then I will vote for X= ML because it=92s 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 (clie= nt-side) prefer it for its simplicity: * Representation closely matches most data models (nested lists and m= aps) * Simple-to-use libraries exist for all major languages/platforms * Don't need a tool chain to work with the data, as is typically need= ed for XML. Apparently, the efficiency gains of JSON also matter to the scalability of = serving systems. [DJ =96 I can=92t argue against these listed pros for JSON, especially when= you=92re dealing with a lot of data (like Twitter, FourSquare, Facebook an= d Google does). But I=92m assuming that PAWS messages will not be exchanged= nearly as often as the applications mentioned above. But again, I know JSO= N is more efficient, can=92t argue with that.] * At the end of the day, it's the data model that matters, rather than t= he 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 suppo= rting 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 device= s) 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 muc= h or exchanged that often.] On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > 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-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; gabor.bajko@nokia.com; = vchen@google.com; peter@spectrumbridge.com Cc: 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 desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml optioncan also work= . JSON I think will necessitate implementation to be native Java and may no= t be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_C2DD64057EC54162B7D06535FC205CD7neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The problem we face with JSON only is the LoST/xCard/... issue. &nbs= p;As long as there is no objection to creating JSON encodings of existing s= tandards in order to use JSON, and no one uses the fact that these encoding= s 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= wrote:

WiFi world buil= ds 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 basica= lly option B) from Brain=92s list.
 
I=92d 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.<= o:p>
I=92d also = like to add the obvious option D) to the list, which is that both the maste= r 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 enco= dings, then the iesg may send the document back to the wg to pick one of th= e 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 s= trong argument in favor of two different encodings.
=
 
Is there anyone who has a technical argument agai= nst 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 J= ava, which is wrong, the other objection gave no real reason. So I am wonde= ring if there is really any valid technical reason against using JSON only?=
 
          Gabor
&= nbsp;
 
From: 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. RolfeCc: paws@ietf.org
Subject: Re: [paws] XML schema versus JSON, vCard &= amp; iCal
&n= bsp;
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=
 
<= /div>
What do you do?
 
Brian
 
On Aug 24, 2012, at 1= :38 PM, "Benjamin A. Rolfe" <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 suppo= rts, without requiring that any device implement every option.  It wor= ks.  

That sa= id, I think (A) is the best choice, (B) is not as nice for me, and (C) is m= ore work than either of the other two.
 

 
One is that one end implements both choices and the other end imple= ments one or both.
&= nbsp;
The other is that both e= nds implement one specific choice ("MUST implement") and both can optionall= y implement the other choice.  Only if both ends implement the other c= hoice would that be available.
 
So, in this = case we could do one of the following:
A) Databases implement both XML and JSON, devices implement e= ither
B) Both Databases a= nd 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 &= lt;ben@blindcreek.com> wrote:


 

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 req= uirements 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 th= ose useful you need to provide  a protocol by which devices can discov= er what options the database supports.  If you have such a mechanism a= nd all devices use it (a  bootstrap protocol), everything else could b= e options.  This requires additional functions in both database and de= vice 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 imp= lementer has options and simplicity, so I like it. 

Since I am focused on the TVWS devices th= at need access to the database, and not a database implementer, shifting bu= rden onto the database implementer (not me) to reduce the burden on the dev= ice implementer (me) is preferred from my perspective.  The database i= mplementer may have another perspective.  Should I point out that ther= e 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 r= est 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 argume= nt =93let the market decide=94 only holds so much validity.  You actua= lly have to choose SOMETHING to create a baseline of interoperability.
 
A virtua= lly identical argument  is now playing out in discussions of mandatory= audio and codec implementations for WEBRTC like things.<= /div>
 =
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.
<= div>
 
=
End of argument you now can = go back to your regularly schedule programming. J
 
 
<= /div>
 
&n= bsp;
I agree with Bria= n.
There needs to be a d= efault mandatory to implement option in order to achieve interoperability.&= nbsp;
And this applies = to the device and database side of the protocol.
 
-Raj
 
From: "<ext Rosen>", "Brian.Rosen@neustar.biz" &= lt;Brian.Rosen@neustar.biz>
Date: Thursday, August 23, 2012 2= :43 PM
To: Don = Joslyn <d.joslyn@spectrumbridge.com>Cc: "= paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] XML schema ve= rsus JSON, vCard & iCal
 
One of my fav= orite IETF expressions is "There are no protocol police".  We apply th= at 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 int= eroperability.  
&n= bsp;
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 c= hoice and the other is optional at both ends.  Here, I think it's serv= er does both and client does either. 
 
 
Bria= n <as individual>
=  
 
 
 
=
On Aug 23, 2012, at 3:11 PM, Don Joslyn <d.joslyn@spectrumbridge.com> wrote:



Hi Ben,
=
That was my original suggesti= on, and I still think it makes the most sense.
Thanks for supporting the pr= oposal.
Don
 
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = Benjamin A. Rolfe
Sent:&nbs= p;Thursday, August 23, 2012 3:05 PM
To: paws@ietf.org
Subject= : Re: [paws] XML sche= ma versus JSON, vCard & iCal
 
Sounds good to me.
 
 paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Tuesday, August 21, 2012 12:42 AM
To: paws@ietf.org
Subject: Re: [paws] XML schema versus= JSON, vCard & iCal
 
Now I can=92= t see anymore any willingness to agree on one or the other encoding.=
To prevent endless discussions = on this topic I=92d suggest we move forward with supporting both in the DB = and either one in the master device.
Any objections?
=
Gabor
 
 
From:paws-bou= nces@ietf.org = [mailto:paws-bounces@ie= tf.org] On = Behalf Of ext Das, Su= bir
Sent: Monda= y, August 20, 2012 2:50 PM
To: Don Joslyn; Vincent Chen; Weixinpeng
Cc: paws@ietf.org; Manikkoth Sajeev
Subject: Re: [paws] XML schema versu= s JSON, vCard & iCal
 
We have a ha= lf 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 t= he data, as is typically needed for XML
 
=  
 =
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of<= span class=3D"apple-converted-space"> Don Joslyn
Sent= : Monday, August 20, = 2012 4:54 PM
To: Vincent Chen; Weixinpeng
Cc: paws@ietf.org; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal
 
Please see my comments below=85=
Thanks,
=
Don
 
From:paws-bou= nces@ietf.org = [mailto:paws-bounces@ie= tf.org] On = Behalf Of Vincent Che= n
Sent: Monday,= August 20, 2012 2:56 PM
To: Weixinpeng
Cc: paws@ietf.org; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal
 
    <= li class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; = font-family: 'Times New Roman', serif; vertical-align: baseline; ">One of our goal= s is to strive to lower the cost and complexity for device manufacturers. T= his lowers the barrier for building a robust ecosystem.
  • To reduce complexity and cost for device = makers, supporting 1 encoding is better than both, as Brian points out. WiF= i access points that "just work" anywhere in the world serves as a good mod= el.
    • [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=92m forced to pick only o= ne, then I will vote for XML because it=92s the one that we currently use o= n all embedded devices.]
    • There's a trend for APIs on the web towards= JSON (Twitter, FourSquare, Facebook, Google, etc.). One of the major reaso= ns is that developers (client-side) prefer it for its simplicity:
        Representati= on closely matches most data models (nested lists and maps)
      • = Simple-= to-use libraries exist for all major languages/platforms<= /li>
      • Don't need= a tool chain to work with the data, as is typically needed for XML.=

     

    [DJ =96 I can=92t argue against these listed pros for JSON, espe= cially when you=92re dealing with a lot of data (like Twitter, FourSquare, = Facebook and Google does). But I=92m assuming that PAWS messages will not b= e exchanged nearly as often as the applications mentioned above. But again,= I know JSON is more efficient, can=92t 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 wha= t device makers want. It would be good to get feedback from device makers (= especially of embedded devices) regarding experiences supporting XML vs JSO= N.

     <= /p>

    Don, can you elabo= rate 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 no= t 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.]<= /o:p>

    On Fri, Aug 17, 2012 at 6:06 PM, = Weixinpeng <weixinpeng@huawei.com> wrote:
    Considering of the de= sign of database discovery protocol, the LoST protocol may be used and LoST= is based on XML, so I think XML may be preferred.
    <= /div>
     
    --Xinpeng Wei=
    From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Rosen, Brian
    <= div>

    Sent: Friday, August 17, 2012 9:26 PM

    Cc: paws@ietf.= org
    Subject:&nbs= p;Re: [paws] XML schema versus JSON, vCard & iCal
     
    I don't really care whether we use json or xm= l as a matter of protocol design or implementation, but I am a big fan of r= eusing 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 existi= ng standards based on the idea there is no json representation of an existi= ng standard.  So, if choosing json means folks feel free to ignore exi= sting xml based standards such as xCard and LoST, then I would not want to = use json.
     =
    I would prefer to not have "b= oth", because of interoperability complications.  If there is rough co= nsensus for both, then I would assert that all servers have to implement bo= th and the client can implement either.
    <= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times= New Roman', serif; "> 
    There are json validators, so I don't think that is a big deal.  
     
    My experience in protocol design on the In= ternet is that decisions made solely or even largely because of compactness= advantages rarely are good choices.  If you like json because it is s= maller, 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>
    Reply-To: Manikkoth Sajeev <mksaji@yahoo.com>
    Date: Thu, 16 Aug 2012 22:37:38 -0400To: "Gabor.Bajko@nokia= .com" <Gabor.Bajko@nokia.com>, "Rosen, Brian" <brian= .rosen@neustar.biz>, "vchen@google.com" <vchen@google.com>, "peter@spectrumbridge.com" <peter@spectrumbridge.com>
    Cc: "= paws@ietf.org= " <paws@ietf.org>
    Subject: Re: [paws] XML schema versus JSON, vCard &= iCal
     
    Hi,
     
    Can it not be both JSON and XML su= pported? 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 optionc= an also work. JSON I think will necessitate implementation to be native Jav= a and may not be as friendly with other implementation languages.
     
    Best Regards,
    From: "Gabor.Bajko@nokia.com" < Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com 
    Cc: paws@ietf.org 
    Sent:&nbs= p;Friday, 17 August 2012, 4:55
    Subject: Re: [paws] XML schema versus JSON, vCard &a= mp; iCal


    We have not heard any obje= ctions for using JSON encoding instead of XML. 
    Therefore, let's go for JSON, and close this thre= ad.

    - Gabor

    -----Original Message-----
    From: = paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of ext Rosen, Brian
    Sent: Monday, August 13, 2012 3:14 PMTo: 'Vincent Chen'; 'Peter Stanforth'
    Cc: 'paws@ietf.org'
    Subject: Re:= [paws] XML schema versus JSON, vCard & iCal

    json is okay with m= e.  
    I'd prefer a= n 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>



    -----Origi= nal Message-----
    From:     Vincent Chen [mailto:vchen@google.com<= /span>]
    Sent:    Monday, August 13, 2012 06:04 PM Eas= tern Standard Time
    To:    Peter Stanforth
    Cc: &nb= sp;  Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
    Subject:    Re: [= paws] XML schema versus JSON, vCard & iCal

    XML vs JSON

    Be= tween XML and JSON, JSON messages are more compact and easier to process (p= arsing, synthesis). As clarification, JSON does not require JavaScript or a= Browser. It is a text-based representation of data that is language indepe= ndent, yet well-matched to all major languages. JSON-handling libraries exi= st for numerous languages (see of&nbs= p;http://j= son.org/) and seem to be reasonably light weight.

    Timesta= mps

    As for timestamp specifications, should we consider just using s= econds since the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate th= e need for datetime-string parsing on devices, assuming devices already hav= e native libraries that provide time in this format. Is that a valid assump= tion? Of course, this is less human-readable....


    On Mon, Aug 13,= 2012 at 6:49 AM, Peter Stanforth <peter@spectrumbridge.com>= wrote:


        Whenever we built mobile devices we n= ever dealt with IETF, in our sensor
        days even an IP s= tack was a challenge,so I would defer to the device guys
      &nb= sp; on that one.
        
        On MonAug/13/12 Mon Aug 13, 9:30 AM, "= Rosen, Brian"
       &n= bsp;
        <Brian.Rosen@neustar.biz> w= rote:
        
        >Our experience in the IETF over many years is= that economizing message
        >size and compromising u= tility and security in search of efficiency of
        >im= plementation on small devices is a poor trade off.  I am not advocatin= g
        >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]
        >Sent:  Saturday, August 11, 2012 07:= 13 AM Eastern Standard Time
        >To:    Teco= Boot; Benjamin A.Rolfe
        >Cc:    paws@ietf.org
       = >Subject:      Re: [paws] XML schema versus JSON, vCard = & iCal
        >
        >Not all mas= ters run over the core network.
        >Some of the Use c= ases have a master talking to another OTA
        >We shou= ld not assume that all Masters are attached to utility power so we
     = ;   >should be sympathetic to processing energy use also.
    &= nbsp;   >
        >On SatAug/11/12 Sat Aug 11= , 5:30 AM, "Teco Boot" <teco@inf-net.nl> wrote:
       = >
        >>
        >>Op 10 au= g. 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,
        >>>su= ch as embedded devices in what are now popularly called "M2M"
     &nbs= p;  >>>applications.  A lot of these devices could use I= P 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 n= o browser?
        >>>Would it be hard to do in a re= source constrained device (i.e. where we
        >>>= talk about memory size in Kilo-bytes still).
        >>=
        >>In use cases and requirements document, ther= e are no requirements for
        >>protocol performanc= e. I guess OS/IP/TCP/TLS code size supersedes needs
        &= gt;>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.
    &nb= sp;   >>
        >>Because PAWS runs be= tween master and database, over core network,
        >>= ;performance is not our primary concern. But as always, it is good to keep<= br>    >>an eye on efficiency.
        &= gt;>
        >>Teco
        >>    >>> Thanks
        >>>= Ben
        >>>
        >>><= br>    >>>> We had a discussion on XML vs. JSON.= I prefer the one with most
        >>>>compact m= essages.
        >>>>
        >&= gt;>> On vCard and JSON: what is the status of "A JavaScript Object N= otation
        >>>>(JSON) Representation for vCa= rd"?
        >>>> http://tools.ietf.org/html/draft-bh= at-vcarddav-json-00
        >>>>
    &n= bsp;   >>>> On valid times: can we use same format as= certificates? They have
        >>>>similar simp= le requirements: valid notBefore&  notAfter.
       = >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
    =     >>>>
        >>>> = Teco
        >>>> _______________________________= ________________
        >>>> paws mailing list    >>>>=  = paws@ietf.org
        >>>> https://www.ietf.org/mailm= an/listinfo/paws
        >>>>
     = ;   >>>
        >>> _____________= __________________________________
        >>> paws = mailing list
        >>> paws@ietf.org
        >>> https://www.ietf.org/= mailman/listinfo/paws
        >>
     &n= bsp;  >>_______________________________________________
     = ;   >>paws mailing list
        >>paws@ietf.org
        >>https://www.ietf.org/mailman/= listinfo/paws
        >
        &= gt;_______________________________________________
        &g= t;paws mailing list
        >paws@ietf.org
      &n= bsp; >https://www.ietf.org/mailman/listinfo/paws
    =     
    &n= bsp;   _______________________________________________
     &= nbsp;  paws mailing list
        paws@ietf.org
        https://www.ietf.org/mailman/l= istinfo/paws
        




    -- 
    -vince

    ______________________________________= _________
    paws mailing list
    paws@ietf.org
    https://www.iet= f.org/mailman/listinfo/paws
    _________________________________= ______________
    paws mailing list
    paws@ietf.org
    https://www.= ietf.org/mailman/listinfo/paws

    <= /div>


     
    -- -vince
     
     
    ________________________________=
_______________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws
     
    <=
/div>
    _______________________________________________paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws
     
     
    ____________=
___________________________________
    paws mailin=
g list
    paws@ietf.org
    https://www.ietf.org/=
mailman/listinfo/paws
     = ;
    _________________________________= ______________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws


    = --_000_C2DD64057EC54162B7D06535FC205CD7neustarbiz_-- From vchen@google.com Fri Aug 24 12:50:42 2012 Return-Path: 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 31E8E21F8609 for ; Fri, 24 Aug 2012 12:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 nnwT8X-OUaFr for ; Fri, 24 Aug 2012 12:50:41 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9135E21F8605 for ; Fri, 24 Aug 2012 12:50:41 -0700 (PDT) Received: by qcac10 with SMTP id c10so1653230qca.31 for ; Fri, 24 Aug 2012 12:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record; bh=59/ttVDrLY+8DsXnIzZqEgW60cqcYXvkSw0jSarC9CI=; b=FInIlnLGM69m5J+f4IqB6G2GNZ+WiSx3JCpkjooTLG+JNo7Pp+o/NRmAQcuPR9wYg3 mL+USd5ibhX/OU+3TG0FJ+YMpkAs5sKzL1TJcx062KYfG7pL+YayJBxUWd4EJVcYavV9 L14eiPXjBryPymBZGgUcGrX/8PHET/GN56VvVSeVFhZ0ZBHeXb6kgxFyiVgHc1BjmSKj Tt/YyuIi/WAL/c1lWCe2EXh5rAjfIogaB00HoIoMwRMJf0TFFFP3HX1vveefacMVh4y2 FO/npNV53VQDMQYzoRjwSQtmtIfhhi7qivlY6+wldhm1TFihmgbTWPA+nXJtjvzuumnR rfVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record:x-gm-message-state; bh=59/ttVDrLY+8DsXnIzZqEgW60cqcYXvkSw0jSarC9CI=; b=j2bRRhW9WQ+67HMtKawq5MLTG+Xr4NHd/SueD/0hhrhDErYK3gTyyXjWSrlHP4/eDE 0E6f+yiKMF4HmAooT+D9jwJxuxeVQGNwz2GqYY3wxctipLCFRjMp8IJ5o8Vx0ACyrgst ylQM9XsEcQG8n/rdPrtz4WQbHS4+5AGTV+u7BI4QyFPszMzMGzDhnNH533KV7TO0rWwF TYw34gWNvRlURm7HojSffuvNkQs6uYXtqGhmJrYOK0aC19K+kuMr/NCtMxy3rwJ9c1NJ i9xex/BwOJzybgK/+zRaDlmwU9uoLng6ujGmzn+T6b39LVavTtfGJl4C3dWD/H3/P5np k7Cg== Received: by 10.229.135.193 with SMTP id o1mr3091756qct.100.1345837841008; Fri, 24 Aug 2012 12:50:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.193 with SMTP id o1mr3091752qct.100.1345837840819; Fri, 24 Aug 2012 12:50:40 -0700 (PDT) Received: by 10.229.64.149 with HTTP; Fri, 24 Aug 2012 12:50:40 -0700 (PDT) In-Reply-To: <5033AB55.10205@blindcreek.com> References: <50329616.3030207@blindcreek.com> <0FCA100D-7C67-47F6-A0C2-03B27F60545E@neustar.biz> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB5D8D@008-AM1MPN1-006.mgdnok.nokia.com> <2782C93FD2244441893673F3F912819206685893@IMCMBX01.MITRE.ORG> <5033AB55.10205@blindcreek.com> Date: Fri, 24 Aug 2012 12:50:40 -0700 Message-ID: From: Vincent Chen To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=00248c768f266d663f04c8084a05 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm9VbBNO373CPjEQBKDCiJYtKyeWbUrZTn5KaF6yr3A7nraeC7Pkoa6URxVqLM/ObbPd6O7zmVCosaAgWjCtAWqofoM00h0akhrP0D0kcOl2r2fkFDc3zjROKW+fR/ZqAOxRJ8Hz4qD18SC61Gj/xQkWbWOgJoFnjzwgbDAG5KbE+76JRtYiyh/wEZun0VKaeDcqCca Subject: Re: [paws] use cases and requirements document X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 19:50:42 -0000 --00248c768f266d663f04c8084a05 Content-Type: text/plain; charset=ISO-8859-1 Although I contributed to the confusion by bring up timestamp format, it seems the exact format of the timestamp is too detailed for the Requirements doc. The requirements should just describe capabilities. Specific encoding/format should be reserved for the Protocol-specification document. Taking this into account, the proposed text for D.7 might be: "The Data Model MUST support specifying available spectrum. The Data Model MUST support specification of this information by start and stop frequencies and MAY also support specification of this information by channel identifiers. The Data Model MUST support a spectrum-availability schedule and maximum power levels for each frequency range." The term, schedule, I believe, captures the intent of the various discussions, e.g., allowing for multiple time-intervals of operation. --00248c768f266d663f04c8084a05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Although I contributed to the confusion by bring up timestamp format, = it seems the exact format of the timestamp is too detailed for the Requirem= ents doc. The requirements should just describe capabilities. Specific enco= ding/format should be reserved for the Protocol-specification document.

    Taking this into account, the proposed text for D.7 mig= ht be:

    "The Data Model MUST support specifyin= g available
    =A0 =A0 =A0 =A0 =A0 spectrum. The Data Model MUST sup= port specification of this
    =A0 =A0 =A0 =A0 =A0 information by start and stop frequencies and MAY = also support
    =A0 =A0 =A0 =A0 =A0 specification of this informatio= n by channel identifiers. The
    =A0 =A0 =A0 =A0 =A0 Data Model MUST= support a spectrum-availability schedule and
    =A0 =A0 =A0 =A0 =A0 maximum power levels for each frequency range.&quo= t;

    The term, schedule, I believe, captures the int= ent of the various discussions, e.g., allowing for multiple time-intervals = of operation.

    --00248c768f266d663f04c8084a05-- From Basavaraj.Patil@nokia.com Fri Aug 24 12:51:27 2012 Return-Path: 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 58A7221F85A8 for ; Fri, 24 Aug 2012 12:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.004 X-Spam-Level: X-Spam-Status: No, score=-106.004 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 CfOrhU+X-2vl for ; Fri, 24 Aug 2012 12:51:23 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3C51E21F8605 for ; Fri, 24 Aug 2012 12:51:22 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7OJpJ8P014555; Fri, 24 Aug 2012 22:51:20 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Aug 2012 22:51:19 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.02.0283.004; Fri, 24 Aug 2012 21:51:18 +0200 From: To: , Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Iej7JadvAx8UahySbuq9n2zQAAU/5DAJUxXAAABrI7AAAWoncAABh1noAAifZJAAAEHtqAAAHwqAAADmEvAACA/ioAAAG/7gAAADZkgAABIt+A///NtAD//meaQIADLqOAgAADSYCAAAgwgIAAAR6AgAAX74CAAAsjAP//rRSA Date: Fri, 24 Aug 2012 19:51:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [72.64.105.77] Content-Type: multipart/alternative; boundary="_000_CC5D4569228D8basavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 24 Aug 2012 19:51:19.0460 (UTC) FILETIME=[D48C8640:01CD8231] X-Nokia-AV: Clean Cc: paws@ietf.org 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 19:51:27 -0000 --_000_CC5D4569228D8basavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 to Brian's view on using JSON only. From: "", "Brian.Rosen@neustar.biz" > Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko > Cc: "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 exis= t 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 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 su= pported by one of the peers, they can still talk, but not use that feature.= That is basically option B) from Brain=92s list. I=92d like to suggest that we recognize that option A) and B) are valid opt= ions, while option C) is invalid, and we should stop debating it. I=92d also like to add the obvious option D) to the list, which is that bot= h the master devices and DBs support one and the same encoding ;) Option A) seems to be like a good compromise, and would cut discussions sho= rt, with the only caveat that if there is no strong technical argument for = supporting and specifying two different encodings, then the iesg may send t= he document back to the wg to pick one of the two specified. As Robert ment= ioned 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 en= coding, being that either xml or json? Most people speak in favor of JSON, because it is compact and more efficien= t. 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 objectio= n gave no real reason. So I am wondering if there is really any valid techn= ical reason against using JSON only? - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Rosen, Brian Sent: Friday, August 24, 2012 10:43 AM To: Benjamin A. Rolfe Cc: 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 dec= iding 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" > 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 informa= tion about what options each supports, without requiring that any device im= plement 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 on= e 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 im= plement 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 implem= ent 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 wha= t to implement doesn't work for me (or Richard). Brian On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe > wrote: Apparently I was unclear. I certainly an capable of being wrong as I pract= ice often, but in this case it is quite unlikely :-). You do not need to choose only one form to achieve interoperability. If y= ou have two, let the device implementer figure out which is best for their = particular device requirements and trade-offs. This is *preferable* from m= y perspective. If you provide more than one form in the database, devices using the databa= se 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 thos= e 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 devic= es 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 f= orms available, it won't need to dynamically figure it out. The device impl= ementer has options and simplicity, so I like it. Since I am focused on the TVWS devices that need access to the database, an= d 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. :) This is why you have MUST and SHOULD in RFC 2119. This BTW is a classic argument in IETF terms .. but the argument =93let the= market decide=94 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 mandat= ory 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.= :) From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com Sent: Thursday, August 23, 2012 5:44 PM To: Brian.Rosen@neustar.biz; d.joslyn@spect= rumbridge.com Cc: 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 achie= ve interoperability. And this applies to the device and database side of the protocol. -Raj From: "", "Brian.Rosen@neustar.biz" > Date: Thursday, August 23, 2012 2:43 PM To: Don Joslyn > Cc: "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 impleme= ntations. On the other hand, the whole point of a protocol document like o= urs is that two independent implementations who both follow the document wi= ll 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 fig= ure it out using proprietary protocols. The market will decide. So, I feel strongly that if one end is "either", the other end must be "bot= h". It's also acceptable to say both ends implement one choice and the oth= er is optional at both ends. Here, I think it's server does both and clien= t does either. It's always possible to build an implementation of a server that only does = one: there are no protocol police. Brian On Aug 23, 2012, at 3:11 PM, Don Joslyn > 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-boun= ces@ietf.org] On Behalf Of Benjamin A. Rolfe Sent: Thursday, August 23, 2012 3:05 PM To: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal Someone suggested that PAWS define both, and let the vendors decide which o= nes to implement. That makes the most sense for both DB and device vendors. Markets will pro= bably drive DB vendors to do both. Device vendors will do what fits the mar= ket segment they're after. Why over-constrain (or argue when natural select= ion will take care of it for us?). B Sounds good to me. From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Tuesday, August 21, 2012 12:42 AM To: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal Now I can=92t see anymore any willingness to agree on one or the other enco= ding. To prevent endless discussions on this topic I=92d 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-boun= ces@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; 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 nee= ded for XML From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Don Josly= n Sent: Monday, August 20, 2012 4:54 PM To: Vincent Chen; Weixinpeng Cc: paws@ietf.org; Manikkoth Sajeev Subject: Re: [paws] XML schema versus JSON, vCard & iCal Please see my comments below=85 Thanks, Don From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: Monday, August 20, 2012 2:56 PM To: Weixinpeng Cc: 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 de= vice manufacturers. This lowers the barrier for building a robust ecosystem= . [DJ - The =93cost=94 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 be= tter define =93cost=94?] * To reduce complexity and cost for device makers, supporting 1 encodin= g is better than both, as Brian points out. WiFi access points that "just w= ork" 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=92m forced to pick only one, then I will vote for X= ML because it=92s 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 (cli= ent-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 nee= ded for XML. Apparently, the efficiency gains of JSON also matter to the scalability of = serving systems. [DJ =96 I can=92t argue against these listed pros for JSON, especially when= you=92re dealing with a lot of data (like Twitter, FourSquare, Facebook an= d Google does). But I=92m assuming that PAWS messages will not be exchanged= nearly as often as the applications mentioned above. But again, I know JSO= N is more efficient, can=92t 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 w= e're clear on what device makers want. It would be good to get feedback fro= m device makers (especially of embedded devices) regarding experiences supp= orting 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 device= s) 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 muc= h or exchanged that often.] On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > 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-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; gabor.bajko@nokia.com; = vchen@google.com; peter@spectrumbridge.com Cc: 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 desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml optioncan also work= . JSON I think will necessitate implementation to be native Java and may no= t be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CC5D4569228D8basavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4B25DC9CEDAC2F47A6BA8E7334A232FF@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable

    +1 to Brian's view on using JSON only.

    From: "<ext Rosen>"= , "Brian.Rosen@neustar.biz<= /a>" <Brian.Rosen@neusta= r.biz>
    Date: Friday, August 24, 2012 2:48 = PM
    To: Gabor Bajko <gabor.bajko@nokia.com>
    Cc: "paws@ietf.org" <paws@i= etf.org>
    Subject: Re: [paws] XML schema vers= us JSON, vCard & iCal

    The problem we face with JSON only is the LoST/xCard/... issue.  As lo= ng as there is no objection to creating JSON encodings of existing standard= s 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 wrote:

    WiFi world builds on mandating the implementation (and ce= rtification) 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 basicall= y option B) from Brain=92s list.
     
    I=92d like to suggest that we recognize that option A) an= d B) are valid options, while option C) is invalid, and we should stop deba= ting it.
    I=92d 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 enc= oding ;)
     
    Option A) seems to be like a good compromise, and would c= ut discussions short, with the only caveat that if there is no strong techn= ical argument for supporting and specifying two different encodings, then the iesg may send the document back to the w= g 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 frankl= y, I do not see a strong argument in favor of two different encodings.
     
    Is there anyone who has a technical argument against supp= orting only one encoding, being that either xml or json?<= /div>
     
    Most people speak in favor of JSON, because it is compact= and more efficient. I went through this thread and I saw 2 objections agai= nst picking JSON. One said that JSON requires native Java, which is wrong, the other objection gave no real rea= son. So I am wondering if there is really any valid technical reason agains= t using JSON only?
     
    -        &nb= sp; = Gabor
     
     
    From:=  paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext = Rosen, Brian
    Sent: Friday, Augu= st 24, 2012 10:43 AM
    To: Benjamin A. Ro= lfe
    Cc: 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 dec= iding 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> 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 inf= ormation about what options each supports, without requiring that any devic= e 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 on= e or both.
     
    The other is that both ends implement one specific choice ("MUST imple= ment") 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 implem= ent 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 wha= t to implement doesn't work for me (or Richard).
     
    Brian
     
    On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe <ben@bl= indcreek.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. &= nbsp; If you have two, let the device implementer figure out which is best = for their particular device requirements and trade-offs.  This is *pre= ferable* from my perspective.

    If you provide more than one form in the database, devices using the databa= se 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 dis= cover what options the database supports.  If you have such a mechanis= m 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 d= evice implementer has options and simplicity, so I like it. 

    Since I am focused on the TVWS devices that need access to the database, an= d 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 th= ere 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.  <= /span>
     
    This BTW is a classic argument in IETF terms .. but the a= rgument =93let the market decide=94 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 i= n discussions of mandatory audio and codec implementations for WEBRTC like = things.
     
    IMHO XML MUST anything else defined SHOULD, but MUST on X= ML and JSON could work as well. It just leads to a level of complexity in i= mplementations.
     
    End of argument you now can go back to your regularly sch= edule programming. J
     
     
    From:=  p= aws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com
    Sent: Thursday, Au= gust 23, 2012 5:44 PM
    To: Brian.Rosen@neustar.biz;&= nbsp;d.joslyn@spectrumbridge.com
    Cc: pa= ws@ietf.org
    Subject: Re: [paws= ] XML schema versus JSON, vCard & iCal
     
     =
    I agre= e with Brian.
    There = needs to be a default mandatory to implement option in order to achieve int= eroperability. 
    And th= is applies to the device and database side of the protocol.
     =
    -Raj
     =
    From= : "<ext Rose= n>", "Brian.Rosen@neustar.biz" <Brian.Rosen@neustar.biz>
    Date: Thursday, Au= gust 23, 2012 2:43 PM
    To: Don Joslyn <= ;d.joslyn@spectrumbridge.com>
    Cc: "paws@ietf.org" <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 i= mplement 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 implem= entations 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 you= r 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 a= lways possible to build an implementation of a server that only does one: t= here are no protocol police.
     =
    Brian = <as individual>
     =
     =
     =
     =
    On Aug= 23, 2012, at 3:11 PM, Don Joslyn <d.joslyn@sp= ectrumbridge.com> wrote:



    Hi Ben,
    That was my original suggestion, and I still think it mak= es the most sense.
    Thanks for supporting the proposal.
    Don
     
    From:=  pa= ws-bounces@ietf.org [= mailto:paws-bounces@ietf.org] On Behalf Of Benjamin A= . Rolfe
    Sent: Thursday, Au= gust 23, 2012 3:05 PM
    To: pa= ws@ietf.org
    Subject: Re: [paws= ] XML schema versus JSON, vCard & iCal
     
    Someone suggested that PAWS define both, and let the vendors decide which o= nes to implement.
    That makes the most sense for both DB and device vendors.  Markets wil= l probably drive DB vendors to do both. Device vendors will do what fits th= e market segment they're after. Why over-constrain (or argue when natural s= election will take care of it for us?).
    B



    Sounds = good to me.
     <= /span>
    From:=  paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com<= br> Sent: Tuesday, Aug= ust 21, 2012 12:42 AM
    To: paws@ietf.org
    Subject: Re: [paws= ] XML schema versus JSON, vCard & iCal
     
    Now I c= an=92t see anymore any willingness to agree on one or the other encoding.
    To prev= ent endless discussions on this topic I=92d suggest we move forward with su= pporting both in the DB and either one in the master device.
    Any obj= ections?
     <= /span>
    Gabor
     <= /span>
     <= /span>
    From:=  paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Das, S= ubir
    Sent: Monday, Augu= st 20, 2012 2:50 PM
    To: Don Joslyn; Vi= ncent Chen; Weixinpeng
    Cc: 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:
     <= /span>
      • Simple-= to-use libraries exist for all major languages/platforms<= /li>
      • Don't n= eed a tool chain to work with the data, as is typically needed for XML
     <= /span>
     <= /span>
     <= /span>
    From:=  paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Don Joslyn=
    Sent: Monday, Augu= st 20, 2012 4:54 PM
    To: Vincent Chen; = Weixinpeng
    Cc: paws@ietf.org; Manikkoth Sajeev Subject: Re: [paws= ] XML schema versus JSON, vCard & iCal
     
    Please = see my comments below=85
    Thanks,=
    Don
     <= /span>
    From:=  paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Ch= en
    Sent: Monday, Augu= st 20, 2012 2:56 PM
    To: Weixinpeng
    Cc: 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 manufact= urers. This lowers the barrier for building a robust ecosystem.=
    [DJ - The =93cost=94 and complexi= ty 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 =93cost=94?]
    • To redu= ce complexity and cost for device makers, supporting 1 encoding is better t= han 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 databas= es support both XML and JSON, devices only need to support one to talk to t= he database. Our current database supports XML and JSON, but if I=92m force= d to pick only one, then I will vote for XML because it=92s the one that we currently use on all embedded devic= es.]
    • There's= a trend for APIs on the web towards JSON (Twitter, FourSquare, Facebook, G= oogle, etc.). One of the major reasons is that developers (client-side) pre= fer it for its simplicity:
      • Represe= ntation closely matches most data models (nested lists and maps)
      • Simple-= to-use libraries exist for all major languages/platforms<= /li>
      • Don't n= eed a tool chain to work with the data, as is typically needed for XML.

    Apparen= tly, the efficiency gains of JSON also matter to the scalability of serving= systems.

     <= o:p>
    [DJ =96 I can=92t argue against t= hese listed pros for JSON, especially when you=92re dealing with a lot of d= ata (like Twitter, FourSquare, Facebook and Google does). But I=92m assumin= g that PAWS messages will not be exchanged nearly as often as the applications mentioned above. But again, I know JSO= N is more efficient, can=92t 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, ca= n 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 b= etween device and database is not that much or exchanged that often.]

    On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng <weixinpeng@huawei.com= > wrote:
    Considering of the design of database discovery protoco= l, the LoST protocol may be used and LoST is based on XML, so I think XML m= ay be preferred.
     
    --Xinpeng Wei
     
    From:=  paws-bounces@ietf.org [mailto:paws-bounces@iet= f.org] On Behalf Of Rosen, Bri= an

    Sent: Friday, Augu= st 17, 2012 9:26 PM

    Cc: 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 defini= ng 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 ign= ore existing xml based standards such as xCard and LoST, then I would not want to use json.
     = ;
    I wou= ld prefer to not have "both", because of interoperability complic= ations.  If there is rough consensus for both, then I would assert tha= t 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 ex= perience in protocol design on the Internet is that decisions made solely o= r even largely because of compactness advantages rarely are good choices. &= nbsp;If you like json because it is smaller, then I believe you need a much better reason.  Binary doesn't work fo= r me, at all.  I have been involved in big binary vs text wars in prot= ocol design.  Text wins, binary loses, in my opinion.
     = ;
    Brian= <as individual>
     = ;
     = ;
    From:<= /span> "Gabor.Bajko@nokia.com" <= Gabor.Bajko@nokia.com>
    To: Brian.Rosen@neust= ar.biz; vchen@google.com= ; peter@spectrum= bridge.com  Cc: paws@ietf.org 
    Sent: Friday, 17 A= ugust 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] On Behalf Of ext Rosen, Brian
    Sent: Monday, August 13, 2012 3:14 PM
    To: 'Vincent Chen'; 'Peter Stanforth'
    Cc: 'paws@iet= f.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.&nbs= p; It's very easy to parse, and its simpler to use and debug.  Don't c= are a whole lot about that

    Brian <as individual>



    -----Original Message-----
    From:     Vincent Chen [mailto:vchen@google.com]
    Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard T= ime
    To:    Peter Stanforth
    Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
    Subject:    Re: [paws] XML schema versus JSON, vCard & i= Cal

    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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries exist for numerous languages (see= of http://json.org/) and seem to be reasonably light weight.

    Timestamps

    As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries 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= > wrote:


        Whenever we built mobile devices we never dealt with IET= F, in our sensor
        days even an IP stack was a challenge,so I would defer t= o the device guys
        on that one.
        
        On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian&= quot;
        
        <Brian.Rosen@neustar.biz> wrote:
        
        >Our experience in the IETF over many years is that e= conomizing 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 sh= ould seriously
        >consider the overhead of XML or json to be significa= nt.
        >
        >Assuming a json library can be loaded on a small dev= ice is reasonable.
        >
        >Brian (as individual)
        >
        >
        >
        > -----Original Message-----
        >From:  Peter Stanforth [mailto:peter@spectrumbrid= ge.com]
        >Sent:  Saturday, August 11, 2012 07:13 AM Easte= rn Standard Time
        >To:    Teco Boot; Benjamin A.Rolfe
        >Cc:    = teco@inf-net.nl> wrote:
        >
        >>
        >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolf= e het volgende
        >>geschreven:
        >>
        >>> Compactness of messages is important, but i= t is also important (to me
        >>>at least) to be realizable in an implementat= ion with limited resources,
        >>>such as embedded devices in what are now pop= ularly called "M2M"
        >>>applications.  A lot of these devices c= ould use IP all the end to end,
        >>>but may have a very compact, simple stack an= d applications (i.e.  no
        >>>browser).  Is JSON typically implemente= d when there is no browser?
        >>>Would it be hard to do in a resource constra= ined device (i.e. where we
        >>>talk about memory size in Kilo-bytes still).=
        >>
        >>In use cases and requirements document, there ar= e 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 t= ake more than the PAWS
        >>message exchange, I think. This may be of import= ance when using satcom
        >>links.
        >>
        >>Because PAWS runs between master and database, o= ver core network,
        >>performance is not our primary concern. But as a= lways, 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 o= f "A JavaScript Object Notation
        >>>>(JSON) Representation for vCard"?     >>>>&n= bsp;= http://tools.ietf.org/html/draft-bhat-vcard= dav-json-00
        >>>>
        >>>> On valid times: can we use same format = as certificates? They have
        >>>>similar simple requirements: valid notBe= fore&  notAfter.
        >>>>&n= bsp;http://tools.ietf.org/html/rfc3280#section-4.1.= 2.5
        >>>>
        >>>> Teco
        >>>> _______________________________________= ________
        >>>> paws mailing list
        >>>>&n= bsp;pa= ws@ietf.org
        >>>>&n= bsp;https://www.ietf.org/mailman/listinfo/paws<= br>     >>>>
        >>>
        >>> ___________________________________________= ____
        >>> paws mailing list
        >>> = paws@i= etf.org
        >>> = https://www.ietf.org/mailman/listinfo/paws
        >>
        >>_______________________________________________<= br>     >>paws mailing list
        >>paws@ietf.org
        >>https://www.ietf.org/mailman/listinfo/p= aws
        >
        >_______________________________________________
        >paws mailing list
        >paws@ietf.org
        >= https://www.ietf.org/mailman/listinfo/paws<= /span>
        
        _______________________________________________
        paws mailing list
        paws@ietf.org
         




    -- 
    -vince

    _______________________________________________
    paws mailing list
    paws@ietf.org=
    https://www.ietf.org/mailman/listinfo/paws
    _______________________________________________
    paws mailing list
    paws@ietf.org=
    https://www.ietf.org/mailman/listinfo/paws



     
    -- 
    -vince
     
     
    _______________________________________________

    paws mailing list
    

    paws@ietf.org
    

    
 
     = 
     
    _______________________________________________

    paws mailing list
    

    paws@ietf.org
    

    https://www.ietf.org/mailman/=
listinfo/paws
    

    
 
    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paw= s
     
     


    --_000_CC5D4569228D8basavarajpatilnokiacom_-- From Peter.McCann@huawei.com Fri Aug 24 14:15:16 2012 Return-Path: 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 32A3621F8617 for ; Fri, 24 Aug 2012 14:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.694 X-Spam-Level: X-Spam-Status: No, score=-5.694 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, 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 PO8RXWkm-9Hd for ; Fri, 24 Aug 2012 14:15:14 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C58FB21F8616 for ; Fri, 24 Aug 2012 14:15:13 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp01-ep.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id ALA00844; Fri, 24 Aug 2012 13:15:13 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Aug 2012 14:11:41 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.151]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Fri, 24 Aug 2012 14:11:38 -0700 From: Peter McCann To: "Basavaraj.Patil@nokia.com" , "Brian.Rosen@neustar.biz" , "Gabor.Bajko@nokia.com" Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Ie7Nd2WNzPm0+85/tpR52R7QAAU/5DAJUxXAAABrI7AAAWoncAABh1noAAifZJAAAEHtqAAAHwqAAADmEvAACA/ioAAAG/7gAAADZkgAABIt+A///NtAD//meaQIADLqOAgAADSYCAAAgwgIAAAR6AgAAX74CAAAsjAP//rRSA//90vsA= Date: Fri, 24 Aug 2012 21:11:37 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E2877C@dfweml512-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 21:15:16 -0000 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 wrote: >=20 > +1 to Brian's view on using JSON only. >=20 > From: "", "Brian.Rosen@neustar.biz"=20 > > Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko=20 > Cc: "paws@ietf.org" Subject: Re: > [paws] XML schema versus JSON, vCard & iCal >=20 >=20 > The problem we face with JSON only is the LoST/xCard/... issue. As=20 > long as there is no objection to creating JSON encodings of existing=20 > standards in order to use JSON, and no one uses the fact that these=20 > encodings don't exist as a reason to roll our own equivalents, I am=20 > okay with JSON only. >=20 > Brian >=20 > On Aug 24, 2012, at 3:08 PM, Gabor.Bajko@nokia.com wrote: >=20 >=20 > WiFi world builds on mandating the implementation (and > certification) of a base spec, and a set of optional features. If an=20 > optional feature is not supported by one of the peers, they can still=20 > talk, but not use that feature. That is basically option B) from=20 > Brain's list. >=20 > I'd like to suggest that we recognize that option A) and B) are valid=20 > 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=20 > both the master devices and DBs support one and the same encoding ;) >=20 > Option A) seems to be like a good compromise, and would cut=20 > discussions short, with the only caveat that if there is no strong=20 > technical argument for supporting and specifying two different=20 > encodings, then the iesg may send the document back to the wg to pick=20 > one of the two specified. As Robert mentioned in his email, this has=20 > happened in the past, so it is likely it would happen again. And=20 > frankly, I do not see a strong argument in favor of two different encodin= gs. >=20 > Is there anyone who has a technical argument against supporting only=20 > one encoding, being that either xml or json? >=20 > Most people speak in favor of JSON, because it is compact and more=20 > efficient. I went through this thread and I saw 2 objections against=20 > picking JSON. One said that JSON requires native Java, which is wrong,=20 > the other objection gave no real reason. So I am wondering if there is=20 > really any valid technical reason against using JSON only? >=20 > - Gabor >=20 >=20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of ext Rosen, Brian > Sent: Friday, August 24, 2012 10:43 AM > To: Benjamin A. Rolfe > Cc: paws@ietf.org > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > Okay: >=20 > So, I implement a database, and I implement XML > You implement a device, and you implement JSON >=20 > You query my database (let's not get into how you do that query=20 > without deciding XML vs JSON) and discover I implement XML only >=20 > What do you do? >=20 > Brian >=20 > On Aug 24, 2012, at 1:38 PM, "Benjamin A. Rolfe" > wrote: >=20 >=20 >=20 >=20 > 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=20 > that any device implement every option. It works. >=20 > That said, I think (A) is the best choice, (B) is not as nice for me,=20 > and (C) is more work than either of the other two. >=20 >=20 >=20 >=20 > One is that one end implements both choices and the other end=20 > implements one or both. >=20 > The other is that both ends implement one specific choice ("MUST > implement") and both can optionally implement the other choice. Only=20 > if both ends implement the other choice would that be available. >=20 > 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=20 > implement the other (say JSON) >=20 > You are advocating for A, Richard was suggesting B. >=20 > I don't care, but choice C) Both databases and devices have a choice=20 > of what to implement doesn't work for me (or Richard). >=20 > Brian >=20 > On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe > wrote: >=20 >=20 > Apparently I was unclear. I certainly an capable of being wrong as I=20 > practice often, but in this case it is quite unlikely :-). >=20 > 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-=20 > offs. This is *preferable* from my perspective. >=20 > If you provide more than one form in the database, devices using the=20 > database need some means for figuring out which are available. It=20 > can't use it if it doesn't no about it. This is an observations, not=20 > an argument ;-). >=20 > It is my *opinion* at the moment that if you provide options, to=20 > make those useful you need to provide a protocol by which devices can=20 > discover what options the database supports. If you have such a=20 > mechanism and all devices use it (a bootstrap protocol), everything=20 > else could be options. This requires additional functions in both=20 > database and device implementations. > If on the other hand the device can "just know" that the database has=20 > two forms available, it won't need to dynamically figure it out. > The device implementer has options and simplicity, so I like it. >=20 > Since I am focused on the TVWS devices that need access to the=20 > database, and not a database implementer, shifting burden onto the=20 > database implementer (not me) to reduce the burden on the device=20 > implementer (me) is preferred from my perspective. The database=20 > implementer may have another perspective. Should I point out that=20 > there will be a lot more devices than databases? That might sound=20 > like an argument, though, so I won't....:-j >=20 > Ben >=20 >=20 >=20 > Brian is right .. sorry but the rest of you are wrong. J >=20 > This is why you have MUST and SHOULD in RFC 2119. >=20 > This BTW is a classic argument in IETF terms .. but the argument "let=20 > the market decide" only holds so much validity. You actually have to=20 > choose SOMETHING to create a baseline of interoperability. >=20 > A virtually identical argument is now playing out in discussions of=20 > mandatory audio and codec implementations for WEBRTC like things. >=20 > IMHO XML MUST anything else defined SHOULD, but MUST on XML and JSON=20 > could work as well. It just leads to a level of complexity in=20 > implementations. >=20 > End of argument you now can go back to your regularly schedule=20 > programming. J >=20 >=20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of Basavaraj.Patil@nokia.com > Sent: Thursday, August 23, 2012 5:44 PM > To: Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com > Cc: paws@ietf.org > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 >=20 > I agree with Brian. > There needs to be a default mandatory to implement option in order to=20 > achieve interoperability. > And this applies to the device and database side of the protocol. >=20 > -Raj >=20 > From: "", "Brian.Rosen@neustar.biz" > Date: Thursday, August 23, 2012 2:43 PM To: > Don Joslyn Cc: "paws@ietf.org" > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > One of my favorite IETF expressions is "There are no protocol=20 > police". We apply that in lots of ways, but one of them is that if=20 > you don't implement what the document says, you may not get=20 > interoperability with other implementations. On the other hand, the=20 > whole point of a protocol document like ours is that two independent=20 > implementations who both follow the document will interwork. If that=20 > wasn't true, why do you need a standard? >=20 > If you say "either" to both ends, then you don't get interoperability. >=20 > By your argument, we should stop working, and the product managers=20 > will figure it out using proprietary protocols. The market will decide. >=20 > So, I feel strongly that if one end is "either", the other end must=20 > be "both". It's also acceptable to say both ends implement one choice=20 > and the other is optional at both ends. Here, I think it's server=20 > does both and client does either. >=20 > It's always possible to build an implementation of a server that only=20 > does one: there are no protocol police. >=20 > Brian >=20 >=20 >=20 >=20 > On Aug 23, 2012, at 3:11 PM, Don Joslyn > wrote: >=20 >=20 >=20 >=20 > Hi Ben, That was my original suggestion, and I still think it makes > the most sense. Thanks for supporting the proposal. Don >=20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of Benjamin A. Rolfe > Sent: Thursday, August 23, 2012 3:05 PM > To: paws@ietf.org > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > Someone suggested that PAWS define both, and let the vendors decide=20 > 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=20 > do what fits the market segment they're after. Why over-constrain (or=20 > argue when natural selection will take care of it for us?). > B >=20 >=20 >=20 >=20 > Sounds good to me. >=20 > From: paws-bounces@ietf.org =20 > [mailto:paws-bounces@ietf.org ] On=20 > Behalf Of Gabor.Bajko@nokia.com > Sent: Tuesday, August 21, 2012 12:42 AM > To: paws@ietf.org > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > 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? >=20 > Gabor >=20 >=20 > From: paws-bounces@ietf.org =20 > [mailto:paws-bounces@ietf.org ] On=20 > Behalf Of ext Das, Subir > Sent: Monday, August 20, 2012 2:50 PM > To: Don Joslyn; Vincent Chen; Weixinpeng > Cc: paws@ietf.org ; Manikkoth Sajeev > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > We have a half a dozen or more TVDB radio vendors that use/prefer=20 > JSON and we will vote for JSON if we had to pick one. > Also I will copy the following two important points: >=20 >=20 > * 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 >=20 >=20 >=20 >=20 > From: paws-bounces@ietf.org =20 > [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 ; Manikkoth Sajeev > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > Please see my comments below... > Thanks, > Don >=20 > From: paws-bounces@ietf.org =20 > [mailto:paws-bounces@ietf.org ] On=20 > Behalf Of Vincent Chen > Sent: Monday, August 20, 2012 2:56 PM > To: Weixinpeng > Cc: paws@ietf.org ; Manikkoth Sajeev > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 >=20 > * One of our goals is to strive to lower the cost and > complexity for device manufacturers. This lowers the barrier for=20 > building a robust ecosystem. >=20 > [DJ - The "cost" and complexity of using XML has not been an issue=20 > for the half dozen TVBD vendors that have already used XML. Maybe we=20 > need to better define "cost"?] >=20 > * To reduce complexity and cost for device makers, supporting > 1 encoding is better than both, as Brian points out. WiFi access=20 > points that "just work" anywhere in the world serves as a good model. >=20 > [DJ - I proposed that the databases support both XML and JSON,=20 > devices only need to support one to talk to the database. Our current=20 > database supports XML and JSON, but if I'm forced to pick only one,=20 > then I will vote for XML because it's the one that we currently use on=20 > all embedded devices.] >=20 > * There's a trend for APIs on the web towards JSON (Twitter, > FourSquare, Facebook, Google, etc.). One of the major reasons is that=20 > developers (client-side) prefer it for its simplicity: >=20 > * 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. >=20 > Apparently, the efficiency gains of JSON also matter to the=20 > scalability of serving systems. >=20 >=20 > [DJ - I can't argue against these listed pros for JSON, especially=20 > when you're dealing with a lot of data (like Twitter, FourSquare,=20 > Facebook and Google does). But I'm assuming that PAWS messages will=20 > not be exchanged nearly as often as the applications mentioned above. > But again, I know JSON is more efficient, can't argue with that.] >=20 > * 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=20 > JSON, as long as we're clear on what device makers want. It would be=20 > good to get feedback from device makers (especially of embedded > devices) regarding experiences supporting XML vs JSON. >=20 >=20 >=20 > Don, can you elaborate on the types of devices that already support XML? >=20 >=20 >=20 > [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=20 > amount of data that needs to be exchanged between device and database=20 > is not that much or exchanged that often.] >=20 > On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > wrote: Considering of the design of > database discovery protocol, the LoST protocol may be used and LoST is=20 > based on XML, so I think XML may be preferred. >=20 > --Xinpeng Wei >=20 > From: paws-bounces@ietf.org =20 > [mailto:paws-bounces@ietf.org ] On=20 > Behalf Of Rosen, Brian >=20 > Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; > gabor.bajko@nokia.com ;=20 > vchen@google.com ; peter@spectrumbridge.com=20 > >=20 > Cc: paws@ietf.org > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > I don't really care whether we use json or xml as a matter of=20 > protocol design or implementation, but I am a big fan of reusing=20 > standards rather than defining new ones, and I would not want to see=20 > the choice of json mean we then decide to roll our own versus using=20 > existing standards based on the idea there is no json representation=20 > of an existing standard. So, if choosing json means folks feel free=20 > to ignore existing xml based standards such as xCard and LoST, then I=20 > would not want to use json. >=20 > I would prefer to not have "both", because of interoperability=20 > complications. If there is rough consensus for both, then I would=20 > assert that all servers have to implement both and the client can=20 > implement either. >=20 > There are json validators, so I don't think that is a big deal. >=20 > My experience in protocol design on the Internet is that decisions=20 > made solely or even largely because of compactness advantages rarely=20 > are good choices. If you like json because it is smaller, then I=20 > believe you need a much better reason. Binary doesn't work for me, at=20 > all. I have been involved in big binary vs text wars in protocol=20 > design. Text wins, binary loses, in my opinion. >=20 > Brian >=20 > From: Manikkoth Sajeev > > Reply-To: Manikkoth Sajeev > > Date: Thu, 16 Aug 2012 22:37:38 -0400 > To: "Gabor.Bajko@nokia.com " > >, "Rosen, Brian" > >,=20 > "vchen@google.com " >, "peter@spectrumbridge.com=20 > " > > Cc: "paws@ietf.org " > > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > Hi, >=20 > 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,=20 > easy to understand and validate. For compactness may be a binary xml=20 > optioncan also work. JSON I think will necessitate implementation to=20 > be native Java and may not be as friendly with other implementation=20 > languages. >=20 > Best Regards, >=20 > Sajeev Manikkoth Mobile: +918792292002 Email: > mksaji@ieee.org > http://www.linkedin.com/in/mksajeev > >=20 >=20 > From: "Gabor.Bajko@nokia.com " > > To: > Brian.Rosen@neustar.biz ;=20 > vchen@google.com ; peter@spectrumbridge.com > Cc: paws@ietf.org > Sent: Friday, 17 August 2012, 4:55 Subject: Re: > [paws] XML schema versus JSON, vCard & iCal >=20 >=20 > We have not heard any objections for using JSON encoding instead of > XML. Therefore, let's go for JSON, and close this thread. >=20 > - Gabor >=20 > -----Original Message----- > From: paws-bounces@ietf.org =20 > [mailto:paws-bounces@ietf.org ] On=20 > Behalf Of ext Rosen, Brian > Sent: Monday, August 13, 2012 3:14 PM > To: 'Vincent Chen'; 'Peter Stanforth' > Cc: 'paws@ietf.org ' > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > json is okay with me. > I'd prefer an ISO time stamp rather than a time in seconds since=20 > epoch. It's very easy to parse, and its simpler to use and debug. > Don't care a whole lot about that >=20 > Brian >=20 >=20 >=20 > -----Original Message----- From: Vincent Chen > [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 > Subject: Re: [paws] XML schema versus JSON, > vCard & iCal >=20 > XML vs JSON >=20 > Between XML and JSON, JSON messages are more compact and easier to=20 > process (parsing, synthesis). As clarification, JSON does not require=20 > JavaScript or a Browser. It is a text-based representation of data=20 > that is language independent, yet well-matched to all major languages. > JSON-handling libraries exist for numerous languages (see of=20 > http://json.org/ ) and seem to be reasonably light=20 > weight. >=20 > Timestamps >=20 > As for timestamp specifications, should we consider just using=20 > seconds since the UNIX Epoch (1970-01-01T00:00:00Z)? This would=20 > eliminate the need for datetime-string parsing on devices, assuming=20 > devices already have native libraries that provide time in this format. > Is that a valid assumption? Of course, this is less human-readable.... >=20 >=20 > On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth=20 > > wrote: >=20 >=20 > 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. >=20 > On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" >=20 > > wrote: >=20 > >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) > =20 > > > > -----Original Message----- >From: Peter > Stanforth [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 >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" > 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" =20 > >>>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 =20 > >>message exchange, I think. This may be of importance when using=20 > >>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 >>> =20 > >>> >>>> We had a discussion on XML vs. JSON. I prefer the one=20 > >>> 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 > >>>> =20 > >>>> On valid times: can we use same format as certificates? They have =09 > >>>>similar simple requirements: valid notBefore& notAfter. =20 > >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5 > >>>> >>>> > Teco >>>> _______________________________________________ >>>> > paws mailing list >>>> paws@ietf.org =20 > >>>> https://www.ietf.org/mailman/listinfo/paws > >>>> >>> >>> > _______________________________________________ >>> paws mailing > list >>> paws@ietf.org >>> > https://www.ietf.org/mailman/listinfo/paws > >> =20 > >>_______________________________________________ >>paws mailing > list >>paws@ietf.org =20 > >>https://www.ietf.org/mailman/listinfo/paws > > =20 > >_______________________________________________ >paws mailing list > >paws@ietf.org =20 > >https://www.ietf.org/mailman/listinfo/paws > >=20 > _______________________________________________ paws mailing From Gabor.Bajko@nokia.com Fri Aug 24 14:49:53 2012 Return-Path: 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 9A69321F85FC for ; Fri, 24 Aug 2012 14:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, 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 vAT9Zm6xS5FW for ; Fri, 24 Aug 2012 14:49:51 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id CAA1E21F8619 for ; Fri, 24 Aug 2012 14:49:50 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7OLni2V029611; Sat, 25 Aug 2012 00:49:44 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 25 Aug 2012 00:49:43 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0283.004; Fri, 24 Aug 2012 23:49:42 +0200 From: To: , , Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Ie7Nd2WNzPm0+85/tpR52R7QAAU/5DAJlUv6AAAo7YAAAWoncAABh1noAAifZJAAAEHtqAAAHwqAAAEnPn8ACBGaEA///sjQCAAAG0gIAACReAgAAhcYCAASYgAIAAHGCAgAADSYCAAAgwgIAAAR6A///OdSCAAFSdAIAAANCAgAAWcoD//9WW4A== Date: Fri, 24 Aug 2012 21:49:41 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB7824@008-AM1MPN1-006.mgdnok.nokia.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE716E2877C@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E2877C@dfweml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.113.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Aug 2012 21:49:44.0000 (UTC) FILETIME=[5F2F4C00:01CD8242] X-Nokia-AV: Clean Cc: paws@ietf.org 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 21:49:53 -0000 My understanding is different. How I interpret the text is that if we choos= e JSON only, we shall not say later on that we are not going to make use Lo= ST, or xCard, or other protocols just because they are not encoded using JS= ON encoding. We could either specify a JSON encoding (convert xml) for those protocols, = or some suggested in the F2F that we could embed xml into JSON. However, th= is latter to me means that we have to support then both JSON and XML.=20 - Gabor -----Original Message----- From: ext Peter McCann [mailto:Peter.McCann@huawei.com]=20 Sent: Friday, August 24, 2012 2:12 PM To: Patil Basavaraj (Nokia-CIC/Dallas); Brian.Rosen@neustar.biz; Bajko Gabo= r (Nokia-CIC/SiliconValley) Cc: paws@ietf.org Subject: RE: [paws] XML schema versus JSON, vCard & iCal I think you are mis-representing Brian's point of view. I share his concer= n about re-inventing encodings for LoST/xCard. -Pete Basavaraj.Patil@nokia.com wrote: >=20 > +1 to Brian's view on using JSON only. >=20 > From: "", "Brian.Rosen@neustar.biz"=20 > > Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko=20 > Cc: "paws@ietf.org" Subject: Re: > [paws] XML schema versus JSON, vCard & iCal >=20 >=20 > The problem we face with JSON only is the LoST/xCard/... issue. As=20 > long as there is no objection to creating JSON encodings of existing=20 > standards in order to use JSON, and no one uses the fact that these=20 > encodings don't exist as a reason to roll our own equivalents, I am=20 > okay with JSON only. >=20 > Brian >=20 > On Aug 24, 2012, at 3:08 PM, Gabor.Bajko@nokia.com wrote: >=20 >=20 > WiFi world builds on mandating the implementation (and > certification) of a base spec, and a set of optional features. If an=20 > optional feature is not supported by one of the peers, they can still=20 > talk, but not use that feature. That is basically option B) from=20 > Brain's list. >=20 > I'd like to suggest that we recognize that option A) and B) are valid=20 > 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=20 > both the master devices and DBs support one and the same encoding ;) >=20 > Option A) seems to be like a good compromise, and would cut=20 > discussions short, with the only caveat that if there is no strong=20 > technical argument for supporting and specifying two different=20 > encodings, then the iesg may send the document back to the wg to pick=20 > one of the two specified. As Robert mentioned in his email, this has=20 > happened in the past, so it is likely it would happen again. And=20 > frankly, I do not see a strong argument in favor of two different encodin= gs. >=20 > Is there anyone who has a technical argument against supporting only=20 > one encoding, being that either xml or json? >=20 > Most people speak in favor of JSON, because it is compact and more=20 > efficient. I went through this thread and I saw 2 objections against=20 > picking JSON. One said that JSON requires native Java, which is wrong,=20 > the other objection gave no real reason. So I am wondering if there is=20 > really any valid technical reason against using JSON only? >=20 > - Gabor >=20 >=20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of ext Rosen, Brian > Sent: Friday, August 24, 2012 10:43 AM > To: Benjamin A. Rolfe > Cc: paws@ietf.org > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > Okay: >=20 > So, I implement a database, and I implement XML > You implement a device, and you implement JSON >=20 > You query my database (let's not get into how you do that query=20 > without deciding XML vs JSON) and discover I implement XML only >=20 > What do you do? >=20 > Brian >=20 > On Aug 24, 2012, at 1:38 PM, "Benjamin A. Rolfe" > wrote: >=20 >=20 >=20 >=20 > 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=20 > that any device implement every option. It works. >=20 > That said, I think (A) is the best choice, (B) is not as nice for me,=20 > and (C) is more work than either of the other two. >=20 >=20 >=20 >=20 > One is that one end implements both choices and the other end=20 > implements one or both. >=20 > The other is that both ends implement one specific choice ("MUST > implement") and both can optionally implement the other choice. Only=20 > if both ends implement the other choice would that be available. >=20 > 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=20 > implement the other (say JSON) >=20 > You are advocating for A, Richard was suggesting B. >=20 > I don't care, but choice C) Both databases and devices have a choice=20 > of what to implement doesn't work for me (or Richard). >=20 > Brian >=20 > On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe > wrote: >=20 >=20 > Apparently I was unclear. I certainly an capable of being wrong as I=20 > practice often, but in this case it is quite unlikely :-). >=20 > 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-=20 > offs. This is *preferable* from my perspective. >=20 > If you provide more than one form in the database, devices using the=20 > database need some means for figuring out which are available. It=20 > can't use it if it doesn't no about it. This is an observations, not=20 > an argument ;-). >=20 > It is my *opinion* at the moment that if you provide options, to=20 > make those useful you need to provide a protocol by which devices can=20 > discover what options the database supports. If you have such a=20 > mechanism and all devices use it (a bootstrap protocol), everything=20 > else could be options. This requires additional functions in both=20 > database and device implementations. > If on the other hand the device can "just know" that the database has=20 > two forms available, it won't need to dynamically figure it out. > The device implementer has options and simplicity, so I like it. >=20 > Since I am focused on the TVWS devices that need access to the=20 > database, and not a database implementer, shifting burden onto the=20 > database implementer (not me) to reduce the burden on the device=20 > implementer (me) is preferred from my perspective. The database=20 > implementer may have another perspective. Should I point out that=20 > there will be a lot more devices than databases? That might sound=20 > like an argument, though, so I won't....:-j >=20 > Ben >=20 >=20 >=20 > Brian is right .. sorry but the rest of you are wrong. J >=20 > This is why you have MUST and SHOULD in RFC 2119. >=20 > This BTW is a classic argument in IETF terms .. but the argument "let=20 > the market decide" only holds so much validity. You actually have to=20 > choose SOMETHING to create a baseline of interoperability. >=20 > A virtually identical argument is now playing out in discussions of=20 > mandatory audio and codec implementations for WEBRTC like things. >=20 > IMHO XML MUST anything else defined SHOULD, but MUST on XML and JSON=20 > could work as well. It just leads to a level of complexity in=20 > implementations. >=20 > End of argument you now can go back to your regularly schedule=20 > programming. J >=20 >=20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of Basavaraj.Patil@nokia.com > Sent: Thursday, August 23, 2012 5:44 PM > To: Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com > Cc: paws@ietf.org > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 >=20 > I agree with Brian. > There needs to be a default mandatory to implement option in order to=20 > achieve interoperability. > And this applies to the device and database side of the protocol. >=20 > -Raj >=20 > From: "", "Brian.Rosen@neustar.biz" > Date: Thursday, August 23, 2012 2:43 PM To: > Don Joslyn Cc: "paws@ietf.org" > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > One of my favorite IETF expressions is "There are no protocol=20 > police". We apply that in lots of ways, but one of them is that if=20 > you don't implement what the document says, you may not get=20 > interoperability with other implementations. On the other hand, the=20 > whole point of a protocol document like ours is that two independent=20 > implementations who both follow the document will interwork. If that=20 > wasn't true, why do you need a standard? >=20 > If you say "either" to both ends, then you don't get interoperability. >=20 > By your argument, we should stop working, and the product managers=20 > will figure it out using proprietary protocols. The market will decide. >=20 > So, I feel strongly that if one end is "either", the other end must=20 > be "both". It's also acceptable to say both ends implement one choice=20 > and the other is optional at both ends. Here, I think it's server=20 > does both and client does either. >=20 > It's always possible to build an implementation of a server that only=20 > does one: there are no protocol police. >=20 > Brian >=20 >=20 >=20 >=20 > On Aug 23, 2012, at 3:11 PM, Don Joslyn > wrote: >=20 >=20 >=20 >=20 > Hi Ben, That was my original suggestion, and I still think it makes > the most sense. Thanks for supporting the proposal. Don >=20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of Benjamin A. Rolfe > Sent: Thursday, August 23, 2012 3:05 PM > To: paws@ietf.org > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > Someone suggested that PAWS define both, and let the vendors decide=20 > 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=20 > do what fits the market segment they're after. Why over-constrain (or=20 > argue when natural selection will take care of it for us?). > B >=20 >=20 >=20 >=20 > Sounds good to me. >=20 > From: paws-bounces@ietf.org =20 > [mailto:paws-bounces@ietf.org ] On=20 > Behalf Of Gabor.Bajko@nokia.com > Sent: Tuesday, August 21, 2012 12:42 AM > To: paws@ietf.org > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > 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? >=20 > Gabor >=20 >=20 > From: paws-bounces@ietf.org =20 > [mailto:paws-bounces@ietf.org ] On=20 > Behalf Of ext Das, Subir > Sent: Monday, August 20, 2012 2:50 PM > To: Don Joslyn; Vincent Chen; Weixinpeng > Cc: paws@ietf.org ; Manikkoth Sajeev > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > We have a half a dozen or more TVDB radio vendors that use/prefer=20 > JSON and we will vote for JSON if we had to pick one. > Also I will copy the following two important points: >=20 >=20 > * 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 >=20 >=20 >=20 >=20 > From: paws-bounces@ietf.org =20 > [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 ; Manikkoth Sajeev > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > Please see my comments below... > Thanks, > Don >=20 > From: paws-bounces@ietf.org =20 > [mailto:paws-bounces@ietf.org ] On=20 > Behalf Of Vincent Chen > Sent: Monday, August 20, 2012 2:56 PM > To: Weixinpeng > Cc: paws@ietf.org ; Manikkoth Sajeev > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 >=20 > * One of our goals is to strive to lower the cost and > complexity for device manufacturers. This lowers the barrier for=20 > building a robust ecosystem. >=20 > [DJ - The "cost" and complexity of using XML has not been an issue=20 > for the half dozen TVBD vendors that have already used XML. Maybe we=20 > need to better define "cost"?] >=20 > * To reduce complexity and cost for device makers, supporting > 1 encoding is better than both, as Brian points out. WiFi access=20 > points that "just work" anywhere in the world serves as a good model. >=20 > [DJ - I proposed that the databases support both XML and JSON,=20 > devices only need to support one to talk to the database. Our current=20 > database supports XML and JSON, but if I'm forced to pick only one,=20 > then I will vote for XML because it's the one that we currently use on=20 > all embedded devices.] >=20 > * There's a trend for APIs on the web towards JSON (Twitter, > FourSquare, Facebook, Google, etc.). One of the major reasons is that=20 > developers (client-side) prefer it for its simplicity: >=20 > * 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. >=20 > Apparently, the efficiency gains of JSON also matter to the=20 > scalability of serving systems. >=20 >=20 > [DJ - I can't argue against these listed pros for JSON, especially=20 > when you're dealing with a lot of data (like Twitter, FourSquare,=20 > Facebook and Google does). But I'm assuming that PAWS messages will=20 > not be exchanged nearly as often as the applications mentioned above. > But again, I know JSON is more efficient, can't argue with that.] >=20 > * 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=20 > JSON, as long as we're clear on what device makers want. It would be=20 > good to get feedback from device makers (especially of embedded > devices) regarding experiences supporting XML vs JSON. >=20 >=20 >=20 > Don, can you elaborate on the types of devices that already support XML? >=20 >=20 >=20 > [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=20 > amount of data that needs to be exchanged between device and database=20 > is not that much or exchanged that often.] >=20 > On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > wrote: Considering of the design of > database discovery protocol, the LoST protocol may be used and LoST is=20 > based on XML, so I think XML may be preferred. >=20 > --Xinpeng Wei >=20 > From: paws-bounces@ietf.org =20 > [mailto:paws-bounces@ietf.org ] On=20 > Behalf Of Rosen, Brian >=20 > Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; > gabor.bajko@nokia.com ;=20 > vchen@google.com ; peter@spectrumbridge.com=20 > >=20 > Cc: paws@ietf.org > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > I don't really care whether we use json or xml as a matter of=20 > protocol design or implementation, but I am a big fan of reusing=20 > standards rather than defining new ones, and I would not want to see=20 > the choice of json mean we then decide to roll our own versus using=20 > existing standards based on the idea there is no json representation=20 > of an existing standard. So, if choosing json means folks feel free=20 > to ignore existing xml based standards such as xCard and LoST, then I=20 > would not want to use json. >=20 > I would prefer to not have "both", because of interoperability=20 > complications. If there is rough consensus for both, then I would=20 > assert that all servers have to implement both and the client can=20 > implement either. >=20 > There are json validators, so I don't think that is a big deal. >=20 > My experience in protocol design on the Internet is that decisions=20 > made solely or even largely because of compactness advantages rarely=20 > are good choices. If you like json because it is smaller, then I=20 > believe you need a much better reason. Binary doesn't work for me, at=20 > all. I have been involved in big binary vs text wars in protocol=20 > design. Text wins, binary loses, in my opinion. >=20 > Brian >=20 > From: Manikkoth Sajeev > > Reply-To: Manikkoth Sajeev > > Date: Thu, 16 Aug 2012 22:37:38 -0400 > To: "Gabor.Bajko@nokia.com " > >, "Rosen, Brian" > >,=20 > "vchen@google.com " >, "peter@spectrumbridge.com=20 > " > > Cc: "paws@ietf.org " > > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > Hi, >=20 > 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,=20 > easy to understand and validate. For compactness may be a binary xml=20 > optioncan also work. JSON I think will necessitate implementation to=20 > be native Java and may not be as friendly with other implementation=20 > languages. >=20 > Best Regards, >=20 > Sajeev Manikkoth Mobile: +918792292002 Email: > mksaji@ieee.org > http://www.linkedin.com/in/mksajeev > >=20 >=20 > From: "Gabor.Bajko@nokia.com " > > To: > Brian.Rosen@neustar.biz ;=20 > vchen@google.com ; peter@spectrumbridge.com > Cc: paws@ietf.org > Sent: Friday, 17 August 2012, 4:55 Subject: Re: > [paws] XML schema versus JSON, vCard & iCal >=20 >=20 > We have not heard any objections for using JSON encoding instead of > XML. Therefore, let's go for JSON, and close this thread. >=20 > - Gabor >=20 > -----Original Message----- > From: paws-bounces@ietf.org =20 > [mailto:paws-bounces@ietf.org ] On=20 > Behalf Of ext Rosen, Brian > Sent: Monday, August 13, 2012 3:14 PM > To: 'Vincent Chen'; 'Peter Stanforth' > Cc: 'paws@ietf.org ' > Subject: Re: [paws] XML schema versus JSON, vCard & iCal >=20 > json is okay with me. > I'd prefer an ISO time stamp rather than a time in seconds since=20 > epoch. It's very easy to parse, and its simpler to use and debug. > Don't care a whole lot about that >=20 > Brian >=20 >=20 >=20 > -----Original Message----- From: Vincent Chen > [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 > Subject: Re: [paws] XML schema versus JSON, > vCard & iCal >=20 > XML vs JSON >=20 > Between XML and JSON, JSON messages are more compact and easier to=20 > process (parsing, synthesis). As clarification, JSON does not require=20 > JavaScript or a Browser. It is a text-based representation of data=20 > that is language independent, yet well-matched to all major languages. > JSON-handling libraries exist for numerous languages (see of=20 > http://json.org/ ) and seem to be reasonably light=20 > weight. >=20 > Timestamps >=20 > As for timestamp specifications, should we consider just using=20 > seconds since the UNIX Epoch (1970-01-01T00:00:00Z)? This would=20 > eliminate the need for datetime-string parsing on devices, assuming=20 > devices already have native libraries that provide time in this format. > Is that a valid assumption? Of course, this is less human-readable.... >=20 >=20 > On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth=20 > > wrote: >=20 >=20 > 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. >=20 > On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" >=20 > > wrote: >=20 > >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) > =20 > > > > -----Original Message----- >From: Peter > Stanforth [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 >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" > 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" =20 > >>>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 =20 > >>message exchange, I think. This may be of importance when using=20 > >>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 >>> =20 > >>> >>>> We had a discussion on XML vs. JSON. I prefer the one=20 > >>> 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 > >>>> =20 > >>>> On valid times: can we use same format as certificates? They have =09 > >>>>similar simple requirements: valid notBefore& notAfter. =20 > >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5 > >>>> >>>> > Teco >>>> _______________________________________________ >>>> > paws mailing list >>>> paws@ietf.org =20 > >>>> https://www.ietf.org/mailman/listinfo/paws > >>>> >>> >>> > _______________________________________________ >>> paws mailing > list >>> paws@ietf.org >>> > https://www.ietf.org/mailman/listinfo/paws > >> =20 > >>_______________________________________________ >>paws mailing > list >>paws@ietf.org =20 > >>https://www.ietf.org/mailman/listinfo/paws > > =20 > >_______________________________________________ >paws mailing list > >paws@ietf.org =20 > >https://www.ietf.org/mailman/listinfo/paws > >=20 > _______________________________________________ paws mailing From Basavaraj.Patil@nokia.com Fri Aug 24 15:42:07 2012 Return-Path: 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 89AD421F8576 for ; Fri, 24 Aug 2012 15:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.003 X-Spam-Level: X-Spam-Status: No, score=-106.003 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 DlBPi3VFKsU3 for ; Fri, 24 Aug 2012 15:42:05 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id A4F9D21F8554 for ; Fri, 24 Aug 2012 15:42:04 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7OMfxIu030682; Sat, 25 Aug 2012 01:42:00 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 25 Aug 2012 01:41:58 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0283.004; Sat, 25 Aug 2012 00:41:57 +0200 From: To: , , Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Iej7JadvAx8UahySbuq9n2zQAAU/5DAJUxXAAABrI7AAAWoncAABh1noAAifZJAAAEHtqAAAHwqAAADmEvAACA/ioAAAG/7gAAADZkgAABIt+A///NtAD//meaQIADLqOAgAADSYCAAAgwgIAAAR6AgAAX74CAAAsjAP//rRSAgABqLoD//8WEgA== Date: Fri, 24 Aug 2012 22:41:56 +0000 Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E2877C@dfweml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [72.64.105.77] Content-Type: text/plain; charset="us-ascii" Content-ID: <21D7E41BB0697F4E8D2C7CF0870F4010@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Aug 2012 22:41:58.0674 (UTC) FILETIME=[AB989720:01CD8249] X-Nokia-AV: Clean Cc: paws@ietf.org 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 22:42:07 -0000 Pete,=20 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.=20 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" 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 wrote: >>=20 >> +1 to Brian's view on using JSON only. >>=20 >> From: "", "Brian.Rosen@neustar.biz" >> >> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko >> Cc: "paws@ietf.org" Subject: Re: >> [paws] XML schema versus JSON, vCard & iCal >>=20 >>=20 >> 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. >>=20 >> Brian >>=20 >> On Aug 24, 2012, at 3:08 PM, Gabor.Bajko@nokia.com wrote: >>=20 >>=20 >> 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. >>=20 >> 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 ;) >>=20 >> 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. >>=20 >> Is there anyone who has a technical argument against supporting only >> one encoding, being that either xml or json? >>=20 >> 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? >>=20 >> - Gabor >>=20 >>=20 >> From: 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 >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >>=20 >> Okay: >>=20 >> So, I implement a database, and I implement XML >> You implement a device, and you implement JSON >>=20 >> 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 >>=20 >> What do you do? >>=20 >> Brian >>=20 >> On Aug 24, 2012, at 1:38 PM, "Benjamin A. Rolfe" >> wrote: >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >>=20 >>=20 >> One is that one end implements both choices and the other end >> implements one or both. >>=20 >> 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. >>=20 >> 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) >>=20 >> You are advocating for A, Richard was suggesting B. >>=20 >> 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). >>=20 >> Brian >>=20 >> On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe >> wrote: >>=20 >>=20 >> Apparently I was unclear. I certainly an capable of being wrong as I >> practice often, but in this case it is quite unlikely :-). >>=20 >> 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. >>=20 >> 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 ;-). >>=20 >> 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. >>=20 >> 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 >>=20 >> Ben >>=20 >>=20 >>=20 >> Brian is right .. sorry but the rest of you are wrong. J >>=20 >> This is why you have MUST and SHOULD in RFC 2119. >>=20 >> 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. >>=20 >> A virtually identical argument is now playing out in discussions of >> mandatory audio and codec implementations for WEBRTC like things. >>=20 >> 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. >>=20 >> End of argument you now can go back to your regularly schedule >> programming. J >>=20 >>=20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of Basavaraj.Patil@nokia.com >> Sent: Thursday, August 23, 2012 5:44 PM >> To: Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com >> Cc: paws@ietf.org >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >>=20 >>=20 >> 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. >>=20 >> -Raj >>=20 >> From: "", "Brian.Rosen@neustar.biz" >> Date: Thursday, August 23, 2012 2:43 PM To: >> Don Joslyn Cc: "paws@ietf.org" >> Subject: Re: [paws] XML schema versus JSON, vCard & >>iCal >>=20 >> 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? >>=20 >> If you say "either" to both ends, then you don't get interoperability. >>=20 >> By your argument, we should stop working, and the product managers >> will figure it out using proprietary protocols. The market will decide. >>=20 >> 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. >>=20 >> It's always possible to build an implementation of a server that only >> does one: there are no protocol police. >>=20 >> Brian >>=20 >>=20 >>=20 >>=20 >> On Aug 23, 2012, at 3:11 PM, Don Joslyn >> wrote: >>=20 >>=20 >>=20 >>=20 >> Hi Ben, That was my original suggestion, and I still think it makes >> the most sense. Thanks for supporting the proposal. Don >>=20 >> From: 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 >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >>=20 >> 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 >>=20 >>=20 >>=20 >>=20 >> Sounds good to me. >>=20 >> From: paws-bounces@ietf.org >> [mailto:paws-bounces@ietf.org ] On >> Behalf Of Gabor.Bajko@nokia.com >> Sent: Tuesday, August 21, 2012 12:42 AM >> To: paws@ietf.org >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >>=20 >> 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? >>=20 >> Gabor >>=20 >>=20 >> From: 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 ; Manikkoth Sajeev >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >>=20 >> 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: >>=20 >>=20 >> * 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 >>=20 >>=20 >>=20 >>=20 >> From: paws-bounces@ietf.org >> [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 ; Manikkoth Sajeev >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >>=20 >> Please see my comments below... >> Thanks, >> Don >>=20 >> From: 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 ; Manikkoth Sajeev >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >>=20 >>=20 >> * 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. >>=20 >> [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"?] >>=20 >> * 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. >>=20 >> [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.] >>=20 >> * 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: >>=20 >> * 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. >>=20 >> Apparently, the efficiency gains of JSON also matter to the >> scalability of serving systems. >>=20 >>=20 >> [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.] >>=20 >> * 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. >>=20 >>=20 >>=20 >> Don, can you elaborate on the types of devices that already support >>XML? >>=20 >>=20 >>=20 >> [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.] >>=20 >> On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > > 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. >>=20 >> --Xinpeng Wei >>=20 >> From: paws-bounces@ietf.org >> [mailto:paws-bounces@ietf.org ] On >> Behalf Of Rosen, Brian >>=20 >> Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; >> gabor.bajko@nokia.com ; >> vchen@google.com ; peter@spectrumbridge.com >> >>=20 >> Cc: paws@ietf.org >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >>=20 >> 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. >>=20 >> 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. >>=20 >> There are json validators, so I don't think that is a big deal. >>=20 >> 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. >>=20 >> Brian >>=20 >> From: Manikkoth Sajeev > >> Reply-To: Manikkoth Sajeev > > >> Date: Thu, 16 Aug 2012 22:37:38 -0400 >> To: "Gabor.Bajko@nokia.com " >> >, "Rosen, Brian" >> >, >> "vchen@google.com " > >, "peter@spectrumbridge.com >> " > > >> Cc: "paws@ietf.org " > > >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >>=20 >> Hi, >>=20 >> 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. >>=20 >> Best Regards, >>=20 >> Sajeev Manikkoth Mobile: +918792292002 Email: >> mksaji@ieee.org >> http://www.linkedin.com/in/mksajeev >> >>=20 >>=20 >> From: "Gabor.Bajko@nokia.com " >> > To: >> Brian.Rosen@neustar.biz ; >> vchen@google.com ; peter@spectrumbridge.com >> Cc: paws@ietf.org >> Sent: Friday, 17 August 2012, 4:55 Subject: Re: >> [paws] XML schema versus JSON, vCard & iCal >>=20 >>=20 >> We have not heard any objections for using JSON encoding instead of >> XML. Therefore, let's go for JSON, and close this thread. >>=20 >> - Gabor >>=20 >> -----Original Message----- >> From: 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 ' >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >>=20 >> 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 >>=20 >> Brian >>=20 >>=20 >>=20 >> -----Original Message----- From: Vincent Chen >> [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 >> Subject: Re: [paws] XML schema versus JSON, >> vCard & iCal >>=20 >> XML vs JSON >>=20 >> 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/ ) and seem to be reasonably light >> weight. >>=20 >> Timestamps >>=20 >> 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.... >>=20 >>=20 >> On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth >> > wrote: >>=20 >>=20 >> 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. >>=20 >> On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" >>=20 >> > wrote: >>=20 >> >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) > =09 >> > > > -----Original Message----- >From: Peter >> Stanforth [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 >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" > 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" =09 >> >>>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 =09 >> >>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 >>> =09 >> >>> >>>> 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 >> >>>> =09 >> >>>> On valid times: can we use same format as certificates? They have = =09 >> >>>>similar simple requirements: valid notBefore& notAfter. =09 >> >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5 >> >>>> >>>> >> Teco >>>> _______________________________________________ >>>> >> paws mailing list >>>> paws@ietf.org =09 >> >>>> https://www.ietf.org/mailman/listinfo/paws >> >>>> >>> >>> >> _______________________________________________ >>> paws mailing >> list >>> paws@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/paws >> >> =09 >> >>_______________________________________________ >>paws mailing >> list >>paws@ietf.org =09 >> >>https://www.ietf.org/mailman/listinfo/paws >> > =09 >> >_______________________________________________ >paws mailing list >> >paws@ietf.org =09 >> >https://www.ietf.org/mailman/listinfo/paws >> >>=20 >> _______________________________________________ paws mailing > From mksaji@yahoo.com Fri Aug 24 20:14:05 2012 Return-Path: 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 7E3CD21F856C for ; Fri, 24 Aug 2012 20:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] 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 7flCURBCziHT for ; Fri, 24 Aug 2012 20:14:02 -0700 (PDT) Received: from nm40.bullet.mail.ne1.yahoo.com (nm40.bullet.mail.ne1.yahoo.com [98.138.229.33]) by ietfa.amsl.com (Postfix) with SMTP id 09B6F21F8554 for ; Fri, 24 Aug 2012 20:14:01 -0700 (PDT) Received: from [98.138.90.55] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 25 Aug 2012 03:13:58 -0000 Received: from [98.138.89.244] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 25 Aug 2012 03:13:58 -0000 Received: from [127.0.0.1] by omp1058.mail.ne1.yahoo.com with NNFMP; 25 Aug 2012 03:13:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 882902.49139.bm@omp1058.mail.ne1.yahoo.com Received: (qmail 25609 invoked by uid 60001); 25 Aug 2012 03:13:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345864438; bh=UE+M2YBpJNA7RFeS+yyNkjb8Al8E/MlUb+dfSEFTEY8=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=vSo3C5EYv+JUvcceo5Wzgs8NkiNTc9qdCz5fkQDYG3U4NEHWF0dTQyCUQg64HZ2Ey+s0+LUUPV/Y4hhyr1gDBK2+1Kp841xmtWKA2SNzoSJQkRqN3uPs1QZe12Dh035/wmxu1wu9P9uJwG5bQaXpbcLVhiKIL6R/wA1tut3XB9Q= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LgRR1T2qPFhGNuOinbVLgDcIDxRNaSlLrdjtO3mgE/FpCx7YwPKF+FAM3YGrtCki30UhOPbwg2O/6IsQFxHynLCU7PINrcbvBLIUJ0eu8v/JY2PEZEA9wL2uBXpG7eZUHSMj+JNHofF5rGTo8gW2Swx9rtrGoprYw57lYuE+90o=; X-YMail-OSG: qq6aplcVM1mo3U_m8lk7u1rXnAO6TTEy5Ef1jLPNYsOVJK5 kKv3jpP37I4HJotX4V5emax8TKNPrIJJINIeaVDG1tuASSqoJH4NuU92KNSB yUPLBBVbUTj5VQrvC2nFhUOHIb32KbFPrtQ5.YrTRyeTP9zctHZheelTJWuf 1y.vxSlS0MXBILgUF5k3hmbQwowbq79FFizmCxA3lz.wypH.gDZVuky4TlVp e4a8imsIvyDRGlS8st1rhrSvaBzEcUlKIaAeoVjUV_2oRrfGcBHt0CZaBvxx RabBp8FbNW0rd4kQ0aBTPhGcM9JKS9EwRoXPS.A2Euy3HaBhDdzgObfvtxTW jPfNL1vDNGPEGt_koEq.gGek9NQb41q2SnSPDP846D5vJ1g3oCLZ.9DwmMHO EWuoFgWziqcxjwwYNxiEzULPduyoK_DqL9RkHreWfsWLp73OvVeEurNUnRnY l9hUS_9uy7mQ6GEhgJQberbhqHkmkDgMpr29UIRUPn1Nrmyha9E5rBiJdB9M C0ZLNKfiSeJMpCRfOV6Q4_zG4JxG_MlxOS3cZ1i809H.5CuEwK3sfVb4AsVS I4ig9W9wXQQZ84PzP0ISyk60zGHUR_9aVphHa5Gu97.1D9nMvdvM- Received: from [117.192.27.184] by web120306.mail.ne1.yahoo.com via HTTP; Fri, 24 Aug 2012 20:13:58 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> <00c601cd820b$67b97170$372c5450$@us> <5037B28B.70501@blindcreek.com> <5D0B1E63-79FE-4BC6-A446-3470931D1043@neustar.biz> <5037BC2B.7010008@blindcreek.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724@008-AM1MPN1-006.mgdnok.nokia.com> Message-ID: <1345864438.6327.YahooMailNeo@web120306.mail.ne1.yahoo.com> Date: Fri, 24 Aug 2012 20:13:58 -0700 (PDT) From: Manikkoth Sajeev To: "Gabor.Bajko@nokia.com" , "Brian.Rosen@neustar.biz" , "ben@blindcreek.com" In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724@008-AM1MPN1-006.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="97335089-707218294-1345864438=:6327" Cc: "paws@ietf.org" Subject: Re: [paws] XML schema versus JSON, vCard & iCal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Manikkoth Sajeev List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 03:14:05 -0000 --97335089-707218294-1345864438=:6327 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=0A=C2=A0=0AI would still support XML. JSON libraries are available for = all languages. But interfacing and linking such libraries are problematic o= n embedded devices most of the time. And if an implementation vouch for mul= tiple such non native language libraries then developers life is hell...=0A= =0ABest Regards,=0A=C2=A0=0ASajeev Manikkoth=0A=0A =0A=0A__________________= ______________=0A From: "Gabor.Bajko@nokia.com" =0AT= o: Brian.Rosen@neustar.biz; ben@blindcreek.com =0ACc: paws@ietf.org =0ASent= : Saturday, 25 August 2012, 0:38=0ASubject: Re: [paws] XML schema versus JS= ON, vCard & iCal=0A =0A=0A =0AWiFi world builds on mandating the implement= ation (and certification) of a base spec, and a set of optional features. I= f 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=E2= =80=99s list. =0A=C2=A0 =0AI=E2=80=99d like to suggest that we recognize th= at option A) and B) are valid options, while option C) is invalid, and we s= hould stop debating it. =0AI=E2=80=99d also like to add the obvious option = D) to the list, which is that both the master devices and DBs support one a= nd the same encoding ;) =0A=C2=A0 =0AOption A) seems to be like a good comp= romise, and would cut discussions short, with the only caveat that if there= is no strong technical argument for supporting and specifying two differen= t 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 s= ee a strong argument in favor of two different encodings. =0A=C2=A0 =0AIs = there anyone who has a technical argument against supporting only one encod= ing, being that either xml or json? =0A=C2=A0 =0AMost people speak in favor= of JSON, because it is compact and more efficient. I went through this thr= ead and I saw 2 objections against picking JSON. One said that JSON require= s 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? =0A=C2=A0 =0A-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Gabor =0A=C2=A0 =0A=C2=A0 =0AFrom:paws-bounces@ietf.org [mailto:paws= -bounces@ietf.org] On Behalf Of ext Rosen, Brian=0ASent: Friday, August 24,= 2012 10:43 AM=0ATo: Benjamin A. Rolfe=0ACc: paws@ietf.org=0ASubject: Re: [= paws] XML schema versus JSON, vCard & iCal =0A=C2=A0 =0AOkay: =0A=C2=A0 = =0ASo, I implement a database, and I implement XML =0AYou implement a devi= ce, and you implement JSON =0A=C2=A0 =0AYou query my database (let's not = get into how you do that query without deciding XML vs JSON) and discover I= implement XML only =0A=C2=A0 =0AWhat do you do? =0A=C2=A0 =0ABrian = =0A=C2=A0 =0AOn Aug 24, 2012, at 1:38 PM, "Benjamin A. Rolfe" wrote: =0A=0A =0A=0A=0A =0AThere are two ways to achieve interope= rability when you have an option. =0AThere are many existence proofs of the= third way that I mentioned below.=0A802.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.=C2=A0 It works.= =C2=A0 =0A=0AThat 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.=0A=C2=A0=0A=0A = =0A=C2=A0 =0AOne is that one end implements both choices and the other end= implements one or both. =0A=C2=A0 =0AThe other is that both ends impleme= nt one specific choice ("MUST implement") and both can optionally implement= the other choice. =C2=A0Only if both ends implement the other choice would= that be available. =0A=C2=A0 =0ASo, in this case we could do one of the = following: =0AA) Databases implement both XML and JSON, devices implement = either =0AB) Both Databases and devices implement one (say XML) and option= ally implement the other (say JSON) =0A=C2=A0 =0AYou are advocating for A= , Richard was suggesting B. =0A=C2=A0 =0AI don't care, but choice C) Both= databases and devices have a choice of what to implement doesn't work for = me (or Richard). =0A=C2=A0 =0ABrian =0A=C2=A0 =0AOn Aug 24, 2012, at 12= :57 PM, Benjamin A. Rolfe wrote: =0A=0A =0AApparently= I was unclear.=C2=A0 I certainly an capable of being wrong as I practice o= ften, but in this case it is quite unlikely :-). =0A=0AYou do not need to c= hoose only one form to achieve interoperability.=C2=A0=C2=A0 If you have tw= o, let the device implementer figure out which is best for their particular= device requirements and trade-offs.=C2=A0 This is *preferable* from my per= spective.=0A=0AIf you provide more than one form in the database, devices u= sing 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 arg= ument ;-).=C2=A0=C2=A0 =0A=0AIt is my *opinion* at the=C2=A0 moment that if= you provide options, to make those useful you need to provide=C2=A0 a prot= ocol by which devices can discover what options the database supports.=C2= =A0 If you have such a mechanism and all devices use it (a=C2=A0 bootstrap = protocol),=0A everything else could be options.=C2=A0 This requires additio= nal functions in both database and device implementations. =0AIf on the oth= er hand the device can "just know" that the database has two forms availabl= e, it won't need to dynamically figure it out. The device implementer has o= ptions and simplicity, so I like it. =0A=0ASince I am focused on the TVWS d= evices that need access to the database, and not a database implementer, sh= ifting burden onto the database implementer (not me) to reduce the burden o= n the device implementer (me) is preferred from my perspective.=C2=A0 The d= atabase=0A implementer may have another perspective.=C2=A0 Should I point o= ut that there will be a lot more devices than databases?=C2=A0 That might s= ound like an argument, though, so I won't....:-j=0A=0ABen=0A=0A=0A =0ABrian= is right .. sorry but the rest of you are wrong. J =0A=C2=A0 =0AThis is w= hy you have MUST and SHOULD in RFC 2119. =C2=A0 =0A=C2=A0 =0AThis BTW is a= classic argument in IETF terms .. but the argument =E2=80=9Clet the market= decide=E2=80=9D only holds so much validity.=C2=A0 You actually have to ch= oose SOMETHING to create a baseline of interoperability. =0A=C2=A0 =0AA vi= rtually identical argument =C2=A0is now playing out in discussions of manda= tory audio and codec implementations for WEBRTC like things. =0A=C2=A0 =0A= 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. = =0A=C2=A0 =0AEnd of argument you now can go back to your regularly schedul= e programming. J =0A=C2=A0 =0A=C2=A0 =0AFrom:paws-bounces@ietf.org [mailt= o:paws-bounces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com=0ASent: Thu= rsday, August 23, 2012 5:44 PM=0ATo: Brian.Rosen@neustar.biz; d.joslyn@spec= trumbridge.com=0ACc: paws@ietf.org=0ASubject: Re: [paws] XML schema versus = JSON, vCard & iCal =0A=C2=A0 =0A=C2=A0 =0AI agree with Brian. =0AThere= needs to be a default mandatory to implement option in order to achieve in= teroperability.=C2=A0 =0AAnd this applies to the device and database side = of the protocol. =0A=C2=A0 =0A-Raj =0A=C2=A0 =0AFrom: "", = "Brian.Rosen@neustar.biz" =0ADate: Thursday, Augus= t 23, 2012 2:43 PM=0ATo: Don Joslyn =0ACc: "pa= ws@ietf.org" =0ASubject: Re: [paws] XML schema versus JSON, = vCard & iCal =0A=C2=A0 =0AOne of my favorite IETF expressions is "There = are no protocol police". =C2=A0We apply that in lots of ways, but one of th= em is that if you don't implement what the document says, you may not get i= nteroperability with other implementations. =C2=A0On the other hand, the wh= ole point of a protocol document like ours is that two independent implemen= tations who both follow the document will interwork. =C2=A0If that wasn't t= rue, why do you need a standard? =0A=C2=A0 =0AIf you say "either" to bot= h ends, then you don't get interoperability. =C2=A0 =0A=C2=A0 =0ABy your= argument, we should stop working, and the product managers will figure it = out using proprietary protocols. =C2=A0The market will decide. =0A=C2=A0 = =0ASo, I feel strongly that if one end is "either", the other end must be = "both". =C2=A0It's also acceptable to say both ends implement one choice an= d the other is optional at both ends. =C2=A0Here, I think it's server does = both and client does either.=C2=A0 =0A=C2=A0 =0AIt's always possible to = build an implementation of a server that only does one: there are no protoc= ol police. =0A=C2=A0 =0ABrian =0A=C2=A0 =0A=C2=A0 = =0A=C2=A0 =0A=C2=A0 =0AOn Aug 23, 2012, at 3:11 PM, Don Joslyn wrote: =0A=0A=0A =0AHi Ben, =0AThat was my original = suggestion, and I still think it makes the most sense. =0AThanks for suppo= rting the proposal. =0ADon =0A=C2=A0 =0AFrom:=C2=A0paws-bounces@ietf.org= [mailto:paws-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Benjamin A. Rolfe=0A= Sent:=C2=A0Thursday, August 23, 2012 3:05 PM=0ATo:=C2=A0paws@ietf.org=0ASub= ject:=C2=A0Re: [paws] XML schema versus JSON, vCard & iCal =0A=C2=A0 = =0ASomeone suggested that PAWS define both, and let the vendors decide whic= h ones to implement.=0AThat makes the most sense for both DB and device ven= dors.=C2=A0 Markets will probably drive DB vendors to do both. Device vendo= rs 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?).=0AB=0A=0A=0A= =0A =0ASounds good to me. =0A=C2=A0 =0AFrom:=C2=A0paws-bounces@ietf.org= =C2=A0[mailto:paws-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Gabor.Bajko@nok= ia.com=0ASent:=C2=A0Tuesday, August 21, 2012 12:42 AM=0ATo:=C2=A0paws@ietf.= org=0ASubject:=C2=A0Re: [paws] XML schema versus JSON, vCard & iCal =0A= =C2=A0 =0ANow I can=E2=80=99t see anymore any willingness to agree on one = or the other encoding. =0ATo prevent endless discussions on this topic I= =E2=80=99d suggest we move forward with supporting both in the DB and eithe= r one in the master device. =0AAny objections? =0A=C2=A0 =0AGabor =0A= =C2=A0 =0A=C2=A0 =0AFrom:=C2=A0paws-bounces@ietf.org=C2=A0[mailto:paws-bo= unces@ietf.org]=C2=A0On Behalf Of=C2=A0ext Das, Subir=0ASent:=C2=A0Monday, = August 20, 2012 2:50 PM=0ATo:=C2=A0Don Joslyn; Vincent Chen; Weixinpeng=0AC= c:=C2=A0paws@ietf.org; Manikkoth Sajeev=0ASubject:=C2=A0Re: [paws] XML sche= ma versus JSON, vCard & iCal =0A=C2=A0 =0AWe have a half a dozen or mor= e TVDB radio vendors that use/prefer JSON and we will vote for JSON if we h= ad to pick one. =0AAlso I will copy the following two important points: = =0A=C2=A0 =0A=09* Simple-to-use libraries exist for all major languages/pl= atforms=0A=09* Don't need a tool chain to work with the data, as is typical= ly needed for XML =0A=C2=A0 =0A=C2=A0 =0A=C2=A0 =0AFrom:=C2=A0paws-boun= ces@ietf.org=C2=A0[mailto:paws-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Don= Joslyn=0ASent:=C2=A0Monday, August 20, 2012 4:54 PM=0ATo:=C2=A0Vincent Che= n; Weixinpeng=0ACc:=C2=A0paws@ietf.org; Manikkoth Sajeev=0ASubject:=C2=A0Re= : [paws] XML schema versus JSON, vCard & iCal =0A=C2=A0 =0APlease see m= y comments below=E2=80=A6 =0AThanks, =0ADon =0A=C2=A0 =0AFrom:=C2=A0paw= s-bounces@ietf.org=C2=A0[mailto:paws-bounces@ietf.org]=C2=A0On Behalf Of=C2= =A0Vincent Chen=0ASent:=C2=A0Monday, August 20, 2012 2:56 PM=0ATo:=C2=A0Wei= xinpeng=0ACc:=C2=A0paws@ietf.org; Manikkoth Sajeev=0ASubject:=C2=A0Re: [paw= s] XML schema versus JSON, vCard & iCal =0A=C2=A0 =0A=09* One of our goa= ls is to strive to lower the cost and complexity for device manufacturers. = This lowers the barrier for building a robust ecosystem. =0A[DJ - The =E2= =80=9Ccost=E2=80=9D and complexity of using XML has not been an issue for t= he half dozen TVBD vendors that have already used XML. Maybe we need to bet= ter define =E2=80=9Ccost=E2=80=9D?] =0A=09* To reduce complexity and cost = for device makers, supporting 1 encoding is better than both, as Brian poin= ts out. WiFi access points that "just work" anywhere in the world serves as= a good model. =0A[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=E2=80=99m forced to pick only one= , then I will vote for XML because it=E2=80=99s the one that we currently u= se on all embedded devices.] =0A=09* There's a trend for APIs on the web t= owards JSON (Twitter, FourSquare, Facebook, Google, etc.). One of the major= reasons is that developers (client-side) prefer it for its simplicity: = =0A=09* Representation closely matches most data models (nested lists and m= aps)=0A=09* Simple-to-use libraries exist for all major languages/platforms= =0A=09* Don't need a tool chain to work with the data, as is typically need= ed for XML. =0AApparently, the efficiency gains of JSON also matter to the= scalability of serving systems. =0A=C2=A0 =0A[DJ =E2=80=93 I can=E2=80=99= t argue against these listed pros for JSON, especially when you=E2=80=99re = dealing with a lot of data (like Twitter, FourSquare, Facebook and Google d= oes). But I=E2=80=99m assuming that PAWS messages will not be exchanged nea= rly as often as the applications mentioned above. But again, I know JSON is= more efficient, can=E2=80=99t argue with that.] =0A=09* At the end of the= day, it's the data model that matters, rather than the encoding. We (Googl= e) are actually neutral on XML vs JSON, as long as we're clear on what devi= ce makers want. It would be good to get feedback from device makers (especi= ally of embedded devices) regarding experiences supporting XML vs JSON. =0A= =C2=A0 =0ADon, can you elaborate on the types of devices that already suppo= rt XML? =0A=C2=A0 =0A[DJ - We currently support half a dozen TVDB radio v= endors (embedded devices) using XML, non using JSON. XML has not been a bur= den, and the amount of data that needs to be exchanged between device and d= atabase is not that much or exchanged that often.] =0AOn Fri, Aug 17, 2012 = at 6:06 PM, Weixinpeng wrote: =0AConsidering of th= e design of database discovery protocol, the LoST protocol may be used and = LoST is based on XML, so I think XML may be preferred. =0A=C2=A0 =0A--Xin= peng Wei =0A=C2=A0 =0AFrom:=C2=A0paws-bounces@ietf.org=C2=A0[mailto:paws-= bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Rosen, Brian =0A=0ASent:=C2=A0Fri= day, August 17, 2012 9:26 PM =0ATo:=C2=A0Manikkoth Sajeev;=C2=A0gabor.baj= ko@nokia.com;=C2=A0vchen@google.com;=C2=A0peter@spectrumbridge.com =0A=0AC= c:=C2=A0paws@ietf.org=0ASubject:=C2=A0Re: [paws] XML schema versus JSON, vC= ard & iCal =0A=C2=A0 =0AI 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 re= using 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 existin= g standards based on the idea there is no json representation of an existin= g standard. =C2=A0So, if choosing json means folks feel free to ignore exis= ting xml based standards such as xCard and LoST, then I would not want to u= se json. =0A=C2=A0 =0AI would prefer to not have "both", because of int= eroperability complications. =C2=A0If there is rough consensus for both, th= en I would assert that all servers have to implement both and the client ca= n implement either. =0A=C2=A0 =0AThere are json validators, so I don't = think that is a big deal. =C2=A0 =0A=C2=A0 =0AMy experience in protocol= design on the Internet is that decisions made solely or even largely becau= se of compactness advantages rarely are good choices. =C2=A0If you like jso= n because it is smaller, then I believe you need a much better reason. =C2= =A0Binary doesn't work for me, at all. =C2=A0I have been involved in big bi= nary vs text wars in protocol design. =C2=A0Text wins, binary loses, in my = opinion. =0A=C2=A0 =0ABrian =0A=C2=A0 =0AFrom:=C2= =A0Manikkoth Sajeev =0AReply-To:=C2=A0Manikkoth Sajeev =0ADate:=C2=A0Thu, 16 Aug 2012 22:37:38 -0400=0ATo:=C2=A0"G= abor.Bajko@nokia.com" , "Rosen, Brian" , "vchen@google.com" , "peter@spectrumbridge.= com" =0ACc:=C2=A0"paws@ietf.org" = =0ASubject:=C2=A0Re: [paws] XML schema versus JSON, vCard & iCal =0A=C2= =A0 =0AHi, =0A=C2=A0 =0ACan it not be both JSON and XML supported? I = would vote for that. Future implementations may prefer=C2=A0XML as it is ge= neric,=C2=A0omni present, easy to understand and validate.=C2=A0For compact= ness may be a=C2=A0=C2=A0binary xml optioncan also work. JSON I think will = necessitate implementation to be native Java and may not be as friendly wit= h other implementation languages. =0A=C2=A0 =0ABest Regards, =0ASajee= v Manikkoth=0AMobile:=C2=A0+918792292002=0AEmail:=C2=A0mksaji@ieee.org=0Aht= tp://www.linkedin.com/in/mksajeev =0A=C2=A0 =0AFrom:=C2=A0"Gabor.Bajko@n= okia.com" =0ATo:=C2=A0Brian.Rosen@neustar.biz;=C2=A0= vchen@google.com;=C2=A0peter@spectrumbridge.com=C2=A0=0ACc:=C2=A0paws@ietf.= org=C2=A0=0ASent:=C2=A0Friday, 17 August 2012, 4:55=0ASubject:=C2=A0Re: [pa= ws] XML schema versus JSON, vCard & iCal =0A=0AWe have not heard any obje= ctions for using JSON encoding instead of XML.=C2=A0=0ATherefore, let's go = for JSON, and close this thread.=0A=0A- Gabor=0A=0A-----Original Message---= --=0AFrom:=C2=A0paws-bounces@ietf.org=C2=A0[mailto:paws-bounces@ietf.org] O= n Behalf Of ext Rosen, Brian=0ASent: Monday, August 13, 2012 3:14 PM=0ATo: = 'Vincent Chen'; 'Peter Stanforth'=0ACc: 'paws@ietf.org'=0ASubject: Re: [paw= s] XML schema versus JSON, vCard & iCal=0A=0Ajson is okay with me.=C2=A0=C2= =A0=0AI'd prefer an ISO time stamp rather than a time in seconds since epoc= h.=C2=A0 It's very easy to parse, and its simpler to use and debug.=C2=A0 D= on't care a whole lot about that=0A=0ABrian =0A=0A=0A=0A----= -Original Message-----=0AFrom: =C2=A0=C2=A0=C2=A0 Vincent Chen [mailto:vche= n@google.com]=0ASent:=C2=A0=C2=A0=C2=A0 Monday, August 13, 2012 06:04 PM Ea= stern Standard Time=0ATo:=C2=A0=C2=A0=C2=A0 Peter Stanforth=0ACc:=C2=A0=C2= =A0=C2=A0 Rosen, Brian; Teco Boot; Benjamin A.Rolfe;=C2=A0paws@ietf.org=0AS= ubject:=C2=A0=C2=A0=C2=A0 Re: [paws] XML schema versus JSON, vCard & iCal= =0A=0AXML vs JSON=0A=0ABetween XML and JSON, JSON messages are more compact= and easier to process (parsing, synthesis). As clarification, JSON does no= t require JavaScript or a Browser. It is a text-based representation of dat= a that is language independent, yet well-matched to all=0A major languages.= JSON-handling libraries exist for numerous languages (see of=C2=A0http://j= son.org/) and seem to be reasonably light weight.=0A=0ATimestamps=0A=0AAs f= or timestamp specifications, should we consider just using seconds since th= e UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for date= time-string parsing on devices, assuming devices already have native librar= ies that provide time in this=0A format. Is that a valid assumption? Of cou= rse, this is less human-readable....=0A=0A=0AOn Mon, Aug 13, 2012 at 6:49 A= M, Peter Stanforth wrote:=0A=0A=0A=C2=A0=C2=A0= =C2=A0 Whenever we built mobile devices we never dealt with IETF, in our se= nsor=0A=C2=A0=C2=A0=C2=A0 days even an IP stack was a challenge,so I would = defer to the device guys=0A=C2=A0=C2=A0=C2=A0 on that one.=0A=C2=A0=C2=A0= =C2=A0=C2=A0=0A=C2=A0=C2=A0=C2=A0 On MonAug/13/12 Mon Aug 13, 9:30 AM, "Ros= en, Brian"=0A=C2=A0=C2=A0=C2=A0=C2=A0=0A=C2=A0=C2=A0=C2=A0 wrote:=0A=C2=A0=C2=A0=C2=A0=C2=A0=0A=C2=A0=C2=A0=C2=A0 >Our exper= ience in the IETF over many years is that economizing message=0A=C2=A0=C2= =A0=C2=A0 >size and compromising utility and security in search of efficien= cy of=0A=C2=A0=C2=A0=C2=A0 >implementation on small devices is a poor trade= off.=C2=A0 I am not advocating=0A=C2=A0=C2=A0=C2=A0 >being wasteful of res= ources, but I don't think we should seriously=0A=C2=A0=C2=A0=C2=A0 >conside= r the overhead of XML or json to be significant.=0A=C2=A0=C2=A0=C2=A0 >=0A= =C2=A0=C2=A0=C2=A0 >Assuming a json library can be loaded on a small device= is reasonable.=0A=C2=A0=C2=A0=C2=A0 >=0A=C2=A0=C2=A0=C2=A0 >Brian (as indi= vidual)=0A=C2=A0=C2=A0=C2=A0 >=0A=C2=A0=C2=A0=C2=A0 >=0A=C2=A0=C2=A0=C2=A0 = >=0A=C2=A0=C2=A0=C2=A0 > -----Original Message-----=0A=C2=A0=C2=A0=C2=A0 >F= rom:=C2=A0 Peter Stanforth [mailto:peter@spectrumbridge.com]=0A=C2=A0=C2=A0= =C2=A0 >Sent:=C2=A0 Saturday, August 11, 2012 07:13 AM Eastern Standard Tim= e=0A=C2=A0=C2=A0=C2=A0 >To:=C2=A0 =C2=A0 Teco Boot; Benjamin A.Rolfe=0A=C2= =A0=C2=A0=C2=A0 >Cc:=C2=A0 =C2=A0=C2=A0paws@ietf.org=0A=C2=A0=C2=A0=C2=A0 >= Subject:=C2=A0 =C2=A0 =C2=A0 Re: [paws] XML schema versus JSON, vCard & iCa= l=0A=C2=A0=C2=A0=C2=A0 >=0A=C2=A0=C2=A0=C2=A0 >Not all masters run over the= core network.=0A=C2=A0=C2=A0=C2=A0 >Some of the Use cases have a master ta= lking to another OTA=0A=C2=A0=C2=A0=C2=A0 >We should not assume that all Ma= sters are attached to utility power so we=0A=C2=A0=C2=A0=C2=A0 >should be s= ympathetic to processing energy use also.=0A=C2=A0=C2=A0=C2=A0 >=0A=C2=A0= =C2=A0=C2=A0 >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" wrote:=0A=C2=A0=C2=A0=C2=A0 >=0A=C2=A0=C2=A0=C2=A0 >>=0A=C2=A0=C2=A0= =C2=A0 >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe het volgende=0A= =C2=A0=C2=A0=C2=A0 >>geschreven:=0A=C2=A0=C2=A0=C2=A0 >>=0A=C2=A0=C2=A0=C2= =A0 >>> Compactness of messages is important, but it is also important (to = me=0A=C2=A0=C2=A0=C2=A0 >>>at least) to be realizable in an implementation = with limited resources,=0A=C2=A0=C2=A0=C2=A0 >>>such as embedded devices in= what are now popularly called "M2M"=0A=C2=A0=C2=A0=C2=A0 >>>applications.= =C2=A0 A lot of these devices could use IP all the end to end,=0A=C2=A0=C2= =A0=C2=A0 >>>but may have a very compact, simple stack and applications (i.= e.=C2=A0 no=0A=C2=A0=C2=A0=C2=A0 >>>browser).=C2=A0 Is JSON typically imple= mented when there is no browser?=0A=C2=A0=C2=A0=C2=A0 >>>Would it be hard t= o do in a resource constrained device (i.e. where we=0A=C2=A0=C2=A0=C2=A0 >= >>talk about memory size in Kilo-bytes still).=0A=C2=A0=C2=A0=C2=A0 >>=0A= =C2=A0=C2=A0=C2=A0 >>In use cases and requirements document, there are no r= equirements for=0A=C2=A0=C2=A0=C2=A0 >>protocol performance. I guess OS/IP/= TCP/TLS code size supersedes needs=0A=C2=A0=C2=A0=C2=A0 >>for JSON or XML.= =0A=C2=A0=C2=A0=C2=A0 >>=0A=C2=A0=C2=A0=C2=A0 >>Same for timing: TCP/TLS co= nnection setup will take more than the PAWS=0A=C2=A0=C2=A0=C2=A0 >>message = exchange, I think. This may be of importance when using satcom=0A=C2=A0=C2= =A0=C2=A0 >>links.=0A=C2=A0=C2=A0=C2=A0 >>=0A=C2=A0=C2=A0=C2=A0 >>Because P= AWS runs between master and database, over core network,=0A=C2=A0=C2=A0=C2= =A0 >>performance is not our primary concern. But as always, it is good to = keep=0A=C2=A0=C2=A0=C2=A0 >>an eye on efficiency.=0A=C2=A0=C2=A0=C2=A0 >>= =0A=C2=A0=C2=A0=C2=A0 >>Teco=0A=C2=A0=C2=A0=C2=A0 >>=0A=C2=A0=C2=A0=C2=A0 >= >> Thanks=0A=C2=A0=C2=A0=C2=A0 >>> Ben=0A=C2=A0=C2=A0=C2=A0 >>>=0A=C2=A0=C2= =A0=C2=A0 >>>=0A=C2=A0=C2=A0=C2=A0 >>>> We had a discussion on XML vs. JSON= . I prefer the one with most=0A=C2=A0=C2=A0=C2=A0 >>>>compact messages.=0A= =C2=A0=C2=A0=C2=A0 >>>>=0A=C2=A0=C2=A0=C2=A0 >>>> On vCard and JSON: what i= s the status of "A JavaScript Object Notation=0A=C2=A0=C2=A0=C2=A0 >>>>(JSO= N) Representation for vCard"?=0A=C2=A0=C2=A0=C2=A0 >>>>=C2=A0http://tools.i= etf.org/html/draft-bhat-vcarddav-json-00=0A=C2=A0=C2=A0=C2=A0 >>>>=0A=C2=A0= =C2=A0=C2=A0 >>>> On valid times: can we use same format as certificates? T= hey have=0A=C2=A0=C2=A0=C2=A0 >>>>similar simple requirements: valid notBef= ore&=C2=A0 notAfter.=0A=C2=A0=C2=A0=C2=A0 >>>>=C2=A0http://tools.ietf.org/h= tml/rfc3280#section-4.1.2.5=0A=C2=A0=C2=A0=C2=A0 >>>>=0A=C2=A0=C2=A0=C2=A0 = >>>> Teco=0A=C2=A0=C2=A0=C2=A0 >>>> _______________________________________= ________=0A=C2=A0=C2=A0=C2=A0 >>>> paws mailing list=0A=C2=A0=C2=A0=C2=A0 >= >>>=C2=A0paws@ietf.org=0A=C2=A0=C2=A0=C2=A0 >>>>=C2=A0https://www.ietf.org/= mailman/listinfo/paws=0A=C2=A0=C2=A0=C2=A0 >>>>=0A=C2=A0=C2=A0=C2=A0 >>>=0A= =C2=A0=C2=A0=C2=A0 >>> _______________________________________________=0A= =C2=A0=C2=A0=C2=A0 >>> paws mailing list=0A=C2=A0=C2=A0=C2=A0 >>>=C2=A0paws= @ietf.org=0A=C2=A0=C2=A0=C2=A0 >>>=C2=A0https://www.ietf.org/mailman/listin= fo/paws=0A=C2=A0=C2=A0=C2=A0 >>=0A=C2=A0=C2=A0=C2=A0 >>____________________= ___________________________=0A=C2=A0=C2=A0=C2=A0 >>paws mailing list=0A=C2= =A0=C2=A0=C2=A0 >>paws@ietf.org=0A=C2=A0=C2=A0=C2=A0 >>https://www.ietf.org= /mailman/listinfo/paws=0A=C2=A0=C2=A0=C2=A0 >=0A=C2=A0=C2=A0=C2=A0 >_______= ________________________________________=0A=C2=A0=C2=A0=C2=A0 >paws mailing= list=0A=C2=A0=C2=A0=C2=A0 >paws@ietf.org=0A=C2=A0=C2=A0=C2=A0 >https://www= .ietf.org/mailman/listinfo/paws=0A=C2=A0=C2=A0=C2=A0=C2=A0=0A=C2=A0=C2=A0= =C2=A0 _______________________________________________=0A=C2=A0=C2=A0=C2=A0= paws mailing list=0A=C2=A0=C2=A0=C2=A0=C2=A0paws@ietf.org=0A=C2=A0=C2=A0= =C2=A0=C2=A0https://www.ietf.org/mailman/listinfo/paws=0A=C2=A0=C2=A0=C2=A0= =C2=A0=0A=0A=0A=0A=0A--=C2=A0=0A-vince=0A=0A_______________________________= ________________=0Apaws mailing list=0Apaws@ietf.org=0Ahttps://www.ietf.org= /mailman/listinfo/paws=0A_______________________________________________=0A= paws mailing list=0Apaws@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/p= aws =0A=0A =0A=C2=A0 =0A--=C2=A0=0A-vince =0A=C2=A0 =0A=C2=A0 =0A= _______________________________________________ =0Apaws mailing list =0Apaw= s@ietf.org =0Ahttps://www.ietf.org/mailman/listinfo/paws =0A=C2=A0 =0A____= ___________________________________________=0Apaws mailing list=0Apaws@ietf= .org=0Ahttps://www.ietf.org/mailman/listinfo/paws =0A=C2=A0 =0A=C2= =A0 =0A_______________________________________________ =0Apaws mailing list= =0Apaws@ietf.org =0Ahttps://www.ietf.org/mailman/listinfo/paws =0A=C2=A0 = =0A_______________________________________________=0Apaws mailing list=0Apa= ws@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/paws =0A=C2=A0 =0A=C2= =A0 =0A=C2=A0 =0A_______________________________________________=0Apaw= s mailing list=0Apaws@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/paws --97335089-707218294-1345864438=:6327 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Hi,=
     
    I would still support = XML. JSON libraries are available for all languages. But interfacing and li= nking such libraries are problematic on embedded devices most of the time. = And if an implementation vouch for multiple such non native language librar= ies then developers life is hell...
     
    Best Regards,
     
    Sajeev Manikkoth

    =
    From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nok= ia.com>
    To: Brian.R= osen@neustar.biz; ben@blindcreek.com
    Cc: paws@ietf.org
    Sent: Saturday, 25 August 2012, 0:38
    Subject: Re: [paws] XML schema versus JSON, vCard & = iCal

    =0A=0A =0A =0A<= style>=0A=0A
    = =0A
    =0A
    WiFi wo= rld builds on mandating the implementation (and certification) of a base sp= ec, and a set of optional features. If an optional feature is not supported= =0A by one of the peers, they can still talk, but not use that feature. Tha= t is basically option B) from Brain=E2=80=99s list.
    =0A
     
    =0A
    I=E2=80=99d like= to suggest that we recognize that option A) and B) are valid options, whil= e option C) is invalid, and we should stop debating it.
    =0AI=E2=80=99d also like to add the obvious option D) to the= list, which is that both the master devices and DBs support one and the sa= me encoding ;)
    =0A
     
    = =0A
    Option A) seems to be like a good compromise, and w= ould cut discussions short, with the only caveat that if there is no strong= technical argument for supporting=0A and specifying two different encoding= s, then the iesg may send the document back to the wg to pick one of the tw= o specified. As Robert mentioned in his email, this has happened in the pas= t, so it is likely it would happen again. And frankly, I do not see a=0A st= rong argument in favor of two different encodings.
    =0A
     
    =0A
    Is there anyone = who has a technical argument against supporting only one encoding, being th= at either xml or json?
    =0A
     <= /div> =0A
    Most people speak in favor of JSON, because i= t is compact and more efficient. I went through this thread and I saw 2 obj= ections against picking JSON. One said=0A that JSON requires native Java, w= hich is wrong, the other objection gave no real reason. So I am wondering i= f there is really any valid technical reason against using JSON only?
    =0A
     
    =0A
    -         = ;=0AGabor
    =0A
     
    =0A=
     
    =0A
    =0A
    =0A
    From: paws-bounces@ietf.org [mailto:paws= -bounces@ietf.org]=0AOn Behalf Of ext Rosen, Brian
    =0ASent: Friday, August 24, 2012 10:43 AM
    =0ATo: Benjamin A. Rolfe
    = =0ACc: paws@ietf.org
    =0ASubject: Re: [paws] XML schema ver= sus JSON, vCard & iCal
    =0A
    =0A
    =0A
     
    =0A
    Okay:
    =0A
    =0A
      =0A
    =0A
    =0A
    So, I impleme= nt a database, and I implement XML
    =0A
    =0A
    =0A
    You implement a device, and you implement JSON =0A
    =0A
    =0A
     
    = =0A
    =0A
    =0A
    You query my data= base (let's not get into how you do that query without deciding XML vs JSON= ) and discover I implement XML only
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    What do you do?
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    Brian
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    =0A
    On Aug 24, 2012, at 1:38 PM, "Benjamin A. = Rolfe" <ben@blindcreek.com> w= rote:
    =0A
    =0A

    =0A
    = =0A
    =0A
    =0A

    =0A
    =0A =0A
    There are two ways to achieve= interoperability when you have an option.
    =0A
    There are many existence proofs of the third way that I ment= ioned below.
    =0A802.11 + WiFi provide many options and a means for devic= es to share information about what options each supports, without requiring= that any device implement every option.  It works. =0A
    =0A=0AThat said, I think (A) is the best choice, (B) is not as nice for me, a= nd (C) is more work than either of the other two.
    =0A 
    =0A
    = =0A
    =0A
    =0A
     
    = =0A
    =0A
    =0A
    One is that one e= nd implements both choices and the other end implements one or both.
    = =0A
    =0A
    =0A
     
    =0A=
    =0A
    =0A
    The other is that bo= th ends implement one specific choice ("MUST implement") and both can optio= nally implement the other choice.  Only if both ends implement the oth= er choice would that be available.
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    So, in this case we could do one of the following: =0A
    =0A
    =0A
    A) Databases i= mplement both XML and JSON, devices implement either
    =0A
    =0A=0A
    B) Both Databases and devices imp= lement one (say XML) and optionally implement the other (say JSON)
    = =0A
    =0A
    =0A
     
    =0A=
    =0A
    =0A
    You are advocating f= or A, Richard was suggesting B.
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    I don't care, but choice C) Both databases and devices ha= ve a choice of what to implement doesn't work for me (or Richard).
    = =0A
    =0A
    =0A
     
    =0A=
    =0A
    =0A
    Brian
    =0A=0A
    =0A
     
    =0A
    = =0A
    =0A
    =0A
    =0A
    On Aug 24,= 2012, at 12:57 PM, Benjamin A. Rolfe <ben@blindcreek.com> wrote:
    =0A
    =0A

    =0A
    =0A
    =0A
    =0A
    Apparently I was unclear.  I certainly an capable of bein= g wrong as I practice often, but in this case it is quite unlikely :-).=0A<= br>=0A
    =0AYou do not need to choose only one form to achieve interoperab= ility.   If you have two, let the device implementer figure out w= hich is best for their particular device requirements and trade-offs. = This is *preferable* from my perspective.
    =0A
    =0AIf 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 abou= t it. This is an observations, not an argument ;-).  =0A
    =0A=0AIt is my *opinion* at the  moment that if you provide options, to= make those useful you need to provide  a protocol by which devices ca= n discover what options the database supports.  If you have such a mec= hanism and all devices use it (a  bootstrap protocol),=0A everything e= lse could be options.  This requires additional functions in both data= base and device implementations.=0A
    =0AIf on the other hand the device c= an "just know" that the database has two forms available, it won't need to = dynamically figure it out. The device implementer has options and simplicit= y, so I like it.=0A
    =0A
    =0ASince I am focused on the TVWS devices tha= t need access to the database, and not a database implementer, shifting bur= den onto the database implementer (not me) to reduce the burden on the devi= ce implementer (me) is preferred from my perspective.  The database=0A= implementer may have another perspective.  Should I point out that th= ere will be a lot more devices than databases?  That might sound like = an argument, though, so I won't....:-j
    =0A
    =0ABen
    =0A
    =0A
    = =0A
    =0A
    Brian is right .. sorry but the rest of y= ou are wrong.=0AJ=0A
    =0A
    =0A
     = ;
    =0A
    =0A
    This is why you have MUST a= nd SHOULD in RFC 2119.  
    =0A
    =0A
    =  
    =0A
    =0A
    This BTW is a classic = argument in IETF terms .. but the argument =E2=80=9Clet the market decide= =E2=80=9D only holds so much validity.  You actually have to choose SO= METHING=0A to create a baseline of interoperability.
    =0A
    = =0A
     
    =0A
    =0A
     
    =0A
    =0A
    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 impl= ementations.=0A
    =0A
    =0A
     <= /div> =0A
    =0A
    End of argument you now can go back = to your regularly schedule programming.=0AJ=0A
    =0A
    =0A=
     
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    From:=0Apa= ws-bounces@ietf.org [mailto:p= aws-bounces@ietf.org]=0AOn Behalf Of Basavaraj.Patil@nokia.com
    =0ASent: Thu= rsday, August 23, 2012 5:44 PM
    =0ATo: Brian.Rosen@neustar.biz; =0Ad.joslyn@spectrumbridge.com
    =0ACc:<= /b> paws@ietf.org
    =0ASubject: Re: [= paws] XML schema versus JSON, vCard & iCal
    =0A
    =0A=0A
     
    =0A
    =0A
    = =0A
    =  
    =0A
    =0A
    =0A
    =0A
    I agree with Brian. =0A
    =0A
    =0A
    There needs to be a default mandatory to implement o= ption in order to achieve interoperability. 
    =0A
    =0A=
    =0A
    And this applies to the device and database side of the protocol.
    =0A
    =0A
    =0A
    =0A
    =  
    =0A
    =0A
    =0A=
    =0A
    -Raj
    =0A
    =0A
    =0A
    =0A
     
    =0A=0A
    =0A
    =0A
    From:=0A"<= ;ext Rosen>", "Brian.Rosen= @neustar.biz" <Brian.R= osen@neustar.biz>
    =0ADate: Thursday, August 23, 2012 2:43 = PM
    =0ATo: Don Joslyn <d.joslyn@spectrumbridge.com>
    =0ACc: "paws@ietf.org" <paws@ie= tf.org>
    =0ASubject: Re: [paws] XML schema versus JSON, vCa= rd & iCal
    =0A
    =0A
    =0A
    =0A
     
    =0A=
    =0A
    =0A
    =0A
    =0A
    One of my favorite IETF expressions is "Ther= e 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,=0A you may not = get interoperability with other implementations.  On the other hand, t= he whole point of a protocol document like ours is that two independent imp= lementations who both follow the document will interwork.  If that was= n't true, why do you need a standard?=0A
    =0A
    =0A
    =0A = ;
    =0A
    =0A
    =0A
    =0A
    If you say "either" to both ends, = then you don't get interoperability.  
    =0A
    =0A
    = =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    By your argument, we = should stop working, and the product managers will figure it out using prop= rietary protocols.  The market will decide.
    =0A
    =0A<= div>=0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    So, I feel strong= ly that if one end is "either", the other end must be "both".  It's al= so acceptable to say both ends implement one choice and the other is option= al at both=0A ends.  Here, I think it's server does both and client do= es either. 
    =0A
    =0A
    =0A
    =0A
     
    = =0A
    =0A
    =0A
    =0A
    It's always possible to build an implementation o= f a server that only does one: there are no protocol police.
    = =0A
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A<= div class=3D"yiv1801539421MsoNormal">Bria= n <as individual>
    =0A
    =0A
    =0A
    =0A
     =
    =0A
    =0A
    =0A
    =0A
    =0A
     
    =0A
    =0A=0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    = =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    On Aug 23, 2012, at 3:= 11 PM, Don Joslyn <d.joslyn@spectrumbridge.com> wrote:
    =0A
    =0A

    =0A=0A
    =0A
    =0A
    =0A
    =0A
    Hi Ben,
    =0A
    =0A
    =0A
    That was my original s= uggestion, and I still think it makes the most sense.
    =0A=0A
    =0A
    Thanks for supporting the proposal.=
    =0A
    =0A
    =0A
    Don
    =0A
    = =0A
    =0A
     
    =0A
    =0A
    =0A= =0A
    =0A
    From: paws-bounces@ietf.or= g=0A [mailto:paws-bounces= @ietf.org] On Behalf Of = Benjamin A. Rolfe
    =0ASent: Thursday, August 23, 2012 3:05 PM
    = =0ATo: paws@ietf.org
    =0ASubject: Re: [paws] XML sche= ma versus JSON, vCard & iCal
    =0A
    =0A
    =0A
    = =0A
    =0A
     
    =0A
    =0A<= div>=0A
    Someone suggested that PAWS de= fine both, and let the vendors decide which ones to implement.
    =0AThat m= akes the most sense for both DB and device vendors.  Markets will prob= ably drive DB vendors to do both. Device vendors will do what fits the mark= et segment they're after. Why over-constrain (or argue when natural selecti= on will take care of it for us?).
    =0AB
    =0A
    =0A
    =0A
    =0A
    = =0A
    =0A
    =0A
    Sounds good to me.
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    =0A
    From: <= /span>paws-bounces@ietf.org [mailto:pa= ws-bounces@ietf.org] On=0A Behalf Of Gabor.Bajko@nokia.com
    =0ASent= : Tuesda= y, August 21, 2012 12:42 AM
    =0ATo: paws@ietf.org
    =0ASubject: Re: [paws] XML schema ver= sus JSON, vCard & iCal
    =0A
    =0A
    =0A
    =0A
    = =0A
     
    =0A
    =0A
    =0A<= div class=3D"yiv1801539421MsoNormal">Now I= can=E2=80=99t see anymore any willingness to agree on one or the other enc= oding.
    =0A
    =0A
    =0A
    To prevent endless discussions on this = topic I=E2=80=99d suggest we move forward with supporting both in the DB an= d either one in the master device.
    =0A
    =0A
    =0A
    Any objecti= ons?
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    Gabor
    =0A
    =0A
    =0A
     <= /div> =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    = =0A
     paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=0A Behalf Of ext Das, Su= bir
    =0ASent:&n= bsp;Monday, August 20, 2012 2:50 PM
    =0ATo: Don Joslyn; Vincent Chen; W= eixinpeng
    =0ACc: paw= s@ietf.org; Manikkoth Sajeev
    =0ASubject: Re: [paws] XML schema ver= sus JSON, vCard & iCal
    =0A
    =0A
    =0A
    =0A
    = =0A
     
    =0A
    =0A
    =0A<= div class=3D"yiv1801539421MsoNormal">We ha= ve a half a dozen or more TVDB radio vendors that use/prefer JSON and we wi= ll vote for JSON if we had to pick one.
    =0A
    =0A
    =0AAlso I= will copy the following two important points:
    =0A
    =0A=0A
     
    =0A
    =0A
      =0A
        =0A
      • Simple-to-use libraries exist for all major languages/platforms<= /span>
      • Don't need a tool chain to work wi= th the data, as is typically needed for XML
      =0A
    =0A=0A
     
    =0A
    =0A
    =0A
     
    =0A
    =0A
    = =0A
    &= nbsp;
    =0A
    =0A
    =0A
    =0A
    =0A
    From:paws-bounces@ietf.org<= /span> <= a href=3D"mailto:[mailto:paws-bounces@ietf.org]" rel=3D"nofollow" target=3D= "_blank" ymailto=3D"mailto:[mailto:paws-bounces@ietf.org]">[mailto:paws-bounces@ietf.org] On=0A Behalf Of Don Joslyn
    =0A<= b>Sent:     = Monday, August 20, 2012 4:54 PM
    =0ATo: Vincent Chen; Weixinpeng
    =0ACc:<= /b> paws@ietf.org;= Manikkoth Sajeev
    =0ASubject: Re: [paws] XML schema versus JSON, vCard & = iCal
    =0A
    =0A
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    Please see my comments belo= w=E2=80=A6
    =0A
    =0A
    =0A
    Thanks,
    =0A
    =0A=0A
     
    =0A
    =0A
    =0A=0A
    From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=0A Behalf Of Vincent C= hen
    =0ASent:&n= bsp;Monday, August 20, 2012 2:56 PM
    =0ATo: Weixinpeng
    =0ACc:=  paws@ietf.org; Man= ikkoth Sajeev
    =0ASubject: Re: [paws] XML schema versus JSON, vCard & iCal=
    =0A
    =0A
    =0A
    =0A
     
    =0A
    =0A
      =0A
    • One of our goals is to strive to lower= the cost and complexity for device manufacturers. This lowers the barrier = for=0A building a robust ecosystem.
    =0A
    =0A
    [DJ - = The =E2=80=9Ccost=E2=80=9D and complexity of using XML has not been an issu= e for the half dozen TVBD vendors that have already used XML. Maybe we need= to better define =E2=80=9Ccost=E2=80=9D?]
    =0A
    =0A
      =0A
    • T= o reduce complexity and cost for device makers, supporting 1 encoding is be= tter than both, as Brian points out. WiFi=0A access points that "just work"= anywhere in the world serves as a good model.
    =0A
    =0A=
    [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 supp= orts XML and JSON, but if I=E2=80=99m forced to pick only one, then I=0A wi= ll vote for XML because it=E2=80=99s the one that we currently use on all e= mbedded devices.]
    =0A
    =0A
      =0A
    • There's a trend for APIs o= n the web towards JSON (Twitter, FourSquare, Facebook, Google, etc.). One o= f the major reasons=0A is that developers (client-side) prefer it for its s= implicity:
    =0A
      =0A
        =0A
      • Representation closely matches most data models (nested lists = and maps)
      • Simple-to-use librari= es exist for all major languages/platforms
      • Don't need a tool chain to work with the data, as is typically = needed for XML.
      =0A
    =0A
    =0AApparently, the efficiency gains of JSON also matter to the scalabili= ty of serving systems.
    =0A
    =0A
     = ;
    =0A
    =0A
    =0A
    [DJ =E2=80=93 I can=E2=80=99t argue = against these listed pros for JSON, especially when you=E2=80=99re dealing = with a lot of data (like Twitter, FourSquare, Facebook and Google does). Bu= t I=E2=80=99m assuming that PAWS messages will not be=0A exchanged nearly a= s often as the applications mentioned above. But again, I know JSON is more= efficient, can=E2=80=99t argue with that.]
    =0A
    =0A
      =0A
    • = At the end of the day, it's the data model that matters, rather than the en= coding. We (Google) are actually neutral=0A on XML vs JSON, as long as we'r= e clear on what device makers want. It would be good to get feedback from d= evice makers (especially of embedded devices) regarding experiences support= ing XML vs JSON.
    =0A
    =0A&= nbsp;
    =0A
    =0ADon, can you ela= borate on the types of devices that already support XML?
    =0A=0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    [DJ - We currently support half a dozen TVDB radio ven= dors (embedded devices) using XML, non using JSON. XML has not been a burde= n, and the amount of data that needs to be exchanged=0A between device and = database is not that much or exchanged that often.]
    =0A
    = =0A
    =0A
    On Fri, Aug 17, 2012 at 6:= 06 PM, Weixinpeng <weixinpeng@huawei.com> wrote:
    =0A=0A
    =0A
    =0A
    Considering of the design of = database discovery protocol, the LoST protocol may be used and LoST is base= d on XML, so I think XML may be preferred.
    =0A
    =0A
    = =0A
     
    =0A
    =0A
    =0A
    --Xinpeng Wei
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    =0A
    From: paws-boun= ces@ietf.org&= nbsp;[mailto:paws-bounces@ietf.org] On=0A Behalf Of Rosen, Brian =0A
    =0A
    =0A
    =0A

    = =0ASent: Friday, August 17, 2012 9:26 PM
    =0A
    =0A
    =0A =0A
    =0A
    =0A
    =0A

    =0ACc: paws@ietf.org
    =0ASubject: Re: [paws] XML schema = versus JSON, vCard & iCal
    =0A
    =0A
    =0A
    =0A
    =0A=
    =0A
    =0A
     
    =0A=0A
    =0A
    =0A
    I don't really care whether we use json or xml as a matte= r of protocol design or implementation, but I am a big fan of reusing stand= ards rather than defining new ones, and=0A I would not want to see the choi= ce of json mean we then decide to roll our own versus using existing standa= rds based on the idea there is no json representation of an existing standa= rd.  So, if choosing json means folks feel free to ignore existing xml= based=0A standards such as xCard and LoST, then I would not want to use js= on.
    =0A
    =0A
    =0A
    =0A
    =0A
     
    =0A=
    =0A
    =0A
    =0A
    =0A
    I would prefer to not have "both", because = of interoperability complications.  If there is rough consensus for bo= th, then I would assert that all servers have to implement=0A both and the = client can implement either.
    =0A
    =0A
    =0A
    =0A=0A
    There are json val= idators, so I don't think that is a big deal.  
    =0A
    = =0A
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A=
    =0A
    My experience in protocol design on the Internet is that decisions ma= de solely or even largely because of compactness advantages rarely are good= choices.  If you like json=0A because it is smaller, then I believe y= ou need a much better reason.  Binary doesn't work for me, at all. &nb= sp;I have been involved in big binary vs text wars in protocol design. &nbs= p;Text wins, binary loses, in my opinion.
    =0A
    =0A
    = =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    =0A<= div class=3D"yiv1801539421MsoNormal">Bri= an <as individual>
    =0A
    =0A
    =0A
    =0A
    =0A=
    &n= bsp;
    =0A
    =0A
    =0A
    =0A
    =0A
    From: Manikkoth Sajeev <mksaji@yahoo.com>
    =0AReply-To:<= span class=3D"yiv1801539421apple-converted-space">     Manikkot= h Sajeev <mksaji@yahoo.com>
    =0ADate: Thu, 16 Aug 2012 22:37:38 -0400
    = =0ATo: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>,= =0A "Rosen, Brian" <brian.rosen@neustar.biz>, "vchen@google.com" <vchen@google.com>,=0A "peter@spectrumbridge.com" <peter@spectrumbridge.com>
    =0ACc: "paws@ietf.org" <paws@ietf.org>
    =0ASubject: Re: [paws] XML schema versus JSON, vCard & iCal
    =0A
    =0A
    =0A
    =0A
    =0A
     
    =0A
    = =0A
    =0A
    =0A
    =0A
    =0A
    =0AHi,
    =0A
    =0A
    =0A
    =0A
    = =0A
    =0A&n= bsp;
    =0A
    =0A
    =0A
    =0A
    =0A
    =0ACan it not be both JSON and XML = supported? I would vote for that. Future implementations may prefer XML as it is gen= eric, omni present, easy to understand and validate. For=0A compactness may be= a  = binary xml optioncan also work. JSON I think will necessitate implement= ation to be native Java and may not be as friendly with other implementatio= n languages.
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A 
    =0A
    = =0A
    =0A
    =0A
    =0A
    =0ABest Regards,
    =0A
    =0A
    =0A=0A
    =0ASajeev Manikkoth
    =0AMobile: +918792292002
    =0AEmail: mksaji@ieee.org
    =0Ahttp://www.linkedin.com/in/mksajeev
    =0A
    =0A
    =0A
    =0A
    =0A 
    =0A
    =0A
    = =0A
    =0A
    =0A
    =0A
    =0AFrom:<= span class=3D"yiv1801539421apple-converted-space"> "Gabor.Bajko@nok= ia.com"=0A <Gabor.Bajko@nokia.com>
    =0ATo: Brian= .Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com     
    =0ACc: paws@ietf.org 
    =0ASent: Friday, 17 Au= gust 2012, 4:55
    =0ASubject: Re: [paws] XML schema versus JSON, vCard & iC= al
    =0A
    =0A
    =0A
    =0A
    =0AWe have not hea= rd any objections for using JSON encoding instead of XML. 
    =0ATherefore, let's go fo= r JSON, and close this thread.
    =0A
    =0A- Gabor
    =0A
    =0A-----Origi= nal Message-----
    =0AFrom: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]= =0A On Behalf Of ext Rosen, Brian
    =0ASent: Monday, August 13, 2012 3:14 = PM
    =0ATo: 'Vincent Chen'; 'Peter Stanforth'
    =0ACc: 'paws@ietf.org'
    =0ASub= ject: Re: [paws] XML schema versus JSON, vCard & iCal
    =0A
    =0Ajson= is okay with me. &= nbsp;
    =0AI'd prefer an ISO time stamp rather than a time in secon= ds since epoch.  It's very easy to parse, and its simpler to use and d= ebug.  Don't care a whole lot about that
    =0A
    =0ABrian <as ind= ividual>
    =0A
    =0A
    =0A
    =0A-----Original Message-----
    =0AFro= m:     Vincent Chen [mailto:= vchen@google.com]
    =0ASent:&nbs= p;   Monday, August 13, 2012 06:04 PM Eastern Standard Time
    = =0ATo:    Peter Stanforth
    =0ACc:    Rosen,= Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
    =0ASubject:    Re: [paws]= XML schema versus JSON, vCard & iCal
    =0A
    =0AXML vs JSON
    =0A=0ABetween XML and JSON, JSON messages are more compact and easier to pro= cess (parsing, synthesis). As clarification, JSON does not require JavaScri= pt or a Browser. It is a text-based representation of data that is language= independent, yet well-matched to all=0A major languages. JSON-handling lib= raries exist for numerous languages (see of http://json.org/= ) and seem to be reasonably light weight.
    =0A
    =0ATimestamps
    = =0A
    =0AAs for timestamp specifications, should we consider just using se= conds 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=0A format. Is that a valid assu= mption? Of course, this is less human-readable....
    =0A
    =0A
    =0AOn M= on, Aug 13, 2012 at 6:49 AM, Peter Stanforth <peter@spectrumbridge.c= om> wrote:
    =0A
    =0A
    =0A    Whenever we= built mobile devices we never dealt with IETF, in our sensor
    =0A &= nbsp;  days even an IP stack was a challenge,so I would defer to the d= evice guys
    =0A    on that one.
    =0A    
    =0A =    On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"
    =0A&nbs= p;   
    =0A    <Brian.Rosen@neustar.biz> w= rote:
    =0A    
    =0A    >Our experience in the IETF= over many years is that economizing message
    =0A    >s= ize and compromising utility and security in search of efficiency of
    =0A=     >implementation on small devices is a poor trade off.=   I am not advocating
    =0A    >being wasteful of r= esources, but I don't think we should seriously
    =0A    &g= t;consider the overhead of XML or json to be significant.
    =0A  = ;  >
    =0A    >Assuming a json library can be lo= aded on a small device is reasonable.
    =0A    >
    =0A&= nbsp;   >Brian (as individual)
    =0A    >=0A    >
    =0A    >
    =0A &nbs= p;  > -----Original Message-----
    =0A    >From:=   Peter Stanforth [mailto:peter@spectrumbridge.com]
    = =0A    >Sent:  Saturday, August 11, 2012 07:13 AM Ea= stern Standard Time
    =0A    >To:    Teco Boot= ; Benjamin A.Rolfe
    =0A    >Cc:    paws@ietf.org
    =0A &nb= sp;  >Subject:      Re: [paws] XML schema versus JSO= N, vCard & iCal
    =0A    >
    =0A    = >Not all masters run over the core network.
    =0A    >= ;Some of the Use cases have a master talking to another OTA
    =0A &nb= sp;  >We should not assume that all Masters are attached to utility= power so we
    =0A    >should be sympathetic to processi= ng energy use also.
    =0A    >
    =0A    = >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <teco@inf-net.nl> w= rote:
    =0A    >
    =0A    >>
    = =0A    >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. R= olfe het volgende
    =0A    >>geschreven:
    =0A =    >>
    =0A    >>> Compactness of = messages is important, but it is also important (to me
    =0A  &n= bsp; >>>at least) to be realizable in an implementation with limit= ed resources,
    =0A    >>>such as embedded devices= in what are now popularly called "M2M"
    =0A    >>&g= t;applications.  A lot of these devices could use IP all the end to en= d,
    =0A    >>>but may have a very compact, simple= stack and applications (i.e.  no
    =0A    >>>= ;browser).  Is JSON typically implemented when there is no browser?=0A    >>>Would it be hard to do in a resource con= strained device (i.e. where we
    =0A    >>>talk ab= out memory size in Kilo-bytes still).
    =0A    >>
    = =0A    >>In use cases and requirements document, there= are no requirements for
    =0A    >>protocol performa= nce. I guess OS/IP/TCP/TLS code size supersedes needs
    =0A  &nb= sp; >>for JSON or XML.
    =0A    >>
    =0A =    >>Same for timing: TCP/TLS connection setup will take mo= re than the PAWS
    =0A    >>message exchange, I think= . This may be of importance when using satcom
    =0A    >= >links.
    =0A    >>
    =0A    >&= gt;Because PAWS runs between master and database, over core network,
    =0A=     >>performance is not our primary concern. But as a= lways, it is good to keep
    =0A    >>an eye on effici= ency.
    =0A    >>
    =0A    >>Te= co
    =0A    >>
    =0A    >>> = Thanks
    =0A    >>> Ben
    =0A    &= gt;>>
    =0A    >>>
    =0A    = >>>> We had a discussion on XML vs. JSON. I prefer the one with= most
    =0A    >>>>compact messages.
    =0A&nbs= p;   >>>>
    =0A    >>>> O= n vCard and JSON: what is the status of "A JavaScript Object Notation
    = =0A    >>>>(JSON) Representation for vCard"?
    = =0A    >>>> http://tools.ietf.org/html/draft-bhat-vcarddav-json-00=
    =0A    >>>>
    =0A    >>= ;>> On valid times: can we use same format as certificates? They have=
    =0A    >>>>similar simple requirements: vali= d notBefore&  notAfter.
    =0A    >>>><= span class=3D"yiv1801539421apple-converted-space">     http://tools.ietf.org/html/rfc32= 80#section-4.1.2.5
    =0A    >>>>
    = =0A    >>>> Teco
    =0A    >&g= t;>> _______________________________________________
    =0A &nbs= p;  >>>> paws mailing list
    =0A    >&g= t;>> <= a href=3D"mailto:paws@ietf.org" rel=3D"nofollow" target=3D"_blank" ymailto= =3D"mailto:paws@ietf.org">paws@ietf.org
    =0A    >>>> https://www.ietf.org/mailman/listinfo/paws
    =0A &= nbsp;  >>>>
    =0A    >>>
    =0A&n= bsp;   >>> _____________________________________________= __
    =0A    >>> paws mailing list
    =0A &nbs= p;  >>>&nb= sp;paws@iet= f.org
    =0A    >>> https://www.ietf.org/mailman/listinfo/paws
    =0A&= nbsp;   >>
    =0A    >>_______________= ________________________________
    =0A    >>paws mail= ing list
    =0A    >>paws@ietf.org
    =0A    &= gt;>https://www.ietf.org/m= ailman/listinfo/paws
    =0A    >
    =0A &= nbsp;  >_______________________________________________
    =0A = ;   >paws mailing list
    =0A    >paws@ietf.org
    = =0A    >htt= ps://www.ietf.org/mailman/listinfo/paws
    =0A   =  
    =0A&nbs= p;   _______________________________________________
    =0A =    paws mailing list
    =0A    paws@ietf.org
    =0A   =  https://www.ietf.org/mailman/listinfo/pa= ws
    =0A    
    =0A
    =0A
    =0A
    =0A
    =0A-- 
    =0A-vince
    =0A=0A_______________________________________________
    =0Apaws mailing lis= t
    =0Apaws@ietf.= org
    =0Ahttps://= www.ietf.org/mailman/listinfo/paws
    =0A_______________________= ________________________
    =0Apaws mailing list
    =0Apaws@ietf.org
    =0Ahttps://www.ietf.org/mailman/listinf= o/paws
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A=0A

    =0A
    =0A =0A
    =0A
    =0A
    =0A
     =
    =0A
    =0A
    =0A
    =0A
    -= - 
    =0A-vi= nce
    =0A
    =0A
    =0A
     
    =0A
     
    =0A_______________________________________________ =0A
    paws maili=
ng list
    =0A
    paws@ietf.org
    =0A
    https://www.ietf.org/mailman/listinfo/paws
    = =0A
    =0A
     
    =0A
    =0A<= div class=3D"yiv1801539421MsoNormal">___= ____________________________________________
    =0Apaws mailing list
    =0A= paws@ietf.org
    =0Ahttps://ww= w.ietf.org/mailman/listinfo/paws
    =0A
    =0A
    =0A=0A
     
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
     =
 
    =0A
    _______________________________________________
    = =0A
    paws mailing list
    =0A
    paws@ietf=
.org
    =0A
    https://www.ietf.org/mailman/listinfo=
/paws
    =0A
     
    =0A<= /div>=0A
    _____________________________= __________________
    =0Apaws mailing list
    =0A= paws@ietf.org
    =0Ahttps://www.ietf.org/mailman/listinf= o/paws
    =0A
    =0A
     <= /div> =0A
    =0A
     
    =0A=0A
    =0A
     
    =0A=0A
    =0A
    =0A=0A

    _______________________________________= ________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/l= istinfo/paws


    --97335089-707218294-1345864438=:6327-- From vchen@google.com Fri Aug 24 20:36:05 2012 Return-Path: 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 0865811E808E for ; Fri, 24 Aug 2012 20:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.151 X-Spam-Level: X-Spam-Status: No, score=-102.151 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 iPZKDaoeotCS for ; Fri, 24 Aug 2012 20:36:02 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B33DC11E808A for ; Fri, 24 Aug 2012 20:36:01 -0700 (PDT) Received: by yhq56 with SMTP id 56so578567yhq.31 for ; Fri, 24 Aug 2012 20:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=z5KSOUvNPcnn9jSa6BK1VH/P3gq4M/kGr3FG6LQgTIg=; b=ecUsUA+/zAK8B/Yct1ih5tGiVDx/E4HcmPXgaUBI8yHKsgOt2E9pU2diFzIjE1q0yj u13M3IwWbV4agpaDicFpg3XSKAshR29r55wsS+F4GNSSWLUKtlNf/hSxOn2I9IaMnPck WhU/AWkJVKuWppB5LNoRqeM61Ng3lNAH2C2kQMw5dvBwWZFOQJXzpxTyBgEHBFp4k9yE iT4s0FHN7JFIVQHHpyk/RzBhzIgH7nErQjxoPUuua2SQwaR7eZArrwWBq+jQxv4pr7zJ O3HU8HfeCAN4zxcQTxq+SEZqAtKnTFh9J7jZZbI5CUh1GR2QBkCBWzgSJXoZhESCXB05 ABlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=z5KSOUvNPcnn9jSa6BK1VH/P3gq4M/kGr3FG6LQgTIg=; b=C8uLGfMfPdJhT64EQmcAako2iXzhcOuFEFlWgMUq6/ZUZXlG1cu9iCH2yoiQ7LA81R YHsW44ADhjlRKdSHle3IztZxvAYYoC/AKw+ReF7Xnk6DwErJCdN5itQ/0TX0q49WpZ21 rylS0ftUQLD9r+94wLcNtLBdrDB3Wfqi0l6jGqLKhvcQ1AUyjJp0c3Pq1rfQQJ4jETwA a7wxphFV65bk+ayBNdWBmWHHCeTIvqL5UMnj/Owdxt+XAeXdKn7bUK29IruDr+tNpjyP ucT8ATy9r8NBpl8iXP4SVKN9Lg8PA9ZgdIYiaDIxswG2i1WPq7zHa1/pS7d1WmcTCLDA LwFw== Received: by 10.236.115.102 with SMTP id d66mr6236285yhh.67.1345865761091; Fri, 24 Aug 2012 20:36:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.115.102 with SMTP id d66mr6236274yhh.67.1345865760878; Fri, 24 Aug 2012 20:36:00 -0700 (PDT) Received: by 10.101.99.2 with HTTP; Fri, 24 Aug 2012 20:36:00 -0700 (PDT) In-Reply-To: <1345864438.6327.YahooMailNeo@web120306.mail.ne1.yahoo.com> References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> <00c601cd820b$67b97170$372c5450$@us> <5037B28B.70501@blindcreek.com> <5D0B1E63-79FE-4BC6-A446-3470931D1043@neustar.biz> <5037BC2B.7010008@blindcreek.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724@008-AM1MPN1-006.mgdnok.nokia.com> <1345864438.6327.YahooMailNeo@web120306.mail.ne1.yahoo.com> Date: Fri, 24 Aug 2012 20:36:00 -0700 Message-ID: From: Vincent Chen To: Manikkoth Sajeev Content-Type: multipart/alternative; boundary=485b397dcd1d97b1ed04c80ecacb X-System-Of-Record: true X-Gm-Message-State: ALoCoQl8Y3M6OvN5TCRixPZZMbDM+pc0aTbeKXa//OR69DEa81VogaYGksoSkNwfmbDtjBI2Xg3AC3TKRm6Q+5TBt1CISIzVMh0q5O1Z610yc8nnmTTfW1eazUsBwcOxsgQUCRkFCf81tgrVjaOKHwXSOkedJMKFbL/QYRZ2Ivr8P6rDsQUkoR1cN8NLKs0LDAf3nNCx6X84 Cc: "paws@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 03:36:05 -0000 --485b397dcd1d97b1ed04c80ecacb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sajeev, It's been a while since I've worked with embedded devices. I'm surprised that the same concern does not apply to XML. Do you not need libraries to work with XML? On Fri, Aug 24, 2012 at 8:13 PM, Manikkoth Sajeev wrote: > Hi, > > I would still support XML. JSON libraries are available for all languages= . > But interfacing and linking such libraries are problematic on embedded > devices most of the time. And if an implementation vouch for multiple suc= h > non native language libraries then developers life is hell... > > *Best Regards,* > ** > *Sajeev Manikkoth > * > > *From:* "Gabor.Bajko@nokia.com" > *To:* Brian.Rosen@neustar.biz; ben@blindcreek.com > *Cc:* paws@ietf.org > *Sent:* Saturday, 25 August 2012, 0:38 > > *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal > > WiFi world builds on mandating the implementation (and certification) of > a base spec, and a set of optional features. If an optional feature is no= t > supported by one of the peers, they can still talk, but not use that > feature. That is basically option B) from Brain=92s list. > > I=92d 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=92d also like to add the obvious option D) to the list, which is that b= oth > 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, th= e > 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] *On Behalf > Of *ext Rosen, Brian > *Sent:* Friday, August 24, 2012 10:43 AM > *To:* Benjamin A. Rolfe > *Cc:* 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" > 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 > 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 the= ir > 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 u= se > 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 discove= r > 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 th= an > 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 =93let > the market decide=94 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] > *On Behalf Of *Basavaraj.Patil@nokia.com > *Sent:* Thursday, August 23, 2012 5:44 PM > *To:* Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com > *Cc:* 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: *"", "Brian.Rosen@neustar.biz" < > Brian.Rosen@neustar.biz> > *Date: *Thursday, August 23, 2012 2:43 PM > *To: *Don Joslyn > *Cc: *"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 follo= w > 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 t= he > 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 > > > > > On Aug 23, 2012, at 3:11 PM, Don Joslyn > 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] *O= n > Behalf Of *Benjamin A. Rolfe > *Sent:* Thursday, August 23, 2012 3:05 PM > *To:* 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 th= e > 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 > ] *On Behalf Of *Gabor.Bajko@nokia.com > *Sent:* Tuesday, August 21, 2012 12:42 AM > *To:* paws@ietf.org > *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal > > Now I can=92t see anymore any willingness to agree on one or the other > encoding. > To prevent endless discussions on this topic I=92d suggest we move forwa= rd > 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 > ] *On Behalf Of *ext Das, Subir > *Sent:* Monday, August 20, 2012 2:50 PM > *To:* Don Joslyn; Vincent Chen; Weixinpeng > *Cc:* 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] *On Behalf > Of *Don Joslyn > *Sent:* Monday, August 20, 2012 4:54 PM > *To:* Vincent Chen; Weixinpeng > *Cc:* paws@ietf.org; Manikkoth Sajeev > *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal > > Please see my comments below=85 > Thanks, > Don > > *From:* 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; 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 =93cost=94 and complexity of using XML has not been an issue f= or > the half dozen TVBD vendors that have already used XML. Maybe we need to > better define =93cost=94?] > > - 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=92m forced to pick only one, then I will = vote > for XML because it=92s the one that we currently use on all embedded devi= ces.] > > - 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 =96 I can=92t argue against these listed pros for JSON, especially w= hen > you=92re dealing with a lot of data (like Twitter, FourSquare, Facebook a= nd > Google does). But I=92m assuming that PAWS messages will not be exchanged > nearly as often as the applications mentioned above. But again, I know JS= ON > is more efficient, can=92t 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 feedba= ck > from device makers (especially of embedded devices) regarding experien= ces > 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 > 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] *On Behalf > Of *Rosen, Brian > > *Sent:* Friday, August 17, 2012 9:26 PM > *To:* Manikkoth Sajeev; gabor.bajko@nokia.com; vchen@google.com; > peter@spectrumbridge.com > > *Cc:* 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 me= an > we then decide to roll our own versus using existing standards based on t= he > idea there is no json representation of an existing standard. So, if > choosing json means folks feel free to ignore existing xml based standard= s > 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 eith= er. > > 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, binar= y > loses, in my opinion. > > Brian > > *From: *Manikkoth Sajeev > *Reply-To: *Manikkoth Sajeev > *Date: *Thu, 16 Aug 2012 22:37:38 -0400 > *To: *"Gabor.Bajko@nokia.com" , "Rosen, Brian" < > brian.rosen@neustar.biz>, "vchen@google.com" , " > peter@spectrumbridge.com" > *Cc: *"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 > option*can also work. JSON I think will necessitate implementation to be > native Java and may not be as friendly with other implementation language= s. > > *Best Regards,* > *Sajeev Manikkoth > Mobile: +918792292002 > Email: mksaji@ieee.org > http://www.linkedin.com/in/mksajeev* > > *From:* "Gabor.Bajko@nokia.com" > *To:* Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com > *Cc:* 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] On Behalf Of > ext Rosen, Brian > Sent: Monday, August 13, 2012 3:14 PM > To: 'Vincent Chen'; 'Peter Stanforth' > Cc: '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 > > > > -----Original Message----- > From: Vincent Chen [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 > Subject: Re: [paws] XML schema versus JSON, vCard & iCal > > XML vs JSON > > Between XML and JSON, JSON messages are more compact and easier to proces= s > (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/) 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 nee= d > 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 > 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" > > wrote: > > >Our experience in the IETF over many years is that economizing messa= ge > >size and compromising utility and security in search of efficiency o= f > >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 reasonabl= e. > > > >Brian (as individual) > > > > > > > > -----Original Message----- > >From: Peter Stanforth [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 > >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" > 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 (t= o > 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. wher= e > we > >>>talk about memory size in Kilo-bytes still). > >> > >>In use cases and requirements document, there are no requirements f= or > >>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 t= o > 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 > >>>> > >>>> On valid times: can we use same format as certificates? They hav= e > >>>>similar simple requirements: valid notBefore& notAfter. > >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5 > >>>> > >>>> Teco > >>>> _______________________________________________ > >>>> paws mailing list > >>>> paws@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/paws > >>>> > >>> > >>> _______________________________________________ > >>> paws mailing list > >>> paws@ietf.org > >>> https://www.ietf.org/mailman/listinfo/paws > >> > >>_______________________________________________ > >>paws mailing list > >>paws@ietf.org > >>https://www.ietf.org/mailman/listinfo/paws > > > >_______________________________________________ > >paws mailing list > >paws@ietf.org > >https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > > > -- > -vince > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > -- > -vince > > > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --485b397dcd1d97b1ed04c80ecacb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sajeev,

    It's been a while since I've worked with= embedded devices. I'm surprised that the same concern does not apply t= o XML. Do you not need libraries to work with XML?


    On Fri, Aug 24, 2012 at 8:13 PM, Manikkoth S= ajeev <mksaji@yahoo.com> wrote:
    Hi,
    =A0
    I would still support XML. JSON libraries are available for all languag= es. But interfacing and linking such libraries are problematic on embedded = devices most of the time. And if an implementation vouch for multiple such = non native language libraries then developers life is hell...
    =A0
    Best Regards,<= /font>
    =A0
    Sajeev Manikkoth

    =
    From: "Gabor.Bajko@nokia.com" <Gab= or.Bajko@nokia.com>
    To: Brian.Rosen@neustar.biz; ben@blindcreek.com Cc: paws@ietf.org
    Sent: Saturday, 25 August 2= 012, 0:38

    Su= bject: Re: [paws] XML schema versus JSON, vCard & iCal
    <= /div>

    =20 =20
    WiFi world builds = on mandating the implementation (and certification) of a base spec, and a s= et 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 i= s basically option B) from Brain=92s list.
    =20
    =A0
    = =20
    I=92d like to sugg= est that we recognize that option A) and B) are valid options, while option= C) is invalid, and we should stop debating it.
    =20
    I=92d also like to= add the obvious option D) to the list, which is that both the master devic= es and DBs support one and the same encoding ;)
    =20
    =A0
    = =20
    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 documen= t back to the wg to pick one of the two specified. As Robert mentioned in h= is email, this has happened in the past, so it is likely it would happen ag= ain. And frankly, I do not see a strong argument in favor of two different encodings.
    =20
    =A0
    = =20
    Is there anyone wh= o has a technical argument against supporting only one encoding, being that= either xml or json?
    =20
    =A0
    = =20
    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 n= o real reason. So I am wondering if there is really any valid technical rea= son against using JSON only?
    =20
    =A0
    = =20
    -=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Ga= bor
    =20
    =A0
    = =20
    =A0
    = =20
    From: 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=
    Subject: Re: [paws] XML schema versus JSON, vCard & iCal    <= /div>=20
    =A0
    =20
    Okay:
    =20
    =A0
    =20
    So, I implement a database, and I implement XML
    =20
    You implement a device, and you implement JSON
    =20
    =A0
    =20
    You query my database (let's not get into how you do that query wi= thout deciding XML vs JSON) and discover I implement XML only
    =20
    =A0
    =20
    What do you do?
    =20
    =A0
    =20
    Brian
    =20
    =A0
    =20
    On Aug 24, 2012, at 1:38 PM, "Benjamin A. Rolfe" <ben@blind= creek.com> wrote:
    =20


    =20


    =20
    There are two ways to achieve interoperability when you have an option= .
    =20
    There are many existence proofs of the third way that I mentioned belo= w.
    802.11 + WiFi provide many options and a means for devices to share informa= tion about what options each supports, without requiring that any device im= plement every option.=A0 It works.=A0

    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.
    =A0

    =20
    =A0
    =20
    One is that one end implements both choices and the other end implemen= ts one or both.
    =20
    =A0
    =20
    The other is that both ends implement one specific choice ("MUST = implement") and both can optionally implement the other choice. =A0Onl= y if both ends implement the other choice would that be available.
    =20
    =A0
    =20
    So, in this case we could do one of the following:
    =20
    A) Databases implement both XML and JSON, devices implement either=20
    B) Both Databases and devices implement one (say XML) and optionally i= mplement the other (say JSON)
    =20
    =A0
    =20
    You are advocating for A, Richard was suggesting B.
    =20
    =A0
    =20
    I don't care, but choice C) Both databases and devices have a choi= ce of what to implement doesn't work for me (or Richard).
    =20
    =A0
    =20
    Brian
    =20
    =A0
    =20
    On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe <ben@blindcreek.com> wrote:
    =20


    =20
    Apparently I was unclear.=A0 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.=A0=A0 = If you have two, let the device implementer figure out which is best for th= eir particular device requirements and trade-offs.=A0 This is *preferable* = from my perspective.

    If you provide more than one form in the database, devices using the databa= se need some means for figuring out which are available. It can't use i= t if it doesn't no about it. This is an observations, not an argument ;= -).=A0=A0

    It is my *opinion* at the=A0 moment that if you provide options, to make th= ose useful you need to provide=A0 a protocol by which devices can discover = what options the database supports.=A0 If you have such a mechanism and all= devices use it (a=A0 bootstrap protocol), everything else could be options.=A0 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. T= he device implementer has options and simplicity, so I like it.

    Since I am focused on the TVWS devices that need access to the database, an= d 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.=A0 The database implementer may have another perspective.=A0 Should I point out that there= will be a lot more devices than databases?=A0 That might sound like an arg= ument, though, so I won't....:-j

    Ben


    =20
    Brian is right .. = sorry but the rest of you are wrong. J
    =20
    =A0
    = =20
    This is why you ha= ve MUST and SHOULD in RFC 2119. =A0
    =20
    =A0
    = =20
    This BTW is a clas= sic argument in IETF terms .. but the argument =93let the market decide=94 = only holds so much validity.=A0 You actually have to choose SOMETHING to create a baseline of interoperability.
    =20
    =A0
    = =20
    A virtually identi= cal argument =A0is now playing out in discussions of mandatory audio and co= dec implementations for WEBRTC like things.
    =20
    =A0
    = =20
    IMHO XML MUST anyt= hing else defined SHOULD, but MUST on XML and JSON could work as well. It j= ust leads to a level of complexity in implementations.
    =20
    =A0
    = =20
    End of argument yo= u now can go back to your regularly schedule programming. J
    =20
    =A0
    = =20
    =A0
    = =20
    From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com
    Sent: Thursday, August 23, 2012 5:44 PM
    To: Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com
    Cc: paws@ietf.org
    Subject: Re: [paws] XML schema versus JSON, vCard & iCal<= /div>=20
    =A0
    =20
    =A0
    =20
    I agree with Brian.
    =20
    There needs to be a default mandatory = to implement option in order to achieve interoperability.=A0
    = =20
    And this applies to the device and dat= abase side of the protocol.
    =20
    =A0
    =20
    -Raj
    =20
    =A0
    =20
    From: "<ext Rosen>", &q= uot;Brian.Rosen@neustar.biz" <Brian.Rosen@neustar.biz= >
    Date: Thursday, August 23, 2012 2:43 PM
    To: Don Joslyn <d.joslyn@spectrumbridge.com>
    Cc: "paws@ietf.org" <paws@ietf.org>
    Subject: Re: [paws] XML schema versus JSON, vCard & iCal    <= /div>=20
    =A0
    =20
    One of my favorite IETF expressions is= "There are no protocol police". =A0We 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. =A0On the oth= er hand, the whole point of a protocol document like ours is that two indep= endent implementations who both follow the document will interwork. =A0If t= hat wasn't true, why do you need a standard?
    =20
    =A0
    =20
    If you say "either" to both = ends, then you don't get interoperability. =A0
    =20
    =A0
    =20
    By your argument, we should stop worki= ng, and the product managers will figure it out using proprietary protocols= . =A0The market will decide.
    =20
    =A0
    =20
    So, I feel strongly that if one end is= "either", the other end must be "both". =A0It's al= so acceptable to say both ends implement one choice and the other is option= al at both ends. =A0Here, I think it's server does both and client does either.= =A0
    =20
    =A0
    =20
    It's always possible to build an i= mplementation of a server that only does one: there are no protocol police.=
    =20
    =A0
    =20
    Brian <as individual>=20
    =A0
    =20
    =A0
    =20
    =A0
    =20
    =A0
    =20
    On Aug 23, 2012, at 3:11 PM, Don Josly= n <d.joslyn@spectrumbridge.com> wrote:
    =20



    =20
    Hi Ben,=20
    That was my origin= al suggestion, and I still think it makes the most sense.
    =20
    Thanks for support= ing the proposal.
    =20
    Don
    = =20
    =A0
    = =20
    From:=A0paws-boun= ces@ietf.org [mailto:paws-<= /a>b= ounces@ietf.org]=A0On Behalf Of=A0Benj= amin A. Rolfe
    Sent:=A0Thursday, August 23, 2012 3:05 PM
    To:=A0paws@ietf.org
    Subject:=A0Re: [paws] XML schema versus JSON, vCard &am= p; iCal
    =20
    =A0
    =20
    Someone suggested that PAWS define both, and let the vendors decide wh= ich ones to implement.
    That makes the most sense for both DB and device vendors.=A0 Markets will p= robably drive DB vendors to do both. Device vendors will do what fits the m= arket segment they're after. Why over-constrain (or argue when natural = selection will take care of it for us?).
    B



    =20
    Sounds good to me.
    =20
    =A0
    =20
    From:=A0paws-bounces@ietf.org=A0[mailto:paws-bounces@ietf.org]=A0On Behalf Of=A0Gabor.Bajko@no= kia.com
    Sent:=A0Tuesday, August 21, 2012 12:42 AM
    To:=A0paws@ietf.org Subject:=A0Re: [paws] XML schema versus JSON, vCard &am= p; iCal
    =20
    =A0
    =20
    Now I can=92t see anymore any willingne= ss to agree on one or the other encoding.
    =20
    To prevent endless discussions on this = topic I=92d suggest we move forward with supporting both in the DB and eith= er one in the master device.
    =20
    Any objections?
    =20
    =A0
    =20
    Gabor
    =20
    =A0
    =20
    =A0
    =20
    From:=A0paws-bounces@ietf.org=A0[mailto:paws-bounces@ietf.org]=A0On Behalf Of=A0ext Das, Subir
    Sent:=A0Monday, August 20, 2012 2:50 PM
    To:=A0Don Joslyn; Vincent Chen; Weixinpeng
    Cc:=A0paws@ietf.org; M= anikkoth Sajeev
    Subject:=A0Re: [paws] XML schema versus JSON, vCard &am= p; iCal
    =20
    =A0
    =20
    We have a half a dozen or more TVDB rad= io vendors that use/prefer JSON and we will vote for JSON if we had to pick= one.
    =20
    Also I will copy the following two impo= rtant points:
    =20
    =A0
    =20
      • Simple-to= -use libraries exist for all major languages/platforms
      • Don't need a t= ool chain to work with the data, as is typically needed for XML
      =20
    =A0
    =20
    =A0
    =20
    =A0
    =20
    From:=A0paws-bounces@ietf.org=A0[mailto:paws-bounces@ietf.org]=A0On Behalf Of=A0Don Joslyn
    Sent:=A0Monday, August 20, 2012 4:54 PM
    To:=A0Vincent Chen; Weixinpeng
    Cc:=A0paws@ietf.org; M= anikkoth Sajeev
    Subject:=A0Re: [paws] XML schema versus JSON, vCard &am= p; iCal
    =20
    =A0
    =20
    Please see my comments below=85<= /div>=20
    Thanks,
    =20
    Don
    =20
    =A0
    =20
    From:=A0paws-bounces@ietf.org=A0[mailto:paws-bounces@ietf.org]=A0On Behalf Of=A0Vincent Chen
    Sent:=A0Monday, August 20, 2012 2:56 PM
    To:=A0Weixinpeng
    Cc:=A0paws@ietf.org; M= anikkoth Sajeev
    Subject:=A0Re: [paws] XML schema versus JSON, vCard &am= p; iCal
    =20
    =A0
    =20
    • One = of our goals is to strive to lower the cost and complexity for device manuf= acturers. This lowers the barrier for building a robust ecosystem.
    =20
    [DJ - The =93cost=94 and complexi= ty 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 =93cost=94?]=20
    • To r= educe complexity and cost for device makers, supporting 1 encoding is bette= r than both, as Brian points out. WiFi access points that "just work" anywhere in the world serves as a= good model.
    =20
    [DJ - I proposed that the databas= es support both XML and JSON, devices only need to support one to talk to t= he database. Our current database supports XML and JSON, but if I=92m force= d to pick only one, then I will vote for XML because it=92s the one that we currently use on all embe= dded devices.]
    =20
    • Ther= e's a trend for APIs on the web towards JSON (Twitter, FourSquare, Face= book, Google, etc.). One of the major reasons is that developers (client-side) prefer it for its simplicity:
    =20
      • Repr= esentation closely matches most data models (nested lists and maps)<= /li>
      • = Simple-to-use libraries exist for all major languages/platforms
      • Don&= #39;t need a tool chain to work with the data, as is typically needed for X= ML.
      =20
    Apparently, the efficiency gains of JSON a= lso matter to the scalability of serving systems.
    =20
    =A0
    = =20
    [DJ =96 I can=92t argue against t= hese listed pros for JSON, especially when you=92re dealing with a lot of d= ata (like Twitter, FourSquare, Facebook and Google does). But I=92m assumin= g that PAWS messages will not be exchanged nearly as often as the applications mentioned above. But again, = I know JSON is more efficient, can=92t argue with that.]
    =20
    • At t= he end of the day, it's the data model that matters, rather than the en= coding. 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 de= vices) regarding experiences supporting XML vs JSON.
    =20
    =A0
    =20
    Don, can you elaborate on the types of dev= ices that already support XML?
    =20
    =A0
    =20
    [DJ = - We currently support half a dozen TVDB radio vendors (embedded devices) u= sing 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.]
    =20
    On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng <weixinpeng@huawei.com> wrote:
    =20
    Considering of t= he design of database discovery protocol, the LoST protocol may be used and= LoST is based on XML, so I think XML may be preferred.
    =20
    =A0
    = =20
    --Xinpeng Wei
    =20
    =A0
    = =20
    From:=A0paws-bounces@ietf.org=A0[mailto= :paws-bounces@ietf.org]=A0On Behalf Of=A0Rosen, Brian
    =20

    Sent:=A0Friday, August 17, 2012 9:26 PM
    =20

    Cc:=A0paws@ietf.org Subject:=A0Re: [paws] XML schema versus JSON, vCard &am= p; iCal
    =20
    =A0
    =20
    I don't really care whether we us= e 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 rep= resentation of an existing standard. =A0So, if choosing json means folks fe= el free to ignore existing xml based standards such as xCard and LoST, then I would not want to use json.
    =20
    =A0
    =20
    I would prefer to not have "both= ", because of interoperability complications. =A0If there is rough con= sensus for both, then I would assert that all servers have to implement both and the client can implement either.
    =20
    =A0
    =20
    There are json validators, so I don&#= 39;t think that is a big deal. =A0
    =20
    =A0
    =20
    My experience in protocol design on t= he Internet is that decisions made solely or even largely because of compac= tness advantages rarely are good choices. =A0If you like json because it is smaller, then I believe you need a much better reason. =A0Bi= nary doesn't work for me, at all. =A0I have been involved in big binary= vs text wars in protocol design. =A0Text wins, binary loses, in my opinion= .
    =20
    =A0
    =20
    Brian <as individual>=20
    =A0
    =20
    From:=A0Manikkoth Sajeev <mk= saji@yahoo.com>
    Reply-To:=A0Manikkoth Sajeev <mksaji@yahoo.com>
    Date:=A0Thu, 16 Aug 2012 22:37:38 -0400
    To:=A0"Gabor.Bajko@n= okia.com" <Gabor.Bajko@no= kia.com>, "Rosen, Brian" <brian.rosen@n= eustar.biz>, "vchen@google.com<= /span>" <vchen@google.com&g= t;, "peter@spectrumbridge.com" <peter@spectrumbridge.com>
    Cc:=A0"paws@ietf.org<= /a>" <paws@ietf.org>
    Subject:=A0Re: [paws] XML schema versus JSON, vCard &am= p; iCal
    =20
    =A0
    =20
    Hi,
    =20
    =A0
    =20
    Can it not be both JSON and XML supported? I would vote for that. Future im= plementations may prefer=A0XML as it is generic,=A0omni pre= sent, easy to understand and validate.=A0For compactness may be a=A0=A0binary xml optioncan also wo= rk. JSON I think will necessitate implementation to be native Java and may = not be as friendly with other implementation languages.
    =20
    =A0
    =20
    Best Regards,
    =20
    =A0
    =20
    From:=A0"Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
    To:=A0Brian.Rosen@neust= ar.biz;=A0vchen@google.c= om;=A0peter@spectr= umbridge.com=A0
    Cc:=A0paws@ietf.org=A0
    Sent:=A0Friday, 17 August 2012, 4:55
    Subject:=A0Re: [paws] XML schema versus JSON, vCard &am= p; iCal
    =20

    We have not heard any objections for using JSON encoding instead of XML.=A0
    Therefore, let's go for JSON, and close this thread.

    - Gabor

    -----Original Message-----
    From:=A0paws-bounces@ietf.org=A0[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'
    Subject: Re: [paws] XML schema versus JSON, vCard & iCal

    json is okay with me.=A0=A0
    I'd prefer an ISO time stamp rather than a time in seconds since epoch.= =A0 It's very easy to parse, and its simpler to use and debug.=A0 Don&#= 39;t care a whole lot about that

    Brian <as individual>



    -----Original Message-----
    From: =A0=A0=A0 Vincent Chen [mailto:vchen@google.= com]
    Sent:=A0=A0=A0 Monday, August 13, 2012 06:04 PM Eastern Standard Time
    To:=A0=A0=A0 Peter Stanforth
    Cc:=A0=A0=A0 Rosen, Brian; Teco Boot; Benjamin A.Rolfe;=A0paws@ietf.org
    Subject:=A0=A0=A0 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries exist for numerous languages (see= of=A0http://json.org/) and seem = to be reasonably light weight.

    Timestamps

    As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries 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> wrote:


    =A0=A0=A0 Whenever we built mobile devices we never dealt with IETF, in our= sensor
    =A0=A0=A0 days even an IP stack was a challenge,so I would defer to the dev= ice guys
    =A0=A0=A0 on that one.
    =A0=A0=A0=A0
    =A0=A0=A0 On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"
    =A0=A0=A0=A0
    =A0=A0=A0 <Brian.Rosen@neustar.biz> wrote:
    =A0=A0=A0=A0
    =A0=A0=A0 >Our experience in the IETF over many years is that economizin= g message
    =A0=A0=A0 >size and compromising utility and security in search of effic= iency of
    =A0=A0=A0 >implementation on small devices is a poor trade off.=A0 I am = not advocating
    =A0=A0=A0 >being wasteful of resources, but I don't think we should = seriously
    =A0=A0=A0 >consider the overhead of XML or json to be significant.
    =A0=A0=A0 >
    =A0=A0=A0 >Assuming a json library can be loaded on a small device is re= asonable.
    =A0=A0=A0 >
    =A0=A0=A0 >Brian (as individual)
    =A0=A0=A0 >
    =A0=A0=A0 >
    =A0=A0=A0 >
    =A0=A0=A0 > -----Original Message-----
    =A0=A0=A0 >From:=A0 Peter Stanforth [mailto:peter@spectrumbridge.com]
    =A0=A0=A0 >Sent:=A0 Saturday, August 11, 2012 07:13 AM Eastern Standard = Time
    =A0=A0=A0 >To:=A0 =A0 Teco Boot; Benjamin A.Rolfe
    =A0=A0=A0 >Cc:=A0 =A0=A0paws@ietf.org=
    =A0=A0=A0 >Subject:=A0 =A0 =A0 Re: [paws] XML schema versus JSON, vCard = & iCal
    =A0=A0=A0 >
    =A0=A0=A0 >Not all masters run over the core network.
    =A0=A0=A0 >Some of the Use cases have a master talking to another OTA =A0=A0=A0 >We should not assume that all Masters are attached to utility= power so we
    =A0=A0=A0 >should be sympathetic to processing energy use also.
    =A0=A0=A0 >
    =A0=A0=A0 >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" &l= t;teco@inf-net.nl> wrote:
    =A0=A0=A0 >
    =A0=A0=A0 >>
    =A0=A0=A0 >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe het vol= gende
    =A0=A0=A0 >>geschreven:
    =A0=A0=A0 >>
    =A0=A0=A0 >>> Compactness of messages is important, but it is also= important (to me
    =A0=A0=A0 >>>at least) to be realizable in an implementation with = limited resources,
    =A0=A0=A0 >>>such as embedded devices in what are now popularly ca= lled "M2M"
    =A0=A0=A0 >>>applications.=A0 A lot of these devices could use IP = all the end to end,
    =A0=A0=A0 >>>but may have a very compact, simple stack and applica= tions (i.e.=A0 no
    =A0=A0=A0 >>>browser).=A0 Is JSON typically implemented when there= is no browser?
    =A0=A0=A0 >>>Would it be hard to do in a resource constrained devi= ce (i.e. where we
    =A0=A0=A0 >>>talk about memory size in Kilo-bytes still).
    =A0=A0=A0 >>
    =A0=A0=A0 >>In use cases and requirements document, there are no requ= irements for
    =A0=A0=A0 >>protocol performance. I guess OS/IP/TCP/TLS code size sup= ersedes needs
    =A0=A0=A0 >>for JSON or XML.
    =A0=A0=A0 >>
    =A0=A0=A0 >>Same for timing: TCP/TLS connection setup will take more = than the PAWS
    =A0=A0=A0 >>message exchange, I think. This may be of importance when= using satcom
    =A0=A0=A0 >>links.
    =A0=A0=A0 >>
    =A0=A0=A0 >>Because PAWS runs between master and database, over core = network,
    =A0=A0=A0 >>performance is not our primary concern. But as always, it= is good to keep
    =A0=A0=A0 >>an eye on efficiency.
    =A0=A0=A0 >>
    =A0=A0=A0 >>Teco
    =A0=A0=A0 >>
    =A0=A0=A0 >>> Thanks
    =A0=A0=A0 >>> Ben
    =A0=A0=A0 >>>
    =A0=A0=A0 >>>
    =A0=A0=A0 >>>> We had a discussion on XML vs. JSON. I prefer th= e one with most
    =A0=A0=A0 >>>>compact messages.
    =A0=A0=A0 >>>>
    =A0=A0=A0 >>>> On vCard and JSON: what is the status of "A= JavaScript Object Notation
    =A0=A0=A0 >>>>(JSON) Representation for vCard"?
    =A0=A0=A0 >>>>=A0http://tools.ietf.org/html/draft-bhat-vcarddav-json-= 00
    =A0=A0=A0 >>>>
    =A0=A0=A0 >>>> On valid times: can we use same format as certif= icates? They have
    =A0=A0=A0 >>>>similar simple requirements: valid notBefore&= =A0 notAfter.
    =A0=A0=A0 >>>>=A0http://tools.ietf.org/html/rfc3280#section-4.1.2.5
    =A0=A0=A0 >>>>
    =A0=A0=A0 >>>> Teco
    =A0=A0=A0 >>>> _______________________________________________<= br> =A0=A0=A0 >>>> paws mailing list
    =A0=A0=A0 >>>>=A0paws@ietf.o= rg
    =A0=A0=A0 >>>>=A0https://www.ietf.org/mailman/listinfo/paws
    =A0=A0=A0 >>>>
    =A0=A0=A0 >>>
    =A0=A0=A0 >>> _______________________________________________
    =A0=A0=A0 >>> paws mailing list
    =A0=A0=A0 >>>=A0paws@ietf.org<= /span>
    =A0=A0=A0 >>>=A0https://www.ietf.org/mailman/listinfo/paws
    =A0=A0=A0 >>
    =A0=A0=A0 >>_______________________________________________
    =A0=A0=A0 >>paws mailing list
    =A0=A0=A0 >>paws@ietf.org
    =A0=A0=A0 >>https://www.i= etf.org/mailman/listinfo/paws
    =A0=A0=A0 >
    =A0=A0=A0 >_______________________________________________
    =A0=A0=A0 >paws mailing list
    =A0=A0=A0 >paws@ietf.org
    =A0=A0=A0 >https://www.ietf.= org/mailman/listinfo/paws
    =A0=A0=A0=A0
    =A0=A0=A0 _______________________________________________
    =A0=A0=A0 paws mailing list
    =A0=A0=A0=A0paws@ietf.org
    =A0=A0=A0=A0https:= //www.ietf.org/mailman/listinfo/paws
    =A0=A0=A0=A0




    --=A0
    -vince

    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/li= stinfo/paws
    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/li= stinfo/paws
    =20


    =20
    =A0
    =20
    --=A0
    -vince
    =20 
    =A0
    =20 
    =A0
    =20 
    _______________________________________________
    =20 
    paws mailing list
    =20 
    paws@ietf.org
    =20 
    https://www.ietf.org/mailm=
an/listinfo/paws
    =20
    =A0
    =20
    _____________________________________= __________
    paws mailing list
    paws@ie= tf.org
    https://www.ietf.org/mailman/listinfo/paws
    = =20
    =A0
    =20 
     =A0
    =20 
    _______________________________________________
    =20 
    paws mailing list
    =20 
    pa=
ws@ietf.org
    =20 
    https://www.ietf.org/mailman/listinfo/paws
    =20
    =A0
    =20
    _______________________________________________
    paws mailing list
    paws@ie= tf.org
    https://www.ietf.org/mailman/listinfo/paws
    =20
    =A0
    =20
    =A0
    =20
    =A0
    =20

    _______________________________________________
    paws mailing l= ist
    paws@ietf.org=
    https://www.ietf.org/mailman/listinfo/paws



    _______________________= ________________________
    paws mailing list
    paws@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/paws




    --
    -vince
    --485b397dcd1d97b1ed04c80ecacb-- From cuiyang@huawei.com Fri Aug 24 20:43:42 2012 Return-Path: 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 A936521F84F7 for ; Fri, 24 Aug 2012 20:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.387 X-Spam-Level: X-Spam-Status: No, score=-4.387 tagged_above=-999 required=5 tests=[AWL=1.611, 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 rmSKXk2COJR1 for ; Fri, 24 Aug 2012 20:43:39 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9977B21F84F6 for ; Fri, 24 Aug 2012 20:43:38 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp03-ep.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id ALM00844; Fri, 24 Aug 2012 19:43:38 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Aug 2012 20:37:56 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Aug 2012 20:38:03 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.203]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sat, 25 Aug 2012 11:38:01 +0800 From: Cuiyang To: Manikkoth Sajeev , "Gabor.Bajko@nokia.com" , "Brian.Rosen@neustar.biz" , "ben@blindcreek.com" Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Iet+vcHW33FkKtiTDiFeYExQAAU/5DAIietgAABrI6AAAWoncAABh1noAAifZJAAAEHtuAAAHwqAAADmEvAACA/ioAAAG/7gAAADZjgAABIt+AAAQuNIAAJMQFAAADi+2AAABpNIAAAQX3gAAAI8OAAAL964AAEPRDAAARbYUw Date: Sat, 25 Aug 2012 03:37:59 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE21636860C6D@SZXEML508-MBS.china.huawei.com> References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> <00c601cd820b$67b97170$372c5450$@us> <5037B28B.70501@blindcreek.com> <5D0B1E63-79FE-4BC6-A446-3470931D1043@neustar.biz> <5037BC2B.7010008@blindcreek.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724@008-AM1MPN1-006.mgdnok.nokia.com> <1345864438.6327.YahooMailNeo@web120306.mail.ne1.yahoo.com> In-Reply-To: <1345864438.6327.YahooMailNeo@web120306.mail.ne1.yahoo.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.48.119] Content-Type: multipart/alternative; boundary="_000_8CC0CB0BCAE52F46882E17828A9AE21636860C6DSZXEML508MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 03:43:42 -0000 --_000_8CC0CB0BCAE52F46882E17828A9AE21636860C6DSZXEML508MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgcHJlZmVyIHRvIGJvdGguDQpCdXQgaWYgSSBoYXZlIHRvIGNob29zZSBmcm9tIGlu dGVyb3BlcmFiaWxpdHkgYW5kIOKAnGEgbGl0dGxl4oCdIGNvbXBhY3RuZXNzIG9mIGNvZGVzLCBJ IHdpbGwgdm90ZSBmb3IgWE1MLg0KDQpCZXN0IHJlZ2FyZHMsDQpZYW5nDQo9PT09PT09PT09PT09 PT09PT0NCllhbmcgQ3VpLCAgUGguRC4NCkh1YXdlaSBUZWNobm9sb2dpZXMNCmN1aXlhbmdAaHVh d2VpLmNvbQ0KDQrlj5Hku7bkuro6IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3Mt Ym91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIE1hbmlra290aCBTYWplZXYNCuWPkemAgeaXtumXtDog MjAxMuW5tDjmnIgyNeaXpSAxMToxNA0K5pS25Lu25Lq6OiBHYWJvci5CYWprb0Bub2tpYS5jb207 IEJyaWFuLlJvc2VuQG5ldXN0YXIuYml6OyBiZW5AYmxpbmRjcmVlay5jb20NCuaKhOmAgTogcGF3 c0BpZXRmLm9yZw0K5Li76aKYOiBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZD YXJkICYgaUNhbA0KDQpIaSwNCg0KSSB3b3VsZCBzdGlsbCBzdXBwb3J0IFhNTC4gSlNPTiBsaWJy YXJpZXMgYXJlIGF2YWlsYWJsZSBmb3IgYWxsIGxhbmd1YWdlcy4gQnV0IGludGVyZmFjaW5nIGFu ZCBsaW5raW5nIHN1Y2ggbGlicmFyaWVzIGFyZSBwcm9ibGVtYXRpYyBvbiBlbWJlZGRlZCBkZXZp Y2VzIG1vc3Qgb2YgdGhlIHRpbWUuIEFuZCBpZiBhbiBpbXBsZW1lbnRhdGlvbiB2b3VjaCBmb3Ig bXVsdGlwbGUgc3VjaCBub24gbmF0aXZlIGxhbmd1YWdlIGxpYnJhcmllcyB0aGVuIGRldmVsb3Bl cnMgbGlmZSBpcyBoZWxsLi4uDQoNCkJlc3QgUmVnYXJkcywNCg0KU2FqZWV2IE1hbmlra290aA0K DQpGcm9tOiAiR2Fib3IuQmFqa29Abm9raWEuY29tIiA8R2Fib3IuQmFqa29Abm9raWEuY29tPg0K VG86IEJyaWFuLlJvc2VuQG5ldXN0YXIuYml6OyBiZW5AYmxpbmRjcmVlay5jb20NCkNjOiBwYXdz QGlldGYub3JnDQpTZW50OiBTYXR1cmRheSwgMjUgQXVndXN0IDIwMTIsIDA6MzgNClN1YmplY3Q6 IFJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJiBpQ2FsDQoNCldpRmkg d29ybGQgYnVpbGRzIG9uIG1hbmRhdGluZyB0aGUgaW1wbGVtZW50YXRpb24gKGFuZCBjZXJ0aWZp Y2F0aW9uKSBvZiBhIGJhc2Ugc3BlYywgYW5kIGEgc2V0IG9mIG9wdGlvbmFsIGZlYXR1cmVzLiBJ ZiBhbiBvcHRpb25hbCBmZWF0dXJlIGlzIG5vdCBzdXBwb3J0ZWQgYnkgb25lIG9mIHRoZSBwZWVy cywgdGhleSBjYW4gc3RpbGwgdGFsaywgYnV0IG5vdCB1c2UgdGhhdCBmZWF0dXJlLiBUaGF0IGlz IGJhc2ljYWxseSBvcHRpb24gQikgZnJvbSBCcmFpbuKAmXMgbGlzdC4NCg0KSeKAmWQgbGlrZSB0 byBzdWdnZXN0IHRoYXQgd2UgcmVjb2duaXplIHRoYXQgb3B0aW9uIEEpIGFuZCBCKSBhcmUgdmFs aWQgb3B0aW9ucywgd2hpbGUgb3B0aW9uIEMpIGlzIGludmFsaWQsIGFuZCB3ZSBzaG91bGQgc3Rv cCBkZWJhdGluZyBpdC4NCknigJlkIGFsc28gbGlrZSB0byBhZGQgdGhlIG9idmlvdXMgb3B0aW9u IEQpIHRvIHRoZSBsaXN0LCB3aGljaCBpcyB0aGF0IGJvdGggdGhlIG1hc3RlciBkZXZpY2VzIGFu ZCBEQnMgc3VwcG9ydCBvbmUgYW5kIHRoZSBzYW1lIGVuY29kaW5nIDspDQoNCk9wdGlvbiBBKSBz ZWVtcyB0byBiZSBsaWtlIGEgZ29vZCBjb21wcm9taXNlLCBhbmQgd291bGQgY3V0IGRpc2N1c3Np b25zIHNob3J0LCB3aXRoIHRoZSBvbmx5IGNhdmVhdCB0aGF0IGlmIHRoZXJlIGlzIG5vIHN0cm9u ZyB0ZWNobmljYWwgYXJndW1lbnQgZm9yIHN1cHBvcnRpbmcgYW5kIHNwZWNpZnlpbmcgdHdvIGRp ZmZlcmVudCBlbmNvZGluZ3MsIHRoZW4gdGhlIGllc2cgbWF5IHNlbmQgdGhlIGRvY3VtZW50IGJh Y2sgdG8gdGhlIHdnIHRvIHBpY2sgb25lIG9mIHRoZSB0d28gc3BlY2lmaWVkLiBBcyBSb2JlcnQg bWVudGlvbmVkIGluIGhpcyBlbWFpbCwgdGhpcyBoYXMgaGFwcGVuZWQgaW4gdGhlIHBhc3QsIHNv IGl0IGlzIGxpa2VseSBpdCB3b3VsZCBoYXBwZW4gYWdhaW4uIEFuZCBmcmFua2x5LCBJIGRvIG5v dCBzZWUgYSBzdHJvbmcgYXJndW1lbnQgaW4gZmF2b3Igb2YgdHdvIGRpZmZlcmVudCBlbmNvZGlu Z3MuDQoNCklzIHRoZXJlIGFueW9uZSB3aG8gaGFzIGEgdGVjaG5pY2FsIGFyZ3VtZW50IGFnYWlu c3Qgc3VwcG9ydGluZyBvbmx5IG9uZSBlbmNvZGluZywgYmVpbmcgdGhhdCBlaXRoZXIgeG1sIG9y IGpzb24/DQoNCk1vc3QgcGVvcGxlIHNwZWFrIGluIGZhdm9yIG9mIEpTT04sIGJlY2F1c2UgaXQg aXMgY29tcGFjdCBhbmQgbW9yZSBlZmZpY2llbnQuIEkgd2VudCB0aHJvdWdoIHRoaXMgdGhyZWFk IGFuZCBJIHNhdyAyIG9iamVjdGlvbnMgYWdhaW5zdCBwaWNraW5nIEpTT04uIE9uZSBzYWlkIHRo YXQgSlNPTiByZXF1aXJlcyBuYXRpdmUgSmF2YSwgd2hpY2ggaXMgd3JvbmcsIHRoZSBvdGhlciBv YmplY3Rpb24gZ2F2ZSBubyByZWFsIHJlYXNvbi4gU28gSSBhbSB3b25kZXJpbmcgaWYgdGhlcmUg aXMgcmVhbGx5IGFueSB2YWxpZCB0ZWNobmljYWwgcmVhc29uIGFnYWluc3QgdXNpbmcgSlNPTiBv bmx5Pw0KDQotICAgICAgICAgIEdhYm9yDQoNCg0KRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IFJvc2VuLCBC cmlhbg0KU2VudDogRnJpZGF5LCBBdWd1c3QgMjQsIDIwMTIgMTA6NDMgQU0NClRvOiBCZW5qYW1p biBBLiBSb2xmZQ0KQ2M6IHBhd3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcGF3c10gWE1MIHNj aGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJiBpQ2FsDQoNCk9rYXk6DQoNClNvLCBJIGltcGxlbWVu dCBhIGRhdGFiYXNlLCBhbmQgSSBpbXBsZW1lbnQgWE1MDQpZb3UgaW1wbGVtZW50IGEgZGV2aWNl LCBhbmQgeW91IGltcGxlbWVudCBKU09ODQoNCllvdSBxdWVyeSBteSBkYXRhYmFzZSAobGV0J3Mg bm90IGdldCBpbnRvIGhvdyB5b3UgZG8gdGhhdCBxdWVyeSB3aXRob3V0IGRlY2lkaW5nIFhNTCB2 cyBKU09OKSBhbmQgZGlzY292ZXIgSSBpbXBsZW1lbnQgWE1MIG9ubHkNCg0KV2hhdCBkbyB5b3Ug ZG8/DQoNCkJyaWFuDQoNCk9uIEF1ZyAyNCwgMjAxMiwgYXQgMTozOCBQTSwgIkJlbmphbWluIEEu IFJvbGZlIiA8YmVuQGJsaW5kY3JlZWsuY29tPG1haWx0bzpiZW5AYmxpbmRjcmVlay5jb20+PiB3 cm90ZToNCg0KDQpUaGVyZSBhcmUgdHdvIHdheXMgdG8gYWNoaWV2ZSBpbnRlcm9wZXJhYmlsaXR5 IHdoZW4geW91IGhhdmUgYW4gb3B0aW9uLg0KVGhlcmUgYXJlIG1hbnkgZXhpc3RlbmNlIHByb29m cyBvZiB0aGUgdGhpcmQgd2F5IHRoYXQgSSBtZW50aW9uZWQgYmVsb3cuDQo4MDIuMTEgKyBXaUZp IHByb3ZpZGUgbWFueSBvcHRpb25zIGFuZCBhIG1lYW5zIGZvciBkZXZpY2VzIHRvIHNoYXJlIGlu Zm9ybWF0aW9uIGFib3V0IHdoYXQgb3B0aW9ucyBlYWNoIHN1cHBvcnRzLCB3aXRob3V0IHJlcXVp cmluZyB0aGF0IGFueSBkZXZpY2UgaW1wbGVtZW50IGV2ZXJ5IG9wdGlvbi4gIEl0IHdvcmtzLg0K DQpUaGF0IHNhaWQsIEkgdGhpbmsgKEEpIGlzIHRoZSBiZXN0IGNob2ljZSwgKEIpIGlzIG5vdCBh cyBuaWNlIGZvciBtZSwgYW5kIChDKSBpcyBtb3JlIHdvcmsgdGhhbiBlaXRoZXIgb2YgdGhlIG90 aGVyIHR3by4NCg0KDQpPbmUgaXMgdGhhdCBvbmUgZW5kIGltcGxlbWVudHMgYm90aCBjaG9pY2Vz IGFuZCB0aGUgb3RoZXIgZW5kIGltcGxlbWVudHMgb25lIG9yIGJvdGguDQoNClRoZSBvdGhlciBp cyB0aGF0IGJvdGggZW5kcyBpbXBsZW1lbnQgb25lIHNwZWNpZmljIGNob2ljZSAoIk1VU1QgaW1w bGVtZW50IikgYW5kIGJvdGggY2FuIG9wdGlvbmFsbHkgaW1wbGVtZW50IHRoZSBvdGhlciBjaG9p Y2UuICBPbmx5IGlmIGJvdGggZW5kcyBpbXBsZW1lbnQgdGhlIG90aGVyIGNob2ljZSB3b3VsZCB0 aGF0IGJlIGF2YWlsYWJsZS4NCg0KU28sIGluIHRoaXMgY2FzZSB3ZSBjb3VsZCBkbyBvbmUgb2Yg dGhlIGZvbGxvd2luZzoNCkEpIERhdGFiYXNlcyBpbXBsZW1lbnQgYm90aCBYTUwgYW5kIEpTT04s IGRldmljZXMgaW1wbGVtZW50IGVpdGhlcg0KQikgQm90aCBEYXRhYmFzZXMgYW5kIGRldmljZXMg aW1wbGVtZW50IG9uZSAoc2F5IFhNTCkgYW5kIG9wdGlvbmFsbHkgaW1wbGVtZW50IHRoZSBvdGhl ciAoc2F5IEpTT04pDQoNCllvdSBhcmUgYWR2b2NhdGluZyBmb3IgQSwgUmljaGFyZCB3YXMgc3Vn Z2VzdGluZyBCLg0KDQpJIGRvbid0IGNhcmUsIGJ1dCBjaG9pY2UgQykgQm90aCBkYXRhYmFzZXMg YW5kIGRldmljZXMgaGF2ZSBhIGNob2ljZSBvZiB3aGF0IHRvIGltcGxlbWVudCBkb2Vzbid0IHdv cmsgZm9yIG1lIChvciBSaWNoYXJkKS4NCg0KQnJpYW4NCg0KT24gQXVnIDI0LCAyMDEyLCBhdCAx Mjo1NyBQTSwgQmVuamFtaW4gQS4gUm9sZmUgPGJlbkBibGluZGNyZWVrLmNvbTxtYWlsdG86YmVu QGJsaW5kY3JlZWsuY29tPj4gd3JvdGU6DQoNCkFwcGFyZW50bHkgSSB3YXMgdW5jbGVhci4gIEkg Y2VydGFpbmx5IGFuIGNhcGFibGUgb2YgYmVpbmcgd3JvbmcgYXMgSSBwcmFjdGljZSBvZnRlbiwg YnV0IGluIHRoaXMgY2FzZSBpdCBpcyBxdWl0ZSB1bmxpa2VseSA6LSkuDQoNCllvdSBkbyBub3Qg bmVlZCB0byBjaG9vc2Ugb25seSBvbmUgZm9ybSB0byBhY2hpZXZlIGludGVyb3BlcmFiaWxpdHku ICAgSWYgeW91IGhhdmUgdHdvLCBsZXQgdGhlIGRldmljZSBpbXBsZW1lbnRlciBmaWd1cmUgb3V0 IHdoaWNoIGlzIGJlc3QgZm9yIHRoZWlyIHBhcnRpY3VsYXIgZGV2aWNlIHJlcXVpcmVtZW50cyBh bmQgdHJhZGUtb2Zmcy4gIFRoaXMgaXMgKnByZWZlcmFibGUqIGZyb20gbXkgcGVyc3BlY3RpdmUu DQoNCklmIHlvdSBwcm92aWRlIG1vcmUgdGhhbiBvbmUgZm9ybSBpbiB0aGUgZGF0YWJhc2UsIGRl dmljZXMgdXNpbmcgdGhlIGRhdGFiYXNlIG5lZWQgc29tZSBtZWFucyBmb3IgZmlndXJpbmcgb3V0 IHdoaWNoIGFyZSBhdmFpbGFibGUuIEl0IGNhbid0IHVzZSBpdCBpZiBpdCBkb2Vzbid0IG5vIGFi b3V0IGl0LiBUaGlzIGlzIGFuIG9ic2VydmF0aW9ucywgbm90IGFuIGFyZ3VtZW50IDstKS4NCg0K SXQgaXMgbXkgKm9waW5pb24qIGF0IHRoZSAgbW9tZW50IHRoYXQgaWYgeW91IHByb3ZpZGUgb3B0 aW9ucywgdG8gbWFrZSB0aG9zZSB1c2VmdWwgeW91IG5lZWQgdG8gcHJvdmlkZSAgYSBwcm90b2Nv bCBieSB3aGljaCBkZXZpY2VzIGNhbiBkaXNjb3ZlciB3aGF0IG9wdGlvbnMgdGhlIGRhdGFiYXNl IHN1cHBvcnRzLiAgSWYgeW91IGhhdmUgc3VjaCBhIG1lY2hhbmlzbSBhbmQgYWxsIGRldmljZXMg dXNlIGl0IChhICBib290c3RyYXAgcHJvdG9jb2wpLCBldmVyeXRoaW5nIGVsc2UgY291bGQgYmUg b3B0aW9ucy4gIFRoaXMgcmVxdWlyZXMgYWRkaXRpb25hbCBmdW5jdGlvbnMgaW4gYm90aCBkYXRh YmFzZSBhbmQgZGV2aWNlIGltcGxlbWVudGF0aW9ucy4NCklmIG9uIHRoZSBvdGhlciBoYW5kIHRo ZSBkZXZpY2UgY2FuICJqdXN0IGtub3ciIHRoYXQgdGhlIGRhdGFiYXNlIGhhcyB0d28gZm9ybXMg YXZhaWxhYmxlLCBpdCB3b24ndCBuZWVkIHRvIGR5bmFtaWNhbGx5IGZpZ3VyZSBpdCBvdXQuIFRo ZSBkZXZpY2UgaW1wbGVtZW50ZXIgaGFzIG9wdGlvbnMgYW5kIHNpbXBsaWNpdHksIHNvIEkgbGlr ZSBpdC4NCg0KU2luY2UgSSBhbSBmb2N1c2VkIG9uIHRoZSBUVldTIGRldmljZXMgdGhhdCBuZWVk IGFjY2VzcyB0byB0aGUgZGF0YWJhc2UsIGFuZCBub3QgYSBkYXRhYmFzZSBpbXBsZW1lbnRlciwg c2hpZnRpbmcgYnVyZGVuIG9udG8gdGhlIGRhdGFiYXNlIGltcGxlbWVudGVyIChub3QgbWUpIHRv IHJlZHVjZSB0aGUgYnVyZGVuIG9uIHRoZSBkZXZpY2UgaW1wbGVtZW50ZXIgKG1lKSBpcyBwcmVm ZXJyZWQgZnJvbSBteSBwZXJzcGVjdGl2ZS4gIFRoZSBkYXRhYmFzZSBpbXBsZW1lbnRlciBtYXkg aGF2ZSBhbm90aGVyIHBlcnNwZWN0aXZlLiAgU2hvdWxkIEkgcG9pbnQgb3V0IHRoYXQgdGhlcmUg d2lsbCBiZSBhIGxvdCBtb3JlIGRldmljZXMgdGhhbiBkYXRhYmFzZXM/ICBUaGF0IG1pZ2h0IHNv dW5kIGxpa2UgYW4gYXJndW1lbnQsIHRob3VnaCwgc28gSSB3b24ndC4uLi46LWoNCg0KQmVuDQoN CkJyaWFuIGlzIHJpZ2h0IC4uIHNvcnJ5IGJ1dCB0aGUgcmVzdCBvZiB5b3UgYXJlIHdyb25nLiDi mLoNCg0KVGhpcyBpcyB3aHkgeW91IGhhdmUgTVVTVCBhbmQgU0hPVUxEIGluIFJGQyAyMTE5Lg0K DQpUaGlzIEJUVyBpcyBhIGNsYXNzaWMgYXJndW1lbnQgaW4gSUVURiB0ZXJtcyAuLiBidXQgdGhl IGFyZ3VtZW50IOKAnGxldCB0aGUgbWFya2V0IGRlY2lkZeKAnSBvbmx5IGhvbGRzIHNvIG11Y2gg dmFsaWRpdHkuICBZb3UgYWN0dWFsbHkgaGF2ZSB0byBjaG9vc2UgU09NRVRISU5HIHRvIGNyZWF0 ZSBhIGJhc2VsaW5lIG9mIGludGVyb3BlcmFiaWxpdHkuDQoNCkEgdmlydHVhbGx5IGlkZW50aWNh bCBhcmd1bWVudCAgaXMgbm93IHBsYXlpbmcgb3V0IGluIGRpc2N1c3Npb25zIG9mIG1hbmRhdG9y eSBhdWRpbyBhbmQgY29kZWMgaW1wbGVtZW50YXRpb25zIGZvciBXRUJSVEMgbGlrZSB0aGluZ3Mu DQoNCklNSE8gWE1MIE1VU1QgYW55dGhpbmcgZWxzZSBkZWZpbmVkIFNIT1VMRCwgYnV0IE1VU1Qg b24gWE1MIGFuZCBKU09OIGNvdWxkIHdvcmsgYXMgd2VsbC4gSXQganVzdCBsZWFkcyB0byBhIGxl dmVsIG9mIGNvbXBsZXhpdHkgaW4gaW1wbGVtZW50YXRpb25zLg0KDQpFbmQgb2YgYXJndW1lbnQg eW91IG5vdyBjYW4gZ28gYmFjayB0byB5b3VyIHJlZ3VsYXJseSBzY2hlZHVsZSBwcm9ncmFtbWlu Zy4g4pi6DQoNCg0KRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwYXdzLWJvdW5j ZXNAaWV0Zi5vcmc+IFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbTxtYWlsdG86QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNv bT4NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjMsIDIwMTIgNTo0NCBQTQ0KVG86IEJyaWFuLlJv c2VuQG5ldXN0YXIuYml6PG1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej47IGQuam9zbHlu QHNwZWN0cnVtYnJpZGdlLmNvbTxtYWlsdG86ZC5qb3NseW5Ac3BlY3RydW1icmlkZ2UuY29tPg0K Q2M6IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Bh d3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJkICYgaUNhbA0KDQoNCkkgYWdyZWUgd2l0 aCBCcmlhbi4NClRoZXJlIG5lZWRzIHRvIGJlIGEgZGVmYXVsdCBtYW5kYXRvcnkgdG8gaW1wbGVt ZW50IG9wdGlvbiBpbiBvcmRlciB0byBhY2hpZXZlIGludGVyb3BlcmFiaWxpdHkuDQpBbmQgdGhp cyBhcHBsaWVzIHRvIHRoZSBkZXZpY2UgYW5kIGRhdGFiYXNlIHNpZGUgb2YgdGhlIHByb3RvY29s Lg0KDQotUmFqDQoNCkZyb206ICI8ZXh0IFJvc2VuPiIsICJCcmlhbi5Sb3NlbkBuZXVzdGFyLmJp ejxtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo+IiA8QnJpYW4uUm9zZW5AbmV1c3Rhci5i aXo8bWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6Pj4NCkRhdGU6IFRodXJzZGF5LCBBdWd1 c3QgMjMsIDIwMTIgMjo0MyBQTQ0KVG86IERvbiBKb3NseW4gPGQuam9zbHluQHNwZWN0cnVtYnJp ZGdlLmNvbTxtYWlsdG86ZC5qb3NseW5Ac3BlY3RydW1icmlkZ2UuY29tPj4NCkNjOiAicGF3c0Bp ZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4iIDxwYXdzQGlldGYub3JnPG1haWx0bzpwYXdz QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwg dkNhcmQgJiBpQ2FsDQoNCk9uZSBvZiBteSBmYXZvcml0ZSBJRVRGIGV4cHJlc3Npb25zIGlzICJU aGVyZSBhcmUgbm8gcHJvdG9jb2wgcG9saWNlIi4gIFdlIGFwcGx5IHRoYXQgaW4gbG90cyBvZiB3 YXlzLCBidXQgb25lIG9mIHRoZW0gaXMgdGhhdCBpZiB5b3UgZG9uJ3QgaW1wbGVtZW50IHdoYXQg dGhlIGRvY3VtZW50IHNheXMsIHlvdSBtYXkgbm90IGdldCBpbnRlcm9wZXJhYmlsaXR5IHdpdGgg b3RoZXIgaW1wbGVtZW50YXRpb25zLiAgT24gdGhlIG90aGVyIGhhbmQsIHRoZSB3aG9sZSBwb2lu dCBvZiBhIHByb3RvY29sIGRvY3VtZW50IGxpa2Ugb3VycyBpcyB0aGF0IHR3byBpbmRlcGVuZGVu dCBpbXBsZW1lbnRhdGlvbnMgd2hvIGJvdGggZm9sbG93IHRoZSBkb2N1bWVudCB3aWxsIGludGVy d29yay4gIElmIHRoYXQgd2Fzbid0IHRydWUsIHdoeSBkbyB5b3UgbmVlZCBhIHN0YW5kYXJkPw0K DQpJZiB5b3Ugc2F5ICJlaXRoZXIiIHRvIGJvdGggZW5kcywgdGhlbiB5b3UgZG9uJ3QgZ2V0IGlu dGVyb3BlcmFiaWxpdHkuDQoNCkJ5IHlvdXIgYXJndW1lbnQsIHdlIHNob3VsZCBzdG9wIHdvcmtp bmcsIGFuZCB0aGUgcHJvZHVjdCBtYW5hZ2VycyB3aWxsIGZpZ3VyZSBpdCBvdXQgdXNpbmcgcHJv cHJpZXRhcnkgcHJvdG9jb2xzLiAgVGhlIG1hcmtldCB3aWxsIGRlY2lkZS4NCg0KU28sIEkgZmVl bCBzdHJvbmdseSB0aGF0IGlmIG9uZSBlbmQgaXMgImVpdGhlciIsIHRoZSBvdGhlciBlbmQgbXVz dCBiZSAiYm90aCIuICBJdCdzIGFsc28gYWNjZXB0YWJsZSB0byBzYXkgYm90aCBlbmRzIGltcGxl bWVudCBvbmUgY2hvaWNlIGFuZCB0aGUgb3RoZXIgaXMgb3B0aW9uYWwgYXQgYm90aCBlbmRzLiAg SGVyZSwgSSB0aGluayBpdCdzIHNlcnZlciBkb2VzIGJvdGggYW5kIGNsaWVudCBkb2VzIGVpdGhl ci4NCg0KSXQncyBhbHdheXMgcG9zc2libGUgdG8gYnVpbGQgYW4gaW1wbGVtZW50YXRpb24gb2Yg YSBzZXJ2ZXIgdGhhdCBvbmx5IGRvZXMgb25lOiB0aGVyZSBhcmUgbm8gcHJvdG9jb2wgcG9saWNl Lg0KDQpCcmlhbiA8YXMgaW5kaXZpZHVhbD4NCg0KDQoNCg0KT24gQXVnIDIzLCAyMDEyLCBhdCAz OjExIFBNLCBEb24gSm9zbHluIDxkLmpvc2x5bkBzcGVjdHJ1bWJyaWRnZS5jb208bWFpbHRvOmQu am9zbHluQHNwZWN0cnVtYnJpZGdlLmNvbT4+IHdyb3RlOg0KDQoNCkhpIEJlbiwNClRoYXQgd2Fz IG15IG9yaWdpbmFsIHN1Z2dlc3Rpb24sIGFuZCBJIHN0aWxsIHRoaW5rIGl0IG1ha2VzIHRoZSBt b3N0IHNlbnNlLg0KVGhhbmtzIGZvciBzdXBwb3J0aW5nIHRoZSBwcm9wb3NhbC4NCkRvbg0KDQpG cm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZz4g W21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmJvdW5jZXNAaWV0Zi5vcmc+XSBP biBCZWhhbGYgT2YgQmVuamFtaW4gQS4gUm9sZmUNClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjMs IDIwMTIgMzowNSBQTQ0KVG86IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJkICYgaUNhbA0K DQpTb21lb25lIHN1Z2dlc3RlZCB0aGF0IFBBV1MgZGVmaW5lIGJvdGgsIGFuZCBsZXQgdGhlIHZl bmRvcnMgZGVjaWRlIHdoaWNoIG9uZXMgdG8gaW1wbGVtZW50Lg0KVGhhdCBtYWtlcyB0aGUgbW9z dCBzZW5zZSBmb3IgYm90aCBEQiBhbmQgZGV2aWNlIHZlbmRvcnMuICBNYXJrZXRzIHdpbGwgcHJv YmFibHkgZHJpdmUgREIgdmVuZG9ycyB0byBkbyBib3RoLiBEZXZpY2UgdmVuZG9ycyB3aWxsIGRv IHdoYXQgZml0cyB0aGUgbWFya2V0IHNlZ21lbnQgdGhleSdyZSBhZnRlci4gV2h5IG92ZXItY29u c3RyYWluIChvciBhcmd1ZSB3aGVuIG5hdHVyYWwgc2VsZWN0aW9uIHdpbGwgdGFrZSBjYXJlIG9m IGl0IGZvciB1cz8pLg0KQg0KDQoNClNvdW5kcyBnb29kIHRvIG1lLg0KDQpGcm9tOiBwYXdzLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpwYXdz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHYWJvci5CYWprb0Bub2tpYS5jb208bWFp bHRvOkdhYm9yLkJhamtvQG5va2lhLmNvbT4NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyMSwgMjAx MiAxMjo0MiBBTQ0KVG86IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJkICYgaUNhbA0KDQpO b3cgSSBjYW7igJl0IHNlZSBhbnltb3JlIGFueSB3aWxsaW5nbmVzcyB0byBhZ3JlZSBvbiBvbmUg b3IgdGhlIG90aGVyIGVuY29kaW5nLg0KVG8gcHJldmVudCBlbmRsZXNzIGRpc2N1c3Npb25zIG9u IHRoaXMgdG9waWMgSeKAmWQgc3VnZ2VzdCB3ZSBtb3ZlIGZvcndhcmQgd2l0aCBzdXBwb3J0aW5n IGJvdGggaW4gdGhlIERCIGFuZCBlaXRoZXIgb25lIGluIHRoZSBtYXN0ZXIgZGV2aWNlLg0KQW55 IG9iamVjdGlvbnM/DQoNCkdhYm9yDQoNCg0KRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgZXh0IERhcywgU3ViaXINClNlbnQ6IE1vbmRheSwgQXVndXN0IDIwLCAy MDEyIDI6NTAgUE0NClRvOiBEb24gSm9zbHluOyBWaW5jZW50IENoZW47IFdlaXhpbnBlbmcNCkNj OiBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPjsgTWFuaWtrb3RoIFNhamVldg0K U3ViamVjdDogUmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmIGlDYWwN Cg0KV2UgaGF2ZSBhIGhhbGYgYSBkb3plbiBvciBtb3JlIFRWREIgcmFkaW8gdmVuZG9ycyB0aGF0 IHVzZS9wcmVmZXIgSlNPTiBhbmQgd2Ugd2lsbCB2b3RlIGZvciBKU09OIGlmIHdlIGhhZCB0byBw aWNrIG9uZS4NCkFsc28gSSB3aWxsIGNvcHkgdGhlIGZvbGxvd2luZyB0d28gaW1wb3J0YW50IHBv aW50czoNCg0KDQogICAgICogICBTaW1wbGUtdG8tdXNlIGxpYnJhcmllcyBleGlzdCBmb3IgYWxs IG1ham9yIGxhbmd1YWdlcy9wbGF0Zm9ybXMNCiAgICAgKiAgIERvbid0IG5lZWQgYSB0b29sIGNo YWluIHRvIHdvcmsgd2l0aCB0aGUgZGF0YSwgYXMgaXMgdHlwaWNhbGx5IG5lZWRlZCBmb3IgWE1M DQoNCg0KDQpGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnBhd3MtYm91bmNlc0Bp ZXRmLm9yZz4gW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddPG1haWx0bzpbbWFpbHRvOnBh d3MtYm91bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFsZiBPZiBEb24gSm9zbHluDQpTZW50OiBNb25k YXksIEF1Z3VzdCAyMCwgMjAxMiA0OjU0IFBNDQpUbzogVmluY2VudCBDaGVuOyBXZWl4aW5wZW5n DQpDYzogcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz47IE1hbmlra290aCBTYWpl ZXYNClN1YmplY3Q6IFJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJiBp Q2FsDQoNClBsZWFzZSBzZWUgbXkgY29tbWVudHMgYmVsb3figKYNClRoYW5rcywNCkRvbg0KDQpG cm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZz4g W21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBWaW5jZW50IENoZW4N ClNlbnQ6IE1vbmRheSwgQXVndXN0IDIwLCAyMDEyIDI6NTYgUE0NClRvOiBXZWl4aW5wZW5nDQpD YzogcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz47IE1hbmlra290aCBTYWplZXYN ClN1YmplY3Q6IFJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJiBpQ2Fs DQoNCg0KICAqICAgT25lIG9mIG91ciBnb2FscyBpcyB0byBzdHJpdmUgdG8gbG93ZXIgdGhlIGNv c3QgYW5kIGNvbXBsZXhpdHkgZm9yIGRldmljZSBtYW51ZmFjdHVyZXJzLiBUaGlzIGxvd2VycyB0 aGUgYmFycmllciBmb3IgYnVpbGRpbmcgYSByb2J1c3QgZWNvc3lzdGVtLg0KW0RKIC0gVGhlIOKA nGNvc3TigJ0gYW5kIGNvbXBsZXhpdHkgb2YgdXNpbmcgWE1MIGhhcyBub3QgYmVlbiBhbiBpc3N1 ZSBmb3IgdGhlIGhhbGYgZG96ZW4gVFZCRCB2ZW5kb3JzIHRoYXQgaGF2ZSBhbHJlYWR5IHVzZWQg WE1MLiBNYXliZSB3ZSBuZWVkIHRvIGJldHRlciBkZWZpbmUg4oCcY29zdOKAnT9dDQoNCiAgKiAg IFRvIHJlZHVjZSBjb21wbGV4aXR5IGFuZCBjb3N0IGZvciBkZXZpY2UgbWFrZXJzLCBzdXBwb3J0 aW5nIDEgZW5jb2RpbmcgaXMgYmV0dGVyIHRoYW4gYm90aCwgYXMgQnJpYW4gcG9pbnRzIG91dC4g V2lGaSBhY2Nlc3MgcG9pbnRzIHRoYXQgImp1c3Qgd29yayIgYW55d2hlcmUgaW4gdGhlIHdvcmxk IHNlcnZlcyBhcyBhIGdvb2QgbW9kZWwuDQpbREogLSBJIHByb3Bvc2VkIHRoYXQgdGhlIGRhdGFi YXNlcyBzdXBwb3J0IGJvdGggWE1MIGFuZCBKU09OLCBkZXZpY2VzIG9ubHkgbmVlZCB0byBzdXBw b3J0IG9uZSB0byB0YWxrIHRvIHRoZSBkYXRhYmFzZS4gT3VyIGN1cnJlbnQgZGF0YWJhc2Ugc3Vw cG9ydHMgWE1MIGFuZCBKU09OLCBidXQgaWYgSeKAmW0gZm9yY2VkIHRvIHBpY2sgb25seSBvbmUs IHRoZW4gSSB3aWxsIHZvdGUgZm9yIFhNTCBiZWNhdXNlIGl04oCZcyB0aGUgb25lIHRoYXQgd2Ug Y3VycmVudGx5IHVzZSBvbiBhbGwgZW1iZWRkZWQgZGV2aWNlcy5dDQoNCiAgKiAgIFRoZXJlJ3Mg YSB0cmVuZCBmb3IgQVBJcyBvbiB0aGUgd2ViIHRvd2FyZHMgSlNPTiAoVHdpdHRlciwgRm91clNx dWFyZSwgRmFjZWJvb2ssIEdvb2dsZSwgZXRjLikuIE9uZSBvZiB0aGUgbWFqb3IgcmVhc29ucyBp cyB0aGF0IGRldmVsb3BlcnMgKGNsaWVudC1zaWRlKSBwcmVmZXIgaXQgZm9yIGl0cyBzaW1wbGlj aXR5Og0KDQogICAgICogICBSZXByZXNlbnRhdGlvbiBjbG9zZWx5IG1hdGNoZXMgbW9zdCBkYXRh IG1vZGVscyAobmVzdGVkIGxpc3RzIGFuZCBtYXBzKQ0KICAgICAqICAgU2ltcGxlLXRvLXVzZSBs aWJyYXJpZXMgZXhpc3QgZm9yIGFsbCBtYWpvciBsYW5ndWFnZXMvcGxhdGZvcm1zDQogICAgICog ICBEb24ndCBuZWVkIGEgdG9vbCBjaGFpbiB0byB3b3JrIHdpdGggdGhlIGRhdGEsIGFzIGlzIHR5 cGljYWxseSBuZWVkZWQgZm9yIFhNTC4NCkFwcGFyZW50bHksIHRoZSBlZmZpY2llbmN5IGdhaW5z IG9mIEpTT04gYWxzbyBtYXR0ZXIgdG8gdGhlIHNjYWxhYmlsaXR5IG9mIHNlcnZpbmcgc3lzdGVt cy4NCg0KW0RKIOKAkyBJIGNhbuKAmXQgYXJndWUgYWdhaW5zdCB0aGVzZSBsaXN0ZWQgcHJvcyBm b3IgSlNPTiwgZXNwZWNpYWxseSB3aGVuIHlvdeKAmXJlIGRlYWxpbmcgd2l0aCBhIGxvdCBvZiBk YXRhIChsaWtlIFR3aXR0ZXIsIEZvdXJTcXVhcmUsIEZhY2Vib29rIGFuZCBHb29nbGUgZG9lcyku IEJ1dCBJ4oCZbSBhc3N1bWluZyB0aGF0IFBBV1MgbWVzc2FnZXMgd2lsbCBub3QgYmUgZXhjaGFu Z2VkIG5lYXJseSBhcyBvZnRlbiBhcyB0aGUgYXBwbGljYXRpb25zIG1lbnRpb25lZCBhYm92ZS4g QnV0IGFnYWluLCBJIGtub3cgSlNPTiBpcyBtb3JlIGVmZmljaWVudCwgY2Fu4oCZdCBhcmd1ZSB3 aXRoIHRoYXQuXQ0KDQogICogICBBdCB0aGUgZW5kIG9mIHRoZSBkYXksIGl0J3MgdGhlIGRhdGEg bW9kZWwgdGhhdCBtYXR0ZXJzLCByYXRoZXIgdGhhbiB0aGUgZW5jb2RpbmcuIFdlIChHb29nbGUp IGFyZSBhY3R1YWxseSBuZXV0cmFsIG9uIFhNTCB2cyBKU09OLCBhcyBsb25nIGFzIHdlJ3JlIGNs ZWFyIG9uIHdoYXQgZGV2aWNlIG1ha2VycyB3YW50LiBJdCB3b3VsZCBiZSBnb29kIHRvIGdldCBm ZWVkYmFjayBmcm9tIGRldmljZSBtYWtlcnMgKGVzcGVjaWFsbHkgb2YgZW1iZWRkZWQgZGV2aWNl cykgcmVnYXJkaW5nIGV4cGVyaWVuY2VzIHN1cHBvcnRpbmcgWE1MIHZzIEpTT04uDQoNCkRvbiwg Y2FuIHlvdSBlbGFib3JhdGUgb24gdGhlIHR5cGVzIG9mIGRldmljZXMgdGhhdCBhbHJlYWR5IHN1 cHBvcnQgWE1MPw0KDQpbREogLSBXZSBjdXJyZW50bHkgc3VwcG9ydCBoYWxmIGEgZG96ZW4gVFZE QiByYWRpbyB2ZW5kb3JzIChlbWJlZGRlZCBkZXZpY2VzKSB1c2luZyBYTUwsIG5vbiB1c2luZyBK U09OLiBYTUwgaGFzIG5vdCBiZWVuIGEgYnVyZGVuLCBhbmQgdGhlIGFtb3VudCBvZiBkYXRhIHRo YXQgbmVlZHMgdG8gYmUgZXhjaGFuZ2VkIGJldHdlZW4gZGV2aWNlIGFuZCBkYXRhYmFzZSBpcyBu b3QgdGhhdCBtdWNoIG9yIGV4Y2hhbmdlZCB0aGF0IG9mdGVuLl0NCk9uIEZyaSwgQXVnIDE3LCAy MDEyIGF0IDY6MDYgUE0sIFdlaXhpbnBlbmcgPHdlaXhpbnBlbmdAaHVhd2VpLmNvbTxtYWlsdG86 d2VpeGlucGVuZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQpDb25zaWRlcmluZyBvZiB0aGUgZGVzaWdu IG9mIGRhdGFiYXNlIGRpc2NvdmVyeSBwcm90b2NvbCwgdGhlIExvU1QgcHJvdG9jb2wgbWF5IGJl IHVzZWQgYW5kIExvU1QgaXMgYmFzZWQgb24gWE1MLCBzbyBJIHRoaW5rIFhNTCBtYXkgYmUgcHJl ZmVycmVkLg0KDQotLVhpbnBlbmcgV2VpDQoNCkZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFJvc2VuLCBCcmlh bg0KDQpTZW50OiBGcmlkYXksIEF1Z3VzdCAxNywgMjAxMiA5OjI2IFBNDQpUbzogTWFuaWtrb3Ro IFNhamVldjsgZ2Fib3IuYmFqa29Abm9raWEuY29tPG1haWx0bzpnYWJvci5iYWprb0Bub2tpYS5j b20+OyB2Y2hlbkBnb29nbGUuY29tPG1haWx0bzp2Y2hlbkBnb29nbGUuY29tPjsgcGV0ZXJAc3Bl Y3RydW1icmlkZ2UuY29tPG1haWx0bzpwZXRlckBzcGVjdHJ1bWJyaWRnZS5jb20+DQoNCkNjOiBw YXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtwYXdzXSBY TUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmIGlDYWwNCg0KSSBkb24ndCByZWFsbHkgY2Fy ZSB3aGV0aGVyIHdlIHVzZSBqc29uIG9yIHhtbCBhcyBhIG1hdHRlciBvZiBwcm90b2NvbCBkZXNp Z24gb3IgaW1wbGVtZW50YXRpb24sIGJ1dCBJIGFtIGEgYmlnIGZhbiBvZiByZXVzaW5nIHN0YW5k YXJkcyByYXRoZXIgdGhhbiBkZWZpbmluZyBuZXcgb25lcywgYW5kIEkgd291bGQgbm90IHdhbnQg dG8gc2VlIHRoZSBjaG9pY2Ugb2YganNvbiBtZWFuIHdlIHRoZW4gZGVjaWRlIHRvIHJvbGwgb3Vy IG93biB2ZXJzdXMgdXNpbmcgZXhpc3Rpbmcgc3RhbmRhcmRzIGJhc2VkIG9uIHRoZSBpZGVhIHRo ZXJlIGlzIG5vIGpzb24gcmVwcmVzZW50YXRpb24gb2YgYW4gZXhpc3Rpbmcgc3RhbmRhcmQuICBT bywgaWYgY2hvb3NpbmcganNvbiBtZWFucyBmb2xrcyBmZWVsIGZyZWUgdG8gaWdub3JlIGV4aXN0 aW5nIHhtbCBiYXNlZCBzdGFuZGFyZHMgc3VjaCBhcyB4Q2FyZCBhbmQgTG9TVCwgdGhlbiBJIHdv dWxkIG5vdCB3YW50IHRvIHVzZSBqc29uLg0KDQpJIHdvdWxkIHByZWZlciB0byBub3QgaGF2ZSAi Ym90aCIsIGJlY2F1c2Ugb2YgaW50ZXJvcGVyYWJpbGl0eSBjb21wbGljYXRpb25zLiAgSWYgdGhl cmUgaXMgcm91Z2ggY29uc2Vuc3VzIGZvciBib3RoLCB0aGVuIEkgd291bGQgYXNzZXJ0IHRoYXQg YWxsIHNlcnZlcnMgaGF2ZSB0byBpbXBsZW1lbnQgYm90aCBhbmQgdGhlIGNsaWVudCBjYW4gaW1w bGVtZW50IGVpdGhlci4NCg0KVGhlcmUgYXJlIGpzb24gdmFsaWRhdG9ycywgc28gSSBkb24ndCB0 aGluayB0aGF0IGlzIGEgYmlnIGRlYWwuDQoNCk15IGV4cGVyaWVuY2UgaW4gcHJvdG9jb2wgZGVz aWduIG9uIHRoZSBJbnRlcm5ldCBpcyB0aGF0IGRlY2lzaW9ucyBtYWRlIHNvbGVseSBvciBldmVu IGxhcmdlbHkgYmVjYXVzZSBvZiBjb21wYWN0bmVzcyBhZHZhbnRhZ2VzIHJhcmVseSBhcmUgZ29v ZCBjaG9pY2VzLiAgSWYgeW91IGxpa2UganNvbiBiZWNhdXNlIGl0IGlzIHNtYWxsZXIsIHRoZW4g SSBiZWxpZXZlIHlvdSBuZWVkIGEgbXVjaCBiZXR0ZXIgcmVhc29uLiAgQmluYXJ5IGRvZXNuJ3Qg d29yayBmb3IgbWUsIGF0IGFsbC4gIEkgaGF2ZSBiZWVuIGludm9sdmVkIGluIGJpZyBiaW5hcnkg dnMgdGV4dCB3YXJzIGluIHByb3RvY29sIGRlc2lnbi4gIFRleHQgd2lucywgYmluYXJ5IGxvc2Vz LCBpbiBteSBvcGluaW9uLg0KDQpCcmlhbiA8YXMgaW5kaXZpZHVhbD4NCg0KRnJvbTogTWFuaWtr b3RoIFNhamVldiA8bWtzYWppQHlhaG9vLmNvbTxtYWlsdG86bWtzYWppQHlhaG9vLmNvbT4+DQpS ZXBseS1UbzogTWFuaWtrb3RoIFNhamVldiA8bWtzYWppQHlhaG9vLmNvbTxtYWlsdG86bWtzYWpp QHlhaG9vLmNvbT4+DQpEYXRlOiBUaHUsIDE2IEF1ZyAyMDEyIDIyOjM3OjM4IC0wNDAwDQpUbzog IkdhYm9yLkJhamtvQG5va2lhLmNvbTxtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tPiIgPEdh Ym9yLkJhamtvQG5va2lhLmNvbTxtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tPj4sICJSb3Nl biwgQnJpYW4iIDxicmlhbi5yb3NlbkBuZXVzdGFyLmJpejxtYWlsdG86YnJpYW4ucm9zZW5AbmV1 c3Rhci5iaXo+PiwgInZjaGVuQGdvb2dsZS5jb208bWFpbHRvOnZjaGVuQGdvb2dsZS5jb20+IiA8 dmNoZW5AZ29vZ2xlLmNvbTxtYWlsdG86dmNoZW5AZ29vZ2xlLmNvbT4+LCAicGV0ZXJAc3BlY3Ry dW1icmlkZ2UuY29tPG1haWx0bzpwZXRlckBzcGVjdHJ1bWJyaWRnZS5jb20+IiA8cGV0ZXJAc3Bl Y3RydW1icmlkZ2UuY29tPG1haWx0bzpwZXRlckBzcGVjdHJ1bWJyaWRnZS5jb20+Pg0KQ2M6ICJw YXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPiIgPHBhd3NAaWV0Zi5vcmc8bWFpbHRv OnBhd3NAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBK U09OLCB2Q2FyZCAmIGlDYWwNCg0KSGksDQoNCkNhbiBpdCBub3QgYmUgYm90aCBKU09OIGFuZCBY TUwgc3VwcG9ydGVkPyBJIHdvdWxkIHZvdGUgZm9yIHRoYXQuIEZ1dHVyZSBpbXBsZW1lbnRhdGlv bnMgbWF5IHByZWZlciBYTUwgYXMgaXQgaXMgZ2VuZXJpYywgb21uaSBwcmVzZW50LCBlYXN5IHRv IHVuZGVyc3RhbmQgYW5kIHZhbGlkYXRlLiBGb3IgY29tcGFjdG5lc3MgbWF5IGJlIGEgIGJpbmFy eSB4bWwgb3B0aW9uY2FuIGFsc28gd29yay4gSlNPTiBJIHRoaW5rIHdpbGwgbmVjZXNzaXRhdGUg aW1wbGVtZW50YXRpb24gdG8gYmUgbmF0aXZlIEphdmEgYW5kIG1heSBub3QgYmUgYXMgZnJpZW5k bHkgd2l0aCBvdGhlciBpbXBsZW1lbnRhdGlvbiBsYW5ndWFnZXMuDQoNCkJlc3QgUmVnYXJkcywN ClNhamVldiBNYW5pa2tvdGgNCk1vYmlsZTogKzkxODc5MjI5MjAwMg0KRW1haWw6IG1rc2FqaUBp ZWVlLm9yZzxtYWlsdG86bWtzYWppQGllZWUub3JnPg0KaHR0cDovL3d3dy5saW5rZWRpbi5jb20v aW4vbWtzYWplZXYNCg0KRnJvbTogIkdhYm9yLkJhamtvQG5va2lhLmNvbTxtYWlsdG86R2Fib3Iu QmFqa29Abm9raWEuY29tPiIgPEdhYm9yLkJhamtvQG5va2lhLmNvbTxtYWlsdG86R2Fib3IuQmFq a29Abm9raWEuY29tPj4NClRvOiBCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpejxtYWlsdG86QnJpYW4u Um9zZW5AbmV1c3Rhci5iaXo+OyB2Y2hlbkBnb29nbGUuY29tPG1haWx0bzp2Y2hlbkBnb29nbGUu Y29tPjsgcGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tPG1haWx0bzpwZXRlckBzcGVjdHJ1bWJyaWRn ZS5jb20+DQpDYzogcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NClNlbnQ6IEZy aWRheSwgMTcgQXVndXN0IDIwMTIsIDQ6NTUNClN1YmplY3Q6IFJlOiBbcGF3c10gWE1MIHNjaGVt YSB2ZXJzdXMgSlNPTiwgdkNhcmQgJiBpQ2FsDQoNCldlIGhhdmUgbm90IGhlYXJkIGFueSBvYmpl Y3Rpb25zIGZvciB1c2luZyBKU09OIGVuY29kaW5nIGluc3RlYWQgb2YgWE1MLg0KVGhlcmVmb3Jl LCBsZXQncyBnbyBmb3IgSlNPTiwgYW5kIGNsb3NlIHRoaXMgdGhyZWFkLg0KDQotIEdhYm9yDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBleHQgUm9zZW4s IEJyaWFuDQpTZW50OiBNb25kYXksIEF1Z3VzdCAxMywgMjAxMiAzOjE0IFBNDQpUbzogJ1ZpbmNl bnQgQ2hlbic7ICdQZXRlciBTdGFuZm9ydGgnDQpDYzogJ3Bhd3NAaWV0Zi5vcmc8bWFpbHRvOnBh d3NAaWV0Zi5vcmc+Jw0KU3ViamVjdDogUmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09O LCB2Q2FyZCAmIGlDYWwNCg0KanNvbiBpcyBva2F5IHdpdGggbWUuDQpJJ2QgcHJlZmVyIGFuIElT TyB0aW1lIHN0YW1wIHJhdGhlciB0aGFuIGEgdGltZSBpbiBzZWNvbmRzIHNpbmNlIGVwb2NoLiAg SXQncyB2ZXJ5IGVhc3kgdG8gcGFyc2UsIGFuZCBpdHMgc2ltcGxlciB0byB1c2UgYW5kIGRlYnVn LiAgRG9uJ3QgY2FyZSBhIHdob2xlIGxvdCBhYm91dCB0aGF0DQoNCkJyaWFuIDxhcyBpbmRpdmlk dWFsPg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206ICAgICBWaW5jZW50 IENoZW4gW21haWx0bzp2Y2hlbkBnb29nbGUuY29tPG1haWx0bzp2Y2hlbkBnb29nbGUuY29tPl0N ClNlbnQ6ICAgIE1vbmRheSwgQXVndXN0IDEzLCAyMDEyIDA2OjA0IFBNIEVhc3Rlcm4gU3RhbmRh cmQgVGltZQ0KVG86ICAgIFBldGVyIFN0YW5mb3J0aA0KQ2M6ICAgIFJvc2VuLCBCcmlhbjsgVGVj byBCb290OyBCZW5qYW1pbiBBLlJvbGZlOyBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYu b3JnPg0KU3ViamVjdDogICAgUmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2Fy ZCAmIGlDYWwNCg0KWE1MIHZzIEpTT04NCg0KQmV0d2VlbiBYTUwgYW5kIEpTT04sIEpTT04gbWVz c2FnZXMgYXJlIG1vcmUgY29tcGFjdCBhbmQgZWFzaWVyIHRvIHByb2Nlc3MgKHBhcnNpbmcsIHN5 bnRoZXNpcykuIEFzIGNsYXJpZmljYXRpb24sIEpTT04gZG9lcyBub3QgcmVxdWlyZSBKYXZhU2Ny aXB0IG9yIGEgQnJvd3Nlci4gSXQgaXMgYSB0ZXh0LWJhc2VkIHJlcHJlc2VudGF0aW9uIG9mIGRh dGEgdGhhdCBpcyBsYW5ndWFnZSBpbmRlcGVuZGVudCwgeWV0IHdlbGwtbWF0Y2hlZCB0byBhbGwg bWFqb3IgbGFuZ3VhZ2VzLiBKU09OLWhhbmRsaW5nIGxpYnJhcmllcyBleGlzdCBmb3IgbnVtZXJv dXMgbGFuZ3VhZ2VzIChzZWUgb2YgaHR0cDovL2pzb24ub3JnLykgYW5kIHNlZW0gdG8gYmUgcmVh c29uYWJseSBsaWdodCB3ZWlnaHQuDQoNClRpbWVzdGFtcHMNCg0KQXMgZm9yIHRpbWVzdGFtcCBz cGVjaWZpY2F0aW9ucywgc2hvdWxkIHdlIGNvbnNpZGVyIGp1c3QgdXNpbmcgc2Vjb25kcyBzaW5j ZSB0aGUgVU5JWCBFcG9jaCAoMTk3MC0wMS0wMVQwMDowMDowMFopPyBUaGlzIHdvdWxkIGVsaW1p bmF0ZSB0aGUgbmVlZCBmb3IgZGF0ZXRpbWUtc3RyaW5nIHBhcnNpbmcgb24gZGV2aWNlcywgYXNz dW1pbmcgZGV2aWNlcyBhbHJlYWR5IGhhdmUgbmF0aXZlIGxpYnJhcmllcyB0aGF0IHByb3ZpZGUg dGltZSBpbiB0aGlzIGZvcm1hdC4gSXMgdGhhdCBhIHZhbGlkIGFzc3VtcHRpb24/IE9mIGNvdXJz ZSwgdGhpcyBpcyBsZXNzIGh1bWFuLXJlYWRhYmxlLi4uLg0KDQoNCk9uIE1vbiwgQXVnIDEzLCAy MDEyIGF0IDY6NDkgQU0sIFBldGVyIFN0YW5mb3J0aCA8cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29t PG1haWx0bzpwZXRlckBzcGVjdHJ1bWJyaWRnZS5jb20+PiB3cm90ZToNCg0KDQogICAgV2hlbmV2 ZXIgd2UgYnVpbHQgbW9iaWxlIGRldmljZXMgd2UgbmV2ZXIgZGVhbHQgd2l0aCBJRVRGLCBpbiBv dXIgc2Vuc29yDQogICAgZGF5cyBldmVuIGFuIElQIHN0YWNrIHdhcyBhIGNoYWxsZW5nZSxzbyBJ IHdvdWxkIGRlZmVyIHRvIHRoZSBkZXZpY2UgZ3V5cw0KICAgIG9uIHRoYXQgb25lLg0KDQogICAg T24gTW9uQXVnLzEzLzEyIE1vbiBBdWcgMTMsIDk6MzAgQU0sICJSb3NlbiwgQnJpYW4iDQoNCiAg ICA8QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo8bWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6 Pj4gd3JvdGU6DQoNCiAgICA+T3VyIGV4cGVyaWVuY2UgaW4gdGhlIElFVEYgb3ZlciBtYW55IHll YXJzIGlzIHRoYXQgZWNvbm9taXppbmcgbWVzc2FnZQ0KICAgID5zaXplIGFuZCBjb21wcm9taXNp bmcgdXRpbGl0eSBhbmQgc2VjdXJpdHkgaW4gc2VhcmNoIG9mIGVmZmljaWVuY3kgb2YNCiAgICA+ aW1wbGVtZW50YXRpb24gb24gc21hbGwgZGV2aWNlcyBpcyBhIHBvb3IgdHJhZGUgb2ZmLiAgSSBh bSBub3QgYWR2b2NhdGluZw0KICAgID5iZWluZyB3YXN0ZWZ1bCBvZiByZXNvdXJjZXMsIGJ1dCBJ IGRvbid0IHRoaW5rIHdlIHNob3VsZCBzZXJpb3VzbHkNCiAgICA+Y29uc2lkZXIgdGhlIG92ZXJo ZWFkIG9mIFhNTCBvciBqc29uIHRvIGJlIHNpZ25pZmljYW50Lg0KICAgID4NCiAgICA+QXNzdW1p bmcgYSBqc29uIGxpYnJhcnkgY2FuIGJlIGxvYWRlZCBvbiBhIHNtYWxsIGRldmljZSBpcyByZWFz b25hYmxlLg0KICAgID4NCiAgICA+QnJpYW4gKGFzIGluZGl2aWR1YWwpDQogICAgPg0KICAgID4N CiAgICA+DQogICAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID5Gcm9tOiAgUGV0 ZXIgU3RhbmZvcnRoIFttYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tPG1haWx0bzpwZXRl ckBzcGVjdHJ1bWJyaWRnZS5jb20+XQ0KICAgID5TZW50OiAgU2F0dXJkYXksIEF1Z3VzdCAxMSwg MjAxMiAwNzoxMyBBTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNCiAgICA+VG86ICAgIFRlY28gQm9v dDsgQmVuamFtaW4gQS5Sb2xmZQ0KICAgID5DYzogICAgcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3 c0BpZXRmLm9yZz4NCiAgICA+U3ViamVjdDogICAgICBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVy c3VzIEpTT04sIHZDYXJkICYgaUNhbA0KICAgID4NCiAgICA+Tm90IGFsbCBtYXN0ZXJzIHJ1biBv dmVyIHRoZSBjb3JlIG5ldHdvcmsuDQogICAgPlNvbWUgb2YgdGhlIFVzZSBjYXNlcyBoYXZlIGEg bWFzdGVyIHRhbGtpbmcgdG8gYW5vdGhlciBPVEENCiAgICA+V2Ugc2hvdWxkIG5vdCBhc3N1bWUg dGhhdCBhbGwgTWFzdGVycyBhcmUgYXR0YWNoZWQgdG8gdXRpbGl0eSBwb3dlciBzbyB3ZQ0KICAg ID5zaG91bGQgYmUgc3ltcGF0aGV0aWMgdG8gcHJvY2Vzc2luZyBlbmVyZ3kgdXNlIGFsc28uDQog ICAgPg0KICAgID5PbiBTYXRBdWcvMTEvMTIgU2F0IEF1ZyAxMSwgNTozMCBBTSwgIlRlY28gQm9v dCIgPHRlY29AaW5mLW5ldC5ubDxtYWlsdG86dGVjb0BpbmYtbmV0Lm5sPj4gd3JvdGU6DQogICAg Pg0KICAgID4+DQogICAgPj5PcCAxMCBhdWcuIDIwMTIsIG9tIDE4OjEwIGhlZWZ0IEJlbmphbWlu IEEuIFJvbGZlIGhldCB2b2xnZW5kZQ0KICAgID4+Z2VzY2hyZXZlbjoNCiAgICA+Pg0KICAgID4+ PiBDb21wYWN0bmVzcyBvZiBtZXNzYWdlcyBpcyBpbXBvcnRhbnQsIGJ1dCBpdCBpcyBhbHNvIGlt cG9ydGFudCAodG8gbWUNCiAgICA+Pj5hdCBsZWFzdCkgdG8gYmUgcmVhbGl6YWJsZSBpbiBhbiBp bXBsZW1lbnRhdGlvbiB3aXRoIGxpbWl0ZWQgcmVzb3VyY2VzLA0KICAgID4+PnN1Y2ggYXMgZW1i ZWRkZWQgZGV2aWNlcyBpbiB3aGF0IGFyZSBub3cgcG9wdWxhcmx5IGNhbGxlZCAiTTJNIg0KICAg ID4+PmFwcGxpY2F0aW9ucy4gIEEgbG90IG9mIHRoZXNlIGRldmljZXMgY291bGQgdXNlIElQIGFs bCB0aGUgZW5kIHRvIGVuZCwNCiAgICA+Pj5idXQgbWF5IGhhdmUgYSB2ZXJ5IGNvbXBhY3QsIHNp bXBsZSBzdGFjayBhbmQgYXBwbGljYXRpb25zIChpLmUuICBubw0KICAgID4+PmJyb3dzZXIpLiAg SXMgSlNPTiB0eXBpY2FsbHkgaW1wbGVtZW50ZWQgd2hlbiB0aGVyZSBpcyBubyBicm93c2VyPw0K ICAgID4+PldvdWxkIGl0IGJlIGhhcmQgdG8gZG8gaW4gYSByZXNvdXJjZSBjb25zdHJhaW5lZCBk ZXZpY2UgKGkuZS4gd2hlcmUgd2UNCiAgICA+Pj50YWxrIGFib3V0IG1lbW9yeSBzaXplIGluIEtp bG8tYnl0ZXMgc3RpbGwpLg0KICAgID4+DQogICAgPj5JbiB1c2UgY2FzZXMgYW5kIHJlcXVpcmVt ZW50cyBkb2N1bWVudCwgdGhlcmUgYXJlIG5vIHJlcXVpcmVtZW50cyBmb3INCiAgICA+PnByb3Rv Y29sIHBlcmZvcm1hbmNlLiBJIGd1ZXNzIE9TL0lQL1RDUC9UTFMgY29kZSBzaXplIHN1cGVyc2Vk ZXMgbmVlZHMNCiAgICA+PmZvciBKU09OIG9yIFhNTC4NCiAgICA+Pg0KICAgID4+U2FtZSBmb3Ig dGltaW5nOiBUQ1AvVExTIGNvbm5lY3Rpb24gc2V0dXAgd2lsbCB0YWtlIG1vcmUgdGhhbiB0aGUg UEFXUw0KICAgID4+bWVzc2FnZSBleGNoYW5nZSwgSSB0aGluay4gVGhpcyBtYXkgYmUgb2YgaW1w b3J0YW5jZSB3aGVuIHVzaW5nIHNhdGNvbQ0KICAgID4+bGlua3MuDQogICAgPj4NCiAgICA+PkJl Y2F1c2UgUEFXUyBydW5zIGJldHdlZW4gbWFzdGVyIGFuZCBkYXRhYmFzZSwgb3ZlciBjb3JlIG5l dHdvcmssDQogICAgPj5wZXJmb3JtYW5jZSBpcyBub3Qgb3VyIHByaW1hcnkgY29uY2Vybi4gQnV0 IGFzIGFsd2F5cywgaXQgaXMgZ29vZCB0byBrZWVwDQogICAgPj5hbiBleWUgb24gZWZmaWNpZW5j eS4NCiAgICA+Pg0KICAgID4+VGVjbw0KICAgID4+DQogICAgPj4+IFRoYW5rcw0KICAgID4+PiBC ZW4NCiAgICA+Pj4NCiAgICA+Pj4NCiAgICA+Pj4+IFdlIGhhZCBhIGRpc2N1c3Npb24gb24gWE1M IHZzLiBKU09OLiBJIHByZWZlciB0aGUgb25lIHdpdGggbW9zdA0KICAgID4+Pj5jb21wYWN0IG1l c3NhZ2VzLg0KICAgID4+Pj4NCiAgICA+Pj4+IE9uIHZDYXJkIGFuZCBKU09OOiB3aGF0IGlzIHRo ZSBzdGF0dXMgb2YgIkEgSmF2YVNjcmlwdCBPYmplY3QgTm90YXRpb24NCiAgICA+Pj4+KEpTT04p IFJlcHJlc2VudGF0aW9uIGZvciB2Q2FyZCI/DQogICAgPj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1iaGF0LXZjYXJkZGF2LWpzb24tMDANCiAgICA+Pj4+DQogICAgPj4+PiBP biB2YWxpZCB0aW1lczogY2FuIHdlIHVzZSBzYW1lIGZvcm1hdCBhcyBjZXJ0aWZpY2F0ZXM/IFRo ZXkgaGF2ZQ0KICAgID4+Pj5zaW1pbGFyIHNpbXBsZSByZXF1aXJlbWVudHM6IHZhbGlkIG5vdEJl Zm9yZSYgIG5vdEFmdGVyLg0KICAgID4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj MzI4MCNzZWN0aW9uLTQuMS4yLjUNCiAgICA+Pj4+DQogICAgPj4+PiBUZWNvDQogICAgPj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+Pj4g cGF3cyBtYWlsaW5nIGxpc3QNCiAgICA+Pj4+IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0 Zi5vcmc+DQogICAgPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bh d3MNCiAgICA+Pj4+DQogICAgPj4+DQogICAgPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQogICAgPj4+IHBhd3MgbWFpbGluZyBsaXN0DQogICAgPj4+ IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQogICAgPj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KICAgID4+DQogICAgPj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+cGF3cyBtYWlsaW5n IGxpc3QNCiAgICA+PnBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQogICAgPj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCiAgICA+DQogICAgPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPnBhd3Mg bWFpbGluZyBsaXN0DQogICAgPnBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQog ICAgPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQogICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBwYXdzIG1h aWxpbmcgbGlzdA0KICAgIHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQogICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg0KDQoNCg0KLS0N Ci12aW5jZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KcGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwYXdzIG1haWxpbmcgbGlzdA0K cGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQoNCg0KLS0NCi12aW5jZQ0KDQoNCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCnBhd3MgbWFpbGlu ZyBsaXN0DQoNCnBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQoNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NAaWV0 Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Bhd3MNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KcGF3cyBtYWlsaW5nIGxpc3QNCg0KcGF3c0BpZXRmLm9yZzxtYWls dG86cGF3c0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9wYXdzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpwYXdzIG1haWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGF3cyBtYWlsaW5n IGxpc3QNCnBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg0K --_000_8CC0CB0BCAE52F46882E17828A9AE21636860C6DSZXEML508MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIg NCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWu i+S9kzt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8 jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg 6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAueWl2MTgwMTUz OTQyMW1zb2FjZXRhdGUsIGxpLnlpdjE4MDE1Mzk0MjFtc29hY2V0YXRlLCBkaXYueWl2MTgwMTUz OTQyMW1zb2FjZXRhdGUNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTgwMTUzOTQyMW1zb2FjZXRhdGU7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KcC55aXYxODAxNTM5NDIxbXNvbGlzdHBhcmFncmFw aCwgbGkueWl2MTgwMTUzOTQyMW1zb2xpc3RwYXJhZ3JhcGgsIGRpdi55aXYxODAxNTM5NDIxbXNv bGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTp5aXYxODAxNTM5NDIxbXNvbGlzdHBhcmFn cmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwLnlpdjE4MDE1Mzk0MjFtc29ub3JtYWws IGxpLnlpdjE4MDE1Mzk0MjFtc29ub3JtYWwsIGRpdi55aXYxODAxNTM5NDIxbXNvbm9ybWFsDQoJ e21zby1zdHlsZS1uYW1lOnlpdjE4MDE1Mzk0MjFtc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrl rovkvZM7fQ0KcC55aXYxODAxNTM5NDIxbXNvY2hwZGVmYXVsdCwgbGkueWl2MTgwMTUzOTQyMW1z b2NocGRlZmF1bHQsIGRpdi55aXYxODAxNTM5NDIxbXNvY2hwZGVmYXVsdA0KCXttc28tc3R5bGUt bmFtZTp5aXYxODAxNTM5NDIxbXNvY2hwZGVmYXVsdDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9 DQpzcGFuLnlpdjE4MDE1Mzk0MjFtc29oeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTgw MTUzOTQyMW1zb2h5cGVybGluazt9DQpzcGFuLnlpdjE4MDE1Mzk0MjFtc29oeXBlcmxpbmtmb2xs b3dlZA0KCXttc28tc3R5bGUtbmFtZTp5aXYxODAxNTM5NDIxbXNvaHlwZXJsaW5rZm9sbG93ZWQ7 fQ0Kc3Bhbi55aXYxODAxNTM5NDIxaHRtbHByZWZvcm1hdHRlZGNoYXINCgl7bXNvLXN0eWxlLW5h bWU6eWl2MTgwMTUzOTQyMWh0bWxwcmVmb3JtYXR0ZWRjaGFyO30NCnNwYW4ueWl2MTgwMTUzOTQy MWJhbGxvb250ZXh0Y2hhcg0KCXttc28tc3R5bGUtbmFtZTp5aXYxODAxNTM5NDIxYmFsbG9vbnRl eHRjaGFyO30NCnNwYW4ueWl2MTgwMTUzOTQyMWVtYWlsc3R5bGUyMw0KCXttc28tc3R5bGUtbmFt ZTp5aXYxODAxNTM5NDIxZW1haWxzdHlsZTIzO30NCnNwYW4ueWl2MTgwMTUzOTQyMWVtYWlsc3R5 bGUyNQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxODAxNTM5NDIxZW1haWxzdHlsZTI1O30NCnAueWl2 MTgwMTUzOTQyMW1zb25vcm1hbDEsIGxpLnlpdjE4MDE1Mzk0MjFtc29ub3JtYWwxLCBkaXYueWl2 MTgwMTUzOTQyMW1zb25vcm1hbDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTgwMTUzOTQyMW1zb25v cm1hbDE7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4u eWl2MTgwMTUzOTQyMW1zb2h5cGVybGluazENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTgwMTUzOTQy MW1zb2h5cGVybGluazE7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4ueWl2MTgwMTUzOTQyMW1zb2h5cGVybGlua2ZvbGxvd2VkMQ0KCXttc28tc3R5bGUt bmFtZTp5aXYxODAxNTM5NDIxbXNvaHlwZXJsaW5rZm9sbG93ZWQxOw0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAueWl2MTgwMTUzOTQyMW1zb2FjZXRhdGUx LCBsaS55aXYxODAxNTM5NDIxbXNvYWNldGF0ZTEsIGRpdi55aXYxODAxNTM5NDIxbXNvYWNldGF0 ZTENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTgwMTUzOTQyMW1zb2FjZXRhdGUxOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjt9DQpwLnlpdjE4MDE1Mzk0MjFtc29saXN0cGFyYWdy YXBoMSwgbGkueWl2MTgwMTUzOTQyMW1zb2xpc3RwYXJhZ3JhcGgxLCBkaXYueWl2MTgwMTUzOTQy MW1zb2xpc3RwYXJhZ3JhcGgxDQoJe21zby1zdHlsZS1uYW1lOnlpdjE4MDE1Mzk0MjFtc29saXN0 cGFyYWdyYXBoMTsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4ueWl2MTgwMTUzOTQyMWh0bWxwcmVmb3JtYXR0ZWRjaGFyMQ0KCXttc28t c3R5bGUtbmFtZTp5aXYxODAxNTM5NDIxaHRtbHByZWZvcm1hdHRlZGNoYXIxOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzO30NCnNwYW4ueWl2MTgwMTUzOTQyMWJhbGxvb250ZXh0Y2hhcjENCgl7bXNv LXN0eWxlLW5hbWU6eWl2MTgwMTUzOTQyMWJhbGxvb250ZXh0Y2hhcjE7DQoJZm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi55aXYxODAxNTM5NDIxZW1haWxzdHlsZTIzMQ0K CXttc28tc3R5bGUtbmFtZTp5aXYxODAxNTM5NDIxZW1haWxzdHlsZTIzMTsNCglmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4ueWl2MTgwMTUz OTQyMWVtYWlsc3R5bGUyNTENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTgwMTUzOTQyMWVtYWlsc3R5 bGUyNTE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpwLnlpdjE4MDE1Mzk0MjFtc29jaHBkZWZhdWx0MSwgbGkueWl2MTgwMTUzOTQyMW1zb2No cGRlZmF1bHQxLCBkaXYueWl2MTgwMTUzOTQyMW1zb2NocGRlZmF1bHQxDQoJe21zby1zdHlsZS1u YW1lOnlpdjE4MDE1Mzk0MjFtc29jaHBkZWZhdWx0MTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNw YWNlDQoJe21zby1zdHlsZS1uYW1lOnlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7 fQ0Kc3Bhbi5FbWFpbFN0eWxlNDENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDoyNjIxNDk5ODI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjExNDg4NjU4NzA7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXtt c28tbGlzdC1pZDo0NDUwMDc0Mjc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1MTQ1NzkwODA7 fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0KCXtt c28tbGlzdC1pZDo0OTQyOTY0ODc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1MDU2NDkyMDY7 fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTA3MzA0NzkwNjsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6OTAxMDI0ODE0O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTcxNjA4MTk5MjsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6MTg5MDM4MTY2O30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6MTcyMTYzNzc3MDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6MjA5NzQ0MDA5ODt9DQpAbGlzdCBsNTpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSwNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHByZWZlciB0byBib3RoLg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgaWYgSSBoYXZlIHRvIGNob29zZSBm cm9tIGludGVyb3BlcmFiaWxpdHkgYW5kIOKAnGEgbGl0dGxl4oCdIGNvbXBhY3RuZXNzIG9mIGNv ZGVzLCBJIHdpbGwgdm90ZSBmb3IgWE1MLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5ZYW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFw aCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij49PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVv Z3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+WWFuZyBDdWksJm5ic3A7IFBoLkQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50 ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkh1YXdlaSBUZWNobm9sb2dpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlm eTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Y3VpeWFuZ0BodWF3ZWkuY29tPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gcGF3cy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij7ku6PooaggPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk1hbmlra290aCBTYWplZXY8YnI+DQo8L3NwYW4+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVO LVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4gMjAxMjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5bm0 PHNwYW4gbGFuZz0iRU4tVVMiPjg8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjI1PC9zcGFu PuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4gMTE6MTQ8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNw YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gR2Fib3IuQmFq a29Abm9raWEuY29tOyBCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpejsgYmVuQGJsaW5kY3JlZWsuY29t PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyI+IHBhd3NAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4g bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFtwYXdzXSBY TUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmYW1wOyBpQ2FsPG86cD48L286cD48L3NwYW4+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjpibGFjayI+SSB3b3VsZCBzdGlsbCBzdXBwb3J0IFhNTC4gSlNPTiBsaWJyYXJpZXMgYXJlIGF2 YWlsYWJsZSBmb3IgYWxsIGxhbmd1YWdlcy4gQnV0IGludGVyZmFjaW5nIGFuZCBsaW5raW5nIHN1 Y2ggbGlicmFyaWVzIGFyZSBwcm9ibGVtYXRpYyBvbiBlbWJlZGRlZCBkZXZpY2VzIG1vc3QNCiBv ZiB0aGUgdGltZS4gQW5kIGlmIGFuIGltcGxlbWVudGF0aW9uIHZvdWNoIGZvciBtdWx0aXBsZSBz dWNoIG5vbiBuYXRpdmUgbGFuZ3VhZ2UgbGlicmFyaWVzIHRoZW4gZGV2ZWxvcGVycyBsaWZlIGlz IGhlbGwuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48aT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojQzAwMDAwIj5CZXN0IFJlZ2FyZHMsPC9z cGFuPjwvaT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGk+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6I0MwMDAwMCI+U2FqZWV2IE1hbmlra290aDwvc3Bhbj48L2k+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ICZxdW90O0dhYm9y LkJhamtvQG5va2lhLmNvbSZxdW90Ow0KICZsdDtHYWJvci5CYWprb0Bub2tpYS5jb20mZ3Q7PGJy Pg0KPGI+VG86PC9iPiBCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpejsgYmVuQGJsaW5kY3JlZWsuY29t IDxicj4NCjxiPkNjOjwvYj4gcGF3c0BpZXRmLm9yZyA8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJk YXksIDI1IEF1Z3VzdCAyMDEyLCAwOjM4PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcGF3c10g WE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJmFtcDsgaUNhbDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgaWQ9InlpdjE4MDE1Mzk0MjEiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2lGaSB3b3JsZCBi dWlsZHMgb24gbWFuZGF0aW5nIHRoZSBpbXBsZW1lbnRhdGlvbiAoYW5kIGNlcnRpZmljYXRpb24p IG9mIGEgYmFzZSBzcGVjLCBhbmQgYSBzZXQgb2Ygb3B0aW9uYWwgZmVhdHVyZXMuDQogSWYgYW4g b3B0aW9uYWwgZmVhdHVyZSBpcyBub3Qgc3VwcG9ydGVkIGJ5IG9uZSBvZiB0aGUgcGVlcnMsIHRo ZXkgY2FuIHN0aWxsIHRhbGssIGJ1dCBub3QgdXNlIHRoYXQgZmVhdHVyZS4gVGhhdCBpcyBiYXNp Y2FsbHkgb3B0aW9uIEIpIGZyb20gQnJhaW7igJlzIGxpc3QuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJlkIGxpa2UgdG8gc3VnZ2VzdCB0aGF0IHdlIHJl Y29nbml6ZSB0aGF0IG9wdGlvbiBBKSBhbmQgQikgYXJlIHZhbGlkIG9wdGlvbnMsIHdoaWxlIG9w dGlvbiBDKSBpcyBpbnZhbGlkLCBhbmQgd2Ugc2hvdWxkDQogc3RvcCBkZWJhdGluZyBpdC48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPknigJlkIGFsc28gbGlrZSB0byBhZGQgdGhlIG9idmlvdXMgb3B0aW9u IEQpIHRvIHRoZSBsaXN0LCB3aGljaCBpcyB0aGF0IGJvdGggdGhlIG1hc3RlciBkZXZpY2VzIGFu ZCBEQnMgc3VwcG9ydCBvbmUgYW5kDQogdGhlIHNhbWUgZW5jb2RpbmcgOyk8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T3B0aW9uIEEpIHNlZW1zIHRvIGJlIGxp a2UgYSBnb29kIGNvbXByb21pc2UsIGFuZCB3b3VsZCBjdXQgZGlzY3Vzc2lvbnMgc2hvcnQsIHdp dGggdGhlIG9ubHkgY2F2ZWF0IHRoYXQgaWYgdGhlcmUgaXMNCiBubyBzdHJvbmcgdGVjaG5pY2Fs IGFyZ3VtZW50IGZvciBzdXBwb3J0aW5nIGFuZCBzcGVjaWZ5aW5nIHR3byBkaWZmZXJlbnQgZW5j b2RpbmdzLCB0aGVuIHRoZSBpZXNnIG1heSBzZW5kIHRoZSBkb2N1bWVudCBiYWNrIHRvIHRoZSB3 ZyB0byBwaWNrIG9uZSBvZiB0aGUgdHdvIHNwZWNpZmllZC4gQXMgUm9iZXJ0IG1lbnRpb25lZCBp biBoaXMgZW1haWwsIHRoaXMgaGFzIGhhcHBlbmVkIGluIHRoZSBwYXN0LCBzbyBpdCBpcyBsaWtl bHkgaXQgd291bGQNCiBoYXBwZW4gYWdhaW4uIEFuZCBmcmFua2x5LCBJIGRvIG5vdCBzZWUgYSBz dHJvbmcgYXJndW1lbnQgaW4gZmF2b3Igb2YgdHdvIGRpZmZlcmVudCBlbmNvZGluZ3MuDQo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXMgdGhlcmUgYW55b25l IHdobyBoYXMgYSB0ZWNobmljYWwgYXJndW1lbnQgYWdhaW5zdCBzdXBwb3J0aW5nIG9ubHkgb25l IGVuY29kaW5nLCBiZWluZyB0aGF0IGVpdGhlciB4bWwgb3IganNvbj88L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TW9zdCBwZW9wbGUgc3BlYWsgaW4gZmF2b3Ig b2YgSlNPTiwgYmVjYXVzZSBpdCBpcyBjb21wYWN0IGFuZCBtb3JlIGVmZmljaWVudC4gSSB3ZW50 IHRocm91Z2ggdGhpcyB0aHJlYWQgYW5kIEkgc2F3DQogMiBvYmplY3Rpb25zIGFnYWluc3QgcGlj a2luZyBKU09OLiBPbmUgc2FpZCB0aGF0IEpTT04gcmVxdWlyZXMgbmF0aXZlIEphdmEsIHdoaWNo IGlzIHdyb25nLCB0aGUgb3RoZXIgb2JqZWN0aW9uIGdhdmUgbm8gcmVhbCByZWFzb24uIFNvIEkg YW0gd29uZGVyaW5nIGlmIHRoZXJlIGlzIHJlYWxseSBhbnkgdmFsaWQgdGVjaG5pY2FsIHJlYXNv biBhZ2FpbnN0IHVzaW5nIEpTT04gb25seT88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+LSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBHYWJvcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtO2JvcmRlci1jb2xvcjpjdXJyZW50Q29sb3IgY3VycmVudENvbG9yIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcNCiBbbWFpbHRvOnBhd3MtYm91bmNl c0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5leHQgUm9zZW4sIEJyaWFuPGJyPg0KPGI+ U2VudDo8L2I+IEZyaWRheSwgQXVndXN0IDI0LCAyMDEyIDEwOjQzIEFNPGJyPg0KPGI+VG86PC9i PiBCZW5qYW1pbiBBLiBSb2xmZTxicj4NCjxiPkNjOjwvYj4gcGF3c0BpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJkICZh bXA7IGlDYWw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+T2theTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlNvLCBJIGltcGxlbWVudCBh IGRhdGFiYXNlLCBhbmQgSSBpbXBsZW1lbnQgWE1MPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Z b3UgaW1wbGVtZW50IGEgZGV2aWNlLCBhbmQgeW91IGltcGxlbWVudCBKU09OPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPllvdSBxdWVyeSBt eSBkYXRhYmFzZSAobGV0J3Mgbm90IGdldCBpbnRvIGhvdyB5b3UgZG8gdGhhdCBxdWVyeSB3aXRo b3V0IGRlY2lkaW5nIFhNTCB2cyBKU09OKSBhbmQgZGlzY292ZXIgSSBpbXBsZW1lbnQgWE1MIG9u bHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+V2hhdCBkbyB5b3UgZG8/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkJyaWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+T24gQXVnIDI0LCAyMDEyLCBh dCAxOjM4IFBNLCAmcXVvdDtCZW5qYW1pbiBBLiBSb2xmZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmJlbkBibGluZGNyZWVrLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJlbkBibGluZGNyZWVrLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2Jh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hp dGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPlRoZXJlIGFyZSB0d28gd2F5cyB0byBhY2hpZXZlIGludGVyb3BlcmFiaWxpdHkgd2hlbiB5 b3UgaGF2ZSBhbiBvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGVyZSBh cmUgbWFueSBleGlzdGVuY2UgcHJvb2ZzIG9mIHRoZSB0aGlyZCB3YXkgdGhhdCBJIG1lbnRpb25l ZCBiZWxvdy48YnI+DQo4MDIuMTEgJiM0MzsgV2lGaSBwcm92aWRlIG1hbnkgb3B0aW9ucyBhbmQg YSBtZWFucyBmb3IgZGV2aWNlcyB0byBzaGFyZSBpbmZvcm1hdGlvbiBhYm91dCB3aGF0IG9wdGlv bnMgZWFjaCBzdXBwb3J0cywgd2l0aG91dCByZXF1aXJpbmcgdGhhdCBhbnkgZGV2aWNlIGltcGxl bWVudCBldmVyeSBvcHRpb24uJm5ic3A7IEl0IHdvcmtzLiZuYnNwOw0KPGJyPg0KPGJyPg0KVGhh dCBzYWlkLCBJIHRoaW5rIChBKSBpcyB0aGUgYmVzdCBjaG9pY2UsIChCKSBpcyBub3QgYXMgbmlj ZSBmb3IgbWUsIGFuZCAoQykgaXMgbW9yZSB3b3JrIHRoYW4gZWl0aGVyIG9mIHRoZSBvdGhlciB0 d28uPGJyPg0KJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5PbmUgaXMgdGhhdCBvbmUgZW5kIGltcGxlbWVudHMgYm90aCBjaG9pY2VzIGFuZCB0 aGUgb3RoZXIgZW5kIGltcGxlbWVudHMgb25lIG9yIGJvdGguPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBvdGhlciBpcyB0aGF0IGJv dGggZW5kcyBpbXBsZW1lbnQgb25lIHNwZWNpZmljIGNob2ljZSAoJnF1b3Q7TVVTVCBpbXBsZW1l bnQmcXVvdDspIGFuZCBib3RoIGNhbiBvcHRpb25hbGx5IGltcGxlbWVudCB0aGUgb3RoZXIgY2hv aWNlLiAmbmJzcDtPbmx5DQogaWYgYm90aCBlbmRzIGltcGxlbWVudCB0aGUgb3RoZXIgY2hvaWNl IHdvdWxkIHRoYXQgYmUgYXZhaWxhYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5TbywgaW4gdGhpcyBjYXNlIHdlIGNvdWxkIGRvIG9u ZSBvZiB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QSkgRGF0YWJhc2Vz IGltcGxlbWVudCBib3RoIFhNTCBhbmQgSlNPTiwgZGV2aWNlcyBpbXBsZW1lbnQgZWl0aGVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CKSBCb3RoIERhdGFiYXNlcyBhbmQgZGV2aWNlcyBpbXBs ZW1lbnQgb25lIChzYXkgWE1MKSBhbmQgb3B0aW9uYWxseSBpbXBsZW1lbnQgdGhlIG90aGVyIChz YXkgSlNPTik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjpibGFjayI+WW91IGFyZSBhZHZvY2F0aW5nIGZvciBBLCBSaWNoYXJkIHdhcyBzdWdnZXN0aW5n IEIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPkkgZG9uJ3QgY2FyZSwgYnV0IGNob2ljZSBDKSBCb3RoIGRhdGFiYXNlcyBhbmQgZGV2aWNl cyBoYXZlIGEgY2hvaWNlIG9mIHdoYXQgdG8gaW1wbGVtZW50IGRvZXNuJ3Qgd29yayBmb3IgbWUg KG9yIFJpY2hhcmQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5CcmlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk9uIEF1ZyAyNCwgMjAxMiwgYXQgMTI6 NTcgUE0sIEJlbmphbWluIEEuIFJvbGZlICZsdDs8YSBocmVmPSJtYWlsdG86YmVuQGJsaW5kY3Jl ZWsuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmVuQGJsaW5kY3JlZWsuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFwcGFyZW50bHkgSSB3YXMgdW5jbGVhci4mbmJz cDsgSSBjZXJ0YWlubHkgYW4gY2FwYWJsZSBvZiBiZWluZyB3cm9uZyBhcyBJIHByYWN0aWNlIG9m dGVuLCBidXQgaW4gdGhpcyBjYXNlIGl0IGlzIHF1aXRlDQogdW5saWtlbHkgOi0pLiA8YnI+DQo8 YnI+DQpZb3UgZG8gbm90IG5lZWQgdG8gY2hvb3NlIG9ubHkgb25lIGZvcm0gdG8gYWNoaWV2ZSBp bnRlcm9wZXJhYmlsaXR5LiZuYnNwOyZuYnNwOyBJZiB5b3UgaGF2ZSB0d28sIGxldCB0aGUgZGV2 aWNlIGltcGxlbWVudGVyIGZpZ3VyZSBvdXQgd2hpY2ggaXMgYmVzdCBmb3IgdGhlaXIgcGFydGlj dWxhciBkZXZpY2UgcmVxdWlyZW1lbnRzIGFuZCB0cmFkZS1vZmZzLiZuYnNwOyBUaGlzIGlzICpw cmVmZXJhYmxlKiBmcm9tIG15IHBlcnNwZWN0aXZlLjxicj4NCjxicj4NCklmIHlvdSBwcm92aWRl IG1vcmUgdGhhbiBvbmUgZm9ybSBpbiB0aGUgZGF0YWJhc2UsIGRldmljZXMgdXNpbmcgdGhlIGRh dGFiYXNlIG5lZWQgc29tZSBtZWFucyBmb3IgZmlndXJpbmcgb3V0IHdoaWNoIGFyZSBhdmFpbGFi bGUuIEl0IGNhbid0IHVzZSBpdCBpZiBpdCBkb2Vzbid0IG5vIGFib3V0IGl0LiBUaGlzIGlzIGFu IG9ic2VydmF0aW9ucywgbm90IGFuIGFyZ3VtZW50IDstKS4mbmJzcDsmbmJzcDsNCjxicj4NCjxi cj4NCkl0IGlzIG15ICpvcGluaW9uKiBhdCB0aGUmbmJzcDsgbW9tZW50IHRoYXQgaWYgeW91IHBy b3ZpZGUgb3B0aW9ucywgdG8gbWFrZSB0aG9zZSB1c2VmdWwgeW91IG5lZWQgdG8gcHJvdmlkZSZu YnNwOyBhIHByb3RvY29sIGJ5IHdoaWNoIGRldmljZXMgY2FuIGRpc2NvdmVyIHdoYXQgb3B0aW9u cyB0aGUgZGF0YWJhc2Ugc3VwcG9ydHMuJm5ic3A7IElmIHlvdSBoYXZlIHN1Y2ggYSBtZWNoYW5p c20gYW5kIGFsbCBkZXZpY2VzIHVzZSBpdCAoYSZuYnNwOyBib290c3RyYXAgcHJvdG9jb2wpLA0K IGV2ZXJ5dGhpbmcgZWxzZSBjb3VsZCBiZSBvcHRpb25zLiZuYnNwOyBUaGlzIHJlcXVpcmVzIGFk ZGl0aW9uYWwgZnVuY3Rpb25zIGluIGJvdGggZGF0YWJhc2UgYW5kIGRldmljZSBpbXBsZW1lbnRh dGlvbnMuDQo8YnI+DQpJZiBvbiB0aGUgb3RoZXIgaGFuZCB0aGUgZGV2aWNlIGNhbiAmcXVvdDtq dXN0IGtub3cmcXVvdDsgdGhhdCB0aGUgZGF0YWJhc2UgaGFzIHR3byBmb3JtcyBhdmFpbGFibGUs IGl0IHdvbid0IG5lZWQgdG8gZHluYW1pY2FsbHkgZmlndXJlIGl0IG91dC4gVGhlIGRldmljZSBp bXBsZW1lbnRlciBoYXMgb3B0aW9ucyBhbmQgc2ltcGxpY2l0eSwgc28gSSBsaWtlIGl0Lg0KPGJy Pg0KPGJyPg0KU2luY2UgSSBhbSBmb2N1c2VkIG9uIHRoZSBUVldTIGRldmljZXMgdGhhdCBuZWVk IGFjY2VzcyB0byB0aGUgZGF0YWJhc2UsIGFuZCBub3QgYSBkYXRhYmFzZSBpbXBsZW1lbnRlciwg c2hpZnRpbmcgYnVyZGVuIG9udG8gdGhlIGRhdGFiYXNlIGltcGxlbWVudGVyIChub3QgbWUpIHRv IHJlZHVjZSB0aGUgYnVyZGVuIG9uIHRoZSBkZXZpY2UgaW1wbGVtZW50ZXIgKG1lKSBpcyBwcmVm ZXJyZWQgZnJvbSBteSBwZXJzcGVjdGl2ZS4mbmJzcDsgVGhlIGRhdGFiYXNlDQogaW1wbGVtZW50 ZXIgbWF5IGhhdmUgYW5vdGhlciBwZXJzcGVjdGl2ZS4mbmJzcDsgU2hvdWxkIEkgcG9pbnQgb3V0 IHRoYXQgdGhlcmUgd2lsbCBiZSBhIGxvdCBtb3JlIGRldmljZXMgdGhhbiBkYXRhYmFzZXM/Jm5i c3A7IFRoYXQgbWlnaHQgc291bmQgbGlrZSBhbiBhcmd1bWVudCwgdGhvdWdoLCBzbyBJIHdvbid0 Li4uLjotajxicj4NCjxicj4NCkJlbjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkJyaWFuIGlzIHJpZ2h0IC4uIHNvcnJ5IGJ1dCB0aGUgcmVzdCBvZiB5b3UgYXJlIHdy b25nLg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMg aXMgd2h5IHlvdSBoYXZlIE1VU1QgYW5kIFNIT1VMRCBpbiBSRkMgMjExOS4gJm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo aXMgQlRXIGlzIGEgY2xhc3NpYyBhcmd1bWVudCBpbiBJRVRGIHRlcm1zIC4uIGJ1dCB0aGUgYXJn dW1lbnQg4oCcbGV0IHRoZSBtYXJrZXQgZGVjaWRl4oCdIG9ubHkgaG9sZHMgc28gbXVjaCB2YWxp ZGl0eS4mbmJzcDsNCiBZb3UgYWN0dWFsbHkgaGF2ZSB0byBjaG9vc2UgU09NRVRISU5HIHRvIGNy ZWF0ZSBhIGJhc2VsaW5lIG9mIGludGVyb3BlcmFiaWxpdHkuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkEgdmlydHVhbGx5IGlkZW50 aWNhbCBhcmd1bWVudCAmbmJzcDtpcyBub3cgcGxheWluZyBvdXQgaW4gZGlzY3Vzc2lvbnMgb2Yg bWFuZGF0b3J5IGF1ZGlvIGFuZCBjb2RlYyBpbXBsZW1lbnRhdGlvbnMgZm9yDQogV0VCUlRDIGxp a2UgdGhpbmdzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JTUhPIFhNTCBNVVNUIGFueXRoaW5nIGVsc2UgZGVmaW5lZCBTSE9VTEQs IGJ1dCBNVVNUIG9uIFhNTCBhbmQgSlNPTiBjb3VsZCB3b3JrIGFzIHdlbGwuIEl0IGp1c3QgbGVh ZHMgdG8gYSBsZXZlbCBvZg0KIGNvbXBsZXhpdHkgaW4gaW1wbGVtZW50YXRpb25zLiA8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RW5k IG9mIGFyZ3VtZW50IHlvdSBub3cgY2FuIGdvIGJhY2sgdG8geW91ciByZWd1bGFybHkgc2NoZWR1 bGUgcHJvZ3JhbW1pbmcuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbTtib3JkZXItY29sb3I6Y3VycmVudENvbG9yIGN1cnJl bnRDb2xvciI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjxhIGhyZWY9Im1haWx0bzpwYXdzLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wYXdzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBo cmVmPSJtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRv OnBhd3MtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPjxhIGhyZWY9 Im1haWx0bzpCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tIiB0YXJnZXQ9Il9ibGFuayI+QmFzYXZh cmFqLlBhdGlsQG5va2lhLmNvbTwvYT48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3Vz dCAyMywgMjAxMiA1OjQ0IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86QnJpYW4u Um9zZW5AbmV1c3Rhci5iaXoiIHRhcmdldD0iX2JsYW5rIj5Ccmlhbi5Sb3NlbkBuZXVzdGFyLmJp ejwvYT47DQo8YSBocmVmPSJtYWlsdG86ZC5qb3NseW5Ac3BlY3RydW1icmlkZ2UuY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZC5qb3NseW5Ac3BlY3RydW1icmlkZ2UuY29tPC9hPjxicj4NCjxiPkNjOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wYXdzQGll dGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVy c3VzIEpTT04sIHZDYXJkICZhbXA7IGlDYWw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgYWdyZWUgd2l0aCBCcmlhbi48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo4LjVw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPlRoZXJlIG5lZWRzIHRvIGJlIGEgZGVmYXVsdCBtYW5kYXRvcnkgdG8g aW1wbGVtZW50IG9wdGlvbiBpbiBvcmRlciB0byBhY2hpZXZlIGludGVyb3BlcmFiaWxpdHkuJm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BbmQgdGhpcyBhcHBsaWVzIHRvIHRo ZSBkZXZpY2UgYW5kIGRhdGFiYXNlIHNpZGUgb2YgdGhlIHByb3RvY29sLjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj4tUmFqPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbTtib3JkZXItY29sb3I6Y3VycmVudENvbG9yIGN1cnJlbnRDb2xvciI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZy b206DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZxdW90OyZsdDtleHQgUm9zZW4mZ3Q7JnF1b3Q7LCAmcXVvdDs8YSBo cmVmPSJtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXoiIHRhcmdldD0iX2JsYW5rIj5Ccmlh bi5Sb3NlbkBuZXVzdGFyLmJpejwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpCcmlhbi5S b3NlbkBuZXVzdGFyLmJpeiIgdGFyZ2V0PSJfYmxhbmsiPkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6 PC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIEF1Z3VzdCAyMywgMjAxMiAyOjQz IFBNPGJyPg0KPGI+VG86IDwvYj5Eb24gSm9zbHluICZsdDs8YSBocmVmPSJtYWlsdG86ZC5qb3Ns eW5Ac3BlY3RydW1icmlkZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZC5qb3NseW5Ac3BlY3RydW1i cmlkZ2UuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpw YXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGF3c0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGF3c0BpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbcGF3c10gWE1MIHNjaGVtYSB2 ZXJzdXMgSlNPTiwgdkNhcmQgJmFtcDsgaUNhbDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+T25lIG9mIG15IGZhdm9yaXRlIElFVEYgZXhwcmVzc2lvbnMgaXMgJnF1b3Q7VGhlcmUg YXJlIG5vIHByb3RvY29sIHBvbGljZSZxdW90Oy4gJm5ic3A7V2UgYXBwbHkgdGhhdCBpbiBsb3Rz IG9mIHdheXMsIGJ1dCBvbmUgb2YgdGhlbQ0KIGlzIHRoYXQgaWYgeW91IGRvbid0IGltcGxlbWVu dCB3aGF0IHRoZSBkb2N1bWVudCBzYXlzLCB5b3UgbWF5IG5vdCBnZXQgaW50ZXJvcGVyYWJpbGl0 eSB3aXRoIG90aGVyIGltcGxlbWVudGF0aW9ucy4gJm5ic3A7T24gdGhlIG90aGVyIGhhbmQsIHRo ZSB3aG9sZSBwb2ludCBvZiBhIHByb3RvY29sIGRvY3VtZW50IGxpa2Ugb3VycyBpcyB0aGF0IHR3 byBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMgd2hvIGJvdGggZm9sbG93IHRoZSBkb2N1bWVu dCB3aWxsDQogaW50ZXJ3b3JrLiAmbmJzcDtJZiB0aGF0IHdhc24ndCB0cnVlLCB3aHkgZG8geW91 IG5lZWQgYSBzdGFuZGFyZD8gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiB5b3Ugc2F5ICZxdW90O2Vp dGhlciZxdW90OyB0byBib3RoIGVuZHMsIHRoZW4geW91IGRvbid0IGdldCBpbnRlcm9wZXJhYmls aXR5LiAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QnkgeW91ciBhcmd1bWVudCwg d2Ugc2hvdWxkIHN0b3Agd29ya2luZywgYW5kIHRoZSBwcm9kdWN0IG1hbmFnZXJzIHdpbGwgZmln dXJlIGl0IG91dCB1c2luZyBwcm9wcmlldGFyeSBwcm90b2NvbHMuICZuYnNwO1RoZQ0KIG1hcmtl dCB3aWxsIGRlY2lkZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U28sIEkgZmVlbCBzdHJv bmdseSB0aGF0IGlmIG9uZSBlbmQgaXMgJnF1b3Q7ZWl0aGVyJnF1b3Q7LCB0aGUgb3RoZXIgZW5k IG11c3QgYmUgJnF1b3Q7Ym90aCZxdW90Oy4gJm5ic3A7SXQncyBhbHNvIGFjY2VwdGFibGUgdG8g c2F5IGJvdGggZW5kcw0KIGltcGxlbWVudCBvbmUgY2hvaWNlIGFuZCB0aGUgb3RoZXIgaXMgb3B0 aW9uYWwgYXQgYm90aCBlbmRzLiAmbmJzcDtIZXJlLCBJIHRoaW5rIGl0J3Mgc2VydmVyIGRvZXMg Ym90aCBhbmQgY2xpZW50IGRvZXMgZWl0aGVyLiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo4LjVw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5JdCdzIGFsd2F5cyBwb3NzaWJsZSB0byBidWlsZCBhbiBpbXBsZW1lbnRhdGlvbiBvZiBh IHNlcnZlciB0aGF0IG9ubHkgZG9lcyBvbmU6IHRoZXJlIGFyZSBubyBwcm90b2NvbCBwb2xpY2Uu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkJyaWFuICZsdDthcyBpbmRpdmlkdWFsJmd0Ozwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5PbiBBdWcgMjMsIDIwMTIsIGF0IDM6MTEgUE0sIERvbiBKb3Ns eW4gJmx0OzxhIGhyZWY9Im1haWx0bzpkLmpvc2x5bkBzcGVjdHJ1bWJyaWRnZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5kLmpvc2x5bkBzcGVjdHJ1bWJyaWRnZS5jb208L2E+Jmd0Ow0KIHdyb3RlOjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgQmVuLDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhhdCB3YXMgbXkgb3JpZ2luYWwgc3VnZ2VzdGlvbiwgYW5kIEkg c3RpbGwgdGhpbmsgaXQgbWFrZXMgdGhlIG1vc3Qgc2Vuc2UuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHN1cHBvcnRpbmcgdGhlIHByb3Bvc2FsLjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RG9uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY207Ym9yZGVyLWNvbG9yOmN1cnJlbnRDb2xvciBjdXJyZW50Q29s b3IiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBw bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpw YXdzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wYXdzLWJvdW5jZXNAaWV0Zi5v cmc8L2E+DQogWzxhIGhyZWY9Im1haWx0bzpwYXdzLSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpw YXdzLTwvYT48YSBocmVmPSJtYWlsdG86Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmJvdW5jZXNAaWV0Zi5vcmc8L2E+XTxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9Inlp djE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+QmVuamFt aW4NCiBBLiBSb2xmZTxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIx YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGh1cnNkYXksIEF1Z3VzdCAyMywg MjAxMiAzOjA1IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wYXdzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+UmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmYW1wOyBp Q2FsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlNvbWVvbmUgc3VnZ2VzdGVkIHRoYXQgUEFX UyBkZWZpbmUgYm90aCwgYW5kIGxldCB0aGUgdmVuZG9ycyBkZWNpZGUgd2hpY2ggb25lcyB0byBp bXBsZW1lbnQuPGJyPg0KVGhhdCBtYWtlcyB0aGUgbW9zdCBzZW5zZSBmb3IgYm90aCBEQiBhbmQg ZGV2aWNlIHZlbmRvcnMuJm5ic3A7IE1hcmtldHMgd2lsbCBwcm9iYWJseSBkcml2ZSBEQiB2ZW5k b3JzIHRvIGRvIGJvdGguIERldmljZSB2ZW5kb3JzIHdpbGwgZG8gd2hhdCBmaXRzIHRoZSBtYXJr ZXQgc2VnbWVudCB0aGV5J3JlIGFmdGVyLiBXaHkgb3Zlci1jb25zdHJhaW4gKG9yIGFyZ3VlIHdo ZW4gbmF0dXJhbCBzZWxlY3Rpb24gd2lsbCB0YWtlIGNhcmUgb2YgaXQgZm9yIHVzPykuPGJyPg0K Qjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5Tb3VuZHMgZ29vZCB0byBtZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY207Ym9yZGVyLWNvbG9yOmN1cnJlbnRDb2xvciBjdXJyZW50Q29sb3IiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVy dGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwYXdzLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5w YXdzLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIx YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+WzxhIGhyZWY9Im1haWx0bzpwYXdz LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5tYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9 InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5Pbg0K IEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9iPjxhIGhyZWY9Im1haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb20i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5HYWJvci5CYWprb0Bu b2tpYS5jb208L3NwYW4+PC9hPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAx NTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgQXVndXN0 IDIxLCAyMDEyIDEyOjQyIEFNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5 NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBh d3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5w YXdzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0i eWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbcGF3 c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJmFtcDsgaUNhbDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPk5vdyBJIGNhbuKAmXQgc2VlIGFueW1vcmUgYW55IHdpbGxpbmduZXNzIHRvIGFn cmVlIG9uIG9uZSBvciB0aGUgb3RoZXIgZW5jb2RpbmcuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjpibGFjayI+VG8gcHJldmVudCBlbmRsZXNzIGRpc2N1c3Npb25zIG9uIHRoaXMgdG9waWMgSeKA mWQgc3VnZ2VzdCB3ZSBtb3ZlIGZvcndhcmQgd2l0aCBzdXBwb3J0aW5nIGJvdGggaW4gdGhlIERC IGFuZCBlaXRoZXIgb25lDQogaW4gdGhlIG1hc3RlciBkZXZpY2UuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+QW55IG9iamVjdGlvbnM/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+R2Fib3I8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY207Ym9yZGVyLWNv bG9yOmN1cnJlbnRDb2xvciBjdXJyZW50Q29sb3IiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5wYXdzLWJvdW5jZXNAaWV0Zi5vcmc8 L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+WzxhIGhyZWY9Im1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86cGF3cy1ib3Vu Y2VzQGlldGYub3JnPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5Pbg0KIEJlaGFsZiBPZjxzcGFuIGNsYXNz PSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPmV4 dCBEYXMsIFN1YmlyPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Nb25kYXksIEF1Z3VzdCAyMCwgMjAx MiAyOjUwIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RG9uIEpvc2x5bjsgVmluY2VudCBDaGVuOyBX ZWl4aW5wZW5nPGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5wYXdzQGlldGYu b3JnPC9zcGFuPjwvYT47IE1hbmlra290aCBTYWplZXY8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3Bh biBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PlJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJmFtcDsgaUNhbDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPldlIGhhdmUgYSBoYWxmIGEgZG96ZW4gb3IgbW9yZSBUVkRCIHJh ZGlvIHZlbmRvcnMgdGhhdCB1c2UvcHJlZmVyIEpTT04gYW5kIHdlIHdpbGwgdm90ZSBmb3IgSlNP TiBpZiB3ZSBoYWQgdG8gcGljayBvbmUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ QWxzbyBJIHdpbGwgY29weSB0aGUgZm9sbG93aW5nIHR3byBpbXBvcnRhbnQgcG9pbnRzOjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw1IGxldmVsMiBsZm8xO2JhY2tncm91 bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ U2ltcGxlLXRvLXVzZSBsaWJyYXJpZXMgZXhpc3QgZm9yIGFsbCBtYWpvciBsYW5ndWFnZXMvcGxh dGZvcm1zPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bh bj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNSBs ZXZlbDIgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPkRvbid0IG5lZWQgYSB0b29sIGNoYWluIHRvIHdvcmsgd2l0aCB0 aGUgZGF0YSwgYXMgaXMgdHlwaWNhbGx5IG5lZWRlZCBmb3IgWE1MPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L3VsPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4 dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtO2JvcmRlci1jb2xvcjpjdXJyZW50Q29s b3IgY3VycmVudENvbG9yIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0ieWl2 MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBo cmVmPSJtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+cGF3cy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh biBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5bbWFpbHRvOnBhd3MtYm91bmNlc0Bp ZXRmLm9yZ108L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24NCiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0ieWl2 MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5Eb24gSm9z bHluPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Nb25kYXksIEF1Z3VzdCAyMCwgMjAxMiA0OjU0IFBN PGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+VmluY2VudCBDaGVuOyBXZWl4aW5wZW5nPGJyPg0KPGI+Q2M6 PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5wYXdzQGlldGYub3JnPC9zcGFuPjwvYT47IE1hbmlr a290aCBTYWplZXY8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQy MWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbcGF3c10gWE1MIHNjaGVt YSB2ZXJzdXMgSlNPTiwgdkNhcmQgJmFtcDsgaUNhbDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlBs ZWFzZSBzZWUgbXkgY29tbWVudHMgYmVsb3figKY8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5UaGFua3MsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RG9uPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY207Ym9yZGVyLWNvbG9yOmN1cnJlbnRDb2xvciBj dXJyZW50Q29sb3IiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAx NTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9 Im1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5wYXdzLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGNs YXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Wzxh IGhyZWY9Im1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnPC9zcGFu PjwvYT5dPHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48Yj5Pbg0KIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlZpbmNlbnQgQ2hlbjxicj4NCjxi PlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+TW9uZGF5LCBBdWd1c3QgMjAsIDIwMTIgMjo1NiBQTTxicj4NCjxiPlRv OjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPldlaXhpbnBlbmc8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9InlpdjE4MDE1 Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86 cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PnBhd3NAaWV0Zi5vcmc8L3NwYW4+PC9hPjsgTWFuaWtrb3RoIFNhamVldjxicj4NCjxiPlN1Ympl Y3Q6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+UmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmYW1w OyBpQ2FsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZTt2 ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5PbmUgb2Ygb3VyIGdvYWxzIGlzIHRvIHN0cml2ZSB0byBsb3dlciB0aGUg Y29zdCBhbmQgY29tcGxleGl0eSBmb3IgZGV2aWNlIG1hbnVmYWN0dXJlcnMuIFRoaXMgbG93ZXJz IHRoZSBiYXJyaWVyIGZvciBidWlsZGluZyBhIHJvYnVzdCBlY29zeXN0ZW0uPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bREogLSBUaGUg4oCcY29z dOKAnSBhbmQgY29tcGxleGl0eSBvZiB1c2luZyBYTUwgaGFzIG5vdCBiZWVuIGFuIGlzc3VlIGZv ciB0aGUgaGFsZiBkb3plbiBUVkJEIHZlbmRvcnMgdGhhdCBoYXZlIGFscmVhZHkgdXNlZCBYTUwu IE1heWJlDQogd2UgbmVlZCB0byBiZXR0ZXIgZGVmaW5lIOKAnGNvc3TigJ0/XTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzM7YmFja2dyb3VuZDp3aGl0ZTt2 ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5UbyByZWR1Y2UgY29tcGxleGl0eSBhbmQgY29zdCBmb3IgZGV2aWNlIG1h a2Vycywgc3VwcG9ydGluZyAxIGVuY29kaW5nIGlzIGJldHRlciB0aGFuIGJvdGgsIGFzIEJyaWFu IHBvaW50cyBvdXQuIFdpRmkgYWNjZXNzIHBvaW50cyB0aGF0ICZxdW90O2p1c3Qgd29yayZxdW90 OyBhbnl3aGVyZSBpbiB0aGUgd29ybGQgc2VydmVzDQogYXMgYSBnb29kIG1vZGVsLjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0RKIC0gSSBwcm9w b3NlZCB0aGF0IHRoZSBkYXRhYmFzZXMgc3VwcG9ydCBib3RoIFhNTCBhbmQgSlNPTiwgZGV2aWNl cyBvbmx5IG5lZWQgdG8gc3VwcG9ydCBvbmUgdG8gdGFsayB0byB0aGUgZGF0YWJhc2UuIE91ciBj dXJyZW50DQogZGF0YWJhc2Ugc3VwcG9ydHMgWE1MIGFuZCBKU09OLCBidXQgaWYgSeKAmW0gZm9y Y2VkIHRvIHBpY2sgb25seSBvbmUsIHRoZW4gSSB3aWxsIHZvdGUgZm9yIFhNTCBiZWNhdXNlIGl0 4oCZcyB0aGUgb25lIHRoYXQgd2UgY3VycmVudGx5IHVzZSBvbiBhbGwgZW1iZWRkZWQgZGV2aWNl cy5dPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvNDtiYWNr Z3JvdW5kOndoaXRlO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoZXJlJ3MgYSB0cmVuZCBmb3IgQVBJcyBvbiB0 aGUgd2ViIHRvd2FyZHMgSlNPTiAoVHdpdHRlciwgRm91clNxdWFyZSwgRmFjZWJvb2ssIEdvb2ds ZSwgZXRjLikuIE9uZSBvZiB0aGUgbWFqb3IgcmVhc29ucyBpcyB0aGF0IGRldmVsb3BlcnMgKGNs aWVudC1zaWRlKSBwcmVmZXIgaXQgZm9yIGl0cyBzaW1wbGljaXR5Ojwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8dWwgdHlw ZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzU7YmFja2dyb3VuZDp3aGl0ZTt2ZXJ0aWNh bC1hbGlnbjpiYXNlbGluZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5SZXByZXNlbnRhdGlvbiBjbG9zZWx5IG1hdGNoZXMgbW9zdCBkYXRhIG1vZGVscyAo bmVzdGVkIGxpc3RzIGFuZCBtYXBzKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9y OmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwyIGxldmVsMiBsZm81O2JhY2tncm91bmQ6d2hpdGU7dmVydGljYWwtYWxpZ246 YmFzZWxpbmUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ U2ltcGxlLXRvLXVzZSBsaWJyYXJpZXMgZXhpc3QgZm9yIGFsbCBtYWpvciBsYW5ndWFnZXMvcGxh dGZvcm1zPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bh bj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2 ZWwyIGxmbzU7YmFja2dyb3VuZDp3aGl0ZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Eb24ndCBuZWVkIGEgdG9v bCBjaGFpbiB0byB3b3JrIHdpdGggdGhlIGRhdGEsIGFzIGlzIHR5cGljYWxseSBuZWVkZWQgZm9y IFhNTC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvbGk+PC91bD4NCjwvdWw+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFwcGFyZW50bHksIHRo ZSBlZmZpY2llbmN5IGdhaW5zIG9mIEpTT04gYWxzbyBtYXR0ZXIgdG8gdGhlIHNjYWxhYmlsaXR5 IG9mIHNlcnZpbmcgc3lzdGVtcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5bREog4oCTIEkgY2Fu4oCZdCBhcmd1ZSBhZ2FpbnN0IHRoZXNlIGxpc3Rl ZCBwcm9zIGZvciBKU09OLCBlc3BlY2lhbGx5IHdoZW4geW914oCZcmUgZGVhbGluZyB3aXRoIGEg bG90IG9mIGRhdGEgKGxpa2UgVHdpdHRlciwgRm91clNxdWFyZSwNCiBGYWNlYm9vayBhbmQgR29v Z2xlIGRvZXMpLiBCdXQgSeKAmW0gYXNzdW1pbmcgdGhhdCBQQVdTIG1lc3NhZ2VzIHdpbGwgbm90 IGJlIGV4Y2hhbmdlZCBuZWFybHkgYXMgb2Z0ZW4gYXMgdGhlIGFwcGxpY2F0aW9ucyBtZW50aW9u ZWQgYWJvdmUuIEJ1dCBhZ2FpbiwgSSBrbm93IEpTT04gaXMgbW9yZSBlZmZpY2llbnQsIGNhbuKA mXQgYXJndWUgd2l0aCB0aGF0Ll08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8dWwgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omwx IGxldmVsMSBsZm82O2JhY2tncm91bmQ6d2hpdGU7dmVydGljYWwtYWxpZ246YmFzZWxpbmUiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QXQgdGhlIGVuZCBv ZiB0aGUgZGF5LCBpdCdzIHRoZSBkYXRhIG1vZGVsIHRoYXQgbWF0dGVycywgcmF0aGVyIHRoYW4g dGhlIGVuY29kaW5nLiBXZSAoR29vZ2xlKSBhcmUgYWN0dWFsbHkgbmV1dHJhbCBvbiBYTUwgdnMg SlNPTiwgYXMgbG9uZyBhcyB3ZSdyZSBjbGVhciBvbiB3aGF0IGRldmljZSBtYWtlcnMNCiB3YW50 LiBJdCB3b3VsZCBiZSBnb29kIHRvIGdldCBmZWVkYmFjayBmcm9tIGRldmljZSBtYWtlcnMgKGVz cGVjaWFsbHkgb2YgZW1iZWRkZWQgZGV2aWNlcykgcmVnYXJkaW5nIGV4cGVyaWVuY2VzIHN1cHBv cnRpbmcgWE1MIHZzIEpTT04uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRvbiwgY2FuIHlvdSBl bGFib3JhdGUgb24gdGhlIHR5cGVzIG9mIGRldmljZXMgdGhhdCBhbHJlYWR5IHN1cHBvcnQgWE1M Pzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltESiAtIFdlIGN1cnJlbnRseSBz dXBwb3J0IGhhbGYgYSBkb3plbiBUVkRCIHJhZGlvIHZlbmRvcnMgKGVtYmVkZGVkIGRldmljZXMp IHVzaW5nIFhNTCwgbm9uIHVzaW5nIEpTT04uIFhNTCBoYXMgbm90IGJlZW4gYSBidXJkZW4sDQog YW5kIHRoZSBhbW91bnQgb2YgZGF0YSB0aGF0IG5lZWRzIHRvIGJlIGV4Y2hhbmdlZCBiZXR3ZWVu IGRldmljZSBhbmQgZGF0YWJhc2UgaXMgbm90IHRoYXQgbXVjaCBvciBleGNoYW5nZWQgdGhhdCBv ZnRlbi5dPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+T24gRnJpLCBBdWcgMTcsIDIwMTIgYXQgNjowNiBQTSwgV2Vp eGlucGVuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndlaXhpbnBlbmdAaHVhd2VpLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPndlaXhpbnBlbmdAaHVhd2VpLmNv bTwvc3Bhbj48L2E+Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5Db25zaWRlcmluZyBvZiB0aGUgZGVzaWduIG9mIGRhdGFiYXNl IGRpc2NvdmVyeSBwcm90b2NvbCwgdGhlIExvU1QgcHJvdG9jb2wgbWF5IGJlIHVzZWQgYW5kIExv U1QgaXMgYmFzZWQgb24gWE1MLCBzbw0KIEkgdGhpbmsgWE1MIG1heSBiZSBwcmVmZXJyZWQuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPi0tWGlucGVuZyBXZWk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbTtib3JkZXItY29sb3I6Y3VycmVudENvbG9yIGN1cnJlbnRDb2xv ciI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBh d3MtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPnBhd3MtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9InlpdjE4 MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5wYXdzLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08c3Bh biBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxiPk9uDQogQmVoYWxmIE9mPHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+Um9zZW4sIEJyaWFuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkZyaWRheSwgQXVndXN0IDE3LCAyMDEyIDk6MjYg UE08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VG86PC9zcGFuPjwvYj48c3Bh biBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk1hbmlra290aA0KIFNhamVldjs8c3BhbiBj bGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxh IGhyZWY9Im1haWx0bzpnYWJvci5iYWprb0Bub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5nYWJvci5iYWprb0Bub2tpYS5jb208L3NwYW4+PC9hPjs8 c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzp2Y2hlbkBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dmNoZW5AZ29vZ2xlLmNvbTwvc3Bhbj48L2E+OzxzcGFu IGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnBldGVyQHNwZWN0cnVtYnJpZGdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBldGVyQHNwZWN0cnVtYnJpZGdlLmNvbTwvc3Bh bj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPGI+Q2M6PC9iPjxz cGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5wYXdzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJmFt cDsgaUNhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+SSBkb24ndCByZWFsbHkgY2FyZSB3aGV0aGVyIHdlIHVzZSBqc29uIG9yIHhtbCBhcyBh IG1hdHRlciBvZiBwcm90b2NvbCBkZXNpZ24gb3IgaW1wbGVtZW50YXRpb24sIGJ1dCBJIGFtIGEg YmlnIGZhbiBvZg0KIHJldXNpbmcgc3RhbmRhcmRzIHJhdGhlciB0aGFuIGRlZmluaW5nIG5ldyBv bmVzLCBhbmQgSSB3b3VsZCBub3Qgd2FudCB0byBzZWUgdGhlIGNob2ljZSBvZiBqc29uIG1lYW4g d2UgdGhlbiBkZWNpZGUgdG8gcm9sbCBvdXIgb3duIHZlcnN1cyB1c2luZyBleGlzdGluZyBzdGFu ZGFyZHMgYmFzZWQgb24gdGhlIGlkZWEgdGhlcmUgaXMgbm8ganNvbiByZXByZXNlbnRhdGlvbiBv ZiBhbiBleGlzdGluZyBzdGFuZGFyZC4gJm5ic3A7U28sIGlmIGNob29zaW5nDQoganNvbiBtZWFu cyBmb2xrcyBmZWVsIGZyZWUgdG8gaWdub3JlIGV4aXN0aW5nIHhtbCBiYXNlZCBzdGFuZGFyZHMg c3VjaCBhcyB4Q2FyZCBhbmQgTG9TVCwgdGhlbiBJIHdvdWxkIG5vdCB3YW50IHRvIHVzZSBqc29u Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgd291bGQgcHJl ZmVyIHRvIG5vdCBoYXZlICZxdW90O2JvdGgmcXVvdDssIGJlY2F1c2Ugb2YgaW50ZXJvcGVyYWJp bGl0eSBjb21wbGljYXRpb25zLiAmbmJzcDtJZiB0aGVyZSBpcyByb3VnaCBjb25zZW5zdXMgZm9y IGJvdGgsDQogdGhlbiBJIHdvdWxkIGFzc2VydCB0aGF0IGFsbCBzZXJ2ZXJzIGhhdmUgdG8gaW1w bGVtZW50IGJvdGggYW5kIHRoZSBjbGllbnQgY2FuIGltcGxlbWVudCBlaXRoZXIuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhlcmUgYXJlIGpzb24gdmFsaWRh dG9ycywgc28gSSBkb24ndCB0aGluayB0aGF0IGlzIGEgYmlnIGRlYWwuICZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk15IGV4cGVyaWVuY2UgaW4gcHJv dG9jb2wgZGVzaWduIG9uIHRoZSBJbnRlcm5ldCBpcyB0aGF0IGRlY2lzaW9ucyBtYWRlIHNvbGVs eSBvciBldmVuIGxhcmdlbHkgYmVjYXVzZSBvZiBjb21wYWN0bmVzcw0KIGFkdmFudGFnZXMgcmFy ZWx5IGFyZSBnb29kIGNob2ljZXMuICZuYnNwO0lmIHlvdSBsaWtlIGpzb24gYmVjYXVzZSBpdCBp cyBzbWFsbGVyLCB0aGVuIEkgYmVsaWV2ZSB5b3UgbmVlZCBhIG11Y2ggYmV0dGVyIHJlYXNvbi4g Jm5ic3A7QmluYXJ5IGRvZXNuJ3Qgd29yayBmb3IgbWUsIGF0IGFsbC4gJm5ic3A7SSBoYXZlIGJl ZW4gaW52b2x2ZWQgaW4gYmlnIGJpbmFyeSB2cyB0ZXh0IHdhcnMgaW4gcHJvdG9jb2wgZGVzaWdu LiAmbmJzcDtUZXh0IHdpbnMsIGJpbmFyeSBsb3NlcywgaW4NCiBteSBvcGluaW9uLjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkJyaWFuICZsdDthcyBpbmRpdmlk dWFsJmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY207Ym9yZGVyLWNvbG9yOmN1cnJlbnRDb2xvciBjdXJyZW50Q29sb3IiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+RnJvbTo8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TWFuaWtrb3RoDQogU2FqZWV2ICZsdDs8YSBocmVmPSJt YWlsdG86bWtzYWppQHlhaG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPm1rc2FqaUB5YWhvby5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5SZXBseS1U bzo8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvYj5NYW5pa2tvdGggU2FqZWV2ICZsdDs8YSBocmVmPSJtYWlsdG86bWtzYWppQHlh aG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1rc2Fq aUB5YWhvby5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJ5aXYx ODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlRodSwgMTYg QXVnIDIwMTIgMjI6Mzc6MzggLTA0MDA8YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0ieWl2MTgwMTUz OTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj4mcXVvdDs8YSBocmVm PSJtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+R2Fib3IuQmFqa29Abm9raWEuY29tPC9zcGFuPjwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb20iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5HYWJvci5CYWprb0Bub2tpYS5jb208L3NwYW4+ PC9hPiZndDssDQogJnF1b3Q7Um9zZW4sIEJyaWFuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 YnJpYW4ucm9zZW5AbmV1c3Rhci5iaXoiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5icmlhbi5yb3NlbkBuZXVzdGFyLmJpejwvc3Bhbj48L2E+Jmd0OywgJnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOnZjaGVuQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj52Y2hlbkBnb29nbGUuY29tPC9zcGFuPjwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzp2Y2hlbkBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+dmNoZW5AZ29vZ2xlLmNvbTwvc3Bhbj48L2E+Jmd0OywNCiAm cXVvdDs8YSBocmVmPSJtYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29t PC9zcGFuPjwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwZXRlckBzcGVjdHJ1bWJyaWRn ZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5wZXRlckBz cGVjdHJ1bWJyaWRnZS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0i eWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj4mcXVv dDs8YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnBhd3NAaWV0Zi5vcmc8L3NwYW4+PC9hPiZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5wYXdzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj dDo8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvYj5SZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJkICZhbXA7 IGlDYWw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkhpLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5DYW4gaXQgbm90IGJlIGJvdGggSlNPTiBhbmQgWE1MIHN1cHBvcnRl ZD8gSSB3b3VsZCB2b3RlIGZvciB0aGF0LiBGdXR1cmUgaW1wbGVtZW50YXRpb25zIG1heSBwcmVm ZXI8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxiPlhNTA0KIGFzIGl0IGlzIGdlbmVyaWMsJm5ic3A7b21uaSBwcmVzZW50LCBlYXN5 IHRvIHVuZGVyc3RhbmQgYW5kIHZhbGlkYXRlLjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQy MWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkZvciBjb21wYWN0bmVzcyBtYXkg YmUgYSZuYnNwOzxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGI+YmluYXJ5IHhtbCBvcHRpb248L2I+Y2FuIGFsc28gd29yay4gSlNP TiBJIHRoaW5rDQogd2lsbCBuZWNlc3NpdGF0ZSBpbXBsZW1lbnRhdGlvbiB0byBiZSBuYXRpdmUg SmF2YSBhbmQgbWF5IG5vdCBiZSBhcyBmcmllbmRseSB3aXRoIG90aGVyIGltcGxlbWVudGF0aW9u IGxhbmd1YWdlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QmVzdCBSZWdhcmRz LDwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPlNhamVldiBNYW5pa2tvdGg8YnI+DQpNb2JpbGU6PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0 MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iTXNvSHlw ZXJsaW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mIzQzOzkxODc5MjI5MjAwMjwvc3Bh bj48L3NwYW4+PGJyPg0KRW1haWw6PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWtzYWppQGllZWUub3Jn IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWtzYWppQGllZWUu b3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9t a3NhamVldiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6 Ly93d3cubGlua2VkaW4uY29tL2luL21rc2FqZWV2PC9zcGFuPjwvYT48L3NwYW4+PC9pPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0i eWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m cXVvdDs8YSBocmVmPSJtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+R2Fib3IuQmFqa29Abm9raWEuY29tPC9zcGFu PjwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkdhYm9yLkJhamtvQG5va2lhLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPkdhYm9yLkJhamtvQG5v a2lhLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0ieWl2MTgw MTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpeiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PC9zcGFuPjwvYT47PHNwYW4gY2xh c3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86dmNoZW5AZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPnZjaGVuQGdvb2dsZS5jb208L3NwYW4+PC9hPjs8c3BhbiBjbGFzcz0i eWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpwZXRlckBzcGVjdHJ1bWJyaWRnZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5wZXRlckBzcGVjdHJ1bWJyaWRnZS5jb208L3NwYW4+PC9hPjxz cGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5wYXdzQGlldGYub3JnPC9z cGFuPjwvYT48c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIx YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnJpZGF5LCAxNyBBdWd1c3QgMjAx MiwgNDo1NTxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZl cnN1cyBKU09OLCB2Q2FyZCAmYW1wOyBpQ2FsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxicj4NCldlIGhhdmUgbm90IGhlYXJkIGFueSBvYmplY3Rpb25zIGZv ciB1c2luZyBKU09OIGVuY29kaW5nIGluc3RlYWQgb2YgWE1MLjxzcGFuIGNsYXNzPSJ5aXYxODAx NTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KVGhlcmVmb3Jl LCBsZXQncyBnbyBmb3IgSlNPTiwgYW5kIGNsb3NlIHRoaXMgdGhyZWFkLjxicj4NCjxicj4NCi0g R2Fib3I8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206PHNw YW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGF3cy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwv YT48c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPlttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBhd3MtYm91bmNlc0BpZXRm Lm9yZzwvc3Bhbj48L2E+XQ0KIE9uIEJlaGFsZiBPZiBleHQgUm9zZW4sIEJyaWFuPGJyPg0KU2Vu dDogTW9uZGF5LCBBdWd1c3QgMTMsIDIwMTIgMzoxNCBQTTxicj4NClRvOiAnVmluY2VudCBDaGVu JzsgJ1BldGVyIFN0YW5mb3J0aCc8YnI+DQpDYzogJzxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGF3c0BpZXRm Lm9yZzwvc3Bhbj48L2E+Jzxicj4NClN1YmplY3Q6IFJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJz dXMgSlNPTiwgdkNhcmQgJmFtcDsgaUNhbDxicj4NCjxicj4NCmpzb24gaXMgb2theSB3aXRoIG1l LiZuYnNwOzxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyPg0KSSdkIHByZWZlciBhbiBJU08gdGltZSBzdGFtcCByYXRoZXIgdGhh biBhIHRpbWUgaW4gc2Vjb25kcyBzaW5jZSBlcG9jaC4mbmJzcDsgSXQncyB2ZXJ5IGVhc3kgdG8g cGFyc2UsIGFuZCBpdHMgc2ltcGxlciB0byB1c2UgYW5kIGRlYnVnLiZuYnNwOyBEb24ndCBjYXJl IGEgd2hvbGUgbG90IGFib3V0IHRoYXQ8YnI+DQo8YnI+DQpCcmlhbiAmbHQ7YXMgaW5kaXZpZHVh bCZndDs8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCkZyb206ICZuYnNwOyZuYnNwOyZuYnNwOyBWaW5jZW50IENoZW4gW21haWx0bzo8YSBocmVm PSJtYWlsdG86dmNoZW5AZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPnZjaGVuQGdvb2dsZS5jb208L3NwYW4+PC9hPl08YnI+DQpTZW50OiZuYnNw OyZuYnNwOyZuYnNwOyBNb25kYXksIEF1Z3VzdCAxMywgMjAxMiAwNjowNCBQTSBFYXN0ZXJuIFN0 YW5kYXJkIFRpbWU8YnI+DQpUbzombmJzcDsmbmJzcDsmbmJzcDsgUGV0ZXIgU3RhbmZvcnRoPGJy Pg0KQ2M6Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvc2VuLCBCcmlhbjsgVGVjbyBCb290OyBCZW5qYW1p biBBLlJvbGZlOzxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5wYXdzQGlldGYub3JnPC9zcGFuPjwvYT48 YnI+DQpTdWJqZWN0OiZuYnNwOyZuYnNwOyZuYnNwOyBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVy c3VzIEpTT04sIHZDYXJkICZhbXA7IGlDYWw8YnI+DQo8YnI+DQpYTUwgdnMgSlNPTjxicj4NCjxi cj4NCkJldHdlZW4gWE1MIGFuZCBKU09OLCBKU09OIG1lc3NhZ2VzIGFyZSBtb3JlIGNvbXBhY3Qg YW5kIGVhc2llciB0byBwcm9jZXNzIChwYXJzaW5nLCBzeW50aGVzaXMpLiBBcyBjbGFyaWZpY2F0 aW9uLCBKU09OIGRvZXMgbm90IHJlcXVpcmUgSmF2YVNjcmlwdCBvciBhIEJyb3dzZXIuIEl0IGlz IGEgdGV4dC1iYXNlZCByZXByZXNlbnRhdGlvbiBvZiBkYXRhIHRoYXQgaXMgbGFuZ3VhZ2UgaW5k ZXBlbmRlbnQsIHlldCB3ZWxsLW1hdGNoZWQgdG8gYWxsDQogbWFqb3IgbGFuZ3VhZ2VzLiBKU09O LWhhbmRsaW5nIGxpYnJhcmllcyBleGlzdCBmb3IgbnVtZXJvdXMgbGFuZ3VhZ2VzIChzZWUgb2Y8 c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Imh0dHA6Ly9qc29uLm9yZy8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5odHRwOi8vanNvbi5vcmcvPC9zcGFuPjwvYT4pIGFuZCBzZWVtIHRv IGJlIHJlYXNvbmFibHkNCiBsaWdodCB3ZWlnaHQuPGJyPg0KPGJyPg0KVGltZXN0YW1wczxicj4N Cjxicj4NCkFzIGZvciB0aW1lc3RhbXAgc3BlY2lmaWNhdGlvbnMsIHNob3VsZCB3ZSBjb25zaWRl ciBqdXN0IHVzaW5nIHNlY29uZHMgc2luY2UgdGhlIFVOSVggRXBvY2ggKDE5NzAtMDEtMDFUMDA6 MDA6MDBaKT8gVGhpcyB3b3VsZCBlbGltaW5hdGUgdGhlIG5lZWQgZm9yIGRhdGV0aW1lLXN0cmlu ZyBwYXJzaW5nIG9uIGRldmljZXMsIGFzc3VtaW5nIGRldmljZXMgYWxyZWFkeSBoYXZlIG5hdGl2 ZSBsaWJyYXJpZXMgdGhhdCBwcm92aWRlIHRpbWUgaW4gdGhpcw0KIGZvcm1hdC4gSXMgdGhhdCBh IHZhbGlkIGFzc3VtcHRpb24/IE9mIGNvdXJzZSwgdGhpcyBpcyBsZXNzIGh1bWFuLXJlYWRhYmxl Li4uLjxicj4NCjxicj4NCjxicj4NCk9uIE1vbiwgQXVnIDEzLCAyMDEyIGF0IDY6NDkgQU0sIFBl dGVyIFN0YW5mb3J0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBldGVyQHNwZWN0cnVtYnJpZGdlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBldGVyQHNwZWN0 cnVtYnJpZGdlLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsgV2hlbmV2ZXIgd2UgYnVpbHQgbW9iaWxlIGRldmljZXMgd2UgbmV2ZXIg ZGVhbHQgd2l0aCBJRVRGLCBpbiBvdXIgc2Vuc29yPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGRh eXMgZXZlbiBhbiBJUCBzdGFjayB3YXMgYSBjaGFsbGVuZ2Usc28gSSB3b3VsZCBkZWZlciB0byB0 aGUgZGV2aWNlIGd1eXM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgb24gdGhhdCBvbmUuPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgT24gTW9uQXVn LzEzLzEyIE1vbiBBdWcgMTMsIDk6MzAgQU0sICZxdW90O1Jvc2VuLCBCcmlhbiZxdW90Ozxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBo cmVmPSJtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXoiIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5Ccmlhbi5Sb3NlbkBuZXVzdGFyLmJpejwvc3Bhbj48L2E+ Jmd0OyB3cm90ZTo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ieWl2MTgwMTUz OTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7T3VyIGV4cGVyaWVuY2UgaW4gdGhlIElFVEYgb3ZlciBtYW55IHllYXJzIGlz IHRoYXQgZWNvbm9taXppbmcgbWVzc2FnZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7c2l6 ZSBhbmQgY29tcHJvbWlzaW5nIHV0aWxpdHkgYW5kIHNlY3VyaXR5IGluIHNlYXJjaCBvZiBlZmZp Y2llbmN5IG9mPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDtpbXBsZW1lbnRhdGlvbiBvbiBz bWFsbCBkZXZpY2VzIGlzIGEgcG9vciB0cmFkZSBvZmYuJm5ic3A7IEkgYW0gbm90IGFkdm9jYXRp bmc8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0O2JlaW5nIHdhc3RlZnVsIG9mIHJlc291cmNl cywgYnV0IEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIHNlcmlvdXNseTxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Y29uc2lkZXIgdGhlIG92ZXJoZWFkIG9mIFhNTCBvciBqc29uIHRvIGJlIHNp Z25pZmljYW50Ljxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDtBc3N1bWluZyBhIGpzb24gbGlicmFyeSBjYW4gYmUgbG9hZGVkIG9uIGEgc21h bGwgZGV2aWNlIGlzIHJlYXNvbmFibGUuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0O0JyaWFuIChhcyBpbmRpdmlkdWFsKTxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDtGcm9tOiZuYnNw OyBQZXRlciBTdGFuZm9ydGggW21haWx0bzo8YSBocmVmPSJtYWlsdG86cGV0ZXJAc3BlY3RydW1i cmlkZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGV0 ZXJAc3BlY3RydW1icmlkZ2UuY29tPC9zcGFuPjwvYT5dPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDtTZW50OiZuYnNwOyBTYXR1cmRheSwgQXVndXN0IDExLCAyMDEyIDA3OjEzIEFNIEVhc3Rl cm4gU3RhbmRhcmQgVGltZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7VG86Jm5ic3A7ICZu YnNwOyBUZWNvIEJvb3Q7IEJlbmphbWluIEEuUm9sZmU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg Jmd0O0NjOiZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGF3c0BpZXRmLm9yZzwv c3Bhbj48L2E+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDtTdWJqZWN0OiZuYnNwOyAmbmJz cDsgJm5ic3A7IFJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJmFtcDsg aUNhbDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDtOb3QgYWxsIG1hc3RlcnMgcnVuIG92ZXIgdGhlIGNvcmUgbmV0d29yay48YnI+DQombmJz cDsmbmJzcDsmbmJzcDsgJmd0O1NvbWUgb2YgdGhlIFVzZSBjYXNlcyBoYXZlIGEgbWFzdGVyIHRh bGtpbmcgdG8gYW5vdGhlciBPVEE8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0O1dlIHNob3Vs ZCBub3QgYXNzdW1lIHRoYXQgYWxsIE1hc3RlcnMgYXJlIGF0dGFjaGVkIHRvIHV0aWxpdHkgcG93 ZXIgc28gd2U8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0O3Nob3VsZCBiZSBzeW1wYXRoZXRp YyB0byBwcm9jZXNzaW5nIGVuZXJneSB1c2UgYWxzby48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7T24gU2F0QXVnLzExLzEyIFNhdCBBdWcg MTEsIDU6MzAgQU0sICZxdW90O1RlY28gQm9vdCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRl Y29AaW5mLW5ldC5ubCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PnRlY29AaW5mLW5ldC5ubDwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgJmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0O09wIDEwIGF1Zy4gMjAxMiwgb20gMTg6MTAgaGVlZnQgQmVuamFt aW4gQS4gUm9sZmUgaGV0IHZvbGdlbmRlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Z2VzY2hyZXZlbjo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDs8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IENvbXBhY3RuZXNzIG9mIG1lc3NhZ2VzIGlzIGltcG9y dGFudCwgYnV0IGl0IGlzIGFsc28gaW1wb3J0YW50ICh0byBtZTxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jmd0OyZndDthdCBsZWFzdCkgdG8gYmUgcmVhbGl6YWJsZSBpbiBhbiBpbXBsZW1l bnRhdGlvbiB3aXRoIGxpbWl0ZWQgcmVzb3VyY2VzLDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyZndDtzdWNoIGFzIGVtYmVkZGVkIGRldmljZXMgaW4gd2hhdCBhcmUgbm93IHBvcHVs YXJseSBjYWxsZWQgJnF1b3Q7TTJNJnF1b3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0O2FwcGxpY2F0aW9ucy4mbmJzcDsgQSBsb3Qgb2YgdGhlc2UgZGV2aWNlcyBjb3VsZCB1 c2UgSVAgYWxsIHRoZSBlbmQgdG8gZW5kLDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDtidXQgbWF5IGhhdmUgYSB2ZXJ5IGNvbXBhY3QsIHNpbXBsZSBzdGFjayBhbmQgYXBwbGlj YXRpb25zIChpLmUuJm5ic3A7IG5vPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0 O2Jyb3dzZXIpLiZuYnNwOyBJcyBKU09OIHR5cGljYWxseSBpbXBsZW1lbnRlZCB3aGVuIHRoZXJl IGlzIG5vIGJyb3dzZXI/PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0O1dvdWxk IGl0IGJlIGhhcmQgdG8gZG8gaW4gYSByZXNvdXJjZSBjb25zdHJhaW5lZCBkZXZpY2UgKGkuZS4g d2hlcmUgd2U8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7dGFsayBhYm91dCBt ZW1vcnkgc2l6ZSBpbiBLaWxvLWJ5dGVzIHN0aWxsKS48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDtJbiB1c2UgY2FzZXMgYW5k IHJlcXVpcmVtZW50cyBkb2N1bWVudCwgdGhlcmUgYXJlIG5vIHJlcXVpcmVtZW50cyBmb3I8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDtwcm90b2NvbCBwZXJmb3JtYW5jZS4gSSBndWVz cyBPUy9JUC9UQ1AvVExTIGNvZGUgc2l6ZSBzdXBlcnNlZGVzIG5lZWRzPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Zm9yIEpTT04gb3IgWE1MLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0O1NhbWUgZm9yIHRpbWlu ZzogVENQL1RMUyBjb25uZWN0aW9uIHNldHVwIHdpbGwgdGFrZSBtb3JlIHRoYW4gdGhlIFBBV1M8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDttZXNzYWdlIGV4Y2hhbmdlLCBJIHRoaW5r LiBUaGlzIG1heSBiZSBvZiBpbXBvcnRhbmNlIHdoZW4gdXNpbmcgc2F0Y29tPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7bGlua3MuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7QmVjYXVzZSBQQVdTIHJ1bnMgYmV0 d2VlbiBtYXN0ZXIgYW5kIGRhdGFiYXNlLCBvdmVyIGNvcmUgbmV0d29yayw8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDtwZXJmb3JtYW5jZSBpcyBub3Qgb3VyIHByaW1hcnkgY29uY2Vy bi4gQnV0IGFzIGFsd2F5cywgaXQgaXMgZ29vZCB0byBrZWVwPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7YW4gZXllIG9uIGVmZmljaWVuY3kuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7VGVjbzxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZn dDsgVGhhbmtzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBCZW48YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IFdlIGhh ZCBhIGRpc2N1c3Npb24gb24gWE1MIHZzLiBKU09OLiBJIHByZWZlciB0aGUgb25lIHdpdGggbW9z dDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Y29tcGFjdCBtZXNzYWdl cy48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIHZDYXJkIGFuZCBKU09OOiB3aGF0IGlzIHRo ZSBzdGF0dXMgb2YgJnF1b3Q7QSBKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbjxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7KEpTT04pIFJlcHJlc2VudGF0aW9uIGZvciB2 Q2FyZCZxdW90Oz88YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OzxzcGFu IGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmhhdC12Y2FyZGRhdi1q c29uLTAwIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmhhdC12Y2FyZGRhdi1qc29uLTAwPC9zcGFuPjwv YT48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIHZhbGlkIHRpbWVzOiBjYW4gd2UgdXNlIHNh bWUgZm9ybWF0IGFzIGNlcnRpZmljYXRlcz8gVGhleSBoYXZlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDtzaW1pbGFyIHNpbXBsZSByZXF1aXJlbWVudHM6IHZhbGlkIG5v dEJlZm9yZSZhbXA7Jm5ic3A7IG5vdEFmdGVyLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMz MjgwI3NlY3Rpb24tNC4xLjIuNSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMyODAjc2VjdGlvbi00LjEuMi41 PC9zcGFuPjwvYT48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRlY288YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 IHBhd3MgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDs8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGF3c0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQy MWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGF3czwvc3Bhbj48L2E+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgcGF3cyBtYWlsaW5n IGxpc3Q8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PHNwYW4gY2xhc3M9Inlp djE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJt YWlsdG86cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPnBhd3NAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyZndDs8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcGF3cyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3czwvc3Bhbj48L2E+PGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDtwYXdzIG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OzxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGF3c0BpZXRmLm9yZzwvc3Bhbj48 L2E+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w YXdzPC9zcGFuPjwvYT48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0O3Bhd3MgbWFpbGluZyBsaXN0PGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBhd3NAaWV0Zi5vcmc8L3Nw YW4+PC9hPjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w YXdzPC9zcGFuPjwvYT48YnI+DQombmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ieWl2MTgw MTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBwYXdzIG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5wYXdzQGlldGYub3JnPC9zcGFuPjwvYT48 YnI+DQombmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcGF3cyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3czwvc3Bh bj48L2E+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQotLTxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGJyPg0KLXZpbmNlPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpwYXdzIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+cGF3c0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wYXdzPC9zcGFuPjwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnBhd3MgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5wYXdzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MiIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Bhd3M8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+LS08c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxicj4NCi12aW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+cGF3cyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGF3c0BpZXRmLm9yZzwv c3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Bhd3M8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KcGF3cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBhd3NAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzPC9hPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj5wYXdzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5wYXdzQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdz IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w YXdzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcGF3cyBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBhd3NAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9wYXdzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9wYXdzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpwYXdzIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIj5wYXdzQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3 czwvYT48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8CC0CB0BCAE52F46882E17828A9AE21636860C6DSZXEML508MBSchi_-- From mksaji@yahoo.com Fri Aug 24 22:54:20 2012 Return-Path: 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 9715121F8534 for ; Fri, 24 Aug 2012 22:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] 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 lStxkuPLd6aS for ; Fri, 24 Aug 2012 22:54:17 -0700 (PDT) Received: from nm33-vm5.bullet.mail.ne1.yahoo.com (nm33-vm5.bullet.mail.ne1.yahoo.com [98.138.229.69]) by ietfa.amsl.com (Postfix) with SMTP id CC40721F8533 for ; Fri, 24 Aug 2012 22:54:16 -0700 (PDT) Received: from [98.138.90.53] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 25 Aug 2012 05:54:11 -0000 Received: from [98.138.89.234] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 25 Aug 2012 05:54:11 -0000 Received: from [127.0.0.1] by omp1049.mail.ne1.yahoo.com with NNFMP; 25 Aug 2012 05:54:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 859102.36639.bm@omp1049.mail.ne1.yahoo.com Received: (qmail 57384 invoked by uid 60001); 25 Aug 2012 05:54:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345874051; bh=yujeO0FFNEe3g/StBHkDEr6TchDSB34ycysRsckQ9XQ=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=q1TQsw/tE8nE+qYWtMQJVfCMmqo+c+38vQDbzQF5MzlHPbdcJvXlzURuOIZIxOOWjTKU0uAqKc7XZnaJphtkA+K4W3ZOPrvKcNu3p3UAlOunGACdAZYLM3CMRUQJ/+IpW85pR0OxdQTXyEHv0VQlvKSYzSAfOnqfU5ex4082rrY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SXU1NRa4ogsxkQeskg5VDwomeQqAXN7gEWGPYLxUxCuK+Hi+EeEsi6u9Lr9ic7JD533PGBxt6qFEcPDP1MsqHZNg8xrspXBoMi645a2xcL4kqLxJmOzIPfWPDe0gCbOXdZAXwMeNKD8uL2QAHRjt5nh6JnMf49u3wLa0n3pIUGo=; X-YMail-OSG: DojEyHsVM1nFI5ijg25hB3JmTw2NDeNuUEYK1Qr7vR3B4Sq .5KON1q42iPW_orZ98qLyGvEROwubdHWZZcBoVZvisrkQi7benjYdLWHz8jl Sje1ctjMQkWwCi70uZsnd87FJ3rcrHhbpK9sFojrxauOIOBYdlHVaqODqJy1 W.7DbOQZpsy4iNvY4ULW5XIwNj5cHxiQ0hYdX6i8yWAv6wxsSk_y0IENln.. frWu_bsz9EI53JoYgr2MUAbudNP1dlRPloRqbuPkU0oKmtEHhCR99R2rzjyz FFq0qvScOWpElQ9r6kY_UpvLuItVnlXV3aIokOyzy4yenOrGTrmnsISoMPK0 FAQV_1m6EXS6UyhnTY3m9poJ2WpkhQrexJB6QxRxy1roh0O472LY91LqtgSu cRTGtiUTOaycZwk_PrBuq4X4RIa2BZRviaY3oSp5XBVoITTlzuvsbIDLAJ5m UOLv3uZESrqALv4d3hbhFeei35HU.t2fYRrecbIcqEaiJ1n17F5LiE9XnIhv e6qHLqnkWssP1VLfp8mMjkk_RCHnlyJ2zBZxPEebc1C6KA0UEASOvVvj6RUg - Received: from [117.192.27.184] by web120302.mail.ne1.yahoo.com via HTTP; Fri, 24 Aug 2012 22:54:11 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> <00c601cd820b$67b97170$372c5450$@us> <5037B28B.70501@blindcreek.com> <5D0B1E63-79FE-4BC6-A446-3470931D1043@neustar.biz> <5037BC2B.7010008@blindcreek.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724@008-AM1MPN1-006.mgdnok.nokia.com> <1345864438.6327.YahooMailNeo@web120306.mail.ne1.yahoo.com> Message-ID: <1345874051.20626.YahooMailNeo@web120302.mail.ne1.yahoo.com> Date: Fri, 24 Aug 2012 22:54:11 -0700 (PDT) From: Manikkoth Sajeev To: Vincent Chen In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-874068440-262716099-1345874051=:20626" Cc: "paws@ietf.org" Subject: Re: [paws] XML schema versus JSON, vCard & iCal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Manikkoth Sajeev List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 05:54:20 -0000 ---874068440-262716099-1345874051=:20626 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=0A=C2=A0=0AXML being generic and widely used=C2=A0in all languages=C2= =A0the required libraries and the code is most of the time already there in= the device=C2=A0is the advantage. =0A=0ABest Regards,=0A=C2=A0=0ASajeev Ma= nikkoth=0A=0A=0A =0A=0A________________________________=0A From: Vincent Ch= en =0ATo: Manikkoth Sajeev =0ACc: "paw= s@ietf.org" =0ASent: Saturday, 25 August 2012, 9:06=0ASubje= ct: Re: [paws] XML schema versus JSON, vCard & iCal=0A =0A=0ASajeev,=0A=0A= It's been a while since I've worked with embedded devices. I'm surprised th= at the same concern does not apply to XML. Do you not need libraries to wor= k with XML?=0A=0A=0A=0AOn Fri, Aug 24, 2012 at 8:13 PM, Manikkoth Sajeev wrote:=0A=0AHi,=0A>=C2=A0=0A>I would still support XML. JS= ON libraries are available for all languages. But interfacing and linking s= uch libraries are problematic on embedded devices most of the time. And if = an implementation vouch for multiple such non native language libraries the= n developers life is hell... =0A>=0A>Best Regards,=0A>=C2=A0=0A>Sajeev Mani= kkoth=0A>=0A>=0A> =0A> From: "Gabor.Bajko@nokia.com" =0A>To: Brian.Rosen@neustar.biz; ben@blindcreek.com =0A>Cc: paws@ietf.org = =0A>Sent: Saturday, 25 August 2012, 0:38=0A>=0A>Subject: Re: [paws] XML sch= ema versus JSON, vCard & iCal=0A> =0A>=0A>=0A>WiFi world builds on mandati= ng the implementation (and certification) of a base spec, and a set of opti= onal 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=E2=80=99s list. =0A>=C2=A0 =0A>I=E2=80=99d like to suggest that= we recognize that option A) and B) are valid options, while option C) is i= nvalid, and we should stop debating it. =0A>I=E2=80=99d also like to add th= e obvious option D) to the list, which is that both the master devices and = DBs support one and the same encoding ;) =0A>=C2=A0 =0A>Option A) seems to = be like a good compromise, and would cut discussions short, with the only c= aveat that if there is no strong technical argument for supporting and spec= ifying 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= . =0A>=C2=A0 =0A>Is there anyone who has a technical argument against supp= orting only one encoding, being that either xml or json? =0A>=C2=A0 =0A>Mos= t 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 g= ave no real reason. So I am wondering if there is really any valid technica= l reason against using JSON only? =0A>=C2=A0 =0A>-=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Gabor =0A>=C2=A0 =0A>=C2=A0 =0A>From:paws-bo= unces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Rosen, Brian= =0A>Sent: Friday, August 24, 2012 10:43 AM=0A>To: Benjamin A. Rolfe=0A>Cc: = paws@ietf.org=0A>Subject: Re: [paws] XML schema versus JSON, vCard & iCal = =0A>=C2=A0 =0A>Okay: =0A>=C2=A0 =0A>So, I implement a database, and I imp= lement XML =0A>You implement a device, and you implement JSON =0A>=C2=A0 = =0A>You query my database (let's not get into how you do that query withou= t deciding XML vs JSON) and discover I implement XML only =0A>=C2=A0 =0A>= What do you do? =0A>=C2=A0 =0A>Brian =0A>=C2=A0 =0A>On Aug 24, 2012, at= 1:38 PM, "Benjamin A. Rolfe" wrote: =0A>=0A>=0A> =0A= >=0A>=0A> =0A>There are two ways to achieve interoperability when you have = an option. =0A>There are many existence proofs of the third way that I ment= ioned below.=0A>802.11 + WiFi provide many options and a means for devices = to share information about what options each supports, without requiring th= at any device implement every option.=C2=A0 It works.=C2=A0 =0A>=0A>That sa= id, I think (A) is the best choice, (B) is not as nice for me, and (C) is m= ore work than either of the other two.=0A>=C2=A0=0A>=0A> =0A>=C2=A0 =0A>On= e is that one end implements both choices and the other end implements one = or both. =0A>=C2=A0 =0A>The other is that both ends implement one specifi= c choice ("MUST implement") and both can optionally implement the other cho= ice. =C2=A0Only if both ends implement the other choice would that be avail= able. =0A>=C2=A0 =0A>So, in this case we could do one of the following: = =0A>A) Databases implement both XML and JSON, devices implement either =0A= >B) Both Databases and devices implement one (say XML) and optionally imple= ment the other (say JSON) =0A>=C2=A0 =0A>You are advocating for A, Richar= d was suggesting B. =0A>=C2=A0 =0A>I don't care, but choice C) Both datab= ases and devices have a choice of what to implement doesn't work for me (or= Richard). =0A>=C2=A0 =0A>Brian =0A>=C2=A0 =0A>On Aug 24, 2012, at 12:5= 7 PM, Benjamin A. Rolfe wrote: =0A>=0A>=0A> =0A>Appar= ently I was unclear.=C2=A0 I certainly an capable of being wrong as I pract= ice often, but in this case it is quite unlikely :-). =0A>=0A>You do not ne= ed to choose only one form to achieve interoperability.=C2=A0=C2=A0 If you = have two, let the device implementer figure out which is best for their par= ticular device requirements and trade-offs.=C2=A0 This is *preferable* from= my perspective.=0A>=0A>If you provide more than one form in the database, = devices using the database need some means for figuring out which are avail= able. It can't use it if it doesn't no about it. This is an observations, n= ot an argument ;-).=C2=A0=C2=A0 =0A>=0A>It is my *opinion* at the=C2=A0 mom= ent that if you provide options, to make those useful you need to provide= =C2=A0 a protocol by which devices can discover what options the database s= upports.=C2=A0 If you have such a mechanism and all devices use it (a=C2=A0= bootstrap protocol),=0A everything else could be options.=C2=A0 This requi= res additional functions in both database and device implementations. =0A>I= f on the other hand the device can "just know" that the database has two fo= rms available, it won't need to dynamically figure it out. The device imple= menter has options and simplicity, so I like it. =0A>=0A>Since I am focused= on the TVWS devices that need access to the database, and not a database i= mplementer, shifting burden onto the database implementer (not me) to reduc= e the burden on the device implementer (me) is preferred from my perspectiv= e.=C2=A0 The database=0A implementer may have another perspective.=C2=A0 Sh= ould I point out that there will be a lot more devices than databases?=C2= =A0 That might sound like an argument, though, so I won't....:-j=0A>=0A>Ben= =0A>=0A>=0A> =0A>Brian is right .. sorry but the rest of you are wrong. J = =0A>=C2=A0 =0A>This is why you have MUST and SHOULD in RFC 2119. =C2=A0 = =0A>=C2=A0 =0A>This BTW is a classic argument in IETF terms .. but the arg= ument =E2=80=9Clet the market decide=E2=80=9D only holds so much validity.= =C2=A0 You actually have to choose SOMETHING to create a baseline of intero= perability. =0A>=C2=A0 =0A>A virtually identical argument =C2=A0is now pla= ying out in discussions of mandatory audio and codec implementations for WE= BRTC like things. =0A>=C2=A0 =0A>IMHO XML MUST anything else defined SHOUL= D, but MUST on XML and JSON could work as well. It just leads to a level of= complexity in implementations. =0A>=C2=A0 =0A>End of argument you now ca= n go back to your regularly schedule programming. J =0A>=C2=A0 =0A>=C2=A0 = =0A>From:paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of= Basavaraj.Patil@nokia.com=0A>Sent: Thursday, August 23, 2012 5:44 PM=0A>To= : Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com=0A>Cc: paws@ietf.org= =0A>Subject: Re: [paws] XML schema versus JSON, vCard & iCal =0A>=0A>=C2= =A0 =0A>I agree with Brian. =0A>There needs to be a default mandatory to= implement option in order to achieve interoperability.=C2=A0 =0A>And this= applies to the device and database side of the protocol. =0A>=C2=A0 =0A= >-Raj =0A>=C2=A0 =0A>From: "", "Brian.Rosen@neustar.biz" =0A>Date: Thursday, August 23, 2012 2:43 PM=0A>To: Don= Joslyn =0A>Cc: "paws@ietf.org" =0A>Subject: Re: [paws] XML schema versus JSON, vCard & iCal =0A>=C2=A0 = =0A>One of my favorite IETF expressions is "There are no protocol police".= =C2=A0We 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 oth= er implementations. =C2=A0On the other hand, the whole point of a protocol = document like ours is that two independent implementations who both follow = the document will interwork. =C2=A0If that wasn't true, why do you need a s= tandard? =0A>=C2=A0 =0A>If you say "either" to both ends, then you don't= get interoperability. =C2=A0 =0A>=C2=A0 =0A>By your argument, we should= stop working, and the product managers will figure it out using proprietar= y protocols. =C2=A0The market will decide. =0A>=C2=A0 =0A>So, I feel str= ongly that if one end is "either", the other end must be "both". =C2=A0It's= also acceptable to say both ends implement one choice and the other is opt= ional at both ends. =C2=A0Here, I think it's server does both and client do= es either.=C2=A0 =0A>=C2=A0 =0A>It's always possible to build an impleme= ntation of a server that only does one: there are no protocol police. =0A>= =C2=A0 =0A>Brian =0A>=C2=A0 =0A>=C2=A0 =0A>=C2=A0 = =0A>=C2=A0 =0A>On Aug 23, 2012, at 3:11 PM, Don Joslyn wrote: =0A>=0A>=0A>=0A> =0A>Hi Ben, =0A>That was my original s= uggestion, and I still think it makes the most sense. =0A>Thanks for suppo= rting the proposal. =0A>Don =0A>=C2=A0 =0A>From:=C2=A0paws-bounces@ietf.= org [mailto:paws-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Benjamin A. Rolfe= =0A>Sent:=C2=A0Thursday, August 23, 2012 3:05 PM=0A>To:=C2=A0paws@ietf.org= =0A>Subject:=C2=A0Re: [paws] XML schema versus JSON, vCard & iCal =0A>= =0A> =0A>Someone suggested that PAWS define both, and let the vendors decid= e which ones to implement.=0A>That makes the most sense for both DB and dev= ice vendors.=C2=A0 Markets will probably drive DB vendors to do both. Devic= e vendors will do what fits the market segment they're after. Why over-cons= train (or argue when natural selection will take care of it for us?).=0A>B= =0A>=0A>=0A>=0A> =0A>Sounds good to me. =0A>=C2=A0 =0A>From:=C2=A0paws-b= ounces@ietf.org=C2=A0[mailto:paws-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0= Gabor.Bajko@nokia.com=0A>Sent:=C2=A0Tuesday, August 21, 2012 12:42 AM=0A>To= :=C2=A0paws@ietf.org=0A>Subject:=C2=A0Re: [paws] XML schema versus JSON, vC= ard & iCal =0A>=0A> =0A>Now I can=E2=80=99t see anymore any willingness = to agree on one or the other encoding. =0A>To prevent endless discussions = on this topic I=E2=80=99d suggest we move forward with supporting both in t= he DB and either one in the master device. =0A>Any objections? =0A>=C2=A0= =0A>Gabor =0A>=C2=A0 =0A>=C2=A0 =0A>From:=C2=A0paws-bounces@ietf.org= =C2=A0[mailto:paws-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0ext Das, Subir= =0A>Sent:=C2=A0Monday, August 20, 2012 2:50 PM=0A>To:=C2=A0Don Joslyn; Vinc= ent Chen; Weixinpeng=0A>Cc:=C2=A0paws@ietf.org; Manikkoth Sajeev=0A>Subject= :=C2=A0Re: [paws] XML schema versus JSON, vCard & iCal =0A>=0A> =0A>We h= ave a half a dozen or more TVDB radio vendors that use/prefer JSON and we w= ill vote for JSON if we had to pick one. =0A>Also I will copy the followin= g two important points: =0A>=C2=A0 =0A>=09* Simple-to-use libraries exist= for all major languages/platforms=0A>=09* Don't need a tool chain to work = with the data, as is typically needed for XML =0A>=C2=A0 =0A>=C2=A0 =0A= >=C2=A0 =0A>From:=C2=A0paws-bounces@ietf.org=C2=A0[mailto:paws-bounces@iet= f.org]=C2=A0On Behalf Of=C2=A0Don Joslyn=0A>Sent:=C2=A0Monday, August 20, 2= 012 4:54 PM=0A>To:=C2=A0Vincent Chen; Weixinpeng=0A>Cc:=C2=A0paws@ietf.org;= Manikkoth Sajeev=0A>Subject:=C2=A0Re: [paws] XML schema versus JSON, vCard= & iCal =0A>=0A> =0A>Please see my comments below=E2=80=A6 =0A>Thanks, = =0A>Don =0A>=C2=A0 =0A>From:=C2=A0paws-bounces@ietf.org=C2=A0[mailto:paw= s-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Vincent Chen=0A>Sent:=C2=A0Monda= y, August 20, 2012 2:56 PM=0A>To:=C2=A0Weixinpeng=0A>Cc:=C2=A0paws@ietf.org= ; Manikkoth Sajeev=0A>Subject:=C2=A0Re: [paws] XML schema versus JSON, vCar= d & iCal =0A>=0A> =0A>=09* One of our goals is to strive to lower the cos= t and complexity for device manufacturers. This lowers the barrier for buil= ding a robust ecosystem. =0A>[DJ - The =E2=80=9Ccost=E2=80=9D and complexit= y of using XML has not been an issue for the half dozen TVBD vendors that h= ave already used XML. Maybe we need to better define =E2=80=9Ccost=E2=80=9D= ?] =0A>=09* 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. =0A>[DJ - I propo= sed that the databases support both XML and JSON, devices only need to supp= ort one to talk to the database. Our current database supports XML and JSON= , but if I=E2=80=99m forced to pick only one, then I will vote for XML beca= use it=E2=80=99s the one that we currently use on all embedded devices.] = =0A>=09* There's a trend for APIs on the web towards JSON (Twitter, FourSqu= are, Facebook, Google, etc.). One of the major reasons is that developers (= client-side) prefer it for its simplicity: =0A>=09* Representation closely= matches most data models (nested lists and maps)=0A>=09* Simple-to-use lib= raries exist for all major languages/platforms =0A>=09* Don't need a tool c= hain to work with the data, as is typically needed for XML. =0A>Apparently= , the efficiency gains of JSON also matter to the scalability of serving sy= stems. =0A>=C2=A0 =0A>[DJ =E2=80=93 I can=E2=80=99t argue against these li= sted pros for JSON, especially when you=E2=80=99re dealing with a lot of da= ta (like Twitter, FourSquare, Facebook and Google does). But I=E2=80=99m as= suming that PAWS messages will not be exchanged nearly as often as the appl= ications mentioned above. But again, I know JSON is more efficient, can=E2= =80=99t argue with that.] =0A>=09* At the end of the day, it's the data mo= del that matters, rather than the encoding. We (Google) are actually neutra= l on XML vs JSON, as long as we're clear on what device makers want. It wou= ld be good to get feedback from device makers (especially of embedded devic= es) regarding experiences supporting XML vs JSON. =0A>=C2=A0 =0A>Don, can y= ou elaborate on the types of devices that already support XML? =0A>=C2=A0 = =0A>[DJ - We currently support half a dozen TVDB radio vendors (embedded d= evices) using XML, non using JSON. XML has not been a burden, and the amoun= t of data that needs to be exchanged between device and database is not tha= t much or exchanged that often.] =0A>On Fri, Aug 17, 2012 at 6:06 PM, Weixi= npeng wrote: =0A>Considering of the design of data= base discovery protocol, the LoST protocol may be used and LoST is based on= XML, so I think XML may be preferred. =0A>=C2=A0 =0A>--Xinpeng Wei =0A>= =C2=A0 =0A>From:=C2=A0paws-bounces@ietf.org=C2=A0[mailto:paws-bounces@ietf= .org]=C2=A0On Behalf Of=C2=A0Rosen, Brian =0A>=0A>Sent:=C2=A0Friday, Augus= t 17, 2012 9:26 PM =0A>To:=C2=A0Manikkoth Sajeev;=C2=A0gabor.bajko@nokia.= com;=C2=A0vchen@google.com;=C2=A0peter@spectrumbridge.com =0A>=0A>Cc:=C2= =A0paws@ietf.org=0A>Subject:=C2=A0Re: [paws] XML schema versus JSON, vCard = & iCal =0A>=0A> =0A>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 c= hoice of json mean we then decide to roll our own versus using existing sta= ndards based on the idea there is no json representation of an existing sta= ndard. =C2=A0So, 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 js= on. =0A>=C2=A0 =0A>I would prefer to not have "both", because of intero= perability complications. =C2=A0If there is rough consensus for both, then = I would assert that all servers have to implement both and the client can i= mplement either. =0A>=C2=A0 =0A>There are json validators, so I don't t= hink that is a big deal. =C2=A0 =0A>=C2=A0 =0A>My experience in protoco= l design on the Internet is that decisions made solely or even largely beca= use of compactness advantages rarely are good choices. =C2=A0If you like js= on because it is smaller, then I believe you need a much better reason. =C2= =A0Binary doesn't work for me, at all. =C2=A0I have been involved in big bi= nary vs text wars in protocol design. =C2=A0Text wins, binary loses, in my = opinion. =0A>=C2=A0 =0A>Brian =0A>=C2=A0 =0A>From:= =C2=A0Manikkoth Sajeev =0A>Reply-To:=C2=A0Manikkoth Sajee= v =0A>Date:=C2=A0Thu, 16 Aug 2012 22:37:38 -0400=0A>To:= =C2=A0"Gabor.Bajko@nokia.com" , "Rosen, Brian" , "vchen@google.com" , "peter@spectru= mbridge.com" =0A>Cc:=C2=A0"paws@ietf.org" =0A>Subject:=C2=A0Re: [paws] XML schema versus JSON, vCard & iCal = =0A>=C2=A0 =0A>Hi, =0A>=C2=A0 =0A>Can it not be both JSON and XML su= pported? I would vote for that. Future implementations may prefer=C2=A0XML = as it is generic,=C2=A0omni present, easy to understand and validate.=C2=A0= For compactness may be a=C2=A0=C2=A0binary xml optioncan also work. JSON I = think will necessitate implementation to be native Java and may not be as f= riendly with other implementation languages. =0A>=C2=A0 =0A>Best Regard= s, =0A>Sajeev Manikkoth=0A>Mobile:=C2=A0+918792292002=0A>Email:=C2=A0mksa= ji@ieee.org=0A>http://www.linkedin.com/in/mksajeev =0A>=C2=A0 =0A>From:= =C2=A0"Gabor.Bajko@nokia.com" =0A>To:=C2=A0Brian.Ros= en@neustar.biz;=C2=A0vchen@google.com;=C2=A0peter@spectrumbridge.com=C2=A0= =0A>Cc:=C2=A0paws@ietf.org=C2=A0=0A>Sent:=C2=A0Friday, 17 August 2012, 4:55= =0A>Subject:=C2=A0Re: [paws] XML schema versus JSON, vCard & iCal =0A>=0A= >We have not heard any objections for using JSON encoding instead of XML.= =C2=A0=0A>Therefore, let's go for JSON, and close this thread.=0A>=0A>- Gab= or=0A>=0A>-----Original Message-----=0A>From:=C2=A0paws-bounces@ietf.org=C2= =A0[mailto:paws-bounces@ietf.org] On Behalf Of ext Rosen, Brian=0A>Sent: Mo= nday, August 13, 2012 3:14 PM=0A>To: 'Vincent Chen'; 'Peter Stanforth'=0A>C= c: 'paws@ietf.org'=0A>Subject: Re: [paws] XML schema versus JSON, vCard & i= Cal=0A>=0A>json is okay with me.=C2=A0=C2=A0=0A>I'd prefer an ISO time stam= p rather than a time in seconds since epoch.=C2=A0 It's very easy to parse,= and its simpler to use and debug.=C2=A0 Don't care a whole lot about that= =0A>=0A>Brian =0A>=0A>=0A>=0A>-----Original Message-----=0A>= From: =C2=A0=C2=A0=C2=A0 Vincent Chen [mailto:vchen@google.com]=0A>Sent:=C2= =A0=C2=A0=C2=A0 Monday, August 13, 2012 06:04 PM Eastern Standard Time=0A>T= o:=C2=A0=C2=A0=C2=A0 Peter Stanforth=0A>Cc:=C2=A0=C2=A0=C2=A0 Rosen, Brian;= Teco Boot; Benjamin A.Rolfe;=C2=A0paws@ietf.org=0A>Subject:=C2=A0=C2=A0=C2= =A0 Re: [paws] XML schema versus JSON, vCard & iCal=0A>=0A>XML vs JSON=0A>= =0A>Between XML and JSON, JSON messages are more compact and easier to proc= ess (parsing, synthesis). As clarification, JSON does not require JavaScrip= t or a Browser. It is a text-based representation of data that is language = independent, yet well-matched to all=0A major languages. JSON-handling libr= aries exist for numerous languages (see of=C2=A0http://json.org/) and seem = to be reasonably light weight.=0A>=0A>Timestamps=0A>=0A>As for timestamp sp= ecifications, should we consider just using seconds since the UNIX Epoch (1= 970-01-01T00:00:00Z)? This would eliminate the need for datetime-string par= sing on devices, assuming devices already have native libraries that provid= e time in this=0A format. Is that a valid assumption? Of course, this is le= ss human-readable....=0A>=0A>=0A>On Mon, Aug 13, 2012 at 6:49 AM, Peter Sta= nforth wrote:=0A>=0A>=0A>=C2=A0=C2=A0=C2=A0 When= ever we built mobile devices we never dealt with IETF, in our sensor=0A>=C2= =A0=C2=A0=C2=A0 days even an IP stack was a challenge,so I would defer to t= he device guys=0A>=C2=A0=C2=A0=C2=A0 on that one.=0A>=C2=A0=C2=A0=C2=A0=C2= =A0=0A>=C2=A0=C2=A0=C2=A0 On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Bria= n"=0A>=C2=A0=C2=A0=C2=A0=C2=A0=0A>=C2=A0=C2=A0=C2=A0 wrote:=0A>=C2=A0=C2=A0=C2=A0=C2=A0=0A>=C2=A0=C2=A0=C2=A0 >Our experienc= e in the IETF over many years is that economizing message=0A>=C2=A0=C2=A0= =C2=A0 >size and compromising utility and security in search of efficiency = of=0A>=C2=A0=C2=A0=C2=A0 >implementation on small devices is a poor trade o= ff.=C2=A0 I am not advocating=0A>=C2=A0=C2=A0=C2=A0 >being wasteful of reso= urces, but I don't think we should seriously=0A>=C2=A0=C2=A0=C2=A0 >conside= r the overhead of XML or json to be significant.=0A>=C2=A0=C2=A0=C2=A0 >=0A= >=C2=A0=C2=A0=C2=A0 >Assuming a json library can be loaded on a small devic= e is reasonable.=0A>=C2=A0=C2=A0=C2=A0 >=0A>=C2=A0=C2=A0=C2=A0 >Brian (as i= ndividual)=0A>=C2=A0=C2=A0=C2=A0 >=0A>=C2=A0=C2=A0=C2=A0 >=0A>=C2=A0=C2=A0= =C2=A0 >=0A>=C2=A0=C2=A0=C2=A0 > -----Original Message-----=0A>=C2=A0=C2=A0= =C2=A0 >From:=C2=A0 Peter Stanforth [mailto:peter@spectrumbridge.com]=0A>= =C2=A0=C2=A0=C2=A0 >Sent:=C2=A0 Saturday, August 11, 2012 07:13 AM Eastern = Standard Time=0A>=C2=A0=C2=A0=C2=A0 >To:=C2=A0 =C2=A0 Teco Boot; Benjamin A= .Rolfe=0A>=C2=A0=C2=A0=C2=A0 >Cc:=C2=A0 =C2=A0=C2=A0paws@ietf.org=0A>=C2=A0= =C2=A0=C2=A0 >Subject:=C2=A0 =C2=A0 =C2=A0 Re: [paws] XML schema versus JSO= N, vCard & iCal=0A>=C2=A0=C2=A0=C2=A0 >=0A>=C2=A0=C2=A0=C2=A0 >Not all mast= ers run over the core network.=0A>=C2=A0=C2=A0=C2=A0 >Some of the Use cases= have a master talking to another OTA=0A>=C2=A0=C2=A0=C2=A0 >We should not = assume that all Masters are attached to utility power so we=0A>=C2=A0=C2=A0= =C2=A0 >should be sympathetic to processing energy use also.=0A>=C2=A0=C2= =A0=C2=A0 >=0A>=C2=A0=C2=A0=C2=A0 >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Te= co Boot" wrote:=0A>=C2=A0=C2=A0=C2=A0 >=0A>=C2=A0=C2=A0= =C2=A0 >>=0A>=C2=A0=C2=A0=C2=A0 >>Op 10 aug. 2012, om 18:10 heeft Benjamin = A. Rolfe het volgende=0A>=C2=A0=C2=A0=C2=A0 >>geschreven:=0A>=C2=A0=C2=A0= =C2=A0 >>=0A>=C2=A0=C2=A0=C2=A0 >>> Compactness of messages is important, b= ut it is also important (to me=0A>=C2=A0=C2=A0=C2=A0 >>>at least) to be rea= lizable in an implementation with limited resources,=0A>=C2=A0=C2=A0=C2=A0 = >>>such as embedded devices in what are now popularly called "M2M"=0A>=C2= =A0=C2=A0=C2=A0 >>>applications.=C2=A0 A lot of these devices could use IP = all the end to end,=0A>=C2=A0=C2=A0=C2=A0 >>>but may have a very compact, s= imple stack and applications (i.e.=C2=A0 no=0A>=C2=A0=C2=A0=C2=A0 >>>browse= r).=C2=A0 Is JSON typically implemented when there is no browser?=0A>=C2=A0= =C2=A0=C2=A0 >>>Would it be hard to do in a resource constrained device (i.= e. where we=0A>=C2=A0=C2=A0=C2=A0 >>>talk about memory size in Kilo-bytes s= till).=0A>=C2=A0=C2=A0=C2=A0 >>=0A>=C2=A0=C2=A0=C2=A0 >>In use cases and re= quirements document, there are no requirements for=0A>=C2=A0=C2=A0=C2=A0 >>= protocol performance. I guess OS/IP/TCP/TLS code size supersedes needs=0A>= =C2=A0=C2=A0=C2=A0 >>for JSON or XML.=0A>=C2=A0=C2=A0=C2=A0 >>=0A>=C2=A0=C2= =A0=C2=A0 >>Same for timing: TCP/TLS connection setup will take more than t= he PAWS=0A>=C2=A0=C2=A0=C2=A0 >>message exchange, I think. This may be of i= mportance when using satcom=0A>=C2=A0=C2=A0=C2=A0 >>links.=0A>=C2=A0=C2=A0= =C2=A0 >>=0A>=C2=A0=C2=A0=C2=A0 >>Because PAWS runs between master and data= base, over core network,=0A>=C2=A0=C2=A0=C2=A0 >>performance is not our pri= mary concern. But as always, it is good to keep=0A>=C2=A0=C2=A0=C2=A0 >>an = eye on efficiency.=0A>=C2=A0=C2=A0=C2=A0 >>=0A>=C2=A0=C2=A0=C2=A0 >>Teco=0A= >=C2=A0=C2=A0=C2=A0 >>=0A>=C2=A0=C2=A0=C2=A0 >>> Thanks=0A>=C2=A0=C2=A0=C2= =A0 >>> Ben=0A>=C2=A0=C2=A0=C2=A0 >>>=0A>=C2=A0=C2=A0=C2=A0 >>>=0A>=C2=A0= =C2=A0=C2=A0 >>>> We had a discussion on XML vs. JSON. I prefer the one wit= h most=0A>=C2=A0=C2=A0=C2=A0 >>>>compact messages.=0A>=C2=A0=C2=A0=C2=A0 >>= >>=0A>=C2=A0=C2=A0=C2=A0 >>>> On vCard and JSON: what is the status of "A J= avaScript Object Notation=0A>=C2=A0=C2=A0=C2=A0 >>>>(JSON) Representation f= or vCard"?=0A>=C2=A0=C2=A0=C2=A0 >>>>=C2=A0http://tools.ietf.org/html/draft= -bhat-vcarddav-json-00=0A>=C2=A0=C2=A0=C2=A0 >>>>=0A>=C2=A0=C2=A0=C2=A0 >>>= > On valid times: can we use same format as certificates? They have=0A>=C2= =A0=C2=A0=C2=A0 >>>>similar simple requirements: valid notBefore&=C2=A0 not= After.=0A>=C2=A0=C2=A0=C2=A0 >>>>=C2=A0http://tools.ietf.org/html/rfc3280#s= ection-4.1.2.5=0A>=C2=A0=C2=A0=C2=A0 >>>>=0A>=C2=A0=C2=A0=C2=A0 >>>> Teco= =0A>=C2=A0=C2=A0=C2=A0 >>>> _______________________________________________= =0A>=C2=A0=C2=A0=C2=A0 >>>> paws mailing list=0A>=C2=A0=C2=A0=C2=A0 >>>>=C2= =A0paws@ietf.org=0A>=C2=A0=C2=A0=C2=A0 >>>>=C2=A0https://www.ietf.org/mailm= an/listinfo/paws=0A>=C2=A0=C2=A0=C2=A0 >>>>=0A>=C2=A0=C2=A0=C2=A0 >>>=0A>= =C2=A0=C2=A0=C2=A0 >>> _______________________________________________=0A>= =C2=A0=C2=A0=C2=A0 >>> paws mailing list=0A>=C2=A0=C2=A0=C2=A0 >>>=C2=A0paw= s@ietf.org=0A>=C2=A0=C2=A0=C2=A0 >>>=C2=A0https://www.ietf.org/mailman/list= info/paws=0A>=C2=A0=C2=A0=C2=A0 >>=0A>=C2=A0=C2=A0=C2=A0 >>________________= _______________________________=0A>=C2=A0=C2=A0=C2=A0 >>paws mailing list= =0A>=C2=A0=C2=A0=C2=A0 >>paws@ietf.org=0A>=C2=A0=C2=A0=C2=A0 >>https://www.= ietf.org/mailman/listinfo/paws=0A>=C2=A0=C2=A0=C2=A0 >=0A>=C2=A0=C2=A0=C2= =A0 >_______________________________________________=0A>=C2=A0=C2=A0=C2=A0 = >paws mailing list=0A>=C2=A0=C2=A0=C2=A0 >paws@ietf.org=0A>=C2=A0=C2=A0=C2= =A0 >https://www.ietf.org/mailman/listinfo/paws=0A>=C2=A0=C2=A0=C2=A0=C2=A0= =0A>=C2=A0=C2=A0=C2=A0 _______________________________________________=0A>= =C2=A0=C2=A0=C2=A0 paws mailing list=0A>=C2=A0=C2=A0=C2=A0=C2=A0paws@ietf.o= rg=0A>=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/mailman/listinfo/paws=0A= >=C2=A0=C2=A0=C2=A0=C2=A0=0A>=0A>=0A>=0A>=0A>--=C2=A0=0A>-vince=0A>=0A>____= ___________________________________________=0A>paws mailing list=0A>paws@ie= tf.org=0A>https://www.ietf.org/mailman/listinfo/paws=0A>___________________= ____________________________=0A>paws mailing list=0A>paws@ietf.org=0A>https= ://www.ietf.org/mailman/listinfo/paws =0A>=0A>=0A> =0A>=0A> =0A>--= =C2=A0=0A>-vince =0A>=C2=A0 =0A>=C2=A0 =0A>______________________________= _________________ =0A>paws mailing list =0A>paws@ietf.org =0A>https://www.i= etf.org/mailman/listinfo/paws =0A>=0A> =0A>________________________________= _______________=0A>paws mailing list=0A>paws@ietf.org=0A>https://www.ietf.o= rg/mailman/listinfo/paws =0A>=C2=A0 =0A>=C2=A0 =0A>_________________= ______________________________ =0A>paws mailing list =0A>paws@ietf.org =0A>= https://www.ietf.org/mailman/listinfo/paws =0A>=C2=A0 =0A>________________= _______________________________=0A>paws mailing list=0A>paws@ietf.org=0A>ht= tps://www.ietf.org/mailman/listinfo/paws =0A>=C2=A0 =0A>=C2=A0 =0A>=C2= =A0 =0A>_______________________________________________=0A>paws mailing = list=0A>paws@ietf.org=0A>https://www.ietf.org/mailman/listinfo/paws=0A>=0A>= =0A> =0A>_______________________________________________=0A>paws mailing l= ist=0A>paws@ietf.org=0A>https://www.ietf.org/mailman/listinfo/paws=0A>=0A>= =0A=0A=0A-- =0A-vince=0A =0A_______________________________________________= =0Apaws mailing list=0Apaws@ietf.org=0Ahttps://www.ietf.org/mailman/listinf= o/paws ---874068440-262716099-1345874051=:20626 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Hi,=
     
    XML being generic and = widely used in all languages the required libraries and the code = is most of the time already there in the device is the advantage.
     
    Best Regards,
     
    Sajeev Manikkoth


    From: Vincent Chen <vchen@google.com>
    To: Manikkoth Sajeev <mksaji@yahoo.com>
    Cc: "paws@ietf.org" <paws@ietf= .org>
    Sent: Saturd= ay, 25 August 2012, 9:06
    Subject:= Re: [paws] XML schema versus JSON, vCard & iCal
    =

    Sajeev,

    It's been a while since I'= ve worked with embedded devices. I'm surprised that the same concern does n= ot apply to XML. Do you not need libraries to work with XML?

    =
    =0A
    On Fri, Aug 24, 2= 012 at 8:13 PM, Manikkoth Sajeev <mksaji@yahoo.com> wrote:
    =0A
    Hi,
    =0A = ;
    = I would still support XML. JSON libraries are available for all languages. = But interfacing and linking such libraries are problematic on embedded devi= ces most of the time. And if an implementation vouch for multiple such non = native language libraries then developers life is hell...
    =0A
     
    Best Regards,=
     
    Sajeev Manikkoth

    =0A
    =0A
    From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
    =0A To: Bri= an.Rosen@neustar.biz; ben@blindcree= k.com
    Cc: paws@ietf.org
    =0A Sent: Saturday, 25 August 2012, 0:38

    Subject:<= /b> Re: [paws] XML schema versus JSON, vCard & iCal
    =0A
    =

    =0A=0A =0A =0A= =0A=0A
    =0A
    =0A
    WiFi world builds on mandating the implementation (and certificat= ion) of a base spec, and a set of optional features. If an optional feature= is not supported=0A by one of the peers, they can still talk, but not use = that feature. That is basically option B) from Brain=E2=80=99s list.=
    =0A
    &= nbsp;
    =0A
    I=E2=80=99d like to suggest that we recognize that option A) and = B) are valid options, while option C) is invalid, and we should stop debati= ng it.
    =0A
    I=E2=80=99d 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 enco= ding ;)
    =0A
     
    =0A
    Option A) seems to be like a good compromise, and w= ould cut discussions short, with the only caveat that if there is no strong= technical argument for supporting=0A and specifying two different encoding= s, then the iesg may send the document back to the wg to pick one of the tw= o specified. As Robert mentioned in his email, this has happened in the pas= t, so it is likely it would happen again. And frankly, I do not see a=0A st= rong argument in favor of two different encodings.
    =0A
      =0A
    Is ther= e anyone who has a technical argument against supporting only one encoding,= being that either xml or json?
    =0A
     
    =0A
    Most people speak in favor = of JSON, because it is compact and more efficient. I went through this thre= ad and I saw 2 objections against picking JSON. One said=0A that JSON requi= res native Java, which is wrong, the other objection gave no real reason. S= o I am wondering if there is really any valid technical reason against usin= g JSON only?
    =0A
     
    =0A
    -     &nb= sp;   =0AGabor
    =0A
     
    =0A
     
    =0A<= div>=0A
    =0A
    From:<= /b> paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]=0AOn Behalf Of ext Rosen, Brian
    = =0ASent: Friday, August 24, 2012 10:43 AM
    =0ATo: Benjamin = A. Rolfe
    =0ACc: paws@ietf.org
    = =0ASubject: Re: [paws] XML schema versus JSON, vCard & iCal
    =0A
    =0A
    =0A
     
    =0A
    Okay:
    =0A=0A
     
    =0A
    =0A
    =0A
    So, I implement a database= , and I implement XML
    =0A
    =0A
    =0A
    You implement a device= , and you implement JSON
    =0A
    =0A
    =0A
     
    =0A=0A
    =0A
    You query my database (let's not get into how you do th= at query without deciding XML vs JSON) and discover I implement XML only =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    What do= you do?
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A<= div>Brian
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A=
    =0A
    =0A
    On Aug 24, 2012, at 1:38 PM, "Benjamin A. Rolfe" <<= a href=3D"mailto:ben@blindcreek.com" rel=3D"nofollow" target=3D"_blank" yma= ilto=3D"mailto:ben@blindcreek.com">ben@blindcreek.com> wrote:
    = =0A
    =0A

    =0A
    =0A
    =0A
    =0A

    =0A
    =0A
    = =0A
    There are two ways to achieve interoperability when you have an opt= ion.
    =0A
    There are many existence proofs of the third way that I = mentioned below.
    =0A802.11 + WiFi provide many options and a means for d= evices to share information about what options each supports, without requi= ring that any device implement every option.  It works. =0A
    = =0A
    =0AThat 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.
    =0A 
    =0A=
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    One is= that one end implements both choices and the other end implements one or b= oth.
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    = The other is that both ends implement one specific choice ("MUST implement"= ) and both can optionally implement the other choice.  Only if both en= ds implement the other choice would that be available.
    =0A =0A
    = =0A
    =0A
     
    =0A
    =0A
    =0A
    So, in this case we = could do one of the following:
    =0A
    =0A
    =0A
    A) Databases = implement both XML and JSON, devices implement either
    =0A
    =0A=0A
    B) Both Databases and devices implement one (say XML) and optiona= lly implement the other (say JSON)
    =0A
    =0A
    =0A
      =0A
    =0A
    =0A
    You are advocating for A, Richard was suggest= ing B.
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0AI don't care, but choice C) Both databases and devices have a choice of w= hat to implement doesn't work for me (or Richard).
    =0A
    =0A
    = =0A
     
    =0A
    =0A
    =0A
    Brian
    =0A
    =0A=0A
     
    =0A
    =0A
    =0A
    =0A
    =0A
    On Aug 24, = 2012, at 12:57 PM, Benjamin A. Rolfe <ben@blindcreek.com> wrote:
    =0A
    =0A

    =0A
    =0A =0A
    =0A
    Apparently I was unclear.  I certainly an capable= of being wrong as I practice often, but in this case it is quite unlikely = :-).=0A
    =0A
    =0AYou do not need to choose only one form to achieve int= eroperability.   If you have two, let the device implementer figu= re out which is best for their particular device requirements and trade-off= s.  This is *preferable* from my perspective.
    =0A=0A
    =0AIf you p= rovide 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 does= n't no about it. This is an observations, not an argument ;-).  = =0A
    =0A
    =0AIt is my *opinion* at the  moment that if you provide= options, to make those useful you need to provide  a protocol by whic= h devices can discover what options the database supports.  If you hav= e such a mechanism and all devices use it (a  bootstrap protocol),=0A = everything else could be options.  This requires additional functions = in both database and device implementations.=0A
    =0AIf on the other hand = the device can "just know" that the database has two forms available, it wo= n't need to dynamically figure it out. The device implementer has options a= nd simplicity, so I like it.=0A
    =0A
    =0ASince 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=0A 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
    =0A
    =0ABen
    =0A<= br>=0A
    =0A
    =0A
    Brian is right .. sorry but the rest of you are wrong.=0A= J= =0A
    =0A
    =0A
     
    =0A
    =0A
    This is why you have MUST and SHOULD in= RFC 2119.  
    =0A
    =0A
     
    =0A
    =0A
    This BTW is a classic arg= ument in IETF terms .. but the argument =E2=80=9Clet the market decide=E2= =80=9D only holds so much validity.  You actually have to choose SOMET= HING=0A to create a baseline of interoperability.
    =0A
    =0A<= div> =
    =0A
    =0A
    A virtually identical argument  is now playing out in discussio= ns of mandatory audio and codec implementations for WEBRTC like things.
    =0A
    =0A
     
    =0A
    =0A
    IMHO XML MUST anything else defined SHOULD, bu= t MUST on XML and JSON could work as well. It just leads to a level of comp= lexity in implementations.=0A
    =0A
    =0A
     
    =0A
    =0A<= div>End of argume= nt you now can go back to your regularly schedule programming.=0AJ=0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
     
    =0A
    =0A=0A
    =0A
    From:=0Apaws-= bounces@ietf.org [mailto:paws= -bounces@ietf.org]=0AOn Behalf Of Basavaraj.Patil@nokia.com
    =0ASent: Thursd= ay, August 23, 2012 5:44 PM
    =0ATo: Brian.Rosen@neustar.biz; =0Ad.joslyn@spectrumbridge.com
    =0ACc:= paws@ietf.org
    =0ASubject: Re: [paw= s] XML schema versus JSON, vCard & iCal
    =0A
    =0A
    = =0A
     
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    I agree with Brian.
    =0A
    =0A
    =0A
    = There needs to be a default mandatory to = implement option in order to achieve interoperability. 
    = =0A
    =0A
    =0A
    And this applies= to the device and database side of the protocol.
    =0A
    =0A=
    =0A
    =0A
     
    = =0A
    =0A
    =0A
    =0A
    -Raj
    =0A
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    From:=0A"<ex= t Rosen>", "Brian.Rosen@ne= ustar.biz" <Brian.Rose= n@neustar.biz>
    =0A=0ADate: Thursday, August 23, 2012 2:43 = PM
    =0ATo: Don Joslyn <d.joslyn@spectrumbridge.com>
    =0ACc: "paws@ietf.org" <paws@ie= tf.org>
    =0ASubject: Re: [paws] XML schema versus JSON, vCa= rd & iCal
    =0A
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    = =0A
    One of my favorite IETF expressio= ns 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,=0A y= ou may not get interoperability with other implementations.  On the ot= her hand, the whole point of a protocol document like ours is that two inde= pendent implementations who both follow the document will interwork.  = If that wasn't true, why do you need a standard?=0A
    =0A
    = =0A
    =0A
     
    =0A=0A
    =0A
    =0A
    If you say "= either" to both ends, then you don't get interoperability.   =0A
    =0A
    =0A
    =0A
    &nbs= p;
    =0A
    =0A
    =0A
    =0A
    By your argument, we should stop working, and the product managers= will figure it out using proprietary protocols.  The market will deci= de.
    =0A
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    So, I feel strongly that if one end is "either", the= other end must be "both".  It's also acceptable to say both ends impl= ement one choice and the other is optional at both=0A ends.  Here, I t= hink it's server does both and client does either. 
    =0A=0A
    =0A
    =0A
     =
    =0A
    =0A
    =0A
    =0A
    = It's always possible to build an implementation of a server that only does = one: there are no protocol police.
    =0A
    =0A
    =0A
    = =0A
     
    =0A
    =0A<= /div>=0A
    =0A
    Brian <as individ= ual>
    =0A
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    =0A
    =  
    =0A
    =0A
    =0A=
    =0A
    =0A
     
    = =0A
    =0A
    =0A
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    On Aug 23, 2012, at 3:11 PM, Don Joslyn <d.joslyn@spectrumbridge.com<= /a>> wrote:
    =0A
    =0A

    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    Hi Ben,
    =0A=0A
    =0A
    That was my original suggestion, and I still think it makes the most sense= .
    =0A
    =0A
    =0A
    Thanks for supporting the proposal.
    =0A=
    =0A
    =0A
    Don
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    = =0A
    =0A
    From:<= span style=3D"font-size: 10pt;"> paws-bounces@ietf.org<= /a>=0A [mailto:paws-bounces= @ietf.org] On Behalf Of Benj= amin A. Rolfe
    =0A=0ASent: Thursday, August 23, = 2012 3:05 PM
    =0ATo: p= aws@ietf.org
    =0ASubject: Re: [paws] XML sch= ema versus JSON, vCard & iCal
    =0A
    =0A
    =0A
    = =0A
    =0A
     
    =0A
    =0A
    =0A
    Someone suggested tha= t PAWS define both, and let the vendors decide which ones to implement.
    = =0AThat 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 natura= l selection will take care of it for us?).
    =0A=0AB
    =0A
    =0A
    =0A<= br>=0A
    =0A
    =0A
    =0A
    Soun= ds good to me.
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A
    =0A
    From: paws-bounces@= ietf.org [mailto:paws-bounces@ietf.org] On=0A Behalf Of Gabor.Bajko@nok= ia.com
    =0ASent: Tuesday, August 21, = 2012 12:42 AM
    =0ATo: = paws@ietf.org
    =0ASubject: Re: [paws] XML schema versus JSON, vCard & iCal
    =0A
    =0A
    =0A
    =0A
    =0A
     
    =0A=0A
    =0A
    Now I can=E2=80=99t see a= nymore any willingness to agree on one or the other encoding.
    = =0A
    =0A
    =0A
    To prevent endles= s discussions on this topic I=E2=80=99d suggest we move forward with suppor= ting both in the DB and either one in the master device.
    =0A=0A
    =0A
    Any objections?=
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    Gabor
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
     
    =0A
    =0A
    =0A
    =0A<= div>=0A
    From: paws-bounces@ietf.org [mailto:paws-bounces@i= etf.org] On=0A Behalf Of = ext Das, Subir
    =0ASent: Monday, August 20, = 2012 2:50 PM
    =0ATo: Don Joslyn; Vincent Chen; W= eixinpeng
    =0ACc: paws@ietf.org    ; Manikkoth Sajeev
    = =0ASubject: Re: [paws] XML schema versus JSON, vCa= rd & iCal
    =0A
    =0A
    =0A
    =0A
    =0A
     = ;
    =0A
    =0A
    =0A
    We have a= half a dozen or more TVDB radio vendors that use/prefer JSON and we will v= ote for JSON if we had to pick one.
    =0A
    =0A
    =0A
    <= span style=3D"font-size: 10pt;">Also I will copy the following two importan= t points:
    =0A
    =0A
    =0A
     
    =0A
    =0A
      =0A
        =0A
      • Simple-to-use l= ibraries exist for all major languages/platforms
      • Don't need a tool = chain to work with the data, as is typically needed for XML
        • =0A<= /ul> =0A
      =0A
      =0A
       =
      =0A
      =0A
      =0A
       
      =0A
      =0A
      =0A
       <= /span>
      =0A
      =0A
      =0A
      =0A
      =0A
      From: <= /span>paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]=  On=0A Behalf Of Don Joslyn<= br>=0ASent: Monday, August 20, 2012 4:54 PM
      =0A= To: Vincent Chen; Weixinpeng
      =0ACc:       paws= @ietf.org; Manikkoth Sajeev
      =0ASubject: Re: [paws] XML schema versus JSON, vCard & iCal
      =0A=0A
      =0A
      =0A
      =0A
       
      =0A
      =0A
      =0A
      = Please see my comments below=E2=80=A6
      =0A
      =0A
      =0A
      Thanks,<= /span>
      =0A
      =0A
      =0A
      Don<= /span>
      =0A
      =0A
      =0A
      &nbs= p;
      =0A
      =0A
      =0A
      =0A
      From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=0A Behalf Of Vincent Chen
      =0ASent: Monday, August 20, 2012 2:56 PM
      =0ATo: <= /span>Weixinpeng
      =0ACc: paws@ietf.org; Manikkoth Sajee= v
      =0ASubject: Re: [paws] XML schema versus JSON= , vCard & iCal
      =0A
      =0A
      =0A
      =0A
        =0A
      =0A
        =0A
      • One of ou= r goals is to strive to lower the cost and complexity for device manufactur= ers. This lowers the barrier for=0A building a robust ecosystem.
      =0A
      =0A
      [DJ - The = =E2=80=9Ccost=E2=80=9D and complexity of using XML has not been an issue fo= r the half dozen TVBD vendors that have already used XML. Maybe we need to = better define =E2=80=9Ccost=E2=80=9D?]
      =0A
      =0A
        =0A
      • To reduce complexity and cost for de= vice makers, supporting 1 encoding is better than both, as Brian points out= . WiFi=0A access points that "just work" anywhere in the world serves as a = good model.
      =0A
      =0A
      [DJ - I proposed that the databases support both XML and JSON, d= evices only need to support one to talk to the database. Our current databa= se supports XML and JSON, but if I=E2=80=99m forced to pick only one, then = I=0A will vote for XML because it=E2=80=99s the one that we currently use o= n all embedded devices.]
      =0A
      =0A
        =0A
      • There's a trend for APIs on the web towards JSON (T= witter, FourSquare, Facebook, Google, etc.). One of the major reasons=0A is= that developers (client-side) prefer it for its simplicity:
        • =0A
          =0A
            =0A
          • Representation closely matches most data mode= ls (nested lists and maps)
          • Simple-to-use libraries exist for all= major languages/platforms
            • =0A
          • Don't need a tool chain to work wi= th the data, as is typically needed for XML.
          =0A
        =0A=0A= Apparently, the efficiency gains of JSON= also matter to the scalability of serving systems.
      =0A
      = =0A
       <= /span>
      =0A
      =0A
      =0A
      [DJ =E2=80=93 I can=E2=80=99t argue against these listed pros for JSON,= especially when you=E2=80=99re dealing with a lot of data (like Twitter, F= ourSquare, Facebook and Google does). But I=E2=80=99m assuming that PAWS me= ssages will not be=0A exchanged nearly as often as the applications mention= ed above. But again, I know JSON is more efficient, can=E2=80=99t argue wit= h that.]
      =0A
      =0A
        =0A
      • At the end of the day, it's the data model that matters, rather than= the encoding. We (Google) are actually neutral=0A 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.
      =0A
      =0A 
      =0A
      =0ADon, can = you elaborate on the types of devices that already support XML? =0A
      =0A
      =0A
       <= /div> =0A
      =0A
      =0A
      =0A
      [DJ - We currently support half a doze= n 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=0A bet= ween device and database is not that much or exchanged that often.]<= /div> =0A
      =0A
      =0A
      On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng &= lt;weixinpeng@huawei.com> wrote:
      =0A
      =0A
      =0A=0A
      Consid= ering of the design of database discovery protocol, the LoST protocol may b= e used and LoST is based on XML, so I think XML may be preferred. =0A
      =0A
      =0A
       
      =0A
      =0A
      =0A
      --Xinpeng Wei
      =0A<= /div>=0A
      =0A
       
      =0A
      =0A
      =0A
      =0A
      =0A
      From: paws-bounces@ietf.= org [mailto:paws-bounces@ietf.org] On=0A Behalf Of Rosen, Brian
      =0A
      =0A
      =0A
      =0A

      =0ASent: Friday, August 17, 2012 9:26 PM
      =0A
      =0A
      =0A=0A =0A
      =0A
      =0A=0A

      =0ACc: paws@ietf.org
      =0ASubject:<= span> Re: [paws] XML schema versus JSON, vCard & iCal
      = =0A
      =0A
      =0A
      =0A
      =0A
      =0A
      =0A
       
      = =0A
      =0A
      =0A
      =0A
      I don't= really care whether we use json or xml as a matter of protocol design or i= mplementation, but I am a big fan of reusing standards rather than defining= new ones, and=0A I would not want to see the choice of json mean we then d= ecide to roll our own versus using existing standards based on the idea the= re is no json representation of an existing standard.  So, if choosing= json means folks feel free to ignore existing xml based=0A standards such = as xCard and LoST, then I would not want to use json.
      =0A=0A
      =0A
      =0A
      =0A
       =
      =0A
      =0A
      =0A
      =0A
      =0A
      I would prefer to not have "both", because of interoperabil= ity complications.  If there is rough consensus for both, then I would= assert that all servers have to implement=0A both and the client can imple= ment either.
      =0A
      =0A
      =0A
      =0A
      =0A
       
      =0A
      =0A
      =0A
      = =0A
      =0A
      There are json validator= s, so I don't think that is a big deal.  
      =0A
      =0A=0A
      =0A
      =0A
       =
      =0A
      =0A
      =0A
      =0A
      =0A
      My experience in protocol design on the Internet is that decisions= made solely or even largely because of compactness advantages rarely are g= ood choices.  If you like json=0A because it is smaller, then I believ= e 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. &= nbsp;Text wins, binary loses, in my opinion.
      =0A =0A
      =0A=0A
      =0A
      =0A
       
      =0A
      =0A
      =0A
      =0A
      =0A
      Brian <as individual>
      =0A
      =0A
      =0A=0A
      =0A
       
      = =0A
      =0A
      =0A
      =0A
      =0A
      From: Manikk= oth Sajeev <mksaji@yahoo.com>
      =0A=0AReply-To: Manikkoth Sajeev <mksaji@yahoo.com>
      =0ADate: Thu, 16 Aug 2012 22:37:38 -0400
      =0ATo: = "G= abor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>,=0A= "Rosen, Brian" <brian.rosen@neustar.biz>, "vchen@google.com<= /a>" <vch= en@google.com>,=0A "peter@spectrumbridge.com" = <peter@spectrumbridge.com>
      =0A=0ACc: = "paws@i= etf.org" <paws@ietf.org>
      =0A=0ASubject: <= /b>Re: [paws] XML schema versus JSON, vCard & iCal
      =0A=0A
      =0A
      =0A
      =0A
       = ;
      =0A
      =0A
      =0A
      =0A
      =0A
      =0A
      =0AHi,
      =0A
      =0A
      =0A
      =0A
      =0A
      =0A 
      =0A
      =0A
      =0A
      =0A=0A
      =0ACan it not be both JSON and XML = supported? I would vote for that. Future implementations may prefer&n= bsp;XML as it is generic, omni present, easy to understand a= nd validate. For=0A compactness may be a &= nbsp;binary xml optioncan also work. JSON I think will necess= itate implementation to be native Java and may not be as friendly with othe= r implementation languages.
      =0A
      =0A
      =0A
      =0A
      =0A=0A 
      =0A
      =0A
      =0A
      =0A=
      =0A
      =0ABest Regards,
      =0A=
      =0A
      =0A
      =0A
      =0ASajeev Manikkoth
      =0AMobile: +918792292002
      = =0AEmail: mksaji@ieee.org
      =0Ahttp://www.linkedin.com/in/mksajeev
      =0A=0A
      =0A
      =0A
      =0A 
      =0A<= /div>=0A
      =0A
      =0A=0A
      =0A
      =0AWe have not heard an= y objections for using JSON encoding instead of XML. 
      = =0ATherefore, let's go for JSON, and close this thread.
      =0A
      =0A- Gabo= r
      =0A
      =0A-----Original Message-----
      =0AFrom:       paws-= bounces@ietf.org [mailto:paws-bounces@ietf.org]=0A On Behalf Of ext Rosen, Brian
      =0ASent: Monday, August 13, = 2012 3:14 PM
      =0ATo: 'Vincent Chen'; 'Peter Stanforth'
      =0ACc: 'paws@ietf.org'=
      =0ASubject: Re: [paws] XML schema versus JSON, vCard & iCal
      =0A<= br>=0Ajson is okay with me.  
      =0AI'd prefer an IS= O time stamp rather than a time in seconds since epoch.  It's very eas= y to parse, and its simpler to use and debug.  Don't care a whole lot = about that
      =0A
      =0ABrian <as individual>
      =0A
      =0A
      =0A=0A-----Original Message-----
      =0AFrom:     Vincent Chen = [mailto:vche= n@google.com]
      =0ASent:    Monday, August 13, 2= 012 06:04 PM Eastern Standard Time
      =0ATo:    Peter Stanfo= rth
      =0ACc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe;<= span> paws@ietf.org
      =0ASubject:    Re: [paws] XML s= chema versus JSON, vCard & iCal
      =0A
      =0AXML vs JSON
      =0A
      =0AB= etween 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 indep= endent, yet well-matched to all=0A major languages. JSON-handling libraries= exist for numerous languages (see of http://json.org/) and seem to be reasonably light weight.
      = =0A=0A
      =0ATimestamps
      =0A
      =0AAs for timestamp specifications, shoul= d 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, as= suming devices already have native libraries that provide time in this=0A f= ormat. Is that a valid assumption? Of course, this is less human-readable..= ..
      =0A
      =0A
      =0AOn Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth <= ;peter@spectrumbridge.com> wrote:
      =0A
      =0A
      =0A&nb= sp;   Whenever we built mobile devices we never dealt with IETF, = in our sensor
      =0A    days even an IP stack was a challeng= e,so I would defer to the device guys
      =0A    on that one.=
      =0A    
      =0A    On Mo= nAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"
      =0A    
      =0A    <Brian.Rosen@neustar.biz      > wrote:
      =0A    
      =0A &= nbsp;  >Our experience in the IETF over many years is that economiz= ing message
      =0A    >size and compromising utility and = security in search of efficiency of
      =0A    >implementa= tion on small devices is a poor trade off.  I am not advocating
      =0A=     >being wasteful of resources, but I don't think we sh= ould seriously
      =0A    >consider the overhead of XML or= json to be significant.
      =0A    >
      =0A  &n= bsp; >Assuming a json library can be loaded on a small device is reasona= ble.
      =0A    >
      =0A    >Brian (as i= ndividual)
      =0A    >
      =0A    >
      = =0A    >
      =0A    > -----Original Mess= age-----
      =0A    >From:  Peter Stanforth [mailto:<= a href=3D"mailto:peter@spectrumbridge.com" rel=3D"nofollow" target=3D"_blan= k" ymailto=3D"mailto:peter@spectrumbridge.com">peter@spectrumbridge.com]
      =0A    >Sent:&= nbsp; Saturday, August 11, 2012 07:13 AM Eastern Standard Time
      =0A =    >To:    Teco Boot; Benjamin A.Rolfe
      =0A &= nbsp;  >Cc:    paws@ietf.org
      =0A  = ;  >Subject:      Re: [paws] XML schema versus JSON,= vCard & iCal
      =0A    >
      =0A    &g= t;Not all masters run over the core network.
      =0A    >S= ome of the Use cases have a master talking to another OTA
      =0A  = ;  >We should not assume that all Masters are attached to utility p= ower so we
      =0A    >should be sympathetic to processing= energy use also.
      =0A    >
      =0A    &g= t;On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <teco@inf-net.nl> wro= te:
      =0A    >
      =0A    >>
      =0A&= nbsp;   >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe= het volgende
      =0A    >>geschreven:
      =0A &nbs= p;  >>
      =0A    >>> Compactness of mess= ages is important, but it is also important (to me
      =0A   = >>>at least) to be realizable in an implementation with limited r= esources,
      =0A    >>>such as embedded devices in = what are now popularly called "M2M"
      =0A    >>>ap= plications.  A lot of these devices could use IP all the end to end,=0A    >>>but may have a very compact, simple sta= ck and applications (i.e.  no
      =0A    >>>bro= wser).  Is JSON typically implemented when there is no browser?
      =0A=     >>>Would it be hard to do in a resource constra= ined device (i.e. where we
      =0A    >>>talk about = memory size in Kilo-bytes still).
      =0A    >>
      =0A&= nbsp;   >>In use cases and requirements document, there are= no requirements for
      =0A    >>protocol performance.= I guess OS/IP/TCP/TLS code size supersedes needs
      =0A    = >>for JSON or XML.
      =0A    >>
      =0A &nbs= p;  >>Same for timing: TCP/TLS connection setup will take more t= han the PAWS
      =0A    >>message exchange, I think. Th= is may be of importance when using satcom
      =0A    >>= links.
      =0A    >>
      =0A    >>B= ecause PAWS runs between master and database, over core network,
      =0A&nbs= p;   >>performance is not our primary concern. But as alway= s, it is good to keep
      =0A    >>an eye on efficiency= .
      =0A    >>
      =0A    >>Teco=0A    >>
      =0A    >>> Than= ks
      =0A    >>> Ben
      =0A    >&= gt;>
      =0A    >>>
      =0A    >= >>> We had a discussion on XML vs. JSON. I prefer the one with mos= t
      =0A    >>>>compact messages.
      =0A &n= bsp;  >>>>
      =0A    >>>> On vC= ard and JSON: what is the status of "A JavaScript Object Notation
      =0A&nb= sp;   >>>>(JSON) Representation for vCard"?
      =0A&nb= sp;   >>>> http://tools.ietf.org/html/draft-bhat-vca= rddav-json-00
      =0A=0A    >>>>
      = =0A    >>>> On valid times: can we use same form= at as certificates? They have
      =0A    >>>>simi= lar simple requirements: valid notBefore&  notAfter.
      =0A &= nbsp;  >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.= 5
      =0A    >>>>
      =0A  &n= bsp; >>>> Teco
      =0A    >>>> ______= _________________________________________
      =0A    >>= >> paws mailing list
      =0A    >>>>&= nbsp;paws@i= etf.org
      =0A    >>>> https://www.ietf.org/mail= man/listinfo/paws
      =0A    >>>>
      = =0A    >>>
      =0A    >>> __= _____________________________________________
      =0A    >= >> paws mailing list
      =0A    >>> = ;paws@ietf.= org
      =0A    >>> https://www.ietf.org/mailman/lis= tinfo/paws
      =0A    >>
      =0A  &= nbsp; >>_______________________________________________
      =0A &= nbsp;  >>paws mailing list
      =0A    >>paws@ietf.org
      =0A    >>      https://www.ietf.org/mailman/listinfo/paws
      =0A &n= bsp;  >
      =0A    >______________________________= _________________
      =0A    >paws mailing list
      =0A&nbs= p;   >paws@ietf.org
      =0A    >https://www.ietf.org/mailman/listinfo/paws      =
      =0A    
      =0A    _= ______________________________________________
      =0A    paw= s mailing list
      =0A    paws@ietf.org
      =0A&nbs= p;   https://www.ietf.org/mailman/listinfo/paws
      =0A  = ;  
      =0A
      =0A
      =0A
      =0A
      =0A-- =
      =0A-vince
      =0A
      =0A_________________________________________= ______
      =0Apaws mailing list
      =0Apaws@ietf.org
      =0Ahttps://www.ietf.org/mailman/listinfo/paws
      =0A_______________________________________________
      =0Apaws mailing = list
      =0A      paws@ie= tf.org
      =0Ahttps= ://www.ietf.org/mailman/listinfo/paws
      =0A
      =0A
      = =0A
      =0A
      =0A
      =0A
      =0A

      =0A
      =0A =0A
      =0A
      =0A
      =0A
       
      =0A
      =0A
      =0A
      = =0A
      -- 
      =0A-vince
      =0A
      =0A
      =0A
      =
 
      =0A
       
      =0A
      _________________________________=
______________
      =0A
      paws mailing list
      =0A
      paws@ietf.org
      = =0A
      https://www.ietf.org/=
mailman/listinfo/paws
      =0A
      =0A
       
      =0A=0A
      ______________________________= _________________
      =0Apaws mailing list
      =0Ap= aws@ietf.org
      =0Ahttps://www.ietf.org/mailman/listinfo= /paws
      =0A
      =0A
      =0A
      =0A
       
      =0A
      =0A
      =0A
      =0A
      =0A=
      =0A
        
      =0A
      _______________________________________=
________
      =0A
      paws mailing list
      =0A
      paws@ietf.org
      =0A
      https://www.ietf.org/m=
ailman/listinfo/paws
      =0A
       
      =0A
      =0A
      _____= __________________________________________
      =0Apaws mailing list
      =0Apaws@ietf.org
      =0Ahttps://ww= w.ietf.org/mailman/listinfo/paws
      =0A
      =0A
       
      = =0A
    =0A
     
    =0A
    =0A
    =0A
     
    =0A<= /div>=0A
    =0A
    =0A=0A

    ____________________________________= ___________
    paws mailing list
    paws@ietf.org=
    https://www.ietf.org/mailman/listinfo/paws
    = =0A


    ____________________= ___________________________
    =0Apaws mailing list
    =0Apaws@ietf.org
    =0Ahttps://www.ietf.org/mailma= n/listinfo/paws
    =0A



    --
    -vince
    =0A
    =0A

    _________________________= ______________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.o= rg/mailman/listinfo/paws


    ---874068440-262716099-1345874051=:20626-- From d.joslyn@spectrumbridge.com Sat Aug 25 05:40:44 2012 Return-Path: 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 373AD21F8527 for ; Sat, 25 Aug 2012 05:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] 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 5wn2P+kUS-rJ for ; Sat, 25 Aug 2012 05:40:40 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id D63D321F852A for ; Sat, 25 Aug 2012 05:40:39 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Sat, 25 Aug 2012 08:40:38 -0400 From: Don Joslyn To: "Basavaraj.Patil@nokia.com" Date: Sat, 25 Aug 2012 08:40:37 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Iej7JadvAx8UahySbuq9n2zQAAU/5DAJUxXAAABrI7AAAWoncAABh1noAAifZJAAAEHtqAAAHwqAAADmEvAACA/ioAAAG/7gAAADZkgAABIt+A///NtAD//meaQIADLqOAgAADSYCAAAgwgIAAAR6AgAAX74CAAAsjAP//rRSAgABqLoD//8WEgAAr8oFc Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_lf5j1lynsnsjfb2s45vx4gac1345898437297emailandroidcom_" MIME-Version: 1.0 Cc: "paws@ietf.org" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 12:40:44 -0000 --_000_lf5j1lynsnsjfb2s45vx4gac1345898437297emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If we decide to use LoST for discovery does it require the use of XML in th= e message format? Sent from my Verizon Wireless 4G LTE DROID RAZR 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" 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 wrote: >> >> +1 to Brian's view on using JSON only. >> >> From: "", "Brian.Rosen@neustar.biz" >> >> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko >> Cc: "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 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 va= lid >> 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 t= hat >> 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 on= ly >> 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] On Beha= lf >> Of ext Rosen, Brian >> Sent: Friday, August 24, 2012 10:43 AM >> To: Benjamin A. Rolfe >> Cc: 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" >> wrote: >> >> >> >> >> There are two ways to achieve interoperability when you have an op= tion. >> 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 optional= ly >> 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 choi= ce >> of what to implement doesn't work for me (or Richard). >> >> Brian >> >> On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe >> wrote: >> >> >> Apparently I was unclear. I certainly an capable of being wrong a= s 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 t= he >> 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 JS= ON >> 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] On Beha= lf >> Of Basavaraj.Patil@nokia.com >> Sent: Thursday, August 23, 2012 5:44 PM >> To: Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com >> Cc: 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: "", "Brian.Rosen@neustar.biz" >> Date: Thursday, August 23, 2012 2:43 PM T= o: >> Don Joslyn Cc: "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 interoperabil= ity. >> >> 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 mus= t >> 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 o= nly >> does one: there are no protocol police. >> >> Brian >> >> >> >> >> On Aug 23, 2012, at 3:11 PM, Don Joslyn >> wrote: >> >> >> >> >> Hi Ben, That was my original suggestion, and I still think it mak= es >> the most sense. Thanks for supporting the proposal. Don >> >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Beha= lf >> Of Benjamin A. Rolfe >> Sent: Thursday, August 23, 2012 3:05 PM >> To: paws@ietf.org >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >> >> Someone suggested that PAWS define both, and let the vendors decid= e >> 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 ] On >> Behalf Of Gabor.Bajko@nokia.com >> Sent: Tuesday, August 21, 2012 12:42 AM >> To: 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 oth= er >> encoding. To prevent endless discussions on this topic I'd suggest w= e >> 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 ] On >> Behalf Of ext Das, Subir >> Sent: Monday, August 20, 2012 2:50 PM >> To: Don Joslyn; Vincent Chen; Weixinpeng >> Cc: 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 langua= ges/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] >> On Behalf Of Don Joslyn >> Sent: Monday, August 20, 2012 4:54 PM >> To: Vincent Chen; Weixinpeng >> Cc: 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 ] On >> Behalf Of Vincent Chen >> Sent: Monday, August 20, 2012 2:56 PM >> To: Weixinpeng >> Cc: 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, supportin= g >> 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 (n= ested lists and >> maps) * Simple-to-use libraries exist for all majo= r >> languages/platforms * Don't need a tool chain to work wi= th 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 suppor= t >>XML? >> >> >> >> [DJ - We currently support half a dozen TVDB radio vendors (embedd= ed >> 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 > > 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 ] On >> Behalf Of Rosen, Brian >> >> Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; >> gabor.bajko@nokia.com ; >> vchen@google.com ; peter@spectrumbridge.com >> >> >> Cc: 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 >> >> From: Manikkoth Sajeev = > >> Reply-To: Manikkoth Sajeev > > >> Date: Thu, 16 Aug 2012 22:37:38 -0400 >> To: "Gabor.Bajko@nokia.com " >> >, "Rosen, Brian" >> >, >> "vchen@google.com " > >, "peter@spectrumbridge.com >> " > > >> Cc: "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 Email: >> mksaji@ieee.org >> http://www.linkedin.com/in/mksajeev >> >> >> >> From: "Gabor.Bajko@nokia.com " >> > To: >> Brian.Rosen@neustar.biz ; >> vchen@google.com ; peter@spectrumbridge.com >> Cc: paws@ietf.org >> Sent: Friday, 17 August 2012, 4:55 S= ubject: Re: >> [paws] XML schema versus JSON, vCard & iCal >> >> >> We have not heard any objections for using JSON encoding instead o= f >> XML. Therefore, let's go for JSON, and close this thread. >> >> - Gabor >> >> -----Original Message----- >> From: 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 ' >> 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 >> >> >> >> -----Original Message----- From: Vincent Chen >> [mailto:vchen@google.com ] Sent: Monday, >> August 13, 2012 06:04 PM Eastern Standard Time To: Peter Stanf= orth >> Cc: Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org >> Subject: Re: [paws] XML schema versus J= SON, >> 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/ ) 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 >> > 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" >> >> > wr= ote: >> >> >Our experience in the IETF over many years is that economizin= g >> message >size and compromising utility and security in search = of >> efficiency of >implementation on small devices is a poor tra= de 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 load= ed on a >> small device is reasonable. > >Brian (as individual) = > >> > > > -----Original Message----- >From: Peter >> Stanforth [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 >Sub= ject: >> 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" > 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) t= o be >> realizable in an implementation with limited resources, >>>suc= h 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-byte= s >> still). >> >>In use cases and requirements document, th= ere 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 >>> Be= n >>> >> >>> >>>> 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 >> >>>> >> >>>> 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 >> >>>> >>>> >> Teco >>>> _______________________________________________ >>>> >> paws mailing list >>>> paws@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/paws >> >>>> >>> >>= > >> _______________________________________________ >>> paws maili= ng >> list >>> paws@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >>_______________________________________________ >>paws mailing >> list >>paws@ietf.org >> >>https://www.ietf.org/mailman/listinfo/paws >> > >> >_______________________________________________ >paws mailing = list >> >paws@ietf.org >> >https://www.ietf.org/mailman/listinfo/paws >> >> >> _______________________________________________ paws= mailing > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_lf5j1lynsnsjfb2s45vx4gac1345898437297emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    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 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.co= m> wrote:

    >I think you are mis-representing Brian's point of view.  I share h= is
    >concern about re-inventing encodings for LoST/xCard.
    >
    >-Pete
    >
    >
    >Basavaraj.Patil@nokia.com wrote:
    >>
    >> +1 to Brian's view on using JSON only.
    >>
    >> From: "<ext Rosen>", "Brian.Rosen@neustar.biz= "
    >> <Brian.Rosen@neustar.biz>
    >> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko
    >> <gabor.bajko@nokia.com> Cc: "paws@ietf.org" <pa= ws@ietf.org> Subject: Re:
    >> [paws] XML schema versus JSON, vCard & iCal
    >>
    >>
    >> The problem we face with JSON only is the LoST/xCard/... issue.&nb= sp; As
    >> long as there is no objection to creating JSON encodings of existi= ng
    >> standards in order to use JSON, and no one uses the fact that thes= e
    >> encodings don't exist as a reason to roll our own equivalents, I a= m
    >> okay with JSON only.
    >>
    >> Brian
    >>
    >> On Aug 24, 2012, at 3:08 PM, 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 st= ill
    >> talk, but not use that feature. That is basically option B) from >> Brain's list.
    >>
    >>       I'd like to suggest that we re= cognize that option A) and B) are valid
    >> options, while option C) is invalid, and we should stop debating i= t.
    >>       I'd also like to add the obvio= us 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 g= ood 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 p= ick
    >> one of the two specified. As Robert mentioned in his email, this h= as
    >> 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<= br> >>encodings.
    >>
    >>       Is there anyone who has a tech= nical 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 again= st
    >> picking JSON. One said that JSON requires native Java, which is wr= ong,
    >> the other objection gave no real reason. So I am wondering if ther= e is
    >> really any valid technical reason against using JSON only?
    >>
    >>       -     = ;     Gabor
    >>
    >>
    >>       From: paws-bounces@ietf.org [<= a href=3D"mailto:paws-bounces@ietf.org">mailto:paws-bounces@ietf.org] O= n Behalf
    >> Of ext Rosen, Brian
    >>       Sent: Friday, August 24, 2012 = 10:43 AM
    >>       To: Benjamin A. Rolfe
    >>       Cc: paws@ietf.org
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Okay:
    >>
    >>       So, I implement a database, an= d I implement XML
    >>       You implement a device, and yo= u implement JSON
    >>
    >>       You query my database (let's n= ot 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, &= quot;Benjamin A. Rolfe"
    >> <ben@blindcreek.com> wrote:
    >>
    >>
    >>
    >>
    >>       There are two ways to achieve = interoperability when you have an option.
    >>       There are many existence proof= s 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 requir= ing
    >> 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 im= plement one specific choice ("MUST
    >> implement") and both can optionally implement the other choic= e.  Only
    >> if both ends implement the other choice would that be available. >>
    >>       So, in this case we could do o= ne of the following:
    >>       A) Databases implement both XM= L 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, Rich= ard was suggesting B.
    >>
    >>       I don't care, but choice C) Bo= th 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>
    >> 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 impl= ementer figure
    >> out which is best for their particular device requirements and tra= de-
    >> offs.  This is *preferable* from my perspective.
    >>
    >>       If you provide more than one f= orm in the database, devices using the
    >> database need some means for figuring out which are available. It<= br> >> can't use it if it doesn't no about it. This is an observations, n= ot
    >> 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 de= vices can
    >> discover what options the database supports.  If you have suc= h a
    >> mechanism and all devices use it (a  bootstrap protocol), eve= rything
    >> else could be options.  This requires additional functions in= both
    >> database and device implementations.
    >>       If on the other hand the devic= e 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 datab= ase
    >> 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 th= e 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 act= ually 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.<= br> >>
    >>       IMHO XML MUST anything else de= fined 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 [<= a href=3D"mailto:paws-bounces@ietf.org">mailto:paws-bounces@ietf.org] O= n Behalf
    >> Of Basavaraj.Patil@nokia.com
    >>       Sent: Thursday, August 23, 201= 2 5:44 PM
    >>       To: Brian.Rosen@neustar.biz; d= .joslyn@spectrumbridge.com
    >>       Cc: paws@ietf.org
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>
    >>       I agree with Brian.
    >>       There needs to be a default ma= ndatory to implement option in order to
    >> achieve interoperability.
    >>       And this applies to the device= and database side of the protocol.
    >>
    >>       -Raj
    >>
    >>       From: "<ext Rosen>&= quot;, "Brian.Rosen@neustar.biz"
    >> <Brian.Rosen@neustar.biz>     Date: Thur= sday, August 23, 2012 2:43 PM  To:
    >> Don Joslyn <d.joslyn@spectrumbridge.com>   &n= bsp;  Cc: "paws@ietf.org"
    >> <paws@ietf.org>       Subject:= Re: [paws] XML schema versus JSON, vCard &
    >>iCal
    >>
    >>       One of my favorite IETF expres= sions 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 ha= nd, the
    >> whole point of a protocol document like ours is that two independe= nt
    >> 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 st= op working, and the product managers
    >> will figure it out using proprietary protocols.  The market w= ill decide.
    >>
    >>       So, I feel strongly that if on= e end is "either", the other end must
    >> be "both".  It's also acceptable to say both ends i= mplement one choice
    >> and the other is optional at both ends.  Here, I think it's s= erver
    >> 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, D= on Joslyn <d.joslyn@spectrumbridge.com>
    >> wrote:
    >>
    >>
    >>
    >>
    >>       Hi Ben,  That was my orig= inal suggestion, and I still think it makes
    >> the most sense.       Thanks for sup= porting the proposal.      Don
    >>
    >>       From: paws-bounces@ietf.org [<= a href=3D"mailto:paws-bounces@ietf.org">mailto:paws-bounces@ietf.org] O= n Behalf
    >> Of Benjamin A. Rolfe
    >>       Sent: Thursday, August 23, 201= 2 3:05 PM
    >>       To: paws@ietf.org
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Someone suggested that PAWS de= fine 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 &l= t;mailto:paws-bounces@ietf.org= >
    >> [mailto:paws-bounces@ietf= .org <mailto:paws-bounces@i= etf.org> ] On
    >> Behalf Of 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>
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Now I can't see anymore any wi= llingness to agree on one or the other
    >> encoding.     To prevent endless discussions o= n 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 &l= t;mailto:paws-bounces@ietf.org= >
    >> [mailto:paws-bounces@ietf= .org <mailto:paws-bounces@i= etf.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> ; 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:
    >>
    >>
    >>           &= nbsp;   *       Simple-to-use libra= ries exist for all major languages/platforms
    >>           &= nbsp;   *       Don't need a tool c= hain to work with the data, as is typically
    >> needed for XML
    >>
    >>
    >>
    >>
    >>       From: paws-bounces@ietf.org &l= t;mailto:paws-bounces@ietf.org= >
    >> [mailto:paws-bounces@ietf= .org] <mailto:[mail= to: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> ; Manikkoth Sajeev >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Please see my comments below..= .
    >>       Thanks,
    >>       Don
    >>
    >>       From: paws-bounces@ietf.org &l= t;mailto:paws-bounces@ietf.org= >
    >> [mailto:paws-bounces@ietf= .org <mailto:paws-bounces@i= etf.org> ] On
    >> Behalf Of Vincent Chen
    >>       Sent: Monday, August 20, 2012 = 2:56 PM
    >>       To: Weixinpeng
    >>       Cc: 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 data= bases support both XML and JSON,
    >> devices only need to support one to talk to the database. Our curr= ent
    >> 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 us= e 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 t= hat
    >> developers (client-side) prefer it for its simplicity:
    >>
    >>           &= nbsp;   *       Representation clos= ely matches most data models (nested lists and
    >> maps)          &= nbsp;      *       S= imple-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 gai= ns of JSON also matter to the
    >> scalability of serving systems.
    >>
    >>
    >>       [DJ - I can't argue against th= ese listed pros for JSON, especially
    >> when you're dealing with a lot of data (like Twitter, FourSquare,<= br> >> Facebook and Google does). But I'm assuming that PAWS messages wil= l
    >> not be exchanged nearly as often as the applications mentioned abo= ve.
    >> But again, I know JSON is more efficient, can't argue with that.]<= br> >>
    >>       *     = ;  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 hal= f 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 datab= ase
    >> is not that much or exchanged that often.]
    >>
    >>       On Fri, Aug 17, 2012 at 6:06 P= M, Weixinpeng <weixinpeng@huawei.com
    >> <mailto:weixinpeng@hua= wei.com> > wrote:       Considering= of the design of
    >> database discovery protocol, the LoST protocol may be used and LoS= T is
    >> based on XML, so I think XML may be preferred.
    >>
    >>       --Xinpeng Wei
    >>
    >>       From: paws-bounces@ietf.org &l= t;mailto:paws-bounces@ietf.org= >
    >> [mailto:paws-bounces@ietf= .org <mailto:paws-bounces@i= etf.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> ;
    >> vchen@google.com <mailto:vc= hen@google.com> ; peter@spectrumbridge.com
    >> <mailto:peter@spect= rumbridge.com>
    >>
    >>       Cc: 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 s= ee
    >> the choice of json mean we then decide to roll our own versus usin= g
    >> existing standards based on the idea there is no json representati= on
    >> of an existing standard.  So, if choosing json means folks fe= el free
    >> to ignore existing xml based standards such as xCard and LoST, the= n I
    >> would not want to use json.
    >>
    >>       I would prefer to not have &qu= ot;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<= br> >> implement either.
    >>
    >>       There are json validators, so = I don't think that is a big deal.
    >>
    >>       My experience in protocol desi= gn on the Internet is that decisions
    >> made solely or even largely because of compactness advantages rare= ly
    >> are good choices.  If you like json because it is smaller, th= en I
    >> believe you need a much better reason.  Binary doesn't work f= or me, at
    >> all.  I have been involved in big binary vs text wars in prot= ocol
    >> design.  Text wins, binary loses, in my opinion.
    >>
    >>       Brian <as individual> >>
    >>       From: Manikkoth Sajeev <mks= aji@yahoo.com <mailto:mksaji@yahoo.c= om> >
    >>       Reply-To: Manikkoth Sajeev <= ;mksaji@yahoo.com
    >> <mailto:mksaji@yahoo.com> >
    >>       Date: Thu, 16 Aug 2012 22:37:3= 8 -0400
    >>       To: "Gabor.Bajko@nokia.co= m <    mailto:Gabor.Bajko@nokia.com= > "
    >> <Gabor.Bajko@nokia.com <mailto:Gabor.Bajko@nokia.com> >, "Rosen, Brian" >> <brian.rosen@neustar.biz <mailto:brian.rosen@neustar.biz> >,
    >> "vchen@google.com <mai= lto:vchen@google.com> " <vchen@google.com
    >> <mailto:vchen@google.com> >, "peter@spectrumbridge.com
    >> <    mailto:peter@spect= rumbridge.com> " <peter@spectrumbridge.com
    >> <mailto:peter@spect= rumbridge.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
    >>
    >>       Hi,
    >>
    >>       Can it not be both JSON and XM= L supported? I would vote for that.
    >> Future implementations may prefer XML as it is generic, omni prese= nt,
    >> easy to understand and validate. For compactness may be a  bi= nary xml
    >> optioncan also work. JSON I think will necessitate implementation = to
    >> be native Java and may not be as friendly with other implementatio= n
    >> languages.
    >>
    >>       Best Regards,
    >>
    >>       Sajeev Manikkoth  &n= bsp;      Mobile: +918792292002 <tel:%2B918= 792292002>      Email:
    >> mksaji@ieee.org <mailto:mksa= ji@ieee.org>
    >>       http://www.linkedin.com/in/mksajeev
    >> <http://www.lin= kedin.com/in/mksajeev>
    >>
    >>
    >>       From: "Gabor.Bajko@nokia.= com <mailto:Gabor.Bajko@nokia.c= om> "
    >> <Gabor.Bajko@nokia.com <mailto:Gabor.Bajko@nokia.com> >     = ;  To:
    >> Brian.Rosen@neustar.biz <mailto:Brian.Rosen@neustar.biz> ;
    >> vchen@google.com <mailto:vc= hen@google.com> ; peter@spectrumbridge.com
    >> <mailto:peter@spect= rumbridge.com>     Cc: paws@ietf.org
    >> <mailto:paws@ietf.org>&= nbsp;       Sent: Friday, 17 August 2012, 4:5= 5       Subject: Re:
    >> [paws] XML schema versus JSON, vCard & iCal
    >>
    >>
    >>       We have not heard any objectio= ns 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 &l= t;mailto:paws-bounces@ietf.org= >
    >> [mailto:paws-bounces@ietf= .org <mailto:paws-bounces@i= etf.org> ] On
    >> Behalf Of ext Rosen, Brian
    >>       Sent: Monday, August 13, 2012 = 3:14 PM
    >>       To: 'Vincent Chen'; 'Peter Sta= nforth'
    >>       Cc: '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 r= ather than a time in seconds since
    >> epoch.  It's very easy to parse, and its simpler to use and d= ebug.
    >> Don't care a whole lot about that
    >>
    >>       Brian <as individual> >>
    >>
    >>
    >>       -----Original Message-----&nbs= p;      From:     Vincent Chen=
    >> [mailto:vchen@google.com &= lt;mailto:vchen@google.com> ]&nb= sp; Sent:    Monday,
    >> August 13, 2012 06:04 PM Eastern Standard Time   &n= bsp;    To:    Peter Stanforth
    >>       Cc:    Rosen, B= rian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
    >> <mailto:paws@ietf.org>&= nbsp;       Subject:    Re: [p= aws] XML schema versus JSON,
    >> vCard & iCal
    >>
    >>       XML vs JSON
    >>
    >>       Between XML and JSON, JSON mes= sages are more compact and easier to
    >> process (parsing, synthesis). As clarification, JSON does not requ= ire
    >> JavaScript or a Browser. It is a text-based representation of data=
    >> that is language independent, yet well-matched to all major langua= ges.
    >> 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 specification= s, 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, assumin= g
    >> devices already have native libraries that provide time in this fo= rmat.
    >> Is that a valid assumption? Of course, this is less human-readable= ....
    >>
    >>
    >>       On Mon, Aug 13, 2012 at 6:49 A= M, Peter Stanforth
    >> <peter@spectrumbridge.com <mailto:peter@spectrumbridge.com> > wrote:
    >>
    >>
    >>           Whenev= er 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        &nb= sp;  on that one.
    >>
    >>           On Mon= Aug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"
    >>
    >>           <Br= ian.Rosen@neustar.biz <mailto= :Brian.Rosen@neustar.biz> > wrote:
    >>
    >>           >Ou= r 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.        &nb= sp;  >         >Assuming= a json library can be loaded on a
    >> small device is reasonable.       &g= t;         >Brian (as individual= )            >&nb= sp;   
    >>   >       > &nb= sp;       > -----Original Message-----&nbs= p;     >From:  Peter
    >> Stanforth [mailto:pete= r@spectrumbridge.com
    >> <mailto:peter@spect= rumbridge.com> ]       >Sent: = Saturday, August 11,
    >> 2012 07:13 AM Eastern Standard Time     &= nbsp; >To:    Teco Boot; Benjamin
    >> A.Rolfe          = ; >Cc:    paws@ietf.org <mailto:paws@ietf.org>      >Subject:=
    >>      Re: [paws] XML schema versus JSON, v= Card & iCal      >    &= nbsp;    >Not
    >> all masters run over the core network.    &nbs= p;       >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.      =       >      &nbs= p;  >On SatAug/11/12 Sat Aug 11,
    >> 5:30 AM, "Teco Boot" <teco@inf- net.nl <mailto:teco@inf-net.nl> > wrote:
    >>           >&n= bsp;        >>   &n= bsp;    >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. = Rolfe
    >> het volgende      >>geschreven:&nbs= p;            >&g= t;        >>> Compactness of me= ssages
    >> is important, but it is also important (to me   &nb= sp;         >>>at least) t= o be
    >> realizable in an implementation with limited resources,  = ;         >>>such as
    >> embedded devices in what are now popularly called "M2M"&= nbsp;     
    >> >>>applications.  A lot of these devices could use I= P 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       &nb= sp;     >>>talk about memory size in Kilo-byte= s
    >> still).          = ; >>        >>In use cases a= nd requirements document, there are
    >> no requirements for       >>pr= otocol performance. I guess OS/IP/TCP/TLS
    >> code size supersedes needs      &nbs= p; >>for JSON or XML.        >&= gt;        >>Same
    >> for timing: TCP/TLS connection setup will take more than the PAWS&= nbsp;   
    >> >>message exchange, I think. This may be of importance when = using
    >> >>satcom
    >>           >&g= t;links.          >>&nbs= p;       >>Because PAWS runs between ma= ster and
    >> database, over core network,      >>= ;performance is not our primary
    >> concern. But as always, it is good to keep    =     >>an eye on efficiency.
    >>           >&g= t;        >>Teco   =          >>   =      >>> Thanks     &= nbsp;  >>> Ben        = ;   >>>  
    >> >>>       >>>> = We had a discussion on XML vs. JSON. I prefer the one
    >> >>> with
    >> most      >>>>compact message= s.             = >>>>      >>>> On vCard an= d JSON:
    >> what is the status of "A JavaScript Object Notation &nbs= p;     >>>>(JSON)
    >> Representation for vCard"?      = ;  >>>>
    >> http://tools.ietf.org/html/draft-bhat-vcarddav-json-00
    >> <http://tools.ietf.org/html/draft-bhat-vcarddav-json-00> &n= bsp;        >>>> 
    >> >>>> On valid times: can we use same format as certifi= cates? They have       
    >>    >>>>similar simple requirements: val= id notBefore&  notAfter.      
    >> >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
    >> <http://tools.ietf.org/html/rfc3280#section-4.1.2.5>  &nbs= p;   >>>>      >>>&= gt;
    >> Teco      >>>> ______________= _________________________________      >>>= ;>
    >> paws mailing list         = >>>> paws@ietf.org <mailto:= paws@ietf.org>    
    >> >>>> https://www.ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>      &= gt;>>>      >>>   = ;    >>>
    >> _______________________________________________   &= nbsp;       >>> paws mailing
    >> list      >>> paws@ietf.org <= mailto:paws@ietf.org>  &n= bsp;       >>>
    >> https://www= .ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>      &= gt;>   
    >> >>_______________________________________________  = ;       >>paws mailing
    >> list      >>paws@ietf.org <mailto:paws@ietf.org>   &= nbsp;   
    >> >>https://www.ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>      &= gt;    
    >> >_______________________________________________  &nb= sp;       >paws mailing list
    >>           >pa= ws@ietf.org <mailto:paws@ietf.org&g= t;        
    >> >https://www.ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>
    >>
    >>           ______= _________________________________________     &nbs= p;     paws mailing
    >

    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org= /mailman/listinfo/paws
     --_000_lf5j1lynsnsjfb2s45vx4gac1345898437297emailandroidcom_-- From sdas@appcomsci.com Sat Aug 25 18:30:25 2012 Return-Path: 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 9574A21F84A5 for ; Sat, 25 Aug 2012 18:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] 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 2nGFqOgXwtPW for ; Sat, 25 Aug 2012 18:30:22 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id D7DF021F84A1 for ; Sat, 25 Aug 2012 18:30:21 -0700 (PDT) Received: from bambi.research.telcordia.com (bambi.appcomsci.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q7Q1U9bJ002956; Sat, 25 Aug 2012 21:30:10 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q7Q1U8db012571; Sat, 25 Aug 2012 21:30:08 -0400 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at bambi Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Sat, 25 Aug 2012 21:30:07 -0400 From: "Das, Subir" To: Manikkoth Sajeev , "Gabor.Bajko@nokia.com" , "Brian.Rosen@neustar.biz" , "ben@blindcreek.com" Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Ie/mfIJuS0gUKZuEsiwN7sRAAAU/5DAKHEAwAABrI7AAAWoncAABh1noAAifZJAAAEHtqAAAZ1W8AACdx8AACA/ioAAAG/7gAAADZkgAABIt6AAAQuNIAAJMQFAAADi+6AAABpM4AAAQX3gAAAI8OAAAL97IAAEPRCAAAlYhKQ Date: Sun, 26 Aug 2012 01:30:06 +0000 Message-ID: References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> <00c601cd820b$67b97170$372c5450$@us> <5037B28B.70501@blindcreek.com> <5D0B1E63-79FE-4BC6-A446-3470931D1043@neustar.biz> <5037BC2B.7010008@blindcreek.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724@008-AM1MPN1-006.mgdnok.nokia.com> <1345864438.6327.YahooMailNeo@web120306.mail.ne1.yahoo.com> In-Reply-To: <1345864438.6327.YahooMailNeo@web120306.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.16.87] Content-Type: multipart/alternative; boundary="_000_AAC987F0CC2C7845A9FBD8A36D52E12D968577rrcatsexmb1_" MIME-Version: 1.0 Cc: "paws@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 01:30:25 -0000 --_000_AAC987F0CC2C7845A9FBD8A36D52E12D968577rrcatsexmb1_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgd291bGQgYmUgZ29vZCBpZiB5b3UgY2FuIHByb3ZpZGUgc29tZSBzcGVjaWZpYyBleGFtcGxl cyB3aGVyZSBKU09OIGlzIHByb2JsZW1hdGljIGJ1dCBYTUwgaXMgZWFzaWVyLg0KDQotU3ViaXIN Cg0KRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgTWFuaWtrb3RoIFNhamVldg0KU2VudDogRnJpZGF5LCBBdWd1c3Qg MjQsIDIwMTIgMTE6MTQgUE0NClRvOiBHYWJvci5CYWprb0Bub2tpYS5jb207IEJyaWFuLlJvc2Vu QG5ldXN0YXIuYml6OyBiZW5AYmxpbmRjcmVlay5jb20NCkNjOiBwYXdzQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJkICYgaUNhbA0KDQpI aSwNCg0KSSB3b3VsZCBzdGlsbCBzdXBwb3J0IFhNTC4gSlNPTiBsaWJyYXJpZXMgYXJlIGF2YWls YWJsZSBmb3IgYWxsIGxhbmd1YWdlcy4gQnV0IGludGVyZmFjaW5nIGFuZCBsaW5raW5nIHN1Y2gg bGlicmFyaWVzIGFyZSBwcm9ibGVtYXRpYyBvbiBlbWJlZGRlZCBkZXZpY2VzIG1vc3Qgb2YgdGhl IHRpbWUuIEFuZCBpZiBhbiBpbXBsZW1lbnRhdGlvbiB2b3VjaCBmb3IgbXVsdGlwbGUgc3VjaCBu b24gbmF0aXZlIGxhbmd1YWdlIGxpYnJhcmllcyB0aGVuIGRldmVsb3BlcnMgbGlmZSBpcyBoZWxs Li4uDQoNCkJlc3QgUmVnYXJkcywNCg0KU2FqZWV2IE1hbmlra290aA0KDQpGcm9tOiAiR2Fib3Iu QmFqa29Abm9raWEuY29tPG1haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb20+IiA8R2Fib3IuQmFq a29Abm9raWEuY29tPG1haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb20+Pg0KVG86IEJyaWFuLlJv c2VuQG5ldXN0YXIuYml6PG1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej47IGJlbkBibGlu ZGNyZWVrLmNvbTxtYWlsdG86YmVuQGJsaW5kY3JlZWsuY29tPg0KQ2M6IHBhd3NAaWV0Zi5vcmc8 bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpTZW50OiBTYXR1cmRheSwgMjUgQXVndXN0IDIwMTIsIDA6 MzgNClN1YmplY3Q6IFJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJiBp Q2FsDQoNCldpRmkgd29ybGQgYnVpbGRzIG9uIG1hbmRhdGluZyB0aGUgaW1wbGVtZW50YXRpb24g KGFuZCBjZXJ0aWZpY2F0aW9uKSBvZiBhIGJhc2Ugc3BlYywgYW5kIGEgc2V0IG9mIG9wdGlvbmFs IGZlYXR1cmVzLiBJZiBhbiBvcHRpb25hbCBmZWF0dXJlIGlzIG5vdCBzdXBwb3J0ZWQgYnkgb25l IG9mIHRoZSBwZWVycywgdGhleSBjYW4gc3RpbGwgdGFsaywgYnV0IG5vdCB1c2UgdGhhdCBmZWF0 dXJlLiBUaGF0IGlzIGJhc2ljYWxseSBvcHRpb24gQikgZnJvbSBCcmFpbuKAmXMgbGlzdC4NCg0K SeKAmWQgbGlrZSB0byBzdWdnZXN0IHRoYXQgd2UgcmVjb2duaXplIHRoYXQgb3B0aW9uIEEpIGFu ZCBCKSBhcmUgdmFsaWQgb3B0aW9ucywgd2hpbGUgb3B0aW9uIEMpIGlzIGludmFsaWQsIGFuZCB3 ZSBzaG91bGQgc3RvcCBkZWJhdGluZyBpdC4NCknigJlkIGFsc28gbGlrZSB0byBhZGQgdGhlIG9i dmlvdXMgb3B0aW9uIEQpIHRvIHRoZSBsaXN0LCB3aGljaCBpcyB0aGF0IGJvdGggdGhlIG1hc3Rl ciBkZXZpY2VzIGFuZCBEQnMgc3VwcG9ydCBvbmUgYW5kIHRoZSBzYW1lIGVuY29kaW5nIDspDQoN Ck9wdGlvbiBBKSBzZWVtcyB0byBiZSBsaWtlIGEgZ29vZCBjb21wcm9taXNlLCBhbmQgd291bGQg Y3V0IGRpc2N1c3Npb25zIHNob3J0LCB3aXRoIHRoZSBvbmx5IGNhdmVhdCB0aGF0IGlmIHRoZXJl IGlzIG5vIHN0cm9uZyB0ZWNobmljYWwgYXJndW1lbnQgZm9yIHN1cHBvcnRpbmcgYW5kIHNwZWNp ZnlpbmcgdHdvIGRpZmZlcmVudCBlbmNvZGluZ3MsIHRoZW4gdGhlIGllc2cgbWF5IHNlbmQgdGhl IGRvY3VtZW50IGJhY2sgdG8gdGhlIHdnIHRvIHBpY2sgb25lIG9mIHRoZSB0d28gc3BlY2lmaWVk LiBBcyBSb2JlcnQgbWVudGlvbmVkIGluIGhpcyBlbWFpbCwgdGhpcyBoYXMgaGFwcGVuZWQgaW4g dGhlIHBhc3QsIHNvIGl0IGlzIGxpa2VseSBpdCB3b3VsZCBoYXBwZW4gYWdhaW4uIEFuZCBmcmFu a2x5LCBJIGRvIG5vdCBzZWUgYSBzdHJvbmcgYXJndW1lbnQgaW4gZmF2b3Igb2YgdHdvIGRpZmZl cmVudCBlbmNvZGluZ3MuDQoNCklzIHRoZXJlIGFueW9uZSB3aG8gaGFzIGEgdGVjaG5pY2FsIGFy Z3VtZW50IGFnYWluc3Qgc3VwcG9ydGluZyBvbmx5IG9uZSBlbmNvZGluZywgYmVpbmcgdGhhdCBl aXRoZXIgeG1sIG9yIGpzb24/DQoNCk1vc3QgcGVvcGxlIHNwZWFrIGluIGZhdm9yIG9mIEpTT04s IGJlY2F1c2UgaXQgaXMgY29tcGFjdCBhbmQgbW9yZSBlZmZpY2llbnQuIEkgd2VudCB0aHJvdWdo IHRoaXMgdGhyZWFkIGFuZCBJIHNhdyAyIG9iamVjdGlvbnMgYWdhaW5zdCBwaWNraW5nIEpTT04u IE9uZSBzYWlkIHRoYXQgSlNPTiByZXF1aXJlcyBuYXRpdmUgSmF2YSwgd2hpY2ggaXMgd3Jvbmcs IHRoZSBvdGhlciBvYmplY3Rpb24gZ2F2ZSBubyByZWFsIHJlYXNvbi4gU28gSSBhbSB3b25kZXJp bmcgaWYgdGhlcmUgaXMgcmVhbGx5IGFueSB2YWxpZCB0ZWNobmljYWwgcmVhc29uIGFnYWluc3Qg dXNpbmcgSlNPTiBvbmx5Pw0KDQotICAgICAgICAgIEdhYm9yDQoNCg0KRnJvbTogcGF3cy1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86cGF3cy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IFJvc2VuLCBCcmlhbg0KU2VudDogRnJp ZGF5LCBBdWd1c3QgMjQsIDIwMTIgMTA6NDMgQU0NClRvOiBCZW5qYW1pbiBBLiBSb2xmZQ0KQ2M6 IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Bhd3Nd IFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJkICYgaUNhbA0KDQpPa2F5Og0KDQpTbywgSSBp bXBsZW1lbnQgYSBkYXRhYmFzZSwgYW5kIEkgaW1wbGVtZW50IFhNTA0KWW91IGltcGxlbWVudCBh IGRldmljZSwgYW5kIHlvdSBpbXBsZW1lbnQgSlNPTg0KDQpZb3UgcXVlcnkgbXkgZGF0YWJhc2Ug KGxldCdzIG5vdCBnZXQgaW50byBob3cgeW91IGRvIHRoYXQgcXVlcnkgd2l0aG91dCBkZWNpZGlu ZyBYTUwgdnMgSlNPTikgYW5kIGRpc2NvdmVyIEkgaW1wbGVtZW50IFhNTCBvbmx5DQoNCldoYXQg ZG8geW91IGRvPw0KDQpCcmlhbg0KDQpPbiBBdWcgMjQsIDIwMTIsIGF0IDE6MzggUE0sICJCZW5q YW1pbiBBLiBSb2xmZSIgPGJlbkBibGluZGNyZWVrLmNvbTxtYWlsdG86YmVuQGJsaW5kY3JlZWsu Y29tPj4gd3JvdGU6DQoNCg0KVGhlcmUgYXJlIHR3byB3YXlzIHRvIGFjaGlldmUgaW50ZXJvcGVy YWJpbGl0eSB3aGVuIHlvdSBoYXZlIGFuIG9wdGlvbi4NClRoZXJlIGFyZSBtYW55IGV4aXN0ZW5j ZSBwcm9vZnMgb2YgdGhlIHRoaXJkIHdheSB0aGF0IEkgbWVudGlvbmVkIGJlbG93Lg0KODAyLjEx ICsgV2lGaSBwcm92aWRlIG1hbnkgb3B0aW9ucyBhbmQgYSBtZWFucyBmb3IgZGV2aWNlcyB0byBz aGFyZSBpbmZvcm1hdGlvbiBhYm91dCB3aGF0IG9wdGlvbnMgZWFjaCBzdXBwb3J0cywgd2l0aG91 dCByZXF1aXJpbmcgdGhhdCBhbnkgZGV2aWNlIGltcGxlbWVudCBldmVyeSBvcHRpb24uICBJdCB3 b3Jrcy4NCg0KVGhhdCBzYWlkLCBJIHRoaW5rIChBKSBpcyB0aGUgYmVzdCBjaG9pY2UsIChCKSBp cyBub3QgYXMgbmljZSBmb3IgbWUsIGFuZCAoQykgaXMgbW9yZSB3b3JrIHRoYW4gZWl0aGVyIG9m IHRoZSBvdGhlciB0d28uDQoNCg0KT25lIGlzIHRoYXQgb25lIGVuZCBpbXBsZW1lbnRzIGJvdGgg Y2hvaWNlcyBhbmQgdGhlIG90aGVyIGVuZCBpbXBsZW1lbnRzIG9uZSBvciBib3RoLg0KDQpUaGUg b3RoZXIgaXMgdGhhdCBib3RoIGVuZHMgaW1wbGVtZW50IG9uZSBzcGVjaWZpYyBjaG9pY2UgKCJN VVNUIGltcGxlbWVudCIpIGFuZCBib3RoIGNhbiBvcHRpb25hbGx5IGltcGxlbWVudCB0aGUgb3Ro ZXIgY2hvaWNlLiAgT25seSBpZiBib3RoIGVuZHMgaW1wbGVtZW50IHRoZSBvdGhlciBjaG9pY2Ug d291bGQgdGhhdCBiZSBhdmFpbGFibGUuDQoNClNvLCBpbiB0aGlzIGNhc2Ugd2UgY291bGQgZG8g b25lIG9mIHRoZSBmb2xsb3dpbmc6DQpBKSBEYXRhYmFzZXMgaW1wbGVtZW50IGJvdGggWE1MIGFu ZCBKU09OLCBkZXZpY2VzIGltcGxlbWVudCBlaXRoZXINCkIpIEJvdGggRGF0YWJhc2VzIGFuZCBk ZXZpY2VzIGltcGxlbWVudCBvbmUgKHNheSBYTUwpIGFuZCBvcHRpb25hbGx5IGltcGxlbWVudCB0 aGUgb3RoZXIgKHNheSBKU09OKQ0KDQpZb3UgYXJlIGFkdm9jYXRpbmcgZm9yIEEsIFJpY2hhcmQg d2FzIHN1Z2dlc3RpbmcgQi4NCg0KSSBkb24ndCBjYXJlLCBidXQgY2hvaWNlIEMpIEJvdGggZGF0 YWJhc2VzIGFuZCBkZXZpY2VzIGhhdmUgYSBjaG9pY2Ugb2Ygd2hhdCB0byBpbXBsZW1lbnQgZG9l c24ndCB3b3JrIGZvciBtZSAob3IgUmljaGFyZCkuDQoNCkJyaWFuDQoNCk9uIEF1ZyAyNCwgMjAx MiwgYXQgMTI6NTcgUE0sIEJlbmphbWluIEEuIFJvbGZlIDxiZW5AYmxpbmRjcmVlay5jb208bWFp bHRvOmJlbkBibGluZGNyZWVrLmNvbT4+IHdyb3RlOg0KDQpBcHBhcmVudGx5IEkgd2FzIHVuY2xl YXIuICBJIGNlcnRhaW5seSBhbiBjYXBhYmxlIG9mIGJlaW5nIHdyb25nIGFzIEkgcHJhY3RpY2Ug b2Z0ZW4sIGJ1dCBpbiB0aGlzIGNhc2UgaXQgaXMgcXVpdGUgdW5saWtlbHkgOi0pLg0KDQpZb3Ug ZG8gbm90IG5lZWQgdG8gY2hvb3NlIG9ubHkgb25lIGZvcm0gdG8gYWNoaWV2ZSBpbnRlcm9wZXJh YmlsaXR5LiAgIElmIHlvdSBoYXZlIHR3bywgbGV0IHRoZSBkZXZpY2UgaW1wbGVtZW50ZXIgZmln dXJlIG91dCB3aGljaCBpcyBiZXN0IGZvciB0aGVpciBwYXJ0aWN1bGFyIGRldmljZSByZXF1aXJl bWVudHMgYW5kIHRyYWRlLW9mZnMuICBUaGlzIGlzICpwcmVmZXJhYmxlKiBmcm9tIG15IHBlcnNw ZWN0aXZlLg0KDQpJZiB5b3UgcHJvdmlkZSBtb3JlIHRoYW4gb25lIGZvcm0gaW4gdGhlIGRhdGFi YXNlLCBkZXZpY2VzIHVzaW5nIHRoZSBkYXRhYmFzZSBuZWVkIHNvbWUgbWVhbnMgZm9yIGZpZ3Vy aW5nIG91dCB3aGljaCBhcmUgYXZhaWxhYmxlLiBJdCBjYW4ndCB1c2UgaXQgaWYgaXQgZG9lc24n dCBubyBhYm91dCBpdC4gVGhpcyBpcyBhbiBvYnNlcnZhdGlvbnMsIG5vdCBhbiBhcmd1bWVudCA7 LSkuDQoNCkl0IGlzIG15ICpvcGluaW9uKiBhdCB0aGUgIG1vbWVudCB0aGF0IGlmIHlvdSBwcm92 aWRlIG9wdGlvbnMsIHRvIG1ha2UgdGhvc2UgdXNlZnVsIHlvdSBuZWVkIHRvIHByb3ZpZGUgIGEg cHJvdG9jb2wgYnkgd2hpY2ggZGV2aWNlcyBjYW4gZGlzY292ZXIgd2hhdCBvcHRpb25zIHRoZSBk YXRhYmFzZSBzdXBwb3J0cy4gIElmIHlvdSBoYXZlIHN1Y2ggYSBtZWNoYW5pc20gYW5kIGFsbCBk ZXZpY2VzIHVzZSBpdCAoYSAgYm9vdHN0cmFwIHByb3RvY29sKSwgZXZlcnl0aGluZyBlbHNlIGNv dWxkIGJlIG9wdGlvbnMuICBUaGlzIHJlcXVpcmVzIGFkZGl0aW9uYWwgZnVuY3Rpb25zIGluIGJv dGggZGF0YWJhc2UgYW5kIGRldmljZSBpbXBsZW1lbnRhdGlvbnMuDQpJZiBvbiB0aGUgb3RoZXIg aGFuZCB0aGUgZGV2aWNlIGNhbiAianVzdCBrbm93IiB0aGF0IHRoZSBkYXRhYmFzZSBoYXMgdHdv IGZvcm1zIGF2YWlsYWJsZSwgaXQgd29uJ3QgbmVlZCB0byBkeW5hbWljYWxseSBmaWd1cmUgaXQg b3V0LiBUaGUgZGV2aWNlIGltcGxlbWVudGVyIGhhcyBvcHRpb25zIGFuZCBzaW1wbGljaXR5LCBz byBJIGxpa2UgaXQuDQoNClNpbmNlIEkgYW0gZm9jdXNlZCBvbiB0aGUgVFZXUyBkZXZpY2VzIHRo YXQgbmVlZCBhY2Nlc3MgdG8gdGhlIGRhdGFiYXNlLCBhbmQgbm90IGEgZGF0YWJhc2UgaW1wbGVt ZW50ZXIsIHNoaWZ0aW5nIGJ1cmRlbiBvbnRvIHRoZSBkYXRhYmFzZSBpbXBsZW1lbnRlciAobm90 IG1lKSB0byByZWR1Y2UgdGhlIGJ1cmRlbiBvbiB0aGUgZGV2aWNlIGltcGxlbWVudGVyIChtZSkg aXMgcHJlZmVycmVkIGZyb20gbXkgcGVyc3BlY3RpdmUuICBUaGUgZGF0YWJhc2UgaW1wbGVtZW50 ZXIgbWF5IGhhdmUgYW5vdGhlciBwZXJzcGVjdGl2ZS4gIFNob3VsZCBJIHBvaW50IG91dCB0aGF0 IHRoZXJlIHdpbGwgYmUgYSBsb3QgbW9yZSBkZXZpY2VzIHRoYW4gZGF0YWJhc2VzPyAgVGhhdCBt aWdodCBzb3VuZCBsaWtlIGFuIGFyZ3VtZW50LCB0aG91Z2gsIHNvIEkgd29uJ3QuLi4uOi1qDQoN CkJlbg0KDQpCcmlhbiBpcyByaWdodCAuLiBzb3JyeSBidXQgdGhlIHJlc3Qgb2YgeW91IGFyZSB3 cm9uZy4g4pi6DQoNClRoaXMgaXMgd2h5IHlvdSBoYXZlIE1VU1QgYW5kIFNIT1VMRCBpbiBSRkMg MjExOS4NCg0KVGhpcyBCVFcgaXMgYSBjbGFzc2ljIGFyZ3VtZW50IGluIElFVEYgdGVybXMgLi4g YnV0IHRoZSBhcmd1bWVudCDigJxsZXQgdGhlIG1hcmtldCBkZWNpZGXigJ0gb25seSBob2xkcyBz byBtdWNoIHZhbGlkaXR5LiAgWW91IGFjdHVhbGx5IGhhdmUgdG8gY2hvb3NlIFNPTUVUSElORyB0 byBjcmVhdGUgYSBiYXNlbGluZSBvZiBpbnRlcm9wZXJhYmlsaXR5Lg0KDQpBIHZpcnR1YWxseSBp ZGVudGljYWwgYXJndW1lbnQgIGlzIG5vdyBwbGF5aW5nIG91dCBpbiBkaXNjdXNzaW9ucyBvZiBt YW5kYXRvcnkgYXVkaW8gYW5kIGNvZGVjIGltcGxlbWVudGF0aW9ucyBmb3IgV0VCUlRDIGxpa2Ug dGhpbmdzLg0KDQpJTUhPIFhNTCBNVVNUIGFueXRoaW5nIGVsc2UgZGVmaW5lZCBTSE9VTEQsIGJ1 dCBNVVNUIG9uIFhNTCBhbmQgSlNPTiBjb3VsZCB3b3JrIGFzIHdlbGwuIEl0IGp1c3QgbGVhZHMg dG8gYSBsZXZlbCBvZiBjb21wbGV4aXR5IGluIGltcGxlbWVudGF0aW9ucy4NCg0KRW5kIG9mIGFy Z3VtZW50IHlvdSBub3cgY2FuIGdvIGJhY2sgdG8geW91ciByZWd1bGFybHkgc2NoZWR1bGUgcHJv Z3JhbW1pbmcuIOKYug0KDQoNCkZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cGF3 cy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb208bWFpbHRvOkJhc2F2YXJhai5QYXRpbEBu b2tpYS5jb20+DQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDIzLCAyMDEyIDU6NDQgUE0NClRvOiBC cmlhbi5Sb3NlbkBuZXVzdGFyLmJpejxtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo+OyBk Lmpvc2x5bkBzcGVjdHJ1bWJyaWRnZS5jb208bWFpbHRvOmQuam9zbHluQHNwZWN0cnVtYnJpZGdl LmNvbT4NCkNjOiBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmIGlDYWwNCg0KDQpJIGFn cmVlIHdpdGggQnJpYW4uDQpUaGVyZSBuZWVkcyB0byBiZSBhIGRlZmF1bHQgbWFuZGF0b3J5IHRv IGltcGxlbWVudCBvcHRpb24gaW4gb3JkZXIgdG8gYWNoaWV2ZSBpbnRlcm9wZXJhYmlsaXR5Lg0K QW5kIHRoaXMgYXBwbGllcyB0byB0aGUgZGV2aWNlIGFuZCBkYXRhYmFzZSBzaWRlIG9mIHRoZSBw cm90b2NvbC4NCg0KLVJhag0KDQpGcm9tOiAiPGV4dCBSb3Nlbj4iLCAiQnJpYW4uUm9zZW5AbmV1 c3Rhci5iaXo8bWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PiIgPEJyaWFuLlJvc2VuQG5l dXN0YXIuYml6PG1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej4+DQpEYXRlOiBUaHVyc2Rh eSwgQXVndXN0IDIzLCAyMDEyIDI6NDMgUE0NClRvOiBEb24gSm9zbHluIDxkLmpvc2x5bkBzcGVj dHJ1bWJyaWRnZS5jb208bWFpbHRvOmQuam9zbHluQHNwZWN0cnVtYnJpZGdlLmNvbT4+DQpDYzog InBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+IiA8cGF3c0BpZXRmLm9yZzxtYWls dG86cGF3c0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3Vz IEpTT04sIHZDYXJkICYgaUNhbA0KDQpPbmUgb2YgbXkgZmF2b3JpdGUgSUVURiBleHByZXNzaW9u cyBpcyAiVGhlcmUgYXJlIG5vIHByb3RvY29sIHBvbGljZSIuICBXZSBhcHBseSB0aGF0IGluIGxv dHMgb2Ygd2F5cywgYnV0IG9uZSBvZiB0aGVtIGlzIHRoYXQgaWYgeW91IGRvbid0IGltcGxlbWVu dCB3aGF0IHRoZSBkb2N1bWVudCBzYXlzLCB5b3UgbWF5IG5vdCBnZXQgaW50ZXJvcGVyYWJpbGl0 eSB3aXRoIG90aGVyIGltcGxlbWVudGF0aW9ucy4gIE9uIHRoZSBvdGhlciBoYW5kLCB0aGUgd2hv bGUgcG9pbnQgb2YgYSBwcm90b2NvbCBkb2N1bWVudCBsaWtlIG91cnMgaXMgdGhhdCB0d28gaW5k ZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zIHdobyBib3RoIGZvbGxvdyB0aGUgZG9jdW1lbnQgd2ls bCBpbnRlcndvcmsuICBJZiB0aGF0IHdhc24ndCB0cnVlLCB3aHkgZG8geW91IG5lZWQgYSBzdGFu ZGFyZD8NCg0KSWYgeW91IHNheSAiZWl0aGVyIiB0byBib3RoIGVuZHMsIHRoZW4geW91IGRvbid0 IGdldCBpbnRlcm9wZXJhYmlsaXR5Lg0KDQpCeSB5b3VyIGFyZ3VtZW50LCB3ZSBzaG91bGQgc3Rv cCB3b3JraW5nLCBhbmQgdGhlIHByb2R1Y3QgbWFuYWdlcnMgd2lsbCBmaWd1cmUgaXQgb3V0IHVz aW5nIHByb3ByaWV0YXJ5IHByb3RvY29scy4gIFRoZSBtYXJrZXQgd2lsbCBkZWNpZGUuDQoNClNv LCBJIGZlZWwgc3Ryb25nbHkgdGhhdCBpZiBvbmUgZW5kIGlzICJlaXRoZXIiLCB0aGUgb3RoZXIg ZW5kIG11c3QgYmUgImJvdGgiLiAgSXQncyBhbHNvIGFjY2VwdGFibGUgdG8gc2F5IGJvdGggZW5k cyBpbXBsZW1lbnQgb25lIGNob2ljZSBhbmQgdGhlIG90aGVyIGlzIG9wdGlvbmFsIGF0IGJvdGgg ZW5kcy4gIEhlcmUsIEkgdGhpbmsgaXQncyBzZXJ2ZXIgZG9lcyBib3RoIGFuZCBjbGllbnQgZG9l cyBlaXRoZXIuDQoNCkl0J3MgYWx3YXlzIHBvc3NpYmxlIHRvIGJ1aWxkIGFuIGltcGxlbWVudGF0 aW9uIG9mIGEgc2VydmVyIHRoYXQgb25seSBkb2VzIG9uZTogdGhlcmUgYXJlIG5vIHByb3RvY29s IHBvbGljZS4NCg0KQnJpYW4gPGFzIGluZGl2aWR1YWw+DQoNCg0KDQoNCk9uIEF1ZyAyMywgMjAx MiwgYXQgMzoxMSBQTSwgRG9uIEpvc2x5biA8ZC5qb3NseW5Ac3BlY3RydW1icmlkZ2UuY29tPG1h aWx0bzpkLmpvc2x5bkBzcGVjdHJ1bWJyaWRnZS5jb20+PiB3cm90ZToNCg0KDQpIaSBCZW4sDQpU aGF0IHdhcyBteSBvcmlnaW5hbCBzdWdnZXN0aW9uLCBhbmQgSSBzdGlsbCB0aGluayBpdCBtYWtl cyB0aGUgbW9zdCBzZW5zZS4NClRoYW5rcyBmb3Igc3VwcG9ydGluZyB0aGUgcHJvcG9zYWwuDQpE b24NCg0KRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwYXdzLWJvdW5jZXNAaWV0 Zi5vcmc+IFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpib3VuY2VzQGlldGYu b3JnPl0gT24gQmVoYWxmIE9mIEJlbmphbWluIEEuIFJvbGZlDQpTZW50OiBUaHVyc2RheSwgQXVn dXN0IDIzLCAyMDEyIDM6MDUgUE0NClRvOiBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAm IGlDYWwNCg0KU29tZW9uZSBzdWdnZXN0ZWQgdGhhdCBQQVdTIGRlZmluZSBib3RoLCBhbmQgbGV0 IHRoZSB2ZW5kb3JzIGRlY2lkZSB3aGljaCBvbmVzIHRvIGltcGxlbWVudC4NClRoYXQgbWFrZXMg dGhlIG1vc3Qgc2Vuc2UgZm9yIGJvdGggREIgYW5kIGRldmljZSB2ZW5kb3JzLiAgTWFya2V0cyB3 aWxsIHByb2JhYmx5IGRyaXZlIERCIHZlbmRvcnMgdG8gZG8gYm90aC4gRGV2aWNlIHZlbmRvcnMg d2lsbCBkbyB3aGF0IGZpdHMgdGhlIG1hcmtldCBzZWdtZW50IHRoZXkncmUgYWZ0ZXIuIFdoeSBv dmVyLWNvbnN0cmFpbiAob3IgYXJndWUgd2hlbiBuYXR1cmFsIHNlbGVjdGlvbiB3aWxsIHRha2Ug Y2FyZSBvZiBpdCBmb3IgdXM/KS4NCkINCg0KDQpTb3VuZHMgZ29vZCB0byBtZS4NCg0KRnJvbTog cGF3cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWls dG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR2Fib3IuQmFqa29Abm9raWEu Y29tPG1haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb20+DQpTZW50OiBUdWVzZGF5LCBBdWd1c3Qg MjEsIDIwMTIgMTI6NDIgQU0NClRvOiBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmIGlD YWwNCg0KTm93IEkgY2Fu4oCZdCBzZWUgYW55bW9yZSBhbnkgd2lsbGluZ25lc3MgdG8gYWdyZWUg b24gb25lIG9yIHRoZSBvdGhlciBlbmNvZGluZy4NClRvIHByZXZlbnQgZW5kbGVzcyBkaXNjdXNz aW9ucyBvbiB0aGlzIHRvcGljIEnigJlkIHN1Z2dlc3Qgd2UgbW92ZSBmb3J3YXJkIHdpdGggc3Vw cG9ydGluZyBib3RoIGluIHRoZSBEQiBhbmQgZWl0aGVyIG9uZSBpbiB0aGUgbWFzdGVyIGRldmlj ZS4NCkFueSBvYmplY3Rpb25zPw0KDQpHYWJvcg0KDQoNCkZyb206IHBhd3MtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnBhd3MtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBEYXMsIFN1YmlyDQpTZW50OiBNb25kYXksIEF1Z3Vz dCAyMCwgMjAxMiAyOjUwIFBNDQpUbzogRG9uIEpvc2x5bjsgVmluY2VudCBDaGVuOyBXZWl4aW5w ZW5nDQpDYzogcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz47IE1hbmlra290aCBT YWplZXYNClN1YmplY3Q6IFJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQg JiBpQ2FsDQoNCldlIGhhdmUgYSBoYWxmIGEgZG96ZW4gb3IgbW9yZSBUVkRCIHJhZGlvIHZlbmRv cnMgdGhhdCB1c2UvcHJlZmVyIEpTT04gYW5kIHdlIHdpbGwgdm90ZSBmb3IgSlNPTiBpZiB3ZSBo YWQgdG8gcGljayBvbmUuDQpBbHNvIEkgd2lsbCBjb3B5IHRoZSBmb2xsb3dpbmcgdHdvIGltcG9y dGFudCBwb2ludHM6DQoNCg0KICAgICAqICAgU2ltcGxlLXRvLXVzZSBsaWJyYXJpZXMgZXhpc3Qg Zm9yIGFsbCBtYWpvciBsYW5ndWFnZXMvcGxhdGZvcm1zDQogICAgICogICBEb24ndCBuZWVkIGEg dG9vbCBjaGFpbiB0byB3b3JrIHdpdGggdGhlIGRhdGEsIGFzIGlzIHR5cGljYWxseSBuZWVkZWQg Zm9yIFhNTA0KDQoNCg0KRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwYXdzLWJv dW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXTxtYWlsdG86W21h aWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgRG9uIEpvc2x5bg0KU2Vu dDogTW9uZGF5LCBBdWd1c3QgMjAsIDIwMTIgNDo1NCBQTQ0KVG86IFZpbmNlbnQgQ2hlbjsgV2Vp eGlucGVuZw0KQ2M6IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+OyBNYW5pa2tv dGggU2FqZWV2DQpTdWJqZWN0OiBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZD YXJkICYgaUNhbA0KDQpQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGJlbG934oCmDQpUaGFua3MsDQpE b24NCg0KRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwYXdzLWJvdW5jZXNAaWV0 Zi5vcmc+IFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVmluY2Vu dCBDaGVuDQpTZW50OiBNb25kYXksIEF1Z3VzdCAyMCwgMjAxMiAyOjU2IFBNDQpUbzogV2VpeGlu cGVuZw0KQ2M6IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+OyBNYW5pa2tvdGgg U2FqZWV2DQpTdWJqZWN0OiBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJk ICYgaUNhbA0KDQoNCiAgKiAgIE9uZSBvZiBvdXIgZ29hbHMgaXMgdG8gc3RyaXZlIHRvIGxvd2Vy IHRoZSBjb3N0IGFuZCBjb21wbGV4aXR5IGZvciBkZXZpY2UgbWFudWZhY3R1cmVycy4gVGhpcyBs b3dlcnMgdGhlIGJhcnJpZXIgZm9yIGJ1aWxkaW5nIGEgcm9idXN0IGVjb3N5c3RlbS4NCltESiAt IFRoZSDigJxjb3N04oCdIGFuZCBjb21wbGV4aXR5IG9mIHVzaW5nIFhNTCBoYXMgbm90IGJlZW4g YW4gaXNzdWUgZm9yIHRoZSBoYWxmIGRvemVuIFRWQkQgdmVuZG9ycyB0aGF0IGhhdmUgYWxyZWFk eSB1c2VkIFhNTC4gTWF5YmUgd2UgbmVlZCB0byBiZXR0ZXIgZGVmaW5lIOKAnGNvc3TigJ0/XQ0K DQogICogICBUbyByZWR1Y2UgY29tcGxleGl0eSBhbmQgY29zdCBmb3IgZGV2aWNlIG1ha2Vycywg c3VwcG9ydGluZyAxIGVuY29kaW5nIGlzIGJldHRlciB0aGFuIGJvdGgsIGFzIEJyaWFuIHBvaW50 cyBvdXQuIFdpRmkgYWNjZXNzIHBvaW50cyB0aGF0ICJqdXN0IHdvcmsiIGFueXdoZXJlIGluIHRo ZSB3b3JsZCBzZXJ2ZXMgYXMgYSBnb29kIG1vZGVsLg0KW0RKIC0gSSBwcm9wb3NlZCB0aGF0IHRo ZSBkYXRhYmFzZXMgc3VwcG9ydCBib3RoIFhNTCBhbmQgSlNPTiwgZGV2aWNlcyBvbmx5IG5lZWQg dG8gc3VwcG9ydCBvbmUgdG8gdGFsayB0byB0aGUgZGF0YWJhc2UuIE91ciBjdXJyZW50IGRhdGFi YXNlIHN1cHBvcnRzIFhNTCBhbmQgSlNPTiwgYnV0IGlmIEnigJltIGZvcmNlZCB0byBwaWNrIG9u bHkgb25lLCB0aGVuIEkgd2lsbCB2b3RlIGZvciBYTUwgYmVjYXVzZSBpdOKAmXMgdGhlIG9uZSB0 aGF0IHdlIGN1cnJlbnRseSB1c2Ugb24gYWxsIGVtYmVkZGVkIGRldmljZXMuXQ0KDQogICogICBU aGVyZSdzIGEgdHJlbmQgZm9yIEFQSXMgb24gdGhlIHdlYiB0b3dhcmRzIEpTT04gKFR3aXR0ZXIs IEZvdXJTcXVhcmUsIEZhY2Vib29rLCBHb29nbGUsIGV0Yy4pLiBPbmUgb2YgdGhlIG1ham9yIHJl YXNvbnMgaXMgdGhhdCBkZXZlbG9wZXJzIChjbGllbnQtc2lkZSkgcHJlZmVyIGl0IGZvciBpdHMg c2ltcGxpY2l0eToNCg0KICAgICAqICAgUmVwcmVzZW50YXRpb24gY2xvc2VseSBtYXRjaGVzIG1v c3QgZGF0YSBtb2RlbHMgKG5lc3RlZCBsaXN0cyBhbmQgbWFwcykNCiAgICAgKiAgIFNpbXBsZS10 by11c2UgbGlicmFyaWVzIGV4aXN0IGZvciBhbGwgbWFqb3IgbGFuZ3VhZ2VzL3BsYXRmb3Jtcw0K ICAgICAqICAgRG9uJ3QgbmVlZCBhIHRvb2wgY2hhaW4gdG8gd29yayB3aXRoIHRoZSBkYXRhLCBh cyBpcyB0eXBpY2FsbHkgbmVlZGVkIGZvciBYTUwuDQpBcHBhcmVudGx5LCB0aGUgZWZmaWNpZW5j eSBnYWlucyBvZiBKU09OIGFsc28gbWF0dGVyIHRvIHRoZSBzY2FsYWJpbGl0eSBvZiBzZXJ2aW5n IHN5c3RlbXMuDQoNCltESiDigJMgSSBjYW7igJl0IGFyZ3VlIGFnYWluc3QgdGhlc2UgbGlzdGVk IHByb3MgZm9yIEpTT04sIGVzcGVjaWFsbHkgd2hlbiB5b3XigJlyZSBkZWFsaW5nIHdpdGggYSBs b3Qgb2YgZGF0YSAobGlrZSBUd2l0dGVyLCBGb3VyU3F1YXJlLCBGYWNlYm9vayBhbmQgR29vZ2xl IGRvZXMpLiBCdXQgSeKAmW0gYXNzdW1pbmcgdGhhdCBQQVdTIG1lc3NhZ2VzIHdpbGwgbm90IGJl IGV4Y2hhbmdlZCBuZWFybHkgYXMgb2Z0ZW4gYXMgdGhlIGFwcGxpY2F0aW9ucyBtZW50aW9uZWQg YWJvdmUuIEJ1dCBhZ2FpbiwgSSBrbm93IEpTT04gaXMgbW9yZSBlZmZpY2llbnQsIGNhbuKAmXQg YXJndWUgd2l0aCB0aGF0Ll0NCg0KICAqICAgQXQgdGhlIGVuZCBvZiB0aGUgZGF5LCBpdCdzIHRo ZSBkYXRhIG1vZGVsIHRoYXQgbWF0dGVycywgcmF0aGVyIHRoYW4gdGhlIGVuY29kaW5nLiBXZSAo R29vZ2xlKSBhcmUgYWN0dWFsbHkgbmV1dHJhbCBvbiBYTUwgdnMgSlNPTiwgYXMgbG9uZyBhcyB3 ZSdyZSBjbGVhciBvbiB3aGF0IGRldmljZSBtYWtlcnMgd2FudC4gSXQgd291bGQgYmUgZ29vZCB0 byBnZXQgZmVlZGJhY2sgZnJvbSBkZXZpY2UgbWFrZXJzIChlc3BlY2lhbGx5IG9mIGVtYmVkZGVk IGRldmljZXMpIHJlZ2FyZGluZyBleHBlcmllbmNlcyBzdXBwb3J0aW5nIFhNTCB2cyBKU09OLg0K DQpEb24sIGNhbiB5b3UgZWxhYm9yYXRlIG9uIHRoZSB0eXBlcyBvZiBkZXZpY2VzIHRoYXQgYWxy ZWFkeSBzdXBwb3J0IFhNTD8NCg0KW0RKIC0gV2UgY3VycmVudGx5IHN1cHBvcnQgaGFsZiBhIGRv emVuIFRWREIgcmFkaW8gdmVuZG9ycyAoZW1iZWRkZWQgZGV2aWNlcykgdXNpbmcgWE1MLCBub24g dXNpbmcgSlNPTi4gWE1MIGhhcyBub3QgYmVlbiBhIGJ1cmRlbiwgYW5kIHRoZSBhbW91bnQgb2Yg ZGF0YSB0aGF0IG5lZWRzIHRvIGJlIGV4Y2hhbmdlZCBiZXR3ZWVuIGRldmljZSBhbmQgZGF0YWJh c2UgaXMgbm90IHRoYXQgbXVjaCBvciBleGNoYW5nZWQgdGhhdCBvZnRlbi5dDQpPbiBGcmksIEF1 ZyAxNywgMjAxMiBhdCA2OjA2IFBNLCBXZWl4aW5wZW5nIDx3ZWl4aW5wZW5nQGh1YXdlaS5jb208 bWFpbHRvOndlaXhpbnBlbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KQ29uc2lkZXJpbmcgb2YgdGhl IGRlc2lnbiBvZiBkYXRhYmFzZSBkaXNjb3ZlcnkgcHJvdG9jb2wsIHRoZSBMb1NUIHByb3RvY29s IG1heSBiZSB1c2VkIGFuZCBMb1NUIGlzIGJhc2VkIG9uIFhNTCwgc28gSSB0aGluayBYTUwgbWF5 IGJlIHByZWZlcnJlZC4NCg0KLS1YaW5wZW5nIFdlaQ0KDQpGcm9tOiBwYXdzLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpwYXdzLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBSb3Nl biwgQnJpYW4NCg0KU2VudDogRnJpZGF5LCBBdWd1c3QgMTcsIDIwMTIgOToyNiBQTQ0KVG86IE1h bmlra290aCBTYWplZXY7IGdhYm9yLmJhamtvQG5va2lhLmNvbTxtYWlsdG86Z2Fib3IuYmFqa29A bm9raWEuY29tPjsgdmNoZW5AZ29vZ2xlLmNvbTxtYWlsdG86dmNoZW5AZ29vZ2xlLmNvbT47IHBl dGVyQHNwZWN0cnVtYnJpZGdlLmNvbTxtYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tPg0K DQpDYzogcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb cGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJiBpQ2FsDQoNCkkgZG9uJ3QgcmVh bGx5IGNhcmUgd2hldGhlciB3ZSB1c2UganNvbiBvciB4bWwgYXMgYSBtYXR0ZXIgb2YgcHJvdG9j b2wgZGVzaWduIG9yIGltcGxlbWVudGF0aW9uLCBidXQgSSBhbSBhIGJpZyBmYW4gb2YgcmV1c2lu ZyBzdGFuZGFyZHMgcmF0aGVyIHRoYW4gZGVmaW5pbmcgbmV3IG9uZXMsIGFuZCBJIHdvdWxkIG5v dCB3YW50IHRvIHNlZSB0aGUgY2hvaWNlIG9mIGpzb24gbWVhbiB3ZSB0aGVuIGRlY2lkZSB0byBy b2xsIG91ciBvd24gdmVyc3VzIHVzaW5nIGV4aXN0aW5nIHN0YW5kYXJkcyBiYXNlZCBvbiB0aGUg aWRlYSB0aGVyZSBpcyBubyBqc29uIHJlcHJlc2VudGF0aW9uIG9mIGFuIGV4aXN0aW5nIHN0YW5k YXJkLiAgU28sIGlmIGNob29zaW5nIGpzb24gbWVhbnMgZm9sa3MgZmVlbCBmcmVlIHRvIGlnbm9y ZSBleGlzdGluZyB4bWwgYmFzZWQgc3RhbmRhcmRzIHN1Y2ggYXMgeENhcmQgYW5kIExvU1QsIHRo ZW4gSSB3b3VsZCBub3Qgd2FudCB0byB1c2UganNvbi4NCg0KSSB3b3VsZCBwcmVmZXIgdG8gbm90 IGhhdmUgImJvdGgiLCBiZWNhdXNlIG9mIGludGVyb3BlcmFiaWxpdHkgY29tcGxpY2F0aW9ucy4g IElmIHRoZXJlIGlzIHJvdWdoIGNvbnNlbnN1cyBmb3IgYm90aCwgdGhlbiBJIHdvdWxkIGFzc2Vy dCB0aGF0IGFsbCBzZXJ2ZXJzIGhhdmUgdG8gaW1wbGVtZW50IGJvdGggYW5kIHRoZSBjbGllbnQg Y2FuIGltcGxlbWVudCBlaXRoZXIuDQoNClRoZXJlIGFyZSBqc29uIHZhbGlkYXRvcnMsIHNvIEkg ZG9uJ3QgdGhpbmsgdGhhdCBpcyBhIGJpZyBkZWFsLg0KDQpNeSBleHBlcmllbmNlIGluIHByb3Rv Y29sIGRlc2lnbiBvbiB0aGUgSW50ZXJuZXQgaXMgdGhhdCBkZWNpc2lvbnMgbWFkZSBzb2xlbHkg b3IgZXZlbiBsYXJnZWx5IGJlY2F1c2Ugb2YgY29tcGFjdG5lc3MgYWR2YW50YWdlcyByYXJlbHkg YXJlIGdvb2QgY2hvaWNlcy4gIElmIHlvdSBsaWtlIGpzb24gYmVjYXVzZSBpdCBpcyBzbWFsbGVy LCB0aGVuIEkgYmVsaWV2ZSB5b3UgbmVlZCBhIG11Y2ggYmV0dGVyIHJlYXNvbi4gIEJpbmFyeSBk b2Vzbid0IHdvcmsgZm9yIG1lLCBhdCBhbGwuICBJIGhhdmUgYmVlbiBpbnZvbHZlZCBpbiBiaWcg YmluYXJ5IHZzIHRleHQgd2FycyBpbiBwcm90b2NvbCBkZXNpZ24uICBUZXh0IHdpbnMsIGJpbmFy eSBsb3NlcywgaW4gbXkgb3Bpbmlvbi4NCg0KQnJpYW4gPGFzIGluZGl2aWR1YWw+DQoNCkZyb206 IE1hbmlra290aCBTYWplZXYgPG1rc2FqaUB5YWhvby5jb208bWFpbHRvOm1rc2FqaUB5YWhvby5j b20+Pg0KUmVwbHktVG86IE1hbmlra290aCBTYWplZXYgPG1rc2FqaUB5YWhvby5jb208bWFpbHRv Om1rc2FqaUB5YWhvby5jb20+Pg0KRGF0ZTogVGh1LCAxNiBBdWcgMjAxMiAyMjozNzozOCAtMDQw MA0KVG86ICJHYWJvci5CYWprb0Bub2tpYS5jb208bWFpbHRvOkdhYm9yLkJhamtvQG5va2lhLmNv bT4iIDxHYWJvci5CYWprb0Bub2tpYS5jb208bWFpbHRvOkdhYm9yLkJhamtvQG5va2lhLmNvbT4+ LCAiUm9zZW4sIEJyaWFuIiA8YnJpYW4ucm9zZW5AbmV1c3Rhci5iaXo8bWFpbHRvOmJyaWFuLnJv c2VuQG5ldXN0YXIuYml6Pj4sICJ2Y2hlbkBnb29nbGUuY29tPG1haWx0bzp2Y2hlbkBnb29nbGUu Y29tPiIgPHZjaGVuQGdvb2dsZS5jb208bWFpbHRvOnZjaGVuQGdvb2dsZS5jb20+PiwgInBldGVy QHNwZWN0cnVtYnJpZGdlLmNvbTxtYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tPiIgPHBl dGVyQHNwZWN0cnVtYnJpZGdlLmNvbTxtYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tPj4N CkNjOiAicGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4iIDxwYXdzQGlldGYub3Jn PG1haWx0bzpwYXdzQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcGF3c10gWE1MIHNjaGVtYSB2 ZXJzdXMgSlNPTiwgdkNhcmQgJiBpQ2FsDQoNCkhpLA0KDQpDYW4gaXQgbm90IGJlIGJvdGggSlNP TiBhbmQgWE1MIHN1cHBvcnRlZD8gSSB3b3VsZCB2b3RlIGZvciB0aGF0LiBGdXR1cmUgaW1wbGVt ZW50YXRpb25zIG1heSBwcmVmZXIgWE1MIGFzIGl0IGlzIGdlbmVyaWMsIG9tbmkgcHJlc2VudCwg ZWFzeSB0byB1bmRlcnN0YW5kIGFuZCB2YWxpZGF0ZS4gRm9yIGNvbXBhY3RuZXNzIG1heSBiZSBh ICBiaW5hcnkgeG1sIG9wdGlvbmNhbiBhbHNvIHdvcmsuIEpTT04gSSB0aGluayB3aWxsIG5lY2Vz c2l0YXRlIGltcGxlbWVudGF0aW9uIHRvIGJlIG5hdGl2ZSBKYXZhIGFuZCBtYXkgbm90IGJlIGFz IGZyaWVuZGx5IHdpdGggb3RoZXIgaW1wbGVtZW50YXRpb24gbGFuZ3VhZ2VzLg0KDQpCZXN0IFJl Z2FyZHMsDQpTYWplZXYgTWFuaWtrb3RoDQpNb2JpbGU6ICs5MTg3OTIyOTIwMDINCkVtYWlsOiBt a3NhamlAaWVlZS5vcmc8bWFpbHRvOm1rc2FqaUBpZWVlLm9yZz4NCmh0dHA6Ly93d3cubGlua2Vk aW4uY29tL2luL21rc2FqZWV2DQoNCkZyb206ICJHYWJvci5CYWprb0Bub2tpYS5jb208bWFpbHRv OkdhYm9yLkJhamtvQG5va2lhLmNvbT4iIDxHYWJvci5CYWprb0Bub2tpYS5jb208bWFpbHRvOkdh Ym9yLkJhamtvQG5va2lhLmNvbT4+DQpUbzogQnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo8bWFpbHRv OkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PjsgdmNoZW5AZ29vZ2xlLmNvbTxtYWlsdG86dmNoZW5A Z29vZ2xlLmNvbT47IHBldGVyQHNwZWN0cnVtYnJpZGdlLmNvbTxtYWlsdG86cGV0ZXJAc3BlY3Ry dW1icmlkZ2UuY29tPg0KQ2M6IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpT ZW50OiBGcmlkYXksIDE3IEF1Z3VzdCAyMDEyLCA0OjU1DQpTdWJqZWN0OiBSZTogW3Bhd3NdIFhN TCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJkICYgaUNhbA0KDQpXZSBoYXZlIG5vdCBoZWFyZCBh bnkgb2JqZWN0aW9ucyBmb3IgdXNpbmcgSlNPTiBlbmNvZGluZyBpbnN0ZWFkIG9mIFhNTC4NClRo ZXJlZm9yZSwgbGV0J3MgZ28gZm9yIEpTT04sIGFuZCBjbG9zZSB0aGlzIHRocmVhZC4NCg0KLSBH YWJvcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGF3cy1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86cGF3cy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgZXh0 IFJvc2VuLCBCcmlhbg0KU2VudDogTW9uZGF5LCBBdWd1c3QgMTMsIDIwMTIgMzoxNCBQTQ0KVG86 ICdWaW5jZW50IENoZW4nOyAnUGV0ZXIgU3RhbmZvcnRoJw0KQ2M6ICdwYXdzQGlldGYub3JnPG1h aWx0bzpwYXdzQGlldGYub3JnPicNClN1YmplY3Q6IFJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJz dXMgSlNPTiwgdkNhcmQgJiBpQ2FsDQoNCmpzb24gaXMgb2theSB3aXRoIG1lLg0KSSdkIHByZWZl ciBhbiBJU08gdGltZSBzdGFtcCByYXRoZXIgdGhhbiBhIHRpbWUgaW4gc2Vjb25kcyBzaW5jZSBl cG9jaC4gIEl0J3MgdmVyeSBlYXN5IHRvIHBhcnNlLCBhbmQgaXRzIHNpbXBsZXIgdG8gdXNlIGFu ZCBkZWJ1Zy4gIERvbid0IGNhcmUgYSB3aG9sZSBsb3QgYWJvdXQgdGhhdA0KDQpCcmlhbiA8YXMg aW5kaXZpZHVhbD4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAgICAg VmluY2VudCBDaGVuIFttYWlsdG86dmNoZW5AZ29vZ2xlLmNvbTxtYWlsdG86dmNoZW5AZ29vZ2xl LmNvbT5dDQpTZW50OiAgICBNb25kYXksIEF1Z3VzdCAxMywgMjAxMiAwNjowNCBQTSBFYXN0ZXJu IFN0YW5kYXJkIFRpbWUNClRvOiAgICBQZXRlciBTdGFuZm9ydGgNCkNjOiAgICBSb3NlbiwgQnJp YW47IFRlY28gQm9vdDsgQmVuamFtaW4gQS5Sb2xmZTsgcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3 c0BpZXRmLm9yZz4NClN1YmplY3Q6ICAgIFJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNP TiwgdkNhcmQgJiBpQ2FsDQoNClhNTCB2cyBKU09ODQoNCkJldHdlZW4gWE1MIGFuZCBKU09OLCBK U09OIG1lc3NhZ2VzIGFyZSBtb3JlIGNvbXBhY3QgYW5kIGVhc2llciB0byBwcm9jZXNzIChwYXJz aW5nLCBzeW50aGVzaXMpLiBBcyBjbGFyaWZpY2F0aW9uLCBKU09OIGRvZXMgbm90IHJlcXVpcmUg SmF2YVNjcmlwdCBvciBhIEJyb3dzZXIuIEl0IGlzIGEgdGV4dC1iYXNlZCByZXByZXNlbnRhdGlv biBvZiBkYXRhIHRoYXQgaXMgbGFuZ3VhZ2UgaW5kZXBlbmRlbnQsIHlldCB3ZWxsLW1hdGNoZWQg dG8gYWxsIG1ham9yIGxhbmd1YWdlcy4gSlNPTi1oYW5kbGluZyBsaWJyYXJpZXMgZXhpc3QgZm9y IG51bWVyb3VzIGxhbmd1YWdlcyAoc2VlIG9mIGh0dHA6Ly9qc29uLm9yZy8pIGFuZCBzZWVtIHRv IGJlIHJlYXNvbmFibHkgbGlnaHQgd2VpZ2h0Lg0KDQpUaW1lc3RhbXBzDQoNCkFzIGZvciB0aW1l c3RhbXAgc3BlY2lmaWNhdGlvbnMsIHNob3VsZCB3ZSBjb25zaWRlciBqdXN0IHVzaW5nIHNlY29u ZHMgc2luY2UgdGhlIFVOSVggRXBvY2ggKDE5NzAtMDEtMDFUMDA6MDA6MDBaKT8gVGhpcyB3b3Vs ZCBlbGltaW5hdGUgdGhlIG5lZWQgZm9yIGRhdGV0aW1lLXN0cmluZyBwYXJzaW5nIG9uIGRldmlj ZXMsIGFzc3VtaW5nIGRldmljZXMgYWxyZWFkeSBoYXZlIG5hdGl2ZSBsaWJyYXJpZXMgdGhhdCBw cm92aWRlIHRpbWUgaW4gdGhpcyBmb3JtYXQuIElzIHRoYXQgYSB2YWxpZCBhc3N1bXB0aW9uPyBP ZiBjb3Vyc2UsIHRoaXMgaXMgbGVzcyBodW1hbi1yZWFkYWJsZS4uLi4NCg0KDQpPbiBNb24sIEF1 ZyAxMywgMjAxMiBhdCA2OjQ5IEFNLCBQZXRlciBTdGFuZm9ydGggPHBldGVyQHNwZWN0cnVtYnJp ZGdlLmNvbTxtYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tPj4gd3JvdGU6DQoNCg0KICAg IFdoZW5ldmVyIHdlIGJ1aWx0IG1vYmlsZSBkZXZpY2VzIHdlIG5ldmVyIGRlYWx0IHdpdGggSUVU RiwgaW4gb3VyIHNlbnNvcg0KICAgIGRheXMgZXZlbiBhbiBJUCBzdGFjayB3YXMgYSBjaGFsbGVu Z2Usc28gSSB3b3VsZCBkZWZlciB0byB0aGUgZGV2aWNlIGd1eXMNCiAgICBvbiB0aGF0IG9uZS4N Cg0KICAgIE9uIE1vbkF1Zy8xMy8xMiBNb24gQXVnIDEzLCA5OjMwIEFNLCAiUm9zZW4sIEJyaWFu Ig0KDQogICAgPEJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PG1haWx0bzpCcmlhbi5Sb3NlbkBuZXVz dGFyLmJpej4+IHdyb3RlOg0KDQogICAgPk91ciBleHBlcmllbmNlIGluIHRoZSBJRVRGIG92ZXIg bWFueSB5ZWFycyBpcyB0aGF0IGVjb25vbWl6aW5nIG1lc3NhZ2UNCiAgICA+c2l6ZSBhbmQgY29t cHJvbWlzaW5nIHV0aWxpdHkgYW5kIHNlY3VyaXR5IGluIHNlYXJjaCBvZiBlZmZpY2llbmN5IG9m DQogICAgPmltcGxlbWVudGF0aW9uIG9uIHNtYWxsIGRldmljZXMgaXMgYSBwb29yIHRyYWRlIG9m Zi4gIEkgYW0gbm90IGFkdm9jYXRpbmcNCiAgICA+YmVpbmcgd2FzdGVmdWwgb2YgcmVzb3VyY2Vz LCBidXQgSSBkb24ndCB0aGluayB3ZSBzaG91bGQgc2VyaW91c2x5DQogICAgPmNvbnNpZGVyIHRo ZSBvdmVyaGVhZCBvZiBYTUwgb3IganNvbiB0byBiZSBzaWduaWZpY2FudC4NCiAgICA+DQogICAg PkFzc3VtaW5nIGEganNvbiBsaWJyYXJ5IGNhbiBiZSBsb2FkZWQgb24gYSBzbWFsbCBkZXZpY2Ug aXMgcmVhc29uYWJsZS4NCiAgICA+DQogICAgPkJyaWFuIChhcyBpbmRpdmlkdWFsKQ0KICAgID4N CiAgICA+DQogICAgPg0KICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICA+RnJv bTogIFBldGVyIFN0YW5mb3J0aCBbbWFpbHRvOnBldGVyQHNwZWN0cnVtYnJpZGdlLmNvbTxtYWls dG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tPl0NCiAgICA+U2VudDogIFNhdHVyZGF5LCBBdWd1 c3QgMTEsIDIwMTIgMDc6MTMgQU0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQogICAgPlRvOiAgICBU ZWNvIEJvb3Q7IEJlbmphbWluIEEuUm9sZmUNCiAgICA+Q2M6ICAgIHBhd3NAaWV0Zi5vcmc8bWFp bHRvOnBhd3NAaWV0Zi5vcmc+DQogICAgPlN1YmplY3Q6ICAgICAgUmU6IFtwYXdzXSBYTUwgc2No ZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmIGlDYWwNCiAgICA+DQogICAgPk5vdCBhbGwgbWFzdGVy cyBydW4gb3ZlciB0aGUgY29yZSBuZXR3b3JrLg0KICAgID5Tb21lIG9mIHRoZSBVc2UgY2FzZXMg aGF2ZSBhIG1hc3RlciB0YWxraW5nIHRvIGFub3RoZXIgT1RBDQogICAgPldlIHNob3VsZCBub3Qg YXNzdW1lIHRoYXQgYWxsIE1hc3RlcnMgYXJlIGF0dGFjaGVkIHRvIHV0aWxpdHkgcG93ZXIgc28g d2UNCiAgICA+c2hvdWxkIGJlIHN5bXBhdGhldGljIHRvIHByb2Nlc3NpbmcgZW5lcmd5IHVzZSBh bHNvLg0KICAgID4NCiAgICA+T24gU2F0QXVnLzExLzEyIFNhdCBBdWcgMTEsIDU6MzAgQU0sICJU ZWNvIEJvb3QiIDx0ZWNvQGluZi1uZXQubmw8bWFpbHRvOnRlY29AaW5mLW5ldC5ubD4+IHdyb3Rl Og0KICAgID4NCiAgICA+Pg0KICAgID4+T3AgMTAgYXVnLiAyMDEyLCBvbSAxODoxMCBoZWVmdCBC ZW5qYW1pbiBBLiBSb2xmZSBoZXQgdm9sZ2VuZGUNCiAgICA+Pmdlc2NocmV2ZW46DQogICAgPj4N CiAgICA+Pj4gQ29tcGFjdG5lc3Mgb2YgbWVzc2FnZXMgaXMgaW1wb3J0YW50LCBidXQgaXQgaXMg YWxzbyBpbXBvcnRhbnQgKHRvIG1lDQogICAgPj4+YXQgbGVhc3QpIHRvIGJlIHJlYWxpemFibGUg aW4gYW4gaW1wbGVtZW50YXRpb24gd2l0aCBsaW1pdGVkIHJlc291cmNlcywNCiAgICA+Pj5zdWNo IGFzIGVtYmVkZGVkIGRldmljZXMgaW4gd2hhdCBhcmUgbm93IHBvcHVsYXJseSBjYWxsZWQgIk0y TSINCiAgICA+Pj5hcHBsaWNhdGlvbnMuICBBIGxvdCBvZiB0aGVzZSBkZXZpY2VzIGNvdWxkIHVz ZSBJUCBhbGwgdGhlIGVuZCB0byBlbmQsDQogICAgPj4+YnV0IG1heSBoYXZlIGEgdmVyeSBjb21w YWN0LCBzaW1wbGUgc3RhY2sgYW5kIGFwcGxpY2F0aW9ucyAoaS5lLiAgbm8NCiAgICA+Pj5icm93 c2VyKS4gIElzIEpTT04gdHlwaWNhbGx5IGltcGxlbWVudGVkIHdoZW4gdGhlcmUgaXMgbm8gYnJv d3Nlcj8NCiAgICA+Pj5Xb3VsZCBpdCBiZSBoYXJkIHRvIGRvIGluIGEgcmVzb3VyY2UgY29uc3Ry YWluZWQgZGV2aWNlIChpLmUuIHdoZXJlIHdlDQogICAgPj4+dGFsayBhYm91dCBtZW1vcnkgc2l6 ZSBpbiBLaWxvLWJ5dGVzIHN0aWxsKS4NCiAgICA+Pg0KICAgID4+SW4gdXNlIGNhc2VzIGFuZCBy ZXF1aXJlbWVudHMgZG9jdW1lbnQsIHRoZXJlIGFyZSBubyByZXF1aXJlbWVudHMgZm9yDQogICAg Pj5wcm90b2NvbCBwZXJmb3JtYW5jZS4gSSBndWVzcyBPUy9JUC9UQ1AvVExTIGNvZGUgc2l6ZSBz dXBlcnNlZGVzIG5lZWRzDQogICAgPj5mb3IgSlNPTiBvciBYTUwuDQogICAgPj4NCiAgICA+PlNh bWUgZm9yIHRpbWluZzogVENQL1RMUyBjb25uZWN0aW9uIHNldHVwIHdpbGwgdGFrZSBtb3JlIHRo YW4gdGhlIFBBV1MNCiAgICA+Pm1lc3NhZ2UgZXhjaGFuZ2UsIEkgdGhpbmsuIFRoaXMgbWF5IGJl IG9mIGltcG9ydGFuY2Ugd2hlbiB1c2luZyBzYXRjb20NCiAgICA+PmxpbmtzLg0KICAgID4+DQog ICAgPj5CZWNhdXNlIFBBV1MgcnVucyBiZXR3ZWVuIG1hc3RlciBhbmQgZGF0YWJhc2UsIG92ZXIg Y29yZSBuZXR3b3JrLA0KICAgID4+cGVyZm9ybWFuY2UgaXMgbm90IG91ciBwcmltYXJ5IGNvbmNl cm4uIEJ1dCBhcyBhbHdheXMsIGl0IGlzIGdvb2QgdG8ga2VlcA0KICAgID4+YW4gZXllIG9uIGVm ZmljaWVuY3kuDQogICAgPj4NCiAgICA+PlRlY28NCiAgICA+Pg0KICAgID4+PiBUaGFua3MNCiAg ICA+Pj4gQmVuDQogICAgPj4+DQogICAgPj4+DQogICAgPj4+PiBXZSBoYWQgYSBkaXNjdXNzaW9u IG9uIFhNTCB2cy4gSlNPTi4gSSBwcmVmZXIgdGhlIG9uZSB3aXRoIG1vc3QNCiAgICA+Pj4+Y29t cGFjdCBtZXNzYWdlcy4NCiAgICA+Pj4+DQogICAgPj4+PiBPbiB2Q2FyZCBhbmQgSlNPTjogd2hh dCBpcyB0aGUgc3RhdHVzIG9mICJBIEphdmFTY3JpcHQgT2JqZWN0IE5vdGF0aW9uDQogICAgPj4+ PihKU09OKSBSZXByZXNlbnRhdGlvbiBmb3IgdkNhcmQiPw0KICAgID4+Pj4gaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYmhhdC12Y2FyZGRhdi1qc29uLTAwDQogICAgPj4+Pg0KICAg ID4+Pj4gT24gdmFsaWQgdGltZXM6IGNhbiB3ZSB1c2Ugc2FtZSBmb3JtYXQgYXMgY2VydGlmaWNh dGVzPyBUaGV5IGhhdmUNCiAgICA+Pj4+c2ltaWxhciBzaW1wbGUgcmVxdWlyZW1lbnRzOiB2YWxp ZCBub3RCZWZvcmUmICBub3RBZnRlci4NCiAgICA+Pj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzMyODAjc2VjdGlvbi00LjEuMi41DQogICAgPj4+Pg0KICAgID4+Pj4gVGVjbw0KICAg ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICA+Pj4+IHBhd3MgbWFpbGluZyBsaXN0DQogICAgPj4+PiBwYXdzQGlldGYub3JnPG1haWx0bzpw YXdzQGlldGYub3JnPg0KICAgID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9wYXdzDQogICAgPj4+Pg0KICAgID4+Pg0KICAgID4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+PiBwYXdzIG1haWxpbmcgbGlzdA0K ICAgID4+PiBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KICAgID4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCiAgICA+Pg0KICAgID4+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+PnBhd3Mg bWFpbGluZyBsaXN0DQogICAgPj5wYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0K ICAgID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQogICAgPg0K ICAgID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAg ID5wYXdzIG1haWxpbmcgbGlzdA0KICAgID5wYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYu b3JnPg0KICAgID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg0K ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAg cGF3cyBtYWlsaW5nIGxpc3QNCiAgICBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3Jn Pg0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQoNCg0K DQoNCi0tDQotdmluY2UNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnBhd3MgbWFpbGluZyBsaXN0DQpwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGF3cyBtYWlsaW5n IGxpc3QNCnBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg0KDQoNCi0tDQotdmluY2UNCg0KDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpwYXdz IG1haWxpbmcgbGlzdA0KDQpwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBhd3MgbWFpbGluZyBsaXN0DQpw YXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCnBhd3MgbWFpbGluZyBsaXN0DQoNCnBhd3NAaWV0Zi5v cmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcGF3cw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KcGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBhd3Mg bWFpbGluZyBsaXN0DQpwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg== --_000_AAC987F0CC2C7845A9FBD8A36D52E12D968577rrcatsexmb1_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0 ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLnlp djE4MDE1Mzk0MjFtc29hY2V0YXRlLCBsaS55aXYxODAxNTM5NDIxbXNvYWNldGF0ZSwgZGl2Lnlp djE4MDE1Mzk0MjFtc29hY2V0YXRlDQoJe21zby1zdHlsZS1uYW1lOnlpdjE4MDE1Mzk0MjFtc29h Y2V0YXRlOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLnlp djE4MDE1Mzk0MjFtc29saXN0cGFyYWdyYXBoLCBsaS55aXYxODAxNTM5NDIxbXNvbGlzdHBhcmFn cmFwaCwgZGl2LnlpdjE4MDE1Mzk0MjFtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1l OnlpdjE4MDE1Mzk0MjFtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpwLnlpdjE4MDE1Mzk0MjFtc29ub3JtYWwsIGxpLnlpdjE4MDE1 Mzk0MjFtc29ub3JtYWwsIGRpdi55aXYxODAxNTM5NDIxbXNvbm9ybWFsDQoJe21zby1zdHlsZS1u YW1lOnlpdjE4MDE1Mzk0MjFtc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCnAueWl2MTgwMTUzOTQyMW1zb2NocGRlZmF1bHQsIGxpLnlpdjE4MDE1 Mzk0MjFtc29jaHBkZWZhdWx0LCBkaXYueWl2MTgwMTUzOTQyMW1zb2NocGRlZmF1bHQNCgl7bXNv LXN0eWxlLW5hbWU6eWl2MTgwMTUzOTQyMW1zb2NocGRlZmF1bHQ7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4ueWl2MTgwMTUzOTQyMW1zb2h5cGVybGlu aw0KCXttc28tc3R5bGUtbmFtZTp5aXYxODAxNTM5NDIxbXNvaHlwZXJsaW5rO30NCnNwYW4ueWl2 MTgwMTUzOTQyMW1zb2h5cGVybGlua2ZvbGxvd2VkDQoJe21zby1zdHlsZS1uYW1lOnlpdjE4MDE1 Mzk0MjFtc29oeXBlcmxpbmtmb2xsb3dlZDt9DQpzcGFuLnlpdjE4MDE1Mzk0MjFodG1scHJlZm9y bWF0dGVkY2hhcg0KCXttc28tc3R5bGUtbmFtZTp5aXYxODAxNTM5NDIxaHRtbHByZWZvcm1hdHRl ZGNoYXI7fQ0Kc3Bhbi55aXYxODAxNTM5NDIxYmFsbG9vbnRleHRjaGFyDQoJe21zby1zdHlsZS1u YW1lOnlpdjE4MDE1Mzk0MjFiYWxsb29udGV4dGNoYXI7fQ0Kc3Bhbi55aXYxODAxNTM5NDIxZW1h aWxzdHlsZTIzDQoJe21zby1zdHlsZS1uYW1lOnlpdjE4MDE1Mzk0MjFlbWFpbHN0eWxlMjM7fQ0K c3Bhbi55aXYxODAxNTM5NDIxZW1haWxzdHlsZTI1DQoJe21zby1zdHlsZS1uYW1lOnlpdjE4MDE1 Mzk0MjFlbWFpbHN0eWxlMjU7fQ0KcC55aXYxODAxNTM5NDIxbXNvbm9ybWFsMSwgbGkueWl2MTgw MTUzOTQyMW1zb25vcm1hbDEsIGRpdi55aXYxODAxNTM5NDIxbXNvbm9ybWFsMQ0KCXttc28tc3R5 bGUtbmFtZTp5aXYxODAxNTM5NDIxbXNvbm9ybWFsMTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYxODAxNTM5NDIxbXNvaHlwZXJsaW5rMQ0KCXtt c28tc3R5bGUtbmFtZTp5aXYxODAxNTM5NDIxbXNvaHlwZXJsaW5rMTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi55aXYxODAxNTM5NDIxbXNvaHlwZXJs aW5rZm9sbG93ZWQxDQoJe21zby1zdHlsZS1uYW1lOnlpdjE4MDE1Mzk0MjFtc29oeXBlcmxpbmtm b2xsb3dlZDE7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cC55aXYxODAxNTM5NDIxbXNvYWNldGF0ZTEsIGxpLnlpdjE4MDE1Mzk0MjFtc29hY2V0YXRlMSwg ZGl2LnlpdjE4MDE1Mzk0MjFtc29hY2V0YXRlMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxODAxNTM5 NDIxbXNvYWNldGF0ZTE7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO30NCnAu eWl2MTgwMTUzOTQyMW1zb2xpc3RwYXJhZ3JhcGgxLCBsaS55aXYxODAxNTM5NDIxbXNvbGlzdHBh cmFncmFwaDEsIGRpdi55aXYxODAxNTM5NDIxbXNvbGlzdHBhcmFncmFwaDENCgl7bXNvLXN0eWxl LW5hbWU6eWl2MTgwMTUzOTQyMW1zb2xpc3RwYXJhZ3JhcGgxOw0KCW1hcmdpbi10b3A6MGluOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4ueWl2MTgwMTUzOTQyMWh0bWxw cmVmb3JtYXR0ZWRjaGFyMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxODAxNTM5NDIxaHRtbHByZWZv cm1hdHRlZGNoYXIxOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4ueWl2MTgwMTUzOTQy MWJhbGxvb250ZXh0Y2hhcjENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTgwMTUzOTQyMWJhbGxvb250 ZXh0Y2hhcjE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi55aXYx ODAxNTM5NDIxZW1haWxzdHlsZTIzMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxODAxNTM5NDIxZW1h aWxzdHlsZTIzMTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4ueWl2MTgwMTUzOTQyMWVtYWlsc3R5bGUyNTENCgl7bXNvLXN0eWxlLW5h bWU6eWl2MTgwMTUzOTQyMWVtYWlsc3R5bGUyNTE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpwLnlpdjE4MDE1Mzk0MjFtc29jaHBkZWZhdWx0 MSwgbGkueWl2MTgwMTUzOTQyMW1zb2NocGRlZmF1bHQxLCBkaXYueWl2MTgwMTUzOTQyMW1zb2No cGRlZmF1bHQxDQoJe21zby1zdHlsZS1uYW1lOnlpdjE4MDE1Mzk0MjFtc29jaHBkZWZhdWx0MTsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYxODAx NTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOnlpdjE4MDE1Mzk0 MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlNDENCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDo1ODE5ODc1MzM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTU3Nzgx NTcwO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDENCgl7 bXNvLWxpc3QtaWQ6NjEwMDg3MjExOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMzI1Nzc0MDY7 fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0KCXttc28t bGlzdC1pZDo2NDMwNTA0ODk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0MzA3ODQ5MzA7fQ0K QGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMw0KCXttc28tbGlz dC1pZDoxMjIwNjczNTUwOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMTAyNTQ2NjE0O30NCkBs aXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDoxNTIwNTc4OTc2Ow0KCW1zby1saXN0LXRl bXBsYXRlLWlkczo2MDY3Nzc1NzY7fQ0KQGxpc3QgbDQ6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsNDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw1DQoJe21zby1saXN0LWlk OjIxMzY2NzYyODE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODAyNTAxNjMwO30NCkBsaXN0 IGw1OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JdCB3b3VsZCBiZSBnb29kIGlmIHlvdSBjYW4gcHJvdmlkZSBzb21lIHNwZWNp ZmljIGV4YW1wbGVzIHdoZXJlIEpTT04gaXMgcHJvYmxlbWF0aWMgYnV0IFhNTCBpcyBlYXNpZXIu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPi1TdWJpcg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcGF3cy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5NYW5pa2tvdGggU2FqZWV2PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXVndXN0IDI0LCAy MDEyIDExOjE0IFBNPGJyPg0KPGI+VG86PC9iPiBHYWJvci5CYWprb0Bub2tpYS5jb207IEJyaWFu LlJvc2VuQG5ldXN0YXIuYml6OyBiZW5AYmxpbmRjcmVlay5jb208YnI+DQo8Yj5DYzo8L2I+IHBh d3NAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZl cnN1cyBKU09OLCB2Q2FyZCAmYW1wOyBpQ2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSB3b3VsZCBzdGlsbCBzdXBwb3J0 IFhNTC4gSlNPTiBsaWJyYXJpZXMgYXJlIGF2YWlsYWJsZSBmb3IgYWxsIGxhbmd1YWdlcy4gQnV0 IGludGVyZmFjaW5nIGFuZCBsaW5raW5nIHN1Y2ggbGlicmFyaWVzIGFyZSBwcm9ibGVtYXRpYyBv biBlbWJlZGRlZCBkZXZpY2VzIG1vc3Qgb2YgdGhlIHRpbWUuIEFuZCBpZiBhbiBpbXBsZW1lbnRh dGlvbiB2b3VjaCBmb3IgbXVsdGlwbGUNCiBzdWNoIG5vbiBuYXRpdmUgbGFuZ3VhZ2UgbGlicmFy aWVzIHRoZW4gZGV2ZWxvcGVycyBsaWZlIGlzIGhlbGwuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDAwMDAiPkJlc3QgUmVnYXJkcyw8L3Nw YW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojQzAwMDAwIj5TYWplZXYgTWFuaWtrb3RoPC9z cGFuPjwvaT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4gJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOkdhYm9yLkJhamtvQG5va2lhLmNvbSI+R2Fib3Iu QmFqa29Abm9raWEuY29tPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86R2Fib3IuQmFq a29Abm9raWEuY29tIj5HYWJvci5CYWprb0Bub2tpYS5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6Ij5Ccmlhbi5Sb3NlbkBu ZXVzdGFyLmJpejwvYT47IDxhIGhyZWY9Im1haWx0bzpiZW5AYmxpbmRjcmVlay5jb20iPg0KYmVu QGJsaW5kY3JlZWsuY29tPC9hPiA8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpwYXdz QGlldGYub3JnIj5wYXdzQGlldGYub3JnPC9hPiA8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXks IDI1IEF1Z3VzdCAyMDEyLCAwOjM4PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcGF3c10gWE1M IHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJmFtcDsgaUNhbDwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBpZD0ieWl2MTgwMTUzOTQyMSI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+ V2lGaSB3b3JsZCBidWlsZHMgb24gbWFuZGF0aW5nIHRoZSBpbXBsZW1lbnRhdGlvbiAoYW5kIGNl cnRpZmljYXRpb24pIG9mIGEgYmFzZSBzcGVjLCBhbmQgYSBzZXQgb2Ygb3B0aW9uYWwgZmVhdHVy ZXMuIElmIGFuIG9wdGlvbmFsIGZlYXR1cmUgaXMgbm90IHN1cHBvcnRlZCBieSBvbmUgb2YNCiB0 aGUgcGVlcnMsIHRoZXkgY2FuIHN0aWxsIHRhbGssIGJ1dCBub3QgdXNlIHRoYXQgZmVhdHVyZS4g VGhhdCBpcyBiYXNpY2FsbHkgb3B0aW9uIEIpIGZyb20gQnJhaW7igJlzIGxpc3QuPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5J4oCZZCBsaWtlIHRvIHN1Z2dl c3QgdGhhdCB3ZSByZWNvZ25pemUgdGhhdCBvcHRpb24gQSkgYW5kIEIpIGFyZSB2YWxpZCBvcHRp b25zLCB3aGlsZSBvcHRpb24gQykgaXMgaW52YWxpZCwgYW5kIHdlIHNob3VsZCBzdG9wIGRlYmF0 aW5nIGl0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5J 4oCZZCBhbHNvIGxpa2UgdG8gYWRkIHRoZSBvYnZpb3VzIG9wdGlvbiBEKSB0byB0aGUgbGlzdCwg d2hpY2ggaXMgdGhhdCBib3RoIHRoZSBtYXN0ZXIgZGV2aWNlcyBhbmQgREJzIHN1cHBvcnQgb25l IGFuZCB0aGUgc2FtZSBlbmNvZGluZyA7KTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzFGNDk3RCI+T3B0aW9uIEEpIHNlZW1zIHRvIGJlIGxpa2UgYSBnb29kIGNvbXByb21p c2UsIGFuZCB3b3VsZCBjdXQgZGlzY3Vzc2lvbnMgc2hvcnQsIHdpdGggdGhlIG9ubHkgY2F2ZWF0 IHRoYXQgaWYgdGhlcmUgaXMgbm8gc3Ryb25nIHRlY2huaWNhbCBhcmd1bWVudCBmb3Igc3VwcG9y dGluZyBhbmQgc3BlY2lmeWluZw0KIHR3byBkaWZmZXJlbnQgZW5jb2RpbmdzLCB0aGVuIHRoZSBp ZXNnIG1heSBzZW5kIHRoZSBkb2N1bWVudCBiYWNrIHRvIHRoZSB3ZyB0byBwaWNrIG9uZSBvZiB0 aGUgdHdvIHNwZWNpZmllZC4gQXMgUm9iZXJ0IG1lbnRpb25lZCBpbiBoaXMgZW1haWwsIHRoaXMg aGFzIGhhcHBlbmVkIGluIHRoZSBwYXN0LCBzbyBpdCBpcyBsaWtlbHkgaXQgd291bGQgaGFwcGVu IGFnYWluLiBBbmQgZnJhbmtseSwgSSBkbyBub3Qgc2VlIGEgc3Ryb25nIGFyZ3VtZW50DQogaW4g ZmF2b3Igb2YgdHdvIGRpZmZlcmVudCBlbmNvZGluZ3MuIDwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+SXMgdGhlcmUgYW55b25lIHdobyBoYXMgYSB0ZWNobmlj YWwgYXJndW1lbnQgYWdhaW5zdCBzdXBwb3J0aW5nIG9ubHkgb25lIGVuY29kaW5nLCBiZWluZyB0 aGF0IGVpdGhlciB4bWwgb3IganNvbj88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOiMxRjQ5N0QiPk1vc3QgcGVvcGxlIHNwZWFrIGluIGZhdm9yIG9mIEpTT04sIGJlY2F1c2Ug aXQgaXMgY29tcGFjdCBhbmQgbW9yZSBlZmZpY2llbnQuIEkgd2VudCB0aHJvdWdoIHRoaXMgdGhy ZWFkIGFuZCBJIHNhdyAyIG9iamVjdGlvbnMgYWdhaW5zdCBwaWNraW5nIEpTT04uIE9uZSBzYWlk IHRoYXQgSlNPTg0KIHJlcXVpcmVzIG5hdGl2ZSBKYXZhLCB3aGljaCBpcyB3cm9uZywgdGhlIG90 aGVyIG9iamVjdGlvbiBnYXZlIG5vIHJlYWwgcmVhc29uLiBTbyBJIGFtIHdvbmRlcmluZyBpZiB0 aGVyZSBpcyByZWFsbHkgYW55IHZhbGlkIHRlY2huaWNhbCByZWFzb24gYWdhaW5zdCB1c2luZyBK U09OIG9ubHk/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4t Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdh Ym9yPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdp bmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6Y3Vy cmVudENvbG9yIGN1cnJlbnRDb2xvciI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Y29sb3I6YmxhY2siPg0KPGEgaHJlZj0ibWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZyI+cGF3 cy1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOnBhd3MtYm91bmNlc0BpZXRm Lm9yZyI+bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPmV4dCBSb3NlbiwgQnJpYW48YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBdWd1c3QgMjQs IDIwMTIgMTA6NDMgQU08YnI+DQo8Yj5Ubzo8L2I+IEJlbmphbWluIEEuIFJvbGZlPGJyPg0KPGI+ Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyI+cGF3c0BpZXRmLm9yZzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2 Q2FyZCAmYW1wOyBpQ2FsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPk9rYXk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNvLCBJIGltcGxlbWVudCBhIGRhdGFi YXNlLCBhbmQgSSBpbXBsZW1lbnQgWE1MPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+WW91IGltcGxlbWVudCBhIGRldmlj ZSwgYW5kIHlvdSBpbXBsZW1lbnQgSlNPTjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPllv dSBxdWVyeSBteSBkYXRhYmFzZSAobGV0J3Mgbm90IGdldCBpbnRvIGhvdyB5b3UgZG8gdGhhdCBx dWVyeSB3aXRob3V0IGRlY2lkaW5nIFhNTCB2cyBKU09OKSBhbmQgZGlzY292ZXIgSSBpbXBsZW1l bnQgWE1MIG9ubHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5XaGF0IGRvIHlvdSBkbz88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5CcmlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+T24gQXVnIDI0LCAyMDEyLCBhdCAxOjM4IFBNLCAmcXVvdDtC ZW5qYW1pbiBBLiBSb2xmZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlbkBibGluZGNyZWVr LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJlbkBibGluZGNyZWVrLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlRoZXJlIGFyZSB0d28gd2F5cyB0byBhY2hpZXZlIGludGVyb3BlcmFiaWxpdHkgd2hlbiB5b3Ug aGF2ZSBhbiBvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlcmUgYXJlIG1hbnkgZXhpc3RlbmNl IHByb29mcyBvZiB0aGUgdGhpcmQgd2F5IHRoYXQgSSBtZW50aW9uZWQgYmVsb3cuPGJyPg0KODAy LjExICYjNDM7IFdpRmkgcHJvdmlkZSBtYW55IG9wdGlvbnMgYW5kIGEgbWVhbnMgZm9yIGRldmlj ZXMgdG8gc2hhcmUgaW5mb3JtYXRpb24gYWJvdXQgd2hhdCBvcHRpb25zIGVhY2ggc3VwcG9ydHMs IHdpdGhvdXQgcmVxdWlyaW5nIHRoYXQgYW55IGRldmljZSBpbXBsZW1lbnQgZXZlcnkgb3B0aW9u LiZuYnNwOyBJdCB3b3Jrcy4mbmJzcDsNCjxicj4NCjxicj4NClRoYXQgc2FpZCwgSSB0aGluayAo QSkgaXMgdGhlIGJlc3QgY2hvaWNlLCAoQikgaXMgbm90IGFzIG5pY2UgZm9yIG1lLCBhbmQgKEMp IGlzIG1vcmUgd29yayB0aGFuIGVpdGhlciBvZiB0aGUgb3RoZXIgdHdvLjxicj4NCiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5PbmUgaXMgdGhhdCBvbmUgZW5kIGltcGxlbWVudHMgYm90aCBj aG9pY2VzIGFuZCB0aGUgb3RoZXIgZW5kIGltcGxlbWVudHMgb25lIG9yIGJvdGguPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIG90aGVyIGlzIHRoYXQgYm90aCBlbmRzIGltcGxlbWVu dCBvbmUgc3BlY2lmaWMgY2hvaWNlICgmcXVvdDtNVVNUIGltcGxlbWVudCZxdW90OykgYW5kIGJv dGggY2FuIG9wdGlvbmFsbHkgaW1wbGVtZW50IHRoZSBvdGhlciBjaG9pY2UuICZuYnNwO09ubHkg aWYgYm90aCBlbmRzIGltcGxlbWVudCB0aGUgb3RoZXIgY2hvaWNlIHdvdWxkIHRoYXQNCiBiZSBh dmFpbGFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U28sIGluIHRoaXMgY2FzZSB3 ZSBjb3VsZCBkbyBvbmUgb2YgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BKSBEYXRhYmFzZXMg aW1wbGVtZW50IGJvdGggWE1MIGFuZCBKU09OLCBkZXZpY2VzIGltcGxlbWVudCBlaXRoZXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5CKSBCb3RoIERhdGFiYXNlcyBhbmQgZGV2aWNlcyBpbXBsZW1lbnQgb25lIChzYXkg WE1MKSBhbmQgb3B0aW9uYWxseSBpbXBsZW1lbnQgdGhlIG90aGVyIChzYXkgSlNPTik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Zb3UgYXJlIGFkdm9jYXRpbmcgZm9yIEEsIFJpY2hhcmQg d2FzIHN1Z2dlc3RpbmcgQi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JIGRvbid0IGNh cmUsIGJ1dCBjaG9pY2UgQykgQm90aCBkYXRhYmFzZXMgYW5kIGRldmljZXMgaGF2ZSBhIGNob2lj ZSBvZiB3aGF0IHRvIGltcGxlbWVudCBkb2Vzbid0IHdvcmsgZm9yIG1lIChvciBSaWNoYXJkKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5CcmlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+T24gQXVnIDI0LCAyMDEyLCBhdCAxMjo1NyBQTSwgQmVuamFt aW4gQS4gUm9sZmUgJmx0OzxhIGhyZWY9Im1haWx0bzpiZW5AYmxpbmRjcmVlay5jb20iIHRhcmdl dD0iX2JsYW5rIj5iZW5AYmxpbmRjcmVlay5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7 YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BcHBhcmVudGx5IEkg d2FzIHVuY2xlYXIuJm5ic3A7IEkgY2VydGFpbmx5IGFuIGNhcGFibGUgb2YgYmVpbmcgd3Jvbmcg YXMgSSBwcmFjdGljZSBvZnRlbiwgYnV0IGluIHRoaXMgY2FzZSBpdCBpcyBxdWl0ZSB1bmxpa2Vs eSA6LSkuDQo8YnI+DQo8YnI+DQpZb3UgZG8gbm90IG5lZWQgdG8gY2hvb3NlIG9ubHkgb25lIGZv cm0gdG8gYWNoaWV2ZSBpbnRlcm9wZXJhYmlsaXR5LiZuYnNwOyZuYnNwOyBJZiB5b3UgaGF2ZSB0 d28sIGxldCB0aGUgZGV2aWNlIGltcGxlbWVudGVyIGZpZ3VyZSBvdXQgd2hpY2ggaXMgYmVzdCBm b3IgdGhlaXIgcGFydGljdWxhciBkZXZpY2UgcmVxdWlyZW1lbnRzIGFuZCB0cmFkZS1vZmZzLiZu YnNwOyBUaGlzIGlzICpwcmVmZXJhYmxlKiBmcm9tIG15IHBlcnNwZWN0aXZlLjxicj4NCjxicj4N CklmIHlvdSBwcm92aWRlIG1vcmUgdGhhbiBvbmUgZm9ybSBpbiB0aGUgZGF0YWJhc2UsIGRldmlj ZXMgdXNpbmcgdGhlIGRhdGFiYXNlIG5lZWQgc29tZSBtZWFucyBmb3IgZmlndXJpbmcgb3V0IHdo aWNoIGFyZSBhdmFpbGFibGUuIEl0IGNhbid0IHVzZSBpdCBpZiBpdCBkb2Vzbid0IG5vIGFib3V0 IGl0LiBUaGlzIGlzIGFuIG9ic2VydmF0aW9ucywgbm90IGFuIGFyZ3VtZW50IDstKS4mbmJzcDsm bmJzcDsNCjxicj4NCjxicj4NCkl0IGlzIG15ICpvcGluaW9uKiBhdCB0aGUmbmJzcDsgbW9tZW50 IHRoYXQgaWYgeW91IHByb3ZpZGUgb3B0aW9ucywgdG8gbWFrZSB0aG9zZSB1c2VmdWwgeW91IG5l ZWQgdG8gcHJvdmlkZSZuYnNwOyBhIHByb3RvY29sIGJ5IHdoaWNoIGRldmljZXMgY2FuIGRpc2Nv dmVyIHdoYXQgb3B0aW9ucyB0aGUgZGF0YWJhc2Ugc3VwcG9ydHMuJm5ic3A7IElmIHlvdSBoYXZl IHN1Y2ggYSBtZWNoYW5pc20gYW5kIGFsbCBkZXZpY2VzIHVzZSBpdCAoYSZuYnNwOyBib290c3Ry YXAgcHJvdG9jb2wpLA0KIGV2ZXJ5dGhpbmcgZWxzZSBjb3VsZCBiZSBvcHRpb25zLiZuYnNwOyBU aGlzIHJlcXVpcmVzIGFkZGl0aW9uYWwgZnVuY3Rpb25zIGluIGJvdGggZGF0YWJhc2UgYW5kIGRl dmljZSBpbXBsZW1lbnRhdGlvbnMuDQo8YnI+DQpJZiBvbiB0aGUgb3RoZXIgaGFuZCB0aGUgZGV2 aWNlIGNhbiAmcXVvdDtqdXN0IGtub3cmcXVvdDsgdGhhdCB0aGUgZGF0YWJhc2UgaGFzIHR3byBm b3JtcyBhdmFpbGFibGUsIGl0IHdvbid0IG5lZWQgdG8gZHluYW1pY2FsbHkgZmlndXJlIGl0IG91 dC4gVGhlIGRldmljZSBpbXBsZW1lbnRlciBoYXMgb3B0aW9ucyBhbmQgc2ltcGxpY2l0eSwgc28g SSBsaWtlIGl0Lg0KPGJyPg0KPGJyPg0KU2luY2UgSSBhbSBmb2N1c2VkIG9uIHRoZSBUVldTIGRl dmljZXMgdGhhdCBuZWVkIGFjY2VzcyB0byB0aGUgZGF0YWJhc2UsIGFuZCBub3QgYSBkYXRhYmFz ZSBpbXBsZW1lbnRlciwgc2hpZnRpbmcgYnVyZGVuIG9udG8gdGhlIGRhdGFiYXNlIGltcGxlbWVu dGVyIChub3QgbWUpIHRvIHJlZHVjZSB0aGUgYnVyZGVuIG9uIHRoZSBkZXZpY2UgaW1wbGVtZW50 ZXIgKG1lKSBpcyBwcmVmZXJyZWQgZnJvbSBteSBwZXJzcGVjdGl2ZS4mbmJzcDsgVGhlIGRhdGFi YXNlDQogaW1wbGVtZW50ZXIgbWF5IGhhdmUgYW5vdGhlciBwZXJzcGVjdGl2ZS4mbmJzcDsgU2hv dWxkIEkgcG9pbnQgb3V0IHRoYXQgdGhlcmUgd2lsbCBiZSBhIGxvdCBtb3JlIGRldmljZXMgdGhh biBkYXRhYmFzZXM/Jm5ic3A7IFRoYXQgbWlnaHQgc291bmQgbGlrZSBhbiBhcmd1bWVudCwgdGhv dWdoLCBzbyBJIHdvbid0Li4uLjotajxicj4NCjxicj4NCkJlbjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MUY0OTdEIj5CcmlhbiBpcyByaWdodCAuLiBzb3JyeSBidXQgdGhlIHJlc3Qgb2YgeW91IGFyZSB3 cm9uZy4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMUY0OTdEIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyB3aHkgeW91IGhhdmUgTVVTVCBhbmQg U0hPVUxEIGluIFJGQyAyMTE5LiAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlRoaXMgQlRXIGlzIGEgY2xhc3NpYyBhcmd1 bWVudCBpbiBJRVRGIHRlcm1zIC4uIGJ1dCB0aGUgYXJndW1lbnQg4oCcbGV0IHRoZSBtYXJrZXQg ZGVjaWRl4oCdIG9ubHkgaG9sZHMgc28gbXVjaCB2YWxpZGl0eS4mbmJzcDsgWW91IGFjdHVhbGx5 IGhhdmUgdG8gY2hvb3NlIFNPTUVUSElORyB0byBjcmVhdGUNCiBhIGJhc2VsaW5lIG9mIGludGVy b3BlcmFiaWxpdHkuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEIj5BIHZpcnR1YWxseSBpZGVudGljYWwgYXJndW1lbnQgJm5ic3A7aXMg bm93IHBsYXlpbmcgb3V0IGluIGRpc2N1c3Npb25zIG9mIG1hbmRhdG9yeSBhdWRpbyBhbmQgY29k ZWMgaW1wbGVtZW50YXRpb25zIGZvciBXRUJSVEMgbGlrZSB0aGluZ3MuPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5JTUhPIFhNTCBN VVNUIGFueXRoaW5nIGVsc2UgZGVmaW5lZCBTSE9VTEQsIGJ1dCBNVVNUIG9uIFhNTCBhbmQgSlNP TiBjb3VsZCB3b3JrIGFzIHdlbGwuIEl0IGp1c3QgbGVhZHMgdG8gYSBsZXZlbCBvZiBjb21wbGV4 aXR5IGluIGltcGxlbWVudGF0aW9ucy4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+RW5kIG9mIGFyZ3VtZW50IHlvdSBub3cgY2Fu IGdvIGJhY2sgdG8geW91ciByZWd1bGFybHkgc2NoZWR1bGUgcHJvZ3JhbW1pbmcuDQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9y OiMxRjQ5N0QiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFG NDk3RCI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJyZW50Q29sb3IgY3VycmVudENvbG9y Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+DQo8YSBocmVm PSJtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGF3cy1ib3Vu Y2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj48YSBocmVmPSJtYWlsdG86QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPkJhc2F2YXJhai5QYXRpbEBub2tpYS5jb208L2E+PGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgMjMsIDIwMTIgNTo0NCBQTTxicj4NCjxiPlRvOjwvYj4g PGEgaHJlZj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6IiB0YXJnZXQ9Il9ibGFuayI+ QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmQuam9zbHluQHNw ZWN0cnVtYnJpZGdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmQuam9zbHluQHNwZWN0cnVtYnJpZGdl LmNvbTwvYT48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+cGF3c0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmYW1wOyBpQ2FsPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC41cHQ7Y29sb3I6YmxhY2siPkkgYWdyZWUgd2l0aCBCcmlhbi48L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtjb2xvcjpibGFjayI+VGhl cmUgbmVlZHMgdG8gYmUgYSBkZWZhdWx0IG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgb3B0aW9uIGlu IG9yZGVyIHRvIGFjaGlldmUgaW50ZXJvcGVyYWJpbGl0eS4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtjb2xvcjpibGFjayI+QW5kIHRoaXMgYXBw bGllcyB0byB0aGUgZGV2aWNlIGFuZCBkYXRhYmFzZSBzaWRlIG9mIHRoZSBwcm90b2NvbC48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC41cHQ7Y29sb3I6YmxhY2siPi1SYWo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2lu ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJy ZW50Q29sb3IgY3VycmVudENvbG9yIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOmJsYWNrIj4mcXVvdDsmbHQ7ZXh0IFJvc2VuJmd0OyZxdW90OywgJnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6IiB0YXJnZXQ9Il9ibGFuayI+QnJpYW4u Um9zZW5AbmV1c3Rhci5iaXo8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86QnJpYW4uUm9z ZW5AbmV1c3Rhci5iaXoiIHRhcmdldD0iX2JsYW5rIj5Ccmlhbi5Sb3NlbkBuZXVzdGFyLmJpejwv YT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBBdWd1c3QgMjMsIDIwMTIgMjo0MyBQ TTxicj4NCjxiPlRvOiA8L2I+RG9uIEpvc2x5biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmQuam9zbHlu QHNwZWN0cnVtYnJpZGdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmQuam9zbHluQHNwZWN0cnVtYnJp ZGdlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86cGF3 c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBhd3NAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBhd3NAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVy c3VzIEpTT04sIHZDYXJkICZhbXA7IGlDYWw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2NvbG9yOmJs YWNrIj5PbmUgb2YgbXkgZmF2b3JpdGUgSUVURiBleHByZXNzaW9ucyBpcyAmcXVvdDtUaGVyZSBh cmUgbm8gcHJvdG9jb2wgcG9saWNlJnF1b3Q7LiAmbmJzcDtXZSBhcHBseSB0aGF0IGluIGxvdHMg b2Ygd2F5cywgYnV0IG9uZSBvZiB0aGVtIGlzIHRoYXQgaWYgeW91IGRvbid0IGltcGxlbWVudCB3 aGF0IHRoZSBkb2N1bWVudCBzYXlzLA0KIHlvdSBtYXkgbm90IGdldCBpbnRlcm9wZXJhYmlsaXR5 IHdpdGggb3RoZXIgaW1wbGVtZW50YXRpb25zLiAmbmJzcDtPbiB0aGUgb3RoZXIgaGFuZCwgdGhl IHdob2xlIHBvaW50IG9mIGEgcHJvdG9jb2wgZG9jdW1lbnQgbGlrZSBvdXJzIGlzIHRoYXQgdHdv IGluZGVwZW5kZW50IGltcGxlbWVudGF0aW9ucyB3aG8gYm90aCBmb2xsb3cgdGhlIGRvY3VtZW50 IHdpbGwgaW50ZXJ3b3JrLiAmbmJzcDtJZiB0aGF0IHdhc24ndCB0cnVlLCB3aHkgZG8geW91IG5l ZWQgYSBzdGFuZGFyZD8NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC41cHQ7Y29sb3I6YmxhY2siPklmIHlvdSBzYXkgJnF1b3Q7ZWl0 aGVyJnF1b3Q7IHRvIGJvdGggZW5kcywgdGhlbiB5b3UgZG9uJ3QgZ2V0IGludGVyb3BlcmFiaWxp dHkuICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtjb2xvcjpibGFjayI+QnkgeW91ciBhcmd1bWVudCwg d2Ugc2hvdWxkIHN0b3Agd29ya2luZywgYW5kIHRoZSBwcm9kdWN0IG1hbmFnZXJzIHdpbGwgZmln dXJlIGl0IG91dCB1c2luZyBwcm9wcmlldGFyeSBwcm90b2NvbHMuICZuYnNwO1RoZSBtYXJrZXQg d2lsbCBkZWNpZGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2NvbG9yOmJsYWNrIj5TbywgSSBmZWVsIHN0cm9u Z2x5IHRoYXQgaWYgb25lIGVuZCBpcyAmcXVvdDtlaXRoZXImcXVvdDssIHRoZSBvdGhlciBlbmQg bXVzdCBiZSAmcXVvdDtib3RoJnF1b3Q7LiAmbmJzcDtJdCdzIGFsc28gYWNjZXB0YWJsZSB0byBz YXkgYm90aCBlbmRzIGltcGxlbWVudCBvbmUgY2hvaWNlIGFuZCB0aGUgb3RoZXIgaXMgb3B0aW9u YWwgYXQgYm90aA0KIGVuZHMuICZuYnNwO0hlcmUsIEkgdGhpbmsgaXQncyBzZXJ2ZXIgZG9lcyBi b3RoIGFuZCBjbGllbnQgZG9lcyBlaXRoZXIuJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2NvbG9yOmJs YWNrIj5JdCdzIGFsd2F5cyBwb3NzaWJsZSB0byBidWlsZCBhbiBpbXBsZW1lbnRhdGlvbiBvZiBh IHNlcnZlciB0aGF0IG9ubHkgZG9lcyBvbmU6IHRoZXJlIGFyZSBubyBwcm90b2NvbCBwb2xpY2Uu PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjguNXB0O2NvbG9yOmJsYWNrIj5CcmlhbiAmbHQ7YXMgaW5kaXZpZHVhbCZndDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjguNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjguNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Y29sb3I6YmxhY2siPk9uIEF1 ZyAyMywgMjAxMiwgYXQgMzoxMSBQTSwgRG9uIEpvc2x5biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmQu am9zbHluQHNwZWN0cnVtYnJpZGdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmQuam9zbHluQHNwZWN0 cnVtYnJpZGdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Y29sb3I6YmxhY2siPjxicj4NCjxicj4N Cjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0QiPkhpIEJlbiw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+VGhhdCB3YXMgbXkgb3JpZ2luYWwgc3VnZ2VzdGlvbiwgYW5k IEkgc3RpbGwgdGhpbmsgaXQgbWFrZXMgdGhlIG1vc3Qgc2Vuc2UuPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3Ig c3VwcG9ydGluZyB0aGUgcHJvcG9zYWwuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkRvbjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2lu ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJy ZW50Q29sb3IgY3VycmVudENvbG9yIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0 MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+cGF3cy1ib3VuY2VzQGlldGYub3JnPC9hPg0KIFs8YSBocmVmPSJtYWls dG86cGF3cy0iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86cGF3cy08L2E+PGEgaHJlZj0ibWFpbHRv OmJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ib3VuY2VzQGlldGYub3JnPC9hPl08 c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkJlbmphbWluDQogQS4gUm9sZmU8YnI+DQo8Yj5T ZW50OjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBBdWd1c3QgMjMsIDIwMTIgMzowNSBQTTxicj4NCjxiPlRv OjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ cGF3c0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0ieWl2MTgw MTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbcGF3c10gWE1M IHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJmFtcDsgaUNhbDwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Tb21lb25lIHN1Z2dlc3RlZCB0aGF0IFBBV1MgZGVmaW5l IGJvdGgsIGFuZCBsZXQgdGhlIHZlbmRvcnMgZGVjaWRlIHdoaWNoIG9uZXMgdG8gaW1wbGVtZW50 Ljxicj4NClRoYXQgbWFrZXMgdGhlIG1vc3Qgc2Vuc2UgZm9yIGJvdGggREIgYW5kIGRldmljZSB2 ZW5kb3JzLiZuYnNwOyBNYXJrZXRzIHdpbGwgcHJvYmFibHkgZHJpdmUgREIgdmVuZG9ycyB0byBk byBib3RoLiBEZXZpY2UgdmVuZG9ycyB3aWxsIGRvIHdoYXQgZml0cyB0aGUgbWFya2V0IHNlZ21l bnQgdGhleSdyZSBhZnRlci4gV2h5IG92ZXItY29uc3RyYWluIChvciBhcmd1ZSB3aGVuIG5hdHVy YWwgc2VsZWN0aW9uIHdpbGwgdGFrZSBjYXJlIG9mIGl0IGZvciB1cz8pLjxicj4NCkI8YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlNvdW5kcyBnb29kIHRvIG1l Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbjtib3JkZXItY29sb3I6Y3VycmVudENvbG9yIGN1cnJlbnRDb2xvciI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBh d3MtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPnBhd3MtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9InlpdjE4 MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bPGEgaHJlZj0ibWFp bHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPm1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08c3Bh biBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxiPk9uDQogQmVoYWxmIE9mPHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+PGEgaHJlZj0ibWFpbHRvOkdhYm9yLkJhamtvQG5v a2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPkdhYm9y LkJhamtvQG5va2lhLmNvbTwvc3Bhbj48L2E+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9 InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UdWVzZGF5 LCBBdWd1c3QgMjEsIDIwMTIgMTI6NDIgQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9Inlp djE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJt YWlsdG86cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPnBhd3NAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFu IGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ UmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmYW1wOyBpQ2FsPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Tm93IEkgY2Fu4oCZdCBzZWUgYW55bW9y ZSBhbnkgd2lsbGluZ25lc3MgdG8gYWdyZWUgb24gb25lIG9yIHRoZSBvdGhlciBlbmNvZGluZy48 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6Ymxh Y2siPlRvIHByZXZlbnQgZW5kbGVzcyBkaXNjdXNzaW9ucyBvbiB0aGlzIHRvcGljIEnigJlkIHN1 Z2dlc3Qgd2UgbW92ZSBmb3J3YXJkIHdpdGggc3VwcG9ydGluZyBib3RoIGluIHRoZSBEQiBhbmQg ZWl0aGVyIG9uZSBpbiB0aGUgbWFzdGVyIGRldmljZS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkFueSBvYmplY3Rpb25zPzwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+R2Fib3I8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjti b3JkZXItY29sb3I6Y3VycmVudENvbG9yIGN1cnJlbnRDb2xvciI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNs YXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBhd3MtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PnBhd3MtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0 MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bPGEgaHJlZj0ibWFpbHRvOnBh d3MtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPm1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08c3BhbiBjbGFz cz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9u DQogQmVoYWxmIE9mPHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L2I+ZXh0IERhcywgU3ViaXI8YnI+DQo8Yj5TZW50OjwvYj48c3Bh biBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pk1vbmRheSwgQXVndXN0IDIwLCAyMDEyIDI6NTAgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xh c3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Eb24g Sm9zbHluOyBWaW5jZW50IENoZW47IFdlaXhpbnBlbmc8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xh c3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPnBhd3NAaWV0Zi5vcmc8L3NwYW4+PC9hPjsgTWFuaWtrb3RoIFNhamVldjxi cj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09O LCB2Q2FyZCAmYW1wOyBpQ2FsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+ V2UgaGF2ZSBhIGhhbGYgYSBkb3plbiBvciBtb3JlIFRWREIgcmFkaW8gdmVuZG9ycyB0aGF0IHVz ZS9wcmVmZXIgSlNPTiBhbmQgd2Ugd2lsbCB2b3RlIGZvciBKU09OIGlmIHdlIGhhZCB0byBwaWNr IG9uZS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6YmxhY2siPkFsc28gSSB3aWxsIGNvcHkgdGhlIGZvbGxvd2luZyB0d28gaW1wb3J0YW50IHBv aW50czo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlw ZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzFGNDk3RDtt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMyBsZXZlbDIgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5TaW1wbGUtdG8tdXNlIGxpYnJhcmllcyBleGlzdCBmb3IgYWxsIG1ham9yIGxh bmd1YWdlcy9wbGF0Zm9ybXM8L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDIgbGZvMTtiYWNrZ3JvdW5kOndo aXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Eb24ndCBuZWVkIGEgdG9vbCBj aGFpbiB0byB3b3JrIHdpdGggdGhlIGRhdGEsIGFzIGlzIHR5cGljYWxseSBuZWVkZWQgZm9yIFhN TDwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLWNv bG9yOmN1cnJlbnRDb2xvciBjdXJyZW50Q29sb3IiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0ieWl2 MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwYXdzLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5wYXdzLWJv dW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOlttYWlsdG86cGF3 cy1ib3VuY2VzQGlldGYub3JnXSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPlttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXTwvc3Bhbj48L2E+PHNwYW4gY2xh c3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5P bg0KIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9iPkRvbiBKb3NseW48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBj bGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1v bmRheSwgQXVndXN0IDIwLCAyMDEyIDQ6NTQgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9 InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5WaW5jZW50 IENoZW47IFdlaXhpbnBlbmc8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0 MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGF3 c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBh d3NAaWV0Zi5vcmc8L3NwYW4+PC9hPjsgTWFuaWtrb3RoIFNhamVldjxicj4NCjxiPlN1YmplY3Q6 PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+UmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmYW1wOyBp Q2FsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+UGxlYXNlIHNlZSBteSBj b21tZW50cyBiZWxvd+KApjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjpibGFjayI+VGhhbmtzLDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+RG9uPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0 IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLWNvbG9yOmN1cnJlbnRDb2xv ciBjdXJyZW50Q29sb3IiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5wYXdzLWJvdW5jZXNAaWV0Zi5vcmc8 L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+WzxhIGhyZWY9Im1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86cGF3cy1ib3Vu Y2VzQGlldGYub3JnPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5Pbg0KIEJlaGFsZiBPZjxzcGFuIGNsYXNz PSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlZp bmNlbnQgQ2hlbjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5LCBBdWd1c3QgMjAsIDIwMTIg Mjo1NiBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlaXhpbnBlbmc8YnI+DQo8Yj5DYzo8L2I+PHNw YW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnBhd3NAaWV0Zi5vcmc8L3NwYW4+PC9hPjsgTWFuaWtrb3RoIFNh amVldjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1 cyBKU09OLCB2Q2FyZCAmYW1wOyBpQ2FsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJj b2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMjtiYWNrZ3JvdW5kOndoaXRlO3ZlcnRpY2FsLWFs aWduOmJhc2VsaW5lIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0Ij5PbmUgb2Ygb3Vy IGdvYWxzIGlzIHRvIHN0cml2ZSB0byBsb3dlciB0aGUgY29zdCBhbmQgY29tcGxleGl0eSBmb3Ig ZGV2aWNlIG1hbnVmYWN0dXJlcnMuIFRoaXMgbG93ZXJzIHRoZSBiYXJyaWVyIGZvciBidWlsZGlu ZyBhIHJvYnVzdCBlY29zeXN0ZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltESiAtIFRoZSDigJxjb3N04oCdIGFuZCBjb21wbGV4 aXR5IG9mIHVzaW5nIFhNTCBoYXMgbm90IGJlZW4gYW4gaXNzdWUgZm9yIHRoZSBoYWxmIGRvemVu IFRWQkQgdmVuZG9ycyB0aGF0IGhhdmUgYWxyZWFkeSB1c2VkIFhNTC4gTWF5YmUgd2UgbmVlZCB0 byBiZXR0ZXIgZGVmaW5lIOKAnGNvc3TigJ0/XTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8dWwgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw1IGxldmVs MSBsZm8zO2JhY2tncm91bmQ6d2hpdGU7dmVydGljYWwtYWxpZ246YmFzZWxpbmUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS41cHQiPlRvIHJlZHVjZSBjb21wbGV4aXR5IGFuZCBjb3N0IGZv ciBkZXZpY2UgbWFrZXJzLCBzdXBwb3J0aW5nIDEgZW5jb2RpbmcgaXMgYmV0dGVyIHRoYW4gYm90 aCwgYXMgQnJpYW4gcG9pbnRzIG91dC4gV2lGaSBhY2Nlc3MgcG9pbnRzIHRoYXQgJnF1b3Q7anVz dCB3b3JrJnF1b3Q7IGFueXdoZXJlIGluIHRoZSB3b3JsZCBzZXJ2ZXMgYXMgYSBnb29kIG1vZGVs Ljwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5bREogLSBJIHByb3Bvc2VkIHRoYXQgdGhlIGRhdGFiYXNlcyBzdXBwb3J0IGJvdGggWE1M IGFuZCBKU09OLCBkZXZpY2VzIG9ubHkgbmVlZCB0byBzdXBwb3J0IG9uZSB0byB0YWxrIHRvIHRo ZSBkYXRhYmFzZS4gT3VyIGN1cnJlbnQgZGF0YWJhc2Ugc3VwcG9ydHMgWE1MIGFuZCBKU09OLCBi dXQgaWYgSeKAmW0gZm9yY2VkDQogdG8gcGljayBvbmx5IG9uZSwgdGhlbiBJIHdpbGwgdm90ZSBm b3IgWE1MIGJlY2F1c2UgaXTigJlzIHRoZSBvbmUgdGhhdCB3ZSBjdXJyZW50bHkgdXNlIG9uIGFs bCBlbWJlZGRlZCBkZXZpY2VzLl08L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvNDti YWNrZ3JvdW5kOndoaXRlO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuNXB0Ij5UaGVyZSdzIGEgdHJlbmQgZm9yIEFQSXMgb24gdGhlIHdlYiB0b3dh cmRzIEpTT04gKFR3aXR0ZXIsIEZvdXJTcXVhcmUsIEZhY2Vib29rLCBHb29nbGUsIGV0Yy4pLiBP bmUgb2YgdGhlIG1ham9yIHJlYXNvbnMgaXMgdGhhdCBkZXZlbG9wZXJzIChjbGllbnQtc2lkZSkg cHJlZmVyIGl0IGZvciBpdHMgc2ltcGxpY2l0eTo8L3NwYW4+DQo8bzpwPjwvbzpwPjwvbGk+PC91 bD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNCBsZXZlbDIgbGZvNTtiYWNrZ3JvdW5kOndo aXRlO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu NXB0Ij5SZXByZXNlbnRhdGlvbiBjbG9zZWx5IG1hdGNoZXMgbW9zdCBkYXRhIG1vZGVscyAobmVz dGVkIGxpc3RzIGFuZCBtYXBzKTwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNCBsZXZlbDIgbGZvNTtiYWNrZ3JvdW5kOndo aXRlO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu NXB0Ij5TaW1wbGUtdG8tdXNlIGxpYnJhcmllcyBleGlzdCBmb3IgYWxsIG1ham9yIGxhbmd1YWdl cy9wbGF0Zm9ybXM8L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDQgbGV2ZWwyIGxmbzU7YmFja2dyb3VuZDp3aGl0ZTt2ZXJ0 aWNhbC1hbGlnbjpiYXNlbGluZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdCI+RG9u J3QgbmVlZCBhIHRvb2wgY2hhaW4gdG8gd29yayB3aXRoIHRoZSBkYXRhLCBhcyBpcyB0eXBpY2Fs bHkgbmVlZGVkIGZvciBYTUwuPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOmJs YWNrIj5BcHBhcmVudGx5LCB0aGUgZWZmaWNpZW5jeSBnYWlucyBvZiBKU09OIGFsc28gbWF0dGVy IHRvIHRoZSBzY2FsYWJpbGl0eSBvZiBzZXJ2aW5nIHN5c3RlbXMuPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEzLjVwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltESiDigJMgSSBjYW7igJl0IGFyZ3Vl IGFnYWluc3QgdGhlc2UgbGlzdGVkIHByb3MgZm9yIEpTT04sIGVzcGVjaWFsbHkgd2hlbiB5b3Xi gJlyZSBkZWFsaW5nIHdpdGggYSBsb3Qgb2YgZGF0YSAobGlrZSBUd2l0dGVyLCBGb3VyU3F1YXJl LCBGYWNlYm9vayBhbmQgR29vZ2xlIGRvZXMpLiBCdXQgSeKAmW0gYXNzdW1pbmcgdGhhdCBQQVdT DQogbWVzc2FnZXMgd2lsbCBub3QgYmUgZXhjaGFuZ2VkIG5lYXJseSBhcyBvZnRlbiBhcyB0aGUg YXBwbGljYXRpb25zIG1lbnRpb25lZCBhYm92ZS4gQnV0IGFnYWluLCBJIGtub3cgSlNPTiBpcyBt b3JlIGVmZmljaWVudCwgY2Fu4oCZdCBhcmd1ZSB3aXRoIHRoYXQuXTwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNr O21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwxIGxldmVsMSBsZm82O2JhY2tncm91bmQ6d2hpdGU7dmVydGljYWwtYWxpZ246YmFzZWxp bmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQiPkF0IHRoZSBlbmQgb2YgdGhlIGRh eSwgaXQncyB0aGUgZGF0YSBtb2RlbCB0aGF0IG1hdHRlcnMsIHJhdGhlciB0aGFuIHRoZSBlbmNv ZGluZy4gV2UgKEdvb2dsZSkgYXJlIGFjdHVhbGx5IG5ldXRyYWwgb24gWE1MIHZzIEpTT04sIGFz IGxvbmcgYXMgd2UncmUgY2xlYXIgb24gd2hhdCBkZXZpY2UgbWFrZXJzIHdhbnQuIEl0IHdvdWxk IGJlIGdvb2QgdG8gZ2V0IGZlZWRiYWNrIGZyb20gZGV2aWNlDQogbWFrZXJzIChlc3BlY2lhbGx5 IG9mIGVtYmVkZGVkIGRldmljZXMpIHJlZ2FyZGluZyBleHBlcmllbmNlcyBzdXBwb3J0aW5nIFhN TCB2cyBKU09OLjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2Nv bG9yOmJsYWNrIj5Eb24sIGNhbiB5b3UgZWxhYm9yYXRlIG9uIHRoZSB0eXBlcyBvZiBkZXZpY2Vz IHRoYXQgYWxyZWFkeSBzdXBwb3J0IFhNTD88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEzLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+W0RKIC0gV2UgY3VycmVudGx5IHN1cHBvcnQgaGFsZiBhIGRvemVuIFRWREIgcmFkaW8g dmVuZG9ycyAoZW1iZWRkZWQgZGV2aWNlcykgdXNpbmcgWE1MLCBub24gdXNpbmcgSlNPTi4gWE1M IGhhcyBub3QgYmVlbiBhIGJ1cmRlbiwgYW5kIHRoZSBhbW91bnQgb2YgZGF0YSB0aGF0IG5lZWRz IHRvIGJlIGV4Y2hhbmdlZCBiZXR3ZWVuDQogZGV2aWNlIGFuZCBkYXRhYmFzZSBpcyBub3QgdGhh dCBtdWNoIG9yIGV4Y2hhbmdlZCB0aGF0IG9mdGVuLl08L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPk9uIEZyaSwgQXVnIDE3LCAyMDEyIGF0IDY6MDYgUE0sIFdlaXhp bnBlbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp3ZWl4aW5wZW5nQGh1YXdlaS5jb20iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53ZWl4aW5wZW5nQGh1YXdlaS5jb208 L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdE Ij5Db25zaWRlcmluZyBvZiB0aGUgZGVzaWduIG9mIGRhdGFiYXNlIGRpc2NvdmVyeSBwcm90b2Nv bCwgdGhlIExvU1QgcHJvdG9jb2wgbWF5IGJlIHVzZWQgYW5kIExvU1QgaXMgYmFzZWQgb24gWE1M LCBzbyBJIHRoaW5rIFhNTCBtYXkgYmUgcHJlZmVycmVkLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+LS1Y aW5wZW5nIFdlaTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJyZW50Q29sb3IgY3VycmVudENvbG9yIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj48YSBocmVm PSJtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+cGF3cy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBj bGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPltt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBhd3MtYm91bmNlc0BpZXRmLm9yZzwvc3Bh bj48L2E+XTxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGI+T24NCiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5Sb3NlbiwgQnJpYW48L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGI+U2Vu dDo8L2I+PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5GcmlkYXksIEF1Z3VzdCAxNywgMjAxMiA5OjI2IFBNPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5Ubzo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29u dmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5NYW5pa2tvdGggU2FqZWV2OzxzcGFuIGNsYXNz PSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOmdhYm9yLmJhamtvQG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmdhYm9yLmJhamtvQG5va2lhLmNvbTwvc3Bhbj48L2E+OzxzcGFu IGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnZjaGVuQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj52Y2hlbkBnb29nbGUuY29tPC9zcGFuPjwvYT47PHNwYW4gY2xh c3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tPC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAx NTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5wYXdzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFz cz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBb cGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJmFtcDsgaUNhbDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOmJsYWNrIj5JIGRvbid0IHJlYWxseSBjYXJlIHdoZXRoZXIgd2UgdXNlIGpzb24g b3IgeG1sIGFzIGEgbWF0dGVyIG9mIHByb3RvY29sIGRlc2lnbiBvciBpbXBsZW1lbnRhdGlvbiwg YnV0IEkgYW0gYSBiaWcgZmFuIG9mIHJldXNpbmcgc3RhbmRhcmRzIHJhdGhlciB0aGFuIGRlZmlu aW5nIG5ldyBvbmVzLA0KIGFuZCBJIHdvdWxkIG5vdCB3YW50IHRvIHNlZSB0aGUgY2hvaWNlIG9m IGpzb24gbWVhbiB3ZSB0aGVuIGRlY2lkZSB0byByb2xsIG91ciBvd24gdmVyc3VzIHVzaW5nIGV4 aXN0aW5nIHN0YW5kYXJkcyBiYXNlZCBvbiB0aGUgaWRlYSB0aGVyZSBpcyBubyBqc29uIHJlcHJl c2VudGF0aW9uIG9mIGFuIGV4aXN0aW5nIHN0YW5kYXJkLiAmbmJzcDtTbywgaWYgY2hvb3Npbmcg anNvbiBtZWFucyBmb2xrcyBmZWVsIGZyZWUgdG8gaWdub3JlIGV4aXN0aW5nIHhtbA0KIGJhc2Vk IHN0YW5kYXJkcyBzdWNoIGFzIHhDYXJkIGFuZCBMb1NULCB0aGVuIEkgd291bGQgbm90IHdhbnQg dG8gdXNlIGpzb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si Pkkgd291bGQgcHJlZmVyIHRvIG5vdCBoYXZlICZxdW90O2JvdGgmcXVvdDssIGJlY2F1c2Ugb2Yg aW50ZXJvcGVyYWJpbGl0eSBjb21wbGljYXRpb25zLiAmbmJzcDtJZiB0aGVyZSBpcyByb3VnaCBj b25zZW5zdXMgZm9yIGJvdGgsIHRoZW4gSSB3b3VsZCBhc3NlcnQgdGhhdCBhbGwgc2VydmVycyBo YXZlIHRvIGltcGxlbWVudA0KIGJvdGggYW5kIHRoZSBjbGllbnQgY2FuIGltcGxlbWVudCBlaXRo ZXIuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPlRoZXJlIGFy ZSBqc29uIHZhbGlkYXRvcnMsIHNvIEkgZG9uJ3QgdGhpbmsgdGhhdCBpcyBhIGJpZyBkZWFsLiAm bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+TXkgZXhw ZXJpZW5jZSBpbiBwcm90b2NvbCBkZXNpZ24gb24gdGhlIEludGVybmV0IGlzIHRoYXQgZGVjaXNp b25zIG1hZGUgc29sZWx5IG9yIGV2ZW4gbGFyZ2VseSBiZWNhdXNlIG9mIGNvbXBhY3RuZXNzIGFk dmFudGFnZXMgcmFyZWx5IGFyZSBnb29kIGNob2ljZXMuICZuYnNwO0lmIHlvdSBsaWtlIGpzb24N CiBiZWNhdXNlIGl0IGlzIHNtYWxsZXIsIHRoZW4gSSBiZWxpZXZlIHlvdSBuZWVkIGEgbXVjaCBi ZXR0ZXIgcmVhc29uLiAmbmJzcDtCaW5hcnkgZG9lc24ndCB3b3JrIGZvciBtZSwgYXQgYWxsLiAm bmJzcDtJIGhhdmUgYmVlbiBpbnZvbHZlZCBpbiBiaWcgYmluYXJ5IHZzIHRleHQgd2FycyBpbiBw cm90b2NvbCBkZXNpZ24uICZuYnNwO1RleHQgd2lucywgYmluYXJ5IGxvc2VzLCBpbiBteSBvcGlu aW9uLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5CcmlhbiAm bHQ7YXMgaW5kaXZpZHVhbCZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2lu ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJy ZW50Q29sb3IgY3VycmVudENvbG9yIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjpibGFjayI+TWFuaWtrb3RoIFNhamVldiAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1rc2FqaUB5YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5ta3NhamlAeWFob28uY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+UmVwbHktVG86 PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48L2I+TWFuaWtrb3RoIFNhamVldiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1rc2FqaUB5YWhv by5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ta3NhamlA eWFob28uY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0ieWl2MTgw MTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5UaHUsIDE2IEF1 ZyAyMDEyIDIyOjM3OjM4IC0wNDAwPGJyPg0KPGI+VG86PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0 MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7PGEgaHJlZj0i bWFpbHRvOkdhYm9yLkJhamtvQG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPkdhYm9yLkJhamtvQG5va2lhLmNvbTwvc3Bhbj48L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+R2Fib3IuQmFqa29Abm9raWEuY29tPC9zcGFuPjwv YT4mZ3Q7LA0KICZxdW90O1Jvc2VuLCBCcmlhbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJy aWFuLnJvc2VuQG5ldXN0YXIuYml6IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+YnJpYW4ucm9zZW5AbmV1c3Rhci5iaXo8L3NwYW4+PC9hPiZndDssICZxdW90Ozxh IGhyZWY9Im1haWx0bzp2Y2hlbkBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+dmNoZW5AZ29vZ2xlLmNvbTwvc3Bhbj48L2E+JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86dmNoZW5AZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnZjaGVuQGdvb2dsZS5jb208L3NwYW4+PC9hPiZndDssDQogJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOnBldGVyQHNwZWN0cnVtYnJpZGdlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBldGVyQHNwZWN0cnVtYnJpZGdlLmNvbTwv c3Bhbj48L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2Uu Y29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGV0ZXJAc3Bl Y3RydW1icmlkZ2UuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PHNwYW4gY2xhc3M9Inlp djE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5wYXdzQGlldGYub3JnPC9zcGFuPjwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+cGF3c0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48L2I+UmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmYW1wOyBp Q2FsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGksPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Q2FuIGl0IG5vdCBi ZSBib3RoIEpTT04gYW5kIFhNTCBzdXBwb3J0ZWQ/IEkgd291bGQgdm90ZSBmb3IgdGhhdC4gRnV0 dXJlIGltcGxlbWVudGF0aW9ucyBtYXkgcHJlZmVyPHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5YTUwgYXMgaXQgaXMgZ2VuZXJp YywmbmJzcDtvbW5pDQogcHJlc2VudCwgZWFzeSB0byB1bmRlcnN0YW5kIGFuZCB2YWxpZGF0ZS48 L2I+PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5Gb3IgY29tcGFjdG5lc3MgbWF5IGJlIGEmbmJzcDs8c3BhbiBjbGFzcz0ieWl2MTgw MTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPmJpbmFyeSB4bWwg b3B0aW9uPC9iPmNhbiBhbHNvIHdvcmsuIEpTT04gSSB0aGluayB3aWxsIG5lY2Vzc2l0YXRlIGlt cGxlbWVudGF0aW9uDQogdG8gYmUgbmF0aXZlIEphdmEgYW5kIG1heSBub3QgYmUgYXMgZnJpZW5k bHkgd2l0aCBvdGhlciBpbXBsZW1lbnRhdGlvbiBsYW5ndWFnZXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QmVzdCBSZWdhcmRz LDwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U2FqZWV2IE1hbmlra290aDxicj4NCk1v YmlsZTo8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJNc29IeXBlcmxpbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPiYjNDM7OTE4NzkyMjkyMDAyPC9zcGFuPjwvc3Bhbj48YnI+DQpFbWFpbDo8c3BhbiBj bGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxh IGhyZWY9Im1haWx0bzpta3NhamlAaWVlZS5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5ta3NhamlAaWVlZS5vcmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9 Imh0dHA6Ly93d3cubGlua2VkaW4uY29tL2luL21rc2FqZWV2IiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL3d3dy5saW5rZWRpbi5jb20vaW4vbWtzYWpl ZXY8L3NwYW4+PC9hPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIx YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjpibGFjayI+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOkdhYm9yLkJhamtvQG5va2lhLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPkdhYm9yLkJhamtv QG5va2lhLmNvbTwvc3Bhbj48L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpHYWJvci5C YWprb0Bub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5HYWJvci5CYWprb0Bub2tpYS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5Ubzo8L2I+PHNw YW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXoiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5Ccmlhbi5Sb3NlbkBuZXVzdGFyLmJpejwvc3Bh bj48L2E+OzxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnZjaGVuQGdvb2dsZS5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj52Y2hlbkBnb29nbGUuY29tPC9zcGFuPjwv YT47PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGV0ZXJAc3BlY3RydW1icmlkZ2Uu Y29tPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTUz OTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpw YXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ cGF3c0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFz cz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkZyaWRh eSwgMTcgQXVndXN0IDIwMTIsIDQ6NTU8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0i eWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbcGF3 c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJmFtcDsgaUNhbDwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxicj4NCldlIGhhdmUgbm90IGhlYXJkIGFueSBvYmplY3Rpb25zIGZvciB1c2luZyBKU09O IGVuY29kaW5nIGluc3RlYWQgb2YgWE1MLjxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KVGhlcmVmb3JlLCBsZXQncyBnbyBm b3IgSlNPTiwgYW5kIGNsb3NlIHRoaXMgdGhyZWFkLjxicj4NCjxicj4NCi0gR2Fib3I8YnI+DQo8 YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206PHNwYW4gY2xhc3M9Inlp djE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJt YWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+cGF3cy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBjbGFz cz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlttYWls dG86PGEgaHJlZj0ibWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBhd3MtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L2E+XQ0KIE9uIEJlaGFsZiBPZiBleHQgUm9zZW4sIEJyaWFuPGJyPg0KU2VudDogTW9uZGF5LCBB dWd1c3QgMTMsIDIwMTIgMzoxNCBQTTxicj4NClRvOiAnVmluY2VudCBDaGVuJzsgJ1BldGVyIFN0 YW5mb3J0aCc8YnI+DQpDYzogJzxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGF3c0BpZXRmLm9yZzwvc3Bhbj48 L2E+Jzxicj4NClN1YmplY3Q6IFJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNh cmQgJmFtcDsgaUNhbDxicj4NCjxicj4NCmpzb24gaXMgb2theSB3aXRoIG1lLiZuYnNwOzxzcGFu IGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGJyPg0KSSdkIHByZWZlciBhbiBJU08gdGltZSBzdGFtcCByYXRoZXIgdGhhbiBhIHRpbWUgaW4g c2Vjb25kcyBzaW5jZSBlcG9jaC4mbmJzcDsgSXQncyB2ZXJ5IGVhc3kgdG8gcGFyc2UsIGFuZCBp dHMgc2ltcGxlciB0byB1c2UgYW5kIGRlYnVnLiZuYnNwOyBEb24ndCBjYXJlIGEgd2hvbGUgbG90 IGFib3V0IHRoYXQ8YnI+DQo8YnI+DQpCcmlhbiAmbHQ7YXMgaW5kaXZpZHVhbCZndDs8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206ICZu YnNwOyZuYnNwOyZuYnNwOyBWaW5jZW50IENoZW4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86dmNo ZW5AZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PnZjaGVuQGdvb2dsZS5jb208L3NwYW4+PC9hPl08YnI+DQpTZW50OiZuYnNwOyZuYnNwOyZuYnNw OyBNb25kYXksIEF1Z3VzdCAxMywgMjAxMiAwNjowNCBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWU8 YnI+DQpUbzombmJzcDsmbmJzcDsmbmJzcDsgUGV0ZXIgU3RhbmZvcnRoPGJyPg0KQ2M6Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFJvc2VuLCBCcmlhbjsgVGVjbyBCb290OyBCZW5qYW1pbiBBLlJvbGZlOzxz cGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5wYXdzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQpTdWJqZWN0 OiZuYnNwOyZuYnNwOyZuYnNwOyBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZD YXJkICZhbXA7IGlDYWw8YnI+DQo8YnI+DQpYTUwgdnMgSlNPTjxicj4NCjxicj4NCkJldHdlZW4g WE1MIGFuZCBKU09OLCBKU09OIG1lc3NhZ2VzIGFyZSBtb3JlIGNvbXBhY3QgYW5kIGVhc2llciB0 byBwcm9jZXNzIChwYXJzaW5nLCBzeW50aGVzaXMpLiBBcyBjbGFyaWZpY2F0aW9uLCBKU09OIGRv ZXMgbm90IHJlcXVpcmUgSmF2YVNjcmlwdCBvciBhIEJyb3dzZXIuIEl0IGlzIGEgdGV4dC1iYXNl ZCByZXByZXNlbnRhdGlvbiBvZiBkYXRhIHRoYXQgaXMgbGFuZ3VhZ2UgaW5kZXBlbmRlbnQsIHll dCB3ZWxsLW1hdGNoZWQgdG8gYWxsDQogbWFqb3IgbGFuZ3VhZ2VzLiBKU09OLWhhbmRsaW5nIGxp YnJhcmllcyBleGlzdCBmb3IgbnVtZXJvdXMgbGFuZ3VhZ2VzIChzZWUgb2Y8c3BhbiBjbGFzcz0i eWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Imh0dHA6Ly9qc29uLm9yZy8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5odHRwOi8vanNvbi5vcmcvPC9zcGFuPjwvYT4pIGFuZCBzZWVtIHRvIGJlIHJlYXNvbmFi bHkNCiBsaWdodCB3ZWlnaHQuPGJyPg0KPGJyPg0KVGltZXN0YW1wczxicj4NCjxicj4NCkFzIGZv ciB0aW1lc3RhbXAgc3BlY2lmaWNhdGlvbnMsIHNob3VsZCB3ZSBjb25zaWRlciBqdXN0IHVzaW5n IHNlY29uZHMgc2luY2UgdGhlIFVOSVggRXBvY2ggKDE5NzAtMDEtMDFUMDA6MDA6MDBaKT8gVGhp cyB3b3VsZCBlbGltaW5hdGUgdGhlIG5lZWQgZm9yIGRhdGV0aW1lLXN0cmluZyBwYXJzaW5nIG9u IGRldmljZXMsIGFzc3VtaW5nIGRldmljZXMgYWxyZWFkeSBoYXZlIG5hdGl2ZSBsaWJyYXJpZXMg dGhhdCBwcm92aWRlIHRpbWUgaW4gdGhpcw0KIGZvcm1hdC4gSXMgdGhhdCBhIHZhbGlkIGFzc3Vt cHRpb24/IE9mIGNvdXJzZSwgdGhpcyBpcyBsZXNzIGh1bWFuLXJlYWRhYmxlLi4uLjxicj4NCjxi cj4NCjxicj4NCk9uIE1vbiwgQXVnIDEzLCAyMDEyIGF0IDY6NDkgQU0sIFBldGVyIFN0YW5mb3J0 aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBldGVyQHNwZWN0cnVtYnJpZGdlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBldGVyQHNwZWN0cnVtYnJpZGdlLmNv bTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgV2hlbmV2ZXIgd2UgYnVpbHQgbW9iaWxlIGRldmljZXMgd2UgbmV2ZXIgZGVhbHQgd2l0aCBJ RVRGLCBpbiBvdXIgc2Vuc29yPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGRheXMgZXZlbiBhbiBJ UCBzdGFjayB3YXMgYSBjaGFsbGVuZ2Usc28gSSB3b3VsZCBkZWZlciB0byB0aGUgZGV2aWNlIGd1 eXM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgb24gdGhhdCBvbmUuPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgT24gTW9uQXVnLzEzLzEyIE1vbiBB dWcgMTMsIDk6MzAgQU0sICZxdW90O1Jvc2VuLCBCcmlhbiZxdW90Ozxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOzxzcGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86 QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXoiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5Ccmlhbi5Sb3NlbkBuZXVzdGFyLmJpejwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 T3VyIGV4cGVyaWVuY2UgaW4gdGhlIElFVEYgb3ZlciBtYW55IHllYXJzIGlzIHRoYXQgZWNvbm9t aXppbmcgbWVzc2FnZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7c2l6ZSBhbmQgY29tcHJv bWlzaW5nIHV0aWxpdHkgYW5kIHNlY3VyaXR5IGluIHNlYXJjaCBvZiBlZmZpY2llbmN5IG9mPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDtpbXBsZW1lbnRhdGlvbiBvbiBzbWFsbCBkZXZpY2Vz IGlzIGEgcG9vciB0cmFkZSBvZmYuJm5ic3A7IEkgYW0gbm90IGFkdm9jYXRpbmc8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsgJmd0O2JlaW5nIHdhc3RlZnVsIG9mIHJlc291cmNlcywgYnV0IEkgZG9u J3QgdGhpbmsgd2Ugc2hvdWxkIHNlcmlvdXNseTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Y29uc2lkZXIgdGhlIG92ZXJoZWFkIG9mIFhNTCBvciBqc29uIHRvIGJlIHNpZ25pZmljYW50Ljxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDtB c3N1bWluZyBhIGpzb24gbGlicmFyeSBjYW4gYmUgbG9hZGVkIG9uIGEgc21hbGwgZGV2aWNlIGlz IHJlYXNvbmFibGUuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgJmd0O0JyaWFuIChhcyBpbmRpdmlkdWFsKTxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgJmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDtGcm9tOiZuYnNwOyBQZXRlciBTdGFu Zm9ydGggW21haWx0bzo8YSBocmVmPSJtYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGV0ZXJAc3BlY3RydW1i cmlkZ2UuY29tPC9zcGFuPjwvYT5dPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDtTZW50OiZu YnNwOyBTYXR1cmRheSwgQXVndXN0IDExLCAyMDEyIDA3OjEzIEFNIEVhc3Rlcm4gU3RhbmRhcmQg VGltZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7VG86Jm5ic3A7ICZuYnNwOyBUZWNvIEJv b3Q7IEJlbmphbWluIEEuUm9sZmU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0O0NjOiZuYnNw OyAmbmJzcDs8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGF3c0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDtTdWJqZWN0OiZuYnNwOyAmbmJzcDsgJm5ic3A7IFJl OiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJmFtcDsgaUNhbDxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDtOb3QgYWxs IG1hc3RlcnMgcnVuIG92ZXIgdGhlIGNvcmUgbmV0d29yay48YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgJmd0O1NvbWUgb2YgdGhlIFVzZSBjYXNlcyBoYXZlIGEgbWFzdGVyIHRhbGtpbmcgdG8gYW5v dGhlciBPVEE8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0O1dlIHNob3VsZCBub3QgYXNzdW1l IHRoYXQgYWxsIE1hc3RlcnMgYXJlIGF0dGFjaGVkIHRvIHV0aWxpdHkgcG93ZXIgc28gd2U8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0O3Nob3VsZCBiZSBzeW1wYXRoZXRpYyB0byBwcm9jZXNz aW5nIGVuZXJneSB1c2UgYWxzby48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7T24gU2F0QXVnLzExLzEyIFNhdCBBdWcgMTEsIDU6MzAgQU0s ICZxdW90O1RlY28gQm9vdCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlY29AaW5mLW5ldC5u bCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRlY29AaW5mLW5l dC5ubDwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0O09wIDEwIGF1Zy4gMjAxMiwgb20gMTg6MTAgaGVlZnQgQmVuamFtaW4gQS4gUm9sZmUg aGV0IHZvbGdlbmRlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Z2VzY2hyZXZlbjo8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDsmZ3Q7IENvbXBhY3RuZXNzIG9mIG1lc3NhZ2VzIGlzIGltcG9ydGFudCwgYnV0IGl0 IGlzIGFsc28gaW1wb3J0YW50ICh0byBtZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDthdCBsZWFzdCkgdG8gYmUgcmVhbGl6YWJsZSBpbiBhbiBpbXBsZW1lbnRhdGlvbiB3aXRo IGxpbWl0ZWQgcmVzb3VyY2VzLDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDtz dWNoIGFzIGVtYmVkZGVkIGRldmljZXMgaW4gd2hhdCBhcmUgbm93IHBvcHVsYXJseSBjYWxsZWQg JnF1b3Q7TTJNJnF1b3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0O2FwcGxp Y2F0aW9ucy4mbmJzcDsgQSBsb3Qgb2YgdGhlc2UgZGV2aWNlcyBjb3VsZCB1c2UgSVAgYWxsIHRo ZSBlbmQgdG8gZW5kLDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDtidXQgbWF5 IGhhdmUgYSB2ZXJ5IGNvbXBhY3QsIHNpbXBsZSBzdGFjayBhbmQgYXBwbGljYXRpb25zIChpLmUu Jm5ic3A7IG5vPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0O2Jyb3dzZXIpLiZu YnNwOyBJcyBKU09OIHR5cGljYWxseSBpbXBsZW1lbnRlZCB3aGVuIHRoZXJlIGlzIG5vIGJyb3dz ZXI/PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0O1dvdWxkIGl0IGJlIGhhcmQg dG8gZG8gaW4gYSByZXNvdXJjZSBjb25zdHJhaW5lZCBkZXZpY2UgKGkuZS4gd2hlcmUgd2U8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7dGFsayBhYm91dCBtZW1vcnkgc2l6ZSBp biBLaWxvLWJ5dGVzIHN0aWxsKS48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDs8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDtJbiB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50 cyBkb2N1bWVudCwgdGhlcmUgYXJlIG5vIHJlcXVpcmVtZW50cyBmb3I8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZndDtwcm90b2NvbCBwZXJmb3JtYW5jZS4gSSBndWVzcyBPUy9JUC9UQ1Av VExTIGNvZGUgc2l6ZSBzdXBlcnNlZGVzIG5lZWRzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmZ3Q7Zm9yIEpTT04gb3IgWE1MLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0Ozxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0O1NhbWUgZm9yIHRpbWluZzogVENQL1RMUyBj b25uZWN0aW9uIHNldHVwIHdpbGwgdGFrZSBtb3JlIHRoYW4gdGhlIFBBV1M8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDttZXNzYWdlIGV4Y2hhbmdlLCBJIHRoaW5rLiBUaGlzIG1heSBi ZSBvZiBpbXBvcnRhbmNlIHdoZW4gdXNpbmcgc2F0Y29tPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7bGlua3MuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7QmVjYXVzZSBQQVdTIHJ1bnMgYmV0d2VlbiBtYXN0ZXIg YW5kIGRhdGFiYXNlLCBvdmVyIGNvcmUgbmV0d29yayw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDtwZXJmb3JtYW5jZSBpcyBub3Qgb3VyIHByaW1hcnkgY29uY2Vybi4gQnV0IGFzIGFs d2F5cywgaXQgaXMgZ29vZCB0byBrZWVwPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 YW4gZXllIG9uIGVmZmljaWVuY3kuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7VGVjbzxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgVGhhbmtzPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBCZW48YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0Ozxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IFdlIGhhZCBhIGRpc2N1c3Np b24gb24gWE1MIHZzLiBKU09OLiBJIHByZWZlciB0aGUgb25lIHdpdGggbW9zdDxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Y29tcGFjdCBtZXNzYWdlcy48YnI+DQombmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7IE9uIHZDYXJkIGFuZCBKU09OOiB3aGF0IGlzIHRoZSBzdGF0dXMgb2Yg JnF1b3Q7QSBKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbjxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7KEpTT04pIFJlcHJlc2VudGF0aW9uIGZvciB2Q2FyZCZxdW90Oz88 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJ5aXYx ODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmhhdC12Y2FyZGRhdi1qc29uLTAwIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtYmhhdC12Y2FyZGRhdi1qc29uLTAwPC9zcGFuPjwvYT48YnI+DQombmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7IE9uIHZhbGlkIHRpbWVzOiBjYW4gd2UgdXNlIHNhbWUgZm9ybWF0IGFz IGNlcnRpZmljYXRlcz8gVGhleSBoYXZlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDtzaW1pbGFyIHNpbXBsZSByZXF1aXJlbWVudHM6IHZhbGlkIG5vdEJlZm9yZSZhbXA7 Jm5ic3A7IG5vdEFmdGVyLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMjgwI3NlY3Rpb24t NC4xLjIuNSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMyODAjc2VjdGlvbi00LjEuMi41PC9zcGFuPjwvYT48 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRlY288YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IHBhd3MgbWFpbGlu ZyBsaXN0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8c3BhbiBjbGFz cz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+cGF3c0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDs8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcGF3cyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3czwvc3Bhbj48 L2E+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgcGF3cyBtYWlsaW5nIGxpc3Q8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGF3c0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBhd3NA aWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8 c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cyIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3czwvc3Bhbj48L2E+PGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDtwYXdzIG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OzxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGF3c0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzPC9zcGFuPjwv YT48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgJmd0O3Bhd3MgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDs8YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBhd3NAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzPC9zcGFuPjwv YT48YnI+DQombmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyBwYXdzIG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5wYXdzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQombmJzcDsm bmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcGF3cyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3czwvc3Bhbj48L2E+PGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9InlpdjE4MDE1Mzk0MjFhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLTxz cGFuIGNsYXNzPSJ5aXYxODAxNTM5NDIxYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGJyPg0KLXZpbmNlPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpwYXdzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+cGF3c0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w YXdzPC9zcGFuPjwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCnBhd3MgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnBh d3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5w YXdzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3M8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0K PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+LS08c3BhbiBjbGFzcz0ieWl2MTgwMTUzOTQyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCi12aW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5wYXdzIG1haWxpbmcgbGlzdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBhd3NAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3M8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdDtjb2xvcjpibGFjayI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpwYXdzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGF3c0BpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bh d3MiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Bhd3M8L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPnBhd3MgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9 Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGF3c0BpZXRmLm9yZzwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wYXdzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpwYXdzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGF3c0BpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3M8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpwYXdzIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIj5wYXdzQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3czwvYT48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AAC987F0CC2C7845A9FBD8A36D52E12D968577rrcatsexmb1_-- From hannes.tschofenig@gmx.net Sun Aug 26 00:35:22 2012 Return-Path: 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 C4CEC21F84A5 for ; Sun, 26 Aug 2012 00:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.81 X-Spam-Level: X-Spam-Status: No, score=-100.81 tagged_above=-999 required=5 tests=[AWL=-1.811, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_92=0.6, USER_IN_WHITELIST=-100] 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 DG1u+LLzjGqP for ; Sun, 26 Aug 2012 00:35:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2BE9F21F84A1 for ; Sun, 26 Aug 2012 00:35:19 -0700 (PDT) Received: (qmail invoked by alias); 26 Aug 2012 07:35:18 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.216.191] by mail.gmx.net (mp041) with SMTP; 26 Aug 2012 09:35:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/Fm3N0jRXFOxc64WwLHu/SXc5By9PyGwZZyIfrK1 4JF6C5r2wBK5z0 Message-ID: <5039D1B2.2080207@gmx.net> Date: Sun, 26 Aug 2012 10:35:14 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Das, Subir" References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> <00c601cd820b$67b97170$372c5450$@us> <5037B28B.70501@blindcreek.com> <5D0B1E63-79FE-4BC6-A446-3470931D1043@neustar.biz> <5037BC2B.7010008@blindcreek.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724@008-AM1MPN1-006.mgdnok.nokia.com> <1345864438.6327.YahooMailNeo@web120306.mail.ne1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "paws@ietf.org" , Manikkoth Sajeev 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 07:35:22 -0000 Hi all, JSON and XML are very similar in terms of supported tools and availability of code in languages. The only question to me that arises is whether you want to re-use existing protocol work (such as LoST, vCard, GML, etc.). Do you know the answer to this question? Ciao Hannes PS: Embedded devices, M2M, Internet of Things implementation (whatever you want to call them) use all sorts of encodings, including XML and JSON. In fact the most "heavy" part of the code will not be the XML/JSON (which will most likely be uses as a template anyway) but the security functionality. On 08/26/2012 04:30 AM, Das, Subir wrote: > It would be good if you can provide some specific examples where JSON is > problematic but XML is easier. > > -Subir > > *From:*paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *Manikkoth Sajeev > *Sent:* Friday, August 24, 2012 11:14 PM > *To:* Gabor.Bajko@nokia.com; Brian.Rosen@neustar.biz; ben@blindcreek.com > *Cc:* paws@ietf.org > *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal > > Hi, > > I would still support XML. JSON libraries are available for all > languages. But interfacing and linking such libraries are problematic on > embedded devices most of the time. And if an implementation vouch for > multiple such non native language libraries then developers life is hell... > > /Best Regards,/ > > /Sajeev Manikkoth/ > > *From:*"Gabor.Bajko@nokia.com " > > > *To:* Brian.Rosen@neustar.biz ; > ben@blindcreek.com > *Cc:* paws@ietf.org > *Sent:* Saturday, 25 August 2012, 0:38 > *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal > > 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] *On Behalf Of *ext Rosen, Brian > *Sent:* Friday, August 24, 2012 10:43 AM > *To:* Benjamin A. Rolfe > *Cc:* 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" > 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 > 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] *On Behalf Of *Basavaraj.Patil@nokia.com > > *Sent:* Thursday, August 23, 2012 5:44 PM > *To:* Brian.Rosen@neustar.biz ; > d.joslyn@spectrumbridge.com > *Cc:* 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: *"", "Brian.Rosen@neustar.biz > " > > *Date: *Thursday, August 23, 2012 2:43 PM > *To: *Don Joslyn > > *Cc: *"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 > > On Aug 23, 2012, at 3:11 PM, Don Joslyn > 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 ]*On Behalf > Of*Benjamin A. Rolfe > *Sent:*Thursday, August 23, 2012 3:05 PM > *To:*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]*On Behalf > Of*Gabor.Bajko@nokia.com > *Sent:*Tuesday, August 21, 2012 12:42 AM > *To:*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]*On Behalf > Of*ext Das, Subir > *Sent:*Monday, August 20, 2012 2:50 PM > *To:*Don Joslyn; Vincent Chen; Weixinpeng > *Cc:*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: > > o Simple-to-use libraries exist for all major languages/platforms > o 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] > *On Behalf Of*Don Joslyn > *Sent:*Monday, August 20, 2012 4:54 PM > *To:*Vincent Chen; Weixinpeng > *Cc:*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]*On Behalf > Of*Vincent Chen > *Sent:*Monday, August 20, 2012 2:56 PM > *To:*Weixinpeng > *Cc:*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: > > o Representation closely matches most data models (nested lists > and maps) > o Simple-to-use libraries exist for all major languages/platforms > o 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 > 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 > ]*On Behalf Of*Rosen, Brian > > > *Sent:*Friday, August 17, 2012 9:26 PM > > *To:*Manikkoth Sajeev;gabor.bajko@nokia.com > ;vchen@google.com > ;peter@spectrumbridge.com > > > > *Cc:*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 > > *From:*Manikkoth Sajeev > > *Reply-To:*Manikkoth Sajeev > > *Date:*Thu, 16 Aug 2012 22:37:38 -0400 > *To:*"Gabor.Bajko@nokia.com " > >, "Rosen, Brian" > >, > "vchen@google.com " >, "peter@spectrumbridge.com > " > > *Cc:*"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 option*can > 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 > Email:mksaji@ieee.org > http://www.linkedin.com/in/mksajeev/ > > *From:*"Gabor.Bajko@nokia.com " > > > *To:*Brian.Rosen@neustar.biz > ;vchen@google.com > ;peter@spectrumbridge.com > > *Cc:*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 > ] On Behalf Of ext Rosen, Brian > Sent: Monday, August 13, 2012 3:14 PM > To: 'Vincent Chen'; 'Peter Stanforth' > Cc: '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 > > > > -----Original Message----- > From: Vincent Chen [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 > > 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 > ofhttp://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 > > 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" > > > 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 > ] > >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time > >To: Teco Boot; Benjamin A.Rolfe > >Cc: 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" > 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 > >>>> > >>>> 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 > >>>> > >>>> Teco > >>>> _______________________________________________ > >>>> paws mailing list > >>>>paws@ietf.org > >>>>https://www.ietf.org/mailman/listinfo/paws > >>>> > >>> > >>> _______________________________________________ > >>> paws mailing list > >>>paws@ietf.org > >>>https://www.ietf.org/mailman/listinfo/paws > >> > >>_______________________________________________ > >>paws mailing list > >>paws@ietf.org > >>https://www.ietf.org/mailman/listinfo/paws > > > >_______________________________________________ > >paws mailing list > >paws@ietf.org > >https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > > > -- > -vince > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > -- > -vince > > > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From cuiyang@huawei.com Mon Aug 27 00:23:10 2012 Return-Path: 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 58F9421F84E4 for ; Mon, 27 Aug 2012 00:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.847 X-Spam-Level: X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[AWL=-2.390, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_92=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 LofwrTMVtjnm for ; Mon, 27 Aug 2012 00:23:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0850821F84CF for ; Mon, 27 Aug 2012 00:23:07 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp01-ep.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id APG00578; Sun, 26 Aug 2012 23:23:06 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 27 Aug 2012 00:20:26 -0700 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 27 Aug 2012 00:20:26 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.203]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Mon, 27 Aug 2012 15:20:22 +0800 From: Cuiyang To: Hannes Tschofenig , "Das, Subir" Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Iet+vcHW33FkKtiTDiFeYExQAAU/5DAIietgAABrI6AAAWoncAABh1noAAifZJAAAEHtuAAAHwqAAADmEvAACA/ioAAAG/7gAAADZjgAABIt+AAAQuNIAAJMQFAAADi+2AAABpNIAAAQX3gAAAI8OAAAL964AAEPRDAAAuqfcAAAzAjAAAQbZHwA== Date: Mon, 27 Aug 2012 07:20:21 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE21636860E7F@SZXEML508-MBS.china.huawei.com> References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> <00c601cd820b$67b97170$372c5450$@us> <5037B28B.70501@blindcreek.com> <5D0B1E63-79FE-4BC6-A446-3470931D1043@neustar.biz> <5037BC2B.7010008@blindcreek.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724@008-AM1MPN1-006.mgdnok.nokia.com> <1345864438.6327.YahooMailNeo@web120306.mail.ne1.yahoo.com> <5039D1B2.2080207@gmx.net> In-Reply-To: <5039D1B2.2080207@gmx.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.48.119] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" , Manikkoth Sajeev 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 07:23:10 -0000 SGksIA0KDQo+IFBTOiBFbWJlZGRlZCBkZXZpY2VzLCBNMk0sIEludGVybmV0IG9mIFRoaW5ncyBp bXBsZW1lbnRhdGlvbiAod2hhdGV2ZXINCj4geW91IHdhbnQgdG8gY2FsbCB0aGVtKSB1c2UgYWxs IHNvcnRzIG9mIGVuY29kaW5ncywgaW5jbHVkaW5nIFhNTCBhbmQNCj4gSlNPTi4gSW4gZmFjdCB0 aGUgbW9zdCAiaGVhdnkiIHBhcnQgb2YgdGhlIGNvZGUgd2lsbCBub3QgYmUgdGhlIFhNTC9KU09O DQpKU09OJ3MgY29tcGFjdG5lc3MgYWR2YW50YWdlIG92ZXIgWE1MIGNhbm5vdCBtYWtlIGJpZyBk aWZmZXJlbmNlLCB0aGVuLg0KDQo+ICh3aGljaCB3aWxsIG1vc3QgbGlrZWx5IGJlIHVzZXMgYXMg YSB0ZW1wbGF0ZSBhbnl3YXkpIGJ1dCB0aGUgc2VjdXJpdHkNCj4gZnVuY3Rpb25hbGl0eS4NCkFn cmVlIQ0KSW4gdGhlIGxhc3QgbWVldGluZyBhdCBWYW5jb3V2ZXIsIG1hbnkgZGlzY3Vzc2lvbnMg b24gdGhlIFBBV1MgZnJhbWV3b3JrIGFyZSBhY3R1YWxseSBvbiBzZWN1cml0eSwgdHlwaWNhbGx5 IGF1dGhlbnRpY2F0aW9uIGJ5IGNlcnRpZmljYXRlIGFuZCBwcmUtc2hhcmVkIHNlY3JldCwgY3J5 cHRvLWJpbmRpbmcgb2YgcHJvdG9jb2xzIGluIGRpc3RpbmN0IGxheWVycywgZXRjLg0KRXZlbiBt b3JlIG5lZWQgdG8gYmUgZGlzY3Vzc2VkIHlldC4NCg0KQmVzdCBSZWdhcmRzLA0KWWFuZw0KPT09 PT09PT09PT09PT09PT09DQogWWFuZyBDdWksICBQaC5ELg0KIEh1YXdlaSBUZWNobm9sb2dpZXMN CiBjdWl5YW5nQGh1YXdlaS5jb20NCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBw YXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0N Cj4gSGFubmVzIFRzY2hvZmVuaWcNCj4gt6LLzcqxvOQ6IDIwMTLE6jjUwjI2yNUgMTU6MzUNCj4g ytW8/sjLOiBEYXMsIFN1YmlyDQo+ILOty806IHBhd3NAaWV0Zi5vcmc7IE1hbmlra290aCBTYWpl ZXYNCj4g1vfM4jogUmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmIGlD YWwNCj4gDQo+IEhpIGFsbCwNCj4gDQo+IEpTT04gYW5kIFhNTCBhcmUgdmVyeSBzaW1pbGFyIGlu IHRlcm1zIG9mIHN1cHBvcnRlZCB0b29scyBhbmQNCj4gYXZhaWxhYmlsaXR5IG9mIGNvZGUgaW4g bGFuZ3VhZ2VzLg0KPiANCj4gVGhlIG9ubHkgcXVlc3Rpb24gdG8gbWUgdGhhdCBhcmlzZXMgaXMg d2hldGhlciB5b3Ugd2FudCB0byByZS11c2UNCj4gZXhpc3RpbmcgcHJvdG9jb2wgd29yayAoc3Vj aCBhcyBMb1NULCB2Q2FyZCwgR01MLCBldGMuKS4gRG8geW91IGtub3cgdGhlDQo+IGFuc3dlciB0 byB0aGlzIHF1ZXN0aW9uPw0KPiANCj4gQ2lhbw0KPiBIYW5uZXMNCj4gDQo+IFBTOiBFbWJlZGRl ZCBkZXZpY2VzLCBNMk0sIEludGVybmV0IG9mIFRoaW5ncyBpbXBsZW1lbnRhdGlvbiAod2hhdGV2 ZXINCj4geW91IHdhbnQgdG8gY2FsbCB0aGVtKSB1c2UgYWxsIHNvcnRzIG9mIGVuY29kaW5ncywg aW5jbHVkaW5nIFhNTCBhbmQNCj4gSlNPTi4gSW4gZmFjdCB0aGUgbW9zdCAiaGVhdnkiIHBhcnQg b2YgdGhlIGNvZGUgd2lsbCBub3QgYmUgdGhlIFhNTC9KU09ODQo+ICh3aGljaCB3aWxsIG1vc3Qg bGlrZWx5IGJlIHVzZXMgYXMgYSB0ZW1wbGF0ZSBhbnl3YXkpIGJ1dCB0aGUgc2VjdXJpdHkNCj4g ZnVuY3Rpb25hbGl0eS4NCj4gDQo+IE9uIDA4LzI2LzIwMTIgMDQ6MzAgQU0sIERhcywgU3ViaXIg d3JvdGU6DQo+ID4gSXQgd291bGQgYmUgZ29vZCBpZiB5b3UgY2FuIHByb3ZpZGUgc29tZSBzcGVj aWZpYyBleGFtcGxlcyB3aGVyZSBKU09OIGlzDQo+ID4gcHJvYmxlbWF0aWMgYnV0IFhNTCBpcyBl YXNpZXIuDQo+ID4NCj4gPiAtU3ViaXINCj4gPg0KPiA+ICpGcm9tOipwYXdzLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddICpPbg0KPiBCZWhhbGYNCj4gPiBP ZiAqTWFuaWtrb3RoIFNhamVldg0KPiA+ICpTZW50OiogRnJpZGF5LCBBdWd1c3QgMjQsIDIwMTIg MTE6MTQgUE0NCj4gPiAqVG86KiBHYWJvci5CYWprb0Bub2tpYS5jb207IEJyaWFuLlJvc2VuQG5l dXN0YXIuYml6Ow0KPiBiZW5AYmxpbmRjcmVlay5jb20NCj4gPiAqQ2M6KiBwYXdzQGlldGYub3Jn DQo+ID4gKlN1YmplY3Q6KiBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJk ICYgaUNhbA0KPiA+DQo+ID4gSGksDQo+ID4NCj4gPiBJIHdvdWxkIHN0aWxsIHN1cHBvcnQgWE1M LiBKU09OIGxpYnJhcmllcyBhcmUgYXZhaWxhYmxlIGZvciBhbGwNCj4gPiBsYW5ndWFnZXMuIEJ1 dCBpbnRlcmZhY2luZyBhbmQgbGlua2luZyBzdWNoIGxpYnJhcmllcyBhcmUgcHJvYmxlbWF0aWMg b24NCj4gPiBlbWJlZGRlZCBkZXZpY2VzIG1vc3Qgb2YgdGhlIHRpbWUuIEFuZCBpZiBhbiBpbXBs ZW1lbnRhdGlvbiB2b3VjaCBmb3INCj4gPiBtdWx0aXBsZSBzdWNoIG5vbiBuYXRpdmUgbGFuZ3Vh Z2UgbGlicmFyaWVzIHRoZW4gZGV2ZWxvcGVycyBsaWZlIGlzIGhlbGwuLi4NCj4gPg0KPiA+IC9C ZXN0IFJlZ2FyZHMsLw0KPiA+DQo+ID4gL1NhamVldiBNYW5pa2tvdGgvDQo+ID4NCj4gPiAqRnJv bToqIkdhYm9yLkJhamtvQG5va2lhLmNvbSA8bWFpbHRvOkdhYm9yLkJhamtvQG5va2lhLmNvbT4i DQo+ID4gPEdhYm9yLkJhamtvQG5va2lhLmNvbSA8bWFpbHRvOkdhYm9yLkJhamtvQG5va2lhLmNv bT4+DQo+ID4gKlRvOiogQnJpYW4uUm9zZW5AbmV1c3Rhci5iaXogPG1haWx0bzpCcmlhbi5Sb3Nl bkBuZXVzdGFyLmJpej47DQo+ID4gYmVuQGJsaW5kY3JlZWsuY29tIDxtYWlsdG86YmVuQGJsaW5k Y3JlZWsuY29tPg0KPiA+ICpDYzoqIHBhd3NAaWV0Zi5vcmcgPG1haWx0bzpwYXdzQGlldGYub3Jn Pg0KPiA+ICpTZW50OiogU2F0dXJkYXksIDI1IEF1Z3VzdCAyMDEyLCAwOjM4DQo+ID4gKlN1Ympl Y3Q6KiBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJkICYgaUNhbA0KPiA+ DQo+ID4gV2lGaSB3b3JsZCBidWlsZHMgb24gbWFuZGF0aW5nIHRoZSBpbXBsZW1lbnRhdGlvbiAo YW5kIGNlcnRpZmljYXRpb24pIG9mDQo+ID4gYSBiYXNlIHNwZWMsIGFuZCBhIHNldCBvZiBvcHRp b25hbCBmZWF0dXJlcy4gSWYgYW4gb3B0aW9uYWwgZmVhdHVyZSBpcw0KPiA+IG5vdCBzdXBwb3J0 ZWQgYnkgb25lIG9mIHRoZSBwZWVycywgdGhleSBjYW4gc3RpbGwgdGFsaywgYnV0IG5vdCB1c2Ug dGhhdA0KPiA+IGZlYXR1cmUuIFRoYXQgaXMgYmFzaWNhbGx5IG9wdGlvbiBCKSBmcm9tIEJyYWlu oa9zIGxpc3QuDQo+ID4NCj4gPiBJoa9kIGxpa2UgdG8gc3VnZ2VzdCB0aGF0IHdlIHJlY29nbml6 ZSB0aGF0IG9wdGlvbiBBKSBhbmQgQikgYXJlIHZhbGlkDQo+ID4gb3B0aW9ucywgd2hpbGUgb3B0 aW9uIEMpIGlzIGludmFsaWQsIGFuZCB3ZSBzaG91bGQgc3RvcCBkZWJhdGluZyBpdC4NCj4gPg0K PiA+IEmhr2QgYWxzbyBsaWtlIHRvIGFkZCB0aGUgb2J2aW91cyBvcHRpb24gRCkgdG8gdGhlIGxp c3QsIHdoaWNoIGlzIHRoYXQNCj4gPiBib3RoIHRoZSBtYXN0ZXIgZGV2aWNlcyBhbmQgREJzIHN1 cHBvcnQgb25lIGFuZCB0aGUgc2FtZSBlbmNvZGluZyA7KQ0KPiA+DQo+ID4gT3B0aW9uIEEpIHNl ZW1zIHRvIGJlIGxpa2UgYSBnb29kIGNvbXByb21pc2UsIGFuZCB3b3VsZCBjdXQgZGlzY3Vzc2lv bnMNCj4gPiBzaG9ydCwgd2l0aCB0aGUgb25seSBjYXZlYXQgdGhhdCBpZiB0aGVyZSBpcyBubyBz dHJvbmcgdGVjaG5pY2FsDQo+ID4gYXJndW1lbnQgZm9yIHN1cHBvcnRpbmcgYW5kIHNwZWNpZnlp bmcgdHdvIGRpZmZlcmVudCBlbmNvZGluZ3MsIHRoZW4gdGhlDQo+ID4gaWVzZyBtYXkgc2VuZCB0 aGUgZG9jdW1lbnQgYmFjayB0byB0aGUgd2cgdG8gcGljayBvbmUgb2YgdGhlIHR3bw0KPiA+IHNw ZWNpZmllZC4gQXMgUm9iZXJ0IG1lbnRpb25lZCBpbiBoaXMgZW1haWwsIHRoaXMgaGFzIGhhcHBl bmVkIGluIHRoZQ0KPiA+IHBhc3QsIHNvIGl0IGlzIGxpa2VseSBpdCB3b3VsZCBoYXBwZW4gYWdh aW4uIEFuZCBmcmFua2x5LCBJIGRvIG5vdCBzZWUgYQ0KPiA+IHN0cm9uZyBhcmd1bWVudCBpbiBm YXZvciBvZiB0d28gZGlmZmVyZW50IGVuY29kaW5ncy4NCj4gPg0KPiA+IElzIHRoZXJlIGFueW9u ZSB3aG8gaGFzIGEgdGVjaG5pY2FsIGFyZ3VtZW50IGFnYWluc3Qgc3VwcG9ydGluZyBvbmx5IG9u ZQ0KPiA+IGVuY29kaW5nLCBiZWluZyB0aGF0IGVpdGhlciB4bWwgb3IganNvbj8NCj4gPg0KPiA+ IE1vc3QgcGVvcGxlIHNwZWFrIGluIGZhdm9yIG9mIEpTT04sIGJlY2F1c2UgaXQgaXMgY29tcGFj dCBhbmQgbW9yZQ0KPiA+IGVmZmljaWVudC4gSSB3ZW50IHRocm91Z2ggdGhpcyB0aHJlYWQgYW5k IEkgc2F3IDIgb2JqZWN0aW9ucyBhZ2FpbnN0DQo+ID4gcGlja2luZyBKU09OLiBPbmUgc2FpZCB0 aGF0IEpTT04gcmVxdWlyZXMgbmF0aXZlIEphdmEsIHdoaWNoIGlzIHdyb25nLA0KPiA+IHRoZSBv dGhlciBvYmplY3Rpb24gZ2F2ZSBubyByZWFsIHJlYXNvbi4gU28gSSBhbSB3b25kZXJpbmcgaWYg dGhlcmUgaXMNCj4gPiByZWFsbHkgYW55IHZhbGlkIHRlY2huaWNhbCByZWFzb24gYWdhaW5zdCB1 c2luZyBKU09OIG9ubHk/DQo+ID4NCj4gPiAtICAgICAgICAgIEdhYm9yDQo+ID4NCj4gPiAqRnJv bToqcGF3cy1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnPg0K PiA+IFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpleHQgUm9z ZW4sIEJyaWFuDQo+ID4gKlNlbnQ6KiBGcmlkYXksIEF1Z3VzdCAyNCwgMjAxMiAxMDo0MyBBTQ0K PiA+ICpUbzoqIEJlbmphbWluIEEuIFJvbGZlDQo+ID4gKkNjOiogcGF3c0BpZXRmLm9yZyA8bWFp bHRvOnBhd3NAaWV0Zi5vcmc+DQo+ID4gKlN1YmplY3Q6KiBSZTogW3Bhd3NdIFhNTCBzY2hlbWEg dmVyc3VzIEpTT04sIHZDYXJkICYgaUNhbA0KPiA+DQo+ID4gT2theToNCj4gPg0KPiA+IFNvLCBJ IGltcGxlbWVudCBhIGRhdGFiYXNlLCBhbmQgSSBpbXBsZW1lbnQgWE1MDQo+ID4NCj4gPiBZb3Ug aW1wbGVtZW50IGEgZGV2aWNlLCBhbmQgeW91IGltcGxlbWVudCBKU09ODQo+ID4NCj4gPiBZb3Ug cXVlcnkgbXkgZGF0YWJhc2UgKGxldCdzIG5vdCBnZXQgaW50byBob3cgeW91IGRvIHRoYXQgcXVl cnkgd2l0aG91dA0KPiA+IGRlY2lkaW5nIFhNTCB2cyBKU09OKSBhbmQgZGlzY292ZXIgSSBpbXBs ZW1lbnQgWE1MIG9ubHkNCj4gPg0KPiA+IFdoYXQgZG8geW91IGRvPw0KPiA+DQo+ID4gQnJpYW4N Cj4gPg0KPiA+IE9uIEF1ZyAyNCwgMjAxMiwgYXQgMTozOCBQTSwgIkJlbmphbWluIEEuIFJvbGZl IiA8YmVuQGJsaW5kY3JlZWsuY29tDQo+ID4gPG1haWx0bzpiZW5AYmxpbmRjcmVlay5jb20+PiB3 cm90ZToNCj4gPg0KPiA+IFRoZXJlIGFyZSB0d28gd2F5cyB0byBhY2hpZXZlIGludGVyb3BlcmFi aWxpdHkgd2hlbiB5b3UgaGF2ZSBhbiBvcHRpb24uDQo+ID4NCj4gPiBUaGVyZSBhcmUgbWFueSBl eGlzdGVuY2UgcHJvb2ZzIG9mIHRoZSB0aGlyZCB3YXkgdGhhdCBJIG1lbnRpb25lZCBiZWxvdy4N Cj4gPiA4MDIuMTEgKyBXaUZpIHByb3ZpZGUgbWFueSBvcHRpb25zIGFuZCBhIG1lYW5zIGZvciBk ZXZpY2VzIHRvIHNoYXJlDQo+ID4gaW5mb3JtYXRpb24gYWJvdXQgd2hhdCBvcHRpb25zIGVhY2gg c3VwcG9ydHMsIHdpdGhvdXQgcmVxdWlyaW5nIHRoYXQgYW55DQo+ID4gZGV2aWNlIGltcGxlbWVu dCBldmVyeSBvcHRpb24uICBJdCB3b3Jrcy4NCj4gPg0KPiA+IFRoYXQgc2FpZCwgSSB0aGluayAo QSkgaXMgdGhlIGJlc3QgY2hvaWNlLCAoQikgaXMgbm90IGFzIG5pY2UgZm9yIG1lLA0KPiA+IGFu ZCAoQykgaXMgbW9yZSB3b3JrIHRoYW4gZWl0aGVyIG9mIHRoZSBvdGhlciB0d28uDQo+ID4NCj4g PiBPbmUgaXMgdGhhdCBvbmUgZW5kIGltcGxlbWVudHMgYm90aCBjaG9pY2VzIGFuZCB0aGUgb3Ro ZXIgZW5kDQo+IGltcGxlbWVudHMNCj4gPiBvbmUgb3IgYm90aC4NCj4gPg0KPiA+IFRoZSBvdGhl ciBpcyB0aGF0IGJvdGggZW5kcyBpbXBsZW1lbnQgb25lIHNwZWNpZmljIGNob2ljZSAoIk1VU1QN Cj4gPiBpbXBsZW1lbnQiKSBhbmQgYm90aCBjYW4gb3B0aW9uYWxseSBpbXBsZW1lbnQgdGhlIG90 aGVyIGNob2ljZS4gIE9ubHkgaWYNCj4gPiBib3RoIGVuZHMgaW1wbGVtZW50IHRoZSBvdGhlciBj aG9pY2Ugd291bGQgdGhhdCBiZSBhdmFpbGFibGUuDQo+ID4NCj4gPiBTbywgaW4gdGhpcyBjYXNl IHdlIGNvdWxkIGRvIG9uZSBvZiB0aGUgZm9sbG93aW5nOg0KPiA+DQo+ID4gQSkgRGF0YWJhc2Vz IGltcGxlbWVudCBib3RoIFhNTCBhbmQgSlNPTiwgZGV2aWNlcyBpbXBsZW1lbnQgZWl0aGVyDQo+ ID4NCj4gPiBCKSBCb3RoIERhdGFiYXNlcyBhbmQgZGV2aWNlcyBpbXBsZW1lbnQgb25lIChzYXkg WE1MKSBhbmQgb3B0aW9uYWxseQ0KPiA+IGltcGxlbWVudCB0aGUgb3RoZXIgKHNheSBKU09OKQ0K PiA+DQo+ID4gWW91IGFyZSBhZHZvY2F0aW5nIGZvciBBLCBSaWNoYXJkIHdhcyBzdWdnZXN0aW5n IEIuDQo+ID4NCj4gPiBJIGRvbid0IGNhcmUsIGJ1dCBjaG9pY2UgQykgQm90aCBkYXRhYmFzZXMg YW5kIGRldmljZXMgaGF2ZSBhIGNob2ljZSBvZg0KPiA+IHdoYXQgdG8gaW1wbGVtZW50IGRvZXNu J3Qgd29yayBmb3IgbWUgKG9yIFJpY2hhcmQpLg0KPiA+DQo+ID4gQnJpYW4NCj4gPg0KPiA+IE9u IEF1ZyAyNCwgMjAxMiwgYXQgMTI6NTcgUE0sIEJlbmphbWluIEEuIFJvbGZlIDxiZW5AYmxpbmRj cmVlay5jb20NCj4gPiA8bWFpbHRvOmJlbkBibGluZGNyZWVrLmNvbT4+IHdyb3RlOg0KPiA+DQo+ ID4gQXBwYXJlbnRseSBJIHdhcyB1bmNsZWFyLiAgSSBjZXJ0YWlubHkgYW4gY2FwYWJsZSBvZiBi ZWluZyB3cm9uZyBhcyBJDQo+ID4gcHJhY3RpY2Ugb2Z0ZW4sIGJ1dCBpbiB0aGlzIGNhc2UgaXQg aXMgcXVpdGUgdW5saWtlbHkgOi0pLg0KPiA+DQo+ID4gWW91IGRvIG5vdCBuZWVkIHRvIGNob29z ZSBvbmx5IG9uZSBmb3JtIHRvIGFjaGlldmUgaW50ZXJvcGVyYWJpbGl0eS4NCj4gPiBJZiB5b3Ug aGF2ZSB0d28sIGxldCB0aGUgZGV2aWNlIGltcGxlbWVudGVyIGZpZ3VyZSBvdXQgd2hpY2ggaXMg YmVzdCBmb3INCj4gPiB0aGVpciBwYXJ0aWN1bGFyIGRldmljZSByZXF1aXJlbWVudHMgYW5kIHRy YWRlLW9mZnMuICBUaGlzIGlzDQo+ID4gKnByZWZlcmFibGUqIGZyb20gbXkgcGVyc3BlY3RpdmUu DQo+ID4NCj4gPiBJZiB5b3UgcHJvdmlkZSBtb3JlIHRoYW4gb25lIGZvcm0gaW4gdGhlIGRhdGFi YXNlLCBkZXZpY2VzIHVzaW5nIHRoZQ0KPiA+IGRhdGFiYXNlIG5lZWQgc29tZSBtZWFucyBmb3Ig ZmlndXJpbmcgb3V0IHdoaWNoIGFyZSBhdmFpbGFibGUuIEl0IGNhbid0DQo+ID4gdXNlIGl0IGlm IGl0IGRvZXNuJ3Qgbm8gYWJvdXQgaXQuIFRoaXMgaXMgYW4gb2JzZXJ2YXRpb25zLCBub3QgYW4N Cj4gPiBhcmd1bWVudCA7LSkuDQo+ID4NCj4gPiBJdCBpcyBteSAqb3BpbmlvbiogYXQgdGhlICBt b21lbnQgdGhhdCBpZiB5b3UgcHJvdmlkZSBvcHRpb25zLCB0byBtYWtlDQo+ID4gdGhvc2UgdXNl ZnVsIHlvdSBuZWVkIHRvIHByb3ZpZGUgIGEgcHJvdG9jb2wgYnkgd2hpY2ggZGV2aWNlcyBjYW4N Cj4gPiBkaXNjb3ZlciB3aGF0IG9wdGlvbnMgdGhlIGRhdGFiYXNlIHN1cHBvcnRzLiAgSWYgeW91 IGhhdmUgc3VjaCBhDQo+ID4gbWVjaGFuaXNtIGFuZCBhbGwgZGV2aWNlcyB1c2UgaXQgKGEgIGJv b3RzdHJhcCBwcm90b2NvbCksIGV2ZXJ5dGhpbmcNCj4gPiBlbHNlIGNvdWxkIGJlIG9wdGlvbnMu ICBUaGlzIHJlcXVpcmVzIGFkZGl0aW9uYWwgZnVuY3Rpb25zIGluIGJvdGgNCj4gPiBkYXRhYmFz ZSBhbmQgZGV2aWNlIGltcGxlbWVudGF0aW9ucy4NCj4gPiBJZiBvbiB0aGUgb3RoZXIgaGFuZCB0 aGUgZGV2aWNlIGNhbiAianVzdCBrbm93IiB0aGF0IHRoZSBkYXRhYmFzZSBoYXMNCj4gPiB0d28g Zm9ybXMgYXZhaWxhYmxlLCBpdCB3b24ndCBuZWVkIHRvIGR5bmFtaWNhbGx5IGZpZ3VyZSBpdCBv dXQuIFRoZQ0KPiA+IGRldmljZSBpbXBsZW1lbnRlciBoYXMgb3B0aW9ucyBhbmQgc2ltcGxpY2l0 eSwgc28gSSBsaWtlIGl0Lg0KPiA+DQo+ID4gU2luY2UgSSBhbSBmb2N1c2VkIG9uIHRoZSBUVldT IGRldmljZXMgdGhhdCBuZWVkIGFjY2VzcyB0byB0aGUgZGF0YWJhc2UsDQo+ID4gYW5kIG5vdCBh IGRhdGFiYXNlIGltcGxlbWVudGVyLCBzaGlmdGluZyBidXJkZW4gb250byB0aGUgZGF0YWJhc2UN Cj4gPiBpbXBsZW1lbnRlciAobm90IG1lKSB0byByZWR1Y2UgdGhlIGJ1cmRlbiBvbiB0aGUgZGV2 aWNlIGltcGxlbWVudGVyDQo+IChtZSkNCj4gPiBpcyBwcmVmZXJyZWQgZnJvbSBteSBwZXJzcGVj dGl2ZS4gIFRoZSBkYXRhYmFzZSBpbXBsZW1lbnRlciBtYXkgaGF2ZQ0KPiA+IGFub3RoZXIgcGVy c3BlY3RpdmUuICBTaG91bGQgSSBwb2ludCBvdXQgdGhhdCB0aGVyZSB3aWxsIGJlIGEgbG90IG1v cmUNCj4gPiBkZXZpY2VzIHRoYW4gZGF0YWJhc2VzPyAgVGhhdCBtaWdodCBzb3VuZCBsaWtlIGFu IGFyZ3VtZW50LCB0aG91Z2gsIHNvIEkNCj4gPiB3b24ndC4uLi46LWoNCj4gPg0KPiA+IEJlbg0K PiA+DQo+ID4gQnJpYW4gaXMgcmlnaHQgLi4gc29ycnkgYnV0IHRoZSByZXN0IG9mIHlvdSBhcmUg d3JvbmcuIEoNCj4gPg0KPiA+IFRoaXMgaXMgd2h5IHlvdSBoYXZlIE1VU1QgYW5kIFNIT1VMRCBp biBSRkMgMjExOS4NCj4gPg0KPiA+IFRoaXMgQlRXIGlzIGEgY2xhc3NpYyBhcmd1bWVudCBpbiBJ RVRGIHRlcm1zIC4uIGJ1dCB0aGUgYXJndW1lbnQgobBsZXQNCj4gPiB0aGUgbWFya2V0IGRlY2lk ZaGxIG9ubHkgaG9sZHMgc28gbXVjaCB2YWxpZGl0eS4gIFlvdSBhY3R1YWxseSBoYXZlIHRvDQo+ ID4gY2hvb3NlIFNPTUVUSElORyB0byBjcmVhdGUgYSBiYXNlbGluZSBvZiBpbnRlcm9wZXJhYmls aXR5Lg0KPiA+DQo+ID4gQSB2aXJ0dWFsbHkgaWRlbnRpY2FsIGFyZ3VtZW50ICBpcyBub3cgcGxh eWluZyBvdXQgaW4gZGlzY3Vzc2lvbnMgb2YNCj4gPiBtYW5kYXRvcnkgYXVkaW8gYW5kIGNvZGVj IGltcGxlbWVudGF0aW9ucyBmb3IgV0VCUlRDIGxpa2UgdGhpbmdzLg0KPiA+DQo+ID4gSU1ITyBY TUwgTVVTVCBhbnl0aGluZyBlbHNlIGRlZmluZWQgU0hPVUxELCBidXQgTVVTVCBvbiBYTUwgYW5k DQo+IEpTT04NCj4gPiBjb3VsZCB3b3JrIGFzIHdlbGwuIEl0IGp1c3QgbGVhZHMgdG8gYSBsZXZl bCBvZiBjb21wbGV4aXR5IGluDQo+ID4gaW1wbGVtZW50YXRpb25zLg0KPiA+DQo+ID4gRW5kIG9m IGFyZ3VtZW50IHlvdSBub3cgY2FuIGdvIGJhY2sgdG8geW91ciByZWd1bGFybHkgc2NoZWR1bGUN Cj4gPiBwcm9ncmFtbWluZy4gSg0KPiA+DQo+ID4gKkZyb206KnBhd3MtYm91bmNlc0BpZXRmLm9y ZyA8bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZz4NCj4gPiBbbWFpbHRvOnBhd3MtYm91bmNl c0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbQ0KPiA+ IDxtYWlsdG86QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbT4NCj4gPiAqU2VudDoqIFRodXJzZGF5 LCBBdWd1c3QgMjMsIDIwMTIgNTo0NCBQTQ0KPiA+ICpUbzoqIEJyaWFuLlJvc2VuQG5ldXN0YXIu Yml6IDxtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo+Ow0KPiA+IGQuam9zbHluQHNwZWN0 cnVtYnJpZGdlLmNvbSA8bWFpbHRvOmQuam9zbHluQHNwZWN0cnVtYnJpZGdlLmNvbT4NCj4gPiAq Q2M6KiBwYXdzQGlldGYub3JnIDxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCj4gPiAqU3ViamVjdDoq IFJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJiBpQ2FsDQo+ID4NCj4g PiBJIGFncmVlIHdpdGggQnJpYW4uDQo+ID4NCj4gPiBUaGVyZSBuZWVkcyB0byBiZSBhIGRlZmF1 bHQgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBvcHRpb24gaW4gb3JkZXIgdG8NCj4gPiBhY2hpZXZl IGludGVyb3BlcmFiaWxpdHkuDQo+ID4NCj4gPiBBbmQgdGhpcyBhcHBsaWVzIHRvIHRoZSBkZXZp Y2UgYW5kIGRhdGFiYXNlIHNpZGUgb2YgdGhlIHByb3RvY29sLg0KPiA+DQo+ID4gLVJhag0KPiA+ DQo+ID4gKkZyb206ICoiPGV4dCBSb3Nlbj4iLCAiQnJpYW4uUm9zZW5AbmV1c3Rhci5iaXoNCj4g PiA8bWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PiIgPEJyaWFuLlJvc2VuQG5ldXN0YXIu Yml6DQo+ID4gPG1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej4+DQo+ID4gKkRhdGU6ICpU aHVyc2RheSwgQXVndXN0IDIzLCAyMDEyIDI6NDMgUE0NCj4gPiAqVG86ICpEb24gSm9zbHluIDxk Lmpvc2x5bkBzcGVjdHJ1bWJyaWRnZS5jb20NCj4gPiA8bWFpbHRvOmQuam9zbHluQHNwZWN0cnVt YnJpZGdlLmNvbT4+DQo+ID4gKkNjOiAqInBhd3NAaWV0Zi5vcmcgPG1haWx0bzpwYXdzQGlldGYu b3JnPiIgPHBhd3NAaWV0Zi5vcmcNCj4gPiA8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+Pg0KPiA+ICpT dWJqZWN0OiAqUmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmIGlDYWwN Cj4gPg0KPiA+IE9uZSBvZiBteSBmYXZvcml0ZSBJRVRGIGV4cHJlc3Npb25zIGlzICJUaGVyZSBh cmUgbm8gcHJvdG9jb2wgcG9saWNlIi4NCj4gPiAgIFdlIGFwcGx5IHRoYXQgaW4gbG90cyBvZiB3 YXlzLCBidXQgb25lIG9mIHRoZW0gaXMgdGhhdCBpZiB5b3UgZG9uJ3QNCj4gPiBpbXBsZW1lbnQg d2hhdCB0aGUgZG9jdW1lbnQgc2F5cywgeW91IG1heSBub3QgZ2V0IGludGVyb3BlcmFiaWxpdHkg d2l0aA0KPiA+IG90aGVyIGltcGxlbWVudGF0aW9ucy4gIE9uIHRoZSBvdGhlciBoYW5kLCB0aGUg d2hvbGUgcG9pbnQgb2YgYSBwcm90b2NvbA0KPiA+IGRvY3VtZW50IGxpa2Ugb3VycyBpcyB0aGF0 IHR3byBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMgd2hvIGJvdGgNCj4gPiBmb2xsb3cgdGhl IGRvY3VtZW50IHdpbGwgaW50ZXJ3b3JrLiAgSWYgdGhhdCB3YXNuJ3QgdHJ1ZSwgd2h5IGRvIHlv dQ0KPiA+IG5lZWQgYSBzdGFuZGFyZD8NCj4gPg0KPiA+IElmIHlvdSBzYXkgImVpdGhlciIgdG8g Ym90aCBlbmRzLCB0aGVuIHlvdSBkb24ndCBnZXQgaW50ZXJvcGVyYWJpbGl0eS4NCj4gPg0KPiA+ IEJ5IHlvdXIgYXJndW1lbnQsIHdlIHNob3VsZCBzdG9wIHdvcmtpbmcsIGFuZCB0aGUgcHJvZHVj dCBtYW5hZ2VycyB3aWxsDQo+ID4gZmlndXJlIGl0IG91dCB1c2luZyBwcm9wcmlldGFyeSBwcm90 b2NvbHMuICBUaGUgbWFya2V0IHdpbGwgZGVjaWRlLg0KPiA+DQo+ID4gU28sIEkgZmVlbCBzdHJv bmdseSB0aGF0IGlmIG9uZSBlbmQgaXMgImVpdGhlciIsIHRoZSBvdGhlciBlbmQgbXVzdCBiZQ0K PiA+ICJib3RoIi4gIEl0J3MgYWxzbyBhY2NlcHRhYmxlIHRvIHNheSBib3RoIGVuZHMgaW1wbGVt ZW50IG9uZSBjaG9pY2UgYW5kDQo+ID4gdGhlIG90aGVyIGlzIG9wdGlvbmFsIGF0IGJvdGggZW5k cy4gIEhlcmUsIEkgdGhpbmsgaXQncyBzZXJ2ZXIgZG9lcyBib3RoDQo+ID4gYW5kIGNsaWVudCBk b2VzIGVpdGhlci4NCj4gPg0KPiA+IEl0J3MgYWx3YXlzIHBvc3NpYmxlIHRvIGJ1aWxkIGFuIGlt cGxlbWVudGF0aW9uIG9mIGEgc2VydmVyIHRoYXQgb25seQ0KPiA+IGRvZXMgb25lOiB0aGVyZSBh cmUgbm8gcHJvdG9jb2wgcG9saWNlLg0KPiA+DQo+ID4gQnJpYW4gPGFzIGluZGl2aWR1YWw+DQo+ ID4NCj4gPiBPbiBBdWcgMjMsIDIwMTIsIGF0IDM6MTEgUE0sIERvbiBKb3NseW4gPGQuam9zbHlu QHNwZWN0cnVtYnJpZGdlLmNvbQ0KPiA+IDxtYWlsdG86ZC5qb3NseW5Ac3BlY3RydW1icmlkZ2Uu Y29tPj4gd3JvdGU6DQo+ID4NCj4gPg0KPiA+DQo+ID4gSGkgQmVuLA0KPiA+DQo+ID4gVGhhdCB3 YXMgbXkgb3JpZ2luYWwgc3VnZ2VzdGlvbiwgYW5kIEkgc3RpbGwgdGhpbmsgaXQgbWFrZXMgdGhl IG1vc3Qgc2Vuc2UuDQo+ID4NCj4gPiBUaGFua3MgZm9yIHN1cHBvcnRpbmcgdGhlIHByb3Bvc2Fs Lg0KPiA+DQo+ID4gRG9uDQo+ID4NCj4gPiAqRnJvbToqcGF3cy1ib3VuY2VzQGlldGYub3JnIDxt YWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnPg0KPiA+IFttYWlsdG86cGF3cy1ib3VuY2VzQGll dGYub3JnIDxtYWlsdG86Ym91bmNlc0BpZXRmLm9yZz5dKk9uIEJlaGFsZg0KPiA+IE9mKkJlbmph bWluIEEuIFJvbGZlDQo+ID4gKlNlbnQ6KlRodXJzZGF5LCBBdWd1c3QgMjMsIDIwMTIgMzowNSBQ TQ0KPiA+ICpUbzoqcGF3c0BpZXRmLm9yZyA8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQo+ID4gKlN1 YmplY3Q6KlJlOiBbcGF3c10gWE1MIHNjaGVtYSB2ZXJzdXMgSlNPTiwgdkNhcmQgJiBpQ2FsDQo+ ID4NCj4gPiBTb21lb25lIHN1Z2dlc3RlZCB0aGF0IFBBV1MgZGVmaW5lIGJvdGgsIGFuZCBsZXQg dGhlIHZlbmRvcnMgZGVjaWRlDQo+ID4gd2hpY2ggb25lcyB0byBpbXBsZW1lbnQuDQo+ID4gVGhh dCBtYWtlcyB0aGUgbW9zdCBzZW5zZSBmb3IgYm90aCBEQiBhbmQgZGV2aWNlIHZlbmRvcnMuICBN YXJrZXRzIHdpbGwNCj4gPiBwcm9iYWJseSBkcml2ZSBEQiB2ZW5kb3JzIHRvIGRvIGJvdGguIERl dmljZSB2ZW5kb3JzIHdpbGwgZG8gd2hhdCBmaXRzDQo+ID4gdGhlIG1hcmtldCBzZWdtZW50IHRo ZXkncmUgYWZ0ZXIuIFdoeSBvdmVyLWNvbnN0cmFpbiAob3IgYXJndWUgd2hlbg0KPiA+IG5hdHVy YWwgc2VsZWN0aW9uIHdpbGwgdGFrZSBjYXJlIG9mIGl0IGZvciB1cz8pLg0KPiA+IEINCj4gPg0K PiA+DQo+ID4gU291bmRzIGdvb2QgdG8gbWUuDQo+ID4NCj4gPiAqRnJvbToqcGF3cy1ib3VuY2Vz QGlldGYub3JnDQo+ID4gPG1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+W21haWx0bzpwYXdz LWJvdW5jZXNAaWV0Zi5vcmddKk9uDQo+IEJlaGFsZg0KPiA+IE9mKkdhYm9yLkJhamtvQG5va2lh LmNvbSA8bWFpbHRvOkdhYm9yLkJhamtvQG5va2lhLmNvbT4NCj4gPiAqU2VudDoqVHVlc2RheSwg QXVndXN0IDIxLCAyMDEyIDEyOjQyIEFNDQo+ID4gKlRvOipwYXdzQGlldGYub3JnIDxtYWlsdG86 cGF3c0BpZXRmLm9yZz4NCj4gPiAqU3ViamVjdDoqUmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1 cyBKU09OLCB2Q2FyZCAmIGlDYWwNCj4gPg0KPiA+IE5vdyBJIGNhbqGvdCBzZWUgYW55bW9yZSBh bnkgd2lsbGluZ25lc3MgdG8gYWdyZWUgb24gb25lIG9yIHRoZSBvdGhlcg0KPiA+IGVuY29kaW5n Lg0KPiA+DQo+ID4gVG8gcHJldmVudCBlbmRsZXNzIGRpc2N1c3Npb25zIG9uIHRoaXMgdG9waWMg SaGvZCBzdWdnZXN0IHdlIG1vdmUgZm9yd2FyZA0KPiA+IHdpdGggc3VwcG9ydGluZyBib3RoIGlu IHRoZSBEQiBhbmQgZWl0aGVyIG9uZSBpbiB0aGUgbWFzdGVyIGRldmljZS4NCj4gPg0KPiA+IEFu eSBvYmplY3Rpb25zPw0KPiA+DQo+ID4gR2Fib3INCj4gPg0KPiA+ICpGcm9tOipwYXdzLWJvdW5j ZXNAaWV0Zi5vcmcNCj4gPiA8bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZz5bbWFpbHRvOnBh d3MtYm91bmNlc0BpZXRmLm9yZ10qT24NCj4gQmVoYWxmDQo+ID4gT2YqZXh0IERhcywgU3ViaXIN Cj4gPiAqU2VudDoqTW9uZGF5LCBBdWd1c3QgMjAsIDIwMTIgMjo1MCBQTQ0KPiA+ICpUbzoqRG9u IEpvc2x5bjsgVmluY2VudCBDaGVuOyBXZWl4aW5wZW5nDQo+ID4gKkNjOipwYXdzQGlldGYub3Jn IDxtYWlsdG86cGF3c0BpZXRmLm9yZz47IE1hbmlra290aCBTYWplZXYNCj4gPiAqU3ViamVjdDoq UmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmIGlDYWwNCj4gPg0KPiA+ IFdlIGhhdmUgYSBoYWxmIGEgZG96ZW4gb3IgbW9yZSBUVkRCIHJhZGlvIHZlbmRvcnMgdGhhdCB1 c2UvcHJlZmVyIEpTT04NCj4gPiBhbmQgd2Ugd2lsbCB2b3RlIGZvciBKU09OIGlmIHdlIGhhZCB0 byBwaWNrIG9uZS4NCj4gPg0KPiA+IEFsc28gSSB3aWxsIGNvcHkgdGhlIGZvbGxvd2luZyB0d28g aW1wb3J0YW50IHBvaW50czoNCj4gPg0KPiA+ICAgICAgIG8gU2ltcGxlLXRvLXVzZSBsaWJyYXJp ZXMgZXhpc3QgZm9yIGFsbCBtYWpvciBsYW5ndWFnZXMvcGxhdGZvcm1zDQo+ID4gICAgICAgbyBE b24ndCBuZWVkIGEgdG9vbCBjaGFpbiB0byB3b3JrIHdpdGggdGhlIGRhdGEsIGFzIGlzIHR5cGlj YWxseQ0KPiA+ICAgICAgICAgbmVlZGVkIGZvciBYTUwNCj4gPg0KPiA+ICpGcm9tOipwYXdzLWJv dW5jZXNAaWV0Zi5vcmcNCj4gPiA8bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZz5bbWFpbHRv OnBhd3MtYm91bmNlc0BpZXRmLm9yZ10NCj4gPiA8bWFpbHRvOlttYWlsdG86cGF3cy1ib3VuY2Vz QGlldGYub3JnXT4qT24gQmVoYWxmIE9mKkRvbiBKb3NseW4NCj4gPiAqU2VudDoqTW9uZGF5LCBB dWd1c3QgMjAsIDIwMTIgNDo1NCBQTQ0KPiA+ICpUbzoqVmluY2VudCBDaGVuOyBXZWl4aW5wZW5n DQo+ID4gKkNjOipwYXdzQGlldGYub3JnIDxtYWlsdG86cGF3c0BpZXRmLm9yZz47IE1hbmlra290 aCBTYWplZXYNCj4gPiAqU3ViamVjdDoqUmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09O LCB2Q2FyZCAmIGlDYWwNCj4gPg0KPiA+IFBsZWFzZSBzZWUgbXkgY29tbWVudHMgYmVsb3ehrQ0K PiA+DQo+ID4gVGhhbmtzLA0KPiA+DQo+ID4gRG9uDQo+ID4NCj4gPiAqRnJvbToqcGF3cy1ib3Vu Y2VzQGlldGYub3JnDQo+ID4gPG1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+W21haWx0bzpw YXdzLWJvdW5jZXNAaWV0Zi5vcmddKk9uDQo+IEJlaGFsZg0KPiA+IE9mKlZpbmNlbnQgQ2hlbg0K PiA+ICpTZW50OipNb25kYXksIEF1Z3VzdCAyMCwgMjAxMiAyOjU2IFBNDQo+ID4gKlRvOipXZWl4 aW5wZW5nDQo+ID4gKkNjOipwYXdzQGlldGYub3JnIDxtYWlsdG86cGF3c0BpZXRmLm9yZz47IE1h bmlra290aCBTYWplZXYNCj4gPiAqU3ViamVjdDoqUmU6IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1 cyBKU09OLCB2Q2FyZCAmIGlDYWwNCj4gPg0KPiA+ICAgKiBPbmUgb2Ygb3VyIGdvYWxzIGlzIHRv IHN0cml2ZSB0byBsb3dlciB0aGUgY29zdCBhbmQgY29tcGxleGl0eSBmb3INCj4gPiAgICAgZGV2 aWNlIG1hbnVmYWN0dXJlcnMuIFRoaXMgbG93ZXJzIHRoZSBiYXJyaWVyIGZvciBidWlsZGluZyBh IHJvYnVzdA0KPiA+ICAgICBlY29zeXN0ZW0uDQo+ID4NCj4gPiBbREogLSBUaGUgobBjb3N0obEg YW5kIGNvbXBsZXhpdHkgb2YgdXNpbmcgWE1MIGhhcyBub3QgYmVlbiBhbiBpc3N1ZSBmb3INCj4g PiB0aGUgaGFsZiBkb3plbiBUVkJEIHZlbmRvcnMgdGhhdCBoYXZlIGFscmVhZHkgdXNlZCBYTUwu IE1heWJlIHdlIG5lZWQNCj4gdG8NCj4gPiBiZXR0ZXIgZGVmaW5lIKGwY29zdKGxP10NCj4gPg0K PiA+ICAgKiBUbyByZWR1Y2UgY29tcGxleGl0eSBhbmQgY29zdCBmb3IgZGV2aWNlIG1ha2Vycywg c3VwcG9ydGluZyAxDQo+ID4gICAgIGVuY29kaW5nIGlzIGJldHRlciB0aGFuIGJvdGgsIGFzIEJy aWFuIHBvaW50cyBvdXQuIFdpRmkgYWNjZXNzDQo+ID4gICAgIHBvaW50cyB0aGF0ICJqdXN0IHdv cmsiIGFueXdoZXJlIGluIHRoZSB3b3JsZCBzZXJ2ZXMgYXMgYSBnb29kDQo+IG1vZGVsLg0KPiA+ DQo+ID4gW0RKIC0gSSBwcm9wb3NlZCB0aGF0IHRoZSBkYXRhYmFzZXMgc3VwcG9ydCBib3RoIFhN TCBhbmQgSlNPTiwgZGV2aWNlcw0KPiA+IG9ubHkgbmVlZCB0byBzdXBwb3J0IG9uZSB0byB0YWxr IHRvIHRoZSBkYXRhYmFzZS4gT3VyIGN1cnJlbnQgZGF0YWJhc2UNCj4gPiBzdXBwb3J0cyBYTUwg YW5kIEpTT04sIGJ1dCBpZiBJoa9tIGZvcmNlZCB0byBwaWNrIG9ubHkgb25lLCB0aGVuIEkgd2ls bA0KPiA+IHZvdGUgZm9yIFhNTCBiZWNhdXNlIGl0oa9zIHRoZSBvbmUgdGhhdCB3ZSBjdXJyZW50 bHkgdXNlIG9uIGFsbCBlbWJlZGRlZA0KPiA+IGRldmljZXMuXQ0KPiA+DQo+ID4gICAqIFRoZXJl J3MgYSB0cmVuZCBmb3IgQVBJcyBvbiB0aGUgd2ViIHRvd2FyZHMgSlNPTiAoVHdpdHRlciwNCj4g PiAgICAgRm91clNxdWFyZSwgRmFjZWJvb2ssIEdvb2dsZSwgZXRjLikuIE9uZSBvZiB0aGUgbWFq b3IgcmVhc29ucyBpcw0KPiA+ICAgICB0aGF0IGRldmVsb3BlcnMgKGNsaWVudC1zaWRlKSBwcmVm ZXIgaXQgZm9yIGl0cyBzaW1wbGljaXR5Og0KPiA+DQo+ID4gICAgICAgbyBSZXByZXNlbnRhdGlv biBjbG9zZWx5IG1hdGNoZXMgbW9zdCBkYXRhIG1vZGVscyAobmVzdGVkIGxpc3RzDQo+ID4gICAg ICAgICBhbmQgbWFwcykNCj4gPiAgICAgICBvIFNpbXBsZS10by11c2UgbGlicmFyaWVzIGV4aXN0 IGZvciBhbGwgbWFqb3IgbGFuZ3VhZ2VzL3BsYXRmb3Jtcw0KPiA+ICAgICAgIG8gRG9uJ3QgbmVl ZCBhIHRvb2wgY2hhaW4gdG8gd29yayB3aXRoIHRoZSBkYXRhLCBhcyBpcyB0eXBpY2FsbHkNCj4g PiAgICAgICAgIG5lZWRlZCBmb3IgWE1MLg0KPiA+DQo+ID4gQXBwYXJlbnRseSwgdGhlIGVmZmlj aWVuY3kgZ2FpbnMgb2YgSlNPTiBhbHNvIG1hdHRlciB0byB0aGUgc2NhbGFiaWxpdHkNCj4gPiBv ZiBzZXJ2aW5nIHN5c3RlbXMuDQo+ID4NCj4gPiBbREogqEMgSSBjYW6hr3QgYXJndWUgYWdhaW5z dCB0aGVzZSBsaXN0ZWQgcHJvcyBmb3IgSlNPTiwgZXNwZWNpYWxseSB3aGVuDQo+ID4geW91oa9y ZSBkZWFsaW5nIHdpdGggYSBsb3Qgb2YgZGF0YSAobGlrZSBUd2l0dGVyLCBGb3VyU3F1YXJlLCBG YWNlYm9vaw0KPiA+IGFuZCBHb29nbGUgZG9lcykuIEJ1dCBJoa9tIGFzc3VtaW5nIHRoYXQgUEFX UyBtZXNzYWdlcyB3aWxsIG5vdCBiZQ0KPiA+IGV4Y2hhbmdlZCBuZWFybHkgYXMgb2Z0ZW4gYXMg dGhlIGFwcGxpY2F0aW9ucyBtZW50aW9uZWQgYWJvdmUuIEJ1dA0KPiA+IGFnYWluLCBJIGtub3cg SlNPTiBpcyBtb3JlIGVmZmljaWVudCwgY2Fuoa90IGFyZ3VlIHdpdGggdGhhdC5dDQo+ID4NCj4g PiAgICogQXQgdGhlIGVuZCBvZiB0aGUgZGF5LCBpdCdzIHRoZSBkYXRhIG1vZGVsIHRoYXQgbWF0 dGVycywgcmF0aGVyIHRoYW4NCj4gPiAgICAgdGhlIGVuY29kaW5nLiBXZSAoR29vZ2xlKSBhcmUg YWN0dWFsbHkgbmV1dHJhbCBvbiBYTUwgdnMgSlNPTiwgYXMNCj4gPiAgICAgbG9uZyBhcyB3ZSdy ZSBjbGVhciBvbiB3aGF0IGRldmljZSBtYWtlcnMgd2FudC4gSXQgd291bGQgYmUgZ29vZCB0bw0K PiA+ICAgICBnZXQgZmVlZGJhY2sgZnJvbSBkZXZpY2UgbWFrZXJzIChlc3BlY2lhbGx5IG9mIGVt YmVkZGVkIGRldmljZXMpDQo+ID4gICAgIHJlZ2FyZGluZyBleHBlcmllbmNlcyBzdXBwb3J0aW5n IFhNTCB2cyBKU09OLg0KPiA+DQo+ID4gRG9uLCBjYW4geW91IGVsYWJvcmF0ZSBvbiB0aGUgdHlw ZXMgb2YgZGV2aWNlcyB0aGF0IGFscmVhZHkgc3VwcG9ydCBYTUw/DQo+ID4NCj4gPiBbREogLSBX ZSBjdXJyZW50bHkgc3VwcG9ydCBoYWxmIGEgZG96ZW4gVFZEQiByYWRpbyB2ZW5kb3JzIChlbWJl ZGRlZA0KPiA+IGRldmljZXMpIHVzaW5nIFhNTCwgbm9uIHVzaW5nIEpTT04uIFhNTCBoYXMgbm90 IGJlZW4gYSBidXJkZW4sIGFuZCB0aGUNCj4gPiBhbW91bnQgb2YgZGF0YSB0aGF0IG5lZWRzIHRv IGJlIGV4Y2hhbmdlZCBiZXR3ZWVuIGRldmljZSBhbmQgZGF0YWJhc2UNCj4gaXMNCj4gPiBub3Qg dGhhdCBtdWNoIG9yIGV4Y2hhbmdlZCB0aGF0IG9mdGVuLl0NCj4gPg0KPiA+IE9uIEZyaSwgQXVn IDE3LCAyMDEyIGF0IDY6MDYgUE0sIFdlaXhpbnBlbmcgPHdlaXhpbnBlbmdAaHVhd2VpLmNvbQ0K PiA+IDxtYWlsdG86d2VpeGlucGVuZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+ID4NCj4gPiBDb25z aWRlcmluZyBvZiB0aGUgZGVzaWduIG9mIGRhdGFiYXNlIGRpc2NvdmVyeSBwcm90b2NvbCwgdGhl IExvU1QNCj4gPiBwcm90b2NvbCBtYXkgYmUgdXNlZCBhbmQgTG9TVCBpcyBiYXNlZCBvbiBYTUws IHNvIEkgdGhpbmsgWE1MIG1heSBiZQ0KPiA+IHByZWZlcnJlZC4NCj4gPg0KPiA+IC0tWGlucGVu ZyBXZWkNCj4gPg0KPiA+ICpGcm9tOipwYXdzLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPiA8bWFpbHRv OnBhd3MtYm91bmNlc0BpZXRmLm9yZz5bbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZw0KPiA+ IDxtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnPl0qT24gQmVoYWxmIE9mKlJvc2VuLCBCcmlh bg0KPiA+DQo+ID4NCj4gPiAqU2VudDoqRnJpZGF5LCBBdWd1c3QgMTcsIDIwMTIgOToyNiBQTQ0K PiA+DQo+ID4gKlRvOipNYW5pa2tvdGggU2FqZWV2O2dhYm9yLmJhamtvQG5va2lhLmNvbQ0KPiA+ IDxtYWlsdG86Z2Fib3IuYmFqa29Abm9raWEuY29tPjt2Y2hlbkBnb29nbGUuY29tDQo+ID4gPG1h aWx0bzp2Y2hlbkBnb29nbGUuY29tPjtwZXRlckBzcGVjdHJ1bWJyaWRnZS5jb20NCj4gPiA8bWFp bHRvOnBldGVyQHNwZWN0cnVtYnJpZGdlLmNvbT4NCj4gPg0KPiA+DQo+ID4gKkNjOipwYXdzQGll dGYub3JnIDxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCj4gPiAqU3ViamVjdDoqUmU6IFtwYXdzXSBY TUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmIGlDYWwNCj4gPg0KPiA+IEkgZG9uJ3QgcmVh bGx5IGNhcmUgd2hldGhlciB3ZSB1c2UganNvbiBvciB4bWwgYXMgYSBtYXR0ZXIgb2YgcHJvdG9j b2wNCj4gPiBkZXNpZ24gb3IgaW1wbGVtZW50YXRpb24sIGJ1dCBJIGFtIGEgYmlnIGZhbiBvZiBy ZXVzaW5nIHN0YW5kYXJkcyByYXRoZXINCj4gPiB0aGFuIGRlZmluaW5nIG5ldyBvbmVzLCBhbmQg SSB3b3VsZCBub3Qgd2FudCB0byBzZWUgdGhlIGNob2ljZSBvZiBqc29uDQo+ID4gbWVhbiB3ZSB0 aGVuIGRlY2lkZSB0byByb2xsIG91ciBvd24gdmVyc3VzIHVzaW5nIGV4aXN0aW5nIHN0YW5kYXJk cw0KPiA+IGJhc2VkIG9uIHRoZSBpZGVhIHRoZXJlIGlzIG5vIGpzb24gcmVwcmVzZW50YXRpb24g b2YgYW4gZXhpc3RpbmcNCj4gPiBzdGFuZGFyZC4gIFNvLCBpZiBjaG9vc2luZyBqc29uIG1lYW5z IGZvbGtzIGZlZWwgZnJlZSB0byBpZ25vcmUgZXhpc3RpbmcNCj4gPiB4bWwgYmFzZWQgc3RhbmRh cmRzIHN1Y2ggYXMgeENhcmQgYW5kIExvU1QsIHRoZW4gSSB3b3VsZCBub3Qgd2FudCB0byB1c2UN Cj4gPiBqc29uLg0KPiA+DQo+ID4gSSB3b3VsZCBwcmVmZXIgdG8gbm90IGhhdmUgImJvdGgiLCBi ZWNhdXNlIG9mIGludGVyb3BlcmFiaWxpdHkNCj4gPiBjb21wbGljYXRpb25zLiAgSWYgdGhlcmUg aXMgcm91Z2ggY29uc2Vuc3VzIGZvciBib3RoLCB0aGVuIEkgd291bGQNCj4gPiBhc3NlcnQgdGhh dCBhbGwgc2VydmVycyBoYXZlIHRvIGltcGxlbWVudCBib3RoIGFuZCB0aGUgY2xpZW50IGNhbg0K PiA+IGltcGxlbWVudCBlaXRoZXIuDQo+ID4NCj4gPiBUaGVyZSBhcmUganNvbiB2YWxpZGF0b3Jz LCBzbyBJIGRvbid0IHRoaW5rIHRoYXQgaXMgYSBiaWcgZGVhbC4NCj4gPg0KPiA+IE15IGV4cGVy aWVuY2UgaW4gcHJvdG9jb2wgZGVzaWduIG9uIHRoZSBJbnRlcm5ldCBpcyB0aGF0IGRlY2lzaW9u cyBtYWRlDQo+ID4gc29sZWx5IG9yIGV2ZW4gbGFyZ2VseSBiZWNhdXNlIG9mIGNvbXBhY3RuZXNz IGFkdmFudGFnZXMgcmFyZWx5IGFyZSBnb29kDQo+ID4gY2hvaWNlcy4gIElmIHlvdSBsaWtlIGpz b24gYmVjYXVzZSBpdCBpcyBzbWFsbGVyLCB0aGVuIEkgYmVsaWV2ZSB5b3UNCj4gPiBuZWVkIGEg bXVjaCBiZXR0ZXIgcmVhc29uLiAgQmluYXJ5IGRvZXNuJ3Qgd29yayBmb3IgbWUsIGF0IGFsbC4g IEkgaGF2ZQ0KPiA+IGJlZW4gaW52b2x2ZWQgaW4gYmlnIGJpbmFyeSB2cyB0ZXh0IHdhcnMgaW4g cHJvdG9jb2wgZGVzaWduLiAgVGV4dCB3aW5zLA0KPiA+IGJpbmFyeSBsb3NlcywgaW4gbXkgb3Bp bmlvbi4NCj4gPg0KPiA+IEJyaWFuIDxhcyBpbmRpdmlkdWFsPg0KPiA+DQo+ID4gKkZyb206Kk1h bmlra290aCBTYWplZXYgPG1rc2FqaUB5YWhvby5jb20NCj4gPG1haWx0bzpta3NhamlAeWFob28u Y29tPj4NCj4gPiAqUmVwbHktVG86Kk1hbmlra290aCBTYWplZXYgPG1rc2FqaUB5YWhvby5jb20N Cj4gPG1haWx0bzpta3NhamlAeWFob28uY29tPj4NCj4gPiAqRGF0ZToqVGh1LCAxNiBBdWcgMjAx MiAyMjozNzozOCAtMDQwMA0KPiA+ICpUbzoqIkdhYm9yLkJhamtvQG5va2lhLmNvbSA8bWFpbHRv OkdhYm9yLkJhamtvQG5va2lhLmNvbT4iDQo+ID4gPEdhYm9yLkJhamtvQG5va2lhLmNvbSA8bWFp bHRvOkdhYm9yLkJhamtvQG5va2lhLmNvbT4+LCAiUm9zZW4sDQo+IEJyaWFuIg0KPiA+IDxicmlh bi5yb3NlbkBuZXVzdGFyLmJpeiA8bWFpbHRvOmJyaWFuLnJvc2VuQG5ldXN0YXIuYml6Pj4sDQo+ ID4gInZjaGVuQGdvb2dsZS5jb20gPG1haWx0bzp2Y2hlbkBnb29nbGUuY29tPiIgPHZjaGVuQGdv b2dsZS5jb20NCj4gPiA8bWFpbHRvOnZjaGVuQGdvb2dsZS5jb20+PiwgInBldGVyQHNwZWN0cnVt YnJpZGdlLmNvbQ0KPiA+IDxtYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tPiIgPHBldGVy QHNwZWN0cnVtYnJpZGdlLmNvbQ0KPiA+IDxtYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29t Pj4NCj4gPiAqQ2M6KiJwYXdzQGlldGYub3JnIDxtYWlsdG86cGF3c0BpZXRmLm9yZz4iIDxwYXdz QGlldGYub3JnDQo+ID4gPG1haWx0bzpwYXdzQGlldGYub3JnPj4NCj4gPiAqU3ViamVjdDoqUmU6 IFtwYXdzXSBYTUwgc2NoZW1hIHZlcnN1cyBKU09OLCB2Q2FyZCAmIGlDYWwNCj4gPg0KPiA+IEhp LA0KPiA+DQo+ID4gQ2FuIGl0IG5vdCBiZSBib3RoIEpTT04gYW5kIFhNTCBzdXBwb3J0ZWQ/IEkg d291bGQgdm90ZSBmb3IgdGhhdC4gRnV0dXJlDQo+ID4gaW1wbGVtZW50YXRpb25zIG1heSBwcmVm ZXIqWE1MIGFzIGl0IGlzIGdlbmVyaWMsIG9tbmkgcHJlc2VudCwgZWFzeSB0bw0KPiA+IHVuZGVy c3RhbmQgYW5kIHZhbGlkYXRlLipGb3IgY29tcGFjdG5lc3MgbWF5IGJlIGEgKmJpbmFyeSB4bWwN Cj4gb3B0aW9uKmNhbg0KPiA+IGFsc28gd29yay4gSlNPTiBJIHRoaW5rIHdpbGwgbmVjZXNzaXRh dGUgaW1wbGVtZW50YXRpb24gdG8gYmUgbmF0aXZlDQo+ID4gSmF2YSBhbmQgbWF5IG5vdCBiZSBh cyBmcmllbmRseSB3aXRoIG90aGVyIGltcGxlbWVudGF0aW9uIGxhbmd1YWdlcy4NCj4gPg0KPiA+ IC9CZXN0IFJlZ2FyZHMsLw0KPiA+DQo+ID4gL1NhamVldiBNYW5pa2tvdGgNCj4gPiBNb2JpbGU6 KzkxODc5MjI5MjAwMg0KPiA+IEVtYWlsOm1rc2FqaUBpZWVlLm9yZyA8bWFpbHRvOm1rc2FqaUBp ZWVlLm9yZz4NCj4gPiBodHRwOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9ta3NhamVldi8NCj4gPg0K PiA+ICpGcm9tOioiR2Fib3IuQmFqa29Abm9raWEuY29tIDxtYWlsdG86R2Fib3IuQmFqa29Abm9r aWEuY29tPiINCj4gPiA8R2Fib3IuQmFqa29Abm9raWEuY29tIDxtYWlsdG86R2Fib3IuQmFqa29A bm9raWEuY29tPj4NCj4gPiAqVG86KkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6DQo+ID4gPG1haWx0 bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej47dmNoZW5AZ29vZ2xlLmNvbQ0KPiA+IDxtYWlsdG86 dmNoZW5AZ29vZ2xlLmNvbT47cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tDQo+ID4gPG1haWx0bzpw ZXRlckBzcGVjdHJ1bWJyaWRnZS5jb20+DQo+ID4gKkNjOipwYXdzQGlldGYub3JnIDxtYWlsdG86 cGF3c0BpZXRmLm9yZz4NCj4gPiAqU2VudDoqRnJpZGF5LCAxNyBBdWd1c3QgMjAxMiwgNDo1NQ0K PiA+ICpTdWJqZWN0OipSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJkICYg aUNhbA0KPiA+DQo+ID4NCj4gPiBXZSBoYXZlIG5vdCBoZWFyZCBhbnkgb2JqZWN0aW9ucyBmb3Ig dXNpbmcgSlNPTiBlbmNvZGluZyBpbnN0ZWFkIG9mIFhNTC4NCj4gPiBUaGVyZWZvcmUsIGxldCdz IGdvIGZvciBKU09OLCBhbmQgY2xvc2UgdGhpcyB0aHJlYWQuDQo+ID4NCj4gPiAtIEdhYm9yDQo+ ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206cGF3cy1ib3VuY2Vz QGlldGYub3JnDQo+ID4gPG1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+W21haWx0bzpwYXdz LWJvdW5jZXNAaWV0Zi5vcmcNCj4gPiA8bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZz5dIE9u IEJlaGFsZiBPZiBleHQgUm9zZW4sIEJyaWFuDQo+ID4gU2VudDogTW9uZGF5LCBBdWd1c3QgMTMs IDIwMTIgMzoxNCBQTQ0KPiA+IFRvOiAnVmluY2VudCBDaGVuJzsgJ1BldGVyIFN0YW5mb3J0aCcN Cj4gPiBDYzogJ3Bhd3NAaWV0Zi5vcmcgPG1haWx0bzpwYXdzQGlldGYub3JnPicNCj4gPiBTdWJq ZWN0OiBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJkICYgaUNhbA0KPiA+ DQo+ID4ganNvbiBpcyBva2F5IHdpdGggbWUuDQo+ID4gSSdkIHByZWZlciBhbiBJU08gdGltZSBz dGFtcCByYXRoZXIgdGhhbiBhIHRpbWUgaW4gc2Vjb25kcyBzaW5jZSBlcG9jaC4NCj4gPiBJdCdz IHZlcnkgZWFzeSB0byBwYXJzZSwgYW5kIGl0cyBzaW1wbGVyIHRvIHVzZSBhbmQgZGVidWcuICBE b24ndCBjYXJlIGENCj4gPiB3aG9sZSBsb3QgYWJvdXQgdGhhdA0KPiA+DQo+ID4gQnJpYW4gPGFz IGluZGl2aWR1YWw+DQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPiBGcm9tOiAgICAgVmluY2VudCBDaGVuIFttYWlsdG86dmNoZW5AZ29vZ2xlLmNvbQ0K PiA8bWFpbHRvOnZjaGVuQGdvb2dsZS5jb20+XQ0KPiA+IFNlbnQ6ICAgIE1vbmRheSwgQXVndXN0 IDEzLCAyMDEyIDA2OjA0IFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KPiA+IFRvOiAgICBQZXRl ciBTdGFuZm9ydGgNCj4gPiBDYzogICAgUm9zZW4sIEJyaWFuOyBUZWNvIEJvb3Q7IEJlbmphbWlu IEEuUm9sZmU7cGF3c0BpZXRmLm9yZw0KPiA+IDxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCj4gPiBT dWJqZWN0OiAgICBSZTogW3Bhd3NdIFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJkICYgaUNh bA0KPiA+DQo+ID4gWE1MIHZzIEpTT04NCj4gPg0KPiA+IEJldHdlZW4gWE1MIGFuZCBKU09OLCBK U09OIG1lc3NhZ2VzIGFyZSBtb3JlIGNvbXBhY3QgYW5kIGVhc2llciB0bw0KPiA+IHByb2Nlc3Mg KHBhcnNpbmcsIHN5bnRoZXNpcykuIEFzIGNsYXJpZmljYXRpb24sIEpTT04gZG9lcyBub3QgcmVx dWlyZQ0KPiA+IEphdmFTY3JpcHQgb3IgYSBCcm93c2VyLiBJdCBpcyBhIHRleHQtYmFzZWQgcmVw cmVzZW50YXRpb24gb2YgZGF0YSB0aGF0DQo+ID4gaXMgbGFuZ3VhZ2UgaW5kZXBlbmRlbnQsIHll dCB3ZWxsLW1hdGNoZWQgdG8gYWxsIG1ham9yIGxhbmd1YWdlcy4NCj4gPiBKU09OLWhhbmRsaW5n IGxpYnJhcmllcyBleGlzdCBmb3IgbnVtZXJvdXMgbGFuZ3VhZ2VzIChzZWUNCj4gPiBvZmh0dHA6 Ly9qc29uLm9yZy8pIGFuZCBzZWVtIHRvIGJlIHJlYXNvbmFibHkgbGlnaHQgd2VpZ2h0Lg0KPiA+ DQo+ID4gVGltZXN0YW1wcw0KPiA+DQo+ID4gQXMgZm9yIHRpbWVzdGFtcCBzcGVjaWZpY2F0aW9u cywgc2hvdWxkIHdlIGNvbnNpZGVyIGp1c3QgdXNpbmcgc2Vjb25kcw0KPiA+IHNpbmNlIHRoZSBV TklYIEVwb2NoICgxOTcwLTAxLTAxVDAwOjAwOjAwWik/IFRoaXMgd291bGQgZWxpbWluYXRlIHRo ZQ0KPiA+IG5lZWQgZm9yIGRhdGV0aW1lLXN0cmluZyBwYXJzaW5nIG9uIGRldmljZXMsIGFzc3Vt aW5nIGRldmljZXMgYWxyZWFkeQ0KPiA+IGhhdmUgbmF0aXZlIGxpYnJhcmllcyB0aGF0IHByb3Zp ZGUgdGltZSBpbiB0aGlzIGZvcm1hdC4gSXMgdGhhdCBhIHZhbGlkDQo+ID4gYXNzdW1wdGlvbj8g T2YgY291cnNlLCB0aGlzIGlzIGxlc3MgaHVtYW4tcmVhZGFibGUuLi4uDQo+ID4NCj4gPg0KPiA+ IE9uIE1vbiwgQXVnIDEzLCAyMDEyIGF0IDY6NDkgQU0sIFBldGVyIFN0YW5mb3J0aA0KPiA+IDxw ZXRlckBzcGVjdHJ1bWJyaWRnZS5jb20gPG1haWx0bzpwZXRlckBzcGVjdHJ1bWJyaWRnZS5jb20+ Pg0KPiB3cm90ZToNCj4gPg0KPiA+DQo+ID4gICAgICBXaGVuZXZlciB3ZSBidWlsdCBtb2JpbGUg ZGV2aWNlcyB3ZSBuZXZlciBkZWFsdCB3aXRoIElFVEYsIGluIG91cg0KPiA+IHNlbnNvcg0KPiA+ ICAgICAgZGF5cyBldmVuIGFuIElQIHN0YWNrIHdhcyBhIGNoYWxsZW5nZSxzbyBJIHdvdWxkIGRl ZmVyIHRvIHRoZQ0KPiA+IGRldmljZSBndXlzDQo+ID4gICAgICBvbiB0aGF0IG9uZS4NCj4gPg0K PiA+ICAgICAgT24gTW9uQXVnLzEzLzEyIE1vbiBBdWcgMTMsIDk6MzAgQU0sICJSb3NlbiwgQnJp YW4iDQo+ID4NCj4gPiAgICAgIDxCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpeiA8bWFpbHRvOkJyaWFu LlJvc2VuQG5ldXN0YXIuYml6Pj4NCj4gd3JvdGU6DQo+ID4NCj4gPiAgICAgID5PdXIgZXhwZXJp ZW5jZSBpbiB0aGUgSUVURiBvdmVyIG1hbnkgeWVhcnMgaXMgdGhhdCBlY29ub21pemluZw0KPiBt ZXNzYWdlDQo+ID4gICAgICA+c2l6ZSBhbmQgY29tcHJvbWlzaW5nIHV0aWxpdHkgYW5kIHNlY3Vy aXR5IGluIHNlYXJjaCBvZiBlZmZpY2llbmN5IG9mDQo+ID4gICAgICA+aW1wbGVtZW50YXRpb24g b24gc21hbGwgZGV2aWNlcyBpcyBhIHBvb3IgdHJhZGUgb2ZmLiAgSSBhbSBub3QNCj4gPiBhZHZv Y2F0aW5nDQo+ID4gICAgICA+YmVpbmcgd2FzdGVmdWwgb2YgcmVzb3VyY2VzLCBidXQgSSBkb24n dCB0aGluayB3ZSBzaG91bGQgc2VyaW91c2x5DQo+ID4gICAgICA+Y29uc2lkZXIgdGhlIG92ZXJo ZWFkIG9mIFhNTCBvciBqc29uIHRvIGJlIHNpZ25pZmljYW50Lg0KPiA+ICAgICAgPg0KPiA+ICAg ICAgPkFzc3VtaW5nIGEganNvbiBsaWJyYXJ5IGNhbiBiZSBsb2FkZWQgb24gYSBzbWFsbCBkZXZp Y2UgaXMNCj4gcmVhc29uYWJsZS4NCj4gPiAgICAgID4NCj4gPiAgICAgID5CcmlhbiAoYXMgaW5k aXZpZHVhbCkNCj4gPiAgICAgID4NCj4gPiAgICAgID4NCj4gPiAgICAgID4NCj4gPiAgICAgID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiAgICAgID5Gcm9tOiAgUGV0ZXIgU3RhbmZv cnRoIFttYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tDQo+ID4gPG1haWx0bzpwZXRlckBz cGVjdHJ1bWJyaWRnZS5jb20+XQ0KPiA+ICAgICAgPlNlbnQ6ICBTYXR1cmRheSwgQXVndXN0IDEx LCAyMDEyIDA3OjEzIEFNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KPiA+ICAgICAgPlRvOiAgICBU ZWNvIEJvb3Q7IEJlbmphbWluIEEuUm9sZmUNCj4gPiAgICAgID5DYzogcGF3c0BpZXRmLm9yZyA8 bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQo+ID4gICAgICA+U3ViamVjdDogICAgICBSZTogW3Bhd3Nd IFhNTCBzY2hlbWEgdmVyc3VzIEpTT04sIHZDYXJkICYgaUNhbA0KPiA+ICAgICAgPg0KPiA+ICAg ICAgPk5vdCBhbGwgbWFzdGVycyBydW4gb3ZlciB0aGUgY29yZSBuZXR3b3JrLg0KPiA+ICAgICAg PlNvbWUgb2YgdGhlIFVzZSBjYXNlcyBoYXZlIGEgbWFzdGVyIHRhbGtpbmcgdG8gYW5vdGhlciBP VEENCj4gPiAgICAgID5XZSBzaG91bGQgbm90IGFzc3VtZSB0aGF0IGFsbCBNYXN0ZXJzIGFyZSBh dHRhY2hlZCB0byB1dGlsaXR5DQo+ID4gcG93ZXIgc28gd2UNCj4gPiAgICAgID5zaG91bGQgYmUg c3ltcGF0aGV0aWMgdG8gcHJvY2Vzc2luZyBlbmVyZ3kgdXNlIGFsc28uDQo+ID4gICAgICA+DQo+ ID4gICAgICA+T24gU2F0QXVnLzExLzEyIFNhdCBBdWcgMTEsIDU6MzAgQU0sICJUZWNvIEJvb3Qi DQo+IDx0ZWNvQGluZi1uZXQubmwNCj4gPiA8bWFpbHRvOnRlY29AaW5mLW5ldC5ubD4+IHdyb3Rl Og0KPiA+ICAgICAgPg0KPiA+ICAgICAgPj4NCj4gPiAgICAgID4+T3AgMTAgYXVnLiAyMDEyLCBv bSAxODoxMCBoZWVmdCBCZW5qYW1pbiBBLiBSb2xmZSBoZXQgdm9sZ2VuZGUNCj4gPiAgICAgID4+ Z2VzY2hyZXZlbjoNCj4gPiAgICAgID4+DQo+ID4gICAgICA+Pj4gQ29tcGFjdG5lc3Mgb2YgbWVz c2FnZXMgaXMgaW1wb3J0YW50LCBidXQgaXQgaXMgYWxzbyBpbXBvcnRhbnQNCj4gPiAodG8gbWUN Cj4gPiAgICAgID4+PmF0IGxlYXN0KSB0byBiZSByZWFsaXphYmxlIGluIGFuIGltcGxlbWVudGF0 aW9uIHdpdGggbGltaXRlZA0KPiA+IHJlc291cmNlcywNCj4gPiAgICAgID4+PnN1Y2ggYXMgZW1i ZWRkZWQgZGV2aWNlcyBpbiB3aGF0IGFyZSBub3cgcG9wdWxhcmx5IGNhbGxlZA0KPiAiTTJNIg0K PiA+ICAgICAgPj4+YXBwbGljYXRpb25zLiAgQSBsb3Qgb2YgdGhlc2UgZGV2aWNlcyBjb3VsZCB1 c2UgSVAgYWxsIHRoZSBlbmQNCj4gPiB0byBlbmQsDQo+ID4gICAgICA+Pj5idXQgbWF5IGhhdmUg YSB2ZXJ5IGNvbXBhY3QsIHNpbXBsZSBzdGFjayBhbmQgYXBwbGljYXRpb25zIChpLmUuDQo+IG5v DQo+ID4gICAgICA+Pj5icm93c2VyKS4gIElzIEpTT04gdHlwaWNhbGx5IGltcGxlbWVudGVkIHdo ZW4gdGhlcmUgaXMgbm8NCj4gYnJvd3Nlcj8NCj4gPiAgICAgID4+PldvdWxkIGl0IGJlIGhhcmQg dG8gZG8gaW4gYSByZXNvdXJjZSBjb25zdHJhaW5lZCBkZXZpY2UgKGkuZS4NCj4gPiB3aGVyZSB3 ZQ0KPiA+ICAgICAgPj4+dGFsayBhYm91dCBtZW1vcnkgc2l6ZSBpbiBLaWxvLWJ5dGVzIHN0aWxs KS4NCj4gPiAgICAgID4+DQo+ID4gICAgICA+PkluIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRz IGRvY3VtZW50LCB0aGVyZSBhcmUgbm8NCj4gcmVxdWlyZW1lbnRzIGZvcg0KPiA+ICAgICAgPj5w cm90b2NvbCBwZXJmb3JtYW5jZS4gSSBndWVzcyBPUy9JUC9UQ1AvVExTIGNvZGUgc2l6ZSBzdXBl cnNlZGVzDQo+ID4gbmVlZHMNCj4gPiAgICAgID4+Zm9yIEpTT04gb3IgWE1MLg0KPiA+ICAgICAg Pj4NCj4gPiAgICAgID4+U2FtZSBmb3IgdGltaW5nOiBUQ1AvVExTIGNvbm5lY3Rpb24gc2V0dXAg d2lsbCB0YWtlIG1vcmUgdGhhbg0KPiB0aGUNCj4gPiBQQVdTDQo+ID4gICAgICA+Pm1lc3NhZ2Ug ZXhjaGFuZ2UsIEkgdGhpbmsuIFRoaXMgbWF5IGJlIG9mIGltcG9ydGFuY2Ugd2hlbiB1c2luZw0K PiA+IHNhdGNvbQ0KPiA+ICAgICAgPj5saW5rcy4NCj4gPiAgICAgID4+DQo+ID4gICAgICA+PkJl Y2F1c2UgUEFXUyBydW5zIGJldHdlZW4gbWFzdGVyIGFuZCBkYXRhYmFzZSwgb3ZlciBjb3JlDQo+ IG5ldHdvcmssDQo+ID4gICAgICA+PnBlcmZvcm1hbmNlIGlzIG5vdCBvdXIgcHJpbWFyeSBjb25j ZXJuLiBCdXQgYXMgYWx3YXlzLCBpdCBpcyBnb29kDQo+ID4gdG8ga2VlcA0KPiA+ICAgICAgPj5h biBleWUgb24gZWZmaWNpZW5jeS4NCj4gPiAgICAgID4+DQo+ID4gICAgICA+PlRlY28NCj4gPiAg ICAgID4+DQo+ID4gICAgICA+Pj4gVGhhbmtzDQo+ID4gICAgICA+Pj4gQmVuDQo+ID4gICAgICA+ Pj4NCj4gPiAgICAgID4+Pg0KPiA+ICAgICAgPj4+PiBXZSBoYWQgYSBkaXNjdXNzaW9uIG9uIFhN TCB2cy4gSlNPTi4gSSBwcmVmZXIgdGhlIG9uZSB3aXRoDQo+IG1vc3QNCj4gPiAgICAgID4+Pj5j b21wYWN0IG1lc3NhZ2VzLg0KPiA+ICAgICAgPj4+Pg0KPiA+ICAgICAgPj4+PiBPbiB2Q2FyZCBh bmQgSlNPTjogd2hhdCBpcyB0aGUgc3RhdHVzIG9mICJBIEphdmFTY3JpcHQgT2JqZWN0DQo+ID4g Tm90YXRpb24NCj4gPiAgICAgID4+Pj4oSlNPTikgUmVwcmVzZW50YXRpb24gZm9yIHZDYXJkIj8N Cj4gPiAgICAgID4+Pj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaGF0LXZjYXJk ZGF2LWpzb24tMDANCj4gPiAgICAgID4+Pj4NCj4gPiAgICAgID4+Pj4gT24gdmFsaWQgdGltZXM6 IGNhbiB3ZSB1c2Ugc2FtZSBmb3JtYXQgYXMgY2VydGlmaWNhdGVzPyBUaGV5DQo+IGhhdmUNCj4g PiAgICAgID4+Pj5zaW1pbGFyIHNpbXBsZSByZXF1aXJlbWVudHM6IHZhbGlkIG5vdEJlZm9yZSYg IG5vdEFmdGVyLg0KPiA+ICAgICAgPj4+Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMy ODAjc2VjdGlvbi00LjEuMi41DQo+ID4gICAgICA+Pj4+DQo+ID4gICAgICA+Pj4+IFRlY28NCj4g PiAgICAgID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiAgICAgID4+Pj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4gPiAgICAgID4+Pj5wYXdzQGll dGYub3JnIDxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCj4gPiAgICAgID4+Pj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gPiAgICAgID4+Pj4NCj4gPiAgICAgID4+ Pg0KPiA+ICAgICAgPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4gICAgICA+Pj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4gPiAgICAgID4+PnBhd3NA aWV0Zi5vcmcgPG1haWx0bzpwYXdzQGlldGYub3JnPg0KPiA+ICAgICAgPj4+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+ID4gICAgICA+Pg0KPiA+ICAgICAgPj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ICAgICAg Pj5wYXdzIG1haWxpbmcgbGlzdA0KPiA+ICAgICAgPj5wYXdzQGlldGYub3JnIDxtYWlsdG86cGF3 c0BpZXRmLm9yZz4NCj4gPiAgICAgID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9wYXdzDQo+ID4gICAgICA+DQo+ID4gICAgICA+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiAgICAgID5wYXdzIG1haWxpbmcgbGlzdA0KPiA+ ICAgICAgPnBhd3NAaWV0Zi5vcmcgPG1haWx0bzpwYXdzQGlldGYub3JnPg0KPiA+ICAgICAgPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPiA+DQo+ID4gICAgICBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ICAgICAg cGF3cyBtYWlsaW5nIGxpc3QNCj4gPiBwYXdzQGlldGYub3JnIDxtYWlsdG86cGF3c0BpZXRmLm9y Zz4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gPg0K PiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0NCj4gPiAtdmluY2UNCj4gPg0KPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gcGF3cyBtYWlsaW5n IGxpc3QNCj4gPiBwYXdzQGlldGYub3JnIDxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCj4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHBhd3MgbWFpbGluZyBsaXN0 DQo+ID4gcGF3c0BpZXRmLm9yZyA8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0N Cj4gPiAtdmluY2UNCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPg0KPiA+IHBhd3MgbWFpbGluZyBs aXN0DQo+ID4NCj4gPiBwYXdzQGlldGYub3JnICA8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQo+ID4N Cj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gPg0KPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gcGF3 cyBtYWlsaW5nIGxpc3QNCj4gPiBwYXdzQGlldGYub3JnIDxtYWlsdG86cGF3c0BpZXRmLm9yZz4N Cj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gPg0KPiA+ DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+DQo+ID4gcGF3cyBtYWlsaW5nIGxpc3QNCj4gPg0KPiA+IHBhd3NAaWV0Zi5vcmcgIDxt YWlsdG86cGF3c0BpZXRmLm9yZz4NCj4gPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGF3cw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBwYXdzIG1haWxpbmcgbGlzdA0KPiA+IHBhd3NAaWV0Zi5v cmcgPG1haWx0bzpwYXdzQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGF3cw0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHBhd3MgbWFpbGluZyBsaXN0DQo+ID4gcGF3c0Bp ZXRmLm9yZyA8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wYXdzDQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBwYXdzIG1haWxpbmcgbGlzdA0K PiA+IHBhd3NAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Bhd3MNCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4gcGF3c0BpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg== From d.joslyn@spectrumbridge.com Mon Aug 27 06:15:55 2012 Return-Path: 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 F028F21F861F for ; Mon, 27 Aug 2012 06:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] 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 fm7BTCd1k+8j for ; Mon, 27 Aug 2012 06:15:49 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCD521F8628 for ; Mon, 27 Aug 2012 06:15:44 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 27 Aug 2012 09:15:42 -0400 From: Don Joslyn To: "Basavaraj.Patil@nokia.com" Date: Mon, 27 Aug 2012 09:15:41 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Iej7JadvAx8UahySbuq9n2zQAAU/5DAJUxXAAABrI7AAAWoncAABh1noAAifZJAAAEHtqAAAHwqAAADmEvAACA/ioAAAG/7gAAADZkgAABIt+A///NtAD//meaQIADLqOAgAADSYCAAAgwgIAAAR6AgAAX74CAAAsjAP//rRSAgABqLoD//8WEgAAr8oFc//zTEsA= Message-ID: <8375F6DAEFB09F48815203F1FE23B797117AA6DA87@shelby> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B797117AA6DA87shelby_" MIME-Version: 1.0 Cc: "paws@ietf.org" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 13:15:55 -0000 --_000_8375F6DAEFB09F48815203F1FE23B797117AA6DA87shelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 Cc: Peter.McCann@huawei.com; Brian.Rosen@neustar.biz; Gabor.Bajko@nokia.com= ; 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 th= e message format? Sent from my Verizon Wireless 4G LTE DROID RAZR 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" > 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 wrote: >> >> +1 to Brian's view on using JSON only. >> >> From: "", "Brian.Rosen@neustar.biz" >> > >> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko >> > Cc: "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 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 va= lid >> 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 t= hat >> 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 on= ly >> 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] On Behalf >> Of ext Rosen, Brian >> Sent: Friday, August 24, 2012 10:43 AM >> To: Benjamin A. Rolfe >> Cc: 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" >> > wrote: >> >> >> >> >> There are two ways to achieve interoperability when you have an op= tion. >> 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 optional= ly >> 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 choi= ce >> of what to implement doesn't work for me (or Richard). >> >> Brian >> >> On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe > >> wrote: >> >> >> Apparently I was unclear. I certainly an capable of being wrong a= s 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 t= he >> 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 JS= ON >> 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] On Behalf >> Of Basavaraj.Patil@nokia.com >> Sent: Thursday, August 23, 2012 5:44 PM >> To: Brian.Rosen@neustar.biz; d.jos= lyn@spectrumbridge.com >> Cc: 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: "", "Brian.Rosen@neustar.biz" >> > Date: Thur= sday, August 23, 2012 2:43 PM To: >> Don Joslyn > Cc: "paws@ietf.org" >> > Subject: Re: [paws] XML sche= ma 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 interoperabil= ity. >> >> 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 mus= t >> 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 o= nly >> does one: there are no protocol police. >> >> Brian >> >> >> >> >> On Aug 23, 2012, at 3:11 PM, Don Joslyn > >> wrote: >> >> >> >> >> Hi Ben, That was my original suggestion, and I still think it mak= es >> the most sense. Thanks for supporting the proposal. Don >> >> From: 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 >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >> >> Someone suggested that PAWS define both, and let the vendors decid= e >> 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 ] On >> Behalf Of Gabor.Bajko@nokia.com >> Sent: Tuesday, August 21, 2012 12:42 AM >> To: 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 oth= er >> encoding. To prevent endless discussions on this topic I'd suggest w= e >> 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 ] On >> Behalf Of ext Das, Subir >> Sent: Monday, August 20, 2012 2:50 PM >> To: Don Joslyn; Vincent Chen; Weixinpeng >> Cc: paws@ietf.org ; M= anikkoth 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 langua= ges/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] >> On Behalf Of Don Joslyn >> Sent: Monday, August 20, 2012 4:54 PM >> To: Vincent Chen; Weixinpeng >> Cc: paws@ietf.org ; M= anikkoth 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 ] On >> Behalf Of Vincent Chen >> Sent: Monday, August 20, 2012 2:56 PM >> To: Weixinpeng >> Cc: paws@ietf.org ; M= anikkoth 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, supportin= g >> 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 (n= ested lists and >> maps) * Simple-to-use libraries exist for all majo= r >> languages/platforms * Don't need a tool chain to work wi= th 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 suppor= t >>XML? >> >> >> >> [DJ - We currently support half a dozen TVDB radio vendors (embedd= ed >> 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 >> > 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 ] On >> Behalf Of Rosen, Brian >> >> Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; >> gabor.bajko@nokia.com ; >> vchen@google.com ; pe= ter@spectrumbridge.com >> >> >> Cc: 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 >> >> From: Manikkoth Sajeev = > >> Reply-To: Manikkoth Sajeev >> > >> Date: Thu, 16 Aug 2012 22:37:38 -0400 >> To: "Gabor.Bajko@nokia.com " >> >, "Rosen, Brian" >> >, >> "vchen@google.com " >> >, "peter@spectrum= bridge.com >> " >> > >> Cc: "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 Email: >> mksaji@ieee.org >> http://www.linkedin.com/in/mksajeev >> >> >> >> From: "Gabor.Bajko@nokia.com " >> > To: >> Brian.Rosen@neustar.biz ; >> vchen@google.com ; pe= ter@spectrumbridge.com >> Cc: paws@ietf.org >> Sent: Friday, 17 August 2012, 4:55 S= ubject: Re: >> [paws] XML schema versus JSON, vCard & iCal >> >> >> We have not heard any objections for using JSON encoding instead o= f >> XML. Therefore, let's go for JSON, and close this thread. >> >> - Gabor >> >> -----Original Message----- >> From: 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 ' >> 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 >> >> >> >> -----Original Message----- From: Vincent Chen >> [mailto:vchen@google.com ] Sent: Monday, >> August 13, 2012 06:04 PM Eastern Standard Time To: Peter Stanf= orth >> Cc: Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org >> Subject: Re: [paws] XML schema versus J= SON, >> 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/ ) 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 >> > 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" >> >> > wr= ote: >> >> >Our experience in the IETF over many years is that economizin= g >> message >size and compromising utility and security in search = of >> efficiency of >implementation on small devices is a poor tra= de 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 load= ed on a >> small device is reasonable. > >Brian (as individual) = > >> > > > -----Original Message----- >From: Peter >> Stanforth [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 >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" > 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) t= o be >> realizable in an implementation with limited resources, >>>suc= h 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-byte= s >> still). >> >>In use cases and requirements document, th= ere 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 >>> Be= n >>> >> >>> >>>> 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 >> >>>> >> >>>> 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 >> >>>> >>>> >> Teco >>>> _______________________________________________ >>>> >> paws mailing list >>>> paws@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/paws >> >>>> >>> >>= > >> _______________________________________________ >>> paws maili= ng >> list >>> paws@ietf.org = >>> >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >>_______________________________________________ >>paws mailing >> list >>paws@ietf.org >> >>https://www.ietf.org/mailman/listinfo/paws >> > >> >_______________________________________________ >paws mailing = list >> >paws@ietf.org >> >https://www.ietf.org/mailman/listinfo/paws >> >> >> _______________________________________________ paws= mailing > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_8375F6DAEFB09F48815203F1FE23B797117AA6DA87shelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Raj,=

     

    If LoST requires XML and PAWS requires JSON, woul= dn’t that mean the master device would need to support both XML and J= SON?

     

    Don

     

    From= : Don Joslyn
    Sent: Saturday, August 25, 2012 8:41 AM
    To= : Basavaraj.Patil@nokia.com
    Cc: Peter.McCann@huawei.com; Bria= n.Rosen@neustar.biz; Gabor.Bajko@nokia.com; 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?

    <= o:p> 

    Sent from my Verizon Wireless 4G LTE DROID RAZR


    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 opt= ion no doubt. I am more
    focused on the actual query/response protocol w.= r.t the encoding
    discussion.
    Database discovery can be a separate as= pect 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 tha= t 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> wrote:

    >I = think you are mis-representing Brian's point of view.  I share his
    = >concern about re-inventing encodings for LoST/xCard.
    >
    >-Pe= te
    >
    >
    >Basa= varaj.Patil@nokia.com wrote:
    >>
    >> +1 to Brian's vie= w on using JSON only.
    >>
    >> From: "<ext Rosen>= ;", "Brian.Rosen@neust= ar.biz"
    >> <Brian.Rosen@neustar.biz>
    >> Date: Friday, August 24, 2012 = 2:48 PM To: Gabor Bajko
    >> <gabor.bajko@nokia.com> Cc: "paws@ietf.org" <paws@ietf.= org> Subject: Re:
    >> [paws] XML schema versus JSON, vCard &= amp; iCal
    >>
    >>
    >> The problem we face with JS= ON only is the LoST/xCard/... issue.  As
    >> long as there is = no objection to creating JSON encodings of existing
    >> standards i= n order to use JSON, and no one uses the fact that these
    >> encodi= ngs don't exist as a reason to roll our own equivalents, I am
    >> o= kay with JSON only.
    >>
    >> Brian
    >>
    >>= On Aug 24, 2012, at 3:08 PM, Gabo= r.Bajko@nokia.com wrote:
    >>
    >>
    >> &nb= sp;     WiFi world builds on mandating the implementati= on (and
    >> certification) of a base spec, and a set of optional fe= atures. If an
    >> optional feature is not supported by one of the p= eers, they can still
    >> talk, but not use that feature. That is ba= sically option B) from
    >> Brain's list.
    >>
    >>&n= bsp;      I'd like to suggest that we recognize th= at option A) and B) are valid
    >> options, while option C) is inval= id, and we should stop debating it.
    >>    &nbs= p;  I'd also like to add the obvious option D) to the list, which is t= hat
    >> both the master devices and DBs support one and the same en= coding ;)
    >>
    >>       Opti= on A) seems to be like a good compromise, and would cut
    >> discuss= ions short, with the only caveat that if there is no strong
    >> tec= hnical argument for supporting and specifying two different
    >> enc= odings, then the iesg may send the document back to the wg to pick
    >&= gt; 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<= br>>> frankly, I do not see a strong argument in favor of two differe= nt
    >>encodings.
    >>
    >>    &n= bsp;  Is there anyone who has a technical argument against supporting = only
    >> one encoding, being that either xml or json?
    >> <= br>>>       Most people speak in favor = of JSON, because it is compact and more
    >> efficient. I went throu= gh 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
    >> r= eally any valid technical reason against using JSON only?
    >>
    &= gt;>       -     =      Gabor
    >>
    >>
    >> &= nbsp;     From: paws-bounces@ietf.org [mailt= o:paws-bounces@ietf.org] On Behalf
    >> Of ext Rosen, Brian
    &= gt;>       Sent: Friday, August 24, 2012 1= 0:43 AM
    >>       To: Benjamin A. Rol= fe
    >>       Cc: paws@ietf.org
    >>     &nb= sp; Subject: Re: [paws] XML schema versus JSON, vCard & iCal
    >>= ;
    >>       Okay:
    >>
    &g= t;>       So, I implement a database, and = I implement XML
    >>       You impleme= nt a device, and you implement JSON
    >>
    >>  &nb= sp;    You query my database (let's not get into how you do = that query
    >> without deciding XML vs JSON) and discover I impleme= nt XML only
    >>
    >>       Wh= at do you do?
    >>
    >>       = Brian
    >>
    >>       On Aug 2= 4, 2012, at 1:38 PM, "Benjamin A. Rolfe"
    >> <ben@blindcreek.com> wrote:
    >>= ;
    >>
    >>
    >>
    >>   &nbs= p;   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 ea= ch supports, without requiring
    >> that any device implement every = option.  It works.
    >>
    >>    &nb= sp;  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.
    >= >
    >>
    >>
    >>
    >>   &= nbsp;   One is that one end implements both choices and the other= end
    >> implements one or both.
    >>
    >> &nbs= p;     The other is that both ends implement one specif= ic choice ("MUST
    >> implement") and both can optionally = implement the other choice.  Only
    >> if both ends implement t= he other choice would that be available.
    >>
    >> &nbs= p;     So, in this case we could do one of the followin= g:
    >>       A) Databases implement b= oth XML and JSON, devices implement either
    >>   &nb= sp;   B) Both Databases and devices implement one (say XML) and o= ptionally
    >> implement the other (say JSON)
    >>
    >&g= t;       You are advocating for A, Richard wa= s suggesting B.
    >>
    >>      = ; I don't care, but choice C) Both databases and devices have a choice
    &= gt;> of what to implement doesn't work for me (or Richard).
    >> =
    >>       Brian
    >>
    >= >       On Aug 24, 2012, at 12:57 PM, Benj= amin A. Rolfe <ben@blindcreek.com<= /a>>
    >> wrote:
    >>
    >>
    >>  = ;     Apparently I was unclear.  I certainly an ca= pable of being wrong as I
    >> practice often, but in this case it i= s quite unlikely :-).
    >>
    >>     = ;  You do not need to choose only one form to achieve
    >> inte= roperability.   If you have two, let the device implementer figur= e
    >> out which is best for their particular device requirements an= d trade-
    >> offs.  This is *preferable* from my perspective.<= br>>>
    >>       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 ;-).
    >>
    >>     &nb= sp; It is my *opinion* at the  moment that if you provide options, to<= br>>> 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  b= ootstrap protocol), everything
    >> else could be options.  Thi= s requires additional functions in both
    >> database and device imp= lementations.
    >>       If on the oth= er hand the device can "just know" that the database has
    >&= gt; two forms available, it won't need to dynamically figure it out.
    >= ;> The device implementer has options and simplicity, so I like it.
    &= gt;>
    >>       Since I am focused= on the TVWS devices that need access to the
    >> database, and not = a database implementer, shifting burden onto the
    >> database imple= menter (not me) to reduce the burden on the device
    >> implementer = (me) is preferred from my perspective.  The database
    >> imple= menter may have another perspective.  Should I point out that
    >&= gt; there will be a lot more devices than databases?  That might sound=
    >> like an argument, though, so I won't....:-j
    >>
    &g= t;>       Ben
    >>
    >> >>
    >>       Brian is right .= . sorry but the rest of you are wrong. J
    >>
    >> &nbs= p;     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 hav= e to
    >> choose SOMETHING to create a baseline of interoperability.=
    >>
    >>       A virtually i= dentical argument  is now playing out in discussions of
    >> ma= ndatory audio and codec implementations for WEBRTC like things.
    >>=
    >>       IMHO XML MUST anything el= se 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 y= ou now can go back to your regularly schedule
    >> programming. J>>
    >>
    >>       Fro= m:     paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On B= ehalf
    >> Of Basavaraj= .Patil@nokia.com
    >>       Sent: = Thursday, August 23, 2012 5:44 PM
    >>     =   To: Brian.Rosen@neustar.b= iz; d.joslyn@spectrumbri= dge.com
    >>       Cc: paws@ietf.org
    >>    =    Subject: Re: [paws] XML schema versus JSON, vCard & iCal>>
    >>
    >>       I = agree with Brian.
    >>       There nee= ds to be a default mandatory to implement option in order to
    >> ac= hieve interoperability.
    >>       And= this applies to the device and database side of the protocol.
    >> =
    >>       -Raj
    >>
    >&= gt;       From: "<ext Rosen>"= , "Brian.Rosen@neustar.biz<= /a>"
    >> <    Brian.= Rosen@neustar.biz>     Date: Thursday, August 23= , 2012 2:43 PM  To:
    >> Don Joslyn <d.joslyn@spectrumbridge.com>  &nbs= p;   Cc: "paws@ietf.org= "
    >> <paws@ietf.org&g= t;       Subject: Re: [paws] XML schema versu= s JSON, vCard &
    >>iCal
    >>
    >>  &nb= sp;    One of my favorite IETF expressions is "There ar= e no protocol
    >> police".  We apply that in lots of ways= , but one of them is that if
    >> you don't implement what the docum= ent says, you may not get
    >> interoperability with other implement= ations.  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 t= rue, why do you need a standard?
    >>
    >>   =     If you say "either" to both ends, then you don= 't get interoperability.
    >>
    >>    &n= bsp;  By your argument, we should stop working, and the product manage= rs
    >> will figure it out using proprietary protocols.  The ma= rket will decide.
    >>
    >>     &nb= sp; So, I feel strongly that if one end is "either", the other en= d must
    >> be "both".  It's also acceptable to say b= oth ends implement one choice
    >> and the other is optional at both= ends.  Here, I think it's server
    >> does both and client doe= s either.
    >>
    >>       It's= always possible to build an implementation of a server that only
    >&g= t; does one: there are no protocol police.
    >>
    >> &n= bsp;     Brian <as individual>
    >>
    &g= t;>
    >>
    >>
    >>     =   On Aug 23, 2012, at 3:11 PM, Don Joslyn <d.joslyn@spectrumbridge.com>
    >> wrot= e:
    >>
    >>
    >>
    >>
    >> &nb= sp;     Hi Ben,  That was my original suggestion, = and I still think it makes
    >> the most sense.   &nb= sp;   Thanks for supporting the proposal.    =   Don
    >>
    >>       Fro= m: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On B= ehalf
    >> Of Benjamin A. Rolfe
    >>    &= nbsp;  Sent: Thursday, August 23, 2012 3:05 PM
    >>  =      To: paws@ietf.org=
    >>       Subject: Re: [paws] XM= L schema versus JSON, vCard & iCal
    >>
    >>  =      Someone suggested that PAWS define both, and let t= he vendors decide
    >> which ones to implement.
    >> &nb= sp;     That makes the most sense for both DB and devic= e vendors.
    >> Markets will probably drive DB vendors to do both. D= evice vendors will
    >> do what fits the market segment they're afte= r. Why over-constrain (or
    >> argue when natural selection will tak= e care of it for us?).
    >>       B>>
    >>
    >>
    >>
    >>  &n= bsp;    Sounds good to me.
    >>
    >> &nb= sp;     From: = paws-bounces@ietf.org <mail= to: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&g= t;
    >>       Sent: Tuesday, August 21= , 2012 12:42 AM
    >>       To: paws@ietf.org <mailto:paws@ietf.org>
    >>     = ;  Subject: Re: [paws] XML schema versus JSON, vCard & iCal
    >= ;>
    >>       Now I can't see anym= ore any willingness to agree on one or the other
    >> encoding. = ;    To prevent endless discussions on this topic I'd sugges= t we
    >> move forward with supporting both in the DB and either one= in the master
    >> device.       Any = objections?
    >>
    >>       Ga= bor
    >>
    >>
    >>     &nbs= p; From: paws-bounces@ietf.org= <mailto:paws-bounces@ietf.org<= /a>>
    >> [    mailto:paws-b= ounces@ietf.org <mailto:paw= s-bounces@ietf.org> ] On
    >> Behalf Of ext Das, Subir
    >= ;>       Sent: Monday, August 20, 2012 2:5= 0 PM
    >>       To: Don Joslyn; Vincen= t Chen; Weixinpeng
    >>       Cc: paws@ietf.org <mailto:paws@ietf.org> ; Manikkoth Sajeev
    >> &= nbsp;     Subject: Re: [paws] XML schema versus JSON, v= Card & 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 importan= t points:
    >>
    >>
    >>    &nbs= p;          *   = ;    Simple-to-use libraries exist for all major languages/p= latforms
    >>         &= nbsp;     *       Don't n= eed a tool chain to work with the data, as is typically
    >> needed = for XML
    >>
    >>
    >>
    >>
    >>&nbs= p;      From: paws-bounces@ietf.org <mailto:paws-bounces@ietf.org>
    >> [mailto:paws-bounces@ietf.org] <mailto:[mailto:paws-bounces@ietf.org]><= br>>> On Behalf Of Don Joslyn
    >>    &nbs= p;  Sent: Monday, August 20, 2012 4:54 PM
    >>   = ;    To: Vincent Chen; Weixinpeng
    >>  &nb= sp;    Cc: paws@ietf.org <mailto:paws@ietf.org> ; Manik= koth Sajeev
    >>       Subject: Re: [p= aws] XML schema versus JSON, vCard & iCal
    >>
    >> = ;      Please see my comments below...
    >>=        Thanks,
    >>   &= nbsp;   Don
    >>
    >>     = ;  From: paws-bounces@ietf.or= g <mailto:paws-bounces@ietf= .org>
    >> [mailto:p= aws-bounces@ietf.org <mailt= o:paws-bounces@ietf.org> ] On
    >> Behalf Of Vincent Chen
    = >>       Sent: Monday, August 20, 2012 = 2:56 PM
    >>       To: Weixinpeng
    &= gt;>       Cc: paws@ietf.org <mailto:paws@ie= tf.org> ; Manikkoth Sajeev
    >>     =   Subject: Re: [paws] XML schema versus JSON, vCard & iCal
    >= >
    >>
    >>       * &= nbsp;     One of our goals is to strive to lower the co= st and
    >> complexity for device manufacturers. This lowers the bar= rier for
    >> building a robust ecosystem.
    >>
    >>&= nbsp;      [DJ - The "cost" and complexi= ty of using XML has not been an issue
    >> for the half dozen TVBD v= endors that have already used XML. Maybe we
    >> need to better defi= ne "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&qu= ot; anywhere in the world serves as a good model.
    >>
    >>&= nbsp;      [DJ - I proposed that the databases sup= port both XML and JSON,
    >> devices only need to support one to tal= k 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 be= cause it's the one that we currently use on
    >> all embedded device= s.]
    >>
    >>       * &nb= sp;     There's a trend for APIs on the web towards JSO= N (Twitter,
    >> FourSquare, Facebook, Google, etc.). One of the maj= or reasons is that
    >> developers (client-side) prefer it for its s= implicity:
    >>
    >>      &nbs= p;        *     = ;  Representation closely matches most data models (nested lists and>> maps)          = ;       *      = Simple-to-use libraries exist for all major
    >> languages/platform= s           *  =      Don't need a tool chain to work with the data,
    = >> as is typically needed for XML.
    >>
    >> &nbs= p;     Apparently, the efficiency gains of JSON also ma= tter to the
    >> scalability of serving systems.
    >>
    >= ;>
    >>       [DJ - I can't argue = against these listed pros for JSON, especially
    >> when you're deal= ing with a lot of data (like Twitter, FourSquare,
    >> Facebook and = Google does). But I'm assuming that PAWS messages will
    >> not be e= xchanged nearly as often as the applications mentioned above.
    >> B= ut 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,
    &= gt;> rather than the encoding. We (Google) are actually neutral on XML v= s
    >> JSON, as long as we're clear on what device makers want. It w= ould 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 su= pport
    >>XML?
    >>
    >>
    >>
    >>&nb= sp;      [DJ - We currently support half a dozen T= VDB radio vendors (embedded
    >> devices) using XML, non using JSON.= XML has not been a burden, and the
    >> amount of data that needs t= o be exchanged between device and database
    >> is not that much or = exchanged that often.]
    >>
    >>    &nbs= p;  On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng <weixinpeng@huawei.com
    >> <mailto:weixinpeng@huawei.com> >= wrote:       Considering of the design of>> database discovery protocol, the LoST protocol may be used and Lo= ST 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> = ] 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> ;
    >> vchen@google.com <mailto:vchen@google.com> ; peter@spectrumbridge.com
    >> <mailto:peter@spectrumbridge.com>
    >>
    &= gt;>       Cc: paws@ietf.org <mailto:paws@ie= tf.org>
    >>       Subject: Re:= [paws] XML schema versus JSON, vCard & iCal
    >>
    >>&n= bsp;      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 d= ecide to roll our own versus using
    >> existing standards based on = the idea there is no json representation
    >> of an existing standar= d.  So, if choosing json means folks feel free
    >> to ignore e= xisting xml based standards such as xCard and LoST, then I
    >> woul= d not want to use json.
    >>
    >>    &nb= sp;  I would prefer to not have "both", because of interoper= ability
    >> complications.  If there is rough consensus for bo= th, then I would
    >> assert that all servers have to implement both= and the client can
    >> implement either.
    >>
    >>&= nbsp;      There are json validators, so I don't t= hink that is a big deal.
    >>
    >>    &n= bsp;  My experience in protocol design on the Internet is that decisio= ns
    >> made solely or even largely because of compactness advantage= s rarely
    >> are good choices.  If you like json because it is= smaller, then I
    >> believe you need a much better reason.  B= inary doesn't work for me, at
    >> all.  I have been involved i= n big binary vs text wars in protocol
    >> design.  Text wins, = binary loses, in my opinion.
    >>
    >>   &nbs= p;   Brian <as individual>
    >>
    >> &n= bsp;     From: Manikkoth Sajeev <mksaji@yahoo.com &l= t;mailto:mksaji@yahoo.com> ><= br>>>       Reply-To: Manikkoth Sajeev = <mksaji@yahoo.com
    >>= <mailto:mksaji@yahoo.com> &g= t;
    >>       Date: Thu, 16 Aug 2012 2= 2:37:38 -0400
    >>       To: "Gab= or.Bajko@nokia.com <mailto:Gabo= r.Bajko@nokia.com> "
    >> <Gabor.Bajko@nokia.com <= mailto:Gabor.Bajko@nokia.com&g= t; >, "Rosen, Brian"
    >> <brian.rosen@neustar.biz &= lt;mailto:brian.rosen@neustar.bi= z> >,
    >> "vchen@google.com <mailto:vchen@google.com> " <vchen@google.com
    >> <mailto:vchen@google.com> >, "peter@spec= trumbridge.com
    >> <= mailto:peter@spectrumbridge.com> " <peter@spectrumbridge.com
    >> <mailto:peter@spectrumbridge.com>= ; >
    >>       Cc: "paws@ietf.= org <mailto:paws@ietf.org> "= ; <paws@ietf.org
    >> <= ;mailto:paws@ietf.org> >
    >= >       Subject: Re: [paws] XML schema ver= sus JSON, vCard & iCal
    >>
    >>    =    Hi,
    >>
    >>     &nbs= p; 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 wi= th other implementation
    >> languages.
    >>
    >>&nbs= p;      Best Regards,
    >>
    >>&nbs= p;      Sajeev Manikkoth    &n= bsp;    Mobile: +918792292002 <tel:%2B918792292002>      Email:
    &= gt;> mksaji@ieee.org <mailto:mksaji@ieee.org>
    >> = ;      http://www.linkedin.com/in/mksajeev
    >> <http://www.linkedin.com/in/mksajeev&g= t;
    >>
    >>
    >>      = ; From: "Gabor.Bajko@nokia.com <mailto:Gabor.Bajko@nokia.com> "
    >> <Gabor.Baj= ko@nokia.com <mailto:Gabor.Bajk= o@nokia.com> >       To:
    >>= ; Brian.Rosen@neustar.biz &l= t;mailto:Brian.Rosen@neustar.biz= > ;
    >> vchen@google.com= <mailto:vchen@google.com>= ; ; peter@spectrumbridge.com
    >> <    mailto:peter@= spectrumbridge.com>     Cc: paws@ietf.org
    >> <mailto:paws@ietf.org>       = Sent: Friday, 17 August 2012, 4:55       Sub= ject: Re:
    >> [paws] XML schema versus JSON, vCard & iCal
    &g= t;>
    >>
    >>       We hav= e not heard any objections for using JSON encoding instead of
    >> X= ML.  Therefore, let's go for JSON, and close this thread.
    >> =
    >>       - Gabor
    >>
    &g= t;>       -----Original Message-----
    &g= t;>       From: 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
    >>    &nbs= p;  Sent: Monday, August 13, 2012 3:14 PM
    >>   = ;    To: 'Vincent Chen'; 'Peter Stanforth'
    >> =       Cc: 'paws@ietf.org <mailto:paws@ietf.org> '
    >>   &nb= sp;   Subject: Re: [paws] XML schema versus JSON, vCard & iCa= l
    >>
    >>       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:     Vin= cent Chen
    >> [mailto:vchen@goo= gle.com <mailto:vchen@google.com= > ]  Sent:    Monday,
    >> August 13, 201= 2 06:04 PM Eastern Standard Time        = To:    Peter Stanforth
    >>    &n= bsp;  Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe;= paws@ietf.org
    >> <mailto:paws@ietf.org>   &nb= sp;    Subject:    Re: [paws] XML schema vers= us JSON,
    >> vCard & iCal
    >>
    >>  &= nbsp;    XML vs JSON
    >>
    >>  &nb= sp;    Between XML and JSON, JSON messages are more compact = and easier to
    >> process (parsing, synthesis). As clarification, J= SON does not require
    >> JavaScript or a Browser. It is a text-base= d representation of data
    >> that is language independent, yet well= -matched to all major languages.
    >> JSON-handling libraries exist = for numerous languages (see of
    >> htt= p://json.org/ <http://json.org/>= ) and seem to be reasonably light
    >> weight.
    >>
    >= >       Timestamps
    >>
    >>= ;       As for timestamp specifications, shou= ld we consider just using
    >> seconds since the UNIX Epoch (1970-01= -01T00:00:00Z)? This would
    >> eliminate the need for datetime-stri= ng parsing on devices, assuming
    >> devices already have native lib= raries that provide time in this format.
    >> Is that a valid assump= tion? Of course, this is less human-readable....
    >>
    >> <= br>>>       On Mon, Aug 13, 2012 at 6:4= 9 AM, Peter Stanforth
    >> <peter@spectrumbridge.com <mailto:peter@spectrumbridge.com>= ; > wrote:
    >>
    >>
    >>    =        Whenever we built mobile devices we ne= ver dealt with IETF, in our
    >> sensor     = ;       days even an IP stack was a challenge= ,so I would defer to
    >> the device guys    &nb= sp;      on that one.
    >>
    >>&nbs= p;          On MonAug/13/12 Mo= n Aug 13, 9:30 AM, "Rosen, Brian"
    >>
    >> &= nbsp;         <Brian.Rosen@neust= ar.biz <mailto:Brian.Rosen@ne= ustar.biz> > wrote:
    >>
    >>   &nb= sp;       >Our experience in the IETF over= many years is that economizing
    >> message    =        >size and compromising utility and = security in search of
    >> efficiency of    &nbs= p;        >implementation on small de= vices 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.&nb= sp;          >  &= nbsp;      >Assuming a json library can be load= ed on a
    >> small device is reasonable.    &nbs= p;  >         >Brian (as= individual)          &nb= sp; >    
    >>   >  &= nbsp;    >        = ; > -----Original Message-----      >From:&n= bsp; Peter
    >> Stanforth [mailto:peter@spectrumbridge.com
    >> <mailto:peter@spectrumbridge.com> ] &nbs= p;     >Sent:  Saturday, August 11,
    >>= 2012 07:13 AM Eastern Standard Time       &g= t;To:    Teco Boot; Benjamin
    >> A.Rolfe  =          >Cc:    = paws@ietf.org <mailto:paws@ietf.org>      >= ;Subject:
    >>      Re: [paws] XML schema v= ersus JSON, vCard & iCal      >  =        >Not
    >> all masters run ov= er the core network.         &= nbsp;  >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.     &nbs= p;      >      &n= bsp;  >On SatAug/11/12 Sat Aug 11,
    >> 5:30 AM, "Teco = Boot" <teco@inf- net.nl <mail= to:teco@inf-net.nl> > wrote:
    >>    &= nbsp;      >      = ;   >>        >>Op= 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe
    >> het volgende&nb= sp;     >>geschreven:    &nbs= p;        >>   &nbs= p;    >>> Compactness of messages
    >> is im= portant, but it is also important (to me      = ;       >>>at least) to be
    >&g= t; realizable in an implementation with limited resources,   = ;        >>>such as
    >>= embedded devices in what are now popularly called "M2M" &nb= sp;    
    >> >>>applications.  A = lot of these devices could use IP all the end to
    >> end, &nbs= p;    >>>but may have a very compact, simple stack = and applications
    >> (i.e.  no     &n= bsp;   >>>browser).  Is JSON typically implemented = when there is
    >> no browser?       &= gt;>>Would it be hard to do in a resource constrained
    >> dev= ice (i.e. where we         &nb= sp;   >>>talk about memory size in Kilo-bytes
    >>= ; still).           >&= gt;        >>In use cases and requ= irements document, there are
    >> no requirements for  &nb= sp;    >>protocol performance. I guess OS/IP/TCP/TLS>> code size supersedes needs      &n= bsp; >>for JSON or XML.        >= ;>        >>Same
    >> fo= r timing: TCP/TLS connection setup will take more than the PAWS  =   
    >> >>message exchange, I think. This may be of= importance when using
    >> >>satcom
    >>  &n= bsp;        >>links.  &n= bsp;       >>    &n= bsp;   >>Because PAWS runs between master and
    >> d= atabase, over core network,      >>performan= ce is not our primary
    >> concern. But as always, it is good to kee= p        >>an eye on efficiency.>>           >= >        >>Teco  &nbs= p;         >>  &nbs= p;     >>> Thanks     = ;   >>> Ben       &nb= sp;   >>>  
    >> >>> &nb= sp;     >>>> We had a discussion on XML vs.= JSON. I prefer the one
    >> >>> with
    >> most = ;     >>>>compact messages.  &nbs= p;          >>>>&n= bsp;     >>>> On vCard and JSON:
    >>= ; what is the status of "A JavaScript Object Notation   = ;    >>>>(JSON)
    >> Representation for v= Card"?        >>>>
    &= gt;> = http://tools.ietf.org/html/draft-bhat-vcarddav-json-00
    >> <= http://t= ools.ietf.org/html/draft-bhat-vcarddav-json-00>   &nb= sp;      >>>> 
    >> >&= gt;>> On valid times: can we use same format as certificates? They ha= ve       
    >>   = >>>>similar simple requirements: valid notBefore&  no= tAfter.      
    >> >>>> <= a href=3D"http://tools.ietf.org/html/rfc3280#section-4.1.2.5">http://tools.= ietf.org/html/rfc3280#section-4.1.2.5
    >> <http://tools.ietf.org/html/rf= c3280#section-4.1.2.5>      >>>>= ;      >>>>
    >> Teco &nbs= p;    >>>> _____________________________________= __________      >>>>
    >> paws = mailing list         >>>&g= t; paws@ietf.org <mailto:paws@ietf.org>    
    &g= t;> >>>> https://www.ietf.org/mailman/listinfo/paws
    >> <https://www.ietf.org/mailma= n/listinfo/paws>      >>>> = ;     >>>       = >>>
    >> _______________________________________________&nb= sp;          >>> paws= mailing
    >> list      >>> paws@ietf.org <mailto:paws@ietf.org>      &nbs= p;   >>>
    >> https://www.ietf.org/mailman/listinfo/paws
    >&= gt; <https://www.= ietf.org/mailman/listinfo/paws>      >&g= t;   
    >> >>_________________________________= ______________         >>paws= mailing
    >> list      >>paws@ietf.org <mailto:paws@ietf.org>        >> >>h= ttps://www.ietf.org/mailman/listinfo/paws
    >> <https://www.ietf.org/mailman/list= info/paws>      >    = ;
    >> >_______________________________________________ &nb= sp;        >paws mailing list
    >= >           >paws@ietf.org <mailto:paws@ietf.org>      &nbs= p; 
    >> >https://www.ietf.org/mailman/listinfo/paws
    >> <https://www.ietf.org/mailm= an/listinfo/paws>
    >>
    >>    &n= bsp;      ________________________________________= _______           paws ma= iling
    >

    _______________________________________________
    paw= s mailing list
    paws@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/paws

    = --_000_8375F6DAEFB09F48815203F1FE23B797117AA6DA87shelby_-- From Basavaraj.Patil@nokia.com Mon Aug 27 07:15:08 2012 Return-Path: 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 796CB21F86B8 for ; Mon, 27 Aug 2012 07:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.002 X-Spam-Level: X-Spam-Status: No, score=-106.002 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 69gYhfOAcNse for ; Mon, 27 Aug 2012 07:15:04 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E51BA21F8678 for ; Mon, 27 Aug 2012 07:15:03 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7REEtaQ008401; Mon, 27 Aug 2012 17:14:56 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Aug 2012 17:14:55 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0309.003; Mon, 27 Aug 2012 16:14:54 +0200 From: To: Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Iej7JadvAx8UahySbuq9n2zQAAU/5DAJUxXAAABrI7AAAWoncAABh1noAAifZJAAAEHtqAAAHwqAAADmEvAACA/ioAAAG/7gAAADZkgAABIt+A///NtAD//meaQIADLqOAgAADSYCAAAgwgIAAAR6AgAAX74CAAAsjAP//rRSAgABqLoD//8WEgAAr8oFc//zTEsD/+glIAA== Date: Mon, 27 Aug 2012 14:14:54 +0000 Message-ID: In-Reply-To: <8375F6DAEFB09F48815203F1FE23B797117AA6DA87@shelby> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [72.64.105.77] Content-Type: multipart/alternative; boundary="_000_CC60E9CF22976basavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Aug 2012 14:14:55.0775 (UTC) FILETIME=[555FDAF0:01CD845E] X-Nokia-AV: Clean Cc: paws@ietf.org, 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 14:15:08 -0000 --_000_CC60E9CF22976basavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Don, If the DB discovery follows the approach recommended in : draft-probasco-p= aws-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 > Date: Monday, August 27, 2012 8:15 AM To: Basavaraj Patil > Cc: "Peter.McCann@huawei.com" >, "Brian.Rosen@neustar.biz" >, Gabor Bajko >, "paws@ietf.org" > Subject: RE: [paws] XML schema versus JSON, vCard & iCal Raj, If LoST requires XML and PAWS requires JSON, wouldn=92t that mean the maste= r 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 Cc: Peter.McCann@huawei.com; Brian.Rosen@ne= ustar.biz; Gabor.Bajko@nokia.com; 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 th= e message format? Sent from my Verizon Wireless 4G LTE DROID RAZR 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" > 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 wrote: >> >> +1 to Brian's view on using JSON only. >> >> From: "", "Brian.Rosen@neustar.biz" >> > >> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko >> > Cc: "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 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 va= lid >> 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 t= hat >> 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 on= ly >> 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] On Behalf >> Of ext Rosen, Brian >> Sent: Friday, August 24, 2012 10:43 AM >> To: Benjamin A. Rolfe >> Cc: 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" >> > wrote: >> >> >> >> >> There are two ways to achieve interoperability when you have an op= tion. >> 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 optional= ly >> 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 choi= ce >> of what to implement doesn't work for me (or Richard). >> >> Brian >> >> On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe > >> wrote: >> >> >> Apparently I was unclear. I certainly an capable of being wrong a= s 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 t= he >> 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 JS= ON >> 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] On Behalf >> Of Basavaraj.Patil@nokia.com >> Sent: Thursday, August 23, 2012 5:44 PM >> To: Brian.Rosen@neustar.biz; d.jos= lyn@spectrumbridge.com >> Cc: 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: "", "Brian.Rosen@neustar.biz" >> > Date: Thur= sday, August 23, 2012 2:43 PM To: >> Don Joslyn > Cc: "paws@ietf.org" >> > Subject: Re: [paws] XML sche= ma 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 interoperabil= ity. >> >> 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 mus= t >> 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 o= nly >> does one: there are no protocol police. >> >> Brian >> >> >> >> >> On Aug 23, 2012, at 3:11 PM, Don Joslyn > >> wrote: >> >> >> >> >> Hi Ben, That was my original suggestion, and I still think it mak= es >> the most sense. Thanks for supporting the proposal. Don >> >> From: 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 >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >> >> Someone suggested that PAWS define both, and let the vendors decid= e >> 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 ] On >> Behalf Of Gabor.Bajko@nokia.com >> Sent: Tuesday, August 21, 2012 12:42 AM >> To: 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 oth= er >> encoding. To prevent endless discussions on this topic I'd suggest w= e >> 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 ] On >> Behalf Of ext Das, Subir >> Sent: Monday, August 20, 2012 2:50 PM >> To: Don Joslyn; Vincent Chen; Weixinpeng >> Cc: paws@ietf.org ; M= anikkoth 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 langua= ges/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] >> On Behalf Of Don Joslyn >> Sent: Monday, August 20, 2012 4:54 PM >> To: Vincent Chen; Weixinpeng >> Cc: paws@ietf.org ; M= anikkoth 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 ] On >> Behalf Of Vincent Chen >> Sent: Monday, August 20, 2012 2:56 PM >> To: Weixinpeng >> Cc: paws@ietf.org ; M= anikkoth 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, supportin= g >> 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 (n= ested lists and >> maps) * Simple-to-use libraries exist for all majo= r >> languages/platforms * Don't need a tool chain to work wi= th 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 suppor= t >>XML? >> >> >> >> [DJ - We currently support half a dozen TVDB radio vendors (embedd= ed >> 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 >> > 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 ] On >> Behalf Of Rosen, Brian >> >> Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; >> gabor.bajko@nokia.com ; >> vchen@google.com ; pe= ter@spectrumbridge.com >> >> >> Cc: 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 >> >> From: Manikkoth Sajeev = > >> Reply-To: Manikkoth Sajeev >> > >> Date: Thu, 16 Aug 2012 22:37:38 -0400 >> To: "Gabor.Bajko@nokia.com " >> >, "Rosen, Brian" >> >, >> "vchen@google.com " <= vchen@google.com >> >, "peter@spectrum= bridge.com >> " >> > >> Cc: "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 Email: >> mksaji@ieee.org >> http://www.linkedin.com/in/mksajeev >> >> >> >> From: "Gabor.Bajko@nokia.com " >> > To: >> Brian.Rosen@neustar.biz ; >> vchen@google.com ; pe= ter@spectrumbridge.com >> Cc: paws@ietf.org >> Sent: Friday, 17 August 2012, 4:55 S= ubject: Re: >> [paws] XML schema versus JSON, vCard & iCal >> >> >> We have not heard any objections for using JSON encoding instead o= f >> XML. Therefore, let's go for JSON, and close this thread. >> >> - Gabor >> >> -----Original Message----- >> From: 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 ' >> 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 >> >> >> >> -----Original Message----- From: Vincent Chen >> [mailto:vchen@google.com ] Sent: Monday, >> August 13, 2012 06:04 PM Eastern Standard Time To: Peter Stanf= orth >> Cc: Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org >> Subject: Re: [paws] XML schema versus J= SON, >> 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/ ) 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 >> > 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" >> >> > wrote: >> >> >Our experience in the IETF over many years is that economizin= g >> message >size and compromising utility and security in search = of >> efficiency of >implementation on small devices is a poor tra= de 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 load= ed on a >> small device is reasonable. > >Brian (as individual) = > >> > > > -----Original Message----- >From: Peter >> Stanforth [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 >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" > 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) t= o be >> realizable in an implementation with limited resources, >>>suc= h 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-byte= s >> still). >> >>In use cases and requirements document, th= ere 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 >>> Be= n >>> >> >>> >>>> 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 >> >>>> >> >>>> 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 >> >>>> >>>> >> Teco >>>> _______________________________________________ >>>> >> paws mailing list >>>> paws@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/paws >> >>>> >>> >>= > >> _______________________________________________ >>> paws maili= ng >> list >>> paws@ietf.org = >>> >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >>_______________________________________________ >>paws mailing >> list >>paws@ietf.org >> >>https://www.ietf.org/mailman/listinfo/paws >> > >> >_______________________________________________ >paws mailing = list >> >paws@ietf.org >> >https://www.ietf.org/mailman/listinfo/paws >> >> >> _______________________________________________ paws= mailing > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CC60E9CF22976basavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4483B83DAA7D2C4089F4C974011C6096@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable

    Hi Don,

    If the DB discovery follows the approach recommended in  : <= span class=3D"Apple-style-span" style=3D"font-family: monospace; font-size:= 13px; line-height: 15px; white-space: pre; -webkit-border-horizontal-spaci= ng: 2px; -webkit-border-vertical-spacing: 2px; ">draft-probasco-paws-discov= ery, then you could simply use JSON for the encoding and thereby harmoniz= e the encoding approach for discovery and the query (PAWS) protocol. <= /div>

    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> Date: Monday, August 27, 2012 8:15 = AM
    To: Basavaraj Patil <basavaraj.patil@nokia.com>
    Cc: "Peter.McCann@huawei.com" <Peter.McCann@huawei.com>, "Brian.Rosen@neustar.biz" <Brian.Rosen@neustar.biz>, Gabor Bajko <gabor.bajko@nokia= .com>, "paws@ietf.org"= ; <paws@ietf.org>
    Subject: RE: [paws] XML schema vers= us JSON, vCard & iCal

    Raj,

     

    If LoST requires XML and PAWS requ= ires JSON, wouldn=92t that mean the master device would need to support bot= h XML and JSON?

     

    Don

     

    From: Don Joslyn
    Sent: Saturday, August 25, 2012 8:41 AM
    To: Basavaraj.Patil@nok= ia.com
    Cc: Peter.McCann@huawei.c= om; Brian.Rosen@neustar.biz; Gabor= .Bajko@nokia.com; paws@ietf.org
    Subject: Re: [paws] XML schema versus JSON, vCard & iCal

     

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

     

    Sent from my Verizo= n Wireless 4G LTE DROID RAZR



    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> wrote:

    >I think you are mis-representing Brian's point of view.  I share h= is
    >concern about re-inventing encodings for LoST/xCard.
    >
    >-Pete
    >
    >
    >Basavaraj.Patil@nokia.com<= /a> wrote:
    >>
    >> +1 to Brian's view on using JSON only.
    >>
    >> From: "<ext Rosen>", "    Brian.Rosen@neustar.biz"
    >> <Brian.Rosen@neustar= .biz>
    >> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko
    >> <gabor.bajko@nokia.com= > Cc: "paws@ietf.org"= <paws@ietf.org> Subject: Re: >> [paws] XML schema versus JSON, vCard & iCal
    >>
    >>
    >> The problem we face with JSON only is the LoST/xCard/... issue.&nb= sp; As
    >> long as there is no objection to creating JSON encodings of existi= ng
    >> standards in order to use JSON, and no one uses the fact that thes= e
    >> encodings don't exist as a reason to roll our own equivalents, I a= m
    >> okay with JSON only.
    >>
    >> Brian
    >>
    >> On Aug 24, 2012, at 3:08 PM, 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 st= ill
    >> talk, but not use that feature. That is basically option B) from >> Brain's list.
    >>
    >>       I'd like to suggest that we re= cognize that option A) and B) are valid
    >> options, while option C) is invalid, and we should stop debating i= t.
    >>       I'd also like to add the obvio= us 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 g= ood 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 p= ick
    >> one of the two specified. As Robert mentioned in his email, this h= as
    >> 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<= br> >>encodings.
    >>
    >>       Is there anyone who has a tech= nical 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 again= st
    >> picking JSON. One said that JSON requires native Java, which is wr= ong,
    >> the other objection gave no real reason. So I am wondering if ther= e is
    >> really any valid technical reason against using JSON only?
    >>
    >>       -     = ;     Gabor
    >>
    >>
    >>       From: 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
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Okay:
    >>
    >>       So, I implement a database, an= d I implement XML
    >>       You implement a device, and yo= u implement JSON
    >>
    >>       You query my database (let's n= ot 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, &= quot;Benjamin A. Rolfe"
    >> <ben@blindcreek.com&g= t; wrote:
    >>
    >>
    >>
    >>
    >>       There are two ways to achieve = interoperability when you have an option.
    >>       There are many existence proof= s 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 requir= ing
    >> 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 im= plement one specific choice ("MUST
    >> implement") and both can optionally implement the other choic= e.  Only
    >> if both ends implement the other choice would that be available. >>
    >>       So, in this case we could do o= ne of the following:
    >>       A) Databases implement both XM= L 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, Rich= ard was suggesting B.
    >>
    >>       I don't care, but choice C) Bo= th 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>
    >> 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 impl= ementer figure
    >> out which is best for their particular device requirements and tra= de-
    >> offs.  This is *preferable* from my perspective.
    >>
    >>       If you provide more than one f= orm in the database, devices using the
    >> database need some means for figuring out which are available. It<= br> >> can't use it if it doesn't no about it. This is an observations, n= ot
    >> 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 de= vices can
    >> discover what options the database supports.  If you have suc= h a
    >> mechanism and all devices use it (a  bootstrap protocol), eve= rything
    >> else could be options.  This requires additional functions in= both
    >> database and device implementations.
    >>       If on the other hand the devic= e 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 datab= ase
    >> 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 th= e 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 act= ually 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.<= br> >>
    >>       IMHO XML MUST anything else de= fined 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] On Behalf
    >> Of Basavaraj.Patil@no= kia.com
    >>       Sent: Thursday, August 23, 201= 2 5:44 PM
    >>       To: Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com<= /a>
    >>       Cc:     paws@ietf.org
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>
    >>       I agree with Brian.
    >>       There needs to be a default ma= ndatory to implement option in order to
    >> achieve interoperability.
    >>       And this applies to the device= and database side of the protocol.
    >>
    >>       -Raj
    >>
    >>       From: "<ext Rosen>&= quot;, "Brian.Rosen@neustar= .biz"
    >> <Brian.Rosen@neustar= .biz>     Date: Thursday, August 23, 2012 2:43 P= M  To:
    >> Don Joslyn <d.jo= slyn@spectrumbridge.com>      Cc: "paws@ietf.org"
    >> <paws@ietf.org> &n= bsp;     Subject: Re: [paws] XML schema versus JSON, vC= ard &
    >>iCal
    >>
    >>       One of my favorite IETF expres= sions 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 ha= nd, the
    >> whole point of a protocol document like ours is that two independe= nt
    >> 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 st= op working, and the product managers
    >> will figure it out using proprietary protocols.  The market w= ill decide.
    >>
    >>       So, I feel strongly that if on= e end is "either", the other end must
    >> be "both".  It's also acceptable to say both ends i= mplement one choice
    >> and the other is optional at both ends.  Here, I think it's s= erver
    >> 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, D= on Joslyn <d.joslyn@spect= rumbridge.com>
    >> wrote:
    >>
    >>
    >>
    >>
    >>       Hi Ben,  That was my orig= inal suggestion, and I still think it makes
    >> the most sense.       Thanks for sup= porting the proposal.      Don
    >>
    >>       From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf
    >> Of Benjamin A. Rolfe
    >>       Sent: Thursday, August 23, 201= 2 3:05 PM
    >>       To: paws@ietf.org
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Someone suggested that PAWS de= fine 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@i= etf.org> ] On
    >> Behalf Of Gabor.Bajko@nok= ia.com <mailto:Gabor.Bajko@= nokia.com>
    >>       Sent: Tuesday, August 21, 2012= 12:42 AM
    >>       To: paws@ietf.org <mailto:paws@i= etf.org>
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Now I can't see anymore any wi= llingness to agree on one or the other
    >> encoding.     To prevent endless discussions o= n 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@i= etf.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@i= etf.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:
    >>
    >>
    >>           &= nbsp;   *       Simple-to-use libra= ries exist for all major languages/platforms
    >>           &= nbsp;   *       Don't need a tool c= hain 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:[mail= to: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@i= etf.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@i= etf.org> ] On
    >> Behalf Of Vincent Chen
    >>       Sent: Monday, August 20, 2012 = 2:56 PM
    >>       To: Weixinpeng
    >>       Cc: paws@ietf.org <mailto:paws@i= etf.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 data= bases support both XML and JSON,
    >> devices only need to support one to talk to the database. Our curr= ent
    >> 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 us= e 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 t= hat
    >> developers (client-side) prefer it for its simplicity:
    >>
    >>           &= nbsp;   *       Representation clos= ely matches most data models (nested lists and
    >> maps)          &= nbsp;      *       S= imple-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 gai= ns of JSON also matter to the
    >> scalability of serving systems.
    >>
    >>
    >>       [DJ - I can't argue against th= ese listed pros for JSON, especially
    >> when you're dealing with a lot of data (like Twitter, FourSquare,<= br> >> Facebook and Google does). But I'm assuming that PAWS messages wil= l
    >> not be exchanged nearly as often as the applications mentioned abo= ve.
    >> But again, I know JSON is more efficient, can't argue with that.]<= br> >>
    >>       *     = ;  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 hal= f 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 datab= ase
    >> is not that much or exchanged that often.]
    >>
    >>       On Fri, Aug 17, 2012 at 6:06 P= M, Weixinpeng <weixinpeng@hu= awei.com
    >> <mailto:weixinpeng= @huawei.com> > wrote:       Conside= ring of the design of
    >> database discovery protocol, the LoST protocol may be used and LoS= T 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@i= etf.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<= /a>> ;
    >>     vchen@google.com <mailto:vchen@google.com> ; peter@spectrumbridge.com >> <mailto:peter@spect= rumbridge.com>
    >>
    >>       Cc: paws@ietf.org <mailto:paws@i= etf.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 s= ee
    >> the choice of json mean we then decide to roll our own versus usin= g
    >> existing standards based on the idea there is no json representati= on
    >> of an existing standard.  So, if choosing json means folks fe= el free
    >> to ignore existing xml based standards such as xCard and LoST, the= n I
    >> would not want to use json.
    >>
    >>       I would prefer to not have &qu= ot;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<= br> >> implement either.
    >>
    >>       There are json validators, so = I don't think that is a big deal.
    >>
    >>       My experience in protocol desi= gn on the Internet is that decisions
    >> made solely or even largely because of compactness advantages rare= ly
    >> are good choices.  If you like json because it is smaller, th= en I
    >> believe you need a much better reason.  Binary doesn't work f= or me, at
    >> all.  I have been involved in big binary vs text wars in prot= ocol
    >> design.  Text wins, binary loses, in my opinion.
    >>
    >>       Brian <as individual> >>
    >>       From: Manikkoth Sajeev <mksaji@yahoo.com <mailto:mksaji@yahoo.com> >
    >>       Reply-To: Manikkoth Sajeev <= ;mksaji@yahoo.com
    >> <mailto:mksaji@yahoo.co= m> >
    >>       Date: Thu, 16 Aug 2012 22:37:3= 8 -0400
    >>       To: "Gabor.Bajko@nokia.com <mailto:Gabor.Bajko@nokia.com> "
    >> <Gabor.Bajko@nokia.com= <mailto:Gabor.Bajko@nokia.= com> >, "Rosen, Brian"
    >> <brian.rosen@neustar= .biz <mailto:brian.rosen@= neustar.biz> >,
    >> "vchen@google.com <= ;mailto:vchen@google.com> "= <vchen@google.com
    >> <mailto:vchen@google.co= m> >, "peter@spe= ctrumbridge.com
    >> <mailto:peter@spect= rumbridge.com> " <peter@spectrumbridge.com
    >> <mailto:peter@s= pectrumbridge.com> >
    >>       Cc: "paws@ietf.org <mailto:= paws@ietf.org> " <paws@i= etf.org
    >> <mailto:paws@ietf.org&= gt; >
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Hi,
    >>
    >>       Can it not be both JSON and XM= L supported? I would vote for that.
    >> Future implementations may prefer XML as it is generic, omni prese= nt,
    >> easy to understand and validate. For compactness may be a  bi= nary xml
    >> optioncan also work. JSON I think will necessitate implementation = to
    >> be native Java and may not be as friendly with other implementatio= n
    >> languages.
    >>
    >>       Best Regards,
    >>
    >>       Sajeev Manikkoth  &n= bsp;      Mobile: +918792292002 <tel:%2B918792292002>    &n= bsp; Email:
    >> mksaji@ieee.org <mailto:mksaji@ieee.org>
    >>       http://www.linkedin.com/in/mksajeev
    >> <http://www.lin= kedin.com/in/mksajeev>
    >>
    >>
    >>       From: "Gabor.Bajko@nokia.com <mailto:Gabor.Bajko@nokia.com> "
    >> <Gabor.Bajko@nokia.com= <mailto:Gabor.Bajko@nokia.= com> >       To:
    >> Brian.Rosen@neustar.biz= <mailto:Brian.Rosen@neus= tar.biz> ;
    >> vchen@google.com <mailto:vchen@google.com> ; peter@spectrumbridge.com >> <mailto:peter@spect= rumbridge.com>     Cc: paws@ietf.org
    >> <mailto:paws@ietf.org>&= nbsp;       Sent: Friday, 17 August 2012, 4:5= 5       Subject: Re:
    >> [paws] XML schema versus JSON, vCard & iCal
    >>
    >>
    >>       We have not heard any objectio= ns 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@i= etf.org> ] On
    >> Behalf Of ext Rosen, Brian
    >>       Sent: Monday, August 13, 2012 = 3:14 PM
    >>       To: 'Vincent Chen'; 'Peter Sta= nforth'
    >>       Cc: '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 r= ather than a time in seconds since
    >> epoch.  It's very easy to parse, and its simpler to use and d= ebug.
    >> Don't care a whole lot about that
    >>
    >>       Brian <as individual> >>
    >>
    >>
    >>       -----Original Message-----&nbs= p;      From:     Vincent Chen=
    >> [mailto:vchen@google.com &= lt;mailto:vchen@google.com> ]&nb= sp; Sent:    Monday,
    >> August 13, 2012 06:04 PM Eastern Standard Time   &n= bsp;    To:    Peter Stanforth
    >>       Cc:    Rosen, B= rian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
    >> <mailto:paws@ietf.org>&= nbsp;       Subject:    Re: [p= aws] XML schema versus JSON,
    >> vCard & iCal
    >>
    >>       XML vs JSON
    >>
    >>       Between XML and JSON, JSON mes= sages are more compact and easier to
    >> process (parsing, synthesis). As clarification, JSON does not requ= ire
    >> JavaScript or a Browser. It is a text-based representation of data=
    >> that is language independent, yet well-matched to all major langua= ges.
    >> 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 specification= s, 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, assumin= g
    >> devices already have native libraries that provide time in this fo= rmat.
    >> Is that a valid assumption? Of course, this is less human-readable= ....
    >>
    >>
    >>       On Mon, Aug 13, 2012 at 6:49 A= M, Peter Stanforth
    >> <peter@spectrumbrid= ge.com <mailto:peter@spe= ctrumbridge.com> > wrote:
    >>
    >>
    >>           Whenev= er 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        &nb= sp;  on that one.
    >>
    >>           On Mon= Aug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"
    >>
    >>           <Brian.Rosen@neustar.biz <mailto:Brian.Rosen@neustar.biz= > > wrote:
    >>
    >>           >Ou= r 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.        &nb= sp;  >         >Assuming= a json library can be loaded on a
    >> small device is reasonable.       &g= t;         >Brian (as individual= )            >&nb= sp;   
    >>   >       > &nb= sp;       > -----Original Message-----&nbs= p;     >From:  Peter
    >> Stanforth [mailto:pete= r@spectrumbridge.com
    >> <mailto:peter@spect= rumbridge.com> ]       >Sent: = Saturday, August 11,
    >> 2012 07:13 AM Eastern Standard Time     &= nbsp; >To:    Teco Boot; Benjamin
    >> A.Rolfe          = ; >Cc:    paws@ietf.org<= /a> <mailto:paws@ietf.org> =      >Subject:
    >>      Re: [paws] XML schema versus JSON, v= Card & iCal      >    &= nbsp;    >Not
    >> all masters run over the core network.    &nbs= p;       >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.      =       >      &nbs= p;  >On SatAug/11/12 Sat Aug 11,
    >> 5:30 AM, "Teco Boot" <teco@inf- net.nl <mailto:teco@inf-net.nl> > wrote:
    >>           >&n= bsp;        >>   &n= bsp;    >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. = Rolfe
    >> het volgende      >>geschreven:&nbs= p;            >&g= t;        >>> Compactness of me= ssages
    >> is important, but it is also important (to me   &nb= sp;         >>>at least) t= o be
    >> realizable in an implementation with limited resources,  = ;         >>>such as
    >> embedded devices in what are now popularly called "M2M"&= nbsp;     
    >> >>>applications.  A lot of these devices could use I= P 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       &nb= sp;     >>>talk about memory size in Kilo-byte= s
    >> still).          = ; >>        >>In use cases a= nd requirements document, there are
    >> no requirements for       >>pr= otocol performance. I guess OS/IP/TCP/TLS
    >> code size supersedes needs      &nbs= p; >>for JSON or XML.        >&= gt;        >>Same
    >> for timing: TCP/TLS connection setup will take more than the PAWS&= nbsp;   
    >> >>message exchange, I think. This may be of importance when = using
    >> >>satcom
    >>           >&g= t;links.          >>&nbs= p;       >>Because PAWS runs between ma= ster and
    >> database, over core network,      >>= ;performance is not our primary
    >> concern. But as always, it is good to keep    =     >>an eye on efficiency.
    >>           >&g= t;        >>Teco   =          >>   =      >>> Thanks     &= nbsp;  >>> Ben        = ;   >>>  
    >> >>>       >>>> = We had a discussion on XML vs. JSON. I prefer the one
    >> >>> with
    >> most      >>>>compact message= s.             = >>>>      >>>> On vCard an= d JSON:
    >> what is the status of "A JavaScript Object Notation &nbs= p;     >>>>(JSON)
    >> Representation for vCard"?      = ;  >>>>
    >> http://tools.ietf.org/html/draft-bhat-vcarddav-json-00
    >> <http://tools.ietf.org/html/draft-bhat-vcarddav-json-00> &n= bsp;        >>>> 
    >> >>>> On valid times: can we use same format as certifi= cates? They have       
    >>    >>>>similar simple requirements: val= id notBefore&  notAfter.      
    >> >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
    >> <http://tools.ietf.org/html/rfc3280#section-4.1.2.5>  &nbs= p;   >>>>      >>>&= gt;
    >> Teco      >>>> ______________= _________________________________      >>>= ;>
    >> paws mailing list         = >>>> paws@ietf.org <mailto:paws@ietf.org>   = ; 
    >> >>>> https://www.ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>      &= gt;>>>      >>>   = ;    >>>
    >> _______________________________________________   &= nbsp;       >>> paws mailing
    >> list      >>> paws@ietf.org <mailt= o:paws@ietf.org>        &nbs= p; >>>
    >> https://www= .ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>      &= gt;>   
    >> >>_______________________________________________  = ;       >>paws mailing
    >> list      >>paws@ietf.org <mailto:paw= s@ietf.org>       
    >> >>htt= ps://www.ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>      &= gt;    
    >> >_______________________________________________  &nb= sp;       >paws mailing list
    >>           >paws@ietf.org <mailto:paws@ietf.org>      =   
    >> >https:/= /www.ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>
    >>
    >>           ______= _________________________________________     &nbs= p;     paws mailing
    >

    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org= /mailman/listinfo/paws

     --_000_CC60E9CF22976basavarajpatilnokiacom_-- From brian.rosen@neustar.biz Mon Aug 27 07:30:48 2012 Return-Path: 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 ; 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 ; 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 ; 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" To: "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: References: In-Reply-To: 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" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 14:30:48 -0000 --_000_A224436CAA234E3883873047ACA1D087neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You are correct, there is no consensus on discovery. However, this is the argument I am strongly against - we choose JSON, and t= hen 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 Lo= ST. Brian On Aug 27, 2012, at 10:14 AM, basavaraj.patil@nokia.com wrote: Hi Don, If the DB discovery follows the approach recommended in : draft-probasco-p= aws-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 > Date: Monday, August 27, 2012 8:15 AM To: Basavaraj Patil > Cc: "Peter.McCann@huawei.com" >, "Brian.Rosen@neustar.biz" >, Gabor Bajko >, "paws@ietf.org" > Subject: RE: [paws] XML schema versus JSON, vCard & iCal Raj, If LoST requires XML and PAWS requires JSON, wouldn=92t that mean the maste= r 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 Cc: Peter.McCann@huawei.com; Brian.Rosen@ne= ustar.biz; Gabor.Bajko@nokia.com; 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 th= e message format? Sent from my Verizon Wireless 4G LTE DROID RAZR 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" > 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 wrote: >> >> +1 to Brian's view on using JSON only. >> >> From: "", "Brian.Rosen@neustar.biz" >> > >> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko >> > Cc: "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 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 va= lid >> 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 t= hat >> 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 on= ly >> 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] On Behalf >> Of ext Rosen, Brian >> Sent: Friday, August 24, 2012 10:43 AM >> To: Benjamin A. Rolfe >> Cc: 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" >> > wrote: >> >> >> >> >> There are two ways to achieve interoperability when you have an op= tion. >> 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 optional= ly >> 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 choi= ce >> of what to implement doesn't work for me (or Richard). >> >> Brian >> >> On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe > >> wrote: >> >> >> Apparently I was unclear. I certainly an capable of being wrong a= s 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 t= he >> 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 JS= ON >> 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] On Behalf >> Of Basavaraj.Patil@nokia.com >> Sent: Thursday, August 23, 2012 5:44 PM >> To: Brian.Rosen@neustar.biz; d.jos= lyn@spectrumbridge.com >> Cc: 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: "", "Brian.Rosen@neustar.biz" >> > Date: Thur= sday, August 23, 2012 2:43 PM To: >> Don Joslyn > Cc: "paws@ietf.org" >> > Subject: Re: [paws] XML sche= ma 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 interoperabil= ity. >> >> 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 mus= t >> 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 o= nly >> does one: there are no protocol police. >> >> Brian >> >> >> >> >> On Aug 23, 2012, at 3:11 PM, Don Joslyn > >> wrote: >> >> >> >> >> Hi Ben, That was my original suggestion, and I still think it mak= es >> the most sense. Thanks for supporting the proposal. Don >> >> From: 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 >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >> >> Someone suggested that PAWS define both, and let the vendors decid= e >> 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 ] On >> Behalf Of Gabor.Bajko@nokia.com >> Sent: Tuesday, August 21, 2012 12:42 AM >> To: 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 oth= er >> encoding. To prevent endless discussions on this topic I'd suggest w= e >> 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 ] On >> Behalf Of ext Das, Subir >> Sent: Monday, August 20, 2012 2:50 PM >> To: Don Joslyn; Vincent Chen; Weixinpeng >> Cc: paws@ietf.org ; M= anikkoth 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 langua= ges/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] >> On Behalf Of Don Joslyn >> Sent: Monday, August 20, 2012 4:54 PM >> To: Vincent Chen; Weixinpeng >> Cc: paws@ietf.org ; M= anikkoth 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 ] On >> Behalf Of Vincent Chen >> Sent: Monday, August 20, 2012 2:56 PM >> To: Weixinpeng >> Cc: paws@ietf.org ; M= anikkoth 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, supportin= g >> 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 (n= ested lists and >> maps) * Simple-to-use libraries exist for all majo= r >> languages/platforms * Don't need a tool chain to work wi= th 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 suppor= t >>XML? >> >> >> >> [DJ - We currently support half a dozen TVDB radio vendors (embedd= ed >> 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 >> > 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 ] On >> Behalf Of Rosen, Brian >> >> Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; >> gabor.bajko@nokia.com ; >> vchen@google.com ; pe= ter@spectrumbridge.com >> >> >> Cc: 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 >> >> From: Manikkoth Sajeev = > >> Reply-To: Manikkoth Sajeev >> > >> Date: Thu, 16 Aug 2012 22:37:38 -0400 >> To: "Gabor.Bajko@nokia.com " >> >, "Rosen, Brian" >> >, >> "vchen@google.com " <= vchen@google.com >> >, "peter@spectrum= bridge.com >> " >> > >> Cc: "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 Email: >> mksaji@ieee.org >> http://www.linkedin.com/in/mksajeev >> >> >> >> From: "Gabor.Bajko@nokia.com " >> > To: >> Brian.Rosen@neustar.biz ; >> vchen@google.com ; pe= ter@spectrumbridge.com >> Cc: paws@ietf.org >> Sent: Friday, 17 August 2012, 4:55 S= ubject: Re: >> [paws] XML schema versus JSON, vCard & iCal >> >> >> We have not heard any objections for using JSON encoding instead o= f >> XML. Therefore, let's go for JSON, and close this thread. >> >> - Gabor >> >> -----Original Message----- >> From: 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 ' >> 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 >> >> >> >> -----Original Message----- From: Vincent Chen >> [mailto:vchen@google.com ] Sent: Monday, >> August 13, 2012 06:04 PM Eastern Standard Time To: Peter Stanf= orth >> Cc: Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org >> Subject: Re: [paws] XML schema versus J= SON, >> 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/ ) 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 >> > 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" >> >> > wrote: >> >> >Our experience in the IETF over many years is that economizin= g >> message >size and compromising utility and security in search = of >> efficiency of >implementation on small devices is a poor tra= de 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 load= ed on a >> small device is reasonable. > >Brian (as individual) = > >> > > > -----Original Message----- >From: Peter >> Stanforth [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 >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" > 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) t= o be >> realizable in an implementation with limited resources, >>>suc= h 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-byte= s >> still). >> >>In use cases and requirements document, th= ere 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 >>> Be= n >>> >> >>> >>>> 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 >> >>>> >> >>>> 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 >> >>>> >>>> >> Teco >>>> _______________________________________________ >>>> >> paws mailing list >>>> paws@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/paws >> >>>> >>> >>= > >> _______________________________________________ >>> paws maili= ng >> list >>> paws@ietf.org = >>> >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >>_______________________________________________ >>paws mailing >> list >>paws@ietf.org >> >>https://www.ietf.org/mailman/listinfo/paws >> > >> >_______________________________________________ >paws mailing = list >> >paws@ietf.org >> >https://www.ietf.org/mailman/listinfo/paws >> >> >> _______________________________________________ paws= mailing > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_A224436CAA234E3883873047ACA1D087neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <as individual>=
    You are correct, there is no consensus on discovery.

    However, this is the argument I am strongly against - we choose JSO= N, 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 poss= ible to do a JSON encoding of LoST.  

    Brian

    On Aug 27, 2012, at 10:14 AM, basavaraj.patil@nokia.com wrote:


    Hi Don,

    If the DB discovery follows the approach recommended in  : <= span class=3D"Apple-style-span" style=3D"font-family: monospace; font-size:= 13px; line-height: 15px; white-space: pre; -webkit-border-horizontal-spaci= ng: 2px; -webkit-border-vertical-spacing: 2px; ">draft-probasco-paws-discov= ery, then you could simply use JSON for the encoding and thereby harmoniz= e the encoding approach for discovery and the query (PAWS) protocol. <= /div>

    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> Date: Monday, August 27, 2012 8:15 = AM
    To: Basavaraj Patil <basavaraj.patil@nokia.com>
    Cc: "Peter.McCann@huawei.com" <Peter.McCann@huawei.com>, "Brian.Rosen@neustar.biz" <Brian.Rosen@neustar.biz>, Gabor Bajko <gabor.bajko@nokia= .com>, "paws@ietf.org" <paws@ietf.org>
    Subject: RE: [paws] XML schema vers= us JSON, vCard & iCal

    Raj,=
    &nb= sp;
    If LoST re= quires XML and PAWS requires JSON, wouldn=92t that mean the master device w= ould need to support both XML and JSON?
     
    Don
     
    From: Don Joslyn
    Sent: Saturday, August 25, 2012 8:41 AM
    To: Basavaraj.Patil@nok= ia.com
    Cc: Peter.McCann@huawei.c= om; Brian.Rosen@neustar.biz; Gabor= .Bajko@nokia.com; paws@ietf.org
    Subject: Re: [paws] XML schema versus JSON, vCard & iCal
     
    If we decide to use LoST for discovery does i= t require the use of XML in the message format?
     
    Sent from my= Verizon Wireless 4G LTE DROID RAZR



    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> wrote:

    >I think you are mis-representing Brian's point of view.  I share h= is
    >concern about re-inventing encodings for LoST/xCard.
    >
    >-Pete
    >
    >
    >Basavaraj.Patil@nokia.com<= /a> wrote:
    >>
    >> +1 to Brian's view on using JSON only.
    >>
    >> From: "<ext Rosen>", "    Brian.Rosen@neustar.biz"
    >> <Brian.Rosen@neustar= .biz>
    >> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko
    >> <gabor.bajko@nokia.com= > Cc: "paws@ietf.org" <paws@ietf.org> Subject: Re:
    >> [paws] XML schema versus JSON, vCard & iCal
    >>
    >>
    >> The problem we face with JSON only is the LoST/xCard/... issue.&nb= sp; As
    >> long as there is no objection to creating JSON encodings of existi= ng
    >> standards in order to use JSON, and no one uses the fact that thes= e
    >> encodings don't exist as a reason to roll our own equivalents, I a= m
    >> okay with JSON only.
    >>
    >> Brian
    >>
    >> On Aug 24, 2012, at 3:08 PM, 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 st= ill
    >> talk, but not use that feature. That is basically option B) from >> Brain's list.
    >>
    >>       I'd like to suggest that we re= cognize that option A) and B) are valid
    >> options, while option C) is invalid, and we should stop debating i= t.
    >>       I'd also like to add the obvio= us 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 g= ood 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 p= ick
    >> one of the two specified. As Robert mentioned in his email, this h= as
    >> 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<= br> >>encodings.
    >>
    >>       Is there anyone who has a tech= nical 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 again= st
    >> picking JSON. One said that JSON requires native Java, which is wr= ong,
    >> the other objection gave no real reason. So I am wondering if ther= e is
    >> really any valid technical reason against using JSON only?
    >>
    >>       -     = ;     Gabor
    >>
    >>
    >>       From: 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
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Okay:
    >>
    >>       So, I implement a database, an= d I implement XML
    >>       You implement a device, and yo= u implement JSON
    >>
    >>       You query my database (let's n= ot 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&g= t; wrote:
    >>
    >>
    >>
    >>
    >>       There are two ways to achieve = interoperability when you have an option.
    >>       There are many existence proof= s of the third way that I mentioned
    >> below.        802.11 + WiFi pro= vide many options and a means for devices to
    >> share information about what options each supports, without requir= ing
    >> 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 im= plement one specific choice ("MUST
    >> implement") and both can optionally implement the other choice.&nb= sp; Only
    >> if both ends implement the other choice would that be available. >>
    >>       So, in this case we could do o= ne of the following:
    >>       A) Databases implement both XM= L 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, Rich= ard was suggesting B.
    >>
    >>       I don't care, but choice C) Bo= th 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>
    >> 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 impl= ementer figure
    >> out which is best for their particular device requirements and tra= de-
    >> offs.  This is *preferable* from my perspective.
    >>
    >>       If you provide more than one f= orm in the database, devices using the
    >> database need some means for figuring out which are available. It<= br> >> can't use it if it doesn't no about it. This is an observations, n= ot
    >> 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 de= vices can
    >> discover what options the database supports.  If you have suc= h a
    >> mechanism and all devices use it (a  bootstrap protocol), eve= rything
    >> else could be options.  This requires additional functions in= both
    >> database and device implementations.
    >>       If on the other hand the devic= e 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 datab= ase
    >> 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 th= e 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.<= br> >>
    >>       IMHO XML MUST anything else de= fined 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] On Behalf
    >> Of Basavaraj.Patil@no= kia.com
    >>       Sent: Thursday, August 23, 201= 2 5:44 PM
    >>       To: Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com<= /a>
    >>       Cc:     paws@ietf.org
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>
    >>       I agree with Brian.
    >>       There needs to be a default ma= ndatory 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"
    >> <Brian.Rosen@neustar= .biz>     Date: Thursday, August 23, 2012 2:43 P= M  To:
    >> Don Joslyn <d.jo= slyn@spectrumbridge.com>      Cc: "paws@ietf.org"
    >> <paws@ietf.org> &n= bsp;     Subject: Re: [paws] XML schema versus JSON, vC= ard &
    >>iCal
    >>
    >>       One of my favorite IETF expres= sions is "There are no protocol
    >> police".  We apply that in lots of ways, but one of them is t= hat if
    >> you don't implement what the document says, you may not get
    >> interoperability with other implementations.  On the other ha= nd, the
    >> whole point of a protocol document like ours is that two independe= nt
    >> 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 en= ds, then you don't get interoperability.
    >>
    >>       By your argument, we should st= op working, and the product managers
    >> will figure it out using proprietary protocols.  The market w= ill decide.
    >>
    >>       So, I feel strongly that if on= e end is "either", the other end must
    >> be "both".  It's also acceptable to say both ends implement o= ne choice
    >> and the other is optional at both ends.  Here, I think it's s= erver
    >> 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, D= on Joslyn <d.joslyn@spect= rumbridge.com>
    >> wrote:
    >>
    >>
    >>
    >>
    >>       Hi Ben,  That was my orig= inal suggestion, and I still think it makes
    >> the most sense.       Thanks for sup= porting the proposal.      Don
    >>
    >>       From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf
    >> Of Benjamin A. Rolfe
    >>       Sent: Thursday, August 23, 201= 2 3:05 PM
    >>       To: paws@ietf.org
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Someone suggested that PAWS de= fine 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@i= etf.org> ] On
    >> Behalf Of Gabor.Bajko@nok= ia.com <mailto:Gabor.Bajko@= nokia.com>
    >>       Sent: Tuesday, August 21, 2012= 12:42 AM
    >>       To: paws@ietf.org <mailto:paws@i= etf.org>
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Now I can't see anymore any wi= llingness to agree on one or the other
    >> encoding.     To prevent endless discussions o= n 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@i= etf.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@i= etf.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:
    >>
    >>
    >>           &= nbsp;   *       Simple-to-use libra= ries exist for all major languages/platforms
    >>           &= nbsp;   *       Don't need a tool c= hain 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:[mail= to: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@i= etf.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@i= etf.org> ] On
    >> Behalf Of Vincent Chen
    >>       Sent: Monday, August 20, 2012 = 2:56 PM
    >>       To: Weixinpeng
    >>       Cc: paws@ietf.org <mailto:paws@i= etf.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 complexit= y 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 mod= el.
    >>
    >>       [DJ - I proposed that the data= bases support both XML and JSON,
    >> devices only need to support one to talk to the database. Our curr= ent
    >> 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 us= e 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 t= hat
    >> developers (client-side) prefer it for its simplicity:
    >>
    >>           &= nbsp;   *       Representation clos= ely matches most data models (nested lists and
    >> maps)          &= nbsp;      *       S= imple-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 gai= ns of JSON also matter to the
    >> scalability of serving systems.
    >>
    >>
    >>       [DJ - I can't argue against th= ese listed pros for JSON, especially
    >> when you're dealing with a lot of data (like Twitter, FourSquare,<= br> >> Facebook and Google does). But I'm assuming that PAWS messages wil= l
    >> not be exchanged nearly as often as the applications mentioned abo= ve.
    >> But again, I know JSON is more efficient, can't argue with that.]<= br> >>
    >>       *     = ;  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 hal= f 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 datab= ase
    >> is not that much or exchanged that often.]
    >>
    >>       On Fri, Aug 17, 2012 at 6:06 P= M, Weixinpeng <weixinpeng@hu= awei.com
    >> <mailto:weixinpeng= @huawei.com> > wrote:       Conside= ring of the design of
    >> database discovery protocol, the LoST protocol may be used and LoS= T 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@i= etf.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<= /a>> ;
    >>     vchen@google.com <mailto:vchen@google.com> ; peter@spectrumbridge.com >> <mailto:peter@spect= rumbridge.com>
    >>
    >>       Cc: paws@ietf.org <mailto:paws@i= etf.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 s= ee
    >> the choice of json mean we then decide to roll our own versus usin= g
    >> existing standards based on the idea there is no json representati= on
    >> of an existing standard.  So, if choosing json means folks fe= el free
    >> to ignore existing xml based standards such as xCard and LoST, the= n I
    >> would not want to use json.
    >>
    >>       I would prefer to not have "bo= th", 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<= br> >> implement either.
    >>
    >>       There are json validators, so = I don't think that is a big deal.
    >>
    >>       My experience in protocol desi= gn on the Internet is that decisions
    >> made solely or even largely because of compactness advantages rare= ly
    >> are good choices.  If you like json because it is smaller, th= en I
    >> believe you need a much better reason.  Binary doesn't work f= or me, at
    >> all.  I have been involved in big binary vs text wars in prot= ocol
    >> design.  Text wins, binary loses, in my opinion.
    >>
    >>       Brian <as individual> >>
    >>       From: Manikkoth Sajeev <mksaji@yahoo.com <mailto:mksaji@yahoo.com> >
    >>       Reply-To: Manikkoth Sajeev <= ;mksaji@yahoo.com
    >> <mailto:mksaji@yahoo.co= m> >
    >>       Date: Thu, 16 Aug 2012 22:37:3= 8 -0400
    >>       To: "Gabor.Bajko@nokia.com <mailto:Gabor.Bajko@nokia.com> "
    >> <Gabor.Bajko@nokia.com= <mailto:Gabor.Bajko@nokia.= com> >, "Rosen, Brian"
    >> <brian.rosen@neustar= .biz <mailto:brian.rosen@= neustar.biz> >,
    >> "vchen@google.com <mailto:vchen@google.com> " <vchen@google.com
    >> <mailto:vchen@google.co= m> >, "peter@spectrum= bridge.com
    >> <mailto:peter@spect= rumbridge.com> " <= peter@spectrumbridge.com
    >> <mailto:peter@s= pectrumbridge.com> >
    >>       Cc: "paws@ietf.org <mailto:paws@= ietf.org> " <paws@ietf.org >> <mailto:paws@ietf.org&= gt; >
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Hi,
    >>
    >>       Can it not be both JSON and XM= L supported? I would vote for that.
    >> Future implementations may prefer XML as it is generic, omni prese= nt,
    >> easy to understand and validate. For compactness may be a  bi= nary xml
    >> optioncan also work. JSON I think will necessitate implementation = to
    >> be native Java and may not be as friendly with other implementatio= n
    >> languages.
    >>
    >>       Best Regards,
    >>
    >>       Sajeev Manikkoth  &n= bsp;      Mobile: +918792292002 <tel:%2B918792292002>     = Email:
    >> mksaji@ieee.org <mailto:mksaji@ieee.org>
    >>       http://www.linkedin.com/in/mksajeev
    >> <http://www.lin= kedin.com/in/mksajeev>
    >>
    >>
    >>       From: "Gabor.Bajko@nokia.com <mailto:Gabor.Bajko@nokia.com> "
    >> <Gabor.Bajko@nokia.com= <mailto:Gabor.Bajko@nokia.= com> >       To:
    >> Brian.Rosen@neustar.biz= <mailto:Brian.Rosen@neus= tar.biz> ;
    >> vchen@google.com <mailto:vchen@google.com> ; peter@spectrumbridge.com >> <mailto:peter@spect= rumbridge.com>     Cc: paws@ietf.org
    >> <mailto:paws@ietf.org>&= nbsp;       Sent: Friday, 17 August 2012, 4:5= 5       Subject: Re:
    >> [paws] XML schema versus JSON, vCard & iCal
    >>
    >>
    >>       We have not heard any objectio= ns 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@i= etf.org> ] On
    >> Behalf Of ext Rosen, Brian
    >>       Sent: Monday, August 13, 2012 = 3:14 PM
    >>       To: 'Vincent Chen'; 'Peter Sta= nforth'
    >>       Cc: '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 r= ather than a time in seconds since
    >> epoch.  It's very easy to parse, and its simpler to use and d= ebug.
    >> Don't care a whole lot about that
    >>
    >>       Brian <as individual> >>
    >>
    >>
    >>       -----Original Message-----&nbs= p;      From:     Vincent Chen=
    >> [mailto:vchen@google.com &= lt;mailto:vchen@google.com> ]&nb= sp; Sent:    Monday,
    >> August 13, 2012 06:04 PM Eastern Standard Time   &n= bsp;    To:    Peter Stanforth
    >>       Cc:    Rosen, B= rian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
    >> <mailto:paws@ietf.org>&= nbsp;       Subject:    Re: [p= aws] XML schema versus JSON,
    >> vCard & iCal
    >>
    >>       XML vs JSON
    >>
    >>       Between XML and JSON, JSON mes= sages are more compact and easier to
    >> process (parsing, synthesis). As clarification, JSON does not requ= ire
    >> JavaScript or a Browser. It is a text-based representation of data=
    >> that is language independent, yet well-matched to all major langua= ges.
    >> 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 specification= s, 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, assumin= g
    >> devices already have native libraries that provide time in this fo= rmat.
    >> Is that a valid assumption? Of course, this is less human-readable= ....
    >>
    >>
    >>       On Mon, Aug 13, 2012 at 6:49 A= M, Peter Stanforth
    >> <peter@spectrumbrid= ge.com <mailto:peter@spe= ctrumbridge.com> > wrote:
    >>
    >>
    >>           Whenev= er 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        &nb= sp;  on that one.
    >>
    >>           On Mon= Aug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"
    >>
    >>           <Brian.Rosen@neustar.biz <mailto:Brian.Rosen@neustar.biz= > > wrote:
    >>
    >>           >Ou= r 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.        &nb= sp;  >         >Assuming= a json library can be loaded on a
    >> small device is reasonable.       &g= t;         >Brian (as individual= )            >&nb= sp;   
    >>   >       > &nb= sp;       > -----Original Message-----&nbs= p;     >From:  Peter
    >> Stanforth [mailto:pete= r@spectrumbridge.com
    >> <mailto:peter@spect= rumbridge.com> ]       >Sent: = Saturday, August 11,
    >> 2012 07:13 AM Eastern Standard Time     &= nbsp; >To:    Teco Boot; Benjamin
    >> A.Rolfe          = ; >Cc:    paws@ietf.org<= /a> <mailto:paws@ietf.org> =      >Subject:
    >>      Re: [paws] XML schema versus JSON, v= Card & iCal      >    &= nbsp;    >Not
    >> all masters run over the core network.    &nbs= p;       >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.      =       >      &nbs= p;  >On SatAug/11/12 Sat Aug 11,
    >> 5:30 AM, "Teco Boot" <teco@inf- net.n= l <mailto:teco@inf-net.nl>= > wrote:
    >>           >&n= bsp;        >>   &n= bsp;    >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. = Rolfe
    >> het volgende      >>geschreven:&nbs= p;            >&g= t;        >>> Compactness of me= ssages
    >> is important, but it is also important (to me   &nb= sp;         >>>at least) t= o 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 I= P 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       &nb= sp;     >>>talk about memory size in Kilo-byte= s
    >> still).          = ; >>        >>In use cases a= nd requirements document, there are
    >> no requirements for       >>pr= otocol performance. I guess OS/IP/TCP/TLS
    >> code size supersedes needs      &nbs= p; >>for JSON or XML.        >&= gt;        >>Same
    >> for timing: TCP/TLS connection setup will take more than the PAWS&= nbsp;   
    >> >>message exchange, I think. This may be of importance when = using
    >> >>satcom
    >>           >&g= t;links.          >>&nbs= p;       >>Because PAWS runs between ma= ster and
    >> database, over core network,      >>= ;performance is not our primary
    >> concern. But as always, it is good to keep    =     >>an eye on efficiency.
    >>           >&g= t;        >>Teco   =          >>   =      >>> Thanks     &= nbsp;  >>> Ben        = ;   >>>  
    >> >>>       >>>> = We had a discussion on XML vs. JSON. I prefer the one
    >> >>> with
    >> most      >>>>compact message= s.             = >>>>      >>>> On vCard an= d JSON:
    >> what is the status of "A JavaScript Object Notation  &nb= sp;    >>>>(JSON)
    >> Representation for vCard"?      &nbs= p; >>>>
    >> http://tools.ietf.org/html/draft-bhat-vcarddav-json-00
    >> <http://tools.ietf.org/html/draft-bhat-vcarddav-json-00> &n= bsp;        >>>> 
    >> >>>> On valid times: can we use same format as certifi= cates? They have       
    >>    >>>>similar simple requirements: val= id notBefore&  notAfter.      
    >> >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
    >> <http://tools.ietf.org/html/rfc3280#section-4.1.2.5>  &nbs= p;   >>>>      >>>&= gt;
    >> Teco      >>>> ______________= _________________________________      >>>= ;>
    >> paws mailing list         = >>>> paws@ietf.org <mailto:paws@ietf.org>   = ; 
    >> >>>> https://www.ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>      &= gt;>>>      >>>   = ;    >>>
    >> _______________________________________________   &= nbsp;       >>> paws mailing
    >> list      >>> paws@ietf.org <mailt= o:paws@ietf.org>        &nbs= p; >>>
    >> https://www= .ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>      &= gt;>   
    >> >>_______________________________________________  = ;       >>paws mailing
    >> list      >>paws@ietf.org <mailto:paw= s@ietf.org>       
    >> >>htt= ps://www.ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>      &= gt;    
    >> >_______________________________________________  &nb= sp;       >paws mailing list
    >>           >paws@ietf.org <mailto:paws@ietf.org>      =   
    >> >https:/= /www.ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>
    >>
    >>           ______= _________________________________________     &nbs= p;     paws mailing
    >

    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org= /mailman/listinfo/paws

    = --_000_A224436CAA234E3883873047ACA1D087neustarbiz_-- From Basavaraj.Patil@nokia.com Mon Aug 27 07:35:24 2012 Return-Path: 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 2190021F8495 for ; Mon, 27 Aug 2012 07:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.002 X-Spam-Level: X-Spam-Status: No, score=-106.002 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 m+RblKcEWuYs for ; Mon, 27 Aug 2012 07:35:20 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5603721F865D for ; Mon, 27 Aug 2012 07:35:15 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7REYbJC030901; Mon, 27 Aug 2012 17:35:10 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Aug 2012 17:34:51 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0309.003; Mon, 27 Aug 2012 16:34:50 +0200 From: To: Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac15n6Iej7JadvAx8UahySbuq9n2zQAAU/5DAJUxXAAABrI7AAAWoncAABh1noAAifZJAAAEHtqAAAHwqAAADmEvAACA/ioAAAG/7gAAADZkgAABIt+A///NtAD//meaQIADLqOAgAADSYCAAAgwgIAAAR6AgAAX74CAAAsjAP//rRSAgABqLoD//8WEgAAr8oFc//zTEsD/+glIAP/zuoGA/+fHgAA= Date: Mon, 27 Aug 2012 14:34:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [72.64.105.77] Content-Type: multipart/alternative; boundary="_000_CC60EF7522985basavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Aug 2012 14:34:52.0043 (UTC) FILETIME=[1E67DDB0:01CD8461] X-Nokia-AV: Clean Cc: paws@ietf.org, 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 14:35:24 -0000 --_000_CC60EF7522985basavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Agree. -Raj From: "", "Brian.Rosen@neustar.biz" > Date: Monday, August 27, 2012 9:30 AM To: Basavaraj Patil > Cc: "d.joslyn@spectrumbridge.com" >, "Peter.McCann= @huawei.com" >, Gabor Bajko >, "paws@ietf.org" > Subject: Re: [paws] XML schema versus JSON, vCard & iCal You are correct, there is no consensus on discovery. However, this is the argument I am strongly against - we choose JSON, and t= hen 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 Lo= ST. Brian On Aug 27, 2012, at 10:14 AM, basavaraj.patil@nokia.com wrote: Hi Don, If the DB discovery follows the approach recommended in : draft-probasco-p= aws-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 > Date: Monday, August 27, 2012 8:15 AM To: Basavaraj Patil > Cc: "Peter.McCann@huawei.com" >, "Brian.Rosen@neustar.biz" >, Gabor Bajko >, "paws@ietf.org" > Subject: RE: [paws] XML schema versus JSON, vCard & iCal Raj, If LoST requires XML and PAWS requires JSON, wouldn=92t that mean the maste= r 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 Cc: Peter.McCann@huawei.com; Brian.Rosen@ne= ustar.biz; Gabor.Bajko@nokia.com; 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 th= e message format? Sent from my Verizon Wireless 4G LTE DROID RAZR 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" > 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 wrote: >> >> +1 to Brian's view on using JSON only. >> >> From: "", "Brian.Rosen@neustar.biz" >> > >> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko >> > Cc: "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 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 va= lid >> 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 t= hat >> 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 on= ly >> 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] On Behalf >> Of ext Rosen, Brian >> Sent: Friday, August 24, 2012 10:43 AM >> To: Benjamin A. Rolfe >> Cc: 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" >> > wrote: >> >> >> >> >> There are two ways to achieve interoperability when you have an op= tion. >> 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 optional= ly >> 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 choi= ce >> of what to implement doesn't work for me (or Richard). >> >> Brian >> >> On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe > >> wrote: >> >> >> Apparently I was unclear. I certainly an capable of being wrong a= s 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 t= he >> 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 JS= ON >> 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] On Behalf >> Of Basavaraj.Patil@nokia.com >> Sent: Thursday, August 23, 2012 5:44 PM >> To: Brian.Rosen@neustar.biz; d.jos= lyn@spectrumbridge.com >> Cc: 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: "", "Brian.Rosen@neustar.biz" >> > Date: Thur= sday, August 23, 2012 2:43 PM To: >> Don Joslyn > Cc: "paws@ietf.org" >> > Subject: Re: [paws] XML sche= ma 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 interoperabil= ity. >> >> 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 mus= t >> 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 o= nly >> does one: there are no protocol police. >> >> Brian >> >> >> >> >> On Aug 23, 2012, at 3:11 PM, Don Joslyn > >> wrote: >> >> >> >> >> Hi Ben, That was my original suggestion, and I still think it mak= es >> the most sense. Thanks for supporting the proposal. Don >> >> From: 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 >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >> >> Someone suggested that PAWS define both, and let the vendors decid= e >> 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 ] On >> Behalf Of Gabor.Bajko@nokia.com >> Sent: Tuesday, August 21, 2012 12:42 AM >> To: 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 oth= er >> encoding. To prevent endless discussions on this topic I'd suggest w= e >> 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 ] On >> Behalf Of ext Das, Subir >> Sent: Monday, August 20, 2012 2:50 PM >> To: Don Joslyn; Vincent Chen; Weixinpeng >> Cc: paws@ietf.org ; M= anikkoth 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 langua= ges/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] >> On Behalf Of Don Joslyn >> Sent: Monday, August 20, 2012 4:54 PM >> To: Vincent Chen; Weixinpeng >> Cc: paws@ietf.org ; M= anikkoth 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 ] On >> Behalf Of Vincent Chen >> Sent: Monday, August 20, 2012 2:56 PM >> To: Weixinpeng >> Cc: paws@ietf.org ; M= anikkoth 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, supportin= g >> 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 (n= ested lists and >> maps) * Simple-to-use libraries exist for all majo= r >> languages/platforms * Don't need a tool chain to work wi= th 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 suppor= t >>XML? >> >> >> >> [DJ - We currently support half a dozen TVDB radio vendors (embedd= ed >> 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 >> > 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 ] On >> Behalf Of Rosen, Brian >> >> Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; >> gabor.bajko@nokia.com ; >> vchen@google.com ; pe= ter@spectrumbridge.com >> >> >> Cc: 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 >> >> From: Manikkoth Sajeev = > >> Reply-To: Manikkoth Sajeev >> > >> Date: Thu, 16 Aug 2012 22:37:38 -0400 >> To: "Gabor.Bajko@nokia.com " >> >, "Rosen, Brian" >> >, >> "vchen@google.com " <= vchen@google.com >> >, "peter@spectrum= bridge.com >> " >> > >> Cc: "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 Email: >> mksaji@ieee.org >> http://www.linkedin.com/in/mksajeev >> >> >> >> From: "Gabor.Bajko@nokia.com " >> > To: >> Brian.Rosen@neustar.biz ; >> vchen@google.com ; pe= ter@spectrumbridge.com >> Cc: paws@ietf.org >> Sent: Friday, 17 August 2012, 4:55 S= ubject: Re: >> [paws] XML schema versus JSON, vCard & iCal >> >> >> We have not heard any objections for using JSON encoding instead o= f >> XML. Therefore, let's go for JSON, and close this thread. >> >> - Gabor >> >> -----Original Message----- >> From: 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 ' >> 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 >> >> >> >> -----Original Message----- From: Vincent Chen >> [mailto:vchen@google.com ] Sent: Monday, >> August 13, 2012 06:04 PM Eastern Standard Time To: Peter Stanf= orth >> Cc: Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org >> Subject: Re: [paws] XML schema versus J= SON, >> 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/ ) 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 >> > 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" >> >> > wrote: >> >> >Our experience in the IETF over many years is that economizin= g >> message >size and compromising utility and security in search = of >> efficiency of >implementation on small devices is a poor tra= de 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 load= ed on a >> small device is reasonable. > >Brian (as individual) = > >> > > > -----Original Message----- >From: Peter >> Stanforth [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 >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" > 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) t= o be >> realizable in an implementation with limited resources, >>>suc= h 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-byte= s >> still). >> >>In use cases and requirements document, th= ere 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 >>> Be= n >>> >> >>> >>>> 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 >> >>>> >> >>>> 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 >> >>>> >>>> >> Teco >>>> _______________________________________________ >>>> >> paws mailing list >>>> paws@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/paws >> >>>> >>> >>= > >> _______________________________________________ >>> paws maili= ng >> list >>> paws@ietf.org = >>> >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >>_______________________________________________ >>paws mailing >> list >>paws@ietf.org >> >>https://www.ietf.org/mailman/listinfo/paws >> > >> >_______________________________________________ >paws mailing = list >> >paws@ietf.org >> >https://www.ietf.org/mailman/listinfo/paws >> >> >> _______________________________________________ paws= mailing > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CC60EF7522985basavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2A444925BA23334397E1DB8810133663@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable

    Agree.

    -Raj

    From: "<ext Rosen>"= , "Brian.Rosen@neustar.biz<= /a>" <Brian.Rosen@neusta= r.biz>
    Date: Monday, August 27, 2012 9:30 = AM
    To: Basavaraj Patil <basavaraj.patil@nokia.com>
    Cc: "d.joslyn@spectrumbridge.com" <d.joslyn@spectrumbridge.com>, &q= uot;Peter.McCann@huawei.com&= quot; <Peter.McCann@huawei.com= >, Gabor Bajko <gabor.bajko@= nokia.com>, "paws@ietf.org= " <paws@ietf.org>
    Subject: Re: [paws] XML schema vers= us 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 X= ML.  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 wrote:


    Hi Don,

    If the DB discovery follows the approach recommended in  : <= span class=3D"Apple-style-span" style=3D"font-family: monospace; font-size:= 13px; line-height: 15px; white-space: pre; -webkit-border-horizontal-spaci= ng: 2px; -webkit-border-vertical-spacing: 2px; ">draft-probasco-paws-discov= ery, then you could simply use JSON for the encoding and thereby harmoniz= e the encoding approach for discovery and the query (PAWS) protocol. <= /div>

    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> Date: Monday, August 27, 2012 8:15 = AM
    To: Basavaraj Patil <basavaraj.patil@nokia.com>
    Cc: "Peter.McCann@huawei.com" <Peter.McCann@huawei.com>, "Brian.Rosen@neustar.biz" <Brian.Rosen@neustar.biz>, Gabor Bajko <gabor.bajko@nokia= .com>, "paws@ietf.org"= ; <paws@ietf.org>
    Subject: RE: [paws] XML schema vers= us JSON, vCard & iCal

    Raj,
     
    If LoST requires XML and PAWS re= quires JSON, wouldn=92t that mean the master device would need to support b= oth XML and JSON?
     
    Don
     
    From: Don Joslyn
    Sent: Saturday, August 25, 2012 8:41 AM
    To: Basavaraj.Patil@nok= ia.com
    Cc: Peter.McCann@huawei.c= om; Brian.Rosen@neustar.biz; Gabor= .Bajko@nokia.com; paws@ietf.org
    Subject: Re: [paws] XML schema versus JSON, vCard & iCal
     
    If we decide to use LoST for discovery does it req= uire the use of XML in the message format?
     
    Sent from my Veri= zon Wireless 4G LTE DROID RAZR



    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> wrote:

    >I think you are mis-representing Brian's point of view.  I share h= is
    >concern about re-inventing encodings for LoST/xCard.
    >
    >-Pete
    >
    >
    >Basavaraj.Patil@nokia.com<= /a> wrote:
    >>
    >> +1 to Brian's view on using JSON only.
    >>
    >> From: "<ext Rosen>", "    Brian.Rosen@neustar.biz"
    >> <Brian.Rosen@neustar= .biz>
    >> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko
    >> <gabor.bajko@nokia.com= > Cc: "paws@ietf.org"= <paws@ietf.org> Subject: Re: >> [paws] XML schema versus JSON, vCard & iCal
    >>
    >>
    >> The problem we face with JSON only is the LoST/xCard/... issue.&nb= sp; As
    >> long as there is no objection to creating JSON encodings of existi= ng
    >> standards in order to use JSON, and no one uses the fact that thes= e
    >> encodings don't exist as a reason to roll our own equivalents, I a= m
    >> okay with JSON only.
    >>
    >> Brian
    >>
    >> On Aug 24, 2012, at 3:08 PM, 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 st= ill
    >> talk, but not use that feature. That is basically option B) from >> Brain's list.
    >>
    >>       I'd like to suggest that we re= cognize that option A) and B) are valid
    >> options, while option C) is invalid, and we should stop debating i= t.
    >>       I'd also like to add the obvio= us 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 g= ood 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 p= ick
    >> one of the two specified. As Robert mentioned in his email, this h= as
    >> 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<= br> >>encodings.
    >>
    >>       Is there anyone who has a tech= nical 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 again= st
    >> picking JSON. One said that JSON requires native Java, which is wr= ong,
    >> the other objection gave no real reason. So I am wondering if ther= e is
    >> really any valid technical reason against using JSON only?
    >>
    >>       -     = ;     Gabor
    >>
    >>
    >>       From: 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
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Okay:
    >>
    >>       So, I implement a database, an= d I implement XML
    >>       You implement a device, and yo= u implement JSON
    >>
    >>       You query my database (let's n= ot 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, &= quot;Benjamin A. Rolfe"
    >> <ben@blindcreek.com&g= t; wrote:
    >>
    >>
    >>
    >>
    >>       There are two ways to achieve = interoperability when you have an option.
    >>       There are many existence proof= s 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 requir= ing
    >> 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 im= plement one specific choice ("MUST
    >> implement") and both can optionally implement the other choic= e.  Only
    >> if both ends implement the other choice would that be available. >>
    >>       So, in this case we could do o= ne of the following:
    >>       A) Databases implement both XM= L 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, Rich= ard was suggesting B.
    >>
    >>       I don't care, but choice C) Bo= th 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>
    >> 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 impl= ementer figure
    >> out which is best for their particular device requirements and tra= de-
    >> offs.  This is *preferable* from my perspective.
    >>
    >>       If you provide more than one f= orm in the database, devices using the
    >> database need some means for figuring out which are available. It<= br> >> can't use it if it doesn't no about it. This is an observations, n= ot
    >> 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 de= vices can
    >> discover what options the database supports.  If you have suc= h a
    >> mechanism and all devices use it (a  bootstrap protocol), eve= rything
    >> else could be options.  This requires additional functions in= both
    >> database and device implementations.
    >>       If on the other hand the devic= e 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 datab= ase
    >> 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 th= e 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 act= ually 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.<= br> >>
    >>       IMHO XML MUST anything else de= fined 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] On Behalf
    >> Of Basavaraj.Patil@no= kia.com
    >>       Sent: Thursday, August 23, 201= 2 5:44 PM
    >>       To: Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com<= /a>
    >>       Cc:     paws@ietf.org
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>
    >>       I agree with Brian.
    >>       There needs to be a default ma= ndatory to implement option in order to
    >> achieve interoperability.
    >>       And this applies to the device= and database side of the protocol.
    >>
    >>       -Raj
    >>
    >>       From: "<ext Rosen>&= quot;, "Brian.Rosen@neustar= .biz"
    >> <Brian.Rosen@neustar= .biz>     Date: Thursday, August 23, 2012 2:43 P= M  To:
    >> Don Joslyn <d.jo= slyn@spectrumbridge.com>      Cc: "paws@ietf.org"
    >> <paws@ietf.org> &n= bsp;     Subject: Re: [paws] XML schema versus JSON, vC= ard &
    >>iCal
    >>
    >>       One of my favorite IETF expres= sions 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 ha= nd, the
    >> whole point of a protocol document like ours is that two independe= nt
    >> 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 st= op working, and the product managers
    >> will figure it out using proprietary protocols.  The market w= ill decide.
    >>
    >>       So, I feel strongly that if on= e end is "either", the other end must
    >> be "both".  It's also acceptable to say both ends i= mplement one choice
    >> and the other is optional at both ends.  Here, I think it's s= erver
    >> 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, D= on Joslyn <d.joslyn@spect= rumbridge.com>
    >> wrote:
    >>
    >>
    >>
    >>
    >>       Hi Ben,  That was my orig= inal suggestion, and I still think it makes
    >> the most sense.       Thanks for sup= porting the proposal.      Don
    >>
    >>       From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf
    >> Of Benjamin A. Rolfe
    >>       Sent: Thursday, August 23, 201= 2 3:05 PM
    >>       To: paws@ietf.org
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Someone suggested that PAWS de= fine 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@i= etf.org> ] On
    >> Behalf Of Gabor.Bajko@nok= ia.com <mailto:Gabor.Bajko@= nokia.com>
    >>       Sent: Tuesday, August 21, 2012= 12:42 AM
    >>       To: paws@ietf.org <mailto:paws@i= etf.org>
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Now I can't see anymore any wi= llingness to agree on one or the other
    >> encoding.     To prevent endless discussions o= n 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@i= etf.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@i= etf.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:
    >>
    >>
    >>           &= nbsp;   *       Simple-to-use libra= ries exist for all major languages/platforms
    >>           &= nbsp;   *       Don't need a tool c= hain 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:[mail= to: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@i= etf.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@i= etf.org> ] On
    >> Behalf Of Vincent Chen
    >>       Sent: Monday, August 20, 2012 = 2:56 PM
    >>       To: Weixinpeng
    >>       Cc: paws@ietf.org <mailto:paws@i= etf.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 data= bases support both XML and JSON,
    >> devices only need to support one to talk to the database. Our curr= ent
    >> 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 us= e 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 t= hat
    >> developers (client-side) prefer it for its simplicity:
    >>
    >>           &= nbsp;   *       Representation clos= ely matches most data models (nested lists and
    >> maps)          &= nbsp;      *       S= imple-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 gai= ns of JSON also matter to the
    >> scalability of serving systems.
    >>
    >>
    >>       [DJ - I can't argue against th= ese listed pros for JSON, especially
    >> when you're dealing with a lot of data (like Twitter, FourSquare,<= br> >> Facebook and Google does). But I'm assuming that PAWS messages wil= l
    >> not be exchanged nearly as often as the applications mentioned abo= ve.
    >> But again, I know JSON is more efficient, can't argue with that.]<= br> >>
    >>       *     = ;  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 hal= f 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 datab= ase
    >> is not that much or exchanged that often.]
    >>
    >>       On Fri, Aug 17, 2012 at 6:06 P= M, Weixinpeng <weixinpeng@hu= awei.com
    >> <mailto:weixinpeng= @huawei.com> > wrote:       Conside= ring of the design of
    >> database discovery protocol, the LoST protocol may be used and LoS= T 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@i= etf.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<= /a>> ;
    >>     vchen@google.com <mailto:vchen@google.com> ; peter@spectrumbridge.com >> <mailto:peter@spect= rumbridge.com>
    >>
    >>       Cc: paws@ietf.org <mailto:paws@i= etf.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 s= ee
    >> the choice of json mean we then decide to roll our own versus usin= g
    >> existing standards based on the idea there is no json representati= on
    >> of an existing standard.  So, if choosing json means folks fe= el free
    >> to ignore existing xml based standards such as xCard and LoST, the= n I
    >> would not want to use json.
    >>
    >>       I would prefer to not have &qu= ot;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<= br> >> implement either.
    >>
    >>       There are json validators, so = I don't think that is a big deal.
    >>
    >>       My experience in protocol desi= gn on the Internet is that decisions
    >> made solely or even largely because of compactness advantages rare= ly
    >> are good choices.  If you like json because it is smaller, th= en I
    >> believe you need a much better reason.  Binary doesn't work f= or me, at
    >> all.  I have been involved in big binary vs text wars in prot= ocol
    >> design.  Text wins, binary loses, in my opinion.
    >>
    >>       Brian <as individual> >>
    >>       From: Manikkoth Sajeev <mksaji@yahoo.com <mailto:mksaji@yahoo.com> >
    >>       Reply-To: Manikkoth Sajeev <= ;mksaji@yahoo.com
    >> <mailto:mksaji@yahoo.co= m> >
    >>       Date: Thu, 16 Aug 2012 22:37:3= 8 -0400
    >>       To: "Gabor.Bajko@nokia.com <mailto:Gabor.Bajko@nokia.com> "
    >> <Gabor.Bajko@nokia.com= <mailto:Gabor.Bajko@nokia.= com> >, "Rosen, Brian"
    >> <brian.rosen@neustar= .biz <mailto:brian.rosen@= neustar.biz> >,
    >> "vchen@google.com <= ;mailto:vchen@google.com> "= <vchen@google.com
    >> <mailto:vchen@google.co= m> >, "peter@spe= ctrumbridge.com
    >> <mailto:peter@spect= rumbridge.com> " <peter@spectrumbridge.com
    >> <mailto:peter@s= pectrumbridge.com> >
    >>       Cc: "paws@ietf.org <mailto:= paws@ietf.org> " <paws@i= etf.org
    >> <mailto:paws@ietf.org&= gt; >
    >>       Subject: Re: [paws] XML schema= versus JSON, vCard & iCal
    >>
    >>       Hi,
    >>
    >>       Can it not be both JSON and XM= L supported? I would vote for that.
    >> Future implementations may prefer XML as it is generic, omni prese= nt,
    >> easy to understand and validate. For compactness may be a  bi= nary xml
    >> optioncan also work. JSON I think will necessitate implementation = to
    >> be native Java and may not be as friendly with other implementatio= n
    >> languages.
    >>
    >>       Best Regards,
    >>
    >>       Sajeev Manikkoth  &n= bsp;      Mobile: +918792292002 <tel:%2B918792292002>    &n= bsp; Email:
    >> mksaji@ieee.org <mailto:mksaji@ieee.org>
    >>       http://www.linkedin.com/in/mksajeev
    >> <http://www.lin= kedin.com/in/mksajeev>
    >>
    >>
    >>       From: "Gabor.Bajko@nokia.com <mailto:Gabor.Bajko@nokia.com> "
    >> <Gabor.Bajko@nokia.com= <mailto:Gabor.Bajko@nokia.= com> >       To:
    >> Brian.Rosen@neustar.biz= <mailto:Brian.Rosen@neus= tar.biz> ;
    >> vchen@google.com <mailto:vchen@google.com> ; peter@spectrumbridge.com >> <mailto:peter@spect= rumbridge.com>     Cc: paws@ietf.org
    >> <mailto:paws@ietf.org>&= nbsp;       Sent: Friday, 17 August 2012, 4:5= 5       Subject: Re:
    >> [paws] XML schema versus JSON, vCard & iCal
    >>
    >>
    >>       We have not heard any objectio= ns 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@i= etf.org> ] On
    >> Behalf Of ext Rosen, Brian
    >>       Sent: Monday, August 13, 2012 = 3:14 PM
    >>       To: 'Vincent Chen'; 'Peter Sta= nforth'
    >>       Cc: '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 r= ather than a time in seconds since
    >> epoch.  It's very easy to parse, and its simpler to use and d= ebug.
    >> Don't care a whole lot about that
    >>
    >>       Brian <as individual> >>
    >>
    >>
    >>       -----Original Message-----&nbs= p;      From:     Vincent Chen=
    >> [mailto:vchen@google.com &= lt;mailto:vchen@google.com> ]&nb= sp; Sent:    Monday,
    >> August 13, 2012 06:04 PM Eastern Standard Time   &n= bsp;    To:    Peter Stanforth
    >>       Cc:    Rosen, B= rian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org
    >> <mailto:paws@ietf.org>&= nbsp;       Subject:    Re: [p= aws] XML schema versus JSON,
    >> vCard & iCal
    >>
    >>       XML vs JSON
    >>
    >>       Between XML and JSON, JSON mes= sages are more compact and easier to
    >> process (parsing, synthesis). As clarification, JSON does not requ= ire
    >> JavaScript or a Browser. It is a text-based representation of data=
    >> that is language independent, yet well-matched to all major langua= ges.
    >> 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 specification= s, 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, assumin= g
    >> devices already have native libraries that provide time in this fo= rmat.
    >> Is that a valid assumption? Of course, this is less human-readable= ....
    >>
    >>
    >>       On Mon, Aug 13, 2012 at 6:49 A= M, Peter Stanforth
    >> <peter@spectrumbrid= ge.com <mailto:peter@spe= ctrumbridge.com> > wrote:
    >>
    >>
    >>           Whenev= er 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        &nb= sp;  on that one.
    >>
    >>           On Mon= Aug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"
    >>
    >>           <Brian.Rosen@neustar.biz <mailto:Brian.Rosen@neustar.biz= > > wrote:
    >>
    >>           >Ou= r 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.        &nb= sp;  >         >Assuming= a json library can be loaded on a
    >> small device is reasonable.       &g= t;         >Brian (as individual= )            >&nb= sp;   
    >>   >       > &nb= sp;       > -----Original Message-----&nbs= p;     >From:  Peter
    >> Stanforth [mailto:pete= r@spectrumbridge.com
    >> <mailto:peter@spect= rumbridge.com> ]       >Sent: = Saturday, August 11,
    >> 2012 07:13 AM Eastern Standard Time     &= nbsp; >To:    Teco Boot; Benjamin
    >> A.Rolfe          = ; >Cc:    paws@ietf.org<= /a> <mailto:paws@ietf.org> =      >Subject:
    >>      Re: [paws] XML schema versus JSON, v= Card & iCal      >    &= nbsp;    >Not
    >> all masters run over the core network.    &nbs= p;       >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.      =       >      &nbs= p;  >On SatAug/11/12 Sat Aug 11,
    >> 5:30 AM, "Teco Boot" <teco@inf- net.nl <mailto:teco@inf-net.= nl> > wrote:
    >>           >&n= bsp;        >>   &n= bsp;    >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. = Rolfe
    >> het volgende      >>geschreven:&nbs= p;            >&g= t;        >>> Compactness of me= ssages
    >> is important, but it is also important (to me   &nb= sp;         >>>at least) t= o be
    >> realizable in an implementation with limited resources,  = ;         >>>such as
    >> embedded devices in what are now popularly called "M2M"&= nbsp;     
    >> >>>applications.  A lot of these devices could use I= P 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       &nb= sp;     >>>talk about memory size in Kilo-byte= s
    >> still).          = ; >>        >>In use cases a= nd requirements document, there are
    >> no requirements for       >>pr= otocol performance. I guess OS/IP/TCP/TLS
    >> code size supersedes needs      &nbs= p; >>for JSON or XML.        >&= gt;        >>Same
    >> for timing: TCP/TLS connection setup will take more than the PAWS&= nbsp;   
    >> >>message exchange, I think. This may be of importance when = using
    >> >>satcom
    >>           >&g= t;links.          >>&nbs= p;       >>Because PAWS runs between ma= ster and
    >> database, over core network,      >>= ;performance is not our primary
    >> concern. But as always, it is good to keep    =     >>an eye on efficiency.
    >>           >&g= t;        >>Teco   =          >>   =      >>> Thanks     &= nbsp;  >>> Ben        = ;   >>>  
    >> >>>       >>>> = We had a discussion on XML vs. JSON. I prefer the one
    >> >>> with
    >> most      >>>>compact message= s.             = >>>>      >>>> On vCard an= d JSON:
    >> what is the status of "A JavaScript Object Notation &nbs= p;     >>>>(JSON)
    >> Representation for vCard"?      = ;  >>>>
    >> http://tools.ietf.org/html/draft-bhat-vcarddav-json-00
    >> <http://tools.ietf.org/html/draft-bhat-vcarddav-json-00> &n= bsp;        >>>> 
    >> >>>> On valid times: can we use same format as certifi= cates? They have       
    >>    >>>>similar simple requirements: val= id notBefore&  notAfter.      
    >> >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
    >> <http://tools.ietf.org/html/rfc3280#section-4.1.2.5>  &nbs= p;   >>>>      >>>&= gt;
    >> Teco      >>>> ______________= _________________________________      >>>= ;>
    >> paws mailing list         = >>>> paws@ietf.org <mailto:paws@ietf.org>   = ; 
    >> >>>> https://www.ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>      &= gt;>>>      >>>   = ;    >>>
    >> _______________________________________________   &= nbsp;       >>> paws mailing
    >> list      >>> paws@ietf.org <mailt= o:paws@ietf.org>        &nbs= p; >>>
    >> https://www= .ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>      &= gt;>   
    >> >>_______________________________________________  = ;       >>paws mailing
    >> list      >>paws@ietf.org <mailto:paw= s@ietf.org>       
    >> >>htt= ps://www.ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>      &= gt;    
    >> >_______________________________________________  &nb= sp;       >paws mailing list
    >>           >paws@ietf.org <mailto:paws@ietf.org>      =   
    >> >https:/= /www.ietf.org/mailman/listinfo/paws
    >> <https:/= /www.ietf.org/mailman/listinfo/paws>
    >>
    >>           ______= _________________________________________     &nbs= p;     paws mailing
    >

    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org= /mailman/listinfo/paws

     --_000_CC60EF7522985basavarajpatilnokiacom_-- From d.joslyn@spectrumbridge.com Mon Aug 27 08:17:49 2012 Return-Path: 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 7653B21F845A for ; Mon, 27 Aug 2012 08:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] 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 bUyAE+u7golt for ; Mon, 27 Aug 2012 08:17:43 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id AF2F421F842F for ; Mon, 27 Aug 2012 08:17:42 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 27 Aug 2012 11:17:41 -0400 From: Don Joslyn To: "Rosen, Brian" , "basavaraj.patil@nokia.com" Date: Mon, 27 Aug 2012 11:17:40 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac2EYITIHTSDIDfBQGOLNBKA/lgn9QABUJCQ Message-ID: <8375F6DAEFB09F48815203F1FE23B797117AA6DAA0@shelby> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B797117AA6DAA0shelby_" MIME-Version: 1.0 Cc: "paws@ietf.org" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:17:49 -0000 --_000_8375F6DAEFB09F48815203F1FE23B797117AA6DAA0shelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So if you use JSON for LoST, are you really supporting the LoST standard as= it's currently written? Is there any chance that PAWS could use an existing LoST server? Does one e= xist? If one does not exist, then I'm assuming that someone would need to i= mplement a LoST server for use by PAWS devices, correct? Would it then make= sense to implement it with JSON, even though the standard as written uses = XML? Maybe somebody should take a look at the XML messages described in the LoST= protocol, to determine how easy it will or will not be to convert them to = JSON. Maybe we should just forget about using LoST, and go with the only discover= y proposal that has been formally submitted to PAWS? Don From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Monday, August 27, 2012 10:31 AM To: basavaraj.patil@nokia.com Cc: Don Joslyn; Peter.McCann@huawei.com; Gabor.Bajko@nokia.com; paws@ietf.o= rg Subject: Re: [paws] XML schema versus JSON, vCard & iCal You are correct, there is no consensus on discovery. However, this is the argument I am strongly against - we choose JSON, and t= hen 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 Lo= ST. Brian On Aug 27, 2012, at 10:14 AM, basavaraj.patil@nokia.com wrote: Hi Don, If the DB discovery follows the approach recommended in : draft-probasco-p= aws-discovery, then you could simply use JSON for the encoding and thereby harmonize the e= ncoding 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 > Date: Monday, August 27, 2012 8:15 AM To: Basavaraj Patil > Cc: "Peter.McCann@huawei.com" >, "Brian.Rosen@neustar.biz" >, Gabor Bajko >, "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 Cc: Peter.McCann@huawei.com; Brian.Rosen@ne= ustar.biz; Gabor.Bajko@nokia.com; 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 th= e message format? Sent from my Verizon Wireless 4G LTE DROID RAZR 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" > 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 wrote: >> >> +1 to Brian's view on using JSON only. >> >> From: "", "Brian.Rosen@neustar.biz" >> > >> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko >> > Cc: "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 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 va= lid >> 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 t= hat >> 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 on= ly >> 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] On Behalf >> Of ext Rosen, Brian >> Sent: Friday, August 24, 2012 10:43 AM >> To: Benjamin A. Rolfe >> Cc: 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" >> > wrote: >> >> >> >> >> There are two ways to achieve interoperability when you have an op= tion. >> 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 optional= ly >> 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 choi= ce >> of what to implement doesn't work for me (or Richard). >> >> Brian >> >> On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe > >> wrote: >> >> >> Apparently I was unclear. I certainly an capable of being wrong a= s 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 t= he >> 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 JS= ON >> 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] On Behalf >> Of Basavaraj.Patil@nokia.com >> Sent: Thursday, August 23, 2012 5:44 PM >> To: Brian.Rosen@neustar.biz; d.jos= lyn@spectrumbridge.com >> Cc: 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: "", "Brian.Rosen@neustar.biz" >> > Date: Thur= sday, August 23, 2012 2:43 PM To: >> Don Joslyn > Cc: "paws@ietf.org" >> > Subject: Re: [paws] XML sche= ma 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 interoperabil= ity. >> >> 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 mus= t >> 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 o= nly >> does one: there are no protocol police. >> >> Brian >> >> >> >> >> On Aug 23, 2012, at 3:11 PM, Don Joslyn > >> wrote: >> >> >> >> >> Hi Ben, That was my original suggestion, and I still think it mak= es >> the most sense. Thanks for supporting the proposal. Don >> >> From: 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 >> Subject: Re: [paws] XML schema versus JSON, vCard & iCal >> >> Someone suggested that PAWS define both, and let the vendors decid= e >> 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 ] On >> Behalf Of Gabor.Bajko@nokia.com >> Sent: Tuesday, August 21, 2012 12:42 AM >> To: 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 oth= er >> encoding. To prevent endless discussions on this topic I'd suggest w= e >> 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 ] On >> Behalf Of ext Das, Subir >> Sent: Monday, August 20, 2012 2:50 PM >> To: Don Joslyn; Vincent Chen; Weixinpeng >> Cc: paws@ietf.org ; M= anikkoth 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 langua= ges/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] >> On Behalf Of Don Joslyn >> Sent: Monday, August 20, 2012 4:54 PM >> To: Vincent Chen; Weixinpeng >> Cc: paws@ietf.org ; M= anikkoth 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 ] On >> Behalf Of Vincent Chen >> Sent: Monday, August 20, 2012 2:56 PM >> To: Weixinpeng >> Cc: paws@ietf.org ; M= anikkoth 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, supportin= g >> 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 (n= ested lists and >> maps) * Simple-to-use libraries exist for all majo= r >> languages/platforms * Don't need a tool chain to work wi= th 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 suppor= t >>XML? >> >> >> >> [DJ - We currently support half a dozen TVDB radio vendors (embedd= ed >> 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 >> > 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 ] On >> Behalf Of Rosen, Brian >> >> Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; >> gabor.bajko@nokia.com ; >> vchen@google.com ; pe= ter@spectrumbridge.com >> >> >> Cc: 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 >> >> From: Manikkoth Sajeev = > >> Reply-To: Manikkoth Sajeev >> > >> Date: Thu, 16 Aug 2012 22:37:38 -0400 >> To: "Gabor.Bajko@nokia.com " >> >, "Rosen, Brian" >> >, >> "vchen@google.com " <= vchen@google.com >> >, "peter@spectrum= bridge.com >> " >> > >> Cc: "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 Email: >> mksaji@ieee.org >> http://www.linkedin.com/in/mksajeev >> >> >> >> From: "Gabor.Bajko@nokia.com " >> > To: >> Brian.Rosen@neustar.biz ; >> vchen@google.com ; pe= ter@spectrumbridge.com >> Cc: paws@ietf.org >> Sent: Friday, 17 August 2012, 4:55 S= ubject: Re: >> [paws] XML schema versus JSON, vCard & iCal >> >> >> We have not heard any objections for using JSON encoding instead o= f >> XML. Therefore, let's go for JSON, and close this thread. >> >> - Gabor >> >> -----Original Message----- >> From: 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 ' >> 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 >> >> >> >> -----Original Message----- From: Vincent Chen >> [mailto:vchen@google.com ] Sent: Monday, >> August 13, 2012 06:04 PM Eastern Standard Time To: Peter Stanf= orth >> Cc: Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.org >> Subject: Re: [paws] XML schema versus J= SON, >> 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/ ) 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 >> > 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" >> >> > wrote: >> >> >Our experience in the IETF over many years is that economizin= g >> message >size and compromising utility and security in search = of >> efficiency of >implementation on small devices is a poor tra= de 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 load= ed on a >> small device is reasonable. > >Brian (as individual) = > >> > > > -----Original Message----- >From: Peter >> Stanforth [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 >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" > 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) t= o be >> realizable in an implementation with limited resources, >>>suc= h 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-byte= s >> still). >> >>In use cases and requirements document, th= ere 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 >>> Be= n >>> >> >>> >>>> 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 >> >>>> >> >>>> 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 >> >>>> >>>> >> Teco >>>> _______________________________________________ >>>> >> paws mailing list >>>> paws@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/paws >> >>>> >>> >>= > >> _______________________________________________ >>> paws maili= ng >> list >>> paws@ietf.org = >>> >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >>_______________________________________________ >>paws mailing >> list >>paws@ietf.org >> >>https://www.ietf.org/mailman/listinfo/paws >> > >> >_______________________________________________ >paws mailing = list >> >paws@ietf.org >> >https://www.ietf.org/mailman/listinfo/paws >> >> >> _______________________________________________ paws= mailing > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_8375F6DAEFB09F48815203F1FE23B797117AA6DAA0shelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

     

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

     

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

    =  

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

     

    Don

     

    =

    From: Rosen, Brian [mailto:Brian.Rosen@neustar.= biz]
    Sent: Monday, August 27, 2012 10:31 AM
    To: basava= raj.patil@nokia.com
    Cc: Don Joslyn; Peter.McCann@huawei.com; Gabo= r.Bajko@nokia.com; paws@ietf.org
    Subject: Re: [paws] XML schema v= ersus JSON, vCard & iCal

     

    <as individual>

    You are correct, there is no consensus= on discovery.

     

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

    <= o:p> 

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

     

    Brian

    <= o:p> 

    On Aug 27, 2012, at 10:1= 4 AM, basavaraj.patil@nokia.co= m 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 harmoniz= e the encoding approach for discovery and the query (PAWS) protocol. <= o:p>

     

    <= /div>

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

     

    -Raj

     

    From: ext Don Joslyn <d.joslyn@spectrumbridge.com>
    Date: Monday, August 27, 2012 8:15 AM
    To: Basavaraj Patil <basavaraj.patil@nokia.com>
    = Cc: "Peter.McCann@hu= awei.com" <Peter.McC= ann@huawei.com>, "Br= ian.Rosen@neustar.biz" <Brian.Rosen@neustar.biz>, Gabor Bajko <gabor.bajko@nokia.com>, "paws@ietf.org" <= paws@ietf.org>
    Subject: RE: [paws] XML schema versus JSON,= vCard & iCal

     =

    Raj,

     <= /o:p>

    If LoST requires XML and PA= WS requires JSON, wouldn’t that mean the master device would need to = support both XML and JSON?

     

    Don

     <= /span>

    From:<= /b> Don = Joslyn
    Sent: Saturday, August 25, 2012 8:41 AM
    To: Basavaraj.Patil@nokia.com
    = Cc: Peter.McCann@huawei.c= om; Brian.Rosen@neustar.biz<= /a>; Gabor.Bajko@nokia.com; paws@ietf.org
    Subject: Re: [pa= ws] XML schema versus JSON, vCard & iCal

     

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

     

    Sent from my Verizon Wireless= 4G LTE DROID RAZR



    Basavaraj.Patil@nokia.com wrote:


    Pete,

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

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

    -Raj

    On 8/24/12 4:11 PM, "= ext Peter McCann" <Peter= .McCann@huawei.com> wrote:

    >I think you are mis-representi= ng Brian's point of view.  I share his
    >concern about re-inventi= ng encodings for LoST/xCard.
    >
    >-Pete
    >
    >
    >Basavaraj.Patil@nokia.com wr= ote:
    >>
    >> +1 to Brian's view on using JSON only.
    >= ;>
    >> From: "<ext Rosen>", "Brian.Rosen@neustar.biz"
    >>= <Brian.Rosen@neustar.biz= >
    >> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko
    &= gt;> <gabor.bajko@nokia.com<= /a>> Cc: "paws@ietf.org" = <paws@ietf.org> Subject: Re:
    = >> [paws] XML schema versus JSON, vCard & iCal
    >>
    &g= t;>
    >> The problem we face with JSON only is the LoST/xCard/..= . issue.  As
    >> long as there is no objection to creating JSO= N 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.
    >&= gt;
    >> Brian
    >>
    >> On Aug 24, 2012, at 3:08 PM= , Gabor.Bajko@nokia.com wrote:=
    >>
    >>
    >>       = WiFi world builds on mandating the implementation (and
    >> certific= ation) of a base spec, and a set of optional features. If an
    >> op= tional feature is not supported by one of the peers, they can still
    >= > talk, but not use that feature. That is basically option B) from
    &g= t;> Brain's list.
    >>
    >>     =   I'd like to suggest that we recognize that option A) and B) are vali= d
    >> options, while option C) is invalid, and we should stop debat= ing it.
    >>       I'd also like to ad= d the obvious option D) to the list, which is that
    >> both the mas= ter devices and DBs support one and the same encoding ;)
    >>
    &g= t;>       Option A) seems to be like a goo= d compromise, and would cut
    >> discussions short, with the only ca= veat that if there is no strong
    >> technical argument for supporti= ng and specifying two different
    >> encodings, then the iesg may se= nd the document back to the wg to pick
    >> one of the two specified= . As Robert mentioned in his email, this has
    >> happened in the pa= st, so it is likely it would happen again. And
    >> frankly, I do no= t see a strong argument in favor of two different
    >>encodings.
    = >>
    >>       Is there anyone w= ho has a technical argument against supporting only
    >> one encodin= g, being that either xml or json?
    >>
    >>   = ;    Most people speak in favor of JSON, because it is compa= ct and more
    >> efficient. I went through this thread and I saw 2 o= bjections against
    >> picking JSON. One said that JSON requires nat= ive Java, which is wrong,
    >> the other objection gave no real reas= on. So I am wondering if there is
    >> really any valid technical re= ason against using JSON only?
    >>
    >>   &nb= sp;   -          Gab= or
    >>
    >>
    >>      = ; From: paws-bounces@ietf.org = [mailto:paws-bounces@ietf.org]= On Behalf
    >> Of ext Rosen, Brian
    >>   &nb= sp;   Sent: Friday, August 24, 2012 10:43 AM
    >> &nb= sp;     To: Benjamin A. Rolfe
    >>  &n= bsp;    Cc: paws@ietf.org
    >>       Subject: Re: [paws] XML = schema versus JSON, vCard & iCal
    >>
    >>  &n= bsp;    Okay:
    >>
    >>   &nbs= p;   So, I implement a database, and I implement XML
    >>&= nbsp;      You implement a device, and you impleme= nt JSON
    >>
    >>       You qu= ery my database (let's not get into how you do that query
    >> witho= ut deciding XML vs JSON) and discover I implement XML only
    >>
    = >>       What do you do?
    >> >>       Brian
    >>
    >&g= t;       On Aug 24, 2012, at 1:38 PM, "B= enjamin A. Rolfe"
    >> <    ben@blindcreek.com> wrote:
    >>
    >>
    >> <= br>>>
    >>       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
    &g= t;> share information about what options each supports, without requirin= g
    >> that any device implement every option.  It works.
    &g= t;>
    >>       That said, I think = (A) is the best choice, (B) is not as nice for me,
    >> and (C) is m= ore work than either of the other two.
    >>
    >>
    >>= ;
    >>
    >>       One is that= one end implements both choices and the other end
    >> implements o= ne or both.
    >>
    >>       Th= e other is that both ends implement one specific choice ("MUST
    >= > implement") and both can optionally implement the other choice.&n= bsp; Only
    >> if both ends implement the other choice would that be= available.
    >>
    >>       So= , in this case we could do one of the following:
    >>  &nb= sp;    A) Databases implement both XML and JSON, devices imp= lement either
    >>       B) Both Datab= ases and devices implement one (say XML) and optionally
    >> impleme= nt the other (say JSON)
    >>
    >>    &nb= sp;  You are advocating for A, Richard was suggesting B.
    >> <= br>>>       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
    >>
    >>    &= nbsp;  On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe <ben@blindcreek.com>
    >> wrote:>>
    >>
    >>       App= arently 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 ch= oose only one form to achieve
    >> interoperability.   If = you have two, let the device implementer figure
    >> out which is be= st for their particular device requirements and trade-
    >> offs.&nb= sp; This is *preferable* from my perspective.
    >>
    >> = ;      If you provide more than one form in the da= tabase, devices using the
    >> database need some means for figuring= out which are available. It
    >> can't use it if it doesn't no abou= t 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
    >> disc= over what options the database supports.  If you have such a
    >&g= t; mechanism and all devices use it (a  bootstrap protocol), everythin= g
    >> else could be options.  This requires additional functio= ns in both
    >> database and device implementations.
    >>&nbs= p;      If on the other hand the device can "= just know" that the database has
    >> two forms available, it w= on't need to dynamically figure it out.
    >> The device implementer = has options and simplicity, so I like it.
    >>
    >> &nb= sp;     Since I am focused on the TVWS devices that nee= d access to the
    >> database, and not a database implementer, shift= ing burden onto the
    >> database implementer (not me) to reduce the= burden on the device
    >> implementer (me) is preferred from my per= spective.  The database
    >> implementer may have another persp= ective.  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
    >>
    >>
    >>
    >> &= nbsp;     Brian is right .. sorry but the rest of you a= re wrong. J
    >>
    >>       Th= is is why you have MUST and SHOULD in RFC 2119.
    >>
    >>&nb= sp;      This BTW is a classic argument in IETF te= rms .. but the argument "let
    >> the market decide" only = holds so much validity.  You actually have to
    >> choose SOMET= HING to create a baseline of interoperability.
    >>
    >>&nbs= p;      A virtually identical argument  is no= w playing out in discussions of
    >> mandatory audio and codec imple= mentations for WEBRTC like things.
    >>
    >>  &nbs= p;    IMHO XML MUST anything else defined SHOULD, but MUST o= n XML and JSON
    >> could work as well. It just leads to a level of = complexity in
    >> implementations.
    >>
    >> &n= bsp;     End of argument you now can go back to your re= gularly schedule
    >> programming. J
    >>
    >>
    &g= t;>       From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf
    >> Of Basavaraj.Patil@nokia.com
    >= >       Sent: Thursday, August 23, 2012 5:= 44 PM
    >>       To: Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com
    >> = ;      Cc: paws@i= etf.org
    >>       Subject: Re: [p= aws] 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.
    &= gt;>       And this applies to the device = and database side of the protocol.
    >>
    >>  &nbs= p;    -Raj
    >>
    >>    &= nbsp;  From: "<ext Rosen>", "Brian.Rosen@neustar.biz"
    >> <Brian.Rosen@neustar.biz>&nb= sp;    Date: Thursday, August 23, 2012 2:43 PM  To:
    = >> Don Joslyn <d.jo= slyn@spectrumbridge.com>      Cc: "paws@ietf.org"
    >> <paws@ietf.org>    &n= bsp;  Subject: Re: [paws] XML schema versus JSON, vCard &
    >&= gt;iCal
    >>
    >>       One of= my favorite IETF expressions is "There are no protocol
    >> po= lice".  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 h= and, the
    >> whole point of a protocol document like ours is that t= wo independent
    >> implementations who both follow the document wil= l interwork.  If that
    >> wasn't true, why do you need a stand= ard?
    >>
    >>       If you sa= y "either" to both ends, then you don't get interoperability.
    = >>
    >>       By your argument,= we should stop working, and the product managers
    >> will figure i= t 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 choic= e
    >> and the other is optional at both ends.  Here, I think i= t's server
    >> does both and client does either.
    >>
    &g= t;>       It's always possible to build an= implementation of a server that only
    >> does one: there are no pr= otocol police.
    >>
    >>      = Brian <as individual>
    >>
    >>
    >>
    >= >
    >>       On Aug 23, 2012, at 3= :11 PM, Don Joslyn <d.jos= lyn@spectrumbridge.com>
    >> wrote:
    >>
    >> =
    >>
    >>
    >>       = Hi Ben,  That was my original suggestion, and I still think it makes>> the most sense.       Thanks for s= upporting the proposal.      Don
    >>
    &= gt;>       From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf
    >> Of Benjami= n A. Rolfe
    >>       Sent: Thursday, = August 23, 2012 3:05 PM
    >>       To:= paws@ietf.org
    >>  =      Subject: Re: [paws] XML schema versus JSON, vCard = & iCal
    >>
    >>       Som= eone 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.
    >> Marke= ts will probably drive DB vendors to do both. Device vendors will
    >&g= t; do what fits the market segment they're after. Why over-constrain (or>> argue when natural selection will take care of it for us?).
    &g= t;>       B
    >>
    >>
    &= gt;>
    >>
    >>       Sound= s good to me.
    >>
    >>       = From: paws-bounces@ietf.org &l= t;mailto:paws-bounces@ietf.org= >
    >> [mailto:paws-boun= ces@ietf.org <mailto:paws-b= ounces@ietf.org> ] On
    >> Behalf Of Gabor.Bajko@nokia.com <mailto:Gabor.Bajko@nokia.com>
    >>  &n= bsp;    Sent: Tuesday, August 21, 2012 12:42 AM
    >>&= nbsp;      To: pa= ws@ietf.org <mailto:paws@ietf.org>
    >>       Subject: Re: [paws] = XML schema versus JSON, vCard & iCal
    >>
    >> &nbs= p;     Now I can't see anymore any willingness to agree= on one or the other
    >> encoding.     To preve= nt endless discussions on this topic I'd suggest we
    >> move forwar= d with supporting both in the DB and either one in the master
    >> d= evice.       Any objections?
    >>
    = >>       Gabor
    >>
    >>=
    >>       From:     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
    >&g= t;       Cc: paws@ietf.org <mailto:paws@ietf.or= g> ; 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 f= or JSON if we had to pick one.
    >>     &nb= sp; Also I will copy the following two important points:
    >>
    &g= t;>
    >>         &n= bsp;     *       Simple-t= o-use libraries exist for all major languages/platforms
    >> &n= bsp;            = ; *       Don't need a tool chain to work wit= h the data, as is typically
    >> needed for XML
    >>
    >= >
    >>
    >>
    >>     &n= bsp; From: paws-bounces@ietf.org <mailto:paws-bounces@ietf.or= g>
    >> [mailto:paws= -bounces@ietf.org] <mailto:[mailto:paws-bounces@ietf.org]>
    >> On Behalf Of Don= Joslyn
    >>       Sent: Monday, Augus= t 20, 2012 4:54 PM
    >>       To: Vinc= ent Chen; Weixinpeng
    >>       Cc: paws@ietf.org <mailto:paws@ietf.org> ; Manikkoth Sajeev
    >> = ;      Subject: Re: [paws] XML schema versus JSON,= vCard & iCal
    >>
    >>     &nb= sp; Please see my comments below...
    >>    &nbs= p;  Thanks,
    >>       Don
    >= ;>
    >>       From: paws-bounces@ietf.org <mailto:paws-bounces@ietf.org>
    >> [mailto:paws-bounces@ietf.org <= ;mailto:paws-bounces@ietf.org&= gt; ] On
    >> Behalf Of Vincent Chen
    >>   &n= bsp;   Sent: Monday, August 20, 2012 2:56 PM
    >> &nb= sp;     To: Weixinpeng
    >>   &nb= sp;   Cc: paws@ietf.org <= mailto:paws@ietf.org> ; Manikkoth S= ajeev
    >>       Subject: Re: [paws] X= ML schema versus JSON, vCard & iCal
    >>
    >>
    >&g= t;       *      = ; One of our goals is to strive to lower the cost and
    >> complexit= y for device manufacturers. This lowers the barrier for
    >> buildin= g 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 use= d XML. Maybe we
    >> need to better define "cost"?]
    >= ;>
    >>       *   &= nbsp;   To reduce complexity and cost for device makers, supporti= ng
    >> 1 encoding is better than both, as Brian points out. WiFi ac= cess
    >> points that "just work" anywhere in the world se= rves as a good model.
    >>
    >>     = ;  [DJ - I proposed that the databases support both XML and JSON,
    &= gt;> devices only need to support one to talk to the database. Our curre= nt
    >> database supports XML and JSON, but if I'm forced to pick on= ly one,
    >> then I will vote for XML because it's the one that we c= urrently use on
    >> all embedded devices.]
    >>
    >>=        *       = There's a trend for APIs on the web towards JSON (Twitter,
    >> Four= Square, Facebook, Google, etc.). One of the major reasons is that
    >&g= t; developers (client-side) prefer it for its simplicity:
    >>
    &= gt;>           &n= bsp;   *       Representation close= ly matches most data models (nested lists and
    >> maps)  =             &nb= sp;  *       Simple-to-use libraries exi= st for all major
    >> languages/platforms    &nb= sp;      *       Don= 't need a tool chain to work with the data,
    >> as is typically nee= ded for XML.
    >>
    >>       A= pparently, the efficiency gains of JSON also matter to the
    >> scal= ability of serving systems.
    >>
    >>
    >> &nbs= p;     [DJ - I can't argue against these listed pros fo= r JSON, especially
    >> when you're dealing with a lot of data (like= Twitter, FourSquare,
    >> Facebook and Google does). But I'm assumi= ng that PAWS messages will
    >> not be exchanged nearly as often as = the applications mentioned above.
    >> But again, I know JSON is mor= e efficient, can't argue with that.]
    >>
    >>  &n= bsp;    *       At the end of = the day, it's the data model that matters,
    >> rather than the enco= ding. 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 el= aborate on the types of devices that already support
    >>XML?
    >= ;>
    >>
    >>
    >>     &= nbsp; [DJ - We currently support half a dozen TVDB radio vendors (embedded<= br>>> devices) using XML, non using JSON. XML has not been a burden, = and the
    >> amount of data that needs to be exchanged between devic= e and database
    >> is not that much or exchanged that often.]
    &g= t;>
    >>       On Fri, Aug 17, 201= 2 at 6:06 PM, Weixinpeng <we= ixinpeng@huawei.com
    >> <mailto:weixinpeng@huawei.com> > wrote:   &nb= sp;   Considering of the design of
    >> database discovery= protocol, the LoST protocol may be used and LoST is
    >> based on X= ML, so I think XML may be preferred.
    >>
    >>  &n= bsp;    --Xinpeng Wei
    >>
    >>  &n= bsp;    From: paws-= bounces@ietf.org <mailto:pa= ws-bounces@ietf.org>
    >> [mailto:paws-bounces@ietf.org <mailto:paws-bounces@ietf.org> ] On
    >> Behalf Of R= osen, Brian
    >>
    >>       Se= nt: Friday, August 17, 2012 9:26 PM    To: Manikkoth Sajeev;=
    >> gabor.bajko@nokia.com= <mailto:gabor.bajko@nokia.= com> ;
    >> vchen@google.= com <mailto:vchen@google.com= > ; peter@spectrumbridge.com=
    >> <mailto:pet= er@spectrumbridge.com>
    >>
    >>   &nb= sp;   Cc: paws@ietf.org <= mailto:paws@ietf.org>
    >>&n= bsp;      Subject: Re: [paws] XML schema versus JS= ON, 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
    &= gt;> standards rather than defining new ones, and I would not want to se= e
    >> the choice of json mean we then decide to roll our own versus= using
    >> existing standards based on the idea there is no json re= presentation
    >> of an existing standard.  So, if choosing jso= n means folks feel free
    >> to ignore existing xml based standards = such as xCard and LoST, then I
    >> would not want to use json.
    &= gt;>
    >>       I would prefer to = not have "both", because of interoperability
    >> complica= tions.  If there is rough consensus for both, then I would
    >>= assert that all servers have to implement both and the client can
    >&= gt; 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 o= r even largely because of compactness advantages rarely
    >> are goo= d choices.  If you like json because it is smaller, then I
    >>= believe you need a much better reason.  Binary doesn't work for me, a= t
    >> 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@yaho= o.com <mailto:mksaji@yahoo.com> >
    >>       Reply-To: Manik= koth Sajeev <    mksaji@yahoo.com
    =     >> <mailto:mksaji@yahoo.co= m> >
    >>       Date: Thu, 1= 6 Aug 2012 22:37:38 -0400
    >>       T= o: "Gabor.Bajko@nokia.com= <mailto:Gabor.Bajko@nokia.com<= /a>> "
    >> <    Gab= or.Bajko@nokia.com <mailto:= Gabor.Bajko@nokia.com> >, "Rosen, Brian"
    >> &l= t;brian.rosen@neustar.biz &l= t;mailto:brian.rosen@neustar.biz= > >,
    >> "vchen@= google.com <mailto:vchen@google.= com> " <vchen@google.= com
    >> <mailto:vchen@go= ogle.com> >, "pe= ter@spectrumbridge.com
    >> <mailto:peter@spectrumbridge.com> " <peter@spectrumbridge.com
    >>= <mailto:peter@spectrumbridg= e.com> >
    >>       Cc: &quo= t;paws@ietf.org <mailto:paws@ietf.org> " <paws@ietf.org
    >> <mailto:paws@ietf.org> >
    >>   &nbs= p;   Subject: Re: [paws] XML schema versus JSON, vCard & iCal=
    >>
    >>       Hi,
    >&g= t;
    >>       Can it not be both JSON= and XML supported? I would vote for that.
    >> Future implementatio= ns may prefer XML as it is generic, omni present,
    >> easy to under= stand and validate. For compactness may be a  binary xml
    >> o= ptioncan 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         Mob= ile: +918792292002 <tel:%2B918792292002<= /a>>      Email:
    >>     mksaji@ieee.org <mailto:mksaji@ieee.org>
    >>     &n= bsp; http://www.linkedin.co= m/in/mksajeev
    >> <http://www.linkedin.com/in/mksajeev>
    >>
    >>=
    >>       From: "Gabor.Bajko@nokia.com <mailto:Gabor.Bajko@nokia.com> "
    >= > <Gabor.Bajko@nokia.com= <mailto:Gabor.Bajko@nokia.com<= /a>> >       To:
    >>     Brian.Rosen@neustar.biz <mailto:Brian.Rosen@neustar.biz> ;>> vchen@google.com <mailto:vchen@google.com> ; peter@spectrumbridge.com
    >&g= t; <mailto:peter@spectrumbri= dge.com>     Cc: paws@ietf.org
    >> <mailto= :paws@ietf.org>        Sent: Frid= ay, 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.  T= herefore, 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> ] On
    >> Be= half Of ext Rosen, Brian
    >>       Se= nt: Monday, August 13, 2012 3:14 PM
    >>    &nbs= p;  To: 'Vincent Chen'; 'Peter Stanforth'
    >>   = ;    Cc: 'paws@ietf.org     <mailto:paws@ietf.org> '
    &g= t;>       Subject: Re: [paws] XML schema v= ersus JSON, vCard & iCal
    >>
    >>   &nbs= p;   json is okay with me.
    >>    &nb= sp;  I'd prefer an ISO time stamp rather than a time in seconds since<= br>>> epoch.  It's very easy to parse, and its simpler to use an= d debug.
    >> Don't care a whole lot about that
    >>
    >= >       Brian <as individual>
    >= ;>
    >>
    >>
    >>     &= nbsp; -----Original Message-----       From:&= nbsp;    Vincent Chen
    >> [mailto:vchen@google.com <mailto:vchen@google.com> ]  Sent:    Monday,=
    >> August 13, 2012 06:04 PM Eastern Standard Time  &nbs= p;     To:    Peter Stanforth
    >>= ;       Cc:    Rosen, Brian; T= eco Boot; Benjamin A.Rolfe; paws@ietf.org<= /a>
    >> <    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, synt= hesis). As clarification, JSON does not require
    >> JavaScript or a= Browser. It is a text-based representation of data
    >> that is lan= guage independent, yet well-matched to all major languages.
    >> JSO= N-handling libraries exist for numerous languages (see of
    >>     http://json.org/ <http://json.org/> ) and seem to be reasonably light
    >> w= eight.
    >>
    >>       Timesta= mps
    >>
    >>       As for tim= estamp specifications, should we consider just using
    >> seconds si= nce the UNIX Epoch (1970-01-01T00:00:00Z)? This would
    >> eliminate= the need for datetime-string parsing on devices, assuming
    >> devi= ces 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>= ; > wrote:
    >>
    >>
    >>    =        Whenever we built mobile devices we ne= ver dealt with IETF, in our
    >> sensor     = ;       days even an IP stack was a challenge= ,so I would defer to
    >> the device guys    &nb= sp;      on that one.
    >>
    >>&nbs= p;          On MonAug/13/12 Mo= n Aug 13, 9:30 AM, "Rosen, Brian"
    >>
    >> &= nbsp;         <Brian.Rosen@neustar.biz <mailto:Brian.Rosen@neustar.biz> > wrote= :
    >>
    >>        &= nbsp;  >Our experience in the IETF over many years is that economiz= ing
    >> message        &nbs= p;  >size and compromising utility and security in search of
    >= ;> efficiency of         &n= bsp;   >implementation on small devices is a poor trade off.>>  I am not advocating      >bein= g wasteful of resources, but I don't
    >> think we should seriously&= nbsp;        >consider the overhead o= f XML or json to
    >> be significant.     &= nbsp;     >       = ;  >Assuming a json library can be loaded on a
    >> small de= vice is reasonable.       >  &nb= sp;      >Brian (as individual)  &nbs= p;         >   &n= bsp;
    >>   >       >=          > -----Original Message= -----      >From:  Peter
    >> Stanf= orth [mailto:peter@spectrumbrid= ge.com
    >> <mail= to:peter@spectrumbridge.com> ]       &= gt;Sent:  Saturday, August 11,
    >> 2012 07:13 AM Eastern Stand= ard Time       >To:    Teco= Boot; Benjamin
    >> A.Rolfe      &nbs= p;    >Cc:    paws@ietf.org <mailto:paws@iet= f.org>      >Subject:
    >> &= nbsp;    Re: [paws] XML schema versus JSON, vCard & iCal=       >      &nbs= p;  >Not
    >> all masters run over the core network. &n= bsp;          >Some of the = Use cases have
    >> a master talking to another OTA   = ;        >We should not assume that a= ll
    >> Masters are attached to utility power so we   = ;    >should be sympathetic
    >> to processing ene= rgy use also.          &n= bsp; >         >On SatAug/11/= 12 Sat Aug 11,
    >> 5:30 AM, "Teco Boot" <teco@inf- net.nl <ma= ilto:teco@inf-net.nl> > wrote:
    >>    = ;       >     &nb= sp;   >>        >>= Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe
    >> het volgende&= nbsp;     >>geschreven:    &n= bsp;        >>   &n= bsp;    >>> Compactness of messages
    >> is = important, but it is also important (to me     &nb= sp;       >>>at least) to be
    >= > realizable in an implementation with limited resources,  &nb= sp;        >>>such as
    >&g= t; embedded devices in what are now popularly called "M2M" &= nbsp;    
    >> >>>applications.  = A lot of these devices could use IP all the end to
    >> end, &n= bsp;    >>>but may have a very compact, simple stac= k and applications
    >> (i.e.  no     =     >>>browser).  Is JSON typically implemente= d when there is
    >> no browser?      = >>>Would it be hard to do in a resource constrained
    >> d= evice (i.e. where we         &= nbsp;   >>>talk about memory size in Kilo-bytes
    >&= gt; still).           >= ;>        >>In use cases and re= quirements document, there are
    >> no requirements for  &= nbsp;    >>protocol performance. I guess OS/IP/TCP/TLS=
    >> code size supersedes needs      =   >>for JSON or XML.        &= gt;>        >>Same
    >> = for timing: TCP/TLS connection setup will take more than the PAWS &nbs= p;  
    >> >>message exchange, I think. This may be = of importance when using
    >> >>satcom
    >>  =          >>links.  =         >>    =     >>Because PAWS runs between master and
    >>= database, over core network,      >>perform= ance is not our primary
    >> concern. But as always, it is good to k= eep        >>an eye on efficiency.=
    >>           &g= t;>        >>Teco  &n= bsp;         >>  &n= bsp;     >>> Thanks    &nb= sp;   >>> Ben       &= nbsp;   >>>  
    >> >>> &= nbsp;     >>>> We had a discussion on XML v= s. JSON. I prefer the one
    >> >>> with
    >> most&nb= sp;     >>>>compact messages.  &n= bsp;          >>>>=       >>>> On vCard and JSON:
    >&= gt; what is the status of "A JavaScript Object Notation  &nb= sp;    >>>>(JSON)
    >> Representation for= vCard"?        >>>>>> http://tools.ietf.org/html/draft-bhat-vcarddav-json-00
    >> &l= t;http:/= /tools.ietf.org/html/draft-bhat-vcarddav-json-00>   &= nbsp;      >>>> 
    >> >= ;>>> On valid times: can we use same format as certificates? They = have       
    >>  &nbs= p; >>>>similar simple requirements: valid notBefore&  = notAfter.      
    >> >>>>= http://tool= s.ietf.org/html/rfc3280#section-4.1.2.5
    >> <http://tools.ietf.org/html/= rfc3280#section-4.1.2.5>      >>>&= gt;      >>>>
    >> Teco &n= bsp;    >>>> ___________________________________= ____________      >>>>
    >> paw= s mailing list         >>>= > paws@ietf.org <mailto:paws@ietf.org>    
    = >> >>>> https://www.ietf.org/mailman/listinfo/paws
    >> <https://www.ietf.org/mailm= an/listinfo/paws>      >>>>&nbs= p;     >>>      = >>>
    >> _______________________________________________&n= bsp;          >>> paw= s mailing
    >> list      >>> paws@ietf.org <mailto:paws@ietf.org>      &nb= sp;   >>>
    >> https://www.ietf.org/mailman/listinfo/paws
    >= > <https://www= .ietf.org/mailman/listinfo/paws>      >&= gt;   
    >> >>________________________________= _______________         >>paw= s mailing
    >> list      >>paws@ietf.org <mailto:paws@ietf.org>        <= br>>> >>= https://www.ietf.org/mailman/listinfo/paws
    >> <https://www.ietf.org/mailman/lis= tinfo/paws>      >   &nbs= p;
    >> >_______________________________________________ &n= bsp;        >paws mailing list
    >= ;>           >paws@ietf.org <mailto:paws@ietf.org>      &nb= sp; 
    >> >https://www.ietf.org/mailman/listinfo/paws
    >> <https://www.ietf.org/mail= man/listinfo/paws>
    >>
    >>    &= nbsp;      _______________________________________= ________           paws m= ailing
    >

    _______________________________________________
    pa= ws mailing list
    paws@ietf.org
    https://www.ietf.org/m= ailman/listinfo/paws

     

    = --_000_8375F6DAEFB09F48815203F1FE23B797117AA6DAA0shelby_-- From brian.rosen@neustar.biz Mon Aug 27 08:40:23 2012 Return-Path: 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 E8EE521F8467 for ; Mon, 27 Aug 2012 08:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 h8nMh2IYCIig for ; Mon, 27 Aug 2012 08:40:23 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id D930B21F84B3 for ; Mon, 27 Aug 2012 08:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1346081784; x=1661438342; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=nh9c4FY7f6qshIlC7RXmmueQ5F3kzEfHgHaWc46dzC0=; b=qpJvgz4QM9LtIUR6HykutC0ewleEvn+RbYcpyhqsiwdRpdi2F29H1Q9rsZfHKA Iln0MCpOlQpq/qGIAy7MR0pA== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.10373244; Mon, 27 Aug 2012 11:36:23 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 27 Aug 2012 11:40:11 -0400 From: "Rosen, Brian" Date: Mon, 27 Aug 2012 11:40:11 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac2Eaj5zf9rowCEFQua6CT63h6yWhA== Message-ID: <5E786066-2218-4B80-A1BE-67F9AB4DDEC3@neustar.biz> References: <8375F6DAEFB09F48815203F1FE23B797117AA6DAA0@shelby> In-Reply-To: <8375F6DAEFB09F48815203F1FE23B797117AA6DAA0@shelby> 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: OBsx33Oz6b3e4f/A6U7GGQ== Content-Type: multipart/alternative; boundary="_000_5E78606622184B80A1BE67F9AB4DDEC3neustarbiz_" MIME-Version: 1.0 To: Don Joslyn Cc: "paws@ietf.org" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:40:24 -0000 --_000_5E78606622184B80A1BE67F9AB4DDEC3neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable So, you think you understand how to write location sensitive discovery for = a specific service? You think you thoroughly understand how it works, what the pitfalls are, wh= ere you need flexibility? Further, you think that every service that needs location sensitive discove= ry should invent its own mechanism and every jurisdiction (read country) sh= ould support who knows how many equivalent - but different, mechanisms? Or, maybe, you could allow that a group of very smart people spent a great = deal of time working out how location sensitive services should be discover= ed, and tried to come up with one mechanism that would work for a very wide= variety of services. I mean, why limit encoding to XML or JSON? Why don't we come up with our o= wn encoding? See in line for responses to the questions you asked On Aug 27, 2012, at 11:17 AM, Don Joslyn > wrote: So if you use JSON for LoST, are you really supporting the LoST standard as= it=92s currently written? Standards evolve. We can evolve LoST if it'd decided that it's useful and = doesn't screw up existing systems. Is there any chance that PAWS could use an existing LoST server? Sure Does one exist? Yes. It's still pretty early though. If one does not exist, then I=92m assuming that someone would need to imple= ment a LoST server for use by PAWS devices, correct? Maybe. In most places, I'd say, probably Would it then make sense to implement it with JSON, even though the standar= d as written uses XML? Sure, why not, assuming we have a good reason to use JSON for whitespace Maybe somebody should take a look at the XML messages described in the LoST= protocol, to determine how easy it will or will not be to convert them to = JSON. I'm not a JSON expert, but I doubt it would be hard. I'll ask an expert. Maybe we should just forget about using LoST, and go with the only discover= y proposal that has been formally submitted to PAWS? Maybe we should stop re-inventing something that has already been invented = and concentrate on things that need new work. Also, remember vCard/xCard - same arguments. --_000_5E78606622184B80A1BE67F9AB4DDEC3neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <as individual>
    So, you think you understand how to write= location sensitive discovery for a specific service?

    Yo= u think you thoroughly understand how it works, what the pitfalls are, wher= e you need flexibility?

    Further, you think that ev= ery service that needs location sensitive discovery should invent its own m= echanism and every jurisdiction (read country) should support who knows how= many equivalent - but different, mechanisms?

    Or, = maybe, you could allow that a group of very smart people spent a great deal= of time working out how location sensitive services should be discovered, = and tried to come up with one mechanism that would work for a very wide var= iety of services.

    I mean, why limit encoding to XM= L or JSON?  Why don't we come up with our own encoding?

    =
    See in line for responses to the questions you asked
    <= br>
    On Aug 27, 2012, at 11:17 AM, Don Joslyn <d.joslyn@spectrumbridge.com> wrote:
    So if you use JSON for Lo= ST, are you really supporting the LoST standard as it=92s currently written= ?
    Standards evolve.  We can evolv= e LoST if it'd decided that it's useful and doesn't screw up existing syste= ms.

    =
     
    = Is there any chance that PAWS could use an existing LoST server?
    Sure
    Does one exist?
    Yes.  It's still pretty early though. 

    <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rgb= (31, 73, 125); ">If one does not exist, then I=92m assuming that someone wo= uld need to implement a LoST server for use by PAWS devices, correct?
    Maybe.  In most places, I'd say, prob= ably

    Would it then make sense to implement it with JSO= N, even though the standard as written uses XML?
    Sure, why not, assuming we have a good reason to use JSON for wh= itespace

     
    Maybe somebody should take a look at the XML messages described in t= he LoST protocol, to determine how easy it will or will not be to convert t= hem to JSON.
    I'm not a JSON expert, bu= t I doubt it would be hard.  I'll ask an expert.

    <= div>
     
    Maybe we shoul= d just forget about using LoST, and go with the only discovery proposal tha= t has been formally submitted to PAWS?
    Maybe we should stop re-inventing something that has already been invented= and concentrate on things that need new work.

    Als= o, remember vCard/xCard - same arguments.  

    <= br>
    = --_000_5E78606622184B80A1BE67F9AB4DDEC3neustarbiz_-- From ben@blindcreek.com Mon Aug 27 08:49:59 2012 Return-Path: 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 F030A21F84D8 for ; Mon, 27 Aug 2012 08:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, MIME_HTML_ONLY=1.457] 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 MDtI3vcLraAh for ; Mon, 27 Aug 2012 08:49:57 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id 954E721F84CF for ; Mon, 27 Aug 2012 08:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=Ii/ABb68OPjCWt31hvbFp1qg+yVnDbGLeumrgSm5AdU=; b=Y4bIimKhC2KhLKeLjt2iWszHkpGP2GLXEGJVkXGa5ooC11WGJ9leji6FX9lTpeonNud7iVvn1fTO55k02/MkCCbmtEErGrMDlydjDmZFM91AkDviJhrvxhZtQogbVG+a; Received: from [64.74.213.174] (port=61912 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1T61ZX-0003Vb-Mb for paws@ietf.org; Mon, 27 Aug 2012 10:49:54 -0500 Message-ID: <503B972B.20109@blindcreek.com> Date: Mon, 27 Aug 2012 08:50:03 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: "paws@ietf.org" References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> <00c601cd820b$67b97170$372c5450$@us> <5037B28B.70501@blindcreek.com> <5D0B1E63-79FE-4BC6-A446-3470931D1043@neustar.biz> <5037BC2B.7010008@blindcreek.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724@008-AM1MPN1-006.mgdnok.nokia.com> <1345864438.6327.YahooMailNeo@web120306.mail.ne1.yahoo.com> In-Reply-To: Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:50:00 -0000 I have implemented minimalist XML parsers in "C" and run with very limited resources along with a very thin imitation of an HTTP/TCP/IP stack, very sharply focused on the specific messages of a particular application (i.e. do only what you need for the app and nothing more). In a device that is deeply embedded, has a very specific purpose, and is not expected to adapt to new purposes after deployment, won't implement all the functions needed to comply with the standard, but just enough to inetrop as needed for the specific purpose.  

    Many embedded developers find the LCD is still a tool chain for  C. I found a C-language implementation of JSON after a very a brief search.  If someone has experience with one of these it'd be great comfort for some, I'm sure.

    Note that the term "embedded" was widely varying meanings, from the sort of limited purpose, long life, no-touch devices I'm thinking about to really smart devices with real operating systems, memory, rechargeable batteries and other such luxuries.  "whitespace device" is a similarly diverse term, and currently we have PHY standards published or in development with over the air data rates from many mega-bits per second to a few hundred kilo-bits per second.  It's clearly a challenge!

    -Ben







    Sajeev,

    It's been a while since I've worked with embedded devices. I'm surprised that the same concern does not apply to XML. Do you not need libraries to work with XML?


    On Fri, Aug 24, 2012 at 8:13 PM, Manikkoth Sajeev <mksaji@yahoo.com> wrote:
    Hi,
     
    I would still support XML. JSON libraries are available for all languages. But interfacing and linking such libraries are problematic on embedded devices most of the time. And if an implementation vouch for multiple such non native language libraries then developers life is hell...
     
    Best Regards,
     
    Sajeev Manikkoth

    From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
    To: Brian.Rosen@neustar.biz; ben@blindcreek.com
    Cc: paws@ietf.org
    Sent: Saturday, 25 August 2012, 0:38

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

    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] On Behalf Of ext Rosen, Brian
    Sent: Friday, August 24, 2012 10:43 AM
    To: Benjamin A. Rolfe
    Cc: 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> 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> 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] On Behalf Of Basavaraj.Patil@nokia.com
    Sent: Thursday, August 23, 2012 5:44 PM
    To: Brian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com
    Cc: 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" <Brian.Rosen@neustar.biz>
    Date: Thursday, August 23, 2012 2:43 PM
    To: Don Joslyn <d.joslyn@spectrumbridge.com>
    Cc: "paws@ietf.org" <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> 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] On Behalf Of Benjamin A. Rolfe
    Sent: Thursday, August 23, 2012 3:05 PM
    To: 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] On Behalf Of Gabor.Bajko@nokia.com
    Sent: Tuesday, August 21, 2012 12:42 AM
    To: 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] On Behalf Of ext Das, Subir
    Sent: Monday, August 20, 2012 2:50 PM
    To: Don Joslyn; Vincent Chen; Weixinpeng
    Cc: 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] On Behalf Of Don Joslyn
    Sent: Monday, August 20, 2012 4:54 PM
    To: Vincent Chen; Weixinpeng
    Cc: 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] On Behalf Of Vincent Chen
    Sent: Monday, August 20, 2012 2:56 PM
    To: Weixinpeng
    Cc: 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> 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] On Behalf Of Rosen, Brian

    Sent: Friday, August 17, 2012 9:26 PM

    Cc: 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>
    Reply-To: Manikkoth Sajeev <mksaji@yahoo.com>
    Date: Thu, 16 Aug 2012 22:37:38 -0400
    To: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>, "Rosen, Brian" <brian.rosen@neustar.biz>, "vchen@google.com" <vchen@google.com>, "peter@spectrumbridge.com" <peter@spectrumbridge.com>
    Cc: "paws@ietf.org" <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,
     
    From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
    To: Brian.Rosen@neustar.biz; vchen@google.com; peter@spectrumbridge.com 
    Cc: 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] On Behalf Of ext Rosen, Brian
    Sent: Monday, August 13, 2012 3:14 PM
    To: 'Vincent Chen'; 'Peter Stanforth'
    Cc: '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]
    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
    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/) 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> 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> 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]
        >Sent:  Saturday, August 11, 2012 07:13 AM Eastern Standard Time
        >To:    Teco Boot; Benjamin A.Rolfe
        >Cc:    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> 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
        >>>>
        >>>> 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
        >>>>
        >>>> Teco
        >>>> _______________________________________________
        >>>> paws mailing list
        >>>> paws@ietf.org
        >>>> https://www.ietf.org/mailman/listinfo/paws
        >>>>
        >>>
        >>> _______________________________________________
        >>> paws mailing list
        >>> paws@ietf.org
        >>> https://www.ietf.org/mailman/listinfo/paws
        >>
        >>_______________________________________________
        >>paws mailing list
        >>paws@ietf.org
        >>https://www.ietf.org/mailman/listinfo/paws
        >
        >_______________________________________________
        >paws mailing list
        >paws@ietf.org
        >https://www.ietf.org/mailman/listinfo/paws
        
        _______________________________________________
        paws mailing list
        paws@ietf.org
        https://www.ietf.org/mailman/listinfo/paws
        




    -- 
    -vince

    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws
    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws


     
    -- 
    -vince
     
     
    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws
     
    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws
     
      
    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws
     
    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws
     
     
     

    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws



    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws




    --
    -vince

    From d.joslyn@spectrumbridge.com Mon Aug 27 10:21:28 2012 Return-Path: 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 A897E21F8582 for ; Mon, 27 Aug 2012 10:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 yIe8y+jxx1H8 for ; Mon, 27 Aug 2012 10:21:24 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id F34B121F856D for ; Mon, 27 Aug 2012 10:21:22 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 27 Aug 2012 13:21:21 -0400 From: Don Joslyn To: "Rosen, Brian" Date: Mon, 27 Aug 2012 13:21:21 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac2Eaj5zf9rowCEFQua6CT63h6yWhAABskwQ Message-ID: <8375F6DAEFB09F48815203F1FE23B797117AA6DAB3@shelby> References: <8375F6DAEFB09F48815203F1FE23B797117AA6DAA0@shelby> <5E786066-2218-4B80-A1BE-67F9AB4DDEC3@neustar.biz> In-Reply-To: <5E786066-2218-4B80-A1BE-67F9AB4DDEC3@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B797117AA6DAB3shelby_" MIME-Version: 1.0 Cc: "paws@ietf.org" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 17:21:28 -0000 --_000_8375F6DAEFB09F48815203F1FE23B797117AA6DAB3shelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, I think you're misunderstanding my reason for suggesting something other th= an LoST for discovery. Let me explain... 1. I support using an existing solution for discovery, such as LoST, as it = could save a great deal of time and effort. I have not seen any meaningful = discussions to help the paws group understand the pros/cons for LoST, or th= e understand the logistics of using it, so I'm trying to promote a useful e= xchange of information. 2. I do find it confusing that we're spending all this time/effort discussi= ng XML versus JSON (and potentially being forced to pick just one), but you= think it does not matter when it comes to LoST ("We can evolve LoST if it'= d decided that it's useful and doesn't screw up existing systems") If we we= re going to use an existing LoST server, I assumed that it would already be= using XML, thus it would matter for the master device because if PAWS uses= JSON only then a master device would need to support both XML and JSON. We= have never really discussed implementing a LoST server before, so I'm tryi= ng to figure out the plan. It's unfortunate that we did not have time to di= scuss discovery in Vancouver. 3. I'm trying to demonstrate other reasons that we may want to support XML,= but my example was based on using an existing LoST server implemented with= XML, and my assumption that we would not be re-writing the LoST standard (= because I didn't realize that was an option). I have a few questions of my own (for Brian): 1. You still don't care if we use XML or JSON, right? 2. You want the paws group to use LoST for discovery, right? 3. You will not support any other discovery proposal, it must be LoST, righ= t? 4. If paws uses JSON only, we will re-write the LoST spec and then implemen= t a LoST server using JSON, right? Thanks, Don From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Monday, August 27, 2012 11:40 AM To: Don Joslyn Cc: basavaraj.patil@nokia.com; peter.mccann@huawei.com; gabor.bajko@nokia.c= om; paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal So, you think you understand how to write location sensitive discovery for = a specific service? You think you thoroughly understand how it works, what the pitfalls are, wh= ere you need flexibility? Further, you think that every service that needs location sensitive discove= ry should invent its own mechanism and every jurisdiction (read country) sh= ould support who knows how many equivalent - but different, mechanisms? Or, maybe, you could allow that a group of very smart people spent a great = deal of time working out how location sensitive services should be discover= ed, and tried to come up with one mechanism that would work for a very wide= variety of services. I mean, why limit encoding to XML or JSON? Why don't we come up with our o= wn encoding? See in line for responses to the questions you asked On Aug 27, 2012, at 11:17 AM, Don Joslyn > wrote: So if you use JSON for LoST, are you really supporting the LoST standard as= it's currently written? Standards evolve. We can evolve LoST if it'd decided that it's useful and = doesn't screw up existing systems. Is there any chance that PAWS could use an existing LoST server? Sure Does one exist? Yes. It's still pretty early though. If one does not exist, then I'm assuming that someone would need to impleme= nt a LoST server for use by PAWS devices, correct? Maybe. In most places, I'd say, probably Would it then make sense to implement it with JSON, even though the standar= d as written uses XML? Sure, why not, assuming we have a good reason to use JSON for whitespace Maybe somebody should take a look at the XML messages described in the LoST= protocol, to determine how easy it will or will not be to convert them to = JSON. I'm not a JSON expert, but I doubt it would be hard. I'll ask an expert. Maybe we should just forget about using LoST, and go with the only discover= y proposal that has been formally submitted to PAWS? Maybe we should stop re-inventing something that has already been invented = and concentrate on things that need new work. Also, remember vCard/xCard - same arguments. --_000_8375F6DAEFB09F48815203F1FE23B797117AA6DAB3shelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Brian,

     

    =

    I think you’re misunderstanding my reason= for suggesting something other than LoST for discovery. Let me explainR= 30;

     

    1. I support using an existing solution f= or discovery, such as LoST, as it could save a great deal of time and effor= t. I have not seen any meaningful discussions to help the paws group unders= tand the pros/cons for LoST, or the understand the logistics of using it, s= o I’m trying to promote a useful exchange of information.<= /span>

     

    2. I do find it confusing that we’re spending all= this time/effort discussing XML versus JSON (and potentially being forced = to pick just one), but you think it does not matter when it comes to LoST (= “We can evolve LoST if it'd decided that it's useful and doesn= 't screw up existing systems”) If we were going to use an exis= ting LoST server, I assumed that it would already be using XML, thus it wou= ld matter for the master device because if PAWS uses JSON only then a maste= r device would need to support both XML and JSON. We have never really disc= ussed implementing a LoST server before, so I’m trying to figure out = the plan. It’s unfortunate that we did not have time to discuss disco= very in Vancouver.

     

    3. I’m trying to demonstrate other= reasons that we may want to support XML, but my example was based on using= an existing LoST server implemented with XML, and my assumption that we wo= uld not be re-writing the LoST standard (because I didn’t realize tha= t was an option).

    &nb= sp;

    I have a few questions of m= y own (for Brian):

    &n= bsp;

    1. You still don’t c= are if we use XML or JSON, right?

     

    2. You want= the paws group to use LoST for discovery, right?

     

    3. You will not support any other discovery proposal, it must be LoST,= right?

     <= /span>

    4. If paws uses JSON only, we will re= -write the LoST spec and then implement a LoST server using JSON, right?

     

    =

    Thanks,

    Don

     <= /o:p>

    From: Rosen, Brian [mail= to:Brian.Rosen@neustar.biz]
    Sent: Monday, August 27, 2012 11:40 = AM
    To: Don Joslyn
    Cc: basavaraj.patil@nokia.com; peter.= mccann@huawei.com; gabor.bajko@nokia.com; paws@ietf.org
    Subject: = Re: [paws] XML schema versus JSON, vCard & iCal

     

    &l= t;as individual>

    So, you think y= ou understand how to write location sensitive discovery for a specific serv= ice?

     

    You think you thoroughly understand how it works, wh= at the pitfalls are, where you need flexibility?

    <= p class=3DMsoNormal> 

    Fu= rther, you think that every service that needs location sensitive discovery= should invent its own mechanism and every jurisdiction (read country) shou= ld support who knows how many equivalent - but different, mechanisms?<= /o:p>

     

    Or, maybe, you could allow that a group of very smart pe= ople spent a great deal of time working out how location sensitive services= should be discovered, and tried to come up with one mechanism that would w= ork for a very wide variety of services.

     

    I mean, w= hy limit encoding to XML or JSON?  Why don't we come up with our own e= ncoding?

     

    See in line for responses to the questions= you asked

     <= /p>

    On Aug 27, 2012, at 11:17 AM, Don Joslyn = <d.joslyn@spectrumbridge.= com> wrote:



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

    Standards evolve. &= nbsp;We can evolve LoST if it'd decided that it's useful and doesn't screw = up existing systems.



    =

     

    Is there any chance that PAWS = could use an existing LoST server?

    Sure

    Does one exist?

    Yes.  It's still pretty early though. 

    =



    = If one does not exist, then I’m assuming that someone would ne= ed to implement a LoST server for use by PAWS devices, correct?

    Maybe.  In most places, I'= d say, probably



    =

    Would it then make sense to= implement it with JSON, even though the standard as written uses XML?

    Sure, why not, assuming w= e have a good reason to use JSON for whitespace



     

    May= be somebody should take a look at the XML messages described in the LoST pr= otocol, to determine how easy it will or will not be to convert them to JSO= N.

    I'm not a JSON exp= ert, but I doubt it would be hard.  I'll ask an expert.

    =

     

     

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

    Maybe we should stop re-inv= enting something that has already been invented and concentrate on things t= hat need new work.

     = ;

    Also, remember vCard/xCard - sam= e arguments.  

    &nbs= p;

     

    = --_000_8375F6DAEFB09F48815203F1FE23B797117AA6DAB3shelby_-- From brian.rosen@neustar.biz Mon Aug 27 11:00:12 2012 Return-Path: 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 5537521F855D for ; Mon, 27 Aug 2012 11:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jQ+82QFYI85y for ; Mon, 27 Aug 2012 11:00:11 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 94B5021F854B for ; Mon, 27 Aug 2012 11:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1346090682; x=1661447662; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=QKptSj2eWLWBPllvxvEAgQt9+N0ia4xEHyqsU3KA4Tc=; b=AHjqVbNaf+mIHuMQLcCdqumP7mSt22AQ7DRNk6IIg+LJaf8X64ZVg19zK+IuD0 JXh7UWg0fisbgUKuwcARfx5w== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.13572459; Mon, 27 Aug 2012 14:04:41 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 27 Aug 2012 14:00:00 -0400 From: "Rosen, Brian" To: Don Joslyn Date: Mon, 27 Aug 2012 13:59:59 -0400 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac2EfcaPpfOBAQfXSPyo09fw+HB2Nw== Message-ID: References: <8375F6DAEFB09F48815203F1FE23B797117AA6DAA0@shelby> <5E786066-2218-4B80-A1BE-67F9AB4DDEC3@neustar.biz> <8375F6DAEFB09F48815203F1FE23B797117AA6DAB3@shelby> In-Reply-To: <8375F6DAEFB09F48815203F1FE23B797117AA6DAB3@shelby> 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: xqW0hMtusRjnUuQEiEDpRQ== Content-Type: multipart/alternative; boundary="_000_C3B3B8778428407EB0944F890C22EA69neustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 18:00:12 -0000 --_000_C3B3B8778428407EB0944F890C22EA69neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable See inline for my responses On Aug 27, 2012, at 1:21 PM, Don Joslyn > wrote: Brian, I think you=92re misunderstanding my reason for suggesting something other = than LoST for discovery. Let me explain=85 1. I support using an existing solution for discovery, such as LoST, as it = could save a great deal of time and effort. I have not seen any meaningful = discussions to help the paws group understand the pros/cons for LoST, or th= e understand the logistics of using it, so I=92m trying to promote a useful= exchange of information. 2. I do find it confusing that we=92re spending all this time/effort discus= sing XML versus JSON (and potentially being forced to pick just one), but y= ou think it does not matter when it comes to LoST (=93We can evolve LoST if= it'd decided that it's useful and doesn't screw up existing systems=94) If= we were going to use an existing LoST server, I assumed that it would alre= ady be using XML, thus it would matter for the master device because if PAW= S uses JSON only then a master device would need to support both XML and JS= ON. We have never really discussed implementing a LoST server before, so I= =92m trying to figure out the plan. It=92s unfortunate that we did not have= time to discuss discovery in Vancouver. A LoST server intending to support Whitespace devices would need to support= whatever encoding we would specify. That could complicate deployment, bec= ause XML encoding is driving current LoST deployments, but I don't think th= at is a limiting factor. It's a factor, but not a limiting one. 3. I=92m trying to demonstrate other reasons that we may want to support XM= L, but my example was based on using an existing LoST server implemented wi= th XML, and my assumption that we would not be re-writing the LoST standard= (because I didn=92t realize that was an option). I think it's an option. We would probably want to consult with ecrit, the = work group that promulgated LoST. I have a few questions of my own (for Brian): 1. You still don=92t care if we use XML or JSON, right? Right 2. You want the paws group to use LoST for discovery, right? Yes 3. You will not support any other discovery proposal, it must be LoST, righ= t? I wouldn't put it that hard. If there is some good reason LoST won't work,= sure. Don't know of any, but I'm willing to listen. 4. If paws uses JSON only, we will re-write the LoST spec and then implemen= t a LoST server using JSON, right? I'd phrase that as "add a JSON encoding to LoST", that's not a rewrite, it'= s an update. It would be a fairly short document that normatively updated = RFC5222. Thanks, Don From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Monday, August 27, 2012 11:40 AM To: Don Joslyn Cc: basavaraj.patil@nokia.com; peter.mcca= nn@huawei.com; gabor.bajko@nokia.com; paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal So, you think you understand how to write location sensitive discovery for = a specific service? You think you thoroughly understand how it works, what the pitfalls are, wh= ere you need flexibility? Further, you think that every service that needs location sensitive discove= ry should invent its own mechanism and every jurisdiction (read country) sh= ould support who knows how many equivalent - but different, mechanisms? Or, maybe, you could allow that a group of very smart people spent a great = deal of time working out how location sensitive services should be discover= ed, and tried to come up with one mechanism that would work for a very wide= variety of services. I mean, why limit encoding to XML or JSON? Why don't we come up with our o= wn encoding? See in line for responses to the questions you asked On Aug 27, 2012, at 11:17 AM, Don Joslyn > wrote: So if you use JSON for LoST, are you really supporting the LoST standard as= it=92s currently written? Standards evolve. We can evolve LoST if it'd decided that it's useful and = doesn't screw up existing systems. Is there any chance that PAWS could use an existing LoST server? Sure Does one exist? Yes. It's still pretty early though. If one does not exist, then I=92m assuming that someone would need to imple= ment a LoST server for use by PAWS devices, correct? Maybe. In most places, I'd say, probably Would it then make sense to implement it with JSON, even though the standar= d as written uses XML? Sure, why not, assuming we have a good reason to use JSON for whitespace Maybe somebody should take a look at the XML messages described in the LoST= protocol, to determine how easy it will or will not be to convert them to = JSON. I'm not a JSON expert, but I doubt it would be hard. I'll ask an expert. Maybe we should just forget about using LoST, and go with the only discover= y proposal that has been formally submitted to PAWS? Maybe we should stop re-inventing something that has already been invented = and concentrate on things that need new work. Also, remember vCard/xCard - same arguments. --_000_C3B3B8778428407EB0944F890C22EA69neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable See inline for my responses <as individual>

    On Aug 27, 2012, at 1:21 PM, Don Joslyn <d.joslyn@spectrumbridge.com> wrote:

    Brian,
     
    I think you=92re misunderstanding my reason for suggesti= ng something other than LoST for discovery. Let me explain=85
     
    1. I support using an existing solution= for discovery, such as LoST, as it could save a great deal of time and eff= ort. I have not seen any meaningful discussions to help the paws group unde= rstand the pros/cons for LoST, or the understand the logistics of using it,= so I=92m trying to promote a useful exchange of information.
     
    2. I do find it confusing that we=92re = spending all this time/effort discussing XML versus JSON (and potentially b= eing forced to pick just one), but you think it does not matter when it com= es to LoST (=93We can evolve LoST if it'd decided that it's useful a= nd doesn't screw up existing systems=94) If we were going to use an existing LoST = server, I assumed that it would already be using XML, thus it would matter = for the master device because if PAWS uses JSON only then a master device w= ould need to support both XML and JSON. We have never really discussed impl= ementing a LoST server before, so I=92m trying to figure out the plan. It= =92s unfortunate that we did not have time to discuss discovery in Vancouve= r.
    A LoST server intending to support = Whitespace devices would need to support whatever encoding we would specify= .  That could complicate deployment, because XML encoding is driving c= urrent LoST deployments, but I don't think that is a limiting factor.  = ;It's a factor, but not a limiting one.

     
    3. I=92m trying to demonstrate other reasons that we = may want to support XML, but my example was based on using an existing LoST= server implemented with XML, and my assumption that we would not be re-wri= ting the LoST standard (because I didn=92t realize that was an option).
    I think it's an option.  We would pr= obably want to consult with ecrit, the work group that promulgated LoST.

     
    I have= a few questions of my own (for Brian):
     
    1. You still don=92t care if we use XML or JSON, right?
    Right

     
    2. You want the paws group to use LoST = for discovery, right?
    Yes
    &= nbsp;
    3. You will not = support any other discovery proposal, it must be LoST, right?
    <= /div>
    I wouldn't put it that hard.  If there is some= good reason LoST won't work, sure.  Don't know of any, but I'm willin= g to listen.


     
    4. If paws uses JSON only, we will re-write the LoS= T spec and then implement a LoST server using JSON, right?
    I'd phrase that as "add a JSON encoding to LoST", that= 's not a rewrite, it's an update.  It would be a fairly short document= that normatively updated RFC5222.


     <= /div>
    Thanks,
    Don
     
    From:<= span style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; "> Rosen, Brian [mailto:Brian.Rosen@= neustar.biz] 
    Sent:=  Monday, August 27, 2= 012 11:40 AM
    To: Don Joslyn
    Cc: basavaraj.patil@nokia.com; peter.mccann@huawei.com; = gabor.bajko@nokia.com; paws@ietf.org
    Subject: Re: [paws] XML schema versus JSON, = vCard & iCal
    =  
    <as individual>
    So, you think you understand how to wr= ite location sensitive discovery for a specific service?
     
    You think you thoroughly understand how it works, what the pitfalls= are, where you need flexibility?
     
    Further, = you think that every service that needs location sensitive discovery should= invent its own mechanism and every jurisdiction (read country) should supp= ort who knows how many equivalent - but different, mechanisms?
     
    Or, maybe, you could allow that a group of very smart p= eople spent a great deal of time working out how location sensitive service= s should be discovered, and tried to come up with one mechanism that would = work for a very wide variety of services.
     
    I= mean, why limit encoding to XML or JSON?  Why don't we come up with o= ur own encoding?
    &nb= sp;
    See in line for responses = to the questions you asked
    On Aug 27, 2012, = at 11:17 AM, Don Joslyn <d.joslyn@spectrumbrid= ge.com> wrote:


    =
    So if you us= e JSON for LoST, are you really supporting the LoST standard as it=92s curr= ently written?
    Standard= s evolve.  We can evolve LoST if it'd decided that it's useful and doe= sn't screw up existing systems.


     
    Is there any chance that PAWS could use an existing LoST ser= ver?
    Sure

    =
    Does one exi= st?
    Yes.  It's sti= ll pretty early though. 


    If one does not exist, then I=92m assuming that someone would need to impl= ement a LoST server for use by PAWS devices, correct?
    Maybe.  In most places, I'd say, probab= ly


    Would it then make sense t= o implement it with JSON, even though the standard as written uses XML?
    Sure, why not, assuming we= have a good reason to use JSON for whitespace
    <= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times= New Roman', serif; ">

     
    Maybe somebody should take a look at the XML= messages described in the LoST protocol, to determine how easy it will or = will not be to convert them to JSON.
    I'm not a JSON expert, but I doubt it would be hard. &n= bsp;I'll ask an expert.
    <= o:p> 
     
    Mayb= e we should just forget about using LoST, and go with the only discovery pr= oposal that has been formally submitted to PAWS?
    Maybe we should stop re-inventing so= mething that has already been invented and concentrate on things that need = new work.
     
    Also, remember vCard/xCard - same= arguments.  
    &= nbsp;


    = --_000_C3B3B8778428407EB0944F890C22EA69neustarbiz_-- From horvitz@volny.cz Mon Aug 27 14:24:47 2012 Return-Path: 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 6B9B621F84F7 for ; Mon, 27 Aug 2012 14:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.35 X-Spam-Level: * X-Spam-Status: No, score=1.35 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 rr+njS8u83kG for ; Mon, 27 Aug 2012 14:24:46 -0700 (PDT) Received: from mxout.volny.cz (mxout.volny.cz [62.44.29.23]) by ietfa.amsl.com (Postfix) with ESMTP id BE86221F84F2 for ; Mon, 27 Aug 2012 14:24:45 -0700 (PDT) Received: from webmail1.volny.internal (webmail1.volny.internal [172.20.100.61]) by mxout.volny.cz (Postfix) with ESMTP id 236121E08FB for ; Mon, 27 Aug 2012 23:24:43 +0200 (CEST) Received: by webmail1.volny.internal (Postfix, from userid 48) id 228E11606FB; Mon, 27 Aug 2012 23:24:43 +0200 (CEST) Received: from 93-137-177-130.adsl.net.t-com.hr (93-137-177-130.adsl.net.t-com.hr [93.137.177.130]) by mail1.volny.cz (mail1.volny.cz [172.20.100.61]) with HTTP; Mon, 27 Aug 2012 23:24:43 +0200 (CEST) MIME-Version: 1.0 From: horvitz@volny.cz X-Originating-Account: horvitz/volny.cz To: paws@ietf.org Date: Mon, 27 Aug 2012 23:24:43 +0200 (CEST) Message-ID: X-Mailer: Volny.cz Webmail2 2.147 X-Originating-Ip: 93.137.177.130 X-Originating-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.83 Safari/537.1 X-Webmail2-Origin: horvitz/volny.cz [93.137.177.130] X-Originating-X-Forwarded-For: 93.137.177.130 X-Priority: 3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [paws] =?iso-8859-2?q?Finland_issues_Europe=27s_first_TVWS_geoloc?= =?iso-8859-2?q?ation_database_test_license?= X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 21:24:47 -0000 Today Finland's telecom regulator FICORA issued Europe's first geolocation database service test license for TV white spaces to Fairspectrum Oy. The license for database control of cognitive radios was issued 27 August to the Turku University of Applied Sciences. The license is valid for one year and covers the 470-790 MHz frequency range in a 40 x 40 km area surrounding Turku, Finland. Nearly 300 000 people live in the radio license area. The license will be used by the White Space Environment (WISE) test consortium. which consists of Nokia, Digita, Fairspectrum, Ficora, Turku University of Applied Sciences, University of Turku, and Aalto University. See the following link for Fairspectrum's press release: https://sites.google.com/a/fairspectrum.com/public/propagating-thoughts/pressreleasefairspectrumprovidestvwhitespacedatabaseforeurope%E2%80%99sfirstgeolocationradiolicense -- Robert Horvitz Stichting Open Spectrum Slavikova 11, 120 00 Prague 2, Czech Republic Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland mailto:bob@openspectrum.info http://www.openspectrum.info/ mob: +420 775024705 tel/fax: +420 222967456 From peter@spectrumbridge.com Mon Aug 27 14:37:47 2012 Return-Path: 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 F419621E803F for ; Mon, 27 Aug 2012 14:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=-1.132, BAYES_50=0.001] 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 cntty4pmZoQx for ; Mon, 27 Aug 2012 14:37:46 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 3E81921E8034 for ; Mon, 27 Aug 2012 14:37:46 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 27 Aug 2012 17:37:45 -0400 From: Peter Stanforth To: "horvitz@volny.cz" , "paws@ietf.org" Date: Mon, 27 Aug 2012 17:37:41 -0400 Thread-Topic: [paws] Finland issues Europe's first TVWS geolocation database test license Thread-Index: Ac2EnDGZWtDWtgF8S8Wx9KApqv3jzA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] Finland issues Europe's first TVWS geolocation database test license X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 21:37:47 -0000 Nice press release. Just 2 years late. Spectrum Bridge, Nokia, Airspan and KTS did this in 2010! On MonAug/27/12 Mon Aug 27, 5:24 PM, "horvitz@volny.cz" wrote: >Today Finland's telecom regulator FICORA issued Europe's first >geolocation database service test license for TV white spaces to >Fairspectrum Oy. > >The license for database control of cognitive radios was issued 27 August >to the Turku University of Applied Sciences. The license is valid for one >year and covers the 470-790 MHz frequency range in a 40 x 40 km area >surrounding Turku, Finland. Nearly 300 000 people live in the radio >license area. The license will be used by the White Space Environment >(WISE) test consortium. which consists of Nokia, Digita, Fairspectrum, >Ficora, Turku University of Applied Sciences, University of Turku, and >Aalto University. See the following link for Fairspectrum's press >release: > >https://sites.google.com/a/fairspectrum.com/public/propagating-thoughts/pr >essreleasefairspectrumprovidestvwhitespacedatabaseforeurope%E2%80%99sfirst >geolocationradiolicense > > > >--=20 >Robert Horvitz >Stichting Open Spectrum >Slavikova 11, 120 00 Prague 2, Czech Republic >Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland >mailto:bob@openspectrum.info >http://www.openspectrum.info/ >mob: +420 775024705 >tel/fax: +420 222967456 > > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From paul@marvell.com Mon Aug 27 18:39:55 2012 Return-Path: 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 2CA6821F848F for ; Mon, 27 Aug 2012 18:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[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 Bcx7OusfOajE for ; Mon, 27 Aug 2012 18:39:43 -0700 (PDT) Received: from na3sys009aog127.obsmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9D821F8493 for ; Mon, 27 Aug 2012 18:39:41 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKUDwhVx96YSfwXYISY7MOdH26S1C9iuHw@postini.com; Mon, 27 Aug 2012 18:39:42 PDT Received: from sc-owa02.marvell.com (10.93.76.22) by sc-owa01.marvell.com (10.93.76.21) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 27 Aug 2012 18:37:13 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Mon, 27 Aug 2012 18:37:13 -0700 From: Paul Lambert To: Vincent Chen , Manikkoth Sajeev , "paws@ietf.org" Date: Mon, 27 Aug 2012 18:37:12 -0700 Thread-Topic: [paws] XML schema versus JSON, vCard & iCal Thread-Index: Ac2CcsREYWfzfuBGR2+2h0mPGD56rACSq3cw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D015E44DE391@SC-VEXCH2.marvell.com> References: <1DBBA0CF-DF26-41E2-BFED-8A5FABC60A0F@neustar.biz> <00c601cd820b$67b97170$372c5450$@us> <5037B28B.70501@blindcreek.com> <5D0B1E63-79FE-4BC6-A446-3470931D1043@neustar.biz> <5037BC2B.7010008@blindcreek.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601FB7724@008-AM1MPN1-006.mgdnok.nokia.com> <1345864438.6327.YahooMailNeo@web120306.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7BAC95F5A7E67643AAFB2C31BEE662D015E44DE391SCVEXCH2marve_" MIME-Version: 1.0 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 01:39:55 -0000 --_000_7BAC95F5A7E67643AAFB2C31BEE662D015E44DE391SCVEXCH2marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Real protocols use TLVs ... :) Paul From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vin= cent Chen Sent: Friday, August 24, 2012 8:36 PM To: Manikkoth Sajeev Cc: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal Sajeev, It's been a while since I've worked with embedded devices. I'm surprised th= at the same concern does not apply to XML. Do you not need libraries to wor= k with XML? On Fri, Aug 24, 2012 at 8:13 PM, Manikkoth Sajeev > wrote: Hi, I would still support XML. JSON libraries are available for all languages. = But interfacing and linking such libraries are problematic on embedded devi= ces most of the time. And if an implementation vouch for multiple such non = native language libraries then developers life is hell... Best Regards, Sajeev Manikkoth From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; ben@blindcreek= .com Cc: paws@ietf.org Sent: Saturday, 25 August 2012, 0:38 Subject: Re: [paws] XML schema versus JSON, vCard & iCal 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 su= pported 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 optio= ns, 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 sho= rt, with the only caveat that if there is no strong technical argument for = supporting and specifying two different encodings, then the iesg may send t= he document back to the wg to pick one of the two specified. As Robert ment= ioned 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 en= coding, being that either xml or json? Most people speak in favor of JSON, because it is compact and more efficien= t. 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 objectio= n gave no real reason. So I am wondering if there is really any valid techn= ical reason against using JSON only? - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Rosen, Brian Sent: Friday, August 24, 2012 10:43 AM To: Benjamin A. Rolfe Cc: 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 dec= iding 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" > 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 informa= tion about what options each supports, without requiring that any device im= plement 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 on= e 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 im= plement 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 implem= ent 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 wha= t to implement doesn't work for me (or Richard). Brian On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe > wrote: Apparently I was unclear. I certainly an capable of being wrong as I pract= ice often, but in this case it is quite unlikely :-). You do not need to choose only one form to achieve interoperability. If y= ou have two, let the device implementer figure out which is best for their = particular device requirements and trade-offs. This is *preferable* from m= y perspective. If you provide more than one form in the database, devices using the databa= se 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 thos= e 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 devic= es 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 f= orms available, it won't need to dynamically figure it out. The device impl= ementer has options and simplicity, so I like it. Since I am focused on the TVWS devices that need access to the database, an= d 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. :) 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 m= arket decide" only holds so much validity. You actually have to choose SOM= ETHING to create a baseline of interoperability. A virtually identical argument is now playing out in discussions of mandat= ory 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.= :) From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com Sent: Thursday, August 23, 2012 5:44 PM To: Brian.Rosen@neustar.biz; d.joslyn@spect= rumbridge.com Cc: 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 achie= ve interoperability. And this applies to the device and database side of the protocol. -Raj From: "", "Brian.Rosen@neustar.biz" > Date: Thursday, August 23, 2012 2:43 PM To: Don Joslyn > Cc: "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 impleme= ntations. On the other hand, the whole point of a protocol document like o= urs is that two independent implementations who both follow the document wi= ll 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 fig= ure it out using proprietary protocols. The market will decide. So, I feel strongly that if one end is "either", the other end must be "bot= h". It's also acceptable to say both ends implement one choice and the oth= er is optional at both ends. Here, I think it's server does both and clien= t does either. It's always possible to build an implementation of a server that only does = one: there are no protocol police. Brian On Aug 23, 2012, at 3:11 PM, Don Joslyn > 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-boun= ces@ietf.org] On Behalf Of Benjamin A. Rolfe Sent: Thursday, August 23, 2012 3:05 PM To: paws@ietf.org Subject: Re: [paws] XML schema versus JSON, vCard & iCal Someone suggested that PAWS define both, and let the vendors decide which o= nes to implement. That makes the most sense for both DB and device vendors. Markets will pro= bably drive DB vendors to do both. Device vendors will do what fits the mar= ket segment they're after. Why over-constrain (or argue when natural select= ion will take care of it for us?). B Sounds good to me. From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Tuesday, August 21, 2012 12:42 AM To: 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 encodi= ng. To prevent endless discussions on this topic I'd suggest we move forward wi= th supporting both in the DB and either one in the master device. Any objections? Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@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; 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 need= ed for XML From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Don Josly= n Sent: Monday, August 20, 2012 4:54 PM To: Vincent Chen; Weixinpeng Cc: 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-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: Monday, August 20, 2012 2:56 PM To: Weixinpeng Cc: 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 dev= ice 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 wo= rk" 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 (clie= nt-side) prefer it for its simplicity: * Representation closely matches most data models (nested lists and m= aps) * Simple-to-use libraries exist for all major languages/platforms * Don't need a tool chain to work with the data, as is typically need= ed 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 Goog= le 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 mor= e efficient, can't argue with that.] * At the end of the day, it's the data model that matters, rather than t= he 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 suppo= rting 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 device= s) 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 muc= h or exchanged that often.] On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng > 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-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; gabor.bajko@nokia.com; = vchen@google.com; peter@spectrumbridge.com Cc: 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 desi= gn or implementation, but I am a big fan of reusing standards rather than d= efining new ones, and I would not want to see the choice of json mean we th= en 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 x= Card and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complication= s. If there is rough consensus for both, then I would assert that all serv= ers 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 sol= ely or even largely because of compactness advantages rarely are good choic= es. 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 From: Manikkoth Sajeev > Reply-To: Manikkoth Sajeev > Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "Gabor.Bajko@nokia.com" >, "Rosen, Brian" >, "vchen@google.com" >, "peter@spectrumbridge.co= m" > Cc: "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 im= plementations may prefer XML as it is generic, omni present, easy to unders= tand and validate. For compactness may be a binary xml optioncan also work= . JSON I think will necessitate implementation to be native Java and may no= t be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev From: "Gabor.Bajko@nokia.com" > To: Brian.Rosen@neustar.biz; vchen@google.c= om; peter@spectrumbridge.com Cc: 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-boun= ces@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' 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 whol= e lot about that Brian -----Original Message----- From: Vincent Chen [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 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 inde= pendent, yet well-matched to all major languages. JSON-handling libraries e= xist for numerous languages (see of http://json.org/) and seem to be reason= ably light weight. Timestamps As for timestamp specifications, should we consider just using seconds sinc= e the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for = datetime-string parsing on devices, assuming devices already have native li= braries that provide time in this format. Is that a valid assumption? Of co= urse, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > wrote: Whenever we built mobile devices we never dealt with IETF, in our senso= r days even an IP stack was a challenge,so I would defer to the device gu= ys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > 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 advocat= ing >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] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: 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" > 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 resourc= es, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to en= d, >>>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 need= s >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAW= S >>message exchange, I think. This may be of importance when using satco= m >>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 Nota= tion >>>>(JSON) Representation for vCard"? >>>> 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 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_7BAC95F5A7E67643AAFB2C31BEE662D015E44DE391SCVEXCH2marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Real prot= ocols use TLVs …  

     

    J

     

     

     

    Paul

     

     

    From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Chen
    Sent: Friday, August 24, 2012 8:36= PM
    To: Manikkoth Sajeev
    Cc: paws@ietf.org
    Subjec= t: Re: [paws] XML schema versus JSON, vCard & iCal

     

    Sajeev,

     

    <= /div>

    It's been a while since I've worked with emb= edded devices. I'm surprised that the same concern does not apply to XML. D= o you not need libraries to work with XML?

     

    &nb= sp;

    On Fri, Aug 24, 2012 at 8:13 PM, Man= ikkoth Sajeev <mks= aji@yahoo.com> wrote:

    Hi,

     

    =

    I would still support XML. JSON libraries a= re available for all languages. But interfacing and linking such libraries = are problematic on embedded devices most of the time. And if an implementat= ion vouch for multiple such non native language libraries then developers l= ife is hell...

     

    Bes= t Regards,

     <= o:p>

    Sajeev Manikkoth

     

    From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>To: B= rian.Rosen@neustar.biz; ben@blindcreek.com
    Cc: paws@ietf.org
    Sent: Saturday, 25 Augu= st 2012, 0:38


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

     

    WiFi worl= d builds on mandating the implementation (and certification) of a base spec= , and a set of optional features. If an optional feature is not supported b= y 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 sho= uld stop debating it.

    = I’d also like to add t= he obvious option D) to the list, which is that both the master devices and= DBs support one and the same encoding ;)

    <= p class=3DMsoNormal> 

    Option A) seems to be like a good compromise, and w= ould 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 s= pecified. 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 a= rgument in favor of two different encodings.

    &nbs= p;

    Is there anyone who has a technical argument ag= ainst 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 thr= ead and I saw 2 objections against picking JSON. One said that JSON require= s 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: pa= ws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Rosen, B= rian
    Sent: Friday, August 24, 2012 10:43 AM
    To: Benjami= n A. Rolfe
    Cc: paws@ietf.org
    Subject: Re: [paws] XML schema versus JSON, vC= ard & iCal

     

    Okay:<= /p>

     

    So, I implement a database, and I implement XM= L

    You implement a = device, and you implement JSON

     

    You query my database (let's not get into how you do that query without d= eciding 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> wrot= e:

     

     

    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 inf= ormation about what options each supports, without requiring that any devic= e 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 tha= n either of the other two.
     

     

    One is that one end implements both choices and the other end implements = one or both.

     = ;

    The other is tha= t both ends implement one specific choice ("MUST implement") and = both can optionally implement the other choice.  Only if both ends imp= lement the other choice would that be available.

    =

     

    <= p class=3DMsoNormal>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.<= o:p>

     <= /p>

    I don't care, but choice C) B= oth databases and devices have a choice of what to implement doesn't work f= or me (or Richard).

     

    Brian

     

    =

    On Aug 24, 2012, at 12= :57 PM, Benjamin A. Rolfe <ben@blindcreek.com> wrote:

     

    =

    Apparen= tly I was unclear.  I certainly an capable of being wrong as I practic= e often, but in this case it is quite unlikely :-).

    You do not need= to choose only one form to achieve interoperability.   If you ha= ve two, let the device implementer figure out which is best for their parti= cular device requirements and trade-offs.  This is *preferable* from m= y perspective.

    If you provide more than one form in the database, de= vices using the database need some means for figuring out which are availab= le. 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  momen= t that if you provide options, to make those useful you need to provide&nbs= p; a protocol by which devices can discover what options the database suppo= rts.  If you have such a mechanism and all devices use it (a  boo= tstrap protocol), everything else could be options.  This requires add= itional functions in both database and device implementations.
    If on th= e 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 im= plementer has options and simplicity, so I like it.

    Since I am focu= sed on the TVWS devices that need access to the database, and not a databas= e implementer, shifting burden onto the database implementer (not me) to re= duce the burden on the device implementer (me) is preferred from my perspec= tive.  The database implementer may have another perspective.  Sh= ould 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 wr= ong. J <= /o:p>

     

    This is why you hav= e MUST and SHOULD in RFC 2119.  

    =

     <= /span>

    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 d= iscussions of mandatory audio and codec implementations for WEBRTC like thi= ngs.

     

    I= MHO XML MUST anything else defined SHOULD, but MUST on XML and JSON could w= ork as well. It just leads to a level of complexity in implementations.

     

    End of ar= gument you now can go back to your regularly schedule programming. <= span style=3D'font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J

     

     

    <= p class=3DMsoNormal>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of= Basavar= aj.Patil@nokia.com
    Sent: Thursday, August 23, 2012 5:44 PMTo: Br= ian.Rosen@neustar.biz; d.joslyn@spectrumbridge.com
    Cc: paws@ietf.org
    Subject:= Re: [paws] XML schema versus JSON, vCard & iCal

    <= /div>

     

    =

     

    I agree with Brian.

    =

    There needs = to be a default mandatory to implement option in order to achieve interoper= ability. 

    And this applies to the device and data= base side of the protocol.

    =

     

    -Raj

     

    From: "<ext Rosen>", "Brian.Rosen@neustar.b= iz" <Brian.Rosen@neustar.biz>
    Date: Thursday, August 23, 201= 2 2:43 PM
    To: Don Joslyn <d.joslyn@spectrumbridge.com>
    Cc: = "paws@ietf.org<= /a>" <paws@ietf.= org>
    Subject: Re: [paws] XML schema versus JSON, vCard &am= p; iCal

     

    <= /div>

    On= e of my favorite IETF expressions is "There are no protocol police&quo= t;.  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 protoc= ol document like ours is that two independent implementations who both foll= ow the document will interwork.  If that wasn't true, why do you need = a standard?

     

    If you s= ay "either" to both ends, then you don't get interoperability. &n= bsp;

    <= span style=3D'font-size:8.5pt'> 

    By your ar= gument, 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 on= e 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 clien= t does either. 

     

    =

    It's always possible to build an implementation of a server that only= does one: there are no protocol police.

    <= div>

     

    Brian <as individual>

    =

     

     

     

    =

     

    On Aug 23, 2012, at 3:11 PM, Don Joslyn <d.joslyn@spectrumbridge.com> wrote:

    From: 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
    Subject: Re: [paws] XML schema= versus JSON, vCard & iCal

     

    =

    Someone suggested that = PAWS define both, and let the vendors decide which ones to implement.
    Th= at 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 sel= ection will take care of it for us?).
    B


    =

    Sound= s good to me.

     

    From: paws-bounces@ietf.org&= nbsp;[mailto:paws-bounces@ietf.org] On Beha= lf Of <= span style=3D'color:purple'>Gabor.Bajko@nokia.com
    Sent: Tuesday, August 21, 2012 12:42 AM
    To: paws@ietf.= org
    Subject: Re: [paws] XML schema versus JSON, v= Card & iCal

     

    Now I can’t see anymore any wi= llingness to agree on one or the other encoding.

    To p= revent endless discussions on this topic I’d suggest we move forward = with supporting both in the DB and either one in the master device.<= o:p>

    Any objections?

    <= p class=3DMsoNormal> 

    Gabor

     =

     

    From: paws-bounces@ietf.org [m= ailto:paws-bounces@ietf.org] On Behalf Of ext D= as, Subir
    Sent: Monday, August 20, 2012 2:50 PM
    To: Don Joslyn; Vincent Chen; Weixinpeng
    Cc: paws@ie= tf.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 fo= r JSON if we had to pick one.

    Also I will copy the fo= llowing two important points:

     

      • Simple-to-use librar= ies 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] On Behalf Of Don Joslyn=
    Sent: Monday, August 20, 2012 4:54 PM
    To: Vi= ncent Chen; Weixinpeng
    Cc: paws@ietf.org; Ma= nikkoth Sajeev
    Subject: Re: [paws] XML schema versus JSON, v= Card & iCal

     

    Please see my comments below…<= /span>

    Thanks,

    Don

     

    From: paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org] On Behalf Of Vincent Chen
    Se= nt: Monday, August 20, 2012 2:56 PM
    To: Weixinpeng<= br>Cc: paws@ietf.org    ; Manikkoth Sajeev
    Su= bject: Re: [paws] XML schema versus JSON, vCard & iCal<= o:p>

     <= /o:p>

    • One of our goals is to s= trive to lower the cost and complexity for device manufacturers. This lower= s the barrier for building a robust ecosystem.
    <= div>

    [DJ - The ̶= 0;cost” and complexity of using XML has not been an issue for the hal= f dozen TVBD vendors that have already used XML. Maybe we need to better de= fine “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, devic= es only need to support one to talk to the database. Our current database s= upports 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 embed= ded devices.]

    • There's a trend for APIs on the web towards JSON (Twitter, FourSquare, Fa= cebook, Google, etc.). One of the major reasons is that developers (client-= side) prefer it for its simplicity:
      • Representation closely matches most da= ta models (nested lists and maps)
      • Simpl= e-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.

    Appare= ntly, the efficiency gains of JSON also matter to the scalability of servin= g systems.

     

    =

    [DJ R= 11; I can’t argue against these listed pros for JSON, especially when= you’re dealing with a lot of data (like Twitter, FourSquare, Faceboo= k and Google does). But I’m assuming that PAWS messages will not be e= xchanged 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 actu= ally neutral on XML vs JSON, as long as we're clear on what device makers w= ant. It would be good to get feedback from device makers (especially of emb= edded devices) regarding experiences supporting XML vs JSON.

     

    Don, c= an you elaborate on the types of devices that already support XML?

     

    [DJ - We currently support half a dozen TVDB radio vendors (embedded devi= ces) using XML, non using JSON. XML has not been a burden, and the amount o= f data that needs to be exchanged between device and database is not that m= uch or exchanged that often.]

    On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng <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 prefe= rred.

     

    --Xinpeng Wei

     

    Fr= om: paws-boun= ces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Rosen, Brian


    Sent: Friday,= August 17, 2012 9:26 PM

    <= div>


    Cc: paws@ietf.org
    Subject: Re: [paws] XML schema versus JSON, vCard = & iCal

     

    I don't really care whether we u= se 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 no= t 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.

     <= /o:p>

    I would prefer to not have "both", because = of interoperability complications.  If there is rough consensus for bo= th, then I would assert that all servers have to implement both and the cli= ent can implement either.

    =

     

    There are json validators, so I don't think that is= a big deal.  

    <= p class=3DMsoNormal> 

    My experience in protocol design on the Internet is that = decisions made solely or even largely because of compactness advantages rar= ely 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 des= ign.  Text wins, binary loses, in my opinion.

     

    Brian <as individual>= ;

     

    =

    From: Manikkoth Sajeev <mksaji@yahoo.com<= /span>>
    Reply-To: Manikkoth Sajeev <mksaji= @yahoo.com>
    Date: Thu, 16 Aug 2012 22:37:38 -0= 400
    To: "Gabor.Bajko@nokia.com&= quot; <Gabor.Bajko@nokia.com>, "Rosen, B= rian" <brian.rosen@neustar.biz>, "= ;vchen@google.com" <vchen@google.com>, "peter@spectrumbridge.com"= ; <peter@spectrumbridge.com>
    Cc:&nbs= p;"paws@ietf.org" <paws@ietf.org>
    Subject: Re: [paws] XML schema versus JSON, vCar= d & iCal

     

    <= /div>

    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 underst= and and validate. For compactness may be a  binary xm= l optioncan also work. JSON I think will necessitate implementation to = be native Java and may not be as friendly with other implementation languag= es.

     

    Best Regards,

    Sajeev Manikkoth
    Mobile:&n= bsp;+918792292002
    Email: mksaji@ieee.org
    http://www.linkedin.com/= in/mksajeev

     

    <= /div>

    From: "Gabor.Bajko@nokia.com" <= ;Gabor.Bajko@nokia.com>
    To: Brian.Rosen@neustar.biz; vchen@google.com= ; peter@spectrumbridge.com =
    Cc: paws@ietf.org     
    Sent:&nbs= p;Friday, 17 August 2012, 4:55
    Subject: Re: [paws] XML schem= a versus JSON, vCard & iCal


    We have not heard any objections for using JSON encoding instead o= f XML. 
    Therefore, let's go for JSON, and close this thread.
    - Gabor

    -----Original Message-----
    From: 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.or= g'
    Subject: Re: [paws] XML schema versus JSON, vCard & iC= al

    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<= /span>]
    Sent:    Monday, August 13, 2012 06:04 PM Eas= tern Standard Time
    To:    Peter Stanforth
    Cc: &nb= sp;  Rosen, Brian; Teco Boot; Benjamin A.Rolfe; paws@ietf.or= g
    Subject:    Re: [paws] XML schema versus JSO= N, vCard & iCal

    XML vs JSON

    Between XML and JSON, JSON me= ssages are more compact and easier to process (parsing, synthesis). As clar= ification, JSON does not require JavaScript or a Browser. It is a text-base= d 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/) and seem to be reasonably light w= eight.

    Timestamps

    As for timestamp specifications, should we = consider just using seconds since the UNIX Epoch (1970-01-01T00:00:00Z)? Th= is would eliminate the need for datetime-string parsing on devices, assumin= g devices already have native libraries that provide time in this format. I= s 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> wrote:


       = ; Whenever we built mobile devices we never dealt with IETF, in our sensor<= br>    days even an IP stack was a challenge,so I would defe= r to the device guys
        on that one.
      &nbs= p; 
        On MonAug/13/12 Mon Aug 13, 9:30 AM, "R= osen, Brian"
        
        <Brian.Rosen@neustar.biz> wrote:
      &n= bsp; 
        >Our experience in the IETF over many y= ears is that economizing message
        >size and comprom= ising utility and security in search of efficiency of
       = >implementation on small devices is a poor trade off.  I am not ad= vocating
        >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 reas= onable.
        >
        >Brian (as indi= vidual)
        >
        >
     &nbs= p;  >
        > -----Original Message-----
    &nbs= p;   >From:  Peter Stanforth [mailto:pete= r@spectrumbridge.com]
        >Sent:  Satu= rday, August 11, 2012 07:13 AM Eastern Standard Time
        = >To:    Teco Boot; Benjamin A.Rolfe
        >= Cc:    paws@ietf.org
        &= gt;Subject:      Re: [paws] XML schema versus JSON, vCard &a= mp; iCal
        >
        >Not all maste= rs run over the core network.
        >Some of the Use cas= es have a master talking to another OTA
        >We should= not assume that all Masters are attached to utility power so we
     &= nbsp;  >should be sympathetic to processing energy use also.
    &nb= sp;   >
        >On SatAug/11/12 Sat Aug 11, = 5:30 AM, "Teco Boot" <teco@inf-net.nl> wr= ote:
        >
        >>
     &nb= sp;  >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe het vol= gende
        >>geschreven:
        >&= gt;
        >>> Compactness of messages is important= , but it is also important (to me
        >>>at leas= t) to be realizable in an implementation with limited resources,
     &= nbsp;  >>>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,
      &n= bsp; >>>but may have a very compact, simple stack and applications= (i.e.  no
        >>>browser).  Is JSON t= ypically implemented when there is no browser?
        >&g= t;>Would it be hard to do in a resource constrained device (i.e. where w= e
        >>>talk about memory size in Kilo-bytes st= ill).
        >>
        >>In use c= ases and requirements document, there are no requirements for
     &nbs= p;  >>protocol performance. I guess OS/IP/TCP/TLS code size supe= rsedes needs
        >>for JSON or XML.
      =   >>
        >>Same for timing: TCP/TLS conn= ection setup will take more than the PAWS
        >>mes= sage exchange, I think. This may be of importance when using satcom
    &nbs= p;   >>links.
        >>
      = ;  >>Because PAWS runs between master and database, over core ne= twork,
        >>performance is not our primary concern= . But as always, it is good to keep
        >>an eye on= efficiency.
        >>
        >>T= eco
        >>
        >>> Thank= s
        >>> Ben
        >>>=
        >>>
        >>>> = We had a discussion on XML vs. JSON. I prefer the one with most
     &n= bsp;  >>>>compact messages.
        >>= >>
        >>>> On vCard and JSON: what is = the status of "A JavaScript Object Notation
        >= >>>(JSON) Representation for vCard"?
        &g= t;>>> http://tools.iet= f.org/html/draft-bhat-vcarddav-json-00
        >= ;>>>
        >>>> On valid times: can we= use same format as certificates? They have
        >>&= gt;>similar simple requirements: valid notBefore&  notAfter.    >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
     &n= bsp;  >>>>
        >>>> Teco
    =     >>>> _______________________________________= ________
        >>>> paws mailing list
     =    >>>> paws@ietf.org
     =    >>>> https://www.i= etf.org/mailman/listinfo/paws
        >>>= >
        >>>
        >>> = _______________________________________________
        >&= gt;> paws mailing list
        >>> pa= ws@ietf.org
        >>> https://www.ietf.org/mailman/listinfo/paws
    &nb= sp;   >>
        >>____________________= ___________________________
        >>paws mailing list=
        >>paws@ietf.org
      = ;  >>https://www.ietf.org/mailman/lis= tinfo/paws
        >
        >= _______________________________________________
        >p= aws mailing list
        >paws@ietf.org    >https://www.ietf.org/mai= lman/listinfo/paws
        
      &n= bsp; _______________________________________________
        = paws mailing list
        paws@ietf.org<= br>    https://www.ietf.org/= mailman/listinfo/paws
        



    -- 
    -vince

    ____________________________________________= ___
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws
    _____= __________________________________________
    paws mailing list
    pa= ws@ietf.org
    https://www.ietf.org/m= ailman/listinfo/paws



     

    -- 
    -vince

    <= /div>
     
     
    _______________________________________________
    paw=
s mailing list
    paws@ietf.org
    https://www.ietf.org/mailman/listi=
nfo/paws

     

    _______________________________________________
    paws mailing li= st
    paws@ietf.org<= br>https://www.ietf.org/mailman/listinfo/paws

    =

    =  

      =
;
    _______________________________________________=

    paws mailing list
    paws@ietf.org
    https:=
//www.ietf.org/mailman/listinfo/paws

     

    ________= _______________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf= .org/mailman/listinfo/paws

     

     

     <= /p>


    _______________________________________________
    paws maili= ng list
    paws@ietf.org=
    https://www.ietf.org/mailman/listinfo/paws

    =


    _______________________________________________
    paws ma= iling list
    paws@ietf.org
    https://w= ww.ietf.org/mailman/listinfo/paws



     = ;

    --
    -vince

    = --_000_7BAC95F5A7E67643AAFB2C31BEE662D015E44DE391SCVEXCH2marve_-- From horvitz@volny.cz Tue Aug 28 03:28:47 2012 Return-Path: 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 1369511E8108 for ; Tue, 28 Aug 2012 03:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 j987BJO5E8VS for ; Tue, 28 Aug 2012 03:28:46 -0700 (PDT) Received: from mxout.volny.cz (mxout.volny.cz [62.44.29.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7AD11E8107 for ; Tue, 28 Aug 2012 03:28:44 -0700 (PDT) Received: from webmail1.volny.internal (webmail1.volny.internal [172.20.100.61]) by mxout.volny.cz (Postfix) with ESMTP id 0DAD71E0DBA for ; Tue, 28 Aug 2012 12:28:43 +0200 (CEST) Received: by webmail1.volny.internal (Postfix, from userid 48) id 0CE07160A05; Tue, 28 Aug 2012 12:28:43 +0200 (CEST) Received: from 93-137-177-130.adsl.net.t-com.hr (93-137-177-130.adsl.net.t-com.hr [93.137.177.130]) by mail1.volny.cz (mail1.volny.cz [172.20.100.61]) with HTTP; Tue, 28 Aug 2012 12:28:43 +0200 (CEST) MIME-Version: 1.0 From: horvitz@volny.cz X-Originating-Account: horvitz/volny.cz To: paws@ietf.org Date: Tue, 28 Aug 2012 12:28:42 +0200 (CEST) Message-ID: <61e7d828b455398bb41ef60fda7ce0ba@mail1.volny.cz> X-Mailer: Volny.cz Webmail2 2.147 X-Originating-Ip: 93.137.177.130 X-Originating-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.83 Safari/537.1 X-Webmail2-Origin: horvitz/volny.cz [93.137.177.130] X-Originating-X-Forwarded-For: 93.137.177.130 X-Priority: 3 In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [paws] =?iso-8859-2?q?European_geolocation_database_test_licenses?= =?iso-8859-2?q?_before_Fairspectrum=27s?= X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 10:28:47 -0000 Peter Stanforth, CTO of Spectrum Bridge Inc. in Florida, sent a message challenging Fairspectrum's release about yesterday's issuing of a white space database test license for part of Finland, which had been claimed as the first in Europe. Mr. Sanforth wrote: "We applied for, and were awarded, an experimental license to conduct white space trials by the Finnish regulators in 2010, I still have the license on my wall. We actually published a joint report with Nokia on the results. Which was used as input into [the Cambridge Consortium's white space tests last spring]. Cambridge was run under a regulatory experimental license. Technically issued by Arquiva but approval by Ofcom was required and, in terms of size and scope I think it has a much better claim to be first in Europe, for which Microsoft should get the credit." Surely FICORA had records about the earlier license so Fairspectrum and Nokia should have been aware of it, too. >BOB< ----- ORIGINAL MESSAGE ----- From: horvitz@volny.cz To: paws@ietf.org Subject: [paws] Finland issues Europe's first TVWS geolocation database Date: 27.8.2012 - 23:24:43 > Today Finland's telecom regulator FICORA issued Europe's first geolocation database service test license for TV white spaces to Fairspectrum Oy. > > The license for database control of cognitive radios was issued 27 August to the Turku University of Applied Sciences. The license is valid for one year and covers the 470-790 MHz frequency range in a 40 x 40 km area surrounding Turku, Finland. Nearly 300 000 people live in the radio license area. The license will be used by the White Space Environment (WISE) test consortium. which consists of Nokia, Digita, Fairspectrum, Ficora, Turku University of Applied Sciences, University of Turku, and Aalto University. See the following link for Fairspectrum's press release: > > https://sites.google.com/a/fairspectrum.com/public/propagating-thoughts/pressreleasefairspectrumprovidestvwhitespacedatabaseforeurope%E2%80%99sfirstgeolocationradiolicense > > > > -- > Robert Horvitz > Stichting Open Spectrum > Slavikova 11, 120 00 Prague 2, Czech Republic > Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland > mailto:bob@openspectrum.info > http://www.openspectrum.info/ > mob: +420 775024705 > tel/fax: +420 222967456 > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- Robert Horvitz Stichting Open Spectrum Slavikova 11, 120 00 Prague 2, Czech Republic Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland mailto:bob@openspectrum.info http://www.openspectrum.info/ mob: +420 775024705 tel/fax: +420 222967456 From brian.rosen@neustar.biz Tue Aug 28 04:30:31 2012 Return-Path: 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 A1FB121F84FC for ; Tue, 28 Aug 2012 04:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.084 X-Spam-Level: X-Spam-Status: No, score=-6.084 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 pMRQlDKqI9hr for ; Tue, 28 Aug 2012 04:30:30 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4F721F84F3 for ; Tue, 28 Aug 2012 04:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1346153707; x=1661503463; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=2gDe6MI9qjdn2AOjYXmvp eatHIotGVMAFDq7ScFawWQ=; b=TrBybUAKzrPGfjaraCS9fRy1coXVQbEfyu7x3 c24Ncon68LN1NvmVbnPeTTzJcwKaqJnBmXEmSBMsGa1TmOosQ== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.13600469; Tue, 28 Aug 2012 07:35:06 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Tue, 28 Aug 2012 07:30:25 -0400 From: "Rosen, Brian" To: "'horvitz@volny.cz'" , "'paws@ietf.org'" Date: Tue, 28 Aug 2012 07:30:24 -0400 Thread-Topic: [paws] European geolocation database test licenses before Fairspectrum's Thread-Index: Ac2FCCXD9CgjgR7oRfm30+N4DmOolAACF5+I Message-ID: <55A5A9A87506CB4BA580BF9D531957DA690227C4@STNTEXCH01.cis.neustar.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: UrzC5fF/rdwW0FU01UsFzA== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [paws] European geolocation database test licenses before Fairspectrum's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 11:30:31 -0000 PGFzIGNoYWlyPgpUaGlzIHN1YmplY3QgaXNuJ3QgcmVsZXZhbnQgdG8gb3VyIHdvcmsuICBOZWl0 aGVyIHRoZSBvcmlnaW5hbCBhbm5vdW5jZW1lbnQsIG5vciB0aGUgZm9sbG93IHVwIGhhcyBhbnl0 aGluZyB0byBkbyB3aXRoIGRldmVsb3BtZW50IG9mIHByb3RvY29scyBmb3Igd2hpdGVzcGFjZS4g IEl0IGlzIG5vdCBhcHByb3ByaWF0ZSBmb3IgYW4gSUVURiBsaXN0LgoKQnJpYW4KCg0KDQogLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IAlob3J2aXR6QHZvbG55LmN6IFttYWlsdG86 aG9ydml0ekB2b2xueS5jel0NClNlbnQ6CVR1ZXNkYXksIEF1Z3VzdCAyOCwgMjAxMiAwNjozMCBB TSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNClRvOglwYXdzQGlldGYub3JnDQpTdWJqZWN0OglbcGF3 c10gRXVyb3BlYW4gZ2VvbG9jYXRpb24gZGF0YWJhc2UgdGVzdCBsaWNlbnNlcyBiZWZvcmUgRmFp cnNwZWN0cnVtJ3MNCg0KUGV0ZXIgU3RhbmZvcnRoLCBDVE8gb2YgU3BlY3RydW0gQnJpZGdlIElu Yy4gaW4gRmxvcmlkYSwgc2VudCBhIG1lc3NhZ2UgY2hhbGxlbmdpbmcgRmFpcnNwZWN0cnVtJ3Mg cmVsZWFzZSBhYm91dCB5ZXN0ZXJkYXkncyBpc3N1aW5nIG9mIGEgd2hpdGUgc3BhY2UgZGF0YWJh c2UgdGVzdCBsaWNlbnNlIGZvciBwYXJ0IG9mIEZpbmxhbmQsIHdoaWNoIGhhZCBiZWVuIGNsYWlt ZWQgYXMgdGhlIGZpcnN0IGluIEV1cm9wZS4gTXIuIFNhbmZvcnRoIHdyb3RlOg0KDQoiV2UgYXBw bGllZCBmb3IsIGFuZCB3ZXJlIGF3YXJkZWQsIGFuIGV4cGVyaW1lbnRhbCBsaWNlbnNlIHRvIGNv bmR1Y3Qgd2hpdGUgc3BhY2UgdHJpYWxzIGJ5IHRoZSBGaW5uaXNoIHJlZ3VsYXRvcnMgaW4gMjAx MCwgSSBzdGlsbCBoYXZlIHRoZSBsaWNlbnNlIG9uIG15IHdhbGwuIFdlIGFjdHVhbGx5IHB1Ymxp c2hlZCBhIGpvaW50IHJlcG9ydCB3aXRoIE5va2lhIG9uIHRoZSByZXN1bHRzLiBXaGljaCB3YXMg dXNlZCBhcyBpbnB1dCBpbnRvIFt0aGUgQ2FtYnJpZGdlIENvbnNvcnRpdW0ncyB3aGl0ZSBzcGFj ZSB0ZXN0cyBsYXN0IHNwcmluZ10uICBDYW1icmlkZ2Ugd2FzIHJ1biB1bmRlciBhIHJlZ3VsYXRv cnkgZXhwZXJpbWVudGFsIGxpY2Vuc2UuIFRlY2huaWNhbGx5IGlzc3VlZCBieSBBcnF1aXZhIGJ1 dCBhcHByb3ZhbCBieSBPZmNvbSB3YXMgcmVxdWlyZWQgYW5kLCBpbiB0ZXJtcyBvZiBzaXplIGFu ZCBzY29wZSBJIHRoaW5rIGl0IGhhcyBhIG11Y2ggYmV0dGVyIGNsYWltIHRvIGJlIGZpcnN0IGlu IEV1cm9wZSwgZm9yIHdoaWNoIE1pY3Jvc29mdCBzaG91bGQgZ2V0IHRoZSBjcmVkaXQuIg0KDQpT dXJlbHkgRklDT1JBIGhhZCByZWNvcmRzIGFib3V0IHRoZSBlYXJsaWVyIGxpY2Vuc2Ugc28gRmFp cnNwZWN0cnVtIGFuZCBOb2tpYSBzaG91bGQgaGF2ZSBiZWVuIGF3YXJlIG9mIGl0LCB0b28uDQoN Cj5CT0I8DQoNCi0tLS0tIE9SSUdJTkFMIE1FU1NBR0UgLS0tLS0NCkZyb206IGhvcnZpdHpAdm9s bnkuY3oNClRvOiBwYXdzQGlldGYub3JnDQpTdWJqZWN0OiBbcGF3c10gRmlubGFuZCBpc3N1ZXMg RXVyb3BlJ3MgZmlyc3QgVFZXUyBnZW9sb2NhdGlvbiBkYXRhYmFzZQ0KRGF0ZTogMjcuOC4yMDEy IC0gMjM6MjQ6NDMNCg0KPiBUb2RheSBGaW5sYW5kJ3MgdGVsZWNvbSByZWd1bGF0b3IgRklDT1JB IGlzc3VlZCBFdXJvcGUncyBmaXJzdCBnZW9sb2NhdGlvbiBkYXRhYmFzZSBzZXJ2aWNlIHRlc3Qg bGljZW5zZSBmb3IgVFYgd2hpdGUgc3BhY2VzIHRvIEZhaXJzcGVjdHJ1bSBPeS4NCj4gDQo+IFRo ZSBsaWNlbnNlIGZvciBkYXRhYmFzZSBjb250cm9sIG9mIGNvZ25pdGl2ZSByYWRpb3Mgd2FzIGlz c3VlZCAyNyBBdWd1c3QgdG8gdGhlIFR1cmt1IFVuaXZlcnNpdHkgb2YgQXBwbGllZCBTY2llbmNl cy4gVGhlIGxpY2Vuc2UgaXMgdmFsaWQgZm9yIG9uZSB5ZWFyIGFuZCBjb3ZlcnMgdGhlIDQ3MC03 OTAgTUh6IGZyZXF1ZW5jeSByYW5nZSBpbiBhIDQwIHggNDAga20gYXJlYSBzdXJyb3VuZGluZyBU dXJrdSwgRmlubGFuZC4gTmVhcmx5IDMwMCAwMDAgcGVvcGxlIGxpdmUgaW4gdGhlIHJhZGlvIGxp Y2Vuc2UgYXJlYS4gIFRoZSBsaWNlbnNlIHdpbGwgYmUgdXNlZCBieSB0aGUgV2hpdGUgU3BhY2Ug RW52aXJvbm1lbnQgKFdJU0UpIHRlc3QgY29uc29ydGl1bS4gd2hpY2ggY29uc2lzdHMgb2YgTm9r aWEsIERpZ2l0YSwgRmFpcnNwZWN0cnVtLCBGaWNvcmEsIFR1cmt1IFVuaXZlcnNpdHkgb2YgQXBw bGllZCBTY2llbmNlcywgVW5pdmVyc2l0eSBvZiBUdXJrdSwgYW5kIEFhbHRvIFVuaXZlcnNpdHku ICBTZWUgdGhlIGZvbGxvd2luZyBsaW5rIGZvciBGYWlyc3BlY3RydW0ncyBwcmVzcyByZWxlYXNl Og0KPiANCj4gaHR0cHM6Ly9zaXRlcy5nb29nbGUuY29tL2EvZmFpcnNwZWN0cnVtLmNvbS9wdWJs aWMvcHJvcGFnYXRpbmctdGhvdWdodHMvcHJlc3NyZWxlYXNlZmFpcnNwZWN0cnVtcHJvdmlkZXN0 dndoaXRlc3BhY2VkYXRhYmFzZWZvcmV1cm9wZSVFMiU4MCU5OXNmaXJzdGdlb2xvY2F0aW9ucmFk aW9saWNlbnNlDQo+IA0KPiANCj4gDQo+IC0tIA0KPiBSb2JlcnQgSG9ydml0eg0KPiBTdGljaHRp bmcgT3BlbiBTcGVjdHJ1bQ0KPiBTbGF2aWtvdmEgMTEsIDEyMCAwMCBQcmFndWUgMiwgQ3plY2gg UmVwdWJsaWMNCj4gR2VsZGVybGFuZHBsZWluIDc1IEwsIDEwODIgTFYgQW1zdGVyZGFtLCBOZWRl cmxhbmQNCj4gbWFpbHRvOmJvYkBvcGVuc3BlY3RydW0uaW5mbw0KPiBodHRwOi8vd3d3Lm9wZW5z cGVjdHJ1bS5pbmZvLw0KPiBtb2I6ICs0MjAgNzc1MDI0NzA1DQo+IHRlbC9mYXg6ICs0MjAgMjIy OTY3NDU2DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4gcGF3c0BpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gDQoNCi0tIA0KUm9iZXJ0IEhv cnZpdHoNClN0aWNodGluZyBPcGVuIFNwZWN0cnVtDQpTbGF2aWtvdmEgMTEsIDEyMCAwMCBQcmFn dWUgMiwgQ3plY2ggUmVwdWJsaWMNCkdlbGRlcmxhbmRwbGVpbiA3NSBMLCAxMDgyIExWIEFtc3Rl cmRhbSwgTmVkZXJsYW5kDQptYWlsdG86Ym9iQG9wZW5zcGVjdHJ1bS5pbmZvDQpodHRwOi8vd3d3 Lm9wZW5zcGVjdHJ1bS5pbmZvLw0KbW9iOiArNDIwIDc3NTAyNDcwNQ0KdGVsL2ZheDogKzQyMCAy MjI5Njc0NTYNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KcGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0K From internet-drafts@ietf.org Wed Aug 29 08:40:05 2012 Return-Path: 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 CF4BB21F86E1; Wed, 29 Aug 2012 08:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] 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 FSAr1YoMIPYG; Wed, 29 Aug 2012 08:40:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350B221F8621; Wed, 29 Aug 2012 08:40:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120829154005.21927.10198.idtracker@ietfa.amsl.com> Date: Wed, 29 Aug 2012 08:40:05 -0700 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-07.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 15:40:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol to Access WS database Working Gr= oup of the IETF. Title : Protocol to Access White Space database: PS, use cases a= nd rqmts Author(s) : Scott Probasco Basavaraj Patil Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-07.txt Pages : 42 Date : 2012-08-29 Abstract: Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes a number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol. The concept of TV white spaces is described including the problems that need to be addressed to enable white space spectrum for additional uses without causing interference to currently assigned use. Use of white space is enabled by querying a database which stores information about the channel availability at any given location and time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-rq= mts-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From scott.probasco@nokia.com Wed Aug 29 09:11:33 2012 Return-Path: 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 E442621F8606 for ; Wed, 29 Aug 2012 09:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 QSDIORjK50Uw for ; Wed, 29 Aug 2012 09:11:33 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB3821F8581 for ; Wed, 29 Aug 2012 09:11:32 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7TGAwSk010889 for ; Wed, 29 Aug 2012 19:11:28 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Aug 2012 19:10:58 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.192]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0309.003; Wed, 29 Aug 2012 18:10:57 +0200 From: To: Thread-Topic: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-07.txt Thread-Index: AQHNhgDfm9DC1+YSUEeU8fgPCUcYyA== Date: Wed, 29 Aug 2012 16:10:57 +0000 Message-ID: In-Reply-To: <20120829154005.21927.10198.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [50.11.3.60] Content-Type: text/plain; charset="us-ascii" Content-ID: <2FD6C0C33BD3DB4B82132545DC4EDBF6@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Aug 2012 16:10:58.0884 (UTC) FILETIME=[E0897840:01CD8600] X-Nokia-AV: Clean Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-07.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 16:11:34 -0000 Hi All, This update reflects the discussion and comments from the mail list regarding the reference to Ofcom's requirements and to Data Model requirement D.7. Thanks for the good discussion, the document should now be ready for submission to the IESG. Kind Regards, Scott & Raj On 8/29/12 10:40 AM, "ext internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Protocol to Access WS database Working >Group of the IETF. > > Title : Protocol to Access White Space database: PS, use >cases and rqmts > Author(s) : Scott Probasco > Basavaraj Patil > Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-07.txt > Pages : 42 > Date : 2012-08-29 > >Abstract: > Portions of the radio spectrum that are assigned to a particular use > but are unused or unoccupied at specific locations and times are > defined as "white space". The concept of allowing additional > transmissions (which may or may not be licensed) in white space is a > technique to "unlock" existing spectrum for new use. An obvious > requirement is that these additional transmissions do not interfere > with the assigned use of the spectrum. One approach to using the > white space spectrum at a given time and location is to verify with a > database for available channels. > > This document describes a number of possible use cases of white space > spectrum and technology as well as a set of requirements for the > database query protocol. The concept of TV white spaces is described > including the problems that need to be addressed to enable white > space spectrum for additional uses without causing interference to > currently assigned use. Use of white space is enabled by querying a > database which stores information about the channel availability at > any given location and time. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqm >ts > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-07 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-r= qm >ts-07 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Wed Aug 29 09:21:10 2012 Return-Path: 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 0487F11E80E5 for ; Wed, 29 Aug 2012 09:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.002 X-Spam-Level: X-Spam-Status: No, score=-106.002 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 aSRuDeTQYRbf for ; Wed, 29 Aug 2012 09:21:09 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 374F111E80CC for ; Wed, 29 Aug 2012 09:21:09 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7TGKwco019388; Wed, 29 Aug 2012 19:21:01 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Aug 2012 19:20:58 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0309.003; Wed, 29 Aug 2012 18:20:57 +0200 From: To: Thread-Topic: Request to submit UC&R I-D to IESG... Thread-Index: AQHNhgJFi2g6E545REORDwmkr5MRqg== Date: Wed, 29 Aug 2012 16:20:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [72.64.105.77] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Aug 2012 16:20:58.0692 (UTC) FILETIME=[460CE840:01CD8602] X-Nokia-AV: Clean Cc: paws-chairs@tools.ietf.org Subject: [paws] Request to submit UC&R I-D to IESG... X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 16:21:10 -0000 The discussion in the WG has shifted to the details about the PAWS protocol. The use case and requirements I-D has been updated to reflect the comments at the WG meeting at IETF84 and on the mailing list. The I-D is ready to be forwarded to the IESG for publication as an Informational RFC. We would like to request the chairs to submit the I-D to the IESG with the pro to writeup. - Raj and Scott From Gabor.Bajko@nokia.com Wed Aug 29 14:59:55 2012 Return-Path: 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 67BEC11E80F1 for ; Wed, 29 Aug 2012 14:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_21=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 YGMAan8XaCyo for ; Wed, 29 Aug 2012 14:59:54 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id C42D411E80F6 for ; Wed, 29 Aug 2012 14:59:54 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7TLxo8l025588; Thu, 30 Aug 2012 00:59:52 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Aug 2012 00:59:50 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0309.003; Wed, 29 Aug 2012 23:59:50 +0200 From: To: , Thread-Topic: Request to submit UC&R I-D to IESG... Thread-Index: AQHNhgJFi2g6E545REORDwmkr5MRqpdxVlpQ Date: Wed, 29 Aug 2012 21:59:48 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FF94F1@008-AM1MPN1-006.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Aug 2012 21:59:50.0908 (UTC) FILETIME=[9CFEDBC0:01CD8631] X-Nokia-AV: Clean Cc: paws-chairs@tools.ietf.org Subject: Re: [paws] Request to submit UC&R I-D to IESG... X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:59:55 -0000 Thanks to the editors for generating this new version of the draft. I will now go ahead and prepare the document writeup and send it to the ies= g. In the process of doing that, I have to ask each author and editor to confi= rm that any and all appropriate IPR disclosures required for full conforman= ce with the provisions of BCP 78 and BCP 79 have already been filed.=20 Thanks, Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Pat= il Basavaraj (Nokia-CIC/Dallas) Sent: Wednesday, August 29, 2012 9:21 AM To: paws@ietf.org Cc: paws-chairs@tools.ietf.org Subject: [paws] Request to submit UC&R I-D to IESG... The discussion in the WG has shifted to the details about the PAWS protocol= . The use case and requirements I-D has been updated to reflect the comments = at the WG meeting at IETF84 and on the mailing list. The I-D is ready to be= forwarded to the IESG for publication as an Informational RFC. We would like to request the chairs to submit the I-D to the IESG with the = pro to writeup. - Raj and Scott _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Thu Aug 30 09:30:17 2012 Return-Path: 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 A33A921F851A for ; Thu, 30 Aug 2012 09:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.001 X-Spam-Level: X-Spam-Status: No, score=-106.001 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Bws-cK3KJkkH for ; Thu, 30 Aug 2012 09:30:17 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id BA34021F8518 for ; Thu, 30 Aug 2012 09:30:16 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7UGU2Ch000489; Thu, 30 Aug 2012 19:30:10 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Aug 2012 19:30:02 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.119]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0309.003; Thu, 30 Aug 2012 18:30:01 +0200 From: To: , Thread-Topic: Request to submit UC&R I-D to IESG... Thread-Index: AQHNhgJFi2g6E545REORDwmkr5MRqpdxVlpQgADB4QA= Date: Thu, 30 Aug 2012 16:30:00 +0000 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FF94F1@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [72.64.105.77] Content-Type: text/plain; charset="us-ascii" Content-ID: <8E43D08530575143B49336A00F850195@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Aug 2012 16:30:02.0625 (UTC) FILETIME=[B4AC3F10:01CD86CC] X-Nokia-AV: Clean Cc: paws-chairs@tools.ietf.org Subject: Re: [paws] Request to submit UC&R I-D to IESG... X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 16:30:17 -0000 As one of the authors of the UC&R I-D, I declare that the I-D is in full conformance of BCP 78 and 79. I have no IPRs associated with this I-D to disclose. -Raj On 8/29/12 4:59 PM, "Bajko Gabor (Nokia-CIC/SiliconValley)" wrote: >Thanks to the editors for generating this new version of the draft. >I will now go ahead and prepare the document writeup and send it to the >iesg. >In the process of doing that, I have to ask each author and editor to >confirm that any and all appropriate IPR disclosures required for full >conformance with the provisions of BCP 78 and BCP 79 have already been >filed.=20 > >Thanks, Gabor > > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >Patil Basavaraj (Nokia-CIC/Dallas) >Sent: Wednesday, August 29, 2012 9:21 AM >To: paws@ietf.org >Cc: paws-chairs@tools.ietf.org >Subject: [paws] Request to submit UC&R I-D to IESG... > > >The discussion in the WG has shifted to the details about the PAWS >protocol. >The use case and requirements I-D has been updated to reflect the >comments at the WG meeting at IETF84 and on the mailing list. The I-D is >ready to be forwarded to the IESG for publication as an Informational RFC. > >We would like to request the chairs to submit the I-D to the IESG with >the pro to writeup. > >- Raj and Scott > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From scott@probasco.me Thu Aug 30 10:55:00 2012 Return-Path: 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 05B6621F8599 for ; Thu, 30 Aug 2012 10:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 wKXiZaMQd5cQ for ; Thu, 30 Aug 2012 10:54:59 -0700 (PDT) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by ietfa.amsl.com (Postfix) with SMTP id 7A75B21F84F1 for ; Thu, 30 Aug 2012 10:54:59 -0700 (PDT) Received: (qmail 30812 invoked from network); 30 Aug 2012 17:54:58 -0000 Received: from unknown (50.11.3.60) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 30 Aug 2012 17:54:58 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Scott Probasco In-Reply-To: Date: Thu, 30 Aug 2012 12:54:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5FF0DC7D-E752-47AA-B32F-D6EB28E07711@probasco.me> References: To: paws@ietf.org, paws-chairs@tools.ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [paws] Request to submit UC&R I-D to IESG... X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 17:55:00 -0000 Hello, I confirm that I have no IPR associated with this I-D to disclose and = that this I-D is in full conformance with the provisions of BCP 78 and = BCP 79. Kind Regards, Scott On Aug 30, 2012, at 11:30 AM, wrote: >=20 > As one of the authors of the UC&R I-D, I declare that the I-D is in = full > conformance of BCP 78 and 79. >=20 > I have no IPRs associated with this I-D to disclose. >=20 > -Raj >=20 > On 8/29/12 4:59 PM, "Bajko Gabor (Nokia-CIC/SiliconValley)" > wrote: >=20 >> Thanks to the editors for generating this new version of the draft. >> I will now go ahead and prepare the document writeup and send it to = the >> iesg. >> In the process of doing that, I have to ask each author and editor to >> confirm that any and all appropriate IPR disclosures required for = full >> conformance with the provisions of BCP 78 and BCP 79 have already = been >> filed.=20 >>=20 >> Thanks, Gabor >>=20 >>=20 >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of >> Patil Basavaraj (Nokia-CIC/Dallas) >> Sent: Wednesday, August 29, 2012 9:21 AM >> To: paws@ietf.org >> Cc: paws-chairs@tools.ietf.org >> Subject: [paws] Request to submit UC&R I-D to IESG... >>=20 >>=20 >> The discussion in the WG has shifted to the details about the PAWS >> protocol. >> The use case and requirements I-D has been updated to reflect the >> comments at the WG meeting at IETF84 and on the mailing list. The I-D = is >> ready to be forwarded to the IESG for publication as an Informational = RFC. >>=20 >> We would like to request the chairs to submit the I-D to the IESG = with >> the pro to writeup. >>=20 >> - Raj and Scott >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From internet-drafts@ietf.org Thu Aug 30 14:58:27 2012 Return-Path: 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 DF92721F849A; Thu, 30 Aug 2012 14:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.324 X-Spam-Level: X-Spam-Status: No, score=-102.324 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] 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 pY2EatD9IUtO; Thu, 30 Aug 2012 14:58:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7600221F8493; Thu, 30 Aug 2012 14:58:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120830215827.2003.41089.idtracker@ietfa.amsl.com> Date: Thu, 30 Aug 2012 14:58:27 -0700 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-08.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 21:58:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol to Access WS database Working Gr= oup of the IETF. Title : Protocol to Access White Space database: PS, use cases a= nd rqmts Author(s) : Scott Probasco Basavaraj Patil Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-08.txt Pages : 42 Date : 2012-08-30 Abstract: Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes a number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol. The concept of TV white spaces is described including the problems that need to be addressed to enable white space spectrum for additional uses without causing interference to currently assigned use. Use of white space is enabled by querying a database which stores information about the channel availability at any given location and time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-rq= mts-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From scott@probasco.me Thu Aug 30 15:01:39 2012 Return-Path: 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 C780021F8498 for ; Thu, 30 Aug 2012 15:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 52WWah8nazmZ for ; Thu, 30 Aug 2012 15:01:39 -0700 (PDT) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by ietfa.amsl.com (Postfix) with SMTP id 3FDAF21F8491 for ; Thu, 30 Aug 2012 15:01:39 -0700 (PDT) Received: (qmail 22507 invoked from network); 30 Aug 2012 22:01:38 -0000 Received: from unknown (50.11.3.60) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 30 Aug 2012 22:01:36 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Scott Probasco In-Reply-To: <20120830215827.2003.41089.idtracker@ietfa.amsl.com> Date: Thu, 30 Aug 2012 17:01:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <55EFA6B7-A9D5-4B57-9240-5BD9EA66629D@probasco.me> References: <20120830215827.2003.41089.idtracker@ietfa.amsl.com> To: paws@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-08.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 22:01:39 -0000 Hello All, This updated version -08 only contains editorial corrections that are = required to pass the IDNITS tool scan. Kind Regards, Scott & Raj On Aug 30, 2012, at 4:58 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Protocol to Access WS database = Working Group of the IETF. >=20 > Title : Protocol to Access White Space database: PS, = use cases and rqmts > Author(s) : Scott Probasco > Basavaraj Patil > Filename : = draft-ietf-paws-problem-stmt-usecases-rqmts-08.txt > Pages : 42 > Date : 2012-08-30 >=20 > Abstract: > Portions of the radio spectrum that are assigned to a particular use > but are unused or unoccupied at specific locations and times are > defined as "white space". The concept of allowing additional > transmissions (which may or may not be licensed) in white space is a > technique to "unlock" existing spectrum for new use. An obvious > requirement is that these additional transmissions do not interfere > with the assigned use of the spectrum. One approach to using the > white space spectrum at a given time and location is to verify with = a > database for available channels. >=20 > This document describes a number of possible use cases of white = space > spectrum and technology as well as a set of requirements for the > database query protocol. The concept of TV white spaces is = described > including the problems that need to be addressed to enable white > space spectrum for additional uses without causing interference to > currently assigned use. Use of white space is enabled by querying a > database which stores information about the channel availability at > any given location and time. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqm= ts >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-08 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-r= qmts-08 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Fri Aug 31 11:49:12 2012 Return-Path: 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 8873E21F855D; Fri, 31 Aug 2012 11:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 Vpb5nPMnVIIk; Fri, 31 Aug 2012 11:49:07 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6329F21F8554; Fri, 31 Aug 2012 11:49:07 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7VIn4H8026799; Fri, 31 Aug 2012 21:49:05 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 31 Aug 2012 21:49:03 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0309.003; Fri, 31 Aug 2012 20:48:51 +0200 From: To: , , Thread-Topic: document write-up for http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-08 Thread-Index: Ac2HqB7L2ZZB998RR2Gjt/ZolBdHeg== Date: Fri, 31 Aug 2012 18:48:50 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FF9FD3@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FF9FD3008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 31 Aug 2012 18:49:03.0984 (UTC) FILETIME=[4AEC5F00:01CD87A9] X-Nokia-AV: Clean Subject: [paws] document write-up for http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-08 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 18:49:12 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FF9FD3008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On behalf of the PAWS WG, I request publication of draft-ietf-paws-problem-= stmt-usecases-rqmts-08 as Informational RFC. As required by RFC 4858, current Document Shepherd Write-Up per latest format at http://www.ietf.org/IESG/content/Doc-Writeup.html. Document Shepherd Write-Up for draft-ietf-paws-problem-stmt-usecases-rqmts-= 08: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet= Standard, Informational, Experimental, or Historic)? Why is this the prope= r type of RFC? Is this type of RFC indicated in the title page header? =3D=3D> Informational, as indicated in the title page. The document describ= es potential use cases for TV White Space spectrum and summarizes the Requi= rements of the protocol a White Space device has to use to get access to th= e spectrum. Requirements were derived from the rules Regulators have adopte= d for White Space functionality. (2) The IESG approval announcement includes a Document Announcement Write-U= p. Please provide such a Document Announcement Write-Up. Recent examples ca= n be found in the "Action" announcements for approved documents. The approv= al announcement contains the following sections: Technical Summary: =3D=3D> The document describes a number of possible use cases of white spac= e spectrum and technology as well as a set of requirements for the database query protocol. The concept of TV white spaces is described including the problems that need to be addressed to enable white space spectrum for additional uses without causing interference to currently assigned use. Working Group Summary: Was there anything in WG process that is worth noting? For example, was the= re controversy about particular points or were there decisions where the co= nsensus was particularly rough? =3D=3D> Early on, there was slight disagreement on what the rules mean and = what requirements should be derived from them. Disagreements were resolved. Document Quality: Are there existing implementations of the protocol? Have a significant numb= er of vendors indicated their plan to implement the specification? Are ther= e any reviewers that merit special mention as having done a thorough review= , e.g., one that resulted in important changes or a conclusion that the doc= ument had no substantive issues? If there was a MIB Doctor, Media Type or o= ther expert review, what was its course (briefly)? In the case of a Media T= ype review, on what date was the request posted? =3D=3D> This document specifies only requirements, not the protocol, implem= entations are n/a. The document was reviewed by people who are familiar wit= h the rules Regulators adopted. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? =3D=3D> Document Shepherd is Gabor Bajko. Responsible AD is Pete Resnick. (3) Briefly describe the review of this document that was performed by the = Document Shepherd. If this version of the document is not ready for publica= tion, please explain why the document is being forwarded to the IESG. =3D=3D> The document went through 2 WGLCs, all issues raised on the list we= re resolved. (4) Does the document Shepherd have any concerns about the depth or breadth= of the reviews that have been performed? =3D=3D> No concerns. (5) Do portions of the document need review from a particular or from broad= er perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML= , or internationalization? If so, describe the review that took place. =3D=3D> No broader review is seen necessary by the document shepherd. (6) Describe any specific concerns or issues that the Document Shepherd has= with this document that the Responsible Area Director and/or the IESG shou= ld be aware of? For example, perhaps he or she is uncomfortable with certai= n parts of the document, or has concerns whether there really is a need for= it. In any event, if the WG has discussed those issues and has indicated t= hat it still wishes to advance the document, detail those concerns here. =3D=3D> No issues or concerns with the document. (7) Has each author confirmed that any and all appropriate IPR disclosures = required for full conformance with the provisions of BCP 78 and BCP 79 have= already been filed. If not, explain why? =3D=3D> There are two authors, and they both confirmed that the document is= in full conformance of BCP 78 and 79 and they have no IPRs to disclose. (8) Has an IPR disclosure been filed that references this document? If so, = summarize any WG discussion and conclusion regarding the IPR disclosures. =3D=3D> Yes, there is an IPR disclosure, filed against wg document version = -03 (not by the authors). The wg was made aware of the declaration, but it = had no issues with it, as the licensing terms were acceptable (royalty free= ). (9) How solid is the WG consensus behind this document? Does it represent t= he strong concurrence of a few individuals, with others being silent, or do= es the WG as a whole understand and agree with it? =3D=3D> The wg had intense discussions on the document, and all issues wer= e resolved. There seems to be very solid wg consensus on the document. (10) Has anyone threatened an appeal or otherwise indicated extreme discont= ent? If so, please summarise the areas of conflict in separate email messag= es to the Responsible Area Director. (It should be in a separate email beca= use this questionnaire is publicly available.) =3D=3D> No. (11) Identify any ID nits the Document Shepherd has found in this document.= (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).= Boilerplate checks are not enough; this check needs to be thorough. =3D=3D> No ID nits found in the document. (12) Describe how the document meets any required formal review criteria, s= uch as the MIB Doctor, media type, and URI type reviews. =3D=3D> The document doesn't define any MIB, media type or URI types, no ad= ditional formal reviews are seen necessary. (13) Have all references within this document been identified as either nor= mative or informative? =3D=3D> yes. (14) Are there normative references to documents that are not ready for adv= ancement or are otherwise in an unclear state? If such normative references= exist, what is the plan for their completion? =3D=3D> no such normative references. (15) Are there downward normative references references (see RFC 3967)? If = so, list these downward references to support the Area Director in the Last= Call procedure. =3D=3D> no downward normative references in this document. (16) Will publication of this document change the status of any existing RF= Cs? Are those RFCs listed on the title page header, listed in the abstract,= and discussed in the introduction? If the RFCs are not listed in the Abstr= act and Introduction, explain why, and point to the part of the document wh= ere the relationship of this document to the other RFCs is discussed. If th= is information is not in the document, explain why the WG considers it unne= cessary. =3D=3D> No. (17) Describe the Document Shepherd's review of the IANA considerations sec= tion, especially with regard to its consistency with the body of the docume= nt. Confirm that all protocol extensions that the document makes are associ= ated with the appropriate reservations in IANA registries. Confirm that any= referenced IANA registries have been clearly identified. Confirm that newl= y created IANA registries include a detailed specification of the initial c= ontents for the registry, that allocations procedures for future registrati= ons are defined, and a reasonable name for the new registry has been sugges= ted (see RFC 5226). =3D=3D> this document has no requests to IANA. (18) List any new IANA registries that require Expert Review for future all= ocations. Provide any public guidance that the IESG would find useful in se= lecting the IANA Experts for these new registries. =3D=3D> no new IANA registries requested. (19) Describe reviews and automated checks performed by the Document Shephe= rd to validate sections of the document written in a formal language, such = as XML code, BNF rules, MIB definitions, etc. =3D=3D> there are no parts of the document written in a formal language. (end) --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FF9FD3008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    On behalf of the PAWS WG, I request publication of d= raft-ietf-paws-problem-stmt-usecases-rqmts-08

    as Informational RFC.

     

    As required by RFC 4858, current Document Shepherd W= rite-Up per 

    latest format at http://www.ietf.org/IESG/content/Doc-Writeup.html.

     

    Document Shepherd Write-Up for draft-ietf-paws-problem=
-stmt-usecases-rqmts-08: 

    (1)   What type of RFC is being requested (BCP, Proposed Standard, Internet = Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the t= itle page header?

    =3D=3D> Informational, as indicated in the title page. The document d= escribes potential use cases for TV White Space spectrum and summarizes the= Requirements of the protocol a White Space device has to use to get access= to the spectrum. Requirements were derived from the rules Regulators have adopted for White Space functionality.=

    (2) The IESG approval announcement includes a Document Announcement Writ= e-Up. Please provide such a Document Announcement Write-Up. Recent examples= can be found in the "Action" announcements for approved document= s. The approval announcement contains the following sections:

    Technical Summary:

    =3D=3D> The document describes a number of possib= le use cases of white space

       spectrum and technology as well as a se= t of requirements for the

       database query protocol.  The conc= ept of TV white spaces is described

       including the problems that need to be = addressed to enable white

       space spectrum for additional uses with= out causing interference to

       currently assigned use.

     

    Working Group Summary:

    Was there anything in WG process that is wo= rth noting? For example, was there controversy about particular points or w= ere there decisions where the consensus was particularly rough?<= /p>

    =3D=3D> Early on, there was slight disagreement on what the rules mea= n and what requirements should be derived from them. Disagreements were res= olved.

    Document Quality:

    Are there existing implementations of the p= rotocol? Have a significant number of vendors indicated their plan to imple= ment the specification? Are there any reviewers that merit special mention = as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the docu= ment had no substantive issues? If there was a MIB Doctor, Media Type or ot= her expert review, what was its course (briefly)? In the case of a Media Ty= pe review, on what date was the request posted?

    =3D=3D> This document specifies only requirements, not the protocol, = implementations are n/a. The document was reviewed by people who are famili= ar with the rules Regulators adopted.

    Personnel:

    Who is the Document Shepherd? Who is the Re= sponsible Area Director?

    =3D=3D> Document Shepherd is Gabor Bajko. Responsible AD is Pete Resn= ick.

    (3) Briefly describe the review of this document that was performed by t= he Document Shepherd. If this version of the document is not ready for publ= ication, please explain why the document is being forwarded to the IESG.

    =3D=3D> The document went through 2 WGLCs, all issues raised on the l= ist were resolved.

    (4) Does the document Shepherd have any concerns about the depth or brea= dth of the reviews that have been performed?

    =3D=3D> No concerns.

    (5) Do portions of the document need review from a particular or from br= oader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, = XML, or internationalization? If so, describe the review that took place.

    =3D=3D> No broader review is seen necessary by the document shepherd.=

    (6) Describe any specific concerns or issues that the Document Shepherd = has with this document that the Responsible Area Director and/or the IESG s= hould be aware of? For example, perhaps he or she is uncomfortable with cer= tain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG ha= s discussed those issues and has indicated that it still wishes to advance = the document, detail those concerns here.

    =3D=3D> No issues or concerns with the document.

    (7) Has each author confirmed that any and all appropriate IPR disclosur= es required for full conformance with the provisions of BCP 78 and BCP 79 h= ave already been filed. If not, explain why?

    =3D=3D> There are two authors, and they both confirmed that the docum= ent is in full conformance of BCP 78 and 79 and they have no IPRs to disclo= se.

    (8) Has an IPR disclosure been filed that references this document? If s= o, summarize any WG discussion and conclusion regarding the IPR disclosures= .

    =3D=3D> Yes, there is an IPR disclosure, filed against wg document ve= rsion -03 (not by the authors). The wg was made aware of the declaration, but = it had no issues with it, as the licensing terms were acceptable (royalty f= ree).

    (9) How solid is the WG consensus behind this document? Does it represen= t the strong concurrence of a few individuals, with others being silent, or= does the WG as a whole understand and agree with it?

    =3D=3D> The wg had  intense discussions on the document, and all= issues were resolved. There seems to be very solid wg consensus on the doc= ument.

    (10) Has anyone threatened an appeal or otherwise indicated extreme disc= ontent? If so, please summarise the areas of conflict in separate email mes= sages to the Responsible Area Director. (It should be in a separate email b= ecause this questionnaire is publicly available.)

    =3D=3D> No.

    (11) Identify any ID nits the Document Shepherd has found in this docume= nt. (See http://www.ietf.= org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this ch= eck needs to be thorough.

    =3D=3D>  No ID nits found in the document.

    (12) Describe how the document meets any required formal review criteria= , such as the MIB Doctor, media type, and URI type reviews.

    =3D=3D> The document doesn’t define any MIB, media type or URI = types, no additional formal reviews are seen necessary.

    (13) Have all references within this document been identified as either = normative or informative?

    =3D=3D> yes.

    (14) Are there normative references to documents that are not ready for = advancement or are otherwise in an unclear state? If such normative referen= ces exist, what is the plan for their completion?

    =3D=3D> no such normative references.

    (15) Are there downward normative references references (see RFC 3967)? = If so, list these downward references to support the Area Director in the L= ast Call procedure.

    =3D=3D> no downward normative references in this document.=

    (16) Will publication of this document change the status of any existing= RFCs? Are those RFCs listed on the title page header, listed in the abstra= ct, and discussed in the introduction? If the RFCs are not listed in the Ab= stract and Introduction, explain why, and point to the part of the document where the relationship of this = document to the other RFCs is discussed. If this information is not in the = document, explain why the WG considers it unnecessary.

    =3D=3D> No.

    (17) Describe the Document Shepherd's review of the IANA considerations = section, especially with regard to its consistency with the body of the doc= ument. Confirm that all protocol extensions that the document makes are ass= ociated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been = clearly identified. Confirm that newly created IANA registries include a de= tailed specification of the initial contents for the registry, that allocat= ions procedures for future registrations are defined, and a reasonable name for the new registry has been suggested= (see RFC 5226).

    =3D=3D> this document has no requests to IANA.

    (18) List any new IANA registries that require Expert Review for future = allocations. Provide any public guidance that the IESG would find useful in= selecting the IANA Experts for these new registries.

    =3D=3D> no new IANA registries requested.

    (19) Describe reviews and automated checks performed by the Document She= pherd to validate sections of the document written in a formal language, su= ch as XML code, BNF rules, MIB definitions, etc.

    =3D=3D> there are no parts of the do= cument written in a formal language.

     <= /p>

    (end)

     

    --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FF9FD3008AM1MPN1006mg_-- From Gabor.Bajko@nokia.com Fri Aug 31 19:54:10 2012 Return-Path: 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 D268A21F845F for ; Fri, 31 Aug 2012 19:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 KA3b4NY-O4Ys for ; Fri, 31 Aug 2012 19:54:08 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED0C21F845D for ; Fri, 31 Aug 2012 19:54:08 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q812s4Bm014755 for ; Sat, 1 Sep 2012 05:54:05 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 1 Sep 2012 05:54:04 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0309.003; Sat, 1 Sep 2012 04:54:03 +0200 From: To: Thread-Topic: moving forward ... Thread-Index: Ac2HwkJWcIdKbSRIRNSbYF3PrBfyvgAKkPQA Date: Sat, 1 Sep 2012 02:54:02 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FFA162@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FFA162008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 01 Sep 2012 02:54:04.0737 (UTC) FILETIME=[0C52E310:01CD87ED] X-Nokia-AV: Clean Subject: [paws] moving forward ... X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 02:54:10 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FFA162008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We had lots of discussions on the list since the Vancouver F2F, with mixed = results. The chairs feel that it is time to move forward one way or the oth= er. We think the best way forward is to appoint an editor who will merge the no= n-controversial parts of the currently available two individual submissions= , draft-das and draft-wei, including the agreements we have made so far on = the list, with the intent to create a document for wg adoption. Vincent Che= n has volunteered to take the very rewarding job of editor. Here's a summary of what we have agreed so far and what is non-controversia= l and should be included into the merged document: Intro, protocol description, protocol functionalities There was no objection to have a DB initialization message, no controversy = around the registration/ validation/query/reporting We also agreed that the Discovery process should result in discovering both= the URI of the DB and the regulatory domain. We have not agreed whether we= should include the discovery as part of this document or have a separate d= ocument. We have also not agreed what mechanisms to use for discovery, LoST= or the one in draft-Probasco. In my opinion, even if we use LoST, we'd nee= d a document describing how to do LoST server discovery and define a parame= ter to be used for conveying the regulatory domain. Ie, either way, we need= a document which describes these details (whether that document would stay= as a standalone or rolled into the base solution doc is a separate discuss= ion we could have). Any volunteer to generate such a document for the wg co= uld discuss? I propose the merged document to have a section on discovery and list at le= ast the above assumptions. We have not agreed on the encoding of the data elements. The chairs and the= AD will soon come up with a process to help us choose between JSON and XML= , unless we'll find good reasons to support and define both. For the time b= eing, I'll ask the editor to at least put together from the two documents a= list of parameters which we'll need to include into the protocol messages,= noting the little agreements we made, like using ISO8601 format. Regarding security, the proposals are to have the protocol be defined to ha= ndle both shared secrets and client certificates. Brian had a problem with = the shared secret, saying that if we choose to support shared secrets but d= o not define a provisioning mechanism, the iesg may not like it. Brian has = an AP to clarify this with the security experts within the iesg. Until this= point is clarified, the editor should include the certificate part and hav= e a placeholder for the shared secret part. Let's start with the above. I am hoping to have a merged document produced = by the editor in a relatively short period of time. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FFA162008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    We had lots of discussions on the list since the Van= couver F2F, with mixed results. The chairs feel that it is time to move for= ward one way or the other.

    We think the best way forward is to appoint an edito= r who will merge the non-controversial parts of the currently available two= individual submissions, draft-das and draft-wei, including the agreements = we have made so far on the list, with the intent to create a document for wg adoption. Vincent Chen has voluntee= red to take the very rewarding job of editor.

    Here’s a summary of what we have agreed so far= and what is non-controversial and should be included into the merged docum= ent:

    Intro, protocol description, protocol functionalitie= s

    There was no objection to have a DB initialization m= essage, no controversy around the registration/ validation/query/reporting<= o:p>

     

    We also agreed that the Discovery process should res= ult in discovering both the URI of the DB and the regulatory domain. We hav= e not agreed whether we should include the discovery as part of this docume= nt or have a separate document. We have also not agreed what mechanisms to use for discovery, LoST or the one= in draft-Probasco. In my opinion, even if we use LoST, we’d need a d= ocument describing how to do LoST server discovery and define a parameter t= o be used for conveying the regulatory domain. Ie, either way, we need a document which describes these details (= whether that document would stay as a standalone or rolled into the base so= lution doc is a separate discussion we could have). Any volunteer to genera= te such a document for the wg could discuss?

    I propose the merged document to have a section on d= iscovery and list at least the above assumptions.

     

    We have not agreed on the encoding of the data eleme= nts. The chairs and the AD will soon come up with a process to help us choo= se between JSON and XML, unless we’ll find good reasons to support an= d define both. For the time being, I’ll ask the editor to at least put together from the two documents a list of p= arameters which we’ll need to include into the protocol messages, not= ing the little agreements we made, like using ISO8601 format.

     

    Regarding security, the proposals are to have the pr= otocol be defined to handle both shared secrets and client certificates. Br= ian had a problem with the shared secret, saying that if we choose to suppo= rt shared secrets but do not define a provisioning mechanism, the iesg may not like it. Brian has an AP to cla= rify this with the security experts within the iesg. Until this point is cl= arified, the editor should include the certificate part and have a placehol= der for the shared secret part.

     

    Let’s start with the above. I am hoping to hav= e a merged document produced by the editor in a relatively short period of = time.

     

    -     &= nbsp;    Gabor

     

     

     

     

    --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FFA162008AM1MPN1006mg_--