From internet-drafts@ietf.org Mon Mar 5 08:26:25 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CC421F8834; Mon, 5 Mar 2012 08:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, 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 C1Ec7C6O2OXS; Mon, 5 Mar 2012 08:26:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5A721F882E; Mon, 5 Mar 2012 08:26:22 -0800 (PST) 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.00 Message-ID: <20120305162622.12099.38754.idtracker@ietfa.amsl.com> Date: Mon, 05 Mar 2012 08:26:22 -0800 Cc: domainrep@ietf.org Subject: [domainrep] I-D Action: draft-ietf-repute-model-01.txt X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 16:26:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Reputation Services Working Group of = the IETF. Title : A Model for Reputation Reporting Author(s) : Nathaniel Borenstein Murray S. Kucherawy Andrew Sullivan Filename : draft-ietf-repute-model-01.txt Pages : 10 Date : 2012-03-05 This document describes a general architecture for a reputation-based service and a model for the exchange of reputation information on the Internet. The document roughly follows the recommendations of RFC4101 for describing a protocol model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-repute-model-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-repute-model-01.txt From ajs@anvilwalrusden.com Mon Mar 5 09:04:35 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C4721F8554 for ; Mon, 5 Mar 2012 09:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 6VyJdEgqMPSH for ; Mon, 5 Mar 2012 09:04:34 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0FC21F8455 for ; Mon, 5 Mar 2012 09:04:32 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E1EA71ECB41D for ; Mon, 5 Mar 2012 17:04:31 +0000 (UTC) Date: Mon, 5 Mar 2012 12:04:30 -0500 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20120305170429.GN76465@mail.yitter.info> References: <20120305162622.12099.38754.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120305162622.12099.38754.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [domainrep] I-D Action: draft-ietf-repute-model-01.txt X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 17:04:35 -0000 Dear colleagues, On Mon, Mar 05, 2012 at 08:26:22AM -0800, 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 Reputation Services Working Group of the IETF. > > Title : A Model for Reputation Reporting > Author(s) : Nathaniel Borenstein > Murray S. Kucherawy > Andrew Sullivan > Filename : draft-ietf-repute-model-01.txt > Pages : 10 > Date : 2012-03-05 The chairs and Murray (and by proxy, it appears, Nathaniel) have asked me to serve as editor for the -model draft. I received the aforementioned text and made no changes to it except to add my name as editor. I believe the text needs careful going over with a red pen, a cleanup of some references, and that's about it. Murphy willing, I'm planning to do some of that work in the next week before the deadline arrives, but if you think otherwise it would be very helpful to know as much. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Mon Mar 5 15:27:27 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F40D21E803A for ; Mon, 5 Mar 2012 15:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 WkdD3rip1qTM for ; Mon, 5 Mar 2012 15:27:26 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 485A921E802D for ; Mon, 5 Mar 2012 15:27:26 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Mon, 5 Mar 2012 15:27:25 -0800 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Thread-Topic: REPUTEing with JSON Thread-Index: Acz7J4VDrnVsR6E7QcWyDis1nxXIZA== Date: Mon, 5 Mar 2012 23:27:24 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807B472@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E00392807B472exchmbx901corpclo_" MIME-Version: 1.0 Subject: [domainrep] REPUTEing with JSON X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 23:27:27 -0000 --_000_9452079D1A51524AA5749AD23E00392807B472exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Hoping it would reveal some interesting issues for to continue the whole XM= L vs. JSON discussion, I recently converted my REPUTE implementation from X= ML to JSON. Unfortunately for the discussion, I hit no major snags. Both client and se= rver conversion took me an evening. The payload in both cases for a simple= REPUTE query is pretty small, though a little smaller in JSON. The code a= fter conversion is also a little simpler, but it could be argued that that'= s a function of the libraries I used to decode the payload and not of the f= ormats themselves. So, to me, there's not a clear winner. But that does l= eave me partial to JSON because the API I chose (jansson) leaves my applica= tion code cleaner. I am no expert in this area, so I have a question about schemas. I hear ab= out the idea of an XML schema a lot more than I hear one about a JSON schem= a. Is it the case that, in XML, one would typically run an XML document ag= ainst a schema to see if it matches before trying to extract values from it= ? Or is that optional? What about with JSON? If there's a web page someone can point me to that makes a comprehensive co= mparison of the two, that might be very helpful for us here (and, actually,= in WEIRDS too). -MSK --_000_9452079D1A51524AA5749AD23E00392807B472exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Hoping it would reveal some interesting issues for t= o continue the whole XML vs. JSON discussion, I recently converted my REPUT= E implementation from XML to JSON.

 

Unfortunately for the discussion, I hit no major sna= gs.  Both client and server conversion took me an evening.  The p= ayload in both cases for a simple REPUTE query is pretty small, though a li= ttle smaller in JSON.  The code after conversion is also a little simpler, but it could be argued that that’s a funct= ion of the libraries I used to decode the payload and not of the formats th= emselves.  So, to me, there’s not a clear winner.  But that= does leave me partial to JSON because the API I chose (jansson) leaves my application code cleaner.

 

I am no expert in this area, so I have a question ab= out schemas.  I hear about the idea of an XML schema a lot more than I= hear one about a JSON schema.  Is it the case that, in XML, one would= typically run an XML document against a schema to see if it matches before trying to extract values from it?  Or is = that optional?  What about with JSON?

 

If there’s a web page someone can point me to = that makes a comprehensive comparison of the two, that might be very helpfu= l for us here (and, actually, in WEIRDS too).

 

-MSK

--_000_9452079D1A51524AA5749AD23E00392807B472exchmbx901corpclo_-- From johnl@iecc.com Mon Mar 5 17:15:46 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E7321E807E for ; Mon, 5 Mar 2012 17:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.529 X-Spam-Level: X-Spam-Status: No, score=-110.529 tagged_above=-999 required=5 tests=[AWL=0.670, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 IxyWUBjgYxIh for ; Mon, 5 Mar 2012 17:15:46 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D060721E8061 for ; Mon, 5 Mar 2012 17:15:45 -0800 (PST) Received: (qmail 84255 invoked from network); 6 Mar 2012 01:15:45 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Mar 2012 01:15:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f556541.xn--btvx9d.k1203; i=johnl@user.iecc.com; bh=2TCo4s2KMvzyJAIEZrpDcLPW7TcqMnRc2TlVOSaOqgM=; b=Ra4mN7X+M9cA5Wzx0qmaSOyumJo8Twp8l0vkFVAzhr//pPDlnvUfU6Um/5LeSOvBFic89f8QgQQ27SkSHQJagRxm1NHa8MxDO+5s/Knk4uF45UvvTlIlCf0nuaOwJp4mzsi9/Kb5OVaClDl3yu10FRK6mnAfv5QWAMD/Y9kC2mc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 Mar 2012 01:15:23 -0000 Message-ID: <20120306011523.80765.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E00392807B472@exch-mbx901.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] REPUTEing with JSON X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 01:15:46 -0000 >I am no expert in this area, so I have a question about schemas. I hear about the idea of an XML schema a lot >more than I hear one about a JSON schema. Is it the case that, in XML, one would typically run an XML document >against a schema to see if it matches before trying to extract values from it? Or is that optional? What about >with JSON? In production, it's more likely that you would use the schema as a configuration file to tools that process the XML. In my experience, if you already know what the schema is, having a separate schema file isn't very helpful. R's, John From dfs@roaringpenguin.com Mon Mar 5 17:26:51 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0B321F867B for ; Mon, 5 Mar 2012 17:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.818 X-Spam-Level: X-Spam-Status: No, score=-3.818 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MISSING_HEADERS=1.292, 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 p+Cj6tT7CD-7 for ; Mon, 5 Mar 2012 17:26:50 -0800 (PST) Received: from colo3.roaringpenguin.com (roaringpenguin.com [70.38.112.54]) by ietfa.amsl.com (Postfix) with ESMTP id 44DF621F8678 for ; Mon, 5 Mar 2012 17:26:50 -0800 (PST) Received: from vanadium.roaringpenguin.com (vanadium.roaringpenguin.com [192.168.10.23]) by colo3.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id q261QmBZ016560 for ; Mon, 5 Mar 2012 20:26:48 -0500 Received: from shishi.roaringpenguin.com (dfs@shishi.roaringpenguin.com [192.168.2.3]) by vanadium.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id q261QkUw022599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 5 Mar 2012 20:26:48 -0500 Date: Mon, 5 Mar 2012 20:26:45 -0500 From: "David F. Skoll" Cc: "domainrep@ietf.org" Message-ID: <20120305202645.3d3ff6ba@shishi.roaringpenguin.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392807B472@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E00392807B472@exch-mbx901.corp.cloudmark.com> Organization: Roaring Penguin Software Inc. X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=roaringpenguin.com; h=date :from:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=beta; bh=q/jRR9A1JeH3 xBxbVWCJfPesluQ=; b=sHyEotVizQwohN3CEvUZ4/IfTddprf+j4YQHuuBRotSe Nnivj1iNk8SaoM+AE3USc5R6/4Heuc5HDSzpNRakYzMDsPVBunbuaBXGt04+ZB3y loxp6vKjP6ieY85Stjx4hxNeYHWA2ZmJIhyLWmi/uV0oBuL2i+FENDUAN8VBGJ0= X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.73 on 192.168.10.23 X-CanIt-Geo: No geolocation information available for 192.168.10.23 X-CanItPRO-Stream: outgoing (inherits from default) X-CanIt-Archive-Cluster: SQVyZJxqklY5buiWXYCN4T/BjiM X-CanIt-Archived-As: base/20120305 / 01GG1qMoL Subject: Re: [domainrep] REPUTEing with JSON X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 01:26:51 -0000 On Mon, 5 Mar 2012 23:27:24 +0000 "Murray S. Kucherawy" wrote: > Hoping it would reveal some interesting issues for to continue the > whole XML vs. JSON discussion, I recently converted my REPUTE > implementation from XML to JSON. It looks like a religious issue. Googling "JSON vs XML" yields plenty of religion. I liked the comment at http://ajaxian.com/archives/json-vs-xml-the-debate: "I believe that the most important thing to understand in the JSON and XML debate is that they are really fundamentally built for two distinct purposes. XML is built for giving semantic meaning two [sic] text within documents. JSON is built for data structures." I think REPUTE is exchanging data structures rather than text documents with semantic meaning and I find JSON easier to read than XML, so I'm mildly in favour of JSON. Human readability of the wire protocol is not required, of course, but if we are going to make it verbose by using something like XML, we might as well make it more human readable (and compact as a bonus.) Regards, David. From msk@cloudmark.com Mon Mar 5 21:14:14 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6328521E805F for ; Mon, 5 Mar 2012 21:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, 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 JaGDP4nks-sn for ; Mon, 5 Mar 2012 21:14:13 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id D905221E8047 for ; Mon, 5 Mar 2012 21:14:13 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 5 Mar 2012 21:14:13 -0800 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Thread-Topic: [domainrep] REPUTEing with JSON Thread-Index: Acz7J4VDrnVsR6E7QcWyDis1nxXIZAAUiOiAAAiPEZA= Date: Tue, 6 Mar 2012 05:14:12 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807C241@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E00392807B472@exch-mbx901.corp.cloudmark.com> <20120306011523.80765.qmail@joyce.lan> In-Reply-To: <20120306011523.80765.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [domainrep] REPUTEing with JSON X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 05:14:14 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQGllY2MuY29tXQ0KPiBTZW50OiBNb25kYXksIE1hcmNoIDA1LCAyMDEyIDU6MTUgUE0N Cj4gVG86IGRvbWFpbnJlcEBpZXRmLm9yZw0KPiBDYzogTXVycmF5IFMuIEt1Y2hlcmF3eQ0KPiBT dWJqZWN0OiBSZTogW2RvbWFpbnJlcF0gUkVQVVRFaW5nIHdpdGggSlNPTg0KPiANCj4gPkkgYW0g bm8gZXhwZXJ0IGluIHRoaXMgYXJlYSwgc28gSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgc2NoZW1h cy4gIEkNCj4gPmhlYXIgYWJvdXQgdGhlIGlkZWEgb2YgYW4gWE1MIHNjaGVtYSBhIGxvdCBtb3Jl IHRoYW4gSSBoZWFyIG9uZSBhYm91dCBhDQo+ID5KU09OIHNjaGVtYS4gIElzIGl0IHRoZSBjYXNl IHRoYXQsIGluIFhNTCwgb25lIHdvdWxkIHR5cGljYWxseSBydW4gYW4NCj4gPlhNTCBkb2N1bWVu dCBhZ2FpbnN0IGEgc2NoZW1hIHRvIHNlZSBpZiBpdCBtYXRjaGVzIGJlZm9yZSB0cnlpbmcgdG8N Cj4gZXh0cmFjdCB2YWx1ZXMgZnJvbSBpdD8gIE9yIGlzIHRoYXQgb3B0aW9uYWw/ICBXaGF0IGFi b3V0IHdpdGggSlNPTj8NCj4gDQo+IEluIHByb2R1Y3Rpb24sIGl0J3MgbW9yZSBsaWtlbHkgdGhh dCB5b3Ugd291bGQgdXNlIHRoZSBzY2hlbWEgYXMgYQ0KPiBjb25maWd1cmF0aW9uIGZpbGUgdG8g dG9vbHMgdGhhdCBwcm9jZXNzIHRoZSBYTUwuICBJbiBteSBleHBlcmllbmNlLCBpZg0KPiB5b3Ug YWxyZWFkeSBrbm93IHdoYXQgdGhlIHNjaGVtYSBpcywgaGF2aW5nIGEgc2VwYXJhdGUgc2NoZW1h IGZpbGUNCj4gaXNuJ3QgdmVyeSBoZWxwZnVsLg0KDQpJIGd1ZXNzIHdoYXQgSSdtIGVudmlzaW9u aW5nIGlzIGFuIEFQSSB0byB3aGljaCB5b3UgaGFuZCB0aGUgaW5wdXQgZG9jdW1lbnQgYW5kIGEg c2NoZW1hLiAgVGhlIEFQSSBjaGVja3MgdGhlIGlucHV0IGFnYWluc3QgdGhlIHNjaGVtYSBhbmQg aW1tZWRpYXRlbHkgdGhyb3dzIGFuIGV4Y2VwdGlvbiBpZiBpdCdzIG5vbi1jb21wbGlhbnQsIG90 aGVyd2lzZSBpdCBoYW5kcyB5b3UgdGhlIGRlY29kZWQgZG9jdW1lbnQgaW4gc29tZSBmb3JtIHRo YXQgeW91IGNhbiBhY2Nlc3Mgd2l0aG91dCBoYXZpbmcgdG8gcGFyc2UgaXQgeW91cnNlbGYgKGUu Zy4sIGFjY2Vzc29yIGZ1bmN0aW9ucyBhbmQgdGhlIGxpa2UpLg0KDQpJdCBzb3VuZHMgbGlrZSB3 aGF0IHlvdSdyZSBzYXlpbmcgaXMgdGhhdCB1c2VyIHRvb2xzIGFuZCBzdWNoIHRoaW5ncyB0aGF0 IG5lZWQgdG8gYmUgcGxpYWJsZSB0ZW5kIHRvIGhhdmUgc3VjaCBjYXBhYmlsaXRpZXMsIGJ1dCBu dXRzLWFuZC1ib2x0cyBjb21wb25lbnRzIGxpa2UgbWFpbCBmaWx0ZXJzIHRoYXQgYXJlIGZhaXJs eSByaWdpZCB0ZW5kIHRvIGRvIHRoZSBzY2hlbWEgZW5mb3JjZW1lbnQgcGllY2Ugb24gdGhlaXIg b3duLiAgSXMgdGhhdCBhYm91dCByaWdodD8NCg0KLU1TSw0K From msk@cloudmark.com Mon Mar 5 21:18:35 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BABF21E805F for ; Mon, 5 Mar 2012 21:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, 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 657bpkCHy88O for ; Mon, 5 Mar 2012 21:18:34 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCA521E804E for ; Mon, 5 Mar 2012 21:18:34 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Mon, 5 Mar 2012 21:18:29 -0800 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Thread-Topic: [domainrep] REPUTEing with JSON Thread-Index: Acz7J4VDrnVsR6E7QcWyDis1nxXIZAAU7oiAAAjP9dA= Date: Tue, 6 Mar 2012 05:18:29 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807C252@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E00392807B472@exch-mbx901.corp.cloudmark.com> <20120305202645.3d3ff6ba@shishi.roaringpenguin.com> In-Reply-To: <20120305202645.3d3ff6ba@shishi.roaringpenguin.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] REPUTEing with JSON X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 05:18:35 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of David F. Skoll > Sent: Monday, March 05, 2012 5:27 PM > Cc: domainrep@ietf.org > Subject: Re: [domainrep] REPUTEing with JSON >=20 > "I believe that the most important thing to understand in the JSON and > XML debate is that they are really fundamentally built for two distinct > purposes. XML is built for giving semantic meaning two [sic] text > within documents. JSON is built for data structures." >=20 > I think REPUTE is exchanging data structures rather than text documents > with semantic meaning and I find JSON easier to read than XML, so I'm > mildly in favour of JSON. Human readability of the wire protocol is > not required, of course, but if we are going to make it verbose by > using something like XML, we might as well make it more human readable > (and compact as a bonus.) I think my current leaning is that way too, but (as you can tell) that's no= t based on lengthy expertise in or experience of either one. Over in WEIRD= S we had a lot of discussion about baggage (namespaces?) that XML drags wit= h it that sounded onerous, but I also haven't run into it in this work yet = so maybe it's not so much of an issue for us. But really, I'm currently fine with either. For simple one-shot queries th= ere's some space savings and readability gains with JSON over XML, but it's= not such a huge burden either. The jansson API seems a little cleaner tha= n libxml2, but those are just the two I happened to pick. I don't want to push for JSON merely because it's the current hotness, howe= ver. But if it wins for other reasons, I'm in. -MSK From johnl@iecc.com Mon Mar 5 22:04:55 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A83C21E8045 for ; Mon, 5 Mar 2012 22:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.552 X-Spam-Level: X-Spam-Status: No, score=-110.552 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 m+H5I757B4SN for ; Mon, 5 Mar 2012 22:04:54 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A8F9D21F8627 for ; Mon, 5 Mar 2012 22:04:52 -0800 (PST) Received: (qmail 46966 invoked from network); 6 Mar 2012 06:04:50 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Mar 2012 06:04:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f55a902.xn--30v786c.k1203; i=johnl@user.iecc.com; bh=3z/0xDA0xJbDQDK7uJ6/fc0osGwfyJAr17f8uaXmp6I=; b=Y9E7dUfyMGS+4VlEHbO+nOBal+qu+mNkcnlS9SNlWLWBwwrEyJbVAOXnwmPP7HlNK+ApGkgEQVd+dAbVAoxNL/QPpLt+j57XgH25XLvgGDP4u1HKvC7Fgpp2DibDXgfPvCjry3T6Gr+dAxYd0XhaxcQKt/IiwtNkc3LzF7HhAwE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 Mar 2012 06:04:27 -0000 Message-ID: <20120306060427.90315.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E00392807C241@exch-mbx901.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] REPUTEing with JSON X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 06:04:55 -0000 > It sounds like what you're saying is that user tools and such things > that need to be pliable tend to have such capabilities, but > nuts-and-bolts components like mail filters that are fairly rigid tend > tend to do the schema enforcement piece on their own. Is that about right? I think so. If you take a look at my little DMARC report parser, it uses the perl module XML::Simple to slurp the entire XML into a tree of perl hashes and arrays. Since all XML fields have names, I can write expressions like $xml{'report_metadata'}->{'org_name'} to pick out a field at a specific place in the tree. That can get a bit piggy if you're parsing something big (although in an era when laptops have 4G of RAM, piggy is more a state of mind) so the usual approach is to register callbacks with your parser that fire when it parses particular tags, but that still isn't using a schema. Schemas are a lot more useful for syntax checking as you're creating the XML, such as in an XML editor like xxe. R's, John From msk@cloudmark.com Mon Mar 5 22:08:29 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BE721E8073 for ; Mon, 5 Mar 2012 22:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, 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 ivbZbOhrKLl6 for ; Mon, 5 Mar 2012 22:08:29 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 001DA21E8045 for ; Mon, 5 Mar 2012 22:08:28 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Mon, 5 Mar 2012 22:08:28 -0800 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Thread-Topic: [domainrep] REPUTEing with JSON Thread-Index: Acz7J4VDrnVsR6E7QcWyDis1nxXIZAAUiOiAAAiPEZAAAYlkgAAQqm4g Date: Tue, 6 Mar 2012 06:08:27 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807C2B8@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E00392807C241@exch-mbx901.corp.cloudmark.com> <20120306060427.90315.qmail@joyce.lan> In-Reply-To: <20120306060427.90315.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [domainrep] REPUTEing with JSON X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 06:08:29 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQGllY2MuY29tXQ0KPiBTZW50OiBNb25kYXksIE1hcmNoIDA1LCAyMDEyIDEwOjA0IFBN DQo+IFRvOiBkb21haW5yZXBAaWV0Zi5vcmcNCj4gQ2M6IE11cnJheSBTLiBLdWNoZXJhd3kNCj4g U3ViamVjdDogUmU6IFtkb21haW5yZXBdIFJFUFVURWluZyB3aXRoIEpTT04NCj4gDQo+IEkgdGhp bmsgc28uICBJZiB5b3UgdGFrZSBhIGxvb2sgYXQgbXkgbGl0dGxlIERNQVJDIHJlcG9ydCBwYXJz ZXIsIGl0DQo+IHVzZXMgdGhlIHBlcmwgbW9kdWxlIFhNTDo6U2ltcGxlIHRvIHNsdXJwIHRoZSBl bnRpcmUgWE1MIGludG8gYSB0cmVlIG9mDQo+IHBlcmwgaGFzaGVzIGFuZCBhcnJheXMuICBTaW5j ZSBhbGwgWE1MIGZpZWxkcyBoYXZlIG5hbWVzLCBJIGNhbiB3cml0ZQ0KPiBleHByZXNzaW9ucyBs aWtlICR4bWx7J3JlcG9ydF9tZXRhZGF0YSd9LT57J29yZ19uYW1lJ30gdG8gcGljayBvdXQgYQ0K PiBmaWVsZCBhdCBhIHNwZWNpZmljIHBsYWNlIGluIHRoZSB0cmVlLg0KDQpZZWFoLCB0aGF0J3Mg d2hhdCBsaWJ4bWwyIGRvZXMgYXMgd2VsbCwgdGhvdWdoIHdpdGggdGhlIG9idmlvdXMgQyBjb25z dHJhaW50cy4gIGphbnNzb24gaXMgdGhlIHNhbWUgdGhvdWdoIHlvdSBkb24ndCBoYXZlIGRpcmVj dCBhY2Nlc3MgdG8gdGhlIGRhdGEgc3RydWN0dXJlcyBidXQgcmF0aGVyIGFyZSBmb3JjZWQgdG8g dXNlIGFjY2Vzc29yIGZ1bmN0aW9ucywgd2hpY2ggSSB0aGluayBJIHByZWZlciB0byBjcmF3bGlu ZyBhIGRhdGEgc3RydWN0dXJlIG9uIG15IG93bi4NCg0KVGhhbmtzIGZvciB0aGUgaW5zaWdodC4N Cg0KLU1TSw0KDQo= From prvs=0412e3ca7f=steve.allam@trustsphere.com Tue Mar 6 00:12:18 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA6521E808C for ; Tue, 6 Mar 2012 00:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_COM=0.311] 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 KR9DP4KV08PG for ; Tue, 6 Mar 2012 00:12:18 -0800 (PST) Received: from st3.realmail-asp.co.uk (fe1.securerealmail.com [80.249.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id A83A621E8081 for ; Tue, 6 Mar 2012 00:12:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trustsphere.com; s=rmdkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=0JUyzN/mgk7HoMP7K9iMt54Z7vMyBs94cwd9DSzvRE8=; b=IlQ5Uk+kWOqGtdD8Yy00mHvoGMdF0v/eXCWc2T9KPs8SXO4sBR5RLc8QzrTJjs3McHF0GJOLZcrp8d0TiylqCC+LoUzhH5goWD2cPuV5tHaqJx3cM2hn3X58bF7a4B9TCrQUqPUbrixgZhGF/4lmSv/dYwD6oVJ+STMCKx16fcI=; Received: from [116.12.149.130] (helo=cgpro.boxsentry.com) by st3.realmail-asp.co.uk with esmtp id 1S4pVH-0008SA-TD for domainrep@ietf.org; Tue, 06 Mar 2012 08:12:15 +0000 Received: by cgpro.boxsentry.com (CommuniGate Pro PIPE 5.4.0) with PIPE id 1882157; Tue, 06 Mar 2012 16:12:09 +0800 Received: from [88.97.130.81] (account steve.allam@trustsphere.com HELO joe90.imhotek.com) by cgpro.boxsentry.com (CommuniGate Pro SMTP 5.4.0) with ESMTPSA id 1882155 for domainrep@ietf.org; Tue, 06 Mar 2012 16:11:58 +0800 Message-ID: <4F55C6B8.3060002@trustsphere.com> Date: Tue, 06 Mar 2012 08:11:36 +0000 From: Steve Allam User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <20120306060427.90315.qmail@joyce.lan> In-Reply-To: <20120306060427.90315.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RMR-rmalert: true X-LogiQ-query: 116.12.149.130/steve.allam@trustsphere.com/domainrep@ietf.org (error socket failure) X-RealMail-Category: UNKNOWN/UNKNOWN X-RealMail-Ref: UNKNOWN/str=0001.0A0B020B.4F55C6DF.0173,ss=1,re=0.000,fgs=0 X-RealMail-IWF: NO X-CTCH-SenderID: steve.allam@trustsphere.com X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-Total-Spam: 0 X-CTCH-SenderID-Total-Suspected: 0 Subject: Re: [domainrep] REPUTEing with JSON X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 08:12:18 -0000 On 03/06/2012 06:04 AM, John Levine wrote: >> It sounds like what you're saying is that user tools and such things >> that need to be pliable tend to have such capabilities, but >> nuts-and-bolts components like mail filters that are fairly rigid tend >> tend to do the schema enforcement piece on their own. Is that about right? > I think so. If you take a look at my little DMARC report parser, it > uses the perl module XML::Simple to slurp the entire XML into a tree > of perl hashes and arrays. Since all XML fields have names, I can > write expressions like $xml{'report_metadata'}->{'org_name'} to pick > out a field at a specific place in the tree. > > That can get a bit piggy if you're parsing something big (although in > an era when laptops have 4G of RAM, piggy is more a state of mind) so the > usual approach is to register callbacks with your parser that fire when > it parses particular tags, but that still isn't using a schema. > > Schemas are a lot more useful for syntax checking as you're creating > the XML, such as in an XML editor like xxe. > > R's, > John I'll second that - we use a schema file to validate an xml config file after upgrades, in case the upgrade did anything strange (it might be merging fields) and have a validate tool available in case users directly edit the config file and want to check it (using the schema). However, for the xml that gets passed back by out reputation query engine, we only have a schema to document the possibilities - it isn't used by the query engine that creates the xml, or used by the consumer (the connector that receives the answer) - although of course someone could write a consumer that checks it - the problem here is that when you are doing possibly thousands of queries per second, the overhead of checking the data structure is too high. Thus, between two machine tasks, the schema is essentially fixed and trusted. Note that our engine allows the querier to choose which output format it receives - either text (less data, proprietary format), HTML - in fact simply uses the HTTP result code to give a 'yes' or 'no', or XML - data + extra information. In theory, we could add a JSON option too. Personally, I hate XML because cpan installs too many packages to enable simple parsing of a text file for my liking (this really from my earlier work in embedded systems where each kb was valuable) - however, it does a job and its easily scanned by a human, for debugging. JSON we use also, to format internal message queue messages. In some way, we have used each depending on which interfaces the tools support. However, we chose XML for the result format for the human readability for debugging (Not saying you can't read JSON, but I guess its the difference between reading SMS speak and email..) Have you thought of allowing the engines to offer answers in both, and allowing the consumer to choose which type it wants (and thus also allowing the engine to state which it supports?) Regards, Steve From msk@cloudmark.com Tue Mar 6 00:35:15 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7000F21F867F for ; Tue, 6 Mar 2012 00:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, 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 gjvwXmkwSe3Q for ; Tue, 6 Mar 2012 00:35:14 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D5CC621F86A6 for ; Tue, 6 Mar 2012 00:35:14 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Tue, 6 Mar 2012 00:35:14 -0800 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Thread-Topic: [domainrep] REPUTEing with JSON Thread-Index: Acz7J4VDrnVsR6E7QcWyDis1nxXIZAAUiOiAAAiPEZAAAYlkgAAEcM8AABAVLLA= Date: Tue, 6 Mar 2012 08:35:13 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807C3FC@exch-mbx901.corp.cloudmark.com> References: <20120306060427.90315.qmail@joyce.lan> <4F55C6B8.3060002@trustsphere.com> In-Reply-To: <4F55C6B8.3060002@trustsphere.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] REPUTEing with JSON X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 08:35:15 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Steve Allam > Sent: Tuesday, March 06, 2012 12:12 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] REPUTEing with JSON Hi Steve, > However, for the xml that gets passed back by out reputation query > engine, we only have a schema to document the possibilities - it isn't > used by the query engine that creates the xml, or used by the consumer > (the connector that receives the answer) - although of course someone > could write a consumer that checks it - the problem here is that when > you are doing possibly thousands of queries per second, the overhead of > checking the data structure is too high. Thus, between two machine > tasks, the schema is essentially fixed and trusted. Sounds like I shouldn't worry about schemas (schemae?) for either system. > Note that our engine allows the querier to choose which output format > it receives - either text (less data, proprietary format), HTML - in > fact simply uses the HTTP result code to give a 'yes' or 'no', or XML - d= ata > + extra information. >=20 > In theory, we could add a JSON option too. > [...] >=20 > JSON we use also, to format internal message queue messages. In some > way, we have used each depending on which interfaces the tools support. > However, we chose XML for the result format for the human readability > for debugging (Not saying you can't read JSON, but I guess its the > difference between reading SMS speak and email..) >=20 > Have you thought of allowing the engines to offer answers in both, and > allowing the consumer to choose which type it wants (and thus also > allowing the engine to state which it supports?) My own current implementation supports both; you configure the client at co= mpile time by picking which libraries to use, and configure the server at r= un time with a flag, because the output is just a bunch of "print" statemen= ts, i.e., generated manually rather than through an API, because the payloa= d is so simple. For standardization though, I fully expect we'll need to pick one and go wi= th it, which is why we're debating the merits of these two. Mind you, the = working group could eventually decide it does want to have a JSON version a= nd an XML version, though I expect we will eventually pick one, and it soun= ds like JSON has a slight edge at the moment. Cheers, -MSK From dhc@dcrocker.net Tue Mar 6 05:37:32 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AF521F886F for ; Tue, 6 Mar 2012 05:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.607 X-Spam-Level: X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 F4ckSmnFiK8o for ; Tue, 6 Mar 2012 05:37:31 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EBF1C21F8848 for ; Tue, 6 Mar 2012 05:37:31 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q26DbQc6031945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2012 05:37:31 -0800 Message-ID: <4F56130C.7050909@dcrocker.net> Date: Tue, 06 Mar 2012 05:37:16 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Steve Allam References: <20120306060427.90315.qmail@joyce.lan> <4F55C6B8.3060002@trustsphere.com> In-Reply-To: <4F55C6B8.3060002@trustsphere.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 06 Mar 2012 05:37:31 -0800 (PST) Cc: domainrep@ietf.org Subject: Re: [domainrep] REPUTEing with JSON X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 13:37:32 -0000 On 3/6/2012 12:11 AM, Steve Allam wrote: > Have you thought of allowing the engines to offer answers in both, and allowing > the consumer to choose which type it wants (and thus also allowing the engine to > state which it supports?) please don't do that. we aren't the ITU. keep the based simple. alternatives for the same thing aren't simple. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Tue Mar 6 06:01:52 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1490021F88F3 for ; Tue, 6 Mar 2012 06:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.607 X-Spam-Level: X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 SQB+aY4YHfU5 for ; Tue, 6 Mar 2012 06:01:51 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id DC03521F88E8 for ; Tue, 6 Mar 2012 06:01:50 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q26E1j2k032620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Mar 2012 06:01:50 -0800 Message-ID: <4F5618BE.9090002@dcrocker.net> Date: Tue, 06 Mar 2012 06:01:34 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "domainrep@ietf.org" , "domainrep@ietf.org" References: <0E04C90C-D7E5-408F-A040-E11C64F17954@amsl.com> In-Reply-To: <0E04C90C-D7E5-408F-A040-E11C64F17954@amsl.com> X-Forwarded-Message-Id: <0E04C90C-D7E5-408F-A040-E11C64F17954@amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 06 Mar 2012 06:01:50 -0800 (PST) Subject: [domainrep] Fwd: 83rd IETF FINAL Agenda X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 14:01:52 -0000 The Repute wg session is scheduled for Wednesday, 103pm, room 243. d/ -------- Original Message -------- Subject: 83rd IETF FINAL Agenda Date: Mon, 5 Mar 2012 10:35:07 -0800 From: Wanda Lo To: WG Chairs CC: irsg@irtf.org Dear WG, BoF, and IRTF Chairs, The final agenda is ready for viewing. Please take a minute to note your session and meeting room(s). Currently, ONLY AD's can submit changes in the form of a swap to agenda@ietf.org . If you have any questions, feel free to contact me at anytime. https://datatracker.ietf.org/meeting/83/agenda.html https://datatracker.ietf.org/meeting/83/agenda.txt http://www.ietf.org/meeting/83/index.html -- Dave Crocker Brandenburg InternetWorking bbiw.net From doowens@cisco.com Tue Mar 6 18:06:20 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A4A21E8028 for ; Tue, 6 Mar 2012 18:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 wS8o1N3mLFRH for ; Tue, 6 Mar 2012 18:06:19 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id DD06F21E801E for ; Tue, 6 Mar 2012 18:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=doowens@cisco.com; l=1620; q=dns/txt; s=iport; t=1331085979; x=1332295579; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/qWxbw0rsOPdhz9bLJsKDmliPVO9NlxC6zTU6B8DWuE=; b=l0D3dJVhZe0FUF+tiy6Cd7FqFVu5gcnyuBTz/Cn0whaopy0vek0FtO40 SnfIRe0B707BQW+dG2vQqHbFSgMRfLdZNbzh1YLfs7pWfDiXsTxhqaGht r2eSE9ZDdyeFcM80HRjkfMS8PaBFtxbOE63N6ZGEN6e8OWsDDV80tSqL2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALPBVk+rRDoI/2dsb2JhbABDtQWBB4F9AQEBAwEBAQEPASc0EAsCAQgYHhAnCyUBAQQTIodgBAELmlkBnw6QDWMElT+QFoJj X-IronPort-AV: E=Sophos;i="4.73,542,1325462400"; d="scan'208";a="34760807" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 07 Mar 2012 02:06:18 +0000 Received: from xht-rcd-x01-p.cisco.com (xht-rcd-x01-p.cisco.com [173.37.178.212]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2726Idk008977 for ; Wed, 7 Mar 2012 02:06:18 GMT Received: from xmb-rcd-x02-p.cisco.com ([169.254.2.118]) by xht-rcd-x01-p.cisco.com ([173.37.178.212]) with mapi id 14.02.0283.003; Tue, 6 Mar 2012 18:06:16 -0800 From: "Don Owens (doowens)" To: "domainrep@ietf.org" Thread-Topic: [domainrep] REPUTEing with JSON Thread-Index: Acz7J4VDrnVsR6E7QcWyDis1nxXIZAAU7oiAADOqkYA= Date: Wed, 7 Mar 2012 02:06:15 +0000 Message-ID: References: <9452079D1A51524AA5749AD23E00392807B472@exch-mbx901.corp.cloudmark.com> <20120305202645.3d3ff6ba@shishi.roaringpenguin.com> In-Reply-To: <20120305202645.3d3ff6ba@shishi.roaringpenguin.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18758.001 x-tm-as-result: No--29.192500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <71EED12027520E418682E4B24BC450DB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] REPUTEing with JSON X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 02:06:20 -0000 +1 for JSON. It is indeed a bit of a religious issue. But I have found JSON much easier= to deal with when working with data rather than documentation, and it's we= ll-suited the "golden data structure" (nested arrays and maps). ./don On Mar 5, 2012, at 5:26 PM, David F. Skoll wrote: > On Mon, 5 Mar 2012 23:27:24 +0000 > "Murray S. Kucherawy" wrote: >=20 >> Hoping it would reveal some interesting issues for to continue the >> whole XML vs. JSON discussion, I recently converted my REPUTE >> implementation from XML to JSON. >=20 > It looks like a religious issue. Googling "JSON vs XML" yields plenty > of religion. >=20 > I liked the comment at http://ajaxian.com/archives/json-vs-xml-the-debate= : >=20 > "I believe that the most important thing to understand in the JSON and > XML debate is that they are really fundamentally built for two > distinct purposes. XML is built for giving semantic meaning two [sic] tex= t > within documents. JSON is built for data structures." >=20 > I think REPUTE is exchanging data structures rather than text > documents with semantic meaning and I find JSON easier to read than > XML, so I'm mildly in favour of JSON. Human readability of the > wire protocol is not required, of course, but if we are going to > make it verbose by using something like XML, we might as well > make it more human readable (and compact as a bonus.) >=20 > Regards, >=20 > David. > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep From leifj@mnt.se Mon Mar 12 08:43:44 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB90F21F8715 for ; Mon, 12 Mar 2012 08:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=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 OlV-Q5a+EXmt for ; Mon, 12 Mar 2012 08:43:44 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 0837521F869A for ; Mon, 12 Mar 2012 08:43:43 -0700 (PDT) Received: from [10.0.1.91] (70-91-87-57-BusName-metrodr.md.hfc.comcastbusiness.net [70.91.87.57]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2CFhcGj019374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Mar 2012 16:43:42 +0100 (CET) Message-ID: <4F5E19AA.2050802@mnt.se> Date: Mon, 12 Mar 2012 16:43:38 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <9452079D1A51524AA5749AD23E00392807B472@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392807B472@exch-mbx901.corp.cloudmark.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] REPUTEing with JSON X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 15:43:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 fortunately for the discussion, I hit no major snags. Both client and > server conversion took me an evening. The payload in both cases > for a simple REPUTE query is pretty small, though a little smaller > in JSON. The code after conversion is also a little simpler, but it > could be argued that that?s a function of the libraries I used to > decode the payload and not of the formats themselves. So, to me, > there?s not a clear winner. But that does leave me partial to JSON > because the API I chose (jansson) leaves my application code > cleaner. Your experience aligns well with other "testimony" from people who have done similar things. The thing to note is probably that you _could_ have written your code from scratch without even using a library for JSON and had a reasonable chance of getting it right. The same could not be said for XML probably. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9eGakACgkQ8Jx8FtbMZnfhaACgsXXInRbRS8YTlPwhoj8Vwqoj e+kAnidwVhGyXIlGGsfvYT4h1b/I92/F =PJsG -----END PGP SIGNATURE----- From dhc@dcrocker.net Mon Mar 12 09:29:05 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D4921F86F3 for ; Mon, 12 Mar 2012 09:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 qT8vYbAH6iWB for ; Mon, 12 Mar 2012 09:29:04 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 62F6721F86D7 for ; Mon, 12 Mar 2012 09:29:04 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2CGSwuD021008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Mar 2012 09:29:04 -0700 Message-ID: <4F5E2436.6000404@dcrocker.net> Date: Mon, 12 Mar 2012 09:28:38 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "domainrep@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 12 Mar 2012 09:29:04 -0700 (PDT) Subject: [domainrep] Topics for IETF Repute wg meeting X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:29:05 -0000 Folks, Happy Monday. The Repute wg meeting during IETF week will be Wednesday, 28 March, 1-3pm. 16 days away... What shall we discuss? What issues are pending that you believe we can resolve with a face-to-face meeting? What issues should be raised that we are likely to make progress on with a f2f meeting? For these, /please raise them in a separate thread/ with a new Subject line, so that we can treat them as new topics and start discussing them before the meeting? What else should be discussed? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Tue Mar 13 06:45:54 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C7E21F8939 for ; Tue, 13 Mar 2012 06:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 yB3KOd-jOGmC for ; Tue, 13 Mar 2012 06:45:54 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3915F21F8930 for ; Tue, 13 Mar 2012 06:45:54 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2DDjmDu025856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Mar 2012 06:45:53 -0700 Message-ID: <4F5F4F74.9050104@dcrocker.net> Date: Tue, 13 Mar 2012 06:45:24 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "domainrep@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 13 Mar 2012 06:45:53 -0700 (PDT) Subject: [domainrep] meetecho details for Repute wg session X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 13:45:55 -0000 For reference, there will be Meetecho support for the Repute wg session at the IETF in Paris. For those not able to be in the Paris meeting room but wanting to participate in the session, see: http://ietf83.conf.meetecho.com/index.php/ d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Wed Mar 14 11:33:47 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC4421F8624 for ; Wed, 14 Mar 2012 11:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, 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 jj0FgPwG344f for ; Wed, 14 Mar 2012 11:33:46 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7E421F8527 for ; Wed, 14 Mar 2012 11:33:46 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 11:33:46 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Thread-Topic: [domainrep] Topics for IETF Repute wg meeting Thread-Index: AQHNAG0/xI26qE2X3ESD30ZNoT3tU5ZqHinw Date: Wed, 14 Mar 2012 18:33:45 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392808A03A@exch-mbx901.corp.cloudmark.com> References: <4F5E2436.6000404@dcrocker.net> In-Reply-To: <4F5E2436.6000404@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Topics for IETF Repute wg meeting X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 18:33:47 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Dave Crocker > Sent: Monday, March 12, 2012 9:29 AM > To: domainrep@ietf.org > Subject: [domainrep] Topics for IETF Repute wg meeting >=20 > What shall we discuss? A brief overview of each of the documents' content and states might be good= . They've all changed since Taipei. Each of them might lead into some of = the topics below. There are some things we talked about in Taipei that hav= en't been revisited on the list yet, such as the complexity forced on clien= ts by using the URI template scheme. I think we could spend some time bashing around the JSON/XML question again= . This has come up in a few related areas lately, including the nascent WE= IRDS work, so we could review and use some of their arguments, or we could = do a good job and let them use ours. I can talk briefly about my experienc= e converting my implementation from XML to JSON to see if it would help ans= wer this question, but there's not that much to say at least from my own pe= rspective. There might be other comments to consider, however. A review of the newly-revised model document would be helpful, to see if th= ere are things we want to change before progressing it. We should talk about the final deliverable: "Informational document, discu= ssing issues of data transparency, redress, meta-reputation and other impor= tant operational considerations, to the IESG for publication." If we don't= actually want to start that now and find an editor, we might at least coll= ect input to act as a starting point to such work. A lot of things on this= topic were brought up during the BoF in Quebec City (in fact, most of our = time was spent on this), so the minutes from that would also be a good sour= ce of input. Some older issues that we've tabled, but could be revisited: - do we need a lightweight protocol? - if so, DNS? CoAP? A new UDP thing? -MSK From msk@cloudmark.com Wed Mar 14 12:31:28 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F95021F84DF for ; Wed, 14 Mar 2012 12:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, 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 BI6JvOC3Er2h for ; Wed, 14 Mar 2012 12:31:27 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id B3AF521F84DC for ; Wed, 14 Mar 2012 12:31:27 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 12:31:27 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Thread-Topic: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) Thread-Index: AcyT5UTkk2iZfxkBS2mST9MqCIcuswFCXMLwGkqHz+A= Date: Wed, 14 Mar 2012 19:31:27 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392808B25C@exch-mbx901.corp.cloudmark.com> References: <4EA80E82.3020202@kitterman.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 19:31:28 -0000 Going back a ways... > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Murray S. Kucherawy > Sent: Tuesday, November 01, 2011 4:38 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about rep= utation data meta-issues) >=20 > > It would be interesting to do an evaluation of if it really is > > necessary. At some level (and I know I'm generalizing here) both DKIM > > validation and SPF pass results output a domain that the domain owner > > have given some level of authorization to. > > > > I don't think it's at all clear that this distinction makes enough > > difference to be worth the complexity associated with maintaining > > multiple types of identity. >=20 > In general I agree that it's unclear. What I expect, though, is that > there will be purists out there that claim one is better than the other > for whatever reason, and want to ensure that their mail flow is based > on one in particular. The IDENTITY stuff provides a way to confirm > that in the reply to the query. >=20 > I think this is something useful to include initially. If it turns out > to be unused because the result is mainly the same on both "sides", > then we can drop it in a later version (say, when it advances to draft > standard). >=20 > Having said that, I'll see if I can produce some reports from the > accumulated OpenDKIM data that confirm (or are unable to confirm) a > strong correlation. Perhaps others here have databases they could tap > to do the same. It looks like my accumulated data don't in fact have what it takes to do th= is correlation. I hope someone else can. In the absence of a general "it = doesn't make a difference" statement, however, I think we still need this c= apability. Even if we do get data that shows SPF and DKIM (for example) ba= sically result in highly similar reputations, some third mechanism that's s= upported might not. -MSK From ajs@anvilwalrusden.com Wed Mar 21 07:13:27 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB66221F86F0 for ; Wed, 21 Mar 2012 07:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 3uJJKgce5H6o for ; Wed, 21 Mar 2012 07:13:27 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF9E21F86EE for ; Wed, 21 Mar 2012 07:13:27 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C69CB1ECB41D for ; Wed, 21 Mar 2012 14:13:25 +0000 (UTC) Date: Wed, 21 Mar 2012 10:13:25 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20120321141325.GD48500@mail.yitter.info> References: <20120305162622.12099.38754.idtracker@ietfa.amsl.com> <20120305170429.GN76465@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120305170429.GN76465@mail.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [domainrep] Murphy intervened (was: I-D Action: draft-ietf-repute-model-01.txt) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 14:13:27 -0000 Dear colleagues, On Mon, Mar 05, 2012 at 12:04:30PM -0500, Andrew Sullivan wrote: > cleanup of some references, and that's about it. Murphy willing, I'm > planning to do some of that work in the next week before the deadline > arrives, but if you think otherwise it would be very helpful to know > as much. As you no doubt noticed from the lack of updates, Murphy did not co-operate. As I noted, however, I do not see what substantive changes to the -01 are needed. I therefore do not have plans for any sort of discussion of this draft in Paris (for instance, I'm not preparing slides). If you think that discussion is needed, please let me know. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From prvs=042975f459=steve.allam@trustsphere.com Fri Mar 23 13:50:48 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BF021E8027 for ; Fri, 23 Mar 2012 13:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.143 X-Spam-Level: X-Spam-Status: No, score=-0.143 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_20=-0.74, DATE_IN_PAST_12_24=0.992, 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 n4sUK7jAzJXk for ; Fri, 23 Mar 2012 13:50:47 -0700 (PDT) Received: from st2.realmail-asp.co.uk (st2.realmail-asp.co.uk [80.249.100.228]) by ietfa.amsl.com (Postfix) with ESMTP id 71A0521E8018 for ; Fri, 23 Mar 2012 13:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trustsphere.com; s=rmdkim; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=2mii03kW+J33BMz0Xj8YE8Zets4si53LQvDMTMrwOTE=; b=WKRmdgPvZnd1MN2z4SdA0Zw/LH4msBg0d4O9t67N4cjl5SncVZVmKi4y2WcNMG6TyavZZ5kuyDMsPmN5PmZ3oqfTJNkZN+N7aI4DVLR+ukGmc70618MZu7caWJN9Wf9bSiiIRaAhuwRB1Vfw6znBz0P/nFnAz0Piw8a1EMzBmTw=; Received: from [116.12.149.130] (helo=cgpro.boxsentry.com) by st2.realmail-asp.co.uk with esmtp id 1SBBRd-0004C6-Rl for domainrep@ietf.org; Fri, 23 Mar 2012 20:50:46 +0000 Received: by cgpro.boxsentry.com (CommuniGate Pro PIPE 5.4.0) with PIPE id 1913655; Sat, 24 Mar 2012 04:51:02 +0800 Received: from [88.97.130.81] (account steve.allam@trustsphere.com HELO [10.1.1.33]) by cgpro.boxsentry.com (CommuniGate Pro SMTP 5.4.0) with ESMTPSA id 1913656 for domainrep@ietf.org; Sat, 24 Mar 2012 04:50:49 +0800 Message-ID: <4F6C229F.5040609@trustsphere.com> Date: Fri, 23 Mar 2012 07:13:35 +0000 From: Steve Allam User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <20120305162622.12099.38754.idtracker@ietfa.amsl.com> <20120305170429.GN76465@mail.yitter.info> <20120321141325.GD48500@mail.yitter.info> In-Reply-To: <20120321141325.GD48500@mail.yitter.info> Content-Type: multipart/alternative; boundary="------------060808070300040000000405" X-RMR-rmalert: true X-LogiQ-query: 116.12.149.130/steve.allam@trustsphere.com/domainrep@ietf.org (I000 OK UNKNOWN.EXISTS ) X-RealMail-Category: UNKNOWN/UNKNOWN X-RealMail-Ref: UNKNOWN/str=0001.0A0B0209.4F6CE226.0020,ss=1,re=0.000,fgs=0 X-RealMail-IWF: NO X-CTCH-SenderID: steve.allam@trustsphere.com X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-Total-Spam: 0 X-CTCH-SenderID-Total-Suspected: 0 Subject: Re: [domainrep] Murphy intervened X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 20:50:48 -0000 This is a multi-part message in MIME format. --------------060808070300040000000405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andrew, I have a question, not on the draft-ietf-repute-model-01.txt document itself, but how it is referred to in vocabulary documents, for example - draft-ietf-repute-email-identifiers-02 states: The "email-id" reputation application recognizes the following OPTIONAL extensions to the basic vocabulary defined in [I-D.REPUTE-MODEL]: This implies that there is a basic vocab defined in the document. The section 'Information represented in a Response Set' defines some terms, such as 'the identity of the entity being rated', however, the document does not define these further, although examples in the media-type doc describe 'RATED', which matches this perhaps. My questions are: When writing a vocab, which document should be referred back to for the basic vocab, when describing extensions? I have started writing a vocab for our reputation application, using the email-id memo as a base - would anyone care to review when I have finished? - although our application is known perhaps only to Murray somewhat, the content and format of the document need to fit into the REPUTE framework. I should explain the context - I have been talking to Murray outside the list and came up with a number of questions that Murray has answered, but he suggested that I ask some further questions in the list, and I also promised to relay my previous questions to the list as they may help further discussions. Regards, Steve On 21/03/2012 2:13 PM, Andrew Sullivan wrote: > Dear colleagues, > > On Mon, Mar 05, 2012 at 12:04:30PM -0500, Andrew Sullivan wrote: >> cleanup of some references, and that's about it. Murphy willing, I'm >> planning to do some of that work in the next week before the deadline >> arrives, but if you think otherwise it would be very helpful to know >> as much. > As you no doubt noticed from the lack of updates, Murphy did not > co-operate. As I noted, however, I do not see what substantive > changes to the -01 are needed. I therefore do not have plans for any > sort of discussion of this draft in Paris (for instance, I'm not preparing > slides). If you think that discussion is needed, please let me know. > > Best, > > A > -- * Steve Allam | * Chief Technology Officer *| TrustSphere * 3 Phillip Street, #13-03 Commerce Point, Singapore, 048693 Tel: +65 6536 5203 | Fax: +65 6536 5463 steve.allam@trustsphere.com | www.trustsphere.com --------------060808070300040000000405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Andrew,

I have a question, not on the draft-ietf-repute-model-01.txt document itself, but how it is referred to in
vocabulary documents, for example - draft-ietf-repute-email-identifiers-02 states:

 The "email-id" reputation application recognizes the following
   OPTIONAL extensions to the basic vocabulary defined in
   [I-D.REPUTE-MODEL]:

This implies that there is a basic vocab defined in the document.  The section 'Information represented in a Response Set' defines some terms, such as 'the identity of the entity being rated', however, the document does not define these further, although examples in the media-type doc describe 'RATED', which matches this perhaps. 

My questions are:

When writing a vocab, which document should be referred back to for the basic vocab, when describing extensions?
I have started writing a vocab for our reputation application, using the email-id memo as a base - would anyone care to review when I have finished? - although our application is known perhaps only to Murray somewhat, the content and format of the document need to fit into the REPUTE framework.


I should explain the context - I have been talking to Murray outside the list and came up with a number of questions that Murray has answered, but he suggested that I ask some further questions in the list, and I also promised to relay my previous questions to the list as they may help further discussions.

Regards,

Steve

On 21/03/2012 2:13 PM, Andrew Sullivan wrote: 
Dear colleagues,

On Mon, Mar 05, 2012 at 12:04:30PM -0500, Andrew Sullivan wrote:

cleanup of some references, and that's about it.  Murphy willing, I'm
planning to do some of that work in the next week before the deadline
arrives, but if you think otherwise it would be very helpful to know
as much.

As you no doubt noticed from the lack of updates, Murphy did not
co-operate.  As I noted, however, I do not see what substantive
changes to the -01 are needed.  I therefore do not have plans for any
sort of discussion of this draft in Paris (for instance, I'm not preparing
slides).  If you think that discussion is needed, please let me know.

Best,

A

--

Steve Allam | Chief Technology Officer | TrustSphere

3 Phillip Street, #13-03 Commerce Point, Singapore, 048693
Tel: +65 6536 5203 | Fax: +65 6536 5463
 steve.allam@trustsphere.com | www.trustsphere.com
--------------060808070300040000000405-- From prvs=042975f459=steve.allam@trustsphere.com Fri Mar 23 13:50:48 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB21A21E8018 for ; Fri, 23 Mar 2012 13:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.055 X-Spam-Level: X-Spam-Status: No, score=0.055 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_20=-0.74, DATE_IN_PAST_12_24=0.992, 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 Ncsdx8sYkfrZ for ; Fri, 23 Mar 2012 13:50:48 -0700 (PDT) Received: from st2.realmail-asp.co.uk (st2.realmail-asp.co.uk [80.249.100.228]) by ietfa.amsl.com (Postfix) with ESMTP id 00B0021E8026 for ; Fri, 23 Mar 2012 13:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trustsphere.com; s=rmdkim; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=rrosLnCPxOLaciT1+06lAZNA/StAe6fBFn74ktxlbw8=; b=jBQKSXFCJe5tHths3Sz+7WYocW5P0putI3cytwPi8Ifh/xfPCoFwWANsBkWicGGMPt+BJRN3l9kBGzNfQ5YOvtL4pn5oSoYnEnTD6OJtUkQOvthMjMYbsd0Tvaz0EjepQjic/Z3hMENMpsfnqwqxgm4AHT0+vV902uIc0oGezgk=; Received: from [116.12.149.130] (helo=cgpro.boxsentry.com) by st2.realmail-asp.co.uk with esmtp id 1SBBRe-0004C6-Sl for domainrep@ietf.org; Fri, 23 Mar 2012 20:50:47 +0000 Received: by cgpro.boxsentry.com (CommuniGate Pro PIPE 5.4.0) with PIPE id 1913664; Sat, 24 Mar 2012 04:51:02 +0800 Received: from [88.97.130.81] (account steve.allam@trustsphere.com HELO [10.1.1.33]) by cgpro.boxsentry.com (CommuniGate Pro SMTP 5.4.0) with ESMTPSA id 1913648 for domainrep@ietf.org; Sat, 24 Mar 2012 04:50:55 +0800 Message-ID: <4F6C26EF.20005@trustsphere.com> Date: Fri, 23 Mar 2012 07:31:59 +0000 From: Steve Allam User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <20120305162622.12099.38754.idtracker@ietfa.amsl.com> In-Reply-To: <20120305162622.12099.38754.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000906050807000307020706" X-RMR-rmalert: true X-LogiQ-query: 116.12.149.130/steve.allam@trustsphere.com/domainrep@ietf.org (I000 OK UNKNOWN.EXISTS ) X-RealMail-Category: UNKNOWN/UNKNOWN X-RealMail-Ref: UNKNOWN/str=0001.0A0B0209.4F6CE227.0081,ss=1,re=0.000,fgs=0 X-RealMail-IWF: NO X-CTCH-SenderID: steve.allam@trustsphere.com X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 2 X-CTCH-SenderID-Total-Spam: 0 X-CTCH-SenderID-Total-Suspected: 0 Subject: [domainrep] writing application vocabs X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 20:50:49 -0000 This is a multi-part message in MIME format. --------------000906050807000307020706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, (What follows is derived from off-list conversation with Murray) My assumption is that application providers will write a vocab for their application and register that vocab with ietf - what is the feeling of the group to specific application related vocab, defining required parameters for the application, versus a more generic vocab that uses minimal required parameters, but allows multiple extensions? To be specific, our application is called LogiQ, and has a set of defined parameters, as detailed in our API. I can define a tight vocab based on this, or perhaps a more generic vocab, for perhaps a more generic relationship reputation application. For LogiQ, I would define required parameters of: - sender ip - sender address - recipient address and a whole bunch of optional parameters. On the other hand, a more generic application might not even require those three parameters. Or, in fact, I could extend the email-id vocab by defining a new assertion of (perhaps) KNOWN-SENDER, and simply require all my parameters as optional. At the moment, I am looking to write an application vocab, but what ideas/suggestions do others have? I have similar concerns with the response,- I'm not sure my concerns are well founded, but I'd rather not end up having to respond with lots of xml elements (or JSON objects!) - purely I think because it looks messy - hence not being sure my concerns are well founded. - However, Murray's comment on the extension mechanism was that perhaps it should be looked at again to ensure people declare better vocabs Regards, Steve -- * Steve Allam | * Chief Technology Officer *| TrustSphere * 3 Phillip Street, #13-03 Commerce Point, Singapore, 048693 Tel: +65 6536 5203 | Fax: +65 6536 5463 steve.allam@trustsphere.com | www.trustsphere.com --------------000906050807000307020706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

(What follows is derived from off-list conversation with Murray)

My assumption is that application providers will write a vocab for their application and register that vocab with ietf - what is the feeling of the group to specific application related vocab, defining required parameters for the application, versus a more generic vocab that uses minimal required parameters, but allows multiple extensions?

To be specific, our application is called LogiQ, and has a set of defined parameters, as detailed in our API.  I can define a tight vocab based on this, or perhaps a more generic vocab, for perhaps a more generic relationship reputation application.  For LogiQ, I would define required parameters of:
 - sender ip
 - sender address
 - recipient address
and a whole bunch of optional parameters.  On the other hand, a more generic application might not even require those three parameters.

Or, in fact, I could extend the email-id vocab by defining a new assertion of (perhaps)  KNOWN-SENDER, and simply require all my parameters as optional.

At the moment, I am looking to write an application vocab, but what ideas/suggestions do others have?

I have similar concerns with the response,- I'm not sure my concerns are well founded, but I'd rather not end up having to respond with lots of <EXTENSION> xml elements (or JSON objects!) - purely I think because it looks messy - hence not being sure my concerns are well founded.

- However, Murray's comment on the extension mechanism was that perhaps it should be looked at again to ensure people declare better vocabs

Regards,

Steve


--

Steve Allam | Chief Technology Officer | TrustSphere

3 Phillip Street, #13-03 Commerce Point, Singapore, 048693
Tel: +65 6536 5203 | Fax: +65 6536 5463
 steve.allam@trustsphere.com | www.trustsphere.com
--------------000906050807000307020706-- From prvs=042975f459=steve.allam@trustsphere.com Fri Mar 23 13:51:43 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5683F21E8083 for ; Fri, 23 Mar 2012 13:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.522 X-Spam-Level: * X-Spam-Status: No, score=1.522 tagged_above=-999 required=5 tests=[AWL=-1.532, BAYES_50=0.001, DATE_IN_PAST_12_24=0.992, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_COM=0.311, 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 DvQ2OexkifBc for ; Fri, 23 Mar 2012 13:51:42 -0700 (PDT) Received: from st3.realmail-asp.co.uk (fe1.securerealmail.com [80.249.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 1D57121E8082 for ; Fri, 23 Mar 2012 13:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trustsphere.com; s=rmdkim; h=Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=B969loBw8riNJhpiAuV+zq6y7VB0hMBHqmmRL2DVtcA=; b=SlO3HqkYKorJfFD1SINeL9V1WYXo4nSYLEMX5EO+sQyukeDmONnompxnDAOe4RMViGXaDlMaKcdXt5K24A4qEVfzHcTlpWGhLK0hJkPj7rQfpjq0Pqid3+bbeLBjt8PpnIUDyVPPTnnHmjtX+CAUcqlhAocFQaBVG8+oDlizwAA=; Received: from [116.12.149.130] (helo=cgpro.boxsentry.com) by st3.realmail-asp.co.uk with esmtp id 1SBBSW-0001cF-Ur for domainrep@ietf.org; Fri, 23 Mar 2012 20:51:41 +0000 Received: by cgpro.boxsentry.com (CommuniGate Pro PIPE 5.4.0) with PIPE id 1913638; Sat, 24 Mar 2012 04:51:17 +0800 Received: from [88.97.130.81] (account steve.allam@trustsphere.com HELO [10.1.1.33]) by cgpro.boxsentry.com (CommuniGate Pro SMTP 5.4.0) with ESMTPSA id 1913666 for domainrep@ietf.org; Sat, 24 Mar 2012 04:51:10 +0800 Message-ID: <4F6C3104.40401@trustsphere.com> Date: Fri, 23 Mar 2012 08:15:00 +0000 From: Steve Allam User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: domainrep@ietf.org Content-Type: multipart/alternative; boundary="------------050301080508000107070508" X-RMR-rmalert: true X-LogiQ-query: 116.12.149.130/steve.allam@trustsphere.com/domainrep@ietf.org (error socket failure) X-RealMail-Category: UNKNOWN/UNKNOWN X-RealMail-Ref: UNKNOWN/str=0001.0A0B0208.4F6CE25D.0018,ss=1,re=0.000,fgs=0 X-RealMail-IWF: NO X-CTCH-SenderID: steve.allam@trustsphere.com X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-Total-Spam: 0 X-CTCH-SenderID-Total-Suspected: 0 Subject: [domainrep] xml versus json X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 20:51:43 -0000 This is a multi-part message in MIME format. --------------050301080508000107070508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, I have been looking at implementing the repute framework in our application, and was exploring the JSON v. XML issue internally. We already supply answers to queries in three formats: - use of HTTP response code (ooh, nasty hack, but really quick) - XML - plain text Digging back, we used XML because, well, it was there, it was used by various standards, we wanted to have a standards based API, SOAP/XML like - partly because when you talk to integrators, you can say - 'we have a proprietary API', or you can say 'we use SOAP/XML' and the latter phrase seems to calm people. However, whilst we return XML, we don't POST xml as part of the query (too slow), we use GET params, so we use a dirty form of soap :-) In fact, in all the connectors we write, we make use of the plain text format the most - none use the XML format. The problem was, we defined the XML as a comprehensive response, and the text one as a minimal response, but with scope creep, the text one got longer. Given our experiences, I would thus tend more towards JSON - SOAP/XML works well as a 'standard', but JSON works equally well and in my experience is much quicker to parse than XML (certainly if you use drop-in libraries). XML gives the benefit of a schema however, closely defining your doc, whereas JSON can be much less well defined,- however, the JSON spec is a one pager (I'd not looked at json.org before - I liked it a lot), so as long as the vocab definitions have a clear indication of how the JSON is formed, I think it could be the winner? Regards, Steve -- * Steve Allam | * Chief Technology Officer *| TrustSphere * 3 Phillip Street, #13-03 Commerce Point, Singapore, 048693 Tel: +65 6536 5203 | Fax: +65 6536 5463 steve.allam@trustsphere.com | www.trustsphere.com --------------050301080508000107070508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

I have been looking at implementing the repute framework in our application, and was exploring the JSON v. XML issue internally.  We already supply answers to queries in three formats:

- use of HTTP response code (ooh, nasty hack, but really quick)
- XML
- plain text

Digging back, we used XML because, well, it was there, it was used by various standards, we wanted to have a standards based API, SOAP/XML like - partly because when you talk to integrators, you can say - 'we have a proprietary API', or you can say 'we use SOAP/XML' and the latter phrase seems to calm people.

However, whilst we return XML, we don't POST xml as part of the query (too slow), we use GET params, so we use a dirty form of soap :-)

In fact, in all the connectors we write, we make use of the plain text format the most - none use the XML format.  The problem was, we defined the XML as a comprehensive response, and the text one as a minimal response, but with scope creep, the text one got longer.

Given our experiences, I would thus tend more towards JSON - SOAP/XML works well as a 'standard', but JSON works equally well and in my experience is much quicker to parse than XML (certainly if you use drop-in libraries).

XML gives the benefit of a schema however, closely defining your doc, whereas JSON can be much less well defined,- however, the JSON spec is a one pager (I'd not looked at json.org before - I liked it a lot), so as long as the vocab definitions have a clear indication of how the JSON is formed, I think it could be the winner?

Regards,

Steve

--

Steve Allam | Chief Technology Officer | TrustSphere

3 Phillip Street, #13-03 Commerce Point, Singapore, 048693
Tel: +65 6536 5203 | Fax: +65 6536 5463
 steve.allam@trustsphere.com | www.trustsphere.com
--------------050301080508000107070508-- From prvs=042975f459=steve.allam@trustsphere.com Fri Mar 23 13:52:24 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A856321E8064 for ; Fri, 23 Mar 2012 13:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.605 X-Spam-Level: X-Spam-Status: No, score=0.605 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_COM=0.311, 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 fmqoJvI4hxP3 for ; Fri, 23 Mar 2012 13:52:23 -0700 (PDT) Received: from st3.realmail-asp.co.uk (fe1.securerealmail.com [80.249.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABC421E804E for ; Fri, 23 Mar 2012 13:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trustsphere.com; s=rmdkim; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=aQLzjGWtDhEf2IWeVA2d1B3x7lxj5ygwdqTxwFi1Cjc=; b=Fxqug98o8Wt9Gd9X7peaIB0G92xeOtVvMK3U+ouYbpZ+f3W1KgHSrZhGVpfkvVfalg+tJ/pawfxAIhLnM7WLN27wPutFi7pFm4EKtqT7jZUrfy6tMfFvsla8Jd6L3QtJEzLX/QTGHNuMczsz8te5g79Bd3J9QF/VXX2h2NwCyKQ=; Received: from [116.12.149.130] (helo=cgpro.boxsentry.com) by st3.realmail-asp.co.uk with esmtp id 1SBBTB-0001cF-Vt for domainrep@ietf.org; Fri, 23 Mar 2012 20:52:22 +0000 Received: by cgpro.boxsentry.com (CommuniGate Pro PIPE 5.4.0) with PIPE id 1913670; Sat, 24 Mar 2012 04:51:17 +0800 Received: from [88.97.130.81] (account steve.allam@trustsphere.com HELO [10.1.1.33]) by cgpro.boxsentry.com (CommuniGate Pro SMTP 5.4.0) with ESMTPSA id 1913661 for domainrep@ietf.org; Sat, 24 Mar 2012 04:51:04 +0800 Message-ID: <4F6C2DC8.50804@trustsphere.com> Date: Fri, 23 Mar 2012 08:01:12 +0000 From: Steve Allam User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <4F5E2436.6000404@dcrocker.net> <9452079D1A51524AA5749AD23E00392808A03A@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392808A03A@exch-mbx901.corp.cloudmark.com> Content-Type: multipart/alternative; boundary="------------060604060305080801070408" X-RMR-rmalert: true X-LogiQ-query: 116.12.149.130/steve.allam@trustsphere.com/domainrep@ietf.org (error socket failure) X-RealMail-Category: UNKNOWN/UNKNOWN X-RealMail-Ref: UNKNOWN/str=0001.0A0B020A.4F6CE286.00CB,ss=1,re=0.000,fgs=0 X-RealMail-IWF: NO X-CTCH-SenderID: steve.allam@trustsphere.com X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 2 X-CTCH-SenderID-Total-Spam: 0 X-CTCH-SenderID-Total-Suspected: 0 Subject: Re: [domainrep] Topics for IETF Repute wg meeting X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 20:52:24 -0000 This is a multi-part message in MIME format. --------------060604060305080801070408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Murray, From my side, I still see some mileage in a lightweight repute scheme, of course I am biased, and we already used both HTTP and DNS based reputation queries. Therefore, I am biased towards DNS in preference to other CoaP, UDP approaches. On the other hand, there are already a number of definitions for DNS based reputation services, IP block/white lists, domain lists etc - which are all providing reputation - are these going to be wrapped up into the repute model, or left alone? The latter I expect. The DNS lookup we do basically takes a sender and a domain, concatenates them, MD5 hashes them and forms a DNS query, such as: {md5-string}.{custkey}.{service-uri} At the time, the whole concat - MD5 mechanism was used to ensure (some) privacy of data, whilst making it possible to still use a standard RWL/RBL lookup mechanism within an MTA. Clearly for our HTTP reputation lookup, we have had to build connectors for all major MTAs, requiring work on our side, and integration work on the customer side. The requirement for integration work has thwarted one customer who simply would not add extensions to their MTA set-up. Making use of the standard RWL mechanism enabled us to leverage exiting functionality in some MTAs - clearly some are not capable of MD5 hashing before doing a lookup, but it got us part way there. By contrast, the HTTP lookup has required connectors to be written to all but two of the MTA's we use (and one of them Murray, belongs to Cloudmark...thanks...err. Bizanga, exim being the other). So, in summary - maybe a lightweight protocol in fact isn't required, because it's too late? Or maybe, when looking at what to use, DNS can be used to leverage existing MTA functionality? Or, maybe, REPUTE will look beyond email, and so MTAs don't matter - however, that doesn't negate DNS as a delivery mechanism for reputation data; already having mechanisms to distribute zone files and applications to serve them effectively. Regards, Steve On 14/03/2012 6:33 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Behalf Of Dave Crocker >> Sent: Monday, March 12, 2012 9:29 AM >> To: domainrep@ietf.org >> Subject: [domainrep] Topics for IETF Repute wg meeting >> >> What shall we discuss? > A brief overview of each of the documents' content and states might be good. They've all changed since Taipei. Each of them might lead into some of the topics below. There are some things we talked about in Taipei that haven't been revisited on the list yet, such as the complexity forced on clients by using the URI template scheme. > > I think we could spend some time bashing around the JSON/XML question again. This has come up in a few related areas lately, including the nascent WEIRDS work, so we could review and use some of their arguments, or we could do a good job and let them use ours. I can talk briefly about my experience converting my implementation from XML to JSON to see if it would help answer this question, but there's not that much to say at least from my own perspective. There might be other comments to consider, however. > > A review of the newly-revised model document would be helpful, to see if there are things we want to change before progressing it. > > We should talk about the final deliverable: "Informational document, discussing issues of data transparency, redress, meta-reputation and other important operational considerations, to the IESG for publication." If we don't actually want to start that now and find an editor, we might at least collect input to act as a starting point to such work. A lot of things on this topic were brought up during the BoF in Quebec City (in fact, most of our time was spent on this), so the minutes from that would also be a good source of input. > > Some older issues that we've tabled, but could be revisited: > - do we need a lightweight protocol? > - if so, DNS? CoAP? A new UDP thing? > > -MSK > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep -- * Steve Allam | * Chief Technology Officer *| TrustSphere * 3 Phillip Street, #13-03 Commerce Point, Singapore, 048693 Tel: +65 6536 5203 | Fax: +65 6536 5463 steve.allam@trustsphere.com | www.trustsphere.com --------------060604060305080801070408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Murray,

From my side, I still see some mileage in a lightweight repute scheme, of course I am biased, and we already used both  HTTP and DNS based reputation queries.  Therefore, I am biased towards DNS in preference to other CoaP, UDP approaches.  On the other hand, there are already a number of definitions for DNS based reputation services, IP block/white lists, domain lists etc - which are all providing reputation - are these going to be wrapped up into the repute model, or left alone?  The latter I expect.

The DNS lookup we do basically takes a sender and a domain, concatenates them, MD5 hashes them and forms a DNS query, such as:

  {md5-string}.{custkey}.{service-uri}

At the time, the whole concat - MD5 mechanism was used to ensure (some) privacy of data, whilst making it possible to still use a standard RWL/RBL lookup mechanism within an MTA.  Clearly for our HTTP reputation lookup, we have had to build connectors for all major MTAs, requiring work on our side, and integration work on the customer side.  The requirement for integration work has thwarted one customer who simply would not add extensions to their MTA set-up.

Making use of the standard RWL mechanism enabled us to leverage exiting functionality in some MTAs - clearly some are not capable of MD5 hashing before doing a lookup, but it got us part way there.  By contrast, the HTTP lookup has required connectors to be written to all but two of the MTA's we use (and one of them Murray, belongs to Cloudmark...thanks...err. Bizanga, exim being the other).

So, in summary - maybe a lightweight protocol in fact isn't required, because it's too late?
Or maybe, when looking at what to use, DNS can be used to leverage existing MTA functionality?
Or, maybe, REPUTE will look beyond email, and so MTAs don't matter - however, that doesn't negate DNS as a delivery mechanism for reputation data; already having mechanisms to distribute zone files and applications to serve them effectively.


Regards,

Steve

On 14/03/2012 6:33 PM, Murray S. Kucherawy wrote: 
-----Original Message-----
From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Behalf Of Dave Crocker
Sent: Monday, March 12, 2012 9:29 AM
To: domainrep@ietf.org
Subject: [domainrep] Topics for IETF Repute wg meeting

What shall we discuss?

A brief overview of each of the documents' content and states might be good.  They've all changed since Taipei.  Each of them might lead into some of the topics below.  There are some things we talked about in Taipei that haven't been revisited on the list yet, such as the complexity forced on clients by using the URI template scheme.

I think we could spend some time bashing around the JSON/XML question again.  This has come up in a few related areas lately, including the nascent WEIRDS work, so we could review and use some of their arguments, or we could do a good job and let them use ours.  I can talk briefly about my experience converting my implementation from XML to JSON to see if it would help answer this question, but there's not that much to say at least from my own perspective.  There might be other comments to consider, however.

A review of the newly-revised model document would be helpful, to see if there are things we want to change before progressing it.

We should talk about the final deliverable:  "Informational document, discussing issues of data transparency, redress, meta-reputation and other important operational considerations, to the IESG for publication."  If we don't actually want to start that now and find an editor, we might at least collect input to act as a starting point to such work.  A lot of things on this topic were brought up during the BoF in Quebec City (in fact, most of our time was spent on this), so the minutes from that would also be a good source of input.

Some older issues that we've tabled, but could be revisited:
	- do we need a lightweight protocol?
	- if so, DNS?  CoAP?  A new UDP thing?

-MSK
_______________________________________________
domainrep mailing list
domainrep@ietf.org
https://www.ietf.org/mailman/listinfo/domainrep

--

Steve Allam | Chief Technology Officer | TrustSphere

3 Phillip Street, #13-03 Commerce Point, Singapore, 048693
Tel: +65 6536 5203 | Fax: +65 6536 5463
 steve.allam@trustsphere.com | www.trustsphere.com
--------------060604060305080801070408-- From prvs=042975f459=steve.allam@trustsphere.com Fri Mar 23 14:06:53 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DC321F85F0 for ; Fri, 23 Mar 2012 14:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.845 X-Spam-Level: X-Spam-Status: No, score=0.845 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_50=0.001, DATE_IN_PAST_12_24=0.992, 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 f9X8wEQGhhLy for ; Fri, 23 Mar 2012 14:06:52 -0700 (PDT) Received: from st2.realmail-asp.co.uk (st2.realmail-asp.co.uk [80.249.100.228]) by ietfa.amsl.com (Postfix) with ESMTP id DD0AA21F85D8 for ; Fri, 23 Mar 2012 14:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trustsphere.com; s=rmdkim; h=Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Capsik82mvmAVtzS0FLjE+iNVqz9r/mzZaAcjPqeAH4=; b=YjExVr+nF7+vacudumECbtfK+/vv+EOIpTm4f7LIXdGCJMC1qX+ta8x1c2g7fa/yi8SaGpCZ7pnPS0D5h8CncQvwcYMeYfJ+aWdDAnK2aBGWkvkWASFq7JUDNVn4fiWilYZtv96fLaD3tWLECswXJa2fsRdhgxi0CoNVF76f8OA=; Received: from [116.12.149.130] (helo=cgpro.boxsentry.com) by st2.realmail-asp.co.uk with esmtp id 1SBBRg-0004C6-QW for domainrep@ietf.org; Fri, 23 Mar 2012 20:50:48 +0000 Received: by cgpro.boxsentry.com (CommuniGate Pro PIPE 5.4.0) with PIPE id 1913663; Sat, 24 Mar 2012 04:51:02 +0800 Received: from [88.97.130.81] (account steve.allam@trustsphere.com HELO [10.1.1.33]) by cgpro.boxsentry.com (CommuniGate Pro SMTP 5.4.0) with ESMTPSA id 1913662 for domainrep@ietf.org; Sat, 24 Mar 2012 04:51:01 +0800 Message-ID: <4F6C29F2.6010000@trustsphere.com> Date: Fri, 23 Mar 2012 07:44:50 +0000 From: Steve Allam User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: domainrep@ietf.org Content-Type: multipart/alternative; boundary="------------090502080500040608060501" X-RMR-rmalert: true X-LogiQ-query: 116.12.149.130/steve.allam@trustsphere.com/domainrep@ietf.org (I000 OK UNKNOWN.EXISTS ) X-RealMail-Category: UNKNOWN/UNKNOWN X-RealMail-Ref: UNKNOWN/str=0001.0A0B0209.4F6CE228.00EE,ss=1,re=0.000,fgs=0 X-RealMail-IWF: NO X-CTCH-SenderID: steve.allam@trustsphere.com X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 3 X-CTCH-SenderID-Total-Spam: 0 X-CTCH-SenderID-Total-Suspected: 0 Subject: [domainrep] template formats X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 21:06:53 -0000 This is a multi-part message in MIME format. --------------090502080500040608060501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, (Again from off-list conversations with Murray) May I ask if there is a format for the template, located at the well-known URI? There have been references to a draft on this I think - but one is not available on the ietf site? - extract from conversation with Murray: "That's what the well-known URI is for. Your vocabulary names all the required and optional parameters for the query. A service implementing your vocabulary puts a template at the well-known URI that tells a client how to form the query given those parameters and where to send it. Then the client fills in the template and issues the query. > - My expectation would be something like: > > https://logiq.com/sender_reputation/blackops.org/msk?ip=1.1.1.1&recip=steve > > .allam@trustsphere.com&direction=inbound&spf=pass > > or > > https://logiq.com/sender_reputation?ip=1.1.1.1&sender=msk@blackops.org&reci > > p=steve.allam@trustsphere.com&direction=inbound&spf=pass The current system supports either. You would just provide the template. In fact to switch from one to the other, the only thing that changes is the template; the client doesn't need any software changes. The server, of course, would need to know what format clients are about to start using. " and.... "Then when I go to repute.trustsphere.com and ask for the well-known URI, I get back: https://{service}/logiq.php{?subject,application,assertion,service,clientip,signer,custkey} " This line was new to me, in terms of knowing how to add parameters in the template - which document defines the template? [URI-TEMPLATE] is mentioned - is this available? Thanks, Steve - * Steve Allam | * Chief Technology Officer *| TrustSphere * 3 Phillip Street, #13-03 Commerce Point, Singapore, 048693 Tel: +65 6536 5203 | Fax: +65 6536 5463 steve.allam@trustsphere.com | www.trustsphere.com --------------090502080500040608060501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

(Again from off-list conversations with Murray)

May I ask if there is a format for the template, located at the well-known URI?  There have been references to a draft on this I think - but one is not available on the ietf site?

- extract from conversation with Murray:

"That's what the well-known URI is for.  Your vocabulary names all the required and optional parameters for the query.  A service implementing your vocabulary puts a template at the well-known URI that tells a client how to form the query given those parameters and where to send it.  Then the client fills in the template and issues the query.

- My expectation would be something like:

   https://logiq.com/sender_reputation/blackops.org/msk?ip=1.1.1.1&recip=steve
.allam@trustsphere.com&direction=inbound&spf=pass

or

   https://logiq.com/sender_reputation?ip=1.1.1.1&sender=msk@blackops.org&reci
p=steve.allam@trustsphere.com&direction=inbound&spf=pass

The current system supports either.  You would just provide the template. In fact to switch from one to the other, the only thing that changes is the template; the client doesn't need any software changes.  The server, of course, would need to know what format clients are about to start using. "

and....

"Then when I go to repute.trustsphere.com and ask for the well-known URI, I get back:

    https://{service}/logiq.php{?subject,application,assertion,service,clientip,signer,custkey}
"

This line was new to me, in terms of knowing how to add parameters in the template - which document defines the template?
[URI-TEMPLATE] is mentioned - is this available?


Thanks,

Steve


-

Steve Allam | Chief Technology Officer | TrustSphere

3 Phillip Street, #13-03 Commerce Point, Singapore, 048693
Tel: +65 6536 5203 | Fax: +65 6536 5463
 steve.allam@trustsphere.com | www.trustsphere.com
--------------090502080500040608060501-- From dcrocker@gmail.com Sat Mar 24 02:40:46 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D25A21F86FF for ; Sat, 24 Mar 2012 02:40:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQTntOiJqvY0 for ; Sat, 24 Mar 2012 02:40:45 -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 7DBDA21F86FC for ; Sat, 24 Mar 2012 02:40:45 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so2307384wib.13 for ; Sat, 24 Mar 2012 02:40:44 -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:x-priority:content-type:content-transfer-encoding; bh=M6vDSHnC0jRKV5g7lIFo+HXfl9ZONL4HIa24IBqrxoI=; b=XKo9K8PMdQ8zjR3oKWAJekoIPneX3WEpuY8TyChXjbI8mm2CXbLnYSmkKFed2BWJJt UvxY+2t+ZUUpCro42kf78iCv16TCHINSeh3D1lgcdpRhIq7gvRT09EJLG25VMbsTHYVz NKJDn4iYyj1juh2WBSkMiDGbL4Mc1VYGj1pg0OBBwnqpk8e9xgI+CqUj9uo1+FO7Qcae waVXl6StM/eKWyZZ2fR7NPuC17HHfwX934L/intOXF2u4nOEYDN8qtfuiSpHig+VZnmf etxLO4FG0YP49lQBi7RbwZgUQX1aYETSJ8QrYsaBC7fVJNCe78xUCfoxlhWnx/l0gr+D gedg== Received: by 10.180.103.134 with SMTP id fw6mr2881350wib.0.1332582044555; Sat, 24 Mar 2012 02:40:44 -0700 (PDT) Received: from [192.168.8.64] (ter75-1-81-57-68-77.fbx.proxad.net. [81.57.68.77]) by mx.google.com with ESMTPS id fw5sm21234822wib.0.2012.03.24.02.40.43 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Mar 2012 02:40:44 -0700 (PDT) Message-ID: <4F6D9697.8050301@gmail.com> Date: Sat, 24 Mar 2012 10:40:39 +0100 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Repute WG X-Priority: 2 (High) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [domainrep] Wed slot: what to cover? X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 09:40:46 -0000 Folks, We have a two-hour slot on Wednesday afternoon (1-3pm). We've had almost no list activity, except for several recent postings by one new participant. This does not bode well for the working group's utility or progress. There is plenty of fresh material to discuss and at least basic consensus that we ought to establish. It's simply not enough to have some diligent authors and a stray wg participant. (That's a slam on the rest of us, not that participant.) There needs to be a basis for showing sufficient community interest to justify assertions of consensus. And, oh yeah, there needs to be technical review sufficient to give confidence that the specifications are viable. These are the active drafts: draft-ietf-repute-model-01 A Model for Reputation Reporting draft-ietf-repute-email-identifiers-02 A Reputation Vocabulary for Email Identifiers draft-ietf-repute-media-type-01 A Media Type for Reputation Interchange draft-ietf-repute-query-http-01 Reputation Data Interchange using HTTP and XML As of now, I'm inclined to schedule a 10 minute slot for each document, for basic review, and 10 minutes for summarizing the JSON v. XML debate and then end the session and hour early. Obviously, short slots like that mean only the most superficial coverage. As of now, I don't see the working group warranting more time on any topic. Feel free to educate me otherwise. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From prvs=0430e2c1d7=steve.allam@trustsphere.com Sat Mar 24 05:34:29 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814C221F8718 for ; Sat, 24 Mar 2012 05:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.103 X-Spam-Level: X-Spam-Status: No, score=0.103 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_COM=0.311] 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 MIS0rBj+Iwuv for ; Sat, 24 Mar 2012 05:34:28 -0700 (PDT) Received: from st3.realmail-asp.co.uk (fe1.securerealmail.com [80.249.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id A1E7521F86D9 for ; Sat, 24 Mar 2012 05:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trustsphere.com; s=rmdkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=8wtKYAC7hJF1FjYyBFcSfO/tgcA9GnCkIO82E7DqgMw=; b=gnDohqNpswR6S0PtfbRvDLSQ+MBBjRxH76p6oSdKVhKhPoF0nhrLHFepNdOnlHsZyT62kUD/2aAR2MTIf0Cb73tgPRWSwJIemv7ulh70u02spdToR4kGA7PbQw4hQJTbr8GnNIG9IIvZFRyAPSI35WWOeHke2ps1OK92W+fC8LY=; Received: from [116.12.149.130] (helo=cgpro.boxsentry.com) by st3.realmail-asp.co.uk with esmtp id 1SBQAs-0001vz-U6 for domainrep@ietf.org; Sat, 24 Mar 2012 12:34:27 +0000 Received: by cgpro.boxsentry.com (CommuniGate Pro PIPE 5.4.0) with PIPE id 1913871; Sat, 24 Mar 2012 20:34:03 +0800 Received: from [88.97.130.81] (account steve.allam@trustsphere.com HELO joe90.imhotek.com) by cgpro.boxsentry.com (CommuniGate Pro SMTP 5.4.0) with ESMTPSA id 1913876 for domainrep@ietf.org; Sat, 24 Mar 2012 20:33:54 +0800 Message-ID: <4F6DBF18.70902@trustsphere.com> Date: Sat, 24 Mar 2012 12:33:28 +0000 From: Steve Allam User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <4F6D9697.8050301@gmail.com> In-Reply-To: <4F6D9697.8050301@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RMR-rmalert: true X-LogiQ-query: 116.12.149.130/steve.allam@trustsphere.com/domainrep@ietf.org (error socket failure) X-RealMail-Category: UNKNOWN/UNKNOWN X-RealMail-Ref: UNKNOWN/str=0001.0A0B0204.4F6DBF52.019D,ss=1,re=0.000,fgs=0 X-RealMail-IWF: NO X-CTCH-SenderID: steve.allam@trustsphere.com X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-Total-Spam: 0 X-CTCH-SenderID-Total-Suspected: 0 Subject: Re: [domainrep] Wed slot: what to cover? X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 12:34:29 -0000 Dave, Not a new participant at all, just a very infrequent poster!! I apologise for the dump of 5 messages at once, that's what happens on 13 hour flights! Regards, Steve On 03/24/2012 09:40 AM, Dave Crocker wrote: > Folks, > > We have a two-hour slot on Wednesday afternoon (1-3pm). > > We've had almost no list activity, except for several recent postings > by one new participant. > > This does not bode well for the working group's utility or progress. > There is plenty of fresh material to discuss and at least basic > consensus that we ought to establish. > > It's simply not enough to have some diligent authors and a stray wg > participant. (That's a slam on the rest of us, not that participant.) > > There needs to be a basis for showing sufficient community interest to > justify assertions of consensus. And, oh yeah, there needs to be > technical review sufficient to give confidence that the specifications > are viable. > > These are the active drafts: > > draft-ietf-repute-model-01 > A Model for Reputation Reporting > > draft-ietf-repute-email-identifiers-02 > A Reputation Vocabulary for Email Identifiers > > draft-ietf-repute-media-type-01 > A Media Type for Reputation Interchange > > draft-ietf-repute-query-http-01 > Reputation Data Interchange using HTTP and XML > > As of now, I'm inclined to schedule a 10 minute slot for each > document, for basic review, and 10 minutes for summarizing the JSON v. > XML debate and then end the session and hour early. > > Obviously, short slots like that mean only the most superficial > coverage. As of now, I don't see the working group warranting more > time on any topic. > > Feel free to educate me otherwise. > > d/ From msk@cloudmark.com Sat Mar 24 14:18:57 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE4921F84DA for ; Sat, 24 Mar 2012 14:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, 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 W+Xbhb8c0tVZ for ; Sat, 24 Mar 2012 14:18:56 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id BB7A521F84B2 for ; Sat, 24 Mar 2012 14:18:56 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Sat, 24 Mar 2012 14:18:51 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Thread-Topic: [domainrep] writing application vocabs Thread-Index: AQHNCTaj5FdvNfWEJEqpMc5Zd2+G+JZ5nv9g Date: Sat, 24 Mar 2012 21:18:51 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280B77A0@exch-mbx901.corp.cloudmark.com> References: <20120305162622.12099.38754.idtracker@ietfa.amsl.com> <4F6C26EF.20005@trustsphere.com> In-Reply-To: <4F6C26EF.20005@trustsphere.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.38.252.84] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] writing application vocabs X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 21:18:57 -0000 > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Steve Allam > Sent: Friday, March 23, 2012 12:32 AM > To: domainrep@ietf.org > Subject: [domainrep] writing application vocabs >=20 > All, >=20 > (What follows is derived from off-list conversation with Murray) For those that don't know, Steve's reputation service predates this work by= a couple of years. It is however largely coincidence that the method used= to issue queries to his service looks a lot like the URI templates stuff t= his work currently uses. The reply format is variable, which he describes = below. I'm glad he's piping up, because so far only my own implementation of the r= epute work exists, so this will help to vet the work. > My assumption is that application providers will write a vocab for their = application and register that vocab > with ietf - what is the feeling of the group to specific application rela= ted vocab, defining required > parameters for the application, versus a more generic vocab that uses min= imal required parameters, but allows > multiple extensions? This is an interesting question. I believe the vision is to have a vocabul= ary be essentially the registration of a particular kind of reputation, and= the things that are common to queries and replies when operating in that s= pace. I don't think the current work gives enough thought to publishing pr= oprietary extensions, but maybe that's okay. By that, I mean something lik= e: - email domain reputation is registered as an application, with what consen= sus feels is a basic (and optionally, an extended) parameter set for querie= s under that application - proprietary implementations of these need a way to explain to clients how= their queries and replies deviate from the registered vocabulary, but perh= aps this can't be standardized in protocol past some indication of this bei= ng the case > To be specific, our application is called LogiQ, and has a set of defined= parameters, as detailed in our > API.=A0 I can define a tight vocab based on this, or perhaps a more gener= ic vocab, for perhaps a more generic > relationship reputation application.=A0 For LogiQ, I would define require= d parameters of: >=A0- sender ip >=A0- sender address >=A0- recipient address > and a whole bunch of optional parameters.=A0 On the other hand, a more ge= neric application might not even require > those three parameters. > > Or, in fact, I could extend the email-id vocab by defining a new assertio= n of (perhaps)=A0 KNOWN-SENDER, and > simply require all my parameters as optional. >=20 > At the moment, I am looking to write an application vocab, but what ideas= /suggestions do others have? It seems like what you want to do would fit within "email-id" as we've got = it defined, perhaps with a few additional optional parameters registered. > I have similar concerns with the response,- I'm not sure my concerns are = well founded, but I'd rather not end > up having to respond with lots of xml elements (or JSON objec= ts!) - purely I think because it looks > messy - hence not being sure my concerns are well founded. > However, Murray's comment on the extension mechanism was that perhaps it = should be looked at again to ensure > people declare better vocabs Right, I think we should revisit the extension construct. I'm currently th= inking those should just be optional reply parameters on their own. For ex= ample, for "email-id", we could now say: IDENTITIY: DKIM Instead, I think "identity" should be registered on its own as an optional = reply parameter. That means the registry in media-type needs to be tweaked= to add that capability, replacing what we have now as extensions. This still doesn't answer the proprietary query/reply parameter extension q= uestion, but I think it's a bit cleaner than what we have now. -MSK From msk@cloudmark.com Sat Mar 24 14:18:57 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD65221F84B2 for ; Sat, 24 Mar 2012 14:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, 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 vgoczkCOSSAA for ; Sat, 24 Mar 2012 14:18:57 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7D67F21F84D1 for ; Sat, 24 Mar 2012 14:18:57 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Sat, 24 Mar 2012 14:18:56 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Thread-Topic: [domainrep] Murphy intervened Thread-Index: AQHNCTalZPJ2pTzAGEqgo49cSXTYFpZ5rSPg Date: Sat, 24 Mar 2012 21:18:55 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280B77A7@exch-mbx901.corp.cloudmark.com> References: <20120305162622.12099.38754.idtracker@ietfa.amsl.com> <20120305170429.GN76465@mail.yitter.info> <20120321141325.GD48500@mail.yitter.info> <4F6C229F.5040609@trustsphere.com> In-Reply-To: <4F6C229F.5040609@trustsphere.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.38.252.84] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Murphy intervened X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 21:18:58 -0000 > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Steve Allam > Sent: Friday, March 23, 2012 12:14 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] Murphy intervened >=20 > I have a question, not on the draft-ietf-repute-model-01.txt document its= elf, but how it is referred to in > vocabulary documents, for example - draft-ietf-repute-email-identifiers-0= 2 states: >=20 >=A0The "email-id" reputation application recognizes the following >=A0=A0 OPTIONAL extensions to the basic vocabulary defined in >=A0=A0 [I-D.REPUTE-MODEL]: >=20 > This implies that there is a basic vocab defined in the document.=A0 The = section 'Information represented in a > Response Set' defines some terms, such as 'the identity of the entity bei= ng rated', however, the document does > not define these further, although examples in the media-type doc describ= e 'RATED', which matches this > perhaps. >=20 >=20 > My questions are: >=20 > When writing a vocab, which document should be referred back to for the b= asic vocab, when describing > extensions? A vocabulary is self-defining with respect to what's required for all of th= em. What you're doing might be almost a copy of the "email-id" vocabulary,= which is why I'm thinking you might want to try extending that one to meet= your needs instead. > I have started writing a vocab for our reputation application, using the = email-id memo as a base > would anyone care to review when I have finished? Yes, please send it to the list. It would be a good vetting of the mechani= sm we have so far. -MSK From msk@cloudmark.com Sat Mar 24 14:18:59 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C8A21E801E for ; Sat, 24 Mar 2012 14:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, 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 gm9gzzRyKEqw for ; Sat, 24 Mar 2012 14:18:58 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6381821F84B2 for ; Sat, 24 Mar 2012 14:18:58 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Sat, 24 Mar 2012 14:18:57 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Thread-Topic: [domainrep] xml versus json Thread-Index: AQHNCTbC7/cgjkwFNky71YdJ/44C7JZ5rytw Date: Sat, 24 Mar 2012 21:18:57 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280B77AE@exch-mbx901.corp.cloudmark.com> References: <4F6C3104.40401@trustsphere.com> In-Reply-To: <4F6C3104.40401@trustsphere.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.38.252.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] xml versus json X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 21:18:59 -0000 > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Steve Allam > Sent: Friday, March 23, 2012 1:15 AM > To: domainrep@ietf.org > Subject: [domainrep] xml versus json >=20 > However, whilst we return XML, we don't POST xml as part of the query (to= o slow), we use GET params, so we use > a dirty form of soap :-) This lines up nicely with the query mechanism we've proposed here. Yay! > Given our experiences, I would thus tend more towards JSON - SOAP/XML wor= ks well as a 'standard', but JSON > works equally well and in my experience is much quicker to parse than XML= (certainly if you use drop-in > libraries). >=20 > XML gives the benefit of a schema however, closely defining your doc, whe= reas JSON can be much less well > defined,- however, the JSON spec is a one pager (I'd not looked at json.o= rg before - I liked it a lot), so as > long as the vocab definitions have a clear indication of how the JSON is = formed, I think it could be the > winner? It's been said lately that XML isn't all that useful for client-server soft= ware, but rather for editors to provide smart formatting. Clients and serv= ers will do their own validation of the content, so the availability of a s= chema doesn't help us that much. I'm less expert in such matters than othe= rs, but I know that both my XML and JSON implementations do their own check= ing of required content and syntax rather than relying on the schema. Inst= ead, the schema guides the code I write. -MSK From ajs@anvilwalrusden.com Sun Mar 25 07:47:11 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E90321F84AA for ; Sun, 25 Mar 2012 07:47:11 -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 XALEallHpqTa for ; Sun, 25 Mar 2012 07:47:10 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 085DF21F84C2 for ; Sun, 25 Mar 2012 07:47:09 -0700 (PDT) Received: from mail.yitter.info (unknown [83.145.64.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2F0A01ECB420 for ; Sun, 25 Mar 2012 14:47:09 +0000 (UTC) Date: Sun, 25 Mar 2012 10:47:09 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20120325144709.GE2517@mail.yitter.info> References: <4F6D9697.8050301@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F6D9697.8050301@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [domainrep] Wed slot: what to cover? X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 14:47:11 -0000 On Sat, Mar 24, 2012 at 10:40:39AM +0100, Dave Crocker wrote: > Folks, > > We have a two-hour slot on Wednesday afternoon (1-3pm). > > We've had almost no list activity, except for several recent > postings by one new participant. In my defence, I did in fact post, "This is what I think as editor. Please object." We appear now to have one substantive question, which appears to be about back-references to the document. I will cheerfully accept the task to add the requisite text, and I'm not looking for others to provide the text -- I'll do that. But I do need people to say, "Yeah, read it, he's right," or, "No, I disagree." (This may be a +1 to Dave's prod from the chair for comments.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From prvs=0431d35d73=steve.allam@trustsphere.com Sun Mar 25 13:40:40 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010C921E801A for ; Sun, 25 Mar 2012 13:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[AWL=1.580, 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 dfG-022A+teq for ; Sun, 25 Mar 2012 13:40:39 -0700 (PDT) Received: from st2.realmail-asp.co.uk (st2.realmail-asp.co.uk [80.249.100.228]) by ietfa.amsl.com (Postfix) with ESMTP id BDBAA21E800C for ; Sun, 25 Mar 2012 13:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trustsphere.com; s=rmdkim; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=jgCL2bMNxQFw2kb0rU6T96I7VJCgw3lmihRlhcTi9Ag=; b=fXlkfLtMERklu+yvZ6aFc1rTwYG4HRbijq1RASNutcGrv0pAuL10qM2bSHUw+bg3SRxT3ZCa1HZGyCdzWeKZT3ANTyv3dYAhZzudpWdBhhG/BTx07F4dsKtZzA1ws+KtoAhwsoB/5NTtQmkDfkMtkj2fPvIY8EzDvZn8GGxY4bo=; Received: from [116.12.149.130] (helo=cgpro.boxsentry.com) by st2.realmail-asp.co.uk with esmtp id 1SBuEu-0003Xb-SB for domainrep@ietf.org; Sun, 25 Mar 2012 21:40:37 +0100 Received: by cgpro.boxsentry.com (CommuniGate Pro PIPE 5.4.0) with PIPE id 1914314; Mon, 26 Mar 2012 04:40:53 +0800 Received: from [88.97.130.81] (account steve.allam@trustsphere.com HELO [10.1.1.32]) by cgpro.boxsentry.com (CommuniGate Pro SMTP 5.4.0) with ESMTPSA id 1914313 for domainrep@ietf.org; Mon, 26 Mar 2012 04:40:41 +0800 Message-ID: <4F6F82B3.9040408@trustsphere.com> Date: Sun, 25 Mar 2012 21:40:19 +0100 From: Steve Allam User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <20120305162622.12099.38754.idtracker@ietfa.amsl.com> <20120305170429.GN76465@mail.yitter.info> <20120321141325.GD48500@mail.yitter.info> <4F6C229F.5040609@trustsphere.com> <9452079D1A51524AA5749AD23E0039280B77A7@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280B77A7@exch-mbx901.corp.cloudmark.com> Content-Type: multipart/alternative; boundary="------------070603010401080204030309" X-RMR-rmalert: true X-LogiQ-query: 116.12.149.130/steve.allam@trustsphere.com/domainrep@ietf.org (I000 OK UNKNOWN.EXISTS ) X-RealMail-Category: UNKNOWN/UNKNOWN X-RealMail-Ref: UNKNOWN/str=0001.0A0B0204.4F6F82C5.00A5,ss=1,re=0.000,fgs=0 X-RealMail-IWF: NO X-CTCH-SenderID: steve.allam@trustsphere.com X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-Total-Spam: 0 X-CTCH-SenderID-Total-Suspected: 0 Subject: Re: [domainrep] Murphy intervened X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 20:40:40 -0000 This is a multi-part message in MIME format. --------------070603010401080204030309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Murray, Ok - I will work further on the vocab I am defining and post to the list! Thanks, Steve On 24/03/2012 9:18 PM, Murray S. Kucherawy wrote: >> From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Behalf Of Steve Allam >> Sent: Friday, March 23, 2012 12:14 AM >> To: domainrep@ietf.org >> Subject: Re: [domainrep] Murphy intervened >> >> I have a question, not on the draft-ietf-repute-model-01.txt document itself, but how it is referred to in >> vocabulary documents, for example - draft-ietf-repute-email-identifiers-02 states: >> >> The "email-id" reputation application recognizes the following >> OPTIONAL extensions to the basic vocabulary defined in >> [I-D.REPUTE-MODEL]: >> >> This implies that there is a basic vocab defined in the document. The section 'Information represented in a >> Response Set' defines some terms, such as 'the identity of the entity being rated', however, the document does >> not define these further, although examples in the media-type doc describe 'RATED', which matches this >> perhaps. >> >> >> My questions are: >> >> When writing a vocab, which document should be referred back to for the basic vocab, when describing >> extensions? > A vocabulary is self-defining with respect to what's required for all of them. What you're doing might be almost a copy of the "email-id" vocabulary, which is why I'm thinking you might want to try extending that one to meet your needs instead. > >> I have started writing a vocab for our reputation application, using the email-id memo as a base >> would anyone care to review when I have finished? > Yes, please send it to the list. It would be a good vetting of the mechanism we have so far. > > -MSK > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep -- * Steve Allam | * Chief Technology Officer *| TrustSphere * 3 Phillip Street, #13-03 Commerce Point, Singapore, 048693 Tel: +65 6536 5203 | Fax: +65 6536 5463 steve.allam@trustsphere.com | www.trustsphere.com --------------070603010401080204030309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Murray,

Ok - I will work further on the vocab I am defining and post to the list!

Thanks,

Steve

On 24/03/2012 9:18 PM, Murray S. Kucherawy wrote: 
From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Behalf Of Steve Allam
Sent: Friday, March 23, 2012 12:14 AM
To: domainrep@ietf.org
Subject: Re: [domainrep] Murphy intervened

I have a question, not on the draft-ietf-repute-model-01.txt document itself, but how it is referred to in
vocabulary documents, for example - draft-ietf-repute-email-identifiers-02 states:

 The "email-id" reputation application recognizes the following
   OPTIONAL extensions to the basic vocabulary defined in
   [I-D.REPUTE-MODEL]:

This implies that there is a basic vocab defined in the document.  The section 'Information represented in a
Response Set' defines some terms, such as 'the identity of the entity being rated', however, the document does
not define these further, although examples in the media-type doc describe 'RATED', which matches this
perhaps.


My questions are:

When writing a vocab, which document should be referred back to for the basic vocab, when describing
extensions?

A vocabulary is self-defining with respect to what's required for all of them.  What you're doing might be almost a copy of the "email-id" vocabulary, which is why I'm thinking you might want to try extending that one to meet your needs instead.


I have started writing a vocab for our reputation application, using the email-id memo as a base
would anyone care to review when I have finished?

Yes, please send it to the list.  It would be a good vetting of the mechanism we have so far.

-MSK
_______________________________________________
domainrep mailing list
domainrep@ietf.org
https://www.ietf.org/mailman/listinfo/domainrep

--

Steve Allam | Chief Technology Officer | TrustSphere

3 Phillip Street, #13-03 Commerce Point, Singapore, 048693
Tel: +65 6536 5203 | Fax: +65 6536 5463
 steve.allam@trustsphere.com | www.trustsphere.com
--------------070603010401080204030309-- From prvs=0431d35d73=steve.allam@trustsphere.com Sun Mar 25 13:47:52 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83B421E802C for ; Sun, 25 Mar 2012 13:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_COM=0.311, 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 eYRf8ZTBCHJk for ; Sun, 25 Mar 2012 13:47:51 -0700 (PDT) Received: from st3.realmail-asp.co.uk (fe1.securerealmail.com [80.249.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4CC21E801A for ; Sun, 25 Mar 2012 13:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trustsphere.com; s=rmdkim; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=9DM6SvNiOT0ZtkYa+xPIE9+x2mpeLL4Dbd3bsjl3z90=; b=K9A3U9qF7TqwaGa0LwvMTqi+zJIXVHEp+mcElPKNPH7yzCYgaxEYl4qx9/hnkoUzpaPVMhc794l6/D+3R2Hq8eBgJdar4PXIFhif2eKRYaXLBJjz5MqD/TgEwFcyYMOi/gcTeHZ/zGR4pFAL8YzlWetpkgeXTar4KIu5+mJWIUw=; Received: from [116.12.149.130] (helo=cgpro.boxsentry.com) by st3.realmail-asp.co.uk with esmtp id 1SBuLr-0004hX-T8 for domainrep@ietf.org; Sun, 25 Mar 2012 21:47:49 +0100 Received: by cgpro.boxsentry.com (CommuniGate Pro PIPE 5.4.0) with PIPE id 1914320; Mon, 26 Mar 2012 04:47:23 +0800 Received: from [88.97.130.81] (account steve.allam@trustsphere.com HELO [10.1.1.32]) by cgpro.boxsentry.com (CommuniGate Pro SMTP 5.4.0) with ESMTPSA id 1914300 for domainrep@ietf.org; Mon, 26 Mar 2012 04:47:19 +0800 Message-ID: <4F6F8441.9080703@trustsphere.com> Date: Sun, 25 Mar 2012 21:46:57 +0100 From: Steve Allam User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <4F6C3104.40401@trustsphere.com> <9452079D1A51524AA5749AD23E0039280B77AE@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280B77AE@exch-mbx901.corp.cloudmark.com> Content-Type: multipart/alternative; boundary="------------080401010903070302080805" X-RMR-rmalert: true X-LogiQ-query: 116.12.149.130/steve.allam@trustsphere.com/domainrep@ietf.org (error socket failure) X-RealMail-Category: UNKNOWN/UNKNOWN X-RealMail-Ref: UNKNOWN/str=0001.0A0B020B.4F6F8475.0030,ss=1,re=0.000,fgs=0 X-RealMail-IWF: NO X-CTCH-SenderID: steve.allam@trustsphere.com X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-Total-Spam: 0 X-CTCH-SenderID-Total-Suspected: 0 Subject: Re: [domainrep] xml versus json X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 20:47:53 -0000 This is a multi-part message in MIME format. --------------080401010903070302080805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Murray, I note that there is a JSON schema (expired) draft ietf document here: http://tools.ietf.org/html/draft-zyp-json-schema-03 - just to make a simple thing more complicated.... Regards, Steve On 24/03/2012 9:18 PM, Murray S. Kucherawy wrote: >> From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Behalf Of Steve Allam >> Sent: Friday, March 23, 2012 1:15 AM >> To: domainrep@ietf.org >> Subject: [domainrep] xml versus json >> >> However, whilst we return XML, we don't POST xml as part of the query (too slow), we use GET params, so we use >> a dirty form of soap :-) > This lines up nicely with the query mechanism we've proposed here. Yay! > >> Given our experiences, I would thus tend more towards JSON - SOAP/XML works well as a 'standard', but JSON >> works equally well and in my experience is much quicker to parse than XML (certainly if you use drop-in >> libraries). >> >> XML gives the benefit of a schema however, closely defining your doc, whereas JSON can be much less well >> defined,- however, the JSON spec is a one pager (I'd not looked at json.org before - I liked it a lot), so as >> long as the vocab definitions have a clear indication of how the JSON is formed, I think it could be the >> winner? > It's been said lately that XML isn't all that useful for client-server software, but rather for editors to provide smart formatting. Clients and servers will do their own validation of the content, so the availability of a schema doesn't help us that much. I'm less expert in such matters than others, but I know that both my XML and JSON implementations do their own checking of required content and syntax rather than relying on the schema. Instead, the schema guides the code I write. > > -MSK > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep -- * Steve Allam | * Chief Technology Officer *| TrustSphere * 3 Phillip Street, #13-03 Commerce Point, Singapore, 048693 Tel: +65 6536 5203 | Fax: +65 6536 5463 steve.allam@trustsphere.com | www.trustsphere.com --------------080401010903070302080805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Murray,

I note that there is a JSON schema (expired) draft ietf document here:
   http://tools.ietf.org/html/draft-zyp-json-schema-03

 - just to make a simple thing more complicated....

Regards,

Steve

On 24/03/2012 9:18 PM, Murray S. Kucherawy wrote: 
From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Behalf Of Steve Allam
Sent: Friday, March 23, 2012 1:15 AM
To: domainrep@ietf.org
Subject: [domainrep] xml versus json

However, whilst we return XML, we don't POST xml as part of the query (too slow), we use GET params, so we use
a dirty form of soap :-)

This lines up nicely with the query mechanism we've proposed here.  Yay!


Given our experiences, I would thus tend more towards JSON - SOAP/XML works well as a 'standard', but JSON
works equally well and in my experience is much quicker to parse than XML (certainly if you use drop-in
libraries).

XML gives the benefit of a schema however, closely defining your doc, whereas JSON can be much less well
defined,- however, the JSON spec is a one pager (I'd not looked at json.org before - I liked it a lot), so as
long as the vocab definitions have a clear indication of how the JSON is formed, I think it could be the
winner?

It's been said lately that XML isn't all that useful for client-server software, but rather for editors to provide smart formatting.  Clients and servers will do their own validation of the content, so the availability of a schema doesn't help us that much.  I'm less expert in such matters than others, but I know that both my XML and JSON implementations do their own checking of required content and syntax rather than relying on the schema.  Instead, the schema guides the code I write.

-MSK
_______________________________________________
domainrep mailing list
domainrep@ietf.org
https://www.ietf.org/mailman/listinfo/domainrep

--

Steve Allam | Chief Technology Officer | TrustSphere

3 Phillip Street, #13-03 Commerce Point, Singapore, 048693
Tel: +65 6536 5203 | Fax: +65 6536 5463
 steve.allam@trustsphere.com | www.trustsphere.com
--------------080401010903070302080805-- From raz@raz.cx Mon Mar 26 05:47:00 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18A521E8097 for ; Mon, 26 Mar 2012 05:47: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=[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 9LzwM8cCa3Gd for ; Mon, 26 Mar 2012 05:47:00 -0700 (PDT) Received: from baldrick.raz.cx (baldrick.raz.cx [80.68.88.67]) by ietfa.amsl.com (Postfix) with ESMTP id F185321E8096 for ; Mon, 26 Mar 2012 05:46:56 -0700 (PDT) Received: from [218.212.130.184] (helo=[10.1.132.100]) by baldrick.raz.cx with esmtp (Exim 3.36 #1 (Debian)) id 1SC9K1-0004D0-00 for ; Mon, 26 Mar 2012 12:46:53 +0000 Message-ID: <4F70653B.5020004@raz.cx> Date: Mon, 26 Mar 2012 20:46:51 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: "domainrep@ietf.org" References: <4F6C3104.40401@trustsphere.com> <9452079D1A51524AA5749AD23E0039280B77AE@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280B77AE@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] xml versus json X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 12:47:01 -0000 On 25/03/2012 05:18, Murray S. Kucherawy wrote: > It's been said lately that XML isn't all that useful for client-server software, but rather for editors to provide smart formatting. I saw a comment to this effect after your recent implementation comparison and I've chewed it over for a while. I'm starting to lean towards JSON is a better choice than XML is for communicating data structures, in particular because of the mess around dealing with whitespace in XML, itself a consequence of XML being a text mark-up language rather than a data structure representation one. (There are correct solutions of course, but converging on them takes time; JSON avoids this problem entirely, not merely because the libraries are newer but because it's not built as marked-up text to begin with.) - Roland From ietf@meetecho.com Tue Mar 27 07:45:13 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DAB21E820B for ; Tue, 27 Mar 2012 07:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.915 X-Spam-Level: X-Spam-Status: No, score=-0.915 tagged_above=-999 required=5 tests=[AWL=-0.196, 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 HOri+xbX10on for ; Tue, 27 Mar 2012 07:45:12 -0700 (PDT) Received: from smtplq01.aruba.it (smtplqs-out27.aruba.it [62.149.158.67]) by ietfa.amsl.com (Postfix) with SMTP id 7E1A521E8207 for ; Tue, 27 Mar 2012 07:45:10 -0700 (PDT) Received: (qmail 10647 invoked by uid 89); 27 Mar 2012 14:45:08 -0000 Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq01.aruba.it with SMTP; 27 Mar 2012 14:45:08 -0000 Received: (qmail 8545 invoked by uid 89); 27 Mar 2012 14:45:08 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp8.ad.aruba.it with SMTP; 27 Mar 2012 14:45:08 -0000 Message-ID: <4F71D272.4060708@meetecho.com> Date: Tue, 27 Mar 2012 16:45:06 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: domainrep@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp8.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: [domainrep] Meetecho support for REPUTE WG meeting session X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:45:13 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Wednesday's REPUTE WG meeting session. Access to the on-line session (including audio and video streams) will be available at: http://www.meetecho.com/ietf83/repute The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room, if they want to, by either calling a landline phone number, or using our embedded VoIP applet (in this last case they are *strongly* advised to use a headset). A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf83/tutorials Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From dcrocker@gmail.com Tue Mar 27 22:30:59 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8233D21E80A9 for ; Tue, 27 Mar 2012 22:30:59 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ+ILTF5iC2G for ; Tue, 27 Mar 2012 22:30:58 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA3421E8047 for ; Tue, 27 Mar 2012 22:30:58 -0700 (PDT) Received: by eeke51 with SMTP id e51so153071eek.31 for ; Tue, 27 Mar 2012 22:30:57 -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:content-type:content-transfer-encoding; bh=DI4ADdxq1Gs/bxLmQyGWJfTVoIA3ugjUw7n0QkddxdY=; b=CbXEhfhNLafwL17+6xN9b9TT4tHAAgUA3ks7PIURsxMgKW4+SkrqIRIkBICpvE8FsT L1zgChVtddOo4LnTD/8onOnWqr6yOzKXLXcZF5NvufJMSldQsZqf+ezWM7+FMGwyX3pR bcTwbZKw/DxAmUpk3AooDmQreCwcL9akAb/v4qtJCs5b9DyZarfYyGVuYb1mSILPSuzC Bz6YK3CM7XUQn3MJxdu0cjXX+WA8YRqV7x8YjETn9nHPmUst4UvyKAM8vE3kxyQw3555 uZK15uxgHZhbrEAwD/lB1w4dYxmz47d8ZVpKDr9elh85Pokw9+7G9sPsQMYlehLH3Ooe lZgg== Received: by 10.14.125.4 with SMTP id y4mr3776927eeh.56.1332912657625; Tue, 27 Mar 2012 22:30:57 -0700 (PDT) Received: from ?IPv6:2001:df8:0:80:3cef:ffe2:96cb:45cf? ([2001:df8:0:80:3cef:ffe2:96cb:45cf]) by mx.google.com with ESMTPS id d54sm6492610eei.9.2012.03.27.22.30.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 22:30:56 -0700 (PDT) Message-ID: <4F72A20D.1000602@gmail.com> Date: Wed, 28 Mar 2012 07:30:53 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Murray Kucherawy , "domainrep@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [domainrep] email vocabulary / draft-ietf-repute-email-identifiers-02 X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 05:30:59 -0000 draft-ietf-repute-email-identifiers-02 Just to add some grist, possibly for the meeting... > IDENTITY: A token indicating the source of the identifier; that is, > where the subject identifier was found in the message. This MUST > be one of: Is there any utility in defining RFC5321.HELO ? Same question for RFC5321.Sender... > RATE: A token that recommends an overall message acceptance rate for > the subject domain. This is expected to be a value tailored to > the requesting agent; for example, the reputation service would > use this to indicate that, based on the data reported by the > requesting agent, the service recommends a particular message > limit for that agent. The value is an unsigned decimal value. "tailored to the requesting agent" cooupled with "unsigned decimal value" essentially means there is no standardization to this. Having a standardized label without a standardized meaning associated to it -- where 'meaning' is in the definition of the value -- isn't really standardization. > A reply that does not contain the IDENTITY or SOURCES extensions is > making a non-specific statement about how the reputation returned was > developed. It sounds as if they are making no statement at all about the 'development' of the reputation. Or perhaps I'm misunderstanding what is meant by development. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dcrocker@gmail.com Tue Mar 27 22:31:10 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C9A21E80C0 for ; Tue, 27 Mar 2012 22:31:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coQFxg80p+ON for ; Tue, 27 Mar 2012 22:31:10 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F21521E8088 for ; Tue, 27 Mar 2012 22:31:09 -0700 (PDT) Received: by eaaq11 with SMTP id q11so147184eaa.31 for ; Tue, 27 Mar 2012 22:31:08 -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:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aBqH0BGyjdrHTcNtvngOeeQZxX5uVwRdrb0UQ0C5WOo=; b=qJ44/fmvDdvfQ75xXIrhWpmirXjgeqy4mXlZZkUfn2jTjSwOgmS3HH/pNvhzAA+8Bb /kHy9aQw784AZWKiobDVpapoGE4KoHphNAO2TvzFZrRGo8cBAyNsNAvzkAD4SXf5iAD+ JI/+egITgJATizF8UseongpYW+OWKt358SkL+fjTUNZKAJz2P4FsyMvSJufgm3Kbv9Tp YLJM5wiFSZCvFmL+s0uUB9SFqzA+guTUk0SnwUpYXIQurK3jqbJxDW2BGHIkhZMKXnoT 7y05usVBC4LKDVQBKOVxWAxG3El3FL/4peTNVHrrWwdxK/1a8UmSypoQTTGglQ9TtXQF QwgA== Received: by 10.213.22.147 with SMTP id n19mr1941753ebb.147.1332912668800; Tue, 27 Mar 2012 22:31:08 -0700 (PDT) Received: from ?IPv6:2001:df8:0:80:3cef:ffe2:96cb:45cf? ([2001:df8:0:80:3cef:ffe2:96cb:45cf]) by mx.google.com with ESMTPS id q45sm6514371eem.7.2012.03.27.22.31.07 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 22:31:08 -0700 (PDT) Message-ID: <4F72A219.60202@gmail.com> Date: Wed, 28 Mar 2012 07:31:05 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Murray Kucherawy References: <4F7290BF.5040508@dcrocker.net> In-Reply-To: <4F7290BF.5040508@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "domainrep@ietf.org" Subject: Re: [domainrep] email vocabulary / draft-ietf-repute-email-identifiers-02 X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 05:31:10 -0000 On 3/28/2012 6:17 AM, Dave Crocker wrote: > draft-ietf-repute-email-identifiers-02 just realized one more change is needed: vocabulary -> response set the terminology changed in the latest -model doc. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Wed Mar 28 00:27:35 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A1621F851B for ; Wed, 28 Mar 2012 00:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, 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 6zmyC5iW5cum for ; Wed, 28 Mar 2012 00:27:35 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 20FCB21F851A for ; Wed, 28 Mar 2012 00:27:35 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 28 Mar 2012 00:27:34 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Thread-Topic: email vocabulary / draft-ietf-repute-email-identifiers-02 Thread-Index: AQHNDJmoq8WbZNyCFUeyeXiU+mhD1ZZ/mikA//+04XA= Date: Wed, 28 Mar 2012 07:27:33 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280BCEB8@exch-mbx901.corp.cloudmark.com> References: <4F7290BF.5040508@dcrocker.net> <4F7299C6.9060709@dcrocker.net> In-Reply-To: <4F7299C6.9060709@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.23.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] email vocabulary / draft-ietf-repute-email-identifiers-02 X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:27:35 -0000 > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net] > Sent: Tuesday, March 27, 2012 9:56 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: email vocabulary / draft-ietf-repute-email-identifiers-02 >=20 > On 3/28/2012 6:17 AM, Dave Crocker wrote: > > draft-ietf-repute-email-identifiers-02 >=20 > just realized one more change is needed: >=20 > vocabulary -> response set >=20 > the terminology changed in the latest -model doc. Right; I'll probably update my three documents after this meeting to includ= e various updates. (Someone noticed, for example, that the Abstract of the= query-http document talks about storing reputation in the DNS.) -MSK From R.E.Sonneveld@sonnection.nl Wed Mar 28 03:53:04 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63E121F8960 for ; Wed, 28 Mar 2012 03:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 Z2bjSd5ZR7pA for ; Wed, 28 Mar 2012 03:53:03 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 92F5621F894A for ; Wed, 28 Mar 2012 03:53:03 -0700 (PDT) Received: from process-dkim-sign-daemon.helium.mailtransaction.com by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0M1L00800CWDRK00@helium.mailtransaction.com>; Wed, 28 Mar 2012 12:53:01 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0M1L00703CWB7M00@helium.mailtransaction.com>; Wed, 28 Mar 2012 12:53:00 +0200 (CEST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gudZmQ35eN3FZ5pACIruZw)" Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0M1L0073ZCW8ZZ00@lion.sonnection.nl> for domainrep@ietf.org; Wed, 28 Mar 2012 12:52:56 +0200 (CEST) Message-id: <4F72EF21.3070107@sonnection.nl> Date: Wed, 28 Mar 2012 12:59:45 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Dave Crocker References: <4F72A20D.1000602@gmail.com> In-reply-to: <4F72A20D.1000602@gmail.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1332931981; bh=GdeUsM0fSxxZfO1LuPof2zHr6eR4Y31PnEJA+PxefhQ=; h=MIME-version:Content-type:Message-id:Date:From:To:Cc:Subject: References:In-reply-to; b=cEXngIoSR/jRlJEX/Hk49wXCxt9pvpxzKLf/khVelGwQQ5uJqprj3FvDVGGXLAr/L S4PwEZGfnVr3wHIQFGgseKc0hro/thdSilsdHjasxRMT8KmfJE3NW7d3qjQU3/02MO jzgtbEa/gr9w4A3g6IV9c6Rs5Y6qP8FYI2bQJd2Q= X-DKIM: OpenDKIM Filter v2.4.3 helium.mailtransaction.com 0M1L00800CWDRK00 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] email vocabulary / draft-ietf-repute-email-identifiers-02 X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:53:05 -0000 This is a multi-part message in MIME format. --Boundary_(ID_gudZmQ35eN3FZ5pACIruZw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On 3/28/12 7:30 AM, Dave Crocker wrote: > draft-ietf-repute-email-identifiers-02 > > > > Just to add some grist, possibly for the meeting... > > >> IDENTITY: A token indicating the source of the identifier; that is, >> where the subject identifier was found in the message. Maybe the phrase "[...] was found in the message" should be rephrased, as some of the identifiers mentioned in the list, are not part of the message but are part of the envelope (RFC5321.MailFrom) or part of the SMTP session (RFC5321.EHLO) or part of the transmission path (IPv4, IPv6). >> This MUST >> be one of: > > Is there any utility in defining RFC5321.HELO ? I don't think so for the following reason. There are two scenario's for the HELO/EHLO parameter: * the parameter matches via the source IP address of the connection (either via a DNS A/AAAA/CNAME or directly if the parameter itself is an IP address) with the IP address * the other scenario is, that it doesn't match the source IP address In scenario 1, the HELO/EHLO parameter identity doesn't add any value to the IP address, that is already known from the connection. In scenario 2, there's little we can say about the authenticity of the identifier On the other hand... The key question here is: when is a part of a message (or transmission) suitable to be used as an identifier? What criteria do apply? In theory any of the identifiers mentioned in paragraph 4.1.4 of RFC5598 are candidates to be used here. However, some of them are not easily verifiable. Do we exempt them from the list of 'MUST be one of...' or do we add an additional phrase to the MUST like: "This MUST be one of [...] and MAY be one of the identifiers mentioned in par. 4.1.4 of RFC5598" leaving the _authentication part of the puzzle_ to the reputation client, that may have specific information about the level of trust they have in the part of the message they want to use as an identifier. > Same question for RFC5321.Sender... I assume, you mean RFC5322.Sender? /rolf --Boundary_(ID_gudZmQ35eN3FZ5pACIruZw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 3/28/12 7:30 AM, Dave Crocker wrote:
draft-ietf-repute-email-identifiers-02



Just to add some grist, possibly for the meeting...


IDENTITY:  A token indicating the source of the identifier; that is,
      where the subject identifier was found in the message.

Maybe the phrase "[...] was found in the message" should be rephrased, as some of the identifiers mentioned in the list, are not part of the message but are part of the envelope (RFC5321.MailFrom) or part of the SMTP session (RFC5321.EHLO) or part of the transmission path (IPv4, IPv6).

  This MUST
      be one of:

Is there any utility in defining RFC5321.HELO ?

I don't think so for the following reason. There are two scenario's for the HELO/EHLO parameter:

  • the parameter matches via the source IP address of the connection (either via a DNS A/AAAA/CNAME or directly if the parameter itself is an IP address) with the IP address
  • the other scenario is, that it doesn't match the source IP address


In scenario 1, the HELO/EHLO parameter identity doesn't add any value to the IP address, that is already known from the connection.
In scenario 2, there's little we can say about the authenticity of the identifier

On the other hand...

The key question here is: when is a part of a message (or transmission) suitable to be used as an identifier? What criteria do apply? In theory any of the identifiers mentioned in paragraph 4.1.4 of RFC5598 are candidates to be used here. However, some of them are not easily verifiable. Do we exempt them from the list of 'MUST be one of...' or do we add an additional phrase to the MUST like:

"This MUST be one of [...]

and MAY be one of the identifiers mentioned in par. 4.1.4 of RFC5598"

leaving the _authentication part of the puzzle_ to the reputation client, that may have specific information about the level of trust they have in the part of the message they want to use as an identifier.

Same question for RFC5321.Sender...

I assume, you mean RFC5322.Sender?

/rolf
--Boundary_(ID_gudZmQ35eN3FZ5pACIruZw)-- From clewis+ietf@mustelids.ca Wed Mar 28 05:51:38 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F8821E81EF for ; Wed, 28 Mar 2012 05:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.786 X-Spam-Level: X-Spam-Status: No, score=0.786 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_50=0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 dESjvtAb6T2C for ; Wed, 28 Mar 2012 05:51:37 -0700 (PDT) Received: from mail.mustelids.ca (unknown [174.35.130.2]) by ietfa.amsl.com (Postfix) with ESMTP id 222FD21E81E6 for ; Wed, 28 Mar 2012 05:51:37 -0700 (PDT) Received: from [192.168.0.8] (otter.mustelids.ca [192.168.0.8]) (authenticated bits=0) by mail.mustelids.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2SCpVsw007844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 28 Mar 2012 08:51:31 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 mail.mustelids.ca q2SCpVsw007844 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mustelids.ca; s=default.private; t=1332939091; bh=uSUCSoqtldGUzfSeuHBg0vw7tyoclxyhu5VYMy8/mpg=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=Vg4k3jwiNGPmaYuBL8MWkAq1Zkwa2mop3eDjaZrm0NTn2TDIOQ6xnftrRKrvh29GB z6vQXsPiqVx2LtrRf8XG/HTp1+uzY9dcZYjmbcgmYUcPd2O4IQEcQvnPqTL9ciHxXT h73m1Q/Emf/N3Il2dtjNi13ZGs+CHUpXPC/zx4Xk= Message-ID: <4F730953.4080009@mustelids.ca> Date: Wed, 28 Mar 2012 08:51:31 -0400 From: Chris Lewis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: "domainrep@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [domainrep] Remarks from Paris: X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:51:38 -0000 My first remark was regarding query templates: It's a common problem with public DNSBLs that queries are malformed from the very beginning, and there's generally no way (or at least polite way) to get them fixed - they just keep pounding away with ineffective/useless queries. Once a service like this is configured at the client end, it tends to be forgotten, and if the admin leaves... Templates would go a long way to avoid that happening from the start. Second: When you query a domain, it would often be useful to get a reputation score back both for where the domain is authenticated, and where it isn't authenticated. This can help spam filtering engines apply probabilities not only for the case where the domain owner does authenticate normally and it's being spoofed, as well as when it's never authenticated. Use cases: a) NACHA (and IRS/DHS/DHL/USPS/UPS/FBI/et al.) spoofs that try to inject Zeus infectors. Absolutely ridiculous volumes of these going on now. Big problem everywhere. Knowing that an authenticated NACHA email is probably good, and an unauthenticated NACHA email should be treated as a plague carrier would be good. b) Even if the domain doesn't "do" authentication, being able to supply reputation on a domain greatly broadens the applicability/usefulness of a reputation service. Eg: if you start getting spoofed like NACHA does, the only way to get a good reputation for _your_ email is to start authenticating. Without the existence of both A/!A reputation there's little incentive. From R.E.Sonneveld@sonnection.nl Wed Mar 28 06:26:50 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23DF21E80BA for ; Wed, 28 Mar 2012 06:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.624 X-Spam-Level: X-Spam-Status: No, score=-3.624 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 mFsTx+NZU6SS for ; Wed, 28 Mar 2012 06:26:50 -0700 (PDT) Received: from mx11.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id B78A821F8861 for ; Wed, 28 Mar 2012 06:26:49 -0700 (PDT) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0M1L00L00JR7UL00@hydrogen.mailtransaction.com>; Wed, 28 Mar 2012 15:26:47 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0M1L0039CK0JT000@hydrogen.mailtransaction.com>; Wed, 28 Mar 2012 15:26:46 +0200 (CEST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0M1L0074LK0IZZ00@lion.sonnection.nl> for domainrep@ietf.org; Wed, 28 Mar 2012 15:26:42 +0200 (CEST) Message-id: <4F73132C.5060404@sonnection.nl> Date: Wed, 28 Mar 2012 15:33:32 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Chris Lewis References: <4F730953.4080009@mustelids.ca> In-reply-to: <4F730953.4080009@mustelids.ca> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1332941207; bh=+YXY4rpFS0pT17wa0FlhTDdYNx2VVVc4vCfIFZLYa0o=; h=MIME-version:Content-transfer-encoding:Content-type:Message-id: Date:From:To:Cc:Subject:References:In-reply-to; b=SZY6YMxL2QOsdF7SZIr7VomPWYU4Hzh9tf3ZXR/NqLsMsog+4n/sSqg3v8y8HvVx2 9sMv9gaNe7Ul+6YzFZ8Fh5ZUOrSvRqfSQ87irjMOi7B7HME853HwvKIZwiUjLn9q1/ IkD4HVgl1nXRRlXHDZd0ZkGC6GT5GrympPLOsaUY= X-DKIM: OpenDKIM Filter v2.4.3 hydrogen.mailtransaction.com 0M1L00L00JR7UL00 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Remarks from Paris: X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:26:50 -0000 On 3/28/12 2:51 PM, Chris Lewis wrote: > My first remark was regarding query templates: > > It's a common problem with public DNSBLs that queries are malformed from > the very beginning, and there's generally no way (or at least polite > way) to get them fixed - they just keep pounding away with > ineffective/useless queries. > > Once a service like this is configured at the client end, it tends to be > forgotten, and if the admin leaves... > > Templates would go a long way to avoid that happening from the start. > > Second: > > When you query a domain, it would often be useful to get a reputation > score back both for where the domain is authenticated, and where it > isn't authenticated. This can help spam filtering engines apply > probabilities not only for the case where the domain owner does > authenticate normally and it's being spoofed, as well as when it's never > authenticated. > > Use cases: > > a) NACHA (and IRS/DHS/DHL/USPS/UPS/FBI/et al.) spoofs that try to inject > Zeus infectors. Absolutely ridiculous volumes of these going on now. > Big problem everywhere. > > Knowing that an authenticated NACHA email is probably good, and an > unauthenticated NACHA email should be treated as a plague carrier would > be good. > > b) Even if the domain doesn't "do" authentication, being able to supply > reputation on a domain greatly broadens the applicability/usefulness of > a reputation service. Eg: if you start getting spoofed like NACHA does, > the only way to get a good reputation for _your_ email is to start > authenticating. Without the existence of both A/!A reputation there's > little incentive. If reputation on unauthenticated identifiers is useful (repeat: if), then _any_ identity mentioned in par. 4.1.4 of RFC5598 should be mentioned as a possible identity candidate (in par. 3.2 of draft-ietf-repute-email-identifiers. /rolf From ietf@meetecho.com Thu Mar 29 02:18:27 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEF421F89FF for ; Thu, 29 Mar 2012 02:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.915 X-Spam-Level: X-Spam-Status: No, score=-0.915 tagged_above=-999 required=5 tests=[AWL=-0.196, 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 R3hamIGgt5an for ; Thu, 29 Mar 2012 02:18:25 -0700 (PDT) Received: from smtplq01.aruba.it (smtplqs-out27.aruba.it [62.149.158.67]) by ietfa.amsl.com (Postfix) with SMTP id 064AF21F8942 for ; Thu, 29 Mar 2012 02:18:23 -0700 (PDT) Received: (qmail 19718 invoked by uid 89); 29 Mar 2012 09:18:13 -0000 Received: from unknown (HELO smtp7.aruba.it) (62.149.158.227) by smtplq01.aruba.it with SMTP; 29 Mar 2012 09:18:13 -0000 Received: (qmail 24620 invoked by uid 89); 29 Mar 2012 09:18:13 -0000 Received: from unknown (HELO ?130.129.21.177?) (alex@meetecho.com@130.129.21.177) by smtp7.ad.aruba.it with ESMTPA; 29 Mar 2012 09:18:13 -0000 Message-ID: <4F7428CF.80901@meetecho.com> Date: Thu, 29 Mar 2012 11:18:07 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: domainrep@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: [domainrep] Meetecho session recording available X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:18:27 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of REPUTE session at IETF-83 is available. You can watch it by either clicking the proper link on the remote participation page (http://www.ietf.org/meeting/83/remote-participation.html#Meetecho), or by directly accessing the following URL: http://ietf83.conf.meetecho.com/index.php/Recorded_Sessions#REPUTE_IETF83 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 msk@cloudmark.com Thu Mar 29 16:25:09 2012 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8853521F8604 for ; Thu, 29 Mar 2012 16:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MDMQKcW+rHGl for ; Thu, 29 Mar 2012 16:25:09 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5807D21F8534 for ; Thu, 29 Mar 2012 16:25:07 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Thu, 29 Mar 2012 16:25:06 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Thread-Topic: Minutes? Thread-Index: Ac0OAyxecZmQSXF3RVGj4uV6MQDW7g== Date: Thu, 29 Mar 2012 23:25:06 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C20B4@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.158] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280C20B4exchmbx901corpclo_" MIME-Version: 1.0 Subject: [domainrep] Minutes? X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 23:25:09 -0000 --_000_9452079D1A51524AA5749AD23E0039280C20B4exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are the minutes available yet? I forget who Dave asked to take them. I'm = putting together my to-do list for REPUTE's next steps and that (along with= the Meetecho stuff and the jabber transcript) will help a lot. Thanks, -MSK --_000_9452079D1A51524AA5749AD23E0039280C20B4exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are the minutes available yet?  I forget who Da= ve asked to take them.  I’m putting together my to-do list for R= EPUTE’s next steps and that (along with the Meetecho stuff and the ja= bber transcript) will help a lot.


Thanks,

-MSK

--_000_9452079D1A51524AA5749AD23E0039280C20B4exchmbx901corpclo_--