From wmaton@ryouko.imsb.nrc.ca Wed Jul 1 12:54:13 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F863A6CFB for ; Wed, 1 Jul 2009 12:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQ+ZRGc5BLor for ; Wed, 1 Jul 2009 12:54:12 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2001:410:9000:127::10]) by core3.amsl.com (Postfix) with ESMTP id F181B3A67D9 for ; Wed, 1 Jul 2009 12:53:45 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.3/8.14.3) with ESMTP id n61JrqVe001727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Jul 2009 15:53:57 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.3/8.14.3/Submit) with ESMTP id n61JrqaZ001724 for ; Wed, 1 Jul 2009 15:53:52 -0400 Date: Wed, 1 Jul 2009 15:53:52 -0400 (EDT) From: "William F. Maton Sotomayor" To: apps-discuss@ietf.org Subject: Interest in reviving WG on FTP(maybe ext?) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 19:54:13 -0000 All, Over the past several months a colleague at a university and myself have revived work on the WU-FTPD daemon. Through researching the various RFCs and such, it's become apparent that there are a small number of drafts as well as a potential number of others that could significantly contribute to the protocol. (So my voyage has gone from operator, developer and implementor to protocol spec.) But, ftpext wound-up and it seems there's no specific venue to flesh these out amongst like-minded FTP people. I suppose what I'm looking for from the Apps Area folk is to test the waters on establishing a BoF (if I have read the Apps website correctly) that will lead to establishing some kind of group that will further the possible work remaining or possibly poending to be done, or not. Discussions amongst a couple of authors of long-expired drafts seem to favour some kind of venue. Thanks, wfms From mnot@mnot.net Thu Jul 2 02:58:11 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53853A6997 for ; Thu, 2 Jul 2009 02:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.039 X-Spam-Level: X-Spam-Status: No, score=-6.039 tagged_above=-999 required=5 tests=[AWL=-2.440, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-QA0GnEPALp for ; Thu, 2 Jul 2009 02:58:11 -0700 (PDT) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id 258363A6A7F for ; Thu, 2 Jul 2009 02:58:11 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.249.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D0ADC23E3AA for ; Thu, 2 Jul 2009 05:58:31 -0400 (EDT) Message-Id: From: Mark Nottingham To: apps-discuss@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: FYI: Bar BoF wiki pages Date: Thu, 2 Jul 2009 19:58:29 +1000 X-Mailer: Apple Mail (2.935.3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 09:58:12 -0000 I've created some wiki pages to plan and track Bar BoFs at: http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75 Cheers, -- Mark Nottingham http://www.mnot.net/ From eran@hueniverse.com Thu Jul 2 09:50:52 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA403A6ACF for ; Thu, 2 Jul 2009 09:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNxNHf9uMeOh for ; Thu, 2 Jul 2009 09:50:51 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 1EA9F28C19E for ; Thu, 2 Jul 2009 09:48:59 -0700 (PDT) Received: (qmail 23963 invoked from network); 2 Jul 2009 16:49:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Jul 2009 16:49:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 2 Jul 2009 09:49:04 -0700 From: Eran Hammer-Lahav To: David Booth Date: Thu, 2 Jul 2009 09:49:02 -0700 Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Topic: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Index: Acn7I/PO3FWClpiKQQm31qXktBHkQAAEHmmg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378339882D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A46C264.6090700@oracle.com> <760bcb2a0906280942jcb99a26y76e99b3f0d8783be@mail.gmail.com> <002101c9f819$5a60bd50$0f2237f0$@org> <1246457271.14395.2820.camel@dbooth-laptop> In-Reply-To: <1246457271.14395.2820.camel@dbooth-laptop> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'URI' , "www-tag@w3.org" , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 16:50:52 -0000 But this approach means a parser cannot figure out the meaning of a URI wit= hout a GET. How would a parser know that a document about such a URI is rea= lly about something else (the subject of the URI) and not the resource the = URI itself is identifying? For this to work, I need to hardcode http://t-d-b.org into every parser to = have a specialized meaning. EHL > -----Original Message----- > From: David Booth [mailto:david@dbooth.org] > Sent: Wednesday, July 01, 2009 7:08 AM > To: Larry Masinter > Cc: 'Jonathan Rees'; ashok.malhotra@oracle.com; Eran Hammer-Lahav; > apps-discuss@ietf.org; www-tag@w3.org; 'URI' > Subject: RE: URI for abstract concepts (domain, host, origin, site, > etc.) >=20 > Larry, >=20 > On Sun, 2009-06-28 at 10:53 -0700, Larry Masinter wrote: > > I'm thinking about revising > > http://larry.masinter.net/duri.html > > > > to: > > (1) to get rid of "duri" and just stick with "tdb" > > (because there isn't much use for duri at all) > > (2) make it a URI scheme rather than a URN namespace > > (3) make the date optional, for cases where the time of > > binding resource to representation (and of interpretation > > of that representation to an 'abstract concept') > > > > So the simplest form would be > > > > tdb:http://larry.masinter.net >=20 > That makes it remarkably similar to > http://t-d-b.org?http://larry.masinter.net >=20 > but the t-d-b.org URI has the advantage that it doesn't require a new > URI scheme, and it *might* be dereferenceable by a browser. In fact, > at > the moment it *is* dereferenceable. >=20 > > > > which would neatly allow using descriptions of > > abstract concepts to identify the abstract concept. >=20 > That sounds like what the "http://t-d-b.org?" prefix does. >=20 > > (Syntactically, the date can be left out without > > ambiguity.) > > > > Would this be helpful, at least for illustrative purposes? >=20 > I think the goal is reasonable, but as explained in > http://dbooth.org/2006/urn2http/ > I don't think a new URI scheme is necessary to achieve it. Similar > things can be done with http URIs, with greater benefit. >=20 > > > > I think there are other means for distinguishing > > between the representation of a description and > > the thing described, but this would at least > > add a well-known method that isn't tied to > > any particular protocol, linking method, resolution > > method, etc. >=20 > Right, but "http:" URIs do not necessarily need to be resolved using > HTTP, nor do they necessarily need to be resolved at all. At worst > they > can be treated as opaque strings, but at best they *might* be > dereferenceable to useful information. A URI prefix like > "http://t-d-b.org?" can become "well known" just as "tdb:" can. This > is > a social issue, independent of whether a new scheme is defined. >=20 >=20 > -- > David Booth, Ph.D. > Cleveland Clinic (contractor) >=20 > Opinions expressed herein are those of the author and do not > necessarily > reflect those of Cleveland Clinic. From phayes@ihmc.us Thu Jul 2 15:06:23 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33623A68CD for ; Thu, 2 Jul 2009 15:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSN8b91I2wYk for ; Thu, 2 Jul 2009 15:06:22 -0700 (PDT) Received: from comet.ihmc.us (comet.ihmc.us [72.236.182.20]) by core3.amsl.com (Postfix) with ESMTP id 4BF413A6951 for ; Thu, 2 Jul 2009 15:06:17 -0700 (PDT) Received: from [10.100.0.69] ([10.100.0.69]) (authenticated user phayes@ihmc.us) by comet.ihmc.us (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 2 Jul 2009 17:06:25 -0500 Message-Id: From: Pat Hayes To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378339882D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) Date: Thu, 2 Jul 2009 17:06:24 -0500 References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A46C264.6090700@oracle.com> <760bcb2a0906280942jcb99a26y76e99b3f0d8783be@mail.gmail.com> <002101c9f819$5a60bd50$0f2237f0$@org> <1246457271.14395.2820.camel@dbooth-laptop> <90C41DD21FB7C64BB94121FBBC2E7234378339882D@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.935.3) Cc: "www-tag@w3.org" , 'URI' , "apps-discuss@ietf.org" , David Booth X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 22:06:23 -0000 On Jul 2, 2009, at 11:49 AM, Eran Hammer-Lahav wrote: > But this approach means a parser cannot figure out the meaning of a > URI without a GET. How would a parser know that a document about > such a URI is really about something else (the subject of the URI) > and not the resource the URI itself is identifying? > Why would a *parser* need to know such a thing? A reasoner could know this by having access to some sentences that told it what the URI refers to. I don't know of any other general way that any entity, including a human being, could know what a URI was intended to denote. > For this to work, I need to hardcode http://t-d-b.org into every > parser to have a specialized meaning. No, you just have to know that it indicates that the URI refers to *something*. Since URIs can (be used to) refer to anything, it isnt possible to have a "specialized" meaning. Pat > > EHL > >> -----Original Message----- >> From: David Booth [mailto:david@dbooth.org] >> Sent: Wednesday, July 01, 2009 7:08 AM >> To: Larry Masinter >> Cc: 'Jonathan Rees'; ashok.malhotra@oracle.com; Eran Hammer-Lahav; >> apps-discuss@ietf.org; www-tag@w3.org; 'URI' >> Subject: RE: URI for abstract concepts (domain, host, origin, site, >> etc.) >> >> Larry, >> >> On Sun, 2009-06-28 at 10:53 -0700, Larry Masinter wrote: >>> I'm thinking about revising >>> http://larry.masinter.net/duri.html >>> >>> to: >>> (1) to get rid of "duri" and just stick with "tdb" >>> (because there isn't much use for duri at all) >>> (2) make it a URI scheme rather than a URN namespace >>> (3) make the date optional, for cases where the time of >>> binding resource to representation (and of interpretation >>> of that representation to an 'abstract concept') >>> >>> So the simplest form would be >>> >>> tdb:http://larry.masinter.net >> >> That makes it remarkably similar to >> http://t-d-b.org?http://larry.masinter.net >> >> but the t-d-b.org URI has the advantage that it doesn't require a new >> URI scheme, and it *might* be dereferenceable by a browser. In fact, >> at >> the moment it *is* dereferenceable. >> >>> >>> which would neatly allow using descriptions of >>> abstract concepts to identify the abstract concept. >> >> That sounds like what the "http://t-d-b.org?" prefix does. >> >>> (Syntactically, the date can be left out without >>> ambiguity.) >>> >>> Would this be helpful, at least for illustrative purposes? >> >> I think the goal is reasonable, but as explained in >> http://dbooth.org/2006/urn2http/ >> I don't think a new URI scheme is necessary to achieve it. Similar >> things can be done with http URIs, with greater benefit. >> >>> >>> I think there are other means for distinguishing >>> between the representation of a description and >>> the thing described, but this would at least >>> add a well-known method that isn't tied to >>> any particular protocol, linking method, resolution >>> method, etc. >> >> Right, but "http:" URIs do not necessarily need to be resolved using >> HTTP, nor do they necessarily need to be resolved at all. At worst >> they >> can be treated as opaque strings, but at best they *might* be >> dereferenceable to useful information. A URI prefix like >> "http://t-d-b.org?" can become "well known" just as "tdb:" can. This >> is >> a social issue, independent of whether a new scheme is defined. >> >> >> -- >> David Booth, Ph.D. >> Cleveland Clinic (contractor) >> >> Opinions expressed herein are those of the author and do not >> necessarily >> reflect those of Cleveland Clinic. > > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes From dret@berkeley.edu Thu Jul 2 17:22:37 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC103A6A48 for ; Thu, 2 Jul 2009 17:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83Eb6EgbPAGb for ; Thu, 2 Jul 2009 17:22:37 -0700 (PDT) Received: from smtp.ischool.berkeley.edu (bliss.ISchool.Berkeley.EDU [128.32.78.13]) by core3.amsl.com (Postfix) with ESMTP id 296AB3A6876 for ; Thu, 2 Jul 2009 17:22:37 -0700 (PDT) Received: from [10.154.207.74] (166-205-130-240.mobile.mymmode.com [166.205.130.240] (may be forged)) (authenticated bits=0) by smtp.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id n630MVTB028892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Jul 2009 17:22:40 -0700 From: Erik Wilde To: Pat Hayes In-Reply-To: X-Mailer: iPhone Mail (7A341) Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A46C264.6090700@oracle.com> <760bcb2a0906280942jcb99a26y76e99b3f0d8783be@mail.gmail.com> <002101c9f819$5a60bd50$0f2237f0$@org> <1246457271.14395.2820.camel@dbooth-laptop> <90C41DD21FB7C64BB94121FBBC2E7234378339882D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-4--162107859 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7A341) Date: Thu, 2 Jul 2009 17:22:26 -0700 X-Scanned-By: MIMEDefang 2.67 on 128.32.78.13 Cc: "www-tag@w3.org" , "apps-discuss@ietf.org" , URI , David Booth X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 00:22:37 -0000 --Apple-Mail-4--162107859 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jul 2, 2009, at 15:06, Pat Hayes wrote: > Why would a *parser* need to know such a thing? A reasoner could > know this by having access to some sentences that told it what the > URI refers to. I don't know of any other general way that any > entity, including a human being, could know what a URI was intended > to denote. that's the semantic web world view, where URIs are completely opaque, always supposed to be http:, and to learn anything about them, a description must be found and used. on the plain web, URI schemes carry semantics, so that a client needs no additional information about tel: to be able to use these URIs. of course, the semantic web methods of describing something are far richer, but that should not imply that all URI semantics are or should be deferred to semantic web technologies. cheers, dret. --Apple-Mail-4--162107859 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Jul 2, 2009, at 15:06, Pat Hayes = <phayes@ihmc.us> = wrote:
Why would a *parser* = need to know such a thing? A reasoner could know this by having access = to some sentences that told it what the URI refers to. I don't know of = any other general way that any entity, including a human being, could = know what a URI was intended to denote.

that's the semantic web = world view, where URIs are completely opaque, always supposed to be = http:, and to learn anything about them, a description must be found and = used. on the plain web, URI schemes carry semantics, so that a client = needs no additional information about tel: to be able to use these URIs. = of course, the semantic web methods of describing something are far = richer, but that should not imply that all URI semantics are or should = be deferred to semantic web = technologies.

cheers,

dr= et.
= --Apple-Mail-4--162107859-- From salvatore.loreto@ericsson.com Fri Jul 3 09:25:47 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339373A688D; Fri, 3 Jul 2009 09:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wn0Z63-DrQrp; Fri, 3 Jul 2009 09:25:45 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 07A793A679F; Fri, 3 Jul 2009 09:25:44 -0700 (PDT) X-AuditID: c1b4fb3e-b7b3cae000002c88-60-4a4e31144437 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 6F.C2.11400.4113E4A4; Fri, 3 Jul 2009 18:25:57 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 18:25:05 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 18:25:04 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 124CA23F6; Fri, 3 Jul 2009 19:25:05 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CBF8221A07; Fri, 3 Jul 2009 19:25:04 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7FF3B219CC; Fri, 3 Jul 2009 19:25:04 +0300 (EEST) Message-ID: <4A4E30E0.7060203@ericsson.com> Date: Fri, 03 Jul 2009 19:25:04 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: hybi@ietf.org, apps-discuss@ietf.org Subject: HyBi Bar BoF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 03 Jul 2009 16:25:04.0931 (UTC) FILETIME=[D2883F30:01C9FBFA] X-Brightmail-Tracker: AAAAAA== X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 16:25:47 -0000 Hi there, I'd like to know if people are interested and available to join a *Bar BoF on HyBi* in Stockholm at IETF 75. *Details* * When: TBD * Where: TBD *Topics:* - the "near term" solutions to the problem of using HTTP for bidirectional exchanges : on which, if any, aspect among the one listed in draft-loreto-http-bidirectional-00 folks think it would be most productive to focus on. - the "long term" solution... clarify the term of the agreement between W3C and IETF, and start to discuss on the requirements. /add suggested topics of discussion as appropriate/ *Resource:* /(add drafts and other links as appropriate) /- http://www.ietf.org/internet-drafts/draft-loreto-http-bidirectional-00.txt/ / Thanks Sal/ www.sloreto.com / From david@dbooth.org Thu Jul 2 07:46:37 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2553A6DA7 for ; Thu, 2 Jul 2009 07:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgGGVQjBcft6 for ; Thu, 2 Jul 2009 07:46:36 -0700 (PDT) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by core3.amsl.com (Postfix) with SMTP id 15C573A6D82 for ; Thu, 2 Jul 2009 07:46:35 -0700 (PDT) Received: (qmail 19798 invoked from network); 2 Jul 2009 14:46:56 -0000 Received: from 74.202.71.201 (HELO ?10.1.1.216?) (74.202.71.201) by relay00.pair.com with SMTP; 2 Jul 2009 14:46:56 -0000 X-pair-Authenticated: 74.202.71.201 Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) From: David Booth To: Larry Masinter In-Reply-To: <002101c9f819$5a60bd50$0f2237f0$@org> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A46C264.6090700@oracle.com> <760bcb2a0906280942jcb99a26y76e99b3f0d8783be@mail.gmail.com> <002101c9f819$5a60bd50$0f2237f0$@org> Content-Type: text/plain Date: Wed, 01 Jul 2009 10:07:51 -0400 Message-Id: <1246457271.14395.2820.camel@dbooth-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 05 Jul 2009 11:30:35 -0700 Cc: apps-discuss@ietf.org, 'Jonathan Rees' , ashok.malhotra@oracle.com, 'URI' , www-tag@w3.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 14:46:37 -0000 Larry, On Sun, 2009-06-28 at 10:53 -0700, Larry Masinter wrote: > I'm thinking about revising > http://larry.masinter.net/duri.html > > to: > (1) to get rid of "duri" and just stick with "tdb" > (because there isn't much use for duri at all) > (2) make it a URI scheme rather than a URN namespace > (3) make the date optional, for cases where the time of > binding resource to representation (and of interpretation > of that representation to an 'abstract concept') > > So the simplest form would be > > tdb:http://larry.masinter.net That makes it remarkably similar to http://t-d-b.org?http://larry.masinter.net but the t-d-b.org URI has the advantage that it doesn't require a new URI scheme, and it *might* be dereferenceable by a browser. In fact, at the moment it *is* dereferenceable. > > which would neatly allow using descriptions of > abstract concepts to identify the abstract concept. That sounds like what the "http://t-d-b.org?" prefix does. > (Syntactically, the date can be left out without > ambiguity.) > > Would this be helpful, at least for illustrative purposes? I think the goal is reasonable, but as explained in http://dbooth.org/2006/urn2http/ I don't think a new URI scheme is necessary to achieve it. Similar things can be done with http URIs, with greater benefit. > > I think there are other means for distinguishing > between the representation of a description and > the thing described, but this would at least > add a well-known method that isn't tied to > any particular protocol, linking method, resolution > method, etc. Right, but "http:" URIs do not necessarily need to be resolved using HTTP, nor do they necessarily need to be resolved at all. At worst they can be treated as opaque strings, but at best they *might* be dereferenceable to useful information. A URI prefix like "http://t-d-b.org?" can become "well known" just as "tdb:" can. This is a social issue, independent of whether a new scheme is defined. -- David Booth, Ph.D. Cleveland Clinic (contractor) Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic. From geeohgeegeeoh@gmail.com Thu Jul 2 16:05:46 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDF33A6AC0 for ; Thu, 2 Jul 2009 16:05:46 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vUWx+VC8cBJ for ; Thu, 2 Jul 2009 16:05:45 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id E09A13A6C66 for ; Thu, 2 Jul 2009 16:05:20 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so772137wff.31 for ; Thu, 02 Jul 2009 16:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date:cc :x-mailer; bh=x2BhynpCgQXrnjXNWUBV/c/gk9SyqLCiLIgj0ppGKQ4=; b=VCIy/bm8TPXvmot2DU3juQocT2ooz+NTM9uXbDAu0slMAadbtKVlOf5XL92TWUhD4J i+ZeYeK1nc0usre1lZGb202aNXUa2cgpbhv5zyMV/J0YRxN4crRMwpWvIX2JD+9jNT12 ja4b8YPv/XZc17+MClh75gxrpKBk4YiPVmLJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:cc:x-mailer; b=cNiU+XgVUbo250xXtgHQSQn7pUBvEHCGdpw2Y3jhvF3hbRy3DJutL2nxlG/tktg/pb VO8W98BYOlryN7ecwq8etLWzw7n97GkQ9p894KdIFzD48XwVwvuBhLo1IcZcui1gk+a0 f7kj90Yslr0Os13HGHrQt0GX2UfAo/cj9ZLo0= Received: by 10.142.222.19 with SMTP id u19mr258727wfg.123.1246575941834; Thu, 02 Jul 2009 16:05:41 -0700 (PDT) Received: from dynamic190.apnic.net (dynamic190.apnic.net [203.119.42.190]) by mx.google.com with ESMTPS id 22sm7884817wfd.8.2009.07.02.16.05.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Jul 2009 16:05:41 -0700 (PDT) Sender: George Michaelson Message-Id: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> From: George Michaelson To: ietf-imapext@imc.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing Date: Fri, 3 Jul 2009 09:05:36 +1000 X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Sun, 05 Jul 2009 11:30:35 -0700 Cc: discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 23:15:28 -0000 I would like to suggest that IMAP extensions could usefully be specified to permit MUA to signal to the MS over IMAP, that the message in question is, or is not spam. I would also like to suggest that an IMAP extension pair to signal that the specified address is to be white, or black listed, would be equally useful. This is because a large number of people now depend on IMAP backed MS in places like google, or corporate maildrops, but also have in-client spam tagging. Where the spam filtering is not sufficiently complete to prevent significant leakage, and mis-attribution across the MUA/MS dialogue, the lack of an in-protocol method to pass the information means we are all using what I would call ad-hoc methods to fix this situation up. If it was possible to communicate this 'first class' in IMAP, I think that it would significantly enhance the user experience. As an example, at the moment if I wish to inform google that I have known spam in local folders, I have to go to the web interface and manually tag. If there was an IMAP extension, I could review my local baysian junk folder, remove all non-spam (and flag the senders as white-listed if need be), and request the rest to be flagged as spam back on the IMAP backed MS. Likewise for false positives and blacklisted senders. I am told that the IMAPEXT WG is closed. I mail this, in the hope that somebody can help decide if this is a viable topic for consideration. Many thanks for guidance and advice thus far from Lisa Dusseault. cheers -George From iljitsch@muada.com Sun Jul 5 12:03:32 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADEEC3A695F for ; Sun, 5 Jul 2009 12:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUlJLb1lCm3m for ; Sun, 5 Jul 2009 12:03:32 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id B74313A6BEC for ; Sun, 5 Jul 2009 12:03:31 -0700 (PDT) Received: from [192.168.2.4] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n65J3Z8C043962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 5 Jul 2009 21:03:38 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: George Michaelson In-Reply-To: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing Date: Sun, 5 Jul 2009 21:03:30 +0200 References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> X-Mailer: Apple Mail (2.935.3) Cc: ietf-imapext@imc.org, discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 19:03:32 -0000 On 3 jul 2009, at 1:05, George Michaelson wrote: > As an example, at the moment if I wish to inform google that I have > known spam in local folders, I have to go to the web interface and > manually tag. If there was an IMAP extension, I could review my > local baysian junk folder, remove all non-spam (and flag the senders > as white-listed if need be), and request the rest to be flagged as > spam back on the IMAP backed MS. Doesn't moving the spam messages to the spam folder accomplish this already? That's what my client does. But if you want this, I'd say that it needs to be a fractional thing, not a binary spam/no spam indication. For instance, the server could give something a spam score of 2 and the client also 2 and together that would be 4 so the message is presumed to be spam (assuming the spam threshold is 3), but in a binary system no spam OR no spam = no spam. From dave@cridland.net Mon Jul 6 01:25:36 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA223A6859 for ; Mon, 6 Jul 2009 01:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO2MJSAwVwGE for ; Mon, 6 Jul 2009 01:25:35 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id E1FB728C1D8 for ; Mon, 6 Jul 2009 01:25:34 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 6 Jul 2009 09:24:51 +0100 X-SMTP-Protocol-Errors: NORDNS Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <28941.1246868682.560969@puncture> Date: Mon, 06 Jul 2009 09:24:42 +0100 From: Dave Cridland To: Iljitsch van Beijnum , , general discussion of application-layer protocols , George Michaelson Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Encoded: Changed encoding from 8Bit for 7bit transmission X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 08:25:36 -0000 On Sun Jul 5 20:03:30 2009, Iljitsch van Beijnum wrote: > On 3 jul 2009, at 1:05, George Michaelson wrote: > = >> As an example, at the moment if I wish to inform google that I = >> have known spam in local folders, I have to go to the web = >> interface and manually tag. If there was an IMAP extension, I = >> could review my local baysian junk folder, remove all non-spam = >> (and flag the senders as white-listed if need be), and request = >> the rest to be flagged as spam back on the IMAP backed MS. > = > Doesn't moving the spam messages to the spam folder accomplish this = > already? That's what my client does. > = > = There's also a proposal (expired?) to use keywords to signal = spamminess. > But if you want this, I'd say that it needs to be a fractional = > thing, not a binary spam/no spam indication. For instance, the = > server could give something a spam score of 2 and the client also = > 2 and together that would be 4 so the message is presumed to be = > spam (assuming the spam threshold is 3), but in a binary system no = > spam OR no spam =3D no spam. Of course, if both client and server use precisely the same criteria, = you've simply halved your threshold. There's two cases: 1) The server has some feedback-based spam detection mechanism, like = a bayesian filter. You want to teach the server's filter about your = explicit decisions. 2) Your client has a spam filter (or some sort), you want the server = to tell your client about it's preliminary findings. The notion of using two spam filters in concert to attempt to make an = overall decision is basically flawed, because it fits into one or = other case above - if you do go to the effort of having a range based = spamminess from one, you'd have to use it as mere input into the = other's decision process, since combining them na=EFvely would produce = poorly weighted results. A simple keyword approach isn't quite as good as ranges, but it does = have the useful property that nearly every service already offers = arbitrary keywords, and so is quite likely to already offer it. Ranges, on the other hand, require the use of annotations, which is a = rather more complex area. Dave. -- = Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From iljitsch@muada.com Mon Jul 6 01:37:41 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB4828C20E for ; Mon, 6 Jul 2009 01:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MMIXEEY+DKf for ; Mon, 6 Jul 2009 01:37:40 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 1BFBE28C1DF for ; Mon, 6 Jul 2009 01:37:39 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n668bAXQ048131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Jul 2009 10:37:11 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Dave Cridland In-Reply-To: <28941.1246868682.560969@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing Date: Mon, 6 Jul 2009 10:37:06 +0200 References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> X-Mailer: Apple Mail (2.935.3) Cc: ietf-imapext@imc.org, George Michaelson , general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 08:37:41 -0000 On 6 jul 2009, at 10:24, Dave Cridland wrote: >> But if you want this, I'd say that it needs to be a fractional =20 >> thing, not a binary spam/no spam indication. For instance, the =20 >> server could give something a spam score of 2 and the client also =20= >> 2 and together that would be 4 so the message is presumed to be =20 >> spam (assuming the spam threshold is 3), but in a binary system no =20= >> spam OR no spam =3D no spam. > The notion of using two spam filters in concert to attempt to make =20 > an overall decision is basically flawed, because it fits into one or =20= > other case above - if you do go to the effort of having a range =20 > based spamminess from one, you'd have to use it as mere input into =20 > the other's decision process, since combining them na=EFvely would =20 > produce poorly weighted results. Right. The filtering would have to be complimentary. So perhaps there =20= should be an indication of the type of filtering done, too. The reason =20= to combine server and client side approaches is that servers can =20 easily do blacklists, and running any type of filtering on the server =20= gives it the opportunity to reject the message during the SMTP =20 session, creating a good error message for real senders but no useless =20= bounces to innocent third parties in the case of spoofed senders. On =20 the client is useful because the client can typically better afford to =20= run CPU intensive stuff like baysian filters and the client probably =20 has a better list of previous correspondents that it can use to =20 whitelist.= From dave@cridland.net Mon Jul 6 02:11:19 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6471A3A69B3 for ; Mon, 6 Jul 2009 02:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH+DiWIZjgD8 for ; Mon, 6 Jul 2009 02:11:18 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id F091328C1CF for ; Mon, 6 Jul 2009 02:11:17 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 6 Jul 2009 10:05:49 +0100 X-SMTP-Protocol-Errors: NORDNS Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> In-Reply-To: MIME-Version: 1.0 Message-Id: <28941.1246871141.850024@puncture> Date: Mon, 06 Jul 2009 10:05:41 +0100 From: Dave Cridland To: Iljitsch van Beijnum , , general discussion of application-layer protocols , George Michaelson Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Encoded: Changed encoding from 8Bit for 7bit transmission X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 09:11:19 -0000 On Mon Jul 6 09:37:06 2009, Iljitsch van Beijnum wrote: > = > On 6 jul 2009, at 10:24, Dave Cridland wrote: > = >>> But if you want this, I'd say that it needs to be a fractional = >>> thing, not a binary spam/no spam indication. For instance, the = >>> server could give something a spam score of 2 and the client = >>> also 2 and together that would be 4 so the message is presumed = >>> to be spam (assuming the spam threshold is 3), but in a binary = >>> system no spam OR no spam =3D no spam. > = >> The notion of using two spam filters in concert to attempt to make = >> an overall decision is basically flawed, because it fits into one = >> or other case above - if you do go to the effort of having a = >> range based spamminess from one, you'd have to use it as mere = >> input into the other's decision process, since combining them = >> na=EFvely would produce poorly weighted results. > = > Right. The filtering would have to be complimentary. So perhaps = > there should be an indication of the type of filtering done, too. = > The reason to combine server and client side approaches is that = > servers can easily do blacklists, and running any type of = > filtering on the server gives it the opportunity to reject the = > message during the SMTP session, creating a good error message for = > real senders but no useless bounces to innocent third parties in = > the case of spoofed senders. On the client is useful because the = > client can typically better afford to run CPU intensive stuff like = > baysian filters and the client probably has a better list of = > previous correspondents that it can use to whitelist. Whitelists should, in principle, be easily comminicable to the server = (and easily processed). Bayesian filters on the client are only really useful if the same = client is always used - this is often not the case (and, in my = experience, is becoming rarer). Otherwise the quality of your spam = filtering radically changes depending on the client you happen to be = using at the time. And basically, any filtering at all that can be done on the server = saves a vast amount of bandwidth, and makes use of email on smaller = devices (like mobile phones) instantly more useful. The one massive advantage that a client has is direct contact with = the user, and the eyeball remains the best spam filtering technology = we have. I'm not suggesting that clients must not do spam filtering - = obviously they do, and it's often useful - but I think we should aim = to make server-side filtering the best we can. A very simple uniform = feedback mechanism of whether the user thinks a message is spam or = not makes this very much easier. Dave. -- = Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From samj@samj.net Mon Jul 6 02:28:01 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E464F3A687E for ; Mon, 6 Jul 2009 02:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uapeblS1RUyX for ; Mon, 6 Jul 2009 02:28:00 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 94EFD3A6801 for ; Mon, 6 Jul 2009 02:28:00 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so1116121fgg.18 for ; Mon, 06 Jul 2009 02:27:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.68.18 with SMTP id q18mr1982532fga.68.1246872421016; Mon, 06 Jul 2009 02:27:01 -0700 (PDT) In-Reply-To: <28941.1246871141.850024@puncture> References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <28941.1246871141.850024@puncture> Date: Mon, 6 Jul 2009 11:27:00 +0200 Message-ID: <21606dcf0907060227u3b516cb8hdb6cb824e608b6c7@mail.gmail.com> Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing From: Sam Johnston To: Dave Cridland Content-Type: multipart/alternative; boundary=000e0cd2431cbc2800046e061b4e Cc: ietf-imapext@imc.org, George Michaelson , general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 09:28:02 -0000 --000e0cd2431cbc2800046e061b4e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Jul 6, 2009 at 11:05 AM, Dave Cridland wrote: > I'm not suggesting that clients must not do spam filtering - obviously they > do, and it's often useful - but I think we should aim to make server-side > filtering the best we can. A very simple uniform feedback mechanism of > whether the user thinks a message is spam or not makes this very much > easier. Agreed - I use the Gmail web interface exclusively now (after OS X Mail lost its mind a few years ago and forgot what was read, unread, labeled, etc.) but if the "Report Spam" button were available in mail clients then I might consider moving back. Being able to report that messages are not spam is useful too, as is being able to black/whitelist certain senders (albeit less so). I'm sure I'm not alone in using a laptop and a mobile client (many have desktop and/or home clients in the mix too) so whatever can possibly be centralised should be. Another thing to consider is that it's not always black and white - certain types of spam also fall into the phishing category and should be specifically investigated (Gmail has a "Report Phishing" menu item for this which allows them to label phishing messages accordingly) and Postini categorises spam so you can lower or raise the threshold depending on whether its type... that way accountants, lawers, etc. can avoid losing good mail (and others can avoid receiving it). Sam --000e0cd2431cbc2800046e061b4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 6, 2009 at 11:05 AM, Dave Cridland <dave@cridland.net> wrote:
<= div class=3D"gmail_quote">
I'm not suggesting that clients must not do spam filtering - obviously = they do, and it's often useful - but I think we should aim to make serv= er-side filtering the best we can. A very simple uniform feedback mechanism= of whether the user thinks a message is spam or not makes this very much e= asier.

Agreed - I use the Gmail web interface exclusively now (after OS = X Mail lost its mind a few years ago and forgot what was read, unread, labe= led, etc.) but if the "Report Spam" button were available in mail= clients then I might consider moving back. Being able to report that messa= ges are not spam is useful too, as is being able to black/whitelist certain= senders (albeit less so).

I'm sure I'm not alone in using a laptop and a mobile client (m= any have desktop and/or home clients in the mix too) so whatever can possib= ly be centralised should be.

Another thing to consider is that it= 9;s not always black and white - certain types of spam also fall into the p= hishing category and should be specifically investigated (Gmail has a "= ;Report Phishing" menu item for this which allows them to label phishi= ng messages accordingly) and Postini categorises spam so you can lower or r= aise the threshold depending on whether its type... that way accountants, l= awers, etc. can avoid losing good mail (and others can avoid receiving it).=

Sam

--000e0cd2431cbc2800046e061b4e-- From alexey.melnikov@isode.com Mon Jul 6 03:28:28 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F10A3A6BE0 for ; Mon, 6 Jul 2009 03:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGPd35N6Eijh for ; Mon, 6 Jul 2009 03:28:27 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4F7E43A6BB9 for ; Mon, 6 Jul 2009 03:28:27 -0700 (PDT) Received: from [92.40.185.222] (92.40.185.222.sub.mbb.three.co.uk [92.40.185.222]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 6 Jul 2009 11:28:33 +0100 Message-ID: <4A51D1A1.5040507@isode.com> Date: Mon, 06 Jul 2009 11:27:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Iljitsch van Beijnum Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> In-Reply-To: <28941.1246868682.560969@puncture> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-imapext@imc.org, George Michaelson , general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 10:28:28 -0000 Dave Cridland wrote: > On Sun Jul 5 20:03:30 2009, Iljitsch van Beijnum wrote: > >> On 3 jul 2009, at 1:05, George Michaelson wrote: >> >>> As an example, at the moment if I wish to inform google that I >>> have known spam in local folders, I have to go to the web >>> interface and manually tag. If there was an IMAP extension, I >>> could review my local baysian junk folder, remove all non-spam >>> (and flag the senders as white-listed if need be), and request the >>> rest to be flagged as spam back on the IMAP backed MS. >> >> Doesn't moving the spam messages to the spam folder accomplish this >> already? That's what my client does. > > There's also a proposal (expired?) to use keywords to signal spamminess. To expand on this: I believe the proposal is implemented by several major email clients (Thunderbird is one of them). [For people not familiar with IMAP: IMAP keywords is a basic IMAP feature implemented by majority of IMAP servers I've seen.] From cabo@tzi.org Mon Jul 6 03:56:02 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D533A6CFC; Mon, 6 Jul 2009 03:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qooXJfghdby2; Mon, 6 Jul 2009 03:56:01 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 876373A6CFB; Mon, 6 Jul 2009 03:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n66AuGi6002910; Mon, 6 Jul 2009 12:56:16 +0200 (CEST) Received: from [192.168.217.107] (p5489FE35.dip.t-dialin.net [84.137.254.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id AA4BBB42E; Mon, 6 Jul 2009 12:56:15 +0200 (CEST) Message-Id: From: Carsten Bormann To: 6lowpan@ietf.org, apps-discuss@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: 6LowApp: Application protocols for 6LoWPAN and other LLN Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 6 Jul 2009 12:56:14 +0200 X-Mailer: Apple Mail (2.935.3) Cc: ROLL WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 10:56:02 -0000 The 6LoWPAN and ROLL WGs are laying the groundwork to make the Wireless Embedded Internet a reality, but what application protocols will we use? Request-response protocols like HTTP are a poor fit to a communication model with battery-operated, mostly sleeping nodes. In addition, the usual data formats (both headers and body) are perceived to be too chatty for the 50-60 byte payloads possible in LoWPANs and to require too much code for the 8-bit and 16-bit processors dominating the Internet of Things. Still, it would be a mistake to start a new silo of application protocols that do not benefit from existing application area Internet experience. At IETF75, we will hold a Bar BOF to scope out possible IETF work and maybe form an opinion on which part should be done in which IETF area. Tentative information is at http://u.nu/6jfh = http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75/6LowApp (and you are welcome to contribute to this Wiki page). -> Please tell us whether the envisaged date and time of ->Tue 18:30<- will work for you! A first version of a problem statement (where the above paragraph was stolen from) is at: http://tools.ietf.org/id/6lowapp (draft-bormann-6lowpan-6lowapp-problem-00.txt) I will start planning an agenda for the Bar BOF soon, so if you have something to say that would help in this conversation, please tell me (with an estimated amount of time). Gruesse, Carsten From alexey.melnikov@isode.com Mon Jul 6 05:46:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DAC328C16F for ; Mon, 6 Jul 2009 05:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7p+irH-jXirJ for ; Mon, 6 Jul 2009 05:46:24 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5CC4528C14D for ; Mon, 6 Jul 2009 05:46:24 -0700 (PDT) Received: from [172.16.2.141] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 6 Jul 2009 13:41:48 +0100 Message-ID: <4A51F0D5.3040903@isode.com> Date: Mon, 06 Jul 2009 13:40:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org Subject: Updated www.apps.ietf.org website MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 12:46:25 -0000 The updated www.apps.ietf.org website is online now. Thank you to Ned Freed for migrating the website to Drupal, for updating it and for providing the hardware for hosting the website! From geeohgeegeeoh@gmail.com Sun Jul 5 15:08:10 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBBFD3A6BE5 for ; Sun, 5 Jul 2009 15:08:10 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lky86ngFpR4 for ; Sun, 5 Jul 2009 15:08:10 -0700 (PDT) Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id 089D83A6B8B for ; Sun, 5 Jul 2009 15:08:10 -0700 (PDT) Received: by pzk36 with SMTP id 36so3818148pzk.29 for ; Sun, 05 Jul 2009 15:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=kpKobQJLRv/p8TH2KE+EVJCRkrZKqL6rk0iaDT9JOK4=; b=M5uBuWfXOk9Lg3drtOzMOs/ipASVz+9LK1OEelKhyxN5f2wF6e5KWoJm9bcnVJmSNs PKBrTgKJYFdpAh20xws75vI3Qm/sDXAbFog5LGFohV76mI8QOgMVgLM8uuuoxKhy+PYp 51PlgninZKlG77c09vQgahUjIeZUb9xfrxxms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=tCGBN69cz0lUjzV9iCL6DbPakq8DOhCkhxyp8f+JEpgUpx6TWr9iMeR7cR08SjYeZs yKCoSpQD7+y/MPw3j34jj8tzA46WpgUYRkWmKtLKtJvtITgNmi45oSGkdaHQXaUsG3/q yoez3m3eZQQOr3TgX3rI4ayBNGbxXAlkHpDsU= Received: by 10.141.35.13 with SMTP id n13mr1994449rvj.132.1246831713687; Sun, 05 Jul 2009 15:08:33 -0700 (PDT) Received: from 192-168-1-5.tpgi.com.au (60-240-104-100-nsw-pppoe.tpgi.com.au [60.240.104.100]) by mx.google.com with ESMTPS id k41sm8504825rvb.17.2009.07.05.15.08.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 05 Jul 2009 15:08:33 -0700 (PDT) Sender: George Michaelson Message-Id: <4E651E16-F697-4198-9B82-D3F32BFFB9E8@pobox.com> From: George Michaelson To: Iljitsch van Beijnum In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing Date: Mon, 6 Jul 2009 08:08:28 +1000 References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Mon, 06 Jul 2009 08:05:43 -0700 Cc: ietf-imapext@imc.org, discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 22:08:10 -0000 On 06/07/2009, at 5:03 AM, Iljitsch van Beijnum wrote: > On 3 jul 2009, at 1:05, George Michaelson wrote: > >> As an example, at the moment if I wish to inform google that I have >> known spam in local folders, I have to go to the web interface and >> manually tag. If there was an IMAP extension, I could review my >> local baysian junk folder, remove all non-spam (and flag the >> senders as white-listed if need be), and request the rest to be >> flagged as spam back on the IMAP backed MS. > > Doesn't moving the spam messages to the spam folder accomplish this > already? That's what my client does. > I think thats a side effect. you depend on the server having a rule which says that the folder of a specific name defines spam, and that moving mails to and from it makes things happen. I'm not driven to side ffects. I like first class behaviour. I think that is fine, in its own way, but I'd like it to have a way to say it without doing that. for instance. what if I run TWO email accounts, off different imap servers. I'd like the JOIN of their state to be used to mark senders white or black listed sometimes. > But if you want this, I'd say that it needs to be a fractional > thing, not a binary spam/no spam indication. For instance, the > server could give something a spam score of 2 and the client also 2 > and together that would be 4 so the message is presumed to be spam > (assuming the spam threshold is 3), but in a binary system no spam > OR no spam = no spam. I want to start simple. Binary state spam/ham and white/black flagging. if I say its spam, then it should be spam. In what sense does the MS know better than me? If I say its whitelisted, in what sense does the MS know better than me? -G > From david@dbooth.org Sun Jul 5 20:08:23 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F103A6B27 for ; Sun, 5 Jul 2009 20:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oElp+9pZmdPf for ; Sun, 5 Jul 2009 20:08:22 -0700 (PDT) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by core3.amsl.com (Postfix) with SMTP id 05CBD3A6951 for ; Sun, 5 Jul 2009 20:08:21 -0700 (PDT) Received: (qmail 6282 invoked from network); 6 Jul 2009 03:08:46 -0000 Received: from 68.56.72.164 (HELO ?192.168.0.102?) (68.56.72.164) by relay01.pair.com with SMTP; 6 Jul 2009 03:08:46 -0000 X-pair-Authenticated: 68.56.72.164 Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) From: David Booth To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378339882D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A46C264.6090700@oracle.com> <760bcb2a0906280942jcb99a26y76e99b3f0d8783be@mail.gmail.com> <002101c9f819$5a60bd50$0f2237f0$@org> <1246457271.14395.2820.camel@dbooth-laptop> <90C41DD21FB7C64BB94121FBBC2E7234378339882D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain Date: Sun, 05 Jul 2009 23:08:07 -0400 Message-Id: <1246849687.5532.519.camel@dbooth-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 06 Jul 2009 08:05:43 -0700 Cc: 'URI' , "www-tag@w3.org" , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 03:08:23 -0000 On Thu, 2009-07-02 at 09:49 -0700, Eran Hammer-Lahav wrote: > But this approach means a parser cannot figure out the meaning of a > URI without a GET. No, the GET can be optimized away if the parser is aware of this convention, as described here: http://thing-described-by.org/#optimizing This is comparable to a parser being aware of the "tdb:" scheme. > How would a parser know that a document about such a URI is really > about something else (the subject of the URI) and not the resource the > URI itself is identifying? > > For this to work, I need to hardcode http://t-d-b.org into every > parser to have a specialized meaning. No, parsers that do not know about this "http://t-d-b.org?" prefix can dereference the URI if they wish, whereupon they will be 303-redirected to the descriptive document, in accordance with: http://www.w3.org/TR/cooluris/ http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039 On the other hand, parsers that *do* know about this prefix can skip the initial HTTP request and go directly to the descriptive document. In comparison with a "tdb:" URI, the result would be the same for parsers that know about the special "tdb:" or "http://t-d-b.org?" prefix. But parsers that do not know about the "tdb:" would be out of luck, whereas parsers that do not know about the "http://t-d-b.org?" prefix may still be able to find the descriptive document by dereferencing the URI. David Booth > > EHL > > > -----Original Message----- > > From: David Booth [mailto:david@dbooth.org] > > Sent: Wednesday, July 01, 2009 7:08 AM > > To: Larry Masinter > > Cc: 'Jonathan Rees'; ashok.malhotra@oracle.com; Eran Hammer-Lahav; > > apps-discuss@ietf.org; www-tag@w3.org; 'URI' > > Subject: RE: URI for abstract concepts (domain, host, origin, site, > > etc.) > > > > Larry, > > > > On Sun, 2009-06-28 at 10:53 -0700, Larry Masinter wrote: > > > I'm thinking about revising > > > http://larry.masinter.net/duri.html > > > > > > to: > > > (1) to get rid of "duri" and just stick with "tdb" > > > (because there isn't much use for duri at all) > > > (2) make it a URI scheme rather than a URN namespace > > > (3) make the date optional, for cases where the time of > > > binding resource to representation (and of interpretation > > > of that representation to an 'abstract concept') > > > > > > So the simplest form would be > > > > > > tdb:http://larry.masinter.net > > > > That makes it remarkably similar to > > http://t-d-b.org?http://larry.masinter.net > > > > but the t-d-b.org URI has the advantage that it doesn't require a new > > URI scheme, and it *might* be dereferenceable by a browser. In fact, > > at > > the moment it *is* dereferenceable. > > > > > > > > which would neatly allow using descriptions of > > > abstract concepts to identify the abstract concept. > > > > That sounds like what the "http://t-d-b.org?" prefix does. > > > > > (Syntactically, the date can be left out without > > > ambiguity.) > > > > > > Would this be helpful, at least for illustrative purposes? > > > > I think the goal is reasonable, but as explained in > > http://dbooth.org/2006/urn2http/ > > I don't think a new URI scheme is necessary to achieve it. Similar > > things can be done with http URIs, with greater benefit. > > > > > > > > I think there are other means for distinguishing > > > between the representation of a description and > > > the thing described, but this would at least > > > add a well-known method that isn't tied to > > > any particular protocol, linking method, resolution > > > method, etc. > > > > Right, but "http:" URIs do not necessarily need to be resolved using > > HTTP, nor do they necessarily need to be resolved at all. At worst > > they > > can be treated as opaque strings, but at best they *might* be > > dereferenceable to useful information. A URI prefix like > > "http://t-d-b.org?" can become "well known" just as "tdb:" can. This > > is > > a social issue, independent of whether a new scheme is defined. > > > > > > -- > > David Booth, Ph.D. > > Cleveland Clinic (contractor) > > > > Opinions expressed herein are those of the author and do not > > necessarily > > reflect those of Cleveland Clinic. > > > > -- David Booth, Ph.D. Cleveland Clinic (contractor) Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic. From ned.freed@mrochek.com Mon Jul 6 10:17:04 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8639228C388 for ; Mon, 6 Jul 2009 10:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cvSPFmxVMVL for ; Mon, 6 Jul 2009 10:17:03 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id C04B73A6D35 for ; Mon, 6 Jul 2009 10:17:03 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NAZUSTSTW000S1PD@mauve.mrochek.com> for discuss@ietf.org; Mon, 6 Jul 2009 10:16:10 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NAUEIO1ZRK001DLH@mauve.mrochek.com>; Mon, 06 Jul 2009 10:16:09 -0700 (PDT) Date: Sun, 05 Jul 2009 17:40:31 -0700 (PDT) From: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-reply-to: "Your message dated Sun, 05 Jul 2009 21:03:30 +0200" To: Iljitsch van Beijnum Message-id: <01NAZUST62HQ001DLH@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; delsp=yes Content-transfer-encoding: 7BIT References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> Cc: ietf-imapext@imc.org, George Michaelson , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 17:17:04 -0000 > On 3 jul 2009, at 1:05, George Michaelson wrote: > > As an example, at the moment if I wish to inform google that I have > > known spam in local folders, I have to go to the web interface and > > manually tag. If there was an IMAP extension, I could review my > > local baysian junk folder, remove all non-spam (and flag the senders > > as white-listed if need be), and request the rest to be flagged as > > spam back on the IMAP backed MS. > Doesn't moving the spam messages to the spam folder accomplish this > already? That's what my client does. Please explain how moving a message to a random, arbtirarily named folder tells the server anything useful. People use all sorts of different naming schemes for folders, and it's common for clients to provide lots of flexibility in this area. The obvious way to make this work in IMAP is with a standardized folder annotation saying "messages put in this folder were flagged as spam". Then moves of messages to the folder with this annotation provide the server with the necessary information that this message is considered to be spam by the user. And by the same token, moving a message from this folder can be construed as the message not being considered spam after all. It isn't perfect, but as long as this is taken as an indicator, not as an absolute statement, it should get the job done. > But if you want this, I'd say that it needs to be a fractional thing, > not a binary spam/no spam indication. For instance, the server could > give something a spam score of 2 and the client also 2 and together > that would be 4 so the message is presumed to be spam (assuming the > spam threshold is 3), but in a binary system no spam OR no spam = no > spam. There's a place for fractional scoring in spam filtering, but this isn't it. A user doesn't think "this message is 90% likely to be spam", they either think it's spam or it isn't. Ned From ned.freed@mrochek.com Mon Jul 6 10:44:10 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88F2528C2F1 for ; Mon, 6 Jul 2009 10:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndJfhePNtdTd for ; Mon, 6 Jul 2009 10:44:09 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id BF32528C2E4 for ; Mon, 6 Jul 2009 10:44:09 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NAZVQBTCS0002DWJ@mauve.mrochek.com> for discuss@ietf.org; Mon, 6 Jul 2009 10:43:11 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NAUEIO1ZRK001DLH@mauve.mrochek.com>; Mon, 06 Jul 2009 10:43:09 -0700 (PDT) Date: Mon, 06 Jul 2009 10:39:40 -0700 (PDT) From: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-reply-to: "Your message dated Mon, 06 Jul 2009 11:27:45 +0100" <4A51D1A1.5040507@isode.com> To: Alexey Melnikov Message-id: <01NAZVQAYWH4001DLH@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed Content-transfer-encoding: 7BIT References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> Cc: ietf-imapext@imc.org, George Michaelson , general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 17:44:10 -0000 > Dave Cridland wrote: > > On Sun Jul 5 20:03:30 2009, Iljitsch van Beijnum wrote: > > > >> On 3 jul 2009, at 1:05, George Michaelson wrote: > >> > >>> As an example, at the moment if I wish to inform google that I > >>> have known spam in local folders, I have to go to the web > >>> interface and manually tag. If there was an IMAP extension, I > >>> could review my local baysian junk folder, remove all non-spam > >>> (and flag the senders as white-listed if need be), and request the > >>> rest to be flagged as spam back on the IMAP backed MS. > >> > >> Doesn't moving the spam messages to the spam folder accomplish this > >> already? That's what my client does. > > > > There's also a proposal (expired?) to use keywords to signal spamminess. > To expand on this: I believe the proposal is implemented by several > major email clients (Thunderbird is one of them). > [For people not familiar with IMAP: IMAP keywords is a basic IMAP > feature implemented by majority of IMAP servers I've seen.] The problem with using keywords for this is that you are now dependence on your client supporting that particular set of keywords and their associated semantics. Had we standardize such a keyword set 10 or so years ago this approach miight have had a chance, but the client base is now too large and too difficult to update. This is why I think folder annotations are a better bet. You mark the spam folder and use that marking to attach meaning to the movement of messages into and out of that folder. It's not perfect, but it has the key advantage that it works with any client (OK, any client that can use folders) once the annotation is in place. Ned From mikek@muonics.com Mon Jul 6 10:50:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D53428C2E4 for ; Mon, 6 Jul 2009 10:50:31 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HvLbJUkB-CT for ; Mon, 6 Jul 2009 10:50:30 -0700 (PDT) Received: from mail.muonics.com (mail.muonics.com [66.92.223.18]) by core3.amsl.com (Postfix) with ESMTP id 0001328C280 for ; Mon, 6 Jul 2009 10:50:17 -0700 (PDT) Received: from eng-bsd.muonics.com (eng-bsd.muonics.com [172.16.42.5]) by mail.muonics.com (Postfix) with ESMTP id 01B91B847; Mon, 6 Jul 2009 10:26:45 -0700 (PDT) Date: Mon, 6 Jul 2009 10:26:10 -0700 (PDT) From: Michael Kirkham To: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-Reply-To: <01NAZUST62HQ001DLH@mauve.mrochek.com> Message-ID: <20090706100834.R49379@eng-bsd.muonics.com> References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ietf-imapext@imc.org, George Michaelson , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 17:50:31 -0000 On Sun, 5 Jul 2009, Ned Freed wrote: > Please explain how moving a message to a random, arbtirarily named > folder tells the server anything useful. Seems to me this is up to the server configuration and software running on the server. I don't see why you need a specific contract between IMAP client and server for flagging spam, and it's of limited usefulness. For one thing, it was pretty painless for me to set up cron jobs to suck in whatever messages I save to certain folders (that could have been named anything) for training my spam filter. I also have other cron jobs set up to do other things with email completely unrelated to spam that also simply involve saving to a particular folder (e.g. a tickler file for email--I move messages to folders named for a month or day, and cron jobs automatiacally reinsert them back in my inbox later). That kind of thing isn't addressed by having something spam-specific, but as far as my email client is concerned, they're flagged the same way. Any additional detail or instructions could likely be provided by adding headers to the message being saved, if the client allows it. Just my two (not seeing the point) cents. -- Michael Kirkham President & CEO Muonics, Inc. http://www.muonics.com/ From Nicolas.Williams@sun.com Mon Jul 6 10:55:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39BB128C3E2 for ; Mon, 6 Jul 2009 10:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.739 X-Spam-Level: X-Spam-Status: No, score=-5.739 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUlC7lzQiKCq for ; Mon, 6 Jul 2009 10:55:24 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 1675F28C302 for ; Mon, 6 Jul 2009 10:55:24 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n66HsZUJ026603 for ; Mon, 6 Jul 2009 17:54:35 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n66HsYDw048505 for ; Mon, 6 Jul 2009 11:54:34 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n66HiKfZ019363; Mon, 6 Jul 2009 12:44:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n66HiEk1019362; Mon, 6 Jul 2009 12:44:14 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 6 Jul 2009 12:44:14 -0500 From: Nicolas Williams To: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing Message-ID: <20090706174414.GM15302@Sun.COM> References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01NAZUST62HQ001DLH@mauve.mrochek.com> User-Agent: Mutt/1.5.7i Cc: ietf-imapext@imc.org, George Michaelson , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 17:55:25 -0000 On Sun, Jul 05, 2009 at 05:40:31PM -0700, Ned Freed wrote: > > >On 3 jul 2009, at 1:05, George Michaelson wrote: > > >> As an example, at the moment if I wish to inform google that I have > >> known spam in local folders, I have to go to the web interface and > >> manually tag. If there was an IMAP extension, I could review my > >> local baysian junk folder, remove all non-spam (and flag the senders > >> as white-listed if need be), and request the rest to be flagged as > >> spam back on the IMAP backed MS. > > >Doesn't moving the spam messages to the spam folder accomplish this > >already? That's what my client does. > > Please explain how moving a message to a random, arbtirarily named > folder tells the server anything useful. People use all sorts of > different naming schemes for folders, and it's common for clients to > provide lots of flexibility in this area. In particular the word 'spam' is really an English-language word. L10N would demand that the name of this folder not be 'spam' in all locales, or at least that clients know how to map that folder name to the user's language(s). But even if we go for the latter, having special folder names means denying or complicating the use of those names in other languages for other purposes; it's bad enough we have one well-known folder name (INBOX), let's have no more. > The obvious way to make this work in IMAP is with a standardized > folder annotation saying "messages put in this folder were flagged as > spam". Then moves of messages to the folder with this annotation > provide the server with the necessary information that this message is > considered to be spam by the user. And by the same token, moving a > message from this folder can be construed as the message not being > considered spam after all. +1 Or even just a message flag/annotation. I understand the "move junk mail to the junk mail folder" metaphor for flagging junk mail as such, but one might want to flag junk mail and still move it to an "archived mail" folder. I don't find my argument for a per-message flag terribly convincing, so I won't push it. > It isn't perfect, but as long as this is taken as an indicator, not as > an absolute statement, it should get the job done. > > >But if you want this, I'd say that it needs to be a fractional thing, > >not a binary spam/no spam indication. For instance, the server could > >give something a spam score of 2 and the client also 2 and together > >that would be 4 so the message is presumed to be spam (assuming the > >spam threshold is 3), but in a binary system no spam OR no spam = no > >spam. > > There's a place for fractional scoring in spam filtering, but this isn't > it. A user doesn't think "this message is 90% likely to be spam", they > either think it's spam or it isn't. +1 Fractional scoring by the server, or by software running on the client can be useful, but the users themselves will generally make binary spam/ not-spam decisions. Nico -- From ned.freed@mrochek.com Mon Jul 6 11:04:58 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492643A6D6A for ; Mon, 6 Jul 2009 11:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ku5caCvTjvRZ for ; Mon, 6 Jul 2009 11:04:57 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 5FF3D3A6D6D for ; Mon, 6 Jul 2009 11:04:57 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NAZWHDBNTS005LCB@mauve.mrochek.com> for discuss@ietf.org; Mon, 6 Jul 2009 11:04:12 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NAZUBB7I4G000078@mauve.mrochek.com>; Mon, 06 Jul 2009 11:04:10 -0700 (PDT) Date: Mon, 06 Jul 2009 11:00:24 -0700 (PDT) From: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-reply-to: "Your message dated Mon, 06 Jul 2009 11:53:41 -0600" <1246902821.8602.70.camel@legolas.orthanc.ca> To: Lyndon Nerenberg Message-id: <01NAZWHC66ZU000078@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <1246902821.8602.70.camel@legolas.orthanc.ca> Cc: ietf-imapext@imc.org, Ned Freed , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 18:04:58 -0000 > On Sun, 2009-07-05 at 17:40 -0700, Ned Freed wrote: > > The obvious way to make this work in IMAP is with a standardized > > folder > > annotation saying "messages put in this folder were flagged as spam". > > Then > > moves of messages to the folder with this annotation provide the > > server with > > the necessary information that this message is considered to be spam > > by the > > user. And by the same token, moving a message from this folder can be > > construed > > as the message not being considered spam after all. > This is just trying to turn a folder into a keyword, but without full > keyword semantics. Actually, it's a hack t work around the lack of client support, which is why I didn't propose a keyword-based mechanism. > The most obvious flaw is that it constrains the > client to storing all the spam in one bucket. If there's a reason multiple folders can't be marked this way I sure don't know what it is. > It doesn't allow for (say) > sorting junk by type into different folders (perhaps on different > servers). A message's 'state of spamminess' is an attribute of the > message, properly denoted by keywords that stick to (and with) the > message. I see no reason why this couldn't be done, if you really want to. > If you want this functionality (and I think it's a useful service for > servers to provide) you need to implement two keywords: $spam and > $nospam (these are just example names). Setting $spam on a message would > instruct the server to pass the message off to the filtering component > as spam; setting $nospam would instruct the server to pass the message > off to the filtering component as valid (non-spam). The two keywords are > exclusive, and it would be up to the server to decide what action to > take if the client tries to light up both at once (e.g. unset the other > flag and take the corresponding action, reject the command, or silently > ignore the request). Again, the problem with using keywords is now you have to get a significant fraction of clients on board before it's useful. I'd be willing to go along with a keyword-based approach if I could convinced that's going to happen, but everything recentlts has supported exactly the opposite conclusion. Ned From stpeter@stpeter.im Mon Jul 6 11:19:16 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8173A6D11; Mon, 6 Jul 2009 11:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44bvqUr9qZxp; Mon, 6 Jul 2009 11:19:15 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8539A3A67DF; Mon, 6 Jul 2009 11:19:00 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2F6EF4007B; Mon, 6 Jul 2009 12:07:25 -0600 (MDT) Message-ID: <4A523D5C.4060100@stpeter.im> Date: Mon, 06 Jul 2009 12:07:24 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Salvatore Loreto Subject: Re: [hybi] HyBi Bar BoF References: <4A4E30E0.7060203@ericsson.com> In-Reply-To: <4A4E30E0.7060203@ericsson.com> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 18:19:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/3/09 10:25 AM, Salvatore Loreto wrote: > Hi there, > > I'd like to know if people are interested and available to join a *Bar > BoF on HyBi* in Stockholm at IETF 75. Sounds like a good idea. > *Details* > > * When: TBD > * Where: TBD I should be there all week. > *Topics:* > - the "near term" solutions to the problem of using HTTP for > bidirectional exchanges : > on which, if any, aspect among the one listed in > draft-loreto-http-bidirectional-00 > folks think it would be most productive to focus on. > > - the "long term" solution... > clarify the term of the agreement between W3C and IETF, > and start to discuss on the requirements. > > /add suggested topics of discussion as appropriate/ I suppose that discussion about BWTP and Web Sockets is part of the long-term solution? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpSPVwACgkQNL8k5A2w/vz2ngCfcyu1bW3B8E2n11g5QHADQxSD JbgAoPwYsZW2NhFJYsOLzRdyaAKK/RwG =JFG2 -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Mon Jul 6 11:26:34 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03BB3A6D6B for ; Mon, 6 Jul 2009 11:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVheXVD9UYH5 for ; Mon, 6 Jul 2009 11:26:33 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5F8523A6BA1 for ; Mon, 6 Jul 2009 11:26:33 -0700 (PDT) Received: from [172.16.2.141] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 6 Jul 2009 19:16:09 +0100 Message-ID: <4A523F0E.5090706@isode.com> Date: Mon, 06 Jul 2009 19:14:38 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Arnt Gulbrandsen Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-imapext@imc.org, Ned Freed , George Michaelson , general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 18:26:35 -0000 Arnt Gulbrandsen wrote: > Ned Freed writes: > >> The obvious way to make this work in IMAP is with a standardized >> folder annotation saying "messages put in this folder were flagged as >> spam". > > I think what Thunderbird and Apple Mail do is to set specific message > flags on messages in whatever folders they happen to be in: $Junk if > the user said a particular message is spam, $autojunk if tb > autonomously decided that message is spam, $nonjunk and $autononjunk > for the opposite. (I may be wrong about the exact flag names.) Something like that, yes. > This was specified in some expired draft, Which was mine. > which IMO now has been frozen by deployment. Apple Mail and > Thunderbird add up to >10% for me. Time for an informational RFC, > perhaps. "Widely-used IMAP flag names"? Yes. I think even more important to create the IANA registry for keywords. Do you want to help finish my draft? From alexey.melnikov@isode.com Mon Jul 6 11:32:16 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CFC83A6D32 for ; Mon, 6 Jul 2009 11:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5KPYZhdTqA0 for ; Mon, 6 Jul 2009 11:32:15 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 34D133A6BA1 for ; Mon, 6 Jul 2009 11:32:15 -0700 (PDT) Received: from [92.40.185.222] (92.40.185.222.sub.mbb.three.co.uk [92.40.185.222]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 6 Jul 2009 19:30:37 +0100 Message-ID: <4A524280.9000106@isode.com> Date: Mon, 06 Jul 2009 19:29:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lyndon Nerenberg Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <1246902821.8602.70.camel@legolas.orthanc.ca> <01NAZWHC66ZU000078@mauve.mrochek.com> <1246904761.8602.86.camel@legolas.orthanc.ca> In-Reply-To: <1246904761.8602.86.camel@legolas.orthanc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-imapext@imc.org, Ned Freed , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 18:32:16 -0000 Lyndon Nerenberg wrote: >But if your concern is adoption rates, a keyword-only solution will get >wider take-up than something that requires support for annotations. (And >from a purely engineering standpoint, the simplest solution wins.) > > +1. From ned.freed@mrochek.com Mon Jul 6 11:35:27 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20D93A6B9E for ; Mon, 6 Jul 2009 11:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9j8cxGDbfnA for ; Mon, 6 Jul 2009 11:35:27 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 306D63A6A84 for ; Mon, 6 Jul 2009 11:35:11 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NAZXI19NJK00SFNX@mauve.mrochek.com> for discuss@ietf.org; Mon, 6 Jul 2009 11:33:46 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NAZUBB7I4G000078@mauve.mrochek.com>; Mon, 06 Jul 2009 11:33:43 -0700 (PDT) Date: Mon, 06 Jul 2009 11:07:18 -0700 (PDT) From: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-reply-to: "Your message dated Mon, 06 Jul 2009 10:26:10 -0700 (PDT)" <20090706100834.R49379@eng-bsd.muonics.com> To: Michael Kirkham Message-id: <01NAZXHZ47O8000078@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed Content-transfer-encoding: 7BIT References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <20090706100834.R49379@eng-bsd.muonics.com> Cc: ietf-imapext@imc.org, Ned Freed , George Michaelson , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 18:35:27 -0000 > On Sun, 5 Jul 2009, Ned Freed wrote: > > Please explain how moving a message to a random, arbtirarily named > > folder tells the server anything useful. > Seems to me this is up to the server configuration and software running on > the server. I don't see why you need a specific contract between IMAP > client and server for flagging spam, The primary reason is so that the server can use the information to automaticallly refine it's filtering policies on a per-user basis. Other uses include, but are not limited to, setting expiration and arhival policies. > and it's of limited usefulness. On the contrary, such a mechanism would be HUGELY useful. We have any number of customers begging for it, as a matter of fact. > For > one thing, it was pretty painless for me to set up cron jobs to suck in > whatever messages I save to certain folders (that could have been named > anything) for training my spam filter. Are you serious? Cron jobs? Do you have any idea how minute a fraction of the users of email even know what a cron job is, let alone know how to set one up? The minute you start talking about setting up your own cron jobs, it pretty much goes without saying that you're operating entirely outside the space where 99+% of the use of IMAP takes place. > I also have other cron jobs set up > to do other things with email completely unrelated to spam that also > simply involve saving to a particular folder (e.g. a tickler file for > email--I move messages to folders named for a month or day, and cron jobs > automatiacally reinsert them back in my inbox later). That kind of thing > isn't addressed by having something spam-specific, but as far as my email > client is concerned, they're flagged the same way. And no doubt you also tweak SpamAssasin rules, set up milters, etc. etc. This is far beyond the capability of most users. Ned From mikek@muonics.com Mon Jul 6 12:20:04 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EEAB28C41A for ; Mon, 6 Jul 2009 12:20:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrBHn9n1D9vH for ; Mon, 6 Jul 2009 12:20:03 -0700 (PDT) Received: from mail.muonics.com (mail.muonics.com [66.92.223.18]) by core3.amsl.com (Postfix) with ESMTP id 4A09A28C412 for ; Mon, 6 Jul 2009 12:20:03 -0700 (PDT) Received: from eng-bsd.muonics.com (eng-bsd.muonics.com [172.16.42.5]) by mail.muonics.com (Postfix) with ESMTP id 8D311B847; Mon, 6 Jul 2009 11:57:10 -0700 (PDT) Date: Mon, 6 Jul 2009 11:56:35 -0700 (PDT) From: Michael Kirkham To: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-Reply-To: <01NAZXHZ47O8000078@mauve.mrochek.com> Message-ID: <20090706111703.S49379@eng-bsd.muonics.com> References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <20090706100834.R49379@eng-bsd.muonics.com> <01NAZXHZ47O8000078@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ietf-imapext@imc.org, George Michaelson , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:20:04 -0000 On Mon, 6 Jul 2009, Ned Freed wrote: > The primary reason is so that the server can use the information to > automaticallly refine it's filtering policies on a per-user basis. Which is what my setup does (assuming I use the folders I set aside for flagging spam/ham). > Other uses include, but are not limited to, setting expiration and arhival > policies. But I don't see what these things have to do with IMAP specifically. Consider Pine, for example, which saves a special message (which Pine hides from the user) to folders it interacts with, having some Pine-specific details about the folder/messages in it. If what you want is to be able to set folder-specific policies, perhaps what you should be arguing for is standardizing an extension to the mbox (or other mail storage) format that does something similar. A standard set of header fields in this hidden message, plus whatever client-specific stuff some other client might want to add, etc. > On the contrary, such a mechanism would be HUGELY useful. We have any > number of customers begging for it, as a matter of fact. I think you misunderstood what I was pointing at not being useful. If these customers don't understand what a cron job is, they probably haven't much clue about IMAP either, other than plugging in the settings their IT person tells them to so their email just works. I've no doubt that your customers want to be able to, from an arbitrary client and server, flag a message as spam (or not) to be handled as such by the server. What I believe is less useful is addressing that requirement through something IMAP and SPAM specific. My point wasn't that users should just set up cron jobs and custom scripts to do it as I've done. Rather, my point was that it doesn't take an IMAP extension to accomplish these things, since it can just be done with folders, and that the solution would be far more useful if the domain of what you're addressing isn't focussed purely on spam/ham stuff. I was also trying to address the argument that using a "special" folder doesn't work because of needing to reserve a folder name with I18N issues and such. I'm not arguing that saving to specific folders is the ideal solution, but whatever them method you've got to have a server and client (or user) both set up with software and a config to use it, and it could (not necessarily should) be just as simple as a client config option for "this folder is spam" the IT person provides (with other settings for email to "just work") after setting up the server. You bring up SpamAsassin.. Well, as far as I know SpamAssassin doesn't know anything about IMAP. How does extending IMAP help an IMAP client feed a message back to SA as spam/ham? It would seem to me (and, admittedly, I'm no IMAP expert) that you've still got to flag the message itself somehow for later processing. It sounds like you want IMAP to do that. But what would IMAP do, beyond tagging the message with an extra header, or tagging the folder itself somehow (say, folder name--in which case that's where we are now--or through headers in a hidden message, a la Pine)? > it pretty much goes without saying that you're operating entirely > outside the space where 99+% of the use of IMAP takes place. I believe that's my point. :) -- Michael Kirkham President & CEO Muonics, Inc. http://www.muonics.com/ From dave@cridland.net Mon Jul 6 13:18:33 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3512A3A677C for ; Mon, 6 Jul 2009 13:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUhM6e18rreA for ; Mon, 6 Jul 2009 13:18:32 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id D9D5E28C189 for ; Mon, 6 Jul 2009 13:18:31 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 6 Jul 2009 21:16:42 +0100 X-SMTP-Protocol-Errors: NORDNS Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <1246902821.8602.70.camel@legolas.orthanc.ca> In-Reply-To: <1246902821.8602.70.camel@legolas.orthanc.ca> MIME-Version: 1.0 Message-Id: <13196.1246911390.279383@puncture> Date: Mon, 06 Jul 2009 21:16:30 +0100 From: Dave Cridland To: Lyndon Nerenberg , , general discussion of application-layer protocols , Ned Freed Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 20:18:33 -0000 On Mon Jul 6 18:53:41 2009, Lyndon Nerenberg wrote: > On Sun, 2009-07-05 at 17:40 -0700, Ned Freed wrote: > > The obvious way to make this work in IMAP is with a standardized > > folder > > annotation saying "messages put in this folder were flagged as > spam". > > Then > > moves of messages to the folder with this annotation provide the > > server with > > the necessary information that this message is considered to be > spam > > by the > > user. And by the same token, moving a message from this folder > can be > > construed > > as the message not being considered spam after all. > > This is just trying to turn a folder into a keyword, but without > full > keyword semantics. +1. It's fundamentally no different from clients trying to replace the \Deleted keyword with a Trash mailbox, and has all the related issues, which we presumably all know. (Or else can find the attempt at documenting them I once tried). This is compounded by the state being a tristate rather than binary - messages are "Ham", or "Spam", or else "The user has not expressed any decision". Should I move all my messages into another folder to mark them as good ham? Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From iljitsch@muada.com Mon Jul 6 13:19:13 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96E43A677C for ; Mon, 6 Jul 2009 13:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0may5e4ExzsX for ; Mon, 6 Jul 2009 13:19:13 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id AD66928C315 for ; Mon, 6 Jul 2009 13:18:59 -0700 (PDT) Received: from [192.168.2.4] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n66JthxZ053208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Jul 2009 21:55:44 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <60154352-AE34-4FDD-A286-A2AF63C07903@muada.com> From: Iljitsch van Beijnum To: Ned Freed In-Reply-To: <01NAZXHZ47O8000078@mauve.mrochek.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing Date: Mon, 6 Jul 2009 21:55:39 +0200 References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <20090706100834.R49379@eng-bsd.muonics.com> <01NAZXHZ47O8000078@mauve.mrochek.com> X-Mailer: Apple Mail (2.935.3) Cc: ietf-imapext@imc.org, discuss@ietf.org, George Michaelson X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 20:19:14 -0000 On 6 jul 2009, at 20:07, Ned Freed wrote: >> it was pretty painless for me to set up cron jobs to suck in >> whatever messages I save to certain folders (that could have been >> named >> anything) for training my spam filter. > Are you serious? Cron jobs? Do you have any idea how minute a > fraction of the > users of email even know what a cron job is, let alone know how to > set one up? Hey, everyone needs a hobby. I have my procmail set up to check whether I have an IMAP session with the server. If so, I let the client do the mail filtering, if not, the server does it. That way, the unread counters for folders get updated when the client is connected, but the client doesn't have to move large volume mailing list traffic to the correct folder, costing me expensive wireless data traffic and/or slowing things down. About folders for spam: Apple's Mail lets the user select "use this folder for... {sent, drafts, junk, trash}, which is nice if you used a different client before that uses a different folder naming scheme for these things. Works well enough although a little more automation wouldn't hurt. The point that working with folders can be done with existing software (I later train spamassassin with what Mail put in the "junk" folder, even though SA doesn't know about IMAP) is an important one. Requiring keywords that are hardcoded in clients and servers means deployment will be extremely slow, if it ever happens. From fanf2@hermes.cam.ac.uk Mon Jul 6 13:26:47 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB5A3A68ED for ; Mon, 6 Jul 2009 13:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.774 X-Spam-Level: X-Spam-Status: No, score=-5.774 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdxNqgGWpj0Z for ; Mon, 6 Jul 2009 13:26:46 -0700 (PDT) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by core3.amsl.com (Postfix) with ESMTP id B8BB33A68A2 for ; Mon, 6 Jul 2009 13:26:45 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:54795) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1MNukm-0001XD-JY (Exim 4.70) (return-path ); Mon, 06 Jul 2009 21:25:32 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1MNukm-0003j2-1E (Exim 4.67) (return-path ); Mon, 06 Jul 2009 21:25:32 +0100 Date: Mon, 6 Jul 2009 21:25:32 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Michael Kirkham Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-Reply-To: <20090706100834.R49379@eng-bsd.muonics.com> Message-ID: References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <20090706100834.R49379@eng-bsd.muonics.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ietf-imapext@imc.org, Ned Freed , George Michaelson , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 20:26:47 -0000 On Mon, 6 Jul 2009, Michael Kirkham wrote: > On Sun, 5 Jul 2009, Ned Freed wrote: > > > Please explain how moving a message to a random, arbtirarily named folder > > tells the server anything useful. > > Seems to me this is up to the server configuration and software running on the > server. I don't see why you need a specific contract between IMAP client and > server for flagging spam So that clients can have user interfaces that expose the functionality in a more friendly manner. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From alexey.melnikov@isode.com Mon Jul 6 14:12:42 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1353A6D2B for ; Mon, 6 Jul 2009 14:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjOBSqb5fPVk for ; Mon, 6 Jul 2009 14:12:41 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6B9AB3A6983 for ; Mon, 6 Jul 2009 14:12:41 -0700 (PDT) Received: from [92.40.43.85] (92.40.43.85.sub.mbb.three.co.uk [92.40.43.85]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 6 Jul 2009 22:07:34 +0100 Message-ID: <4A526763.1020202@isode.com> Date: Mon, 06 Jul 2009 22:06:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Iljitsch van Beijnum Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <20090706100834.R49379@eng-bsd.muonics.com> <01NAZXHZ47O8000078@mauve.mrochek.com> <60154352-AE34-4FDD-A286-A2AF63C07903@muada.com> In-Reply-To: <60154352-AE34-4FDD-A286-A2AF63C07903@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-imapext@imc.org, discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 21:12:42 -0000 Iljitsch van Beijnum wrote: [...] > About folders for spam: Apple's Mail lets the user select "use this > folder for... {sent, drafts, junk, trash}, which is nice if you used > a different client before that uses a different folder naming scheme > for these things. Works well enough although a little more > automation wouldn't hurt. > > The point that working with folders can be done with existing > software (I later train spamassassin with what Mail put in the "junk" > folder, even though SA doesn't know about IMAP) is an important one. > Requiring keywords that are hardcoded in clients and servers means > deployment will be extremely slow, if it ever happens. I don't think your argument in favour of folders (mailboxes) is valid. An IMAP server don't need to treat $Junk/$NotJunk any specially, it just needs to be able to store arbitrary IMAP keywords. Most servers already do. A recent Thunderbird can also be configured to set arbitrary IMAP keywords. (It also recognized $Junk/$NonJunk natively, but this is besides my point). From Nicolas.Williams@sun.com Mon Jul 6 14:20:37 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401BE3A6925 for ; Mon, 6 Jul 2009 14:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.744 X-Spam-Level: X-Spam-Status: No, score=-5.744 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3l8WdSpZPuK for ; Mon, 6 Jul 2009 14:20:36 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 3817F3A69BF for ; Mon, 6 Jul 2009 14:20:36 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n66LJj9b011620 for ; Mon, 6 Jul 2009 21:19:45 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n66LJj4C015075 for ; Mon, 6 Jul 2009 15:19:45 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n66KW0YG028138; Mon, 6 Jul 2009 15:32:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n66KVhZo028137; Mon, 6 Jul 2009 15:31:43 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 6 Jul 2009 15:31:43 -0500 From: Nicolas Williams To: Tony Finch Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing Message-ID: <20090706203143.GR15302@Sun.COM> References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <20090706100834.R49379@eng-bsd.muonics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: ietf-imapext@imc.org, Ned Freed , discuss@ietf.org, George Michaelson X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 21:20:37 -0000 On Mon, Jul 06, 2009 at 09:25:32PM +0100, Tony Finch wrote: > On Mon, 6 Jul 2009, Michael Kirkham wrote: > > On Sun, 5 Jul 2009, Ned Freed wrote: > > > > > Please explain how moving a message to a random, arbtirarily named folder > > > tells the server anything useful. > > > > Seems to me this is up to the server configuration and software running on the > > server. I don't see why you need a specific contract between IMAP client and > > server for flagging spam > > So that clients can have user interfaces that expose the functionality > in a more friendly manner. More specifically: so that users and their clients don't need to know specific details of the server's configuration. From alexey.melnikov@isode.com Mon Jul 6 15:11:32 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 784D328C34F for ; Mon, 6 Jul 2009 15:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs6+BctkN5w8 for ; Mon, 6 Jul 2009 15:11:31 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9FEDD28C315 for ; Mon, 6 Jul 2009 15:11:31 -0700 (PDT) Received: from [92.40.43.85] (92.40.43.85.sub.mbb.three.co.uk [92.40.43.85]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 6 Jul 2009 23:10:44 +0100 Message-ID: <4A527630.4070509@isode.com> Date: Mon, 06 Jul 2009 23:09:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org Subject: Request for discussion topics for the Apps Area meeting in Stockholm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 22:11:32 -0000 Please let Lisa and myself know if you would like to talk about any particular topic. So far I've seen the following requests (in no particular order): Barry Leiba : SMTP Service Extension for Message Recall (draft-leiba-morg-message-recall-00.txt) Cyrus Daboo : Timezone IANA registry and protocol Michael Tuexen : Running application layer protocols over SCTP Iljitsch van Beijnum : FTP Application Layer Gateway for IPv6-to-IPv4 translation Please let me know if I forgot about some topics, or if a name of a particular presentation is not correct. From stpeter@stpeter.im Mon Jul 6 15:18:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C333A6B97 for ; Mon, 6 Jul 2009 15:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4-cJpNIGgC5 for ; Mon, 6 Jul 2009 15:18:38 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B67943A6B3D for ; Mon, 6 Jul 2009 15:18:38 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7E00440C29; Mon, 6 Jul 2009 16:17:36 -0600 (MDT) Message-ID: <4A5277FF.7020801@stpeter.im> Date: Mon, 06 Jul 2009 16:17:35 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: Request for discussion topics for the Apps Area meeting in Stockholm References: <4A527630.4070509@isode.com> In-Reply-To: <4A527630.4070509@isode.com> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 22:18:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/6/09 4:09 PM, Alexey Melnikov wrote: > Please let Lisa and myself know if you would like to talk about any > particular topic. Given that the OAuth WG is ramping up but is not meeting in Stockholm, I could provide a very brief report on the WG (or create a slide or two that the ADs could present). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpSd/8ACgkQNL8k5A2w/vxl2wCgr8jIkifrTW92Am5D1BRRw8I1 KNcAn3LTLZwn456TgtA0EpLSf/3Xi+Rs =r0Pv -----END PGP SIGNATURE----- From lyndon@orthanc.ca Mon Jul 6 11:11:49 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97E8728C24C for ; Mon, 6 Jul 2009 11:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pviX+lBZND+x for ; Mon, 6 Jul 2009 11:11:48 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [208.86.224.138]) by core3.amsl.com (Postfix) with ESMTP id 230A228C1A4 for ; Mon, 6 Jul 2009 11:11:48 -0700 (PDT) Received: from [192.168.0.42] (S01060011242eafe2.cg.shawcable.net [68.145.131.177]) (authenticated bits=0) by orthanc.ca (8.14.3/8.14.3) with ESMTP id n66HrlfS094952; Mon, 6 Jul 2009 11:53:47 -0600 (MDT) (envelope-from lyndon@orthanc.ca) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orthanc.ca; s=2009-1; t=1246902828; bh=43yaytwJNSzxZ5RcTMNBAjKIwGNjzZ4YtRQZoliwL+M=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id:Mime-Version:Content-Transfer-Encoding; b=SiB2C1/Pib6nDPH+BvnP1LLBdtfZGOBmv1Ifkl7CFQsN8W6leE2GPuD2pWLLmEq7p m8JIt+jG6YoCjg9osnORaz1AaXz5EDGObCkkfc12rK1tPWFybSFIcbDeRs6JMXtEQI HLujERdLnxCngkOVdrcrfCNS/8fKe0eecVM2SkEFtRx6tYgrFarb6Zfh/JOH+hIvKj o8ftiLby6kxMszh0mviaX+WDdehBTSllN7GJ7HajGs6OlCgZgglBDGwZpc6hIfAqBc QzLGt5QhcI0cbqleDaZxkrEK5UawakmhEZKqnNbwLl/cvz48ph2SlAG6sXnjkpTIQC tsbWon+QvYcLQ== Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing From: Lyndon Nerenberg To: Ned Freed In-Reply-To: <01NAZUST62HQ001DLH@mauve.mrochek.com> References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> Content-Type: text/plain Date: Mon, 06 Jul 2009 11:53:41 -0600 Message-Id: <1246902821.8602.70.camel@legolas.orthanc.ca> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 06 Jul 2009 15:57:46 -0700 Cc: ietf-imapext@imc.org, discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 18:11:49 -0000 On Sun, 2009-07-05 at 17:40 -0700, Ned Freed wrote: > The obvious way to make this work in IMAP is with a standardized > folder > annotation saying "messages put in this folder were flagged as spam". > Then > moves of messages to the folder with this annotation provide the > server with > the necessary information that this message is considered to be spam > by the > user. And by the same token, moving a message from this folder can be > construed > as the message not being considered spam after all. This is just trying to turn a folder into a keyword, but without full keyword semantics. The most obvious flaw is that it constrains the client to storing all the spam in one bucket. It doesn't allow for (say) sorting junk by type into different folders (perhaps on different servers). A message's 'state of spamminess' is an attribute of the message, properly denoted by keywords that stick to (and with) the message. If you want this functionality (and I think it's a useful service for servers to provide) you need to implement two keywords: $spam and $nospam (these are just example names). Setting $spam on a message would instruct the server to pass the message off to the filtering component as spam; setting $nospam would instruct the server to pass the message off to the filtering component as valid (non-spam). The two keywords are exclusive, and it would be up to the server to decide what action to take if the client tries to light up both at once (e.g. unset the other flag and take the corresponding action, reject the command, or silently ignore the request). From arnt@gulbrandsen.priv.no Mon Jul 6 12:05:59 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151CB28C447 for ; Mon, 6 Jul 2009 12:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8708WfT1FMlI for ; Mon, 6 Jul 2009 12:05:58 -0700 (PDT) Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by core3.amsl.com (Postfix) with ESMTP id 74D4C28C473 for ; Mon, 6 Jul 2009 12:05:18 -0700 (PDT) Received: from kalyani.oryx.com (localhost [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id D25AD2E2F5; Mon, 6 Jul 2009 19:48:06 +0200 (CEST) Received: from arnt@oryx.com (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1246902486-80172-80171/6/64 (6 recipients); Mon, 6 Jul 2009 19:48:06 +0200 Message-Id: Date: Mon, 6 Jul 2009 19:50:08 +0200 From: Arnt Gulbrandsen To: general discussion of application-layer protocols , ietf-imapext@imc.org Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> In-Reply-To: <01NAZUST62HQ001DLH@mauve.mrochek.com> Content-Type: text/plain; format=flowed Mime-Version: 1.0 Sender: arnt@oryx.com X-Mailman-Approved-At: Mon, 06 Jul 2009 15:57:46 -0700 Cc: Ned Freed , George Michaelson X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:05:59 -0000 Ned Freed writes: > The obvious way to make this work in IMAP is with a standardized > folder annotation saying "messages put in this folder were flagged as > spam". I think what Thunderbird and Apple Mail do is to set specific message flags on messages in whatever folders they happen to be in: $Junk if the user said a particular message is spam, $autojunk if tb autonomously decided that message is spam, $nonjunk and $autononjunk for the opposite. (I may be wrong about the exact flag names.) This was specified in some expired draft, which IMO now has been frozen by deployment. Apple Mail and Thunderbird add up to >10% for me. Time for an informational RFC, perhaps. "Widely-used IMAP flag names"? Arnt From lyndon@orthanc.ca Mon Jul 6 12:10:52 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8CCA28C413 for ; Mon, 6 Jul 2009 12:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVd-rN6LFIrx for ; Mon, 6 Jul 2009 12:10:51 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [208.86.224.138]) by core3.amsl.com (Postfix) with ESMTP id 46B9528C44D for ; Mon, 6 Jul 2009 12:10:28 -0700 (PDT) Received: from [192.168.0.42] (S01060011242eafe2.cg.shawcable.net [68.145.131.177]) (authenticated bits=0) by orthanc.ca (8.14.3/8.14.3) with ESMTP id n66IQ7lm095621; Mon, 6 Jul 2009 12:26:08 -0600 (MDT) (envelope-from lyndon@orthanc.ca) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orthanc.ca; s=2009-1; t=1246904768; bh=WwrMcL9AQ6/lx87Ocpx19pPgFGa77TTioXFJrUQ6PG0=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id:Mime-Version:Content-Transfer-Encoding; b=UpIRbLSvwCIbBPMKoSj32racmtHCxgrbXDONA7nswDpkJvUQBkRfgEKOzqw9ehBSX YqeF4VAVWmpI7RWOIjmTAI2ZPbGUTdryjtWGZE602ZKCP9EZ9hrIJ9Qtr+GQg6GHMa lMllguVaer1Sv+6qwOzmPhrWvCjFsB3G14Ss4qZmLMAieFrdu7Gv5Ak7bUoT71w/XN zcSGgCEzIAq0IddWJXtOZcAKiIkrAwDGtz3tXN0q0wdB4wSn4uCM0RBfucYRP0e+nY Lef60eIg9cG+xn15i8e9WRCjqp2JLP0tub0DmBDo/XyWz7DdCXRxDgJYNDclblVKa8 5pEpPz6qEeLag== Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing From: Lyndon Nerenberg To: Ned Freed In-Reply-To: <01NAZWHC66ZU000078@mauve.mrochek.com> References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <1246902821.8602.70.camel@legolas.orthanc.ca> <01NAZWHC66ZU000078@mauve.mrochek.com> Content-Type: text/plain Date: Mon, 06 Jul 2009 12:26:01 -0600 Message-Id: <1246904761.8602.86.camel@legolas.orthanc.ca> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 06 Jul 2009 15:57:46 -0700 Cc: ietf-imapext@imc.org, discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:10:53 -0000 On Mon, 2009-07-06 at 11:00 -0700, Ned Freed wrote: > If there's a reason multiple folders can't be marked this way I sure > don't > know what it is. You're right -- I didn't parse what you were saying correctly the first time around. But if your concern is adoption rates, a keyword-only solution will get wider take-up than something that requires support for annotations. (And from a purely engineering standpoint, the simplest solution wins.) --lyndon From arnt@gulbrandsen.priv.no Mon Jul 6 13:57:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00D03A6925 for ; Mon, 6 Jul 2009 13:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keK7zB+zQ+Rt for ; Mon, 6 Jul 2009 13:57:31 -0700 (PDT) Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by core3.amsl.com (Postfix) with ESMTP id F143F3A6983 for ; Mon, 6 Jul 2009 13:57:30 -0700 (PDT) Received: from kalyani.oryx.com (localhost [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id C7F212E2A2; Mon, 6 Jul 2009 22:54:17 +0200 (CEST) Received: from arnt@oryx.com (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1246913657-80172-80171/6/65 (5 recipients); Mon, 6 Jul 2009 22:54:17 +0200 Message-Id: Date: Mon, 6 Jul 2009 22:56:19 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <1246902821.8602.70.camel@legolas.orthanc.ca> <01NAZWHC66ZU000078@mauve.mrochek.com> <1246904761.8602.86.camel@legolas.orthanc.ca> In-Reply-To: <1246904761.8602.86.camel@legolas.orthanc.ca> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; format=flowed Mime-Version: 1.0 Sender: arnt@oryx.com X-Mailman-Approved-At: Mon, 06 Jul 2009 15:57:46 -0700 Cc: Ned Freed , Lyndon Nerenberg , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 20:57:32 -0000 Lyndon Nerenberg writes: > But if your concern is adoption rates, a keyword-only solution will=20 > get wider take-up than something that requires support for=20 > annotations. Given that two significant clients (say two of the top five) use the=20 keyword approach today, I think it's safe to say =ABhas received wider=20 take-up=BB, not =ABwill get wider=BB. Arnt From geeohgeegeeoh@gmail.com Mon Jul 6 15:51:56 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B873A6C9F for ; Mon, 6 Jul 2009 15:51:56 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsJASao6Davp for ; Mon, 6 Jul 2009 15:51:55 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 3C00A3A6819 for ; Mon, 6 Jul 2009 15:51:55 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so973235eye.65 for ; Mon, 06 Jul 2009 15:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=r+7LcUkx2CzPSYoKaluYkgILXeCnh9mjJTGnQ8ZGZ8E=; b=gUTgQNyfJyD6XV0DmORWZcIgp6/vtqNklpgh55LBQRjnMQ4RcpCMO4+64aSSlCUa71 isdmewhi7b3DNTmFsnDvT5J6J6M/9lsTkEBTaIEaN0AA7Y0+8jRW7Wuf6Hgry87jSPDD gt508y4FixaEhToCA7L70EC0u7cGbrjEBoRhA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=U2K8Qr07ZRGo3eUq+9PbqiTRcf2NnG0BnDc6JIRq3v7eHYY3IZHjnAB+S83VVZH4sZ E2YRv4GoPMRNjtGf3sGhpERxtzpLCE8tnc+bFzQHQBG4RFVn9bF94iKyKHgKjoKISTi1 I8G+BOGG8ekY99A8ApM7PlqepTm5v1lKoGim0= Received: by 10.211.179.6 with SMTP id g6mr6226505ebp.32.1246920678982; Mon, 06 Jul 2009 15:51:18 -0700 (PDT) Received: from 192-168-1-5.tpgi.com.au (60-240-104-100-nsw-pppoe.tpgi.com.au [60.240.104.100]) by mx.google.com with ESMTPS id 24sm1264403eyx.43.2009.07.06.15.51.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Jul 2009 15:51:17 -0700 (PDT) Sender: George Michaelson Message-Id: <47CB230E-B713-4098-82D4-318744434C46@pobox.com> From: George Michaelson To: Ned Freed In-Reply-To: <01NAZVQAYWH4001DLH@mauve.mrochek.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing Date: Tue, 7 Jul 2009 08:51:10 +1000 References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> <01NAZVQAYWH4001DLH@mauve.mrochek.com> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Mon, 06 Jul 2009 15:57:46 -0700 Cc: ietf-imapext@imc.org, general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 22:51:56 -0000 > > > This is why I think folder annotations are a better bet. You mark > the spam > folder and use that marking to attach meaning to the movement of > messages into > and out of that folder. It's not perfect, but it has the key > advantage that it > works with any client (OK, any client that can use folders) once the > annotation > is in place. > > Ned I have two IMAP servers, one google, one not. how do I synchronize state between them. After all, If I (and I do) sometimes have to send from one, to reply to mails from the other (mail clients are bad at selecting sender account) it would be useful to have at least white and blacklist sender synchronization between them. Or, I could be sharing explicit spam tagging information to improve BOTH of their tracking. Do I really have to pass the entire messages between imap servers? An explicit extension/flag/keyword would be unquestionably more efficient use of the network. And, removing the mails from the spam folder in your methodology implies saying 'its not spam' -so the server I move them FROM thinks they've been un-tagged. Again, I say what I said to Ijllitch: I don't like depending on side- effects. I think explicit messaging is better. -George From lisa.dusseault@gmail.com Mon Jul 6 17:09:16 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DEED3A6A71 for ; Mon, 6 Jul 2009 17:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dopxGaJT7LH for ; Mon, 6 Jul 2009 17:09:15 -0700 (PDT) Received: from mail-vw0-f184.google.com (mail-vw0-f184.google.com [209.85.212.184]) by core3.amsl.com (Postfix) with ESMTP id D3DAB28C45F for ; Mon, 6 Jul 2009 17:09:10 -0700 (PDT) Received: by vwj14 with SMTP id 14so3097305vwj.29 for ; Mon, 06 Jul 2009 17:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=vpO1Xf5ntosR7udJvbc7drwh/y0Nu+L7bQFXaL5I+oA=; b=oWCCOSQrWN4lcXF2ZLGwiV11Hf4SOt+PlwVJ/6DBkfmS26uQEFPVTRtVQGJm/7yz0M en/6Ejypp/KQzKlEf8WO5BvCxiXYJG6Pl6jqpzoBAwwQcMGE91KC3zjtj8a34qsPlmpw 0Cv8LyvjDXjH+Z8S5VttpfFAW9iZeDfbmXWZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XPXBxPX/FEtdXVGzaJLtL2FAFaDAG34ise2EoSgCgNw2Uv6AnOYtP+4HCOCMa2Hpax NNvzPYA1WSFm5ZBjEqgJXn+8Tsyw5OLI0TLl75Gw4qwmMWja0HaSmYFpW4jz3KNQEJt8 ueWpJ4XVbEuFUGJH0awKhYAdgNNgrKK9yu0YU= MIME-Version: 1.0 Received: by 10.220.100.1 with SMTP id w1mr10823371vcn.15.1246924725279; Mon, 06 Jul 2009 16:58:45 -0700 (PDT) Date: Mon, 6 Jul 2009 16:58:45 -0700 Message-ID: Subject: Lisa's Apps Area Activity Report for Jun 2009 From: Lisa Dusseault To: lisa-dusseault-chairs@tools.ietf.org, discuss@ietf.org Content-Type: multipart/alternative; boundary=0016e642d57a4fdc30046e124963 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 00:09:16 -0000 --0016e642d57a4fdc30046e124963 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit *News, Updates* Bar BoF planning: thx to MNot, we have a centralized place to coordinate/inform: http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75 - IRIs - FTP? various extensions - 6LOWAPP: low power, grid and home device applications BOFs: - OGPX: Proposed BOF on virtual worlds interoperability, more specific than MMOX APPAREA: topics on message recall, timezone registry, SCTP, FTP gateway for IPv4/iPv6, and accepting other suggestions *Document Status and Progress* Active documents, my action: - draft-ietf-calsify-2446bis (PS): checking with chair on whether the Last Call issues were dealt with Active documents, waiting on other: - draft-montemurro-gsma-imei-urn (Exp): New version of draft expected - draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review and writeup - draft-ietf-sieve-mime-loop (PS): Waiting on authors to respond to GenArt review Finished processing -- new in RFC Ed queue and new RFCs -draft-livingood-woundy-p4p-experiences (Info): Approved-- announcement sent -- soon to be in RFC Ed queue *WG Status* ALTO: Some discussion on problem statement and requirements drafts. CALSIFY: RFC2445bis held up on code license issues. HTTPBIS: Discussion on core specs issues, content-sniffing draft (not a WG product) IDNABIS: New version on mapping: please read http://tools.ietf.org/html/draft-ietf-idnabis-mappings-01. WG is calling for rough consensus on its documents this summer. OAUTH: Split document into 2: authentication and Web delegation SIEVE: A couple fresh drafts, but not much discussion --0016e642d57a4fdc30046e124963 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable News, Updates
Bar BoF planning: thx to MNot, we have a centraliz= ed place to coordinate/inform: http://trac.tools.ietf.org/area/app/trac/wiki/= BarBofs/IETF75
=A0 =A0 =A0- IRIs
=A0 =A0 =A0- FTP? various extensions
=A0 =A0 =A0= - 6LOWAPP: low power, grid and home device applications

BOFs:
= =A0 =A0- OGPX: Proposed BOF on virtual worlds interoperability, more specif= ic than MMOX

APPAREA: topics on message recall, timezone registry, SCTP, FTP gateway for= IPv4/iPv6, and accepting other suggestions

Document Status and = Progress
Active documents, my action:
- draft-ietf-calsify-2446bi= s (PS): checking with chair on whether the Last Call issues were dealt with=

Active documents, waiting on other:
- draft-montemurro-gsma-imei-urn= (Exp): New version of draft expected
- draft-reschke-webdav-post (Exp):= Cyrus Daboo is doing shepherd review and writeup
- draft-ietf-sieve-mim= e-loop (PS): Waiting on authors to respond to GenArt review

Finished processing -- new in RFC Ed queue and new RFCs
-draft-livi= ngood-woundy-p4p-experiences (Info): Approved-- announcement sent -- soon t= o be in RFC Ed queue


WG Status

ALTO: Some discussi= on on problem statement and requirements drafts.
CALSIFY: RFC2445bis held up on code license issues.
HTTPBIS: Discussion = on core specs issues, content-sniffing draft (not a WG product)
IDNABIS:= =A0New version on mapping: =A0please read
http://tools.ietf.org/html/draft-i= etf-idnabis-mappings-01. =A0WG is calling for rough consensus on its do= cuments this summer.
OAUTH: Split document into 2: authentication and Web delegation
SIEVE: = =A0A couple fresh drafts, but not much discussion
--0016e642d57a4fdc30046e124963-- From ned.freed@mrochek.com Mon Jul 6 18:20:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2076428C450 for ; Mon, 6 Jul 2009 18:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOzliMYHpS3s for ; Mon, 6 Jul 2009 18:20:14 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 1B72B3A6DF4 for ; Mon, 6 Jul 2009 18:20:14 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB0BP0Z28000QPIT@mauve.mrochek.com> for discuss@ietf.org; Mon, 6 Jul 2009 18:20:16 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB09YSB36O001ML6@mauve.mrochek.com>; Mon, 06 Jul 2009 18:20:14 -0700 (PDT) Date: Mon, 06 Jul 2009 17:42:58 -0700 (PDT) From: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-reply-to: "Your message dated Tue, 07 Jul 2009 08:51:10 +1000" <47CB230E-B713-4098-82D4-318744434C46@pobox.com> To: George Michaelson Message-id: <01NB0BOZYUPY001ML6@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; delsp=yes Content-transfer-encoding: 7BIT References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> <01NAZVQAYWH4001DLH@mauve.mrochek.com> <47CB230E-B713-4098-82D4-318744434C46@pobox.com> Cc: ietf-imapext@imc.org, Ned Freed , general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 01:20:15 -0000 > > > > > > This is why I think folder annotations are a better bet. You mark > > the spam > > folder and use that marking to attach meaning to the movement of > > messages into > > and out of that folder. It's not perfect, but it has the key > > advantage that it > > works with any client (OK, any client that can use folders) once the > > annotation > > is in place. > > > > Ned > I have two IMAP servers, one google, one not. That's a problem in and of itself, because last time I looked gmail is rather limited in its support of IMAP. > how do I synchronize state between them. By "state" you appear to be referring to spam filtering state. If so, the short answer is you can't possibly do it. > After all, If I (and I do) > sometimes have to send from one, to reply to mails from the other > (mail clients are bad at selecting sender account) it would be useful > to have at least white and blacklist sender synchronization between > them. Sorry, that's simply not realistic. The number of different spam filtering mechanisms in use is much too large, and the lack of semantic equivalents across them all makes this an intractable problem. > Or, I could be sharing explicit spam tagging information to > improve BOTH of their tracking. Do I really have to pass the entire > messages between imap servers? If you want to train the server that doesn't have the message that you do, or don't regard, it as spam, moving the entire message is the only option. I will note that moving messages from one IMAP server to another without having to download and upload them would be possible by relaxing the relative URL restriction in the CATENATE extension defined in RFC 4469. But sending misclassified messages to multiple servers is not going to get them synchronized. Again, there are a myriad of approaches to spam filtering with hugely different semantics. In fact it is entirely possible that you'll cause their behavior to diverge instead of converging. > An explicit extension/flag/keyword would be unquestionably more > efficient use of the network. This makes no sense at all. Setting a flag associated with a message stored on one server is not going to be visible to the other in any way. So the flagging approach offers no solution to the multiple server problem at all. The folder annotation approach doesn't work any better, of course. > And, removing the mails from the spam folder in your methodology > implies saying 'its not spam' -so the server I move them FROM thinks > they've been un-tagged. No, not really. Since there's no facility in IMAP to move a message between servers, the way you have to do it is to FETCH the message from one server and APPEND it to the other. In constrast moving a message from one folder to another on a single server is done with a COPY/SETFLAG sequence. Entirely different. > Again, I say what I said to Ijllitch: I don't like depending on side- > effects. I think explicit messaging is better. I don't especially like depending on side effects either, but when the choice is between a mechanism that works with the vast array of currently deployed clients and one that requires deployment of new client software everywhere to stand even a chance of wortking, I'm strongly inclined to pursue the former. Again, had we standardized flags for marking messages as spam 10 years ago, I'd be fully in favor of using them for this additional purpose because there would be plenty of deployed client support by now. But we didn't, there isn't, and I don't hold out a lot of hope for _anything_ deploying with reasonable speed in the IMAP client space right now. Ned From geeohgeegeeoh@gmail.com Mon Jul 6 18:29:35 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6383628C45F for ; Mon, 6 Jul 2009 18:29:35 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYSJh6E8xccm for ; Mon, 6 Jul 2009 18:29:34 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 66DB428C404 for ; Mon, 6 Jul 2009 18:29:32 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id f9so1248230rvb.49 for ; Mon, 06 Jul 2009 18:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=3J/Yta9Bbh7ajzOXaSQzbVXsLfoNrtu1yc1NdH0tSic=; b=oAXsZJe1Wn5uzwgg1G7cubHrtEyzBbJBt8B4SYegfmMWrN2vEZndPlWmv1J8O9tiPW Vm99DGb0Ew3nLOIRUvSgRCpc9iN+lnQTSxRyAPD3wX07/NZPmXAihWkh5xLACpRleu+z oNiBn5NKCPwrECOBaac2aKoSQyHl8Awk30mDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Gu8mduCa3TLsFDZnF15vJA+wtvhxAMF+dTQ032PuxTHq24qRRqbB6J9zR2N74w/IZS 0jiEWXQurWNYYZajk8Ysm9W8evi0E6Ss1KrckiFq4mc0oJ/EPlqsE4XYRVT5gyl0tUz5 BvN95jk1iZEw2Sj0jOFO33LaALpA9Z9pBLr3U= Received: by 10.141.52.2 with SMTP id e2mr2312993rvk.30.1246930139104; Mon, 06 Jul 2009 18:28:59 -0700 (PDT) Received: from 192-168-1-5.tpgi.com.au (60-240-104-100-nsw-pppoe.tpgi.com.au [60.240.104.100]) by mx.google.com with ESMTPS id k41sm978032rvb.17.2009.07.06.18.28.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Jul 2009 18:28:58 -0700 (PDT) Sender: George Michaelson Message-Id: <6DECD560-B257-4E6E-80E7-A99A69D297C6@pobox.com> From: George Michaelson To: Ned Freed In-Reply-To: <01NB0BOZYUPY001ML6@mauve.mrochek.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing Date: Tue, 7 Jul 2009 11:28:53 +1000 References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> <01NAZVQAYWH4001DLH@mauve.mrochek.com> <47CB230E-B713-4098-82D4-318744434C46@pobox.com> <01NB0BOZYUPY001ML6@mauve.mrochek.com> X-Mailer: Apple Mail (2.935.3) Cc: ietf-imapext@imc.org, general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 01:29:35 -0000 hang on. The MS has the message. It presumably has some held state of it, specific to its implementation. I don't want deep knowledge of that model, I really just want to be able to override it with my explicit knowledge. I simply want to pass the toggle: If you class this as spam, please class as ham or if you class this as ham, please class as spam what it means, semantically, is of course MS specific. I don't care how its held, or what the effect on the weighting is, in the re-class as spam. In the class as ham, I care quite a lot that its sender is removed from hard blocks of course. Yes, I see that moving this state between servers requires the entire message flow. But, if we forget that for now, and just consider that I have some mail in my local client cache, which I feel is now worthy of a state change, why do I have to pass full-state baysian model information? I just want to tell an MS "change your own flags to match my flags" in the hard sense: yes-or-no, not some qualitative weighting model. How it acts, is up to it. I don't see why I need a complex flag model to say what I think, as the consumer of the mail. If I moved off SPAM/HAM to white/black on sender, would that be easier for you to consider? -G From julian.reschke@gmx.de Mon Jul 6 23:55:02 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AD433A6D4E for ; Mon, 6 Jul 2009 23:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.175 X-Spam-Level: X-Spam-Status: No, score=-4.175 tagged_above=-999 required=5 tests=[AWL=-3.935, BAYES_05=-1.11, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS3IjjT17RSj for ; Mon, 6 Jul 2009 23:55:01 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2415B3A67F6 for ; Mon, 6 Jul 2009 23:55:00 -0700 (PDT) Received: (qmail invoked by alias); 07 Jul 2009 06:54:38 -0000 Received: from p508FCBA9.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.203.169] by mail.gmx.net (mp039) with SMTP; 07 Jul 2009 08:54:38 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX188SAAmZXU84P1rShSpifQetciWk0SLbZSwTRdAIV oGKdYhcsrAYyYT Message-ID: <4A52F11F.6000400@gmx.de> Date: Tue, 07 Jul 2009 08:54:23 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Apps Discuss Subject: httpbis vs yam meeting slots in Stockholm Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 06:55:02 -0000 Hi, I just noticed that HTTPBIS and YAM run in parallel; that's IMHO non-optimal because both would benefit from people with MIME experience... Dunno whether this has been already considered, and whether it's possible to do something about it... BR, Julian From iljitsch@muada.com Tue Jul 7 00:23:08 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7343A6E07 for ; Tue, 7 Jul 2009 00:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUOsN6POgdED for ; Tue, 7 Jul 2009 00:23:08 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id CA4863A6D31 for ; Tue, 7 Jul 2009 00:23:07 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n677LFxk057589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Jul 2009 09:21:16 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Lyndon Nerenberg In-Reply-To: <1246902821.8602.70.camel@legolas.orthanc.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing Date: Tue, 7 Jul 2009 09:21:11 +0200 References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <1246902821.8602.70.camel@legolas.orthanc.ca> X-Mailer: Apple Mail (2.935.3) Cc: ietf-imapext@imc.org, Ned Freed , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 07:23:09 -0000 On 6 jul 2009, at 19:53, Lyndon Nerenberg wrote: > A message's 'state of spamminess' is an attribute of the > message, properly denoted by keywords that stick to (and with) the > message. That's nice in the abstract, but why do we have servers classify messages as spam to begin with? In order to not have to look at them, or to be able to look at them when it suits us to clean out the spam rather than in between mail that we actually wanted to receive. So moving spam to a separate folder is not something that happens because of lack of a better mechanism, but the thing that we want to happen 98% of the time anyway. > $spam and $nospam There are more states than that: 1. automatically flagged as spam 2. automatically flagged as non-spam 3. manually flagged as spam 4. manually flagged as non-spam Where 1 and 2 / 3 and 4 are mutually exclusive but 1 + 4 and 2 + 3 should trigger retraining of baysian filters etc. From salvatore.loreto@ericsson.com Tue Jul 7 04:59:28 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5A1D3A6E43; Tue, 7 Jul 2009 04:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.385 X-Spam-Level: X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGgifqqp+QZQ; Tue, 7 Jul 2009 04:59:27 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1D1923A6905; Tue, 7 Jul 2009 04:59:26 -0700 (PDT) X-AuditID: c1b4fb3c-b7c04ae0000036a1-29-4a5334e51741 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 80.C3.13985.5E4335A4; Tue, 7 Jul 2009 13:43:33 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Jul 2009 13:43:32 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Jul 2009 13:43:32 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2AE64245E; Tue, 7 Jul 2009 14:43:32 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E8D5F21A07; Tue, 7 Jul 2009 14:43:31 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7589F219CC; Tue, 7 Jul 2009 14:43:31 +0300 (EEST) Message-ID: <4A5334E3.1070407@ericsson.com> Date: Tue, 07 Jul 2009 14:43:31 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: [hybi] HyBi Bar BoF References: <4A4E30E0.7060203@ericsson.com> <4A523D5C.4060100@stpeter.im> In-Reply-To: <4A523D5C.4060100@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 07 Jul 2009 11:43:32.0367 (UTC) FILETIME=[276E89F0:01C9FEF8] X-Brightmail-Tracker: AAAAAA== Cc: hybi@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 11:59:28 -0000 Hi Peter, yes discussions about BWTP and Web Socket are part of the long term solution and specifically related to the *agreement between W3C and IETF*. I think we want make some progress on the long term solution, we should at least understand better the agreement and in particular the *requirements that the W3C wants be met by long-term solution.* /Sal Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/3/09 10:25 AM, Salvatore Loreto wrote: > >> Hi there, >> >> I'd like to know if people are interested and available to join a *Bar >> BoF on HyBi* in Stockholm at IETF 75. >> > > Sounds like a good idea. > > >> *Details* >> >> * When: TBD >> * Where: TBD >> > > I should be there all week. > > >> *Topics:* >> - the "near term" solutions to the problem of using HTTP for >> bidirectional exchanges : >> on which, if any, aspect among the one listed in >> draft-loreto-http-bidirectional-00 >> folks think it would be most productive to focus on. >> >> - the "long term" solution... >> clarify the term of the agreement between W3C and IETF, >> and start to discuss on the requirements. >> >> /add suggested topics of discussion as appropriate/ >> > > I suppose that discussion about BWTP and Web Sockets is part of the > long-term solution? > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkpSPVwACgkQNL8k5A2w/vz2ngCfcyu1bW3B8E2n11g5QHADQxSD > JbgAoPwYsZW2NhFJYsOLzRdyaAKK/RwG > =JFG2 > -----END PGP SIGNATURE----- > From ned.freed@mrochek.com Tue Jul 7 07:01:16 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991E628C278 for ; Tue, 7 Jul 2009 07:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLYWL4uI1t73 for ; Tue, 7 Jul 2009 07:01:15 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id B66D328C104 for ; Tue, 7 Jul 2009 07:01:15 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB12AAY2E8006J0V@mauve.mrochek.com> for discuss@ietf.org; Tue, 7 Jul 2009 07:01:06 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB09YSB36O001ML6@mauve.mrochek.com>; Tue, 07 Jul 2009 07:01:04 -0700 (PDT) Date: Tue, 07 Jul 2009 06:54:49 -0700 (PDT) From: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-reply-to: "Your message dated Tue, 07 Jul 2009 09:21:11 +0200" To: Iljitsch van Beijnum Message-id: <01NB12A9GJE8001ML6@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; delsp=yes Content-transfer-encoding: 7BIT References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <1246902821.8602.70.camel@legolas.orthanc.ca> Cc: ietf-imapext@imc.org, Ned Freed , Lyndon Nerenberg , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 14:01:16 -0000 > On 6 jul 2009, at 19:53, Lyndon Nerenberg wrote: > > A message's 'state of spamminess' is an attribute of the > > message, properly denoted by keywords that stick to (and with) the > > message. > That's nice in the abstract, but why do we have servers classify > messages as spam to begin with? In order to not have to look at them, > or to be able to look at them when it suits us to clean out the spam > rather than in between mail that we actually wanted to receive. Actually, the primary reason servers classify messages as spam is so they can avoid having to deal with them. If the overhead could be ignored no server operator would bother - spam filteringh is expensive and difficult. The reason it's done is the alternate of receiving and dealing with the those spam messages, with all the ramificaations, is even more expensive and difficult. This more than anything is why a score and not a yes/no verdict is important. A score lets you do stuff like reject messages clearly found to be spam at the SMTP level, while letting likely but less certain to be spam messages through to specially designated spam folders or whatever. > So moving spam to a separate folder is not something that happens > because of lack of a better mechanism, but the thing that we want to > happen 98% of the time anyway. Sometimes yes, sometimes no. > > $spam and $nospam > There are more states than that: > 1. automatically flagged as spam > 2. automatically flagged as non-spam > 3. manually flagged as spam > 4. manually flagged as non-spam > Where 1 and 2 / 3 and 4 are mutually exclusive but 1 + 4 and 2 + 3 > should trigger retraining of baysian filters etc. It's not the flag state of the message that triggers retraining, it's the change of flag state (or folder locaation). Your proposal is unnecessatily complicated. Ned From cyrus@daboo.name Tue Jul 7 07:14:48 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90D6828C4B2 for ; Tue, 7 Jul 2009 07:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3ab4I0E1Oea for ; Tue, 7 Jul 2009 07:14:48 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id E390728C4AE for ; Tue, 7 Jul 2009 07:14:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id C0479168065F; Tue, 7 Jul 2009 10:14:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7-J8DE8kCc5; Tue, 7 Jul 2009 10:14:48 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id ADA281680658; Tue, 7 Jul 2009 10:14:47 -0400 (EDT) Date: Tue, 07 Jul 2009 10:14:42 -0400 From: Cyrus Daboo To: Julian Reschke , Apps Discuss Subject: Re: httpbis vs yam meeting slots in Stockholm Message-ID: <59412B3595BB07DCFCFDC95E@caldav.corp.apple.com> In-Reply-To: <4A52F11F.6000400@gmx.de> References: <4A52F11F.6000400@gmx.de> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=412 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 14:14:48 -0000 Hi Julian, --On July 7, 2009 8:54:23 AM +0200 Julian Reschke wrote: > I just noticed that HTTPBIS and YAM run in parallel; that's IMHO > non-optimal because both would benefit from people with MIME experience... > > Dunno whether this has been already considered, and whether it's possible > to do something about it... +1 We should try and get this conflict fixed. -- Cyrus Daboo From ned.freed@mrochek.com Tue Jul 7 07:39:14 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 155163A69DD for ; Tue, 7 Jul 2009 07:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dt+L82J3fXPT for ; Tue, 7 Jul 2009 07:39:13 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 7393A3A6E73 for ; Tue, 7 Jul 2009 07:39:04 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB13KKILF4001742@mauve.mrochek.com> for discuss@ietf.org; Tue, 7 Jul 2009 07:38:24 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB09YSB36O001ML6@mauve.mrochek.com>; Tue, 07 Jul 2009 07:38:20 -0700 (PDT) Date: Tue, 07 Jul 2009 07:22:42 -0700 (PDT) From: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-reply-to: "Your message dated Mon, 06 Jul 2009 12:26:01 -0600" <1246904761.8602.86.camel@legolas.orthanc.ca> To: Lyndon Nerenberg Message-id: <01NB13KIAQHQ001ML6@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <1246902821.8602.70.camel@legolas.orthanc.ca> <01NAZWHC66ZU000078@mauve.mrochek.com> <1246904761.8602.86.camel@legolas.orthanc.ca> Cc: ietf-imapext@imc.org, Ned Freed , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 14:39:14 -0000 > On Mon, 2009-07-06 at 11:00 -0700, Ned Freed wrote: > > If there's a reason multiple folders can't be marked this way I sure > > don't > > know what it is. > You're right -- I didn't parse what you were saying correctly the first > time around. > But if your concern is adoption rates, a keyword-only solution will get > wider take-up than something that requires support for annotations. (And > from a purely engineering standpoint, the simplest solution wins.) My concern isn't adoption rate. Rather, my concern is, as someone who provides server software, how I can offer a better user experience in regards to spam. Suppose I implement spam filter retraining based on setting of flags. how well this works, or whether it works at all, depends entirely on the client people use. And past experience on client uptake of new features like this is best described as "lousy". Now suppose I implement this with folder annotations. I'm in business immediately. Things just work no matter what client people use. There is, of course, the issue of setting the annotation on the proper folder and having a client to do that. But this isn't as much of a problem as it sounds. Since the annotation only has to be set once, it can be done through a simple web page, or better still, make it an option in the webmail interface. (Everyone has a webmail interface these days.) And in many cases even this is unnecessary, because many service providers predesignate a folder as the spam folder. The only way I could get behind a flag-based solution is if there really was an common set of ad-hoc flag choices already in use by all the major clients - not a couple, all. But I don't believe that's the case. We've had to choose between client and server side solutions many times in the past, and in almost every case the conclusion has been server side solutions are a deployment win. I really wish this weren't true - I wish clients would pick up new capabilities in a more timely fashion - but that's just not how things work. Ned From ned.freed@mrochek.com Tue Jul 7 08:05:51 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3473A6E42 for ; Tue, 7 Jul 2009 08:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vvbXMircS+D for ; Tue, 7 Jul 2009 08:05:50 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 3D6713A6CB3 for ; Tue, 7 Jul 2009 08:05:50 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB14JDJETS00HWDR@mauve.mrochek.com> for discuss@ietf.org; Tue, 7 Jul 2009 08:05:41 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB09YSB36O001ML6@mauve.mrochek.com>; Tue, 07 Jul 2009 08:05:37 -0700 (PDT) Date: Tue, 07 Jul 2009 07:42:42 -0700 (PDT) From: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-reply-to: "Your message dated Tue, 07 Jul 2009 11:28:53 +1000" <6DECD560-B257-4E6E-80E7-A99A69D297C6@pobox.com> To: George Michaelson Message-id: <01NB14JAPS8E001ML6@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; delsp=yes Content-transfer-encoding: 7BIT References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> <01NAZVQAYWH4001DLH@mauve.mrochek.com> <47CB230E-B713-4098-82D4-318744434C46@pobox.com> <01NB0BOZYUPY001ML6@mauve.mrochek.com> <6DECD560-B257-4E6E-80E7-A99A69D297C6@pobox.com> Cc: ietf-imapext@imc.org, Ned Freed , general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 15:05:51 -0000 > hang on. > The MS has the message. It presumably has some held state of it, > specific to its implementation. Actually, that's highly unlikely. There is some amounts of state IMAP requires that's associated with the message - flags/keywords, annotations, some remnants of the envelope. But beyond that there's little point in keeping a bunch of implementation-specific state. Why? Because there's no way to expose such state through the IMAP protocol. So when messages are FETCHed the state stays behind. And more to the point, when a client moves a message, implementation-specific state tends to get lost, because the client doesn't know how to access it in order to move it. The result is that in most csaes IMAP servers don't store much beyond the things the standard requires them to store. The differences between servers lie in how the standard stuff is stored and to what extent metainformation, like body structured, is cached instead of being recomputed. > I don't want deep knowledge of that > model, I really just want to be able to override it with my explicit > knowledge. > I simply want to pass the toggle: > If you class this as spam, please class as ham > or > if you class this as ham, please class as spam This is exactly what we're trying to accomplish. The question is what mechanism to use to do it. > what it means, semantically, is of course MS specific. I don't care > how its held, or what the effect on the weighting is, in the re-class > as spam. In the class as ham, I care quite a lot that its sender is > removed from hard blocks of course. I'm afraid you cannot count on that happening either. The problem is that such blocks are often outside the control of the service provider to change. In many cases the provider has subscribed to some sort of spam filtering service. Whitelisting may be an alternative in such cases, but you have to be careful lest the amount of whitelisting information grow to the point where it is unmanageable. (I've seen this happen.) > Yes, I see that moving this state between servers requires the entire > message flow. But, if we forget that for now, and just consider that I > have some mail in my local client cache, which I feel is now worthy of > a state change, why do I have to pass full-state baysian model > information? You appear to be arguing against a straw man of your own construction here, because AFAIK nobody has suggested such a thing. > I just want to tell an MS "change your own flags to match > my flags" in the hard sense: yes-or-no, not some qualitative weighting > model. The only "weight" people have mentioned in any of this is storing a spam score rather than a yes/no indicator. I've already responded that while there is a place for such information in spam handling, it makes no sense in this particular context. > How it acts, is up to it. I don't see why I need a complex flag > model to say what I think, as the consumer of the mail. Again, you appear to be arguing against a proposal nobody has made. (Perhaps some proposal was made in an earlier thread not on the imapext list.) I'll also point out that flags are binary by definition in IMAP - you cannot implement even a single-valued spam score using them. If you want to store a reviseable per-message score, you have no choice but to use message-level annotations. > If I moved off SPAM/HAM to white/black on sender, would that be easier > for you to consider? Whitelisting and blacklisting is actually a fairly different problem. Ned From cyrus@daboo.name Tue Jul 7 08:15:23 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1325D28C4C4 for ; Tue, 7 Jul 2009 08:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqrOytufu6Pf for ; Tue, 7 Jul 2009 08:15:22 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id D35E328C4C0 for ; Tue, 7 Jul 2009 08:15:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 6B24B1680AD5; Tue, 7 Jul 2009 11:15:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPdNDLFU4hpp; Tue, 7 Jul 2009 11:15:11 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id A54A91680ACE; Tue, 7 Jul 2009 11:15:08 -0400 (EDT) Date: Tue, 07 Jul 2009 11:15:04 -0400 From: Cyrus Daboo To: Ned Freed , Lyndon Nerenberg Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing Message-ID: In-Reply-To: <01NB13KIAQHQ001ML6@mauve.mrochek.com> References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <1246902821.8602.70.camel@legolas.orthanc.ca> <01NAZWHC66ZU000078@mauve.mrochek.com> <1246904761.8602.86.camel@legolas.orthanc.ca> <01NB13KIAQHQ001ML6@mauve.mrochek.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=3318 Cc: ietf-imapext@imc.org, discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 15:15:23 -0000 Hi Ned, --On July 7, 2009 7:22:42 AM -0700 Ned Freed wrote: > Now suppose I implement this with folder annotations. I'm in business > immediately. Things just work no matter what client people use. Actually you need to consider what the user experience is likely to be on the client side. There are several things to consider: for spam messages users will typically want to delete them from their regular mailbox. With ham messages they will typically want to leave the message in place (or file them away after processing). In each case I certainly would not want the spam messages or an extra copy of the ham messages to reside on my server consuming quota or other resources, or being indexed as part of a server-wide search etc. With that in mind lets look at how each solution might work client-side: 1) Keywords: for a spam message the user sets the spam keyword, then sets the deleted flag (and then may explicitly expunge if the client has that as an option as opposed to hide-deleted-messages with lazy expunge). For a ham message the user just sets the ham keyword. i.e. two user operations for spam, one for ham. 2) Mailbox (I am going to assume that the client has both a move and copy command available - the former implicitly setting the delete flag after the IMAP COPY command): for a spam message the user moves the message to the spam mailbox. For a ham message the user copies the message to the ham mailbox. NB both of these assume that the server does not actually store the spam/ham messages in the spam/ham mailboxes (or perhaps it garbage collects them). Things to note: typically clients don't offer shortcuts "move to mailbox X" or "copy to mailbox X" so the mailbox operations will involve some drag and drop or menu list selection operation. The same may be true for setting arbitrary keywords (though Mail.app and I suspect Thunderbird do have buttons for this). Frankly the best user experience would be for the client to have spam/ham buttons and commands that would allow the user to do the appropriate actions in one click or keyboard shortcut operation - that is certainly important if the level of spam is moderate to high. So at the end of the day, for the best (and frankly simplest) user experience clients do have to change for both the keyword and move to mailbox approaches. Now for keywords that change does have to be immediate if arbitrary keyword support is not already present in the client, whereas for move to mailbox, or clients already supporting keywords, that change can be done over time - though as Ned points out client changes tend to happen on geological time-scales! So other approaches to consider: 1) An extension with commands SPAM and HAM to explicitly tag one or more messages. 2) A "forward to spam/ham" option that specifies special email addresses for the user where spam/ham can be forwarded to trigger training. 3) An IMAP URL handed off to the SPAM system with URLAUTH to allow that to pull details of the message for training. (This could be tied to (2) in that forward-without-download could be used in (2) with URLAUTH etc). These of course all require new client/server behaviors and thus are probably non-starters, but they should not be dismissed entirely. -- Cyrus Daboo From ned.freed@mrochek.com Tue Jul 7 09:01:53 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00E1E28C29E for ; Tue, 7 Jul 2009 09:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRFQDFdQ7uT7 for ; Tue, 7 Jul 2009 09:01:52 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id F0B6728C1D3 for ; Tue, 7 Jul 2009 09:01:51 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB16I3I5TS0017B6@mauve.mrochek.com> for discuss@ietf.org; Tue, 7 Jul 2009 09:01:56 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB09YSB36O001ML6@mauve.mrochek.com>; Tue, 07 Jul 2009 09:01:52 -0700 (PDT) Date: Tue, 07 Jul 2009 08:43:46 -0700 (PDT) From: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-reply-to: "Your message dated Tue, 07 Jul 2009 11:15:04 -0400" To: Cyrus Daboo Message-id: <01NB16I1ENDC001ML6@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed Content-transfer-encoding: 7BIT References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <1246902821.8602.70.camel@legolas.orthanc.ca> <01NAZWHC66ZU000078@mauve.mrochek.com> <1246904761.8602.86.camel@legolas.orthanc.ca> <01NB13KIAQHQ001ML6@mauve.mrochek.com> Cc: ietf-imapext@imc.org, Lyndon Nerenberg , Ned Freed , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 16:01:53 -0000 > Hi Ned, > --On July 7, 2009 7:22:42 AM -0700 Ned Freed wrote: > > Now suppose I implement this with folder annotations. I'm in business > > immediately. Things just work no matter what client people use. > Actually you need to consider what the user experience is likely to be on > the client side. There are several things to consider: for spam messages > users will typically want to delete them from their regular mailbox. With > ham messages they will typically want to leave the message in place (or > file them away after processing). In each case I certainly would not want > the spam messages or an extra copy of the ham messages to reside on my > server consuming quota or other resources, or being indexed as part of a > server-wide search etc. > With that in mind lets look at how each solution might work client-side: > 1) Keywords: for a spam message the user sets the spam keyword, then sets > the deleted flag (and then may explicitly expunge if the client has that as > an option as opposed to hide-deleted-messages with lazy expunge). For a ham > message the user just sets the ham keyword. i.e. two user operations for > spam, one for ham. > 2) Mailbox (I am going to assume that the client has both a move and copy > command available - the former implicitly setting the delete flag after the > IMAP COPY command): for a spam message the user moves the message to the > spam mailbox. For a ham message the user copies the message to the ham > mailbox. NB both of these assume that the server does not actually store > the spam/ham messages in the spam/ham mailboxes (or perhaps it garbage > collects them). > Things to note: typically clients don't offer shortcuts "move to mailbox X" > or "copy to mailbox X" so the mailbox operations will involve some drag and > drop or menu list selection operation. The same may be true for setting > arbitrary keywords (though Mail.app and I suspect Thunderbird do have > buttons for this). Frankly the best user experience would be for the client > to have spam/ham buttons and commands that would allow the user to do the > appropriate actions in one click or keyboard shortcut operation - that is > certainly important if the level of spam is moderate to high. The presence of spam/not-spam buttons in existing clients is an important factor I hadn't really considered, but I think it has implications that go a lot further than you let on here. Simply put, if enough popular clients already have such buttons, and those buttons do different things in different clients, I think we're pretty much screwed. Given the presence of such buttons you're not going to be able to get users to do something different to deal with spam, whether it's adding a keyword or annotation or performing a folder move. Our only recourse with such clients in the mix is to write a specification for what such buttons should do in terms of signalling the server and then hope that clients actually adopt whatever that specification says. And frankly, if there's some degree of commonality in what those buttons do in existing clients and it can be made to work, we probably should adopt that approach no matter what it happens to be. > So at the end of the day, for the best (and frankly simplest) user > experience clients do have to change for both the keyword and move to > mailbox approaches. Now for keywords that change does have to be immediate > if arbitrary keyword support is not already present in the client, whereas > for move to mailbox, or clients already supporting keywords, that change > can be done over time - though as Ned points out client changes tend to > happen on geological time-scales! I agree completely that a keyword-based approach has the potential to offer a better user experience. The question is whether the possibility of offering a better user experience at some distant point down the road is worth giving up on a more immediately deployable solution. But as I indicated above, now that you've brought up the important point of existing clients having spam classification buttons, that's the real gorilla in the room we have to deal with. > So other approaches to consider: > 1) An extension with commands SPAM and HAM to explicitly tag one or more > messages. > 2) A "forward to spam/ham" option that specifies special email addresses > for the user where spam/ham can be forwarded to trigger training. I believe this is what the buttons I've seen on at least a couple of clients already do. If that's indeed the case, it's worth considering. > 3) An IMAP URL handed off to the SPAM system with URLAUTH to allow that to > pull details of the message for training. (This could be tied to (2) in > that forward-without-download could be used in (2) with URLAUTH etc). > These of course all require new client/server behaviors and thus are > probably non-starters, but they should not be dismissed entirely. I'm actually not sure (2) does with all clients, but I agree regarding (1) and (3). Ned From lyndon@orthanc.ca Tue Jul 7 10:31:22 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BABD53A6EAB for ; Tue, 7 Jul 2009 10:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2hMNvlNqdcF for ; Tue, 7 Jul 2009 10:31:21 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [208.86.224.138]) by core3.amsl.com (Postfix) with ESMTP id 9D53A3A6E9C for ; Tue, 7 Jul 2009 10:31:21 -0700 (PDT) Received: from [192.168.0.42] (S01060011242eafe2.cg.shawcable.net [68.145.131.177]) (authenticated bits=0) by orthanc.ca (8.14.3/8.14.3) with ESMTP id n67HVJe6030816; Tue, 7 Jul 2009 11:31:20 -0600 (MDT) (envelope-from lyndon@orthanc.ca) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orthanc.ca; s=2009-1; t=1246987881; bh=dqQG1R61W3fm+QI72VYQMJEiJ/ert5IkyFlRyhkB2Q0=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id:Mime-Version:Content-Transfer-Encoding; b=Teu5CztYJbN9luvvex3j2ymkN17mq/1iXMk1anpY1/j8DxZfn4a/XHg5Cg6JLeF5z TL9mrgBINQE/bFmUP8M6IyE9Y9yd+XCBn8zGqvNoqniN3VI4uFWX1jOcVTeplLDMj+ fdjCbtx0NB+q2A6iYhvgz/yi87heqHncOJ9m1sSCSiSU8xfC/Hwr1ARTonjCuRVt+f QXZfz5u+0giKTGpvmo6pCbG+njBtMjjfu9Ql3DfzwbUndDt/IYpltzE9PaaIrNJZRM uIog/qABIwS5SzIc41Jm/b3Gti4FNPXfPXJM3kgiLS8ldJBs/gt9Jx4C1YXVtK6XRN D/I7pLQ9Kumgw== Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing From: Lyndon Nerenberg To: Iljitsch van Beijnum In-Reply-To: References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <01NAZUST62HQ001DLH@mauve.mrochek.com> <1246902821.8602.70.camel@legolas.orthanc.ca> Content-Type: text/plain Date: Tue, 07 Jul 2009 11:31:13 -0600 Message-Id: <1246987873.8602.92.camel@legolas.orthanc.ca> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: ietf-imapext@imc.org, discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 17:31:22 -0000 On Tue, 2009-07-07 at 09:21 +0200, Iljitsch van Beijnum wrote: > 3. manually flagged as spam > 4. manually flagged as non-spam > > Where 1 and 2 / 3 and 4 are mutually exclusive but 1 + 4 and 2 + 3 > should trigger retraining of baysian filters etc. The keywords I'm describing are intended to tell the server to process the flagged message through its filters (i.e. train on the message). It isn't relevant to the proposal whether a human sets them, just what the server's behaviour is in their presence. --lyndon From alexey.melnikov@isode.com Tue Jul 7 13:48:00 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E07B3A682B for ; Tue, 7 Jul 2009 13:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeiNZJjBT9JQ for ; Tue, 7 Jul 2009 13:47:59 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id E1D6A3A688C for ; Tue, 7 Jul 2009 13:47:58 -0700 (PDT) Received: from [94.197.216.96] (94.197.216.96.threembb.co.uk [94.197.216.96]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 7 Jul 2009 21:47:39 +0100 Message-ID: <4A53B411.6040201@isode.com> Date: Tue, 07 Jul 2009 21:46:09 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps Discuss , alexey-melnikov-chairs@tools.ietf.org Subject: Alexey's Apps Area Activity Report for June 2009 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 20:48:00 -0000 Please let me know if you think the information below is not accurate. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Document Status and Progress Active documents, my action: - draft-duerst-mailto-bis - promised Martin D=FCrst to review this document - draft-ietf-sasl-scram (my own document) - need to update as per channel bindings related changes in SASL GS2 draft. - draft-ietf-webdav-bind (Experimental) - need to address 3 DISCUSSes (Adrian, Robert, Cullen), in particular about the document "updating the base WebDAV spec". Also need to approve erratum about IANA procedure for=20 HTTP status code registrations. Active documents in IETF LC or IESG review: - draft-hollenbeck-rfc493*bis - in IESG review In RFC Editor's queue: - draft-ietf-ltru-4645bis (Informational) - draft-ietf-ltru-4646bis (BCP) - draft-ietf-lemonade-streaming (Informational) - draft-ietf-lemonade-notifications (Informational) - draft-crocker-email-arch (Informational) Published as RFCs: - draft-ncook-urlauth-accessid (Proposed Standard) - RFC 5593 - draft-thomson-beep-async (Experimental) - RFC 5573 Active documents, waiting on others: - draft-dusseault-http-patch (Unknown) - waiting for shepherding=20 write-up before requesting IETF LC List of DISCUSSes I am currently holding: Really Old: draft-ietf-bfd-base-09.txt draft-ietf-ipfix-file-03.txt draft-ietf-ipfix-exporting-type-04.txt draft-ietf-ntp-ntpv4-proto-11.txt draft-mraihi-inch-thraud-08.txt Old: draft-ietf-mmusic-sdp-capability-negotiation-10.txt New (last 2 weeks week): draft-ietf-avt-rtcpssm-18.txt draft-ietf-mipshop-mos-dns-discovery-06.txt draft-ietf-ltans-dssc-09.txt draft-ietf-dime-diameter-api-08.txt Other activities/actions: Done: - Reviewed and approved most of the errata for various Lemonade and=20 Sieve WG documents - Approval of application/mp21 MIME type registation from ISO/IEC=20 21000-9:2005/Amd.1:2008 - Migrated www.apps.ietf.org to another machine - most of the work was=20 done by Ned Freed - Discussed Timezone registry proposal with Cyrus Daboo - a presentation=20 is coming in Stockholm - Convinced Dave Cridland to post draft-cridland-acap-vendor-registry,=20 which makes the ACAP vendor registry non-ACAP specific - to be reused by=20 vCard 4.0 spec. Ongoing: - Request to review 2 new MIME type registrations (some activity on the first 2): - Request for registration for 3gpp-ims+xml: waiting for the author=20 to update the document referenced by the registration - Request for registration for multiple MIME types () from Library of Congress: need to advise on the best way forward with this. My action: - Need to review OAuth document regarding possible reuse of SCRAM - Need to post 4954bis (SMTP AUTH) in order to start moving it to Draft Standard Waiting for others: - Suggestion to move LMTP to Standard Track (Ned Freed agreed to update the document, Chris Newman agreed to shepherd it) - Suggestion to convert MIME BNF to ABNF and publish as a separate draft (Ned Freed agreed to do this) WG Status: 1) EAI - updated IMAP and POP documents posted. A draft with EAI POP=20 scenarios posted (individual submission), several other draft. Some discussion about algorithmic construction of ASCII-only=20 alt-addresses from Unicode versions 2) Lemonade [In shutting down state] - all documents are in RFC Editor's=20 queue, 2 documents are in AUTH48 (Lemonade Notifications and Lemonade=20 Profile Bis) 3) LTRU - all active documents approved for publication 4) MORG - multimailbox search draft was updated. Also some discussion=20 about mail revocation (individual submission) 5) VCARDDAV - Discussions about LDAP mapping for vCards, timezone=20 registry and new properties. From anthonybryan@gmail.com Tue Jul 7 15:14:26 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1863A6A85 for ; Tue, 7 Jul 2009 15:14:26 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2PRglZfaE3a for ; Tue, 7 Jul 2009 15:14:24 -0700 (PDT) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.210.182]) by core3.amsl.com (Postfix) with ESMTP id 879E73A68B4 for ; Tue, 7 Jul 2009 15:14:24 -0700 (PDT) Received: by yxe12 with SMTP id 12so8285241yxe.29 for ; Tue, 07 Jul 2009 15:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/8GiNn3uauHtsmzrXieWfmk8uuMFJp5TaQ8Z7uMU6XE=; b=ak6twgJ7b1+xREeUArkaGDTaNHF97RDPJZi5Vf+Q5PWAq97AmI6pNU8XiJoplfwCUH UxcGMFs+xM3KHhvCylfU1nZpKaGYzuaCnmfSRY/mVrRqQVbVVcj2DbmUvKTK/BrT7C8i ed0Lz1A34SunEIRCFD83mlJxTmfEfEnHgqFlk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=b7l8Zwir//MdDOQr5wRFruWKgV1O5Vq8GG4i07u91l9ax/m96SdbEUulsJQd+DL5rY kiH4jnBCoX8XVeHN69Wio94YKLVjpe1vao43UEQ7a5RdtzM/Qjs6xWrHgn6L06sxVmv7 KnOUEPCNsiJKHJ2Cv8n9rzL0TLmtMCatVAhbs= MIME-Version: 1.0 Received: by 10.150.53.2 with SMTP id b2mr718369yba.71.1247004825772; Tue, 07 Jul 2009 15:13:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jul 2009 18:13:45 -0400 Message-ID: Subject: Re: Lisa's Apps Area Activity Report for Jun 2009 From: Anthony Bryan To: Lisa Dusseault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisa-dusseault-chairs@tools.ietf.org, discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 22:14:26 -0000 Progress continues on the Metalink ID ( http://tools.ietf.org/html/draft-bryan-metalink ). With guidance from Eran Hammer-Lahav, we are focusing on the Metalink XML file format. We've currently addressed all feedback, and welcome more. Metalink is an XML-based document format that describes a file or lists of files to be added to a download queue. Lists are composed of a number of files, each with an extensible set of attached metadata. For example, each file can have a description, checksum, and list of URIs that it is available from. The primary use case that Metalink addresses is the description of downloadable content in a format so download agents can act intelligently and recover from common errors with little or no user interaction necessary. These errors can include multiple servers going down and data corrupted in transmission. On Mon, Jul 6, 2009 at 7:58 PM, Lisa Dusseault wr= ote: > News, Updates > Bar BoF planning: thx to MNot, we have a centralized place to > coordinate/inform: > http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75 > =A0 =A0 =A0- IRIs > =A0 =A0 =A0- FTP? various extensions > =A0 =A0 =A0- 6LOWAPP: low power, grid and home device applications > > BOFs: > =A0 =A0- OGPX: Proposed BOF on virtual worlds interoperability, more spec= ific > than MMOX > > APPAREA: topics on message recall, timezone registry, SCTP, FTP gateway f= or > IPv4/iPv6, and accepting other suggestions > > Document Status and Progress > Active documents, my action: > - draft-ietf-calsify-2446bis (PS): checking with chair on whether the Las= t > Call issues were dealt with > > Active documents, waiting on other: > - draft-montemurro-gsma-imei-urn (Exp): New version of draft expected > - draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review a= nd > writeup > - draft-ietf-sieve-mime-loop (PS): Waiting on authors to respond to GenAr= t > review > > Finished processing -- new in RFC Ed queue and new RFCs > -draft-livingood-woundy-p4p-experiences (Info): Approved-- announcement s= ent > -- soon to be in RFC Ed queue > > > WG Status > > ALTO: Some discussion on problem statement and requirements drafts. > CALSIFY: RFC2445bis held up on code license issues. > HTTPBIS: Discussion on core specs issues, content-sniffing draft (not a W= G > product) > IDNABIS: =A0New version on mapping: =A0please read > http://tools.ietf.org/html/draft-ietf-idnabis-mappings-01. =A0WG is calli= ng > for rough consensus on its documents this summer. > OAUTH: Split document into 2: authentication and Web delegation > SIEVE: =A0A couple fresh drafts, but not much discussion > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From geeohgeegeeoh@gmail.com Tue Jul 7 16:52:18 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1D533A6982 for ; Tue, 7 Jul 2009 16:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VEnuulC8MHv for ; Tue, 7 Jul 2009 16:52:17 -0700 (PDT) Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id E46753A6A45 for ; Tue, 7 Jul 2009 16:52:17 -0700 (PDT) Received: by pzk36 with SMTP id 36so5186940pzk.29 for ; Tue, 07 Jul 2009 16:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=uri6F1NXp3iCgMWpBjPCHOhy9HNrz/zI5lMaIjSrzk4=; b=M9GXGgvziIdTGpxBO6ouWz+AtDOFtRp/KQ1MOz1dnKD/dRVEYiRByj3Bs8RyZfxuLc RGyH3OQ2FoBMownLEw3e2MpjKeJX0KCsL5TrCelQc2cI+jPtoGJO5mMZr2GontibMAmf WTTWUC63j8rxZT/RVuVdF0JKz1GJ6YNp8obxc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=pwmzwC7oiXcLdp2YDbfbSqxJhSGiXEsRmtfOLSBgBKbBJDt2Cuo6q/KLAJ+MGVRP95 CiPxCaPWOR0prxLuu5nT+dIua/GbXHjSWYvdUmKX380Lfljkfk3E8+htrzxRrh8Qy531 ShDzc5Qe/0OA4j0/BA2wsabFTf/mqEkPl0x6c= Received: by 10.140.204.7 with SMTP id b7mr3237099rvg.2.1247010185520; Tue, 07 Jul 2009 16:43:05 -0700 (PDT) Received: from 192-168-1-5.tpgi.com.au (60-240-104-100-nsw-pppoe.tpgi.com.au [60.240.104.100]) by mx.google.com with ESMTPS id k41sm6165046rvb.47.2009.07.07.16.43.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Jul 2009 16:43:04 -0700 (PDT) Sender: George Michaelson Message-Id: From: George Michaelson To: Ned Freed In-Reply-To: <01NB14JAPS8E001ML6@mauve.mrochek.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing Date: Wed, 8 Jul 2009 09:42:58 +1000 References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> <01NAZVQAYWH4001DLH@mauve.mrochek.com> <47CB230E-B713-4098-82D4-318744434C46@pobox.com> <01NB0BOZYUPY001ML6@mauve.mrochek.com> <6DECD560-B257-4E6E-80E7-A99A69D297C6@pobox.com> <01NB14JAPS8E001ML6@mauve.mrochek.com> X-Mailer: Apple Mail (2.935.3) Cc: ietf-imapext@imc.org, general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 23:52:18 -0000 I have no desire to argue against my own proposal! sorry if I misunderstood the tenor of some comments to this suggestion. The original posting asked about two things 1) spam/ham 2) white/black so far, people seem to be focussing on 1). I acknowledge problems with 1), I appreciate that people are trying to address 1) as a possibility. I asked about 2). I asked you if, ignoring 1), it was possible or plausible to send white/black information about sender, if 1) was hard or intractable. Does that make more sense? I do realize white/black listing is a different PROBLEM to spam/ham marking, but neither of them currently have support directly in imap, and I imagine both of them would use IMAP extensions to pass information client-server. Sorry if I'm being unclear. I'm not subscribed to the IMAPEXT, or other lists, I have very little context for this beyond wanting a facility to cover a problem I see as a mail consumer. I'm not in the business of mail system development. I appreciate people spending time discussing this. I still think there is a tractable problem here, some class of IMAP extension will permit better information flow from the client side. cheers -G From ned.freed@mrochek.com Tue Jul 7 20:11:01 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DFBC3A691C for ; Tue, 7 Jul 2009 20:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6PXtZuSolAj for ; Tue, 7 Jul 2009 20:11:00 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 90C233A6A1F for ; Tue, 7 Jul 2009 20:11:00 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB1TV23J0G00SKEL@mauve.mrochek.com> for discuss@ietf.org; Tue, 7 Jul 2009 20:11:19 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB09YSB36O001ML6@mauve.mrochek.com>; Tue, 07 Jul 2009 20:11:16 -0700 (PDT) Date: Tue, 07 Jul 2009 20:02:51 -0700 (PDT) From: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-reply-to: "Your message dated Wed, 08 Jul 2009 09:42:58 +1000" To: George Michaelson Message-id: <01NB1TV04NJS001ML6@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; delsp=yes Content-transfer-encoding: 7BIT References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> <01NAZVQAYWH4001DLH@mauve.mrochek.com> <47CB230E-B713-4098-82D4-318744434C46@pobox.com> <01NB0BOZYUPY001ML6@mauve.mrochek.com> <6DECD560-B257-4E6E-80E7-A99A69D297C6@pobox.com> <01NB14JAPS8E001ML6@mauve.mrochek.com> Cc: ietf-imapext@imc.org, Ned Freed , general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 03:11:01 -0000 > I have no desire to argue against my own proposal! sorry if I > misunderstood the tenor of some comments to this suggestion. > The original posting asked about two things > 1) spam/ham > 2) white/black > so far, people seem to be focussing on 1). I acknowledge problems with > 1), I appreciate that people are trying to address 1) as a possibility. > I asked about 2). I asked you if, ignoring 1), it was possible or > plausible to send white/black information about sender, if 1) was hard > or intractable. Of course it's possible, but this has no business being in IMAP. IMAP is a message access protocol, not an address handling protocol. It is also already quite complex, and extending its function to include what amountss to a specialized address book capability is a really bad idea IMO. In fact a pretty good case can be made that it's inappropriate to use IMAP for spam/ham classification, but at the spam/ham classification is intrinsicly tied to messages in the store. The same cannot be said for address white and blacklisting. > Does that make more sense? I do realize white/black listing is a > different PROBLEM to spam/ham marking, but neither of them currently > have support directly in imap, and I imagine both of them would use > IMAP extensions to pass information client-server. The place where I'd like to see white and black listing done is in CARDDAV, not IMAP. Ned From iljitsch@muada.com Tue Jul 7 23:08:17 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F8A28C320 for ; Tue, 7 Jul 2009 23:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpg299iAK3oq for ; Tue, 7 Jul 2009 23:08:17 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 008D828C334 for ; Tue, 7 Jul 2009 23:08:16 -0700 (PDT) Received: from [192.168.0.193] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n686896f066815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jul 2009 08:08:12 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Ned Freed In-Reply-To: <01NB1TV04NJS001ML6@mauve.mrochek.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing Date: Wed, 8 Jul 2009 08:08:05 +0200 References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> <01NAZVQAYWH4001DLH@mauve.mrochek.com> <47CB230E-B713-4098-82D4-318744434C46@pobox.com> <01NB0BOZYUPY001ML6@mauve.mrochek.com> <6DECD560-B257-4E6E-80E7-A99A69D297C6@pobox.com> <01NB14JAPS8E001ML6@mauve.mrochek.com> <01NB1TV04NJS001ML6@mauve.mrochek.com> X-Mailer: Apple Mail (2.930.3) Cc: ietf-imapext@imc.org, George Michaelson , general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 06:08:18 -0000 On 8 jul 2009, at 5:02, Ned Freed wrote: > The place where I'd like to see white and black listing done is in > CARDDAV, not > IMAP. I never felt comfortable uploading all my contact info to Google. (May be somewhat strange since they do have all the mail sent to one of my email addresses.) So I think white/blacklists shouldn't be complete contact info, but rather, just lists of hashes of email addresses. From ned.freed@mrochek.com Tue Jul 7 23:26:46 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9A33A6981 for ; Tue, 7 Jul 2009 23:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azTS1LxBwavA for ; Tue, 7 Jul 2009 23:26:45 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 283FF3A6835 for ; Tue, 7 Jul 2009 23:26:45 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB20PU9RC0018VKL@mauve.mrochek.com> for discuss@ietf.org; Tue, 7 Jul 2009 23:27:09 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB09YSB36O001ML6@mauve.mrochek.com>; Tue, 07 Jul 2009 23:27:07 -0700 (PDT) Date: Tue, 07 Jul 2009 23:19:32 -0700 (PDT) From: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-reply-to: "Your message dated Wed, 08 Jul 2009 08:08:05 +0200" To: Iljitsch van Beijnum Message-id: <01NB20PSV3XE001ML6@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; delsp=yes Content-transfer-encoding: 7BIT References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> <01NAZVQAYWH4001DLH@mauve.mrochek.com> <47CB230E-B713-4098-82D4-318744434C46@pobox.com> <01NB0BOZYUPY001ML6@mauve.mrochek.com> <6DECD560-B257-4E6E-80E7-A99A69D297C6@pobox.com> <01NB14JAPS8E001ML6@mauve.mrochek.com> <01NB1TV04NJS001ML6@mauve.mrochek.com> Cc: ietf-imapext@imc.org, Ned Freed , George Michaelson , general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 06:26:46 -0000 > On 8 jul 2009, at 5:02, Ned Freed wrote: > > The place where I'd like to see white and black listing done is in > > CARDDAV, not > > IMAP. > I never felt comfortable uploading all my contact info to Google. (May > be somewhat strange since they do have all the mail sent to one of my > email addresses.) That's fine, but this doesn't translate into a need to put an addressbook capability in IMAP. > So I think white/blacklists shouldn't be complete contact info, but > rather, just lists of hashes of email addresses. So use CARDDAV to only upload the stuff that's needed to Google. Problem solved. I'll also note that addressbook programs have had facilities for exporting subsets of the information they contain pretty much from the start. So doing this is hardly entering new territory. And most users want an authoritative address book with all their contact information in one place. I know I do - it's much too confusing otherwise. Ned From alexey.melnikov@isode.com Wed Jul 8 03:14:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6BE23A6F19 for ; Wed, 8 Jul 2009 03:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.805 X-Spam-Level: X-Spam-Status: No, score=-2.805 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJ-jFZkW3Txn for ; Wed, 8 Jul 2009 03:14:15 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 749D93A6F16 for ; Wed, 8 Jul 2009 03:13:55 -0700 (PDT) Received: from [94.197.220.252] (94.197.220.252.threembb.co.uk [94.197.220.252]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 8 Jul 2009 11:09:14 +0100 Message-ID: <4A54701C.6080107@isode.com> Date: Wed, 08 Jul 2009 11:08:28 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: George Michaelson Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> <01NAZVQAYWH4001DLH@mauve.mrochek.com> <47CB230E-B713-4098-82D4-318744434C46@pobox.com> <01NB0BOZYUPY001ML6@mauve.mrochek.com> <6DECD560-B257-4E6E-80E7-A99A69D297C6@pobox.com> <01NB14JAPS8E001ML6@mauve.mrochek.com> <01NB1TV04NJS001ML6@mauve.mrochek.com> In-Reply-To: <01NB1TV04NJS001ML6@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-imapext@imc.org, Ned Freed , general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 10:14:15 -0000 Ned Freed wrote: >> I have no desire to argue against my own proposal! sorry if I >> misunderstood the tenor of some comments to this suggestion. > >> The original posting asked about two things > >> 1) spam/ham > >> 2) white/black > >> so far, people seem to be focussing on 1). I acknowledge problems with >> 1), I appreciate that people are trying to address 1) as a possibility. > >> I asked about 2). I asked you if, ignoring 1), it was possible or >> plausible to send white/black information about sender, if 1) was hard >> or intractable. > > Of course it's possible, but this has no business being in IMAP. IMAP > is a > message access protocol, not an address handling protocol. It is also > already > quite complex, and extending its function to include what amountss to a > specialized address book capability is a really bad idea IMO. > > In fact a pretty good case can be made that it's inappropriate to use > IMAP for spam/ham classification, but at the spam/ham classification is > intrinsicly tied to messages in the store. The same cannot be said for > address white and blacklisting. +1 >> Does that make more sense? I do realize white/black listing is a >> different PROBLEM to spam/ham marking, but neither of them currently >> have support directly in imap, and I imagine both of them would use >> IMAP extensions to pass information client-server. > > The place where I'd like to see white and black listing done is in > CARDDAV, not > IMAP. Or LDAP :-). There is also a Sieve extension for making use of whitelists/blacklists during mail delivery. See draft-melnikov-sieve-external-lists-02.txt. It can work with CARDDAV, LDAP and other things. From Anil.Srivastava@Sun.COM Tue Jul 7 20:50:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B864628C111 for ; Tue, 7 Jul 2009 20:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWU2ahFFyxpw for ; Tue, 7 Jul 2009 20:50:31 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id E99193A6884 for ; Tue, 7 Jul 2009 20:50:30 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n683okAK023864 for ; Tue, 7 Jul 2009 20:50:46 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMG001002MKDM00@fe-sfbay-09.sun.com> for discuss@ietf.org; Tue, 07 Jul 2009 20:50:46 -0700 (PDT) Received: from [192.168.132.10] ([unknown] [129.150.24.16]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMG00M0Z2OLJYD0@fe-sfbay-09.sun.com>; Tue, 07 Jul 2009 20:50:46 -0700 (PDT) Date: Tue, 07 Jul 2009 20:50:40 -0700 (PDT) From: Anil SRIVASTAVA Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-reply-to: <01NB1TV04NJS001ML6@mauve.mrochek.com> Sender: Anil.Srivastava@Sun.COM To: Ned Freed Message-id: Organization: Sun Microsystems [http://www.sun.com] Accept-Language: English; en X-Message-Class: normal X-Endorsement: Message brought to you by Sun Java Communication Suite 6 References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> <01NAZVQAYWH4001DLH@mauve.mrochek.com> <47CB230E-B713-4098-82D4-318744434C46@pobox.com> <01NB0BOZYUPY001ML6@mauve.mrochek.com> <6DECD560-B257-4E6E-80E7-A99A69D297C6@pobox.com> <01NB14JAPS8E001ML6@mauve.mrochek.com> <01NB1TV04NJS001ML6@mauve.mrochek.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) X-Message-flag: Outlook: the best virus distribution system around X-Mailman-Approved-At: Wed, 08 Jul 2009 09:03:19 -0700 Cc: ietf-imapext@imc.org, George Michaelson , general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anil.Srivastava@Sun.COM List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 03:50:31 -0000 On 2009-07-07/20:02 [-0700], ned.freed@mrochek.com [Ned Freed] wrote: > > > I have no desire to argue against my own proposal! sorry if I > > misunderstood the tenor of some comments to this suggestion. > > > The original posting asked about two things > > > 1) spam/ham > > > 2) white/black > > > so far, people seem to be focussing on 1). I acknowledge problems with > > 1), I appreciate that people are trying to address 1) as a possibility. > > > I asked about 2). I asked you if, ignoring 1), it was possible or > > plausible to send white/black information about sender, if 1) was hard > > or intractable. > > Of course it's possible, but this has no business being in IMAP. IMAP is > a message access protocol, not an address handling protocol. It is also > already quite complex, and extending its function to include what > amountss to a specialized address book capability is a really bad idea > IMO. > > In fact a pretty good case can be made that it's inappropriate to > useIMAP for spam/ham classification, but at the spam/ham classification > is intrinsicly tied to messages in the store. The same cannot be said > for address white and blacklisting. > > > Does that make more sense? I do realize white/black listing is a > > different PROBLEM to spam/ham marking, but neither of them currently > > have support directly in imap, and I imagine both of them would use > > IMAP extensions to pass information client-server. > > The place where I'd like to see white and black listing done is in > CARDDAV, not IMAP. > +1 Anil > Ned > _______________ Anil SRIVASTAVA | anil.srivastava@Sun.COM | Sun Microsystems, Inc From ned.freed@mrochek.com Wed Jul 8 12:08:36 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B803A6918 for ; Wed, 8 Jul 2009 12:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cLq5WgZtgIg for ; Wed, 8 Jul 2009 12:08:35 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 14B463A68D4 for ; Wed, 8 Jul 2009 12:08:35 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB2RBB0E4G015OWJ@mauve.mrochek.com> for discuss@ietf.org; Wed, 8 Jul 2009 12:08:55 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB2NV4DYVK001ML6@mauve.mrochek.com>; Wed, 08 Jul 2009 12:08:52 -0700 (PDT) Date: Wed, 08 Jul 2009 11:54:05 -0700 (PDT) From: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-reply-to: "Your message dated Wed, 08 Jul 2009 11:08:28 +0100" <4A54701C.6080107@isode.com> To: Alexey Melnikov Message-id: <01NB2RB8UTA4001ML6@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed Content-transfer-encoding: 7BIT References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> <01NAZVQAYWH4001DLH@mauve.mrochek.com> <47CB230E-B713-4098-82D4-318744434C46@pobox.com> <01NB0BOZYUPY001ML6@mauve.mrochek.com> <6DECD560-B257-4E6E-80E7-A99A69D297C6@pobox.com> <01NB14JAPS8E001ML6@mauve.mrochek.com> <01NB1TV04NJS001ML6@mauve.mrochek.com> <4A54701C.6080107@isode.com> Cc: ietf-imapext@imc.org, Ned Freed , George Michaelson , general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 19:08:36 -0000 > Ned Freed wrote: > >> I have no desire to argue against my own proposal! sorry if I > >> misunderstood the tenor of some comments to this suggestion. > > > >> The original posting asked about two things > > > >> 1) spam/ham > > > >> 2) white/black > > > >> so far, people seem to be focussing on 1). I acknowledge problems with > >> 1), I appreciate that people are trying to address 1) as a possibility. > > > >> I asked about 2). I asked you if, ignoring 1), it was possible or > >> plausible to send white/black information about sender, if 1) was hard > >> or intractable. > > > > Of course it's possible, but this has no business being in IMAP. IMAP > > is a > > message access protocol, not an address handling protocol. It is also > > already > > quite complex, and extending its function to include what amountss to a > > specialized address book capability is a really bad idea IMO. > > > > In fact a pretty good case can be made that it's inappropriate to use > > IMAP for spam/ham classification, but at the spam/ham classification is > > intrinsicly tied to messages in the store. The same cannot be said for > > address white and blacklisting. > +1 > >> Does that make more sense? I do realize white/black listing is a > >> different PROBLEM to spam/ham marking, but neither of them currently > >> have support directly in imap, and I imagine both of them would use > >> IMAP extensions to pass information client-server. > > > > The place where I'd like to see white and black listing done is in > > CARDDAV, not > > IMAP. > Or LDAP :-). That's actually how we do it now. We're hoping to move to CARDDAV in the future. > There is also a Sieve extension for making use of whitelists/blacklists > during mail delivery. See draft-melnikov-sieve-external-lists-02.txt. > It can work with CARDDAV, LDAP and other things. Interestingly, this extension in its current form is not compatible with at least one of the proposals that was made here. The issue is one I've raised before - the fact that :list is separate argument and not a match type. Where there is clearly some utility in being able to say stuff along the lines of: header :contains :list "subject" "tag:dirty-word-list" The problem is that in order for this to work the list has to be enumerable. Not all lists are enumerable, and even some that are are so large even though oyu can enumerate them in theory you can't afford to do so in practice. One use case where this matters is when the list is a set of hashed values. The way you find if something is "on the list" is to hash it and see if that value appears. And even if the input string is short enough that you can enumerate all the unique substrings, how about :matches and :regex? Good luck with those. Hashed lists have in fact been proposed in the present discussion as a means of avoiding giving your address whitelist to the mail server. I happen not to think this is a useful thing to do for a variety of reasons, mostly having to do with address canonicalization (or lack thereof), but there are other use cases where hashed lists make more sense. So, although it reduces functionality, I believe :list should be a match type and the underlying comparison type that's done should be a property of the list itself. Ned From geeohgeegeeoh@gmail.com Wed Jul 8 15:27:24 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACBBF3A6F9D for ; Wed, 8 Jul 2009 15:27:24 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9+6QDNvX7u1 for ; Wed, 8 Jul 2009 15:27:23 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 79C803A6A6D for ; Wed, 8 Jul 2009 15:27:23 -0700 (PDT) Received: by ewy26 with SMTP id 26so2071632ewy.37 for ; Wed, 08 Jul 2009 15:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=TXGOqBBjbdG9nXZAFR79a2n2MsazOtTdRvdhoCvIooU=; b=NQk57XltAke0iE7kWCRT7H0wqFsmRkobkUn5XDMgS21BgacIhWqog3xlYn1RdmP6RI YLrgX6bpp9J/1f112knqqr9xnrhCrMb7raCi4GpQvvwOZZtAjv41E19s0NzKC/mQMeby eVn36eHb3AzFZyHIs/nScOpeGowqWF3ZuGX2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=ZwEzaNEjT+YsIf+t5klQYJEkYjykNSrF5W2HdSnz8c5SXePXIu6zu4YOOVKxBJCKmf ai/4sMfp3DF6ylc03AQWZTEMDR93uudksCQ9x3okpwUnv3Fmt9rFXvElZCPV2O4VRPHg Nn+b5V/J+DWWVxERWoF2yAmccVjbmIYdsO9Yg= Received: by 10.210.109.19 with SMTP id h19mr8612445ebc.56.1247092068279; Wed, 08 Jul 2009 15:27:48 -0700 (PDT) Received: from 192-168-1-5.tpgi.com.au (60-240-104-100-nsw-pppoe.tpgi.com.au [60.240.104.100]) by mx.google.com with ESMTPS id 7sm1176374eyg.19.2009.07.08.15.27.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Jul 2009 15:27:47 -0700 (PDT) Sender: George Michaelson Message-Id: <4A25E43A-83E3-4A59-9C0B-C334820275BF@pobox.com> From: George Michaelson To: Ned Freed In-Reply-To: <01NB1TV04NJS001ML6@mauve.mrochek.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing Date: Thu, 9 Jul 2009 08:27:39 +1000 References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> <01NAZVQAYWH4001DLH@mauve.mrochek.com> <47CB230E-B713-4098-82D4-318744434C46@pobox.com> <01NB0BOZYUPY001ML6@mauve.mrochek.com> <6DECD560-B257-4E6E-80E7-A99A69D297C6@pobox.com> <01NB14JAPS8E001ML6@mauve.mrochek.com> <01NB1TV04NJS001ML6@mauve.mrochek.com> X-Mailer: Apple Mail (2.935.3) Cc: ietf-imapext@imc.org, general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 22:27:24 -0000 >> > > The place where I'd like to see white and black listing done is in > CARDDAV, not > IMAP. > > Ned so there's only one real question: if it was standardized, would the likes of google implement it? How about the client side? because, unless its in gmail AND in the Apple Mail client, Thunderbird, Outlook, its not useful. -G From ned.freed@mrochek.com Wed Jul 8 17:49:54 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EFD13A6B54 for ; Wed, 8 Jul 2009 17:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VscX0xbv4Cfo for ; Wed, 8 Jul 2009 17:49:53 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 422D93A6802 for ; Wed, 8 Jul 2009 17:49:53 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB338IGJXS00QEO9@mauve.mrochek.com> for discuss@ietf.org; Wed, 8 Jul 2009 17:50:15 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NB32ESTD2800007A@mauve.mrochek.com>; Wed, 08 Jul 2009 17:50:13 -0700 (PDT) Date: Wed, 08 Jul 2009 17:30:06 -0700 (PDT) From: Ned Freed Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing In-reply-to: "Your message dated Thu, 09 Jul 2009 08:27:39 +1000" <4A25E43A-83E3-4A59-9C0B-C334820275BF@pobox.com> To: George Michaelson Message-id: <01NB338GXYBS00007A@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; delsp=yes Content-transfer-encoding: 7BIT References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> <01NAZVQAYWH4001DLH@mauve.mrochek.com> <47CB230E-B713-4098-82D4-318744434C46@pobox.com> <01NB0BOZYUPY001ML6@mauve.mrochek.com> <6DECD560-B257-4E6E-80E7-A99A69D297C6@pobox.com> <01NB14JAPS8E001ML6@mauve.mrochek.com> <01NB1TV04NJS001ML6@mauve.mrochek.com> <4A25E43A-83E3-4A59-9C0B-C334820275BF@pobox.com> Cc: ietf-imapext@imc.org, Ned Freed , general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 00:49:54 -0000 > >> > > > > The place where I'd like to see white and black listing done is in > > CARDDAV, not > > IMAP. > > > > Ned > so there's only one real question: if it was standardized, would the > likes of google implement it? How about the client side? This is actually one of the reasons why CARDDAV is a better choice to piggyback on. RIght now proprietary environments like Exchange/Outlook and Lotus Notes have a significant advantage over standards-based solutions: They provide a fully integrated mail/calendar/addressbook client experience. One reason standards-based solutions have a problem with this has been the lack of open protocols for accessing and manipulating calendar and addressbook information. But this is changing. CALDAV addresses the calendar access issue, CARDDAV does the same for address books. Once all the pieces are in place, and assuming we get the details right, this will allow standards-based clients and servers all to interoperate. Uptake isn't going to be fast because these are complex protocols and getting the integration right isn't easy. But for once the incentives appear to be woring for us, not against us. > because, unless its in gmail AND in the Apple Mail client, > Thunderbird, Outlook, its not useful. That may be true now, but at some point given sufficient adoption things flip around to where not having support for this stuff makes your client or server not useful. I note, however, that now that CALDAV is complete we see Apple, Thunderbird, and gmail all either supporting it or working on supporting it. It's a little much to expect Outlook to shift from it's currrent proprietary way of doing all this, but even Microsoft may eventually have no choice but to support the emerging standards in this area. Ned From cyrus@daboo.name Wed Jul 8 19:50:00 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FC543A6FC4 for ; Wed, 8 Jul 2009 19:50: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf-Maaj+wmfl for ; Wed, 8 Jul 2009 19:49:59 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 5B71A3A6FC8 for ; Wed, 8 Jul 2009 19:49:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 036E81691025; Wed, 8 Jul 2009 22:50:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mRu4KuRy9ZF; Wed, 8 Jul 2009 22:50:23 -0400 (EDT) Received: from [10.0.1.8] (unknown [10.0.1.1]) by daboo.name (Postfix) with ESMTP id 5D0B7169101A; Wed, 8 Jul 2009 22:50:23 -0400 (EDT) Date: Wed, 08 Jul 2009 22:50:22 -0400 From: Cyrus Daboo To: Ned Freed , George Michaelson Subject: Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing Message-ID: <20A9EE8D49D98D53C36F6F48@socrates.local> In-Reply-To: <01NB338GXYBS00007A@mauve.mrochek.com> References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> <01NAZVQAYWH4001DLH@mauve.mrochek.com> <47CB230E-B713-4098-82D4-318744434C46@pobox.com> <01NB0BOZYUPY001ML6@mauve.mrochek.com> <6DECD560-B257-4E6E-80E7-A99A69D297C6@pobox.com> <01NB14JAPS8E001ML6@mauve.mrochek.com> <01NB1TV04NJS001ML6@mauve.mrochek.com> <4A25E43A-83E3-4A59-9C0B-C334820275BF@pobox.com> <01NB338GXYBS00007A@mauve.mrochek.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=675 Cc: ietf-imapext@imc.org, general discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 02:50:00 -0000 Hi Ned, --On July 8, 2009 5:30:06 PM -0700 Ned Freed wrote: > I note, however, that now that CALDAV is complete we see Apple, > Thunderbird, and gmail all either supporting it or working on supporting > it. For a more comprehensive list of implementations see: . > It's a little much to expect Outlook to shift from it's currrent > proprietary way of doing all this, but even Microsoft may eventually have > no choice but to support the emerging standards in this area. In the meantime the folks at have a plugin for Outlook that does CalDAV and CardDAV. -- Cyrus Daboo From msk@cloudmark.com Wed Jul 8 14:49:55 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1C03A6E00 for ; Wed, 8 Jul 2009 14:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srtBVK22pKMG for ; Wed, 8 Jul 2009 14:49:54 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 127933A69A7 for ; Wed, 8 Jul 2009 14:49:37 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Wed, 8 Jul 2009 14:50:02 -0700 From: "Murray S. Kucherawy" To: "discuss@ietf.org" Date: Wed, 8 Jul 2009 14:50:01 -0700 Subject: Proposed WG charter for "arf" (Abuse Report Format) Thread-Topic: Proposed WG charter for "arf" (Abuse Report Format) Thread-Index: AcoAFgtYVs7crKUkQZ+iueuqC7iy5A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_BB012BD379D7B046ABE1472D8093C61C0112AA8C82EXCHC2corpclo_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 09 Jul 2009 05:53:33 -0700 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 21:49:55 -0000 --_004_BB012BD379D7B046ABE1472D8093C61C0112AA8C82EXCHC2corpclo_ Content-Type: multipart/alternative; boundary="_000_BB012BD379D7B046ABE1472D8093C61C0112AA8C82EXCHC2corpclo_" --_000_BB012BD379D7B046ABE1472D8093C61C0112AA8C82EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_BB012BD379D7B046ABE1472D8093C61C0112AA8C82EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

--_000_BB012BD379D7B046ABE1472D8093C61C0112AA8C82EXCHC2corpclo_-- --_004_BB012BD379D7B046ABE1472D8093C61C0112AA8C82EXCHC2corpclo_ Content-Type: text/plain; name="arf-charter v02.txt" Content-Description: arf-charter v02.txt Content-Disposition: attachment; filename="arf-charter v02.txt"; size=3123; creation-date="Tue, 16 Jun 2009 13:09:28 GMT"; modification-date="Wed, 08 Jul 2009 14:49:04 GMT" Content-Transfer-Encoding: base64 ICAgV29ya2luZyBHcm91cCBOYW1lOg0KICAgICAgICBBYnVzZSBSZXBvcnRpbmcgRm9ybWF0IChB UkYpDQoNCiAgIElFVEYgQXJlYToNCiAgICAgICAgQXBwbGljYXRpb25zIEFyZWENCg0KICAgQ2hh aXIocyk6DQogICAgICAgIFRCRA0KDQogICBBcHBsaWNhdGlvbnMgQXJlYSBEaXJlY3RvcihzKToN CiAgICAgICAgTGlzYSBEdXNzZWF1bHQgPExpc2EuRHVzc2VhdWx0QG1lc3NhZ2luZ2FyY2hpdGVj dHMuY29tPg0KICAgICAgICBBbGV4ZXkgTWVsbmlrb3YgPGFsZXhleS5tZWxuaWtvdkBpc29kZS5j b20+DQoNCiAgIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3I6DQogICAgICAgIFRCRA0KDQogICBN YWlsaW5nIExpc3RzOg0KICAgICAgICBHZW5lcmFsIERpc2N1c3Npb246IGFidXNlLWZlZWRiYWNr LXJlcG9ydEBtaXBhc3NvYy5vcmcNCiAgICAgICAgVG8gU3Vic2NyaWJlOiBodHRwOi8vbWlwYXNz b2Mub3JnL21haWxtYW4vbGlzdGluZm8vYWJ1c2UtZmVlZGJhY2stcmVwb3J0DQogICAgICAgIEFy Y2hpdmU6IGh0dHA6Ly9taXBhc3NvYy5vcmcvbWFpbG1hbi9saXN0aW5mby9hYnVzZS1mZWVkYmFj ay1yZXBvcnQNCg0KICAgRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoNCglNZXNzYWdpbmcg YW50aS1hYnVzZSBvcGVyYXRpb25zIGJldHdlZW4gaW5kZXBlbmRlbnQgc2VydmljZXMgb2Z0ZW4g cmVxdWlyZXMNCglzZW5kaW5nIHJlcG9ydHMgb24gb2JzZXJ2ZWQgZnJhdWQsIHNwYW0gdmlydXMg b3Igb3RoZXIgYWJ1c2UgYWN0aXZpdHkuICBBDQoJc3RhbmRhcmRpemVkIHJlcG9ydCBmb3JtYXQg ZW5hYmxlcyBhdXRvbWF0ZWQgcHJvY2Vzc2luZy4gIFRoZSBBYnVzZSBSZXBvcnRpbmcNCglGb3Jt YXQgKEFSRikgc3BlY2lmaWNhdGlvbiBoYXMgZ2FpbmVkIHN1ZmZpY2llbnQgcG9wdWxhcml0eSB0 byB3YXJyYW50IGZvcm1hbA0KCWNvZGlmaWNhdGlvbiwgdG8gZW5zdXJlIGZ1dHVyZSBpbnRlcm9w ZXJhYmlsaXR5IHdpdGggbmV3IGltcGxlbWVudGF0aW9ucy4NCglUaGUgcHJpbWFyeSBmdW5jdGlv biBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBiZSB0byBzb2xpY2l0IHJldmlldyBhbmQNCgly ZWZpbmVtZW50IG9mIHRoZSBleGlzdGluZyBzcGVjaWZpY2F0aW9uLg0KDQoJQVJGIHdhcyBkZXZl bG9wZWQgYnkgYSBtZXNzYWdpbmcgdHJhZGUgb3JnYW5pemF0aW9uIGluZGVwZW5kZW50IG9mIHRo ZSBJRVRGLA0KCWFuZCB1c2VzIGEgZm9ybWF0IHNpbWlsYXIgdG8gYSBEZWxpdmVyeSBTdGF0dXMg Tm90aWZpY2F0aW9uIChEU04sIFJGQzM0NjQpDQoJdG8gcmVwb3J0IGZyYXVkLCBzcGFtLCB2aXJ1 c2VzIG9yIG90aGVyIGFidXNpdmUgYWN0aXZpdHkgaW4gdGhlIGVtYWlsIHN5c3RlbS4NCglUaGUg YmFzaWMgZm9ybWF0IGlzIGFtZW5hYmxlIHRvIHByb2Nlc3NpbmcgYnkgaHVtYW5zIG9yIHNvZnR3 YXJlLCB3aXRoIHRoZQ0KCWxhdHRlciByZXF1aXJpbmcgdGhlIGZvcm1hdCB0byBiZSBzdGFuZGFy ZGl6ZWQsIHRvIHBlcm1pdCBpbnRlcm9wZXJhYmlsaXR5DQoJYmV0d2VlbiBhdXRvbWF0ZWQgc2Vy dmljZXMsIHBhcnRpY3VsYXJseSB3aXRob3V0IHByaW9yIGFycmFuZ2VtZW50Lg0KDQoJQVJGIGFz IGluaXRpYWxseSBkZWZpbmVkIGlzIGFscmVhZHkgaW4gd2lkZXNwcmVhZCB1c2UgYXQgbGFyZ2Ug SVNQcywgc28NCglpbnRlcm9wZXJhYmlsaXR5IGNhbiBiZSBkZW1vbnN0cmF0ZWQuICBTb21lIHRv b2xzIGFscmVhZHkgZXhpc3QNCglmb3IgcHJvY2Vzc2luZyBBUkYgbWVzc2FnZXMsIGEgZmV3IG9m IHdoaWNoIGFyZSBvcGVuIHNvdXJjZS4gIEluIG9yZGVyIHRvDQoJcHJlc2VydmUgdGhlIGluc3Rh bGxlZCBiYXNlLCB0aGUgd29ya2luZyBncm91cCB3aWxsIG1ha2UgdGhlIG1pbmltdW0gY2hhbmdl cw0KCW5lY2Vzc2FyeSB0byB0aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbiBhbmQgd2lsbCBzZWVr IHRvIGhhdmUgYmFja3dhcmQNCgljb21wYXRpYmlsaXR5LiAgRnVydGhlcm1vcmUsIHNvbWUgZXh0 ZW5zaW9ucyB0byB0aGUgY3VycmVudCBwcm9wb3NhbCBhcmUNCglvZiBpbnRlcmVzdCB0byB0aGUg Y29tbXVuaXR5LCBzdWNoIGFzIHRoZSBtZWFucyBmb3IgYW4gb3BlcmF0b3IgdG8gYWR2ZXJ0aXNl DQoJYW4gZW1haWwgYWRkcmVzcyB0byB3aGljaCBhYnVzZSByZXBvcnRzIHVzaW5nIEFSRiBzaG91 bGQgYmUgc2VudC4gIFRoZQ0KCXdvcmtpbmcgZ3JvdXAgd2lsbCB0YWtlIG9uIHRoZSB0YXNrIG9m IHNwZWNpZnlpbmcgc3VjaCBhIG1lY2hhbmlzbSBhcw0KCXBhcnQgb2YgdGhlIGZpcnN0IGRyYWZ0 IGl0IHdpbGwgaXNzdWUuDQoNCglUaGUgaW5pdGlhbCBwcm9wb3NhbCBpcyBwdWJsaXNoZWQgYXMg ZHJhZnQtc2hhZnJhbm92aWNoLWZlZWRiYWNrLXJlcG9ydCwNCglhbmQgdGhpcyB3aWxsIHByb3Zp ZGUgdGhlIHdvcmtpbmcgZ3JvdXAncyBzdGFydGluZyBwb2ludC4NCg0KCUluIGFkZGl0aW9uLCB0 aGUgZ3JvdXAgd2lsbCBzcGVjaWZ5IHRoZSBpbnRlZ3JhdGlvbiBvZiBBUkYgaW50byBES0lNIHVz ZQ0KCXVzaW5nIGRyYWZ0LWt1Y2hlcmF3eS1ka2ltLXJlcG9ydGluZyBhcyBpdHMgaW5wdXQuICBJ dCBjb250YWlucyBleHRlbnNpb25zDQoJdG8gREtJTSB0aGF0IGFyZSByZWxhdGVkIHRvIEFSRiBh cyBhIG1lYW5zIG9mIHJlcG9ydGluZyBES0lNLXJlbGF0ZWQgZmFpbHVyZXMNCgl3aGljaCBpbmNs dWRlIHBoaXNoaW5nICgiZnJhdWQiKSBhbmQgYXMgc3VjaCBhcmUgcmVsZXZhbnQgdG8gdGhlIEFS RiBlZmZvcnQuDQoNCiAgIEdvYWxzIGFuZCBNaWxlc3RvbmVzOg0KCVNlcCAwOQlJc3N1ZSBmaXJz dCBXRy1iYXNlZCBJbnRlcm5ldC1EcmFmdCBkZWZpbmluZyBBUkYNCglOb3YgMDkJQWNoaWV2ZSBj b25zZW5zdXMgb24gYW55IFdHLWJhc2VkIGNoYW5nZXMgdG8gQVJGDQoJRGVjIDA5CVN1Ym1pdCBB UkYgSUQgdG8gSUVTRyBmb3IgcHVibGljYXRpb24NCglGZWIgMTAJSXNzdWUgZmlyc3QgV0ctYmFz ZWQgSUQgYWJvdXQgREtJTSByZXBvcnRpbmcgZXh0ZW5zaW9ucw0KCU1heSAxMAlBY2hpZXZlIGNv bnNlbnN1cyBvbiBES0lNIHJlcG9ydGluZyBleHRlbnNpb25zIGRyYWZ0DQoJSnVuIDEwCVN1Ym1p dCBES0lNIHJlcG9ydGluZyBJRCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbg0K --_004_BB012BD379D7B046ABE1472D8093C61C0112AA8C82EXCHC2corpclo_-- From lear@cisco.com Thu Jul 9 07:02:19 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BD2B3A704E for ; Thu, 9 Jul 2009 07:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.432 X-Spam-Level: X-Spam-Status: No, score=-8.432 tagged_above=-999 required=5 tests=[AWL=-1.833, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPECbkxWHL9t for ; Thu, 9 Jul 2009 07:02:18 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 447453A7059 for ; Thu, 9 Jul 2009 07:02:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,373,1243814400"; d="scan'208";a="175707737" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-3.cisco.com with ESMTP; 09 Jul 2009 14:02:45 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n69E2i29021464; Thu, 9 Jul 2009 16:02:44 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp6731.cisco.com [10.61.90.74]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n69E2i5U005697; Thu, 9 Jul 2009 14:02:44 GMT Message-ID: <4A55F884.6070703@cisco.com> Date: Thu, 09 Jul 2009 16:02:44 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090602 Shredder/3.0b3pre MIME-Version: 1.0 To: "Murray S. Kucherawy" Subject: Re: Proposed WG charter for "arf" (Abuse Report Format) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=241; t=1247148164; x=1248012164; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Proposed=20WG=20charter=20for=20=22arf= 22=20(Abuse=20Report=20Format) |Sender:=20; bh=vWri8QmK8NP+I6BQDDAuX9MTH4GxX/PHz0v6ehfBmuQ=; b=YgzMvKrL1tDzzqURiI2yfOfUqFVTeMFlbvzut+NHB2GXE0IWl+sUDmJBFn JDJu+pW8E0I4i0Im5ytbY4hWiUvTJs6vmvJofCNmW89IxFMSzFPwo2K09ahT L7qATodtX+; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:02:19 -0000 Murray, I think standardizing ARF is a GREAT idea, but I wonder if we need a working group to do it. There's a lot of ARF out there today. Is there something controversial here that requires us to bang our heads together? Eliot From alexey.melnikov@isode.com Thu Jul 9 09:47:52 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6003A6D00 for ; Thu, 9 Jul 2009 09:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O0fodSHpfMb for ; Thu, 9 Jul 2009 09:47:51 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4EE7C3A6D21 for ; Thu, 9 Jul 2009 09:47:51 -0700 (PDT) Received: from [172.16.2.148] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 9 Jul 2009 17:48:17 +0100 Message-ID: <4A561F0A.1030100@isode.com> Date: Thu, 09 Jul 2009 17:47:06 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Cyrus Daboo Subject: Re: httpbis vs yam meeting slots in Stockholm References: <4A52F11F.6000400@gmx.de> <59412B3595BB07DCFCFDC95E@caldav.corp.apple.com> In-Reply-To: <59412B3595BB07DCFCFDC95E@caldav.corp.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 16:47:52 -0000 Cyrus Daboo wrote: > Hi Julian, > > --On July 7, 2009 8:54:23 AM +0200 Julian Reschke > wrote: > >> I just noticed that HTTPBIS and YAM run in parallel; that's IMHO >> non-optimal because both would benefit from people with MIME >> experience... >> >> Dunno whether this has been already considered, and whether it's >> possible >> to do something about it... > > +1 > > We should try and get this conflict fixed. Can we swap httpbis with either: Monday, 13:00-15:00 (idnabis) or Tuesday, 13:00-15:00 (alto) ? From alexey.melnikov@isode.com Thu Jul 9 09:51:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF07A3A6CEE for ; Thu, 9 Jul 2009 09:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c02P34TjC2oz for ; Thu, 9 Jul 2009 09:51:25 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 2439D3A6D17 for ; Thu, 9 Jul 2009 09:51:25 -0700 (PDT) Received: from [172.16.2.148] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 9 Jul 2009 17:51:52 +0100 Message-ID: <4A561FE6.1070504@isode.com> Date: Thu, 09 Jul 2009 17:50:46 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps Discuss Subject: Re: httpbis vs yam meeting slots in Stockholm References: <4A52F11F.6000400@gmx.de> <59412B3595BB07DCFCFDC95E@caldav.corp.apple.com> <4A561F0A.1030100@isode.com> In-Reply-To: <4A561F0A.1030100@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 16:51:26 -0000 Alexey Melnikov wrote: > Cyrus Daboo wrote: > >> Hi Julian, >> >> --On July 7, 2009 8:54:23 AM +0200 Julian Reschke >> wrote: >> >>> I just noticed that HTTPBIS and YAM run in parallel; that's IMHO >>> non-optimal because both would benefit from people with MIME >>> experience... >>> >>> Dunno whether this has been already considered, and whether it's >>> possible >>> to do something about it... >> >> +1 >> >> We should try and get this conflict fixed. > > Can we swap httpbis with either: > Monday, 13:00-15:00 (idnabis) > or > Tuesday, 13:00-15:00 (alto) Actually alto would be better, as there is less overlap in attendence between YAM and ALTO, as far as I can see. > ? From julian.reschke@gmx.de Thu Jul 9 10:01:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8BAF28C179 for ; Thu, 9 Jul 2009 10:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.623 X-Spam-Level: X-Spam-Status: No, score=-3.623 tagged_above=-999 required=5 tests=[AWL=-1.894, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWnlXrCZBApB for ; Thu, 9 Jul 2009 10:01:25 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B8F2E28C1E9 for ; Thu, 9 Jul 2009 10:01:24 -0700 (PDT) Received: (qmail invoked by alias); 09 Jul 2009 17:01:50 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp013) with SMTP; 09 Jul 2009 19:01:50 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/FsjYK9RLFTirXktElJHHFx2ldXJG4vrBEnLl3aJ JPWqWzeDnv40UZ Message-ID: <4A562279.5060802@gmx.de> Date: Thu, 09 Jul 2009 19:01:45 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: httpbis vs yam meeting slots in Stockholm References: <4A52F11F.6000400@gmx.de> <59412B3595BB07DCFCFDC95E@caldav.corp.apple.com> <4A561F0A.1030100@isode.com> In-Reply-To: <4A561F0A.1030100@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 17:01:25 -0000 Alexey Melnikov wrote: > Cyrus Daboo wrote: > >> Hi Julian, >> >> --On July 7, 2009 8:54:23 AM +0200 Julian Reschke >> wrote: >> >>> I just noticed that HTTPBIS and YAM run in parallel; that's IMHO >>> non-optimal because both would benefit from people with MIME >>> experience... >>> >>> Dunno whether this has been already considered, and whether it's >>> possible >>> to do something about it... >> >> +1 >> >> We should try and get this conflict fixed. > > Can we swap httpbis with either: > Monday, 13:00-15:00 (idnabis) > or > Tuesday, 13:00-15:00 (alto) Both sound good to me; the things I'd like HTTPbis not to collide with are YAM and VCARDDAV (but of course that's just a personal preference). BR, Julian From iljitsch@muada.com Thu Jul 9 10:09:47 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E128A28C0EA for ; Thu, 9 Jul 2009 10:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQq4cbrt5pnN for ; Thu, 9 Jul 2009 10:09:47 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 845D53A679F for ; Thu, 9 Jul 2009 10:09:23 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n69H9XAw081446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 9 Jul 2009 19:09:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: apps-discuss@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: FTP issues with IPv6-IPv4 translation Date: Thu, 9 Jul 2009 19:09:32 +0200 X-Mailer: Apple Mail (2.935.3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 17:09:48 -0000 Here's an update of the FTP64 draft. It specifies some updates to FTP servers and clients so those can talk through IPv6-to-IPv4 translators on their own, but it does allow for (not mandate) FTP ALGs to help out unupdated clients/servers. I think this is a reasonable tradeoff, please let me know what you think. I'll be talking about this in the apps area session in Stockholm. Iljitsch Begin forwarded message: > Title : IPv6-to-IPv4 translation FTP considerations > Author(s) : I. van Beijnum > Filename : draft-van-beijnum-behave-ftp64-04.txt > Pages : 9 > Date : 2009-07-09 > The File Transfer Protocol has a very long history, and despite the > fact that today, other options exist to perform file transfers, FTP > is still in common use. As such, it is important that in the > situation where some client computers are IPv6-only while many > servers are still IPv4-only and IPv6-to-IPv4 translators are used to > bridge that gap, FTP is made to work through these translators as > best it can. > FTP has an active and a passive mode, both as original commands that > are IPv4-specific, and as extended, IP version agnostic commands. > The only FTP mode that works without changes through an IPv6-to-IPv4 > translator is extended passive However, many existing FTP servers > don't support this mode, and some clients don't ask for it. This > document describes the optimal server, client and middlebox (if any) > behavior to minimize this problem. > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-van-beijnum-behave-ftp64-04.txt From john-ietf@jck.com Thu Jul 9 11:03:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA1F28C24D for ; Thu, 9 Jul 2009 11:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oM1KmCRkesCY for ; Thu, 9 Jul 2009 11:03:38 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 575443A6809 for ; Thu, 9 Jul 2009 11:03:38 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MOxyV-000MzW-EJ; Thu, 09 Jul 2009 14:04:03 -0400 Date: Thu, 09 Jul 2009 14:04:02 -0400 From: John C Klensin To: Alexey Melnikov , Cyrus Daboo Subject: Re: httpbis vs yam meeting slots in Stockholm Message-ID: In-Reply-To: <4A561F0A.1030100@isode.com> References: <4A52F11F.6000400@gmx.de> <59412B3595BB07DCFCFDC95E@caldav.corp.apple.com> <4A561F0A.1030100@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:03:39 -0000 --On Thursday, July 09, 2009 17:47 +0100 Alexey Melnikov wrote: >> We should try and get this conflict fixed. > > Can we swap httpbis with either: > Monday, 13:00-15:00 (idnabis) Moving IDNABIS would set off a whole series of other problems including, I believe, unavailability of the Chair. FWIW, given the concerns about the content rules for URIs and IRIs, a conflict between HTTPBIS and IDNABIS should also be on the "must avoid" list. john From mnot@mnot.net Thu Jul 9 16:27:36 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65CDA28C2F6 for ; Thu, 9 Jul 2009 16:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.553 X-Spam-Level: X-Spam-Status: No, score=-5.553 tagged_above=-999 required=5 tests=[AWL=-2.824, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9d2LvxiJ8DRc for ; Thu, 9 Jul 2009 16:27:35 -0700 (PDT) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id B463928C1E5 for ; Thu, 9 Jul 2009 16:27:34 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.249.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B6B3A23E3E8; Thu, 9 Jul 2009 19:27:49 -0400 (EDT) Message-Id: <96684634-7032-4399-9721-75BA83893025@mnot.net> From: Mark Nottingham To: John C Klensin In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: httpbis vs yam meeting slots in Stockholm Date: Fri, 10 Jul 2009 09:27:47 +1000 References: <4A52F11F.6000400@gmx.de> <59412B3595BB07DCFCFDC95E@caldav.corp.apple.com> <4A561F0A.1030100@isode.com> X-Mailer: Apple Mail (2.935.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 23:27:37 -0000 Moving HTTPbis to Monday or Tuesday would lead to a chair availability problem as well. Furthermore, the agenda has been marked as FINAL, and people tend to book travel once that happens. It'd be best if we could move HTTPbis to another slot on Thursday; e.g., morning I and afternoon II don't have any obvious conflicts (at least to me), and afternoon II looks to have available space (although I suspect that's because congresshall A and B are being prepared for the plenary, although I note congresshall C is in use). Cheers, On 10/07/2009, at 4:04 AM, John C Klensin wrote: > > > --On Thursday, July 09, 2009 17:47 +0100 Alexey Melnikov > wrote: > >>> We should try and get this conflict fixed. >> >> Can we swap httpbis with either: >> Monday, 13:00-15:00 (idnabis) > > Moving IDNABIS would set off a whole series of other problems > including, I believe, unavailability of the Chair. > > FWIW, given the concerns about the content rules for URIs and > IRIs, a conflict between HTTPBIS and IDNABIS should also be on > the "must avoid" list. > > john > > > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From alexey.melnikov@isode.com Fri Jul 10 02:27:55 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 110843A6BE0 for ; Fri, 10 Jul 2009 02:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqCMYezB9n3G for ; Fri, 10 Jul 2009 02:27:54 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 0E3693A686D for ; Fri, 10 Jul 2009 02:27:54 -0700 (PDT) Received: from [172.16.2.145] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 10 Jul 2009 10:28:14 +0100 Message-ID: <4A570976.2090108@isode.com> Date: Fri, 10 Jul 2009 10:27:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Mark Nottingham Subject: Re: httpbis vs yam meeting slots in Stockholm References: <4A52F11F.6000400@gmx.de> <59412B3595BB07DCFCFDC95E@caldav.corp.apple.com> <4A561F0A.1030100@isode.com> <96684634-7032-4399-9721-75BA83893025@mnot.net> In-Reply-To: <96684634-7032-4399-9721-75BA83893025@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 09:27:55 -0000 Mark Nottingham wrote: > Moving HTTPbis to Monday or Tuesday would lead to a chair > availability problem as well. Oops. Sorry about that. > Furthermore, the agenda has been marked as FINAL, and people tend to > book travel once that happens. Well, don't get me started on that ;-). YAM has appeared in the only version of the agenda I saw, so I couldn't possibly have commented on the conflict before that. > It'd be best if we could move HTTPbis to another slot on Thursday; > e.g., morning I This wouldn't work, as there are no room available. And there are no Apps area slots, so we can't swap anything. We could try to swap slots with WG in other areas, but this might create other conflicts elsewhere. Also note that the morning I is 2.5 hours, not 2 hours allocated for HTTPBIS. > and afternoon II don't have any obvious conflicts (at least to me), > and afternoon II looks to have available space (although I suspect > that's because congresshall A and B are being prepared for the > plenary, although I note congresshall C is in use). It is also only 1 hour long. > Cheers, > > On 10/07/2009, at 4:04 AM, John C Klensin wrote: > >> --On Thursday, July 09, 2009 17:47 +0100 Alexey Melnikov >> wrote: >> >>>> We should try and get this conflict fixed. >>> >>> Can we swap httpbis with either: >>> Monday, 13:00-15:00 (idnabis) >> >> Moving IDNABIS would set off a whole series of other problems >> including, I believe, unavailability of the Chair. >> >> FWIW, given the concerns about the content rules for URIs and >> IRIs, a conflict between HTTPBIS and IDNABIS should also be on >> the "must avoid" list. > From alexey.melnikov@isode.com Fri Jul 10 02:30:56 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240AD3A6C44 for ; Fri, 10 Jul 2009 02:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nq1iwHdV1nwW for ; Fri, 10 Jul 2009 02:30:55 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 1CBD428C0D8 for ; Fri, 10 Jul 2009 02:30:54 -0700 (PDT) Received: from [172.16.2.145] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 10 Jul 2009 10:31:21 +0100 Message-ID: <4A570A3A.9090704@isode.com> Date: Fri, 10 Jul 2009 10:30:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps Discuss Subject: Re: httpbis vs yam meeting slots in Stockholm References: <4A52F11F.6000400@gmx.de> <59412B3595BB07DCFCFDC95E@caldav.corp.apple.com> <4A561F0A.1030100@isode.com> <96684634-7032-4399-9721-75BA83893025@mnot.net> <4A570976.2090108@isode.com> In-Reply-To: <4A570976.2090108@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 09:30:56 -0000 Alexey Melnikov wrote: > Mark Nottingham wrote: [...] >> It'd be best if we could move HTTPbis to another slot on Thursday; >> e.g., morning I > > This wouldn't work, as there are no room available. > And there are no Apps area slots, so we can't swap anything. We could > try to swap slots with WG in other areas, but this might create other > conflicts elsewhere. > Also note that the morning I is 2.5 hours, not 2 hours allocated for > HTTPBIS. > >> and afternoon II don't have any obvious conflicts (at least to me), >> and afternoon II looks to have available space (although I suspect >> that's because congresshall A and B are being prepared for the >> plenary, although I note congresshall C is in use). > > It is also only 1 hour long. Considering that my original proposal is not working and I showed that Mark's alternatives wouldn't work either, I am suggesting we leave things as is. Unless people have a third proposal that would work for the majority of interested participants. We can try to coordinate agendas between the two meetings. From vesely@tana.it Fri Jul 10 06:44:34 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368AC28C317 for ; Fri, 10 Jul 2009 06:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.761 X-Spam-Level: X-Spam-Status: No, score=-2.761 tagged_above=-999 required=5 tests=[AWL=1.958, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL+dDN7w+3A5 for ; Fri, 10 Jul 2009 06:44:33 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id E4F6B28C321 for ; Fri, 10 Jul 2009 06:44:30 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 10 Jul 2009 15:44:55 +0200 id 00000000005DC035.000000004A5745D7.00005028 Message-ID: <4A5745D7.4080606@tana.it> Date: Fri, 10 Jul 2009 15:44:55 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Murray S. Kucherawy" Subject: Re: Proposed WG charter for "arf" (Abuse Report Format) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 13:44:34 -0000 Murray S. Kucherawy wrote: > Furthermore, some extensions to the current proposal are > of interest to the community, such as the means for an operator to advertise > an email address to which abuse reports using ARF should be sent. Apparently, that snippet considers "generic" reports. It is not explicit from the proposal if that email address is going to be specified in the same RFC that also standardizes the ARF. Since a (possibly different) email address is mentioned in your dkim-reporting draft, I understand a generic ARF email address is not what you aim for. In facts, there are two obvious arguments against it: 1) When feedback reports are processed by software, it may be convenient to have different addresses for different types of report. 2) The primary target for "generic" abuse reports (fraud, spam, virus, etcetera) would be the abuse desk of the organization accountable for originating the message. A document specifying where the target address can be found should also say how to identify such accountable originator, which is not a marginal task for a document --or a WG-- dedicated to a format specification. OTOH, there are various possible synergies. For example, some of the r/rs/ri/ro/rs tags that describe feedback characteristics could be factored out in the ARF document, so as to avoid having to repeat them every time. SPF's softfail result might be a good candidate for collecting reports about SPF checks. DKIM's key reporting policy might require SPF "pass" to avoid collecting reports about extraneous transmitters trying to forge signatures. My vhlo draft defines the accountable originator mentioned in (2) above. Giving room to these synergies may expand the WG goals beyond reporting issues, and add one or two "issue/achieve/submit" triplets to its milestones. Would that be good or bad? From dhc@dcrocker.net Fri Jul 10 06:57:45 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F4328C329 for ; Fri, 10 Jul 2009 06:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wX1bl-eBwT2L for ; Fri, 10 Jul 2009 06:57:45 -0700 (PDT) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7147]) by core3.amsl.com (Postfix) with ESMTP id 8E48328C31F for ; Fri, 10 Jul 2009 06:57:44 -0700 (PDT) Received: from [127.0.0.1] (ppp-68-120-199-146.dsl.pltn13.pacbell.net [68.120.199.146]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6ADw5GP025661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jul 2009 06:58:11 -0700 Message-ID: <4A5748ED.8070104@dcrocker.net> Date: Fri, 10 Jul 2009 06:58:05 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Murray S. Kucherawy" Subject: Re: Proposed WG charter for "arf" (Abuse Report Format) References: In-Reply-To: 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]); Fri, 10 Jul 2009 06:58:11 -0700 (PDT) Cc: "discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 13:57:46 -0000 > Messaging anti-abuse operations between independent services often requires > sending reports on observed fraud, spam virus or other abuse activity. oops. subject/verb mismatch. not sure whether plural or singular is better. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From tony@att.com Fri Jul 10 07:37:22 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63C173A6AAF for ; Fri, 10 Jul 2009 07:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.841 X-Spam-Level: X-Spam-Status: No, score=-105.841 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hoq1KtWsrFuo for ; Fri, 10 Jul 2009 07:37:21 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 66C3A3A6B96 for ; Fri, 10 Jul 2009 07:37:21 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1247236667!22691557!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 6791 invoked from network); 10 Jul 2009 14:37:48 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-12.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Jul 2009 14:37:48 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6AEblru025761 for ; Fri, 10 Jul 2009 07:37:47 -0700 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6AEbgVg025691 for ; Fri, 10 Jul 2009 07:37:43 -0700 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n6AEbgRf027904 for ; Fri, 10 Jul 2009 09:37:42 -0500 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n6AEbbw0027745 for ; Fri, 10 Jul 2009 09:37:37 -0500 Received: from [135.70.141.115] (vpn-135-70-141-115.vpn.mwst.att.com[135.70.141.115]) by maillennium.att.com (mailgw1) with ESMTP id <20090710143736gw1003ibqie> (Authid: tony); Fri, 10 Jul 2009 14:37:37 +0000 X-Originating-IP: [135.70.141.115] Message-ID: <4A575230.4030409@att.com> Date: Fri, 10 Jul 2009 10:37:36 -0400 From: Tony Hansen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: httpbis vs yam meeting slots in Stockholm References: <4A52F11F.6000400@gmx.de> <59412B3595BB07DCFCFDC95E@caldav.corp.apple.com> <4A561F0A.1030100@isode.com> <96684634-7032-4399-9721-75BA83893025@mnot.net> <4A570976.2090108@isode.com> <4A570A3A.9090704@isode.com> In-Reply-To: <4A570A3A.9090704@isode.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 14:37:22 -0000 Would Wed afternoon @1510 work? There appears to be an open slot there. The only potential conflict I see is with SIMPLE, but I'm less concerned about that compared with HTTPbis. Tony Alexey Melnikov wrote: > Alexey Melnikov wrote: > >> Mark Nottingham wrote: > > [...] > >>> It'd be best if we could move HTTPbis to another slot on Thursday; >>> e.g., morning I >> >> This wouldn't work, as there are no room available. >> And there are no Apps area slots, so we can't swap anything. We could >> try to swap slots with WG in other areas, but this might create other >> conflicts elsewhere. >> Also note that the morning I is 2.5 hours, not 2 hours allocated for >> HTTPBIS. >> >>> and afternoon II don't have any obvious conflicts (at least to me), >>> and afternoon II looks to have available space (although I suspect >>> that's because congresshall A and B are being prepared for the >>> plenary, although I note congresshall C is in use). >> >> It is also only 1 hour long. > > Considering that my original proposal is not working and I showed that > Mark's alternatives wouldn't work either, I am suggesting we leave > things as is. > Unless people have a third proposal that would work for the majority > of interested participants. > > We can try to coordinate agendas between the two meetings. > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From msk@cloudmark.com Thu Jul 9 09:04:22 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2573A683A for ; Thu, 9 Jul 2009 09:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNAFn6WCjJr0 for ; Thu, 9 Jul 2009 09:04:21 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id F2D9A3A6B16 for ; Thu, 9 Jul 2009 09:04:15 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Thu, 9 Jul 2009 09:04:43 -0700 From: "Murray S. Kucherawy" To: Eliot Lear Date: Thu, 9 Jul 2009 09:04:43 -0700 Subject: RE: Proposed WG charter for "arf" (Abuse Report Format) Thread-Topic: Proposed WG charter for "arf" (Abuse Report Format) Thread-Index: AcoAnfBNXEGRsEYJQi2vvsNV0JbNSQAEIyCw Message-ID: References: <4A55F884.6070703@cisco.com> In-Reply-To: <4A55F884.6070703@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 10 Jul 2009 08:31:51 -0700 Cc: "discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 16:04:22 -0000 SGkgRWxpb3QsDQoNClRoZSBNQUFXRyBjb25mZXJlbmNlIGluIEFtc3RlcmRhbSBzaG93ZWQgdGhh dCB0aGVyZSBhcmUgYSBmZXcgZGVwbG95ZWQgZW5oYW5jZW1lbnRzIG5vdCBhbHJlYWR5IGNvdmVy ZWQgYnkgdGhlIGN1cnJlbnQgZHJhZnQsIGFuZCBhIGZldyBvdGhlcnMgcGVvcGxlIGFyZSBpbnRl cmVzdGVkIGluIGRpc2N1c3NpbmcuICBJJ20gYWxzbyBpbnRlcmVzdGVkIGluIGV4cG9zaW5nIEFS RiB0byBhIHdpZGVyIGJvZHkgb2Ygb3BlcmF0aW9uYWwgc2NydXRpbnkgdGhhbiB3aGF0IE1BQVdH IHRlbmRzIHRvIGhhdmUgYmVmb3JlIG1vdmluZyBpdCB0b3dhcmQgZm9ybWFsIHB1YmxpY2F0aW9u LiAgQ292ZXJpbmcgYWxsIG9mIHRoaXMgaW4gdGhlIGNvbnRleHQgb2YgYSB3b3JraW5nIGdyb3Vw IHNlZW1zIGxpa2UgYSBnb29kIHVzZSBvZiByZXNvdXJjZXMgdG8gbWUuDQoNClRoZSBES0lNIHJl cG9ydGluZyBzdHVmZiBjb3VsZCByZWFsbHkgdXNlIGEgaG9tZSB0b28gYW5kIGl0J3MgYmVjb21l IHRpZWQgdG8gQVJGIGluIHNvbWUgd2F5cywgc28gdGhpcyBpcyBhbHNvIGEgZ29vZCBmaXQuDQoN ClNvIG5vLCBub3QgbXVjaCBpbiB0aGUgd2F5IG9mIGNvbnRyb3ZlcnN5LCBidXQgdGhlcmUncyBz dGlsbCB3b3JrIHRvIGJlIGRvbmUgYW5kIHRoaXMgc2VlbXMgdG8gYmUgYSBnb29kIHdheSB0byBr ZWVwIHRoZSBtb21lbnR1bSB1cC4NCg0KLU1TSw0K From dhc@dcrocker.net Fri Jul 10 08:57:17 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C23EB28C25F for ; Fri, 10 Jul 2009 08:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjWu1vNGccpJ for ; Fri, 10 Jul 2009 08:57:16 -0700 (PDT) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7147]) by core3.amsl.com (Postfix) with ESMTP id 695F828C205 for ; Fri, 10 Jul 2009 08:57:16 -0700 (PDT) Received: from [127.0.0.1] (ppp-68-120-199-146.dsl.pltn13.pacbell.net [68.120.199.146]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6AFvHCm032499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jul 2009 08:57:23 -0700 Message-ID: <4A5764DD.30404@dcrocker.net> Date: Fri, 10 Jul 2009 08:57:17 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Murray S. Kucherawy" Subject: Re: Proposed WG charter for "arf" (Abuse Report Format) References: <4A55F884.6070703@cisco.com> In-Reply-To: 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]); Fri, 10 Jul 2009 08:57:23 -0700 (PDT) Cc: "discuss@ietf.org" , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 15:57:17 -0000 Murray S. Kucherawy wrote: > Hi Eliot, > > The MAAWG conference in Amsterdam showed that there are a few deployed > enhancements not already covered by the current draft, and a few others > people are interested in discussing. The current draft lists exactly one item from this set. It would probably help to list others. The goal is to increase the risk of failure... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From cfinss@dial.pipex.com Fri Jul 10 10:10:36 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4AD128C349 for ; Fri, 10 Jul 2009 10:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.341 X-Spam-Level: X-Spam-Status: No, score=-1.341 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZuMmZ8pVvFT for ; Fri, 10 Jul 2009 10:10:35 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 4A90428C2FC for ; Fri, 10 Jul 2009 10:10:35 -0700 (PDT) X-Trace: 265706427/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.121/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.121 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4EAAMTV0o+vGl5/2dsb2JhbABFgmc8HIt/wGgJg38FgTs X-IronPort-AV: E=Sophos;i="4.42,379,1243810800"; d="scan'208";a="265706427" X-IP-Direction: IN Received: from 1cust121.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.121]) by smtp.pipex.tiscali.co.uk with SMTP; 10 Jul 2009 18:11:01 +0100 Message-ID: <000701ca0178$c300e700$0601a8c0@allison> From: "tom.petch" To: , References: Subject: Re: Interest in reviving WG on FTP(maybe ext?) Date: Fri, 10 Jul 2009 11:52:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 17:10:36 -0000 In October last, there was a thread on "Subject: Followup on IETF72 discussion of FTP protocol extensions and updates". I cannot recall seeing any conclusion to it; may be this time? Tom Petch ----- Original Message ----- From: "William F. Maton Sotomayor" To: Sent: Wednesday, July 01, 2009 9:53 PM Subject: Interest in reviving WG on FTP(maybe ext?) > > All, > > Over the past several months a colleague at a university and > myself have revived work on the WU-FTPD daemon. Through researching the > various RFCs and such, it's become apparent that there are a small number > of drafts as well as a potential number of others that could significantly > contribute to the protocol. (So my voyage has gone from operator, > developer and implementor to protocol spec.) But, ftpext wound-up and it > seems there's no specific venue to flesh these out amongst like-minded > FTP people. > > I suppose what I'm looking for from the Apps Area folk is to test > the waters on establishing a BoF (if I have read the Apps website > correctly) that will lead to establishing some kind of group that will > further the possible work remaining or possibly poending to be done, or > not. Discussions amongst a couple of authors of long-expired drafts seem > to favour some kind of venue. > > Thanks, > > wfms > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From wmaton@ryouko.imsb.nrc.ca Fri Jul 10 11:07:54 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B009828C38E for ; Fri, 10 Jul 2009 11:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2ZpOmurmfKx for ; Fri, 10 Jul 2009 11:07:54 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2001:410:9000:127::10]) by core3.amsl.com (Postfix) with ESMTP id 283FC28C384 for ; Fri, 10 Jul 2009 11:07:52 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.3/8.14.3) with ESMTP id n6AI833R028042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jul 2009 14:08:08 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.3/8.14.3/Submit) with ESMTP id n6AI82uT028039; Fri, 10 Jul 2009 14:08:03 -0400 Date: Fri, 10 Jul 2009 14:08:02 -0400 (EDT) From: "William F. Maton Sotomayor" To: "tom.petch" Subject: Re: Interest in reviving WG on FTP(maybe ext?) In-Reply-To: <000701ca0178$c300e700$0601a8c0@allison> Message-ID: References: <000701ca0178$c300e700$0601a8c0@allison> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 18:07:54 -0000 On Fri, 10 Jul 2009, tom.petch wrote: > In October last, there was a thread on > "Subject: Followup on IETF72 discussion of FTP protocol extensions and > updates". > > I cannot recall seeing any conclusion to it; may be this time? Ah, thanks for that pointer. I was in DUblin and had not realized at the time that there were discussions in progress...Alas, that was prior getting involved in the issue in the first place. I don't see one in the archives either. I think a Bar BoF may be planned for it though? > > Tom Petch > > > ----- Original Message ----- > From: "William F. Maton Sotomayor" > To: > Sent: Wednesday, July 01, 2009 9:53 PM > Subject: Interest in reviving WG on FTP(maybe ext?) > > >> >> All, >> >> Over the past several months a colleague at a university and >> myself have revived work on the WU-FTPD daemon. Through researching the >> various RFCs and such, it's become apparent that there are a small number >> of drafts as well as a potential number of others that could significantly >> contribute to the protocol. (So my voyage has gone from operator, >> developer and implementor to protocol spec.) But, ftpext wound-up and it >> seems there's no specific venue to flesh these out amongst like-minded >> FTP people. >> >> I suppose what I'm looking for from the Apps Area folk is to test >> the waters on establishing a BoF (if I have read the Apps website >> correctly) that will lead to establishing some kind of group that will >> further the possible work remaining or possibly poending to be done, or >> not. Discussions amongst a couple of authors of long-expired drafts seem >> to favour some kind of venue. >> >> Thanks, >> >> wfms >> _______________________________________________ >> Apps-Discuss mailing list >> Apps-Discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > wfms From john-ietf@jck.com Fri Jul 10 13:49:45 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 690393A6E8F for ; Fri, 10 Jul 2009 13:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOxVjmWgL4Vv for ; Fri, 10 Jul 2009 13:49:44 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 8DC173A6E61 for ; Fri, 10 Jul 2009 13:48:46 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MPN1p-000Ls9-9D; Fri, 10 Jul 2009 16:49:09 -0400 Date: Fri, 10 Jul 2009 16:49:08 -0400 From: John C Klensin To: wmaton@ryouko.imsb.nrc.ca, "tom.petch" Subject: Re: Interest in reviving WG on FTP(maybe ext?) Message-ID: <45CD4EB44CDFB32F772D8D6E@PST.JCK.COM> In-Reply-To: References: <000701ca0178$c300e700$0601a8c0@allison> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 20:49:45 -0000 --On Friday, July 10, 2009 14:08 -0400 "William F. Maton Sotomayor" wrote: > On Fri, 10 Jul 2009, tom.petch wrote: > >> In October last, there was a thread on >> "Subject: Followup on IETF72 discussion of FTP protocol >> extensions and updates". >> >> I cannot recall seeing any conclusion to it; may be this time? > > Ah, thanks for that pointer. I was in DUblin and had not > realized at the time that there were discussions in > progress...Alas, that was prior getting involved in the issue > in the first place. > > I don't see one in the archives either. > > I think a Bar BoF may be planned for it though? With the understanding that I have been, and remain, sympathetic to getting a WG spun up if there is interest, the conclusion in Dublin and elsewhere was that there really wasn't critical mass to do this. Critical mass would require people who were willing to actually work on, review, and, where appropriate, implement each other's documents, not just present ideas and hope that others sign off. There have been a number of drafts posted relevant to FTP. Some seems obvious to me (like the extension registry), others may be seriously bad ideas, and most lie somewhere in between. If that critical mass exists, then someone needs to get to work on a charter, perhaps using the one that a couple of us put together a year ago as a starting point. If it doesn't, then writing and posting more FTP extension drafts is probably a waste of time -- given the number of proposals, if there isn't enough interest to put a WG together, then it would be hard to argue that there is sufficient interest in FTP extensions in the community to justify standardizing anything. That is just my opinion, but I think it is a reasonable summary of where things stood a year ago. I'm not convinced that anything has changed. john From eburger@standardstrack.com Sat Jul 11 18:11:37 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC62F3A6812 for ; Sat, 11 Jul 2009 18:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+iNUe1U6Pd4 for ; Sat, 11 Jul 2009 18:11:37 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 05EAC3A6811 for ; Sat, 11 Jul 2009 18:11:37 -0700 (PDT) Received: from c-75-68-112-157.hsd1.nh.comcast.net ([75.68.112.157] helo=[192.168.45.100]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MPnbF-0004gp-Hx; Sat, 11 Jul 2009 18:11:29 -0700 Message-Id: <082C97B4-E5EC-4D88-B231-08B16AB8E3AF@standardstrack.com> From: Eric Burger To: Alexey Melnikov In-Reply-To: <4A575230.4030409@att.com> Content-Type: multipart/signed; boundary=Apple-Mail-26-618464645; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: httpbis vs yam meeting slots in Stockholm Date: Sat, 11 Jul 2009 21:12:00 -0400 References: <4A52F11F.6000400@gmx.de> <59412B3595BB07DCFCFDC95E@caldav.corp.apple.com> <4A561F0A.1030100@isode.com> <96684634-7032-4399-9721-75BA83893025@mnot.net> <4A570976.2090108@isode.com> <4A570A3A.9090704@isode.com> <4A575230.4030409@att.com> X-Mailer: Apple Mail (2.935.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - apps.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 01:11:37 -0000 --Apple-Mail-26-618464645 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit And, as an ALTO author, I would prefer not to have a YAM/ALTO conflict, if possible. On Jul 10, 2009, at 10:37 AM, Tony Hansen wrote: > Would Wed afternoon @1510 work? There appears to be an open slot > there. > The only potential conflict I see is with SIMPLE, but I'm less > concerned > about that compared with HTTPbis. > > Tony > > Alexey Melnikov wrote: >> Alexey Melnikov wrote: >> >>> Mark Nottingham wrote: >> >> [...] >> >>>> It'd be best if we could move HTTPbis to another slot on Thursday; >>>> e.g., morning I >>> >>> This wouldn't work, as there are no room available. >>> And there are no Apps area slots, so we can't swap anything. We >>> could >>> try to swap slots with WG in other areas, but this might create >>> other >>> conflicts elsewhere. >>> Also note that the morning I is 2.5 hours, not 2 hours allocated for >>> HTTPBIS. >>> >>>> and afternoon II don't have any obvious conflicts (at least to >>>> me), >>>> and afternoon II looks to have available space (although I suspect >>>> that's because congresshall A and B are being prepared for the >>>> plenary, although I note congresshall C is in use). >>> >>> It is also only 1 hour long. >> >> Considering that my original proposal is not working and I showed >> that >> Mark's alternatives wouldn't work either, I am suggesting we leave >> things as is. >> Unless people have a third proposal that would work for the majority >> of interested participants. >> >> We can try to coordinate agendas between the two meetings. >> >> _______________________________________________ >> Apps-Discuss mailing list >> Apps-Discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-26-618464645 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA3MTIwMTEyMDBaMCMGCSqGSIb3 DQEJBDEWBBRJkifaUVMMWR1Nk7NdzzXkeqXfujCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQBkn4eGUl/M+5Ml6AuFUmiefCr1lEl/o3beWO7iTCxOciyR QnsYdddvPFa1JlPGxNjhAJtveeMSBDeb+PcUUaXoU7E5IvU/9Ivy1zwvT/WLB1iTyfPpZ3TgQABs lfkUa5DrAuq0r1sc8wVV9N4xXAgfE9QJddUHCeVGjWx15fnQhv7UHeWP7PZzL8KxasqYtQjCg6LR 30vKTq091cw5phd6cTc0GfCz82I5w3fY5Wm1i4chauzIR4T2Jf6J/RDX3gVtqc5r3J11OTfSoB6R +j13BZjSxgJGL6bPiJofl24JWwsXgRM6zcbAwr8AE4WzU9Uy5oDd2OSUN9iy8qdpfpqZAAAAAAAA --Apple-Mail-26-618464645-- From mnot@mnot.net Sat Jul 11 20:39:17 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 098723A6895 for ; Sat, 11 Jul 2009 20:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.982 X-Spam-Level: X-Spam-Status: No, score=-5.982 tagged_above=-999 required=5 tests=[AWL=-2.383, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLMf7xuY2CVh for ; Sat, 11 Jul 2009 20:39:16 -0700 (PDT) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id 692C83A6AB9 for ; Sat, 11 Jul 2009 20:38:46 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.249.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BED9523E3E8 for ; Sat, 11 Jul 2009 23:39:08 -0400 (EDT) Message-Id: From: Mark Nottingham To: Apps Discuss Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: FYI: new draft of site-meta; now well-known Date: Sun, 12 Jul 2009 13:38:32 +1000 X-Mailer: Apple Mail (2.935.3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 03:39:17 -0000 See: http://bit.ly/48bdmV Cheers, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Sun Jul 12 15:44:19 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4FA28C14F; Sun, 12 Jul 2009 15:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.969 X-Spam-Level: X-Spam-Status: No, score=-5.969 tagged_above=-999 required=5 tests=[AWL=-2.370, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRVBDvXQU7el; Sun, 12 Jul 2009 15:44:15 -0700 (PDT) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id CA8F33A657C; Sun, 12 Jul 2009 15:44:10 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.249.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 624C923E3F1; Sun, 12 Jul 2009 18:44:32 -0400 (EDT) Message-Id: <7DF3CF53-1104-40A7-8256-66F7F252D904@mnot.net> From: Mark Nottingham To: Peter Saint-Andre In-Reply-To: <4A523D5C.4060100@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [hybi] HyBi Bar BoF Date: Mon, 13 Jul 2009 08:43:55 +1000 References: <4A4E30E0.7060203@ericsson.com> <4A523D5C.4060100@stpeter.im> X-Mailer: Apple Mail (2.935.3) Cc: hybi@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 22:44:19 -0000 Breakfast, perhaps? The evening slots are getting full... http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75 On 07/07/2009, at 4:07 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/3/09 10:25 AM, Salvatore Loreto wrote: >> Hi there, >> >> I'd like to know if people are interested and available to join a >> *Bar >> BoF on HyBi* in Stockholm at IETF 75. > > Sounds like a good idea. > >> *Details* >> >> * When: TBD >> * Where: TBD > > I should be there all week. > >> *Topics:* >> - the "near term" solutions to the problem of using HTTP for >> bidirectional exchanges : >> on which, if any, aspect among the one listed in >> draft-loreto-http-bidirectional-00 >> folks think it would be most productive to focus on. >> >> - the "long term" solution... >> clarify the term of the agreement between W3C and IETF, >> and start to discuss on the requirements. >> >> /add suggested topics of discussion as appropriate/ > > I suppose that discussion about BWTP and Web Sockets is part of the > long-term solution? > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkpSPVwACgkQNL8k5A2w/vz2ngCfcyu1bW3B8E2n11g5QHADQxSD > JbgAoPwYsZW2NhFJYsOLzRdyaAKK/RwG > =JFG2 > -----END PGP SIGNATURE----- > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From brad@fitzpat.com Sun Jul 12 18:33:21 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36283A6A37 for ; Sun, 12 Jul 2009 18:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0xtLqS1tTvz for ; Sun, 12 Jul 2009 18:33:21 -0700 (PDT) Received: from mail-yx0-f188.google.com (mail-yx0-f188.google.com [209.85.210.188]) by core3.amsl.com (Postfix) with ESMTP id 008693A67FF for ; Sun, 12 Jul 2009 18:33:20 -0700 (PDT) Received: by yxe26 with SMTP id 26so3237724yxe.4 for ; Sun, 12 Jul 2009 18:33:49 -0700 (PDT) MIME-Version: 1.0 Sender: brad@fitzpat.com Received: by 10.100.107.8 with SMTP id f8mr6398312anc.149.1247448829273; Sun, 12 Jul 2009 18:33:49 -0700 (PDT) In-Reply-To: References: Date: Sun, 12 Jul 2009 18:33:49 -0700 X-Google-Sender-Auth: 4b7f79ce64c1869b Message-ID: <1076e6c00907121833k2b91cd25i90a606b5fdd2a0a9@mail.gmail.com> Subject: Re: FYI: new draft of site-meta; now well-known From: Brad Fitzpatrick To: Mark Nottingham Content-Type: multipart/alternative; boundary=0016e64402545826b4046e8c50be Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 01:33:22 -0000 --0016e64402545826b4046e8c50be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Excellent! Thanks for writing this up! - Brad On Sat, Jul 11, 2009 at 8:38 PM, Mark Nottingham wrote: > See: > http://bit.ly/48bdmV > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --0016e64402545826b4046e8c50be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Excellent! =C2=A0Thanks for writing this up!

- Brad
<= div>
On Sat, Jul 11, 2009 at 8:38 PM, Mark No= ttingham <mnot@mnot.n= et> wrote:
See:
=C2=A0http://bit.ly/48b= dmV

Cheers,

--
Mark Nottingham =C2=A0 =C2=A0 http://www.mnot.net/

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--0016e64402545826b4046e8c50be-- From mnot@mnot.net Sun Jul 12 18:40:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15C43A6906 for ; Sun, 12 Jul 2009 18:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.957 X-Spam-Level: X-Spam-Status: No, score=-5.957 tagged_above=-999 required=5 tests=[AWL=-2.358, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-Zm85TQryoN for ; Sun, 12 Jul 2009 18:40:14 -0700 (PDT) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id CC70A3A6889 for ; Sun, 12 Jul 2009 18:40:14 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.249.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A108323E3F2; Sun, 12 Jul 2009 21:40:30 -0400 (EDT) Message-Id: From: Mark Nottingham To: Brad Fitzpatrick In-Reply-To: <1076e6c00907121833k2b91cd25i90a606b5fdd2a0a9@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: FYI: new draft of site-meta; now well-known Date: Mon, 13 Jul 2009 11:39:54 +1000 References: <1076e6c00907121833k2b91cd25i90a606b5fdd2a0a9@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 01:40:15 -0000 No worries. One thing I'd like early and broad feedback on is that the selection of "/.well-known/" as the distinguished path prefix is appropriate; if someone has a reason that we shouldn't use this, please speak up now! Cheers, On 13/07/2009, at 11:33 AM, Brad Fitzpatrick wrote: > Excellent! Thanks for writing this up! > > - Brad > > On Sat, Jul 11, 2009 at 8:38 PM, Mark Nottingham > wrote: > See: > http://bit.ly/48bdmV > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Mark Nottingham http://www.mnot.net/ From brad@fitzpat.com Sun Jul 12 18:44:43 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A633A6A5C for ; Sun, 12 Jul 2009 18:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXPjbhD7yqy0 for ; Sun, 12 Jul 2009 18:44:42 -0700 (PDT) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by core3.amsl.com (Postfix) with ESMTP id A28453A6920 for ; Sun, 12 Jul 2009 18:44:42 -0700 (PDT) Received: by gxk20 with SMTP id 20so12173224gxk.10 for ; Sun, 12 Jul 2009 18:45:03 -0700 (PDT) MIME-Version: 1.0 Sender: brad@fitzpat.com Received: by 10.100.254.12 with SMTP id b12mr6464247ani.43.1247449501664; Sun, 12 Jul 2009 18:45:01 -0700 (PDT) In-Reply-To: References: <1076e6c00907121833k2b91cd25i90a606b5fdd2a0a9@mail.gmail.com> Date: Sun, 12 Jul 2009 18:45:01 -0700 X-Google-Sender-Auth: 1ca80ae2c6fc9ade Message-ID: <1076e6c00907121845n55d0e420p176079fd26b42a83@mail.gmail.com> Subject: Re: FYI: new draft of site-meta; now well-known From: Brad Fitzpatrick To: Mark Nottingham Content-Type: multipart/alternative; boundary=00163662e7116c055d046e8c7838 Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 01:44:43 -0000 --00163662e7116c055d046e8c7838 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit FWIW, I'm happy with it, and I think I was one of the most grumpy ones about the potential namespace conflicts of well-known URIs. I spent a fair bit of time writing parsers for sites and sites' URLs, so I'm acutely aware of issues like this. I think "/.well-known/" strikes the right balance between obscurity (two semi-'weird' characters), and legibility, and "feels" like a hidden directory, starting with a period. On Sun, Jul 12, 2009 at 6:39 PM, Mark Nottingham wrote: > No worries. > > One thing I'd like early and broad feedback on is that the selection of > "/.well-known/" as the distinguished path prefix is appropriate; if someone > has a reason that we shouldn't use this, please speak up now! > > Cheers, > > > > On 13/07/2009, at 11:33 AM, Brad Fitzpatrick wrote: > > Excellent! Thanks for writing this up! >> >> - Brad >> >> On Sat, Jul 11, 2009 at 8:38 PM, Mark Nottingham wrote: >> See: >> http://bit.ly/48bdmV >> >> Cheers, >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> _______________________________________________ >> Apps-Discuss mailing list >> Apps-Discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > -- > Mark Nottingham http://www.mnot.net/ > > --00163662e7116c055d046e8c7838 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FWIW, I'm happy with it, and I think I was one of the most grumpy ones = about the potential namespace conflicts of well-known URIs. =C2=A0I spent a= fair bit of time writing parsers for sites and sites' URLs, so I'm= =C2=A0acutely=C2=A0aware of issues like this. =C2=A0I think "/.well-kn= own/" strikes the right balance between obscurity (two semi-'weird= ' characters), and legibility, and "feels" like a hidden dire= ctory, starting with a period. --00163662e7116c055d046e8c7838-- From joe@bitworking.org Sun Jul 12 19:45:14 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A29D28C1FF for ; Sun, 12 Jul 2009 19:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twvYx479KDKD for ; Sun, 12 Jul 2009 19:45:13 -0700 (PDT) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by core3.amsl.com (Postfix) with ESMTP id 7258628C1DD for ; Sun, 12 Jul 2009 19:45:13 -0700 (PDT) Received: by gxk20 with SMTP id 20so12298792gxk.10 for ; Sun, 12 Jul 2009 19:45:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.165.8 with SMTP id n8mr6438515ane.111.1247453141971; Sun, 12 Jul 2009 19:45:41 -0700 (PDT) X-Originating-IP: [72.148.43.48] In-Reply-To: References: Date: Sun, 12 Jul 2009 22:45:41 -0400 Message-ID: Subject: Re: FYI: new draft of site-meta; now well-known From: Joe Gregorio To: Mark Nottingham Content-Type: multipart/alternative; boundary=0016e640876866b50a046e8d511a Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 02:45:14 -0000 --0016e640876866b50a046e8d511a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This looks good. I'm historically opposed to well-known URIs, but have mellowed to pragmatism in the past several years. I'm very happy to see the spec cover the minimum needed to do the job and you successfully avoided 'discovery' and left the definition of sub-paths and query parameters to the spec for each well known location. I have spotted two issues: 1) The problem with the current wording is that it leaves the use of fragment identifiers ambiguous in specs that defined well-known locations. I would suggest addressing it to remove the ambiguity. It MAY also contain additional information, such as the syntax of additional path components, query strings, or fragment identifiers to be appended to the well-known URI, or protocol-specific details (e.g., HTTP [RFC2616] method handling). 2) You explain that the spec doesn't say anything about the formats and media-types to be expected at a well-known URI, but fail to mention that the same lack of guarantee also applies to the URI "/.well-known/" itself. To the end of Section 3 you could add: Note that this specification also does not define a format or media-type for the resource at "/.well-known/" and clients should not expect a resource to exist at that location. Thanks, -joe On Sat, Jul 11, 2009 at 11:38 PM, Mark Nottingham wrote: > See: > http://bit.ly/48bdmV > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --0016e640876866b50a046e8d511a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This looks good. I'm historically opposed to well-known URIs, but
ha= ve mellowed to pragmatism in the past several years.
I'm very happy = to see the spec cover the minimum needed to
do the job and you successf= ully avoided 'discovery' and left the definition of
sub-paths and query parameters to the spec for each well known location.
I have spotted two issues:

1) The problem with the current word= ing is that it leaves
the use of fragment identifiers ambiguous in spec= s
that defined well-known locations. I would suggest addressing it to
rem= ove the ambiguity.

   It MAY also contain additional informatio=
n, such as the syntax of 
   additional path components, query strings, =
or fragment identifiers

   to be appended to the well-known URI, or protocol-specific details 
 =
  (e.g., HTTP [RFC2616] method handling).

2) You explain that = the spec doesn't say anything about the formats and media-types
to be expected at a well-known URI, but fail to mention that the same
la= ck of guarantee also applies to the URI "/.well-known/" itself. T= o the end
of Section 3 you could add:

   Note that this spec=
ification also does not define a format or media-type

   for the resource at "/.well-known/" and clients should not exp=
ect a
   resource to exist at that location.
=A0=A0 Thanks,
= =A0=A0 -joe

On Sat, Jul 11, 2009 at 11:38= PM, Mark Nottingham <mnot@mnot.net> wrote:
See:
=A0http://bit.ly/48bdmV=

Cheers,

--
Mark Nottingham =A0 =A0 = http://www.mnot.net/

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--0016e640876866b50a046e8d511a-- From mnot@mnot.net Mon Jul 13 00:04:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45FC83A69A6 for ; Mon, 13 Jul 2009 00:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.838 X-Spam-Level: X-Spam-Status: No, score=-5.838 tagged_above=-999 required=5 tests=[AWL=-2.239, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBgTwuQc6Wo7 for ; Mon, 13 Jul 2009 00:04:14 -0700 (PDT) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id 546EE3A6C74 for ; Mon, 13 Jul 2009 00:03:43 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.249.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BC9CE23E3E7; Mon, 13 Jul 2009 03:03:50 -0400 (EDT) Message-Id: From: Mark Nottingham To: Joe Gregorio In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: FYI: new draft of site-meta; now well-known Date: Mon, 13 Jul 2009 17:03:14 +1000 References: X-Mailer: Apple Mail (2.935.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 07:04:15 -0000 Thanks. Agreed on both points; I'll incorporate into the next drop. On 13/07/2009, at 12:45 PM, Joe Gregorio wrote: > This looks good. I'm historically opposed to well-known URIs, but > have mellowed to pragmatism in the past several years. > I'm very happy to see the spec cover the minimum needed to > do the job and you successfully avoided 'discovery' and left the > definition of > sub-paths and query parameters to the spec for each well known > location. > > I have spotted two issues: > > 1) The problem with the current wording is that it leaves > the use of fragment identifiers ambiguous in specs > that defined well-known locations. I would suggest addressing it to > remove the ambiguity. > > It MAY also contain additional information, such as the syntax of > additional path components, query strings, or fragment identifiers > > to be appended to the well-known URI, or protocol-specific details > (e.g., HTTP [RFC2616] method handling). > > 2) You explain that the spec doesn't say anything about the formats > and media-types > to be expected at a well-known URI, but fail to mention that the same > lack of guarantee also applies to the URI "/.well-known/" itself. To > the end > of Section 3 you could add: > > Note that this specification also does not define a format or > media-type > > for the resource at "/.well-known/" and clients should not expect a > resource to exist at that location. > Thanks, > -joe > > On Sat, Jul 11, 2009 at 11:38 PM, Mark Nottingham > wrote: > See: > http://bit.ly/48bdmV > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Mark Nottingham http://www.mnot.net/ From peter@denic.de Mon Jul 13 00:24:29 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E506E3A6CC3 for ; Mon, 13 Jul 2009 00:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.819 X-Spam-Level: X-Spam-Status: No, score=-5.819 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8utbSmwFJCzW for ; Mon, 13 Jul 2009 00:24:29 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id CD3853A6A8B for ; Mon, 13 Jul 2009 00:24:28 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1MQFuC-0000Hi-Q7; Mon, 13 Jul 2009 09:24:56 +0200 Received: from localhost by x27.adm.denic.de with local id 1MQFuC-00040n-MQ; Mon, 13 Jul 2009 09:24:56 +0200 Date: Mon, 13 Jul 2009 09:24:56 +0200 From: Peter Koch To: Mark Nottingham Subject: Re: FYI: new draft of site-meta; now well-known Message-ID: <20090713072456.GA12378@x27.adm.denic.de> Mail-Followup-To: Mark Nottingham , Apps Discuss References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 07:24:30 -0000 On Sun, Jul 12, 2009 at 01:38:32PM +1000, Mark Nottingham wrote: > See: > http://bit.ly/48bdmV Defining Well-Known URIs draft-nottingham-site-meta-02 The IANA registration policy could benefit from a disambiguation. Section 5.1 says "Designated Expert" with "Specification Required", but then says "typically published in an RFC or Open Standard". The threshold for "Specification Required" is lower, so it's unclear to me whether the additional clause is intended to provide guidance only or is meant to be normative. Later, 5.1.1 seems to imply that change control with all specifications backed by an RFC lies with the IETF, which isn't necessarily the case. On the choice of the name: It's short, descriptive and according to search indices, not widely used. It's descriptive in a certain language environment but at the same time it's a protocol element that is likely exposed to end users. There's an odd chance that helpful implementations will provide localizations (like some do today for email header fields). A tag like "/.---.-" (W and K in Morse code) looks less nice, but might reduce the temptaion of translation. -Peter From mnot@mnot.net Mon Jul 13 00:39:17 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC38A3A6A8B for ; Mon, 13 Jul 2009 00:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.818 X-Spam-Level: X-Spam-Status: No, score=-5.818 tagged_above=-999 required=5 tests=[AWL=-2.219, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h4xoczvSlkG for ; Mon, 13 Jul 2009 00:39:14 -0700 (PDT) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id DDF143A6CF0 for ; Mon, 13 Jul 2009 00:38:57 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.249.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8958623E3F3; Mon, 13 Jul 2009 03:39:23 -0400 (EDT) Message-Id: <8678C394-3BA6-4603-9981-D26256CE7A9C@mnot.net> From: Mark Nottingham To: Peter Koch In-Reply-To: <20090713072456.GA12378@x27.adm.denic.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: FYI: new draft of site-meta; now well-known Date: Mon, 13 Jul 2009 17:38:47 +1000 References: <20090713072456.GA12378@x27.adm.denic.de> X-Mailer: Apple Mail (2.935.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 07:39:17 -0000 On 13/07/2009, at 5:24 PM, Peter Koch wrote: > On Sun, Jul 12, 2009 at 01:38:32PM +1000, Mark Nottingham wrote: >> See: >> http://bit.ly/48bdmV > > Defining Well-Known URIs > draft-nottingham-site-meta-02 > > The IANA registration policy could benefit from a disambiguation. > Section > 5.1 says "Designated Expert" with "Specification Required", but then > says > "typically published in an RFC or Open Standard". The threshold for > "Specification Required" is lower, so it's unclear to me whether the > additional clause is intended to provide guidance only or is meant to > be normative. The use of 'typically' makes it unambiguous. > Later, 5.1.1 seems to imply that change control with all > specifications backed by an RFC lies with the IETF, which isn't > necessarily the case. Will fix this, thanks. > On the choice of the name: > > It's short, descriptive and according to search indices, not widely > used. > > It's descriptive in a certain language environment but at the same > time > it's a protocol element that is likely exposed to end users. There's > an > odd chance that helpful implementations will provide localizations > (like > some do today for email header fields). A tag like "/.---.-" (W and K > in Morse code) looks less nice, but might reduce the temptaion of > translation. It won't be exposed to end users; only site authors/administrators; do people routinely try to rename robots.txt? Using a form with multiple dashes is much more likely to cause problems, IMO. -- Mark Nottingham http://www.mnot.net/ From samj@samj.net Mon Jul 13 02:06:16 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72DA828C251 for ; Mon, 13 Jul 2009 02:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDigFA3FN6jE for ; Mon, 13 Jul 2009 02:06:15 -0700 (PDT) Received: from eu1sys200aog114.obsmtp.com (eu1sys200aog114.obsmtp.com [207.126.144.137]) by core3.amsl.com (Postfix) with SMTP id 51EB028C28C for ; Mon, 13 Jul 2009 02:06:15 -0700 (PDT) Received: from source ([209.85.220.216]) by eu1sys200aob114.postini.com ([207.126.147.11]) with SMTP ID DSNKSlr5JEQ4Q1NHC5z302QfyWTt5PzXZ7r5@postini.com; Mon, 13 Jul 2009 09:06:46 UTC Received: by fxm12 with SMTP id 12so34134fxm.36 for ; Mon, 13 Jul 2009 02:06:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.31.17 with SMTP id e17mr3058889fge.47.1247476004715; Mon, 13 Jul 2009 02:06:44 -0700 (PDT) In-Reply-To: <8678C394-3BA6-4603-9981-D26256CE7A9C@mnot.net> References: <20090713072456.GA12378@x27.adm.denic.de> <8678C394-3BA6-4603-9981-D26256CE7A9C@mnot.net> Date: Mon, 13 Jul 2009 11:06:44 +0200 Message-ID: <21606dcf0907130206h295cc849nfb8bbcdab076b843@mail.gmail.com> Subject: Re: FYI: new draft of site-meta; now well-known From: Sam Johnston To: Mark Nottingham Content-Type: multipart/alternative; boundary=000e0cd24442207eaf046e92a4d2 Cc: Apps Discuss , Peter Koch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 09:06:16 -0000 --000e0cd24442207eaf046e92a4d2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Jul 13, 2009 at 9:38 AM, Mark Nottingham wrote: > Using a form with multiple dashes is much more likely to cause problems, > IMO. > Agreed... I think /.well-known/ is highly sensible - kudos to whoever came up with that (the former suggestions were, in contrast, very ordinary). Sam --000e0cd24442207eaf046e92a4d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 13, 2009 at 9:38 AM, Mark Nottingham <mnot@mnot.net> wrote:
Using a form with multiple dashes is much m= ore likely to cause problems, IMO.

Agreed... I think /.well-known/ is highly sensible - kudos= to whoever came up with that (the former suggestions were, in contrast, ve= ry ordinary).

Sam

--000e0cd24442207eaf046e92a4d2-- From salvatore.loreto@ericsson.com Mon Jul 13 10:37:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AEDC28C5F9; Mon, 13 Jul 2009 10:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.903 X-Spam-Level: X-Spam-Status: No, score=-3.903 tagged_above=-999 required=5 tests=[AWL=-1.654, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIv7MNzoi5+7; Mon, 13 Jul 2009 10:37:30 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 33D743A6DA5; Mon, 13 Jul 2009 10:36:35 -0700 (PDT) X-AuditID: c1b4fb24-b7b2fae000000abb-95-4a5b70c08d3e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id E7.81.02747.0C07B5A4; Mon, 13 Jul 2009 19:37:04 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 19:37:03 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 19:37:03 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id F08DB2461; Mon, 13 Jul 2009 20:37:03 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B518D21A07; Mon, 13 Jul 2009 20:37:03 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5823F219CC; Mon, 13 Jul 2009 20:37:03 +0300 (EEST) Message-ID: <4A5B70BF.8050903@ericsson.com> Date: Mon, 13 Jul 2009 20:37:03 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Mark Nottingham Subject: Re: [hybi] HyBi Bar BoF References: <4A4E30E0.7060203@ericsson.com> <4A523D5C.4060100@stpeter.im> <7DF3CF53-1104-40A7-8256-66F7F252D904@mnot.net> In-Reply-To: <7DF3CF53-1104-40A7-8256-66F7F252D904@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 13 Jul 2009 17:37:03.0723 (UTC) FILETIME=[88DD1BB0:01CA03E0] X-Brightmail-Tracker: AAAAAA== Cc: hybi@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 17:37:31 -0000 here a possibility, - HyBi Breakfast BoF on Thursday 30 July, 07:30 - ? - Where: TBD cheers Sal Mark Nottingham wrote: > Breakfast, perhaps? > > The evening slots are getting full... > > http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75 > > > > On 07/07/2009, at 4:07 AM, Peter Saint-Andre wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 7/3/09 10:25 AM, Salvatore Loreto wrote: >>> Hi there, >>> >>> I'd like to know if people are interested and available to join a *Bar >>> BoF on HyBi* in Stockholm at IETF 75. >> >> Sounds like a good idea. >> >>> *Details* >>> >>> * When: TBD >>> * Where: TBD >> >> I should be there all week. >> >>> *Topics:* >>> - the "near term" solutions to the problem of using HTTP for >>> bidirectional exchanges : >>> on which, if any, aspect among the one listed in >>> draft-loreto-http-bidirectional-00 >>> folks think it would be most productive to focus on. >>> >>> - the "long term" solution... >>> clarify the term of the agreement between W3C and IETF, >>> and start to discuss on the requirements. >>> >>> /add suggested topics of discussion as appropriate/ >> >> I suppose that discussion about BWTP and Web Sockets is part of the >> long-term solution? >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkpSPVwACgkQNL8k5A2w/vz2ngCfcyu1bW3B8E2n11g5QHADQxSD >> JbgAoPwYsZW2NhFJYsOLzRdyaAKK/RwG >> =JFG2 >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Apps-Discuss mailing list >> Apps-Discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > -- > Mark Nottingham http://www.mnot.net/ > From stpeter@stpeter.im Mon Jul 13 11:37:10 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497BF28C37B; Mon, 13 Jul 2009 11:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2aRyAKASB6V; Mon, 13 Jul 2009 11:37:09 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5693928C54D; Mon, 13 Jul 2009 11:36:30 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 942FF4007B; Mon, 13 Jul 2009 12:37:00 -0600 (MDT) Message-ID: <4A5B7ECB.6010800@stpeter.im> Date: Mon, 13 Jul 2009 12:36:59 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Salvatore Loreto Subject: Re: [hybi] HyBi Bar BoF References: <4A4E30E0.7060203@ericsson.com> <4A523D5C.4060100@stpeter.im> <7DF3CF53-1104-40A7-8256-66F7F252D904@mnot.net> <4A5B70BF.8050903@ericsson.com> In-Reply-To: <4A5B70BF.8050903@ericsson.com> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 18:37:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/13/09 11:37 AM, Salvatore Loreto wrote: > > here a possibility, > > - HyBi Breakfast BoF on Thursday 30 July, 07:30 - ? > - Where: TBD That works for. Plus the httpbis session is on Thursday so I hope we'll have lots of HTTP people available on that morning. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpbfssACgkQNL8k5A2w/vwMEwCglqi61IIFlyVa2jWcX0Bmthv0 pHwAoMJzOdGB/Xmwxt9T+QyHtKbGNsg8 =QZCy -----END PGP SIGNATURE----- From cabo@tzi.org Mon Jul 13 14:15:36 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC08828C37E; Mon, 13 Jul 2009 14:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weUFKJQYUOd9; Mon, 13 Jul 2009 14:15:35 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 5BC8A28C36C; Mon, 13 Jul 2009 14:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n6DLFtvs004933; Mon, 13 Jul 2009 23:15:55 +0200 (CEST) Received: from [192.168.217.107] (p5489C4F4.dip.t-dialin.net [84.137.196.244]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 47C39B607; Mon, 13 Jul 2009 23:15:55 +0200 (CEST) Message-Id: <827B8C0A-667E-441B-8396-D33FF007A7A0@tzi.org> From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org>, apps-discuss@ietf.org, ROLL WG In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: Re: 6LowApp: Application protocols for 6LoWPAN and other LLN Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 13 Jul 2009 23:15:54 +0200 References: X-Mailer: Apple Mail (2.935.3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 21:15:36 -0000 Based on the extensive feedback I got for the 6LowApp Bar BOF, I have slightly extended the problem statement: http://u.nu/2bfj = http://www.ietf.org/internet-drafts/draft-bormann-6lowpan-6lowapp-problem-01.txt Thanks to all the additional contributors. (I don't agree with all their comments, but I tried to err on the side of capturing as many requirements as possible.) The Bar BOF is still scheduled at ->Tue 18:30<-. I'm going to ask the ADs for a room so we can hear each other (and maybe use a projector). Again, please tell me if you want a slot in the structured part. Even after the I-D deadline, you can continue to capture information at the Bar BOF Wiki: http://u.nu/6jfh = http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75/6LowApp Gruesse, Carsten On Jul 6, 2009, at 12:56, Carsten Bormann wrote: > The 6LoWPAN and ROLL WGs are laying the groundwork to make the > Wireless Embedded Internet a reality, but what application protocols > will we use? Request-response protocols like HTTP are a poor fit to > a communication model with battery-operated, mostly sleeping nodes. > In addition, the usual data formats (both headers and body) are > perceived to be too chatty for the 50-60 byte payloads possible in > LoWPANs and to require too much code for the 8-bit and 16-bit > processors dominating the Internet of Things. Still, it would be a > mistake to start a new silo of application protocols that do not > benefit from existing application area Internet experience. > > At IETF75, we will hold a Bar BOF to scope out possible IETF work > and maybe form an opinion on which part should be done in which IETF > area. > > Tentative information is at http://u.nu/6jfh = > http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75/6LowApp > (and you are welcome to contribute to this Wiki page). > > -> Please tell us whether the envisaged date and time of ->Tue > 18:30<- will work for you! > > A first version of a problem statement (where the above paragraph > was stolen from) is at: > > http://tools.ietf.org/id/6lowapp > (draft-bormann-6lowpan-6lowapp-problem-00.txt) > > I will start planning an agenda for the Bar BOF soon, so if you have > something to say that would help in this conversation, please tell > me (with an estimated amount of time). > > Gruesse, Carsten From iljitsch@muada.com Mon Jul 13 14:20:35 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74BCE28C609 for ; Mon, 13 Jul 2009 14:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koMHmLwtb2ZL for ; Mon, 13 Jul 2009 14:20:34 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 0BEBD28C6B9 for ; Mon, 13 Jul 2009 14:19:18 -0700 (PDT) Received: from [192.168.2.4] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n6DLJLnr033648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 13 Jul 2009 23:19:22 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <3AF3234F-D18E-492C-A291-BA36F02AE2AE@muada.com> From: Iljitsch van Beijnum To: apps-discuss@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: FTP issues with IPv6-IPv4 translation Date: Mon, 13 Jul 2009 23:19:22 +0200 References: X-Mailer: Apple Mail (2.935.3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 21:20:35 -0000 Here's an update of the FTP64 draft that fixes an incorrect interpretation of the default port 20 behavior in the -04 version: http://www.ietf.org/internet-drafts/draft-van-beijnum-behave-ftp64-05.txt From cabo@tzi.org Mon Jul 13 15:06:07 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4AC63A696D; Mon, 13 Jul 2009 15:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFhoYC2GVWbS; Mon, 13 Jul 2009 15:06:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id C3A0A28C678; Mon, 13 Jul 2009 15:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n6DM4pda019968; Tue, 14 Jul 2009 00:04:51 +0200 (CEST) Received: from [192.168.217.107] (p5489C4F4.dip.t-dialin.net [84.137.196.244]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 50FE7B615; Tue, 14 Jul 2009 00:04:51 +0200 (CEST) Message-Id: From: Carsten Bormann To: Carsten Bormann In-Reply-To: <827B8C0A-667E-441B-8396-D33FF007A7A0@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [6lowpan] 6LowApp: Application protocols for 6LoWPAN and other LLN Date: Tue, 14 Jul 2009 00:04:50 +0200 References: <827B8C0A-667E-441B-8396-D33FF007A7A0@tzi.org> X-Mailer: Apple Mail (2.935.3) Cc: ROLL WG , 6lowpan <6lowpan@ietf.org>, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 22:06:07 -0000 On Jul 13, 2009, at 23:15, Carsten Bormann wrote: > slightly extended the problem statement (For those not aware of tools.ietf.org: side-by-side diff at:) http://u.nu/8pfj Gruesse, Carsten From josh@lindenlab.com Mon Jul 13 09:47:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D9628C4EC; Mon, 13 Jul 2009 09:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZpdx1Hq5shy; Mon, 13 Jul 2009 09:47:53 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [216.82.11.128]) by core3.amsl.com (Postfix) with ESMTP id 0C37328C4C0; Mon, 13 Jul 2009 09:47:52 -0700 (PDT) Received: from [10.1.8.223] (thickslab.lindenlab.com [10.1.8.223]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 5C7D23DBC448; Mon, 13 Jul 2009 09:48:23 -0700 (PDT) Message-ID: <4A5B6557.90500@lindenlab.com> Date: Mon, 13 Jul 2009 09:48:23 -0700 From: Joshua Bell User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: hybi@ietf.org Subject: Re: [hybi] HyBi Bar BoF References: <4A4E30E0.7060203@ericsson.com> <4A523D5C.4060100@stpeter.im> <7DF3CF53-1104-40A7-8256-66F7F252D904@mnot.net> In-Reply-To: <7DF3CF53-1104-40A7-8256-66F7F252D904@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Jul 2009 17:16:15 -0700 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 16:47:57 -0000 At the risk of saying "me too!", count me in as interested in attending any/all HyBi discussions that take place in Stockholm. The OGPX drafts (my primary motivation for attending) currently recommend long-polling over HTTP for server-to-client messaging and look wistfully towards future standardization in this area. I work closely with one of the authors of http://tools.ietf.org/html/draft-lentczner-rhttp-00 Discussion topics mentioned below sound appropriate. I'd toss on "past, present, and future of the two-connection limit" as well, and possibly (but lower priority) "evolution of the same-origin policy, and its impact on HyBi". Mark Nottingham wrote: > Breakfast, perhaps? > > The evening slots are getting full... > > http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75 > > > > On 07/07/2009, at 4:07 AM, Peter Saint-Andre wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 7/3/09 10:25 AM, Salvatore Loreto wrote: >>> Hi there, >>> >>> I'd like to know if people are interested and available to join a *Bar >>> BoF on HyBi* in Stockholm at IETF 75. >> >> Sounds like a good idea. >> >>> *Details* >>> >>> * When: TBD >>> * Where: TBD >> >> I should be there all week. >> >>> *Topics:* >>> - the "near term" solutions to the problem of using HTTP for >>> bidirectional exchanges : >>> on which, if any, aspect among the one listed in >>> draft-loreto-http-bidirectional-00 >>> folks think it would be most productive to focus on. >>> >>> - the "long term" solution... >>> clarify the term of the agreement between W3C and IETF, >>> and start to discuss on the requirements. >>> >>> /add suggested topics of discussion as appropriate/ >> >> I suppose that discussion about BWTP and Web Sockets is part of the >> long-term solution? >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkpSPVwACgkQNL8k5A2w/vz2ngCfcyu1bW3B8E2n11g5QHADQxSD >> JbgAoPwYsZW2NhFJYsOLzRdyaAKK/RwG >> =JFG2 >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Apps-Discuss mailing list >> Apps-Discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > -- > Mark Nottingham http://www.mnot.net/ > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From msk@cloudmark.com Mon Jul 13 13:25:30 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7993A67F3 for ; Mon, 13 Jul 2009 13:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.242 X-Spam-Level: X-Spam-Status: No, score=-1.242 tagged_above=-999 required=5 tests=[AWL=-1.340, BAYES_00=-2.599, FRT_POSSIBLE=2.697] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hihtvTqR1HHP for ; Mon, 13 Jul 2009 13:25:29 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id C35AE3A6A16 for ; Mon, 13 Jul 2009 13:24:55 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Mon, 13 Jul 2009 13:25:13 -0700 From: "Murray S. Kucherawy" To: "discuss@ietf.org" Date: Mon, 13 Jul 2009 13:25:12 -0700 Subject: RE: Proposed WG charter for "arf" (Abuse Report Format) Thread-Topic: Proposed WG charter for "arf" (Abuse Report Format) Thread-Index: AcoAnfBNXEGRsEYJQi2vvsNV0JbNSQDWeleg Message-ID: References: <4A55F884.6070703@cisco.com> In-Reply-To: <4A55F884.6070703@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_BB012BD379D7B046ABE1472D8093C61C01131FA8F7EXCHC2corpclo_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 13 Jul 2009 17:16:15 -0700 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 20:25:30 -0000 --_002_BB012BD379D7B046ABE1472D8093C61C01131FA8F7EXCHC2corpclo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVyZSdzIGEgcmV2aXNlZCBjaGFydGVyIHRoYXQgbGlzdHMgc29tZSBzcGVjaWZpYyBlbmhhbmNl bWVudHMgdGhhdCBoYXZlIGJlZW4gcHJvcG9zZWQgYnkgb3BlcmF0b3JzIGFscmVhZHkgdXNpbmcg QVJGIHdpdGhpbiBNQUFXRy4gIFRoZSB3b3JraW5nIGdyb3VwIHdvdWxkIGNvbnNpZGVyIHRoZXNl IGFzIGVuaGFuY2VtZW50cyB0byB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uLg0K --_002_BB012BD379D7B046ABE1472D8093C61C01131FA8F7EXCHC2corpclo_ Content-Type: text/plain; name="arf-charter v03.txt" Content-Description: arf-charter v03.txt Content-Disposition: attachment; filename="arf-charter v03.txt"; size=3559; creation-date="Tue, 16 Jun 2009 13:09:28 GMT"; modification-date="Mon, 13 Jul 2009 13:23:37 GMT" Content-Transfer-Encoding: base64 ICAgV29ya2luZyBHcm91cCBOYW1lOg0KICAgICAgICBBYnVzZSBSZXBvcnRpbmcgRm9ybWF0IChB UkYpDQoNCiAgIElFVEYgQXJlYToNCiAgICAgICAgQXBwbGljYXRpb25zIEFyZWENCg0KICAgQ2hh aXIocyk6DQogICAgICAgIFRCRA0KDQogICBBcHBsaWNhdGlvbnMgQXJlYSBEaXJlY3RvcihzKToN CiAgICAgICAgTGlzYSBEdXNzZWF1bHQgPExpc2EuRHVzc2VhdWx0QG1lc3NhZ2luZ2FyY2hpdGVj dHMuY29tPg0KICAgICAgICBBbGV4ZXkgTWVsbmlrb3YgPGFsZXhleS5tZWxuaWtvdkBpc29kZS5j b20+DQoNCiAgIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3I6DQogICAgICAgIFRCRA0KDQogICBN YWlsaW5nIExpc3RzOg0KICAgICAgICBHZW5lcmFsIERpc2N1c3Npb246IGFidXNlLWZlZWRiYWNr LXJlcG9ydEBtaXBhc3NvYy5vcmcNCiAgICAgICAgVG8gU3Vic2NyaWJlOiBodHRwOi8vbWlwYXNz b2Mub3JnL21haWxtYW4vbGlzdGluZm8vYWJ1c2UtZmVlZGJhY2stcmVwb3J0DQogICAgICAgIEFy Y2hpdmU6IGh0dHA6Ly9taXBhc3NvYy5vcmcvbWFpbG1hbi9saXN0aW5mby9hYnVzZS1mZWVkYmFj ay1yZXBvcnQNCg0KICAgRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoNCglNZXNzYWdpbmcg YW50aS1hYnVzZSBvcGVyYXRpb25zIGJldHdlZW4gaW5kZXBlbmRlbnQgc2VydmljZXMgb2Z0ZW4g cmVxdWlyZXMNCglzZW5kaW5nIHJlcG9ydHMgb24gb2JzZXJ2ZWQgZnJhdWQsIHNwYW0gdmlydXMg b3Igb3RoZXIgYWJ1c2UgYWN0aXZpdHkuICBBDQoJc3RhbmRhcmRpemVkIHJlcG9ydCBmb3JtYXQg ZW5hYmxlcyBhdXRvbWF0ZWQgcHJvY2Vzc2luZy4gIFRoZSBBYnVzZSBSZXBvcnRpbmcNCglGb3Jt YXQgKEFSRikgc3BlY2lmaWNhdGlvbiBoYXMgZ2FpbmVkIHN1ZmZpY2llbnQgcG9wdWxhcml0eSB0 byB3YXJyYW50IGZvcm1hbA0KCWNvZGlmaWNhdGlvbiwgdG8gZW5zdXJlIGZ1dHVyZSBpbnRlcm9w ZXJhYmlsaXR5IHdpdGggbmV3IGltcGxlbWVudGF0aW9ucy4NCglUaGUgcHJpbWFyeSBmdW5jdGlv biBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBiZSB0byBzb2xpY2l0IHJldmlldyBhbmQNCgly ZWZpbmVtZW50IG9mIHRoZSBleGlzdGluZyBzcGVjaWZpY2F0aW9uLg0KDQoJQVJGIHdhcyBkZXZl bG9wZWQgYnkgYSBtZXNzYWdpbmcgdHJhZGUgb3JnYW5pemF0aW9uIGluZGVwZW5kZW50IG9mIHRo ZSBJRVRGLA0KCWFuZCB1c2VzIGEgZm9ybWF0IHNpbWlsYXIgdG8gYSBEZWxpdmVyeSBTdGF0dXMg Tm90aWZpY2F0aW9uIChEU04sIFJGQzM0NjQpDQoJdG8gcmVwb3J0IGZyYXVkLCBzcGFtLCB2aXJ1 c2VzIG9yIG90aGVyIGFidXNpdmUgYWN0aXZpdHkgaW4gdGhlIGVtYWlsIHN5c3RlbS4NCglUaGUg YmFzaWMgZm9ybWF0IGlzIGFtZW5hYmxlIHRvIHByb2Nlc3NpbmcgYnkgaHVtYW5zIG9yIHNvZnR3 YXJlLCB3aXRoIHRoZQ0KCWxhdHRlciByZXF1aXJpbmcgdGhlIGZvcm1hdCB0byBiZSBzdGFuZGFy ZGl6ZWQsIHRvIHBlcm1pdCBpbnRlcm9wZXJhYmlsaXR5DQoJYmV0d2VlbiBhdXRvbWF0ZWQgc2Vy dmljZXMsIHBhcnRpY3VsYXJseSB3aXRob3V0IHByaW9yIGFycmFuZ2VtZW50Lg0KDQoJQVJGIGFz IGluaXRpYWxseSBkZWZpbmVkIGlzIGFscmVhZHkgaW4gd2lkZXNwcmVhZCB1c2UgYXQgbGFyZ2Ug SVNQcywgc28NCglpbnRlcm9wZXJhYmlsaXR5IGNhbiBiZSBkZW1vbnN0cmF0ZWQuICBTb21lIHRv b2xzIGFscmVhZHkgZXhpc3QNCglmb3IgcHJvY2Vzc2luZyBBUkYgbWVzc2FnZXMsIGEgZmV3IG9m IHdoaWNoIGFyZSBvcGVuIHNvdXJjZS4gIEluIG9yZGVyIHRvDQoJcHJlc2VydmUgdGhlIGluc3Rh bGxlZCBiYXNlLCB0aGUgd29ya2luZyBncm91cCB3aWxsIG1ha2UgdGhlIG1pbmltdW0gY2hhbmdl cw0KCW5lY2Vzc2FyeSB0byB0aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbiBhbmQgd2lsbCBzZWVr IHRvIGhhdmUgYmFja3dhcmQNCgljb21wYXRpYmlsaXR5LiAgRnVydGhlcm1vcmUsIHNvbWUgZXh0 ZW5zaW9ucyB0byB0aGUgY3VycmVudCBwcm9wb3NhbCBhcmUNCglvZiBpbnRlcmVzdCB0byB0aGUg Y29tbXVuaXR5LCBzdWNoIGFzIHRoZSBtZWFucyBmb3IgYW4gb3BlcmF0b3IgdG8gYWR2ZXJ0aXNl DQoJYW4gZW1haWwgYWRkcmVzcyB0byB3aGljaCBhYnVzZSByZXBvcnRzIHVzaW5nIEFSRiBzaG91 bGQgYmUgc2VudC4gIFRoZQ0KCXdvcmtpbmcgZ3JvdXAgd2lsbCB0YWtlIG9uIHRoZSB0YXNrIG9m IHNwZWNpZnlpbmcgc3VjaCBhIG1lY2hhbmlzbSBhcw0KCXBhcnQgb2YgdGhlIGZpcnN0IGRyYWZ0 IGl0IHdpbGwgaXNzdWUuDQoNCglUaGUgaW5pdGlhbCBwcm9wb3NhbCBpcyBwdWJsaXNoZWQgYXMg ZHJhZnQtc2hhZnJhbm92aWNoLWZlZWRiYWNrLXJlcG9ydCwNCglhbmQgdGhpcyB3aWxsIHByb3Zp ZGUgdGhlIHdvcmtpbmcgZ3JvdXAncyBzdGFydGluZyBwb2ludC4NCg0KCVRoZSBmb2xsb3dpbmcg cG9zc2lsYmxlIHJlcG9ydGluZyBleHRlbnNpb25zIHdpbGwgYmUgY29uc2lkZXJlZDoNCg0KCTEp IGRyb3AgYm94ZXMgKGRldGVjdGlvbiBvZiBhIG1haWxib3ggdXNlZCB0byByZWNlaXZlIHRoaW5n cyBsaWtlIHN0b2xlbg0KCSAgIGNyZWRpdCBjYXJkcykNCgkyKSBib3RuZXQgZGV0ZWN0aW9uIChp LmUuIHJlcG9ydGluZyBvZiB0cmFmZmljIHRoYXQgYXBwZWFycyB0byBoYXZlIGNvbWUNCgkgICBm cm9tIGEgYm90LCByZWdhcmRsZXNzIG9mIGNvbnRlbnQpDQoJMykgU1NIIGF0dGFja3MNCgk0KSBG VFAgYXR0YWNrcw0KCTUpIFdlYiBzZXJ2ZXIgYXR0YWNrcw0KCTYpIG1haWwgc2VudCB0byBhIGhv bmV5cG90IG9yIHNwYW0gdHJhcA0KCTcpIG1hbHdhcmUgY29ubmVjdGlvbnMgdG8gc2lua2hvbGVz DQoJOCkgRERvUyByZXBvcnRzDQoNCglJbiBhZGRpdGlvbiwgdGhlIGdyb3VwIHdpbGwgc3BlY2lm eSB0aGUgaW50ZWdyYXRpb24gb2YgQVJGIGludG8gREtJTSB1c2UNCgl1c2luZyBkcmFmdC1rdWNo ZXJhd3ktZGtpbS1yZXBvcnRpbmcgYXMgaXRzIGlucHV0LiAgSXQgY29udGFpbnMgZXh0ZW5zaW9u cw0KCXRvIERLSU0gdGhhdCBhcmUgcmVsYXRlZCB0byBBUkYgYXMgYSBtZWFucyBvZiByZXBvcnRp bmcgREtJTS1yZWxhdGVkIGZhaWx1cmVzDQoJd2hpY2ggaW5jbHVkZSBwaGlzaGluZyAoImZyYXVk IikgYW5kIGFzIHN1Y2ggYXJlIHJlbGV2YW50IHRvIHRoZSBBUkYgZWZmb3J0Lg0KDQogICBHb2Fs cyBhbmQgTWlsZXN0b25lczoNCglOb3YgMDkJSXNzdWUgZmlyc3QgV0ctYmFzZWQgSW50ZXJuZXQt RHJhZnQgZGVmaW5pbmcgQVJGDQoJSmFuIDA5CUFjaGlldmUgY29uc2Vuc3VzIG9uIGFueSBXRy1i YXNlZCBjaGFuZ2VzIHRvIEFSRg0KCUZlYiAxMAlTdWJtaXQgQVJGIElEIHRvIElFU0cgZm9yIHB1 YmxpY2F0aW9uDQoJQXByIDEwCUlzc3VlIGZpcnN0IFdHLWJhc2VkIElEIGFib3V0IERLSU0gcmVw b3J0aW5nIGV4dGVuc2lvbnMNCglKdW4gMTAJQWNoaWV2ZSBjb25zZW5zdXMgb24gREtJTSByZXBv cnRpbmcgZXh0ZW5zaW9ucyBkcmFmdA0KCUp1bCAxMAlTdWJtaXQgREtJTSByZXBvcnRpbmcgSUQg dG8gSUVTRyBmb3IgcHVibGljYXRpb24NCg== --_002_BB012BD379D7B046ABE1472D8093C61C01131FA8F7EXCHC2corpclo_-- From d.sturek@att.net Mon Jul 13 15:47:40 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2E828C347 for ; Mon, 13 Jul 2009 15:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mai-bCwvV1c7 for ; Mon, 13 Jul 2009 15:47:40 -0700 (PDT) Received: from smtp109-mob.biz.mail.ac4.yahoo.com (smtp109-mob.biz.mail.ac4.yahoo.com [76.13.13.230]) by core3.amsl.com (Postfix) with SMTP id 17BDF3A6A8D for ; Mon, 13 Jul 2009 15:47:40 -0700 (PDT) Received: (qmail 93777 invoked from network); 13 Jul 2009 22:41:31 -0000 Received: from unknown (HELO bda1055.bisx.prod.on.blackberry) (d.sturek@67.223.70.32 with xymcookie) by smtp109-mob.biz.mail.ac4.yahoo.com with SMTP; 13 Jul 2009 22:41:30 -0000 X-Yahoo-SMTP: RL.ukv2swBCmFOHc.o9VWIAUOOfGTiu9CJTsFEQ- X-YMail-OSG: JM6jJmgVM1kmAm819XTlPQhhXJfyC_ufqwt9eFYLTN.3xwpg0LKLJ2JibMuZE0KFcGBOjoP6gvky37ToWbnm7m8mixE2PnrTYR1mqDu7xFheRnr_WCapcsNCTHP7Drx2ALntdEoGO3y3FTCx1pws8Eus_jTsmMg1nolQ7OzlstW0SiLe0cMW2mXOTy3FQjjgj4rXBhIGceuwZcXNQ530MblXHLjAzLLqs9.VxM5oAeoYKpk9q9x70TezUYdYqIxLqmb88M4friK0NiYJ2uj185LI X-Yahoo-Newman-Property: ymail-3 X-rim-org-msg-ref-id: 1819178574 Message-ID: <1819178574-1247524889-cardhu_decombobulator_blackberry.rim.net-1146920564-@bxe1266.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <827B8C0A-667E-441B-8396-D33FF007A7A0@tzi.org> In-Reply-To: <827B8C0A-667E-441B-8396-D33FF007A7A0@tzi.org> Sensitivity: Normal Importance: Normal To: "Carsten Bormann" , roll-bounces@ietf.org, "6lowpan" <6lowpan@ietf.org>, apps-discuss@ietf.org, "ROLL WG" Subject: Re: [Roll] 6LowApp: Application protocols for 6LoWPAN and other LLN From: d.sturek@att.net Date: Mon, 13 Jul 2009 22:44:02 +0000 Content-Type: text/plain MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 13 Jul 2009 17:16:15 -0700 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 22:47:40 -0000 SGkgY2Fyc3RlbiwNCg0KSSB3b3VsZCBsaWtlIHRvIHByZXNlbnQgdGhlIHRpbWVsaW5lIGFuZCBy ZXF1aXJlbWVudHMgZm9yIHRoZSB6aWdiZWUgc21hcnQgZW5lcmd5IHdvcmsuICBTaG91bGQgYmUg bm90IG1vcmUgdGhhbiA1IHNsaWRlcyBhbmQgMTUgbWludXRlcy4NCg0KRG9uDQpTZW50IHZpYSBC bGFja0JlcnJ5IGZyb20gVC1Nb2JpbGUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPg0KDQpEYXRlOiBNb24sIDEzIEp1bCAy MDA5IDIzOjE1OjU0IA0KVG86IDZsb3dwYW48Nmxvd3BhbkBpZXRmLm9yZz47IDxhcHBzLWRpc2N1 c3NAaWV0Zi5vcmc+OyBST0xMIFdHPHJvbGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1JvbGxd IDZMb3dBcHA6IEFwcGxpY2F0aW9uIHByb3RvY29scyBmb3IgNkxvV1BBTiBhbmQgb3RoZXIgTExO DQoNCg0KQmFzZWQgb24gdGhlIGV4dGVuc2l2ZSBmZWVkYmFjayBJIGdvdCBmb3IgdGhlIDZMb3dB cHAgQmFyIEJPRiwgSSBoYXZlICANCnNsaWdodGx5IGV4dGVuZGVkIHRoZSBwcm9ibGVtIHN0YXRl bWVudDoNCg0KaHR0cDovL3UubnUvMmJmaiAgPQ0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtYm9ybWFubi02bG93cGFuLTZsb3dhcHAtcHJvYmxlbS0wMS50eHQNCg0K VGhhbmtzIHRvIGFsbCB0aGUgYWRkaXRpb25hbCBjb250cmlidXRvcnMuIChJIGRvbid0IGFncmVl IHdpdGggYWxsICANCnRoZWlyIGNvbW1lbnRzLCBidXQgSSB0cmllZCB0byBlcnIgb24gdGhlIHNp ZGUgb2YgY2FwdHVyaW5nIGFzIG1hbnkgIA0KcmVxdWlyZW1lbnRzIGFzIHBvc3NpYmxlLikNCg0K VGhlIEJhciBCT0YgaXMgc3RpbGwgc2NoZWR1bGVkIGF0IC0+VHVlIDE4OjMwPC0uDQpJJ20gZ29p bmcgdG8gYXNrIHRoZSBBRHMgZm9yIGEgcm9vbSBzbyB3ZSBjYW4gaGVhciBlYWNoIG90aGVyIChh bmQgIA0KbWF5YmUgdXNlIGEgcHJvamVjdG9yKS4NCkFnYWluLCBwbGVhc2UgdGVsbCBtZSBpZiB5 b3Ugd2FudCBhIHNsb3QgaW4gdGhlIHN0cnVjdHVyZWQgcGFydC4NCg0KRXZlbiBhZnRlciB0aGUg SS1EIGRlYWRsaW5lLCB5b3UgY2FuIGNvbnRpbnVlIHRvIGNhcHR1cmUgaW5mb3JtYXRpb24gIA0K YXQgdGhlIEJhciBCT0YgV2lraToNCmh0dHA6Ly91Lm51LzZqZmggID0NCmh0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvYXBwL3RyYWMvd2lraS9CYXJCb2ZzL0lFVEY3NS82TG93QXBwDQoN CkdydWVzc2UsIENhcnN0ZW4NCg0KDQpPbiBKdWwgNiwgMjAwOSwgYXQgMTI6NTYsIENhcnN0ZW4g Qm9ybWFubiB3cm90ZToNCg0KPiAgIFRoZSA2TG9XUEFOIGFuZCBST0xMIFdHcyBhcmUgbGF5aW5n IHRoZSBncm91bmR3b3JrIHRvIG1ha2UgdGhlDQo+ICAgV2lyZWxlc3MgRW1iZWRkZWQgSW50ZXJu ZXQgYSByZWFsaXR5LCBidXQgd2hhdCBhcHBsaWNhdGlvbiBwcm90b2NvbHMNCj4gICB3aWxsIHdl IHVzZT8gIFJlcXVlc3QtcmVzcG9uc2UgcHJvdG9jb2xzIGxpa2UgSFRUUCBhcmUgYSBwb29yIGZp dCB0bw0KPiAgIGEgY29tbXVuaWNhdGlvbiBtb2RlbCB3aXRoIGJhdHRlcnktb3BlcmF0ZWQsIG1v c3RseSBzbGVlcGluZyBub2Rlcy4NCj4gICBJbiBhZGRpdGlvbiwgdGhlIHVzdWFsIGRhdGEgZm9y bWF0cyAoYm90aCBoZWFkZXJzIGFuZCBib2R5KSBhcmUNCj4gICBwZXJjZWl2ZWQgdG8gYmUgdG9v IGNoYXR0eSBmb3IgdGhlIDUwLTYwIGJ5dGUgcGF5bG9hZHMgcG9zc2libGUgaW4NCj4gICBMb1dQ QU5zIGFuZCB0byByZXF1aXJlIHRvbyBtdWNoIGNvZGUgZm9yIHRoZSA4LWJpdCBhbmQgMTYtYml0 DQo+ICAgcHJvY2Vzc29ycyBkb21pbmF0aW5nIHRoZSBJbnRlcm5ldCBvZiBUaGluZ3MuICBTdGls bCwgaXQgd291bGQgYmUgYQ0KPiAgIG1pc3Rha2UgdG8gc3RhcnQgYSBuZXcgc2lsbyBvZiBhcHBs aWNhdGlvbiBwcm90b2NvbHMgdGhhdCBkbyBub3QNCj4gICBiZW5lZml0IGZyb20gZXhpc3Rpbmcg YXBwbGljYXRpb24gYXJlYSBJbnRlcm5ldCBleHBlcmllbmNlLg0KPg0KPiBBdCBJRVRGNzUsIHdl IHdpbGwgaG9sZCBhIEJhciBCT0YgdG8gc2NvcGUgb3V0IHBvc3NpYmxlIElFVEYgd29yayAgDQo+ IGFuZCBtYXliZSBmb3JtIGFuIG9waW5pb24gb24gd2hpY2ggcGFydCBzaG91bGQgYmUgZG9uZSBp biB3aGljaCBJRVRGICANCj4gYXJlYS4NCj4NCj4gVGVudGF0aXZlIGluZm9ybWF0aW9uIGlzIGF0 IGh0dHA6Ly91Lm51LzZqZmggPQ0KPiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL2Fw cC90cmFjL3dpa2kvQmFyQm9mcy9JRVRGNzUvNkxvd0FwcA0KPiAoYW5kIHlvdSBhcmUgd2VsY29t ZSB0byBjb250cmlidXRlIHRvIHRoaXMgV2lraSBwYWdlKS4NCj4NCj4gLT4gUGxlYXNlIHRlbGwg dXMgd2hldGhlciB0aGUgZW52aXNhZ2VkIGRhdGUgYW5kIHRpbWUgb2YgLT5UdWUgIA0KPiAxODoz MDwtIHdpbGwgd29yayBmb3IgeW91IQ0KPg0KPiBBIGZpcnN0IHZlcnNpb24gb2YgYSBwcm9ibGVt IHN0YXRlbWVudCAod2hlcmUgdGhlIGFib3ZlIHBhcmFncmFwaCAgDQo+IHdhcyBzdG9sZW4gZnJv bSkgaXMgYXQ6DQo+DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC82bG93YXBwDQo+IChkcmFm dC1ib3JtYW5uLTZsb3dwYW4tNmxvd2FwcC1wcm9ibGVtLTAwLnR4dCkNCj4NCj4gSSB3aWxsIHN0 YXJ0IHBsYW5uaW5nIGFuIGFnZW5kYSBmb3IgdGhlIEJhciBCT0Ygc29vbiwgc28gaWYgeW91IGhh dmUgIA0KPiBzb21ldGhpbmcgdG8gc2F5IHRoYXQgd291bGQgaGVscCBpbiB0aGlzIGNvbnZlcnNh dGlvbiwgcGxlYXNlIHRlbGwgIA0KPiBtZSAod2l0aCBhbiBlc3RpbWF0ZWQgYW1vdW50IG9mIHRp bWUpLg0KPg0KPiBHcnVlc3NlLCBDYXJzdGVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From mnot@mnot.net Mon Jul 13 23:50:21 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5D1428C104; Mon, 13 Jul 2009 23:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-2.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VgieoThPN6Q; Mon, 13 Jul 2009 23:50:20 -0700 (PDT) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id 2E3C93A6A12; Mon, 13 Jul 2009 23:50:20 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.249.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 615C323E3F6; Tue, 14 Jul 2009 02:50:08 -0400 (EDT) Message-Id: <67A2DAF1-C803-4372-A7DC-C40AF402BFD8@mnot.net> From: Mark Nottingham To: Peter Saint-Andre In-Reply-To: <4A5B7ECB.6010800@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [hybi] HyBi Bar BoF Date: Tue, 14 Jul 2009 16:49:32 +1000 References: <4A4E30E0.7060203@ericsson.com> <4A523D5C.4060100@stpeter.im> <7DF3CF53-1104-40A7-8256-66F7F252D904@mnot.net> <4A5B70BF.8050903@ericsson.com> <4A5B7ECB.6010800@stpeter.im> X-Mailer: Apple Mail (2.935.3) Cc: hybi@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 06:50:22 -0000 I've created a Wiki placeholder: http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75/HyBi Please populate! On 14/07/2009, at 4:36 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/13/09 11:37 AM, Salvatore Loreto wrote: >> >> here a possibility, >> >> - HyBi Breakfast BoF on Thursday 30 July, 07:30 - ? >> - Where: TBD > > That works for. Plus the httpbis session is on Thursday so I hope > we'll > have lots of HTTP people available on that morning. :) > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkpbfssACgkQNL8k5A2w/vwMEwCglqi61IIFlyVa2jWcX0Bmthv0 > pHwAoMJzOdGB/Xmwxt9T+QyHtKbGNsg8 > =QZCy > -----END PGP SIGNATURE----- -- Mark Nottingham http://www.mnot.net/ From alexey.melnikov@isode.com Tue Jul 14 03:39:48 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028B828C108 for ; Tue, 14 Jul 2009 03:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib0O+1ZWwZYX for ; Tue, 14 Jul 2009 03:39:47 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D8F0B28C188 for ; Tue, 14 Jul 2009 03:39:42 -0700 (PDT) Received: from [172.16.2.195] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 14 Jul 2009 11:34:31 +0100 Message-ID: <4A5C5F10.6050207@isode.com> Date: Tue, 14 Jul 2009 11:33:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org Subject: Re: Request for discussion topics for the Apps Area meeting in Stockholm References: <4A527630.4070509@isode.com> In-Reply-To: <4A527630.4070509@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 10:39:48 -0000 I hope I captured all requests. Please let me know if anything is missing. Alexey Melnikov wrote: > Please let Lisa and myself know if you would like to talk about any > particular topic. > So far I've seen the following requests (in no particular order): > > Barry Leiba : SMTP Service Extension for > Message Recall (draft-leiba-morg-message-recall-00.txt) > Cyrus Daboo : Timezone IANA registry and protocol > Michael Tuexen : Running application layer > protocols over SCTP > Iljitsch van Beijnum : FTP Application Layer > Gateway for IPv6-to-IPv4 translation Additional presentations requested: Carsten Bormann : 6lowapp bar BOF Peter Saint-Andre : OAuth WG status report Fred Baker : HTTP over SCTP Dan Wing : Successful Introduction of New Technology to HTTP Julian Reschke on behalf of Mark Nottingham: Link header and Host Metadata for the Web drafts Other possible topics for discussion: Review of OGPX BOF and planned Bar BOFs. Proposed "Abuse Report Format" WG > Please let me know if I forgot about some topics, or if a name of a > particular presentation is not correct. From shinta@sfc.wide.ad.jp Tue Jul 14 04:04:58 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1D73A67F4 for ; Tue, 14 Jul 2009 04:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.822 X-Spam-Level: * X-Spam-Status: No, score=1.822 tagged_above=-999 required=5 tests=[AWL=0.918, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYa5AytVW7-4 for ; Tue, 14 Jul 2009 04:04:57 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 980DA3A672F for ; Tue, 14 Jul 2009 04:04:57 -0700 (PDT) Received: from localhost.localdomain (unknown [IPv6:2001:380:633:2:20b:cdff:fefb:2a8]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 741BD4CC4D for ; Tue, 14 Jul 2009 19:33:29 +0900 (JST) Message-ID: <4A5C5CE3.6090200@sfc.wide.ad.jp> Date: Tue, 14 Jul 2009 19:24:35 +0900 From: Shinta Sugimoto User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: [Fwd: I-D Action:draft-ietf-shim6-multihome-shim-api-09.txt] Content-Type: multipart/mixed; boundary="------------090405070107080107000807" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 11:04:58 -0000 This is a multi-part message in MIME format. --------------090405070107080107000807 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Dear all, Let me inform you that we have submitted an internet-draft titled "Socket Application Program Interface (API) for Multihoming Shim". We would very much appreciate any kind of feedbacks. Thank you! URL to the draft: http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-09.txt Regards, Shinta --------------090405070107080107000807 Content-Type: message/rfc822; name="I-D Action:draft-ietf-shim6-multihome-shim-api-09.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="I-D Action:draft-ietf-shim6-multihome-shim-api-09.txt.eml" X-Account-Key: account2 X-Mozilla-Keys: Return-Path: X-Original-To: shinta@sfc.wide.ad.jp Received: from ironport1.sfc.wide.ad.jp (ironport1.sfc.wide.ad.jp [203.178.142.150]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPS id 65B7A4CDA9; Mon, 13 Jul 2009 14:31:11 +0900 (JST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQBADZjWkpAqmIglGdsb2JhbACYBil5AQEBAQkLCAkTBbANhAkFgT0 X-IronPort-AV: E=Sophos;i="4.42,388,1243782000"; d="txt'208?scan'208,208";a="4157126" Received: from mail.ietf.org ([64.170.98.32]) by ironport1.sfc.wide.ad.jp with ESMTP; 13 Jul 2009 14:31:10 +0900 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C00C3A6968; Sun, 12 Jul 2009 22:30:05 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4199C3A6920; Sun, 12 Jul 2009 22:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-shim6-multihome-shim-api-09.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713053002.4199C3A6920@core3.amsl.com> Date: Sun, 12 Jul 2009 22:30:02 -0700 (PDT) Cc: shim6@psg.com X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming by IPv6 Intermediation Working Group of the IETF. Title : Socket Application Program Interface (API) for Multihoming Shim Author(s) : M. Komu, et al. Filename : draft-ietf-shim6-multihome-shim-api-09.txt Pages : 41 Date : 2009-07-12 This document specifies sockets API extensions for the multihoming shim layer. The API aims to enable interactions between applications and the multihoming shim layer for advanced locator management, and access to information about failure detection and path exploration. This document is based on an assumption that a multihomed host is equipped with a conceptual sub-layer (hereafter "shim") inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are SHIM6 and HIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-shim6-multihome-shim-api-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-12222649.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --------------090405070107080107000807-- From dwing@cisco.com Wed Jul 15 09:01:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4893A6EC1 for ; Wed, 15 Jul 2009 09:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFSPvlXE+ioO for ; Wed, 15 Jul 2009 09:01:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 18D6E3A6EA3 for ; Wed, 15 Jul 2009 09:01:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,405,1243814400"; d="scan'208";a="347211098" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Jul 2009 15:54:04 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6FFs4mC007611; Wed, 15 Jul 2009 08:54:04 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6FFs3db027876; Wed, 15 Jul 2009 15:54:04 GMT From: "Dan Wing" To: Subject: Successfully deploying IPv6 and SCTP with HTTP, draft-wing-http-new-tech-00 Date: Wed, 15 Jul 2009 08:54:03 -0700 Message-ID: <112001ca0564$7a711420$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoFZHob2vYrMQAxRqig9tcO1N9NMg== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1871; t=1247673244; x=1248537244; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20Successfully=20deploying=20IPv6=20and=20SCTP=20 with=20HTTP,=20draft-wing-http-new-tech-00 |Sender:=20; bh=AucNX+L79L4V1AYBjn1qERM6eCxPhQb5meCGyDaFOBQ=; b=ROnkmkduBP5O58eA7ve9vQmpJ+rQrLAwf77Rd2svCCPl7boK9OIhOva8iE W4/EWnsUQnwsFTj+I/O2mFz4HZd/0KzLwQkqgJsjetymxUhG9q6moDj6/Cdk 3zZrQnk2z+Y+YVmjDCDr5LvSFL+k3nDt/lzg8uGUXWoHdyIOAm03c=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "'Preethi Natarajan \(prenatar\)'" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 16:01:15 -0000 Until new technologies are well-established and working well, there are times when the old technology works better. We see this in real life when unleaded gasoline and diesel cars were introduced (before ubiquitous availability of appropriate fueling stations). We see this with IPv6 where content providers are reluctant to put AAAA on their primary domain because it harms the user experience for some users -- users with poorly-functioning IPv6 connectivity. As we have all seen, many workarounds for IPv6 connectivity problems say "disable IPv6". Such workarounds are unhelpful, but the underlying problem remains: when users enable IPv6, their user experience is often degraded due to poorly-performing tunnels, broken IPv6 connectivity, or other reasons. Replacing HTTP's reliance on TCP with SCTP suffers a similar fate, but SCTP doesn't even have the benefit of a DNS record to indicate the server is listening for incoming SCTP connections. Taking ideas from ICE, draft-nward-6to4-qualification, Stuart Cheshire's comments a few IETFs ago, and other places, we have recently published an I-D that proposes a way around this impasse and allows browsers to support IPv6 and to support SCTP with very little noticable impact to the end user's experience. This is accomplished by having the web browser attempt to use IPv4, IPv6, SCTP, and TCP, with suggested delays and caching to offset the impact to the network and to the servers. With such a change, the end user's incentive to disable IPv6 or disable SCTP is significantly reduced. Our I-D is available at http://tools.ietf.org/html/draft-wing-http-new-tech-00 We have requested agenda time at the APPAREA meeting on Monday, but would like to initiate discussion before IETF75 on the APPAREA mailing list. Thanks, -Dan Wing Andrew Yourtchenko Preethi Natarajan From wmaton@ryouko.imsb.nrc.ca Wed Jul 15 13:20:14 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A92033A6808 for ; Wed, 15 Jul 2009 13:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtBy15sZTVqA for ; Wed, 15 Jul 2009 13:20:13 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2001:410:9000:127::10]) by core3.amsl.com (Postfix) with ESMTP id 98FF13A63CB for ; Wed, 15 Jul 2009 13:20:13 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.3/8.14.3) with ESMTP id n6FKKP5H006403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jul 2009 16:20:30 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.3/8.14.3/Submit) with ESMTP id n6FKKOA9006396; Wed, 15 Jul 2009 16:20:25 -0400 Date: Wed, 15 Jul 2009 16:20:24 -0400 (EDT) From: "William F. Maton Sotomayor" To: John C Klensin Subject: Re: Interest in reviving WG on FTP(maybe ext?) In-Reply-To: <45CD4EB44CDFB32F772D8D6E@PST.JCK.COM> Message-ID: References: <000701ca0178$c300e700$0601a8c0@allison> <45CD4EB44CDFB32F772D8D6E@PST.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:20:14 -0000 Hi John, On Fri, 10 Jul 2009, John C Klensin wrote: > With the understanding that I have been, and remain, sympathetic > to getting a WG spun up if there is interest, the conclusion in > Dublin and elsewhere was that there really wasn't critical mass > to do this. Critical mass would require people who were willing > to actually work on, review, and, where appropriate, implement > each other's documents, not just present ideas and hope that Thanks for the update. At least there's closure on that aspect of it. > others sign off. There have been a number of drafts posted > relevant to FTP. Some seems obvious to me (like the extension > registry), others may be seriously bad ideas, and most lie > somewhere in between. I've seen a number of them over the year's on various websites and snarfed a few for posterity. Agreed, some of them are good ideas. I'd like to see your's revived as I just went through this exercise myself to figure out what's missing from wu-ftpd versus what's new. Hmmm....I should post the result of that script output somewhere. (Good idea, maybe it will form the basis of your missing section.) > If that critical mass exists, then someone needs to get to work > on a charter, perhaps using the one that a couple of us put > together a year ago as a starting point. If it doesn't, then > writing and posting more FTP extension drafts is probably a > waste of time -- given the number of proposals, if there isn't A couple of people I have contacted are interested in putting in more proposals, and implementations seem to exist for at least one of them: - gridFTP, for extensions involving bulk transfers of scientific data - David Somers has one with a few extensions that some other FTP implementors seem to be pushing ahead with. > enough interest to put a WG together, then it would be hard to > argue that there is sufficient interest in FTP extensions in the > community to justify standardizing anything. > > That is just my opinion, but I think it is a reasonable summary > of where things stood a year ago. I'm not convinced that > anything has changed. Thanks John, much appreciated. I don't know how many here are of the FTP slant, but I'm sure others could be asked beyond that to solicit further interest down the road. I would expect that process itself to take some time too. wfms From wmaton@ryouko.imsb.nrc.ca Wed Jul 15 13:35:13 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3E73A6B30 for ; Wed, 15 Jul 2009 13:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wNrvhUYjsW4 for ; Wed, 15 Jul 2009 13:35:12 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2001:410:9000:127::10]) by core3.amsl.com (Postfix) with ESMTP id 98C653A6995 for ; Wed, 15 Jul 2009 13:35:12 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.3/8.14.3) with ESMTP id n6FKZSRF008515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jul 2009 16:35:33 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.3/8.14.3/Submit) with ESMTP id n6FKZSbQ008512; Wed, 15 Jul 2009 16:35:28 -0400 Date: Wed, 15 Jul 2009 16:35:28 -0400 (EDT) From: "William F. Maton Sotomayor" To: Iljitsch van Beijnum Subject: Re: Interest in reviving WG on FTP(maybe ext?) In-Reply-To: <500C2305-B995-4628-A6C9-C758771D5B35@muada.com> Message-ID: References: <000701ca0178$c300e700$0601a8c0@allison> <45CD4EB44CDFB32F772D8D6E@PST.JCK.COM> <500C2305-B995-4628-A6C9-C758771D5B35@muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:35:13 -0000 On Wed, 15 Jul 2009, Iljitsch van Beijnum wrote: > Well, I think I found a bug in RFC 959. Might be nice to fix it. OK, now some are getting shaken out, that's good. :-) I know Gregory Lundberg found a bunch of issues, some great, some small with RFC 959, and he was in touch with some folks at that time (we're talking around a decade now) about that. But where that conversation went....? > 3.3. DATA CONNECTION MANAGEMENT > [..] > However, you can't use both PORT and PASV because with PORT the server is > supposed to initiate the data session and with PASV the client. If you do > both it's unclear who does what. I also don't see any use cases for this. This rings a bell....I wonder if it was the old data assurance draft that also addressed this.... Thanks, now you got me rumaging.... :-) wfms From iljitsch@muada.com Wed Jul 15 13:50:21 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5863B3A6808 for ; Wed, 15 Jul 2009 13:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vn1FDr+C2atV for ; Wed, 15 Jul 2009 13:50:19 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id B2BE13A6995 for ; Wed, 15 Jul 2009 13:50:18 -0700 (PDT) Received: from [192.168.2.4] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n6FKOMbr051679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jul 2009 22:24:23 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <500C2305-B995-4628-A6C9-C758771D5B35@muada.com> From: Iljitsch van Beijnum To: wmaton@ryouko.imsb.nrc.ca In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Interest in reviving WG on FTP(maybe ext?) Date: Wed, 15 Jul 2009 22:24:24 +0200 References: <000701ca0178$c300e700$0601a8c0@allison> <45CD4EB44CDFB32F772D8D6E@PST.JCK.COM> X-Mailer: Apple Mail (2.935.3) Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:50:21 -0000 On 15 jul 2009, at 22:20, William F. Maton Sotomayor wrote: > I don't know how many here are of the FTP slant, Well, I think I found a bug in RFC 959. Might be nice to fix it. 3.3. DATA CONNECTION MANAGEMENT Default Data Connection Ports: All FTP implementations must support use of the default data connection ports, and only the User-PI may initiate the use of non-default ports. Negotiating Non-Default Data Ports: The User-PI may specify a non-default user side data port with the PORT command. The User-PI may request the server side to identify a non-default server side data port with the PASV command. Since a connection is defined by the pair of addresses, either of these actions is enough to get a different data connection, still it is permitted to do both commands to use new ports on both ends of the data connection. However, you can't use both PORT and PASV because with PORT the server is supposed to initiate the data session and with PASV the client. If you do both it's unclear who does what. I also don't see any use cases for this. From john-ietf@jck.com Wed Jul 15 15:08:12 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722D93A6C26 for ; Wed, 15 Jul 2009 15:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVbIjU1YCHtL for ; Wed, 15 Jul 2009 15:08:11 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 1DA8A3A68D2 for ; Wed, 15 Jul 2009 15:08:11 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MRCbb-000GyG-Lt; Wed, 15 Jul 2009 18:05:40 -0400 Date: Wed, 15 Jul 2009 18:05:38 -0400 From: John C Klensin To: wmaton@ryouko.imsb.nrc.ca Subject: Re: Interest in reviving WG on FTP(maybe ext?) Message-ID: In-Reply-To: References: <000701ca0178$c300e700$0601a8c0@allison> <45CD4EB44CDFB32F772D8D6E@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========6FA5C248B3EF39C09DEE==========" Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 22:08:12 -0000 --==========6FA5C248B3EF39C09DEE========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline --On Wednesday, July 15, 2009 16:20 -0400 "William F. Maton Sotomayor" wrote: >... >> others sign off. There have been a number of drafts posted >> relevant to FTP. Some seems obvious to me (like the extension >> registry), others may be seriously bad ideas, and most lie >> somewhere in between. > > I've seen a number of them over the year's on various websites > and snarfed a few for posterity. Agreed, some of them are > good ideas. I'd like to see your's revived as I just went > through this exercise myself to figure out what's missing from > wu-ftpd versus what's new. Hmmm....I should post the result > of that script output somewhere. (Good idea, maybe it will > form the basis of your missing section.) > >> If that critical mass exists, then someone needs to get to >> work on a charter, perhaps using the one that a couple of us >> put together a year ago as a starting point. If it doesn't, >> then writing and posting more FTP extension drafts is >> probably a waste of time -- given the number of proposals, if >> there isn't > > A couple of people I have contacted are interested in putting > in more proposals, and implementations seem to exist for at > least one of them: One of the ways of interpreting the Dublin discussion (probably not the only one) is that we really should have multiple implementations. In other words, clear intent by multiple parties to implement a particular idea (or who have done it already) is evidence of sufficient interest to restart IETF work. Someone pushing any idea that is either untested or that only they care to implement doesn't count. >... > Thanks John, much appreciated. I don't know how many here are > of the FTP slant, but I'm sure others could be asked beyond > that to solicit further interest down the road. I would > expect that process itself to take some time too. Let me suggest the following plan. First, it is really too late to do anything in Stockholm. We might try to organize a Bar-BOF, but, given scheduling, etc., and people who may or may not be in Stockholm, it is probably late even for that. Let's try to think about getting things together sufficiently well before Hiroshima (or, if people prefer due to location, Anaheim in March) that we can do a useful pre-WG BOF or even have a WG proposal in front of the IESG before one of those meetings. One warning is that I'm happy to offer advice and support, but should not be counted on for much serious work in this area in the near term (although I can do some work on my two documents if desired). In the meantime, in the hope that this is agreeable to the ADs: (1) I will forward in a few minutes my notes and Lisa's from before the Dublin meeting a year ago. That should help everyone get synchronized even those most of the drafts are now expired. (2) If people convince me, ideally before the end of the Stockholm meeing, that there really is interest in moving forward, I'll update the extension registry spec and get it in front of the IESG as an individual submission. It should be routine and should not require a WG. I'll modify the proposal so that the registry entries can provide some information about state of implementation and by whom, which should help inform a BOF or WG development process. (3) My notes indicate that a couple of us started on a draft charter for a working group last October, before the effort ran out of steam. I'm attaching a copy of it, with the understanding that the dates and some of the comments may be irrelevant by now. The intent is just to give people some calibration about how we've thought about the topic in the past and maybe some text to think about in starting to form a charter or BOF proposal. john --==========6FA5C248B3EF39C09DEE========== Content-Type: text/plain; charset=utf-8; name="ftp-charter-20081031.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ftp-charter-20081031.txt"; size=1886 File Transfer Protocol Extensions (ftpext) Last Modified: 2008-10-30 (JcK, preliminary draft) Chair(s): # To be determined Applications Area Director(s): # Chris Newman # Lisa Dusseault Applications Area Advisor: # To be determined Mailing Lists: General Discussion: To be determined To Subscribe: To be determined Archive: To be determined Description of Working Group: The Standard File Transfer Protocol specification in RFC 959 has = been updated several times with command extensions of one sort or = another, including those described in RFCs 2228, 2640, 2773, and 3659. In = the last year or so, a series of additional Internet Drafts (listed = below) have been posted. This WG will examine the outstanding = proposals, determine which ones are worth pursuing, and bring the relevant = ones to Proposed Standard or, if more appropriate, Experimental. If time and energy permit, the WG will also review the Proposed Standard specifications identified above, revise and advance = them to Draft Standard as appropriate, and review and, if needed, = update, the FTP URI specifications. Goals and Milestones: January 2008 WG formation March 2009 Decision on form and structure of the WG document set, including which documents will be addressed.=20 June 2009 WG Last Call on WG document set August 2009 IETF Last Call on WG document set Internet-Drafts: Streamlined FTP Command Extensions draft-peterson-streamlined-ftp-command-extensions-05.txt FTP Extension for Internationalized Text draft-klensin-ftp-typeu-00.txt FTP Extension Registry draft-klensin-ftp-registry-00.txt File Transfer Protocol HOST Command draft-hethmon-mcmurray-ftp-hosts-01 FTP Extension Allowing IP Forwarding (NATs) draft-rosenau-ftp-single-port-04 No Request For Comments --==========6FA5C248B3EF39C09DEE==========-- From john-ietf@jck.com Wed Jul 15 15:10:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB7D13A6F4A for ; Wed, 15 Jul 2009 15:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtqNjh7ejAkl for ; Wed, 15 Jul 2009 15:10:56 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 3DA2F3A6F3E for ; Wed, 15 Jul 2009 15:10:56 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MRCfm-000HA7-D2 for apps-discuss@ietf.org; Wed, 15 Jul 2009 18:09:59 -0400 Date: Wed, 15 Jul 2009 18:09:56 -0400 From: John C Klensin To: apps-discuss@ietf.org Subject: Re: Interest in reviving WG on FTP(maybe ext?) Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========54E3A0C1A66145FB9DBB==========" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 22:10:57 -0000 --==========54E3A0C1A66145FB9DBB========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline As promised, I'm attaching my note and Lisa's from before Dublin. The existence of work on a charter at the end of October indicates that there may have been some further discussion in Minneapolis (IETF 73) but I have no recollection of any substantive decisions. john --==========54E3A0C1A66145FB9DBB========== Content-Type: message/rfc822; name="Re: FTP protocol extensions and updates" Return-path: Envelope-to: john-ietf@jck.com Delivery-date: Wed, 16 Jul 2008 14:43:51 -0400 Received: from [64.170.98.32] (helo=mail.ietf.org) by bs.jck.com with esmtp (Exim 4.34) id 1KJByg-00045J-Ob for john-ietf@jck.com; Wed, 16 Jul 2008 14:43:51 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10C93A6844; Wed, 16 Jul 2008 11:42:44 -0700 (PDT) X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D25E3A6844 for ; Wed, 16 Jul 2008 11:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.024 X-Spam-Level: X-Spam-Status: No, score=-107.024 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMIWT2f0C69n for ; Wed, 16 Jul 2008 11:42:43 -0700 (PDT) Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by core3.amsl.com (Postfix) with ESMTP id 2F8F33A67B5 for ; Wed, 16 Jul 2008 11:42:40 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 09483142206; Wed, 16 Jul 2008 11:43:10 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ws+t+ea41nU5; Wed, 16 Jul 2008 11:43:00 -0700 (PDT) Received: from [10.1.1.142] (corp.collabrx.com [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D5BA914220E; Wed, 16 Jul 2008 11:42:59 -0700 (PDT) Message-Id: <6C66E5BB-6582-4AE5-9409-0438F7BC255B@osafoundation.org> From: Lisa Dusseault To: apps-discuss@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: FTP protocol extensions and updates Date: Wed, 16 Jul 2008 11:42:59 -0700 References: <2A738A9E34659851081D5C0D@p3.JCK.COM> <6.0.0.20.2.20080712164945.0968a0a0@localhost> X-Mailer: Apple Mail (2.926) Cc: douglas.papenthien@rhinosoft.com, mark.peterson@rhinosoft.com, martin@rosenau-ka.de, dsomers@omz13.com, robmcm@microsoft.com X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org The Apparea open meeting will have some time allocated to discuss FTP extensions -- Monday July 28 at 9:00 am in Dublin. John Klensin suggested the topic so I've asked him to be on the hook for leading those 10 or more minutes. We'll be discussing what work needs to be done on FTP and for what deployed communities (e.g. what extent), and if the conclusion is that the IETF needs to do some work we may even get to discussing how. Current, unexpired I-Ds relating to FTP: http://tools.ietf.org/html/draft-peterson-streamlined-ftp-command-extensions-05 http://tools.ietf.org/html/draft-hethmon-mcmurray-ftp-hosts-01 http://tools.ietf.org/html/draft-rosenau-ftp-single-port-04 As always, meeting attendees are expected to read meeting documents before getting to the meeting! Advance discussion on this list is very welcome. Lisa On Jul 12, 2008, at 10:24 AM, Frank Ellermann wrote: > Martin Duerst wrong: > >> John has mentioned a long list, is that what you thought about > > Yes, I think he saw more points then I saw, and I wasn't sure if > he proposed an effort to get a 2640bis as DS, or something else. > > I never before looked into this RFC, I checked the four "updated > by" in RFC 959, after looking in Paul's last ftp URI draft. Any > 0xFF in memos about telnet / ftp / UTF-8 attracts my attention, > once bitten... > > Frank > > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --==========54E3A0C1A66145FB9DBB========== Content-Type: message/rfc822; name="FTP protocol extensions and updates" Return-path: Envelope-to: john-ietf@jck.com Delivery-date: Fri, 11 Jul 2008 13:32:40 -0400 Received: from [64.170.98.32] (helo=mail.ietf.org) by bs.jck.com with esmtp (Exim 4.34) id 1KHMU3-0004y5-VC for john-ietf@jck.com; Fri, 11 Jul 2008 13:32:40 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8002D3A6A38; Fri, 11 Jul 2008 10:31:45 -0700 (PDT) X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC763A67D9 for ; Fri, 11 Jul 2008 10:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csbXSyJj7c7Z for ; Fri, 11 Jul 2008 10:31:43 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 1B8D53A692B for ; Fri, 11 Jul 2008 10:31:43 -0700 (PDT) Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KHMTQ-0004xO-AF; Fri, 11 Jul 2008 13:32:00 -0400 Date: Fri, 11 Jul 2008 13:31:59 -0400 From: John C Klensin To: apps-discuss@ietf.org Subject: FTP protocol extensions and updates Message-ID: <2A738A9E34659851081D5C0D@p3.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Disposition: inline Cc: douglas.papenthien@rhinosoft.com, "Mark P. Peterson" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Subject: FTP Extensions and Updates Hi. We have proposals for a number of FTP extensions at various places in the queue, including draft-peterson-streamlined-ftp-command-extensions-04 and the long-overdue "TYPE U" proposal that was the original impetus for what is now RFC 5198. I have first-draft I-Ds for TYPE U and for an IANA registry for FTP Extensions ready to go up as soon as the pre-IETF blackout window closes. The question now is how people would like to process these extensions. Mark Peterson and Doug Papenthien think their document is just about ready to go and have implementation and running code for its features. "TYPE U" is essentially trivial now that the format itself is defined. If enough people are interested, it might be sensible to move toward a (hopefully short-lived) WG. If not, it would probably make sense to handle them as individual submissions, probably folding the substance of my two documents into draft-peterson... in the hope of handling everything through one Last Call. FWIW, I don't have any particular personal investment in any of this. The "TYPE U" document was prepared as the last step of what I seem to have volunteered for when I started the Unicode stream discussion several years ago and the registry document was started because it seemed to be the right thing to do. If people decide they want a WG, I will be looking for someone who wants to take over or share editing responsibilities on the two new drafts. If it is ok with Chris and Lisa, and especially if anyone has opinions in the interim, I'd like to spend a couple of minutes on FTP strategy at the Apps Area meeting. john _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --==========54E3A0C1A66145FB9DBB==========-- From mnot@mnot.net Wed Jul 15 23:24:55 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3633A68ED for ; Wed, 15 Jul 2009 23:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[AWL=-2.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXOI5uheOi+N for ; Wed, 15 Jul 2009 23:24:54 -0700 (PDT) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id 951EF3A67F1 for ; Wed, 15 Jul 2009 23:24:54 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.249.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EB9A223E3E8 for ; Thu, 16 Jul 2009 02:24:06 -0400 (EDT) Message-Id: From: Mark Nottingham To: apps-discuss@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Fwd: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard Date: Thu, 16 Jul 2009 16:24:06 +1000 References: <20090714153141.493B43A6F00@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 06:24:55 -0000 FYI Begin forwarded message: > From: The IESG > Date: 15 July 2009 1:31:40 AM > To: IETF-Announce > Subject: Last Call: draft-nottingham-http-link-header (Web Linking) > to Proposed Standard > Reply-To: ietf@ietf.org > > The IESG has received a request from an individual submitter to > consider > the following document: > > - 'Web Linking ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2009-08-11. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-06.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14833&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce -- Mark Nottingham http://www.mnot.net/ From alexey.melnikov@isode.com Fri Jul 17 12:51:50 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751F03A6A2F for ; Fri, 17 Jul 2009 12:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvyIoOsJ2PSW for ; Fri, 17 Jul 2009 12:51:49 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 712573A690B for ; Fri, 17 Jul 2009 12:51:49 -0700 (PDT) Received: from [172.16.2.107] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 17 Jul 2009 20:52:22 +0100 Message-ID: <4A60D633.1090807@isode.com> Date: Fri, 17 Jul 2009 20:51:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org Subject: Agenda for the Apps Area meeting in Stockholm References: <4A527630.4070509@isode.com> <4A5C5F10.6050207@isode.com> In-Reply-To: <4A5C5F10.6050207@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 19:51:50 -0000 Here is the updated list of presentations. Please let me know if the list is correct and complete, and if the order and the length of sessions is Ok. We will have some time for discussions/questions, this time is not included below: Carsten Bormann : 6lowapp bar BOF [5 mins] Julian Reschke on behalf of Mark Nottingham: "Link header" and "Host Metadata for the Web" drafts [5 mins] Peter Saint-Andre : OAuth WG status report [5 mins] Barry Leiba(?): OGPX BOF [5 mins] Michael Tuexen : Running application layer protocols over SCTP [20 mins] Andrew Yourtchenko : Successful Introduction of New Technology to HTTP [20 mins] Alexey Melnikov : Vendor name registry for use in Application Protocols [5 mins] Cyrus Daboo : Timezone IANA registry and protocol [15 mins] Possible: Barry Leiba: Proposed "Abuse Report Format" WG [10 mins] Iljitsch van Beijnum : FTP Application Layer Gateway for IPv6-to-IPv4 translation [15 mins] Barry Leiba : SMTP Service Extension for Message Recall (draft-leiba-morg-message-recall-00.txt) [15 mins] Barry Leiba DRM proxies [5 mins] From julian.reschke@gmx.de Sat Jul 18 00:56:44 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A403A699C for ; Sat, 18 Jul 2009 00:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vl4a76pNdUlJ for ; Sat, 18 Jul 2009 00:56:43 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id F06CF3A696E for ; Sat, 18 Jul 2009 00:56:42 -0700 (PDT) Received: (qmail invoked by alias); 18 Jul 2009 07:56:39 -0000 Received: from p508FE471.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.228.113] by mail.gmx.net (mp048) with SMTP; 18 Jul 2009 09:56:39 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/3IuchwjL38kEu4pG7TsJLaaP9EG2CsHGFyK0OcC PDyKDqiHGVPT34 MIME-version: 1.0 From: julian.reschke@gmx.de To: apps-discuss@ietf.org Subject: Event Invitation: Agenda for the Apps Area meeting in Stockholm Content-type: multipart/mixed; boundary="Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ)" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.84 Message-Id: <20090718075642.F06CF3A696E@core3.amsl.com> Date: Sat, 18 Jul 2009 00:56:42 -0700 (PDT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 07:56:44 -0000 --Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ) Content-type: multipart/alternative; boundary="Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA)" --Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT Julian Reschke has invited you to Agenda for the Apps Area meeting in Stockholm --Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA) Content-type: text/calendar; method=REQUEST; charset=UTF-8 Content-transfer-encoding: 8BIT BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/Berlin X-LIC-LOCATION:Europe/Berlin BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10 END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20090718T075618Z LAST-MODIFIED:20090718T075628Z DTSTAMP:20090718T075628Z UID:8280b76f-d75a-4729-a325-152ca0435e9a SUMMARY:Agenda for the Apps Area meeting in Stockholm ORGANIZER;RSVP=FALSE;CN=Julian Reschke;PARTSTAT=ACCEPTED; ROLE=REQ-PARTICIPANT:mailto:julian.reschke@gmx.de ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto: apps-discuss@ietf.org DTSTART;TZID=Europe/Berlin:20090720T100000 DTEND;TZID=Europe/Berlin:20090720T110000 DESCRIPTION:\nHere is the updated list of presentations. Please let me know if the \nlist is correct and complete\, and if the order and the length of \nsessions is Ok. We will have some time for discussions/questions\, this \ntime is not included below:\n\nCarsten Bormann : 6lowapp bar BOF [5 mins]\nJulian Reschke on behalf of Mark \nNottingham: \"Link header\" and \"Host Metadata for the Web\" drafts [5 mins]\nPeter Saint-Andre : OAuth WG status report [5 mins]\nBarry Leiba(?): OGPX BOF [5 mins]\nMichael Tuexen : Running application layer \nprotocols over SCTP [20 mins]\nAndrew Yourtchenko : Successful Introduction of New \nTechnology to HTTP [20 mins]\nAlexey Melnikov : Vendor name registry for \nuse in Application Protocols [5 mins]\nCyrus Daboo : Timezone IANA registry and protocol [15 \nmins]\nPossible: Barry Leiba: Proposed \"Abuse Report Format\" WG [10 mins]\nIljitsch van Beijnum : FTP Application Layer Gateway \nfor IPv6-to-IPv4 translation [15 mins]\nBarry Leiba : SMTP Service Extension for \nMessage Recall (draft-leiba-morg-message-recall-00.txt) [15 mins]\nBarry Leiba DRM proxies [5 mins]\n\n_______________________________________________\nApps-Discuss mailing list\nApps-Discuss@ietf.org\nhttps: //www.ietf.org/mailman/listinfo/apps-discuss\n\n SEQUENCE:0 END:VEVENT END:VCALENDAR --Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA)-- --Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ) Content-type: application/ics; name=invite.ics Content-transfer-encoding: 8BIT Content-disposition: attachment; filename=invite.ics BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/Berlin X-LIC-LOCATION:Europe/Berlin BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10 END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20090718T075618Z LAST-MODIFIED:20090718T075628Z DTSTAMP:20090718T075628Z UID:8280b76f-d75a-4729-a325-152ca0435e9a SUMMARY:Agenda for the Apps Area meeting in Stockholm ORGANIZER;RSVP=FALSE;CN=Julian Reschke;PARTSTAT=ACCEPTED; ROLE=REQ-PARTICIPANT:mailto:julian.reschke@gmx.de ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto: apps-discuss@ietf.org DTSTART;TZID=Europe/Berlin:20090720T100000 DTEND;TZID=Europe/Berlin:20090720T110000 DESCRIPTION:\nHere is the updated list of presentations. Please let me know if the \nlist is correct and complete\, and if the order and the length of \nsessions is Ok. We will have some time for discussions/questions\, this \ntime is not included below:\n\nCarsten Bormann : 6lowapp bar BOF [5 mins]\nJulian Reschke on behalf of Mark \nNottingham: \"Link header\" and \"Host Metadata for the Web\" drafts [5 mins]\nPeter Saint-Andre : OAuth WG status report [5 mins]\nBarry Leiba(?): OGPX BOF [5 mins]\nMichael Tuexen : Running application layer \nprotocols over SCTP [20 mins]\nAndrew Yourtchenko : Successful Introduction of New \nTechnology to HTTP [20 mins]\nAlexey Melnikov : Vendor name registry for \nuse in Application Protocols [5 mins]\nCyrus Daboo : Timezone IANA registry and protocol [15 \nmins]\nPossible: Barry Leiba: Proposed \"Abuse Report Format\" WG [10 mins]\nIljitsch van Beijnum : FTP Application Layer Gateway \nfor IPv6-to-IPv4 translation [15 mins]\nBarry Leiba : SMTP Service Extension for \nMessage Recall (draft-leiba-morg-message-recall-00.txt) [15 mins]\nBarry Leiba DRM proxies [5 mins]\n\n_______________________________________________\nApps-Discuss mailing list\nApps-Discuss@ietf.org\nhttps: //www.ietf.org/mailman/listinfo/apps-discuss\n\n SEQUENCE:0 END:VEVENT END:VCALENDAR --Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ)-- From julian.reschke@gmx.de Sat Jul 18 00:57:29 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A615B3A6F5F for ; Sat, 18 Jul 2009 00:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, GB_I_INVITATION=-2, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmAghMh23iKn for ; Sat, 18 Jul 2009 00:57:29 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9DA2F3A696E for ; Sat, 18 Jul 2009 00:57:28 -0700 (PDT) Received: (qmail invoked by alias); 18 Jul 2009 07:57:25 -0000 Received: from p508FE471.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.228.113] by mail.gmx.net (mp032) with SMTP; 18 Jul 2009 09:57:25 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+PAQw8SBuPCfeFsoipc2F8Rp6UtvI84pfYfOT3Pl Y8NliP2rtC6CqF MIME-version: 1.0 From: julian.reschke@gmx.de To: apps-discuss@ietf.org Subject: Event Invitation: Agenda for the Apps Area meeting in Stockholm Content-type: multipart/mixed; boundary="Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ)" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.84 Message-Id: <20090718075728.9DA2F3A696E@core3.amsl.com> Date: Sat, 18 Jul 2009 00:57:28 -0700 (PDT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 07:57:29 -0000 --Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ) Content-type: multipart/alternative; boundary="Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA)" --Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT Julian Reschke has invited you to Agenda for the Apps Area meeting in Stockholm --Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA) Content-type: text/calendar; method=REQUEST; charset=UTF-8 Content-transfer-encoding: 8BIT BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/Berlin X-LIC-LOCATION:Europe/Berlin BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10 END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20090718T075705Z LAST-MODIFIED:20090718T075715Z DTSTAMP:20090718T075715Z UID:58b5d032-4b9f-462b-a205-b3508b0da5d1 SUMMARY:Agenda for the Apps Area meeting in Stockholm ORGANIZER;RSVP=FALSE;CN=Julian Reschke;PARTSTAT=ACCEPTED; ROLE=REQ-PARTICIPANT:mailto:julian.reschke@gmx.de ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto: apps-discuss@ietf.org DTSTART;TZID=Europe/Berlin:20090720T100000 DTEND;TZID=Europe/Berlin:20090720T110000 DESCRIPTION:\nHere is the updated list of presentations. Please let me know if the \nlist is correct and complete\, and if the order and the length of \nsessions is Ok. We will have some time for discussions/questions\, this \ntime is not included below:\n\nCarsten Bormann : 6lowapp bar BOF [5 mins]\nJulian Reschke on behalf of Mark \nNottingham: \"Link header\" and \"Host Metadata for the Web\" drafts [5 mins]\nPeter Saint-Andre : OAuth WG status report [5 mins]\nBarry Leiba(?): OGPX BOF [5 mins]\nMichael Tuexen : Running application layer \nprotocols over SCTP [20 mins]\nAndrew Yourtchenko : Successful Introduction of New \nTechnology to HTTP [20 mins]\nAlexey Melnikov : Vendor name registry for \nuse in Application Protocols [5 mins]\nCyrus Daboo : Timezone IANA registry and protocol [15 \nmins]\nPossible: Barry Leiba: Proposed \"Abuse Report Format\" WG [10 mins]\nIljitsch van Beijnum : FTP Application Layer Gateway \nfor IPv6-to-IPv4 translation [15 mins]\nBarry Leiba : SMTP Service Extension for \nMessage Recall (draft-leiba-morg-message-recall-00.txt) [15 mins]\nBarry Leiba DRM proxies [5 mins]\n\n_______________________________________________\nApps-Discuss mailing list\nApps-Discuss@ietf.org\nhttps: //www.ietf.org/mailman/listinfo/apps-discuss\n\n TRANSP:OPAQUE SEQUENCE:0 END:VEVENT END:VCALENDAR --Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA)-- --Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ) Content-type: application/ics; name=invite.ics Content-transfer-encoding: 8BIT Content-disposition: attachment; filename=invite.ics BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/Berlin X-LIC-LOCATION:Europe/Berlin BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10 END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20090718T075705Z LAST-MODIFIED:20090718T075715Z DTSTAMP:20090718T075715Z UID:58b5d032-4b9f-462b-a205-b3508b0da5d1 SUMMARY:Agenda for the Apps Area meeting in Stockholm ORGANIZER;RSVP=FALSE;CN=Julian Reschke;PARTSTAT=ACCEPTED; ROLE=REQ-PARTICIPANT:mailto:julian.reschke@gmx.de ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto: apps-discuss@ietf.org DTSTART;TZID=Europe/Berlin:20090720T100000 DTEND;TZID=Europe/Berlin:20090720T110000 DESCRIPTION:\nHere is the updated list of presentations. Please let me know if the \nlist is correct and complete\, and if the order and the length of \nsessions is Ok. We will have some time for discussions/questions\, this \ntime is not included below:\n\nCarsten Bormann : 6lowapp bar BOF [5 mins]\nJulian Reschke on behalf of Mark \nNottingham: \"Link header\" and \"Host Metadata for the Web\" drafts [5 mins]\nPeter Saint-Andre : OAuth WG status report [5 mins]\nBarry Leiba(?): OGPX BOF [5 mins]\nMichael Tuexen : Running application layer \nprotocols over SCTP [20 mins]\nAndrew Yourtchenko : Successful Introduction of New \nTechnology to HTTP [20 mins]\nAlexey Melnikov : Vendor name registry for \nuse in Application Protocols [5 mins]\nCyrus Daboo : Timezone IANA registry and protocol [15 \nmins]\nPossible: Barry Leiba: Proposed \"Abuse Report Format\" WG [10 mins]\nIljitsch van Beijnum : FTP Application Layer Gateway \nfor IPv6-to-IPv4 translation [15 mins]\nBarry Leiba : SMTP Service Extension for \nMessage Recall (draft-leiba-morg-message-recall-00.txt) [15 mins]\nBarry Leiba DRM proxies [5 mins]\n\n_______________________________________________\nApps-Discuss mailing list\nApps-Discuss@ietf.org\nhttps: //www.ietf.org/mailman/listinfo/apps-discuss\n\n TRANSP:OPAQUE SEQUENCE:0 END:VEVENT END:VCALENDAR --Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ)-- From julian.reschke@gmx.de Sat Jul 18 01:09:35 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D50E3A6B06 for ; Sat, 18 Jul 2009 01:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.038 X-Spam-Level: X-Spam-Status: No, score=-4.038 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, GB_I_INVITATION=-2, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juWMNMyeVsqA for ; Sat, 18 Jul 2009 01:09:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1CB0F3A6F8D for ; Sat, 18 Jul 2009 01:09:23 -0700 (PDT) Received: (qmail invoked by alias); 18 Jul 2009 08:09:22 -0000 Received: from p508FE471.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.228.113] by mail.gmx.net (mp014) with SMTP; 18 Jul 2009 10:09:22 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+4qaFCOaK46YnbMmZfFjEL5l0rM86vlkR1re41d+ ZtCFMQ3hmXrDBy Message-ID: <4A618328.20504@gmx.de> Date: Sat, 18 Jul 2009 10:09:12 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Re: Event Invitation: Agenda for the Apps Area meeting in Stockholm References: <20090718075728.9DA2F3A696E@core3.amsl.com> In-Reply-To: <20090718075728.9DA2F3A696E@core3.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.84 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 08:09:35 -0000 julian.reschke@gmx.de wrote: > > > Event Invitation > > Title: > ... Sorry for the noise. BR, Julian From alexey.melnikov@isode.com Sat Jul 18 12:01:35 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AED53A696B; Sat, 18 Jul 2009 12:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yoi4fSJ+spNT; Sat, 18 Jul 2009 12:01:34 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A5D493A67FD; Sat, 18 Jul 2009 12:01:34 -0700 (PDT) Received: from [92.40.162.39] (92.40.162.39.sub.mbb.three.co.uk [92.40.162.39]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 18 Jul 2009 19:33:06 +0100 Message-ID: <4A61ACC3.3020806@isode.com> Date: Sat, 18 Jul 2009 12:06:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Salvatore Loreto Subject: Re: [hybi] HyBi Bar BoF References: <4A4E30E0.7060203@ericsson.com> <4A523D5C.4060100@stpeter.im> <7DF3CF53-1104-40A7-8256-66F7F252D904@mnot.net> <4A5B70BF.8050903@ericsson.com> In-Reply-To: <4A5B70BF.8050903@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 19:01:35 -0000 Salvatore Loreto wrote: > here a possibility, > > - HyBi Breakfast BoF on Thursday 30 July, 07:30 - ? This time is good for Lisa and myself. From alexey.melnikov@isode.com Sun Jul 19 11:40:48 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40FEF3A6AF1 for ; Sun, 19 Jul 2009 11:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjDKzc5q2BKh for ; Sun, 19 Jul 2009 11:40:47 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9A20B3A694D for ; Sun, 19 Jul 2009 11:40:46 -0700 (PDT) Received: from [92.40.25.192] (92.40.25.192.sub.mbb.three.co.uk [92.40.25.192]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 19 Jul 2009 19:40:43 +0100 Message-ID: <4A636889.7020009@isode.com> Date: Sun, 19 Jul 2009 19:40:09 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: general discussion of application-layer protocols Subject: [Fwd: Comments on draft-melnikov-sieve-external-lists-02.txt] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------010502010004060500050307" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 18:40:48 -0000 This is a multi-part message in MIME format. --------------010502010004060500050307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This started as a discussion on white/black listing. --------------010502010004060500050307 Content-Type: message/rfc822; name="Comments on draft-melnikov-sieve-external-lists-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Comments on draft-melnikov-sieve-external-lists-02.txt" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine (Isode M-Box/14.4v1) with LMTP; Sun, 19 Jul 2009 19:39:17 +0100 (BST) Received: from [92.40.25.192] (92.40.25.192.sub.mbb.three.co.uk [92.40.25.192]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 19 Jul 2009 19:39:16 +0100 Message-ID: <4A636837.7010105@isode.com> Date: Sun, 19 Jul 2009 19:38:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Ned Freed CC: ietf-mta-filters@imc.org Subject: Comments on draft-melnikov-sieve-external-lists-02.txt References: <371C2EEC-8CBD-4AC1-B07A-928352E19DCB@pobox.com> <28941.1246868682.560969@puncture> <4A51D1A1.5040507@isode.com> <01NAZVQAYWH4001DLH@mauve.mrochek.com> <47CB230E-B713-4098-82D4-318744434C46@pobox.com> <01NB0BOZYUPY001ML6@mauve.mrochek.com> <6DECD560-B257-4E6E-80E7-A99A69D297C6@pobox.com> <01NB14JAPS8E001ML6@mauve.mrochek.com> <01NB1TV04NJS001ML6@mauve.mrochek.com> <4A54701C.6080107@isode.com> <01NB2RB8UTA4001ML6@mauve.mrochek.com> In-Reply-To: <01NB2RB8UTA4001ML6@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Ned, I've changed the subject and moving my reply to the Sieve mailing list, where I think it belongs. Ned Freed wrote: [...] >> There is also a Sieve extension for making use of whitelists/blacklists >> during mail delivery. See draft-melnikov-sieve-external-lists-02.txt. >> It can work with CARDDAV, LDAP and other things. > > Interestingly, this extension in its current form is not compatible with > at least one of the proposals that was made here. The issue is one I've > raised before - the fact that :list is separate argument and not a > match type. > > Where there is clearly some utility in being able to say stuff along the > lines of: > > header :contains :list "subject" "tag:dirty-word-list" > > The problem is that in order for this to work the list has to be > enumerable. This wasn't the intent. I was certainly aware of the need not to retrieve the whole membership list. But you are saying that my syntax wouldn't work in this case. > Not all lists are enumerable, and even some that are are so large even > though oyu can enumerate them in theory you can't afford to do so in > practice. > > One use case where this matters is when the list is a set of hashed > values. The > way you find if something is "on the list" is to hash it and see if > that value > appears. And even if the input string is short enough that you can > enumerate > all the unique substrings, how about :matches and :regex? Good luck with > those. > > Hashed lists have in fact been proposed in the present discussion as a > means of > avoiding giving your address whitelist to the mail server. I happen > not to > think this is a useful thing to do for a variety of reasons, mostly > having to > do with address canonicalization (or lack thereof), but there are other > use cases where hashed lists make more sense. > > So, although it reduces functionality, I believe :list should be a > match type > and the underlying comparison type that's done should be a property of > the list > itself. Hmm. You are probably right, :list as a modifier is a bit of a hack. How would the new match type work with tests other than header/address/envelope? --------------010502010004060500050307-- From masinter@adobe.com Wed Jul 22 02:24:17 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0877628C0ED for ; Wed, 22 Jul 2009 02:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCbcANEIUvey for ; Wed, 22 Jul 2009 02:24:13 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by core3.amsl.com (Postfix) with ESMTP id E89BE3A6D21 for ; Wed, 22 Jul 2009 02:24:09 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKSmbamd6QZ4Z3Sx/3Ye6R7+fVYm4PV7ET@postini.com; Wed, 22 Jul 2009 02:24:13 PDT Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6M9H8ao015759; Wed, 22 Jul 2009 02:17:09 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n6M9NXY2007887; Wed, 22 Jul 2009 02:23:33 -0700 (PDT) Received: from nambx04.corp.adobe.com ([10.8.127.98]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Wed, 22 Jul 2009 02:23:32 -0700 From: Larry Masinter To: "apps-discuss@ietf.org" , "idna-update@alvestrand.no" Date: Wed, 22 Jul 2009 02:23:27 -0700 Subject: Agenda items for IRI-BOF Thread-Topic: Agenda items for IRI-BOF Thread-Index: AcoEDVWOjC7C30kgSY2uKytr5DvnSAC8Io0AAOtzRtAAAGRYAA== Message-ID: <8B62A039C620904E92F1233570534C9B0118D7F3F6B1@nambx04.corp.adobe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 09:24:17 -0000 If you have additional agenda items for the IRI BOF on Thursday July 30, or issues that you think are not in the issues list, please let me know. Thanks, Larry -----Original Message----- From: Larry Masinter=20 Sent: Wednesday, July 22, 2009 2:17 AM To: 'PUBLIC-IRI@W3.ORG' Cc: 'Mark Nottingham' Subject: Agenda items for IRI-BOF? (Is this the right list to send this to?) I've proposed an agenda for the IRI Issues review meeting=20 (July 30, 7:30-8:45 PM Stockholm http://www.ietf.org/meeting/75/ ) Agenda: http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75/IriIssues=20 *(10 minutes) Agenda Review, discussion of technical and process questions= =20 *(20 minutes) Tour of the latest Internet Draft http://tools.ietf.org/html/= draft-duerst-iri-bis Larry Masinter will walk through the document table of= contents, discussing the structure of the document and its status.=20 *(30 minutes) Taking at most 4 minutes per issue, walk through any open iss= ues from IETF/W3C liaison or Public IRI list, against current document.=20 *(15 minutes) Discussion of next steps and bringing document to a conclusio= n I'll try to prioritize and update the issue list before the meeting. Larry From alexey.melnikov@isode.com Wed Jul 22 06:20:07 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF34D3A6A7D for ; Wed, 22 Jul 2009 06:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95WDrtQvcGze for ; Wed, 22 Jul 2009 06:20:07 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id E6E4C3A6AE9 for ; Wed, 22 Jul 2009 06:19:09 -0700 (PDT) Received: from [172.16.2.134] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 22 Jul 2009 14:13:26 +0100 Message-ID: <4A671047.7010503@isode.com> Date: Wed, 22 Jul 2009 14:12:39 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps Discuss Subject: MIME related discussions with web folks (was Re: httpbis vs yam meeting slots in Stockholm) References: <4A52F11F.6000400@gmx.de> <59412B3595BB07DCFCFDC95E@caldav.corp.apple.com> <4A561F0A.1030100@isode.com> <96684634-7032-4399-9721-75BA83893025@mnot.net> <4A570976.2090108@isode.com> <4A570A3A.9090704@isode.com> In-Reply-To: <4A570A3A.9090704@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 13:20:08 -0000 Alexey Melnikov wrote: [...] > Considering that my original proposal is not working and I showed that > Mark's alternatives wouldn't work either, I am suggesting we leave > things as is. > Unless people have a third proposal that would work for the majority > of interested participants. > > We can try to coordinate agendas between the two meetings. I've asked MORG chairs to leave 30 minutes at the end of their slot for MIME related discussions between web and email folks. MORG slot is 13:00-15:00 on Wednesday. So we can have this discussion starting around 14:30. /* */ From alexey.melnikov@isode.com Wed Jul 22 15:24:37 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B803A6C50 for ; Wed, 22 Jul 2009 15:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I79ZqnQNkSos for ; Wed, 22 Jul 2009 15:24:36 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5BF463A6C80 for ; Wed, 22 Jul 2009 15:24:07 -0700 (PDT) Received: from [217.214.124.120] (host-n177-120.homerun.telia.com [217.214.124.120]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 22 Jul 2009 22:43:49 +0100 Message-ID: <4A6787EC.1080107@isode.com> Date: Wed, 22 Jul 2009 23:43:08 +0200 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org Subject: Updated agenda for the Apps Area meeting in Stockholm References: <4A527630.4070509@isode.com> <4A5C5F10.6050207@isode.com> In-Reply-To: <4A5C5F10.6050207@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:24:37 -0000 I've updated the list and order based on additional feedback: ================================== Here is the updated list of presentations. Please let me know if the list is correct and complete, and if the order and the length of sessions is Ok. We will have some time for discussions/questions, this time is not included below: 1) Iljitsch van Beijnum : FTP Application Layer Gateway for IPv6-to-IPv4 translation [15 mins] 2) Michael Tuexen : Running application layer protocols over SCTP [20 mins] 3) Andrew Yourtchenko : Successful Introduction of New Technology to HTTP [20 mins] 4) Alexey Melnikov : Vendor name registry for use in Application Protocols [5 mins] 5) Cyrus Daboo : Timezone IANA registry and protocol [15 mins] 6) Julian Reschke on behalf of Mark Nottingham: "Link header" and "Host Metadata for the Web" drafts [5 mins] 7) Peter Saint-Andre : OAuth WG status report [5 mins] 8) Barry Leiba(?): OGPX BOF [5 mins] 9) Bar BOF announcements, in particular: Carsten Bormann : 6lowapp bar BOF [5 mins] 10) Alexey Melnikov (no slides): area discussion about possibly moving SPF/SenderID to historic [10 mins] 11) Possible: Barry Leiba: Proposed "Abuse Report Format" WG [10 mins] 12) Barry Leiba : SMTP Service Extension for Message Recall (draft-leiba-morg-message-recall-00.txt) [15 mins] 13) Barry Leiba DRM proxies [5 mins] From julian.reschke@gmx.de Fri Jul 24 05:01:30 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7831E28C17D for ; Fri, 24 Jul 2009 05:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.093 X-Spam-Level: X-Spam-Status: No, score=-3.093 tagged_above=-999 required=5 tests=[AWL=-1.364, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UhMNhTOZKfL for ; Fri, 24 Jul 2009 05:01:29 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5028228C17B for ; Fri, 24 Jul 2009 05:01:28 -0700 (PDT) Received: (qmail invoked by alias); 24 Jul 2009 12:01:27 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp069) with SMTP; 24 Jul 2009 14:01:27 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/WMupkogDWuiAi1usLfdNexH1bBnvyy9oLKOsgoG FNylWfVr3+C1pJ Message-ID: <4A69A294.7020705@gmx.de> Date: Fri, 24 Jul 2009 14:01:24 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: MIME related discussions with web folks (was Re: httpbis vs yam meeting slots in Stockholm) References: <4A52F11F.6000400@gmx.de> <59412B3595BB07DCFCFDC95E@caldav.corp.apple.com> <4A561F0A.1030100@isode.com> <96684634-7032-4399-9721-75BA83893025@mnot.net> <4A570976.2090108@isode.com> <4A570A3A.9090704@isode.com> <4A671047.7010503@isode.com> In-Reply-To: <4A671047.7010503@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 12:01:30 -0000 Alexey Melnikov wrote: > Alexey Melnikov wrote: > [...] > >> Considering that my original proposal is not working and I showed that >> Mark's alternatives wouldn't work either, I am suggesting we leave >> things as is. >> Unless people have a third proposal that would work for the majority >> of interested participants. >> >> We can try to coordinate agendas between the two meetings. > > I've asked MORG chairs to leave 30 minutes at the end of their slot for > MIME related discussions between web and email folks. > MORG slot is 13:00-15:00 on Wednesday. So we can have this discussion > starting around 14:30. > ... Alexey, thanks a lot for trying to arrange this. In the meantime, and after talking to other HTTPbis people, I'm not sure it's even needed; my main interest was in finding out about the time table for progressing MIME specs to full standard, and that probably can be easily discussed informally (reception, or before/after apps area meeting). BR, Julian From alexey.melnikov@isode.com Fri Jul 24 05:45:37 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974B828C172 for ; Fri, 24 Jul 2009 05:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0-Gq7KcEcXH for ; Fri, 24 Jul 2009 05:45:36 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 83BF93A6944 for ; Fri, 24 Jul 2009 05:45:36 -0700 (PDT) Received: from [10.88.5.30] ((unknown) [212.175.117.115]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 24 Jul 2009 13:45:21 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4A69ACB4.5050105@isode.com> Date: Fri, 24 Jul 2009 15:44:36 +0300 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps Discuss Subject: Re: MIME related discussions with web folks (was Re: httpbis vs yam meeting slots in Stockholm) References: <4A52F11F.6000400@gmx.de> <59412B3595BB07DCFCFDC95E@caldav.corp.apple.com> <4A561F0A.1030100@isode.com> <96684634-7032-4399-9721-75BA83893025@mnot.net> <4A570976.2090108@isode.com> <4A570A3A.9090704@isode.com> <4A671047.7010503@isode.com> <4A69A294.7020705@gmx.de> In-Reply-To: <4A69A294.7020705@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 12:45:37 -0000 Julian Reschke wrote: > Alexey Melnikov wrote: > >> Alexey Melnikov wrote: >> [...] >> >>> Considering that my original proposal is not working and I showed >>> that Mark's alternatives wouldn't work either, I am suggesting we >>> leave things as is. >>> Unless people have a third proposal that would work for the majority >>> of interested participants. >>> >>> We can try to coordinate agendas between the two meetings. >> >> I've asked MORG chairs to leave 30 minutes at the end of their slot >> for MIME related discussions between web and email folks. >> MORG slot is 13:00-15:00 on Wednesday. So we can have this discussion >> starting around 14:30. >> ... > > Alexey, > > thanks a lot for trying to arrange this. > > In the meantime, and after talking to other HTTPbis people, I'm not > sure it's even needed; my main interest was in finding out about the > time table for progressing MIME specs to full standard, and that > probably can be easily discussed informally (reception, or > before/after apps area meeting). Ok, In this case I can sell the half hour to the highest bidder :-). So let me know if you want to talk to me. But note that seats are limited. From john-ietf@jck.com Sat Jul 25 00:09:11 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2073A6CB3 for ; Sat, 25 Jul 2009 00:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erX-zGUApdwL for ; Sat, 25 Jul 2009 00:09:11 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 1D7653A6CC2 for ; Sat, 25 Jul 2009 00:09:11 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MUbNU-0005Fp-Jf; Sat, 25 Jul 2009 03:09:08 -0400 Date: Sat, 25 Jul 2009 03:09:07 -0400 From: John C Klensin To: Julian Reschke , Alexey Melnikov Subject: Re: MIME related discussions with web folks (was Re: httpbis vs yam meeting slots in Stockholm) Message-ID: In-Reply-To: <4A69A294.7020705@gmx.de> References: <4A52F11F.6000400@gmx.de> <59412B3595BB07DCFCFDC95E@caldav.corp.apple.com> <4A561F0A.1030100@isode.com> <96684634-7032-4399-9721-75BA83893025@mnot.net> <4A570976.2090108@isode.com> <4A570A3A.9090704@isode.com> <4A671047.7010503@isode.com> <4A69A294.7020705@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 07:09:11 -0000 --On Friday, July 24, 2009 14:01 +0200 Julian Reschke wrote: > In the meantime, and after talking to other HTTPbis people, > I'm not sure it's even needed; my main interest was in finding > out about the time table for progressing MIME specs to full > standard, and that probably can be easily discussed informally > (reception, or before/after apps area meeting). I think we should know a lot more about that after YAM meets. john From alexey.melnikov@isode.com Sat Jul 25 06:16:34 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D753A691D for ; Sat, 25 Jul 2009 06:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=-1.034, BAYES_20=-0.74, J_CHICKENPOX_74=0.6, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFLrBszK2W-O for ; Sat, 25 Jul 2009 06:16:34 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 07F423A67FF for ; Sat, 25 Jul 2009 06:16:34 -0700 (PDT) Received: from [10.88.5.30] ((unknown) [212.175.117.58]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 25 Jul 2009 14:14:53 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4A6B0526.8090201@isode.com> Date: Sat, 25 Jul 2009 16:14:14 +0300 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org Subject: Help needed with P2P caching bar BOF MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 13:16:34 -0000 Is anybody willing&able to help me out (by attending) with the P2P Caching bar BOF on Wednesday, 8:00pm-10:00pm? From cabo@tzi.org Mon Jul 27 02:07:17 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772F13A6C3A; Mon, 27 Jul 2009 02:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKmgVUPG6hS3; Mon, 27 Jul 2009 02:07:16 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 085BF3A6C3C; Mon, 27 Jul 2009 02:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n6R973QK026832; Mon, 27 Jul 2009 11:07:03 +0200 (CEST) Received: from dhcp-161d.meeting.ietf.org (dhcp-161d.meeting.ietf.org [130.129.22.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id E9DEEB9B5; Mon, 27 Jul 2009 11:07:02 +0200 (CEST) Message-Id: <71C22460-1734-47D6-B7D4-C3A6D272CD42@tzi.org> From: Carsten Bormann To: Carsten Bormann In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [6lowpan] 6LowApp: Application protocols for 6LoWPAN and other LLN Date: Mon, 27 Jul 2009 11:06:57 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: ROLL WG , 6lowpan@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 09:07:17 -0000 The 6LowApp BOF is scheduled for Tue 18:30 at Room 202, see http://u.nu/6jfh I have been asked about the conflict with the social event at Tue evening. The idea is that we will take about an hour for structured discussion. At around 19:30, we will move to a more Bar-BOFy style. Those who want to go to the social will be able to then -- we will find out whether there still will be buses at that time or whether Taxis will be shared. So the Wireless Embedded Internet sub-schedule at IETF 75 for tomorrow, Tue 28, is: 0900-1130 6lowpan INT Cabaret 1520-1810 roll RTG Congresshall C 1830-19xx 6lowapp (APP) Room 202 Gruesse, Carsten From marc.blanchet@viagenie.ca Mon Jul 27 08:05:02 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6247A3A6BFB; Mon, 27 Jul 2009 08:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFUjoSTJRU5P; Mon, 27 Jul 2009 08:05:01 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 0CC6D3A6B22; Mon, 27 Jul 2009 08:05:01 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 0C82A29E15E5; Mon, 27 Jul 2009 11:05:02 -0400 (EDT) Received: from dhcp-1451.meeting.ietf.org (dhcp-1451.meeting.ietf.org [130.129.20.81]) by jazz.viagenie.ca (Postfix) with ESMTP id 63D9829E15E1; Mon, 27 Jul 2009 11:05:01 -0400 (EDT) Message-ID: <4A6DC20C.8040608@viagenie.ca> Date: Mon, 27 Jul 2009 17:04:44 +0200 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: apps-discuss@ietf.org, vcarddav@ietf.org Subject: vendor registry lookup service X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 15:05:02 -0000 Hi, there are some discussions about creating/extending a vendor name space registry for applications protocols (see http://www3.ietf.org/proceedings/75/slides/apparea-3.pdf as presented at apps-area meeting this morning). I made the point at the mike that we already have a vendor registry: the private enterprise numbers (PEN), which contains 35K entries, on a first come first serve manner, and automated by IANA. On the contrary, the proposal is based on the acap registry which contains about a dozen entries. why should we reinvent another registry with almost same data? One comment was made about the fact that the PEN are made of digits, therefore not user-friendly to be shown to the end-user. While I don't think this is a real issue and can be managed differently, I'm proposing a simple solution: a lookup service mapping PEN to vendor name, for user display. Thereby, this mail announces a PEN lookup service to map the PEN to the vendor name. This is implemented as a DNS TXT record under the enterprise-numbers.org domain name. It is available now. For example: dig 31474.enterprise-numbers.org TXT ... 31474.enterprise-numbers.org. 86400 IN TXT "Viagenie inc." dig 5842.enterprise-numbers.org TXT ... 5842.enterprise-numbers.org. 86400 IN TXT "Cisco Systems" Regards, Marc. -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From cabo@tzi.org Mon Jul 27 08:27:07 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0B33A6B0D; Mon, 27 Jul 2009 08:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfXF4NxU8N7Y; Mon, 27 Jul 2009 08:27:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 80E273A6AD4; Mon, 27 Jul 2009 08:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n6RFQxEL028768; Mon, 27 Jul 2009 17:26:59 +0200 (CEST) Received: from dhcp-52ef.meeting.ietf.org (unknown [130.129.82.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 74E7CBC09; Mon, 27 Jul 2009 17:26:59 +0200 (CEST) Message-Id: <7101F1BF-3003-42B0-BDE6-0502399CF988@tzi.org> From: Carsten Bormann To: ROLL WG , 6lowpan <6lowpan@ietf.org>, apps-discuss@ietf.org In-Reply-To: <71C22460-1734-47D6-B7D4-C3A6D272CD42@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: Re: [6lowpan] 6LowApp: Application protocols for 6LoWPAN and other LLN Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 17:26:24 +0200 References: <71C22460-1734-47D6-B7D4-C3A6D272CD42@tzi.org> X-Mailer: Apple Mail (2.935.3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 15:27:07 -0000 On Jul 27, 2009, at 11:06, Carsten Bormann wrote: > the conflict with the social event Sorry for tricasting once more, but this is *important information*: -- the last bus to the social will leave at 7:30 PM from in front of the Clarion Sign and will wait for us. We are a big enough group that it was OK. (Obviously, not all of us *will* go to the social; happy discussions await the rest.) -- for those who asked what the "Bar" in the "Bar BOF" was about, this seems to be a variant spelling of "beer", and indeed there will be some beer available for the participants of the Bar BOF, sponsored by an entity very interested in progress on the 6lowapp problem. As I said, important information! See you tomorrow at 1830. Gruesse, Carsten From dromasca@avaya.com Mon Jul 27 10:10:46 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F08E728C333; Mon, 27 Jul 2009 10:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpize7v9Wyuu; Mon, 27 Jul 2009 10:10:44 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 8C23928C2F6; Mon, 27 Jul 2009 10:10:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,277,1246852800"; d="scan'208";a="178131564" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Jul 2009 13:10:32 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jul 2009 13:10:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: vendor registry lookup service Date: Mon, 27 Jul 2009 19:10:09 +0200 Message-ID: In-Reply-To: <4A6DC20C.8040608@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: vendor registry lookup service thread-index: AcoOy6JXe0Xa6LJuSEyu8LfY/YgMdgAESjDw References: <4A6DC20C.8040608@viagenie.ca> From: "Romascanu, Dan (Dan)" To: "Marc Blanchet" , , X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 17:10:46 -0000 Marc, The name that is associated with a PEN is the name on the form submitted to IANA at the moment of the request. Nothing less, nothing more.=20 Dan =20 > -----Original Message----- > From: apps-discuss-bounces@ietf.org=20 > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Marc Blanchet > Sent: Monday, July 27, 2009 6:05 PM > To: apps-discuss@ietf.org; vcarddav@ietf.org > Subject: vendor registry lookup service >=20 > Hi, > there are some discussions about creating/extending a vendor=20 > name space registry for applications protocols (see=20 > http://www3.ietf.org/proceedings/75/slides/apparea-3.pdf as=20 > presented at apps-area meeting this morning). >=20 > I made the point at the mike that we already have a vendor=20 > registry: the private enterprise numbers (PEN), which=20 > contains 35K entries, on a first come first serve manner, and=20 > automated by IANA. On the contrary, the proposal is based on=20 > the acap registry which contains about a dozen entries. >=20 > why should we reinvent another registry with almost same data? >=20 > One comment was made about the fact that the PEN are made of=20 > digits, therefore not user-friendly to be shown to the=20 > end-user. While I don't think this is a real issue and can be=20 > managed differently, I'm proposing a simple solution: a=20 > lookup service mapping PEN to vendor name, for user display. >=20 > Thereby, this mail announces a PEN lookup service to map the=20 > PEN to the vendor name. This is implemented as a DNS TXT=20 > record under the enterprise-numbers.org domain name. It is=20 > available now. >=20 > For example: >=20 > dig 31474.enterprise-numbers.org TXT > ... > 31474.enterprise-numbers.org. 86400 IN TXT "Viagenie inc." >=20 >=20 > dig 5842.enterprise-numbers.org TXT > ... > 5842.enterprise-numbers.org. 86400 IN TXT "Cisco Systems" >=20 > Regards, Marc. >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D > IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca=20 > Stun/Turn server for VoIP NAT-FW traversal:=20 > http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca >=20 > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From dave@cridland.net Mon Jul 27 10:49:04 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18FDD3A6CA4; Mon, 27 Jul 2009 10:49:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfG2gH8Ha-Bu; Mon, 27 Jul 2009 10:49:03 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 56C973A6C77; Mon, 27 Jul 2009 10:48:37 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 27 Jul 2009 18:43:17 +0100 X-SMTP-Protocol-Errors: NORDNS Subject: Re: vendor registry lookup service References: <4A6DC20C.8040608@viagenie.ca> In-Reply-To: <4A6DC20C.8040608@viagenie.ca> MIME-Version: 1.0 Message-Id: <21725.1248716527.767300@puncture> Date: Mon, 27 Jul 2009 18:42:07 +0100 From: Dave Cridland To: Marc Blanchet , General discussion of application-layer protocols , Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 17:49:04 -0000 On Mon Jul 27 16:04:44 2009, Marc Blanchet wrote: > I made the point at the mike that we already have a vendor > registry: the > private enterprise numbers (PEN), which contains 35K entries, on a > first > come first serve manner, and automated by IANA. On the contrary, the > proposal is based on the acap registry which contains about a dozen > entries. Right, that's largely because we've reused that registry in a couple of other protocols already, and "short tag" names seem to be particularly useful. > One comment was made about the fact that the PEN are made of digits, > therefore not user-friendly to be shown to the end-user. While I > don't > think this is a real issue and can be managed differently, I'm > proposing > a simple solution: a lookup service mapping PEN to vendor name, for > user > display. You'd need one the other way around, too - existing protocols, and all. And existing protocols are real issues, like it or not. > Thereby, this mail announces a PEN lookup service to map the PEN to > the > vendor name. This is implemented as a DNS TXT record under the > enterprise-numbers.org domain name. It is available now. I'm absolutely not against combining the ACAP vendor registry with the PEN registry, but since existing protocols use both names and numbers (more technically, OID arcs), I think we need both registered. Moreover, most protocols have severe limitations on what characters can be included in those names - you'll have noticed that one of the changes I've made between the ACAP vendor registry and my draft is that I've drastically sliced the possible characters involved. So the vast majority of the names included in the PEN registry are simply unsuitable from the get-go. I'd even be happy to see a DNS based lookup, actually - it might be entertaining to translate to and from "vendor.isode" <=> "1.3.6.1.4.1.453", and it can certainly have a *very* long TTL. Of course, whilst you're at it, one could conceivably map the whole of the OBJECT IDENTIFIER space to DNS. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From iljitsch@muada.com Tue Jul 28 01:15:18 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC1A3A6CCC for ; Tue, 28 Jul 2009 01:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfUHYpTegIxE for ; Tue, 28 Jul 2009 01:15:17 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2973A6ABC for ; Tue, 28 Jul 2009 01:15:17 -0700 (PDT) Received: from dhcp-55f3.meeting.ietf.org (dhcp-55f3.meeting.ietf.org [130.129.85.243] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n6S8Ew1X073967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 28 Jul 2009 10:14:58 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <75B51C54-57D1-48C4-BCCB-BF6AE09476A2@muada.com> From: Iljitsch van Beijnum To: apps-discuss@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: FTP64 Date: Tue, 28 Jul 2009 10:15:14 +0200 X-Mailer: Apple Mail (2.935.3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:15:18 -0000 Hi, The BEHAVE wg just hummed to adopt the next iteration of the FTP64 draft as a working group document. I'd be happy to receive in person feedback here in Stockholm if anyone is inclined to offer it. The slides: http://www.ietf.org/proceedings/75/slides/behave-0.pdf From dwing@cisco.com Thu Jul 30 01:49:28 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2A43A6BC7; Thu, 30 Jul 2009 01:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiZdoZK5-m11; Thu, 30 Jul 2009 01:49:27 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EC8D028C1D2; Thu, 30 Jul 2009 01:48:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEANP7cEpAZnme/2dsb2JhbACLDa4XiCeQFAWEEQ X-IronPort-AV: E=Sophos;i="4.43,294,1246838400"; d="scan'208";a="52232184" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Jul 2009 08:48:51 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6U8mpQ8022740; Thu, 30 Jul 2009 04:48:51 -0400 Received: from dwingwxp01 ([10.21.72.10]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6U8mmUj008471; Thu, 30 Jul 2009 08:48:49 GMT From: "Dan Wing" To: Subject: WGLC: draft-ietf-behave-turn-uri-02 Date: Thu, 30 Jul 2009 10:48:45 +0200 Message-ID: <0a9801ca10f2$8f933600$5f7d150a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoQ8ov/YM9wzQORRlC6NiHyOFf8mA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=371; t=1248943731; x=1249807731; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20WGLC=3A=20draft-ietf-behave-turn-uri-02 |Sender:=20 |To:=20; bh=xKEyN+k3186Eb4o7yECwvyQK4DnxNkEp5Mp7BRINY4U=; b=LP6tQniAP/L4e5T+kp/Qr08XuKJNcA4KXqu+ctWE1IYh+rWYtYe16xwDWX iHhheqXTSW+1zOwaEdQlJyK9bIDdbYCm+J9HVY622tmv2DgfPta81s1cQHfj AE2TCX4KOY; Authentication-Results: rtp-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: draft-ietf-behave-turn-uri@tools.ietf.org, 'Behave Chairs' , apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 08:49:28 -0000 BEHAVE is starting a 3 week working group last call (WGLC), ending August 19, for draft-ietf-behave-turn-uri-02 "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers" *** Review by folks familiar with URIs are encouraged. *** Please send technical comments to the BEHAVE list, and editorial comments to the authors. Thanks, -d