From nobody Sun Jun 1 06:59:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDD91A021E for ; Sun, 1 Jun 2014 06:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nX3hnZ5B_GbG for ; Sun, 1 Jun 2014 06:59:56 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1501A0213 for ; Sun, 1 Jun 2014 06:59:56 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8HNOQWSV40048KB@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 1 Jun 2014 06:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1401630890; bh=GIQECyc5nfKLImlTi6IFms58M2otmS/sVq36f8pmBu8=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=SKSqn4SfuWcNc65lalINZ1+JmhNGw2aHpR+TSZVbAcZaqAiqZ1Vf7iwQfO434ssJi A/z5LhuCKP4DKnSxTPUCrHqmNSuucb97n9MpLIvrQEQsySGYykCxJV4SVND9tnjcDl V2LHtYuzSdBxBdWRK269QcPQ9gKo1dl7+eFqtggo= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8GKCSZM74000054@mauve.mrochek.com>; Sun, 01 Jun 2014 06:54:46 -0700 (PDT) Message-id: <01P8HNOPBWDC000054@mauve.mrochek.com> Date: Sun, 01 Jun 2014 06:51:12 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 31 May 2014 23:39:51 -0700" References: <8D87868A-7739-4085-8F1C-4DBDE40B2BE7@isode.com> To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eRll9hVjPvL-vjm_v4ypqHaLltc Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-email-auth-codes-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jun 2014 13:59:57 -0000 > On Sat, May 31, 2014 at 10:05 AM, Alexey Melnikov > wrote: ... > > Other comments: > > > > Description of DKIM codes: do they cover lack of any DKIM signature or > > only cases when DKIM signatures are present, but don't verify or cover > > wrong domains? > > > The DKIM specification says that an unsigned message is to be treated no > differently than one with a signature that failed to verify. I also don't > know of any receivers that only care that there was a valid signature > regardless of the domain that added it, so that doesn't seem to be a use > case we need to worry about. I agree with this analysis, however, it may be worth adding a bit of text referring to where the DKIM specification says this. ... > > I am not convinced about the "multiple failures" status code, but then it > > provides more information than X.7.0, so it is probably Ok. > > > The reason that was suggested (by Barry, I believe) is that a message might > be rejected for multiple authentication failures, yet you can only return a > single code. However, let's say you always expect SPF to fail, but DKIM > should always pass. Reporting an SPF failure is useless there; providing > the less specific response in that case is actually more useful. And more generally, I think we've previously set the bar for registering codes far too high. (We have a marked tendency to do this for registries in general.) Even if this code were to prove not to be useful, it's meaning is clear and integers are cheap. Ned From nobody Sun Jun 1 11:10:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59501A026D for ; Sun, 1 Jun 2014 11:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJHcc_9yoz9A for ; Sun, 1 Jun 2014 11:10:09 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0301A026A for ; Sun, 1 Jun 2014 11:10:09 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id D6604D04583; Sun, 1 Jun 2014 14:10:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1401646200; bh=V1Y6wuzKw3tNI1sIOUGXxcMVv5vqWPfvb1JZbgwaFuE=; h=In-Reply-To:References:Subject:From:Date:To:From; b=zSVq5dwTy1IKnCHBIu5jbEoUwTopmT8UsgsJ0BhB070i6yMvh7qkkxxqJGy2ujO8U yX9NiaJhLuAMPbIYDaptpsJeS+72L/bkjEaFbCM5S2oF5Wes4MT/u0yLMLJulJXEPg U1XTBAzz6dJ2AEqCX+Q4RfYSPhu3Iku7W7an1GaE= Received: from [IPV6:2600:1003:b108:62b0:5430:61aa:7a18:567a] (unknown [IPv6:2600:1003:b108:62b0:5430:61aa:7a18:567a]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 7234CD040E8; Sun, 1 Jun 2014 14:10:00 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----5BEN95VY8XJABZK1T6UZ81RSOM95EG" Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 01 Jun 2014 14:09:59 -0400 To: apps-discuss@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/g9PxgOMPrwwTf1qubjKxOnPhnAA Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jun 2014 18:10:11 -0000 ------5BEN95VY8XJABZK1T6UZ81RSOM95EG Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 I've reviewed the draft. I support publication after resolution of some comments. RFC 7208 section 8 makes different recommendations based on SPF result. By aggregating SPF failures into a single result code, I am afraid we're losing information not gaining it in some cases. If we could have a x.something for SPF verification failures and an x.something_else for SPF error results, I believe it would be useful and consistent with RFC 7208. The former would be for verification failures that met local policy for rejection and the latter would be for SPF errors (5.x for permerror and 4.x for temperror). This would allow for the new specificity that this is about SPF without losing the RFC 7208 distinction between verification failures and error conditions. I am concerned about the DKIM codes. By design, DKIM doesn't give any basis for rejection. DKIM in particular doesn't tie the signature domain to any identities in the message. I believe the idea of author domain signed messages is foreign to DKIM. Much of what is in the draft about DKIM could is really about either completely private out of band arrangements or DMARC. I think the DKIM codes should probably be moved to the DMARC draft. The others make sense. If DKIM is covered, I think covering TLS makes sense to include too. Closely related, I wonder about DANE SMTP verification failures.? Scott K ------5BEN95VY8XJABZK1T6UZ81RSOM95EG Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I've reviewed the draft. I support publication after resolution of some comments.

RFC 7208 section 8 makes different recommendations based on SPF result. By aggregating SPF failures into a single result code, I am afraid we're losing information not gaining it in some cases.

If we could have a x.something for SPF verification failures and an x.something_else for SPF error results, I believe it would be useful and consistent with RFC 7208.

The former would be for verification failures that met local policy for rejection and the latter would be for SPF errors (5.x for permerror and 4.x for temperror).

This would allow for the new specificity that this is about SPF without losing the RFC 7208 distinction between verification failures and error conditions.

I am concerned about the DKIM codes. By design, DKIM doesn't give any basis for rejection. DKIM in particular doesn't tie the signature domain to any identities in the message. I believe the idea of author domain signed messages is foreign to DKIM.

Much of what is in the draft about DKIM could is really about either completely private out of band arrangements or DMARC. I think the DKIM codes should probably be moved to the DMARC draft.

The others make sense.

If DKIM is covered, I think covering TLS makes sense to include too. Closely related, I wonder about DANE SMTP verification failures.?

Scott K
------5BEN95VY8XJABZK1T6UZ81RSOM95EG-- From nobody Sun Jun 1 16:19:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900351A00FA for ; Sun, 1 Jun 2014 16:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_19=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CZlvmJ8SyAu for ; Sun, 1 Jun 2014 16:19:47 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 298AA1A00F5 for ; Sun, 1 Jun 2014 16:19:47 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8I78V7WWG003IYI@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 1 Jun 2014 16:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1401664482; bh=45dwLMbIJE2KESzDYJ641ij6E09LTwPMkfAIRMhfFeA=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=anr11aRd72wENHKuWBGMFZcNkUr/2W8zkM7lbnkJZspBdSlicEvFWET/8XrabsS6V L8P04h3fVmbKePHhe4bwt26qwRYicnFkD9h4JzcBVuYHXg2tjchPzFXL2r87yOPbb0 j0bhN0XFQB/39tTkZd39Nuy0hdZv8SGAxpiGwZjk= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8GKCSZM74000054@mauve.mrochek.com>; Sun, 01 Jun 2014 16:14:38 -0700 (PDT) Message-id: <01P8I78TXLUE000054@mauve.mrochek.com> Date: Sun, 01 Jun 2014 16:02:52 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 01 Jun 2014 14:09:59 -0400" References: To: Scott Kitterman Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GgwgVlbhBuEG9BAU-vNOjhBD92o Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jun 2014 23:19:48 -0000 > I've reviewed the draft. I support publication after resolution of some comments. > RFC 7208 section 8 makes different recommendations based on SPF result. By aggregating SPF failures into a single result code, I am afraid we're losing information not gaining it in some cases. > If we could have a x.something for SPF verification failures and an > x.something_else for SPF error results, I believe it would be useful and > consistent with RFC 7208. > The former would be for verification failures that met local policy for > rejection and the latter would be for SPF errors (5.x for permerror and 4.x for > temperror). > This would allow for the new specificity that this is about SPF without > losing the RFC 7208 distinction between verification failures and error > conditions. This seems reasonable to me. Our implementation of SPF already makes the distinction in regards to the error text that's returned. > I am concerned about the DKIM codes. By design, DKIM doesn't give any basis > for rejection. DKIM in particular doesn't tie the signature domain to any > identities in the message. I believe the idea of author domain signed messages > is foreign to DKIM. That may be the design and the intent. It's not the reality on the ground. Error code assignments need to reflect the reality on the ground. > Much of what is in the draft about DKIM could is really about either > completely private out of band arrangements or DMARC. I think the DKIM codes > should probably be moved to the DMARC draft. I used this was the right thing to do. I no longer think so. I think these codes need to be in a general error code definition document so that the next policy enforcment mechanism defined along these lines (we're on our third, remember) will have them available. If you put them alongside a specific policy mechanism it will be taken to mean that those codes are for that mechanism specifically. > The others make sense. > If DKIM is covered, I think covering TLS makes sense to include too. Closely > related, I wonder about DANE SMTP verification failures.? I'll first note that codes for TLS have limited utility since the usual result of a TLS negotiation failure is a broken connection and no opportunity to return any sort of code. That said, a subsequent policy check can fail, in which case it may make sense to have some codes defined. But since the entire TLS in SMTP space is in the process of being reworked with DANE and such, I think it's best to wait for that work to define the necessary codes. Ned From nobody Mon Jun 2 07:18:33 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3011A0358; Mon, 2 Jun 2014 07:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFN0q7d96nAn; Mon, 2 Jun 2014 07:18:18 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80B41A0340; Mon, 2 Jun 2014 07:18:09 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s52EI1ba000986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Jun 2014 09:18:01 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s52EI0am028166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jun 2014 09:18:00 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s52EHwZk024804; Mon, 2 Jun 2014 09:17:59 -0500 (CDT) Message-ID: <538C8820.1090900@bell-labs.com> Date: Mon, 02 Jun 2014 09:20:16 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Emil Ivov , "apps-discuss@ietf.org" , draft-ietf-mmusic-latching@tools.ietf.org References: <537F520E.3060501@bell-labs.com> <538663F1.4080709@jitsi.org> In-Reply-To: <538663F1.4080709@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/OM9szMXNKDBGZUhNh2_GyEazMmY Cc: IESG IESG , mmusic Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-mmusic-latching-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 14:18:27 -0000 On 05/28/2014 05:32 PM, Emil Ivov wrote: > Hey Vijay, > > Thanks for your review! Comments inline. Emil: Thank you for indulging me. More inline (please see to end). I have taken out items of agreement and only list those where more discussion is required. For reference, my original review is at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12014.html). >> SDP is as much of a standard as SIP is, no? Maybe you mean to say that >> because of the complexity of representing SIP messages, the SIP portion >> of a RTC component's stack may vary between implementations and deploy- >> ments. SDP, being a simpler protocol (at least syntactically), is not >> exposed to such vagaries. Yes? > > Yes, exactly. [...] > On the other hand there only so many ways you can change an IP address > in SDP. So, how about the following wording? > > SIP's many features in terms of controlling message routing provide > for various ways of addressing NAT traversal. As a result, the HNT > component for SIP is typically more implementation-specific and > deployment-specific than the SDP and media components. > > Would this be better? Yes, much improved. One minor modification to the suggested text: s/SIP's many features in terms of controlling message routing provide for various ways of addressing NAT traversal./ SIP uses numerous expressive primitives for message routing and, consequently, NAT traversal./ >> - S3, second paragraph: "newly introduced media relay" --- newly >> introduced to who? [...] > So how about this? > > While this is not necessary for HNT to work, quite often, the IP > address of that media relay may be the same as that of the signaling > intermediary (i.e. the SIP SBC and media relay are co-located on the > same host). Also, in almost all cases, the address of the media > relay would belong to the same IP address family as the one used for > signaling, as it is known to work for that UA. > > Is this better or do you prefer the original? The problem with qualifying phrases like "In almost all cases" is that one wonders what happens in other cases? What do you think about the following text: In typical deployments, the media relay and signaling intermediary (the SBC) are co-located, thereby sharing the same IP address family. This works well because the UA also shares the same IP address family. In deployments where the media relay belongs to a different address family, the signaling intermediary would rewrite it to correspond to the address family of the UA. Feel free to push back and modify if this does not convey the right semantics (especially the "In deployments..." part). >> - S4, the descriptional steps below the text "The latching mechanism >> works as follows:" will be improved if you used "UAC" or "UAS" instead >> of "UA" (I recognize that in SIP it is not necessary that the UAC >> make the first offer, but these steps are for illustrative purposes >> and it helps to be as clear as we can for neophyte readers). Even >> much better if you could cast the actors in terms of the principals >> Alice and Bob that appear in Figures 2. So, something like "After >> receving an offer from Alice (UAC) who is behind a NAT" is preferable >> (I think) to "After receiving an offer from a NATed UA". > > I agree this can be said better. What would you say about: > > This way, while a session is still being setup, the signalling > intermediary is not yet aware what addresses and ports the caller > and the callee would end up using for media traffic: it has only > seen them advertise the private addresses they use behind their > respective NATs. Therefore media relays used in HNT would often use > a mechanism called "latching". Umm ... I think there is a bit of a disconnect here. I am referring to all steps 1 - 6 above. See next comment; it is related. >> - S4, the numbered steps in Figure 2: change UAC to Alice in all of >> the steps, and change UAS to Bob in all of the steps. Easier for >> neophyte readers to follow. Alternatively, you may put "(UAC)" >> above Alice and "(UAS)" above Bob to impart the same semantics. > > Agreed! Would be much better! > >> - S4, Figure 2: the text between step 12 and step 13 ("(SBC latches >> to source IP address and port seen in (10))" --- what is this >> referring to? Is it referring to the latching created by Alice? >> or Bob? It is not clear, specially since I am not sure if the >> "(10)" in the text I quote is a typo or not. Maybe you meant >> "(7)" or maybe "(2)"? > > Latching happens as soon as the first media packet arrives so this meant > (11). Thanks for the catch and sorry about the confusion! No worries. >> - S4, Figure 2, step 13: Much as you do in step 11, you should >> spell out the "dest" field here as well. So, >> s/RTP/RTP, dest=198.51.100.2:22007/ > > OK, that's going to require some ASCII art magic because we are out of > place there already but I do agree it would be useful :) Sure; will be helpful if put in. >> - S5, first paragraph, line 12: s/onto packets/onto media packets/ > > Well they don't need to be media. They would be ignored even if they > weren't. WDYT? Yes, you are right. Disregard that comment. >> - S5, first paragraph, line 14: "... a range of IP addresses belonging >> to the same network..." Here, "same" as which one? I suspect you >> mean the attacker's network. But being explicit is better here. > > It means the same as the one that the source address of the signalling > packets belongs to. How about this: > > In some cases the > limitation may be loosened to allow media from a predefined range of > IP addresses in order to allow for use cases such as decomposed UAs Yes, much better. >> - S5, first paragraph, towards the end: "widen the gap for potential >> attackers..." Here, I suspect you mean that it provides the attackers >> more IP address from which to mount attacks, i.e., advantage: >> attackers. Yes? > > Yes. Is this a clarifying question or do you think it would be better if > changed that way? I think it is better to say that "it provides the attackers a larger attack surface" (or something similar). Using the phrase "widen the gap" is ambiguous. One can read that as widening the gap between attacker and defender (i.e., advantage defenders). >> - S5, third paragraph: I am not sure I understand case (2). Why would >> an SBC latch on to an attacker if it is using restricted latching? [...] > Well, automated UAs are often less picky than humans about the kind of > media they get (if at all) and the intention was to warn aout that > option. Happy to remove it if you find it unnecessary. No leave all that in. As I re-read my comment on case (2), it seems that I may have been in error. If the attacker is behind the same NAT as the legitimate SIP UA, then what you describe is good. >> - S5, fourth paragraph: "For example, in cases where end-to-end >> encryption is used it would still be possible for an attacker to >> hijack a session despite the use of SRTP and perform a denial of >> service attack. However, media integrity would not be compromised." >> >> Can you explain more broadly how the above would work? If we assume >> that the endpoints exchange keys end-to-end and create secure channels >> end-to-end, how would the attacker hijack a session? (Heartbleed and >> all such mechanisms aside, of course. If we assume keys are derived >> end-to-end and don't follow the hop-by-hop model, how would the >> attacker prevail?) > > End-to-end was probably not the best choice of words here. Imagine > something like ZRTP though. Given that such mechanisms rely exclusively > on the media path for key negotiation, there would be no way for the SBC > to authenticate the UA so it would still latch onto the wrong endpoint. > Obviously ZRTP's authentication would prevent from an actual MitM attack > but given that it's already on the media path, the attacker can simply > stop relaying media and effectively perform a DoS. Does this make sense? Yes, more now. But, I think you will have to describe this attack using ZRTP as an example in some more detail since there are various issues at work here (the SBC not being able to authenticate the endpoint using ZRTP, etc.). I suspect that the security ADs may ask you to do this anyway during IESG review. Of course, if they don't you are free to proceed, but as a matter of principle, it is best to explain the security threat in enough detail that someone building these things can appreciate the reasoning. (In the current form, at least I had questions on the scenario you had in mind, hence the comment.) >> - Abstract, 3rd paragraph: >> s/components of the HNT components/components of HNT/ > > thanks > >> In fact, the entire 3rd paragraph could be written more succinctly as >> follows: >> >> Latching, one of the components of HNT, has a number of security >> issues detailed in this document. Based on the known threats, the >> IETF advises against use of this mechanism on the Internet and >> recommends other solutions, such as the Interactive Connectivity >> Establishment (ICE) protocol. > > That paragraph was the result of literally tens of back and forths so, > unless you think this is paramount, I think it would be better to keep > it as is. Specifically, the above version is missing on the fact that a) > using SRTP allows for the security concerns to be addresses and the > mechanism becomes acceptable b) sometimes the security concerns simply > don't come into play (e.g. public conferences) c) there are controlled > environments where security is taken care of in another way. Hmmm ... I don't see that the original version attends to (a), (b) and (c) any more explicitly than the above version, but I will defer to your judgment here. Since the paragraph is crafted through a hard-won battle, please feel free to retain it. >> - S4, first paragraph: s/couple/tuple/ > > well, in this case the text does refer to the address:port couple but I > am ok with changing that to the "addres:port/transport" tuple (or triplet?) Stevens used "tuple" in his seminal TCP books. I personally think "tuple" is better (and it is devoid of ordinal value, i.e., there can be a 2-tuple, a quintuple, sextuple, etc.). If, however, you'd like to leave it as "couple", no problem. >> - S4, Figure 3: why not use the principals Alice and Bob here as >> well instead of "XMPP Client 1" and "XMPP Client 2"? > > Frankly the main reason was because it otherwise looks exactly like SIP > and it becomes confusing. But I don't mind switching to Romeo and Juliet > (which are XSF's protagonists of choice ;) ). Sure. Out of curiosity, who is XSF's Eve? Thanks for your time on this, Emil. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Mon Jun 2 10:40:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7ED1A032E for ; Mon, 2 Jun 2014 10:40:23 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1JYHIrt2cGL for ; Mon, 2 Jun 2014 10:40:22 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE2D1A02F7 for ; Mon, 2 Jun 2014 10:40:21 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id u57so5515166wes.4 for ; Mon, 02 Jun 2014 10:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8HsZTLFYhjDXoQgMH9mEMDncypGpl5V/PowElCvZGpM=; b=YE9gYrRyVhibjnrKDIgbOvWlh0IW3VW7akjwzYxxmRwiNhMQi7pnIfzon2vAzdq6o4 JjvEGHchSZZWpC4d7HDqOGLaUJLVObZ63fD5V1sQ2GGe50hlTac9uei1hlkky81nfKAS qMKGTRsgoWGVBtjApi0/8UqSWQe8uE7VCgOAuiM/NXzyjGrFldMd0aCmig1K6+t34CeL FyFTgy2MHVGiw2aDhL3lY4iOWS1i8n2ZRIKxRrh2uHcVjKBPZqLkp5yP6FnXwC49KwF6 ZpNfx0XJcLTCoQ+dlhR3JEw0prYmXC2FKkZLpaNUwBgbjbpZWsHxPv44YOciIvZxF5L/ V+5A== MIME-Version: 1.0 X-Received: by 10.180.75.102 with SMTP id b6mr24283254wiw.26.1401730813726; Mon, 02 Jun 2014 10:40:13 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Mon, 2 Jun 2014 10:40:13 -0700 (PDT) In-Reply-To: <01P8HNOPBWDC000054@mauve.mrochek.com> References: <8D87868A-7739-4085-8F1C-4DBDE40B2BE7@isode.com> <01P8HNOPBWDC000054@mauve.mrochek.com> Date: Mon, 2 Jun 2014 10:40:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=f46d043891553918af04fadde306 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AotWfuzKTnPgq1vNyOZqQL92hQ4 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-email-auth-codes-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 17:40:23 -0000 --f46d043891553918af04fadde306 Content-Type: text/plain; charset=UTF-8 On Sun, Jun 1, 2014 at 6:51 AM, Ned Freed wrote: > > > The DKIM specification says that an unsigned message is to be treated no > > differently than one with a signature that failed to verify. I also > don't > > know of any receivers that only care that there was a valid signature > > regardless of the domain that added it, so that doesn't seem to be a use > > case we need to worry about. > > I agree with this analysis, however, it may be worth adding a bit of > text referring to where the DKIM specification says this. > Paragraph 2 of Section 3 already contains that reference. Do we need to say more than that? -MSK --f46d043891553918af04fadde306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jun 1, 2014 at 6:51 AM, Ned Freed <ned.freed@= mrochek.com> wrote:

> The DKIM specification says that an unsigned message is to be treated = no
> differently than one with a signature that failed to verify. =C2=A0I a= lso don't
> know of any receivers that only care that there was a valid signature<= br> > regardless of the domain that added it, so that doesn't seem to be= a use
> case we need to worry about.

I agree with this analysis, however, it may be worth adding a bit of<= br> text referring to where the DKIM specification says this.
<= div>
Paragraph 2 of Section 3 already contains that reference= .=C2=A0 Do we need to say more than that?

-MSK
<= /div>
--f46d043891553918af04fadde306-- From nobody Mon Jun 2 10:47:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB841A0367 for ; Mon, 2 Jun 2014 10:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2a9MrHw9MAp for ; Mon, 2 Jun 2014 10:47:00 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019C91A032C for ; Mon, 2 Jun 2014 10:46:59 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n15so5110704wiw.2 for ; Mon, 02 Jun 2014 10:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n5wyo2d9olsYqjXbh7njDQ+wEjeKvv9CPchj5DN77Io=; b=ZhDSxr5LGVau5E8RHnqo1/NzMYF5zbreZuhUqBt6S5TOOB2l3SNlBttKJi6sL0xt6C p7lIJukUGa9B+h0L+EAjKut8IhlL/PzcJmSzB/DBdBWcR6G3nzzwYs5ux9q9i07vBzAA pDIXvJC4H6z4eyA4G4YdN++CN9I0Kjihn4/hOBLzLpe4wjc70Z1nDoRbq4lUBg+Pk489 9PIN6V5OkSvEvvYRPRq+HlmFpFVRyZsPHkqvQ6/MSypwOCP+9aogpJ7QrmvvQppR4fDA 0BhkO5Kz7Wcx0Fn2isKk4DZ5ojglGjV2k9MMMDFgiDDp95PCxjQ+P9YhD0AYYNtoxuCt 3mpg== MIME-Version: 1.0 X-Received: by 10.180.20.210 with SMTP id p18mr24308323wie.8.1401731213286; Mon, 02 Jun 2014 10:46:53 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Mon, 2 Jun 2014 10:46:53 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Jun 2014 10:46:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=bcaec53d5c6109e8e404faddfb78 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EIvtrAqV2yVOCCTM-DlpPauwQ4Y Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 17:47:02 -0000 --bcaec53d5c6109e8e404faddfb78 Content-Type: text/plain; charset=UTF-8 On Sun, Jun 1, 2014 at 11:09 AM, Scott Kitterman wrote: > RFC 7208 section 8 makes different recommendations based on SPF result. By > aggregating SPF failures into a single result code, I am afraid we're > losing information not gaining it in some cases. > > If we could have a x.something for SPF verification failures and an > x.something_else for SPF error results, I believe it would be useful and > consistent with RFC 7208. > > The former would be for verification failures that met local policy for > rejection and the latter would be for SPF errors (5.x for permerror and 4.x > for temperror). > > This would allow for the new specificity that this is about SPF without > losing the RFC 7208 distinction between verification failures and error > conditions. > Seems reasonable to me as well. I'll add this for the next version. > I am concerned about the DKIM codes. By design, DKIM doesn't give any > basis for rejection. DKIM in particular doesn't tie the signature domain to > any identities in the message. I believe the idea of author domain signed > messages is foreign to DKIM. > That's true, but we covered this in another thread: The point of including the DKIM codes is not to encourage non-compliant behavior, but rather to accept the fact that some operators do it despite the fact that DKIM has a SHOULD NOT about it, and improve interoperability with those operators. There's text in the -01 version (second paragraph of Section 3) that talks about this already. I also agree with Ned's point about reflecting reality with these codes, and that we've quite possibly been too strict on assigning them to date. Much of what is in the draft about DKIM could is really about either > completely private out of band arrangements or DMARC. I think the DKIM > codes should probably be moved to the DMARC draft. > > The others make sense. > > If DKIM is covered, I think covering TLS makes sense to include too. > Closely related, I wonder about DANE SMTP verification failures.? > I agree with Ned's response on that point as well. -MSK --bcaec53d5c6109e8e404faddfb78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jun 1, 2014 at 11:09 AM, Scott Kitterman <scott= @kitterman.com> wrote:
RFC 7208 section 8 makes different recommend= ations based on SPF result. By aggregating SPF failures into a single resu= lt code, I am afraid we're losing information not gaining it in some ca= ses.

If we could have a x.something for SPF verification failures and an x.somet= hing_else for SPF error results, I believe it would be useful and consisten= t with RFC 7208.

The former would be for verification failures that met local policy for rej= ection and the latter would be for SPF errors (5.x for permerror and 4.x fo= r temperror).

This would allow for the new specificity that this is about SPF without los= ing the RFC 7208 distinction between verification failures and error condit= ions.

Seems reasonable to me as well.= =C2=A0 I'll add this for the next version.
=C2=A0
I am concerned about the DKIM codes. By design, DKIM doesn't give any b= asis for rejection. DKIM in particular doesn't tie the signature domain= to any identities in the message. I believe the idea of author domain sig= ned messages is foreign to DKIM.

That's true, but we covered this in an= other thread: The point of including the DKIM codes is not to encourage non= -compliant behavior, but rather to accept the fact that some operators do i= t despite the fact that DKIM has a SHOULD NOT about it, and improve interop= erability with those operators.=C2=A0 There's text in the -01 version (= second paragraph of Section 3) that talks about this already.

I also agree with Ned's point about reflecting reality w= ith these codes, and that we've quite possibly been too strict on assig= ning them to date.

Much of what is in the draft about DKIM could is really about either comple= tely private out of band arrangements or DMARC. I think the DKIM codes sho= uld probably be moved to the DMARC draft.

The others make sense.

If DKIM is covered, I think covering TLS makes sense to include too. Close= ly related, I wonder about DANE SMTP verification failures.?

I agree with Ned's response on that point as well= .

-MSK
--bcaec53d5c6109e8e404faddfb78-- From nobody Mon Jun 2 10:51:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6EB1A039C; Mon, 2 Jun 2014 10:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0txVjvAwSPkR; Mon, 2 Jun 2014 10:51:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8892B1A03A4; Mon, 2 Jun 2014 10:51:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140602175137.29599.55614.idtracker@ietfa.amsl.com> Date: Mon, 02 Jun 2014 10:51:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tgl0HPy_609Z7Ax8UL1DmIeUV5I Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 17:51:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Email Authentication Status Codes Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-email-auth-codes-02.txt Pages : 7 Date : 2014-06-02 Abstract: There is at present no way to return a status code to an email client that indicates a message is being rejected or deferred specifically because of email authentication failures. This document registers codes for this purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-email-auth-codes-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-email-auth-codes-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 2 12:00:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DC11A0409 for ; Mon, 2 Jun 2014 12:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_19=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5JaoMXBg_0n for ; Mon, 2 Jun 2014 12:00:22 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D1E1A0469 for ; Mon, 2 Jun 2014 12:00:18 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id C4C07D042F0; Mon, 2 Jun 2014 15:00:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1401735612; bh=KaBY05rtBcdFkns5M8nbBYLqC6vFExEcBhO3VcAog3A=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SzMoxQB/b4wI6fAuBUkwkr90SQAmNfx8tdZMDsun8B6cZRKnpYXREBkJViWp40obf JFmQMAMszp+JzCNbCEGOwQ+pdct7v5pwJ1hVQP3OeZeY4DZpChCg/+jj6icHxlNYgN DDOHQZandkGCIuSQS7558XCrzmtMsm9AoGXtjLik= Received: from scott-latitude-e6320.localnet (unknown [209.140.86.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 7139FD04105; Mon, 2 Jun 2014 15:00:11 -0400 (EDT) From: Scott Kitterman To: IETF Apps Discuss Date: Mon, 02 Jun 2014 14:59:59 -0400 Message-ID: <2312436.FhlNVapo4H@scott-latitude-e6320> User-Agent: KMail/4.13 (Linux/3.13.0-27-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tK2Ln6QUKCN4KWCF4cy-n1MbYEA Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 19:00:24 -0000 On Monday, June 02, 2014 10:46:53 Murray S. Kucherawy wrote: > On Sun, Jun 1, 2014 at 11:09 AM, Scott Kitterman > > wrote: > > RFC 7208 section 8 makes different recommendations based on SPF result. By > > aggregating SPF failures into a single result code, I am afraid we're > > losing information not gaining it in some cases. > > > > If we could have a x.something for SPF verification failures and an > > x.something_else for SPF error results, I believe it would be useful and > > consistent with RFC 7208. > > > > The former would be for verification failures that met local policy for > > rejection and the latter would be for SPF errors (5.x for permerror and > > 4.x > > for temperror). > > > > This would allow for the new specificity that this is about SPF without > > losing the RFC 7208 distinction between verification failures and error > > conditions. > > Seems reasonable to me as well. I'll add this for the next version. Thanks. > > I am concerned about the DKIM codes. By design, DKIM doesn't give any > > basis for rejection. DKIM in particular doesn't tie the signature domain > > to > > any identities in the message. I believe the idea of author domain signed > > messages is foreign to DKIM. > > That's true, but we covered this in another thread: The point of including > the DKIM codes is not to encourage non-compliant behavior, but rather to > accept the fact that some operators do it despite the fact that DKIM has a > SHOULD NOT about it, and improve interoperability with those operators. > There's text in the -01 version (second paragraph of Section 3) that talks > about this already. If it is going to be included, it needs to be adequately caveatted. I'll have another look at it in -02. > I also agree with Ned's point about reflecting reality with these codes, > and that we've quite possibly been too strict on assigning them to date. Perhaps. As they proliferate, it's more and more likely implementations will process codes that are unknown to them. Did anyone go back and check of behavior in that case is already adequately specified? > > Much of what is in the draft about DKIM could is really about either > > completely private out of band arrangements or DMARC. I think the DKIM > > codes should probably be moved to the DMARC draft. > > > > The others make sense. > > > > If DKIM is covered, I think covering TLS makes sense to include too. > > Closely related, I wonder about DANE SMTP verification failures.? > > I agree with Ned's response on that point as well. Upon further reflection, so do it. Scott K From nobody Mon Jun 2 12:11:12 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB6C1A03F2 for ; Mon, 2 Jun 2014 12:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_19=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQAtM27S8Dm1 for ; Mon, 2 Jun 2014 12:11:09 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF3F1A0223 for ; Mon, 2 Jun 2014 12:11:09 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 4F91DD04562; Mon, 2 Jun 2014 15:11:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1401736263; bh=XJBpu0whx5VP3qz17ftUHy5z9UquUME1urKoRs9kipw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KdkNCOP6RJELh8DnvtPs6p6J05/syEuq2a5YtGvJ7qui+TC5QgTyLyj7KzoqktSLM +Npay8UaB0KKYF5aYkKPthKCTYDFeUyPhrfbi6nFdqN0zkqxa7gDS36906fBjRjiYN dK0ibKQf9FWoQCIArlyIEMATdWIpLoyOn7shWjWQ= Received: from scott-latitude-e6320.localnet (unknown [209.140.86.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E8DA4D0408C; Mon, 2 Jun 2014 15:11:01 -0400 (EDT) From: Scott Kitterman To: IETF Apps Discuss Date: Mon, 02 Jun 2014 15:10:50 -0400 Message-ID: <1716765.aF01ETVRW5@scott-latitude-e6320> User-Agent: KMail/4.13 (Linux/3.13.0-27-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: <2312436.FhlNVapo4H@scott-latitude-e6320> References: <2312436.FhlNVapo4H@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0LMOwwnMCqKnD1EfP3_0nildsbg Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 19:11:10 -0000 On Monday, June 02, 2014 14:59:59 Scott Kitterman wrote: > On Monday, June 02, 2014 10:46:53 Murray S. Kucherawy wrote: > > On Sun, Jun 1, 2014 at 11:09 AM, Scott Kitterman > > > > wrote: > > > RFC 7208 section 8 makes different recommendations based on SPF result. > > > By > > > aggregating SPF failures into a single result code, I am afraid we're > > > losing information not gaining it in some cases. > > > > > > If we could have a x.something for SPF verification failures and an > > > x.something_else for SPF error results, I believe it would be useful and > > > consistent with RFC 7208. > > > > > > The former would be for verification failures that met local policy for > > > rejection and the latter would be for SPF errors (5.x for permerror and > > > 4.x > > > for temperror). > > > > > > This would allow for the new specificity that this is about SPF without > > > losing the RFC 7208 distinction between verification failures and error > > > conditions. > > > > Seems reasonable to me as well. I'll add this for the next version. > > Thanks. Would it make sense to provide a little more detail for the SPF cases since we're overriding specific language in 7208 (should this update 7208)? Perhaps: Description: This status code is returned when a message failed an SPF check, contrary to local policy requirements. Used in place of 5.7.1 as described in Section 8.4 of [RFC7208] Description: This status code is returned when evaluation of SPF relative to an arriving message resulted in an error. Used in place of 4.4.3/5.5.2 as described in Sections 8.6/8.7 of [RFC7208] respectively. > > > I am concerned about the DKIM codes. By design, DKIM doesn't give any > > > basis for rejection. DKIM in particular doesn't tie the signature domain > > > to > > > any identities in the message. I believe the idea of author domain > > > signed > > > messages is foreign to DKIM. > > > > That's true, but we covered this in another thread: The point of including > > the DKIM codes is not to encourage non-compliant behavior, but rather to > > accept the fact that some operators do it despite the fact that DKIM has a > > SHOULD NOT about it, and improve interoperability with those operators. > > There's text in the -01 version (second paragraph of Section 3) that talks > > about this already. > > If it is going to be included, it needs to be adequately caveatted. I'll > have another look at it in -02. I looked. I think it's fine. Scott K From nobody Mon Jun 2 13:13:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCDC1A0404 for ; Mon, 2 Jun 2014 13:13:10 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCGLEKrN95xp for ; Mon, 2 Jun 2014 13:13:09 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B980E1A03A1 for ; Mon, 2 Jun 2014 13:13:08 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id k48so5840782wev.33 for ; Mon, 02 Jun 2014 13:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2L9Yg/Q9PeyAvab/qokakdXS55QfALkBshkxcgkjmuI=; b=LYwMYgWBzVi5/OFBaxbW2i+pnCDhIDYqaJcjoM/tgs6WLwyubBkjNov1LaUwiGN1WG TBHU9ijrA8DimNP4c7p5jmoeJ+fTwHVuANPP492jGIvMSHlF+fHMpLgJzVG7PmtJJpM5 YKvaqZGsAD+9WU+LcwTFbmVVnwaJH7PFW3x5FMWqD6V9Ufc+GyJ+phn7sqcZGq7XGgCU JJ4yhLOwhXGDlBDpVTvSO64RgujM/hnB8cxcKZjrcalfzzySSObkmMFZ47fQ8l5Fqz/D BYBt5q9BkxFaPoVOh0kHsPlo+nci8uxvHAjUtMUOwIMbgC8546+6Rd2wFsAkPwYa2H26 hggQ== MIME-Version: 1.0 X-Received: by 10.194.89.168 with SMTP id bp8mr53070559wjb.73.1401739982236; Mon, 02 Jun 2014 13:13:02 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Mon, 2 Jun 2014 13:13:02 -0700 (PDT) In-Reply-To: <1716765.aF01ETVRW5@scott-latitude-e6320> References: <2312436.FhlNVapo4H@scott-latitude-e6320> <1716765.aF01ETVRW5@scott-latitude-e6320> Date: Mon, 2 Jun 2014 13:13:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bf10a1cb5733904fae005bd Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/IASjEUMfoOMrORpqrfJ5YqbV-zc Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 20:13:10 -0000 --047d7bf10a1cb5733904fae005bd Content-Type: text/plain; charset=UTF-8 On Mon, Jun 2, 2014 at 12:10 PM, Scott Kitterman wrote: > Would it make sense to provide a little more detail for the SPF cases since > we're overriding specific language in 7208 (should this update 7208)? > Perhaps: > > Description: This status code is returned when a message > failed an SPF check, contrary to local > policy requirements. Used in place of 5.7.1 as > described in Section 8.4 of [RFC7208] > > Description: This status code is returned when evaluation > of SPF relative to an arriving message > resulted in an error. Used in place of > 4.4.3/5.5.2 > as described in Sections 8.6/8.7 of [RFC7208] > respectively. > > Sure, done for -03. And yes, an "updates" seems right given this change. -MSK --047d7bf10a1cb5733904fae005bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 2, 2014 at 12:10 PM, Scott Kitterman <scott= @kitterman.com> wrote:
Would it make sense to provide a little more= detail for the SPF cases since
we're overriding specific language in 7208 (should this update 7208)? = =C2=A0Perhaps:

=C2=A0 =C2=A0 =C2=A0 Description: =C2=A0 =C2=A0 =C2=A0 =C2=A0This status co= de is returned when a message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 failed an SPF check, contrary to local
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 policy requirements. =C2=A0Used in place of 5.7.1 as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 described in Section 8.4 of [RFC7208]

=C2=A0 =C2=A0 =C2=A0 Description: =C2=A0 =C2=A0 =C2=A0 =C2=A0This status co= de is returned when evaluation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 of SPF relative to an arriving message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 resulted in an error. =C2=A0Used in place of 4.4.3/5.5.2<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0as described in Sections 8.6/8.7 of [RFC7208]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0respectively.


Sure, done for -= 03.=C2=A0 And yes, an "updates" seems right given this change.
-MSK
--047d7bf10a1cb5733904fae005bd-- From nobody Mon Jun 2 15:09:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0C71A0422 for ; Mon, 2 Jun 2014 15:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.302 X-Spam-Level: X-Spam-Status: No, score=-99.302 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAAMVj0HrwE9 for ; Mon, 2 Jun 2014 15:09:00 -0700 (PDT) Received: from news.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CB7611A03A0 for ; Mon, 2 Jun 2014 15:08:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1521; t=1401746931; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=VU5CFPAcjNMvjmE3rcXoZXwYvKs=; b=RlJCws01kFoGmHVXr3jj vxF1eBjePoTe1XTy4wz0Y/De0JcuEdl92sqOY3HdI9lUr/RO3a6nUyknX/zQMN3r LNS3P5ZYEa4KBYWTD8KmCmyzYmsWDu6A54r+0bSN3SqeoZWgknGp50Euvh+31bn9 wlQYnv5adCZGfIQl+AkfYas= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 02 Jun 2014 18:08:51 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1227061291.8045.2712; Mon, 02 Jun 2014 18:08:50 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1521; t=1401746779; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=bjqOtFY /1yOBeCk31mSzsTCBebsr/qov08QvmqDrl3U=; b=n/sTXgFkX6f3yM3prP1JNDp Zsfgk1e2hMNXdDzSb4xJxtM6OqpZuAH6LxMERzYvf/emrHGEG8Xga9FmRkp2tAQ9 OSqvviKujqMJSPSAiHJkv1XsHVSIqKN+uGqZGuQD117fRv0F9kzjGHVbWjLWO6e5 PZDtkEE7Vihp7pnXUigU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 02 Jun 2014 18:06:19 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1243426343.9.3408; Mon, 02 Jun 2014 18:06:18 -0400 Message-ID: <538CF5F0.9010403@isdg.net> Date: Mon, 02 Jun 2014 18:08:48 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/K_uhIMD-Gbc2JdgR6EwH0BahdbE Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 22:09:03 -0000 > I am concerned about the DKIM codes. By design, DKIM doesn't give any > basis for rejection. Not true. Its the basic MODEL in preparation for rejection and/or acceptance (with added layers). Are you just going DKIM process mail for no reason? Its all in the functional description, it is by design, allowing software engineers to extract logic from it that ends up begin logic for rejection, acceptation and/or including discarding and quarantining. > DKIM in particular doesn't tie the signature > domain to any identities in the message. As a minimum requirement, a DKIM signature MUST be hash bound to the 5322.From identity. How does that not tie it? > I believe the idea of author > domain signed messages is foreign to DKIM. Since its initial invention with DomainKeys and its built-in author domain policy, then later with its derivative DKIM with its built-in expanded 1st and 3rd party policies called SSP which were eventually reduce to ADSP, it was always a fundamental part of the DKIM framework, despite ADSP being erroneously tossed aside by the DKIM project group. That error has finally come back to haunt DKIM in the form of DMARC. I don't see anything foreign about the author domain and DKIM. I am just noting for the archive record, I don't agree with the above statement. Its an confusing position to have about the total integrated concepts involved. What is stated above is akin to saying the original mail return path/sender is foreign to SPF. -- HLS From nobody Mon Jun 2 16:06:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798631A03E7 for ; Mon, 2 Jun 2014 16:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXJIKmxv0-1M for ; Mon, 2 Jun 2014 16:06:20 -0700 (PDT) Received: from news.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id EB0FD1A03C4 for ; Mon, 2 Jun 2014 16:06:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2042; t=1401750370; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=KDROQaZzDXWHEDZz9fGCBy030oM=; b=fuU2iS1pgcksFkQsj6Hx tdYoMLhqBfp6LDC6v05zcoNy1j71F8JyEgdpK798lVdmZsoF0u8wPmjowEcZcy0S YsBjuTEp8R/rQKHNRE3yp6/Gch8H+GJdj5AzVLosQjyrcE8i12wX20vryVAjcFk/ +TzDZ7/UvMm5q9mh9FtHqO0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 02 Jun 2014 19:06:10 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1230501503.8045.2660; Mon, 02 Jun 2014 19:06:10 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2042; t=1401750219; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=u7Wp+Ta 1qJjBFInuaSHlmensJYichMvsnDIfiy4zTKg=; b=eUzs8+ubOGP9U8J0vy8SO/6 tpcz0wNHnma43E3kBO1aL8rg07D7UDkOf69WCJcY7YBUjbcJz4EuTXdlD8Z8901o 3pYfA9dTE4RPbw1Gn/kdqEpoRVGd6NWplRComcHQh9x3cnBsjZ+2q3eZ/HyAsq6p ea9DOcldKR+5dBR2JfgQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 02 Jun 2014 19:03:39 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1246865781.9.5104; Mon, 02 Jun 2014 19:03:38 -0400 Message-ID: <538D0360.90806@isdg.net> Date: Mon, 02 Jun 2014 19:06:08 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: IETF Apps Discuss References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8jZFXPJfdBsRmlEBGVWPlw3EIjQ Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 23:06:23 -0000 On 6/2/2014 1:46 PM, Murray S. Kucherawy wrote: > That's true, but we covered this in another thread: The point of > including the DKIM codes is not to encourage non-compliant behavior, > but rather to accept the fact that some operators do it despite the > fact that DKIM has a SHOULD NOT about it, and improve interoperability > with those operators. I'm not going to dwell on this, but this is odd to me. Do you really know of any raw DKIM-BASE only receivers that are rejecting based on raw DKIM-base processing results only and nothing else as part of the raw verification equation? In other words, no common, open public proposed standard or method is being explored? If that is the case, then it would be in violation of DKIM when a *LOCAL POLICY" uses RAW DKIM-BASE processing only for that determination. I just think doc is still a little ambiguous about how and when to use these codes. It is not clear and the first question implementers may probably ask is: "How can they use these codes without violating DKIM?" The 5.7.21 description is still ambiguous: Code: X.7.21 Sample Text: No valid author DKIM signature found Description: This status code is returned when a message did not contain a valid DKIM signature matching the domain(s) found in the From header field, contrary to local policy requirements. (Note that this violates the advice of Section 6.1 of RFC6376.) You can have a valid signature. Its just not authorized. Unless you mean x.7.20 folds missing and invalid, and x.7.21 implies valid but unauthorized, you might need a third code: Code: X.7.22 Sample Text: No AUTHORIZED DKIM signature found Description: This status code is returned when a message contains a valid DKIM signature but it is not authorized by the matching the domain(s) found in the From header field. I hope you don't fast track this. You got DMARC and also 3rd party Protocols to finish and all this needs to be review then too as well. It may change. -- HLS From nobody Tue Jun 3 10:42:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2AF1A0256 for ; Mon, 2 Jun 2014 09:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRkaoISPKKa7 for ; Mon, 2 Jun 2014 09:14:01 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E43C1A0141 for ; Mon, 2 Jun 2014 09:14:01 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5C750135D072; Mon, 2 Jun 2014 18:13:54 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 489AF135D070; Mon, 2 Jun 2014 18:13:54 +0200 (CEST) Message-ID: <1401725634.5613.86.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "\"Martin J." =?ISO-8859-1?Q?D=FCrst=22?= Date: Mon, 02 Jun 2014 18:13:54 +0200 In-Reply-To: <5379D7D7.8020202@it.aoyama.ac.jp> References: <5379D7D7.8020202@it.aoyama.ac.jp> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20734.000 X-TM-AS-Result: No--26.538-7.0-31-1 X-imss-scan-details: No--26.538-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3_UTJMfo67Ovetr0AJcoE9SRkh0 X-Mailman-Approved-At: Tue, 03 Jun 2014 10:42:35 -0700 Cc: draft-ietf-p2psip-diagnostics.all@tools.ietf.org, "apps-discuss@ietf.org" , Brian Rosen Subject: Re: [apps-discuss] [APPS-REVIEW] review of draft-ietf-p2psip-diagnostics-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:14:05 -0000 Hi Martin, authors, all, @Martin: Thank you very much for your review. @authors: please address Martin's comments and generate a new version of the draft. Thanks! Carlos On Mon, 2014-05-19 at 19:07 +0900, "Martin J. Dürst" wrote: > I have been selected as the Applications Area Review Team reviewer for > this draft (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-p2psip-diagnostics > Title: P2P Overlay Diagnostics > Reviewer: Martin J. Dürst > Review Date: various days before and including May 19, 2014 > IETF Last Call Date: not yet > IESG Telechat Date: not yet > > > Summary: To me, the draft looks in reasonable shape, with some issues to > be fixed as bellow. However, I'm not a SIP or P2P expert, and therefore > this review shouldn't be taken as an active endorsement of the draft. > > > Preface: I sincerely apologize for the long time it took me to review > this draft. I have reviewed -13, but I have also checked the diff at > http://tools.ietf.org/rfcdiff?url2=draft-ietf-p2psip-diagnostics-14.txt > to make sure I haven't missed anything new. > > > Overall issue: There were quite a few places in the text where the > wording choice was somewhat suboptimal. I strongly recommend a review by > a native English speaker familiar with the subject. > > > Minor issues: > > Structure: The meat of the draft is all in section 5. It may make sense > to split that section (but merge others) to get a better balance. But I > can't give a specific proposal, sorry. The start of section 5 also reads > like an abstract for a whole document. > > p. 9: DiagnosticRequest has 'dmFlags' before 'length', but in the text, > the order is reversed. Please align. > > p. 10: There is only a single 'kind' code (0xFFFE) reserved for private > use. Given that currently only about 16 such codes are defined in the > spec, it seems okay to reserve a somewhat larger number of these codes > for private/experimental use. > > 5.1.2, timestamp_received (and timestamps in general): is a resolution > of milliseconds good enough? It may be way more than actually useful in > a world-wide overlay, but it could be less than desirable in a local > deployment. Same also for the limits (10 to 600 seconds) on the > expiration field. A local network should probably not need a timeout of > 10 seconds. > > 5.1.3, PROCESS_POWER, BANDWIDTH: 32bits of MIPS and Kbps seem to cover > the current range of hardware, but what about extremely slow hardware or > very fast hardware in a few years? Similar for bandwidth. What about > e.g. defining some kind of log scale, which may reflect the long-term > realities of technology and market better? Same for MEMORY_FOOTPRINT. > 5.1.3, SOFTWARE_VERSION: there is a '*', is that supposed to be some > kind of syntax indicator (e.g. repetition as in regular expressions)? > The example should be put into quotes. > > 5.1.3, BATTERY_STATUS: "using a battery power" -> "using battery power" > > 5.2: "and will treat the message if it was a normal ping" -> "and will > treat the message *AS* if it was a normal ping" > > 5.4: I'm surprised that this diagnostics document has to define an error > code for "Underlay Destination Unreachable". Shouldn't such an error > condition occur in the base protocol already? > > 5.5.1: There are way too many MUSTs here. It would be much better to put > limitations on field values where these field values are defined, and > just describe the limitations in positive language. > > 5.5.1: The first paragraph uses "Ping message with diagnostic > extension", the second paragraph uses "diagnostic Ping message". Please > unify terminology. > > 5.5.3: The first two paragraphs semantically form one single sentence. > The first paragraph forms one syntactical sentence. Both of these are > too long. > > In the first paragraph, it is impossible to understand to what clauses > the initial "When" applies without rereading the paragraph. Please fix. > > Section 6: Just to check, would this be what's described in this section: > > > > > > > > Would also be okay? Or should it be > ? Things like these should be carefully > specified. An actual example also will help. > > 8.1 and 8.5: Rather than creating two registries that have to be kept in > sync, it would be better to create one registry where the first 64 > entries have more columns than the rest. > > 8.6: "XML namespaces": I only see one namespace. Is the intent that the > example above actually be written e.g. like > xmlns='urn:ietf:params:xml:ns:p2p:config-diagnostics'> > > > > > > Why is there a need for a separate namespace for just one or two > elements? It's a common misconception that each spec that defines a bit > of XML has to have its own namespace. As long as there is coordination > to avoid element name collisions (which should be achievable e.g. in an > IETF WG), there's absolutely no need for such piecemeal namespaces. > > : I'm not at all sure it's a good idea to use an > XML namespace URI to identify protocol/format extensions. But it may > already be too late to fix this. > > > Regards, Martin. > From nobody Tue Jun 3 17:41:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D621A0350; Tue, 3 Jun 2014 17:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyWSixA48zLB; Tue, 3 Jun 2014 17:41:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B661A03B1; Tue, 3 Jun 2014 17:41:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140604004116.3906.4059.idtracker@ietfa.amsl.com> Date: Tue, 03 Jun 2014 17:41:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1y11aXSCf3Z8YycajLh-xizvqDE Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-multimailbox-search-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 00:41:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : IMAP4 Multimailbox SEARCH Extension Authors : Barry Leiba Alexey Melnikov Filename : draft-ietf-appsawg-multimailbox-search-01.txt Pages : 12 Date : 2014-06-03 Abstract: The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting round trips delay, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-multimailbox-search-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multimailbox-search-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 3 22:37:03 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698621A008F for ; Tue, 3 Jun 2014 22:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxdkh_nkQSyV for ; Tue, 3 Jun 2014 22:36:58 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4DA1A008A for ; Tue, 3 Jun 2014 22:36:58 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8LD063N8W003NAT@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 3 Jun 2014 22:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1401859911; bh=pm5bZNjxvxcKAP770wCobJqQSMNFcsKYdUkmmHGHYNg=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=k+pPdVMc1bvz2Nl3pKH0gtlcj/IWCOk1soLP16dZtV5WeXxDQeSsivLxcgKXOT4tN 1wVTERK2537ELiYU6ngkooWSE8k885dFk1Qw6Ujpf/B0MPL4r0d5DIm0caL4u+eu// 8soORsu8s9dbYfFyI6GlLzf0DBBiZjqtTHwKKVBk= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8KJV8YJCW000054@mauve.mrochek.com>; Tue, 03 Jun 2014 22:31:47 -0700 (PDT) Message-id: <01P8LD046PI6000054@mauve.mrochek.com> Date: Tue, 03 Jun 2014 22:31:05 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 02 Jun 2014 10:40:13 -0700" References: <8D87868A-7739-4085-8F1C-4DBDE40B2BE7@isode.com> <01P8HNOPBWDC000054@mauve.mrochek.com> To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RdAB0N9DB0X-BV_SQP3A87Euj9o Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-email-auth-codes-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2014 05:36:59 -0000 > On Sun, Jun 1, 2014 at 6:51 AM, Ned Freed wrote: > > > > > The DKIM specification says that an unsigned message is to be treated no > > > differently than one with a signature that failed to verify. I also > > don't > > > know of any receivers that only care that there was a valid signature > > > regardless of the domain that added it, so that doesn't seem to be a use > > > case we need to worry about. > > > > I agree with this analysis, however, it may be worth adding a bit of > > text referring to where the DKIM specification says this. > > > Paragraph 2 of Section 3 already contains that reference. Do we need to > say more than that? It's a reference in a somewhat different context. But given that it's the same reference, I guess that's good enough. Ned From nobody Tue Jun 3 23:29:36 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CD91A00A9; Tue, 3 Jun 2014 23:29:34 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OE29sPm8xycU; Tue, 3 Jun 2014 23:29:33 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53991A009C; Tue, 3 Jun 2014 23:29:32 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so7739444wgg.13 for ; Tue, 03 Jun 2014 23:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YnyK6Dyg232zl15GHBeWxdRONpJK1S1PJD8t3mDvDpY=; b=UBm+ySIktN+fZFHtb3j6N0OM1SbmcU7p5cEEbn7a2F/Fg7+Rn2jdR8NyUz1CQTAHjr 9Sbo6A4+ssJzTQ4gDlEp49/jo5SS7cC8K6qVbnuZnHEKQWgBS/gymiVH5OSAyXVIn4hJ gn+jPQisNjDbQtL94L90NFE27wvRYHMDs4o4/kvhb5tW3egLfTaoQzlk0tyEk/NbWeNg ItcjPNn6+V469GCqEEMAJi3EfLbLoLu6IKf+Pn97jNBS3ARdq/BzUeASPMvw+jC21ETH /cf1HapdR1DEzKbVXFg21SmW1LFHHqrro5wu6RynyWKZC9ZtQ+D5432SOLD64/spPKqX R41g== MIME-Version: 1.0 X-Received: by 10.195.17.169 with SMTP id gf9mr68266105wjd.10.1401863365477; Tue, 03 Jun 2014 23:29:25 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Tue, 3 Jun 2014 23:29:25 -0700 (PDT) Date: Tue, 3 Jun 2014 23:29:25 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss , imapext@ietf.org Content-Type: multipart/alternative; boundary=089e01681bfcec4c7304fafcbf57 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/160qokC5_SNVL5ueE-_0A76GuSQ Subject: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-multimailbox-search X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2014 06:29:34 -0000 --089e01681bfcec4c7304fafcbf57 Content-Type: text/plain; charset=UTF-8 Colleagues, This note starts a Working Group Last Call for draft-ietf-appsawg-multimailbox-search. This was introduced after the London meeting for movement from Experimental status to Proposed Standard. The discussion about doing so, with implementation details, took place on the imapext list and can be found in the archive for that list. (Barry did ask them to post to apps-discuss, but they didn't.) Please provide review comments either on this list or privately to draft-ietf-appsawg-multimailbox-search.all@tools.ietf.org on or before June 20, 2014. Also, if any participant has knowledge of IPR that needs to be declared on this work, please do so, as required by BCPs 78 and 79. -MSK, APPSAWG co-chair and document shepherd --089e01681bfcec4c7304fafcbf57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

This note starts a Working Gr= oup Last Call for draft-ietf-appsawg-multimailbox-search.=C2=A0 This was in= troduced after the London meeting for movement from Experimental status to = Proposed Standard.=C2=A0 The discussion about doing so, with implementation= details, took place on the imapext list and can be found in the archive fo= r that list.=C2=A0 (Barry did ask them to post to apps-discuss, but they di= dn't.)

Please provide review comments either on this list or privately t= o draft-ietf-appsawg-multimailbox-search.all@tools.ietf.org on or bef= ore June 20, 2014.

Also, if any participant has knowledge of IPR that needs to be de= clared on this work, please do so, as required by BCPs 78 and 79.

-M= SK, APPSAWG co-chair and document shepherd
--089e01681bfcec4c7304fafcbf57-- From nobody Wed Jun 4 13:34:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86121A02F0 for ; Wed, 4 Jun 2014 13:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-IXJEdMOwod for ; Wed, 4 Jun 2014 13:33:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE251A0085 for ; Wed, 4 Jun 2014 13:33:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 36E7F18000D; Wed, 4 Jun 2014 13:32:55 -0700 (PDT) To: paul.hoffman@vpnc.org, john+ietf@jck.com, barryleiba@computer.org, presnick@qti.qualcomm.com, superuser@gmail.com, Salvatore.Loreto@ericsson.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140604203255.36E7F18000D@rfc-editor.org> Date: Wed, 4 Jun 2014 13:32:55 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wPMI2NZnhs_IcxsaXfyKTLT4w4o Cc: john=ietf@jck.com, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2014 20:33:59 -0000 The following errata report has been submitted for RFC6365, "Terminology Used in Internationalization in the IETF". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6365&eid=4005 -------------------------------------- Type: Editorial Reported by: John Klensin Section: GLOBAL Original Text ------------- US-ASCII Corrected Text -------------- ASCII Notes ----- The term "US-ASCII" is an IETF artifact, left over from some misunderstandings about what "ASCII" referred to (and the complete absence of CSCII or CASCII, MSCII or MXSCII, BRSCII, ARSCII, and other "American" coded character sets). It is a source of confusion for people who come to IETF specifications with a background in coded character sets and terminology from other areas or standards bodies and has been warned against multiple times. It should not have appeared in this document except possibly with a warning against its use (and the use of other bogus terms like "ASCII7"). The second author, who is normally sensitive to the issue, has no idea how this got past him, even in text picked up from other documents, but supposes this is what errata are for. In any event, there is no such thing as "US-ASCII": the term is an erroneous and misleading synonym/ substitute for "ASCII". The reference for the latter is correct, but the citation anchor should probably be corrected as well. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6365 (draft-ietf-appsawg-rfc3536bis-06) -------------------------------------- Title : Terminology Used in Internationalization in the IETF Publication Date : September 2011 Author(s) : P. Hoffman, J. Klensin Category : BEST CURRENT PRACTICE Source : Applications Area Working Group Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed Jun 4 13:52:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023E01A035D for ; Wed, 4 Jun 2014 13:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xflzFSsbq7aq for ; Wed, 4 Jun 2014 13:52:42 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B921A0351 for ; Wed, 4 Jun 2014 13:52:41 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id b8so32809lan.9 for ; Wed, 04 Jun 2014 13:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=RZ96KICWjttrSRk+pcgs/CWPM1WYxxqIZhjF+oNGUSE=; b=Uss/eiu+BHTkrA4xmBL8fMRIsrEMUi6SvZ9ilpW8D85QLujOLkp8jjM61bJEzG+I4c mnqEcccNL3cs6KKCbpvA1xKBmqlu2fA2fbQ+JTwYITxQRtn6phhAhJJCTbcHXrQ4JWfn 3G+WjIOgpvi8k/8ZZxecfEgJiG9hdL7mDIMy9LBjGXtby0z4pY1xZYbnwxtdPVUmDhxg A2CzJhKShLBWUQ96t02XMsP4vCEtwqN/g3JBz6p6ViJtTUy6tVmY4WZKgdPrTSAZ2aT5 oCDXIHr/fw8EdMvtCAT2cFVXdSIK2W9jZIa49iHKVHZdG/u5kVCcGYIGoMD19fxQF3ub zzfg== MIME-Version: 1.0 X-Received: by 10.112.219.73 with SMTP id pm9mr16157621lbc.48.1401915154083; Wed, 04 Jun 2014 13:52:34 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.206.9 with HTTP; Wed, 4 Jun 2014 13:52:34 -0700 (PDT) In-Reply-To: <20140604203255.36E7F18000D@rfc-editor.org> References: <20140604203255.36E7F18000D@rfc-editor.org> Date: Wed, 4 Jun 2014 16:52:34 -0400 X-Google-Sender-Auth: 92NkUqVM6H8l6AAf0yrM9P3POKg Message-ID: From: Barry Leiba To: RFC Errata System Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JEAXjnpIDij8_di9RN7dtnzZ7Fs Cc: Apps Discuss , john=ietf@jck.com, Pete Resnick , Paul Hoffman , "John C. Klensin" Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2014 20:52:43 -0000 John, your argument may well be absolutely correct, but this is also absolutely *not* an error in the specification. You and Paul certainly *meant* to say "US-ASCII", and, while in retrospect perhaps you shouldn't have, it's not an issue for an errata report. Am I wrong here? Barry On Wed, Jun 4, 2014 at 4:32 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC6365, > "Terminology Used in Internationalization in the IETF". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6365&eid=3D4005 > > -------------------------------------- > Type: Editorial > Reported by: John Klensin > > Section: GLOBAL > > Original Text > ------------- > US-ASCII > > Corrected Text > -------------- > ASCII > > Notes > ----- > The term "US-ASCII" is an IETF artifact, left over from some misunderstan= dings about what "ASCII" referred to (and the complete absence of CSCII or = CASCII, MSCII or MXSCII, BRSCII, ARSCII, and other "American" coded charact= er sets). It is a source of confusion for people who come to IETF specific= ations with a background in coded character sets and terminology from other= areas or standards bodies and has been warned against multiple times. It = should not have appeared in this document except possibly with a warning ag= ainst its use (and the use of other bogus terms like "ASCII7"). The second= author, who is normally sensitive to the issue, has no idea how this got p= ast him, even in text picked up from other documents, but supposes this is = what errata are for. > > In any event, there is no such thing as "US-ASCII": the term is an errone= ous and misleading synonym/ substitute for "ASCII". The reference for the = latter is correct, but the citation anchor should probably be corrected as = well. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6365 (draft-ietf-appsawg-rfc3536bis-06) > -------------------------------------- > Title : Terminology Used in Internationalization in the IET= F > Publication Date : September 2011 > Author(s) : P. Hoffman, J. Klensin > Category : BEST CURRENT PRACTICE > Source : Applications Area Working Group > Area : Applications > Stream : IETF > Verifying Party : IESG From nobody Wed Jun 4 14:06:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC371A03DF for ; Wed, 4 Jun 2014 14:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVI-cMWjylkg for ; Wed, 4 Jun 2014 14:06:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503B91A03F2 for ; Wed, 4 Jun 2014 14:06:05 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s54L5oiW055818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Jun 2014 14:05:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: <20140604203255.36E7F18000D@rfc-editor.org> Date: Wed, 4 Jun 2014 14:05:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140604203255.36E7F18000D@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/pjuuB8rZCe7jIGwLbdc1vDVRTBI Cc: apps-discuss@ietf.org, john=ietf@jck.com, Pete Resnick , john+ietf@jck.com, Barry Leiba Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2014 21:06:07 -0000 I'm not sure how to deal with this errata. grep tells me that the term = "US-ASCII" appears to have been invented in the first MIME specs, = starting with RFC 1341. The reference to it is just the ANSI spec, which = does not appear to have "US-ASCII" in the title. However, grep also tells me that the term appears in about 370 RFCs. I = propose that trying to change it now would be indistinguishable from a = DoS attack on the RFC errata system. A proposed counter-proposal for this would be as follows. Section: New section 1.4 to be added Original Text ------------- (none) Corrected Text -------------- Throughout this document and hundreds of other RFCs, the term "US-ASCII" = is used in text and in references to refer to the coded character set = defined by ANSI as "Coded Character Set -- 7-bit American Standard Code = for Information Interchange, ANSI X3.4-1986". Although the term = "US-ASCII" has been popular for more than two decades, it is incorrect: = it should just be called "ASCII". There is no "US-ASCII" defined, and = using the "US-" prefix can cause confusion to readers who wonder what = that prefix means. If the chairs/ADs agree with this, you should reject John's errata and = I'll submit mine with any edits you like. As a side note: On Jun 4, 2014, at 1:32 PM, RFC Errata System = wrote: > The second author, who is normally sensitive to the issue, has no idea = how this got past him, even in text picked up from other documents, but = supposes this is what errata are for. The second author did not contact the first author before submitting = this errata. Further, the first author notes that the second author has = used the term in many of said second author's earlier RFCs. Further, the = first author disagrees that this is what errata is for. --Paul Hoffman= From nobody Wed Jun 4 16:01:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F0D1A0384 for ; Wed, 4 Jun 2014 16:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o38wjyjfXYWQ for ; Wed, 4 Jun 2014 16:01:24 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89FCB1A037F for ; Wed, 4 Jun 2014 16:01:24 -0700 (PDT) Received: (qmail 1160 invoked from network); 4 Jun 2014 23:01:17 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 4 Jun 2014 23:01:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14957.538fa53d.k1406; i=johnl@user.iecc.com; bh=+Rt7cexnZlBh7WRV1oB9+jsuMnXguXyiq8xYFTMNf0s=; b=DIWjUL07YKwaWY9dHPjoZxuiRWx4LfGy0f/OzJf0/klOUyILSySdMr8f5o/mN6FnW3JQ0z2+S3aekjNVqoQowaunnFovNKJ7w4N5/4OvnyNPNIPqUWd5KPjYVbfjPvz2ZwmMXol/OBZoi5JkMx2utyBWz7sPOEj3Oi4TZWgW29CRbost7vWPZPdaEgZOPJydq1fu5I1PRRpayfR1tVaLUDL7es3NFddFi87dTdU80jAN2ZnGBH8pwCogCrOsOcgQ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14957.538fa53d.k1406; olt=johnl@user.iecc.com; bh=+Rt7cexnZlBh7WRV1oB9+jsuMnXguXyiq8xYFTMNf0s=; b=WOq+3nZbeIRgthxjPzYGigigk8K9Q1oem71YKnCjERmD/QhP50Z7rX1OCox/ji1rQYhD2xJ1pcltdQon3g66FwOtzxvW6QxDB3qA1wG+RrWxZV4UoXzDW0i4ML2DJKPg43SffyUWpnFQgPTS7b3pH5peQKPSYaqaOKdSTj48iiFN73L0tIjwQ4ZBTUPVlNxJixpMTKbc5CUBODR36BhectYoO4FEbLHVvEH4+CROeM34BP6UyaU1wtKKjPW+Dk1R Date: 4 Jun 2014 23:00:55 -0000 Message-ID: <20140604230055.84310.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/yKWJZVrc39RNKLUJAYwbrz_TfWI Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2014 23:01:26 -0000 Section 4 says: By the nature of the Simple Mail Transfer Protocol (SMTP), only one enhanced status code can be returned for a given exchange between client and server. ... Is that true? When I read RFC 3463 and RFC 5321, I don't see any advice about when or where to present the status codes other than a largely implicit assumption that they go in the reply string. I don't see why this wouldn't be valid: 550 Your mail stinks (5.7.25) because it has no DKIM (5.7.20) and no SPF (5.7.22). There are practical issues, like whether recipient MTAs are likely to do anything useful with multiple status codes, but that's a separate question. R's, John From nobody Wed Jun 4 16:23:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849741A03C9 for ; Wed, 4 Jun 2014 16:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOao6wFd8arn for ; Wed, 4 Jun 2014 16:23:50 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FF201A03A1 for ; Wed, 4 Jun 2014 16:23:50 -0700 (PDT) Received: from [192.168.80.56] (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id EA3042DED3 for ; Wed, 4 Jun 2014 16:23:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Steve Atkins In-Reply-To: <20140604230055.84310.qmail@joyce.lan> Date: Wed, 4 Jun 2014 16:23:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140604230055.84310.qmail@joyce.lan> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0B2CpjgbxtjnwORwCXUyg1nHCGE Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2014 23:23:51 -0000 On Jun 4, 2014, at 4:00 PM, John Levine wrote: > Section 4 says: >=20 > By the nature of the Simple Mail Transfer Protocol (SMTP), only one > enhanced status code can be returned for a given exchange between > client and server. ... >=20 > Is that true? When I read RFC 3463 and RFC 5321, I don't see any > advice about when or where to present the status codes other than a > largely implicit assumption that they go in the reply string. >=20 > I don't see why this wouldn't be valid:=20 >=20 > 550 Your mail stinks (5.7.25) because it has no DKIM (5.7.20) and no = SPF (5.7.22). >=20 > There are practical issues, like whether recipient MTAs are likely to > do anything useful with multiple status codes, but that's a separate > question. RFC 2034 says enhanced status codes must appear at the beginning of each response line. I'm not sure they're anything other than human readable text if they appear elsewhere. Cheers, Steve= From nobody Wed Jun 4 16:58:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF99F1A03DB for ; Wed, 4 Jun 2014 16:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HxG9FLpTW2s for ; Wed, 4 Jun 2014 16:58:46 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C558C1A03D8 for ; Wed, 4 Jun 2014 16:58:45 -0700 (PDT) Received: (qmail 9981 invoked from network); 4 Jun 2014 23:58:39 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 4 Jun 2014 23:58:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14a16.538fb2ae.k1406; i=johnl@user.iecc.com; bh=tb39QRMIh8iDWKHFr5ruXWaw5IYHz5RaoFKTyCAlVjw=; b=gWIv43QJbOszcmx/nlnWi6SG0FC+lGXplTJL3Z7YwlKIaFiIcyRR8TMkavRAfMllpIjWaL0I0mjoHTjNmpT8HCWeNIn11mvRTcHenjvgLVR2slysYtAxZSR1jS2LYaAzOnWT7+Q7LgvpVzhRjXUMcVBDe3hG5z8tcgnbxRgGXq8U7PXD1AE52Uj30wYElxM+/aAf00nq+cUaluPxkecwWOGBN2F+lBg3DzjyPUMPrANDLpFUvi983AkiD8hIk26m DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14a16.538fb2ae.k1406; olt=johnl@user.iecc.com; bh=tb39QRMIh8iDWKHFr5ruXWaw5IYHz5RaoFKTyCAlVjw=; b=ErmJVWph+kWI3vryD924Mkd8TW4nUKW9CafX4nXBGooXKaaGKvKVCB+Vl52T/Q6z3OGjrLCfhdnktB1J768H9nEQJu7ZXIOQfGsLmo2Y3VC4qYFZf8OzuODruaX4PA4RgCYDoqjQxelPGSO16Kt4wGcYz1D9sEx7E2pZG5TWKidKAIbSV3GMrwYB2p4I7PMY6ybhOjWxb2EjABBwPJyNd9meaVHqgq0bU7Qyehs0X32pow4LPcmTf/EtKNNKnpkf Date: 4 Jun 2014 23:58:16 -0000 Message-ID: <20140604235816.84501.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Af5tnyajK3L_Ld6jQZ-epiATXAM Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2014 23:58:46 -0000 >RFC 2034 says enhanced status codes must appear at the beginning >of each response line. I'm not sure they're anything other than human >readable text if they appear elsewhere. Oh, look at that. "Never mind". Sure would have been nice if 3463 or 5321 had a reference to it. R's, John From nobody Wed Jun 4 17:14:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E141A03DC for ; Wed, 4 Jun 2014 17:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYEgS-L9YjF8 for ; Wed, 4 Jun 2014 17:14:18 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id C4BDA1A03DB for ; Wed, 4 Jun 2014 17:14:18 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8MG1G9CCW004XUN@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 4 Jun 2014 17:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1401926952; bh=U9l4BiTzuvxYm6Vco3ht8CJsFWPAQZ1kpKfFKbeetys=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=sJztRoXCSL6b9atuQqxiF9ozbIDTuomTGrp++Q3/glhH/Ok/m33pPs9k2idMUiZYi HkL39cLHbsAeKdmmbn8fjeFfM2uUywtjf+MzzPsMd9+2NHCTL/V64BEQNWFCdftft2 vsPsbAeUeqTBMpIHzZ5SL3r82zdgK32yt4Fi0Eo0= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8M34L23V40049PU@mauve.mrochek.com>; Wed, 04 Jun 2014 17:09:07 -0700 (PDT) Message-id: <01P8MG1EGM8Q0049PU@mauve.mrochek.com> Date: Wed, 04 Jun 2014 14:46:58 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 04 Jun 2014 16:52:34 -0400" References: <20140604203255.36E7F18000D@rfc-editor.org> To: Barry Leiba Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0zQ391Fn_Pc_Yjo9uE-HhYYe1kU Cc: Apps Discuss , john=ietf@jck.com, Pete Resnick , Paul Hoffman , "John C. Klensin" , RFC Errata System Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2014 00:14:21 -0000 This errata may represent the way you would like things to be, it's factually incorrect and doesn't represent the way things are. "US-ASCII" is the registered charset name for what's defined in ANSI X3.4-1986. Not "ASCII". It's the charset various important media types default to, and it's the name that appears throughout RFC 2046 as well as many other RFCs. And if you use any other name for this charset, including but not limited to plain "ASCII", you're not going to like the results. As such, there absolutely is such a thing a "US-ASCII" and it's far more than an "IETF artefact" at this point. Les jeux sont faits, rein ne va plus. I note in passing that the text in RFC 6365 is incorrect in another way: It effectively says that "charset" and "character encoding scheme" are equivalent. They aren't. A charset is, as RFC 6365 correctly says, a mapping from a sequence of octets to a sequence of characters. A character encoding scheme (CES), OTOH, is a means of translating a sequence of integers into a sequence of octets. And a coded character set (CCS) is a 1:1 mapping between a set of characters and a set of integers. When you combine one or more CCSes and a CES you obtain a means of translating from characters to octets. This is the inverse of a charset, more or less. Charset was defined the way it was because we very consciously and deliberately *rejected* the ISO approach to this stuff when MIME was specified. The main problem with the CCS/CES thing is that it's inherently ambiguous: For example, if even a subset of ISO 2022 is part of your CES, you now have a one-to-many mapping - and an interoperability mess in the making. Charset, on the other hand, is clean, simple and precise. It focuses on interpretation rather than creation of the octet stream, which is what you want when interoperability is your primary goal. As always, the proof is in the pudding. There are any number of examples of the suckage of the ISO approach to this problem - generaltext anyone? - but the one I like to use is the combination of RFC 1468 and RFC 2047. In brief, RFC 1468 says that you can't have two adjacent double byte segments. RFC 2047 then says that any such segment must be entirely enclosed in an encoded-word. It also says that spaces (which would count as a single byte segement) between encoded words are to be removed. Which, unless you go to a lot of trouble to remove the single-byte-seq double-byte-seq pairs, results in illegal iso-2022-jp. This is what happens when you use an overly complex approach built on decades of accreted bad design. Now, as you might have already guessed, my sympathy level for the poor ISOers who are confused by the approach the IETF took to this problem is low. Actually, make that nonexistant. The character set space is a huge mess in large part due to the way the ISO has handled it. And like it or not, failure has consequences. The "US-ASCII" label is one of them. Ned > John, your argument may well be absolutely correct, but this is also > absolutely *not* an error in the specification. You and Paul > certainly *meant* to say "US-ASCII", and, while in retrospect perhaps > you shouldn't have, it's not an issue for an errata report. > Am I wrong here? > Barry > On Wed, Jun 4, 2014 at 4:32 PM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC6365, > > "Terminology Used in Internationalization in the IETF". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=6365&eid=4005 > > > > -------------------------------------- > > Type: Editorial > > Reported by: John Klensin > > > > Section: GLOBAL > > > > Original Text > > ------------- > > US-ASCII > > > > Corrected Text > > -------------- > > ASCII > > > > Notes > > ----- > > The term "US-ASCII" is an IETF artifact, left over from some misunderstandings about what "ASCII" referred to (and the complete absence of CSCII or CASCII, MSCII or MXSCII, BRSCII, ARSCII, and other "American" coded character sets). It is a source of confusion for people who come to IETF specifications with a background in coded character sets and terminology from other areas or standards bodies and has been warned against multiple times. It should not have appeared in this document except possibly with a warning against its use (and the use of other bogus terms like "ASCII7"). The second author, who is normally sensitive to the issue, has no idea how this got past him, even in text picked up from other documents, but supposes this is what errata are for. > > > > In any event, there is no such thing as "US-ASCII": the term is an erroneous and misleading synonym/ substitute for "ASCII". The reference for the latter is correct, but the citation anchor should probably be corrected as well. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6365 (draft-ietf-appsawg-rfc3536bis-06) > > -------------------------------------- > > Title : Terminology Used in Internationalization in the IETF > > Publication Date : September 2011 > > Author(s) : P. Hoffman, J. Klensin > > Category : BEST CURRENT PRACTICE > > Source : Applications Area Working Group > > Area : Applications > > Stream : IETF > > Verifying Party : IESG > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Wed Jun 4 20:31:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25641A0002; Wed, 4 Jun 2014 20:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6vBC_jPf91H; Wed, 4 Jun 2014 20:31:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD2C1A0010; Wed, 4 Jun 2014 20:31:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140605033120.19678.66014.idtracker@ietfa.amsl.com> Date: Wed, 04 Jun 2014 20:31:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/4sT40MjraK1TsaESMouy6SFjbRo Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 03:31:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A NULL MX Resource Record for Domains that Accept No Mail Authors : John Levine Mark Delany Filename : draft-ietf-appsawg-nullmx-03.txt Pages : 6 Date : 2014-06-04 Abstract: Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately this means that the A/ AAAA record is taken to be mail server address even when that address does not accept mail. The NULL MX RR formalizes the existing mechanism by which a domain announces that it accepts no mail, which permits significant operational efficiencies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-nullmx-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-nullmx-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 4 20:33:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAE71A000E for ; Wed, 4 Jun 2014 20:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BayyYytXbd5 for ; Wed, 4 Jun 2014 20:33:26 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC411A0002 for ; Wed, 4 Jun 2014 20:33:26 -0700 (PDT) Received: (qmail 41952 invoked from network); 5 Jun 2014 03:33:19 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 5 Jun 2014 03:33:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14d4d.538fe4ff.k1406; i=johnl@user.iecc.com; bh=IdsVE0Fm6uPRowrwckdH6F30yMpxQys7f7SkBf/baT8=; b=n9Gua3m5WinfB895ry9JNwiXO8LCjHju3lbHuGhFS58Wl4TIB7WCl80qvwCHG0ndwuiRRhJkXPcORDv9Dlq7jMNZmy4g6InLir8hAIlSM303nS80U/n6L55Tc2vbko6zW0FiHu8jBcuiauFcaZsOtscJDh8/YSZ21pjF29JzCMNJYj5LPQytKk4kk01KaevsLbDMdMg7juLNt9Pr136tfss1/4+1pN+dmnt6xGS91M6ylKk+Q2zG749OX9JLiWcL DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14d4d.538fe4ff.k1406; olt=johnl@user.iecc.com; bh=IdsVE0Fm6uPRowrwckdH6F30yMpxQys7f7SkBf/baT8=; b=dhbdjJcl6QNCvsyVmebbKYkva+I4d3oQt8hb+chjQ8r0ikv9VOxmkhgPgl76ZgrhFhFhTahBx7HZY8vaHJAoGlkCH6dIqONR+7p9wir0SMg5MxaPLvgC04+A4VxCRQgXhSMFV73ZQwBfvDcdYoGtjiWAxr7wBRZjsavTO8O5U7ynYdTGuhLRcrW6eOuXQKcYmM7+l6QdRNjXYFAQBkQKDZEgfFak1AW9neLXfgZbWVh/jfKOoCeKj2i/ohum0ooX Date: 5 Jun 2014 03:32:56 -0000 Message-ID: <20140605033256.85324.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FvtTXiJsiPusPrW1yCG_pg9jId4 Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-nullmx X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2014 03:33:28 -0000 In article you write: >-=-=-=-=-=- > >Mostly minor stuff on the current version: I just posted an -03 that addresses these. With any luck we're done now. Mr. Shepherd? R's, John From nobody Thu Jun 5 12:02:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141361A02B5 for ; Thu, 5 Jun 2014 12:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCmARRja46Ti for ; Thu, 5 Jun 2014 12:02:48 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id E02A01A02FA for ; Thu, 5 Jun 2014 12:02:48 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8MR4NMGNK0041T1@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 4 Jun 2014 22:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1401946029; bh=xOBx7ghPIT6vrsx+DWLKFNh8nKATMnNshdoiu3JjNT8=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=ev/XLaW4q9GNnI9Kf6r3edtafaY8rCKGfCMxbB83/zcWXPgkkd8y5oag9qUZtDCzO gFfo3wz8P2As0j23GBm1Bw7ClK5blX+9Ik++W8Lpi1sp8eE4qaM5ylAdSdgB/Z9ny+ 0JCYuuzSKs6vuXpTq+R/GoK4DyXh6iW00kyTJSng= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8M34L23V40049PU@mauve.mrochek.com>; Wed, 04 Jun 2014 22:27:03 -0700 (PDT) Message-id: <01P8MR4M1ROS0049PU@mauve.mrochek.com> Date: Wed, 04 Jun 2014 22:25:20 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 04 Jun 2014 23:00:55 +0000" <20140604230055.84310.qmail@joyce.lan> References: <20140604230055.84310.qmail@joyce.lan> To: John Levine Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SngQMyIsRcUQj32NMGFKx6H2Ca4 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2014 19:02:50 -0000 > Section 4 says: > By the nature of the Simple Mail Transfer Protocol (SMTP), only one > enhanced status code can be returned for a given exchange between > client and server. ... > Is that true? When I read RFC 3463 and RFC 5321, I don't see any > advice about when or where to present the status codes other than a > largely implicit assumption that they go in the reply string. Wrong RFCs. Try RFC 2034. > I don't see why this wouldn't be valid: > 550 Your mail stinks (5.7.25) because it has no DKIM (5.7.20) and no SPF (5.7.22). It's "valid" but those codes have no defined meaning. They might be enhanced status codes. Or something else entirely. Ned From nobody Thu Jun 5 23:31:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DCB1A02F5 for ; Thu, 5 Jun 2014 23:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjEPBzKkzHJf for ; Thu, 5 Jun 2014 23:31:17 -0700 (PDT) Received: from vincent.hireahit.com (vincent.hireahit.com [23.19.120.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8F51A03EF for ; Thu, 5 Jun 2014 23:31:16 -0700 (PDT) Received: from VINCENT.hireahit.com by hireahit.com (vincent.hireahit.com) (SecurityGateway 3.0.0) with SMTP id SG000887194.MSG for ; Thu, 05 Jun 2014 23:31:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=hireahit.com; s=MD-20140321; t=1402036266; x=1402641066; q=dns/txt; h=Received: Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=yYVFMWc8LRbe5AYQ21v3sqEPVYT6JCDaAOr/XM/lPfE=; b=TDTME+9lYnCKl sfj8N7oj2Lw9RiWnW3YmQ6WeQHllYlMbI/4XwCz3CqiTej2KUCI/koc8k0Js82At 6h5Bp/1YgR3FyCI5OseG53M4C6pIJdQIqD42pJSA1icjtwmoAFgrf8CCJWUgnajx 2WQuhRXmVBXAIHtTznaM0bC0uPsOZE= Received: from [172.24.0.151] ([184.68.44.226]) by VINCENT.hireahit.com (VINCENT.hireahit.com [23.19.120.58]) (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v14.0.2) with ESMTP id 31-md50000007754.msg for ; Thu, 05 Jun 2014 23:31:05 -0700 X-Spam-Processed: VINCENT.hireahit.com, Thu, 05 Jun 2014 23:31:05 -0700 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: davew@hireahit.com X-MDRemoteIP: 184.68.44.226 X-Return-Path: davew@hireahit.com X-Envelope-From: davew@hireahit.com X-MDaemon-Deliver-To: apps-discuss@ietf.org Message-ID: <53916024.5070600@hireahit.com> Date: Thu, 05 Jun 2014 23:31:00 -0700 From: Dave Warren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140604230055.84310.qmail@joyce.lan> <01P8MR4M1ROS0049PU@mauve.mrochek.com> In-Reply-To: <01P8MR4M1ROS0049PU@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/CxTdOXZmWoURqN-JN2R8V8S33vc Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2014 06:31:18 -0000 On 2014-06-04 22:25, Ned Freed wrote: >> 550 Your mail stinks (5.7.25) because it has no DKIM (5.7.20) and no SPF (5.7.22). > It's "valid" but those codes have no defined meaning. They might be > enhanced status codes. Or something else entirely. Since it doesn't conflict with existing behaviour, it possibly enables creation of a formal standard without breaking backward compatibility. Also helpful is that such a standard would be human-readable (both the text and the Googleable error codes), so it would be beneficial to generate such information even if senders don't use it at all. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren From nobody Fri Jun 6 01:24:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D711A0409 for ; Fri, 6 Jun 2014 01:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWklwkN6HS1r for ; Fri, 6 Jun 2014 01:24:36 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 757071A00EC for ; Fri, 6 Jun 2014 01:24:36 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8OBFPOZ2O004ZT2@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 6 Jun 2014 01:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1402042772; bh=jP4/ozE4NKlfZUMiTw7l2xZnh25bsGXAFuUCqly9tqI=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=MKiI2NIPzf5KX1TuGGA/PwnO1H+0hv16U6GP6lefRLNNx7Yx4E47hVNEHEG6XbBVf TiObigxsxbXgYytuCkv4MOcGi0ZFnzBbdUt4LeAFPdIFeuVZ9R1Qe4ywxcB/ZYlEA+ S7xcAL/EgNc3D+esGFQP2adzj67+3rgIw7EtOGl4= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8NABDUSCW0049PU@mauve.mrochek.com>; Fri, 06 Jun 2014 01:19:26 -0700 (PDT) Message-id: <01P8OBFOH0RQ0049PU@mauve.mrochek.com> Date: Fri, 06 Jun 2014 01:11:36 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 05 Jun 2014 23:31:00 -0700" <53916024.5070600@hireahit.com> References: <20140604230055.84310.qmail@joyce.lan> <01P8MR4M1ROS0049PU@mauve.mrochek.com> <53916024.5070600@hireahit.com> To: Dave Warren Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/W7EPzmtPhP-c1CbZkdMSZ6U4L2o Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2014 08:24:37 -0000 > On 2014-06-04 22:25, Ned Freed wrote: > >> 550 Your mail stinks (5.7.25) because it has no DKIM (5.7.20) and no SPF (5.7.22). > > It's "valid" but those codes have no defined meaning. They might be > > enhanced status codes. Or something else entirely. > Since it doesn't conflict with existing behaviour, it possibly enables > creation of a formal standard without breaking backward compatibility. First of all, unless you have insight into all the strings exchanged by the SMTP servers of the world, you have no way of knowing whether or not this conflicts with existing behavior. Second, a formal standard for what? We've had a standard in place for negotiating the use of enhanced status codes in SMTP replies since 1996. (RFC 2034). It's widely and successfully deployed. If you're talking about allowing multiple codes, it would be a very simple matter to specify a similar extension for that. An extension to the DSN format would also be in order; it's not as obvious how to do that. The sticking point is I've yet to see anyone advance a use-case for this that would justify standardizaing or implementing any of this. > Also helpful is that such a standard would be human-readable (both the > text and the Googleable error codes), so it would be beneficial to > generate such information even if senders don't use it at all. I'm afraid I have no idea what you're proposing here. Ned From nobody Fri Jun 6 07:02:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C701A00FB for ; Fri, 6 Jun 2014 07:01:55 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDZIc3uuDVgj for ; Fri, 6 Jun 2014 07:01:51 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A0D1A0496 for ; Fri, 6 Jun 2014 07:01:50 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id b13so1904029wgh.21 for ; Fri, 06 Jun 2014 07:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qiLhyuN00nc7Y6bXqApEZyiBwLHPP7WwX7v3Xk/m5sY=; b=o8E5yNZ67HejOpAQNi5ZQE2Iu8sQMw8dONdhA4gVpLiBAlEHl2X5WVGhUOUPMG6BNu qZjS4uxmivaAsR3xdl8SE94qa/EXy6fZapneO14zLD1Sjig9qW9+wiRjpCnCi0c2m1NX eAXOT/FOh0pfjgOZSXDSjgRsJgTU6hr2/h3x3gUeFbzmzIBx/OPv09dgwW9JFz8Frv8L 8HBzke+vI0gW/KXLBaVUQywy7L84FKJGdFGDDBcNz1RCGgeMMDNGjSY7ntfzXqc62y3u /5cqUpCdCA7A9oWPaApfvi2+BUiZ9MoQ6LYuccxv+MuTycSkJeFO7p7SftX9bWjsAGs4 P3nw== MIME-Version: 1.0 X-Received: by 10.194.89.168 with SMTP id bp8mr7182260wjb.73.1402063301940; Fri, 06 Jun 2014 07:01:41 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Fri, 6 Jun 2014 07:01:41 -0700 (PDT) In-Reply-To: <01P8OBFOH0RQ0049PU@mauve.mrochek.com> References: <20140604230055.84310.qmail@joyce.lan> <01P8MR4M1ROS0049PU@mauve.mrochek.com> <53916024.5070600@hireahit.com> <01P8OBFOH0RQ0049PU@mauve.mrochek.com> Date: Fri, 6 Jun 2014 07:01:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=047d7bf10a1c109da604fb2b4d78 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0giSqKoUySaF4qc0sxsOJImlDTY Cc: IETF Apps Discuss , Dave Warren Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2014 14:01:55 -0000 --047d7bf10a1c109da604fb2b4d78 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 6, 2014 at 1:11 AM, Ned Freed wrote: > > The sticking point is I've yet to see anyone advance a use-case for this > that > would justify standardizaing or implementing any of this. > > The only case I've seen is the ability to report that the message failed for multiple reasons, and the desire to report all of those reasons to the client. "SPF and DKIM" is the common example. The benefit of doing so is that the sending agent doesn't have to fix one problem and try again, only to be denied for some other reason. Two solutions to this have been suggested. One, admittedly the simpler one, is what we have now, which is to have a separate code to mean "This failed for more than one reason." It has the benefit of requiring approximately zero changes to the deployed base. The other is to do something more fancy. There have now been two proposals for this: (a) Make the third number in the enhanced status code a bit mask so it can indicate multiple failures of the same type (e.g., 5.8.5 would mean 5.8.1 and 5.8.4 at the same time; or (b) create a mechanism to send and receive multiple distinct status codes. In either case, there's quite a bit more work to do. -MSK --047d7bf10a1c109da604fb2b4d78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 6, 2014 at 1:11 AM, Ned Freed <ned.freed@= mrochek.com> wrote:

The sticking point is I've yet to =C2=A0see anyone advance a use-case f= or this that
would justify standardizaing or implementing any of this.

The only case I've seen is the= ability to report that the message failed for multiple reasons, and the de= sire to report all of those reasons to the client.=C2=A0 "SPF and DKIM= " is the common example.=C2=A0 The benefit of doing so is that the sen= ding agent doesn't have to fix one problem and try again, only to be de= nied for some other reason.

Two solutions to this have been suggested.=C2=A0 One, admitt= edly the simpler one, is what we have now, which is to have a separate code= to mean "This failed for more than one reason."=C2=A0 It has the= benefit of requiring approximately zero changes to the deployed base.

The other is to do something more fancy.=C2=A0 There have now been two = proposals for this: (a) Make the third number in the enhanced status code a= bit mask so it can indicate multiple failures of the same type (e.g., 5.8.= 5 would mean 5.8.1 and 5.8.4 at the same time; or (b) create a mechanism to= send and receive multiple distinct status codes.=C2=A0 In either case, the= re's quite a bit more work to do.

-MSK
--047d7bf10a1c109da604fb2b4d78-- From nobody Fri Jun 6 08:03:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A633A1A02B8; Thu, 5 Jun 2014 11:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCSnElrlCFDH; Thu, 5 Jun 2014 11:28:19 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBF81A0259; Thu, 5 Jun 2014 11:28:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C8FAD1E4366; Thu, 5 Jun 2014 11:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVpa6jZ2y46z; Thu, 5 Jun 2014 11:26:39 -0700 (PDT) Received: from [192.168.2.100] (pool-96-255-144-77.washdc.fios.verizon.net [96.255.144.77]) by c8a.amsl.com (Postfix) with ESMTPSA id 2C9581E40EF; Thu, 5 Jun 2014 11:26:39 -0700 (PDT) From: IAB Chair Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jun 2014 14:28:11 -0400 Message-Id: To: IETF Announce Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6wG3Ed5dCFDVh-_LFRcgL4ftqIw X-Mailman-Approved-At: Fri, 06 Jun 2014 08:03:44 -0700 Cc: Internet Architecture Board , ietf-http-wg@w3.org, Apps Discuss , json@ietf.org Subject: [apps-discuss] Call for Volunteers for Liaison Manager to ECMA TC39 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2014 18:28:21 -0000 The IAB and ECMA International's TC39 have agreed to establish a liaison = relationship between the two organizations. The IAB is seeking a = volunteer to serve as IETF liaison manager to ECMA TC39 to represent = IETF views, as required. The IETF process for managing such = relationships is detailed in RFCs 4052, 4053, and 4691. It is preferred = to have a liaison manager that participates in with both the IETF and = TC39 activities, and is familiar with the processes of the = organizations. As it is expected that the first activity will be = related to JSON, therefore some understanding of JSON is desirable. If you are interested, please reply to this message by 7 July 2014, with = a brief note that explains your interest, your background, availability = to attend meetings, and whether you have any potential conflicts of = interest. The IAB would like to make a decision during the week of the = Toronto IETF meeting. Please note, the IAB may seek the views of the community on candidates, = and we may wish to interview candidates during the Toronto meeting. On behalf of the IAB, Russ Housley IAB Chair From nobody Fri Jun 6 09:25:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F991A0088 for ; Fri, 6 Jun 2014 09:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id girF7R-c3YKn for ; Fri, 6 Jun 2014 09:25:00 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3879D1A007D for ; Fri, 6 Jun 2014 09:25:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.9]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s56GOcHc027640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2014 09:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402071891; x=1402158291; bh=9hYJnIFlnfITXe1300cXOLwdL2U53Joez95S5VtuetI=; h=Date:To:From:Subject:In-Reply-To:References; b=V6/XySx5yItyFznI7glsbfMzXhaQ8oc3n4p8+PZ3W4FKcY4Ab62HvkgwQK742Dd/8 NGQY84N7U225+5Tbg4fBC/LXbgDAkGpKSXyRgDjfq57d5qrbI2BES6Ce0q5sc+Ty68 l0fD8vGVVNIiJlscwTDSCe15MyiIZDc7gJ+9hCz4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402071891; x=1402158291; i=@elandsys.com; bh=9hYJnIFlnfITXe1300cXOLwdL2U53Joez95S5VtuetI=; h=Date:To:From:Subject:In-Reply-To:References; b=x4CjsRNUd9BPx9PoqwxkmDJwywy7wVetJV4a339kbyUStZH6eQfrV11oiRr4Gib0F E3Ynb9wgozdcwnjhTgvov4vAKyKUujbLrVLUIMlDOojVACi7ftsj4GuSlhn4M6N4+a 6mLTVWaTOsCzk5kO3Q9qhMzZ9uJw2bmVpFzSQn7U= Message-Id: <6.2.5.6.2.20140606081954.0b44f3e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Jun 2014 09:08:13 -0700 To: rfc-editor@rfc-editor.org, apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <20140604203255.36E7F18000D@rfc-editor.org> References: <20140604203255.36E7F18000D@rfc-editor.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ct48jvT47-yE8NQ_D40nB5Qk5O0 Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2014 16:25:01 -0000 At 13:32 04-06-2014, RFC Errata System wrote: >The following errata report has been submitted for RFC6365, >"Terminology Used in Internationalization in the IETF". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=6365&eid=4005 > >-------------------------------------- >Type: Editorial >Reported by: John Klensin > >Section: GLOBAL > >Original Text >------------- >US-ASCII > >Corrected Text >-------------- >ASCII > >Notes >----- >The term "US-ASCII" is an IETF artifact, left over from some >misunderstandings about what "ASCII" referred to (and the complete >absence of CSCII or CASCII, MSCII or MXSCII, BRSCII, ARSCII, and >other "American" coded character sets). It is a source of confusion >for people who come to IETF specifications with a background in >coded character sets and terminology from other areas or standards >bodies and has been warned against multiple times. It should not >have appeared in this document except possibly with a warning >against its use (and the use of other bogus terms like >"ASCII7"). The second author, who is normally sensitive to the >issue, has no idea how this got past him, even in text picked up >from other documents, but supposes this is what errata are for. > >In any event, there is no such thing as "US-ASCII": the term is an >erroneous and misleading synonym/ substitute for "ASCII". The >reference for the latter is correct, but the citation anchor should >probably be corrected as well. I read ANSI X3.4-1986. The term for the Coded Character Set is "ASCII". The character set in the IANA registry is "US-ASCII". Ned Freed commented about that. The term "USASCII" predates the IETF. I took a quick look at several IETF RFCs and found occurrences of the term "US-ASCII". I suggest not doing a global replace as the two terms are not used interchangeably throughout RFC 6365. The guidance which people might be following could be: "These are the official names for character sets that may be used in the Internet and may be referred to in Internet documentation. These names are expressed in ANSI_X3.4-1968 which is commonly called US-ASCII or simply ASCII. The character set most commonly use in the Internet and used especially in protocol standards is US-ASCII, this is strongly encouraged. The use of the name US-ASCII is also encouraged." Regards, S. Moonesamy From nobody Fri Jun 6 09:39:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC641A0143 for ; Fri, 6 Jun 2014 09:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDKGpc0_kcC3 for ; Fri, 6 Jun 2014 09:39:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7F81A0115 for ; Fri, 6 Jun 2014 09:39:16 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s56GbcR0048514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jun 2014 09:37:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: <6.2.5.6.2.20140606081954.0b44f3e0@resistor.net> Date: Fri, 6 Jun 2014 09:37:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140604203255.36E7F18000D@rfc-editor.org> <6.2.5.6.2.20140606081954.0b44f3e0@resistor.net> To: S Moonesamy X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/L5yR5HOEFAgWRKOWPECLuDPYhhY Cc: IETF Apps Discuss Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2014 16:39:17 -0000 On Jun 6, 2014, at 9:08 AM, S Moonesamy wrote: > The term "USASCII" predates the IETF. Do you have examples of that? I could not find any, but I might have = missed them. --Paul Hoffman= From nobody Fri Jun 6 10:12:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF84A1A01BF for ; Fri, 6 Jun 2014 10:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ok3N7MTU-rjB for ; Fri, 6 Jun 2014 10:12:16 -0700 (PDT) Received: from winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2C85A1A01A7 for ; Fri, 6 Jun 2014 10:12:14 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=144589; t=1402074725; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=v+SPQ93eFmTCv7nKYWHfDEsxk4I=; b=fljxJx5mSS0FEjO6RkiE 90z62aA0576MQYwQiSMVmvjcCottAoED6n08CudZ4fAAYtPW1zCdBz7+mW5g3FHO t2lgZ/BP1pROAH9TFvmUNeqtmkD4FYEMyqYsbaKUVV9JIbxZN7OBaYhaJc9tdo40 xg9K5VBxOLlfGR7rIb1fozc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Fri, 06 Jun 2014 13:12:05 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1554851310.4211.4480; Fri, 06 Jun 2014 13:12:03 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=144589; t=1402074562; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=jSic47t RobuylL6W8DxSmxkOaFmlRPpZO6LtP7UPZck=; b=qHs2YKajcZu1EuXB6WEFVA3 NDLwBF7OY9fyClwgrJ3A/N35H+nVmv9gCi7ApIn0eW9Aa2vPRqO2YI0zKP8Ejn7V cWenVn40leU61czjh5DDFmlz58gLG+lADXGR9FdhTFksbz4JU3SNlP/iE6lUcsul HHjeWWcuCMj4K3m5HnDo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Fri, 06 Jun 2014 13:09:22 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1571208156.9.5548; Fri, 06 Jun 2014 13:09:20 -0400 Message-ID: <5391F662.5010102@isdg.net> Date: Fri, 06 Jun 2014 13:12:02 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Paul Hoffman , S Moonesamy References: <20140604203255.36E7F18000D@rfc-editor.org> <6.2.5.6.2.20140606081954.0b44f3e0@resistor.net> In-Reply-To: Content-Type: multipart/mixed; boundary="------------020406050406060705020409" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RpEAKNpoTi2_TCPtCNrlP4aIGCM Cc: IETF Apps Discuss Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2014 17:12:19 -0000 This is a multi-part message in MIME format. --------------020406050406060705020409 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/6/2014 12:37 PM, Paul Hoffman wrote: > On Jun 6, 2014, at 9:08 AM, S Moonesamy wrote: > >> The term "USASCII" predates the IETF. > > Do you have examples of that? I could not find any, but I might have missed them. > Ask former device driver developers what they were using and before they started or with the IETF. I was referencing US-ASCII charts in my early 80s ANSI, VT10x, display, dot/laser printer device drivers, flow control, data communications, text/gui editor design works. This charts came from non-IETF documents like from hardware or software vendor reference manuals, which probably just copied standard charts and whether they were named ASCII or US-ASCII, it was pretty obvious we were only dealing or interested with the US or american version of printable and non-printable control keys. China and wider international support was still far from our minds, and if it was, for some, it was a complex and moving target implementation problem. We were also very still influence with 7-bit text based application needs. As for a public example, I see one at wikipedia. The attached image would be a common chart seen in many materials, this is is circa 1972. http://en.wikipedia.org/wiki/File:ASCII_Code_Chart-Quick_ref_card.jpg -- HLS --------------020406050406060705020409 Content-Type: image/jpeg; name="800px-ASCII_Code_Chart-Quick_ref_card.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="800px-ASCII_Code_Chart-Quick_ref_card.jpg" /9j/4AAQSkZJRgABAQEAYABgAAD//gBZRmlsZSBzb3VyY2U6IGh0dHA6Ly9jb21tb25zLndp a2ltZWRpYS5vcmcvd2lraS9GaWxlOkFTQ0lJX0NvZGVfQ2hhcnQtUXVpY2tfcmVmX2NhcmQu anBn/9sAQwAGBAUGBQQGBgUGBwcGCAoQCgoJCQoUDg8MEBcUGBgXFBYWGh0lHxobIxwWFiAs ICMmJykqKRkfLTAtKDAlKCko/8AACwgCRQMgAQERAP/EAB0AAAIBBQEBAAAAAAAAAAAAAAAH BgIDBAUIAQn/xABsEAABAgUDAQQDBwsPBQsKBAcBAgMABAUGEQcSITEIE0FRFCJhFRYXMnGB kSM3QlZ1lKGxs9HSGDM2UlVXcnN0kpOVssHTJCVTYqInNDU4Q1R2gpak8EZjZYOEtMLD4fEm RGSFo+JFR6XE1P/aAAgBAQAAPwDqmCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCMedkZSfbS3PSrEy2k7kpebCwD0 yAfHkxh+92ifuPTfvVH5oPe7RP3Hpv3qj80Hvdon7j0371R+aD3u0T9x6b96o/NB73aJ+49N +9Ufmg97tE/cem/eqPzQe92ifuPTfvVH5oPe7RP3Hpv3qj80Hvdon7j0371R+aNpBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBAehx1hZWjqa5cer 9x2czSw3J0dlSjO96SVrSpCSkpxgcqV4/YwM6oJe1snLDTTiGJaU79c+HshKtiVncnGEpwrG Sc5+WF+e0FcFSm6tPWrY79XtinP90ubQ4oOEHACsAHGeTjBwCM4h/wBNqCZqiStReaclEOy6 Zhbb/qqZBSFEK8iM8/JEB0h1XkNR6nccrJS5lxTXx3ClLyZhhWQlzHgcpOR0G5PnGu1g1Xnb TuOkWva1Ibq9yVIJU2247sQgFRCQRkZJwepAAGcxnWzqLVGbPr1Y1Ft6YttdGIDuSVNzORx3 RPXJwngkZI564g1I1I1dvdldWsa0aUxQFKKJddRc9d3HBUD3iMjPkMeGTgxs7s1auq1NIpev V+3GKfcz0+JBMo8s92QElRe25zg7SMZ8QckRuZrUqtfDNbVnStLljJTlPE7OulZLjZKFK9U5 AASUgcg5z4Q3B0EEEEB6HEKPSC9K1dOo2o0jPzjb1IpE42xJNBkILYKnU/GABP63zuyc9MdI bkEEaq7KgqkWvWKk2tCFSck9MBaxlKShBUCR4jiIhoBXq1c2ltKq9yzQm6hMqdJeCEI3IDik pyEAAcDyhiQRpb0uKVtK1qlXagla5aRZLqkII3LPQJGSBkkgfPFjT26Ze9bOptwycu7LMzqV KDTvxkFK1II9vKTz5RIYIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIII5s7LbzdT1G1Oqy1Nh+YnMobUvc4lCnXVH5U/FGfYIxdI56Tquv ept2z7so1RpNpcuuZeWA2lJWlKSVfFwUsq8fGNNctMrOgcy1ddiVqWqdnVeZAVIuHcnCgVJA IJBG0EBxJB6AgiJP2o9UWZazJOgUBzfN3BLJfeUPjtSigCAR4FfT5ArzBiK6dro2n2ultSdE l6lL0qsUluTfenW1JD0yv1ipskcp3BtPHAOccYhlasWNStR6x7rWZcknLXtbp2fUXkK2qQol KHQOUEKBAV4cgg+C4um76/qH2Yaq/U2S7UqTVG5eedYIw62jB7wpTxwVpzjjjdwOj10euy3q ppnRXabUZRLFPkGWZlCnEoVLKQgBQWCfV+KeTwRyOIVnaom2rhrGnFBkZlDzFTng4FMLSreF qbQhQ8CPWVg9IytPnhWu1xes4QdkhIKl04I+Mkst/wByo6Kjm3tNVGeql/WdZUxVlUm3qmEr nXUubAvc5tIUehwE8A8ZVz7NFq3TmNMtLmaJZFwTr1HrdVU1MTCplLiZZCU+s0kpAAyclXid pHnHrVGk9K9VrDp2nlyTVQarL6G6lIreS82plSkpLpCcAZTuI8RsznGRFVjNTOqdTvO57lvO s0BdMdcalJWUnPRzItDJ3KA8BwDjGSlWTEEt+4K1aXZ6rNTpU681NV24PQzNJJS4G0s71LSr OQVHKc9Rz58TPQd276dqRbzSadcktRqjIqcqQqcwXmn1BvJmG9wTtBWUY+McHGTmOtIR/atu mq29Z1OkaNMOSKqvNiWenkKKO5bAyRuHIz5jwCo0Fz2YjS7SW9Z6RuupVlqcpaZNyVmXErbC 31pb71Izx6qzj2eJ4iAUSj1Ww5vRxVGuGqmYr7/fzMgZhRl20LWzwGhjhQWrJOclOfCJvbj9 W1U1QvZU7eNWoNNt58tSUpT5nuNoSpSe8WDwoDu9ys+KscDiIpJXxc7ehV+1afuWenJt6qNU 6RnA6E4wpJWW8cpCkZ4HyjxMe6qWTOUXQiUrtwXVcVSq0+7KuKlpiaKpcKUnISpBJ5SnPrZJ yBxHRWi1st2npnQaa28+6fRxMOd8fird9dSQPsQCo8f3kxN4IIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIID04hBXf2bqdV7nm6zQ7in6G Z51bk0w233qVbzlQQQpJSCcnB3DnyGInVC0jtej6fTlntyi5inToJmnnVDvnl5yFlQAwUkDb xgYHtzCaN2Z7bkqpKu1Cr1eqUyVWVtU6ZWnu+uQFYAyPMADP4IndM0uospqPUL0mVPztVmAE sIfILcokICMNjHkMc9ASB7dpetiUi8J+gTlW9JD9FnBOSxZcCcqBB2qyDlJKUnjB4HMQ27dA 7RuS5JmuF2r0udmypUyKdMpbQ8pXxioKQrlXjjGeT1MTq1rMoNs2v73qVTmm6UpKkusufVO+ 3DCisn4xI658OOnEL+a7Omnr1RdmkSE6y24rcqVZnFpaPsx1A9mePDETKa04td+r29UVUpAf oLYbp6UuKS2yAcp9QHBIPIJ8YuWpYFCte4q5W6VLuioVhzvJlx1zfjkqKUZ6Ak5I9g8hEsiI aiadW5qBKyzNySKnlyxV3D7Tpbca3YzgjqDgcHI4jEZ0ps9qw/ej7kpcoxc78oW4oud7/pN+ chXhkeHHTiLOn+kVn2LPKnqHTFe6GCkTcw6XXEg5BCc8J4JHABPjGtrGhNiVe5JitztLe9Im VFx9hqZW2y6o9VFKSDyecAgE9R1jbK0otNWnqLNVT1qoyF96kF096HMk95v67uT7McdOI1+m mi9saf1NdSpq6hO1EoU0iYnXwottn7BKUhKfAckE+WOkMyI3f1lUS+6EqlXDKl6X3hxtaFbH GlgYCkq8DgnzB8QYhlJ0HsynWlUbfS1UH5eoLaXMTL0z9XX3SsoGUgJAGSOE9D8hiV1LT+36 hX7cq78ov0mgILcilLhCEDACcp8duBj8OY1Fb0ZsWtVufq09Rl+nTxJmVszj7IcyBuylCwOc ZPHJ5PMXXNIbJctJi2VUhXuKzN+nIlxNPD6ttKdxVu3HgkYJxG1v+xaJfVGlqVX5dxyTl5hE w2llwt4UkEY48NqiMe3jB5iTtIDbaUJASlIwAPAeEVQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQRbmnO5lnXdinNiCrYnqrA6D2xx+x2k7+mZmY XT7ckJiVQ8sJT6K8tSE/YoUUqAyPk5jL/VHajfadI/ecz+nFmV7Qep6fSHnLTlHmQoY/zfMA NZJwMhXj7fKNvJ9o69ljYuwC+6CVHukPp9QDJ42nkef4IvSWvmpLralq05ceS6CWFNS8wkY9 vB3eHTEeyXaCv/vPRJnTl16eTkqSy0+jj+CUqI+mM9vX+9mnEomtLaiVKBUEpU8gkDk9Wj4R aT2jLpS24+7pnP8Ao3ebUKDjoCQD6ySe6wTggeHPh4QI7TFaCRv00qBV4kTawPyEentM1jw0 0qP34v8AwI8/VL1tKlFemlQ2HBR/lSwcf0HPOYuN9pStuZ7vTCprKRlW2bWcDz/WIxXO0vcJ dy1pxNpb44VMOE+3nuh+KK/1S9e73Pwbzvd7vi+kOZxjz7nrn2RX+qYrWR/uaVDHj/la/b/5 j5ItzPaXr6m8Sum8625nq5MuLGPkDI/HHqe0xXfstN54+t4TLg9XHT9Z6+2Kx2mazt500qGe efS1/wCBF09o+4WUOekaX1MFtexZ9JcSEk9AfqHXgxbT2l60pwBOmdRII6CbWST/AEEeDtM1 nnOmlQPPGJtY4/oI9/VM1j97Oo/fi/8AAjw9pmtbk400qAT4/wCVryf/AOBHkx2i7scSpyS0 ynkMt5DhccdXgj2hoYgGv1+K7rbphOnvRuRhL/rDGcj6n5Riu9o+8Gn1Mu6dPIdSraUEvAg+ WNkXpbtB30VoQ7ppNOLK9uEJfTnPrAcoPO3H48eEYKu0jegm8+8MCXCcFspf37v4W3GPZj54 vp7SV3Kxt08dOSEjCnup6D4kCe0rdO1YVp48Vn4pDjoA+Ud3z+CLVN7U1WfmnGV2MZlxGQW5 ebWFpI65HdmMj9Utcu9P+53MbcHcO9dyTzjB7vp8X6D0zxVK9pW5StIf05mnMno086kkY6ct HnOIB2iL1LIdGm0yWysNhQ77BUfD9b6xbX2j7wR8fTp9PAPJeHB6fYRhVPtJ3sqczTrIal5Z RwhuZbfdWTjJG4bQehPSKHO0bqAU7kWQwlOCcql5gjGcA9fm9vsixO9pK/6W0HKvaEjKtuDD SnpeYaBOfNSueh4i4z2jdQ59xtdLsyUdYfVhjbLTDm/2BQUAo/II9b7RGpOVlVkypQjheJOZ G0+07jjmMYdorUgOlRtCR2YACfQpjg85Od/yfRF5XaJ1KS2hxVlygQvO1RkpnCsdcHdFY7RW ozaEresmV2OAlBEpMpBwcftjnmLjfaB1Pe3pYsRla2hl0CRmjtB6ZG7iLrmu2rDZAXp+2knO M0+a5wMn7LyBMWFdo6/5OWMxUbJl0MJUoKcMvMNpGByMknBBKT8nHjkYkn2l79m5ZL0talOf bKiO8al5hST7AQo8xskdpK8whwLsMKUR6hSl4AH2jbz+CLTPaQvoIb76x2VLG7eUMvpCv2uB zjHj1z7Iyv1S117tvwfr3Yzje70/mR7+qUuz975z+e7+hF6V7S1xpWr0vTqZcRjgNPOIOflL RjIX2nKq2ncvTWoJTnqZ1Y/+RGC32r5hcx3KLGWtzJHdpqR35HhjufDmMgdqSfLqGhp3Nlxa d6UenqypOM5A7jkYjxPannVqKU6ezSlAbsCoKPHn+sdIvs9qKZTMBE7p/UGW+dxROFShg4Pq loePHXrFpvtVlTLhNiznep5CUz2U4yOp7rjqfDy8+L0p2qpVSU+l2bUWlEncGpkOADwwShOf wY9sZP6qek/apWf56ID2qKQlJJtWsADkkrRxFn9VjQftbqn9K3F9ztWW8W21S9uVpz1fqm4t pCVeQIJyMePHyRSntU0dWdtq1g4ODhaOD5R4ntWUZS1ITa9XK09UhxGR8sZbXamtnLKZm3rg bWr4wS20rHB+LlYz4eXU+XNR7Vll7yBSLi2YGD3LOevPHe+WPl9kWn+1baSVDuKJXlp3YJWh lJ2468OHnPh+HwjI/VV2R+5Vyfe7H+NFX6qmx9ilGmXGFAgbTLM5PXn9dx4fhin9VXY/7lXJ 97sf40eN9qqylb99LuFIB9XDDJyMdf13j/7fNkzPajsNlSQ3K158FOSW5VsYPkdzg5/BA/2o 7DbDRRLV10r+MESrf1P+Flwfgz0i632n7BWgqUisoIGdqpVOT7OFmPJXtQWC81vcbrUurONj kqkn5fVWR+GL36prT/8Ab1b70/8A5oP1TWn3+kqv3p//ADQfqmtPv9JVfvT/APmi0x2nrBcW 6lxNYZCV7UqVKghY/bDCjgfLzF1XaZ09CiA7VFAHGRKcH8MWx2nbALykf54CQkEOeiDaT5fG zn5sRc/VNaff6Sq/en/80W/1Ttgd9sArBTgHf6IMePHxs+A8PEe3FR7Ten4UBuqxB8fROn+1 Fae0zp6o4L1UTwTkyh+jgxfl+0lp0842ldQnWApJJU5JOEIIJ4O3JyceGRzGb+qG0y+2Jf3h M/4cH6oXTPr74lfeEx/hxno1y04UhKvfTKjIB5adB+jbHvw4acfbVKf0bv6MZdG1fsKsVL0G QueQU/sCx3pU0k5OMBSwAT7M5iewQQQQQRj1JC3KdNIaOHFNLCecc4OI5u7KF80GmUSSsx95 Yr07NzL+EtkoyAMBSv2xCDj2D5I6YBBOPGPcc5gMeYHt+mPcfL9MGPl+mPMfL9MewQYgIz5/ TBBBBBBABiAjMEEEeYHt+mDHy/THuPljzHy/THsBGYPDiOfNGG+77RWqSSoqO4HJxnlefADz joOA8x5tHt+mPcfLAQCQSOR0jwgHz+mEv2upVL2jM04VKBl5xh0DrklRRj/a/BDE0zSlOnFq BICR7lSvA4H6ymJJj5fpj2DHOYMcx5j5fpj3HyxEtWltM6WXep5QSj3Imk5V0yWlAfhIiPdm lCWtELZKUpTubdUdqcZPfL5Pthm7uM4MejkQQQQEZHtjnnTRpl3tXahOFhoLalBsISBtJ7kE j2nnJ8cnzjoPu2wtKu7TuAwDjkCPUoQFbkoAUBjOMHEe7E/tR9HzxQGGgCA0jB4+KIO4a/0T f80Qdw1/om/5ojxUswoYUy0R5FAjnnQakUmZ1j1WcRJMPNS86htgltKkNhTju4DPIJKRjHHB 9kdAt06RaQUtycshJOSEtJAP4IuIlJdsEIYaTklRwgDJ84obkJNt1brcpLpdX8ZaW0gq+U4i pUnLKcStUuyVpyAooGRn2xj+41L/AHNkv6BP5o99xqZ+50l/QJ/NEA17pVPa0dupbUhKIWmU JCkspBB3J56RrOzNQ6V8DVDfNNk1PzPeuvOKZSpTiu8UnJJHPAA+aGemg0hLinE0qQDihhSh LoyR7TiKk0WlJSEppkiEgYADCMAfRFt636M+kpepFPcScZCpZBzg5HhGH7y7X2lJtyjbSd2P Qm8Z/mx57ybV+1qifeLX6MHvJtX7WqJ94tfowjL9tO3nO09Y1KVRKcKbMyDy35VMulLbqkof KSpIGDgpT9EOL4L7E+0+gfeLf5otJ0sscuKU5aVBKeClIkWxgjOeQOQeODGbL6d2ZLoUhi1K GhKiCQmRb5I6eEeTOnVlzSgqYtShOKAwCqRbPGc+UWPgvsT7T6B94N/mg+C+xPtPoH3i3+aA 6X2IRg2fQOmOJFv80I7sm2dbtYotzzdXo0jPPoqPo7ZmmUuhtCQFAJCgccn8A8oe6tN7JUHQ q0qCe9VuX/kDXrHnn4vtMD+nFlPttIetOhKQ0NqAZFvCR9HsEWfgvsT7T6B94t/mjGnNItP5 tKku2jSEhQAPdMBo8Z6FOMdev5o1ruhGmrjqHFWuwFIxgJmHkjjpkBeD15z18YEaE6aolwyL XY2bSnJmHirB6+sV5z5HPHhCM7Uem9pWVRrcmrcpYp6nppTD5S844FoCc87lHkc8jnn5I64k NnoEt3JJb7tO0nPTAx15i/BBBBBFmdcDUm+4rohtSj8wj5q2ZSZS5L4p1MqFQRTpKdmdjk0p QAbScnOVYHs584697MFZm0WncUlUqp6dRaPUnJWQqby8NuMj9qo/YjAUOeArHQQ8W3EOAlta VYODtOcRUTiFYvtAaZIWpKrm9ZJwcSEyf/lwHtA6ZAZNykD7nzX+FFQ1801IJFxLIBwf83TX X+iig9oLTEdbm/7hNf4cXXte9NGm23F3Q0UuZ2hEpMKIx5gN5HXxxHj+vmmbKWyu6GyHE7xs lJheB7cNnB9hwY8Z190zdcCE3OgEgnK5KZQOBnqWwIvSmuum02VBq6ZZO3r3rDzX0bkDMX3d a9Omm1rVdciUpBUQkLUePIBOT8giv4Z9O8499lO+lX5o9+GbTv7bKd9KvzRbc1r06b27rrkD uISNoWr6cJ4Hti03rlpu4jem6pUDj4zTqTz7CjMeI1z03VMlgXTK7xjksuhPIz8Yo2/h48Y8 Guumxf7kXTLb+OSw8E89PW2Y+XnjxjKOs+nY/wDKynfSr80U/DTp1uA99chk/wAP9GLM/rjp 3JyT8wLllpgtIKgywlSnHCPsUjHJPzfNEGl+1VZq3HA/Sa80gH1FBppRUPaO8GIn+n+sNo33 Vfcygzcyah3Re7h+WWg7RjJzgp4yPH5Mww4IIIIIQGj/APxjtUv+p/aEYdMuHUvVKu3JO2PX JagW9S5hcnJ75ZDhm3E8+sVJJBI2k+ACgMHkwy9EL5fvuyW52pMhiryjy5OfQlO1IdR4j5QQ ceByIYEEEEJvtbBz4FqiW1JCRMy+8KGSR3g6eRzj6DE00ieK9KbUcdc34pjGVqG3gIA/ABCo mda7zrb1ZqVg2YiqWtSnFNuzbzmHHdqQVFKQoeecJCjgjOMw5NPrvp182pJV2kkhmYThbSj6 zLg4UhXtB+kYPjEjgggiF60uqZ0lu5aFKSfcx9OU9eUEf3xGtBZz3M7PFFnktF0y0lMv92kc rKXHTge04hPWdYb986bVbUyq3JUUXYFTE3KTDT21MsGSTsI6gEhXAIABHHn0Fojck5d2ltv1 upq3Tr7Km3l8DettxTZXwABu2ZwPOJxBBHijhJMITT1kS/av1DQ0oLQqQaWo55BUGDj6SRGN rCzO37rVRNO3KrN0+gmRVOzaJdWC+fWOD58JAGcgZJxGx0eNQtDVq49Ol1WaqlFl5BFRkFTL m9csnchJbJx494PZ6oIAyYekEEEEc+9mn65Or/3Ta/KTMTvtEVudt/SCvT9KnH5KfSGW2X2S QtBU8gHBHT1SoZ/viWWPOP1GyrfnZxZcmZmny7zqz9ktTaST9JMbuCCCF/r/APWauz+Rn+0I wOzP9ZG2v4Dv5ZcWtXLlqtDv3TaSp06qXk6lUlszbYAw8n1AEnP8I/PDUHSCCCCEVfSVjtX6 dLLeEGnzIC8H1iG38jPsyPphga01Gp0jSy45+hvLYqEvKlxt1GNyACNyhnyTmKtGapOVrS22 qhUnXnpx+TQXXXs7lkZG4+ecZz49YmcEEEEc69jiZW/Tr0DjwWr3TDhRt5BUFZVnpzj/AGY3 vaGuetW9demrdFqL8m1OVRSJlts+q8nc0naseIwtXB889QCHbBBBBHN3bYJFs2uUpCyJ9eEk ZB9TpHRNOKjT5YrQELLScpHQHA4jIgggggjV3VNpkLYrE4tvvUS8m86UZxuCUE4/BHLnZsoG nV72kqjXFIyj1wys068lpbi23FtKCcFJBG4DGMckY9uS/L2o9oW/pnPs1Khyr1uUtlUyJBDY 2lSckY/1iTjJ8+Yi/ZptAWrp4uruoKJmuEVEy6FHYy0QS0hOf9U5yfPHhEm0t1Mo+odIExKq bkp9Lq2109yYSp4bfsgByQRznHnE0EhKEKxLMYXyrDafW8eeOYrdlWHUgOtNuAHcApAOD59O sXAjGcE88mMddPk1qKnJSXWo9SppJJ/BHnuZIf8AMpX+iT+aD3MkP+ZSv9En80VLkJRzb3kq wvaMJ3NpOB5DiLSqRTlFWZCU9YbVfUU8jyPHtipNLkAAPQpXj/zKfzRaeodKeaW09TZJxpZy pCpdBCvlGOYx0Wrb6HG3EUOlJcbx3axJtgox0wdvEZLNFpbGe5p0kjPJ2sIGfoEVilU8KKvQ ZTcRjPcp6fRFD9Fpj6dr1Oklp5GFMIPUYPUeUU+4VK7tLfubI92kYCPR0YA+TEVsUWlsJKWa dJNpPglhAH4BHjtFpbxy7TpJfGPWYQePLkRdFMkB/wDkpX+hT+aNZVbNtqrTEu/U6DS5t2XO WlPSyFFP0jp7I2srISkoR6LLMM4G36m2lPHlwOkZG4c8jiPYIIID0jn7RJS5vtA6qTaGHUMo cS0orGMK3kDPy7FEewRHLbq156N1S5bUkrRnK63UZ5c3SZxoK7tS3EgDeQnBG1KSRlOClXgc hxaGWZOWXYrcrWFJVWJ19c9O7ceq6vHq5HXAAGRxnOI3t5X3bVmBj3y1iWkFv5Lba8qWsDqQ lOTj24xGzt+vUq46aioUKoS0/JqUUh1hYUNw6g+R9hjZQQnO1q4hGitSStQSVzMulIJ+Me8B wPmBPzRKtMpB1zRe3ZFeEOu0ZpsE8gbmhgnHyiObtNdW5TS2x6/ZlZpE0/X5ecmG2ksJT3K1 EBOHFFWeFA8hJyMQ4+yja07bOl4dqjamX6pMGdS0sYKWylKUE/KE5+QiG8/PybEw3Lvzcu0+ 4MoaW4EqVzjgE5PMZMEEQfXH60F3fc538Ua3s7S6kaH2w0+j48s4SnzSp1ZH0giF4nQu8acm qW3bt5S8nYlTdU6+ytkqmEBQwUAYwRgJBO9OcdPAvm2KHJW3b9Po9LQUSckyllsE5JA8T7Sc knzMXZqsU6Uq0jS5mdYaqM8FmWl1LAW8EDKto8cDkxnwQRzzpWtLnao1HKCCkS20n2hTIP4Q Ymmq+nNWr9wUi67KqrFKuqmJLSHJhGWn2ieUrIBIwFK8DnOOOoydLNPp+3qvVrlu2qN1e7Kq EtvTDSChtloYw02OOMpHOB0HHGSyYwKZWKdVH55mnTjEy7IvGXmUNqyWnByUq8jGfBBHPXZq 3/Cdq7jb3fuk3uGOc97M4x7Ov4IaOslqzl7acVe36Y7LtTk2Gu7XMKUlsFLqFncUgnok+B5x EitimGi21SaUp0PKkZRmWLoTt3lCAndjwzjOIu1urSFDpcxUqvNtSkjLp3uvOqwlI/P4AeJi N2PqXad7vOs25WGZqYayVMKSpp3aMZUEKAJTyORxExghf6//AFmrs/kZ/tCMDsz/AFkba/gO /llxsNR7Bdu+6LMqiJ8SrVBnjOONhJ3O8pUAD4coAPsJifA8DPBML6u6yWJQrgNGqdwS7c8l exwIbWtDSs4wtaQUpI8cnjxifsutvsodZWlxpaQpC0HIUDyCD4iK4ISt/O57TemTQCwUyk6o nHByy5xn5vwiGDqlb0xdentdoki4G5qcllIaKlbU7wQUgnBwCQAfYYyrBo79vWTQqNNrQ5MS EkzLOLR8UqSgA49nEb+NTQripVfeqLdHnmZtVPmDKzPdknu3R1Tnx+aNtBBHOfY1k+5pd5TO 8K7ypJZwDkeolRz/ALcMLV7TyZvmq2fOSc0xLKotRE06Xdx3NZSVBIA5VlCcZwOTzDKHIjBr tXkaDSJqqVaZblZGVQXHXVnhI/vOcADxJi7TZ2XqVPlp6ReQ/KTLaXmXUHKVoUMpI+UERkwR zj20gTb1qBJ2n3RVg+XqR0TKgplWQVFRCAMnx4i7BBBBBEW1VmVSmmV2PoSFKbpUyQD0/WlR zpo/odRb10gp1aM1NUy4Xn3nGJ+WcUdoQsoSlaCccFJOU7TyOfCJQ5d97aaMPUzVmle+i03U 9yaxKthzahXq7XgQAoHphWCc9VQ4qHddDuizpmo2pUJeYlUS6gO74LBCDhKkYygjyI+kRw7Z a6Uq25RNDTNHU5deb9z3mCsAMFKcZGdmN+7PGfPjMdw0XUS063ck1QKVW5aaq8tv7yXQFD4p wraojarH+qTEqCgfP6Ij97rulFIR7yWaU5Uy8kKNTUsNJb53HCOSenjENaf1oSFIdlLEcVjK XA5MpAPljkn6RFSprWRBJ9zbHdBOAEvzKSnrySRz4RWZjWM7cSFip8SC/NH5un4Y99J1h3EC nWPgeJmZnn/ZjwzWsIz/AJusc8EjEzM9fL4seJnNYSATSrJTnqDNTHHOPL54HJvWJtBUKXZL pB+IiZmAT9IxHomdYiAfc6xhnwMzM8f7MeOTesSEkimWQ4R9imZmQTx7RFn3R1l2g+4Vm5Iz j0x7jjoePmgVUtZUqUBQLOUEjIInHvW9gz/fFHutrN9rdpffrkHutrN9rdpffrkerq2sm47L atMJ8AZ5wmKjVtYu5SBbNqd7uJUr09zaR4DGOvtz80Ue62s32t2l9+uQe62s32t2l9+uRDr2 Y1/nJhNSpSqXTkSzeBJU55DnenxUQ6CFH2E444Geujta6e0Q+4lK6G3MhvJUqpSbcuFZyRnB Rn/q+zMP2xJq7pqUmVXtT6VIzCVgMpp7ynApOOd2ehzjxiUQQQlNFwfhn1hwRt9Mk8jHOcPe P0w6to9v0x7HNlAodNvDtR3om8JeVqCqbKp9Ckn0BxoowgBRSeDgK6EdVk9RmNpoixJUrXLU uk20oJt1nuVBlr9abf43pA8MKLicDjCceAh/wQi+2R9aNr7ps/2HIaGmvOnFq/cqU/Ipjaqo 1LVUfdBVOkzP4x6SWElzH8LGY9rk4aZRKhPNoC1S0u4+EE4CilJOCfmjlHT7S+S1K07rl93V VKi7X5tx95l5pYSGC3kjgjkEjpxgYAx1h6dnm4qjc+ktDqFZccencOsreWkAuhDikpVx14AB PiQYZEEL/X6aRJ6N3Y44CUqki1x5rUED8KhFHZ7bW1oxaiXFFSjKbskk8FaiBz7CIYcEI/Vo kdoDSjBI9aa6fwRDwggjn3S5Kj2p9SFYJSJVIJ8Acs4/EY6CgghFdndwK1B1dSMpxXlnYCdv 668M8nqccw9YII517Lsz6TqDqy73a0FyotK2nnb9VmeCemY6Kgjn3tqekfBtSu573ufdNHe7 c7cd25jd8+OvjGgW1Tnri0LmrTp8pTa7MIQ4+ww6FOegBCQouLwN31NLgyRkncOY6gQkJQlK c4AwMnMewuu0O53ei11q3tozKhOXOnK0jHynOB7SIxezP9ZG2v4Dv5ZcM+KV/FOBk+HyxzPo nK2w7pHfvvobkkziZ2bRVHZgJ71AwNnJ6etnbj7LOOYZvZqVPr0Vts1Pdv7twM787u5Dqw3n P+rjGPsdsM2CElf0yhfag00lQDvak5xwnwwpl0D+wYdsEBhHdnFLSLq1STLApZFdVtGCMes5 4HmHjBBHPXY9l3Jel3mlY2hNWLeD1BSk5yQSD1HT6TxjoWCF72gpZE1ozdbboBQJPvMHPxkL SodD5pH/ANYzdE1BWkdolPT3NZHTHO0ZiawRz32zGQbKt2Y7palt1hCAsEYAU0slOPEnaPoP nHQEqd0s0rBGUA4PyRcgggggiGazud3pNeB2qVmlTAwkZPLZGfkGcmI12V/rGW9/Cmf/AHhy Gq60280406hC23AUrQoAhQPBBHjCRvHQ/wBDqhuHSqpKtivI9buGyRKvf6pTyEg8cYKfZ4xG LFv+kW9WZigagWpSrNu5aFMtVaWkW2WnCsEb1OJGU5P2QJSeeU4jTdnul3lbF10uiJlq21Ko mZhyqJfl0Kp3cFsbHGXhklalAcpODgdQDGff1wXlRu0vUxZDLdUnF0ltK5J4nu0spQFndykZ ByRg/Z46kiHjpNeqL/seRrqZZUq84VNPsk5CHUnCsHxT4j5YmMBOATGmmbqt6VmHGJqu0piY bUUracnG0qQR4EE5Big3fbYQFquCjhtRISr01vBx18Y8VeFtIUUruGjJUOoM81n+1FxF02+4 0XWq7SltBaWytM42QFHonOep8oHrqt9gkP12ktEKKSFzjY5HUcnrFv35Wx9sdF+/mv0ovS9z UKaz6LWqY/hQSe7m21cnoOD4xULho6kPKTVqcUsqKXCJpGEEDJB54OOYuprNNUUgVCSO74uH 0nPycxccqki2grVOyoSOSS8kAD6Yq90JL/ncv/Sp/PFJqkiHEoM7Kgq6AvJyfwxX7oSX/O5f +lT+eMebrlKk2y5NVKRZbA3FTkwhIA8+T7Y8fr1Jl0KXMVOQaQlO8qXMoSAnON3J6ZIGfbGG bxtc9bjop/8Abmv0oPfjbB/8o6L9/NfpRcbuq31trW1XKSttCStakzjZCUjqTz0iGy+u+mr7 qm0XSwFJzkuS7yBxjoVIAPX54lNMvq06otKKbc1FmnFFICGp5tSsq6DAOcnyiRk4HnCU0UUF ayaxlJyPTZMfQHxDrghZ6iaQ0277mlLilatU6DXGG+6M5TXA2txOCBk9cgEjIPTjwESHTiw6 RYNEXIUdLrrry+9mpt87nplz9stX4h0Hykk16lXlIWHaE7Xamhx1tnCG2WzhTzijhKAfD2nw AJ56QpqVq1fFHmKDUdRbbkqdbFbdS0zNy7hC5YrBKC4Co4BGDzg4B8RiM3tkc6RNY/dNn+y5 DZseWVJ2Vb8qsJC2KfLtkJJIyltI4J6jiN3FD7Tb7LjLyEuNOJKFoUMhQIwQR5RzyrRC8KOz VbdtC8mZGy6o4px5h5oqfaSrAUlJxzlPBO5OQBnqYd9m25I2lbFOodJSUyck13aCr4yjnKlH 2qUST7TF+5a5JW3QZ+sVRakSUkyp51SU7jgeAHiT0jy1q7I3Pb0jWqStS5GdbDrRWnarHTBH gQQR80QftKfWQun+Ka/LNxtNDvrQ2j9zmvxROII1NStyk1Ku0usT0i09UqZv9EfVnLW8YVgZ wePMHHhiNtCuvzWalWtcrlBk6RWK7U2Gw7Mt01kOCXB5AUc9cEHGPEcxNbNuil3hbstWqG8X ZN8HhQ2rQocKQoeCgf8AwRzCk0lSlztFapvFtBWjuEBYOSB4j59oz8kPeCCNJQLWo9v1Crzt IkkS0zVpj0qcWkk945589OSTgeJJ8Y3cRWkXvI1PUGvWiyw+iepDLLzrqgO7WHEpUAnx4Ck9 YlUc+9mn65Or/wB02vykzHQUEa+v0Wm3DSZimVqTZnZB8bXGXU5B9vsI6gjkeERLTzSa07Am npugSK/TXQUGZmXC44lJx6qT0SOPAZPiY3OoV40yxLWmq7WVL9HZwlDTeN7zh+KhIPifwAE+ EL20dZpuar9MkLztSetlisq20qZfWVoeUTwheQNpOU448R0BzG97Rm46J3VteLJ7hHrBO7I7 1GU/P0z4ZzFrs1IUjRO2QtJBLbihnxBdWQYZ0ELu49GLEuKvu1mq0NDk86Qp0odW2h1XmpKS ASfE+PjE/lJdqUlmpeXbbaYaSG2220hKUJAwEgDoAOI0WoN1ylkWjPXDUWH35WTLe9tgDed7 iUDGSB1UDG9k5luclGJlgksvNpcQSMZSRkfjhKX6y6ntS6bPqKO5XJTaEgDnIaeJz7PWH4Ye EEeKGRgHEayiUCmUN2oOUqTall1CYVNzSkZ+quqABUcn2dBxC81E1UnqReMvaFmW85cNyOM9 862Hg23LAjKd588YJyUgAp55jb6S6iG92KlJ1KmO0i4aS6GZ+RcOdhOdqknxBwfo8RglgQge yVIqkZW+WiQA1Wlsd2OQkoBB5PJ6jr5Q/oIwa3SpOt0qaptTZTMSM02WnmVEgLSeoyCCPlEX KVT5WlU2Vp9PZQxJyrSWWWkdEISMAD5hEW1PvuVsKQpE1Oyzr7dQqLUhlCtvdBeSVng5wEk4 xzEzhDdsnPwcUPBwfd1jn/1L8PWVBEs0CckIHPzRcgggggiD63tOO6R3eGl7FCmvKJKd3ATk jHtAIz4ZzEe7LB/3DLdHjumf/eHIUU7rxX5Ko3JUHbikEuSNTVLSdtu03cJhjvMbvSU4KSEh XJzyOnIEdbZzGju21KHd1MXIXFTmJ6WUMAODCkHzQoesk+0EQkJmy9QdIZgzWnc27ctrbtzt FnDvdbHT1MYz4cowfNJAiJKandUtTl3Np3dEjQa69JejTlMqO9uZYIT3bgSNhS4nGDkYIPgM Q1qxY9UsrQSYtmx51blYylPpankyynHFup7wpUVAJzkpAz0wMk8x7oK9N0d+o2rcjVWl7jlp diadTO1ITrTrZTs7xpQ+INyTlB6ZHJ8HCRkYiG1DS6x6jPzE7PWvS35uYcU686tkblrUcqUf aSSYx/gi0/8AtRpH9AI9+CPT/AHvRpHH/mBHnwRaf/ajSP6AQfBFp/8AajSP6AQfBFp/9qNI /oBB8EWn/wBqNI/oBFK9INPljBtKk49jOPxR4nR3T1OcWlS/jbuWyefp6ezpFt/RjTt9aVrt OnAp4GwKQPnAIBjGa0M03bUFJteWJH7Z11Q+gqjOTo/p8ndi0qV6xJOWs/R5fJFtGjWniEqA tOm4UMHKVE/Nk8fNFxGj+nyEhItKlEAY5ayfpMA0f0+7wr96VKyRj9a4+jpFXwRaf/ajSP6A R4rSDT5QwbSpPzM4j34ItP8A7UaR/QCNNcOgmntaS1miJp62+i5BwslQ8iOQflxmMmjaG6d0 h5D0vbjLrqFbkqmXXHsHjwUojwz85hkgBIhF6ETSndYtYUzOxEwqel8Ng9UoL6c9fIpz8sPW CCCEz2saBP13SsLpjC310yean3W2xlSm0oWhRAHl3gJ9gMQW+L6k9aqDbVnWdKzz8zNTLD1V UplQTJNIHrbldDySQQeduOpAiXdsGXUdHU90BsZqDClc9E4Wn8ZENmypr0+zqDN7dvpEgw7j y3NpP98bmCCCF92gPrNXZ/Iz/aEXNBU7dHLSBTt/yFJxjHUk5jA7Sn1kLp/imvyzcbTQ760F o/c5r8UTiCCCOa7Fuij6cay6nS16TYp7tQmvTpaZeQohxkqWsJSRnJw4AB/qkeGImnZrLs3Q rprKZVyWptXr0zOyKVpKd7KtoCgD0BIPzgxptKlN/qlNT0qcUHS2yUo3cKThOTjxx6vPhk+c PmCCCCEvZDbv6p7UdwsqS0JCSG/acHLTeOfmUP8Aqnyh0Rz32YVNm99Vhtc9I91UFa1LCsp7 yY2jjjIO7PyiOhIIIITvaooU9WtM2nqbKmcVSqg1UXmAMlbSEOJVxnOAF5OPAGIjel90jVWf sWg2S3MT06iqS1TmlJaUhMg038bcogYIyeh8OuSMtDX76zV2fyM/2hGJ2bXS7opbCilKcMuJ wkYzh1Yz8sMuCCCFd2nGXZjQ65GmG1uuq9GwhCSon/KWvARP7abW1blKbdQpDiJRpKkqGCkh AyCIWN6MtHtJ6eOqXscEhPbfWxvw2rCeevClHjmHBBBBHPVy1VOmHaKn7luFp5u27kkW5f09 LZWlh1CUJwrGT/yY/nZ5wcbnRVuZuXUm9L/TJPyVGqQalKf3iSgzSEAAvFJ55CU4P+sR4GHZ CJ7KJQZC+SyVFr3fe2bhg4wMZEPaCCCEh2rpGYnrWtgSkrMTDia6x+tDdtylY5AHicDwh3wh u2R9bih/d1j8i/D2l/1hv+CPxRXBBBBBEP1i+tPeH3JmvySoiXZVQ2jRCgltKUrW5MqWQPjH v1jJ+YAfNGuldEqk23WqO9dmbUq08qdmZFFPbDy9ywooDxJKQdoGQPDjGTE/rNwMUu/bUt1q eMsqfamVCUEp3gfS23kDvdw7vbgnod3Tjxl+ecQEA4z4QttS9ILevh73Q2uUqvtjc1U5E925 u8CvHx8YHPXyIhVXVcl1WXQJq3daaEbrtWYw01VpNW1SiMFIWRjCuMgnarIPKo0ln682PZ/p Zo9qVlcxNqBfm5qdDz7oTwkKWok4A6AcRJf1WVD+1qp/0zcH6rKhfa1U/wCmbio9q+iJUAu2 aonp1eb6Rdle1PSpt0Nylp1mYWo4SltaFKPzDxwDGYntJNrWtCbEuNS0YCkhGSn5eOIB2jld 4c2DcmzHB2c5+Tb06RiznahkZBSU1Czq1KqVkpDy0o3Dz5AjLHaQC0BTdhXIoKGQQjg/gi1L 9pZDrale8W4CUHC+7G4JI65O2LjXaQKkAqsC4wTz6qcjHhztjW1XtUSckos+8+ptzQIy1NPJ awP5pPl4QDtJVkqBGnNTKCcj6ovpj+L8/wAEWpntH3ItaBI6bz54JUHFuE+fGG/KKpHtC3jO ECX0wqMwQsBYZ75WAeg4a6nBgqnaMuegpaeuTTSo0yVcVsQ5MrdZClYzgFbQBPU/JBRe0zU6 7OLl6Hp9Uak6hG9TUm8p5aRnGSEtnA56xtmtd7recdQ1pLci1tK2uJSh0lBxnB+o8HBB5iNK 7VM6p0SbNkrNTU93IlzNkqKicBO3u927OBjHWNjUtfb8psm9OVDSupycm0Nzj8wh9tCBnGVK LQAiiW1z1Lm2ETMrpZUH5V5HeMuNysypK0kZSoKCMEYwcjrGezrdqGArvtIK6TjjYzMDn52Y vymsmo7zzW7SKrBpSgk571B6Z+yb4+fjw6wodM75u2k6q3bUqJZkxUKjUVOLm6YlLm+VPebu SE5GDkcgZJHjDkXrHqChAWdIqzsCjuwpwqwDjgBvJPX5eCIvyesF+PFQXpFXAfjp9dafUPTO 5set1yItK1b1JJShvSSo96MqXudXt2k+rg7OvBz83nHidWNT9w3aSTpT4gPqz/Yi7L6p6nuK XnSSbwlJVzNlHA64yjk+wcxjS2puocs2US+jk0yFHKg26Ugnnyb9sQLXu/L4rena5C47FfoE g7NNd5Nrf3hRAKkowU55xnOfDESyyNStSmbXoMjT9L5malm5NhliZVMFtLqAgBKySnCQQAeT jmN4zqXqq9Mql0aTuhxJxlc8Eo/nEBJ+mKJjVTU9DqgjSWc2biB/lJUePkTFo6r6oZONJZ3H h9XV+hAdV9UPDSWd/p1foRRO6j6h1WQmpSe0cfmZd1OFszD25taMeslQUjCvDiKmtStTKfLM S0vpA6zLttpS00xMeqhAGAkBKcJwPDwiJau6g6gVrTatSVb06mKTTHkIS/OreKu6AcSQdpSP EAfPGZpRf+pcnYVDkaZpwupSTLCWpec9I7gOt5AScK+Uc5weT0zEydvjWIuNFrS+VS2FZcSq qtKKh5A7hg+3Bi3MXvrMpnEvplJNu8esupNrHt43j2ePHtjGTeeuZOPg6pI48ZtH+NF+TuvX KZ37rCoTG3H67OAZ+TDpjXVhOqdxKacr2ltlVFbO5LZnlNvFAzzt3LOAcZ+iNibk1ulG0ssW Db3dNt+olmbSEgDACQO9446DpxCjsqu6ksa43XOUq15CYuWYa2z8i46A3LoyjBC+8A8EeJzk /M2pq7tcmHdidP6K8MZ3tTiSPwuiKk3trUCxu00kCE/ruKg2N/8AB+qer8+YuzF8axqaWJfS +UbcJ9VS6o0sAe0BQz9Iitm+dXw2A9pbLrXxkpqzSR08tx8c+MV+/rVv96tn+uGfzxQL61ZD pxpSzvKeVe6zXIHt+fpFSr81aQkqVpU2QOTirtE/ghV6F3LfEjcd/TlFshVVXOToXNS/paJY Sj+9w7Mr+Nwog46YHTPLMnNStUmJtLKdJ3iSByJ9KxnHPrJG38MW3NTNVG2mnFaTulLhASEz wURnzAGU/PiLs7qLqvJt73tKSpOcYZqSHT9CATHkrqPqtNb+70oUnaAT3lQS31GeNwGfm6RY Gp2qa5db/wAEz+xGMgzmFHJxwnbk/MOOsYclqDqJTw4uR0Z9G77LrncuhBWckZVhHJ9h58ek RzVPUjUGq6e1yRrGm01S6e+xsenFOKUGUlQ9bG0f+OYxNF9SL5pWmtNp1B09mq1JSy3ENTzb ikocG9RIxtPIJxkHHETmX1d1DQtaJ3SSrFW0rR3LiyMDrk7OvTA6mKXNXNR23E7tI6mULO1O 11ZOdp64b4GR1PGPbFpGrmpy3HGxpJP7m8ZJccAORnglGD82cRX8K+qH70s5/Tr/AEIyZLUj VWeK0taTuJ2AE9/PhkH5N4GfmgVqVqqkvA6TufUlbVYnwcnOPV49Yc9RkQtLp1Evt3V60KnM 2G/KVaWZfalqaoqUqbStJCyFbeNo5yOmOeIYnwq6o79h0lm85xn0hWPp24i9N6maqSqWlOaT uqDgJT3U6HCMeYSDj58Rlu6i6oISlkaUO+lBBcUfdJst7QTwCBjPTjOevEYDGqWqT7qW0aTT IUehXNFA+kpAEXFai6pvySn16SlTIJBSueTu4/1CN34I9nNTdTpRphI0mmS4pG5WycDiR5Y2 pOOPA8xeY1Yv3YjvtI6zvwN22Y4z7MohUaGag3ZRp67m6TY09WUTVRVNzDbKylUo6onLaiUn PTxwfVhsq1XvtKik6SVnIOOJnI+nZGLM6sajbx6LpJU9mBnvHznOeeiPkix8K+qH70s5/Tq/ Qg+FfVD96Wc/p1/oQHVfU89dJJz+mV+hFLmrWp6BlWkk9j2OrP4kQqdfdQrwuu2qfS7hsedt 1luopebmXg4A46lC0hCSpKR0WTkE9I7JpQcFLkw+AHu5RvAJPrbRnk9YyoIIIIIgevEwqV0e u1xIWSZBbeEdfWwkn5OefZnpEV7JUzKv6NU1qWUC9LzEwiYAPIWXCoZ/6qkw5oi9Ws6XqV/0 G6XZp9D9IYfZbYTjY53oCcqPsGePPB8OYVfDdXX2hdPxK1RbdNMnNrck08D1R66lee7c2B5b D5w3AoAJ3EAnoD4x7Cs7TrbbmiVxd46G9oZUnJ+Me9RxCC0m1KpliUq2qfWKE1OUmfln3Xls SqXJkzBfISv1iNyQlITgfLzjB66tOu0u5LekqrQH0P02YRllSBtwBwUkeBBBBHhiNtHPvaEl irWDSF9SUFtVTDXPUkPMn6OYzFa7NW9qddVv3lLuNU2TeR6JNSbBdDLe0ZL2DnBykggHBJHl DvkZuXn5KXnJJ5D8rMNpdadQcpWhQylQPiCCDF+EP2ugk2xafeDc37us7k5HI2LixcGuhsvW K6aDcktNzdEYRLqlDJMpU4wSy2tZVkjKTvJzk4x05h40KrSVdpEpVKW+mYkZtpLzLqeNyT7D 0PmPCM6ER2kmW5m89JWH0BbLteQhaD0UC4yCPoMaK0O0QmnXLXaTezMy6w1Vnmmp+XaHdyrO 8pSlwDnAI68nB8cR0iy4h5tLjSkrbUApKknIUDyCD5RXCR7W7iRpzS2VtqWH6zLo+LlI9VZ9 b2cRvbp0sKK2bn09n027cu0BxKED0SdAIO15sDxx8Yc+OM8xmWdqU1VZ5dv3PJm27vbJQKfM uApmODhbDnxXEnB4HIwevUp+156zqDo7NVuqtUl6/pScmnsTqUGc90kuq2DHxlYyg46ePWIx WbrrExYFU9Eu2dudqo26iaq7T+FIp8w5MMo2Jwn1ThTiQjPhuxjGMif1quGhacrp0tVCxd0t XHJdUo5KozLSSGyAjaE7cBQA4z0PMZyLi1Nk20KevKabcTa4uh1MxJMq2kOLSljpwFDac9ee nGIyXtWr3nWand8jUmpaj0w0ttVJXJp2TDj7SC8kLPrJAUVEHJOCOkSvQqTS3rtqw404lxDc ylBJPOVuLURxxwUkHx4Htx0FBBBBBCN7Yuz4IU7yoK90WNuOhO1fX5s/ghn6a86c2rn9ypX8 imJHBBBBBCz7Sf1kbp/imvyzcbTQ/nSG0c/uc1/ZicQQEA9RAAB0EEGB5Qi9KGUK7RWqjxT9 UQJdAPsUAT/ZEPSCCCDAznHMEEJLs5HNd1OGBxcLpz4nlXEO2CDEGB5CCCF/r/8AWauz+Rn+ 0I1/ZlATojbW0AZQ8eB/55cNCCCCCDEKe7v+MXYX3Nn/AOzDYggwPIQQYHlAOOkEI/sv/F1A /wCkcx/dDwggggghDdsj63FD+7rH5F+HtL/rDf8ABH4orgggggjHqEpL1CQmZOeZQ/KTDamn mljKVoUMKSfYQTHEr1NqGmOp9ap1FrrtszxfD1KRMqKpKdlipQSh1Z6HwClAp4Vkp4J6BtDW mXNTFA1DkU2tcI2hvvVEysyDwFtudAknpkkeSjDhHMW1MtqeQ6pCS4gEJUUglIOM4PhnA+iO a9ZZauo7QtuTcvRa5WKYlqX7tMq44020vvFBW1xPqjjG7djg8kDmOmIWfaTQF6JXRkA4aaUM +GHkRzjpxSLtkTp/eFtWu/XZeny0ygtpWEJUVOPIIyeQRvyDg9I6I0kp72nOlL83ebjFPcLz 9Smmwr1JYOKyGxjjPTgZ5OBmLekmqU/fFxVCRqNAXSJdUoio01Tq/qj8qpZQFqT7cZyOPl4J jvaD+uZo6COfds8/+tl4j902vqBT9R7/AHKHa7FXp11S4lETUw+2lDKSgDcRkcDKhgjwBycH Lus+gVC1tN6dQ5SYl5mqSEgGW3Xt3dKeCTjOPW2buPPEQTRTVOsXlddyW/XmaR6TSfiv05Lr aHMLKF+q6SrAOOePk5EYfa17v3lW9vSor93JfYR0B2rzn5oh2oNsX+3rRes/a9sNz8jX6eKY JqZ292hC5dpK1AlQwQUEc8HyMOC1rfrGn+j0vSKEwzVa7Iyii004va26+olRGSR6oKj4jIHh mNfpNfVfuK4q1RbiRQpl2nstOqnaGpxcu2teQWFlRI7wYJ4OOD5RHu0V+zzSD/pC3+VZheJ0 31LVMXtbMrRZFmiXJUw89Un3EEttpdKwpICskEEcYyD0weY6qo8gil0mSp7BJalGUMIJ6lKU hI/FEW0lvCava3ZypTssxLLZqExKJQ0SRsbVhJOfHHX8Q6RB+1q6UaeUlGxSg5WpYFQ6JwFn J+jHzw7R0ERu+LMot50v0OuSveFJCmJhs7H5ZY5C21jlJB+Y+ORCgl5FzSu5kT99UaRrlHyA xdrUkFTssroPSsZJ4wO8HPHJJOA5KSigigOz1DlpF2mzSFTOZBlKkzHU5ASPWJ5+eFuvUSmt 1N6po0ru0zTiMLnBRWw6v1ehO7cfKI1fOv8AL0asNU2Z06qi25yWCVipgSzrjZJBQlvYvejr 4gE548S0dO6xJXnQ3HX7QnKIwhxv/J6lKJbDi0AFKkDxCSkAEgdBCq7P/wBfzVInk9+5z/69 UdIQE4hP17Wd43PP0Wx7TqF1O007Z5+WdDbbRGcpSdqtyuCMcZIIGcRMtNr9pd/Ud+dpiJiW flnjLzUlNJCHpdweChk9fA/KOoIEughHdsVpbmkAUhOUt1FhSz5DCxn6SPphoadJCNPrYQla VpTS5UBSeih3SeREhgiLajXrI2Hb6avVGJh+WVMNy+2XAKsrPXkjgYMShCgtCVJ5BGRHsELP tKfWQun+Ka/LNxuNFS2rSW0SwgoR7mMDBOTnYMn5zkxNIjmoN40yxLYma5WlOejNEIS20nK3 Vn4qEjpk+3jgwt6Lrm+KlTEXlZtStqlVUhMjUX3C62tR5SFjYnbkfL9GTDqSSRz1j2CEdpOl J7QuqqsesPRgD7Cn/wCgh4wRC9RrouS2zIe9qzpi5Uv7++LU2ljuMY25ylWc5P0RG9M9Wahd l81S1q1ab9CqMhLekObpsPhPKfVVhCcEhYI6+MNiCCEj2cf2Qan/APSB38aod0ERLUi/qLp9 QfdSuvHas7GJdrBefV4hAJHTqScAfOIq0xvSWv60JSvycq7KNvqWgsuqCilSFFJ5HUcRK4Ig eu4aOjt299u2+gLxtUB63G3r7cceMazsz/WRtr+A7+WXDPil1wNNqWsgJSCST4AQkaFrpU7k Dz9tad12pyCHVNiaadSEK29ecYzgg4z4w7mlFbaVKSUEgEpPUewxVBCnu7/jF2D9zZ/+zDYg iHanag0rT2jsztVQ/MPzLncSknLJ3OzDnkB5DjJ9o8SAdDZ2ptXqdyytFuiyKrbr88la5J5x XftObUlRC1BI2HA6HPzcQz4IIR/Zf+LqB/0jmP7oeEa64pyep9DnZuk041OeZaK2ZMOhovKH 2IUQQPohJ3DrfeVsUhdSuHS5+Sk0rCC85VkpGVH1RjuySf8AxxDhsavm6bQpFcVJuSRn5dL/ AKOtW4o3DzwMjxBwMgjgRvIIQvbKITptRFHOBXWCcDJ/WX4esorfKMqwRuQk4Ix4Rdgggggg IyMGIfqRp5QdQKKuRrcqnvwgiXnEJHfS565Sryz1HQxzndFEq2mEi3QNQaem79N1ubZebQkp mKeSRgoV/wAmr/U3bVYwCMkGQ2/NXhY1vS9c03qovqwsb1U9/mbk04BKQR6wI8QBx+08YcOm uqVs6gyx9xpstVBAy9T5nCH2/MhP2Q9qc+GcHiJyACM8jxj2FX2n3O70RuLLi29wZT6ozuy8 jg+yKOy4lSdEbf3IUjJfIzj1h3y+Rjw+WJ5eNHpFwUCapFxISunTe1paVOlvcSobQFAg53Yx 7YhdgaOUKyb2m7gpDswpDkomUYl3lqX3HTcdxJJyEpAHhzET7QDil6r6Py6GlnFXLu/HH66x kfNjMPuMGrlbsi/Ky06JKdmG1ty72EqUhZScKSlXCin42PZEDsmw69J3gm57yuBir1NiQ9zp b0aVEujuyvepawD6yifDoPLOMRvtZn/8EUH1wP8APcv6pPKuF9Id0aS9qM7cNpVejy80ZN6e lXJdMwAT3ZUMZwCPxxFtHrIrFiUcUidn6TM01lP1ESciWHXHCfWcdVuO44wOnQDyiIdor9nm kH/SFv8AKsw84xpuoSco/KsTU3LsPzSy3LtuuBKnlAZKUAnKjgE4EaDTu0Zay6E7TZOYdmUO zT02pxwAEqcVnHHkMD5oXPa53DTOQcQsJKKvLqwo4SrhfxvHHjxDgm6rI05hpypzspKJc4Sp 55KEqOMkAqIzGVLvtTDSHWHEONLG5K0KCkqHmCIrWlK0KStIUkjBSeQRChrdj1+xpmYrelLq TKn6pNWw+SZV7kbjL8/Ulnk4HBPyARKNMdQ6dfdMdWy25I1aVUW56lPnD8qsEjCgQCQcdcew 4IIibFCSQSkEjoSOkBAGD4xznoJt+H/VLYUlPfL5SCB+vHzjo2KHt3dL2Y3kEJz5+EIvskuS 7Vp3JIPbE1yWrLvugjOV7iAEq6525SsD2pV8sXtLA0rtEapOUoJVSsSyXVN/F9J2jeCf22/v c+3Psh4wQlu1240jRqaS6BuXOMJbzn424n8QVDJ07LatP7ZLCFIaNMlShKjkpT3ScAnxiQQQ le1wkq0kO0BRFRl/VOOeTxg9fkhx08YkJYbNmGk+pjG3gccRfghZ9pT6yF084+pNflm43mjy kL0qtFTQbCfcqWHqAgZDYB6gc5zn25iYRDtW5+3qVYk/UrukW5+mSZQ96MtIUXHAoBATnx3E fNmFVSqFeetaqNWbz9Do1mNTCJ+Upcv6z0zgHYpS+oBCiM8cE+qODHQw6QQQj9Jue0Fqv8sr /ZMPCCI/eiWp+kO0Ruv+4dSqiFMSkw24lL+4DJ7oEgqIHXHIHOR1hE2lbL+iusFCpcnUVVen 3YhbMwX2gh1txvKgsHJzyr8J9kdLQQQiOzdNbry1WlfV+pVvveM59Zbo58Mep+OHvBHI01Wr oOq9Que/NPrmrDFLWtFKl2JRfosolKj9UztKVHAB3ZxnnwTic9jWqOTdh1aSMpMtsS1QW42+ vJbWFpSShJ804yR/rA+MdAQRAteVITo7dpdQVp9BWAM45OMH5jg/NGt7M/1kba/gO/llwz4x qkyJmnzLBdUyHW1ILicZRkEbhnjjrzHOsroa3a2n8/VLev6ttT8uw7PNTUhMd1KuBKCcbEk5 BCQCrd80N/Ri4p+7NMKBWqw33c/MsqDvq7d5QtSAvHhuCQry9bjiJpBCnu7/AIxdg/c2f/sw 2II5h7Wpq0pfentQpjqGltPH0Vx0/U0TAdbUFKzxj4vzAxLH6xfWnd12sxd9zSdx0iuzQkHB 6GiWclnSPVUjYMqTk85Hh4Zh5QQQjOywVKlr8Lgw4bhfKh5HAh5wQi7llE6i9oNi3qmrfQLU lW6g7LYyl+aXtKQsHgpwpPGOgUOijD0AAGBwIIIQnbMKBppRy4RsTXGCrIzkdy/mHpIlBkZc sgBstpKQBjAxxx4RfgggggggjHn5KXn5N6UnGGn5Z5JQ606gKStJ6gg9RCGurTmv6a1h+69I FAyZQkz9urBUh5KRypGTknHOPjA5wTnbGvkqTYmt0u7UqEXLTv6WypwMK7t5pwHlSkjb3g/1 xhQzzjpF6S1OvXTKoCl6tUp+fpAIbZr0g3uCvIq6BXtB2qHkqHvbdw0m5aY3UaDPy89JOfFc ZVn5iOqT7Dgwuu1MQNEa7lIVlTAHPT6sjmKuy3n4EbfyVHl/qon/AJZfTPQewRDO2bWarS7e thFOeSzLLnlPuKAyvvWwlTWPDAysn2hPth/UZ2Yfo8i9OhsTTjCFvBv4oWUgqx7M5hK9oQn4 S9HRgge7Z/Ky8PaObe0jW61I6u6by1PA7lM028wkIBU48p0IUnzwUlIx7THSUJXtYfsCo33b lvxLh1Rzv2tq9cFENkmgvrZbNQW/uSDy+3s7oK8xha/V8fmjoOULplmjMBIeKQVhOcBWOcZ8 Mwke0V+zzSD/AKQt/lWYecc29o2erres+mkpTH1IYVMtOS6CDsL/AH4SoqI5I2lIPkCfOOkh 0hIdr91TGlDDreN7dUl1pz5gLMYWu8o/Wr902kpKiyVcnSmbfVITp2MOI7tGStXgB1HXkDg9 IgtpV6vUykVH3BEta0xcV2M0MybLYcZo6kNgOKSg8b1HGfA7TjwxkV/W++rLmarTpqXkK7JS Uw9Sparlotl6YSAQpYSSlRSk8pAHJ6xMLb1oqVwaZ3rdc1LS1Kk6bJoYkV4Usqni1yPIp7xT YA8AefGM2hWxK6saeW1dq5tyl3omXGytSKdrgdQSn6okYC05HKfaQCBGwt3UyqW1X2rX1Wlk Sc66styddaTskp0AAjJPCFnx8M+A4y3mlpeaStCgpCgClSTkEeYMc66DOKf7QWqLrvLgdWjP TgPEdPmEdGwQrrt0Xotduh64afVa1b9VmBiZdpMyGe+4AyeDzxzjr1PMS2wrLo1jUU02gsLQ hay6886srdfcIwVrUep4+T2RJIISPbBly9o84sLQkMz7DhCjgqHrJwPM+tn5AYZemn1ubV+5 Mp+RTEjgiMah2XTr7t8UiruTDcsJhuYCpdQSrcg5xkg8EZHzxJkJCEJSnoBgR7BCz7Sn1kLp /imvyzcbzR1DyNKbRTMr3ue5UsrOc+qWwUj5hgRMIiWqFjSWoVpvUKozMxKtqcS8h5gjKVpz jIPBHJyPxdYiNN0amqexLMM6iXmmXlkoQ0ymcSEJSnGE42/F4wB4DiG2BiCAnAPGY5/0LZWx rtq2h0EKM2lYyCOFOOKHX2ER0BBEO1K08pGoNPlZeruTUu/Jud7KzUo5sdZV4kHBHgPDwjV2 ZpPS7buJNfmqrWK7W221NMTdVme+UwgjBCBgYOMjP+sfOGLBBHPvZp+uTq/902vykzHQUEB6 cRprTtmk2lSE0y35NuTkQ4p3u0ZPrKOSSScny+QAeEbmCIDr4ndo3dgzj/IlHoT0IPhGu7M/ 1kba/gO/llwz4pdbS62pCwFIUCFJPQg9RCa+AKnN99T5S6bklrXeVvXRWprDJJVlSc4+IfLG fHMN2lyEtS6dLSEgyhiTlm0sstIGEoQkYAHzCMqCFPd3/GLsH7mz/wDZhsQRG79sujX1QnKV cEv3suTvbWj1XGV+C0K8D+Ajg5iL2po7RqHcLNbn6pWq/UpYESjlXmu/9G6coGBzx1hmQQQj uy6pK27/AFIUFJNxPkEHII4h4wRFbesWlUG7rguOTVMLqNaUgvl1zclASOiB4AnnnPTjAiVQ QQg+2e33umVHbBwV1tlOflZfh6U1n0enSrJVu7tpCM4xnAAjIgggggggggIyMQtdS9JqZdky is0p5dEuxg75eqyvqrKgMDvMY3DAxnrj2cRHrY1CmafUF2RrHLS8tUnT3EtPONZk6q3naCc5 SFK68gDnok8Rrrt0WqVuVFy4dGam7Rqlu3P0xTv+TzAznandwPH1VZTyMbcRAtStZXa3pxX7 Ovq35mi3UUNbAlslpxSXEK3YUcoyAcfGGPGGB2ZLstylaPUmUqdfpMlNJef3MzE422sZcURl KiD05ia3nO6a3nISslcVwW/Ny0tMomm0GptJ9dOcZwrkEEgjxBjfpvyzkpAF12+AOg90WeP9 qEtr1dVvTl+6VTknXKZNS0lVy5MuS80hwMo3sHcraTgcHk+UOr3+2f8AbXQP6xZ/SjS1mq6b Vqr0mp1SuW1Mz9KcLsm8uotZaURgn43Pgec4IB6iN17/AGz/ALa6B/WLP6UJ3tRXbbtQsKli m1ymTzjVXl3VtSk028sISF5O1JJx+cQ5FX1aSEoLl0UNAWkLTvn2k5B6HlUaS7ZzTu55WmLr 9coT7EnOJm5Vw1JtADzfkQsZHPKenIz4RJJm6relWg7NV6kstEgb3JxtIyRkDJPlzCM7RV0U NV26YTcvVZGaakK0mYmPR5hCy2hK2SScHjp44h0G/bPBwbroGfuiz+lEfr07pvXq/RKzU7io Ls9RnFuSi/dRoBKlAA5G7nkAj2gRumdRbLcA2XZQj623mfaHOCf23sMJztYXZbtY0tZlKRXa XPTK59pwNS00h1W0JVk4STjqIZLV/wCmzj1Pqb9x2+qfYYLTMwp9HeISoDckZ5AOBxGpq9a0 brEpPy1TqlszLE9MCbmErmE+u8E7Q5kHIVt4yMdT5mMiWuLSCUplOprNTtRMjT3UzMoyXW1J Zc5IcTnorknPXmNTedY0yq+m9atSjXHbFPanGV9y2h9DbSXs70qIH+uEknEV6Q3ZZdmad0Wh T930Azsq0e/7qeStO9Sio4PjjOPmjf3DfOl9xUp6m124LdnpF0esy9MIUM+BHiCPAjkeEKU3 1I6TPIdtO7KfdVlKcCDRVziVzcju8WF9VIHkenA6kqjR6FaiW6zrVetWnJlmk0mrtrfYcnnQ ghXepOw5JGSFKPX7HiOiW9U7DccShF3UMqUQkf5Ygcn548Oqthj/AMrqJ99o/PHnwrWF9t9E ++0fng+Fawvtvon32j88UjVmwSso991FyAD/AL5Tj6ekVfCtYX230T77R+eFN2nb9tKv6VzE hR7ikZ6eXNMqbYlXUuKVg5OcdBjJzxziJtpzqnY7NgW0xM3NTJaYap7DDjL74QtC0NhKgoHp yDElRqlYi1BKbuomf5Wgf3xUvVCxUJyq7qHjAVxOIPB6eMUfCrYWce++iZ/laPzx58K1hfbf RPvtH54PhWsL7b6J99o/PFKtWLBSTm7qNwM8TKTEB191Ds+saRXFT6VctKm515tsNsMzCVrW Q6gnAHsBjZaRaq2anTK2mKlcdLk52VkWpV1h94NrQptIR0Uc+A56GJY3qzYLilhN3UbKFbTm ZSBnGeM9Rz1HEUfC7p/3KnffbSdiTg/VueuOnU9YufCvYOVD33UXKev+VJ/8GAar2CQD776J yM8zafzwfCvYO4j330XIx/8Amk/nj34VbCPS76J99o/PCW0w1FtOR1x1Cn52uyzMhVFs+iTL uUtu7MggKxgDnjPUQ2161adIWpJuuQykZOAsj5iE89fCBjWrTp5exF1yAOCfXC0jj2lIEX3d X9PmnW21XbSipw4BS7uA+UjgfPiK3NW7AbDhVdtIPdp3K2vhXHsx1PsHMYPw36cfbVJ/0bn6 MXWdadO3lJSi66eCpW0b96Rn2kpGB7ekZvwrWF9t9E++0fnhD9n/AFAtmj6k6juVSrS0pKVa bEzKTL6+7bcSh13IBPiQ6CB5Aw+PhWsL7b6J99o/PHo1UsMpKhd9DwCAf8sR+f2QDVSwylSh d9Ewnr/laPzxeXqZY6Joy6ruoQdHUenN46Z65xF86g2aFoQbsoG5fxcVBo5/2or9/tn/AG10 D+sWf0oh2sN82q/pZdTMtcVImn3qc802zLz7alqUpO1OAlWTyRx5deI0PZtvi2ZXSCjSVQrt LkZuUU6y4zNTbbSwe8UoHCiDghQOYZS9RLLQtxKrsoOUI7xWJ9o4Tz/rezpF33+2f9tdA/rF n9KD3+2f9tdA/rFn9KD3+2f9tdA/rFn9KKVX/ZyfjXZQBxn/AIRZ/Sio37Z463XQP6xZ/ShU 3je9rJ18sme98NKXJS9PnEvTDcylbbZWnCQpQJAJwep/GIaLeodmOMIeTdlA7teME1BodfYV Rd9/lofbXQP6xZ/SjxN/WcoAi7KBg/8ApFn9KPff7Z/210D+sWf0oPf7Z/210D+sWf0oPf7Z /wBtdA/rFn9KD3+2eel10D+sWf0oTPZtui3aU1fCZ+uUmTS9XnnWQ/NNtBbZ6KTkjKeOohze /wBs/wC2ugf1iz+lB7/bP+2ugf1iz+lB7/bP+2ugf1iz+lB7/bP+2ugf1iz+lB7/AGz/ALa6 B/WLP6UHv9s/7a6B/WLP6UIjtRXnbN26cUlu361IVFaK60HGmnQVgBp4E7eu3Kh62McjmOlp RCW5VlCBhKUJAHkMRdggggggggggjT3XbVJuuiP0mvSTU5IvEFTayQQR0UkjlJHmIsWRbfvV oCKQmpTtRlmVq7hU4oKW019i3uA5CRwCefmwBbvW1KLc9Kebq9Ekao622ruEzCBkKwcAL4Kc nyIjmbssaYWxeVr1ipXVShPqRNhhgqfcQEgIBPCFDxUOvlDmOhGmCVBKraZC1fFSZ18Z/wD4 kXEaBaZ7ebYRnnrOTH+JCq1o0nsmiXRp7I0inLkE1erJlJppp9xQeZKkBXKlHaRuAGP2x8hD VOgemYBJtdvj/wDWTH+JFhnQXTFtxbZt5Li1KK9qp1/Kc+AAX0EZA0D0zx+xdH35Mf4kKvtG 6U2Zatk0+bt+kppsy9U2Zdb6X3VkIUleRhaiMcA/NDTa0B00Q0hJtpKyBjeqbfyr2nC4oVoR ph3yUe9tnfg+p6a/k/N3kXE6B6ac5thvk5/33Mf4kKXW/SuzqFdGnUhRaT6DL1irpk5zu33F FxtS2k4ypRxwo8jzhtnQPTP7V2/vyY/xIxkaM6TrmTTkUKQVNo9csCedLoHmR3m7H4Iy2dCN NELS4i12SQcgKmX1D5wV4MKvtP6a2fa2naatb9DYkagZxljvWnF/E2qyNpVtydoycZMNCjaF 6dS1MZQu22H1qZbSt151xSlkAHd8bCSSOduPLpxG0Vo5p6p1LhtKmbkjAAbIHzjODGDV9H9M WZV6aqNtU2WlmUl1x3vFsoQlKTkkhQAGD8nj1hPSM72dahXVSZoj8sypZSiffMw3KuH2HvMp H8JKRxDgGhGmveBz3rMbvL0l/H0b8RkSmiWnMr+tWrJK6D6qtxzoSfslHzjId0e0+caWhVpU oBY2kpb2nHsIOQfaI580tsG3ZztJ3jQajSWJik09iYelpRwlbaD3rSU9euEuHGenzQ8bm070 qoFGfnq/QKJISCRsW84jZjdwACOc+WOY9OmOlcvJSLi6DQ0y04ppqVdWsYfUoZbCFFXrFQHg SVe2MmX0w0yenZiRYtyhOTcqlBeYSlKnGgoeqVjORkA4z1xGIbE0kAdPuRbGGpoSLnrN+pME 4DJ54WSR6vWNqNItPz/5I0n+hEeHR/T4lJNpUrjphrEKvtMad2fb+lkzUqNQJSRn2plkNvSz ZSeVYIVjwxnr448YlemmkdhT2ndszM3b8hPTD0i0+5MLBKnFrbyrJB55UePDAxyBGBedlaG2 J6Iu56bJSKnz9RQpyZeUvbjnYkqOOmSRg+OcxtrV000fuGjPTNu0elVGRdUUuOtPuOKQoeGS rc2cc446gxuZDR/TZUm2ZS16W8wo70OZLu7/AKxUcj58RpLxtjRqyWWXbnpFDp4mVkNJcYUt SyMA7UpBOBkZOMDPPWK7QtPR69pScetqiUafYlnSw8tuWW3tVjPG4AkY6EceRiRfBDp/9qVJ /oYX+vmmlmUbSS4KjSrcp8pPS6G1tPMt7VIJdQOoPkTGw0g0usip6YW1PVC2adMTczJNuvPO t7lLWRkkkmJh8EOn/wBqVJ/oYjF6ULRayxLpuilUCQW8fqTZlytxQPG7agFW3j4xGBGfL2Rp HM26uvS1Gt16jIbU4ucbCVNpSPjZIPBHiOo6RpbfkdCbgqiKdR5W2pmec/W2Q3tU4eeE7sbj weBEyGkOn+P2I0n+hitvSawGt+20aMdySg7pZKuD5Z6H2jmE5pnp7adQ1v1Ips5Q5KYp0gWR LS60bm2d/Kto8OR83SHB8EOn/wBqVJ/oYPgh0++1Kk/0Mae6bH0mtSlLqNxUGhyEkk7e8dZ+ McZwkDJUeOgBMFo2fpHdlLXOW1RLeqEqrAWptgFTZ6gKB9ZB9hAMbj4IdP8A7UqT/QwfBDp9 9qVJ/oY9GkOn4/8AJGkf0AhH6B2Da1c1B1Ml6tRZSblaZPJYk2XQVIZQpx7IAJ/82kZ8vlh4 fBDp/wDalSf6ER58EOn/ANqVJ/oYpXpJp6gEqtKkADkksgARhyml2l9XZ3yNvUOaaQsErlSC AoHoSk/SDwfGLsxonpy+lxK7UkQFnJ7tS0Ec54KVDHzfJ0jHc0J01cQhKrWYAQMDbMPJPzkL yfniE6xaNWFQNMbiqlIoCZaflZbvGXhMvKKFBQ5wpZH4IwtCdHrGuTSui1auUT02oTQcU68u ZdQThxSQMJUAAAB4RP06B6aAc2u1n+VzH+JHitBNMgMm12/vyY/xIto0K0ucOG7cYWcZwmef PH9JF74BdNNmz3rtYzn/AH0/n6d+Yqa0H01aWFJtdgkftpl9Q+grjKltFtOpZpDbdqSBSk5B c3uHqTyVKJPXx9nkIXV06aWazrtZlMZt+Sap81Izbr8ugENuqQn1CpOccZPy+OYYzei+naJx c0m1KeXVjaUq3FHzIJ2g8dQIxjoVpsVlXvWl8nH/AOYexx7N/wD94tzOhOmilOvrtZrccrKW 5l9I88BIXgfIIj1j6YaO3rQkVWh25uYK1NONuzMyhxlxPxkLT3nBESD4AtM/tYb+/Jj/ABIP gC0z+1hv78mP8SPPgD0z8LXb+/Jj/EhQ9nvSm0LhYuxNxUwVJ6nVZck0pT7iNraehwhQ6nzz 0hv/AABaZ/aw39+TH+JFo9n/AE1w6Pe2PXPB9NmMp4xx6/z/ACmPUaAaaBa1G2UndjgzswQM eXrx65oBpoojFspTgg8TsxzyD+39kVHQLTTgi2G8j/8AWTH+JGPL9nvTZlxxZt9Tu/olydfI T8mFj8PlCg7TGldtWXQqDV7Xp4ke8qQln09+45v3oKk4CicAd2ry+N4+HWrH6w3/AAR+KK4I IIIIIIIIIIII557Fcw2rTqsspJLjVRUpQx0BbRj8RjR6Z6f0/Vug3VdV1Ts09XJmffl5N8TC gKeEbVIKQOOCeh42gYxkmG32e7knbn0rpM1VXe/nmC5KOvZz3vdqKUqJ8SU7cnxOT4xEO0Pu +EjR4oAKvdo4BOAfqkv4w47on3KVbNWqDISXZSUemEBXQlCCoZ+iOXLV06kLj0Qqmo89Uah7 83G5yppqCJhSFNLZUvCcA4wQ316jfx0EdFaU1+aujTugVqoJ2zk3KpW8QnaFLGUlQHgCRn54 Xfa8eVLaaU+ZS2Vhiry7pA46JX1Ph5Q4qzOqkKJOz6G+8VLy63w2D8YpSTj8Ecs2fp1K3VpH VtRapVZ83i+JmfZn2ZpSTLqbKsJAGMZ2kHyBwMYjojSetzNyab27V58K9LmpNCnioY3LA2lX zkZ+eFx2iv2eaQf9IW/yrMMbVqrTVC02uSp05Zbm5aRcU0sdUKxgKHyZzHPFb00otE7PtLvq lvzMtdbEvLVU1EPKK3HHVIJSQTjjfgY5yOc5MdQWpUHqva9HqU0z3ExOSbMw41/o1LQFFPzE 4hRdsXHwQpySD7osYwPHC4dcl/vNj+LT+KL0JXtYzbzendPp4fVLSVTqrErOPgZCGfWUSfZl KT82Ikuqls0VjRK4aSmQl006nUl5yVZ24DTjbSlIUP8AW3AHPjk5zkxm6HzsxUdI7UmJzPfG RQgk9SE+qk/OEgxOII5r0o/43GoP8ie/Ky8Sjtf/AFnHv5cx+MwqLtmJ6z1W/pnWnpiZcpty yU/SZ1ScB2SO8YJzwUqVjHygcAQ37SebZ7Td+tPOIQ67TJNxtKuCpKUICiPMAkZMJCqBtyn6 gVQrbcpjl+MLZmQoFtWHHipQUOD6q0nPkRHacEJ7tZfWUqv8fL/lUxO9Lw0NNrV7gIDfuVK4 2Yx+tJz+GFjqTKS072l9Ompxhp9r0OYWEOpCk7khZBwfEEZHt5iil06nS2tF/Um2lS0nITFv BU8iX4aZmipScqA4SoJOcDzJiR9mBwOaI27he/aHk9c4w8viIX2hpCrzmr2nKaDI0qcn3G5o MtVBBW04UgFQdHTaEnIxzkn2Q7rOl6hL2/KCtydMlKqpGZlumpIYCsnATnn4uPnz1EbqFn2l PrIXT/FNflm42mh31oLR+5zX4onEJHVSx5+o6oU+57Wft+frkrI9y9Q6sQQ80SsBaR1ydyhz gcdeoiOVGu06s9nbUFmQttq3JmQmXJeekmFJW16QFt7lJUAAfDjHGPEYMajT2wrrum3rIEzb tu0CjU12WnxUUo3T82EEqB9U8b8jIVjnn2R1QORmA9DCL0TZdlNb9XGGytUsqbZeUpSMeuou KAz/ANZWPMcw9IIRmrTEpUNftNpG4WW3qMpqYU02+nLbkxjgHwJyG+D7PONpSJKRpnaSqDNA ShlEzQO/qrDCdraXg8kNrUAMbyknjyyfHlvwQRz3oWhDevmq6W0hKRMdAMf8qqOhID0jlHXa 8Tc13VOkTPpj1pW440zMScm4W11OdWQEsqX0SkEKGcEjaogEkYwtJalMy/aPkqVTbZlbaDMs /J1STkny+2oJQpYUo5xkL2DI8eI67HQQRAtem1O6OXalPUSK1dCeBgn8Ua3sz/WRtr+A7+WX DPiH6xoWvSi7u6fdYWmlzCwto4V6rZVj5DjB9hMc76d2+KpTLBmLHsqt0issTDL09X31d3Lu sg5dwd31RK/AbR5DMdcQQQp7u/4xdg/c2f8A7MNiCCIRbdkrt/Ua4q9T5xKKVWmm1v08II2z STgug9MEZz5k+wRN4II557GyEm2rqdKUl1VWIUsj1lAIBAJ6nkn6THQ0Ec4T+s97m67xXSaD Spi27Tm1tTyCpYmHWUuKQVJUTjd6ilfFwB5+PQlHqLFXpElUpPd6NOMImGt4wdi0hQyPA4Ij Lgjn/tnzAZ08oSVNuFPuy24VpA2jay7weepzx8hh8U55MzT5V9AUEOtJWAoYIBAPIjIggggg ggggggggjnzsWyCZfTqqTofStU1UFAtgct7EJHPy5jZzejNdkKzXk2XeLlEt6vqU5PyZlUvL QpWd3dKPxchShkEEDA5wCGpZFsyFnWrTqDSUrEpJN7AVnKlqJJUtXtUoknHHPGBCf7SsyZS+ 9JJgJ3FuslW3OM/VGPGHy+2h5hxp1AW2tJSpJ6KB4IhDsaHXDT5Oo25RL5fkrIn3Ct2R9FSt 8JUfXbDnUApAGQefFPJy7qLTZaj0mSpsggolZRhEu0knJCEJCQM+PAhP9rr61TaVTAYZVUZc O88qTlXT5OvzQ69qVthKvWSRg55zCHXodXZNFToNv3q9TrGqbqnZinejJW6kKI3NoWeQkgYy COOoOTDtolNlqNR5KmSDfdSkmyiXZQTnCEpAH4BCY7RRAvvSEkgAXA3kn+NZh0Vmmy1YpM5T p9vvJSbZWw6nzSoYP44SlE0LqTUrKUKuXnNVKyJOZ9Jbo5lgguYOUoW5nO3PJSOPIA8h6thC EJQ2AlCRgADAA8hCP7Y31oUfdJj+yuHZInMlL/xafxReiLamWjLX3ZtQt+aX3ImUgtv7NxZW k5SoDjPI8+hMJ9zTjViuUGXs25LjpKLZbCUPT0ulS5qYaSfVaOQM4wOTj2lXIh+0inylIpUn Taez3MnKNJYZbGTtQkYAz48DrGZn5fojxfxTHPGjzLP6prU1x1QVNpQUt5ODsU4gq48QMI5+ Tzh91alyFYlUy9Uk2JuXS4l0NvNhSQtJylWD4giNXcNl2/cVZpFVrNNamp+lOd7KOqJBQeDy AcKAIBAOcEfLGuvzTW2L6cl3rgkVuTcukttzLDymnQgnlBKSMpPPBzjJxjMe1HTS056yE2ku kts0NCgtDDK1IKVg537s5KvaSc+OY1tnaRW1aFearFHXVRNNoU2A7POLQQoYIUnofkPiAeoE MPI9v0Qk+1HJCT0VrxS/Mvd/PMPEPOFfd5cR6qM/FSMcDwyYnuj3cjSu0xLhwNCmMABzGfiD PT25jB1L0tomoM1TJuqTVSkZ2n7wzM055LTmFYyCSlXAxx0xk+cbKxLCt+xqS/IUKWWlMyrf MvPOFx2YVjGVqPsJ4GByeOTEFkez3bVNme8pVeuyQl+970SktUQhodMjGzdg4HU546xLdQtM bdv5VPcriZxMxIpUmXelny2tIVjPnn4o6iK9NdO6Zp/KTkvSqhV51uZWHFe6EwHdhH7UBKQP bxkxNNwxnPELTtJEHRG6cf6Fr8s3Gz0PIGkNo5/c5r+zE4yIgeoGlVr33UpWpVlmaaqMskNp mpR8tLKASdh8CMk+GeesbOjWHbdLss2oxIIeoq0kOsvErLxJyVLPUqJGc+wYxgRJpdpqWZal 2EBtptIQhCRgJSBgAfNFyPM5BxCT0eeI1z1bZLwc3Pyq+EjwSsYz7M4h2wHiIxflk0O+6Uin 3AwtxDSw8w604W3GV4xuSoeOD0OR7Is2Fp9b9iysw1QZZwPTJBmJp9wuPPY6blHwHkMD2RLY II590P8Ar/asfygflFR0FnnHjBHN9T0oqk7qJdlJqslNu2zc02ips1iRcSlcjMN94pIUlR5H rrT0OcpIwc4Y2l2kdG09qlSqrE5O1OrToKXJydUCsJJClAY81AEk88CGVkQRB9cJVyc0hu5p kgKTTnXSSccITvP4EmNR2ZvrJW1/Ad/LLhnxrrkpDFwW/UqPOLdblp+WclXVNEBYStJSSkkE ZwfEGLlFpktRqRJU2RSpMrKMoYaClbiEpGBk+PAjNgghS3ZvPaPsTIT3Ypk9g55zt5z7On4Y bQORxBBBBBBHPHY9bmJWnXpLTKm09zVdhZyN6F4IVn2HAA/gmOh4I5Yt7SG6Liv7UZc3VKhb tAqFWeQ+hDPrVFhTq3BsJ4AwpPrcj1iOeRHT9NlGafT5aSlGw1LSzaWWmx0ShIASPoAjIgjn 7toyjL2mtLmFEiZbqzaGgATu3NOZTjp9iDn/AFceMPOgtrZodOacKytEs2lRXjcSEjOceMZ0 EEEEEEEEEEEEEci9la1rpqFr1eo27eHuHLOTYYXLiQRNb1JSDv8AXICeFY4645h0tWhqbuw9 qaxtx1RQWc5z7VeUXfefqL++f/8A4GX/ADwme0Dbl2sXDp9K1a8FVaZm6gpqUcRTW2DLOb2h vAQfXPKeD+19sOc2hqLuyNTuM9PcKX/PGKbE1EWAF6qzXT7Gjy4zFbljahLcLh1TmUqJ+Kij S4SPkEK3tHWld1M0xemq5fL1ckm5xlSpVyntMcnKQQpHPGenSGnK2ZqK3KMIOqBJQ2lJJobC iSAPEqyflPMeu2VqK4T/ALqTicjHqUSXHj1+WLPvA1A/fWnv6pl4UWutnXRL1+wJOrXvM1eY n6oJaVcck22BKrUtsBY2dTkjr5Q6mLEvAA+kan1hav8AzdPlUD+wYBp/dCW1Np1Nr+1RJVmV lieSScHZkdePLwiwNNbjDHc/Cdc2zz2M7uhHxtueh8+vPUZhR9pKxqtQNOmpqbvSvVxoz7bY lZ0pUglSVYIwM5GOPlMNSW0pqqabLIb1JvNt9LaAomaSpOcc4SU5H0n54vo0qqWD3mpV7KOO onEJ58/ifgin4JZ3Y6kaj3yO9+MfdBPXoSPV448sYjEe03YlKpJ053VC9Wp+ZSVS0uurp3uJ bHrFKSnkAK5+k9IzXdJJh0EOai34QcA7amE9PkQIxvgcmgyltOpF+cH1iamSSMjI6cdBz4fO YvN6PuNOBbeod/BQ6bqsVD6CMQi9OtO36jr/AHdRVXRXmE05pxblRlpvu5uYJWgALXnJHrEk +aR0yIefwPO5SfhEv7KcY/zsfA5GfV56+MZHwVTn7419f1gj9CD4Kpz98a+v6wR+hHp0rmyk D4RL5ChnJFQRz/sRSdKZwgg6jX1g/wDpBH6EWjpLPHI+Ei+NpIH+/wBOdo6DO3r7fGFn2i7A n6HpnO1GYva46tLszDJ9Dn3kuNqyvaDwByMxItK9L6hM6cW3MSt/3TItPyiXzLykwgNI3jcE oGDgAk+efZEl+Cmvfvo3d/So/NF+V0zuGUWVs6nXSVFO098GnR8wUkgRZRpVXkKBGqF3ZHm4 g/jEefBRXv30Lv8A6VP5oqGllfDiVjVC7NycYytsjjzGMH++Mh/T67xK91J6oVtCv2z0lLuc HrztB/DxC61usW66bpfXJ6raiVKqSjKEOOya5RttDxLiEgEpOQPinHmM+MbHRvTuuzOmFvzE tf8AXacxMy/folZVLZbaCySEpKkk+Pn1zEvb0wuFtlTSdT7pKVJKCVd0pWCQeFFOQeOo5i8d N7jwQNTbmAODy2xnIAH7T2f+DzGObSrDlVNN+Fise6IbTNGVS3Kh0NhWAvYEZ2Z48j0MZwsG 6A4V/CZX9x//AEstjw8NmPD/AMZir3iXT++XXfvOV/w4GLBuVoEHUq4VAknmXlScn2ls8eyF BpbYtZc1i1GblLwqcnMSTraXZ1plpS5kvFS/XSpJTxtPQDnpgcQ4BYt0Z51LrxHslJX/AA48 94l0/vl137zlf8OKGtP7na37NTLgO5RWd0tLK5PllHA9g4EXBYt0YP8Aul17P8klf8OPPeJd P75dd+85X/Dj33i3Rg51Lr2fD/JJX/Dj02Lc/q41Kr2fHMpKHP8A/DhI6TWtW53WzUJiUvCp yMzJuFD840y0pc0S5wVpUkoHxT0HjxgZh2KsK5A53jepVxBZGFbpeVUnGeMDu8A+3xityxbl yO61JuBIxzulpRXP9EIo94l0/vl137zlf8OKHbAud0JC9TLgASoLG2Wlk8g55wjkezofGKPg 7uXvm3fhNuPcjJA7mX2nIxynZg/P08Ive8S6f3y6795yv+HEa1Msq5pfTm533tQ6zNNM02Yd cl3ZWXSl5CW1FSCUoBAUARwfGI52ebLuKb0spc5JXzUqXJzKnXGpOWlmVpaHeKB9ZaSSSRny 5hke8S6f3y6795yv+HB7xLp/fLrv3nK/4cHvEun98uu/ecr/AIcHvEun98uu/ecr/hwe8S6f 3y6795yv+HB7xLp/fLrv3nK/4cKi6bJuQa/2ezM3zPPTUxKTC2J/0Zpt5hDaVEoCQNis7j1H QnjiGt7xLq4xqZXMeOZKV5//AIcUqse80vNljU6qhoBW8OU2VWSSOMHYMfhjC94N/wCz66s/ uz+5UvjEZElYd6o3+maoVVzOAnuqdLIx55yk+yK/eLeanQV6n1buucpTTpUHrxzt8seHXmBd i3mFOdxqfVkpUkAd5TpVZBzz9iPZ+GKHLL1CWogaoOpb5AIokvuxkePTPHXHiYS3Z0tS6Xqn eyaFeK6SZSf9GfV6C3MCaWlS/XIWfV//AJj5Q43bF1DdWVL1UmUk+DdHl0iKU2HqEhSSnVWb O05G6kS5B+WPU2FqAltSRqrOkqPJNJlzgeyBFiahJcS58Kk2pQIJSaPL7T80XZyytQnHyZfV B9to+rtVRpYnHjyMc+2La7AvpcopB1TqXfKJG4U2XA249gyD7cxz5rzYl82rQKd747xXcVBX PNtMNvuuF0PlDh3FCsjAAUM78+t4R2fIjEjLjGMNpGPmi/BBBBBBBBBBBBBHOXYmmHFWPX2V q+pNT4UkY6ZbGfxCPaNXdTtRWLgue1K7KUakU6acZp1MXKpdM13YG4OKIyMjx59YkYA5ht6R 3l7/ACwqZXVy6ZaZeCm5hlOdqHUKKVYzzg4yOuAQIWHabmHJW9tJ3mSA4irlSSRnB7xiOgCM jEc8WtUNSdTWK1dVu3S1QqczNOM0ulKkkuomA0MjvHDggKOAVetzu4AAENXSG8/f9YNOrymB LzDoU2+2k5SHEHCtvsPUeWccxDO1v9Zef/lUv/bEN6ZmWpOQdmZhYbYZbLji1dEpSMkn5hHN dAqOp1923VNQ6PdaaaxLPPLkKH6OlTTrTfVK1Z64yMkHJHVPg9NM7oReli0i4G2gyZ1rc42D kIcSooWB7NyVYhZ9or9nmkH/AEhb/Ksw84WVx3XV5LXm07al5hKaPPU+YemGS2CVrAWUnd1G Ng6eZhmwju2IM6RtjIGamwMnw9VcOuTGJRkeSEj8EXoISl/AK7TmmgSsqUmTnVKRj4g7pzCu nifxQ64II530kaSe1FqS6WFKUlkpD27hAK2iU48c7Qc+G0+cOjUAVk2XWhbGfdv0Rz0TBAPe Y4xnjPlnxxHPOi70i1XqA1VLvuujXgHlKn6ZWSvuKhncNiArABJIwSScg8E4IlLFKn9VtUbz lKzXqtTqHbzqJOVk6XN9yVuKCsuL4OSMZGR1wOQkg6Cq33dlu6W37TF1V9yt2tVWZVipuBK3 Hpdx0FG7OQVbQc5HQgecVXZryitzthy1pv1GTmpmpS6p9LkvsaWglIU1kn1hlXh9PSOmhxCb 7WqynRaogNqUFTMuCRjCB3gOT7OMceYia6QIdRpZaaZgEOe5kucHHTYMdPZiIB2kVVGbqVhU GQq89S5er1Qy8w7KOFCin1AOhGcbj7Iy7UXWbH1XlrMnazP12gVeScm5F6oOByZlnW/jpUvA 3JI5HHGRxwSYvZdJuLVtu4rkevet0NbdRck6ZLU9exlhDeMFxvPrk5HRQ6Zyc4Ei7S0/XpHS f0+2a2uWVITTaZyYYcLbjoBLZAKeh7wjI46H5C2qBMuTtDp82+QXX5Zt1eBgblJBOPpjPhZ9 pT6yF0/xTX5ZuNpod9aC0fuc1+KJxBCHlphxnthzbbedr1BDa8c+r6qvxpHlD4gghO6RfXn1 f/lUh+TdhxQRqbtmajJ2vVpmiS3pVVZlXVyrPXe6EnaMePOOPGIP2b63Urh0kpVRrU69Ozy3 H0qfeVlSgHVAZPjgcQzoIIRWhLaTrFrGs53JqDAHPHKn/D5hD1giO6iXAm1rGrlbKkhclKLc a3DILmMIBGRnKikQp+zxXbnkqki3b2qSqi5VqW1cFOfccUtaW3D67aioA5GQdvQc44h9QRDd ZnH29JrwVLNB1w0qZSUk4wktkKPzJJPzRouzP9ZG2v4Dv5ZcM+PFq2oUryGY5ys62KhqHZtb vifuWsS1fmJiYcpwlZ1TbMkGVENo2DCSMp5z1BHQ5Jbuj1zTF4aaUGuTw/yuaYIfITtCnELU 2pQA4AJQT88S9wFSFBKtqiODjODHqAoISFq3KAwVYxk+cKW8W0Odo3T4rSFFFPn1JJ8Dsxn6 CYbcEYlYqMtSKTO1KfWW5STYXMPLAztQhJUo48eAYTFu67zlTuK2ZSesuap1IuN9bVPn3J1K lOJScbu7COOSnI3cZyCfF5QQQguyk0247qDPsuB1ExW1pS4Ps0p3KB8ud8P2CE1qNrc5a101 Kh0W1J6vO0mWE1U3m3u6RLIKUqB+IrI2qBJOMe3nDKsi45a7rTplekW3GpeeaDqW3PjIOSCD 8hBGfGN3BHPnbODIsa31JCFT4rCO5BOCU905u+bIRn5ofkgVmRly6kJcLadyQcgHHIi/BBBB BBBBBBBBFqafblZZ2YeVtaaQVrOM4SBkxzl2Ixmz7k/lyPyYi5bTOo2lT9etihWmu4abNzTk zSp9DqW0tKXx9V8MDA4O3kHnBGG3pBaDtkWBTaNNuoenkb3ppxv4qnXFFSgPYMhOeM7c4GYW 3aVQly+9JELXsQqskFW3dj6ox4eMPw8DgZjnig0nUzTOTrVrWvQGq7S33XHaRUVTLbfou889 6lRGcZzjjJB6g4DT0ds5ViafUuhPOJcmmkl2ZWn4pdWdygPMAnAPjiId2t/rLz/8ql/7Yhwq QFsBChlKhgj2ERzfTLa1Ss+3qzYVtUKTm6PMvupka25NoQZdh08lSM7ioDPOOCeihgQ9NP7a Zs+zKRQJdYcRIsBtTgGO8WfWWrHhlRUfnhV9o7c3eWk0wW1qaauBvcUpzz3jRA+U4P0GHpC3 uKz6pPa4WpdMuGjS5CQmJeYJUApKiFbePHO/w6bTnwhkQlO1uvutLpV1Qyhqqyy1ccADf1h0 MEKZQU/FKQR8mIrghUXtSKrMa/6d1OVkphymS0vOomJltBKGiWlABZHAySnGephrwQRzppa+ kdq7URphS0MKk1KW2tWdy0rYG7p0G5WPlh8XNJz1Qt+oylInTIVB5hbcvNBIV3LhHqqwfIwm J7TzUi9JqhSN/wBWoKaXSplE4Z2nNKE2+tPhnACPHlISPHBwI3dcsG66LqBVLs04n6S0usNB E/IVNCy0XE4w4nZznr16FSuueMb4FFTGmNZt6erSnK3XJxNQqNTLO4LdCwohKcj1Rg49pJ46 CQ6iacKuiWs6WkJpqTYoFQYmcLRuK2mwBtGOAeB7IY8JftdvlrRmbQNv1acl0HJwfjbuPM+r 9GYn+lQaGmVqBhe9v3KlsHdu57pOeflzEU1ws247mmLUqVpKkfdGiT5mg3OKKULGAR0B8UgE e2LlgWbchvGYvPUGakXq4qW9ClJSn7vR5RnOVEbuSpR+XqeTwBGmrA1FtOp16n2BVaOzbtYm VTTa5tJ76nLWRvLaQMHgYGcjgcA5zu9XLGrlW0jZtO2G5Wbm3nGhNzEw4Gd2Fb1vYxypSxk+ PrE8mGHZ8vPydq0iVrCWE1FiUaamAwoqRvSkA7SfDiNvCz7Sn1kLp/imvyzcbzR5lDGlNoNt b9vuVLK9cYOS2knw6ZJiYQQv6c7Lq1oqaRaU8zNiltoNwqCu4eQFA9yn7HPrdRydpyMAQwII IT2kX15tX/5VIfk3IcMEYdamZiTo89MyMqqcm2WHHGZZJwXlhJKUA+ZIA+eFZ2XZGuUfTb3H uOjzVMfkppzuu/TtLqFnfnHsJI+iG/BBCK0JK/hj1iAA2e6DGT7dz+P74esEQvViyDqDbCKE 5UnafKrmW3phTTYWp1tJyUDPQ5wc+GOh6RFrb0PpVsXvQriodWqwNObWw7Lzj3fJeaLSkBKT wU4UrdjlPkBDaKlh1CAglJSSV54BGOPnyfoiuIXrS+7LaSXethkvLNLmGykZ4SpBSpXHkCT8 0aTsz/WStr+A7+WXDPgIB6xzTe+iN8oaqtNse6Q1bM7MuTnuY68pkha/jIKkj1kewnHAyM8w /LJoqbcs+i0ZCUJ9Bk2pdW3GFKSgBSuAMknJzjknMbqCFPd3/GLsH7nT/wDZhsQRrrlpLVet 2q0eYWttmoSrsotbeNyUuIKCRnjIBhFWlo1eUvXbONyV+mP0a1HluSKJdpXerCiFbTkDxQnq TgecdDQQQguyHLmUod4yx3ZZrbjfrDB4SByPmh+wQgtY9P7plqvd11WVMybrNao65OqyM1uK 1JS1tKmccFWxIAB8SfPid9n1l2X0ZtRD7am1mU37VDBwpalA/OCD88MKCEF2ymW1WBQHykF1 FbaQlXiEqadJHz7U/RD6Y/WG/wCCPxRXBBBBBBBBBBBBFifWw1JTC5zb6MltSndwyNgBzkeI xmOOOy/OX/JUqse8ilUmoST800h9U/MFsMLCVesACCRgjOAT0wOsPA1jWoE4tm0lY6ETjnP+ 1FZqutAWlIt6zyCeVCbdwOfHnPthS9oSY1CauSwHq23baJ1ueUqmimOOqBfC2v1wugYGdmMe 3MOhS9Y1JO1nT9J3A/r84cDxHxIr36v5z6LYGf5ROfoRhOta2qcUpt7T9CCeE7ps4Hy7IWHa IRqejTOZ9+D1pLpBmGe8FM7/AL7du9X46QMZ6+MMWlSut6JCTbdnLGAS0hKluekrd4AyVYTt KvPBxmMgsa4DpNafn5RND/4Y9XL63AjZOWCrp8ZM0PAZ+x88wntfk6lpnbMRc8zbSnF1IegN UzvSDMApwpwOJGQMgcZ6nPUQ4peW1rxh+fsMYA5S3Mqz8vAxHsrI60FCFTNYslC05BQiWmFp VnoSeDx7Pwxbcp+tb74zWrLlWUg4LMu+srOeMhQ448j+eFd2k6dqKzp2X7rq9DnaV6a1uZkZ Vba0KIVtO4+Hhz5wyKXRtZ1U2UK7ptlKu5RlKpJSiDtHBIHJ9sZXuJrIQc3bbAI5AFPVz7D/ AOPCA0XWTCSLstjOOQaerj5IsuUnWArDZvG1UOZBwJFW4jPTBHQ9Pni8i0tV3GHO+1Hp7TpU VpS3RUKA4+LkkcZ9hihqz9WFSu57UqSRM7Se7RRm1I3eA3Eg49u35oJa0NWVS6fSdSZBt7IJ DdGbWB58kjw56dYStiW3fDnaLuqRlbnakq4zLuuTlUMklxLzRU3gBrhIyVNnGRjaeuOXq1aW p6AM6lyiyDnCqA0c/wC3Fr3papgFoakyJbVlReNEb7xJ4wkDdjHXmM5Nt6lhoI9/9LJAxvNB Tk+39dx+CLXvW1O3vK+EWn4cIIHuCjCMftfqn48xWq2tTcDbqDTMgk49wU8+z9c6RbZt/VQF aXb3om1I9RQo2Ss4+yG8Ac56ZhT9pOjX+zpuH7nuCj1KmNTTK3GZaT7hYWQQCCSdwBJ9vOcR L9MqLqm5ZNt+iXVb8rSlSLKmkmn96622UApBwQFEDA6iJOihas/Z3nb44V0pJPOOB8boTjJ8 PbFs0jWH0VKBc9ql0qJUv3PcykeAHOCD8gPHWPDS9YylA98VogpzkiRd9f5efD2Yi8ujatLa dULstpt3Ce7QmlrKc9VAkqyMdBwcjyjGVR9ZVKJF02qn2CQXgfTFPuLrL9tdr/eC4g+ttL1P l9Lq67cVw2/N0lKG/SGZaUU24pPeIxtURwc4jcaXUfVeX0/tw0yu2umnmRacl2JmVcUpLSkZ QlSk4ycEdPEePjKFSGsanUn3ZstCE4JCZR/1/MHJ4HyHxipMhrEG0pNaswkAeuZN/Kvl9bH0 RV6HrB+6tkfekz+lB6HrD+6tk/ekz+lB6HrD+6tk/ekz+lFn0XWfYs+6Ni7gfVHczOCPMnw+ TB+WFfpvJ6muauaguU6ftpmoIWwmp96h1cspZSS33aRhXCQoZOOp6w025TWQg95U7HScnATL TKuPA9Rz7PwmK/Q9Yf3Vsn70mf0o8VJ6xbTiqWQVY4BlZkc/Luj30PWH91bJ+9Jn9KPUSmr4 WkqqlkqSCCR6JMjI8vjRddb1ceaAS/Y0qsKySlE07kfPjEWEy2sYl15qFjF4pBA7iZwlXlnP Twzj5oUekcrqO3q9qCae7brc8l9s1YTIeMupaistloJwo/ZcnHBhuPM6yOOuFubsRhCU4QA3 NL3q55OcbfDpmPESmsZQkrqljpXgbgJWZIB8cHcM/RFXoesP7q2T96TP6UHoesP7q2T96TP6 UHoesP7q2T96TP6UHoesP7q2T96TP6URbVOm6qTGm9ypqlTtFUgmQddmEy0u+h0toG9YSSSM lKSOR4+HWNH2f5PUz4LKUq35+2WaUtbqpdFQZeceCe8OclCgMbt2B5QxfQ9Yf3Vsn70mf0oP Q9Yf3Vsn70mf0oPQ9Yf3Vsn70mf0oPQ9Yf3Vsn70mf0oPQ9Yf3Vsn70mf0oPQ9Yf3Wsn70mf 0oVt3U/U13XWyxNT9tqq6JaYXJPMtOCXQgIUHe8Sr1iSDgYPiOnMNIyesGeKtZOP5JMfpQeh 6w/utZP3pM/pR6qU1gKiU1SyUgngeiTJx7PjR56HrD+6tk/ekz+lGM5L62g/U52wljjlSJpP y+Bj0y+teTidsIjwyia/NHqZfWoNKUqesMuhXqt93NbVD2qxkH2YPywm+z98Jrs3eZtpdvM5 qRM6mqB0JEySrcG9gPz5/wBWHMJXWfuiTUbFDufi9xMkY+X/AOkVuyusiG1Fmo2M6vGEhcvM oHy5BP4oq9D1h8atZP3pMfpRSiQ1hTndWrMXnzk3+PoVGMpjW/PqzOn5+X0r9GBLWt4Csv6f kkYHM3wfP4kJztKO6itUKgS98O24unOVAONikh3d3qUkDf3iRgbVKxj5/COuWP1hv+CPxRXB BBBBBBBBBBBGNU3VsU6aeaa75bbS1paxneQk4Tj2xzn2KHEtWVc7i8lKJ1Kjj2Nxl2fcOqd6 2tWb1pNdp0hTkrfVTqO7T0OB5CM8FwesDwQDk5UD0ENrSK7FXvp3Rq882huZmW1JfQg8BxCi hWB4AlOQPIiFl2omybh0wc2KITWgndsBSMra4KvA8cDxwfKHxNOoYlnXXM7G0FasdcAZMc2W u5qbqdRahfFHu5dFS286KXRWGAtp0NjhKySAcnjKkq5ycAYEOXR+7jfOn1KrrqUomnkFuZQn 4odQSlWPIEjIHkYh3a0Vt0XqXAO6Ylxznj6oOYcbf62n5BCi1nums0DUTS+QpE4pmUqdRdam 2eAl5OWUgKODwA4r58HqBDehG9pAbbm0tefCfQ0XE0HVLHq/HbIyfAYCvo9kO6YdDMu66QSE JKiB44GY5jtVq/tQLSrd/wArfE/S5lt2YXT6UwB6MEtchCgTg5xt5B6ZOc4h36RXcu+NPaRX X20NTMw2pL6EAhIcQopVtz4EjI5PWIL2vkNK0cfU66W1onWC2n/SKyRt+gqPzQ5ZL/ebH8Wn 8UXooe7zuXO42d7tOzf8XPhnHhHKVf08t+2LJqVW1cuF7371Euvy7kvOLWtKh8RKED4w3YJJ GBnAIxmHrodO1moaWW9NXJ3pqTkuSpbwIWtG47FKz4lO058esTuCOd9LCtjtWaiy7jjoLkoX g2CChQ3s4J9oCxj5VR0RHJD1Zqz973A3e1/Vmz7nanimkS6krFPU1lW0kYKSg8DcTjHJ3Z4c GulvT1QsKcrcjcdblJ6lSCn226bMhliYWkZK1pAyeM4woYEY2lFqVprSUTkrdtYfrtepjcy0 /Pvd+1JuLRuSW0EZHCkgkk/FyPKIJaGpF731d9v2UD7lVaizTjtwTjSkETCGFhJSB4bj6qgO CVA8JyI6aT0GISna/Q8rRx4tDKEzzBd4HCckf2inpDJ01+tzav3KlPyKYXOvE1XX7408t2iV +eorFYfmkzLsmras7Etkc+wKVx05jM09qFwW1qHVLHuasu11j0AVSmz76drxb3bFtrxnJB8S fb44ET09ldQdSaMb2F7zNFW9NK9ApjcuFSqWkLwQ4njfnkZIzxnJzgNHVSl3BV6FKMUG5Wbb l0vd5UqgTtWhhKSTsPgd2Oqk8Z58DDOz5cFWq1VuuSNcm7ktinvNN0+rTTe1xxZGXEZ6qAyO T4YPAIEOuFn2lPrIXT/FNflm4kWlG74MLQ34z7jyfTp+soiVRh1gzIpU4ZD/AH4GFljgH6pt O3rx1x1hNaIzOoMxcFK9+Qqvuf7gOKWZpG0GZM0Nu7x392D15x8sPGCCE7pF9efV/wDlUh+T dhxQRp7wm6rIWzUZq3pBFRqzTRVLSq17A6vyJyPacZGcYhX2/d18UXUO3bYviYt6ouVtp1fd 00qQ/JKQ2V5WDwUHBHtIJB4wXRBBCN0IJOr2smTn/OMv/amIeUEJHXK+Lho18WvbVv1ym28z U21uvVKdaStKMEgJ9cFIHHl1I5EbvRa96hc1QuWj1efp1WmKK+22iqU4bWZpC056ftgUkEjg +HTJacEQLXl5bGjt2qaVtUZFaCfYrCSPoJjW9mb6yNtfwHfyy4Z8eE4xxnJjlVjV27qlJXRU /fpa1I9y5p1EtTHpYF2ZS3yAnPOFZAB5OQfix0hZFYduG0KNWJiVVKPT0o3MLYV9gVJBIHs8 vZiN3BCZu6YfX2oLElmigNtUubcXkckKS4OD8qU+XjzDmghc6535Nad2xTazKsMzDTlTYlpl DgJPcELUvZgjC8IwCcgZ6Ru7B1Aty/JV962agJr0chLza0FtxvOcEpIBwcHB6cRK4II557ID kuqTvdMq4FtCq7kFwkvFBCtpX4c4+ndHQ0ERy9L1oFlSkvM3NUESTEwsttqUhStygMkYSCeg /FG0oFXkq/RpOq0t0uyM22HWXChSNyT0OFAERnwQhu2R9bmh/d1j8i/D2Y/WG/4I/FFcEEEE EEEEEEEEWpta25V5bIBcSglOQSM444HJ+bmOcOxO2HbLuZtedq51KT8hbEe0O0NU7CpVcsy1 KbIVCiTzzipKsOTSWlSiXE4JUkncSAB0BwckZh26a2o1ZNj0m32ni/6G2Qt0/ZuKUVrPyblK x7MQqe1D/wAP6Y/VGh/ntPqEeufXa5B8h4/Knyh8vtoeZcacTuQtJSpPmD1Ec+W7ZGpmnbNc tuym6TPUGeeW7Iz02/3bskVp2lShjKiAB4EZTnxIhu6YWmiyLGpVvoeD6pRv6o6BgLcUSpRA 8sk49kQTtalI0XqO5O4mZlwDnG094Ofx/TDhZUFstqTnBSCMjH4IXupViz903vYNZkpmWal6 BOuTEyh3duWlXdkbMDrlvHOPjZ8IYsIvtSPtpVp8wVgPLuBlaU46pTwT8xUn6YeTqEuNrQsZ SoFJHmDHPUjp5qZZshXLWsyao81bNTW4ZeZnXFJfkEuDCsAdTjyyMjOBkw5dP7Uk7JtGm0Cn rU4zJtkF1YwXFklSlEeGSTx4dIWfbCQlejyyorBRPsKG1OQT6w5PgOTz54HjDlpbzcxTZR5l QW0tlCkqHQgpBBjJgPQ8ZjjvT+4ZCWu+vXVqjalxVO53Zj/J0+5RcalUJGAAlRAChgAZHG0Y OSY6nsu42Lrt+Wq8nKT0pLTGShueZ7p3AOM7cng+B8Y3sEc26VpUntc6gBYIPoLx58u9lsR0 lCTvS19UrgpdctyZdtWo0ifcKWJ+ZQtt9hokn4iUlO8DGD4EZyfCcVOyTNaSOWW3OeuaYKem aUnA3BASFkeWRnEZDNCq1H0yl7foU4wKtJ0tuRlpt1JSjvENhAcIGcdM45+eFbTNCZ22Jy06 5bNWCrokpzvKxNTK1lE824rLvBzyASkdM5JJBwYfw6Qnu1l9ZOq/yiX/ACqYn2mv1ubV+5Up +RTEI1otW6qtdVkXBZ0vITUzQ331OMzbvdpIc7sZ+QBKs456YBjY2HaFfRdtTu6+naa7WpqW TIMS9PCu6lZcKKiApXJKicn5OvgIbb9kan2QmbtmzZ6h+9p6ZW/KT82FKekkKVko2fZH5iM5 ORmN72hrKuy9bOptMt1+VdDTwdnpdxwsmawOMHpjOTg48OeIk2l4uOXp7khXLXpVu0+UShEm xIzQdBHO7gDAHTnqSTE4hZ9pT6yF0/xTX5ZuJHpSQdLrPIII9x5Pp/EoiUwQQQQQntIh/uza vn/9VI/k3IcMERzUd2uMWLW3LTY7+uCWUJRHGdx43JzwVAEkDxIAhQdnqnv2+5LS1ZsWvy9y T/emoV+dQlaT8ZQHeFRUEkJSMY5VjOesdBQQQjdB/rvayfdKX/tTEPKCEZrras9Oah2hcqbX XdVIkW3WJunthKlZPKFFKuFDJzjGPV56iNrova0/S7ruium3G7WotURLplaVvQVgoTy4Uoyl Gc/F65zkeJb0EQfXCUXO6Q3c02pKVJpzz2T5ITvP4EmNR2Z/rI21/Ad/LLhnx4sEp4AJ9sc5 taAekaR1im1GSpYu96adnZWbZAyk7vUaLhGdpGRjoNwPUZjoCh+lCiyHuiyhid9Hb79pCtyU ObRuSD4gHPMZsEJW5f8AjW2h9xH/AP5sOqKErUXVoKFAAAhRxg5zwOc8Y/CIS/a0pdSq2msm zR6bM1F1qqMural21OKCQhwZ2pBJGSB88ZOlMhXa1qNVr5q1AftqSmaY1TmKc+oBxwpUCXFo wCNu3akkA4PSHFBBHOXYzT/mm8V85VUUjx8En5vHw58/COjYIUWv9kT17zdkS0pKGZkmKslU /ggbJc43qOfYCMeJIhtMtpaaS22hKG0DalKRgADoAPCK4IQ3bI+txQ/u6x+Rfh7MfrDf8Efi iuCCCCCCCCCCCCPFEJBJOAOSY457LdzXZRaHWJW2bLcuKXdmkrW8KgiUSyvZjaStJByAD4fi h2m/tS++S18EThUoEgi4ZfbxnqrZgdPOLovfU4gEaR9eebklh/8ADCh7Qdy3tOqs52tWGiiu S1US7KKNRanC+8NpS36gG0HHj1wPKHCxdmqHozz72mUoVBQSiXTcLKXD5qztKcfODx4xZXdO rXetpRp5SghYSVKNabIbJxkK8eMnoD08eM3pa4dWHg5vsihsFKykBysZ3AfZDak8H24Pshcd oqe1BntL55u4LbpElTEvMreflqgXlowsYwkpHU4HjE1tytatrtOl9xbNtuOqlGiiYcqCgFZS MFSAOuMZAV16GM4VHWV95tDVCs2TRt9dyYnHnE58/U5A9mD8sUvzutTaFFFMsR4hW0JbfmQV DjkZxx8vPHSFN2iJjUZEvabtyyNsAt1NC5N2mLcUe/xlKFhzHBxzjjjrDhQ7rMvP1DT1PsLs 4T+BMVbtZv8ARaef0s7+jBu1m/0Wnn9LO/owse0YvUz4LpwXQzaXuQZhnv1UtcwXk+v6v64A MbtoOMnnyzDAoitaPcSnhTdibxLt7vSXJvvSdozv2p27vPHGekZE2nWt1ADCtPWFA5KgqcVk eXKYsLl9cS02Ezmn4WM7jtmufL7GPHW9bNiEif0+Q4kYVkTXJJ4+x8oqEprap5rdP2EhsgBx SW5kkeZAxz9I+aPTJ62+kBIqdiFjdyvupndtz124xnHhn5/GPFyGtiWtrdYshxecbly76TjJ 54GM428Y8T5ZKVsWS1F/VGXQ3L1GiM3OmUW5OuvNrXKraJaISgYCsZLWOhAB69C9hIav4Ga3 Zuf5E/8ApQGQ1ex/w3Zv3i/+lAmQ1f2jdW7NBxziSfPP86D0DV793LO+8X/0op9zdX8JHvgt DjqfQHvW+X1vxRbZpOsLZyu5rUd9i5BwefkR5/ghddoiT1EY0qn1XPVrdmqWH2O9RJyrjbqv XGMFRI+Njw/+sn01peq7On9vJk65bHopkmlsiblnnHUtlIKEqUlQBwkgdPp6xJfQNXv3bs37 xf8A0opVIav7TtrdmlWOAZJ8f/FHvoGr37uWcf8A2F/9KKlSOrpQkCs2aCM5V6FMet/tx4ZD V7bj3bs3Oc59Bf8Ao+PGN6FrT3zqfdax+5Cctr9HmNyjxwU9AOvIJ6dPKD64yeqKNKKw5cVU tVymhtszjMlLupcI7xOAhSsg+tjqBxGy0pY1ZmdNKA9TqvaqZQyaBKIm5Z1TgaAw2FqSQM4A HAPzmN00nXRM+hpblhraCd5czMBBOcbOm7Pj0x7Yz2BrUgHvfg9dOByVzg+XomLu7Wb/AEWn n9LO/owbtZv9Fp5/Szv6MebtZ9uO708zjr3k7+jHoVrNnlrTzH8bO/owpdMjqcdXNQlUhdru T4eaFTEyp70Xf63dhopTv4G4c+XPMNV8a1OMlLXwetLJ+OFzhxz5FMZShq/sbUlVgleRvQRO AYxzg+w+zn2RUsauhgKQqwi9n9bKZwJx/Czn8EAGrp3Z94WMjH+/ORxnP4fl9kWN2s3+i08/ pZ39GK2l6xh1BdY0+U2CNwS9OAkeIB2nHy4MXJtzV5T5MnK2E0zgeq7Mzjis+PIbT+KE5pO9 qQvVTUg0Ri1hPmZbFTE2p4S4cCnAjuigFZyO86/PzDdSrWXJ3NaegY8HJ3r/ADY83azf6LTz +lnf0YN2s2c9zp5/Szv6MelWso+K1p787k7+jHm7Wb/Raef0s7+jBu1m/wBFp5/Szv6MR7UZ erI07uf3VYsf0E02Y9IMq7Nd6Gu6Vv2BScFW3OMnGYj2gQ1QRpXRxbybQXSSXTL+6bsx34T3 isg92CnGc48cQwt2s3+i08/pZ39GPEp1lcmGi4uwGWkn1wj0te4fOBjHyxlOo1aByy9Yixj4 qmptPOfPcfDMDQ1bLRLq7DQ7zhCUTah7PWyPxR6lvVkNkmZsZTh529xNgD2Z3/hxHi2NWFd5 tn7JRuIKT6LMnaPEfH5z/fCfvRvUdfaHtVLTttor/uev0dxhL3o3cfVN5dCsqz8bAST9jDWq TGsammvc6esTeCd5WzNIBHh4qjGaY1uS0sLmrAWtYwFYmh3ftHq8/PGS2jWRYAdXYDRAzvQJ te4+WCBge3PhGYhvVbquYsbPsYmz/wDHGK4nWNcovaqwGpjcNoHpikkZ5ySOPoMebtZv9Fp5 /Szv6MAVrNnlnTz+lnf0YRPZfRfiVXU5Z5txTRmG0zQqpeCS56+C33Yz55z5iHc8jW1b6Ftu aettpxubCpshXzlOYthjXAFZ9K0/O4nCSJrCBnPB28+I5jJaTrOnvVOHT5ZKhsRunAEjHnjP X2eMUJTrWJTu1K0+U9tI77dOAg+BxtxF4K1nwMtaeZ/jZ39GDdrN/otPP6Wd/RhN9plWoptu iC8m7aTR/dNvaaQp0q7/AGL27u8AONu/p5c+EdXsfrDf8EfiiuCCCCCCCCCCCCCObexF+xC4 /wCXI/JiJA7qde90XlXKdppb9HnKVRHCzMzVQdWDMOA8pbIUkJJIUBncOASRnEMLSu9mL8tV NUalHJGZaeXKzcm4rcqXfQfWQTgZ4KT08YX/AGnf1/Tr/pEx+OHgYQo1Iv8AvSt11zS6mUJ6 gUZ4sd9PlRVPOAHOzaoDB4I6eGTzgMzSq8278sqSraZcyr6ypqYlyc906g4UB7PEewxEO1U4 tvRWtBtBVucl0qwM4Hep5hlWu8qYtqkvrShKnJRlZSgYSCUA4A8BETu2+Zmian2bbIkmnJOt pmO9fKjvQpCcp2jpjPXPnx05n8I/tRfrNg/9I5f8Rh4Qv9VLznrSqNmy0hLyzya1WWac+Xgo lDazglGCMK56nI9kMAQn+1j9ZKr/AMfL/lUw2pL/AHmx/Fp/FF6LU2ymYlXmFqcQlxBQVNrK FAEYyFDkH2iOFdd6Halk1pVEt2r3POXA0425Nuzs0gssgpCkgbUJUpeFJOQcD2ngdu2zj3uU oJnTPj0RrE2VbjMDYPqmfHd1z7Y2UEc/WIU/qvr5BB3e5Awc8YzK54+iJ9rte1Q0/sB2uUiX lJicEw0ylM0lSmwFHkkJIJ6eYi3pc/es7Mrm7juO1qxSVtYR7kIK1Bz+GCE46+eeOkRbX2p6 iW4GKna9ySMpTpmdYkmZT0FCnQtwY5WsKBG4E9BwYm0vLX1R9OZxL1Rp9wXeyhbrDrkv3LTp yCGylBTk43AH1edufExBrW1on73uG26LatFAnFfVbg9MCwJBtJCVpQeMqznBPsGOTh5J+KIT /ay+snVf5RL/AJVMT7TT63Nq/cmU/IpiD6yXfdNHu2z7bs5dOl5qureSqZnm1LSjZsIAweOp zwT06Rdt7UOqUecuCh6iysozVaPTVVVM1Ibu5npVIO5aUq5SoEYI8SeAMRrdObg1QucUm5Ji Wt9Ns1J7mnpK0zDEsSQHQvopQxnHjnoM8bbXWr3BbVsuVujXRI0OUlm1BTb8iH3Jl7qhCCcg bsEfF45OfLN0Cu+fvfTaSrFZdYdqJddZeUyjYMpVxkdAcEHjzhiws+0p9ZC6f4pr8s3G00O+ tDaP3Oa/FE4iN3tddOsumiqVcT7kopwNESssp7YSCdyto4GB1JxHPUz2iptdgXRNNGcarD1R cbor/oKe5bYJTtSpRBSVpTuJByc48OnQmntzsXba0nVJZMyAod24X2FMkuJA3EJPhnPI4iSw QndIRjWbV/HH+VSH5N2HFBEev5NdNszKrWqNPptQQQ4ZmfQVNIbScrz5cDrg+PyhbaBah1u8 biumnVmqUqqS9MDPcTUgyWkulW7cQFYJSCAM4/AYdUEEI3Qj672sn3Sl/wC1MQ8oIXmr1/Td oJotLoFORUrlrr5l5CXdJDQIxuWsjwBUnjI4JORgxtbAnLxmEzrF9UulykwwpPczNNeUpmYS QScIVlSdvA5PJ/DLoIiurH1rLy+4s7+QXEa7M/1kba/gO/llwz4IUOouoNySupVNsi0maPKz c1KGaVP1krDaj6wCGwkjKvV9vJxgYJif2PNV+bt9pd3U+VkKwlam3W5Vze0vBwFpzyArrgkk Rv4ISV1Opb7V1mBQWS5Rn0janIBw8efIcdfkh2wRbmXm5aXcffcQ0y2krW44oJShI5JJPQAc 5iN2nf1r3dOTErblbk5+Yl073GmlHcE5xuAIGU5IGRkcjziUQQRzz2NSTbd15cyPdU4b/a+o Ofn/ALo6GgiK31qDbVityqrmqSJQzRIZQEKWtWOpwkE4GRz7Y39IqUnWKZLVGlzLU1JTKA40 80rKVpPiIy4IQ3bI+txQ/u6x+Rfh7MfrDf8ABH4orggggggggggggi3MOpYYcdXnY2kqVtGT gDPA8Y5x7EX7ELj/AJcj8mIwrWrtS0UvS8qfXLbq9RkqxOGbpkzIs7w+slW1HlyFDpyCPinM Mvs7WtVLes6dnrhYVLVeuTztSfliMFgLxtSR4HjOOo3YPIjR9p39e07/AOkTH44eEcx2PO1v RKdui1zalZrInJpc1RpqTZLiJkkBKUuEfF4CckZI546GGvoNaM/Z9gMy1aSlFWnH3J6bQg5D a3D8TjjIAGccZz1jQ9rNSkaLVPZ0VMS6VcZ47wf34hwtDDaAOgAhX3xaVWq+tVg1yVYBpdLb mlTT+5PqEpwlOCckqJA4z4nwhpQje1EFd3YHPq++JjjHXr/9YeULPWW1qxcdUsN+jSqZhul1 5idmyXUo7tlJBKvWIz06DJ9kMyE/2sfrJVf+Pl/yqYbUiQZNjH+jT+IReixUFzDchMrkWkPz aWlFlpatqVrAO1JPgCcDMc8TOu1Mq1t1W3Lxs6pi43ErlVUZDBcRMrPCQCfWTzg9CRwRniGr onbtRtXTGhUitH/L2GlF1G/d3ZUsqCM+wHHHHlE5gjnyxf8Ajg3x9yB+OViUdqOiVOvaUTMp RJCZn5pM0y6WJZsuOFIJBISOT1HTMV6R1ujtzvuNQ9OrktVp5HfuPTlLLDCnAMFJcycnHQnr z0jd6y2xUrqoFJlaOhpb8tV5WccDjmwd2hR3EHz56RIL5qFVpdqVKbt2nKqVXQ1iVlQR67ii EgnJHAzuIyOAeYRVlaa3rp9e9v3LLOGsTNacW3crSVoCGO9WFFYyRu2kk5HikjoqOkhyBCh7 VzS3NEqyUJ3Bt6XWr2DvkjP0kQx7OlUSNo0SUaKlNy8iw0kq6kJbSBn6IWmtrdXkb4sO5aVb c9X5SjKnDNMyaAtxHeJbSkpTySeCRgeHh1i3SLWrt9V+57huylroMtP0VyhU+UceC30MuZK3 V7eASSMA88dPE4WndV1JoNMoNnTFlJUuQeRKv1dyaT6MZRJ+OnHJVt4HjwMjJIEz1KrVepVR prcrZYue33gfSQyUqeZdHxD3auCn2+HPI4zqNCLTqtvN3LUapTGaG3WagZmXo7K0KTKNgYHK eASCOBwMDgdA14WfaU+shdP8U1+WbjeaOy/oulFoN5z/AJqll9c/GbSr++JhCi7RKrsp9l1S rW5XUyUizLBh6RTJJdcmFOuJbJDhOU8L8B+cJ9Wld5l+yNP3q8U0wtrrLwTIDZIOpJyCv/lD lZSMkcq6YxHVtvy0/J0eVYrE+KjUEJw9NBkMhxWeoQOAPD5o2EEJnSMu/Dfq4AW+57+S3A53 7u7XjHsxnPzQ5oIjmoFRrFJtiYnbeoya3ONKSVyJXtLrWfX28cqxnA8fb0Kv0+pk3W9T6fcd Isd6yqFISD0q8mYl0yrs8pWNqCynGEpI3BRB6fJh5wQQhNC31p1v1eYCAW1zja1K8ilboA+f cfoh9wQpdcaPVU1yy7wotPmKqq3Zxa5mQlU73nGXQkKUhP2RG3p7fIGN9pze1UvKoVWYctue o9vshCZOYqCS0/Mr53/U/BI6ZBPy5yBPIIiurH1rLy+4s7+QXEa7M/1kba/gO/llwz4IUmsv oL1UkJW5tOZ66KGthQRPU1rv5lh4lWWwhJC0pKUpO4KAyR4iM3s8Uqs0iwHGq5Lzkk27OuvU +RnHVOOykoQkNtKzykjB9Xwz4HgM6CEvcqFfqqrQXtVsNEmAFY4OO8z+MfTDogiIau0OfuTT S4qRR1qTPzUqpLISQC4QQe7yeBuAKef23hC40EqEs+qkUyV0+mqVOU2mGWqFXmpRLCkuhQ+p pURuWFEFR8QfDqYe0EEc59jNbppF4IUlzuRUkqSopwkqKTkA+fCcjwyPOOjII5+7VtsyNUlK JPPUGtzr6C4yqdpSA4phPBSlxBB3JJzjpjnnnBYuhqq8dMKMm6pBMhUUIKQyGUs4bBOwltIA QduOMD5BE8ghDdsj63FD+7rH5F+Hsx+sN/wR+KK4IIIIIIIIIIII19xkpt6pqSSFCVdII6j1 DHJXZYu2tUChV2XpNn1GvMLmEOrelHUp7tW3G07uvgeIdfwoXT6ShlOldyZI6942E5+Xp5+M X2tSbrddU2jS24ApOc75hlKevgonB+aFH2i7suCrs2kzP2TUqS41VEvMF99twPrGAGxszyc+ P4fBtP6gX0kr7nSqqLISNoXVZdIKucjjOB055zk8DHNhGoOpK23FjSJ8bMZBrzIJyccDZzGQ 3e2pagMaThI/1rjlx5/6nsha9oi573qOls5L1+wxQ6e6+zvmxWWpkpIUCEltCQTkjHsif0i8 dU1UyQU7pk0+Sw2VuKrrLSnDs5JSU+qScHB6cj2jJVd2qRZUBpbLd9621ZuFjaOuOMc+Geef ZFKbj1cKQTY1DT8bg1ccY6D5/D8OITXaOreoFRodARc9qytHbRUQuWdlp5Mwtb207U4SePH6 IdzNa1ZW0hS7StttZAKkKqi8pPkcJI/CYFVrVgLSn3pW2c+IqqsD/YzFBqur/eZTbVqBG74p qDmceWcdfbiFp2iJ/Ud/SybbuWi0CUpffM+kvSk2txzO8bdqTjA3Yz1iX2pVtaXLckHPcG1S 2uUb7n0iYeQ6PVGC4NxycdQMcxm+6Guf7j2N/Sv/AKcHp+uf7j2N/Sv/AKcUqnNcFKbcNGsN SwDg94/lOeozv/FFYn9ctp/zTYoI+x72Yyf9uKfT9dMEe5FjZ5571/8ATjCqyteZz0Qy7Foy BYd7xXcOOEPDBGxYWVerznjByBzCmtFOpz/aJr5k10GXuwSRM8JjJlO4w0ABsyrr3R45z18Y eLiNblPIWlenSUpzlH+WEK6ezPgennFz/dsz8XTj6Z380UhetpcUnu9OcAA7t07g9ePPj+8R V/u2E8p04Pzzv5oxn2tcC+hSXtPEITjLafS8K58cpz9BjJB1s8E6cY+Wd/NCy7RM5qjK6aza LqVaKaNNPNMPJpQmFOk7t6eXBgDKBz+eJraDmtL9pUVyXVYncrlGFoVOelh8o2JI7zaNu4jr jxzG3A1s5yNOCScjmd4/BHv+7Xz6unHPtnfzR5jWzIwnTgezM7+aPT8NhBynTj2etO8fgjBE nrqOlQsD+bM/oR6mV11Gcz9gHjHKZnj2/EiFa0MatN6WV/30zdmu0fY2Zj0EP9/t7xOAjckJ 67c58BGy0iOriNM7dFGFkKpplk+i+nqme/7sk7d/d+r08vDGecxLlDW49Facp6dDO/mjzbrd 3Ozdp1v247zM5nOOvTH4Ir/3bP2unH0zv5opUvWxJA2acHPkqd4ihL+tpaSssadpUerZXObh 8vh+GLjLutSlJLjWnQTnlO+czjPTODCj0+mtTU6waiLo8pbiqxvbM+zNuOBjgkN90UkE+r4q xx1weIcE3NaxF5LcrIWG2kZUp1yZmloIyMAAJSQeTzjHHh40KqGsSH5jNGsp1tKk90ETj4Kk /Zckc/OE48jGRKzurb7LqXaNZku9zsLk9MEDyyEoOfpGfZA7UdWGHQkW/aUyNgytmovJG7x+ MgH5sfPFCqvq0cbbWtgc85qbh4/mRV7sasfarbP9aL/QgFY1Xzzats4+6i/0ISWlM1qG1rDq A/RqLR5ipLdIqSHn1JYYWVqKQhY5OcK+XB6Q7RV9VsDNs2uCc8e6jnh/1PGKvdXVXuA5727V KyrHde6ju4Dz/W8Y+fMUe6+q+c+9W2f60X+hFiZn9V31yzgtu2kll0qUgVV31xsUMHCMdSDz np08Yvs1XVkvFLltWqhtRASo1J31B4lWEHPnwPpiiem9Yg4tUpTrF7tISoIVNTK1K65SDtSM 9OSMfLEV1JmtYBp9ciqlJWUaaZB9E0mUcmC+GS2Q4tG4hPA3EZ59hjTaBuapnSukotxi0U0p Jc9GXVVzHfKT3iichsEYyTjpwIYIXrUAUqRpyVH4pC53A+UY5jIlHdX2gsz0rYL4OAnuZmca wfEnKFZ/BFKF6x925vY0+U4c7FJenAE+WRs5+kRYHw2DonTj6Z380GdbP2unH0zv5oM62ftd OPpnfzQp7wmNTjr/AGUxNe9c3EiUdXJplVP+h92oOBzvd3rg7Unp5JxzDaSdasKyjTk8cYXO 8H6OfGB6Y1mZQkiTsF8kAbW35sHPifWAGPDEX5ad1YXLOKmKVZSHVFRQkz0wClP2IIDZBPtB APsj12d1ZU68yxR7Mb9T6nMOT8wtvd7QGwo/JgdDzGMt3WgtKW2xp7u6hHezhOMfF6Yz7c4i mVf1pUt9D8pp+naMNr76bAUf22ACSOvBwYuOr1o3Zba07CcD1S5Okk+POBCL7MStQQxc4s1u 3O4My36Qqrre2h3CuGw1z0PJI8BzDxzrZ+104+md/NFpT2twfDfo+nhTtz3oXN7c+Xnn5sRc SvWxSQdunA45BVO5EWUTOt6l7TJ6fIGzfuUuaxn9rwc5/B7YsGf1zyf80WMfb3r/AOnB7oa5 /uPY39K/+nCo7RszqS/alHTfMjbstSxVWyhVMW4pZe7tzaFb1Hjbv6eyOtWP1hv+CPxRXBBB BBBBBBBBBGuuT9jtV/krv9gwjuxYhI02qqwkBSqmsE45OG0fnipGqmoFzTden9P7ZpczbVGe WypydWsvTZRyoN7VAZ24OMHqOpOIbGmt4yV92fIV6nNrZbfCkuMufGacScKTnxGeh8QR06Qt +05+v6df9I2Pxw8IhGpV4zVqTlpsS0i3MorNZYpjrjiyA0lw43ADqfLw4ibgQnu1i2HNFaoT uGx+XUMY/wBIBzz7Yapm0ytI9MnXEpbaY715YSQAAnKjg8+fHWEBTr81WuO25u+qFJUVq3GF LWzSXUKU/MsoJ3q3DncMHoRnnjpl4WTcUtdtp0uvSba2mJ5gOhtfJQehST44IIz44hVdqH9Z sHH2xy/98OiozbdPp81OPhRal2lPLCRk7Ugk49vEc4SN86rV21Z3UalvUxi2ZRxbjdEVLhS5 mXbOFq37SoEYVyFDlKuMYBfdj3FK3baVLrtPQtuXnmQ6EL6oOSFJPnggjPshd9rH6yVX/j5f 8qmG1JHMmx/Fp/FF6KXXEMtLcdWlDaElSlKOAkDqSfARyxrDqfddyylXqWnM09I2jbq2/Sao 2ooM48paUhKDj1kgqHHQjk8FIjpGzp96q2jQ6hNlBmZuRYmHSkYBWttKlYHgMmNxBCGsGVC+ 1df833iQWqa013firf3Bz82z8Ihjaw3NN2dp1Wa9Tm23JyUbSWg6hS0blLSnKgMcDOesQHRq 4bsvb3NqczflDmGkpD0/RpSSR3zaSDhKlZ3JOcZOPDEDVd1A1Buq5BZFbkaBQqHNGQbU/KJm FTr6Pj7iQdqfaOQCOCcxlUGu3vqRYgdt6sSlsXLS59+QqiVSaX2nHWwOE7921PrJOcE5yPDn W9nGqX9ecm1c9yXaiZpHeOse5yZBlKnFJGAorSlJTgnPHXAh8wlO19MljRx9sYxMTrDRyPIl XH82G5QOaDTc/wDNm/7IhUauXDd3wmWpaFnVpiiGpsPPuzTkqh8nbk4wtJ8Enpjk8mNzZF3V mRq1wWxfbkvMVOjyoqCKjLICEzkqc+uWx8VaSMEDj8Zitj1jVC/GJW76RVqRTaC/NYZor8sF 95LpcKVFbu3duxkjBAJHh4zjV3UOWsKgtKbZM7XZ5fcUyQSCpUw7wOQOdoKhnzyB1MRvQe6b wqdXue39QnZddZpK5dzDaEJUhLqNwQdg2kAY568nJMOOFn2lPrI3T/FNflm4kelJzphZ/HHu PJ/kERKYIRdu6+ytw6wsWlI00Ipbjz0umfccO91aEkghGPVSSkgZJJyDxyIekEBHEJbSlcud etWAlpSXt8nhRVnjuzu9nJwfZ0h04giD6sagyWn9BRMusmcqk2vuKfINn15h09PbtBIyfaB1 IiN6D3LeFSn7ooWoLss7WaS6woloNgpS83vCDsASccc+ZIyYbkEEInQArOrOsZdBC/dJjOQB 9nMeRMPaAwkr6rV61PWmVsy1bllKDKik+6CnfRGpla1bynaoLBweAQBjg55iWaU3RWavMV+h 3a1KouGgzCJd92VJDcw2tAU26En4uU8kfi6BgwRAdfCBo3dmSof5Eoer16j8Eavsxtpb0Stz YMbkvKPOeS8uGlBHP+u0le9uqbrFEv6cabqdUZkpenGXQhDIcyAAvxwR5dIctm0mo0SgMSNZ rT9cnW1KKp15pLalgkkDaM9Bx1MbuCE7eTQPaX0/cewpHudO9yPFKwhWT7fVPt+QQ4oIxarU JSk02aqFReRLycq0p551fRCEjJP0CEZStdU3Pqxa1EtyTmG6JPpeEwucl+7W6dqihbZyeAUe XOSPkfsEEc79jVKPcC7VBKe8NUwVA8kBPAx85+mOiIIWXaEvmoWBYKqpRmAuoPTCJdpxbe9t nOSVKHyJIHtIib2nVk162KVV0MuMJnpVuZDTgIKN6QcfhjbQQhu2R9bih/d1j8i/D2Y/WG/4 I/FFcEEEEEEEEEEEEa65P2O1T+Su/wBgwj+xaM6ZVQf+k1/k241Nj1+4tHhcNqT9o1ushycd mqTN0+XLrT5WEhKVEAYGQCSMkEkY6Qzuz/Z8/ZmncvJ1gbanNvuT0y1uyGlrwAgfIlKcjzJi Mdp39f06/wCkTH44eELTWug1auOWQqjSK5wyFxSs5MBLgR3bSCSpRPUAeYyYZcKPtUsB7RSu EhP1NcusE+x5P54aE3LsVWjvSy1b5abYLalIV1QtOMg/IY51oLt/WTZ9Q04lrOnqpNZfYptZ Z4lO6cJ9dxRGEkZJwT7PDl5ab24q0bFotBceDzsjLpbccT0Uvqoj2ZJx7IUfbGKm7Ptp9t1T brVZbKCnIIPdrOQR0IxD2qsmio0ycknVKS3MsrZUpPUBSSCR9Mc0UWT1LtexanpczaC6imZR My0jWG3kplkMOlW9SyRgH11EBRCucYOIfum9sizrFotADvfLkpcIcczwpwkqWR7NxVj2YiB9 rH6yVX/j5f8AKphk2ehxu0qIh/PfJkWAvJyd3dpzzG3iPag287ddmVahsTZk3J5gsiY27tmS M8AjI4x18Y5r1K0yu7T/AERqki3d8vO24y826/IJkEtKXudSP1zJPxyg49nzF+6KUapULTG3 5GtTapmbRLJV6zewsoUNyWiOvqg4yeeInEEc/wBi4Ha9vnIVuNIBHljMt/8ASGVrVQp65dLb ipVJbDs8/LZab8VqSpK9o9p24HtIiAaPKmbYlqJTWtKqjTJ55tmVqVUT3ISdowXVKzuI3esR 7TjJABJOnXxpndF0+9i2U3JQa7NmelA1OJaMrMLB3BwL52nA56YSnkE4E30XtKo2lak0K862 7XKrPPVSeDZylDzuMoB8cBI555z1EUaEWZO2JpxJUaqlo1AOuvP90vegFSjgA4H2IT8+YYMI vtkfWia+6bP9lyHLb/8AwDTf5M1/ZEKXV2kXRK6rWfd9u2+uuytOYel32Gn0NrBXkD4x6YVn OCODnHEbiybTrVVuO5LqvmTZkJurSiaZL0xp5LxlZUA5CnE8KUoknjp+ARrTqnanWHSmrPlb dp1Rp0vO4lq25OoQ0mWUvcorZB7wq5VjHQnxAyZxqTpZQr+nafPVJ6fk6jIDDE1JP92tI3Z8 Qeh5BGDzEa0a0nnLDva66tOT7s4xOlLUmt14uOuN53KU6ccqzgfT5w44VvacS+rRG4/R1pRh LJcz4o75GQOPkiTaRuh7Sy0FJStIFJlU4WMHhpIz+CJZBHF1NtCuyPavZYlKcingVVU+gtJU WBK5K1KBOcbkZGOAFKwMcY7RHtgghL6SNNnXLVt4q+rJek0BOfsShZJx8oEOiCIFqhpdQ9Rl 05dbcnmXqeVlh2VdCCN2Mg5B8UpPnxEU0k0jnLI1JuiuTFRmZ2Tmm0sybkw/3jz4WQtxb3HK goYB8eTDogghHaHkJ1l1iR3ZbJnpZW0k5PL/AD8+c/PDxghI3hQbso+uzV5W7a6bhknaUJRx PpjMuplzKs4Kz5BPOOiiIlWktq1ekzFwXFdQZRX7gmRMPS7K96ZVtI2ts7uiiB1I4+XGYYkE QbXOZVK6P3c4lCFk091vChkYWNpPyjdke2NT2Z/rI21/Ad/LLhnwRB9VbKfvaWt1iXnG5VNN rDFRdK0lW9DYVlIx4+t48ROIIISd+hH6p7TTLyiv0Od+pcEJ+pO4OPDPPP8AqiHZBEX1QoM1 dGntfotPU2mbnJVTbJcOElfUAnwyRjPhmE9YFr3+7fdgTNbtaVotMtiQdkXH0zrbofBbKMhC VEgng+XU56COiYII5p7FylFq90knaJxkgeAP1TP4hHS0ELzXu1Kneums/RaGhlc866ytCXXN gIS4CefkidUyVEjTZSUSQUy7SGgQnaDtSBwPDp0jJghDdsj63FD+7rH5F+Hsx+sN/wAEfiiu CCCCCCCCCCCCMC4FJRQakpaA4lMs4SgkgKGw8HHP0Ry12XNQpe27LqNNVbdx1JwTheU/TJP0 lv1kJASrkbVeqYcKdYmd4SLDv4I/b+5AwPm35/BFxesEugJ2WRfi8qAOKMRtHnyr/wCsKTtC aioq5s1xi2bklBJVdE2fdCSMuHijH1NBJOVHMN6W1VmJnf3Onl9+qcevT2kfjdEUzGq0wwyl x7Tu+ghR2jEg0Tn5A7mLq9UJttaEK07vnKlbE4kmSM4z173p7YXnaDvqeq2lNWklWVc9PadU 0FzU+y0200A4DklK1HkgDp49YltpalVJNn0RI09u9xYk2BuZYaLahsTylRcBIxyMpHzRsH9S q1kiU00u5zofqyGW8nnP2Z9mPPJ6Y5tzGplypXtldL7mcSE7lF1bSDnyGCc+Ht68cQo+0rd1 frdk0xiqWNUaKymptupmZp5DgUsIWAgBPIJyeePimG0NRrySwhbmllaOUBR2zjOef9XOfm6w HUe70LCPgrrmSnfxOMkY+Xpn2dYrRqFejrYU1pXWOU7gHKgwj6c9IXPaDu266tpVUJOq6fz9 IlnFsl6cXONPoZw4k8hHOCQBnjr80TG1tRrwVbFOKdMay+GZRoLdTNNNhzCB6yEq5IOMgdek ZLWo+oL6VKY0jqHBOO9q7TeRn2o8ouK1A1HGNmkcyeOd1dZGD7PUPEWJq+NQ5uXWxNaOKfYW MKbcrbCkq+UFvBi78IOpP70T39fM/wCHFZv7UkNBz4JXOVbdvu8zn6O76RR8IOpP70T39fM/ 4cKmh3Peo7SlXqDFjg1l+lhl+lKqCE90xhohwv429Uo8PHHWHP77dSf3sJf/ALSM/wCHFPvu 1JKik6XMYxnPvjZx8n63Hjl3alBKdul8vjcAf/xGyeP6OLS701LaUhCtK0OKUcFSLhZ29Ovx OBFl2/tSW3VI+CRxW043Jr7JB+Q93F9i9dSXWC78FaG+vquXCyFHHs7uFT2iLwvKq6aPylw6 fGhyDk0zmccqbcztUCSAEpSCCcYz83jDAtS+dSFWzQynTITSHJVoCZ93Gmg4O7T9UKNh2A9c eHSNnM3xqQy5s+CkO+pvy3cDKh8me76xcTempJmA0NK0jLfeb1XCztHsz3fX2RS9e2pLTJcO lSVYUU7UXCyVHnGcd30i8i79SVISr4LmBkZwbjZyP/4cWpq69UVt4lNNZJpz9s7X2ljp5BKf HHjFaLs1PCfX0zlCrI5FwtAY4z9h8v8A9YX+vl0X3MaW1iXrVjy1Ipj5abemhV25pSB3gPCE pBOSEj2c/Nk6OXdqIxprQUSGnrFTprbCWJWYTVkSqnEJJTvUhYUccdePPoRE1F6alFG74K0D lQwbiZzxn/zfjjj5RFCr31KS42j4KAd4JyLhZwn5T3fECL01LC1tnSpGUgHd74WQk5PQepyR 4xYOoGpIJHwRvHBxxXmf8OLzV86krYU58FCklOSUquBkE4x0GzmLknfV/PPpS9pXONIKRlXu zLnCsgYwQOOc5z80KjTm5bultbr9mJSxXJuemlMidk01JpJk8DCT3hG1eevGIaab+v4uoCtK J8NnO5QrEvkcnGBjnjGeRj29TfXfl7pcwNLamQCQSKpLfg55g9/t7fvWVX+s5b88Hv8Ab1/e tqv9Zy354pRft77fX0sqgV7KpLH++Kvf7e371lV/rOW/PB7/AG9f3rar/Wct+eE7pddl1M6y 6gz8tZ87UZqZWkTUiJ1tDkptUQgFSvVUMZHHlDi9/t7fvWVX+s5b88Hv9vb96yq/1nLfng9/ l65z8FlUz905b88VN39eBUpLul9ZSdhKNtQllAq8idwwPbz8kUC/71JIGllW486lLj++Pff7 e371lV/rOW/PET1ZvO657TS5JaoabVGUlXZJaHJhyeZdSyD9mUoO47evsxk8ZjT6AXjd9P0t pUnJWBPVaSZU6lidZnGWUup7xR+KvB4JIzznEMT3+3t+9ZVf6zlvzx4q/b2xxpbVc+H+c5b8 8Cb9vfaN2llUBxyBU5Y/3wKv298p26WVQ885qksMD6YpRfl9Kd2nSuopQVYCvdaX6Y6ny58P /tFfv+vX96yq/wBZy354VN/3Zdg13sOemLGmWJuWafRLSHpjbi5rehSXCFpykbUnPPkc8Q1h ft7Y+tbVf6zlvzxSu/b3xlGllUKvI1SWA/HFXv8Ab1/etqv9Zy354Bfl6g/Wsqn9Zy354Pf7 e371lV/rOW/PB7/b2/esqv8AWct+eD3+XsogDS2qZ8M1SWA+c5hG9l+6a/SGLol6NZ81XErm m3nVS8y00WVHcNpK8bs4PTpg+cPFV+3vlONLKoRnnNUlhgfTz4R77/b2/esqv9Zy3548Vf8A eqeullW8uKlLn++BV/XqEknS2rYAycVKWJ+jMUs6gXs40hfwV1YbhnBqUuCPpIP0iB7UC9kI 3fBXVjgjgVKXPj7CYTnaTuy6K3a1Fkq9Y81QJNNTae9KenUPpU6EOANjaP2qick+BGI6xY/W G/4I/FFcEEEEEEEEEEEEWpruvRnfSA2Wdh395jZtxzuzxjEc8diacl3LIrsmgYmWZ8OOcdUq QAk5/wCqqN/O6tXRWLsrdP08tJqt06hqLc3MuzXd98sZyhvwzkHHUnHhkQxNNL0kb9tOWrdO bUzvUpp+XWcrl3U/GQr6QR5gg4GYXHadP1bTv/pGx+OHhEKuK9zRtS7WtUyPeorbUwv0gOYL RbTuHq45BwfGJqOkKrtQ/WRuH/1H5ZET20Di0KGT/wAxYyf/AFaYT8nqTqBd3u5WrBo1Fdti lvrZQidU56TPFvBX3e07RkHjPmOphrae3VLXtZ1NuCSaWy1OIUS0vktqSooUnPjhSSM+MKzt ifW0pP3bY/Juw9YhN63m5bl7WbRzLNOS1dmHpdx1SiFNlKQUbR0OVHBibDkdMQsO0z9ZG5f4 DX5ZETSxv2E2/wDc+X/JpjdxanH0yso++sFSWkKWQOpAGY44sy/a/ebj8zW9X27Ynn5koZkT KYbSnAwd3CEjnAyc8Ekx2HTUOtU6VamZozj6GkJcmClKS8oAZXtTwMnnA45jJghGW5/xvrp/ 6PI/tS0T/WK6pyytPKrX6bKompuVSkNocBKElSwncrHJAznGR8ojVab1S9K77nVKrVa0pqlP MJdeZpjTpdQVt7kjcVkDkjOR0zEeqmsb1D19VZVWYk0UV4MtszXKXG3VthQ3EnBSVHb0GMgx s6vq4il03UWYmqelLlrPIYZT3mRMqcGG88DHrdcZ4iOq1A1BtGlUW576k6K9btUfbQ9LySVo maelwZQSSdqgAOQecnGYfCSFJCkkEHkEeMJHth5+B84Xt/zgxkZxu4Vx7fP5oblrLU7bFIcc ZUwtcmypTSiCUEoGUkjjI6cQqdZdW5nTi/7aknpdl2gzrSnJ47SXUDft3IIP2PXGDnkeRiay F5ie1NftlhllyTTSGqqzONObg4FuFOPLGMEEQu7h1wmKRq3M0kSDD1nyDzEhUKiAQqWmHc4U pedoSCkggj7FXPhEn1V1Sl9PbktWXqDTaqPVu/M1NZJUylARtUkDOeV/RGZpLeVWv01Suehy 8paqne5pQVkzLuwkLcc5wAT0HXr5ZLFhWdp6XL+iVxYKR3YZc5B8HkdMfLEj0dl/RdKbQa3b /wDNUsvOMfGbSrHzZxEwhf663RWLP03qNWt2VU/PtlKA4EBYlkk8uqSQcgfRyCeAYSNta73N K2ZWXKk4K3POBpij1ASJYS9NuBO9naEhKu73Z4AzgD7IR05bXukLepnu8po1Yy7fpXdjCe92 jdgeWcxsoDCU0nZX8PerLoSlTYXJpKwehKFED8B8PD6XXBCq7R981awrEYqNALCZ16cRL73U BYQkpUo4SeM+qB88XtELoXXZSpy1QvBu4qnLuJUtCqb6A7LpI6FsgFSc9FYhnwQQgtD2SNdt W3VKCSmaQnYeFEKW4cgeXH4RD9ghZ9oS86pYmnrtWoSEmeVMNy6XVt70tBRJKiOnhgZ8TFzS p+5qk45Uare1AuOl7C0EUqXThDvqnlxKuCAT6pHiDxDIgiK6sfWsvL7izv5BcRrsz/WStr+A 7+WXDPgiC6eXlNXJT7smJyVYaXRqvNU9sNKOHENJSoKOehO7mPdFrwm7709kK9UZZiWmX1uo WhhWUHYspyASSnOOh58ehETmCEtqAvPaX0wRhWRLTxzjjllzx+b8UOmCLcw83LsOPPLQ202k rWtZwlKRyST4ACIDZWsFn3nX36NQqgtc+3uLaHWi2JhKeqmyeviccHAJxgQwoII5w7GS2TTb ySkfVxUEFZx9iQrbz8oVHR8ER43jRU3PO2+ucCanJSYnn2yk7UM+ZVjGRwceREZFn3JTruty TrdGcWuRmgS2Vp2qGFFJBHgcgxuYIQ3bI+txQ/u6x+Rfh7MfrDf8EfiiuCCCCCCCCCCCCNdc n7Har/JXf7Bjn7sRfsQuP+XI/JiMa0brmNGbjvajXHQalMifnl1KmTElLbxNbs4QV+XxMdcE rzjxZPZ0tyq2/YT7tfl/RajV6g9VHJYo2FjvAkBJTjg4RnHhnEaHtO/r+nX/AEiY/HDwhT31 R6jN696c1GWk3nZCSYnjMTCU+o1logBR8CSoYHU/MYbEK3tOr7vRK4yEoUVJZT6wzj6sjke2 JtZpTMWTQVJyUOU9gg4wcFpMc+WdWLi0dp1xWUqzKzV3FTLj1JnJJkuNPhwBKd5A44APGTnI IHWHFobacxZmmdJpVQCU1EhcxNAHO1xxRUU+WUghPHHqxB+2J9bSk/dtj8m7D1hU6sW7VK1q TpnN06VddlafPuvzToH1NlACFAqPgTtIHmeIawhYdpn6yNy/wGvyyImljfsJt/7ny/5NMbuM ap7Pc2b72XMy33K9zCRkuDacpGfPpHN8lWtDp7SysJbptOpDwZdQ5JzTSTUG3iMDuyolSjnG CDgeOMEBr6AsVNjSG2UVoOCaEt6oc+MGiolsH/qbfmxDCghAUtqZc7ZFZVLrKW26KlT4BxuR saAH84oPzQw9dqVPVzSW46dSZZyannmElthsZUva4lRAHicA8dT4RDNFalTKIJCkU/TW6qBP TrTaJ2cep5Et3iEHKluKXnbnODgcq6ReuDSh27L51Ama1KyyaZV6fKsSE0SlTqHkIHrJ6lIC kjPTIx15xDLG0mu6r6aagyF3ksVytzDbku5MuBaluMkqClEE4So+rnwGTjpGouyY1SvBFu2T cdnO02jmYlGJubZZU8CUKCVOF1OUJTwTgfSRHWLSUoaQhsYQkAJHkIR/bFRu0hSdyRsqLBwf H1Vjj6YbdnlZtKiF1wuOGRYKlkY3Hu05OPbELuyyZqvaxW/WpiVaeoUpS5qWmd7gG5TgKQjb 1OQs+zjr0BhGjOm12WXf90PzSu/p0tIKkaLMTTwUl1suFbaTgkpCccjHGeI0jmg18u2hcbc1 d0i9Uq7ian5T0IL9IeQorQj0gkFI3eSQAfDETK5tKaheKNME3N6O+3RZdSKw33pHektt+qnA 5ytvB5HBMbnSS0a9YVwV+gpQ29ZCl+mUt5ToLrKln1mSOuB1yePHOSQGlCs7T/pHwI3F6MAe Ge8zj4nfIz1+aJVpTn4L7PyMf5nk/HP/ACKIlMBGcdYRt2WbdF26l1irGW9Ckrep627bC1p2 Ozy0bkv45GEq8/FKPIiNP2bKPe8lcc09X03HK0pMkW5pqsOlYfnS6TvZSrkJ2nlQzk55ORjo qA9OIS+l6HZbtBarS61+osSTxSk8es1uHz4V+OHRBER1LnLhp1El5y1aJK1yZYmm1vSTy9ql NDqWyeAsHBB8OeD0iG6e025Lg1Qm76uC3kW2z7l+5jUm48HX3yVpWXFEAYAxjBGYcEEEIbRN Ur8OuraGkLLpmWilavABTm8dfFRGPYPCHzBCw7RtuVS6dMpmQockqfnETLD4lkrCS4lKvWHJ GeD0zmK9Jai62TR5fTmctKUZa7x1xQbSyp3CeEkcuE5PreznEMyCIrqx9ay8vuLO/kFxGuzP 9ZG2v4Dv5ZcM+CEKJC/7BrV4U+3rXTcdIr847PSk0Jxtn0d51OFBxJ5IGB5A4688MrSK03bH 06o1vzLyH5mVbWXnGx6pWtanFAeYBUQD4gDpEwghMag/8ZPS/wDk8/8AkVw54I016Ut2uWdX aTLuJben5B+VbWrolTjakgn5zHNXZ+0yq1HvalzNdtKpy8zTC/38/NTqUsJUQQ33LYHr9eTu KeSfCOrh0ggjmjsWjDd8fytj/wCbHS8EIbV63bxktSffPaFBbrLc/Q3KM62HktllaiSFnJGR yn2cEHHETrQi2qlaOl1Ho9bZSxUWu8U60l0ObCpxSgMgkZwR0JET+COc+2goi3rUSCdpqRJH /Ujolj9Yb/gj8UVwQQQQQQQQQQQRrrk/Y7Vf5I7/AGDHKvZX1Et+0rZqlOqTFTXUJicDo9Fl HJgLSUpSkeoDg5z8uRDub1ptlYdLUjcam2iUuLTR3yltQx6qvV4PMXvhfoW5ITSbpKSM7hRJ jA/2cwnu0ZqRTqmiznZGl1tJkKqmdV6XIuSyVhGPUSVgZUc+GcQ1mdaaUtxoLti82kL6rXRn MI+XGT5dM9YG9Y5J5KlM2bfDiAQkqTRlYJ/nRc+F5rakix789Yer/mcjPGf20L/XrUZmuaVV mQVad3SPf90kPzsh3LLau8BG5eT5dPGJNZGreLNt9Ltl3nMOCQZC3ZWlFbKyG0jcg7+UE8g+ WI2jur7iVKDent9rSOivc1Kc/SviBWrzzZ+t1fW0jKSKcjnw5G/jpCm7SV/vXHYklKrs+5KU lupNPekVSWDTeQhwBKSFHKjk8eQMN1zVl9EpLvfB9ey+8SCoIkEKCSUgjB38j2xcTqhPqYEw dOL1DeM59Fa3Y6/F7zMWBq1OEtAacXx9U+L/AJCj8Pr8fPEB161FnavpZVpBdj3RTm5kttqm p6XQhpoBaVZUUqUfIDgDnrxEs0+1Mqbtj2+UWBdMwn0JpAel2mu6c2oCdySpwHacZGQMg+Mb pOpNbVNbU6a3b6OE8rUlkK3Z6BPeYIx45+bxgTqfUVsh1OnN6bSvZzLMg5zjp3mcZ8ekaOYq FMdrDlYf0YrblSV6yplUhKKcUfP9c5Pt6xvWNTak+F93pzeY2K2nfLso5xnjLoz80WZvUm4U J/yTTO6XXCrgOqZQNuOpIUrB9n4YxvhMu/bn4Kq/uz09KaxiFDTb0uVrtMVCqS9mT/ujNU4S z1ILyA6GwhBC95G0DKEH5DDqdvq9d4DOltUXhIKiuqSycK8QOTke38Aj338Xp9VK9L6rtGSj FUlTu+UbuPmzF9q+7gVbDtRVp9XU1FEyGE04Ot7lIKd3e7s42gjB4zkj5tejUS9FIKkaU1cJ wVetPsJPHsPOfZF1N+XwpO4aVVHafOqywP0RQvUO9kJSVaVVbClbRtqLBOfbjoPb0hX9ou97 gq2mcxI1WxalRZV+ZZBm5qYbWlKgd2AE88kYB8omtmai3oLKobnwa1eeQJFn/KkzzQL4CQO8 2n1vW68joc9Ikrt/XQihyc6jTetrnH33GlyfpLQLSUhO1ZOeiiSBwPinwxm23fl2uSu9rTGt 96oAhC56WQOuDklWR7OOY8Tft5kup+C6r94nGwGoy21R8cq3cDGeRnw6ZihV/wB8JWlCtK6n uVxkVOXI+c+EW06jXoooCdKqxlfTM+yPPr5dPH++LqL9vlxIUjSupYP7aqyyT9BiA663rdU/ pVXZWp2BOUmTdLbTs4/PtLDf1RJyEp5VkgAeHOY2em976iMaf26zK6ZKnpZqQZaZmfdduX75 tKQlC+7UglOUgHr458YlbV9X93ae90qnQ59kEVmWIz7Ccfiir39X3+9XUP63lvzx4m+75OQN K6hx1zVpYQC+b5HPwVz4/wD3aW/PHjd/3w4AUaV1PGCfWqkunxx4xZ+Ee89234Kq1nkf7+Zx 9MLGyr2uRrXa+Kgixam65NsS3pkg26gPyoQhCUKyrCVbhzgdc5HAMNo6hXClp7Om1z9+nIQk OS5SojHVXecc+QPHMXJO+7ldR/lOm1xNOBOVBEzKqHU9CXE56fh+TPnv7uZcogjTW4PSFHBQ qalQkdcet3mfAeAxn5M1pvu4HJcLZ03uXvOAUrelUDOMnku5x15x7OIxpjUC7EFKpfTGvONr JCS5OS6FZ8MpCjtHtPSKG9QbyU24tzS2soQkH4tQlyokEeGQcdeRnp7Yz2r8rxlkOO6c3Mkl G5SUuSqiOOQB3oJ+gE+UJLT27apSu0DfL8rZ1XdTPN97MU9ru/SWMFJStQKgnkq5AV9mOuId PwjVb97m7/6OX/xYszuotfQ2kyuml0OrIJAcUwgezOFq/FGEm86xUJyQnajppdzM5JKcW0li YaLfrJ2ncO8SFcdAQcHpzG1Vftdc9WX04ucvFIUnvHJVtOM+Ki7wfZ1i25fdzNuhJ02uIpyn lMzKq4JwejmOgPj5ZxnMXX76uBLyWm9OblU6eeXpQI2+PrB0jPsiNao3xW3dOLolTYNxMd7T X2lvvrl+7aQpCkqWoocUSEglWAD08BzEc7PF61uQ0ppkoLIrlQlpdbiGJuRLWx5JWo5w4tJy DuBwCOPbiGL8I1W/e5u/+jl/8WD4Rqt+9zd/9HL/AOLHh1GqmQDpxeGT0+pS/wDix78I1W/e 5u/+jl/8WD4Rqt+9zd/9HL/4sHwjVX97m7/6OX/xYT2p191ZOten9Ul7OrDE3Kpdaakp0IQ5 Nd76igjapQ4CjyT1xniHCNRqqOunV4Y8fqUuf/mx4vUydZSpya0+vRtofZIlGXD/ADUukx4z qe8+4hKLBvfY4grQpUg2kEAgHOXODz0ODGQnUSbyc2Beien/AOUYP/zotuajVILIa08vFaf2 xYYT+DvYp+Earfvc3f8A0cv/AIseK1Gq2ONObvz/ABcv/iwiuy7edQobVz09i0qxVguaTMKX T2klTKjkFDhWpIHTgZzwqHoNSqoXVNjTm8dyQFH6ixjB9ve4PSKvhGq373N3/wBHL/4sUPak 1NptTjmnN47UjJ2sMKOPkDuTGS7qDUW5dhaNP7tWtzcVthlgFvBwM/VfHrxGOjUasc7tObvH JxhEuePD/lYtHUau96oDTe7C1gEK+oBROeRjvOmPb9HWEd2mbsq9fplvS9Ws6pUFpufK2n5x 1Ku89XBSAnoeQefL5Y66Y/WG/wCCPxRXBBBBBBBBBBBBGJWGm3qTOtPOhlpxhaVuEZ2ApIJ+ aEF2KCybArexBD4qP1RWOo7tO0Z+n6Yllwa1y0pcVUpNuW1WLkVSBmovyCB3bBzggddxGFeX xTjOCQwrOuelXfb0rWqFMh+SmBwSMKQodUKHgoHqPxjBhT9qFCHVaetOJStC7hYCkqGQR0II 8RzDyiM3nedOtJ+htVJDylVeoNU5juwMJWs43KJIwkeMSaFV2oFKTolcRSpSchgHBxkd8jiJ 7ZvFoUPH/MWPyaY1NyXzJUK9rYtp9h12arpeCHEEbWe7TkFWeu48ceUS6EZ2wlqTphTkjGxd YYS4CMgp2Onn5wIeSUhCAlsBKQMJAGABCarustSXXKxLWTaE1cdOoattTnW3w2lKhncloEEr Ix4ZJweMYJY1h3VI3ratPr1LC0ys2gnY5jc2oEpUk48QQYiHaYJGiNzYP2DX5ZETKwW0tWLb jbY2oRTZZKR5ANJxG9gPSOfaZd+oWqE9WZ7T+o02hW5TH1MSrs0wHFz6wM4VuB2JPB4AI3Dq QcOWyZiuzNsU9y7ZRiTrhbxNMsOBaAoHGQRxyMHGTjOMxvYI5+poB7ZNWPOU0ZJHIH2DX/ji OgfCFTbusUpWNW6jZpp62ZVpx2WlagpR2vzDQBdaxjHHrYOfsenIi/qFqHVpC8ZKzrIozNZu J6XM28X3u7ZlGs4ClkefyjqnruAjMqF+Ve39LKndF124qRqVPKkrkETCVpcPeBCFJWM+qdwP IzweDxnDp+rcrXbmtmi2vTlVR+pSqJ6oLQ8NlNYUnPrqAIKwTjbxzgdSIZ4ORmEt2u5VExo1 NuLJBl5yXdSB4kq2c/Msw0LKYZlrNoLEs53rDUgwhteQdyQ2kA5HmIhesOok/Z1Qtqj0SQlJ mrV+YWxLuzrpbYaKSgZVjk5Lg8v7oyEXVedMsyv1Cu2k05WKXtU2xIzW9qeb4K1tnBUMDcdp GeAI1knrhQKy5bErbDD1XqladCVSTSgHJJsH6ot3wG0AnHiBkHHMU6h6xMWPqnQ7Yqci37lz 8s287P8Ae4UwVuOIHq4wUgoGTnoSfDmXUS8m6pf9yWumVKXKM3LuF8OBQWHU7sEfYkRLIUna pAOiVbyoDDkuefH6sjiJnpX9bCz/ALjyf5BESiCOdqrrNc0zdt4SVDYtmQkrb37mqzMKbmJr YSFFvBwfin5NyecmHVYNyMXfZ1Jr0s0phE8wHe6UclCskKTnxwoEZ8Y38EJywAlXaR1RWMEi XpyQf/UJz+KHHBES1SvSVsKy56vTbKpgs7UNMJVtLjijhKc+A8SfIGI1pFeF33UWpuvU6gt0 mZkxNNOU+c7x1hSiCht1GTgqSSeOmMHniGlBBCQ0zDC+0hqetlCwUsyqSXBznandj2Ej8Ah3 wQrtUr7r1FvS2bVtGSpr9Vq6XXVOVJakNISgcAFJzk4V59Bwc8S+yzdCpN9V4ijelFz6j7ll wo2Y+y385zEigiK6sfWsvL7izv5BcRrsz/WRtr+A7+WXDPgiEWff7FanLuk6pLCmTVuTa232 1ubiZfbuQ/04CgFHAz09sZWll3O3zZkrcDlONPbmnHQy0pzeS2lxSQonA67f/AxEtghMag/8 ZPS/+Tz/AORXDngjxRwCTgAecKnSjVNzUC+rrkJRqRTRKVsTLPIcJefypSd+OhQdpPHTKeuY a8EEc9dkKopn2L6V3QbdXVvSVYOeHArCcnk42n6Y6FgjCfqkkzVZemuTcuifmG1Osy6lgOOJ TjcUjxAyIKTVJGry636ZNsTbKHVsqWysLSFpOFJyPEGM2COcu2j/AMAWn90Vf2I6KY/WG/4I /FFcEEEEEEEEEEEEYFwLU1Qak42opWmWdUkjwIQeYQ/YpmEr0+rLACgtqokknodzacY+iMXR 68aFp5WNQ6FeEyzSqg1Vnqglbxx6S0ocJR+2IxkDx7zjoYmHZbp7snpzNTapVcpL1WqTFQlW HAdyGVbEoB8/iZz4jBjXdp/h/TtYTuULhYx59RxmHlCV7ToeVIWOmVCjMKuSVS2EDKir1sAe 3OIdUKrtQ/WRuH/1H5ZET6zv2I0P+Qsfk0wqNbJF+b1g0f7lKlFM/NLPHACe5WefkSfoh3Ql u1s4G9LGAp3u99UlkgbSd/xjjPh0zk8ceZEOmOU9LL9pOi85etsXo1MMTrM+ublltMFRm0lI CUjyyAlSScD1jkiG12bqJUKLpjLCqSfoLs5MvTjcryCy24oFKSCOOBnHkR48RX2mfrI3L/Aa /LIiY6fuofsO23WiS2umyykkjGQWk+BjfRZnmPSpKYl923vW1N7sZxkYzHFmjtn6dti6ZDVK ZTJ1qmvKZ7qZmFMJQ2PV3Ixjcrd4c8YwOYfvZkq1QqtgTBnJianKfKz70tTJ2a/XH5VJG0nx 4ORz5Y8IbkEIq3m0r7YFzlaUkot9Ckk9Qcy4z7OCR88Nq9qhUaVadVnaHIuVCpsy61S0s2Ml bmMJ48QCckdSBxHMBsXVaiWBbzLNApqnaLU01VtUs+XJ5bilHIUMlKh6wBA8Ej2wxbxVMaf6 3NXzM0uenKHWqaKfPLlGi8qTdSUEKIHUYQny+yxkjBzdQKpVdRdBrtdkrcqUk4tYTJS0wnD0 0whbS++CMAjI3YTyfV4JzEMsq1axoncdqzklLTtQpFxsS8lWWQjcuVmzyFcJ4SkrUB7ArPOI 6bHSE72tM/ApU8AEekS+eeg7wQ0LZQpFt0lDjinFplGgVqxlR2Dk44zC/wBcZ6gS8tR5S8rV m63QZp5feTUshS1STgACTtT63rAq5B+x6HpGDoE3PCZuZyVNbFnF5lNFTV1KLu1KMOFIX6wR u6Z8MeOYx9IbQNH1i1LqrtHVJsOvMokHy2UoWhe5bvdnoQVBsnEYl8afTN6az1hNWpq3KK9b HoktPutgty75cJSUEfZgkqx1xnwIjWdmS3rrpF2XnMXmzMCbSmVke/eye/7pJSkpUR66dgR6 3jx4x0NCj7Vf1kq1/GS/5ZETTSr619n/AHHk/wAgiJRBHHjNv0aTuW9JXUyzq/W7mnZ9yYp7 shLuFMyhROO7KSABkk5OcAY6jENXso0yv0Ky6tSbjp89IrlqkosNzWeEKbQSlGfsc85HBKj4 5h3R4rlJxCT0tdU92htVVL6gSaPmSjA/ABDtghZ9om0p68tLqhIUhsvVBpxuaZZAGXSg8pHt 2k4+iFJpNQ91/WdN2dZtetlEky4mvTVQ7xLUwC1tCACcLyrJHA5IOOI6ngghH6Xf8Y3VP+BK /wBgQ8IIUGq+mKL51Ns+cqEmZuhS0vMt1BJe7sJ4BaAwQokqUengnw8WhQaRI0CjSdKpLAl5 CUbDTLYJO1I9p5PzxnwRFdWPrWXl9xZ38guI12Z/rI21/Ad/LLhnwRzpr5Y92vXuifsWXWWb nkxR6upCdyUAKGHHM/FBQAncOgQRwVDL7t2ky1BoVPpMigNyskwhhtI/apSBn5TjMbCCExqD /wAZPS/+Tz/5FcOeCPFciE/oDb4pdX1CnXKSJBx+vPtNKU1sUplOCAnw2ZUSMeZ8ocMEEc2d i9hxMper6k4aXOtISrzUkLJH+0n6Y6TghE9qWn1mSlLbu+1Gpn3apE0poOy7ZcUht1O3lPPB OE9PssQwNF7YXaOmtFpcwgone67+bCiSe+c9ZWc+IJx80TaCOcu2j/wBaf3RV/Yjopj9Yb/g j8UVwQQQQQQQQQQQRhV3uvcSoekhwsejud4G8binac4zxnEcmdmDVOh2datUpNZl6gXlTfpC Fyssp4FKkhODt6YKfwwzK1qdpbXZ1mcrVuTc/NMjDbszQlOKSM5wCU9Mxuk682ahKUol64lK RgAUtwADy6QpO0ZqhS7ipdqv0WWq7RkqmJsPTMmplB2Dokq4Ks44hxua3200E9/TbmaUpKFb V0h4EBXxfDx8PPwi1N62WkkMLm6bcCQo94yp2ju88cKTkeRHI849Z1vosy6tMjbl4TbTZKVu sUhakpV+1POQYgGvOp8pX9K6tTU21dUguY7oB+fpqmWUEOpOFLJxzjj5YkdiazS7dk0Ftdo3 nNLakWWlvy9LU624pKAkqSsH1gSDzG7VrLKKUkqse+iUnKSaKrjw45ir4aJb7Sb7/qZX54V3 aP1Plbh01cpabbuWnOvzbW16pyBl2/VyogKJ5PHT5fKGJSdaJf3BknBZF7rAYbGW6UVIJKR8 VWeRjkHyx5xXM6mS8+8p06X3jNraIShx6kIByPAblZGMnmMn4W6kfi6aXsR4H0NP6UQLXXUe erWltap7li3TTUPhpKpqel0oaa+qJPrEE+WB7TG60y1XqKNP7dZTYN2z6WJBpgzcuwlbb3dp 2FaVFQznaT+eJIdW6jn1NNb3KfMySR/8UefC1UvstNL2x4/5Gn9KI3V6rR7mrCajVtE7gnZ4 J299MyDQKhg/GyrCuBxnOPCJBTdR5+TkQ1I6W3ZLSMugJaaalmkBKeeEo3DyPAz+GNhLai15 2XQ4NN7qG9O7CjLgjPsLgI+cRbc1DuZIcI0zuQpB9XD7BJTtznG/rnjAzxznwhPSF5VuX7Ud QqDVo1UzM3ThKu0wLa9IDYQhQXnOwcoSfjePXPBdyr4uHchKtN7hJX8X/KJQj5z3vHzx4L6u BTncjTe49/Tl6UCf53e4gN6XSXlob02rnCc7jPSg5PQfrmMcefHlFSb2uRaSoab1/I65mpMf R9V5jXTN/XmyrCNLKuoFI590JcnOeRwTxjxi58IFz71hOmVxbABgmZlwT0zxv8Ocdc+zwWna VvKr1PS6ZkpqzKzSpd6aZSuanVs7E4O4ABC1HJKQOmPwRMrTv67WrLo+NOq9OOIp8ulD/pbI D69gBUcq3AEAHJGecECN1L6g3KXXO/0yuNCBjYpD8usnzyCsY5+XPsjxGoNzmaUhemdxCWwN q/SJcrJ8infgD54um/7iTMlJ00uTukp+MHpYndnpjvMY9ufmi6b5uNTKnW9N7iwPBUxKJJPy d7n8EY0zqDcwTmV0xuFxQ5w7MS7Y/As+OPw+UYp1FvcZzpTVuOeKiwf7oXuv93XXWNKalL1W wJ2jyDjrXeTb0+053eFgjKE88nA+eJHpjel9S+nFuNs6cTc+wzINNtTIqbDPfNpSAhQQoZAK Qk8xKPfvf3hpbNf11Lwe/e//AN6ya/rqWg9+1/fvWTP9dS0AvW/cjOlkz8vu1LRinUa9x10o q+fuiz+aMlF9Xwtexel1RSoo3p21WXI8eCeMHOOPLJ8IU2nNzXXLa3agzEtZExNzkyGzNSSJ 9pCpUpGEZcVhKgoHw/DiG179r/8A3rJr+u5aD373/wDvWTX9dS0ei9r9Od2ls37MVqW6xSb1 v4jB0smT/wDvUtHvv3v7962a/rqWikXxfqkBQ0smwD51mXB+iLadQL2SwC/pZVkvlIIS3UmF pyTyCrPAxnnHl55hV6eXdX2dfr8dYsyoTE5OtJL0imYaS5Ld2EhJUtRCMKz4HxGMw4Det4pe X3mmdW9HGNik1KVKz55TvwPHxPh5xZXf12JUpB0xru9JPSdlyk8H7LdzzgfOfLBqRet7q3KV pfUBwCjFXlsnjxyePwx57+r0aRumtMKqFHPDFSlnOOPaPOPJi/LxQ79Q0wrDjAbLm5dQl0rx nptCjz7M5j1++ryQhHcaY1dbvd73ErqMsEp9iSFHJ6+APTjmNDqdfNfmNNrmYOn1wS6H6dMM rffcY2MoU2QpatqyrCUknpzjw6xoez3edbktKKRKS1kVmpsS/fJRNyjjAbdSHFE4C1pOQSRj HhxDD+EGvfvb3R/Olv8AFj1OoFeJAGm9z5PmuWH/AM2PPhBruc/BvdH86W/xYPhBr37290fz pb/FjxOodcUVAab3TlJwcmXH0fVOYPhFreXAdN7rygZOBL8/J9V5+aE7qXe9ac1q09qbVn1u SmpUOJRJzCGy7NIc9VYbCSRkJJ6kYz4dYcfwg14f/wBt7o/ny3+LAdQq6ASdN7owBnhUsf8A 5sWJnUusS0uHndNrtLZx8Rtlauf9UOEwNalVd2XMw3ptd3djPxm2UrwP9UuZ/BFTGpVZeTlO m13DJwNyGE9OucuDEUnU2sBKT8Gt3+srYPqTPXGf2/A9vSLqtQ67hRGm90+p15l+eM/6Tn5o Q/ZivWpUBm5ZCXtau1hLs4l8iRaSfR14UFJcKiMEhI4z9iYffwg1397e6P50t/ixQvUatozu 03uvgbvVEufPyc9nT5PMRac1MrCGytWmt3YCw3w2yTn5A5nHt6e2PDqZV0M978G13bCjvOG2 ScfJ3mc+zrGOnVmpqVgaaXrnnrKIH/xR58LVT/ezvb7zT+lCW7TN6Tlz062peatSvUNDU6pw O1JkNpcOANqcE885/wDHHXjH6w3/AAR+KK4IIIIIIIIIIIIwa6331EqDW4J3y7idxzgZSeTg E/QI587ESALPuNY27lT6EnzwGx19nJ/DG/ruvL6birMjaNoz1wyNFBM/OMu7EoxwraNp4BCv lwSBgZhp2HdlNva1pKu0ZajKzKTlCxhbSwcKQoeYI+fgjgiE/wBrtpT9IsxlAWpTlaQkBCdx JKSOB4n2Q/4h993yxaFWteRmZJ6ZNdqKKehbawA0VEAKOeoyocfLEwhVdqA/7iNw/wDqPyyI lek/1rLN+4sl+QRFjUi+paxkUBycllvt1SptU8qSrb3IWFEuE4IOMD1cgnJx0iYwmu1v9Zef /lUv/bht0n/guT/iUf2REYvW+GbXuS1KQ5JOTDlenDKpcSsJDOAPWPHPKk8ccZ+QzEdOYWna RaW9opc6UEAhlCzk44DqCfxRvdIGW2NKLOQ0kJSaRKrIHmppKifnJJiXRqLtarD1uz7dsvy8 vWVNESrswnLaV+G7g8dfAxzZqJXdbbDpkjN1e56I8uZmESrErJsocffWQeiC0MjgA48VDzjo nT5ddcsqjru0JTXVS6TNgADC/aE8ZxjOOM5iQwQgqT3X6saud6cL9xE90ME5VtZ/+HdDV1Nu R60bCrVdlZcTL8lLlxttWcFRISM48BnJ9ghPyuqd40OjWlXrhm7YqdPrzzLYkZELRNtIc+zA yd23BBGOFYHjxIdYtR6zbmoNr2tQJukSK6okuTE1UG1LSykqKUkgKAA9VXj18omDNWrdB07r tdrc/S63Myko/Py7kg0WWXG0Nb0p+MrOSk+sD0I8o3NhV1dz2XRa26wmXcn5VuYU0lWQgqGS AfKN9Cd7WYzopUzkjExLnA8fqghp2/8A8A03+TNf2RCo1Ov+vUrVmh2hRKhRKSxOSBnHp2qI Kkg7nAEj1k8/U+BnndE+t9i5ferOIqdZpc5V3UrMpPSsqUMpBQO7UpG47sKyTgjIIHthTW/X tT6prFULSeuCkNytIZbmZl9mQCkPIJR6m3cSlRCz4jG35I32qV/Vik6lUK0qJVaHRkzskqbf naqgqCMqUlCU5UlOSUHAzyfw7XRq+p+6pi46XV3qZPTdFmUte6NMJ9HmULBIKQehGCDyR5eZ Z0KftSuIb0Sr29pLhUphKckjaS8j1omGlX1r7P8AuPJ/kERKIIgGj9duO5KdW6lcsr6Iyupv IpzCmtiky6cAZ8TyDyevJ6YifwQK6GEtpU6U6+asMhSFpUqSXlCcDIbIx0ByM4+XPXrDpgjQ Xou5U0f/APBjdLXVO9Tn3TUtLXd87vic56fhhd6bXze1c1IrFt1+n0NySpLeJuepi3C228cF LYUr4yuoKcDGD5YhxwQQhNGplc32g9VnHAAUuNtDHkhRSPwJEPuCInqfectYlozNYmWVTLoU lmWlkHCn3lcJQPxn2Axq9P61fc5Uu4vS2ZKQlXpX0lubk5oLDSir9YcQTneAeSMjj6GBBEV1 Y+tZeX3FnfyC4i/ZidQ7olbmw5CUvJPGOQ8vMNKCEzW9dJSl2BUq+5SVCekawqjrp639qi4k 5KslOcbAVYx14zwTEvoeoUnXL2laFTJZx5h+it1j0wKG1CXCNiFJ6glJ3c+YibwQmNQf+Mnp f/J5/wDIrhzwQRHaXe9rVWp+51OuOjTU+VqQmWZnW1OqUBkgJBycAHp5HyiRQQRzt2OlOvyF 6zT8wHFvVMFSD8YKwolR+Xd/smOiYIwG6zTlz07JCelfTJJCXZlnvU72UKBKVLH2IIBOTFyX qUjMzjkpLzss7NNNodWy26lS0oVnaopByAcHB8cRlwRzf20lqFGtFAB2mfWSccAhI8fnMdGs frDf8EfiiuCCCCCCCCCCCCNdcn7Hap/JXf7Bjn7sRjNn3IBx/lyPyYjVaT35SdIHL4ti9S6x OS9QcnZdSWVKM6FAJ2p44ztSQSceseeDDJ7LtAn6Hpe25U2Vy7lSnHag2wsYU02sJSkEe0I3 eHChGi7WSgmUsZS3HG201xsqU0MuJ46p9o5+fEPuEx2gWHnrq0qUy044lu5WCspSSEjeg8+X AJ+aHPCq7UP1kbh/9R+WRE006lvQtPrYlck9xS5VrKsZ9VpI5x8kLztPy8zNW3aDcky48+bm lClDaNx+I74Q5ITXa3+svP8A8ql/7cNuk/8ABUn/ABKP7IhT63SzjuoelLzUtMOluskFSACh IISTn24Tn5EqhxA5ELntEMuP6MXSlpewplgsnzCVpJHzgRvNJ/rWWb9xZL8giJVBCRlJVN2d qGqrqX1WVtOnsiUZUn1UvOpSvvPLICj18h5Q7gMCCCOeZNCl9s6fKXFICKSCQMYX9RQMH2c5 +YQ1dYKXUqzplcdOojQeqExJrQ03kAr6ZSM+JGQPaR06xzjLWbL1m2LaottaeV6jXrJuyy5m rTjBZYQUYLjqnCr1gTyE7cjwHABm+uNvLVrLblzVW1J+5bYZpplpliSY75QcC3SMoyPFxB5O Dg+UT2VfbuvR+4adbdtVOiJXTpqSk5CelUypKlNLCQkZICSo9c4iK6NXpP2/aFt2rVbJvFFQ ZAllzAp47hOVkhRUVghISQTx4HEPUdOYT3ay+snVf5RL/lUwx7ImzP2ZQJxSQgzFPl3SkdBu bScfhhJ63UN6Y1stmq1O0Z657b9zVSrjEmx3ikuhThJPIHAUggKIHXHjDf0/q7NYt9Bk7fqt AlJYJl2JSoyyWFd2lA2lCUqICccD5IjNr2jWaZrldtxzDTBotUkmUMvBwbw4gIG0o6+CufYO ueIrrhbD07qXbNfm7QmbpoMvKOSs1LSuFOIUVEpVtyN2M5A6deRG40JtebotWu+pCgO27Ran Msqp9NecBcbQhGCtSQSElROcZJByOgBLfhR9qv6yVa/jJf8ALIiaaVfWvs/7jyf5BESiCADH nBBBCS0maWdfNWHgB3aVyiCc+JSojj5jDtgjHqTjzNPmXZZvvX22lLbbxneoAkD5zC+7Pttz tt6byia0063Wp952enu+H1QurUfjZ8doTmGTBBHPuh31/tWP5QPyio6CghadoC3qtX7Fbct5 rv6pSp1mpMsYyXi2TlIHicHOPHGIhVoVWqXdrZTq5QpK7KbTRLOCvStVKkSqFhvY220k8FQW ATjHTPHMdAQRE9W93wVXlsIB9xpzqM8dyvP4IjnZn+slbX8B38suGfBHJuomi9QuTX+aZZZn GreqjZn3Z1CfqbTmwhQz0yXAOOuFRLeyjp/WbbbrVauVqclp15Qp7Mu+o/rTZ5Vg+GQAnnGA ccER0LBCY1B/4yel/wDJ5/8AIrhzwRpr1lJ6fs2vSdIWW6lMSD7MqsL2FLqm1BB3eHrEcxx3 ZbtIZvHSKlyNGm6RX5GdcTVnJiWLSn1qWnaN3xlYAUMEADdjzjt2CCObexgl4SV6KWD3Bnmw g4GCrC934NsdJQRy52mrLuGd1Bpj9ny04pVxygp0/wCjpIbXsWkjvVDoMbck4GG/lje9lC0a 9SF1+q3ZKzkvOYapkqmbyFJaZzuCc9UA7ACOPV4joaCOZe2o7MbLHlkf72cmphayRwFjugnn w4Uv/wACOl2P1hvkH1R0+SK4IIIIIIIIIIII11yfsdqn8ld/sGOUOyffUrbVGr1Pfo9eqDjj 7b++mSKppKAU7cK28pORxnrDjmtT6TOTgdnNOryfcYz3LztvqWR/BJ5EX/hlH2gX9/Uyvzwn u0lfwuSjW4kWxc9KMrUg9vqUgqXS5hJ9VBJ5V7IcaNZGlJWTYl+pITlINFXlR8usUHWNJxnT 6/jjn/gVX54E6yFSylGn1+kBO7PuQodM5HJ8hEF191EcrWldYpzlm3bTu/7nEzPSPdso+qA5 UoKOPi4+UiJDp3qtMtWJbUuuyL0nnUU5lszMvId428UICStKyoZBxnJ658YkK9VJop405vlS hyAqnIHP8+Kk6qzZCd2nV9AkcgU9Bx/twqe0VqBPXBpc9JPWVc1JadmWVKmqhLhtpAByBkEn JxjBAxDGpeq9RFGkinTi81q7hs5RKoKCNvUK3cjp4eMZcxqnVG5nujppeSi3grUJZshJOcbS FkK48jxFteqtaQtSRpheBAJGQwj+4xCNaNQq3VNMrgkX7BuamMvNpQqcmNqW20lQJKiM8eGP byRmN3pJfN0s6aW2yvT+sziGZJtlqZYeYQh5pA2oWAtYUMpAPI56jgxJJm/7vSsiW0wrayUE jvJ2XSNwIwOFHA5P5oti/wC9+8bB0tqobKR3hFRl8hWOcDPI+iNYxc10SFZqNTpuj86idqBR 6VMGpMJW9sG1G7k9E4jcKv28O7cKdMK13gQC2DPy2CrHIJ3cDPjg/IIx3L/vrvF7NK6mWwPV JqbAJ+UeEZLF+3cUoMxpjW0rI9cInpZQHXplYz4eUJdq5biR2pn6jLWdOLqL8iGVUtc00lxL XdJ+qFwEoHQHGfZ1h2TN4X0BiV0zm18kfVazLJ48DwTz7PwxR78b/wB6R8GD3d55Pu3LbsZ8 B8nti6i7r178BWmk+GcfGFXlSvPHhuxjr4xS/eF9hJ9G0zmlK3YHe1iWSNuODwTznw6e2Lbl 636hzB0wmig4CSmsS5O7HiPAZ8c9OceEUt3vfaXtkzpdOhsfZMVeWXzjPQkcQtO0VdV01HS2 oylasSbpEmuZaHpi59l9KQF5GUoOckjHlz1iZ2Xdd9ylkW+zLabPTDbNPl0Ic92WEd4kNgBW 08gkAHB6Zx4Rt2701CUncNLXU58FVuXB/FFQvHULdzpe4Bz0rkv18PCPffjqFyfgwczkYHu5 L49vh8kUm8NQj10uV/Xkv+aPfflqH+9ev+vZf80Hvz1D8dL1/wBeS/5oXHaJuO8p/S2pytYs f3KkFPMhyc91GpgJAWCMISAeSAM+2JFpnd9/taeW41L6cKm5duQZbZfFWaZ71tKAlC9ihlOU gH54lHvw1C7sq+DI5BA2e7jGT15+LjHHn4iKfflqH+9ev+vZf80AvLUPP1r1/wBey/5opYvH USbZ3MaZhhXUelVtpPj5BJMVLvHUNJUkaYlWOMiusYP4OkVyl16iPAJd03aZVwCV11rGcEnG EE4yMfOPbhR6eXBeErrbqHMyNlidnn+69LkxU22zK4+JhwjavIz0/uhtm8NQwgK+DInPgK6x kf7MeKvHUMYxpgo5APFdl+PZ0in35ah/vXr/AK9l/wA0AvHUIdNLlD/98l/zR778tQ/3r1/1 7L/mg9+Wof716/69l/zQe/LUP969f9ey/wCaE7pxcV4yuud+zMlZHpM7MhJm6eJ1tkyuCNh7 w5SrIznHUnI4EOL35ah/vXr/AK9l/wA0eKvTUNOM6XOHJA4rkuf7o9N5ahYGNMHN2ef8+S+M fR8sHvy1D/evX/Xsv+aD35ah/vXr/r2X/NALy1CJG7TBwJzziuS+cfREb1Huy+3tObnandOX JSXdpsw29Me7DLoZbU2Qpe0DKtoJOB5RoNC7uvCn6TUZikafzNVkme8S3NJqLTPfDvFHIQrn qSPLiGI3eV+7yXdMZkM9corMuV4/gnAz88XU3vdqnu7+DStADncahK9MZ/b4z04zFRvS6uf9 zStBKQSr/L5TJPHQd5z1/BGOL0vsuFSNMJz0bd1VV5YO7fE7M4z7M/PFIvXUBa3O70umAhKi ElytS6SR4HHP44pdvjUJsoSdLH1FZwCitS5A+XjiFVqddd1ta2WBUHbNflJ6X75ErJqnmXVT aV+osBSTtQcE9T4iG1MXnfjZWprTGbWnclKM1iWyQc5JAJx4efj5RYcvrUFBAOlc0SodU1mX IHy8Rke/e8+7AGmVUL6f1xJqUsEf9VW7KuceAiBUW3qlS71euqX0lqa60XHHCt+4WXENrWfW U2FHn1ScZ6E4HmJ+m+LuVyNMq1twOtQlQc58t/lGOm/rzK179L6wEhwBJFQlySjPJI3cHHh0 9sX/AH83cWX1t6Z1oqQCUJXUJUb/APbz9AMIfst3NXaS3dDNItCbrSXpht11cvMttFhXreqr eRnjcRjxGPHh1DUG/vHSmofNVWIyGL9vIukP6X1lDXOFIqEupXhjgqHt8YvC+7p2DOmlf38Z Hpkrj2874pYvy7Ccv6Y1xJyrGydllcZ9XqsckdfL2xQi/rxU88lzS+spZAPdKTPyxUo/6w3Y HzExZcv++Q4vutK6oUYG0qqbAJPGcjPy/ghJdo6v16uT1kquOzZyiS7E25gOzSHhMFRaygbT gHCfsuueOhjsBAAQkBO0Y+L5eyPYIIIIIIIIIIII11yfsdqv8kd/sGOfuxEkC0LjVhOTPIBP jw2Pz/jh0XbfNJta4bbo9UD4mK8+tiWWhIKEKTt+OSRjJWkDAPWJVCH7V6ZdcjYyZ1wolzXm g6RxhGDuOfDAh8HgcQlqxrm4K3WpW1bPqlxU6iqLc/PyzgSlCgcHYNp3AYVzxnBPTmGfZty0 677ck65RnFLkJtG5G9O1SSCQpKh4EEEeXkSIh3aQ734F7o7hKFHuEbgroE96nJHtxEh0n+tZ Zv3GkvyCIgFd1snTXKrKWbZtSuOQo7hbqE8yvYhJT8dLYCTuI/DjpjmGfZlzU68LZka7RXFr kZtJUjenapJBKVJUPAhQI8uOMjmFp2t/rLz/APKpf+2IbdJ/4Lk/4lH9kQmK/rlP++KtSVm2 fN3DT6GSmozjb2wJIJCtgCTkeqrB8cHjAyWrZN00y8rakq5RXS5KTKc7VcLbUOFIUPBQPH4R wREY7QiFL0ZutKACfRNxyfALST+CN1pQANLrOAO4CjSeDjGfqCIlMYdZnFU+jz062yt9csw4 8lpAypwpSTtHtOMRx9b141m6LWrN2VjVt2i12nrcclqOkpbQ5hIUkBvcA4FcpA2qxjJzHUul 9cnbl09oNZqrSWp6clUuupSnaCr9sB4A4z88SiCEHRWA/wBsWvuJcA9GoaXCMZzwynHs+Pn5 ofkB6cDMJ06wVmfrtyyVs2JOViUoL6mZmaTPts525zhKhkn1VeqCT06ZEbW6dYaLRtM6deUl LzFQlqkpLUnLo9RSnDuyhR527SlQPXkcZjb6f3VcVbnJ2Ruqz5u3puXbQ6lwvpmGHgonhLie NwxynkjxxE2hPdrL6ydV/j5f8qmGjbo22/TBkqxKtDJ6n1BEW1U1BYsOmyZTT36pV6i/6PIU 9g4W+vjPODgDI8D1EZFg3NX62uelbotObt+elNh9Z5L7D4Vn4jieCRjkc4yIjDWtFNOsTtjO yS22gsSzdR3+qqa27u7KccftQc9fDnMZd66u02z9TqLalYli1LVGVS+qolzCWVLWtCApOOmU HKs8ZHgDEkpF3oqV/V+10ya0OUliXeVMFwEOd6CcBOOMY8+fZEphR9qv6yVa/jJf8siJppV9 a+z/ALjyf5BESiCIJpJeM3fFOrNUdlpZmmt1J2Wp6mlEqdZRgb1+0nPl/eZ3BBCZ0kbaOt+r jhSe+D8kkKwcBJbXkeXUD28Q5oIiGrF5iwbHnq/6EudWwUIQyk7QVKUACo+CRnr83jEJ0+1R uCo3HbVLu2jU2TFyybk5T3JGZLikpSjvPqqTnGUdDnqMY64csEEIrSZanO0RqoVhQI9HThQw cAYHzeXsh6wREK/fUlRL+t61pqWe76sturamSQltKkDhPPUnnp0yOueLsreLExqVN2giWJdl qcioKmQ4Cn1l7dhT1B6HOfGJVBEV1Y+tZeX3GnPyC4jXZn+sjbX8B38suGfBChrutsjal13D RLxpj9MMkyZmnPhW9NQbxwE8cKJyPEcEEgjlgWFW5y47PpVZqNP9zZmeZD5le8392kk7ecDq naenGcRvoIS2oiEr7SWlwWAR3E8cEeIZWR+EQ6QMACCI7qHcnvQsmr18S3pRkWC6Gd23ecgA E4OBk+UY9hX7QL3pzcxQ6lKvv9yh1+VS4O9YKgMhSevByM9OIlUEEc3djEgyd6gAbvT2yVZH Iwvw6/8Aj5Y6RgjDm6pT5Odk5ObnpZibnCoSzLjqUreKRlWxJOVYHJxFynz8pUZYTFPmmJqX KikOsOBaSQcEZHGQQRGRBHM3bKdWmq6dtjeptU1MLU2DgKIVL448+T9JjpkHIBII9h8IIIII IIIIIIIII11yfsdqv8ld/sGEZ2Kgfg5q6ihIBqagFADJ+po6nxjJ7RbTjmpmkHdtKXiqO8gE 4O+XOPwH6IfYOekc+dsT/gG0fuun+wY6DJwMmOVtHb1o+jvv0t29lTMrUZeeXMs5YJM4nG1O zHirAIJOMK69YaPZhotRomlEm1V5Z2UemH3ZpuWc4LbazlOAeQD1weeY2faHSlWi915Gf8lH 4HExutKPrV2b9xpP8giENpffVI0bmr0te80TbE4mouzkqUy6lJm0KASkIxnGdoIJ4568GGh2 a6BUKDpk17rNOS79QmnZ9Mq51l2142ox4cJ3Y6jdz5DV9rpxCNGppC1AKdnJdCAfsjuzj6AT 80N6k/8ABUn/ABKP7IjlvTi96ZolVL4oF4S08icM6qbk1tskmdb5SnBOMA4yCTjlXiMFu9m2 25+2dLJBiqy/os1NOuThlyDllKyNqTk5ztAODyM4PIjL7REx6NoxdKsoG6WDfrnHxlpHHt5j eaT/AFrLN+4sl+QREqjQX97r+8mue9vPux6G76Jjr3m042/63l7cRx5QaXpBNaQzL9amJqSv SVYdDqC84HnHwVbAlB9QpPqjoMDqQeY6j0El6rKaRW2xXm3G5xEtgIcGFJbye7BHgdm3g8+c T+CELRVbe2FcQHeevQUg7MYPDB9bPOOPDnOPDMPqAxxwaVabd/anMXnc1Xoc56Y4uWl5BxaA +hW5W7btPeHkDbkcKPyhiUUSNL7NduympNuVKfp6lltbUuxl2XaLjhaeWkEFGE46EnkeZEXt E6w9M6jT1Ps2sVauafNyIcL9S3q9FmSeGm1rAUePsfl8uX7Ce7WX1k6r/Hy/5VMNG3d3vfpm 8gq9FayQMDOwQq9e2JmlXFYl6plX5uQoE66mdbl0bloaeCR3mPEDbz8oiSUfUqWuSk3BO2rS qrPN02UU8w87LKZbnHghSgy2FeuVZAB9XxhBKsrVBnSybW/bsgubXVxcRX3pM8l4Y57ocE4z xnOCRjMTq9tPntTNTJZ6uU2ZlJR2z2x6SUHbKTqnlkJ9qk7jlOenl1jF7L1GuemXne67vYnB ONolpNUy+k4dLYUhO1RHrDYE4I8MHxjo2FH2q/rJVr+Ml/yyImmlX1r7P+48n+QREoghNdl5 r3Js+tW1Mb0z1Eq78s8lQwSCQUqHsIziHLBBCW0kW8NdNWmwjLCnpNSl46KCF4GfkJ+iHTBC 07RlHrNd0lrEhbrSn5pZbUthCQpbraVhSkpHnwDxzxgdYUGnFvUFzU2xZ/T236vIv09h1dcc n2nUNI3M7CnLh5cytXCeOQegOOqoIIR+l3/GN1T/AIEr/YEPCCE7rVYTt96g6fsTEk+/Q5Uz i591tZQG0lLRQNw5BKk4GOesUaf6dN2XrXVZiiU6aYt9+ioSH3XlOpL/AHoykKUSc7Ug4hyw RF9VCtOmN3lkrDgo85tKM5z3K8Yx4xGOzP8AWRtr+A7+WXDPgjm7WaxLu1YumorlZRNLpltN Lbp/pbeVVJ9WFKKeMbDtSATkdPNW126dV2euOz6fUqvS5ilVFxOyYln2ygpcT6qikHnaSCRn nESSCExqD/xk9L/5PP8A5FcOeCF52hKZMVjRu5pKSbddmFMocQ20kqUrY6heABychMLWzrHn bY1i09XTKO9J09FslNUfQ0EJW9tXvDpHVe9TXB56eAjo2CCOb+xiEe595qD25wz7YU1t+KMK wrPjnkY8NvtjpCCEl2paBOXNb1BpVEo0xP1x+f8A8lmGvVEqAklZUv7EEY68cZ6gRuezU1My WlcjTZ+kP0qcp8w/LPtvI2lxYWSVjzzuxn2GGpBHM3bEITcOmpVu2iamSdoyfjy3QeMdMg5A PnBBBBBBBBBBBBBGuuT9jtU/krv9gxzh2Srztq39PatLV2u02nTCZ9T3dzcyhpSkFtHKQTlX xT0zDvcv+wJpTDr912s4tpXeNKcqLBLasYyMqyDgkefMX/hGsf7cra/rRj9KEp2qbrtWtWpb 3uTX6TUJuXrDTikSc4h5SGti9yiEE8Z28w6U6kWOpIULxtvBGRmpsD8G6NZVbz0wmXWp+o16 0ZqYlyO7dXMy7ziCDxt5Khgk9Pli+5qzYDTikqu6jFQ6lMwlQ+kcGIPrxqHZ1S0quCnU+56V NTs1Kp7lmWmUuKUd6Tj1c4PHQ/PGfphqtY0ppva0pO3NTpaalqZLy7zLzm1aFobShQIPtSfl 6xvZvVXTRbjcxM3JRHXWc92skLWjPXbwSPmi+NYdPcJPvtpXr4x9U8/Pjj54VXab1GtCv6XT FMolekp+femWVIal1FZwlWSTgYAx5ww6TrVp6m3ZKZeuaTawwjc0oLLqDgAgoAzkHyEY8xrf pTMuNOTFelHXGjubU5IPqKD5glvg8mL/AMPmmf20N/ekx/hxDNZdYbBuLTC4aVSbhD8/My4Q y0iWeSVq3JOMlIGOOcnpGw031v0+pmnttU+pV8S07J02Xln2VyrxKFttpQoZSgg8pPj0iQP9 oDTRporFyBwjHqok38nn2oj1ev2midn/AOJkq3HHEnMce0+p0jSzOqWiLlTFVefoztSSreJo 0dxTwPmFlrOfnjbPdoPTRsKxcJcwnd6kk/z7OUdYtntD6ahIPu658UKx6E9xwDj4vXnHzRZ/ VG6bfuvM/eLv6MKKR1YtZvtKzl1pnJg0KZp4lA8Jde4r2I42Y3YynHTriHedb7PSoJJrQUc4 HuTMZOP+pHvw3Wf/AOmv6pmP0ItnWiy1Od4W6uXMY3GjzGcfLsiv4bLOyTis5P8A6ImP0IsL 1xsaSQApVUYQTxmlPoGSQP2nmQPnEUPa/wBhMFwPTdSb7tYbXupr42qPRJyng+yFx2iNVLXu vSyaptKVUFzL77SmVPSLjSPVXk+uoAdARxE4tTW605Wz6IKg7V+/RJMIdWaa+oFexIPrBODk +I6xuvhts/x92v6omP0I8GtlnAAAVkAf+iJj9CPU62WdzzWU8E/8ETPP+xHnw22fjpWv6omP 0It/DjafpAb9Hr/d7c997kvbAf2vxd2fmx7YufDfaG4DbW8H7L3JmMD2fFhadoTVW3rk0uqN KpzFZTMTC2Slb9PcabBDgUQpSsYOEnpmN/YOuFrUnTS3mpyWrYXJU5iXe7unrWgFtAQpQX8U p9UnOent4iWJ1vs5SQpKqypKhkEUmYII8CPUjxGuVmLUtKF1hRQdqwKVMHacA4PqcHBB+cRb Z1kshl151liqodeUFOrRRnwpwgYBUdnJwAOfKL8vrdZboClP1VpvG7vF0qZ24+UIMYzmvlhN BtT89UGkuOFpCnKa+ApQODj1OcHgjr7IyVa3WWlxCA/VVKVgHFJmfVOM4Pqdcc8QotOdV6BT daL/AJ533SXTauppbKmpJa1AtApO5AG9Pxjjj5cQ2V652YjdvVWE7U7jmlTAwPP4vSLnw22c UtqQusLC07vVpMzx/sfii3I676fz6HPRatMuutjcWUU+YWvw8Ag+Jx8sUDX7TcpCl15xCdxQ VKkZgAKBxg+p18fkj2X170+mnHG5SrTUw8gqAaZp8wtagMcgBHTnxxFl3tA6fN7AajO5WFKA 9z384T8b7HwwQfLaYvsa+6autJWLjCc4G1UnMZBPhw3Chs3Vy0aHrff1an519NLqYaRLPCWW dxbASQU43DxxkDpDXV2hNNktPLNdcCmzjuzJPhSuccepF5evmnQlPSEVt51HAUESEwSkkEgH 1MAnGOsUo1906XJelCsv92ASr/N8wdvOOSEYGT05j1rX7TNxtK/fIlClDJSqTmMj2H6nFQ19 0zx+ydH3nMf4cHw+6Z/bOj7zmP8ADjS3vrrp9N2ZXpemXCl+fekH25doSr6StwtqCU5U3gZJ HJiLaA6x2VbmltKpFxVpMjUJRTqFNGWeXwXFKScpSRyFCGH8Pumf2zo+85j/AA4Ph90z+2dH 3nMf4cHw+6ZfbO395zH+HB8Pumf2zo+85j/Dg+H3TP7Z0fecx/hwfD7pn9s6PvOY/wAOFLqR q9ab+slhXHRqkZ6n0xL6JtaJdwFCXAUcJUAScEniG0NfNMxwbobP/scx/hxbX2gdNEsuLFx7 inPqiTf3K+T1IsJ7ROmpSg+7bw3K2kGSe9X2n1ekXl9oHTNLKli4d3rAbBJP5OT15RFCu0Np qmWDorrhO7b3Yk3t3y/Fxj54tq7RemwCj7szBxjpJPc5/wCr4RlDtAaZloL98oB252GTmM/J 8TrCP7L2pVrWezdLdy1MyHpkw28wVtOOBY9cHhCTgjI6+fsh2t9oPTRa0JNwlIUjfuVJv4B/ an1OsXfh90z+2dv7zmP8OLK+0HpolhbguBSik4CBJv7ldOnqY8fwRWjX/TNQBNyBJ2g4MlMZ GfD9b6xitdovTZagDWZhHHVUk9+jGU52gNNkyhfTcClgBOUJknyQT4H1MZ6+PgYR+vuotsag XFYRtidemVyM6vvgthbYSFrZx8YDPxD08o7EgggggggggggggjXXJ+x2q/yR3+wY5l7JNl2x c1m1iZr1Bk6hNNT3dJemmw5hOxJCUg9OSc+eYbFzWlpTbL1LarNuUKWcqc0mTlUmTB7xxXQc DgdOTxyPON81pXYackWhQ8kFJzKIPX5oT/alsm2KLZ9Am6RQKbIzK6zLyq1yzCWipotukpO3 Gfijr5Q629OrJaaShNo29tQAkbqcyTgeZKcmF1e1z6MWbW3KTVbfojlQaAU61K0VtzugRkbi E4zjwznzieUa0dP6zSpWpUq2rZmpGaQHWnm6ayUrB8fi/gPI6GIfrtZVrU/SK5pqn21RZWaa lgpt5iRabWg708hQSCIkGk1r0P4KrTSukU9wPUqWec7yWQretbSVKJyOSSo/TGl1FvfTqypp ujVeiMz86loOGQkaY28ptvoCoHCUjB6Z6fNmW2yxZt5W/I1ikUylTcg+j6kpUk3lGOCkgp4I IwR7IXHatoVJldHph+Wpciy8xNMBpxuXSlSAVYIBA444hs0W36O3SJFCKVIJQlhACRLIwPVH sjAuedtW2naU3V5OSaVVJxuQlQJQK3PL+KDgcD2+GY3golKI5pchn+To/NEC16olLTo/dK0U 6UQtEoVpUhlKSlQUCCCBGy0hoVJZ0us9TVNk0rVSpV4q7lJJWppK1KzjqVEn5TEsVRaWpRUq mySlE5JLCMk/RGmvOfodmWzUrgnpCWDEmwSQhlAU50CWxx4nAhF+/vUmVtpF9Tlm24bUcKJt UqhAEx3RVgO5znPIIVg9c4xmOg7cqtNu62pGryID0hUGO8Sl1sZ2qGFJUD49QR04jPFNkg6p 0Skv3qkd2V90nJTjG3OOmOMRkpQEnI+fiOfpAA9s2pEgZFIBBx4903HQcaao3LS6dcdIoU5M 93U6sHTKNbFHvO6TuXyBgYHPOM4ihy6KW3eLdrqfIrLkl6ehnYrBZ3lGd3TOQeOsLXUTWKu2 XcCafMafzkxKzE0JWRm0z6QJtRxt2pCFYJz0Jz+KGnbM/O1ShSc7VaW5SZ15G52ScdDimTkj BUODxg/PGzhO9rMA6KVQkAkTEuRkdPqghiWDLuyliW5LTCdrzNNlm1pznCg0kEZHtjfQsLr1 Z9x74ftalWtWa7UZaWTMzHoSU4bSrGOD1+MOeOo6xIqjeqKPp49dlepNQp7bDPevSKwhT6Mq CQMBWMnI6kdecRr6jqpb8npg1feX3aS8lJaaCQHlLK9vd4zjcCDnnHqnmJZblYlbgoNPq9PU VSc8wiYa3Y3BKkggKwTgjOCPAgxsYWfaUIGiN05GfqTX5ZuJHpSAnS+0NoABo8ocAY5LKCYl MEQ2i3oud1JrtoTsgJV+Slmp2UeDu8TTCsJUrGBtKVHHj1iZQQQjdJUJHaE1WISAQZboPMEm HlBEU1Nvin6f2q/Wakhb5Cg1LyzZwp90/FQD4dCSfAA9ehjtnaozNSuSUt67LXn7YrE80p6S RMOpdamQkZUkLAGFAZOCPDrnALNgghFaUAntF6pqW0ltYEuBgg8YHOfbwcQ9YIwq3MzsnSJu Ypch7ozzbZUzKd8Ge+V4J3q4TnzMRTSS+nr/AKBOVCYo66Q7Kzjkk4wp8PZWgJ3YUAPFWOnh E4giKatJCtK7yCgCPcacPP8AELiLdmBhpjRK3i0gJ7wPOLx4qLq8n8ENSCISnUijNX9ULRqf eUyoSzKZhl2c2oam2yncpTas49XBznHQ+Rxn6e3nIX3RZirUhiabkETTks07MI2ekBGPqiOf iEkgZwcgggYiTwQmdSZBt/tC6WPPoaWgongEq5O5DJWk49hwQfOHNBATgRpbYq79XbqK5hmV bTLzr0s0qWmkzAcQggBSin4iuoKDyMRuoII5z7GsvLCj3a+hlCZz3SDa3Qn1i2E5SnPlkq49 sdGQRYXOSzaJhbkwylMv+vErADXAV63lwQefAxdbWhxtK21JWhQCkqScgg9CDA62h1O1xKVJ yDhQBGQcg/SMxVHPXa3l21PafzJSO9RVu7SrHICigkf7IjoWCCCCCCCCCCCCCNdcn7Har/JX f7BhDdieZU5YlclykbWahuB8TubT+aM3tVf7+05z+7afxoh+iEZ2vf2B27/0hlvyT0POOcNC n7fpdf1R99rsgxVk1V0zSp9SBulypXirqkqJzjg5T7IlfZYQ2mwaoqS740pVZmjIFzxYyAkg eHIPz5iQ9oX6y91/yUf20xtNHm3G9KLOS66XVGkyqgojGAWkkJ+YED5oU+k9Xo9C1r1U99E3 LSFVcmkrYfnnUt7pbco4SpWABgtHGeRt49WNz2Ym2Vy16z1KQpq3ZuvPLpqNuE7B1Un2Y2j/ AKuIvdrpAVozOKOconJdQwfHdj5+phvUn/gqT/iUf2RCV7UK3WntPHJYLL6bhZU2EDJKhjGB 55h6CIFr19Zy7f5Cr8YjK0XEwNJbP9LWFue5cvghOPU7sbB8ydoiZxHNRaHIXJZNZpdXf9Gk H5ZXezHH1EJ9bfz5EZ+aOWLno2oElo+4xP37b8xYzEuESymHt6poJ5bYQoN7ycgJ2k4G3BwB HQnZ5pczSNHbal51KkPLYU+UqGCkOLK0j6FCGNBHPlP/AOOZU/uQPybcdBwjNcbcnbn1Z03k ZGcnqYSJ1ZqEok7mNqEr4V0BO3HPnGutO16lbPaXlWajXapX+8t5bqZudSSptPelPd56YBBP h8f5zJNe5KanLj0v9Fl3Xg3csu44UJJCEghRJ8hgE/NDgAxBCc7WqEr0VqSjnKJmXUMHx7wD +8wyrLfTNWdQphCt6HZBhwK55BbSc88/TG5jmO8G5JHaYrjlXu+btKXNMYWiZYfSyZgAIBRu UCnGQTyD8WGTrZNy9d0HuB6hzKKq09LtpadlCHQ6e9RnGzjPXOOkc6VCx7pTNVjTKXcm3KBS 0OV9DvoyitxXowUhvjg5UduB9luMdVaLykxI6U2rLTrDkvMNyDQW04napJxnBHgfZE0hZ9pT 6yF0/wAU1+WbiQ6TKUrS60CtOw+5Epxuzx3KcHMSuCFNMo9P7TciZNwkUy3V+l4zhJcd9RBP TJzuwfAQ2YIDyIRejKVta76somVIW+X2FJUCokIO8pHPHAKR83HEPSCIBrnSbcqum9TF4uTD FLYKHjMSyCtxle4JStIAOeVc8dCYSFqyM5cutFnO06+H73lKOlyYmJpckWESLWMJSpeTvWs8 efGT446ugghH6Xf8Y3VP+BK/2BDwgi3MPNS7Dj8w4hplpJWtxaglKUgZJJPQAQlOyfU5KdtK 42JOaL7jdbmHlbvjFDgTsWf4W1X0GHfBEV1Y+tZeX3FnfyC4jXZn+sjbX8B38suGfBCP7XVB kJ/S12pOSiXKnIzDIlngn10hbgSpOepBz08wIblr0uVolu02l09kMSspLoZbb8QAkdfb4k+J jaQQodRkrRr7pU8SS2RUUbQMnPcHn5OYbwORkQQH2wnezW081IXyHm3WwbnnCgLSRxhHTPth xQQRz32Nf2K3R911f2Ex0JBHJnaMpldpmpLtOtxz/Jr9YYlXmVKJCn23EJyP2vGznnhS46op EixTKXKSEoCJeUZRLtBRyQlCQkZ+YRlwQgO1p+tWH92k/wB0P+CCCCCCCCCCCCCNdcn7Har/ ACV3+wY5t7GFcpVPtu45WfqMpKv+ltuhD7yWyUlGMjJ55Bh3XS1ZF0OUtdaqNJmF02aTOSp9 NQkocT06K5HmOhwPKN6LnoH7uUv77b/PCR7WVeo85Y9AblKrIzDjdcYdUhl9K1BAbdBVgEnA yPph1++y3Sz3vu9Se7KdwUZxsDGM56xA7ysvSq8qymr19ykPTxASt1qpd13qQMAL2LGfDnrw BnAiZ0msWlSKZLU+mVWiyslLNhtplubbCUJHQDmIVr7clCmdH7nYl61THX3JYJQ2iabUpSt6 eAAckxXpLqFaTGl9qsz90UOVmWKaww41Mz7TS0KQgIIKSoEfFjHvWX0YvadZnLmrNqzc2ynY h9NYbaWU5ztUUODcPLOcZOMZiS0q+9O6TKy1Lp10WxLSsu1hlpqfZS2hA4wDuxn2Zz4wsu1H e9rVbSiZkKTcVIqE67NMlDEpNofUQlWSSEE4GPE8Qyrd1Nst63aY8/ddvy7q5VpS2XKiylbZ KBlJBVkEHjGIw65f2l9RmJRdXuG3ZxdPfExLlb6He6dA4WnGRkZ4I/ujJd1k08aTuVdlNIyB 6qyo8nHQD8PhEF1k1YsWu6YXLS6VcktMTz8nhpptKwVkqGACUgeHI646xnaUav2RLaY23L1S 4JKRnJKntSr0u6ohaVNICOmOc7c8ecSxzWPT1ttS1XZTCEgk7VlR+YAZMaye1q0vn6S61N3L Kuyc0lcu40ph4KUkpIUCnZuAIyM4EJqlSXZ1p1baqKLgn30Mul5uTfbmVMJOcgY7oKIHHBUc 45zzDnGvemm3Pvoa4SFf70mOhP8AF9fZ1gZ180zeeQ0i6GwpRwCuUmEJ+clsAfKY2LmsmniE KUbsphCRk4WSfmAGTCGltUbRZ7Ts1dJqhNvv08SwnBLu4C+7T1Rt39U46ePlDj/VB6YfbN/3 Ca/w4P1QWmH2zf8AcJr/AAo8/VA6X5z75Rnpn3Pmv8KPf1QWmH2zdP8A0fNf4UH6oPTD7Zv+ 4TX+HB+qD0w+2b/uE1/hwt+0Lq7ZF3aXT9It6t+mVB15lSGvRH28hKwScrQB0HnEssTXbTqn WTb8jP3AWJuVp7DDzSpKYUULQ2lKhlKCDyD0MSZjXXTZ5xpCLplgXRlJWw8kD+ESgBPz4jAq l/6N1qcam6tP21PTbR7tt6blEuLRjkYUpBIGfEcRsqdqpphTJRMrTbhoknLJJIZl092gEnJO 0ADk8xfRrNp2tSgLrpvq9cqUPE9Mjnp/4zFuY1s05YYU8u65EoGchtLi1fzUpJPTyjHRrxpo suAXQz6gycyz48umUc9eg9vkYgmuer1i3FpZcNHo1famqjMNtpaZSw6N5DyScKKAOiSev4xG VpZrhp7R9ObcptVrYkp6Ukm2HmBJzC9qkjB5ShQOcZ4Pj4dIlP6oPTD7Zv8AuE1/hwfqg9Mf tm/7hNf4cYEnrXpBJ1KeqErWpdqfntnpMwimTIW9sGE7j3XOB0jP/VB6YfbN/wBwmv8ADg/V B6YfbN/3Ca/w4P1QemP2zf8AcJr/AA4V+nOrFn0vWHUKrT9bLFIqy5cyjpYdKXSgEE7QkkYz 1IHENH9UFpjnHvm/7hNf4cXX9etNGZjuV3Q0V8colJhaef8AWDZH4Yuta26azkss++eSLRV3 SkvNOIzn/VUgEjnrjEVU7VXTCRlyzT7hokqzuJ7tpPdpznrgJHl1jJRrLp4tORdlNx7VEfjE efDNp53vd++ym7tu7O5WMZx1xjPs6xV8MWnv220v+kP5oT2nepNoyWu+oFUm61Ls02ooZ9Fm nAQ24UABQBx9Hngw2H9b9OGHm2l3VJlSwVAobcWkYGTlSUkD5CefCK5XWvTqZb3t3XIJHH64 Ftn6FJBitesWnTgW0u6qWpJThQUokEHPHTBjBGsOltDlkty1wUxhg5Ibk5dah7fVbQcdYtHt BaYg/sm/7hNf4cH6oLTH7Zv+4TX+HGm1E1nsCraY3MzTbhZmJibp8xKMsBlxDi3FtqQn1VJB xlQ56RouzxqzZlJ0wpdFrVaYp1Rke8Q41MBQBBcUoKSrGDkKHGcjmGZ8MWnv220v+kP5oPhj 09+22l/0h/NHitYdPFDCrrpRHXlZ/NFQ1i09+22l/wBIfzR58MWnv220v+kP5oPhi09+22l/ 0h/NCv1F1VsxWrOnlVlq2xNSFNVOGbdYSpYZDrWxJOBk8+AyeIYruuOm7Msl9V0yndkAgIad Urn/AFQjI+jiPPh0029GL/vpltgSFY7l7dgkj4uzdnjpjI4z1EWZfXvTOYeQ0i52wpZwC5KT CE/OpTYA+cxbOv8Apihe0XInknJTIzGM/wBHB+qC0x+2b/uE1/hwfqgtMftmH3hM/wCHB+qC 0xzj3zD7wmf8OEx2ZtUrSsyj3FJ3NUzIqfn/AElhfcOuB1JTjgISSMbR1x8YQ5v1QemH2zf9 wmv8OD9UHpjz/wDib/uEz/hxDJ/ULR6c1El7znbtnpyfkmO6lJRUpM9yycEFSE90PWOfE4zz 5Ymf6oLTEf8AlNj/ANgmv8OMiS1206nnS1JV56YdA3bGqbNrOPPAajYjVuziwXhPz+wK2ke5 M5uzj9r3Wce3GITPaKvWhXV7ymqLMTTrjNYQpYekX5fg4HBcQkH5o6igggggggggggggjXXJ +x2q/wAkd/sGOZeyzpda9zWNO1m5aWzUX3ZxTDQdWrDaEJT0AI5JUfoENWtaW6T0VEqatQqT Jom30yrKnnVo7x1WdqE+t1ODGx+BPTnH7FJH+cv9KFR2m7EtS27IoKaHQZSQcfrbTS3mGsLK FNubklfXB2pOPZmG0xoxp3LuNuItSnkoxjeFLHzgkg/PEIuNrQa1q+KNWJGiMVFICFN+jOOh vd03qSClJ5zycgcxOZHTHTepyktPSNsUKYlXkh5p1llJQtJHBBHBH4Ih+umm9m0zSi4p+nW1 S5SdlmA408wwG1IVuSMgj5YzNHtNbKntLrXm5y3aTPzL8i267MPSqVLUtQ3KBJyTgkj5vDpG 9rtuaY27N0KSqtBt+VenpksSCFyKD3jp5xkJ+QZVxyB4iN2dN7JK0KNp0LKFKUn/ACFvqrr4 QrO1Jalu0vSScm6bQqXJzKJpgJelpRttYBXggFIB6QzaDYNot0Kmo969FVslmwO9kWlr+IBy rbyfM+MKu89QNF6JX3qJPWvJTy5dzu5l+SpDKmZdWdpClHaTjx2g+XXiGFRrA00uCkStTpVt 0KakZpvey81LJAUk/NweMEHkHIiO616fWjTtJLomKdblLlJhqW75DrEslC0rSQQQoDI8fpjI 0Js22ZvSO2Zmbt2jzEy9K73HXpNtxa1FSuSpQJMTz3jWl9q1B/q9n9GLU1ZdnsSzrz1rULu2 0lav83MngDP7WIrbM1prcFhG8Gbdo0nR0JcU6qcprKFNBBIUCACCeOME5yPHiIJT9SdO35sT E9puJC2Hnu4lq67R2jLrPHKvV9VOc9CrwyBzh8SlGoyZVoSlOp/o+wd2G2EbNvhtwMYi77jU z9zpL+gT+aEq5Iyg7W8uyJSXDQt4qCO6TgHcoZAx1xxnyh8wEgDJ4EeJUlQBSQQRkEHqIwq1 V6dQ5Bc9WZ6WkZNBAU9MOBtAJ6DJ8Ywbeu63bkedZoFbp1SdaSFuIlZhLhSknGSAeBG8hOdr RCVaK1MqSlRTMS5SSM7T3gGR5cE/TE503lZdWmNrMFhruTS5VRb2Dbnu0qzjp15+WNtVDR6X LuztUXISjJwhyYmNjaTngAqP4oxqKu2qvLCcoppE4wkgh6V7twJPUcp6RuVBBQVKUChQwScY I/8ABjR1qdtiiute7czR5Fx7epv0tTTZX0CiN2M9Rn5Yy6WKLUZBmYpfufNSR3htcuELbOfV VgjjnoYv+49M/c6T/oE/mhb9pGnSSdFrldEpLhxtlru1BpIKPqyMYOOOpjeaFtob0gtINNoQ FU9tRCEgAkjJPHiTzE6igtpLgWQCtIICsDIB6gH5h9EYKa1SvQn5wVOTMow6WHXu/TsbcCtp Qo5wFBWBg854jYwQHODjrCJ0dl2Tr7qvMNypaLbrKAotYwVbio58NxTu9vWHtAYsPyku+0G5 hlp1vOdi0AjPng+MYzdNpb7eWpSSca+L6rSCMgkY6eBz+GKzSaeUJQqRlChOdqSynAz1xxHn uPTP3Okv6BP5oPcim7ce58ntzkDuE4z9EIzSOnU09oTU4y8pJhthTIbCEpIQonKikY4O5OTj oYfwbABHgeowIx3KZIuud47Jyzjmc7lNJJz55xFv3HpnJNPkyTyT3CPzQSLtOeXNS0g7KrVL qDL7TJSe6OMhKgOnB6HzjLaZbZaS2ylLbaeEoQkAAewRbMnLqacbWw0ptwgrSWxhWPMY56D6 IiurMlLHSq8UlhopFHmlBPdjAKWFbT06jAx5YERLszUWmnRegOrkZZx17vnHFuNJUVK71Y64 8gIaPuPTP3Okv6BP5oPcemfudJf0CfzRGa1XtPqa8/J1io2zLOtna6w+4yFJJ8FJPyRthQ7a rcgw97m0eoSTiQ40v0dp1tQPRSTgj54zE0GkpBCaZIgEAHEujkdMdIplreo0qgol6TTmkk7i ESyEgk9TwOsKXUShU5XaA0wzTpcsOInQpPcI7tRQypSc+ZBwRkccEQ3xRqYB/wAHSf8AQJ/N HvuRTsAGnyhA5A7lPH4IPcemfudJ/wBAn80WJRujuTszJyiJIzUoUl5ptCNzW4ZTkY4yACPk jOalJdllbLTDTbS87kJQAk565HjFDtPk3ge+lZdzJ3He0k5OAM9OuAB8giuXlJeWSpMsw0yl RypLaAkH5cRzz2NJWWTRrsmUsNpmzUe6LoA3FsJyE+YAJJ+eOi1ICjkx6RkYzHiQEAJHAAwB 5QbATnOfDmBDaUFRSACo5UcdTjGT8wH0RVCA7Wn61Yf3aT/dD/gggggggggggggjXXJ+x2q/ yV3+wYRHYoadTYFadW5uZXUcIRk+qQ2nJ+fI+iJD2oBmh2Vn7aJP+y7DnhGdr39gdu/9IZb8 k9Dzjmbs4S9t1O0L6m7wTJO1V6efNXVOBIWlkpBJPikbi508R8kTvsquPuaOU8PF8sImX0yx e6lrvDjHszmN52g0lWjF1gAk+iZ49i0xn6LNJZ0ktBKAADS5deArdypAJ5wPEnjw6c4zED7S QT7u6YqwncLgaAJHOMpz+IQ74TXa3+svP/yqX/twzaE++9aFPmMJ9JXItuYb5G8tg8ezMcw6 E3BalH0zv6mXs5KsVZUzMKnJaZIbefbLYSEJyMlQWHBgAkE5xDM7IsvOMaPSypwq7p6bfclg rPDeQOPZuColuvf1nLt/kKvxiKNAPrNWn/Ix/aMMCMKt/wDAs/8Aydz+yY49mXZlvsayKJdS gy9WCiZwOrferUM+zelH4I6R1FlaRKaI1uWJbVSGaKtDJz6pSlrDePbkJx7cRnaPFZ0qtHvd xc9ypbdvzn9bHnEwhHvf8b1j/o4f7Zh4RgXAlxVBqSWUFbplnAhIcLe47Tgbhyn5fCID2a3C 7opbKlOFxQacTkqzgB1YA+YADEQ3tepmZijWdJScv6W7MVlCUSpPqvr2kJQR45KsfPDM02pK ZenmoTlmUu1qo5llTEmptwloHKcrQlI6+ETOE92svrJ1X+US/wCVTE+00+tzav3JlPyKYiev 9lVO9rXpkvRvQ3ZqRqDc56HOKKWpsJCgWyR7D9GeREFkVUyWpt+UM2R70LynbamHVS8s8Fys 00G1pCm9h2JIUrngH2nmMmsVBU52OEzDS1hYpDLRUF5PquJQrn5j+KIpqPT6o9rLYSUW7LXc 972mUrlZxQS08pKnd6yVZAIyDkgjkcGJh2aGqjJXJqFTalTkUUszzLwpLStzcqXEqV6hHGCn b08MQ+4WfaU+shdP8U1+WbjdaMoab0ntFMu53jfuXLnd/rFAKh8xyPmiZRg101IUecNCEoqq BpXowm93clzHq79vOM+UcJXpI3om4q1WnJKTFLRXW25tMgVe5rk8n/UUrJ9bIUo+KiMjIEd5 030s0+W90gwJ7u09/wBxnu+8x623PO3OcZjIghI6RzCzr3qyyMhtTkqogjklKVAH8J+mHdBA YjWnshbNKt4U+ylyyqVLPuoIYmC+Eu7iVgqKic5PiYksEEIvRJ/Otur7XcobUqcl1cccJLoz g885yT0+kQ9II1NduGl0KYpbNVmRLrqc0JOVykkLdIJCcjpnB6+OBC50XGNQdVuMH3ZR/YMN yCIrqx9ay8vuLO/kFxFOy+tatErf3rZXt74DuznA71fB/wBbzhqwRzxrvQreuG5pOyrcoNNV d9bdTNTtSTLp3yTAVlTq1gZ3KwRjxHypy9bbo0nbtBkaRS2g1JSTSWWk+OAOp8yTkk+JMbKC ExqCT+qT0uGePR5/j/1K4c8EELu1rqqU5rHeVszrMqJKRl5aZlXG0bVkKQMhZ+y5PXjGMQxI II5x7GS2DS7yQlGJkVFBWvzQUq2j5iF/THR0EJ3tMVitW9aMtVKFdKqK626WkyrculxyecVj ahJPKcAKJ8PwQwNPGK/L2XSW7vmkTVdDIM04lIThR5CTjgkAgEjqRmJFBCA7Wn61Yf3aT/dD /gggggggggggggjW3OpKLaqylkJSmUeJJOABsMJHsWfWzqf3UX+TbhuXxZ1NvKVprFWL4RIT zVQZLS9p7xvOAfMEKIMSQdOYRHbFWG9O6CtXATXpcknP+hf8uYerSw4gLScpUAQfZiFld2ht j3Vciq3Uqe83NuqC5hEs8Wm5g+awPE+JTgnqeYYtKp0pSabLSFNl2paTlkBtpltOEoSOgEQb tC/WXuvH/NR/bTF/Qb6ztpfyBH98SauW7Sq5NUyYqkm3MvUyYE1KKWSO6dAwFDBGfkOR0PhG 2hM9rf6y8/8AyqX/ALcMqxf2D299zpf8kmIbV9GbJuO55ytVmitOzanSVd3MrSl8lIO5xKSA FbiocdQATnMMmVl2ZSXbl5VltlhtIShttISlIHQADgCIbrc2h7SW7UOKwPc50/GA5AyOvtEY XZ5ebf0XtRbKwtIlSgkftkrUkj5iCPmhiZGAcjnpGPMpampV9hTg2uIUhRSRkAjBiCW3ptb1 K0u9404+KjTVpcDrjpSlalKWVbhj4pBxjywIiLGizszIS1EuK/qnVbUlHUrZpaghsqSn4qFu g7ikDHHA44xxh0SypOWl2mJdbLbLSAhCEqACUgYAHsxFz0lj/TN/zhCHqdSlJLtfU30h5CRN UP0dpW4YKyVqAJz47SB7SPOHx6Qx/pm/5wiiYcl3WXGlvIAWkpOFjPPBhJ0jRF6h05VNoWpd x0+mFwuJl5d1KNuTk4UCMZxzjAPlDUr1v0OvTFGfq6W5l2kzKZyVUp3G11IwFHHXzx0yBG79 IY/0zX84RZdqUm04ltyal0LUCUpU6kFQAySBnwHJhSdq+YZXorUwl5slUxLhIChz9UB4+YH6 InemM5KuabWqpuZZWn3Llk5SsEZDSQR8xBHzRb1DtKlXxS5WUnajNSL0pMJmpabkZjunmXAC MpPyEiNZZendItyfqFTnqrN3BWJ5r0Z6dqrwdV3H+iSOgSeMjxjUSmi1oSxRLmpVl6iIfMwm iPVNSpAK3bgO68QFc4JOfHMbW+dOqXdVfplbar1TotUp7Jl2n6ZMpa+pk52kEHzPTqDg54jN 07sml2Q3UVy9VnKlP1F4PTU9UJgOvu7RhIKvIDP0xMvSGP8ATN/zhC07ST7KtEroSHWyS00A Aoc/VkRn6Ez8o9o/apZmWV93IoaVhY9VaRhST5EGJimtUxa3kIqMkpxlQQ6kTCMtqPQK54J8 jFuYuGjSzoamatTmXScBDk0hJJzjoTFPupRJ9lxr0ymzLQAWtHfNrTjghRGenQ5ituvUlxCl N1OQUEbd22ZQdu74uefHw84ynp6VZbK3ZhhCR1KnAAPnMXDMsY/Xmv54hF6TVGV/VB6pNibZ w76OtADgwrYMKI88FWPnh6eksf6Zr+eIPSWP9M3/ADhAJhkkAOtkk4A3CNfRabR6Gw8xSJeS kmXXlPuIYSlAU4o+sogeP5o2HpLH+mb/AJwjxU0wBnvmv54izJVSQnme+kp6VmGSSA4y8lac +IyDCV0gqtPRrzqvKS7rIEw7LPJO8DKmwpLmAevrOcn88PH0lj/TNfzhB6Sx/pm/5wiN35al Bvijpp1dVltt1L7LrD3dusODotCvA8keMVWRbFDsymOSVHXnvnVPzExMO94/MOqOStxZ5UYk XpLH+mb/AJwg9JY/0zf84RGtTly8xptdbJmmGg5SZtG9axhOWVDJ+mIH2TpmXGi1MR3zW9Ex MBad4yk94o8+XBBhw+ksf6Zv+cI9S+yo4S62T7FCFHVNGqfMXlV7lk7xuClVKpLJdVJTSWyE HGWwcZxwMeWB5QzaFLJo9IlafMVN+fdl0bFTM24FOuHzUeMmM/v2cZ71vHTO4R56Qx/pm/5w hMaiT8vKdo3TF159lDS5eda3rWANym1JSM+ZUQB5k4hziYZP/Kt/zhHpmGQcF1sH2qEUqmGN p+rtj27xCv08o9bGql63VcUtLU6XnQ1JyDKZhDinWW8gOK2qOMgJODg8njjlo+ksf6Zv+cIP SGP9M3/OEeiYZJwHWyf4Qjn3sjqakpW9pAzjDhYq5SlIIyRgp358QdvHyHzjoH0hj/TN/wA4 Qeksf6Zv+cIXequmFB1ImqXM1SqTso9TwoNGUeQkesQcnIPOUjkRMrckpeh0aWpyapNz4YBH pM/Nd++5kk5Us9ev0YEbL0lj/TN/zhB6Sx/pm/5whB9rFxDjNibFpV/npPQg+UdAwQQQQQQQ QQQQQRrrk/Y7VP5K7/YMcvdluwGLksio1FdeuSluGeLJRTJ4y7awlCSCQAcn1jzDhc0hlEq3 rve+UpyCc1kjJ4AOdvzfPFwaQywyRet95JyT7sq5P82FN2mNOJahafM1IXLck+6ieabSzU58 zDatwUOEkDCh1z5ZHjwzqbo9Le48o09el7kBhCVBFXUhJ9UdAE8D2RRU9NKJIJQ3VNQrwlku /ETMV/u9+PLIGYvt6K0UqQo3LeLgHJzWV+v484H4sRF9bdMKLStK7hn5Ocryn5dgOJS9VX3k HC08KQpRBHyiLmjOl1Fqel1uT03P18vTEqHVBqqvtITuJOEoQoAAfJExc0ht0AE1G5EDI592 5nnnpyvx6R6rR+3FjCp24yPI1qZP/wAcKjtKaX0Kg6ZvVenuVVyblJhlKDNT7r6QhStpG1ai APW8OePLMS6z9CbMm7Ooz0wmrKffkWnFuCoOp9ZSASQkHaOTwMYil3QfTyg92/UZ6roRMPoZ 3P1EoDjiztQCUgZJPA+WN38Aljf83qn9Zv8A6URrUrQ6zKdYNwz8m1UkTUrIuPtrVPuuDKEl QylRIIz+OMHRbRi0q1pXQqjVpeben51ovuOtTjrQGVrwAlKsDAIB4525iZjQGwQlCfQKhhGM f5yf8sft/KNTcGlukNtz1JlapSfRpmrTHocqlMxMEuLPgcK4HIBJ45Ebo6B6bY4ttB/9pe/T jS2VprpHcT1Tdo1utuqpc67T5hL63SA6jg4ClYUOeDEs+BrTz7U6b/NV+eD4GtPPtTpv81X5 4TdS0+s5PafplvKo8szSVUkzCZJAIbeeAc+Nz5An/qiHA9opp06psqtWRT3atwCCtIPsODyP YYufA1p59qdN/mq/PAdG9OwCTalNAHiUq/PGHP6W6WU4tioUGhypczs79zZux1xlXPWKKfpn pRUn3WadRKDNvMgKcQw6HFIB6EgK4zgxn/A1p59qdN/mq/PCv7SWmtn27pRP1Kh0CTkZ5l9j Y8yCFAFYSR16YJiXadaP2JMWBbkxO25JTc0/T2HnX3QSpa1oCiTz5mNxP6VaX09tK5+36LKo UdqVPr2AnyBKoJDSjS+oJW5IW9RppKTtUple8A9cHCusEvpXpdMTTstL2/RHZhr9caQvctHy gKyIrnNJtMpFnvp23KPLs5xveOxOfLJVF1vR3Tl1tLjVq0taFAKSpIJBHmDmPTozp2SD706d xz0V+eIFrxphZdC0muGpUi3ZGUn5dttTTzYIUgl1AOOfImNppVpBZM1ptbU1VbckZqempBmZ dec3KUtTiQvJOf8AW6eEStWjenijk2nTPmQR/fFTWj2nzagU2lSiR+2a3eGPEwOaP6euBIVa dKGBgbWtufoPMXF6SWApKQbRo+Eq3DEuBzjHOOo9nSLJ0b08OM2nTOBjhB/PHqNHNPUKyLTp mfagn8ZhRaaad2lPa5ah0+coco/IUwseiSzgKmmt4yr1TwenjDcVo3p4pRJtOmZJzwgj++PP ga08+1Om/wA1X54vSekdhSU4xNStr05uYYcS62sJPqqScg9fMRaVo3p6pRUbTpuScn1T+ePP ga08+1Om/wA1X54Pga08+1Om/wA1X54Pga08+1Om/wA1X54T2lGm1p1jWDUqWmqNKzFJpTzU vLSzm7a0Vledo9ndkfPx1hxp0c09CVAWnTMKGDlBP0c8RT8DWnn2p03+ar88eHR3TpsZVatL SDx6yT4/PFC9I9NUPty67ZpCXlpUpDZ4WoDGSBnJAyPkzFz4GtPPtTpv81X54Pga08+1Om/z VfnjR33pJp/IWRcE4zasoh2Xp8w8hTCVd4FJbUoFPPXIiG9nDTaz7j0nptTrlAk52fdefC3n QSogOKA8fICGd8DWnn2p03+ar88eL0X07UBm1KeMftdw/EYiFeoWhtvVwUetSNBk6jtCiw4F 5SDgjcRwCQQQDEvGjOnZJULUpxz44Uf74staI6ctuuuC1pNRcOSFKWQPkBVgRdGi+nYQU+9S n4P8LP05hYXvppZktrhp7R5SgstSU63NuTcu2CG3Q20pSCec8KHPmIZrWiunTW/FqyB3KKju 3qx8mTwPZFz4GtPPtTpv81X54Do3p2ASbUpoA6kpV+eLElpLpnPSrUzJW3SJiWdTvbdaJWha fMEHBEX/AIGtPPtTpv8ANV+eLatFNOlTCHjasjuSkpCQVhJz5p3YJ9sV/Axp3uJ96dOyRjor 88I/sy6Z2nc0tdE/Wqcipsy9QMpKB/cNjaRuzgKwScp+THth4I0X07QCBadP5OeQo/jMe/A1 p59qdN/mq/PC/vKybUl77olo2vZNAXUZxoz01MzqXC0xLIVhWEpOVLUeBzx49chgDRrTw9bS po/6p/PB8DWnn2p03+ar88HwNaefanTf5qvzwnO0VY9s2mqynrcospT3n6uhDi2QQVJGDg8+ cdRwQQQQQQQQQQQQRrrk/Y7VP5K7/YMJDsWk/BnU+T/wmv8AJtxve1k6tnRufW0+4ysTUsU7 OqiHAcZ6jGM5HiBDcp5KpCWKiSotJJJOSeBCU7YjL7ulMqtggIaqrC3c+KdjiRj/AKykw6ZL /g6X/ik/iEc52PaFG1N1a1Lnb2lzUTTZ8yErLLfcSGmwpaAoBJBHqoGPaSevMTbs3vzLNGui hPTzk9KUOtPyEm64sqUGUgbU5Plz8nQcRINfXnJfRu7FsqCV+hlOSAeFKAPX2ExXoN9Z20v5 Aj++Iv2rlbNK0rS6ppaalKqRtzkncfEdPP5ocEv+sNnxKRk/NCl7V7CXtEaytTm0svSziRj4 x75CcfQon5oYdjfsJt/7ny/5NMKbti7E6VS7nelt9upMqawogk7V9PaOsPJsqU2krTsUQCU5 zg+URHWFCXNK7tSsZBpcxxnH2BjX6AfWatP+Rj+0YYEKDXpC/fHpg4G2y2m42klwj10kjgA+ Rwc/IIb8Jns2/wD9w+f/ACpm+P5sOaCOf6wwp7tkURaejFFU4rjPGx5P41COgI0d9UU3HZta o6HA27OyjjLbhz6iyk7VcEdFYPzRzdPX1M3jpDbFhofc99VTn00aoIU9l1ptlQ3uKx4EbevX 1+uDDl1vtCg1jTqtztVprM1OUmkzbkk8sncypLRUCCD5pSefKNP2X7co9P0sotYkqdLtVSfZ X6TNBOXHMOqABUfD1RwOOIcEJ7tZfWTqv8ol/wAqmJ7ppzpxav3JlPyKYRvaYkXZvVjT1LlF XXpJ5Lzaaal3Z6QpKgVgHwwCk5PHHPEM+i2dLNaa1eStOjqs2pVaWdSWyoFxl3CkJKlJKvDn IOQDkYMJ/T+lUbTiet5m/bMqdFrbU0WmbilJlbsvMuLVgJcKFYAUCfVI6Jz4mJS/Q5XUTtE3 JTrvZM3SLekWRISDiilBLiUKU4QD63JVz7U56Q47OtqmWlQmqRQ2XGJBlS1NtrdU4U7lEkZU ScDOB7BG7hZ9pT6yF0/xTX5ZuJDpMsL0ts8gKT/meUGFDB4ZSIlcam66pM0W3p2oSNMmarMs I3NyUtjvHjkDAz8uT7AcA9I5/wBM7+vGa1mu2WnLVqrrc05Ld9KKnARSUgYCvWwk7grcQME4 4ziOlUnIj2BXQ84hKaYMGX7Q+qqFKSolMkvI/wBZvdj8MOuCCNFQ0XCmvV1VZekl0lTrfuYl hBDiUbPX7w+e78XzRvYIIRuhH13tZPulL/2piHlBCc7WLi2dHZx1lxbbiJyWUlaCQQQ4CCCI i+hxqdb1dr9T1JamJe9JaVbVJSa/UaZlVghRaSCcjkA8nGTnKsx0WOkEaS+P2FXB9z5j8mqF 12TvrJUj+PmPyqocEEJDTaSlZntA6qvTDCXXmvQktlaAoJSpvKuo65SnHyQ7wAOkEEJnUAkd pPS/B/8Ay0/+RXDmgjBrzLkzQ6iwzjvXZZxCMqKeSkgcjkfLHLPZR1Ers/WqVZRcpzNGkZWY e9ZtXfvkqyEhWcZBVngfFCs54x1pBBCI7K0s3LN38lsDCa860Dj1sJ6ZPz/jh7wQo25gT3ai caWw60adbe1C1cB3e8CVD2DOPlBhuQQQgO1p+tWH92k/3Q/4IIIIIIIIIIIII19xYNv1MKJC fRXckDOPUMJrsby7bekzrqAd7tReK8nrhKAPwQxNWrMVf9kTlvonRImYW0vvy13m3YsKPGR1 A84lsu0GJdpoEqDaQnJ8cDEJDtiej/BXJ+kFYd91mO429N+xzOfZt3/PiHZT/wDeEt/FJ/EI VN66PzNRvZ26rOuictiqTaA3Pdw3vQ+MbSrG4YVjHmMgK4PMTXTmyabYVuIpNKU66FLLz8w8 cuPukDctR9uBx4Ri6y/Wou77mP8A9gxrOzu6XtFrUUopJEsUeqsKGEuKA5Hjx08OnhG31Qsl m/rbao8zOLlGkTbUypaEBRUEHlPPmCefD2xLUJCEhI6DgDyhSdqxIVofXCXg2UuyxCePqn1d A2/hzx+1hg2LzZFvfc6X/JJjV6oWNKag261RqjMuS8qmaamVltIKlBBOUjyyCRnwiXxDdZWe /wBKbtR6v/Bj59YZHCCf7o0/ZvnBO6JWs6lGzay4zjOfiOrRn59ufnhlRC7/ALI99latOfNQ VKooU/6apsI3B7AGB14OQOeeCYmnUcGIZpnZhsxmvoXMpmXKpVpipFaUFO0OEYSck8gDwiZw RzzcMx6N2yrd3ulpD1JLZyraF5bfwk+frAceYEdCBaSOFD6Y93J8x9MLehaTUSjaqVS92H1r mpxCu7llJAQw4v8AXHEkeJH0bldcjE5r9Nlq5QqjSZxahLT8s5KulCgFBC0lJwfPBMYll0CU tO1aZQpBwrl5FkNJWvAUs9So48SST88brcn9sPphOdrNxA0VqYK0gqmJcJBPU94DgfMD9ETf Sadl53TG1X5ZYU0aZLoBznlLYSofMQR80ajU3T6Yu+t29WKXcTtDqdFU8WXm2EvZ7wJB9VRA +x9ucxn2xbtyNU2sSV33aaymda7lpyVlUyTkukpKVKSpBJ3HOQfAjiInKaPzsxM0pi6L4qle oVLmEzUvT5hpCSpxHxO8dB3LAyeD+CN3fmnBuC45W5KBX5m3bjZZMqqblkJcS+yedq0E4JGe D8nXAxItP7YYs22WKOzPzU/3a1uLmZtze44taiok+XJ/8HMSJTiEpKlLSAOSSekLHtIzDC9E LnKXm1BTbSUkLHJ75HAiQ6UzkqrS601JmWFJbpEolag4CEkMpBBPygiJQ3OSzitrcwypXXCV gmAzcrvCPSGd5OAN4zmNVSqBSpCv1etyQHuhVu59Kc7wqCg2nCAB0HB+fMbpK0EApUnHsMe7 0/th9MeKUkggKGflhN6fvN/qkdUUF1srVLyBAB5ISwkHj2ZAMOXen9sPpg3p/bD6YN6f2w+m F/bNAuOR1YuysT9VLtuTzLAk5QvlYQsJAUQk8IxhXTru9kMDen9sPpg3p/bD6YN6f2w+mEho kWGNZtYWUzLTi1zss4ADg/8ALbhj/VKgknz+WHfvT+2H0x4FpIyFJIPtjRXpbFLvGimlVoLX Jl1t4pbXtJUhQUBny45i1VbWo8/d9FuOYJbrFNS62w424E94hxJSULH2QGSQPAxI9yf2w+mD en9sPpjQaguITYdyEvIaApsz66lYCfqSuYXPZLmmF6MU5pLrZcZmX0uJ3cpJcJAPygiHLvT+ 2H0x4HEEqAWklPBAPSFXV9LJtWpE9dtt3fNUN+oIbTNy7Uuh1LoQAD8Y452jwOCT54hqJUAO Vg/PHu9P7YfTBvT+2H0wktTJuXk+0bpc9NPtMtdzOI3uLCRlTakpGT5qIA8ycQ7AseJAPyx7 uT+2H0x4sJcbUkkFKhg4ML+39JbTt9y3XaWy81MUJx5yWe7313O9BCw4cesOeB4Y9pzPJl/u JZ11La31NoKw03jevAzhOSBk+0iK23UrQFZxkZweDFW5OfjD6YQvZZmkuTuozSXUKQmuLdAH korGc+IO38EPrcn9sPpg3p/bD6YVmoQet3U62ryNOmJykIlHqXUHpRtTzkuFqSptwtpySncC CQDjPngQ096f2w+mPCtA6qTz7Y93p/bD6YQHazILVhkEH/PSf7o6AgggggggggggggjXXJ+x 2q/yV3+wY5c7NFo3JXrDfmqPfs7RJNE8pHoUqwl3BCUlRO48E5GMccePg12dMrvbfeWvVevF CyClJlm8p5OeSSPLoB+atvTG7Gdy2NVbi3lJSC4w24kZ9h/+8LDtK2PcVO0+Zn6re8/W5Zme a3Ss0w22kFQUkLGwdRnGD4E/Ow6TpRc6KXJp+FK5EbWUDahKdo9UcDJziMr4Krn/AH1bn/mp /PANK7oBBGqtzfzUfniO6madXJIaeXDNTOpNfnWJeTeeXLOto2ujbkoUQc4IGPZn5c6TQrT+ vVrSuh1CS1ArtJlnu+KJKUCe7aAeWkgZPiQT88MWX0trYebMxqbd62Ru3pQ62hSuuMEpOMcZ 4OcHp4XGtMKr3ag5qReinNxwpMw0AE+AI2Hn2558hCw7Sdiz1F0xXUHLzuWqIZmGkuytReQ4 04VHAICUpwQeed398S+yNHUKs6iupvm9pcOSLS+5lqghtpG5AJShOw4AzwMmNkrR9ho/V9Rr 7QFqw3uqyE56cco5OYyG9GWQ4nfft/OJByUGrAA/Q2DEa1U0kp0hp9cdQRcV1TMxLyLrqUzl UW62raM7VJxyOOka/RzRqgVfTahVVVTuGUmJ5gPPIk6gppsqyRkJA9kTP4C6D+793f1sv80Y dR0VtGWDSKjcdytibcTLIS9WCA8s5wgZHJPOBFiuaSWVbNJM5WLruSm09rDYcdrKkIHgEjj6 AIwra0809utTot+96/Uly/rLSzW1KUjPGSMZA8MxIPgMoP7v3d/W6/zQfAXQf3fu7+tl/mhN 1zTSintL0K1Zmaq03TXpH0lxcxOKW8VJQ6oJDnUJygdPbDlXoBYJRtRJVBvnOU1F/wA8nqo9 f74rOglgDrTp7+spj9OA6CWABk0+ex90pj9OPDoLYAOPc+e/rKY/Tj34BLAz/wAHT39ZTH6c HwB2B+509/WUx+nC87Q+ldm2vpVUKnR6W5Lz7D7PdPGZddI3OAEELWRjBP4IkWmuh9lTtiW3 P1Gmzbk5MSTMy8TOvJS4taQs5Sle3HPQY4iT/ATp9jAorw9Upz6fMePj8fqPOBWhenxbS2KO +nzUmfmApXynfz/9IBoZp4lwK9xHeE7dpnpjB9pG/r7Y9RoZp42gBVDcX7Vz0wT9O+PE6E6e Bso9xHTn7Iz8xkceB3x78BWnnAVQlqABGFTr5Byc8jfzEB120fsi39LK3V6NRzJz0mlDjKkT LpSCXEJOUlRSeCfCN7pvorYU9p3bk3PUJMxNTtOl5l91b7gK1rbCznCgMZUfDwESH4CNOB8W 2mknplMw8D/bgToRpunkW0znz9Id/Ti4jQ7TtCnCi3WxvGCBMvAD5PX4jxOhuniUFIt8Yxj/ AH2/xz4evxB8Bunn7gH79mP8SD4DtPEnIoJBHIPpsxx//EhWWdpRZ9Q14v2lzdOceptMZlVy rBmncIU80lSyVBW48kgZPj8mGevQnT1a93uK8njG1M/MAdMft4F6E6eqdQsUV5AT1QmfmAlX yjfHi9CNPV4/zM+kAknbPzAznwPr9PKLatC9PEMqSulzAClBIWqozGQeMAEri6NCtPgcmivH 4vWfmPD/AK/j4+cXVaHaeKOTb/OAOJx8f/HHg0N08BB9wD9+zH+JCe0k0utatar6lSdQp5dp tImUS8rLd+4nYFrWc7goKOO7xyT1hwfAbp54UAj/ANtmP04BoZp2AALfwBwAJyY/TgOhunY/ /oB+/Zj9OPDoVp0pQUbeSojoTNvkj5Dvj06GaeEg+4Khg54nZjn5fXj34DdPP3AP37Mf4kam 7tFbAlLTrUwxQtrzMk84hXpb52qSgkHBWRwQIg/Zz0ps65tLZGrVykmbn5h97e6ZhxHCVlKQ AlQHAH0kwzvgN08/cA/fsx/iRSNC9OwokW9gnqROPjPy+vzHitDNOyUn3BUkg9ROzGT7Pj9I r+A3Tz9wD9+zH+JFtGhOnqXVrNFfUlXRCp+YKU/IN8XPgN08/cA/fsx/iQsL90ksxjWLT+jS 1JdZp1TTN+ltpmnCHQ00VoGSoqHPXBGRDNd0M09cQoe4biCr7JE9MAj5DvjxOhWnyXkuCjP7 h4e6Exjrn9vFa9EbELHdN0ybZRv3kNVGZTk/Mv8A8YjX0vRfTOfSZmnya5xhDi2lBFUfcbC0 kpUk4X1BGMeBEXxoLYSTlEhUE/JU5j9OPUaC2AlYUaZOKA+xVUpgj+3FxrQnT5tBBoz6yfsl z8wVD5Dv4hQdn/Si1LkVeK6xKzEymRqy5KWCZt1ra2jOMlChuJyOT5Q2joJYGR/m2eH/AO5T HP8AtwDQTT/n/Nk6Qf8A0lMfpxqra040nuCq1mUpFNeemaQ/6HOI9LmUpbc5yBleD0IyPKN4 vQvT1f8A/Q3E8EerPTA6+Px+sWpjQbT55QUKTMtY8G6hMAfL8eKPgDsD9zp7+spj9OEx2ibA t6wJuzZ+gsTLLbk+Q+l2cW9kJKFAhKyT58gj588ddJUFJCh0IyI9ggggggggggggjW3OoItq rKOcCUdJwMn4h8ISPYs+tnU/uov8m3Ew7SlWqFD0jqlQo07MSM809L7H5dwoWnLyMjI8COCP EcQxaRM+m0mSms579hDucYzuSD/fCi7XGfgcmdoyfTZf+1DdpJUqmShc+MWUZ4xztEKPtYVe p0XS1EzR6hMyEwaiwkuyzhbXtwtWNwII5SD80N+mzCpunSsytISp5pDhA6AkAxFdZvrT3d9z H/7BiPdl/wCsXbHyTP8A7y7C3t+xFaz3Nelbuiu1SX9zqo7TKexJOBCJcN9FYIOeqeBgkgkn nhk9nC56hc2ni/diZcnJ6lzz1NcmnB6zwQEqSo+Z2rSMnk45yeYxe1Yha9D64pOcIcllKxjp 36Bzn2kdOfmzDAsX9hFvfc6X/JJjne07Vkta9Rb/AJ68ZqfWzSpr0CnsMu92JdG5xKSOoyAg HyJJJzDB7MlSqrtq1ih1p8zblvVJ2mtTe4qDqEHoFHqAcgezESvW9vvNJLtAWpH+bXjlJAPA zjn5MRj6AfWatP8AkY/tGGBCg7TU0mRtO3JxSCsS9wyTuB1O0qOB9EbjVe06FWahRK/eVTaY t+glx9+TmQO4fWoAIK89cEY24O7OPHlb6bycnemtcreljUJdEtWnyzstMTGwS6Kg4UqSkIbT xgZSTn9oM4OI6Pgjnqvf8c62/uSv8lMR0LHi/in5I5A0lrKrxuB1m4NU7tkbgfqCm5amyrjn drTyeOFNgcHjAAx4w0O1RclTt+27eYp1am6OxPVBLM5OyuQ8hoDJKSkg8dcAjOMRvNCpSnTF Omq3Rb3uW55J9RlwmrvqWlpSeThKwCDyORxgw1ITXa3eQ1ovPoXnLs1LoTgZ53hXPlwkwwtN Prc2r9yZT8imJHHO/azuKdpE3Zsk1WajSaXNzDnp70g4pDpaBQlXxSN2EqV6p4JjdUiQmpTR muVnTa57nuObnpQCSNTmC8totqKVdyhSQUqwVcc5KU49un0HnaPOVyRUi/7onriTJrFSoNYe cI77jeUpWAMpIPAKjjy5joaCFn2lPrIXT/FNflm43+kL6JnSq0HGs7RSZVHIxylpKT+EGJbB BBBARkYMJywVAdpHVFJI3GWpxA8SAwj84hxwRBtY7+GnNmuVr3Odn3S6lhttJ2oSpQOFLVg4 Tx85IHjEQ03td++2qPfN7V1uuvnZOU+nSitklT1fGwUg+u6knBKuQRg5xmHRBBCT0Sl1y2se saHPjGelHB8iu/UPwEQ7IIVmt7zrVW037lxxsquaXSdiiMgoWCOPDENOCCNJfP7Crg+58x+T VC67J31kqR/HzH5VUOCCE3edTqWnurVOrs5UZx6zbh2yM4y6suNSEyBhtac/ESrxxx8Yn7GH IDmCCFBqE49+qE0sbKf8n7uoKCsfZejqyM/JiG/BAYUfZ5l0SvwhMtZ2IumbAyc/Ytw3III5 47HanWqXeck+0UOMVXKtyhu3FJBBHUY29fHPsMdDwQluzm0hdZ1PnQoF1+5plKihe5BCVEgp OOfjnnx4h0wQRzN21XViWspoK+pqmn1FOzOSA2Ad3h8Y8eOfZHSzH6w3/BH4orgggggggggg ggjUXi4lq0a4444ppCZF9SnEjJQA2rkD2QluxZ9bOp/dRf5NuGZrDZz1+WBUbflZtuUfmC2t DriSpIKFhWCBzzjGYlsgwiVkZeXbCAhltLYCE7UgAY4HgOISfbHS6dJGS1nYmpsFwg9E7XB5 jxKfP5PEOK3TmgU094tzMq166xhSvUHJHnEK16sWe1DsQUalTUrLTaZtuYSqZKghQTuBGUgk cKz0PTHjkT+QlxKSMtLJUVhltLYUeM4AGfwRFNZfrT3d9zH/AOwYj3Zf+sXbHyTP/vLsaWo6 bXpQrtrs9ptcNMp9Mr7wfnWJ5olcu4c7lsgJIJ9Ynnb4A9AYY2m9nSVi2nK0SQdW/sKnH5lw YW+6o5Us9evl4ADrEO7VAzoZcJyn1VSx5HP++G+nt/uzE8sX9hFvfc6X/JJhZ3PpNX5e9alc OnV1e99dY/4SYca7xBJ6uIH7bOTzggk4IziJ7pnZMhYNqsUWmOLeCVKdemHBhb7qvjLPl0AA 8AB1jC1vQpzSS7EIb7wmnOnbtJ6D2eXWMfQD6zVp/wAjH9owwIWPaBoFVuG06UxQ6f7oTEvV 5WZWxuAyhJIOc+HIz7I03aRtG6Ltk7bRbdOaq8nJzvpM7TXJhLIfxjaFFSkgpxvTwcjdxG4s Os38upyNMrOnkjb1CQhSVPy9RZcSyAklKUtIPQqwPYDDPgjni4lhHbNtoq8aUoD52n46Hilw EtqAOCRjOM4iD6SWAxYlrsSL/ok1Ug6689ONS4QpwrWSOevCcDr4RXqTYyLzn7VeedZ7ikVJ M66w83vS+gA5T8ucdeOuYmjDLUu0lphtDTaeEoQkJA+QCK4TvaySFaKVQ4yUzEuRx0+qpiea XrK9NbUUoJB9ypXhKtw/Wk+MSaIZeFiMXNeVpV2Ymy2mgvOvej93kPFSRt5z6uFBJ8c9OOsb +6ZeqTVvzzFvzzUhVVt4l5l1vvEIXkdU+IPT54V0rZV73HeFtVe/V25Lt0FxTqHqR3pmJpeM BJUoDa31JAPPTHOQ5YIXfaGlxM6L3W2pYQBKhzJPilaVY+fGPnjJ0JdQ7o9aSmlpWkSDaSUn PI4I+YgiJ3BC8uOi3c7q9a9VpNSfRbDUs83UpYuDus4O31MgqUolPPO3Z8xYcEEJaxX0I7T+ pUuUZcdkpFxK/IJZaBHz7h9EOmCLcwy3MMuMvNocacG1aFpCkqB6gg9RECoOl1Pti7/dm1Kh O0iTeWpU5SGlBUm+SkjIQfiEHByOmMDAMMGCCE3pGpHw2awBs5BmJDxzz3bufww5IIhWqlie /wApdNYaq0zSJynzqJ6WmpdIUpC0gjpkefn1EXbMty5aPUX37gvKYrzCmQ22wuRalwhQPx8o 5Jxx88TCCI9qM4lnT253VrU2lFLmlFacZSA0rkZ4zEA7J/1kqR/HzH5VUOCCNPd1uU67LenK LWme+kJpO1aQcKBByFJPgQQCDGykZZEnJsSzRWW2W0tpK1FSsAADJPJPHUxeghS6lvIY1v0o W6oISXKgjJOBlUvtA+ckCG14QQGIBppZ9TtS4b1fnZuWfp1YqXp8ohoq3t7gd+8EAA/FHBPx Yn8EEIfstPNel6iyqG9rjVecWSEgDaoqAA+Tar6YfEELbQizKnZdsVJm4O4NWn6k9OvqZVuS d2AMH5s9B1hkwQRzf20gPca0Vd4oET6xszwfVHOPZ/efOOjZf9Yb/gj8UVwQQQQQQQQQQQRq bteEtalZfUFKDck8shIyThtR4HnHLfZclr+nLTqSbRq9DkaWicPeCdl1PO97sT0Ax6pGOp8D xDUm6Vre5L92Lls2WeWcBaJdwqHjxuQQfHwjFat/XdK0k3jargBBKVS3Bx54ZHX+/jELTtC0 nVKVsMvXtW6LUKMJ5BLUiztWlRCtpyW0+qOU9c8jOYn9rULWx+0qUGrrt6VQ4w2Ud5KBbrLW 0bRnu9qjjg5HgOeY2cjb2t4eWmcvS2gypG0LTI71IOOoT3aRnx5OPZ4Rtm6Fq0lSQq77bWgA gqVSlZV06gKHt6f/AGj2pNC1NGndw+n3TQpiURIuqfbaphQt1sJJUkK3EAkZ5x9HWIxoLb+p M3pPS3beu+n0ylvOurlmXpBMw42kOKCk7jxhSgo4wSPAjOIYcxberbrjSk35RWQjOUoo6SF8 +O4k/RiLQtLV1b2ValU9psnJDdEZVt+QEc/TC+16oGo0jpTVHrmvaQqVLbUz30s3TkMLmMvI CRuA+xVg4GOAcxLbHtHVF61KKsalMSUsqRYU0yKKy+ptJQCEFSiCrAwM+MbtyxtTFhIOrZG0 g+rbsuPPyX7YxVac6kKOTq/M/NQ2h/8AMiHap2XqTStP7lnJ7Uh2qyDMtlUoKchpT7RwHAog kowCemcgc4jH0Ps6861pPTKlSdRqhTG5hLiZaT9DQ62wG3Vt7cqOSDszxjGfHETBrSq/0Ntp VrBVlFn1mj7nD42R8fLp3jAPB8/mNyY0tuRouzM/q3crbCU71KBS0lJ8STuwE9eMcRYn9OKr TpNM1UdYrilZXcMvvzCG2yDnaAoqxnp8vlFqmWLMVV5TVL1qrs66kblIlp1t1QHmQlRjZL0k uLYrbqpdoVjglYIB+TMWpjSi7w2kU/Vm42XArKlTDIeB+Qb046ecKCtWBc8p2hbVpE/etQnq pNyhmU1ZLex1hCQ7uQkFRGPUV/O6Q7JnS65plxS3dUrnClAA90ltsceQTgCK5HSury7m+a1M vR4pIKdkyhI6+IUlQPjBMaWT4WFtalXy2wMbg5PIUTzzhWwAZGMcce2MtWlry1EnUO/sk84q TQH4GotL0rmu/b2ajX6GwDvSai2Srywe748fA59kVM6WTSSSvUW/VEKJGKi2BjPAILRz/f5Q qe0nZFSoenT88/elyVaSRMsoRJTykOJySeVqSE5wScEjyHkYl+l+mNTcsGhOzV+3bLtzEgy6 iWkJptttgKTuCU7kKOACBxjp8wkstphUmHd6dRr3UMYIXNNK53Zz6zZHTjp+aMs6eVKZk0tT 2ol4rcBypcs7Ly4PXHRnPT28xitab1lt9J+Em7jLNE92krZKsHGQpRQd54OCRxkY6HNxzTOc PdY1DvoIbJV/v1nJycnJ7rkcdDkDwjxzS91tlSl6iX+EJyon3RbJ6fxOfmihjSyYUjcrUa/V BRykpqLafV8M5a6/+MRCNatNZ+Q02r861fd1zjEvLd65KVKcS408AoEg4Sn5h54jC0T04qNX 0ooc9JX5dFK9JS4tMtKPgMNDvVDCUkZHQnr1MTRGktfC0lzVK8FIByQl4An54vnSiql9wp1L vcMlBCEGbRuCvAlW3kezAz5iBelVXCkKY1MvVJCee8mULBXng42j1fZznzjJGm9fRKy6Eal3 V6Q26XFuKDCkrBzxtKM+PiSBjgDjHjunNwFhSGdSrpQ44QXFrSwoE+O0bAUDpwD5+ceNadXW 02lCNUK+UpGBulWFH5yU5MKS3bHrL/aRuaR9+lYam5WQbfdqLJQH5hKkNDYpONgAyMDH2Kce cONGm1QAlyvUO9lONHkiZYCVDGBkd1z4dc/hihrTSprbUib1FvRe/wCMWZhlrxGMfUyR08Ou flzde05qPcdw1qHeqW1KysqmJdSyPJK+5Ck/T80eSmmM1LuIdGod9qcSPs59laScftVMkfTm PHdMZqYdW69qHfYWo9G55ltOPD1UtYjHmNKZwoHo+o9+IVnkrqDawR8gbEXZbS2aaSgr1Fvx boThR90GtpOOSElo4/DCg0nsN+r6salNG7rmkzTZluXVMyk0hExM71OYLqygg47vwA6+HSHB 8Fb374l//wBZt/4UCtLHlKKjqHf+Sc8VJof/ACotp0xmWzsVqNfY7zIwqoNZI64GWuD7R7Yq TpbMKSN+ol/ZHHFRaHGTj/kuTz1i81plMtvB1OoV9lQ8FT7Kk9MfFLOPwRbOlbxOfhEv/wDr Nv8Awo0t6aXPNWfXF+/693gmRfKmpmfbcbcAQcpUnuxkEcHkdYhfZusKYrOl8rUReV001ExM PFMrTZpDTTe1eOikK5JTkkY64x1yz16WvrWVHUO/sk54qTQH0BqPFaWPqOTqHf2fZUmh/wDK jW1Sx6fSVtIquq94yS3c92mZrbDRXjrjc2M9R9MZTelk2p4r+Ee/FS6kjalNQbznz3d3gj5o rTpVNhsbtRr9K93JFRbAxnpju+uOM568+yLw0xmmlNqa1DvvKVZ9efZWD58Fr8eYVOq1g1t/ V7TyRavCsTXpTrq2JicU2XJQsgOLUgIQlJJSOMjqADkQ0J3TGquLW5J6kXoypwEOB2YacGCR 8UBCQnjPI8xjpzSnTW4kJStvU26PSUnAUtLKm9mMAFBTyr/Wzz5Z5jMa07qraFKGot4F/csp JclykBSs4KS1yQOOvHgAOIttWBceXBMak3KtCgQkNsyyCn5T3Zz82ItOaaVp4Ope1Ju/YUnY GnGWylfmSEcp6erx8sY81pbXHnVFvU670M8kILre4H+EEjI6cY8/OKXNLK+tQ2an3alKRsGV oPq+GcAZPX1uvTyhPdniyZ6tV6+GvffcFORIz4ZdVTngyuaXucHeLJCufVP0nmHYdK5kFX+6 Jf5GPV/zk3x//C5i3LaXVRieS8nUi9i2kZShc00v1sDrlBSRnPG3xHlkw626PUpu9KnQRqJf dNq0t3nctVNltSJtpKsF5kkFK09PI89BzErRpjciFpWjVC6A4ElCt6WlJI/gkYB9vWPPgvub uu7+FK5tuEjOxvd6vTnr8vn45ipemNzrIKtUrl4wBtbaHT5Bz0hI9pu0ajasnbtXqd1VS4Xv TFhtufSjY1wlR2gcDO1ORjHEdeSDpmJGXeKdpcbSvHlkZi/BBBBBBBBBBBBGjvx16Xse4XpV BXMN06YW2lIyVKDSiAPnhJdidebAraOfVqWfjZ6to8M8dPIROu0dclXtTTCbqlvTXok+iYZQ HglCilKlYOAoEc9OhPMTazZ1yq2rRanNBYmZyRYfdChtwpSAo+qDgHJPSFR2v5VtekTr+XEr bnmD6iykLzkesBwr2Z6GGzau4WjRygZV6CzgZxk92IX2vly1a15G0pukTCWJh6uMMOkoCwtt SVbkEEdCPLB8iIbERbVRTKdM7rMwMte5cyCMePdKx+HERXswA/AbbHORtmP/AHl2Iw9O3rqX qJdMhbdzuW1RLcdTKpLTKXFzExhWSrODtBTyCcYxxyTEy0QuysXHRqxI3T3Sq9Q6i7T5p1lI Sh0p6KAHHmOMdPbGo7WCWTolWC6sJWl6XLQxncrvkjHs9UqPzQxLG/YTb/3Ol/yaYhevd2Ve 0aLb83Q5hLDkxWZeXfy2lfeNHcVI5BwDjqOfIwz4ierf1r7r+5kx+TMaDs2ty7WiNrJlFlbZ ZcUSTn1y8srHzKKh80MuFt2jgFaLXQClxX1BBwg4I+qI5PPTziqh2zRbu0StWRuKnqqkl7ky T4aK1IcUtLCcEFKgQo5I+N44JxHOmnIp1va/USo1S1alZFGd71iQZm0zA7xwpKE71ucnO/nH qjKQeMmO0oI51vgPSnbBsx5tziYkMYx0TtfSRz8nhHRUaW96s7QbMr1Xl20OPSEg/NIQv4ql IbUoA+zIhO6U2HV7io1Bvmp3xX/dudeTPvIafxLLZ3Z7gt8DBAAPgOQB0MQ/W2qSa9eHqdcl RuY0RNLQUS1CWQtCzkncnoRjcSevI8BE97K0/P1G2K28X6g9byagpuke6DwdfQ0ByknyHq9O M5xDvhOdrQrGitS2AEGZlwrJ6DvB0+fETPR15yY0ptJx5W5ZpcuCcAdGwB09giYRz5eUi1fe qN5Uy76tVKfadsU9iY9DknVoD+Ud6p5SQk78YUMAE8DHjE70tnpSsaYOsWfdczWnGg9Ly9Qq CCXmHCMoS4FAE7NyeSOQOOIRtm0WQtq4aI5qAbutu9vdELcrS3C5Jz+XM9yXASNqk7Uq+fJx xHXR5gAxEG1zSlej93BaQoe57pwR4gZH4Y1vZtAGiNrbTkdy5zjH/LLhlwQtZvVlmVqtSkTZ t7zBkn1MF+Wo6nG14+yBB6HqPMYPjE7oFTTWaNKVFEpOSaZhG8MTrJaeb9i0HoYz4IS1rS7b ParvRxtxS1P0WXccBGNivqKcDz4SD88OmCFZrlqVUNOWqO/JSdNmWJxbjbnpcwptQUACkJCQ eOTlR4GOcZi/pDqJNXm9Ps1J23e/YQlxDdLni+vaSc7gQMY9UZBPPlxDMgghF6ElPww6x5A3 e6LGD/1n/wD6Q9II5q7Xs3V5K4NP5i31THuhLuTky0lnJO5sMqztHXA3Z9mfCIhc+oruoesO ndSovpTVFkZ+nsuA5QETLzoLiDzz6o28dQD4GOxII0l8/sKuD7nzH5NULrsnfWSpH8fMflVQ 4IIhep9kUK7KDOu1WkSs7UJeSeTKOujCm1FJIwodOQDGm7NE29O6H2u7MLK1pbeaBP7VD7iE j5kpA+aGbBCm1JcS1rjpSpe7BXUU+qkq5MvgdPaevh1MNkHIyII5/u/WO7JW5r0YtqjUqYo9 rJQZpycWtLq84CtuDjruwPJOepxEg0v1KuOsXTJUK8qPJSUxU6UmsSLsmtRHdE42uJVyFdT1 9kOCCCOfuyw4o3Bqc2T6iaxuA9pW7n8QjoGCFFqzUpW29U9N67Ut6ZDvJunrcQncUreQkIyO uM//AGhug5ggjnztfyzc3TbLYewW3auGlJ8SFJwcf+PGOgWW0MtIaaSEtoSEpSOgA6CKoIII IIIIIIIIIjWpyijTW7FJ+MKRNkcZ/wCRXCS7EX7ELj/lyPyYhkdoi3andOlNVpdDlDOVBa2X G2QQFEJcSVYzxnAMTCyqWaJZ1Dpa0bFyciywtOc4UlAB58eQeYV3a+UoaOPhKNwM8wFHONoy efbzgfPDWtL9ilF/kTP5NMQTXi0qxd8hbDFCl0PKk60xNTBW4lAbaGQpfPXGegyfIGGhEN1l +tPd33Mf/sGI92X/AKxdsfJMf+8uxGZu1tQLD1HuCtaf0ySr1IuFffTEtMzIZVLPDPrEqUMj KlHjORxxgGJ1o3ZE3ZdBn/dibZnK3VZ1yoTzrIOwOLx6iSeSkY6nxJjSdqplLuh1fWoJJZXL LGQeD6Q2njnyUfP++J9YpzZFvY/c6X/JJiK612XUb4pdBkaW7LtGVqzM4+t5RG1pIVuIAHJ5 6cfLDGERLVv6112fcyY/JmIz2X1rc0LthTilKIEynKjngTLoA+YACGnEM1lpE9X9MbhpVIlz Mz81LbGWgoJKjuBxkkDw8TGmrdOvO39IqDI2WZZdwUiVlG3mHAFJmENNhLjaSeMkgc8cA4IO IXNxzF/6uzVCo0zY79sSFPqDVQmp6ddUrlAUB3eUpz8ZXAz1HIGTHSQOQDgjPgfCCOe9Riod rbT7aSP83EHHl/lMdCRiVeny1WpU5Tp9sOSk2yth5B+yQoFKh9BMJm3tJ7zoDcnQaffq2bQl Zv0ltDUvsm9m7d3W8cbSrrzg8nGPVhiyFlS8pqTVbx9KWuZnpNuSDBQAltKSCSD45wI807sm WseWq0pTpla5CcqDk8xLlASmVSsD6knH2II4/wDBiWwnu1l9ZOq/x8v+VTEx0e7v4KrS7oYR 7mS/iT9gM9fbEwhbXnp3UZ+82bqtC5FW/WVMCUmyZUTLUy2CCNyCQMjz9g6dY2un9jG1LfqU nMVaZqFSqkw7Nz1R2hpbjzgwVJSCQjAAx1iGfA/cU+9ISdzaiT9Yt6UfQ96A5JIS46G1bkBT 24knOMnHIHh4OeCIPrj9aC7vuc7+KNb2b9nwJ2t3e7b3Dmd3n3q8/NnMMqCCCCCErauP1Vl6 bX0uH3Fl8oCcd2fqPqnzP2Wf9bEOqCMadp8nP916dKS8z3St7ffNpXsVgjIyODgkZ9seysjK ShUZWVYYKsbi22E5x0ziMiCCEhoa33esGsid6F5qEqrKDkcl84+UZwfaId8ERy4LOpNwXFRK zUkOOTNID4l0BWEHvkBC9w8eBxEct3Ry1KFRqdTpZiZcbkKqmsMuOO+v36fibiANyUjAAPl7 TDGgjSXx+wq4PufMfk1Quuyf9ZKkfx8x+VVDgzBES1DoFxXDJsS1t3Qm30YcTMq9BTMqeCkg AAlQ249Y8c5I6Y5ytOrUl7HsumW7JvuTLMkhQ75wAFalLUtRwOg3KOB4DziRwQodTkqc1x0p SHiwkOTyu8SoZOGc7ORjCsbT488Q3gMDEELyb0qpL8ne7Im5tDl1qC5lzKT3JA4CBjpkk8xs qfp/TZG7KRX2piaVNUykJo7KFKGwtg5C1YGSrqPLnpExgghD9mNtpdd1OnGdjQery0iXT/ya QpwjnyO4j/qw+IIT1wVGnXRr9Z9Op62aiq32Z2ZnwhW9Eq4pIQgK8AsKB46g4PEOGDIgjnTt kB5dNsxmXQ4VrqStq0kDCtoAHXOTnj5PDiOiWgQ0gKzu2jOTnmKoIIIIIIIIIIII0GoKHHLC uVDDCZh5VMmQhlXRxRaVhJ5HXp1Ecr9lqfvyVotdRZlIpM/Il9CnVzz5aKXAg+qnHXIx4fPD jbrOuIlnA5bFoqmCfUWmaWEpHtTvJP0iMRVT18IX/mCzAVdDvcynjw+q/jzC57QE7qtM6dPI valW3J0YTLRWuQUsulWTtHrOK4z7InFs1XXL3uUhMhb9oeieiNBpTy3AvZtG0qAd4OMZH/2j fNTWui05XIWC2c9FGZP4lxX6Rrj/AM00/Hyma/TiPajnWF6wa+isM2QimqkHjNGV9IDqW9p3 bNytucdMxH+z2/qq5plIottm1k0RpTwk11VD/er+qEqA7tQG3eV4J8j7IZbjesziwkzFgNAc 7kszZzz0wVHjHMY78nrXMOrDdUseWQDuSpph854xtwrPHGflPXHRea8SGqcvpXWV3RV7bm6N uY9Jbk2Fodx3yNu0kAfH2Z9g+nf6fUzWNVi0AyFbtiWlDJNdwzMyyy6hvaNgUQnGduI3/uVr b9sdn/erv6MXpej6yqJ9Jui1W044Lci4sk/PiInqvQdV5ayrhm5u96ZMUtuRWX5RmmoaLiOd 6Qogker47vo6xBtE7S1Qq2nslN2feUrSaOt10NyrqDlJCyFHPdngnPjE7Fga4gg/CPT/AOYf 8KN1IWZrKmVQJnU6RbdGcpRSWXR1/bKQCfoi+bN1fH/90pT+o5f9GNZK2/rJNzU6xL6pUN0y q+7WGqewtaFYzhxIa9Q4wccxnsWfrMrf3+p0gjB9XZR2FZHmcoGPwx5MWfrOltZl9Tae44Mb EuUdhAPnkhBx9BhOag0G+mterMp9Xu1mbr7zbSpSpsySG/Rkd4vOW0pAXghZ54IPOBD0VZWq ASdurWVYOAbclQM+Hj0ildkaoLcKTq1hkp6i3pYKzn2Hp7cxX7yNTf33Ff8AZuV/Sj33k6nf vuH/ALNSv6UHvJ1O/fcP/ZqV/SgFkalhRWrVpZISQNtuyoGTjkjPPSFp2hLUvSl6XT81cOob 1bkG32iZIUhmWDilOADK0KzgE5x04Eb/AEos/UOZ03t1+n6mKp0m7KIcZlDRGJnuUHlKe8Wd ysAjr06eESpuxtTUJwNXFdSebclldTnqVRizNuajM1aUp6tWHg/MtrWhSLVYU2AgJzuXkhJO QQCRnnHSMz3k6nfvuH/s1K/pQGytTgggatAqPIPvblv0ooRZeqRS3u1ZSFfZ4t2WIHHhzzzj yjxFl6pFSt+rKUp3Hbi3ZYkjAxnng5zEP1ZtbUWS0ur81WdSmp6WbliZiT9yGJdLyNwykOp9 YEjwxyePGLeh1n33MaYUCZpOoj1IpzyFuNyBorD5aSXFcBxZyQfjDjHMTj3k6nfvuH/s3K/p Qe8nU799w/8AZqV/Sg95Op377h/7NSv6UZDVm6hBtwO6qTKllI2FNBk0hJxySMHIzjjI/vil uzNRQEd5qs+ojO7bb8oM9MY648fPPsil2zNRy20GtV3kuAfVFKt6UUFH2DjH0mFNb9tXm/2i LnkJPUAtVqXprSpuqe5LR75JS1tb7gnYMAp5B8PMmGuuy9SiAEasrSR1KrclTn5OflgNl6lE rxqy4Bj1c25K8Hjrzz4+UeCz9RZdK3ZzVxXcpSSSLelEbTjgkkkYB6/jEXJOzdRUPgzmqz7z WOUM2/KNqz8p3D8EX2bOv0TGXtUZ1bOT6qKHJpV7PWKT08eOfZFmWszUVMwFTWqz7jHOUN2/ KIV7PWOR+CM1u0L03r36mVIpz6oFIkgQPae7OfwQl9JLYuyb1c1HTT74ekXpOZQ3PTLciy4Z 1alOFCi2obEEbVdBxkgcEw1k2VqWFpK9WllGeQLclQcfLmLpsvUElRVqpNZCgW8UKUAT4HcP suM+XOD4RRL2Be60EVLVSqvL42mVpkvLgAeY9bJ56xfXp9dKykq1Or/qgJG2Vl08D5Ecn2xb Xp3dPG3U64Qc85lmDx/Nir4O7n/fOuH73l/0Y1F3af3KzadadXqVX3UIknlKbUwyAsBBODhI OD04IMLfs22Vc9Z08bn6bfFUoUiqecCZRhhDiFIAAUUlR4JV44IGDwcmHCqwrsLfdHU2ud2A NuJKWCupPKtmT1jD94OoAeddTqvPbnEKSQaNLlIJPBCc4HHlg+0QIsbUxCUhOri8JGButyWJ +clXJ9pioWRqaAANXD/2blf0oPeTqd++4f8As1K/pQe8nU799w/9mpX9KFlqpat5jVDT2VmL 4fqE3MzTxkphVKYbVI7QlSl7UYS5wM8gDiGg5ZepCkt9zqw4khOFlVuyigpXmORgezn5Yo95 Op377h/7NSv6UHvJ1O/fcP8A2alf0os+8bU9EyVt6tKIWPqhVQJc4wONqc4Ht6fPF73k6nfv uH/s1K/pQe8nU799w/8AZqV/Sj33lam4A+FrxySLblcn/ahOdn61r1napfC6HeaqOlqoGXmJ hVNbmjNvJUvK8LPqkZzx+39kONFlampWlStWQsAglKrblsH2HCsxW9Zupbjzi06qttoUTtbT bcvtR8mVk8e0mPW7HvmWRMinX3SpByZWXXnZW2GkrcWeq1ZdIUonnJEUC09UWi0EamSj6Uq3 qU7b7KSv/UISrG32jBi23a+q6XphStQ6WpDhOwGiI+pfwcEf7RMVyltarMtpS7fdGfUlJ9dy ipBUeSCdqgPIcDp4Ewmu0dIXzJyNpO3dX6VNpNQw0iSlSz3TmBhW48kYz5fP4dbNZ7pGVbjg ZV5+2KoIIIIIIIIIIII0d9znufY9wzuzf6NTph7ZnG7a0o4/BCJ7EX7ELj/lyPyYh/3JXqbb VFmqtW5kStPlkhTrxQpe0EgDhIJPJHQRl06dlqlT5aekHkPyky2l5l1BylaFDKVD2EEQlO2N JNzOkiJha3AuVqDLiAlWEqJCk8jx4Uf/ABmG3ZuPejRAlO0CRY9Xy+pp4jVar3W9ZFgVa4Za VRNvSSWyllatqVbnEo5Ps3Z+aN9b1STWaBTao22WkTss1MpQo5KQtAVg/JmNBq8lhWll2Cb7 zufcyYJ7vr8Q4/DiIp2WX++0Rt9PdqR3SphGT9l9XWcj6cfNG07QVVqFF0nrE/Rp9ynz7a2A 2+2fWG59CSB7SCRE+kELbkmEOuKdcS2kKcVjcs4GVHHGTCo7V0s4/ojWXG5lxlLD0s4tCMYe SXkJ2K9mVBXyoETPSdSl6YWopSipRpcvyTn/AJMQparVLw1W1Ar9PsS51W/Q7d2yq3kjKpmY JUFHA525SoA9MJz48TjQS76tdNrz8vc6kqr9GnnadOLQgJC1IPCsAAZ6g48s+Mb/AFdMsNMb pM8y49L+5r+5Dadyj6hxj5Dg+zGYhHZI+svIfyqY/tmHLCc7UK3mbMoD0ooomm69KKaUDyFD djrx1x1jL1+1Hcs+js0SgoemLsrYLFPaZTlTZUQnvPlycJHir2Awkux6/MN6sV6WefmVldKc dmEvFQKng8zkqSeqgVKGTzyfMx2LBHNOsylI7VOnJQopPcy44PgX3QY6Wih9ZbZWsJKilJVt T1OPARzdYeo2qN8ImqzQfe68xJzwYdoKsNzKmSRlRKj6uAcA5AJCuCRgze/rwuyoagt2Lp/6 FJ1BmVE9PVKdG9DSD0QlODk8p5wevhgmNlpLd9bqdUr1rXkiXFx0JaO9mJYbWptpwEocSCBj 28Y5HyQy4T3ay+snVf5RL/lUxLdFvrS2j9zGP7AiaQjNZb9uCkam27a9IuCk23JTUsqafqFQ bSpGRvwlRVwB6nHIyT16CN7pPqNPXPcVxUCeepNVdpLbbqKpR1H0eZC8+rhRICh04UQcHyhU 2vqPqVedSnZ2h3FQZeflp/uWbUmA025MNDlWFLAUrA4OFZ9VR44B6sgiCa7Ibc0eu1LqULSK e4oBQBGRyD8oIBHtix2fJv0zRi1HSnbtlO6xnPxFqRn59uYYUEEEEEJ+2PR2O07ebbLTZdma NKvuuZypKk7UbR5Ap2Ej/VEOCCNdcNGkbhos3SavLJmZCbR3bzSiQFJ69RyDwCCPGFoql3Xp ZITL9BmFXRarCC6qn1CZDc3JITyrunjwtAGfUVgjAx45ndg3bTb4teUrtGL3okxuGx5G1aFJ OFJUORkEeBIiQwQktEZdyW1i1jQ6AFGflHBg54V36h+AiHbBCI7QWrFd08vG2pakMMvyDrS5 mcYUjKnkhWCAfscAE5Hz8CJZa19v3Dql6BITDb1uzNusVaWGwBYWt0jJPXOOCk9CPlhlwRpL 5/YTcH3PmPyaoXPZN+snSvWJ/wAomOD4fVVcQ4Y8Jx1hSXNqvU3LonKDp5bT1zzlKJVVHO9D LTIH2CFH4y854/1TgK5xMdOb4pd90EVClqW282rupuTdGHZV0dULHzHB8fpAlcEJPWs41g0j 5x/l73/y4dg6cQRHb8vCk2Nbj9arzjqZRpSUBLSNy3FK6JSPM4PUgcRotM9WbZ1FXNs0Jc01 NyqQ45LTbQQ5sJxvGCQRnHjxkZ6iJ/BBCF7Lale6WpCSpO0V1ZCMDIOV8nnODgdRjg4zzh9E 4GYWdzayUKlVuZotIkKzclXljtflqNKF/uleIUrpkc5xnBGDyDF60NXber1VTR6g1ULery/i U6ssGXcc5wNhPBJ8BnJ544hjA58D88WVzLKH0srcQl5QKkoKhuUB1IHXEXo5u7ZhX6NZKNoS yqfcK31HIbOEYBT45BUehxt9sdHMY7lvBBG0cgYB4iuCCCCCCCCCCCCI7qOwua08uiXZALr1 Kmm0AnAyWVAcwj+xF+xC4/5cj8mIaWvdJn65pNcFOo8o5OTzzSO7ZaGVLw4knA8TgHiJNZNL XRLNoNKdBDkjIMSysnPKG0pPPzQrO2A6lvR11KgolyeYQMJJAPrHnyHB588ecNOySDZtBIUV gyEuQpXU/U08mIt2gKPPXDpFcNNo0s5OT7iWi2w18ZW15CiAPE7QTiJHp/KzMjY1uyk+0pmb l6bLNPNnqhaWkgj5QRGLquAdMbrBYMwPcuY+pg4z9TV+Lr80QvspMLZ0SoqlgYedmHE/J3yh /cY2HaLtar3hpu5TKA13076Yw73YUEkpCsEjOBxnd83niGRItKYk2WVrK1NoSgrPVRAAzCw7 Uf1ibm/9l/8AemolGkn1rrT+5cv+TEJhVKv3SW/7qnLRtk3HRLidMwyG1YMu6SpQCwMkBJWo eAUMcg5wzNC7MqNoW1Nu3E931wViaXUagUkFKHF/YjHGfPHGSccRs9a5n0PSW7Hijf8A5udR jOPjJ2/3xD+yR9ZeQ/lUx/bMOWFF2mqZOVezKLJ0+XdfeXXJUYbQVbQdwycdBkjmMvU7Reh6 gXAzXJ6o1WQqLEuJdC5NxIGASUnBSTkFR6EQptDNL6za3aAq3up6c7KU2VddbqHdkNzandqU hROQSUqWojJOUeyOq4I521uGO0VparHVxIzhPP1Xz+N4+PHl4x0TFLmQglIyrHAzjJjlS82J 25hMMymldZomoxmh3FUpxLUsMKGXVPgpByM9QfA7vCJzdjV0WHqYxecrSJu4qZUaY1IVRqQR l5t5H/KJRj4pwMc+KskcRutH6LXJ+6Lhv665FVMnKylEvJ09R9aXlUAbd/8ArHA688HgZwG1 Ce7WX1k6r/KJf8qmJDoBMGZ0btNZJyJMI5Vu+Kop/u+aGBCevfTj34a20WqVmmNTltStJcQ7 3pylT29W1BGc59fd5eqYy9G7Dm7ArN6STUqyiiTU43M0x4LBUtJSrLavsgEHAGfMkeMKS96X c13mepc9pE3LXcuY+pXBT3Sywk7wQ4VYwfVA5KjyScA8R1Db8vNylCp0vU5kTU+zLNNzEwBg OuBAClge0gn542EQTXZsOaPXakkjEg4rI9nP90a7s1/WQtfIx9Sd/LOQzIIiNwVe5pW/bbpt KozUxb82l1VQqCycsFKSUgYOBk465znHGMxLoIITFsIdT2qrwLjLTaFUSXLakHlxOWhuV7cg p+RIhzwRgXBNzUjRZ2ap0guozjLSlsyiHA2XlgcI3HgZPjCtp+n1xXu6J3VufSZQOJcYt2nO lMq3jkd8ocuKB/1iPaQcBtSMpLyEo1KyTDMvLNJ2tssoCEIT5ADgCL8EJnSd5Kdc9XWVqT3i 3ZBaQM8pDax+DcIc0GR5wtLrsqoVnWa17hAljRqfIzDEyl05LhWFJCAjxBCvHjAMRPRPSerW Fqhc9QdW1733GlMU87wpS0KcCwMdU7cYPTJ5HEPeCMGtttv0eeadOG3GHErOM8FJzCa7HPGk K/uk9/ZRDzyPOI7f9Iq1etiZptArJos6+pCTOobK1tt7hv2gEYUU5GfxdR7Yto0mybeZpFDZ 7thHrLcXy484fjOLPio/mAwBGindN2G9QZK7rdqCqNOk7amyyyFNVFvyWnIAX/r8+eMxPh5Q Qk9bGyrV3SNRQSgVB7kjIz9TI+eHZBC07QtrVS8tNJukUGWTMVBcwwtCFLSgYCxk5UQBgZPy ZizbliTtH1n9325eVRRhbbdMBaUAUvJcb424zjajr80NGCCOauxiorRfLi3Ctap1kqKiST+u ck+Ocx0jMtd/LuslSkBxBRuScEZGMg+cR7T+y6TYlus0eiNq7pBKnHncF19ZOStagBk/iHEX 7ytKi3lSHKdcEi1NS6gQhSkjvGifskK6pV05ELlu09V7ZxIWlddGqtHQAGPfA256QykdE720 nf8AKcdOgiQ2HYk/T7imrpvCrprN0TEumVS60z3TEowDnumk+OVEkqPXyHJLDjmXtqvpS3ZD H1TvFzMwtOCNuE90Dnxz6wx88dLsfrDf8EfiiuCCCCCCCCCCCCNdcn7Hap/JXf7BjkLsyXlX 7YoFebo1nT9xSqphtxxyUXsLSikjB4O7gA4A48esOaY1Q1CabwNJKkXVJC0ATyVJxk9SEHBw OnXPzRgfC9qKpza3pDU8FRSN0yochRSee6x1B58uenML7Xy9r5rlgTlOuOwXqJIommVOTvpH eoT1KU8DBySBnOB06mJtYV+6kS9l0FmT0wcnZRuRaS1MiqIb75AQAle0jKcjBwYkC7+1JbmF 9xpI9sUQVE1dkEnAB6DHh9Ai4b/1LWzhrSd4PZHx6wyE4xz4ecaW8b41Im7NuBmc0wMnKqpz 6Xn1VdpfdpKSlSgkJyrAJOOvERbs83Vf8rplKSdBspms0yWfeSxOOVJEtuBWVKSEqBJwoq56 c48DDI9+eqe5sfBhL+uMk+7jXq8ePqxc99+qX72Up/XrX6MLvXy5b/ndKq1K3DY0vS6W8thL s41U0PlkB5Ck5QBk5UkJz/rCN7prc2pspp9brElYEpPSrcm0GplVWbaLrWPVOzHqkpxEm9+G qX72Up/XrX6MesXdqk6tCTprJtblbdzlcbwnnGThJOIhWplX1gnrMr8lULOoTVMVKuiZfami 4QztO4oG8HIHPTw6RGOz/cGpcnpzLy1n2nTqjSW5h0JmZmaDalqJyoY3DgE4zDHYurWt1D6j YdDaLRwErnhlzn7HC/x4jxu6NbZmmekM2RQGXVJ9Vt6bO8HOOU7x8uMiMiVuHWp5CyuzLcYK R0cnj63yYUfwxrl3Jr07tWxZtstJKSSl14qUCCfJ4deMQSte1+fe2LtW0WBgne44vb8nD5P4 IJiva/tKITatoujJGUOKx8vL4hO6lVLUh/WSzHq9TaRLXSlDKqfKypKmTl5WO8ytXO7OcK6A Q+mF64AKUtuwsrIVsUmZ9TgcDCufE856/MLynNbAfVa0/UMDPqzY+X7OPO91u/0On30Tf6UV b9a9vxNPwdufiTfXPT4/zxQga2KaCFqsJJykFYbmST5n42PweMe79bUoQAiwFnaMkpmhz/Oh Z9oL4UPgxqBu0WmKOZhku+5oeDw9YBIG84xuxnx5jYaGN6rs6ZUf3v8AvRVR1JcXK+6QfLwS Vq4PdkDBVn28xPS5rZhOG9PySOcpm+Of4fyRZl1a4Jb9duwiVHdhaZn1c+AwroI8WrXBxY+p 2CgJUDlKZkhYx0OVdPki8PhsaQkJVYTxUCpW9uaGwkn1RhXIAwM/j6x4XNbiCO60/GfHbN/p RelxrP6K4XVWCl1I9VPdTZ3nHiQsAfREF1mmdWmtMa+u4BZzVKLKUTJp4mO/2KWlJCd6innO DnwzHugrWqI0spHuK9aaKUQsygqTMwp7YXFZ3FtQGM5I4ziGApGsW1vD9gEn4w7ic9Xj+Hzz xGMpWtQcbCU6flKgNytk36vnxv5gDmtXc7i3YBcz8XbNjj+d45/B7YuqmNY1NAIkrFbcJxuU 9NKCenOMDPjxmATGsZASZGxkqIx3nfzRAPntx09mfni+fhcclUY94rT+QFbkzSwR4kcjHnjJ hO2wvUl7tH3KhmYt33eap7SZzvEOqk0s7WlJSgZ3g5Uk9epVDjLer2OJuws/yac/xIO61d/5 3YX3rOf4kY9QmNU6dJPTlQqmnkrKMp3OPPMTSEIHmVFzAEaS0bnv24/Sk0G7NOKutpZW4ltq YKmkk8DCVg7fAEg58zEh7jV3vN3pth4wBt9Fm8D2/rmf/tFXdau/87sL71nP8SDutXf+d2F9 6zf+JCZ0x+EWZ1vv92mzFtpqjZS3UFTDTqpZRCsN92EkLHCT1PnnJhxPM6wHu9k3YZwsbh6N Njj51mMd+Q1jVLLQ3V7JS4eUrEpMZHs5JGPm8IviV1eDwX7o2MUgAbPRJnHjz8fOTkePgPbm 0/IawuzSXU1mymkBJBZRJvlCj5klRVkew44ixM0rWZ59S27jtGXQejbck6Up+Tdk/SYx1ULW ouBXvutgJCcFHoKsE5HPxc58OuOY9rNJ1iepVVQa1aCg+w4lKG5Z5Cm8pxhCs8H2qzjMKLsu y+o0xbFQXaNUojVCRNLbLFUaU5tfKEEqRswocFPVW3OeOsNinUzXBicmVTFctCZZUAhtL0sv ajqCtOxKTnocKJEbNTGsjTr625uxHU7E922ZeaSN3OQPXyPDkk/NFuYk9ZUtPrZqdkrdUUqS 2JV8BGOqUknofbk+REZbaNYCfXmLBSMDpLzh5/nxi41pRLpcSqwFvKV6zZamhsHsO7mKA7rb kAs6fjJHOJvgfzoU2uDmo8vfunaqs/bpqJngKaKcl5DZfLjYw6FqJKeUjgjgmHAtWsyDlKbB WAM7QibGfW+Lndxxzn8EWw/rSE4MpYRVzyFzQHs8fl+X2QNv60hSe8lbCUBncEqmk58scnH4 YupmtYtozTbGJxyfSZkf/DHpm9YgCfcyxzjwE1M8/wCzFLk9rEjG2j2W5n9rNzAx9Iiwmq6y FeDbdpADx9Od5hE9m2r30iqXaLQo9Ine+eQ9N+mOqaQ05uXtCCDz1Vx7Bz5vNNX1nCRutm0y rHJE64AfwxX7sax92R717V35GFenrxjnIx59PGPPdfWXP7GLU+/nI8frWsnfHubTtjuyrjNQ Udoyep4zjjoItIrus6nX0G0rYSGsYWZ5WHMjPq8+HTnHMWm7h1qW24o2XbiCgAhKp85XnwGF fjxCR7UFVvqeZt2SvWjUmnNLdeXKmSe70uKGwKySeAApPl19nHY9KbW1S5Nt3HeIZQlWOmQk ZjKggggggggggggjU3e4tm0626033riJF9SW9wTvIbVgZPAz5niEV2JpcosWuvlSSl2oBIA6 ja2nr9MPO8J9ykWnWalLtd89KSbz6GzyFKSgkAjy4iO6IXE/dmllCrM5Ly8vMTCHErblkbGw UOrbylPhnZnHtjRdqVSUaF3GCcFZlkj5fSWj/cYmemmz4O7Z7sEI9zZfGev62mI1r5fVR0+s dusUdiXemVTrUuQ+CUhJ3KPQjqE4+eGQhaXEJW2oKQoZSpJyCPMRHNS1BOnV0lW4j3Lmvigk /rSvLmIT2V5dMvojQFBRJfVMukHwPfrTj/Zjda83JU7R0tq9boTyGKhLKYDa1oCwAp5CTweO ijE2pby5mmSj7uO8dZQtWOmSkEws+1Lu+Aq5NoGMy2cnw9Ja6fgiVaSfWutP7mS/5MRoO0Fe VVsXT81mhFgTYm2WvqyNw2kkqGPbjHyE+MMuI9qIsN2Fci1DKU0yZJG3dn6krwhcdkVe7RmT G1Q2TcwMkYB9bOR5jn8Bh0Qtde7mrVo2fJ1G3FIbfVUpdl5a2u8SG1E5B8gTgZ688YMRbtQ3 zWLRp9uStErBpDlQmlCYmUMhxSGUgAnBB4BVnA5OBiMnQq4DWaxUnHdUEXcAztbkTICTWjBG XNigFEAYHHHrHPOIdUEcya3stzHai05beG5BaliRnHSYdIjpuNfcVVl6FQKlVpwOGVkJdyad DYBUUISVHAOMnAMKWy9ZqvcEzSpmbsaqSlvVea9Fkqky4HvWzjLiAAUpz9l04VjODG71k1Rm NM2JGadt16qU6ZUW1TSJpLQbc5IQU7SeQCc9IZrSiptKlJUhRAJSrGU+w4yPoiqE72syRorU 8DI9Il884x9UH/0jednb6ytq/wAmV+UXDGiL0u7pefv6tWshh5MzS5ZiYceURsX3mTgDrwMc +2MeRv8ApE7PXdKtCbS7bBHpyS0DuSUFYUjBOQdqhzg5ELS0NZ7vud6WqshYLr9pPToklTMv Mh2YbJIBWUDnAyCfVx/rQ+4IWfaU+shdP8U1+Wbi52clJVopapSpah6OsZV1yHV5HyDw9kMi CI9f91SNlWlUq7Uj9RlG9yW88uuHhCB7SrA9nU8CL1kVSerVoUip1aTEjPTcsh52XGfqZUM4 55+Yxu4IRdk/8bTUL7ly35OWh6QRD9XaXRqrp3WmrmE2qkMMGbmBKHDpS19Uwn+b48fJ1he9 nqgu1KdnL+cpsjRZKoyiZCmU2TTgIlkL4W4fslkpAz14z4iHlBBCI0KZCtZ9YXtytyJ9lATn 1SFLeJJHn6vHymHvBEB1nv8AVp7azdQlpL06ozcwiUk5ckhK3VZPrY5xgHp1OBEZpN7XvbN1 UCl6lytF9DuB5TEpM0xasyz/ABtZcCuDknGRnnxMOSCMapOBqnzS1ZwlpZOPYkwhexR9bOr/ AHXc/Isx0HBBBBBCJ7QDrKdUNIUPsBwGsAhQzuB7xkD5skH5oew6cwR4tQQkqUQEgZJJwAIi VqakWhdlSmafb1dlp2dl929pIUkkJOCpO4Denn4ycj2xLoII5m7FqU7b4VjkzTAz/Sx0BelZ VbtoVqtIZD66fJuzQaKtoWUIKsE+GcQmbf1hvKUtGmXbeFt082rNrCHJunvHvmEqXtS4ppRO U54wDnx+XNubVK7JjVepWPZlPoZdk2Wn/TKk+sJWlSG1qPq+Xejjk4ST7Ik9zX9UbEtCiz97 SUu7Pzc+1IuqpLmWBv3nckuYPCUZIwOSMHqQyk9Bzn2x7HNnbOal3mLIbU42ibXPOpbKzgBB De4k+AB2ZjpBkYZbGQfVHI6GK4IIIIIIIIIIII016Bs2dXQ+lamjIP7w2MqKe7VnA8TCK7Ej pVZNwNEeqmoBQOT4tp/NDvvelLq1l3BTmkl52cknmkIVyCotkAAZHjjx6xE+znSKlQtIKDIV qUdk5xvv1Fh1JStCVPLUNw8CQc/IYxe1H9Ym5v8A2X/3pqJtp86H7Et11O3C6dLkBKSkD6mn gAxAu0/bdXunTRMhb8g7PziZ9l0stY3bQFAnn+EIbaBhIGAnAxgdBEa1PbU7ptdSEr7smlzP reX1JXtEQTsnAjRSk5OcvzGOen1VUbjtFUWpXBpDW6bRJN2dn3lMFthoZUra+hRx8gBMT6jt rapMk06gocQwhKknwISMiFj2qHkN6GXClROXVSyE4BPPpDaufLhJ6xK9IlJVpbaZQpKh7mS4 yk5H62IivaZt2rXVpp7mW/IuTs6ueYUG2yB6uSCTk4wMjJ8IazSA00htOdqQEjPkIhutE2qR 0pup9DanFCnuo2pBPxk7c8A8DOYh3ZI+svIfyqY/tmHLCc7VHffBxJd0Fd0KvKl0joE7jjPs 3bY2es0/ZlLqFsTV+UNydlfSilmoFrezJr4I73n4qsdMH4p44hWVqaoVx9o+x39M0Ssw9Kp7 2pzNPQENd1nCtxGASEFQPnuSnrwOo4I5i1yfRLdqHTp1zO0Nyo6jxmXR4/LHTuRGpu16Ul7W rD1RknKhJNybqn5RtvvFPthB3ICfEkZGPbHKNt3DRKNWrTXo7cVwOOT1RSzM2xPguNttKz3i +PVGMA9VHnORgxO+2pUJRqxqLILeb9MdqAeQwTypCUKCjx4ZUkfPHQsu82+yh5lxLjTiQtCk 9FJIyCPmi5CY7XJc+Bmc7t1DaTNsb0qTnvBu+KPI5wfmMSHs7fWVtX+TK/KKhjRzxdlwy+mv aNm7huZt1qgVmkoZbm22lOd2tG0YIHP2HgD8ZPtxutFGZucrGpF5P0qbbpVdmW1SUs81h2Yb aQ5k7FY4VvAGfHIhQ1adtyWDTujnvtol6TE8jdQChxKAArB7xPKcZAPKiACQQBnHZcELPtJ/ WRun+Ka/LNx72bONEbWz/oXfyzkMuCEheEu/qVrZIWwts+9m1Aio1LOdsxMrALTRHQ8HPPh3 nsh3gYGII8V8U+cImxwVdrXUFRVnbTJceqeP1uW6+2HvBGFW0uro0+mWlGZ18sOBuWeUEtvq 2nCFEggJUeCcHgxhWZLPydrUqXm6bLUt9qWQhclLK3NMED4iT4gRuoIIRWhLqE6x6xNFQDiq gwpKc8kBT4J/CPph65ghVdom2qzXrTp09bLff1Sh1BqptS23cXtmfVSPEjIOPHGIh03Xqrq9 fFksU6261SKTRJ5urVGZqDPdpDiPWS2kH43KSnPX1s4AEdDQRqrmUZa3qvMJecaKJR1feJG4 t4QfWCfEjrjxhIdihSTprWUBSd4q6yU55ALLWDj5j9EdCRob0qFdptJQ9a9Cbrc+p0IMu5OJ lQhBSr19ygc4ISNvGc9eIhbV4amolwXNLmVuDhW24mRk+JAKDgfPGwpF03/NVaWl6lpw3IyS 3EpemhXmXe6QTyoICAVY8oYQORBkecI/XJ1LOrukSluJbBqTiMqGRlRbAHyknA9ph4DpBGkv mmTNasm4KXIKQmbnqfMSzJWrakLW2pKcnwGSI5z0xoNRm6np3TZC05+h1O2H3nq1UZiX7kLS rjYlfV3eCePAeYyY6nggjmLsXTCQ/fEthXeekML6cYy6IfGp0jNVTTm55CnsqfnJmmzDLLSe q1qbUAB8pMc6S1brt0aL0jTWj2fVm6y62iVm35qVUzLSzaHQe8KiBycAnyOepxnW3vaFLk9d 6uLvt6v1S2hT5VuXdp8u4pSlol2WwrKMD7BYPtiadomZVd2h1InrcpFVTLSdVaWuWflFtOst oadRkpIztypIyMjn5YZVh6sWvds5KUqkPTnuitjf3Lso6gJ2j1gVlO3jBHXwhiRzl2x2WXJa yFzAKUCorQpaTlaUqCN2Bjnp+AecdFsgBpATnaEgDPXEVQQQQQQQQQQQQRbmWkvy7rLidzbi ShST4gjBjmGR7Ot52/MTbdpagPU6RdWFYaceYWsAcbwhWCRkj/xiM6b0Q1MWpsN6q1F1Cdqx 3s1MgpWPEDefHoYyU6J6kEs79XKyAR9VxMzPqnH2P1TnnzxFupdn27qzTHJOuao1aeYXtUZe Y715oqBzyFOkceHEX5TQi95OSalpTVmtsMspS2000t5CEIAwAEh3AA4wBFz4Eb//AH4K/wD0 sx/jRdd0X1AeJU7q9XQoJCU92p5A4wOQHfLx6kxhzOhF9Tks/LTurFZflXkltbTq31pWgjkK BdwQeeIwpTQS/bcpC5K0tRnpZlSisy6e9l0bseBSo4zk5+Y+EZcxpBqxMpS45qpNpfWgJcQ2 ++hKcYxt2kc+ZwD8uYzpfSvVfvVl7VV9KVICSUoWryzgEjHjyOYwbo0T1GuOnOSFW1KVPSSl ZMu8ytCHMEEbwk4OCARnOCIt0fRPUymU1mnSmpr0nIyyT3DUup0BJ8E9RhPs6Dyi6dJ9X3nH HXdUXULWNhCHngnaDwQBgAnAyQM+GTF9OmesrTYQ3qa2pKE4SVbyTjpklJJ+U5+eNTUtKNaK xJPSlTv9hUs6goW2mZdSHEngpVtQMgjzizbGj2r9uU5mmUa9JCn05CyrumXFkJ3HKjgt8/TG c5p/rulIKb9lVncAQHiMDPJ/W/CLU9pZrTUmkJqF9yTyWXEvtIW4opLiTlJI7vHB55zyBF2f 0z1rmmXJeYvunzcs58ZD2VJVg5GUlojwBjHp+les1OCxTrxpMoFkFXcDu93y4aEZfwe66/vg Sn9Kr/DglLC13Lc2l2/ZRrBSG8uFfeDPJz3eU+Hy5iP1XQjVGuVyn1Ss3bT35+T2pYm1OuFx kBRUMHYM4JJjfS1ka+NVB9Kb3kwyj4jziwsOceCS2cdT18vkjLk7V7QJWuYdvaktPOYCm1NN rSAOmB3G0fMOfGNHJ6da40uqzCqZcFHa78Zcmm0NICirOQB3WRjcT0Hs6CL1Z0o1kre4Ve76 NPJKioJmEBaUk4ztBawkcDgYHEZ67Z7Q0o8Eyt3UuYQrPrlLRA9UeCmfZjjxyfEmL6rb7Qra 5haLyo6ztBSO5Z9c8cAFjCep+XEaO79M9bb0kE0m57jos5TA6HsYQ366QQk+oylXieM4jNtH TjW616FL0ui3jSJSRaypEutCXu7J5IClsqOM54BxG3ctrtApbUUXxRFqAJCRKsjJ8v1iPHLV 19dQA7e9BUOuFSbJ/wD9eLzdr6+EOd5ftFSQnKcSTJ3Hy/WOPHmLfvW1+3lQvmhbiMZ9DZzj 73j02z2gMHF9UQ/+yM//APPFyXtfXtbeXr+ozS8p9USTKuPHnuPD8Mam59MdZLupC6Rcl7Ui YpjykqdaTLpRkhWRkoaSTjAOM4+iMu1tLtWrTobVIt7UCmS0gyVFplUghwJKiSfWW2o4yTG2 btLXAtpLmpFKSsjlIpjJA+fuo9Fo63c51KpXXj/NbP8AhR4zZmtLaVBOpVMBx19y2SVH2kt5 6fLHhtLXHvkpGo9JLRSSV+5jOQfLHdf3xS9aOuPeNhGo9KUnkkmnNJwfDjuuY8Noa5OOLbc1 GpSWdoIWmntZJ8RgNDHy5iO0jRTUuj3RN3FT7+km6zNp2TEyqXLhdHHCkqSUn4o8PCJI5Zet a0rCtS6eArrtpzY+jDfHzRgp041jG3Gp7Xq9Msk/T6vPzx65pxrI4QVantDH7Vkp/EmLTemO sLYITqgDklXrJWrr8o6eyKvg11i/fPR/Rq/Rj2W0/wBa2nFf7pMqA0vc0VM79/H2QKOnsORG O/Y2u82616Rf9PbSkBOWkhHHmQloZPyxg25ovqdblx1CsUi/JBmfqIPpcytgul45B9ZK0kZz nnqPnjc+8PW2bRunNSJJlfrDazLgcE/6rY8h8nOIwnNOdbQ64G9R2FICcoUSobjxwRs48YyH tOdZy0AnUxhRQnCR3ZTnkk5IRz16nPlwAI8b021lKUlepraSUgqAQo4PiPi8/LFL+m2s6UAs 6mNOK3AEKSpOB4nO0xWnTXWT1t2pzY54whRyP5sYc1pfrLOy05KTWo7CpV1JaIysd4hQwc4R kcE+MayztCdSbSZnWbfvmSpjUyoFxLKFqC9ucK5TwfkjaO6da4JmClvUSWWzkALK1A488d3/ AHxkjTjWbvFIVqYyGQApK9hyT4jG3wwPHxisaa6xHpqgj+jV+jF06d6ylnuvhOY2+fo/rdc/ G25/DFr4NtYwQU6ntk5HVtX6MXXdP9aFiYV8JkrvdOSBL7R82Eer80ae5NFdSrnqFNnq5f8A JzE3TFByScTLFssrBSQobEjnKQc8niNguxdc5d5xErqHIusuBO5bjYyMeQLR2/MefGM5dq67 hhSkag0dToxhBkGQD589z4fhjV/B1raX2gdRpcNKSCteVZSfEAbOfpEZB011j2nGp7ZOOAW1 foxhv6a62OybgVqO13u7aEIdWjKSMZ3BAIPJ4jXjSLWd5t4P6kvNkkKSEVGZ9Y4PGQBt8OOh zFlOjWsag+l3UmZ27DsBqk2oOHyIPQEfLGoo3Z31Jt5S129d0rTlzCE9+ZSbfYKiCcJJSnnH 95jZ/A7rT++NM/1xN/mi01pBratbyXNQJlCEnCVGtTSt488Y4i3PaOa1fUlJvt+ZWlWRmszI 2e3kQK0O1cW0WlX1loq3FCqnMkE4xnGPLiLI0D1UGdt5MJz+1qEwP/hg+ATVb7dW/wCsZn80 ZNF7Ot1TNwSE1fF0tzFMlFh1RRMuPO8EHakuDCckDJ/AY6tByAekEEEEEEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEeKSFAhQyDAlISk JSAEgYAHQR7BBBBBBBBBBBBBBBBBAQCOYBwIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIMc5ggggggg gggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg gggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg gggggggggggggggggggggggggggggggggggggggggggggggggggggj//2Q== --------------020406050406060705020409-- From nobody Fri Jun 6 10:12:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001DF1A01C6 for ; Fri, 6 Jun 2014 10:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9blhMq9e3uS for ; Fri, 6 Jun 2014 10:12:39 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D42C91A01C9 for ; Fri, 6 Jun 2014 10:12:39 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.9]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s56HCL88005496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2014 10:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402074752; x=1402161152; bh=7T6M15zTpjOgMhjUQtubC8McZt1RwzvtlPewRnnZKw4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Zk77A+b9u939+jSjOWPs3LsuKRGtsi1Ky1IXekWMFwiSumPajhNDL4ZVsbGJCedCy Schq8m1/xajwO3t5Sy9iJlfFUIyTcU/f7HerCyOmFrwCsEofsBV3Cqd8rgFSoQN93e RpD4yIaosEYfoZJUN7CkgUCU++rPUBMIp0vVQeF8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402074752; x=1402161152; i=@elandsys.com; bh=7T6M15zTpjOgMhjUQtubC8McZt1RwzvtlPewRnnZKw4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=obEovOGem5LuEWvXQjsU1oG1xUZgdCKxnmIiBN6oKEi46th5kIxsoulnW8GOB9o06 YO0SlvF/GhtQjKMWwwvY2SuH94tSBNXjmtxDYyLqd11a3JdnqU6bnUjbY71Xjl5tHz Pa9dxWmlWYh57BNT96ZYUwQm+TQmQbOWiB0EYVmY= Message-Id: <6.2.5.6.2.20140606095943.0b36fe90@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Jun 2014 10:11:45 -0700 To: Paul Hoffman From: S Moonesamy In-Reply-To: References: <20140604203255.36E7F18000D@rfc-editor.org> <6.2.5.6.2.20140606081954.0b44f3e0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/V1sYN81zGKq8me407t9Mu25pfvI Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2014 17:12:41 -0000 Hi Paul, At 09:37 06-06-2014, Paul Hoffman wrote: >Do you have examples of that? I could not find any, but I might have >missed them. The term is used in RFC 20. Regards, S. Moonesamy From nobody Fri Jun 6 10:30:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4C41A01C0 for ; Fri, 6 Jun 2014 10:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJ0nxd4VpYS3 for ; Fri, 6 Jun 2014 10:30:51 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830D51A0181 for ; Fri, 6 Jun 2014 10:30:50 -0700 (PDT) Received: (qmail 7217 invoked from network); 6 Jun 2014 17:30:42 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 6 Jun 2014 17:30:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=8ce9.5391fac2.k1406; i=johnl@user.iecc.com; bh=mWKaxzfi+3zAoZZw5l+yZl2BJWxohCNrZYm+drwXI4k=; b=Uecng1w4rMfuQjMVoGtSmsEPjxPVVoZLqID1Wp4T6Cri/ZTRO2eaT/PvyieQ6hA9sjG/D74HrcIB1Jwfx86HAuuYWViHoR+HUgCWvjP4+5NEi19YnLv/dgg4KtmdWT3M34yAq7MvdyRwCSAOXkc5OtSOy1mfv9y3QGCHTOrBbRZGVddScEiFzGlvhJPfdNIOSauZVADnZ6a7QhtCAK/GLOT9g1z9gpQWBeLqqKJ2n2G8/fp5GINQcwY7yZSH1i6G DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=8ce9.5391fac2.k1406; olt=johnl@user.iecc.com; bh=mWKaxzfi+3zAoZZw5l+yZl2BJWxohCNrZYm+drwXI4k=; b=lyG3UyAEyt0ZJQzr7mfQ+kyX8kZZ5YT2NoJsIjBAdm5NwXOBRrd9KIOXD+RCOuRbTzQDIkmMxukrhzr4XYdpho3XoPGCwdSjaTMKBaHhlUZDCsDtOOzDuUp7l9CFqNEPDFtmRsj7DD67BS1yxhObX/v3SkimS0UQfA4C125DeCo1I2155Bxcq+5r3TgmQy7x3G1fks+/FveV6BKyXyPYPdVdHwpJ23iGOJhWkzyxh33e1c8cCIx7VvWj4W11T9/L Date: 6 Jun 2014 17:30:19 -0000 Message-ID: <20140606173019.36072.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-BBJRrEnSAecbIWcxyYL8ww01W0 Cc: paul.hoffman@vpnc.org Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2014 17:30:52 -0000 >> The term "USASCII" predates the IETF. > >Do you have examples of that? I could not find any, but I might have missed them. Here's a blurb from 1973 for a TI terminal that says it speaks USASCII: http://bitsavers.trailing-edge.com/pdf/ti/terminal/TI-334A-10M_Silent_700_Model_732_733_Specifications_Jul_1973.pdf From nobody Fri Jun 6 10:40:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FEB1A01F9 for ; Fri, 6 Jun 2014 10:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3INGZwaTee7 for ; Fri, 6 Jun 2014 10:40:53 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F291A01EE for ; Fri, 6 Jun 2014 10:40:52 -0700 (PDT) Received: (qmail 8880 invoked from network); 6 Jun 2014 17:40:44 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 6 Jun 2014 17:40:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=8d30.5391fd1c.k1406; i=johnl@user.iecc.com; bh=57Wtakx2UjAuclt1JylRke0GFbENVX7uV2pFPQqiQPo=; b=WjpN8ha0N3symhhZANkOJGBFWOyyHWZHV3M1lfsHjDRDLvM5MvYdhUFfUrfVL/sWuFoh9HuzujXGZDhR+TFkpJSiWDpZClvCl3oVmYKaAr6RnJ1q+GTGGaq1qcnhak1qtyBUlRjIPMW1M+aziOufqdoR0JbOnR3gzm7G3U/bC6yuGWsYcvJvr0A+hkvZ6HS2K4Gk7UTwn8ruwFd9U+L09MIbsViBIm7bQlq1+HE3b3hZpWnU4uZufUE2cx/DeOoQ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=8d30.5391fd1c.k1406; olt=johnl@user.iecc.com; bh=57Wtakx2UjAuclt1JylRke0GFbENVX7uV2pFPQqiQPo=; b=emmSOuXcibRJu4irwnxAAeF4hhjPlZpgJPST39hCbNi2mws4lgp2i98cGT1oy02LRvZP+u9sN+LzRDLwtN6RGtaI8hJtDPIzbTrkff4a+k6vL3Uk92aJs5880TDujznDazI9g6KRGaGET35Uh8g7G7Zh4hgGfduJ5VdguTgGayhM174JE5Ol+Z6MCYm1XCmIYCxaOeGuPuMfHibX3ceSboxQ2bcL7AoYrbUhHS9b0jdPV5Oyqpsy4l2+SidKsQyL Date: 6 Jun 2014 17:40:22 -0000 Message-ID: <20140606174022.36143.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/IaP9GdsU_ejz6H3SgKIuUmbgPXI Cc: paul.hoffman@vpnc.org Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2014 17:40:54 -0000 >> The term "USASCII" predates the IETF. > >Do you have examples of that? I could not find any, but I might have missed them. One more: US Patent 3,743,797, filed on Aug 30, 1971 by a guy at Bell Labs for a keyboard decoding matrix says in columns 8 and 9: The principles of this invention can be used in a key board which, along with some simple logic circuitry, can be utilized to generate special codes such as the United States American Society for Communication and Information Interchange Code (USASCII Code). Because the USASCII Code contains 128 elements, a (4 X 4) matrix using second-order stroke coding is suf- ficent to generate the complete code because as previ- ously mentioned such a matrix can define up to 256 unique characters. Googling around I see a lot of references from the early 1970s. The earliest I see is a Burroughs document at bitsavers from May 1970. R's, Prior Art 'r' Us From nobody Fri Jun 6 13:05:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2941A0078 for ; Fri, 6 Jun 2014 13:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq07dp2BTQvv; Fri, 6 Jun 2014 13:05:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5BB1A025F; Fri, 6 Jun 2014 13:05:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, ned+ietf@mrochek.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140606200539.16136.75841.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 13:05:39 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YJdK39dkM5ej9gwKzcl9X-EahKQ Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 20:05:50 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ From nobody Fri Jun 6 15:53:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48B31A02B7 for ; Fri, 6 Jun 2014 15:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRVlY7g71lHw for ; Fri, 6 Jun 2014 15:52:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5898C1A02B3 for ; Fri, 6 Jun 2014 15:52:59 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s56MqoPn070630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 6 Jun 2014 15:52:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: Date: Fri, 6 Jun 2014 15:52:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0D388716-0A9A-41B1-8B1C-46EF4119CFC2@vpnc.org> References: <20140604203255.36E7F18000D@rfc-editor.org> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/29A2VhMtSKum8orPsbxBgTzE84I Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2014 22:53:00 -0000 Thanks for the pointers to earlier reference to USASCII and US-ASCII. I = still believe that John's propose errata should be rejected, and = replaced with something along the lines of the following: Section: New section 1.4 Original Text ------------- (none) Corrected Text -------------- 1.4 Use of "US-ASCII" Throughout this document and hundreds of other RFCs, the term "US-ASCII" = is used in text and in references to refer to the coded character set = defined by ANSI as "Coded Character Set -- 7-bit American Standard Code = for Information Interchange, ANSI X3.4-1986". Although the term = "US-ASCII" has been popular in RFCs for more than two decades, and in = non-IETF usage before that, it is probably not the best term to use: it = should just be called "ASCII". The ANSI reference does not define = "US-ASCII", and using the "US-" prefix can cause confusion to readers = who wonder what that prefix means. From nobody Fri Jun 6 16:17:44 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72E01A0226 for ; Fri, 6 Jun 2014 16:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nODokVxASj06 for ; Fri, 6 Jun 2014 16:17:40 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8511A024A for ; Fri, 6 Jun 2014 16:17:39 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id pa12so4081748veb.26 for ; Fri, 06 Jun 2014 16:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CZiAXNp7mxRRYJ3zJ+pkwpmzlS0CKTPLYIQemuagGds=; b=cPKcbuHvNKbeLNe0SKCSK3VW6EiHp49gGb3AwosM8jEip8Zh0NXcSLEV5O/WBbafE7 ZEHtEfLRJRuVk/d1i4CzyzrNzZVWUUwVLByyy+k8nPBCPxFkNbyUbRTUWDYmZNSOXhrF QVofTy2v7XkjiYVZNYXbWC5LLqDo8Bk6nYsovX/iHKkWl9Ja85EzV2MmdfhrMB4/9bVp XXkX3S//HgAlACAkEIC70Gg0WQ1yNSzyWlJm/7/B+KaiwgzLmKvslU0WLy8q1TIxqR0R CzRSbBucZOtlqq5ylahfZeZ+SpKGPYoH2krne02IeTQMxEEss9urzUMkEniWqUrc/8vd Mvig== MIME-Version: 1.0 X-Received: by 10.58.209.233 with SMTP id mp9mr9576192vec.30.1402096652543; Fri, 06 Jun 2014 16:17:32 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Fri, 6 Jun 2014 16:17:32 -0700 (PDT) In-Reply-To: <0D388716-0A9A-41B1-8B1C-46EF4119CFC2@vpnc.org> References: <20140604203255.36E7F18000D@rfc-editor.org> <0D388716-0A9A-41B1-8B1C-46EF4119CFC2@vpnc.org> Date: Fri, 6 Jun 2014 19:17:32 -0400 X-Google-Sender-Auth: p-slIKWcs4_6GJ1XL8nZfNK9yCc Message-ID: From: Barry Leiba To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_Mf9e5Wh6wWZrgwH2kM2jrq5XLo Cc: IETF Apps Discuss Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2014 23:17:41 -0000 > I still believe that John's propose errata should be rejected, I agree. > and replaced with something along the lines of the following: I don't agree. The use of "US-ASCII" in RFC 6365 was not an error that failed to be caught. We all looked at it, and we all thought it was a fine term to use. In fact, many thought it preferable to "ASCII" in the context. That we might think otherwise now is not correct use of the errata system. > Section: New section 1.4 > > Original Text > ------------- > (none) > > Corrected Text > -------------- > > 1.4 Use of "US-ASCII" > > Throughout this document and hundreds of other RFCs, the term > "US-ASCII" is used in text and in references to refer to the coded > character set defined by ANSI as "Coded Character Set -- 7-bit > American Standard Code for Information Interchange, ANSI X3.4-1986". > Although the term "US-ASCII" has been popular in RFCs for more than > two decades, and in non-IETF usage before that, it is probably not the > best term to use: it should just be called "ASCII". The ANSI reference > does not define "US-ASCII", and using the "US-" prefix can cause > confusion to readers who wonder what that prefix means. If you would like to write a one-page draft that "updates" 6365 and that says that, I will be happy to AD-sponsor it. Barry From nobody Fri Jun 6 16:24:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57B81A026B for ; Fri, 6 Jun 2014 16:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUPLnq9AcFKW for ; Fri, 6 Jun 2014 16:24:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265041A0268 for ; Fri, 6 Jun 2014 16:24:00 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s56NNoVs071490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jun 2014 16:23:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: Date: Fri, 6 Jun 2014 16:23:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9BB9FE52-5F66-44C2-AF43-86D6206941CD@vpnc.org> References: <20140604203255.36E7F18000D@rfc-editor.org> <0D388716-0A9A-41B1-8B1C-46EF4119CFC2@vpnc.org> To: Barry Leiba X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/m4VN6YZS373aGTR3YE0lAVm-UiE Cc: IETF Apps Discuss Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2014 23:24:01 -0000 On Jun 6, 2014, at 4:17 PM, Barry Leiba wrote: > If you would like to write a one-page draft that "updates" 6365 and > that says that, I will be happy to AD-sponsor it. If John wants to do so, great. I guess I'll co-author if he does. = Otherwise, maybe we can just let this one die. --Paul Hoffman= From nobody Fri Jun 6 16:26:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B882A1A0201 for ; Fri, 6 Jun 2014 16:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzkurFbkPtCQ for ; Fri, 6 Jun 2014 16:26:37 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E52241A0086 for ; Fri, 6 Jun 2014 16:26:37 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 379EB768059 for ; Fri, 6 Jun 2014 16:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=U+ayn/P43X2hYPCivuwq CNlODwI=; b=CMio3BnHyODVKWmkptM2KpsxyDEcd5hN2GUp+uJM/H/L+YEZpceW p+0codj8rHnOXrEQQz0j/+A/icjvRydAll5aerfPDtEadJxWeWgBYp33SXfe+II3 KWKruKVUGckve59YjcqBRvXpQU40u8L5xTXtXGtKQDE1xO4e/LI7mIs= Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id D2ED8768057 for ; Fri, 6 Jun 2014 16:26:30 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n15so1792516wiw.14 for ; Fri, 06 Jun 2014 16:26:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.77.225 with SMTP id v1mr1000445wiw.5.1402097189168; Fri, 06 Jun 2014 16:26:29 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Fri, 6 Jun 2014 16:26:29 -0700 (PDT) In-Reply-To: <9BB9FE52-5F66-44C2-AF43-86D6206941CD@vpnc.org> References: <20140604203255.36E7F18000D@rfc-editor.org> <0D388716-0A9A-41B1-8B1C-46EF4119CFC2@vpnc.org> <9BB9FE52-5F66-44C2-AF43-86D6206941CD@vpnc.org> Date: Fri, 6 Jun 2014 18:26:29 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BD0_73m0z_5LUGcGEn297Zs-h70 Cc: Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2014 23:26:38 -0000 Give it a generic title, something like, "It's ASCII, not US-ASCII". On Fri, Jun 6, 2014 at 6:23 PM, Paul Hoffman wrote: > On Jun 6, 2014, at 4:17 PM, Barry Leiba wrote: > >> If you would like to write a one-page draft that "updates" 6365 and >> that says that, I will be happy to AD-sponsor it. > > If John wants to do so, great. I guess I'll co-author if he does. Otherwise, maybe we can just let this one die. > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Fri Jun 6 17:07:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CD01A0201 for ; Fri, 6 Jun 2014 17:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHAQOoIxMosT for ; Fri, 6 Jun 2014 17:06:51 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 96A2A1A01F5 for ; Fri, 6 Jun 2014 17:06:51 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8P8CR2474004PXP@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 6 Jun 2014 17:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1402099295; bh=eAtNrO4ZPX/vGKjENlHXj7b+3W6oMGu4B9kpyfC2xAc=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=f5Pdpwrgx02G7FldlXbevmToOOjrtpUSWun12NFemWmL01Q2mF1TGdqS2YPK+BQzA s5MeoAVok2RG2dExfmbMMHyDGZQdSPEjymaarNs2U6hewuurFHbicfddr6r1s+eohI Wojw7bBFS5oAMi6v9uIEhRfDyPkG5H7Jdb8ndaFY= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8P33PUR68000054@mauve.mrochek.com>; Fri, 06 Jun 2014 17:01:33 -0700 (PDT) Message-id: <01P8P8CPNWSW000054@mauve.mrochek.com> Date: Fri, 06 Jun 2014 16:51:20 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 06 Jun 2014 09:08:13 -0700" <6.2.5.6.2.20140606081954.0b44f3e0@resistor.net> References: <20140604203255.36E7F18000D@rfc-editor.org> <6.2.5.6.2.20140606081954.0b44f3e0@resistor.net> To: S Moonesamy Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/coHNKBIUxE5DhJ7CBmUvJ-tZJRQ Cc: apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jun 2014 00:06:55 -0000 > I read ANSI X3.4-1986. The term for the Coded Character Set is > "ASCII". The character set in the IANA registry is "US-ASCII". Ned > Freed commented about that. The term "USASCII" predates the IETF. I > took a quick look at several IETF RFCs and found occurrences of the > term "US-ASCII". That's a very good point I should have remembered, the more fool I for not having done so. The term "ASCII" as defined X3.4 is NOT a charset. So it's actually incorrect to use them interchangeably. > I suggest not doing a global replace as the two terms are not used > interchangeably throughout RFC 6365. You're right. The terms are used for the most part correctly, but there are some goofs, e.g. the reference label [US-ASCII] should be [ASCII], or better still something like [ANSI-X3.4]. And most of the places where it says "non-ASCII text" should be "non-US-ASCII text", because there are many CESes that can be combined with the ASCII CCS, and a lot of them don't produce anything resembling what's being talked about here. This goes far beyond the ability of an erratum to fix, I think. > The guidance which people might be following could be: > "These are the official names for character sets that may be used in > the Internet and may be referred to in Internet documentation. These > names are expressed in ANSI_X3.4-1968 which is commonly called > US-ASCII or simply ASCII. The character set most commonly use in the > Internet and used especially in protocol standards is US-ASCII, this > is strongly encouraged. The use of the name US-ASCII is also > encouraged." It needs to be "charset", not "character set", but other than that this looks OK to me - as far as it goes. Ned From nobody Fri Jun 6 18:19:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D371A02F3; Fri, 6 Jun 2014 18:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGq0G50WO6GM; Fri, 6 Jun 2014 18:19:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9056C1A02EF; Fri, 6 Jun 2014 18:19:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9CE28180491; Fri, 6 Jun 2014 18:18:03 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140607011803.9CE28180491@rfc-editor.org> Date: Fri, 6 Jun 2014 18:18:03 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZW4rVDBCnHKpDGGELsCJK17TRqU Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7239 on Forwarded HTTP Extension X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jun 2014 01:19:16 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7239 Title: Forwarded HTTP Extension Author: A. Petersson, M. Nilsson Status: Standards Track Stream: IETF Date: June 2014 Mailbox: andreas@sbin.se, nilsson@opera.com Pages: 16 Characters: 35003 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-appsawg-http-forwarded-10.txt URL: http://www.rfc-editor.org/rfc/rfc7239.txt This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Jun 7 08:26:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B4A1A011C for ; Sat, 7 Jun 2014 08:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqIYb1-8G7B2 for ; Sat, 7 Jun 2014 08:26:20 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id D12B61A00D7 for ; Sat, 7 Jun 2014 08:26:20 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8Q4GQKG9C002DYS@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 7 Jun 2014 08:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1402154465; bh=TdUSiqB6ZWv61DauXQFrKvIDR6/hH5P5qOxWpB8E69Y=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=eRHN5SAOXYcG2ySCkGHG2UWfX2Kbek2pr9xiPG30W6IyvySRTxsMawWR+nv0qiFS4 UEuD3JPZy7DtNOE7huKevPgaqXQ0HaA/EgeGU6pxh/YYDkSmXu5Qbk7RNCIcm+LfB3 gciSzVT9BBInPT9Y7lpiW1rWnPgVX6jM5KD9Tngs= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8P641BPZK0049PU@mauve.mrochek.com>; Sat, 07 Jun 2014 08:21:02 -0700 (PDT) Message-id: <01P8Q4GPNZFK0049PU@mauve.mrochek.com> Date: Sat, 07 Jun 2014 08:06:51 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 06 Jun 2014 19:17:32 -0400" References: <20140604203255.36E7F18000D@rfc-editor.org> <0D388716-0A9A-41B1-8B1C-46EF4119CFC2@vpnc.org> To: Barry Leiba Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DWobk4EaWMZwdJjXj01B6uQPMFc Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jun 2014 15:26:22 -0000 > > I still believe that John's propose errata should be rejected, > I agree. > > and replaced with something along the lines of the following: > I don't agree. The use of "US-ASCII" in RFC 6365 was not an error > that failed to be caught. We all looked at it, and we all thought it > was a fine term to use. Actually, it's more than that. We thought it was the *correct* term to use. > In fact, many thought it preferable to > "ASCII" in the context. That we might think otherwise now is not > correct use of the errata system. Again, more than that. At least some of us thought that the use of the term "ASCII" would have been *incorrect*. > > Section: New section 1.4 > > > > Original Text > > ------------- > > (none) > > > > Corrected Text > > -------------- > > > > 1.4 Use of "US-ASCII" > > > > Throughout this document and hundreds of other RFCs, the term > > "US-ASCII" is used in text and in references to refer to the coded > > character set defined by ANSI as "Coded Character Set -- 7-bit > > American Standard Code for Information Interchange, ANSI X3.4-1986". > > Although the term "US-ASCII" has been popular in RFCs for more than > > two decades, and in non-IETF usage before that, it is probably not the > > best term to use: it should just be called "ASCII". The ANSI reference > > does not define "US-ASCII", and using the "US-" prefix can cause > > confusion to readers who wonder what that prefix means. > If you would like to write a one-page draft that "updates" 6365 and > that says that, I will be happy to AD-sponsor it. And this is supposed to accomplish ... what, exactly? We have two different terms that refer to different things. We have now apparently decided that one of these terms is "confusing" and wish to deprecate its use in favor of the other. This despite the fact that the terms aren't interchangeable, and the one we wish to deprecate is actual registered name for the entity we're referring to most of the time. Which means this change is likely to cause, well, a lot of confusion. And this is somehow supposed to make things "better". I guess "better" got redefined when I wasn't looking. If you want to fix something, fix the actual problems RFC 6365 has. Unfortunately that's not really amenable to being done in either an erratum or a separate document. I don't see any way to do it other than a full revision, which is likely to open multiple cans of worms. Ned From nobody Sun Jun 8 15:10:35 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AB91A04AE for ; Sun, 8 Jun 2014 15:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imlWhnLEAe-b for ; Sun, 8 Jun 2014 15:10:33 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2391A03E3 for ; Sun, 8 Jun 2014 15:10:33 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8RWVDLMZ400548T@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 8 Jun 2014 15:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1402265126; bh=ciJweX0GiLX9uPJoy/G13dXPMbq/FJ7KZGQMrgMaou8=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=I1l+Utj4YJSYKsu24bYAxBJJZ1pDVToJGbMDvVTnw3oOh0UjFIPMGXEaNwb7doxVM mtoX+vHK6er8s9gSM4HVzr/GcWLTUdfWVwwUkghRTeWceXnJseER3e0QBf5UUOlHzn uTe07hSv4DGRQzDRZpGIn538nH5AEP1mEP6FvoW4= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8RM7N8OM80049PU@mauve.mrochek.com>; Sun, 08 Jun 2014 15:05:20 -0700 (PDT) Message-id: <01P8RWVBBBOM0049PU@mauve.mrochek.com> Date: Sun, 08 Jun 2014 14:22:12 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 06 Jun 2014 07:01:41 -0700" References: <20140604230055.84310.qmail@joyce.lan> <01P8MR4M1ROS0049PU@mauve.mrochek.com> <53916024.5070600@hireahit.com> <01P8OBFOH0RQ0049PU@mauve.mrochek.com> To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eIj7KvPPYiZwS1-DVd5lu9TQmyY Cc: Ned Freed , IETF Apps Discuss , Dave Warren Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jun 2014 22:10:34 -0000 > On Fri, Jun 6, 2014 at 1:11 AM, Ned Freed wrote: > > > > The sticking point is I've yet to see anyone advance a use-case for this > > that > > would justify standardizaing or implementing any of this. > > > > > The only case I've seen is the ability to report that the message failed > for multiple reasons, and the desire to report all of those reasons to the > client. "SPF and DKIM" is the common example. The benefit of doing so is > that the sending agent doesn't have to fix one problem and try again, only > to be denied for some other reason. In other words, it's a "nice to have". So the question is whether the cost of a given solution is worth the benefit. > Two solutions to this have been suggested. One, admittedly the simpler > one, is what we have now, which is to have a separate code to mean "This > failed for more than one reason." It has the benefit of requiring > approximately zero changes to the deployed base. The cost here is pretty low - of course the code itself is essentially free, but this does require validators to not stop at the first error they detect. The benefit is correspondingly limited to covering the current use case. > The other is to do something more fancy. There have now been two proposals > for this: (a) Make the third number in the enhanced status code a bit mask > so it can indicate multiple failures of the same type (e.g., 5.8.5 would > mean 5.8.1 and 5.8.4 at the same time; or (b) create a mechanism to send > and receive multiple distinct status codes. In either case, there's quite > a bit more work to do. Exactly. The bit encoding scheme has much lower cost overall since it doesn't require upgrades to the transport infrastructure. But I still don't think it's worth it. Ned From nobody Mon Jun 9 00:18:35 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8835D1A0008 for ; Mon, 9 Jun 2014 00:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2jGYvh0S6Bb for ; Mon, 9 Jun 2014 00:18:31 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4045C1A0002 for ; Mon, 9 Jun 2014 00:18:30 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 9F37432E52A; Mon, 9 Jun 2014 16:18:29 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 5a58_d3d6_6eb66ec8_151a_4c82_93a9_abdd5a67a693; Mon, 09 Jun 2014 16:18:29 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id D6E75BF418; Mon, 9 Jun 2014 16:18:28 +0900 (JST) Message-ID: <53955FB6.9030203@it.aoyama.ac.jp> Date: Mon, 09 Jun 2014 16:18:14 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ned Freed , Barry Leiba References: <20140604203255.36E7F18000D@rfc-editor.org> <0D388716-0A9A-41B1-8B1C-46EF4119CFC2@vpnc.org> <01P8Q4GPNZFK0049PU@mauve.mrochek.com> In-Reply-To: <01P8Q4GPNZFK0049PU@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dXmiZ1u0aikAUmUa_snSm_WYFYE Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2014 07:18:33 -0000 I have read the original erratum post and all the followup posts. I have also looked through RFC 6365 searching for all occurrences of the string ASCII (which of course includes strings reading US-ASCII). I fully agree with what Ned wrote below (up to and including the paragraph that starts with "If you want to fix something, fix the actual problems RFC 6365 has."). I also think that the way the RFC is currently written, the chance that a reader from another area or standard body is fundamentally confused (rather than just confused for a short time) is quite low. Regards, Martin. On 2014/06/08 00:06, Ned Freed wrote: >>> I still believe that John's propose errata should be rejected, > >> I agree. > >>> and replaced with something along the lines of the following: > >> I don't agree. The use of "US-ASCII" in RFC 6365 was not an error >> that failed to be caught. We all looked at it, and we all thought it >> was a fine term to use. > > Actually, it's more than that. We thought it was the *correct* term to > use. > >> In fact, many thought it preferable to >> "ASCII" in the context. That we might think otherwise now is not >> correct use of the errata system. > > Again, more than that. At least some of us thought that the use of the term > "ASCII" would have been *incorrect*. > >>> Section: New section 1.4 >>> >>> Original Text >>> ------------- >>> (none) >>> >>> Corrected Text >>> -------------- >>> >>> 1.4 Use of "US-ASCII" >>> >>> Throughout this document and hundreds of other RFCs, the term >>> "US-ASCII" is used in text and in references to refer to the coded >>> character set defined by ANSI as "Coded Character Set -- 7-bit >>> American Standard Code for Information Interchange, ANSI X3.4-1986". >>> Although the term "US-ASCII" has been popular in RFCs for more than >>> two decades, and in non-IETF usage before that, it is probably not the >>> best term to use: it should just be called "ASCII". The ANSI reference >>> does not define "US-ASCII", and using the "US-" prefix can cause >>> confusion to readers who wonder what that prefix means. > >> If you would like to write a one-page draft that "updates" 6365 and >> that says that, I will be happy to AD-sponsor it. > > And this is supposed to accomplish ... what, exactly? We have two different > terms that refer to different things. We have now apparently decided that one > of these terms is "confusing" and wish to deprecate its use in favor of the > other. > > This despite the fact that the terms aren't interchangeable, and the one we > wish to deprecate is actual registered name for the entity we're referring to > most of the time. Which means this change is likely to cause, well, a lot of > confusion. > > And this is somehow supposed to make things "better". > > I guess "better" got redefined when I wasn't looking. > > If you want to fix something, fix the actual problems RFC 6365 has. > Unfortunately that's not really amenable to being done in either an erratum or > a separate document. I don't see any way to do it other than a full revision, > which is likely to open multiple cans of worms. > > Ned > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Mon Jun 9 07:22:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C171A01AC for ; Mon, 9 Jun 2014 07:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n63AP-llB0gv for ; Mon, 9 Jun 2014 07:22:00 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D621A01A6 for ; Mon, 9 Jun 2014 07:21:58 -0700 (PDT) X-AuditID: c1b4fb2d-f79776d000001085-8c-5395c304419c Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 67.30.04229.403C5935; Mon, 9 Jun 2014 16:21:57 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.10]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 16:21:56 +0200 From: Salvatore Loreto To: "apps-discuss@ietf.org Discuss" Thread-Topic: draft-ietf-appsawg-email-auth-codes ready for wglc? Thread-Index: AQHPg+4q3jAdziAte0e9QkTkjLbvnw== Date: Mon, 9 Jun 2014 14:21:55 +0000 Message-ID: <1F0D92EA-74ED-4127-A7E3-EA24834FD39E@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3Rpf18NRggy/T+S1Wv1zBZjHxewOb A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXxe94PtoK9zBULri5jamC8wtTFyMkhIWAi MW/jWUYIW0ziwr31bF2MXBxCAkcZJbasbmSBcBYxSvQ/3sECUsUmYCbx/OEWZhBbRMBaYv6H 3WA2s4C+RMOaOawgtrCAjcTqrvdMEDWOEg9XtQNN5QCy9SSal5iChFkEVCTeHoUo5xWwl3jU dQpsvJBAgETXvXlgIzkFAiVWbbzFBmIzAh33/dQaJohV4hK3nsyHekBAYsme88wQtqjEy8f/ WCFsJYnGJU9YIep1JBbs/sQGYVtLzOg8AzVHW2LZwtfMEDcISpyc+YRlAqP4LCQrZiFpn4Wk fRaS9llI2hcwsq5iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECIy3g1t+6+5gXP3a8RCjAAej Eg+vgujUYCHWxLLiytxDjNIcLErivJc0qoOFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MK49 8c63/MQxH9edh8t62N5NnHTH6vB/Bm6+t/uWJxqKLixgz461neiW9f25TcH+tU9YDNk3qybZ 1N9iOejA0Dhn5RXXExaBZwpYF13sM7k4+YHN9h2WpUqWdqf21z2bf93M5OKUPanvD9x6We0+ T/Dk/D7W1wFbNBgmPsir7vrzfuHn/98eKCcpsRRnJBpqMRcVJwIADRIONJgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3ng9OFKlj5iKRRkWmDErxm1IZbw Subject: [apps-discuss] draft-ietf-appsawg-email-auth-codes ready for wglc? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2014 14:22:02 -0000 Hi guys, as co-chair I have seen a really good email discussion and quite quick prog= ress on this draft,=20 Murray has also produced a 01 version to address the comments he has receiv= ed. So I do believe that the draft is ready for WGLC, as all the last if any minor comments can be addressed during the wglc stag= e. I will wait for a couple of days and if anything happen I will formally sta= rt the wglc. br Salvatore From nobody Mon Jun 9 08:05:44 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3BC1A01FA for ; Mon, 9 Jun 2014 08:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UquF2sTVwTHv for ; Mon, 9 Jun 2014 08:05:41 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B4F1A01D8 for ; Mon, 9 Jun 2014 08:05:41 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jz11so2487777veb.16 for ; Mon, 09 Jun 2014 08:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RnlMlzZgKJfVpEvWdTZBDOYX8K5QSUDIhvFFHvyf07k=; b=gE7Lnvt2PoL8IXWyhqo5fy4oAWVtuwxrB1daTWARZ67iKnM3OsZu8I+MPIcuLu88AN xu/MqPpZkILm0OzlHqf0N30fjfOaUs1O8TFZsP08Wh4h2WWsXLpii0YDUnPHuKFEQ29L oLtmgKGkO/qTrQMJUwkqsT0NLWfy3PbPB0OxCd0BgZMwmT9exGYcT0+HtIrZflUNL9fl r83fgf/BKAVUlqgtSX/PGvf2y6L93K2v67RQewC01RHPts+aECgjuKe5/sczjaw1HKs3 eBygl/YA1K8kT5iFrooE+qpLmsV++flT/uFOqsq4BoPxd+KCu3tMBmEGblEe+YaAD4Yg bpww== MIME-Version: 1.0 X-Received: by 10.52.190.162 with SMTP id gr2mr1383074vdc.71.1402326340512; Mon, 09 Jun 2014 08:05:40 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Mon, 9 Jun 2014 08:05:40 -0700 (PDT) In-Reply-To: <01P8RWVBBBOM0049PU@mauve.mrochek.com> References: <20140604230055.84310.qmail@joyce.lan> <01P8MR4M1ROS0049PU@mauve.mrochek.com> <53916024.5070600@hireahit.com> <01P8OBFOH0RQ0049PU@mauve.mrochek.com> <01P8RWVBBBOM0049PU@mauve.mrochek.com> Date: Mon, 9 Jun 2014 11:05:40 -0400 X-Google-Sender-Auth: PFyo7TzY--0Dj8ajyjE9bPmHdXQ Message-ID: From: Barry Leiba To: Ned Freed Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ov8u-_vdBGJcCqjuTh-lh-NTc3Q Cc: Dave Warren , IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2014 15:05:42 -0000 >> The only case I've seen is the ability to report that the message failed >> for multiple reasons, and the desire to report all of those reasons to the >> client. "SPF and DKIM" is the common example. The benefit of doing so is >> that the sending agent doesn't have to fix one problem and try again, only >> to be denied for some other reason. > > In other words, it's a "nice to have". So the question is whether the cost of a > given solution is worth the benefit. ... > The cost here is pretty low - of course the code itself is essentially free, > but this does require validators to not stop at the first error they detect. > > The benefit is correspondingly limited to covering the current use case. Indeed. The reason I supported that code, though, is that the current use case is, at least for now, extremely common. Very many systems check both SPF and DKIM, usually in that order, and they don't stop when one of them fails, because we know that they're complementary, and that it's often the case that one of them fails and the other validates. And there aren't other, comparable domain-validation systems ("sender authentication", we unfortunately have come to call it) for now, so in this case "more than one" means two, and specifically means SPF and DKIM. Should we eventually have a third, and should that third become as widely deployed, we'll have to decide then whether this code is enough to meet that use case or not. >> The other is to do something more fancy. There have now been two proposals >> for this: (a) Make the third number in the enhanced status code a bit mask >> so it can indicate multiple failures of the same type (e.g., 5.8.5 would >> mean 5.8.1 and 5.8.4 at the same time; or (b) create a mechanism to send >> and receive multiple distinct status codes. In either case, there's quite >> a bit more work to do. > > Exactly. The bit encoding scheme has much lower cost overall since it doesn't > require upgrades to the transport infrastructure. > > But I still don't think it's worth it. I agree that it's not worth it, but I might think otherwise if/when we develop another such domain-validation system. Barry From nobody Mon Jun 9 09:24:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C609D1A0274 for ; Mon, 9 Jun 2014 09:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK7fz8gjWXSE for ; Mon, 9 Jun 2014 09:24:48 -0700 (PDT) Received: from mail.santronics.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3981A01D0 for ; Mon, 9 Jun 2014 09:24:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2885; t=1402331078; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=eRjbVxvpHFzBMmPiLp6Nkb4k7ac=; b=AibuABag1Skr+OQ9OGip +AZB/XCJnugnrOAVdkmvDrMylzIw5eqtbT3oqK3Qpsv9p4Xvth9Dt8b9MCOvNwuj zeuuGWbbpuLNIorRUPap7ipdx91BodGDlCswamdZSYiqNQydG6eNUqYiS80BHnta S0NxeN347nWp5hb/ocXdpZ0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 09 Jun 2014 12:24:38 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1811202012.10081.2476; Mon, 09 Jun 2014 12:24:37 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2885; t=1402330910; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=pRahdWp t2zXwvN0Yvvsmoh9w4fsBzOw6dR9Xir29LII=; b=p7w1a+X0U0Wak3NY1TAHrXB W0oTSBqJlIEQWBwJshfh3xeHo72BlmfRhh7Ya/XxTT2V9wb18oaFPnbvMrwDHoq2 WtvnaABXKLglZwlqelpMvObGi3MuRRHmYsQl9CEvl0HeYoWAjzV6d7r/O2JjzgZi 5AYUXQOTY2FLGKMJLnYA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 09 Jun 2014 12:21:50 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1827557421.9.1784; Mon, 09 Jun 2014 12:21:49 -0400 Message-ID: <5395DFBF.9050100@isdg.net> Date: Mon, 09 Jun 2014 12:24:31 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Barry Leiba , Ned Freed References: <20140604230055.84310.qmail@joyce.lan> <01P8MR4M1ROS0049PU@mauve.mrochek.com> <53916024.5070600@hireahit.com> <01P8OBFOH0RQ0049PU@mauve.mrochek.com> <01P8RWVBBBOM0049PU@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FYlcMG2A4NfsMpFiHJUO0JeU--c Cc: IETF Apps Discuss , Dave Warren Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2014 16:24:51 -0000 On 6/9/2014 11:05 AM, Barry Leiba wrote: > > Indeed. The reason I supported that code, though, is that the current > use case is, at least for now, extremely common. Very many systems > check both SPF and DKIM, usually in that order, and they don't stop > when one of them fails, because we know that they're complementary, > and that it's often the case that one of them fails and the other > validates. Barry, I disagree with the notion that there isn't a significant amount of systems with optimized short circuiting on the SMTP level before the DATA payload is reached. If you want to be specific and suggest that there is a multi-technology protocol (DMARC) that requires the SPF process to be delayed or results handling delayed until the PAYLOAD is reached, I think that would be ok to say, but not demanding it be the required mode of operation. There will be existing SPF sites that do reject at the SMTP-PRE-DATA state and when they migrate to add DMARC support, there might be new design change pressures to alter/offer new modes of operation. For example, there could be two options added to our configuration tool: [X] Enable SPF Support [_] Delay SPF -ALL rejection until DMARC is processed (NEW) [X] Enable DMARC support (NEW) Or to make it an easy Plug and Play solution, or just exploratory as many will most likely do first and learn what are all the options are, their new DMARC implementation would naturally only apply to relaxed SPF results (~ALL, ?ALL) transactions that would allow the payload to be reached. Many sites will find that for SPF -ALL results, a majority would fail anyway at the PAYLOAD level. Therefore, it would be a major overhead performance, higher scale issue if this redundancy was allowed. So you must take into account that this optimization will most likely occur. Also, its not just SPF, but you got other dynamic rejection SMTP filters too and popular one is DNS-based RBL (Runtime Black List). That is what we found with the Microsoft CEP proposal, the XML version of SPF for the 5322 payload which eventually became: RFC4405 SUBMITTER SMTP Service Extension RFC4406 Sender ID: Authenticating E-Mail RFC4407 Purported Responsible Address (PRA) SUBMITTER allows for the 5322 PRA to be passed via the 5321 MAIL FROM command. C: EHLO client.example.com S: 250 SUBMITTER c: MAIL FROM: SUBMITTER=pra I bring this up because to dot/cross all the engineering eyes/tees, it is clear that a similar ESMTP level DMARC optimizer could apply if the author domain can be passed to the SMTP MAIL FROM command: C: EHLO client.example.com S: 250 DMARC c: MAIL FROM: DMARC=5322.From.domain This would allow for SPF extended reply codes to apply for DMARC policy reasons at the SMTP level without processing the payload. -- HLS From nobody Wed Jun 11 02:20:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BBE1B2837; Wed, 11 Jun 2014 02:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSS_p-lgNoLF; Wed, 11 Jun 2014 02:20:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id B112D1A0340; Wed, 11 Jun 2014 02:20:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 253F818000E; Wed, 11 Jun 2014 02:19:32 -0700 (PDT) To: john=ietf@jck.com, paul.hoffman@vpnc.org, john+ietf@jck.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140611091932.253F818000E@rfc-editor.org> Date: Wed, 11 Jun 2014 02:19:32 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iPCNH9DPSoSpoAB9DkJirTWezPM Cc: barryleiba@computer.org, iesg@ietf.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Errata Rejected] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2014 09:20:26 -0000 The following errata report has been rejected for RFC6365, "Terminology Used in Internationalization in the IETF". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6365&eid=4005 -------------------------------------- Status: Rejected Type: Editorial Reported by: John Klensin Date Reported: 2014-06-04 Rejected by: Barry Leiba (IESG) Section: GLOBAL Original Text ------------- US-ASCII Corrected Text -------------- ASCII Notes ----- The term "US-ASCII" is an IETF artifact, left over from some misunderstandings about what "ASCII" referred to (and the complete absence of CSCII or CASCII, MSCII or MXSCII, BRSCII, ARSCII, and other "American" coded character sets). It is a source of confusion for people who come to IETF specifications with a background in coded character sets and terminology from other areas or standards bodies and has been warned against multiple times. It should not have appeared in this document except possibly with a warning against its use (and the use of other bogus terms like "ASCII7"). The second author, who is normally sensitive to the issue, has no idea how this got past him, even in text picked up from other documents, but supposes this is what errata are for. In any event, there is no such thing as "US-ASCII": the term is an erroneous and misleading synonym/ substitute for "ASCII". The reference for the latter is correct, but the citation anchor should probably be corrected as well. --VERIFIER NOTES-- (1) It's clear that this is NOT errata: the use of "US-ASCII" in the document was quite intentional at the time. (2) If (and it's not clear that there's consensus on this) we think that "US-ASCII" is not the right term, the right answer is to revise the document. Should that be done, we'd open up quite a debate about what terminology is right, and why. Simply replacing all occurrences of "US-ASCII" with "ASCII" is unlikely to be the answer. Whatever should happen would be more complicated than that. -------------------------------------- RFC6365 (draft-ietf-appsawg-rfc3536bis-06) -------------------------------------- Title : Terminology Used in Internationalization in the IETF Publication Date : September 2011 Author(s) : P. Hoffman, J. Klensin Category : BEST CURRENT PRACTICE Source : Applications Area Working Group Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed Jun 11 14:11:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9C71B28A6 for ; Wed, 11 Jun 2014 14:10:59 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R15mDa5fDquK for ; Wed, 11 Jun 2014 14:10:58 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCA91B289B for ; Wed, 11 Jun 2014 14:10:57 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id bs8so2341634wib.1 for ; Wed, 11 Jun 2014 14:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=u8F2V6yVOWah0+aP6Evz+xvb1aycy7NmgANU7vWygjs=; b=GF2vRAx2YSqrOsn0Ku1IP0RKML2LbUiRCYq7242AzcE1vk/X0LyAe0JCmiRDH/rprU tA04DRCAJD529NWAa5TGmfUIGEXSOIqocVRXKf+vS0lDyV8tmlrqQ0BChMj+IEzWvNTE vmmRvKB7QdwgGwrvnipqtmkjx+zBFEA1h8nV12rWQxnlL5hu5X4e/7nCLRdCjslndZna dgw5kvNTpKE4v/CssR7PenvLH/BqPXB3aKnnP24URfNZr/R99bqsI0prFOJerCiIPWtF mAbIQ/UDve0CTTv0Isw50TLh1QLdzXXlUfmw9CQWRiZRwSUX0wVhNHw02YNR0Sh7QuPt 40gw== MIME-Version: 1.0 X-Received: by 10.194.161.168 with SMTP id xt8mr55736469wjb.35.1402521056529; Wed, 11 Jun 2014 14:10:56 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Wed, 11 Jun 2014 14:10:56 -0700 (PDT) Date: Wed, 11 Jun 2014 14:10:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e01419c6a5d556e04fb95e13e Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GC15_LTpXn7Oyo1twV3LNeoCZyY Subject: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-nullmx X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2014 21:10:59 -0000 --089e01419c6a5d556e04fb95e13e Content-Type: text/plain; charset=UTF-8 Colleagues, This note starts a Working Group Last Call for draft-ietf-appsawg-nullmx. This resurrects work originally proposed in 2006, championed this time by John Levine. It has had a good number of reviewers since its introduction after London and seems to be stable. Please provide review comments either on this list or privately to draft-ietf-appsawg-nullmx.all@tools.ietf.org on or before June 27, 2014. Also, if any participant has knowledge of IPR that needs to be declared on this work, please do so, as required by BCPs 78 and 79. Dave Crocker is fulfilling the duties of document shepherd. -MSK, APPSAWG co-chair --089e01419c6a5d556e04fb95e13e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

This note starts a Working Group L= ast Call for draft-ietf-appsawg-nullmx.=C2= =A0 This resurrects work originally proposed in 2006, championed this time = by John Levine.=C2=A0 It has had a good number of reviewers since its intro= duction after London and seems to be stable.

Please provide review comments either on this list or privately to draft-ietf-apps= awg-nullmx.all@tools.ietf.org on or before June 27, 2014.

Also, if any participant has knowledge of IPR that needs to be de= clared on this work, please do so, as required by B= CPs 78 and 79.

Dave Crocker is fulfilling the duties of docume= nt shepherd.

-MSK, APPSAWG co-chair

--089e01419c6a5d556e04fb95e13e-- From nobody Thu Jun 12 00:08:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23D91A016C; Thu, 12 Jun 2014 00:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4NaxDVvC_OU; Thu, 12 Jun 2014 00:08:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D53771A022B; Thu, 12 Jun 2014 00:08:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, ned+ietf@mrochek.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140612070818.8662.38519.idtracker@ietfa.amsl.com> Date: Thu, 12 Jun 2014 00:08:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/C8piUQUH-xEXBM-pWeuhOAq409k Cc: iesg-secretary@ietf.org Subject: [apps-discuss] Last Call Expired: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 07:08:21 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Thu Jun 12 01:20:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F8E1A0415 for ; Thu, 12 Jun 2014 01:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5ZJ35Lhqeyg; Thu, 12 Jun 2014 01:20:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E13331B27A4; Thu, 12 Jun 2014 01:20:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, ned+ietf@mrochek.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140612082032.6739.67946.idtracker@ietfa.amsl.com> Date: Thu, 12 Jun 2014 01:20:32 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AZ8DGmwjwW5SYhwgDS2aIrUJmjM Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 08:20:34 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ From nobody Thu Jun 12 09:17:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0981A0178 for ; Thu, 12 Jun 2014 09:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMPhY-RG3jFK for ; Thu, 12 Jun 2014 09:17:53 -0700 (PDT) Received: from waldorf.isode.com (host217-34-220-158.in-addr.btopenworld.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 112731B2A9A for ; Thu, 12 Jun 2014 09:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1402589869; d=isode.com; s=selector; i=@isode.com; bh=EecJKp/NoZ3QrTFuPN+AAwsAKBhLQv92wLjFxgjLY0A=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=KkfkdR5Kyvnhn001NpD2kj1rzXKOe3KIdJVS1zJzrNuQI+KFrvaCI91/o76zHuU/6k55q2 c+TqZXjogkVC+VZzp6heNJ06D+xuArkP6ZX0H0SplPYtxgDbBzy2Qp/P7WUx3bevW9CGkQ OcOOnHjc7IRhG6Qcg3AvXCeTF8LCdSM=; Received: from [172.20.1.49] ((unknown) [172.20.1.49]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 12 Jun 2014 17:17:49 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <5399D2C4.7080606@isode.com> Date: Thu, 12 Jun 2014 17:18:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 To: "Murray S. Kucherawy" , IETF Apps Discuss References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------030900080909020702080905" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RNJH41HGm5L-Mc8Op_a352KuDxU Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-nullmx X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jun 2014 16:17:56 -0000 This is a multi-part message in MIME format. --------------030900080909020702080905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/06/2014 22:10, Murray S. Kucherawy wrote: > Colleagues, > > This note starts a Working Group Last Call for > draft-ietf-appsawg-nullmx. This resurrects work originally proposed in > 2006, championed this time by John Levine. It has had a good number > of reviewers since its introduction after London and seems to be stable. > > Please provide review comments either on this list or privately to > draft-ietf-appsawg-nullmx.all@tools.ietf.org > on or before > June 27, 2014. > > Also, if any participant has knowledge of IPR that needs to be > declared on this work, please do so, as required by BCPs 78 and 79. > > Dave Crocker is fulfilling the duties of document shepherd. I read the document, it is a well written document that serves a useful purpose. Thus I support its publication. --------------030900080909020702080905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/06/2014 22:10, Murray S. Kucherawy wrote:
Colleagues,

This note starts a Working Group Last Call for draft-ietf-appsawg-nullmx.  This resurrects work originally proposed in 2006, championed this time by John Levine.  It has had a good number of reviewers since its introduction after London and seems to be stable.

Please provide review comments either on this list or privately to draft-ietf-appsawg-nullmx.all@tools.ietf.org on or before June 27, 2014.

Also, if any participant has knowledge of IPR that needs to be declared on this work, please do so, as required by BCPs 78 and 79.

Dave Crocker is fulfilling the duties of document shepherd.
I read the document, it is a well written document that serves a useful purpose. Thus I support its publication.

--------------030900080909020702080905-- From nobody Thu Jun 12 12:15:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0360D1A026E; Wed, 11 Jun 2014 11:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ0Q8LjsgHdF; Wed, 11 Jun 2014 11:43:26 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A601A0259; Wed, 11 Jun 2014 11:43:25 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WunSh-0009ls-LC; Wed, 11 Jun 2014 14:41:27 -0400 Date: Wed, 11 Jun 2014 14:43:12 -0400 From: John C Klensin To: RFC Errata System , paul.hoffman@vpnc.org Message-ID: <3E3432F3ADA6DBD51AF77A93@JcK-HP8200.jck.com> In-Reply-To: <20140611091932.253F818000E@rfc-editor.org> References: <20140611091932.253F818000E@rfc-editor.org> 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 X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/q7E07ML1igISN0tON4gq5HHusdM X-Mailman-Approved-At: Thu, 12 Jun 2014 12:15:21 -0700 Cc: barryleiba@computer.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [Errata Rejected] RFC6365 (4005) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2014 18:43:28 -0000 Sigh. Folks, I apologize, but I'm very busy, not feeling well, have zero support for any IETF-related or Internet-protocol-development-related work (nothing new -- that has been the case for more than a decade and is partially my choice to avoid conflicts of loyalties), and have to prioritize work. When I get under pressure to get things done, I tend to write a little too quickly and leave things out. On the other hand, when I put in all the details, people attack me for that. In the last week (and, less specifically, the last few weeks), I've also felt, perhaps incorrectly, that issues that affected the PRECIS and URNBIS WGs, and even some policy issues on which I've got some special experience or perspective, should take precedence over a detailed response to the comments about this proposed erratum. Before someone asks, submitting it was consistent with those priorities, promoted by the introduction of "ASCII7" (a term not covered in 6365) in draft-ietf-precis-framework. Given that the hasty and sloppy way in which I wrote the erratum note caused some justifiably-negative comments and a bit of confusion, I didn't want to respond to the various notes, especially Ned's, until I had time to do so adequately. A partially-written response has been on my machine, being worked on at intervals to make it tight and clear, since a few hours after Ned's note was posted. I assume it is now OBE and that, if I want to reopen this, it should be in a new draft erratum that is written as precisely and in as much detail as I can manage. In the interim and partially in my defense, I am perfectly aware of what a "charset" is and equally aware of the use of "US-ASCII" in the charset context. I am also aware of the difference between a coded character set, encodings, and a repertoire, including, btw, the fact that none of our normal, Internet, use of the ASCII repertoire in an eight bit form/encoding (one of at least two that were in use at one time and distinct from two seven bit encodings I'm aware of and at least one nine-bit one) isn't specified anywhere in the ASCII standard. That is one of the two reasons I've encouraged the use of normative references in RFCs to RFC 20 rather than X3.4 (or especially the more recent ANSI/INCITS 4). I have even argued that the choice of "US-ASCII" as a charset identifier was a good idea, precisely because it identified one particular combination of a CCS and encoding. That was precisely the "IETF artifact" I was referring to, obviously without going into enough detail. And, if the term "artifact" wasn't chosen carefully enough from the range of alternatives, I'm sorry, but note that the proposed erratum was intended (I thought clearly) more to flag the issue for readers and as a memory aid for any future update or revision, not as definitive text. I had thought that 6365 itself clearly explained the CCS-Encoding-Repertoire-Charset distinctions and that I was writing in that context. Given the discussion, probably I was wrong and someone should take another look at that. I do note that 6365 does use both "ASCII" and "US-ASCII". I thought that had been done consistent with references to the ASCII standard, repertoire, and CCS and the US-ASCII charset. On rereading somewhat over a week ago, I was less convinced that we were consistent enough about that. That was another thing that prompted the erratum posting. It also helped cause the delay in responding to last week's comments because I wanted to go back through 6365, check every use of either term, and identify which ones were candidates for correction or clarification before creating more misunderstanding. So much for that idea. regretfully, john --On Wednesday, June 11, 2014 02:19 -0700 RFC Errata System wrote: > The following errata report has been rejected for RFC6365, > "Terminology Used in Internationalization in the IETF". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6365&eid=4005 > > -------------------------------------- > Status: Rejected > Type: Editorial > > Reported by: John Klensin > Date Reported: 2014-06-04 > Rejected by: Barry Leiba (IESG) > > Section: GLOBAL > > Original Text > ------------- > US-ASCII > > Corrected Text > -------------- > ASCII > > Notes > ----- > The term "US-ASCII" is an IETF artifact, left over from some > misunderstandings about what "ASCII" referred to (and the > complete absence of CSCII or CASCII, MSCII or MXSCII, BRSCII, > ARSCII, and other "American" coded character sets). It is a > source of confusion for people who come to IETF specifications > with a background in coded character sets and terminology from > other areas or standards bodies and has been warned against > multiple times. It should not have appeared in this document > except possibly with a warning against its use (and the use of > other bogus terms like "ASCII7"). The second author, who is > normally sensitive to the issue, has no idea how this got past > him, even in text picked up from other documents, but supposes > this is what errata are for. > > In any event, there is no such thing as "US-ASCII": the term > is an erroneous and misleading synonym/ substitute for > "ASCII". The reference for the latter is correct, but the > citation anchor should probably be corrected as well. > --VERIFIER NOTES-- > (1) It's clear that this is NOT errata: the use of "US-ASCII" > in the document was quite intentional at the time. > > (2) If (and it's not clear that there's consensus on this) we > think that "US-ASCII" is not the right term, the right answer > is to revise the document. Should that be done, we'd open up > quite a debate about what terminology is right, and why. > Simply replacing all occurrences of "US-ASCII" with "ASCII" is > unlikely to be the answer. Whatever should happen would be > more complicated than that. > > -------------------------------------- > RFC6365 (draft-ietf-appsawg-rfc3536bis-06) > -------------------------------------- > Title : Terminology Used in Internationalization > in the IETF Publication Date : September 2011 > Author(s) : P. Hoffman, J. Klensin > Category : BEST CURRENT PRACTICE > Source : Applications Area Working Group > Area : Applications > Stream : IETF > Verifying Party : IESG > From nobody Fri Jun 13 00:13:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2881A00DD for ; Fri, 13 Jun 2014 00:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soUCKt1Yq935 for ; Fri, 13 Jun 2014 00:13:12 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745A21B28E7 for ; Fri, 13 Jun 2014 00:12:44 -0700 (PDT) Received: from mfilter34-d.gandi.net (mfilter34-d.gandi.net [217.70.178.165]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 8B10317209D for ; Fri, 13 Jun 2014 09:12:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter34-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter34-d.gandi.net (mfilter34-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Qyf67LV3AGN9 for ; Fri, 13 Jun 2014 09:12:41 +0200 (CEST) X-Originating-IP: 10.58.1.142 Received: from webmail.gandi.net (unknown [10.58.1.142]) (Authenticated sender: anything@michielbdejong.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPA id 37B44172085 for ; Fri, 13 Jun 2014 09:12:41 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 13 Jun 2014 09:12:41 +0200 From: "Michiel B. de Jong" To: apps-discuss@ietf.org Message-ID: X-Sender: anything@michielbdejong.com User-Agent: Roundcube Webmail/0.9.5 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0efofViHFIM6X_zvJeEdeaBd-2I Subject: [apps-discuss] Fwd: New Version Notification for draft-dejong-remotestorage-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jun 2014 07:13:15 -0000 FYI: -------- Original Message -------- Subject: New Version Notification for draft-dejong-remotestorage-03.txt Date: 2014-06-13 09:07 From: internet-drafts@ietf.org To: Michiel B. de Jong , "F. Kooman" , F. Kooman , "Michiel B. de Jong" A new version of I-D, draft-dejong-remotestorage-03.txt has been successfully submitted by Michiel B. de Jong and posted to the IETF repository. Name: draft-dejong-remotestorage Revision: 03 Title: remoteStorage Document date: 2014-06-13 Group: Individual Submission Pages: 20 URL: http://www.ietf.org/internet-drafts/draft-dejong-remotestorage-03.txt Status: https://datatracker.ietf.org/doc/draft-dejong-remotestorage/ Htmlized: http://tools.ietf.org/html/draft-dejong-remotestorage-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-dejong-remotestorage-03 Abstract: This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Jun 13 00:22:36 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B921A00B7 for ; Fri, 13 Jun 2014 00:22:34 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJBd_f1Ly7K4 for ; Fri, 13 Jun 2014 00:22:30 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F731A00CA for ; Fri, 13 Jun 2014 00:22:29 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gl10so1242846lab.33 for ; Fri, 13 Jun 2014 00:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fKUGLkNlIhOt35DeybWgwvBvuoY5yej2xH+Q8RxnXxg=; b=D6Be03WGsiXWBFcz6hBgLNwdeqJno/Y6zKrVAw8OlPSLSNnv+1v65L8ZXPJerLNGkg pLsZm2jWcDp97vzbG64ipfYulzf1wUIlIT9FztCY7cFO3R3Hq8GVCx0W4Yb233C14kQ0 SZnaZDOMebYMii+6y6b2wS5torQW83B/x60WtnXq0jrPrs8/DQeYOK1Ku80+dsqtfjlK mn3gbP+yL3ouk8VlZqR3YKq02J+AJBXGkYtfKAivnFu92pwJ1QvU9SXOp9/NA2q3pxcE 7mvlBMliQf9nuP3YPl3PMnmdkjNbcEOWAi2DGHlwq4I8BX+SDCy11yHNCUKOpBlv+lW+ i4PQ== MIME-Version: 1.0 X-Received: by 10.112.180.162 with SMTP id dp2mr368553lbc.11.1402644147242; Fri, 13 Jun 2014 00:22:27 -0700 (PDT) Received: by 10.113.3.139 with HTTP; Fri, 13 Jun 2014 00:22:27 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Jun 2014 09:22:27 +0200 Message-ID: From: Melvin Carvalho To: "Michiel B. de Jong" Content-Type: multipart/alternative; boundary=001a11c34462248b6f04fbb28a2b Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bda-_SzMZIq8kFB97tatqB8yvvc Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-dejong-remotestorage-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jun 2014 07:22:34 -0000 --001a11c34462248b6f04fbb28a2b Content-Type: text/plain; charset=UTF-8 On 13 June 2014 09:12, Michiel B. de Jong wrote: > FYI: > Nice to see you are using JSON-LD I was unable to retrieve a document at: http://remotestorage.io/spec/folder-description Was the intention to have the @context dereferencable? Note: It's also possible to add a @context inline. Examples: http://json-ld.org/playground/ > > -------- Original Message -------- > Subject: New Version Notification for draft-dejong-remotestorage-03.txt > Date: 2014-06-13 09:07 > From: internet-drafts@ietf.org > To: Michiel B. de Jong , "F. Kooman" < > fkooman@tuxed.net>, F. Kooman , "Michiel B. de Jong" < > michiel@michielbdejong.com> > > A new version of I-D, draft-dejong-remotestorage-03.txt > has been successfully submitted by Michiel B. de Jong and posted to the > IETF repository. > > Name: draft-dejong-remotestorage > Revision: 03 > Title: remoteStorage > Document date: 2014-06-13 > Group: Individual Submission > Pages: 20 > URL: http://www.ietf.org/internet-drafts/draft-dejong- > remotestorage-03.txt > Status: https://datatracker.ietf.org/doc/draft-dejong- > remotestorage/ > Htmlized: http://tools.ietf.org/html/draft-dejong-remotestorage-03 > Diff: http://www.ietf.org/rfcdiff?url2=draft-dejong- > remotestorage-03 > > Abstract: > This draft describes a protocol by which client-side applications, > running inside a web browser, can communicate with a data storage > server that is hosted on a different domain name. This way, the > provider of a web application need not also play the role of data > storage provider. The protocol supports storing, retrieving, and > removing individual documents, as well as listing the contents of an > individual folder, and access control is based on bearer tokens. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a11c34462248b6f04fbb28a2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 13 June 2014 09:12, Michiel B. de Jong <anything@mich= ielbdejong.com> wrote:
FYI:

Nice to see you are using JSON-LD

I was u= nable to retrieve a document at:
http://rem=
otestorage.io/spec/folder-description
Was the intention to have th= e @context dereferencable?=C2=A0

Note: It's also possible to ad= d a @context inline.=C2=A0 Examples:

http://json-ld.org/playgroun= d/
=C2=A0

-------- Original Message --------
Subject: New Version Notification for draft-dejong-remotestorage-03.= txt
Date: 2014-06-13 09:07
From: interne= t-drafts@ietf.org
To: Michiel B. de Jong <michiel@michielbdejong.com>, "F. Kooman" &= lt;fkooman@tuxed.net= >, F. Kooman <fkooman@tuxed.net>, "Michiel B. de Jong" <michiel@michielbde= jong.com>

A new version of I-D, draft-dejong-remotestorage-03.txt
has been successfully submitted by Michiel B. de Jong and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-dejong-remotestorage
Revision: =C2=A0 =C2=A0 =C2=A0 03
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0remoteStorage
Document date: =C2=A02014-06-13
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A020
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= ://www.ietf.org/internet-drafts/draft-dejong-remotestorage-03= .txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.iet= f.org/doc/draft-dejong-remotestorage/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/draft-dejong-remotestorage-03
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.iet= f.org/rfcdiff?url2=3Ddraft-dejong-remotestorage-03

Abstract:
=C2=A0 =C2=A0 This draft describes a protocol by which client-side applicat= ions,
=C2=A0 =C2=A0 running inside a web browser, can communicate with a data sto= rage
=C2=A0 =C2=A0 server that is hosted on a different domain name. This way, t= he
=C2=A0 =C2=A0 provider of a web application need not also play the role of = data
=C2=A0 =C2=A0 storage provider. The protocol supports storing, retrieving, = and
=C2=A0 =C2=A0 removing individual documents, as well as listing the content= s of an
=C2=A0 =C2=A0 individual folder, and access control is based on bearer toke= ns.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

--001a11c34462248b6f04fbb28a2b-- From nobody Fri Jun 13 02:12:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A777D1A038C for ; Fri, 13 Jun 2014 02:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DX2AZkMx0dkj for ; Fri, 13 Jun 2014 02:12:29 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 005FD1A030E for ; Fri, 13 Jun 2014 02:12:28 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-a2-539ac07bf9f2 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 04.B3.25910.B70CA935; Fri, 13 Jun 2014 11:12:27 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.10]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Fri, 13 Jun 2014 11:12:26 +0200 From: Salvatore Loreto To: "apps-discuss@ietf.org Discuss" Thread-Topic: Working Group Last Call: draft-ietf-appsawg-email-auth-codes Thread-Index: AQHPhueXfoj+YqPYmEmM2UGVa7d79Q== Date: Fri, 13 Jun 2014 09:12:25 +0000 Message-ID: <96700B03-80FF-4C2B-9887-2C3133EA4E86@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_96700B0380FF4C2B98872C3133EA4E86ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvjW71gVnBBpOXilqsfrmCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGRvXrWMr2C9Y8fr2UaYGxgn8XYycHBICJhK3f79ihrDFJC7c W8/WxcjFISRwlFHi/NTXUM5iRonVk+czgVSxCZhJPH+4BaxDRMBaYv6H3WC2sICrxLkFcxkh 4l4SzX8/skPYehL/5j4Di7MIqEq8uP2XBcTmFbCXmPN6ClgvI9Dm76fWgM1nFhCXuPUEYpeE gIDEkj3noa4TlXj5+B8rhK0ksej2Z6j6ZIm+Q3fZIGYKSpyc+YRlAqPQLCSjZiEpm4WkDCKu I7Fg9yc2CFtbYtnC18ww9pkDj4F6OYBsa4lJ2/SRlSxg5FjFKFqcWpyUm25kpJdalJlcXJyf p5eXWrKJERgrB7f8NtjB+PK54yFGAQ5GJR7eB0qzgoVYE8uKK3MPMUpzsCiJ817UqA4WEkhP LEnNTk0tSC2KLyrNSS0+xMjEwSnVwDjbealaPqPcRY20O1WXRZ8czH/59bOPfhyPVE/7b/kl MbuuC4u5Gcm8MVm57uiriSrKe4N5eD/8PT9ZtyjwCMtT5ZXuS+y5go+KOk9obnI1mrfvPv+W HxvTXbSk2ud/jNgocY8vLmjysYeeErJZF45e+BY+7fj0pl9mNgpnb8TmTppkk79Hc4ISS3FG oqEWc1FxIgCui4uqdgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zXvidpMH41_jexM0lchmO7onrds Subject: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jun 2014 09:12:30 -0000 --_000_96700B0380FF4C2B98872C3133EA4E86ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colleagues, This note starts a Working Group Last Call for draft-ietf-appsawg-email-aut= h-codes-02. There has been a good mail discussion and couple of versions and now it see= ms to be stable and ready. Please provide review comments either on this list or privately to draft-ku= cherawy-email-auth-codes@tools.ietf.org on or before June 30, 2014. Also, if any participant has knowledge of IPR that needs to be declared on = this work, please do so, as required by BCPs 78 and 79. SM is fulfilling the duties of document shepherd. -MSK, APPSAWG co-chair --_000_96700B0380FF4C2B98872C3133EA4E86ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <53B7F9E14B2CC3489DF41A392770C2A6@ericsson.com> Content-Transfer-Encoding: quoted-printable
Colleagues,

This note starts a Working Group Last Cal= l for draft-ietf-appsawg-email-auth-codes-02. 
There has been a good mail discussion and couple of versions and now i= t seems to be
stable and ready.

Please provide review comments either on this list or privately to&nbs= p;draft-kuc= herawy-email-auth-codes@tools.ietf.org on or before June 30, 2014.=

Also, if any participant has knowledge of IPR that needs to be declared on = this work, please do so, as required by BCPs 7= 8 and 79.

SM is fulfilling the duties of document shepherd.

-MSK, APPSAWG co-chair
--_000_96700B0380FF4C2B98872C3133EA4E86ericssoncom_-- From nobody Mon Jun 16 05:47:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F3B1A0009 for ; Mon, 16 Jun 2014 05:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_DsbZcoL1uO for ; Mon, 16 Jun 2014 05:47:47 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F311A0007 for ; Mon, 16 Jun 2014 05:47:47 -0700 (PDT) Received: from [10.53.148.137] ([88.128.80.110]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s5GClWIh022393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 16 Jun 2014 05:47:37 -0700 Message-ID: <539EE723.1040301@dcrocker.net> Date: Mon, 16 Jun 2014 14:46:27 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Apps Discuss , "Murray S. Kucherawy" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 16 Jun 2014 05:47:39 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6Iktj1s5r1IigFgvTwC7TKs2B5E Subject: [apps-discuss] Review of: draft-ietf-appsawg-email-auth-codes-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 16 Jun 2014 12:47:48 -0000 This is an independent review effort on the draft. Review of: Email Authentication Status Codes I-D: draft-ietf-appsawg-email-auth-codes-02 Reviewer: D. Crocker Review Date: 16 June 2014 Summary: As the draft says, it takes note of the established practice of rejecting mail for some specific failures in authentication and seeks to permit rejectors to tell sources about the reason(s) for the rejection. The purpose and style of the draft are straightforward. It's usable in its current form, though there are some tweaks or clarifications I've suggested inline. Detail: > Abstract > > There is at present no way to return a status code to an email client > that indicates a message is being rejected or deferred specifically > because of email authentication failures. This document registers > codes for this purpose. Stray bit of curiosity: There are a number of security-related reasons a message could be rejected. Is there any benefit in considered them as a coherent set? Is there any benefit in at least having the document reference the larger set and then clarify what/why the current draft is restricted. (I did say 'stray'...) > 1. Introduction > > [RFC3463] introduced Enhanced Mail System Status Codes, and [RFC5248] > created an IANA registry for these. > > [RFC6376] and [RFC7208] introduced, respectively, DomainKeys > Identified Mail and Sender Policy Framework, two protocols for > conducting email authentication. Another common email acceptance > test is the reverse Domain Name System check on an email client's IP > address, as described in Section 3 of [RFC7001]. > > The current set of enhanced status codes does not include any code > for indicating that a message is being rejected or deferred due to > local policy reasons related to either of these two mechanisms. This > is potentially useful information to agents that need more than > rudimentary handling information about the reason a message was > rejected on receipt. This document introduces enhanced status codes > for reporting those cases to clients. This is an oddly 'bottom-up' introduction to the purpose of the document. Not 'wrong', just odd, to me. I'd have opened with something like a statement that email authentication methods are a relatively recent addition to the handling process and that it would helpful to be able to send information back to authors/originators about authentication-related failures. That would at least set the stage for the detail the doc immediately dives into. But then, I'm happier with top-down... > 3.1. DKIM Failure Codes > > > Code: X.7.20 > Sample Text: No valid DKIM signature found > Associated basic status code: 5 > Description: This status code is returned when a message > did not contain a valid DKIM signature, > contrary to local policy requirements. > (Note that this violates the advice of > Section 6.1 of RFC6376.) > Reference: [this document]; RFC6376 > Submitter: M. Kucherawy > Change controller: IESG > Code: X.7.21 > Sample Text: No valid author DKIM signature found I suggest phrasing this as "No valid author-aligned DKIM signature, in order to more strongly invoke the DMARC phrasing of things, since there really isn't anything called an "author dkim signature'. > Associated basic status code: 5 > Description: This status code is returned when a message > did not contain a valid DKIM signature > matching the domain(s) found in the From > header field, contrary to local policy > requirements. (Note that this violates the > advice of Section 6.1 of RFC6376.) However it conforms to the dmarc spec... > Reference: [this document]; RFC6376 > Submitter: M. Kucherawy > Change controller: IESG > > 3.2. SPF Failure Codes > > > Code: X.7.22 > Sample Text: SPF validation failed > Associated basic status code: 5 > Description: This status code is returned when a message > failed an SPF check, contrary to local > policy requirements. > Reference: [this document]; RFC7208 > Submitter: M. Kucherawy > Change controller: IESG > > > Code: X.7.23 > Sample Text: SPF validation error > Associated basic status code: 5 > Description: This status code is returned when evaluation > of SPF relative to an arriving message > resulted in an error. > Reference: [this document]; RFC7208 > Submitter: M. Kucherawy > Change controller: IESG There should be text that makes clear when to do .22 and when to do .23. While yes I see some Description differences, it's not obvious to me what the differences mean, in terms of when to apply one or the other. > 4. General Considerations > > By the nature of the Simple Mail Transfer Protocol (SMTP), only one > enhanced status code can be returned for a given exchange between > client and server. However, an operator might decide to defer or > reject a message for a plurality of reasons. Clients receiving these > codes need to consider that the failure reflected by one of these > status codes might not reflect the only reason, or the most important > reason, for non-acceptance of the message or command. > > It is important to note that Section 6.1 of [RFC6376] discourages > special treatment of messages bearing no valid signature. There are > some operators that disregard this advice, a few of which go so far > as to require a valid Author Domain signature in order to accept the 'author domain signature' should be defined explicitly, since it's a key construct. Anyhow, there are operators that do this enforcement even without DMARC????? > message. Moreover, some nascent technologies built atop SPF and DKIM > depend on such authentications. This work does not endorse > configurations that violate DKIM's recommendations, but rather > acknowledges that they do exist and provides for improved and provides -> and merely seeks to provide d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 16 09:36:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCD71A0105 for ; Mon, 16 Jun 2014 09:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb2xZvbxkfY2 for ; Mon, 16 Jun 2014 09:36:03 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B9FB1A00C9 for ; Mon, 16 Jun 2014 09:36:02 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u57so6084271wes.33 for ; Mon, 16 Jun 2014 09:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=soXa0bjlmogzXnWU6UAXlz8NFTvQvNl9CLmyID+g/P0=; b=rgcSmGXetCHmzEJRWhxTJ2xGqg/lwNwJJqImxcQa68KDmudvabvNFolWWRH/zaBawp WPH1eC4saq0tz5yPCvXoNlTZD+P5WGftkv0SVEhYL1YHCF4wH31tbTk9XPHLqk3Dw4lM JlTS2sTnEZmyJQSBBJSJraltipq0A97ugTimXI6Mn0dvds27a7N8pn8NMnRZbh+IhngC dnZbJA8w+ZFuUA50IDtTHFNm0khUA5CkpBiX775jmZUUzqz5DcskmsJ2/JOsBCmQxBll 9k7yLnmiaLD7bW7C6kT58Lm5AeWV/RJYi4lB3TKAzXpNHYFQA2CrX6iESxn8OJ1MIiAG WpNw== MIME-Version: 1.0 X-Received: by 10.194.161.168 with SMTP id xt8mr30417819wjb.35.1402936554470; Mon, 16 Jun 2014 09:35:54 -0700 (PDT) Sender: superuser@gmail.com Received: by 10.180.19.73 with HTTP; Mon, 16 Jun 2014 09:35:54 -0700 (PDT) In-Reply-To: <539EE723.1040301@dcrocker.net> References: <539EE723.1040301@dcrocker.net> Date: Mon, 16 Jun 2014 09:35:54 -0700 X-Google-Sender-Auth: MMUVSFaEhEnfLaAA5IDd-81HXPM Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=089e01419c6af8c3d304fbf69e43 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dR2bCeewdCLPws2AhidyFmVwRig Cc: Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-email-auth-codes-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2014 16:36:05 -0000 --089e01419c6af8c3d304fbf69e43 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 16, 2014 at 5:46 AM, Dave Crocker wrote: > > Abstract > > > > There is at present no way to return a status code to an email client > > that indicates a message is being rejected or deferred specifically > > because of email authentication failures. This document registers > > codes for this purpose. > > Stray bit of curiosity: There are a number of security-related reasons > a message could be rejected. Is there any benefit in considered them as > a coherent set? Is there any benefit in at least having the document > reference the larger set and then clarify what/why the current draft is > restricted. (I did say 'stray'...) > Yes, that's a possibility. One idea was to have the third part of the enhanced status code be a bit mask of the mechanism(s) whose evaluation failed. Consensus appears to be that this is a somewhat interesting idea but there aren't enough cases to warrant doing so now. > Code: X.7.21 > > Sample Text: No valid author DKIM signature found > > I suggest phrasing this as "No valid author-aligned DKIM signature, in > order to more strongly invoke the DMARC phrasing of things, since there > really isn't anything called an "author dkim signature'. > Sure. However, this draft is deliberately independent of DMARC, because we don't know how long that's going to take to make its way to standardization. Meanwhile, even if DMARC never sees the light of RFC-day, these codes are already potentially useful. > > There should be text that makes clear when to do .22 and when to do .23. > While yes I see some Description differences, it's not obvious to me > what the differences mean, in terms of when to apply one or the other. > OK. > > It is important to note that Section 6.1 of [RFC6376] discourages > > special treatment of messages bearing no valid signature. There are > > some operators that disregard this advice, a few of which go so far > > as to require a valid Author Domain signature in order to accept the > > 'author domain signature' should be defined explicitly, since it's a key > construct. > OK. Anyhow, there are operators that do this enforcement even without DMARC????? > There was a major revision done to dkim-filter (OpenDKIM's antecedent) specifically to make this possible, at the request of a large email operator. I presume they're still applying that logic or some variant of it. > message. Moreover, some nascent technologies built atop SPF and DKIM > > depend on such authentications. This work does not endorse > > configurations that violate DKIM's recommendations, but rather > > acknowledges that they do exist and provides for improved > > and provides -> and merely seeks to provide > Done. Thanks! -MSK --089e01419c6af8c3d304fbf69e43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 16, 2014 at 5:46 AM, Dave Crocker <dhc@dcrocke= r.net> wrote:
> Abstract
>
> =C2=A0 =C2=A0There is at present no way to return a status code to an = email client
> =C2=A0 =C2=A0that indicates a message is being rejected or deferred sp= ecifically
> =C2=A0 =C2=A0because of email authentication failures. =C2=A0This docu= ment registers
> =C2=A0 =C2=A0codes for this purpose.

Stray bit of curiosity: =C2=A0There are a number of security-related reason= s
a message could be rejected. =C2=A0Is there any benefit in considered them = as
a coherent set? =C2=A0Is there any benefit in at least having the document<= br> reference the larger set and then clarify what/why the current draft is
restricted. =C2=A0(I did say 'stray'...)

<= /div>
Yes, that's a possibility.=C2=A0 One idea was to have the thi= rd part of the enhanced status code be a bit mask of the mechanism(s) whose= evaluation failed.=C2=A0 Consensus appears to be that this is a somewhat i= nteresting idea but there aren't enough cases to warrant doing so now.<= br>
> =C2=A0 =C2=A0 =C2=A0 Code: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 X.7.21
> =C2=A0 =C2=A0 =C2=A0 Sample Text: =C2=A0 =C2=A0 =C2=A0 =C2=A0No valid = author DKIM signature found

I suggest phrasing this as "No valid author-aligned DKIM signature, in=
order to more strongly invoke the DMARC phrasing of things, since there
really isn't anything called an "author dkim signature'.

Sure.=C2=A0 However, this draft is deliberat= ely independent of DMARC, because we don't know how long that's goi= ng to take to make its way to standardization.=C2=A0 Meanwhile, even if DMA= RC never sees the light of RFC-day, these codes are already potentially use= ful.
=C2=A0

There should be text that makes clear when to do .22 and when to do .23. =C2=A0While yes I see some Description differences, it's not obvious to= me
what the differences mean, in terms of when to apply one or the other.
<= /blockquote>

OK.
=C2=A0
> =C2=A0 =C2=A0It is important to note that Section 6.1 of [RFC6376] dis= courages
> =C2=A0 =C2=A0special treatment of messages bearing no valid signature.= =C2=A0There are
> =C2=A0 =C2=A0some operators that disregard this advice, a few of which= go so far
> =C2=A0 =C2=A0as to require a valid Author Domain signature in order to= accept the

'author domain signature' should be defined explicitly, since it= 9;s a key
construct.

OK.

Anyhow, there are operators that do this enforcement even without DMARC????= ?

There was a major revision done to dk= im-filter (OpenDKIM's antecedent) specifically to make this possible, a= t the request of a large email operator.=C2=A0 I presume they're still = applying that logic or some variant of it.

> =C2=A0 =C2=A0message. =C2=A0Moreover, some nascent technologies built = atop SPF and DKIM
> =C2=A0 =C2=A0depend on such authentications. =C2=A0This work does not = endorse
> =C2=A0 =C2=A0configurations that violate DKIM's recommendations, b= ut rather
> =C2=A0 =C2=A0acknowledges that they do exist and provides for improved=

=C2=A0 =C2=A0and provides -> and merely seeks to provide

Done.=C2=A0 Thanks!

-MSK
--089e01419c6af8c3d304fbf69e43-- From nobody Mon Jun 16 14:40:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F691A026D; Mon, 16 Jun 2014 14:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OX3AwHC1KMsc; Mon, 16 Jun 2014 14:40:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8091A0275; Mon, 16 Jun 2014 14:40:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140616214009.30282.2054.idtracker@ietfa.amsl.com> Date: Mon, 16 Jun 2014 14:40:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oas2kKXejzRwTRlXvCkIPt4LL1k Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-sieve-duplicate-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 21:40:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Sieve Email Filtering: Detecting Duplicate Deliveries Author : Stephan Bosch Filename : draft-ietf-appsawg-sieve-duplicate-07.txt Pages : 13 Date : 2014-06-16 Abstract: This document defines a new test command "duplicate" for the "Sieve" email filtering language. This test adds the ability to detect duplications. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header or other parts of the message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-sieve-duplicate-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 16 14:40:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3134E1A026D for ; Mon, 16 Jun 2014 14:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOpYgSJfY1av; Mon, 16 Jun 2014 14:40:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C1A1A0280; Mon, 16 Jun 2014 14:40:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, ned+ietf@mrochek.com, apps-discuss@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140616214010.30282.78766.idtracker@ietfa.amsl.com> Date: Mon, 16 Jun 2014 14:40:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ke03IKrolL1o5d-_avATB4oG9f0 Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-sieve-duplicate-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 21:40:28 -0000 A new version (-07) has been submitted for draft-ietf-appsawg-sieve-duplicate: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-sieve-duplicate-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-sieve-duplicate-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Jun 17 15:11:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91BE1A01BC for ; Tue, 17 Jun 2014 15:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spzuyPMyvugK for ; Tue, 17 Jun 2014 15:11:14 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 301F71A01AA for ; Tue, 17 Jun 2014 15:11:14 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id E277956493E for ; Tue, 17 Jun 2014 17:11:13 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id C980E60260 for ; Tue, 17 Jun 2014 17:11:13 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdMYZ8F_h4Hx for ; Tue, 17 Jun 2014 17:11:13 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 97BE160531 for ; Tue, 17 Jun 2014 17:11:13 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 77F59602FC for ; Tue, 17 Jun 2014 17:11:13 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oP8CM8ip-zII for ; Tue, 17 Jun 2014 17:11:13 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 5697360260 for ; Tue, 17 Jun 2014 17:11:13 -0500 (CDT) Date: Tue, 17 Jun 2014 17:11:13 -0500 (CDT) From: Franck Martin To: IETF Apps Discuss Message-ID: <216293845.56470.1403043073007.JavaMail.zimbra@peachymango.org> In-Reply-To: <638911626.56445.1403043031661.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_56469_846382339.1403043073006" X-Originating-IP: [216.3.18.37] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-martin-authentication-results-tls-02.txt Thread-Index: oVBbJ3DATSE9pLQFK4OAmL/LdcslPA== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0r-mmAGFDJhFKoWer971x6OIuDg Subject: [apps-discuss] New Version Notification for draft-martin-authentication-results-tls-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jun 2014 22:11:15 -0000 ------=_Part_56469_846382339.1403043073006 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit It would be nice if this draft is picked up by the UTA or APPS WG, tho I have no idea on that process.... It is to be noted this draft requires an upgrade to RFC7001 to allow the use of new ptype. I understand this is a work in progress. There are a few updates, besides ptype format, to allow to record the issuer and the Subject Alternative Name that may contain the information for verifying the host alignement. -------------------- A new version of I-D, draft-martin-authentication-results-tls-02.txt has been successfully submitted by Franck Martin and posted to the IETF repository. Name: draft-martin-authentication-results-tls Revision: 02 Title: Authentication-Results Registration for TLS Document date: 2014-06-17 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-martin-authentication-results-tls-02.txt Status: https://datatracker.ietf.org/doc/draft-martin-authentication-results-tls/ Htmlized: http://tools.ietf.org/html/draft-martin-authentication-results-tls-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-martin-authentication-results-tls-02 Abstract: This memo updates the registry of properties in Authentication- Results: message header fields to allow relaying of the results of an email sent using STARTTLS [RFC3207] or not. ------=_Part_56469_846382339.1403043073006 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It would be nice if this draft is picked= up by the UTA or APPS WG, tho I have no idea on that process....

It is to be noted this draft requires an upgrade to RFC7001= to allow the use of new ptype. I understand this is a work in progress.

There are a few updates, besides ptype format, to al= low to record the issuer and the Subject Alternative Name that may contain = the information for verifying the host alignement.

--------------------
A new version of I-D, draft-martin-authenticatio= n-results-tls-02.txt
has been successfully submitted by Franck Martin an= d posted to the
IETF repository.

Name:     &n= bsp;  draft-martin-authentication-results-tls
Revision:  =  02
Title:        Authentication-Res= ults Registration for TLS
Document date:    2014-06-17Group:        Individual Submission
Pages= :        8
URL:    &nb= sp;       http://www.ietf.org/internet-drafts= /draft-martin-authentication-results-tls-02.txt
Status:   = ;      https://datatracker.ietf.org/doc/draft-mart= in-authentication-results-tls/
Htmlized:     &n= bsp; http://tools.ietf.org/html/draft-martin-authentication-results-tls-02<= br>Diff:           http:/= /www.ietf.org/rfcdiff?url2=3Ddraft-martin-authentication-results-tls-02
=
Abstract:
  This memo updates the registry of properties in Aut= hentication-
  Results: message header fields to allow relaying of = the results of an
  email sent using STARTTLS [RFC3207] or not.
------=_Part_56469_846382339.1403043073006-- From nobody Tue Jun 17 15:36:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD371A019B for ; Tue, 17 Jun 2014 15:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5esWawYMDf2X for ; Tue, 17 Jun 2014 15:36:14 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D251A0188 for ; Tue, 17 Jun 2014 15:36:13 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so161032wiw.11 for ; Tue, 17 Jun 2014 15:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rXsOI/uLMeefzJfzG4RrTlXWNKeOUDjIfr3jZkDWYao=; b=YzJTXpdMDvli9GEGQM18QKBfrMqDrTylV5upy3MLlevLXyv6GOYyElGyWjq1bT2g6P 7JlzAslk4TJ7FZGCfrfx0GrOQVCSXm6OGUJsRDw3dgPw50DvsXFoTIm6CXIbO+2MQYxK hB1i7k9aVaLYsNOrBuAJ9Vubdn+lF4o6Eu/9bT+I+/oPlD63eGl9u4/KnQ+vVWCULizG RcCB7ZztNa0BKapjCpwn7n/11QOTMoZan2a/4bXxUxaWsOYTpxDW1AT/m7yZ19/GiIXl 9C9vNrAROc0XVZow42jTxsLfeei/DvXWszt/7ZhqSLUxwNk6OFKZTc9OvLIkjdOsqyH5 v3xQ== MIME-Version: 1.0 X-Received: by 10.194.91.175 with SMTP id cf15mr42357426wjb.5.1403044572318; Tue, 17 Jun 2014 15:36:12 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Tue, 17 Jun 2014 15:36:11 -0700 (PDT) In-Reply-To: <18924.1402682912@sandelman.ca> References: <18924.1402682912@sandelman.ca> Date: Tue, 17 Jun 2014 15:36:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/mixed; boundary=047d7bfcebc6569c8304fc0fc507 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QFP57jTKId5CWFPU5xUo791tafU Subject: [apps-discuss] Fwd: third call: NomCom 2014-2015 Call for Volunteers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jun 2014 22:36:18 -0000 --047d7bfcebc6569c8304fc0fc507 Content-Type: multipart/alternative; boundary=047d7bfcebc6569c7e04fc0fc505 --047d7bfcebc6569c7e04fc0fc505 Content-Type: text/plain; charset=UTF-8 ---------- Forwarded message ---------- From: Michael Richardson Date: Fri, Jun 13, 2014 at 11:08 AM Subject: third call: NomCom 2014-2015 Call for Volunteers To: ietf@ietf.org This is the third call for volunteers. VOLUNTEER NOW: we need to make 200. The DEADLINE is June 26 to volunteer. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG (including IETF Chair). If your name is on the below, then you have volunteered and are qualified. In addition to those who volunteered by email, it also includes those who indicated their willingness to serve on the IETF90 registration form, and whose eligibility has been confirmed. 54 people were confirmed to be eligible, and 70 people were not confirmed based upon the email they have used to register. Those 124 people have been contacted directly. If you have heard from me, but are not on the list, then there is some problem, and you should have gotten a query from me to determine your eligibility. If you have volunteered and not heard from him, then please resend; it got lost. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. Let's break the 200 volunteer mark again this year! We are at 123 volunteers so far, and WE NEED TO HAVE 200!!! The details of the operation of the nomcom can be found in RFC 3777, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are IETF 85(Atlanta), \ 86(Orlando), \ 87(Berlin), *** ANY THREE! 88(Vancouver), / 89(London) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2015 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: To be confirmed IAB: Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) (names with * have publically indicated they will not serve another term) The primary activity for this nomcom will begin in July 2014 and should be completed in January 2015. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF91 to conduct interviews. Being at IETF90 is useful for training. Being at IETF92 is not essential. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 22, 2013, as follows: To: nomcom-chair-2014@ietf.org Subject: Nomcom 2014-15 Volunteer Please include the following 4 lines the email body (it is simplest if you just include the info); Your Full Name Emails used to register Telephone Current Primary Affiliation You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2014/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org ===== qualified volunteers so far, in alphabetical order by first name ANM Zaheduzzaman Sarker Adam Montville Ari Ker?nen Benson Schliesser Bhumip Khasnabish Bill VerSteeg Carl Williams Carlos Martinez Charles Eckel Charles Perkins Christer Holmberg Craig White DHRUV DHODY Dacheng Zhang Damien Saucez Dapeng Liu Dean Bogdanovic Dimitri Papadimitriou Donald Eastlake Edward Crabbe Emil Ivov Eric Rescorla Eric VYNCKE Fangwei Hu Fatai Zhang Fernando Gont Fred Baker Giles Heron Gonzalo Salgueiro Gregory Mirsky Hannes Gredler Hongyu Li Hosnieh Rafiee Hugo Salgado Hui Deng Iuniana Oprescu Jeff Tantsura John Drake John Jason Brzozowski John Levine John Scudder Jon Hudson Jon Mitchell Karen O'Donoghue Karen Seo Kaveh Ranjbar Klaas Wierenga Larry Masinter Lars Eggert Lee Howard Lei Zhu Li Xue Linda Dunbar Lingli Deng Louis (Lou) Berger Luca Martini Lucy Lynch Lucy Yong Luigi Iannone Mach Chen Marcelo Bagnulo Mark Townsley Matt Lepinski Matthew Bocci Mehmet Ersue Melinda Shore Michael Jones Min Ye Mingui Zhang Ning Zong Ole Troan Pascal Thubert Paul Hoffman Peter Lothberg Peter Yee QIN WU Ralph Droms Ron Bonica Ross Callon Ross Finlayson Russ White Sam K. Aldrin Samuel Weiler Sandeep Kumar Sanjay Mishra Scott Mansfield Sheng JIANG Shucheng Liu Simon Pietro Romano Stan Ratliff Stephan Friedl Stephan Wenger Stephen Kent Stewart Bryant Stig Venaas Suhas Nandakumar Suresh Krishnan Susan Hares Thomas Walsh Tim Wicinski Tissa Senevirathne Toerless Eckert Tony Hansen Ulrich Herberg Varun Singh Wassim Haddad Xiaohu XU Yi Zhao Yizhou Li Yong Cui Yuanlong Jiang Yunfei Zhang Zhaohui Zhang Zhen Cao iuniana oprescu -- Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org --047d7bfcebc6569c7e04fc0fc505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


---------- Forwarded me= ssage ----------
From: Michael Richardson<= /b> <mcr+= nomcom@sandelman.ca>
Date: Fri, Jun 13, 2014 at 11:08 AM
Subject: third call: NomCom 2014-201= 5 Call for Volunteers
To: ietf@ietf.org=



This is the third call for volunteers.
VOLUNTEER NOW: we need to make 200.
The DEADLINE is June 26 to volunteer.

The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB,=
and the IESG (including IETF Chair).

If your name is on the below, then you have volunteered and are qualified.<= br> In addition to those who volunteered by email, it also includes those who indicated their willingness to serve on the IETF90 registration form, and whose eligibility has been confirmed. =C2=A054 people were confirmed to be<= br> eligible, and 70 people were not confirmed based upon the email they have used to register. =C2=A0 Those 124 people have been contacted directly.

If you have heard from me, but are not on the list, then there is some
problem, and you should have gotten a query from me to determine your
eligibility.

If you have volunteered and not heard from him, then please resend;
it got lost.

Ten voting members for the nomcom are selected in a verifiably random
way from a pool of volunteers. The more volunteers, the better chance we ha= ve
of choosing a random yet representative cross section of the IETF populatio= n.

Let's break the 200 volunteer mark again this year!
We are at 123 volunteers so far, and WE NEED TO HAVE 200!!!

The details of the operation of the nomcom can be found in RFC 3777,
and BCP10/RFC3797 details the selection algorithm.

Volunteers must have attended 3 of the past 5 IETF meetings. =C2=A0As speci= fied in
RFC 3777, that means three out of the five past meetings up to the time thi= s
email announcement goes out to start the solicitation of volunteers.
The five meetings out of which you must have attended *three*
are IETF 85(Atlanta), =C2=A0 =C2=A0 =C2=A0\
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A086(Orlando), =C2=A0 =C2=A0 =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A087(Berlin), =C2=A0 =C2=A0 =C2=A0 =C2=A0 *= ** ANY THREE!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A088(Vancouver), =C2=A0 =C2=A0 /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A089(London) =C2=A0 =C2=A0 =C2=A0 =C2=A0/
If you qualify, please volunteer. =C2=A0 However, much as we want this, bef= ore you
decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible.

The list of people and posts whose terms end with the March 2015 IETF
meeting, and thus the positions for which this nomcom is responsible, are
IAOC:
To be confirmed

IAB:
Joel Halpern
Russ Housley
Eliot Lear
Xing Li
Andrew Sullivan
Dave Thaler

IESG:
Pete Resnick (Applications)
Ted Lemon (Internet)
Joel Jaeggli (Operations and Management)
Richard Barnes (RAI)
Adrian Farrel* (Routing)
Stephen Farrell (Security)
Spencer Dawkins (Transport)
Jari Arkko (Gen)

(names with * have publically indicated they will not serve another term)
The primary activity for this nomcom will begin in July 2014 and should be<= br> completed in January 2015. =C2=A0 The nomcom will have regularly scheduled<= br> conference calls to ensure progress. (We might dogfood WebRTC)
There will be activities to collect requirements from the community, review=
candidate questionnaires, review feedback from community members about
candidates, and talk to candidates.

Thus, being a nomcom member does require some time commitment; but it is al= so
a very rewarding experience.

It is very important that you be able to attend IETF91 to conduct interview= s.
Being at IETF90 is useful for training. =C2=A0Being at IETF92 is not essent= ial.

Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours)<= br> June 22, 2013, as follows:

To: nomcom-chair-2014@ietf.or= g
Subject: Nomcom 2014-15 Volunteer

Please include the following 4 lines the email body (it is simplest
if you just include the info);

Your Full Name
Emails used to register
Telephone
Current Primary Affiliation

You should expect an email response from me within 3 business days stating<= br> whether or not you are qualified. =C2=A0If you don't receive this respo= nse,
please re-send your email with the tag "RESEND"" added to th= e subject line.

If you are not yet sure if you would like to volunteer, please consider
that nomcom members play a very important role in shaping the leadership of the IETF. =C2=A0Questions by email or voice are welcome.
Volunteering for the nomcom is a great way to contribute to the IETF!

You can find a detailed timeline on the nomcom web site at:
=C2=A0 =C2=A0 https://datatracker.ietf.org/nomcom/2014/

I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process,
within the next couple weeks.

Thank you!
Michael Richardson
mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org

=3D=3D=3D=3D=3D =C2=A0qualified volunteers so far, in alphabetical order by= first name
ANM Zaheduzzaman Sarker
Adam Montville
Ari Ker?nen
Benson Schliesser
Bhumip Khasnabish
Bill VerSteeg
Carl Williams
Carlos Martinez
Charles Eckel
Charles Perkins
Christer Holmberg
Craig White
DHRUV DHODY
Dacheng Zhang
Damien Saucez
Dapeng Liu
Dean Bogdanovic
Dimitri Papadimitriou
Donald Eastlake
Edward Crabbe
Emil Ivov
Eric Rescorla
Eric VYNCKE
Fangwei Hu
Fatai Zhang
Fernando Gont
Fred Baker
Giles Heron
Gonzalo Salgueiro
Gregory Mirsky
Hannes Gredler
Hongyu Li
Hosnieh Rafiee
Hugo Salgado
Hui Deng
Iuniana Oprescu
Jeff Tantsura
John Drake
John Jason Brzozowski
John Levine
John Scudder
Jon Hudson
Jon Mitchell
Karen O'Donoghue
Karen Seo
Kaveh Ranjbar
Klaas Wierenga
Larry Masinter
Lars Eggert
Lee Howard
Lei Zhu
Li Xue
Linda Dunbar
Lingli Deng
Louis (Lou) Berger
Luca Martini
Lucy Lynch
Lucy Yong
Luigi Iannone
Mach Chen
Marcelo Bagnulo
Mark Townsley
Matt Lepinski
Matthew Bocci
Mehmet Ersue
Melinda Shore
Michael Jones
Min Ye
Mingui Zhang
Ning Zong
Ole Troan
Pascal Thubert
Paul Hoffman
Peter Lothberg
Peter Yee
QIN WU
Ralph Droms
Ron Bonica
Ross Callon
Ross Finlayson
Russ White
Sam K. Aldrin
Samuel Weiler
Sandeep Kumar
Sanjay Mishra
Scott Mansfield
Sheng JIANG
Shucheng Liu
Simon Pietro Romano
Stan Ratliff
Stephan Friedl
Stephan Wenger
Stephen Kent
Stewart Bryant
Stig Venaas
Suhas Nandakumar
Suresh Krishnan
Susan Hares
Thomas Walsh
Tim Wicinski
Tissa Senevirathne
Toerless Eckert
Tony Hansen
Ulrich Herberg
Varun Singh
Wassim Haddad
Xiaohu XU
Yi Zhao
Yizhou Li
Yong Cui
Yuanlong Jiang
Yunfei Zhang
Zhaohui Zhang
Zhen Cao
iuniana oprescu


--
Michael Richardson
mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org




--047d7bfcebc6569c7e04fc0fc505-- --047d7bfcebc6569c8304fc0fc507 Content-Type: application/pgp-signature Content-Disposition: attachment Content-Transfer-Encoding: base64 X-Attachment-Id: dd79a84fbec698a8_0.1 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuMTIgKEdO VS9MaW51eCkNCg0KaVFFVkF3VUJVNXMrSFlDTGNQdmQwTjFsQVFJU3lnZ0FsamlQZlovaXRDbDIz V0FrTW9pcjlYS0ZkOVRBSFN4cw0KaGIyQmU1azdmZVI1QSszTEVrL3JnSCtCc1RqbnVYOGNjQW1u aVZqTTg4LzE0L1lsTTlxNkhlTnpZckNlZFcwdw0KWDBGeXNoTjAxVXBIeWx3aGd4d2VTMUwyclEx TXl3c0prV3J4K1ROc2xGMk02dEhzL1I5cVdjY0MwK29iRWQrQQ0KY1I2amtnelhiaUFsTnlzR2lt V3FwenhscnRhdWtRa3dHMy9saVZqNDVMRmxNZmlFVjFVV0t1NUtSRnl4NFdSTg0KQXovOTFJRkU2 OUtmTkZKbUxieDFSTGdsWXkreDk0UGpZbXprWFRXN1NJdHdhV1R1L0NvalJvWnE5cXE2VSs0Rg0K OURod00xVTBQNTM5ZDJ4TjBGdFlBTjVKOFZrNi8zYmZUSlFuUjhNSE1HbUU4QVNUNDU1S0F3PT0N Cj0vMFdPDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0= --047d7bfcebc6569c8304fc0fc507-- From nobody Tue Jun 17 16:15:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF9E1A0089 for ; Tue, 17 Jun 2014 16:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkKpl_mVbhbx for ; Tue, 17 Jun 2014 16:14:57 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96471A00A2 for ; Tue, 17 Jun 2014 16:14:57 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.0.980.1; Tue, 17 Jun 2014 23:14:56 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.253]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.253]) with mapi id 15.00.0980.000; Tue, 17 Jun 2014 23:14:56 +0000 From: Terry Zink To: Franck Martin , IETF Apps Discuss Thread-Topic: New Version Notification for draft-martin-authentication-results-tls-02.txt Thread-Index: Ac+KgdWGTSE9pLQFK4OAmL/LdcslPAAABboQ Date: Tue, 17 Jun 2014 23:14:55 +0000 Message-ID: <31422d7d5bf645ab964cd37cef08681a@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.156] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(377454003)(199002)(189002)(377424004)(33646001)(65816002)(56816006)(76482001)(59766002)(56776002)(63696004)(46102001)(79102001)(16236675004)(64706001)(50986002)(20776003)(2656002)(15202345003)(51856002)(94316002)(83072002)(47736002)(53806002)(47976003)(93136001)(47446003)(49866002)(54316003)(95416001)(54356002)(83322001)(19580405001)(97336001)(90146001)(93516002)(92566001)(85852003)(105586002)(81816001)(81686001)(74502001)(77982001)(15975445006)(87266001)(31966008)(4396001)(87936001)(21056001)(81342001)(74366001)(80022001)(99396002)(66066001)(98676001)(76786001)(76796001)(81542001)(76176001)(74876001)(97186001)(19300405004)(74662001)(69226001)(94946001)(19580395003)(19625215002)(101416001)(85306003)(74706001)(95666004)(77096002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_31422d7d5bf645ab964cd37cef08681aBL2SR01MB605namsdf01sdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bcs2vXi1URj--gqlWlSUEaIvfQk Subject: Re: [apps-discuss] New Version Notification for draft-martin-authentication-results-tls-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jun 2014 23:15:02 -0000 --_000_31422d7d5bf645ab964cd37cef08681aBL2SR01MB605namsdf01sdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T29wcywgZGlkbuKAmXQgc2Nyb2xsIGRvd24gZmFyIGVub3VnaCBpbiB0aGUgc3BlYy4gTmV2ZXIg bWluZC4NCg0KLS0gVGVycnkNCg0KRnJvbTogVGVycnkgWmluaw0KU2VudDogVHVlc2RheSwgSnVu ZSAxNywgMjAxNCA0OjE0IFBNDQpUbzogJ0ZyYW5jayBNYXJ0aW4nOyBJRVRGIEFwcHMgRGlzY3Vz cw0KU3ViamVjdDogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWFydGlu LWF1dGhlbnRpY2F0aW9uLXJlc3VsdHMtdGxzLTAyLnR4dA0KDQpJdCB3b3VsZCBiZSBoZWxwZnVs IGlmIHlvdSBwdXQgc29tZSBzYW1wbGUgQXV0aGVudGljYXRpb24tUmVzdWx0cyBoZWFkZXJzIGlu dG8gdGhlIGRyYWZ0Lg0KDQotLSBUZXJyeQ0KDQpGcm9tOiBhcHBzLWRpc2N1c3MgW21haWx0bzph cHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEZyYW5jayBNYXJ0aW4N ClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTcsIDIwMTQgMzoxMSBQTQ0KVG86IElFVEYgQXBwcyBEaXNj dXNzDQpTdWJqZWN0OiBbYXBwcy1kaXNjdXNzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LW1hcnRpbi1hdXRoZW50aWNhdGlvbi1yZXN1bHRzLXRscy0wMi50eHQNCg0KSXQgd291 bGQgYmUgbmljZSBpZiB0aGlzIGRyYWZ0IGlzIHBpY2tlZCB1cCBieSB0aGUgVVRBIG9yIEFQUFMg V0csIHRobyBJIGhhdmUgbm8gaWRlYSBvbiB0aGF0IHByb2Nlc3MuLi4uDQoNCkl0IGlzIHRvIGJl IG5vdGVkIHRoaXMgZHJhZnQgcmVxdWlyZXMgYW4gdXBncmFkZSB0byBSRkM3MDAxIHRvIGFsbG93 IHRoZSB1c2Ugb2YgbmV3IHB0eXBlLiBJIHVuZGVyc3RhbmQgdGhpcyBpcyBhIHdvcmsgaW4gcHJv Z3Jlc3MuDQoNClRoZXJlIGFyZSBhIGZldyB1cGRhdGVzLCBiZXNpZGVzIHB0eXBlIGZvcm1hdCwg dG8gYWxsb3cgdG8gcmVjb3JkIHRoZSBpc3N1ZXIgYW5kIHRoZSBTdWJqZWN0IEFsdGVybmF0aXZl IE5hbWUgdGhhdCBtYXkgY29udGFpbiB0aGUgaW5mb3JtYXRpb24gZm9yIHZlcmlmeWluZyB0aGUg aG9zdCBhbGlnbmVtZW50Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LW1hcnRpbi1hdXRoZW50aWNhdGlvbi1yZXN1bHRzLXRscy0wMi50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRnJhbmNrIE1hcnRpbiBhbmQgcG9zdGVk IHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgZHJhZnQtbWFydGluLWF1 dGhlbnRpY2F0aW9uLXJlc3VsdHMtdGxzDQpSZXZpc2lvbjogICAgMDINClRpdGxlOiAgICAgICAg QXV0aGVudGljYXRpb24tUmVzdWx0cyBSZWdpc3RyYXRpb24gZm9yIFRMUw0KRG9jdW1lbnQgZGF0 ZTogICAgMjAxNC0wNi0xNw0KR3JvdXA6ICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBh Z2VzOiAgICAgICAgOA0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LW1hcnRpbi1hdXRoZW50aWNhdGlvbi1yZXN1bHRzLXRscy0wMi50eHQN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1t YXJ0aW4tYXV0aGVudGljYXRpb24tcmVzdWx0cy10bHMvDQpIdG1saXplZDogICAgICAgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFydGluLWF1dGhlbnRpY2F0aW9uLXJlc3VsdHMt dGxzLTAyDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtbWFydGluLWF1dGhlbnRpY2F0aW9uLXJlc3VsdHMtdGxzLTAyDQoNCkFic3RyYWN0Og0K ICBUaGlzIG1lbW8gdXBkYXRlcyB0aGUgcmVnaXN0cnkgb2YgcHJvcGVydGllcyBpbiBBdXRoZW50 aWNhdGlvbi0NCiAgUmVzdWx0czogbWVzc2FnZSBoZWFkZXIgZmllbGRzIHRvIGFsbG93IHJlbGF5 aW5nIG9mIHRoZSByZXN1bHRzIG9mIGFuDQogIGVtYWlsIHNlbnQgdXNpbmcgU1RBUlRUTFMgW1JG QzMyMDddIG9yIG5vdC4NCg== --_000_31422d7d5bf645ab964cd37cef08681aBL2SR01MB605namsdf01sdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOmR0PSJ1dWlkOkMyRjQxMDEwLTY1QjMtMTFkMS1B MjlGLTAwQUEwMEMxNDg4MiIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0i TWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYz QzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+T29wcywgZGlkbuKAmXQgc2Nyb2xs IGRvd24gZmFyIGVub3VnaCBpbiB0aGUgc3BlYy4gTmV2ZXIgbWluZC48bzpwPjwvbzpwPjwvc3Bh bj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4tLSBUZXJyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVycnkgWmluaw0KPGJyPg0K PGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMTcsIDIwMTQgNDoxNCBQTTxicj4NCjxiPlRvOjwv Yj4gJ0ZyYW5jayBNYXJ0aW4nOyBJRVRGIEFwcHMgRGlzY3Vzczxicj4NCjxiPlN1YmplY3Q6PC9i PiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tYXJ0aW4tYXV0aGVudGlj YXRpb24tcmVzdWx0cy10bHMtMDIudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5J dCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBwdXQgc29tZSBzYW1wbGUgQXV0aGVudGljYXRpb24t UmVzdWx0cyBoZWFkZXJzIGludG8gdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LS0gVGVycnk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGFwcHMtZGlzY3VzcyBbPGEgaHJlZj0ibWFpbHRvOmFw cHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5GcmFuY2sgTWFydGluPGJyPg0KPGI+ U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMTcsIDIwMTQgMzoxMSBQTTxicj4NCjxiPlRvOjwvYj4g SUVURiBBcHBzIERpc2N1c3M8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2FwcHMtZGlzY3Vzc10gTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tYXJ0aW4tYXV0aGVudGljYXRpb24tcmVz dWx0cy10bHMtMDIudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkl0IHdvdWxk IGJlIG5pY2UgaWYgdGhpcyBkcmFmdCBpcyBwaWNrZWQgdXAgYnkgdGhlIFVUQSBvciBBUFBTIFdH LCB0aG8gSSBoYXZlIG5vIGlkZWEgb24gdGhhdCBwcm9jZXNzLi4uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SXQgaXMgdG8gYmUgbm90ZWQg dGhpcyBkcmFmdCByZXF1aXJlcyBhbiB1cGdyYWRlIHRvIFJGQzcwMDEgdG8gYWxsb3cgdGhlIHVz ZSBvZiBuZXcgcHR5cGUuIEkgdW5kZXJzdGFuZCB0aGlzIGlzIGEgd29yayBpbiBwcm9ncmVzcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRo ZXJlIGFyZSBhIGZldyB1cGRhdGVzLCBiZXNpZGVzIHB0eXBlIGZvcm1hdCwgdG8gYWxsb3cgdG8g cmVjb3JkIHRoZSBpc3N1ZXIgYW5kIHRoZSBTdWJqZWN0IEFsdGVybmF0aXZlIE5hbWUgdGhhdCBt YXkgY29udGFpbiB0aGUgaW5mb3JtYXRpb24gZm9yIHZlcmlmeWluZyB0aGUgaG9zdCBhbGlnbmVt ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+LS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtbWFydGluLWF1dGhlbnRpY2F0aW9uLXJlc3VsdHMtdGxzLTAyLnR4dDxicj4N CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRnJhbmNrIE1hcnRpbiBhbmQgcG9z dGVkIHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7ZHJhZnQtbWFydGluLWF1dGhlbnRpY2F0aW9u LXJlc3VsdHMtdGxzPGJyPg0KUmV2aXNpb246Jm5ic3A7Jm5ic3A7ICZuYnNwOzAyPGJyPg0KVGl0 bGU6Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtBdXRoZW50aWNhdGlvbi1S ZXN1bHRzIFJlZ2lzdHJhdGlvbiBmb3IgVExTPGJyPg0KRG9jdW1lbnQgZGF0ZTombmJzcDsmbmJz cDsgJm5ic3A7MjAxNC0wNi0xNzxicj4NCkdyb3VwOiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDs4PGJyPg0KVVJMOiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYXJ0aW4tYXV0aGVudGlj YXRpb24tcmVzdWx0cy10bHMtMDIudHh0Ij4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LW1hcnRpbi1hdXRoZW50aWNhdGlvbi1yZXN1bHRzLXRscy0wMi50eHQ8L2E+ PGJyPg0KU3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYXJ0 aW4tYXV0aGVudGljYXRpb24tcmVzdWx0cy10bHMvIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LW1hcnRpbi1hdXRoZW50aWNhdGlvbi1yZXN1bHRzLXRscy88L2E+PGJy Pg0KSHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hcnRpbi1hdXRoZW50aWNhdGlvbi1y ZXN1bHRzLXRscy0wMiI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXJ0aW4t YXV0aGVudGljYXRpb24tcmVzdWx0cy10bHMtMDI8L2E+PGJyPg0KRGlmZjombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbWFydGluLWF1dGhlbnRpY2F0 aW9uLXJlc3VsdHMtdGxzLTAyIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LW1hcnRpbi1hdXRoZW50aWNhdGlvbi1yZXN1bHRzLXRscy0wMjwvYT48YnI+DQo8YnI+DQpB YnN0cmFjdDo8YnI+DQombmJzcDsgVGhpcyBtZW1vIHVwZGF0ZXMgdGhlIHJlZ2lzdHJ5IG9mIHBy b3BlcnRpZXMgaW4gQXV0aGVudGljYXRpb24tPGJyPg0KJm5ic3A7IFJlc3VsdHM6IG1lc3NhZ2Ug aGVhZGVyIGZpZWxkcyB0byBhbGxvdyByZWxheWluZyBvZiB0aGUgcmVzdWx0cyBvZiBhbjxicj4N CiZuYnNwOyBlbWFpbCBzZW50IHVzaW5nIFNUQVJUVExTIFtSRkMzMjA3XSBvciBub3QuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_31422d7d5bf645ab964cd37cef08681aBL2SR01MB605namsdf01sdf_-- From nobody Tue Jun 17 17:52:44 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BB11A01A5 for ; Tue, 17 Jun 2014 17:52:43 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fipA0TpCt5gl for ; Tue, 17 Jun 2014 17:52:41 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33BF21A017F for ; Tue, 17 Jun 2014 17:52:41 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so98527wgg.8 for ; Tue, 17 Jun 2014 17:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OCNsal3rGYxTwjjg8OIZXj7szi4HUr66hG1S6uaXNJA=; b=cN89Q19KPRKVXc4nN5TzBhamyM3KUepvfJHAbl5KjFiFtR4m+F4NkYYxuadcrtDuGt RvF0sI+EtEbRN0yJfVAowntfZg0j6fgQdndGRiAo8WGIRXWS5ljANsG6g2V5J5U6IIxy SSAPSt7w1qIJ3NywkA9BLkS3ZWS8Si14oCnd39C7phYZyNVD6bhEJZb6itdV6LFaeu0o 26y6HUr/jmwrRJFbCjcVbJ2Kjtn/0mb/YPp4MAVvr4PYrzXBrPoH63k0fWGIELFwz1xo fiEy8fkQ8S3FZqC5CqmF+mR/945FiIib5QU+oYwQxI8nigo4Pg1hrY2c8XJFDDgXIG1F 4/Vg== MIME-Version: 1.0 X-Received: by 10.181.8.67 with SMTP id di3mr256434wid.8.1403052759633; Tue, 17 Jun 2014 17:52:39 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Tue, 17 Jun 2014 17:52:39 -0700 (PDT) In-Reply-To: <216293845.56470.1403043073007.JavaMail.zimbra@peachymango.org> References: <638911626.56445.1403043031661.JavaMail.zimbra@peachymango.org> <216293845.56470.1403043073007.JavaMail.zimbra@peachymango.org> Date: Tue, 17 Jun 2014 17:52:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=001a1134d24456d45404fc11ad1d Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wYIF2gsUy4SWis1T7WwJVNrBCLA Cc: IETF Apps Discuss Subject: Re: [apps-discuss] New Version Notification for draft-martin-authentication-results-tls-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2014 00:52:43 -0000 --001a1134d24456d45404fc11ad1d Content-Type: text/plain; charset=UTF-8 Yeah, we need to do this first: http://datatracker.ietf.org/doc/draft-kucherawy-authres-ptypes-registry/ -MSK On Tue, Jun 17, 2014 at 3:11 PM, Franck Martin wrote: > It would be nice if this draft is picked up by the UTA or APPS WG, tho I > have no idea on that process.... > > It is to be noted this draft requires an upgrade to RFC7001 to allow the > use of new ptype. I understand this is a work in progress. > > There are a few updates, besides ptype format, to allow to record the > issuer and the Subject Alternative Name that may contain the information > for verifying the host alignement. > > -------------------- > A new version of I-D, draft-martin-authentication-results-tls-02.txt > has been successfully submitted by Franck Martin and posted to the > IETF repository. > > Name: draft-martin-authentication-results-tls > Revision: 02 > Title: Authentication-Results Registration for TLS > Document date: 2014-06-17 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-martin-authentication-results-tls-02.txt > Status: > https://datatracker.ietf.org/doc/draft-martin-authentication-results-tls/ > Htmlized: > http://tools.ietf.org/html/draft-martin-authentication-results-tls-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-martin-authentication-results-tls-02 > > Abstract: > This memo updates the registry of properties in Authentication- > Results: message header fields to allow relaying of the results of an > email sent using STARTTLS [RFC3207] or not. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --001a1134d24456d45404fc11ad1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 17, 2014 at 3:11 PM, Franck Martin <franck@pea= chymango.org> wrote:
It would be nice if t= his draft is picked up by the UTA or APPS WG, tho I have no idea on that pr= ocess....

It is to be noted this draft requires an upgrade to RFC= 7001 to allow the use of new ptype. I understand this is a work in progress= .

There are a few updates, besides ptype format, t= o allow to record the issuer and the Subject Alternative Name that may cont= ain the information for verifying the host alignement.

--------------------
A new version of I-D, draft-m= artin-authentication-results-tls-02.txt
has been successfully submitted = by Franck Martin and posted to the
IETF repository.

Name:=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0draft-martin-authentication-results-tls
Revision:=C2=A0=C2=A0 =C2=A002
Title:=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2= =A0Authentication-Results Registration for TLS
Document date:=C2=A0=C2= =A0 =C2=A02014-06-17
Group:=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0Individ= ual Submission
Pages:=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A08
URL:=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/internet-drafts/draft-martin= -authentication-results-tls-02.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/draft-martin-authentication-re= sults-tls/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-martin-authentication-result= s-tls-02
Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-martin-a= uthentication-results-tls-02

Abstract:
=C2=A0 This memo updat= es the registry of properties in Authentication-
=C2=A0 Results: message header fields to allow relaying of the results of a= n
=C2=A0 email sent using STARTTLS [RFC3207] or not.
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--001a1134d24456d45404fc11ad1d-- From nobody Tue Jun 17 19:50:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31F61A00FB for ; Tue, 17 Jun 2014 19:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXFbFBG434qe for ; Tue, 17 Jun 2014 19:50:46 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 207341A00F8 for ; Tue, 17 Jun 2014 19:50:45 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.0.980.1; Tue, 17 Jun 2014 23:14:07 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.253]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.253]) with mapi id 15.00.0980.000; Tue, 17 Jun 2014 23:14:07 +0000 From: Terry Zink To: Franck Martin , IETF Apps Discuss Thread-Topic: New Version Notification for draft-martin-authentication-results-tls-02.txt Thread-Index: oVBbJ3DATSE9pLQFK4OAmL/LdcslPP5etMkw Date: Tue, 17 Jun 2014 23:14:06 +0000 Message-ID: <10859145ea204fe084ec2e0811da657a@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <638911626.56445.1403043031661.JavaMail.zimbra@peachymango.org> <216293845.56470.1403043073007.JavaMail.zimbra@peachymango.org> In-Reply-To: <216293845.56470.1403043073007.JavaMail.zimbra@peachymango.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.156] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(377454003)(199002)(189002)(377424004)(33646001)(65816002)(56816006)(76482001)(59766002)(56776002)(63696004)(46102001)(79102001)(16236675004)(64706001)(50986002)(20776003)(2656002)(15202345003)(51856002)(94316002)(83072002)(47736002)(53806002)(47976003)(93136001)(47446003)(49866002)(54316003)(95416001)(54356002)(83322001)(19580405001)(97336001)(90146001)(93516002)(92566001)(85852003)(105586002)(81816001)(81686001)(74502001)(77982001)(15975445006)(87266001)(31966008)(4396001)(87936001)(21056001)(81342001)(74366001)(80022001)(99396002)(66066001)(98676001)(76786001)(76796001)(81542001)(74876001)(97186001)(19300405004)(74662001)(69226001)(94946001)(19580395003)(19625215002)(101416001)(85306003)(74706001)(95666004)(77096002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_10859145ea204fe084ec2e0811da657aBL2SR01MB605namsdf01sdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Rfk5cA6VmeVV8x6nuUAekDwf7ks Subject: Re: [apps-discuss] New Version Notification for draft-martin-authentication-results-tls-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2014 02:50:50 -0000 --_000_10859145ea204fe084ec2e0811da657aBL2SR01MB605namsdf01sdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgcHV0IHNvbWUgc2FtcGxlIEF1dGhlbnRpY2F0aW9u LVJlc3VsdHMgaGVhZGVycyBpbnRvIHRoZSBkcmFmdC4NCg0KLS0gVGVycnkNCg0KRnJvbTogYXBw cy1kaXNjdXNzIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBGcmFuY2sgTWFydGluDQpTZW50OiBUdWVzZGF5LCBKdW5lIDE3LCAyMDE0IDM6MTEgUE0N ClRvOiBJRVRGIEFwcHMgRGlzY3Vzcw0KU3ViamVjdDogW2FwcHMtZGlzY3Vzc10gTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tYXJ0aW4tYXV0aGVudGljYXRpb24tcmVzdWx0cy10 bHMtMDIudHh0DQoNCkl0IHdvdWxkIGJlIG5pY2UgaWYgdGhpcyBkcmFmdCBpcyBwaWNrZWQgdXAg YnkgdGhlIFVUQSBvciBBUFBTIFdHLCB0aG8gSSBoYXZlIG5vIGlkZWEgb24gdGhhdCBwcm9jZXNz Li4uLg0KDQpJdCBpcyB0byBiZSBub3RlZCB0aGlzIGRyYWZ0IHJlcXVpcmVzIGFuIHVwZ3JhZGUg dG8gUkZDNzAwMSB0byBhbGxvdyB0aGUgdXNlIG9mIG5ldyBwdHlwZS4gSSB1bmRlcnN0YW5kIHRo aXMgaXMgYSB3b3JrIGluIHByb2dyZXNzLg0KDQpUaGVyZSBhcmUgYSBmZXcgdXBkYXRlcywgYmVz aWRlcyBwdHlwZSBmb3JtYXQsIHRvIGFsbG93IHRvIHJlY29yZCB0aGUgaXNzdWVyIGFuZCB0aGUg U3ViamVjdCBBbHRlcm5hdGl2ZSBOYW1lIHRoYXQgbWF5IGNvbnRhaW4gdGhlIGluZm9ybWF0aW9u IGZvciB2ZXJpZnlpbmcgdGhlIGhvc3QgYWxpZ25lbWVudC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tYXJ0aW4tYXV0aGVudGljYXRpb24tcmVz dWx0cy10bHMtMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEZyYW5j ayBNYXJ0aW4gYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAg ICAgIGRyYWZ0LW1hcnRpbi1hdXRoZW50aWNhdGlvbi1yZXN1bHRzLXRscw0KUmV2aXNpb246ICAg IDAyDQpUaXRsZTogICAgICAgIEF1dGhlbnRpY2F0aW9uLVJlc3VsdHMgUmVnaXN0cmF0aW9uIGZv ciBUTFMNCkRvY3VtZW50IGRhdGU6ICAgIDIwMTQtMDYtMTcNCkdyb3VwOiAgICAgICAgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgIDgNClVSTDogICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYXJ0aW4tYXV0aGVudGljYXRpb24t cmVzdWx0cy10bHMtMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtbWFydGluLWF1dGhlbnRpY2F0aW9uLXJlc3VsdHMtdGxzLw0KSHRt bGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hcnRpbi1hdXRo ZW50aWNhdGlvbi1yZXN1bHRzLXRscy0wMg0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1hcnRpbi1hdXRoZW50aWNhdGlvbi1yZXN1bHRzLXRs cy0wMg0KDQpBYnN0cmFjdDoNCiAgVGhpcyBtZW1vIHVwZGF0ZXMgdGhlIHJlZ2lzdHJ5IG9mIHBy b3BlcnRpZXMgaW4gQXV0aGVudGljYXRpb24tDQogIFJlc3VsdHM6IG1lc3NhZ2UgaGVhZGVyIGZp ZWxkcyB0byBhbGxvdyByZWxheWluZyBvZiB0aGUgcmVzdWx0cyBvZiBhbg0KICBlbWFpbCBzZW50 IHVzaW5nIFNUQVJUVExTIFtSRkMzMjA3XSBvciBub3QuDQo= --_000_10859145ea204fe084ec2e0811da657aBL2SR01MB605namsdf01sdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOmR0PSJ1dWlkOkMyRjQxMDEwLTY1QjMtMTFkMS1B MjlGLTAwQUEwMEMxNDg4MiIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0i TWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYz QzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkl0IHdvdWxk IGJlIGhlbHBmdWwgaWYgeW91IHB1dCBzb21lIHNhbXBsZSBBdXRoZW50aWNhdGlvbi1SZXN1bHRz IGhlYWRlcnMgaW50byB0aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LS0gVGVycnk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGFwcHMtZGlzY3VzcyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5GcmFuY2sgTWFydGluPGJyPg0K PGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMTcsIDIwMTQgMzoxMSBQTTxicj4NCjxiPlRvOjwv Yj4gSUVURiBBcHBzIERpc2N1c3M8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2FwcHMtZGlzY3Vzc10g TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tYXJ0aW4tYXV0aGVudGljYXRpb24t cmVzdWx0cy10bHMtMDIudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkl0IHdv dWxkIGJlIG5pY2UgaWYgdGhpcyBkcmFmdCBpcyBwaWNrZWQgdXAgYnkgdGhlIFVUQSBvciBBUFBT IFdHLCB0aG8gSSBoYXZlIG5vIGlkZWEgb24gdGhhdCBwcm9jZXNzLi4uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SXQgaXMgdG8gYmUgbm90 ZWQgdGhpcyBkcmFmdCByZXF1aXJlcyBhbiB1cGdyYWRlIHRvIFJGQzcwMDEgdG8gYWxsb3cgdGhl IHVzZSBvZiBuZXcgcHR5cGUuIEkgdW5kZXJzdGFuZCB0aGlzIGlzIGEgd29yayBpbiBwcm9ncmVz cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PlRoZXJlIGFyZSBhIGZldyB1cGRhdGVzLCBiZXNpZGVzIHB0eXBlIGZvcm1hdCwgdG8gYWxsb3cg dG8gcmVjb3JkIHRoZSBpc3N1ZXIgYW5kIHRoZSBTdWJqZWN0IEFsdGVybmF0aXZlIE5hbWUgdGhh dCBtYXkgY29udGFpbiB0aGUgaW5mb3JtYXRpb24gZm9yIHZlcmlmeWluZyB0aGUgaG9zdCBhbGln bmVtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+LS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtbWFydGluLWF1dGhlbnRpY2F0aW9uLXJlc3VsdHMtdGxzLTAyLnR4dDxi cj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRnJhbmNrIE1hcnRpbiBhbmQg cG9zdGVkIHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7ZHJhZnQtbWFydGluLWF1dGhlbnRpY2F0 aW9uLXJlc3VsdHMtdGxzPGJyPg0KUmV2aXNpb246Jm5ic3A7Jm5ic3A7ICZuYnNwOzAyPGJyPg0K VGl0bGU6Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtBdXRoZW50aWNhdGlv bi1SZXN1bHRzIFJlZ2lzdHJhdGlvbiBmb3IgVExTPGJyPg0KRG9jdW1lbnQgZGF0ZTombmJzcDsm bmJzcDsgJm5ic3A7MjAxNC0wNi0xNzxicj4NCkdyb3VwOiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDs4PGJyPg0KVVJMOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYXJ0aW4tYXV0aGVu dGljYXRpb24tcmVzdWx0cy10bHMtMDIudHh0Ij4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LW1hcnRpbi1hdXRoZW50aWNhdGlvbi1yZXN1bHRzLXRscy0wMi50eHQ8 L2E+PGJyPg0KU3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1t YXJ0aW4tYXV0aGVudGljYXRpb24tcmVzdWx0cy10bHMvIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LW1hcnRpbi1hdXRoZW50aWNhdGlvbi1yZXN1bHRzLXRscy88L2E+ PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hcnRpbi1hdXRoZW50aWNhdGlv bi1yZXN1bHRzLXRscy0wMiI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXJ0 aW4tYXV0aGVudGljYXRpb24tcmVzdWx0cy10bHMtMDI8L2E+PGJyPg0KRGlmZjombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbWFydGluLWF1dGhlbnRp Y2F0aW9uLXJlc3VsdHMtdGxzLTAyIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LW1hcnRpbi1hdXRoZW50aWNhdGlvbi1yZXN1bHRzLXRscy0wMjwvYT48YnI+DQo8YnI+ DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgVGhpcyBtZW1vIHVwZGF0ZXMgdGhlIHJlZ2lzdHJ5IG9m IHByb3BlcnRpZXMgaW4gQXV0aGVudGljYXRpb24tPGJyPg0KJm5ic3A7IFJlc3VsdHM6IG1lc3Nh Z2UgaGVhZGVyIGZpZWxkcyB0byBhbGxvdyByZWxheWluZyBvZiB0aGUgcmVzdWx0cyBvZiBhbjxi cj4NCiZuYnNwOyBlbWFpbCBzZW50IHVzaW5nIFNUQVJUVExTIFtSRkMzMjA3XSBvciBub3QuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_10859145ea204fe084ec2e0811da657aBL2SR01MB605namsdf01sdf_-- From nobody Wed Jun 18 08:39:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282A41A0263; Wed, 18 Jun 2014 08:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAODuoCnNh-5; Wed, 18 Jun 2014 08:39:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2281A0297; Wed, 18 Jun 2014 08:38:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140618153858.26432.39093.idtracker@ietfa.amsl.com> Date: Wed, 18 Jun 2014 08:38:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JxM8ot-lJYMqjdAJ23H4sh1KPps Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 15:39:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A NULL MX Resource Record for Domains that Accept No Mail Authors : John Levine Mark Delany Filename : draft-ietf-appsawg-nullmx-04.txt Pages : 6 Date : 2014-06-18 Abstract: Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately this means that the A/ AAAA record is taken to be mail server address even when that address does not accept mail. The NULL MX RR formalizes the existing mechanism by which a domain announces that it accepts no mail, which permits significant operational efficiencies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-nullmx-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-nullmx-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 18 09:32:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60DC1A017C for ; Tue, 17 Jun 2014 14:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQhsVctB6JQx for ; Tue, 17 Jun 2014 14:53:22 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBAEF1A0188 for ; Tue, 17 Jun 2014 14:53:18 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id y10so7574864wgg.17 for ; Tue, 17 Jun 2014 14:53:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mO4yEGVCh13p8bxdrnfkKLDclrI1/LEQjbeo/hNPfeE=; b=mtFGqx2H2fIfVrDdwyw+KgWuqI4lQ1+mVaYDQtCkjQCRURY+dpJ7dnRzqecs7m7Tv/ UYG2CgHJC6iplfb/04EST+hhwzySZy88nOM3k4fE4xdiRpcO+8kTG2EIEvPe5Fab8Xcd HsJYJkwD9sCaExct1otCPQ7XFKRU7EoaLdsHTFVoJc+IC04JD8iKF6UX9ITPNn8hvlgd si/7C1jF6qy7CVU/Nw0tF4CbP7XiQvZonN8o8MOiq6F1ES0MZc5B3SQLjkaFPvZ9iuD4 a573y2YIqfLxfSfpRhOoHm67SjAvDT4ygG27GKZpEtP9/RnpFK1nwcbG3Ob4Bbbe8rKq PHZw== X-Gm-Message-State: ALoCoQl3Jj3QmR5KaPW3tJI2xUoZpACfWb39vIoK+6bPaUbbyJFX4dbfKSVw7sVH5natNInPOHsU X-Received: by 10.194.85.225 with SMTP id k1mr41993983wjz.49.1403041997109; Tue, 17 Jun 2014 14:53:17 -0700 (PDT) Received: from [192.168.1.118] ([88.203.232.9]) by mx.google.com with ESMTPSA id ub8sm465739wib.0.2014.06.17.14.53.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 14:53:16 -0700 (PDT) Message-ID: <53A0B8CA.3080107@jitsi.org> Date: Wed, 18 Jun 2014 00:53:14 +0300 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Vijay K. Gurbani" , "apps-discuss@ietf.org" , draft-ietf-mmusic-latching@tools.ietf.org References: <537F520E.3060501@bell-labs.com> <538663F1.4080709@jitsi.org> <538C8820.1090900@bell-labs.com> In-Reply-To: <538C8820.1090900@bell-labs.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Vanl-N_C740AOXlx8w4FaccEGtc X-Mailman-Approved-At: Wed, 18 Jun 2014 09:32:08 -0700 Cc: IESG IESG , mmusic Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-mmusic-latching-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jun 2014 21:53:25 -0000 Hey Vijay, Apologies for the delay! I believe we have addressed all comments and a new version is available here: Html: http://tools.ietf.org/html/draft-ietf-mmusic-latching-08 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-08 Please see inline for the rest of my responses (points of accord removed): On 02.06.14, 17:20, Vijay K. Gurbani wrote: > On 05/28/2014 05:32 PM, Emil Ivov wrote: >> Hey Vijay, >> >> Thanks for your review! Comments inline. > > Emil: Thank you for indulging me. Any time ;) > More inline (please see to end). I > have taken out items of agreement and only list those where more > discussion is required. For reference, my original review is at > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12014.html). > >>> SDP is as much of a standard as SIP is, no? Maybe you mean to say >>> that >>> because of the complexity of representing SIP messages, the SIP >>> portion >>> of a RTC component's stack may vary between implementations and >>> deploy- >>> ments. SDP, being a simpler protocol (at least syntactically), is not >>> exposed to such vagaries. Yes? >> >> Yes, exactly. [...] >> On the other hand there only so many ways you can change an IP address >> in SDP. So, how about the following wording? >> >> SIP's many features in terms of controlling message routing provide >> for various ways of addressing NAT traversal. As a result, the HNT >> component for SIP is typically more implementation-specific and >> deployment-specific than the SDP and media components. >> >> Would this be better? > > Yes, much improved. One minor modification to the suggested text: > > s/SIP's many features in terms of controlling message routing provide > for various ways of addressing NAT traversal./ > SIP uses numerous expressive primitives for message routing and, > consequently, NAT traversal./ I like that! Although with your wording the first part of the sentence is enough so if we remove the second we get: SIP uses numerous expressive primitives for message routing. As a result, the HNT component for SIP is typically more implementation-specific and deployment-specific than the SDP and media components. I think this matches exactly what we intended to say so if you are happy with it I think it's perfect. >>> - S3, second paragraph: "newly introduced media relay" --- newly >>> introduced to who? [...] >> So how about this? >> >> While this is not necessary for HNT to work, quite often, the IP >> address of that media relay may be the same as that of the signaling >> intermediary (i.e. the SIP SBC and media relay are co-located on the >> same host). Also, in almost all cases, the address of the media >> relay would belong to the same IP address family as the one used for >> signaling, as it is known to work for that UA. >> >> Is this better or do you prefer the original? > > The problem with qualifying phrases like "In almost all cases" is that > one wonders what happens in other cases? Well ... we have media and signalling going over different IP versions ... but I see what you mean. > What do you think about the > following text: > > In typical deployments, the media relay and signaling intermediary > (the SBC) are co-located, thereby sharing the same IP address > family. This works well because the UA also shares the same IP > address family. In deployments where the media relay belongs to > a different address family, the signaling intermediary would > rewrite it to correspond to the address family of the UA. > > Feel free to push back and modify if this does not convey the right > semantics (especially the "In deployments..." part). Yes, I think there might have been a misunderstanding here. I used some of your wording and arrived at: In typical deployments, the media relay and signaling intermediary (i.e., the SBC) are co-located, thereby sharing the same IP address. Also, the address of the media relay would typically belong to the same IP address family as the one used for signaling, as it is known to work for that UA. In other words, signalling and media would either both travel over IPv4 or IPv6. Is this better? >>> - S4, the descriptional steps below the text "The latching mechanism >>> works as follows:" will be improved if you used "UAC" or "UAS" instead >>> of "UA" (I recognize that in SIP it is not necessary that the UAC >>> make the first offer, but these steps are for illustrative purposes >>> and it helps to be as clear as we can for neophyte readers). Even >>> much better if you could cast the actors in terms of the principals >>> Alice and Bob that appear in Figures 2. So, something like "After >>> receving an offer from Alice (UAC) who is behind a NAT" is preferable >>> (I think) to "After receiving an offer from a NATed UA". >> >> I agree this can be said better. What would you say about: >> >> This way, while a session is still being setup, the signalling >> intermediary is not yet aware what addresses and ports the caller >> and the callee would end up using for media traffic: it has only >> seen them advertise the private addresses they use behind their >> respective NATs. Therefore media relays used in HNT would often use >> a mechanism called "latching". > > Umm ... I think there is a bit of a disconnect here. I am referring to > all steps 1 - 6 above. See next comment; it is related. Ah! Gotcha! Better now? >>> - S4, Figure 2, step 13: Much as you do in step 11, you should >>> spell out the "dest" field here as well. So, >>> s/RTP/RTP, dest=198.51.100.2:22007/ >> >> OK, that's going to require some ASCII art magic because we are out of >> place there already but I do agree it would be useful :) > > Sure; will be helpful if put in. Done. >>> - S5, first paragraph, towards the end: "widen the gap for potential >>> attackers..." Here, I suspect you mean that it provides the attackers >>> more IP address from which to mount attacks, i.e., advantage: >>> attackers. Yes? >> >> Yes. Is this a clarifying question or do you think it would be better if >> changed that way? > > I think it is better to say that "it provides the attackers a larger > attack surface" (or something similar). Using the phrase "widen the > gap" is ambiguous. One can read that as widening the gap between > attacker and defender (i.e., advantage defenders). Got it. Changed. >>> - S5, fourth paragraph: "For example, in cases where end-to-end >>> encryption is used it would still be possible for an attacker to >>> hijack a session despite the use of SRTP and perform a denial of >>> service attack. However, media integrity would not be compromised." >>> >>> Can you explain more broadly how the above would work? If we assume >>> that the endpoints exchange keys end-to-end and create secure channels >>> end-to-end, how would the attacker hijack a session? (Heartbleed and >>> all such mechanisms aside, of course. If we assume keys are derived >>> end-to-end and don't follow the hop-by-hop model, how would the >>> attacker prevail?) >> >> End-to-end was probably not the best choice of words here. Imagine >> something like ZRTP though. Given that such mechanisms rely exclusively >> on the media path for key negotiation, there would be no way for the SBC >> to authenticate the UA so it would still latch onto the wrong endpoint. >> Obviously ZRTP's authentication would prevent from an actual MitM attack >> but given that it's already on the media path, the attacker can simply >> stop relaying media and effectively perform a DoS. Does this make sense? > > Yes, more now. But, I think you will have to describe this attack using > ZRTP as an example in some more detail since there are various issues at > work here (the SBC not being able to authenticate the endpoint using > ZRTP, etc.). I suspect that the security ADs may ask you to do this > anyway during IESG review. Of course, if they don't you are free to > proceed, but as a matter of principle, it is best to explain the > security threat in enough detail that someone building these things can > appreciate the reasoning. (In the current form, at least I had > questions on the scenario you had in mind, hence the comment.) This section got completely reworded during IESG review and the above text is no longer there so ... >>> - Abstract, 3rd paragraph: >>> s/components of the HNT components/components of HNT/ >> >> thanks >> >>> In fact, the entire 3rd paragraph could be written more succinctly as >>> follows: >>> >>> Latching, one of the components of HNT, has a number of security >>> issues detailed in this document. Based on the known threats, the >>> IETF advises against use of this mechanism on the Internet and >>> recommends other solutions, such as the Interactive Connectivity >>> Establishment (ICE) protocol. >> >> That paragraph was the result of literally tens of back and forths so, >> unless you think this is paramount, I think it would be better to keep >> it as is. Specifically, the above version is missing on the fact that a) >> using SRTP allows for the security concerns to be addresses and the >> mechanism becomes acceptable b) sometimes the security concerns simply >> don't come into play (e.g. public conferences) c) there are controlled >> environments where security is taken care of in another way. > > Hmmm ... I don't see that the original version attends to (a), (b) and > (c) any more explicitly than the above version, but I will defer to your > judgment here. Since the paragraph is crafted through a hard-won > battle, please feel free to retain it. Also rewritten during IESG review. >>> - S4, first paragraph: s/couple/tuple/ >> >> well, in this case the text does refer to the address:port couple but I >> am ok with changing that to the "addres:port/transport" tuple (or >> triplet?) > > Stevens used "tuple" in his seminal TCP books. I personally think > "tuple" is better (and it is devoid of ordinal value, i.e., there can > be a 2-tuple, a quintuple, sextuple, etc.). If, however, you'd like > to leave it as "couple", no problem. OK. Changed for tuple everywhere. >>> - S4, Figure 3: why not use the principals Alice and Bob here as >>> well instead of "XMPP Client 1" and "XMPP Client 2"? >> >> Frankly the main reason was because it otherwise looks exactly like SIP >> and it becomes confusing. But I don't mind switching to Romeo and Juliet >> (which are XSF's protagonists of choice ;) ). > > Sure. Out of curiosity, who is XSF's Eve? I assume if an "Eve" is necessary it is easier to just pick a couple of other common protagonists: hamlet@denmark.lit and ophelia@denmark.lit, and then just go for claudius@denmark.lit > Thanks for your time on this, Emil. Thank you for yours Vijay! Emil -- https://jitsi.org From nobody Wed Jun 18 10:04:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999291A0085 for ; Wed, 18 Jun 2014 10:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oev2NcXvk8QJ for ; Wed, 18 Jun 2014 10:04:13 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F631A004A for ; Wed, 18 Jun 2014 10:04:12 -0700 (PDT) Received: (qmail 50190 invoked from network); 18 Jun 2014 17:04:10 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 18 Jun 2014 17:04:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=e887.53a1c68a.k1406; i=johnl@user.iecc.com; bh=smUAM708rh6+hpv66XpRFhYR80Xg45VedZGgaTT6nKc=; b=nA/jZCO74Xs5J7IHJvLMGeeImFLZk7KcSqziZG7zGVLUabs1l31Lox+CfHBebCCkWFiWMc3EuFzsFmWsvdwkYtiRUOByc4TxnN9fGplgtNhYkBGHtVBYJ8rUBE/zrgVqew/pLRbNyz9VXNJBKAZdXHPmL6a6phmv2rfP7g8ibA7MU+tKUiO8z6Jq74ftsahoTxFaaSgCr6SQrzoC+P72Y4kldg5et60XPvK5Jya01CNm84r8SLvhiXzMMfMOVcY+ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=e887.53a1c68a.k1406; olt=johnl@user.iecc.com; bh=smUAM708rh6+hpv66XpRFhYR80Xg45VedZGgaTT6nKc=; b=ANQFJea4iBL7SmPjwgEAgHwGEgcjG7hwcKH+7rKxpDheg7CZIc6OFeb/vGXjF3kPygjkyBfYeQOUrqk4ovBMiIO1gKGsR7E5bNUJplTiL69ppaSX1C408pFmbFXZ1Gx/2MhiyvDbM1Lc4s1CIZYldy3XEHLMCs92MKuml8BfUgoeh7tbdR+Vj7BEhKMeizZwOZo4n3ZhEy7DDofWQ5WktM3bMV6Bb7QDlTOHI/WGxdh7dUumry03e3DH6juHNtwb Date: 18 Jun 2014 17:03:48 -0000 Message-ID: <20140618170348.59526.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NWhNGG5zLev5MMthBwTCWjOb9wU Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-nullmx X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2014 17:04:14 -0000 As previously threatened, I did a fairly extensive edit for what I hope is the last draft. The only deliberate change of substance is that it now says you MUST NOT rather than SHOULD NOT publish other MXes along with nullmx, since I couldn't think of any useful reason to do so, and the semantics if you do are unclear. R's, John ------------------------------------------------------------------------------------- A new version of I-D, draft-ietf-appsawg-nullmx-04.txt has been successfully submitted by John Levine and posted to the IETF repository. Name: draft-ietf-appsawg-nullmx Revision: 04 Title: A NULL MX Resource Record for Domains that Accept No Mail Document date: 2014-06-18 Group: appsawg Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-nullmx-04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ Htmlized: http://tools.ietf.org/html/draft-ietf-appsawg-nullmx-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-nullmx-04 Abstract: Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately this means that the A/ AAAA record is taken to be mail server address even when that address does not accept mail. The NULL MX RR formalizes the existing mechanism by which a domain announces that it accepts no mail, which permits significant operational efficiencies. From nobody Wed Jun 18 15:08:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0601A01A8; Wed, 18 Jun 2014 15:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ez-xZC5vpzmI; Wed, 18 Jun 2014 15:08:25 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68061A019D; Wed, 18 Jun 2014 15:08:24 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5IM8NCf018021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Jun 2014 17:08:23 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s5IM8Md5030284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Jun 2014 17:08:23 -0500 Received: from shoonya.ih.lucent.com (vkg.lra.lucent.com [135.244.3.195]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s5IM87Hd014615; Wed, 18 Jun 2014 17:08:08 -0500 (CDT) Message-ID: <53A20E5B.1000209@bell-labs.com> Date: Wed, 18 Jun 2014 17:10:35 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Emil Ivov , "apps-discuss@ietf.org" , draft-ietf-mmusic-latching@tools.ietf.org References: <537F520E.3060501@bell-labs.com> <538663F1.4080709@jitsi.org> <538C8820.1090900@bell-labs.com> <53A0B8CA.3080107@jitsi.org> In-Reply-To: <53A0B8CA.3080107@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/cbZvyNXyCN6tPsIKFhJFxBuTPOk Cc: IESG IESG , mmusic Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-mmusic-latching-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2014 22:08:28 -0000 On 06/17/2014 04:53 PM, Emil Ivov wrote: > Hey Vijay, > > Apologies for the delay! I believe we have addressed all comments and a > new version is available here: > > Html: http://tools.ietf.org/html/draft-ietf-mmusic-latching-08 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-08 > > Please see inline for the rest of my responses (points of accord removed): Emil: I am fine with the changes you suggested in the email text. I will go through the diffs next week, but I suspect all is good. Thanks for attending to my comments. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Thu Jun 19 17:40:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A141A0302; Thu, 19 Jun 2014 17:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJOw05rpcS53; Thu, 19 Jun 2014 17:40:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 133861A02A9; Thu, 19 Jun 2014 17:40:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> Date: Thu, 19 Jun 2014 17:40:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ltprWxOLhgFC6Zsn24xzCcGSNss Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 00:40:42 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-appsawg-sieve-duplicate-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- o Section 3.3: "A default expiration time of around 7 days is usually appropriate. ... If that limit is exceeded by the ":seconds" argument, the maximum value MUST silently be substituted" The suggested default seems really long, especially for the example use case described in Section 1. On the other hand, it seems odd that the user's choice would be overriden by the preset maximum. This would make more sense to me if the default expiration were shorter and the user could override it with a longer :seconds argument if he wanted. What is the rationale for doing it the opposite way? o Section 6: It seems like this section is missing a discussion of the privacy considerations associated with enabling the duplicate test. In the case where the Sieve filter is implemented server side, making use of the duplicate test means that some record of the receipt of a particular message will be persisted (for as long as specified by the logic in Section 3.3) even if the user downloads his messages or deletes a received message on the server that matches a test string in the meantime. If I want to filter all messages with duplicate message IDs, for example, this puts a requirement on the server to maintain a list of the message IDs of all messages I’ve received (for the amount of time specified by the timing parameters). So if a third party wanted to find out that list, it could go to the operator of the server and ask for it. This introduces a privacy risk that is not discussed in the document and is exacerbated by the long default expiration time mentioned above. Tests that make use of the :header or :uniqueid arguments are also potentially problematic since the list of strings to match is kept on the server. It seems like these aspects should at least be noted in the document for implementers to consider. o Section 6: Sieve scripts that include duplicate tests contain potentially sensitive information (e.g., subject or body strings). So it seems like the scripts should be confidentiality protected in transit. I checked with Barry and he said that there is no RFC that specifies if/when scripts should be protected in transit, and I understand that this document is probably not the right place to specify required behavior there, but I'd like to discuss (more with the ADs than the authors) if there is some plan for specifying that behavior somewhere. o Section 6: I think it would make sense to require that the tracked message list be stored with an equivalent level of protection as the user's messages themselves. E.g., if message headers and bodies are stored encrypted, then the duplicate tracking list should be as well. And the duplicate tracking list should be subject to the same access controls as the mailbox (perhaps this is obvious but I'm not sure). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- o Section 3.1: "When the ":uniqueid" argument is used, such normalization concerns are the responsibility of the user." I don't quite get this. Do we expect users to, e.g., specify that uniqueid strings should only be compared after conversion to UTF-8? That would seem to rely on a level of technical sophistication that almost no users actually have. o Section 3.2: "This means that it does not matter whether values are obtained from the message ID header, from an arbitrary header specified using the ":header" argument or explicitly from the ":uniqueid" argument. I had trouble understanding what "it does not matter" meant in this sentence. I would suggest: "This means that the values in the duplicate list should be used for duplicate testing regardless of whether they were obtained from the message ID header, from an arbitrary header specified using the ":header" argument or explicitly from the ":uniqueid" argument." From nobody Fri Jun 20 00:52:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB731B2799; Fri, 20 Jun 2014 00:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7QaoByNy2Ve; Fri, 20 Jun 2014 00:52:12 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69A21AD6B1; Fri, 20 Jun 2014 00:52:10 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:65170 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Wxtc4-0000oA-6S; Fri, 20 Jun 2014 09:51:58 +0200 Message-ID: <53A3E7EB.1030604@rename-it.nl> Date: Fri, 20 Jun 2014 09:51:07 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alissa Cooper , The IESG References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> In-Reply-To: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/lqF7m-F5JvptoFOzBcpaA94DK80 Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jun 2014 07:52:16 -0000 Hi Alissa, On 6/20/2014 2:40 AM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-appsawg-sieve-duplicate-07: Discuss > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > o Section 3.3: > "A default expiration time of around 7 days is usually > appropriate. ... If that limit is exceeded by the ":seconds" argument, > the > maximum value MUST silently be substituted" > > The suggested default seems really long, especially for the example use > case described in Section 1. On the other hand, it seems odd that the > user's choice would be overriden by the preset maximum. This would make > more sense to me if the default expiration were shorter and the user > could override it with a longer :seconds argument if he wanted. What is > the rationale for doing it the opposite way? The default was chosen in Sieve mailing list discussions, but in essence it is pretty arbitrary. It is mainly based on the period in which a series of duplicate messages may arrive with a margin of a few more days. The rationale for a maximum is to prevent users from having the ability to create duplicate tracking list entries that linger indefinitely. > o Section 6: > It seems like this section is missing a discussion of the privacy > considerations associated with enabling the duplicate test. In the case > where the Sieve filter is implemented server side, making use of the > duplicate test means that some record of the receipt of a particular > message will be persisted (for as long as specified by the logic in > Section 3.3) even if the user downloads his messages or deletes a > received message on the server that matches a test string in the > meantime. If I want to filter all messages with duplicate message IDs, > for example, this puts a > requirement on the server to maintain a list of the message IDs of all > messages I’ve received (for the amount of time specified by the timing > parameters). So if a third party wanted to find out that list, it could > go to the operator > of the server and ask for it. This introduces a privacy risk that is not > discussed in the document and is exacerbated by the long default > expiration time mentioned above. Tests that make use of the :header or > :uniqueid arguments are also potentially problematic since the list of > strings to match is kept on the server. It seems like these aspects > should at least be noted in the document for implementers to consider. > > o Section 6: > Sieve scripts that include duplicate tests contain potentially sensitive > information (e.g., subject or body strings). So it seems like the scripts > should be confidentiality protected in transit. I checked with Barry and > he said that there is no RFC that specifies if/when scripts should be > protected in transit, and I understand that this document is probably not > the right place to specify required behavior there, but I'd like to > discuss (more with the ADs than the authors) if there is some plan for > specifying that behavior somewhere. > > o Section 6: > I think it would make sense to require that the tracked message list be > stored with an equivalent level of protection as the user's messages > themselves. E.g., if message headers and bodies are stored encrypted, > then the duplicate tracking list should be as well. And the duplicate > tracking list should be subject to the same access controls as the > mailbox (perhaps this is obvious but I'm not sure). This is a very interesting point of view. I had not thought of privacy concerns relating to the duplicate tracking list. Probably, the main reason we have not considered this is that the document states the following: NOTE: The necessary mechanism to track duplicate messages is very similar to the mechanism that is needed for tracking duplicate responses for the "vacation" [VACATION ] action. One way to implement the necessary mechanism for the "duplicate" test is therefore to store a hash of the tracked unique ID and, if provided, the ":handle" argument. There is no tractable way to reverse a hash into its original string value, meaning that the entries in the duplicate tracking list would have very little value for an attacker. Of course, if implementations choose a different approach that uses entries that can yield the original string values, there would be a real concern. I propose adding a sentence or two pointing out that duplicate tracking list entries should not contain the plain user strings for privacy reasons, or, alternatively, that the tracked message list be stored with an equivalent level of protection as the user's messages themselves. The same considerations apply to the vacation extension (RFC 5230). > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > o Section 3.1: > "When the ":uniqueid" argument is used, such normalization > concerns are the responsibility of the user." > > I don't quite get this. Do we expect users to, e.g., specify that > uniqueid strings should only be compared after conversion to UTF-8? That > would seem to rely on a level of technical sophistication that almost no > users actually have. I am not sure what exactly you mean here. The normalization concerns listed before that sentence all apply to header field content, something the author of a sieve script cannot control directly. With ":uniqueid" the script author is directly responsible for the composition of the unique ID value. As long as the encoding is chosen consistently, the encoding does not matter for successfully matching it to past values in the duplicate tracking list. It can also be some sort of binary value if appropriate; whatever the application demands. The quoted sentence mainly points to the fact that for some applications it can be useful to have such normalization for ":uniqueid" as well, e.g. to trim leading and trailing white space. However, the script author will have to implement this explicitly, since the duplicate test will not do this implicitly. > o Section 3.2: > "This means that it does not matter whether values are > obtained from the message ID header, from an arbitrary header > specified using the ":header" argument or explicitly from the > ":uniqueid" argument. > > I had trouble understanding what "it does not matter" meant in this > sentence. I would suggest: > > "This means that the values in the duplicate list should be used for > duplicate testing regardless of whether they were > obtained from the message ID header, from an arbitrary header > specified using the ":header" argument or explicitly from the > ":uniqueid" argument." Ok, works for me. Regards, Stephan. From nobody Fri Jun 20 06:42:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904B01A03A5; Fri, 20 Jun 2014 06:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 686tY8bMtvTf; Fri, 20 Jun 2014 06:42:50 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530771A03A1; Fri, 20 Jun 2014 06:42:50 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s5KDgamI028779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 20 Jun 2014 06:42:42 -0700 Message-ID: <53A43A08.7060509@dcrocker.net> Date: Fri, 20 Jun 2014 06:41:28 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephan Bosch , Alissa Cooper , The IESG References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> In-Reply-To: <53A3E7EB.1030604@rename-it.nl> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 20 Jun 2014 06:42:47 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xWiZZujJfUSGu6Cjoy7OcpkLszQ Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jun 2014 13:42:51 -0000 On 6/20/2014 12:51 AM, Stephan Bosch wrote: > This is a very interesting point of view. I had not thought of privacy > concerns relating to the duplicate tracking list. Shouldn't this same concern apply to all meta-data for the users message? Folder structure, access records, etc. If it is 'about' the user or their messages, it should be considered for privacy protection on a par with the message content. The counter-force is the need for the system to actually /use/ the data. Content might be subject to protection controlled by the user and not the system, but quite a lot of meta-data has to be used by the system itself, so the exposure is greater. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jun 20 06:43:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA70D1A039C for ; Fri, 20 Jun 2014 06:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlva4StVqqTp for ; Fri, 20 Jun 2014 06:43:03 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0015.outbound.protection.outlook.com [213.199.154.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E4CE1A039A for ; Fri, 20 Jun 2014 06:43:03 -0700 (PDT) Received: from AMXPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.133) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.0.969.15; Fri, 20 Jun 2014 13:43:01 +0000 Message-ID: <043201cf8c8d$194d2fc0$4001a8c0@gateway.2wire.net> From: t.petch To: Barry Leiba , Apps Discuss References: <20140328105940.ADCCF7FC2CB@rfc-editor.org> Date: Fri, 20 Jun 2014 14:32:14 +0100 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-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AMSPR07CA010.eurprd07.prod.outlook.com (10.242.77.178) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 024847EE92 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(51704005)(24454002)(13464003)(377454003)(51444003)(33646001)(79102001)(77982001)(62236002)(44716002)(15188155005)(19580405001)(84392001)(31966008)(16799955002)(87286001)(104166001)(102836001)(15975445006)(87976001)(64706001)(89996001)(81342001)(76482001)(77156001)(88136002)(81542001)(92566001)(93916002)(92726001)(86362001)(15202345003)(80022001)(50226001)(85852003)(46102001)(83072002)(66066001)(20776003)(47776003)(50466002)(83322001)(19580395003)(99396002)(106356001)(105586002)(23756003)(81686999)(14496001)(76176999)(50986999)(81816999)(101416001)(4396001)(551544002)(77096002)(21056001)(44736004)(74662001)(74502001)(85306003)(62966002)(95666004)(42186005)(61296003)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR07MB055; H:AMXPRD0310HT004.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/TqkSZeMRL1tpJUl7QZvcWMLR_E8 Cc: Myunggyun Jonathan Aldo Seo Subject: Re: [apps-discuss] [Technical Errata Reported] RFC1459 (3938) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jun 2014 13:43:11 -0000 Barry RFC1459 s4.2.3.1 is updated by RFC2812 s3.2.3 and, in part, by RFC2811 s4. Comparing those two last with RFC1459, I think it clear that a page has been missed, giving the Numeric Replies and Examples. The equivalent to the truncated sentence, "When using the 'o' and 'b' options, a restriction on a total of three per mode command has been imposed. That is, any combination of 'o' and" is now " Note that there is a maximum limit of three (3) changes per command for modes that take a parameter." I think that the erratum should point out that RFC1459 has been updated - Obsoleted I would call it - and that a comprehensive description can be found in the RFC281x. Trying to reconstruct the missing page seems unproductive. I am curious whether or not the raiser of this was aware of the later RFC, which seem to me to resolve any issues. Tom Petch ----- Original Message ----- From: "Barry Leiba" To: "Apps Discuss" Cc: "Myunggyun Jonathan Aldo Seo" Sent: Wednesday, April 16, 2014 4:56 PM > Myunggyun Jonathan Aldo Seo has reported the errata below, on RFC > 1459, the IRC protocol. He's correct that the last paragraph of > Section 4.2.3.1 has clearly been truncated. But, as this is a > more-than-20-year-old document, it's likely hard to know what the text > was intended to say. > > Here's Section 4.2.3.1 in its entirety: > > ------------------------------------- > 4.2.3.1 Channel modes > > Parameters: {[+|-]|o|p|s|i|t|n|b|v} [] [] > [] > > The MODE command is provided so that channel operators may change the > characteristics of `their' channel. It is also required that servers > be able to change channel modes so that channel operators may be > created. > > The various modes available for channels are as follows: > > o - give/take channel operator privileges; > p - private channel flag; > s - secret channel flag; > i - invite-only channel flag; > t - topic settable by channel operator only flag; > n - no messages to channel from clients on the outside; > m - moderated channel; > l - set the user limit to channel; > b - set a ban mask to keep users out; > v - give/take the ability to speak on a moderated channel; > k - set a channel key (password). > > When using the 'o' and 'b' options, a restriction on a total of three > per mode command has been imposed. That is, any combination of 'o' > and > ------------------------------------- > > I would like to mark the errata report as Verified, but it would be > nice to be able to suggest correct text in the report. Can anyone > help figure out what was supposed to be there? If not, I'll likely > mark it "Held For Document Update" instead. > > Barry > > On Fri, Mar 28, 2014 at 6:59 AM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC1459, > > "Internet Relay Chat Protocol". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=1459&eid=3938 > > > > -------------------------------------- > > Type: Technical > > Reported by: Myunggyun Jonathan Aldo Seo > > > > Section: 4.2.3.1 > > > > Original Text > > ------------- > > When using the 'o' and 'b' options, a restriction on a total of three > > per mode command has been imposed. That is, any combination of 'o' > > and > > > > Corrected Text > > -------------- > > > > > > Notes > > ----- > > The sentence lacks the last part and does not explain what it expected to. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC1459 (no draft string recorded) > > -------------------------------------- > > Title : Internet Relay Chat Protocol > > Publication Date : May 1993 > > Author(s) : J. Oikarinen, D. Reed > > Category : EXPERIMENTAL > > Source : Legacy > > Area : Legacy > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Fri Jun 20 07:57:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461321B27E4; Fri, 20 Jun 2014 07:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzSgiuY2Y6dM; Fri, 20 Jun 2014 07:57:06 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E0121B2804; Fri, 20 Jun 2014 07:57:06 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id el20so2417456lab.19 for ; Fri, 20 Jun 2014 07:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7gH+NSZ50XW9m9jibiO9xqM5aDzWhIEhZdz2jBv7cdo=; b=lChMHl/DgL5OD7+tKKx1h3CJ+/ZhwmqxClyzWTWAPAHx6WDrx6IpUu1HCaCkFb+lLZ nXaDMm8mj7PeGHPB5v+Q/Sb6BmXLVWE+dZ+kiN38EyeK5qL3Jz3Ux/uVPqYWvVLFDPXK Dqt0VYy48EVzw3VsAWQdBHwDeKfO29OaElkohbx+Ay0hhrwgtKNSHduXMCivVvLWy8bI skuIF5BSH7Jq5mYx/ZldMJs2zmIz4TjcM0Uu7pk8QG7h1FvzOYgYzeaik/ew/nBQshmH y+MgUmWbPCTjgZBd33Wh/UXBekiGsNKljYTd38pBliUnRgwJan2t+cUgQz1CZNMnCymc UBKg== MIME-Version: 1.0 X-Received: by 10.152.36.99 with SMTP id p3mr2187703laj.61.1403276224627; Fri, 20 Jun 2014 07:57:04 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Fri, 20 Jun 2014 07:57:04 -0700 (PDT) In-Reply-To: <53A3E7EB.1030604@rename-it.nl> References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> Date: Fri, 20 Jun 2014 10:57:04 -0400 X-Google-Sender-Auth: ACPRqkO2IEXQGzqn0r2nbm-ou-Y Message-ID: From: Barry Leiba To: Stephan Bosch Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VQWV3blEA9h9cplA3bNPOyyfn-E Cc: Apps Discuss , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jun 2014 14:57:08 -0000 > This is a very interesting point of view. I had not thought of privacy > concerns relating to the duplicate tracking list. > > Probably, the main reason we have not considered this is that the > document states the following: > > NOTE: The necessary mechanism to track duplicate messages is very > similar to the mechanism that is needed for tracking duplicate > responses for the "vacation" [VACATION ] action. One way to implement > the necessary mechanism for the "duplicate" test is therefore to > store a hash of the tracked unique ID and, if provided, the ":handle" > argument. > > There is no tractable way to reverse a hash into its original string > value, meaning that the entries in the duplicate tracking list would > have very little value for an attacker. > > Of course, if implementations choose a different approach that uses > entries that can yield the original string values, there would be a real > concern. I propose adding a sentence or two pointing out that duplicate > tracking list entries should not contain the plain user strings for > privacy reasons, or, alternatively, that the tracked message list be > stored with an equivalent level of protection as the user's messages > themselves. > > The same considerations apply to the vacation extension (RFC 5230). I think a good way to resolve this would be to put something like what you propose (a sentence or two) into the Security Considerations, to add that note that this applies to Vacation as well, and to have this document "update" 5230. Specifically: 1. Add two paragraphs to Section 6: The list of unique IDs used for duplicate tracking can include privacy-sensitive information, such as Message-ID values, content of subject lines, and content extracted from message bodies. It is important to protect that information, either by obscuring it through hashing (see the note at the end of Section 3.2) or by storing it with a level of access control equivalent to that of the messages themselves. The same considerations apply to the Vacation extension [VACATION], and this updates the Security Considerations of that document (RFC 5230, Section 8) accordingly. 2. Add a paragraph to Section 1: The Security Considerations section of this document (see Section 6) updates the Security Considerations for RFC 5230 [VACATION]. 3. Add "Updates: 5230" to the document header. The update to 5230 is optional, but I think it's easy and useful. >> "When the ":uniqueid" argument is used, such normalization >> concerns are the responsibility of the user." >> >> I don't quite get this. Do we expect users to, e.g., specify that >> uniqueid strings should only be compared after conversion to UTF-8? That >> would seem to rely on a level of technical sophistication that almost no >> users actually have. > > I am not sure what exactly you mean here. The normalization concerns > listed before that sentence all apply to header field content, something > the author of a sieve script cannot control directly. With ":uniqueid" > the script author is directly responsible for the composition of the > unique ID value. [etc...] The problem here, really, is "the user", I think. What you really want to say, and something I don't think would make Alissa blink, is this: NEW When the ":uniqueid" argument is used, any normalization needs to be done in the Sieve script itself, as the unique ID is created. END Barry From nobody Fri Jun 20 08:06:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A251A0379 for ; Fri, 20 Jun 2014 08:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMo99EDGV8sJ for ; Fri, 20 Jun 2014 08:06:55 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0C41A0369 for ; Fri, 20 Jun 2014 08:06:52 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id gf5so2420394lab.8 for ; Fri, 20 Jun 2014 08:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=XDzvFCuoU27s137FK8+dY8hCjN1EvE8aMFtWXOA2yqc=; b=CoeL8W3hV0oGkPSyR46Q/QgoasUXyepCExI0k1qEqW80azkvQWgQjI2FJERsqa+HK2 BDsNI/gTf7EOZtJ1V2f8+Yu36y4TWsqQdWoSFHQUa+IruGgnCB6PiUK1DMg1+yQoXTSj ON9yoqR0a0ZHJMHhoCmEwiVaVvFteqee2qa5ij+ur11qD6ant5psBHg5kHDUlPNeXu9w NyLFiW1r1h4A5GPDu2GPZuYa6E/n7qsuZAoID2yoDdHWaYNd8PgFU5+Hm4Xr6NadTMvf mODTIcQpqEhIaKWK2EshQOPMmEOBInQ2ojyXxcBisIi+OF1ND9n+9DcW6uuwW3W8ePab IG0g== MIME-Version: 1.0 X-Received: by 10.112.157.130 with SMTP id wm2mr2806803lbb.38.1403276811102; Fri, 20 Jun 2014 08:06:51 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Fri, 20 Jun 2014 08:06:51 -0700 (PDT) Date: Fri, 20 Jun 2014 11:06:51 -0400 X-Google-Sender-Auth: mizEke5InA6EwPkrtJl6UWhFTBs Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/WfQEnWXUkUKQyg52NWczIh0szG0 Subject: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jun 2014 15:06:56 -0000 Cyrus Daboo has proposed a new working group in the Applications Area, and I'm initiating charter discussion on it: https://datatracker.ietf.org/doc/charter-ietf-tzdist/ We'll have the charter discussion here on apps-discuss. Assuming a working group comes out of this, we'll create a new mailing list for the actual work, once the charter is done. Comments on this charter are welcome. I expect to put it on the 10 July IESG telechat for initial approval, after which it will go out for IETF and external review. So, comments here by 4 July, please. Barry, Applications AD From nobody Fri Jun 20 11:21:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0AC1B28AA; Fri, 20 Jun 2014 11:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brdMAjSuF7ZE; Fri, 20 Jun 2014 11:21:17 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45AC41B28BF; Fri, 20 Jun 2014 11:20:40 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:62673 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Wy3Q8-00041s-R6; Fri, 20 Jun 2014 20:20:22 +0200 Message-ID: <53A47B46.80506@rename-it.nl> Date: Fri, 20 Jun 2014 20:19:50 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Barry Leiba , Alissa Cooper References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0x8LCAxAgubx93XPU93w0sZxneQ Cc: "appsawg-chairs@tools.ietf.org" , "ned+ietf@mrochek.com" , The IESG , Apps Discuss , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jun 2014 18:21:19 -0000 Hi Barry, Alissa, On 6/20/2014 4:57 PM, Barry Leiba wrote: >> Of course, if implementations choose a different approach that uses >> entries that can yield the original string values, there would be a real >> concern. I propose adding a sentence or two pointing out that duplicate >> tracking list entries should not contain the plain user strings for >> privacy reasons, or, alternatively, that the tracked message list be >> stored with an equivalent level of protection as the user's messages >> themselves. >> >> The same considerations apply to the vacation extension (RFC 5230). > I think a good way to resolve this would be to put something like what > you propose (a sentence or two) into the Security Considerations, to > add that note that this applies to Vacation as well, and to have this > document "update" 5230. Specifically: > > 1. Add two paragraphs to Section 6: > > The list of unique IDs used for duplicate tracking can include > privacy-sensitive information, such as Message-ID values, content of > subject lines, and content extracted from message bodies. It is > important to protect that information, either by obscuring it through > hashing (see the note at the end of Section 3.2) or by storing it with > a level of access control equivalent to that of the messages > themselves. Yes, good text. > The same considerations apply to the Vacation extension [VACATION], > and this updates the Security Considerations of that document (RFC > 5230, Section 8) accordingly. > > 2. Add a paragraph to Section 1: > > The Security Considerations section of this document (see Section 6) > updates the Security Considerations for RFC 5230 [VACATION]. > > 3. Add "Updates: 5230" to the document header. > > The update to 5230 is optional, but I think it's easy and useful. It feels a bit odd to update the vacation specification from a document that has very little to do with it. I have no real issue with that, and if you say it is OK to do so, I'd be happy to add that. But, still, it seems a bit awkward and perhaps unexpected for implementers. >>> "When the ":uniqueid" argument is used, such normalization >>> concerns are the responsibility of the user." >>> >>> I don't quite get this. Do we expect users to, e.g., specify that >>> uniqueid strings should only be compared after conversion to UTF-8? That >>> would seem to rely on a level of technical sophistication that almost no >>> users actually have. >> I am not sure what exactly you mean here. The normalization concerns >> listed before that sentence all apply to header field content, something >> the author of a sieve script cannot control directly. With ":uniqueid" >> the script author is directly responsible for the composition of the >> unique ID value. [etc...] > The problem here, really, is "the user", I think. > > What you really want to say, and something I don't think would make > Alissa blink, is this: > > NEW > When the ":uniqueid" argument is used, any normalization > needs to be done in the Sieve script itself, as the unique ID > is created. > END Yes, that would be OK. Alissa, is this what you meant? Regards, Stephan. From nobody Fri Jun 20 11:38:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691E21A0291; Fri, 20 Jun 2014 11:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr-N9QowtZrk; Fri, 20 Jun 2014 11:38:27 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C911A0051; Fri, 20 Jun 2014 11:38:26 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id u10so2566869lbd.5 for ; Fri, 20 Jun 2014 11:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=g7U9X+M/Vh+Vy0Vkp1hb73y458ueawzVKxIJtbSjiTM=; b=w+DA+LkxaLK2nBtSwlcNYh79/k3CFSUUniifv/p0/GlyslL/ZTBKjbMXNidZb9auF9 WYMIGnVJzGg3Hyp9u4FCoNucBEJtK06Jb7lt9z9iBegv7tZ+ukM+kkZMDDQ6772X+XKZ oViw58r0TlsVlOZ+I1Ud2X2pKzXLTfsfeQdIsuK3s2O56G2nTnxzBwZCguXNdnf9fjpg GFfl02+E68pTP08YxbHbpZDBFxW8XEQd2l2unnhyYQqqxzT31ApoTMk8Z+JzDmbnOpRZ 711P2vlCtqFoYUHJPyc4C1UFj9JMgnfiAQ/npmCIDltpZgTE88Zluddn04BAqE4nTs8d eWbw== MIME-Version: 1.0 X-Received: by 10.152.234.201 with SMTP id ug9mr1840046lac.73.1403289505333; Fri, 20 Jun 2014 11:38:25 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Fri, 20 Jun 2014 11:38:25 -0700 (PDT) In-Reply-To: <53A47B46.80506@rename-it.nl> References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A47B46.80506@rename-it.nl> Date: Fri, 20 Jun 2014 14:38:25 -0400 X-Google-Sender-Auth: qGxdXseVwlnG5gA7OqGY3oo4sH0 Message-ID: From: Barry Leiba To: Stephan Bosch , Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/lk4rodAi088bWwgfaE70OoRBRhI Cc: Apps Discuss , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jun 2014 18:38:28 -0000 >> The same considerations apply to the Vacation extension [VACATION], >> and this updates the Security Considerations of that document (RFC >> 5230, Section 8) accordingly. >> >> 2. Add a paragraph to Section 1: >> >> The Security Considerations section of this document (see Section 6) >> updates the Security Considerations for RFC 5230 [VACATION]. >> >> 3. Add "Updates: 5230" to the document header. >> >> The update to 5230 is optional, but I think it's easy and useful. > > It feels a bit odd to update the vacation specification from a document > that has very little to do with it. I have no real issue with that, and > if you say it is OK to do so, I'd be happy to add that. But, still, it > seems a bit awkward and perhaps unexpected for implementers. Understood. I think it's fine to do that, as long as it's clear what the update is, but I do understand why it would seem odd. Ned, Pete -- do you have opinions here? I will point out that we just published an IMAP extension (the update to CONDSTORE/QRESYNC, RFC 7162) that updated the otherwise unrelated RFC 2683 by changing a recommendation about maximum line length. Barry From nobody Fri Jun 20 11:46:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14021B28B1; Fri, 20 Jun 2014 11:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAAxDyS6_eM0; Fri, 20 Jun 2014 11:46:47 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49DE1B28B5; Fri, 20 Jun 2014 11:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1403290007; x=1434826007; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LymZncakpiCRHozxObRchgq7AczzDGWAAonj+q5SR10=; b=bRf0cNRsD1elExpijheCYploLDVol7FvzXpSqh4LFrLx7fckPrT+PJCh pzLHitY+UojU+D4lXNki7ejqlkmkuEJ6jeVYCOb/DrubIOQOPQ59U+o6h pQliKGxI34xT9/xXEB3Ondf7MNLd8kdqYh/d+Y9xmiD3AXr64iC1HewwZ 4=; X-IronPort-AV: E=McAfee;i="5600,1067,7475"; a="135747191" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 20 Jun 2014 11:46:47 -0700 X-IronPort-AV: E=Sophos;i="5.01,515,1400050800"; d="scan'208";a="685906197" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Jun 2014 11:46:46 -0700 Received: from presnick-mac.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 20 Jun 2014 11:46:45 -0700 Message-ID: <53A48194.9030509@qti.qualcomm.com> Date: Fri, 20 Jun 2014 11:46:44 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A47B46.80506@rename-it.nl> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Sen-Mut9F7v85gyVyy5_Gn7FF0o Cc: Apps Discuss , Stephan Bosch , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jun 2014 18:46:49 -0000 On 6/20/14 11:38 AM, Barry Leiba wrote: >>> The same considerations apply to the Vacation extension [VACATION], >>> and this updates the Security Considerations of that document (RFC >>> 5230, Section 8) accordingly. >>> >>> 2. Add a paragraph to Section 1: >>> >>> The Security Considerations section of this document (see Section 6) >>> updates the Security Considerations for RFC 5230 [VACATION]. >>> >>> 3. Add "Updates: 5230" to the document header. >>> >>> The update to 5230 is optional, but I think it's easy and useful. >>> >> It feels a bit odd to update the vacation specification from a document >> that has very little to do with it. I have no real issue with that, and >> if you say it is OK to do so, I'd be happy to add that. But, still, it >> seems a bit awkward and perhaps unexpected for implementers. >> > Understood. I think it's fine to do that, as long as it's clear what > the update is, but I do understand why it would seem odd. Ned, Pete > -- do you have opinions here? > Especially for this sort of privacy consideration, I think it's unnecessary. We have a long history of documents (still in use) that have bad or no advice along these lines (and similarly for security or i18n considerations) that we don't try to go back to "update" this way. > I will point out that we just published an IMAP extension (the update > to CONDSTORE/QRESYNC, RFC 7162) that updated the otherwise unrelated > RFC 2683 by changing a recommendation about maximum line length. > I do find changes to protocol processing recommendations somewhat different than simply these considerations bits. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Fri Jun 20 11:59:28 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809131B28BA; Fri, 20 Jun 2014 11:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duqsGlFxKsN5; Fri, 20 Jun 2014 11:59:25 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C151B27C9; Fri, 20 Jun 2014 11:59:25 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id c11so2648265lbj.27 for ; Fri, 20 Jun 2014 11:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3itjtccr8OoMId90ENRTExtPUrvPiAjznmBYtr+8crE=; b=OHr/sT4t6YwU3J/IhnXUYKiVJCq8Tb14kUK6HPgQxRM/7pV2646pJl3x+c5Ih/kuTM 3cbKNSumwi+es77iDbcCwM73kjzGd6NfcGphizP49o7fOidHRlCDX5d2v3Y+elevM+RI EH3cvbyRP1MbJj5dFuSomgHIWyLWzLglharhkaxjf87HyvYQIffUWU0DQxUhtaoOcaMi M0pHol7M/GYTaVgD/QGZXGpuCXEQE/FrQAp1Gt8+AbjafpjrCyqNx7wf5qUUFFTaTais doq/1vf2AxoltCkSRmh/V/EO6rHfHGJADoJr4p3673WTt8RITVYy8XTm5cPQFQAm1+bX aoRA== MIME-Version: 1.0 X-Received: by 10.152.43.135 with SMTP id w7mr3839823lal.32.1403290763549; Fri, 20 Jun 2014 11:59:23 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Fri, 20 Jun 2014 11:59:23 -0700 (PDT) In-Reply-To: <53A48194.9030509@qti.qualcomm.com> References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A47B46.80506@rename-it.nl> <53A48194.9030509@qti.qualcomm.com> Date: Fri, 20 Jun 2014 14:59:23 -0400 X-Google-Sender-Auth: cWHCtFQM6jCZxdgu40rvDaf9Ecs Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/aSqL__ANU2ebh9dRv-wBq7Z-EPY Cc: Apps Discuss , Stephan Bosch , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jun 2014 18:59:26 -0000 >>> It feels a bit odd to update the vacation specification from a document >>> that has very little to do with it. I have no real issue with that, and >>> if you say it is OK to do so, I'd be happy to add that. But, still, it >>> seems a bit awkward and perhaps unexpected for implementers. >> >> Understood. I think it's fine to do that, as long as it's clear what >> the update is, but I do understand why it would seem odd. Ned, Pete >> -- do you have opinions here? > > Especially for this sort of privacy consideration, I think it's unnecessary. > We have a long history of documents (still in use) that have bad or no > advice along these lines (and similarly for security or i18n considerations) > that we don't try to go back to "update" this way. OK, that's good enough for me. Alissa, does the added paragraph to Section 6 work for you as a resolution to this issue? Barry From nobody Fri Jun 20 13:25:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DB61B2905 for ; Fri, 20 Jun 2014 13:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPqcy-BpBEuY for ; Fri, 20 Jun 2014 13:24:56 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF1C1B28FC for ; Fri, 20 Jun 2014 13:24:56 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 4FF54564D01; Fri, 20 Jun 2014 15:24:55 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 46B98A07B6; Fri, 20 Jun 2014 15:24:55 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyM8TO7sPPkr; Fri, 20 Jun 2014 15:24:55 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 20B2AA077C; Fri, 20 Jun 2014 15:24:55 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 10824A078C; Fri, 20 Jun 2014 15:24:55 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id houEgGcGI7qS; Fri, 20 Jun 2014 15:24:54 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id E2385A077C; Fri, 20 Jun 2014 15:24:54 -0500 (CDT) Date: Fri, 20 Jun 2014 15:24:52 -0500 (CDT) From: Franck Martin To: Barry Leiba Message-ID: <1470560924.132851.1403295892170.JavaMail.zimbra@peachymango.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF30 (Mac)/8.0.5_GA_5839) Thread-Topic: Proposed working group: Timezone Data Distribution Service (tzdist) Thread-Index: TY0US+xLmajFHsV3l9N2V0CVVOX3Bw== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nDSknZChHYNja4j_T0-Mfu7HIm4 Cc: Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jun 2014 20:24:59 -0000 ----- Original Message ----- > From: "Barry Leiba" > To: "Apps Discuss" > Sent: Friday, June 20, 2014 8:06:51 AM > Subject: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) > > Cyrus Daboo has proposed a new working group in the Applications Area, > and I'm initiating charter discussion on it: > > https://datatracker.ietf.org/doc/charter-ietf-tzdist/ > > We'll have the charter discussion here on apps-discuss. Assuming a > working group comes out of this, we'll create a new mailing list for > the actual work, once the charter is done. > > Comments on this charter are welcome. I expect to put it on the 10 > July IESG telechat for initial approval, after which it will go out > for IETF and external review. So, comments here by 4 July, please. > > Barry, Applications AD About time.... I used to live in a country, where they would announce timezone changes like 2 weeks in advance, twice a year, every year... In light of the ntp leap second propagation saga, it would be nice to consider the protocol to be able to work in a multi-tiered environment with out of band messaging. I mean, before a change is disseminated to a system, there is the possibility to review and approve such change. I wonder if the charter should mention this architecture design, or just indicate the architecture should allow controlled dissemination of changes within a network sub-system. Finally, I hope the protocol is DoS and DDoS robust. From nobody Fri Jun 20 16:03:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B9A1A0319 for ; Fri, 20 Jun 2014 16:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gg7XHdRJafki for ; Fri, 20 Jun 2014 16:03:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE951A042D for ; Fri, 20 Jun 2014 16:03:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140620230350.22470.39672.idtracker@ietfa.amsl.com> Date: Fri, 20 Jun 2014 16:03:50 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Av495UKgWDCT519ilVXwACHw-VE Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 23:03:54 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-multimailbox-search", resolved as "Done". URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Fri Jun 20 18:08:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6FD1A028C for ; Fri, 20 Jun 2014 18:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ucU7ovwuPnl for ; Fri, 20 Jun 2014 18:07:55 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5C51A0161 for ; Fri, 20 Jun 2014 18:07:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 167466A3127F; Fri, 20 Jun 2014 21:07:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsQ4crtjq-Cr; Fri, 20 Jun 2014 21:07:50 -0400 (EDT) Received: from [10.0.1.22] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 9FA326A31270; Fri, 20 Jun 2014 21:07:49 -0400 (EDT) Date: Fri, 20 Jun 2014 21:07:45 -0400 From: Cyrus Daboo To: Franck Martin Message-ID: In-Reply-To: <1470560924.132851.1403295892170.JavaMail.zimbra@peachymango.org> References: <1470560924.132851.1403295892170.JavaMail.zimbra@peachymango.org> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1500 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/q5SA_wOq5dI6YCdQH-LAnYAdi90 Cc: Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jun 2014 01:08:00 -0000 Hi Franck, --On June 20, 2014 at 3:24:52 PM -0500 Franck Martin wrote: > I used to live in a country, where they would announce timezone changes > like 2 weeks in advance, twice a year, every year... > > In light of the ntp leap second propagation saga, it would be nice to > consider the protocol to be able to work in a multi-tiered environment > with out of band messaging. > > I mean, before a change is disseminated to a system, there is the > possibility to review and approve such change. I wonder if the charter > should mention this architecture design, or just indicate the > architecture should allow controlled dissemination of changes within a > network sub-system. > draft-douglass-timezone-service is meant as a starting point for any WG work. The protocol we defined there is HTTP based (several reasons for that choice that can be discussed in the WG). That document does have an architecture diagram that introduces the concepts of contributors, publishers, providers and clients. In the current scheme of things, the first two of those would map to: IANA timezone list subscribers who post messages about tz changes in their locale (contributors), the IANA tz DB itself (publisher). Anyone running the timezone data distribution server can act as a "primary" or "secondary" - with secondary servers typically use within a LAN for performance etc. So I think we have captured some of what you are after in that initial spec. -- Cyrus Daboo From nobody Fri Jun 20 21:41:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEE61A01BA for ; Fri, 20 Jun 2014 21:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MXJwrAzIzir for ; Fri, 20 Jun 2014 21:40:58 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726FB1A053B for ; Fri, 20 Jun 2014 21:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1237; q=dns/txt; s=iport; t=1403325657; x=1404535257; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=izDlNySyLYiSZ46Xl9yfNipsWqno3bwUcRohluxjBLU=; b=M3QYw/a7U2gDf0q9RjUtecZbzkOAUR5wMyaqxWkbQjsmoziwILk8NZHD gbyVjNbT+bUmWYM2AP2FPeODghxavjzo1GbXoM829WOmMtvpYGot6Irru tZWxVH2pDgmfoaO7nf8XeRBeO4vyQKjsEmLy1KrJZFeYPvYGRj6+NjzVL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFAPULpVOtJssW/2dsb2JhbABZg1+DR6c0AQEBAQEBBQGRa4c/AYEidYQDAQEBBAEBASBLChELGAICBRYLAgIJAwIBAgEVMAYBDAYCAQGIPg2sAZ4zEwSBKoQ4iDxfgneBTAEDmkSLQogYggCBRDuBMQ X-IronPort-AV: E=Sophos;i="5.01,518,1400025600"; d="scan'208";a="93341559" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 21 Jun 2014 04:40:55 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.204.139]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5L4etGM022004; Sat, 21 Jun 2014 04:40:55 GMT Message-ID: <53A50CD7.9060703@cisco.com> Date: Sat, 21 Jun 2014 06:40:55 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Barry Leiba , Apps Discuss References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XkRQsJ4vZAk-JlVYJIjwlDn3yuA Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jun 2014 04:41:00 -0000 Barry, One issue: If there is the possibility of multiple sources of naming of timezones, then there needs to be a way to differentiate those sources, and so naming cannot be entirely out of scope. Rather, the scope should be limited to differentiating the sources. Also, if there is to be a conversion from Olson to this, we should determine who is responsible for that conversion. Eliot On 6/20/14, 5:06 PM, Barry Leiba wrote: > Cyrus Daboo has proposed a new working group in the Applications Area, > and I'm initiating charter discussion on it: > > https://datatracker.ietf.org/doc/charter-ietf-tzdist/ > > We'll have the charter discussion here on apps-discuss. Assuming a > working group comes out of this, we'll create a new mailing list for > the actual work, once the charter is done. > > Comments on this charter are welcome. I expect to put it on the 10 > July IESG telechat for initial approval, after which it will go out > for IETF and external review. So, comments here by 4 July, please. > > Barry, Applications AD > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From nobody Fri Jun 20 22:31:44 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798101B2926 for ; Fri, 20 Jun 2014 22:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVS3YDuRq3xa for ; Fri, 20 Jun 2014 22:31:38 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CAC91B2904 for ; Fri, 20 Jun 2014 22:31:38 -0700 (PDT) Received: from [10.196.219.252] (1-195.icannmeeting.org [199.91.195.1]) by mail.frobbit.se (Postfix) with ESMTPSA id 08C5E22D3C; Sat, 21 Jun 2014 07:31:34 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Sat, 21 Jun 2014 06:31:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Barry Leiba X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2MSjRwcDNV6pyJ9DXlx0caYJGLQ Cc: Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jun 2014 05:31:40 -0000 On 20 jun 2014, at 16:06, Barry Leiba wrote: > Cyrus Daboo has proposed a new working group in the Applications Area, > and I'm initiating charter discussion on it: >=20 > https://datatracker.ietf.org/doc/charter-ietf-tzdist/ >=20 > We'll have the charter discussion here on apps-discuss. Assuming a > working group comes out of this, we'll create a new mailing list for > the actual work, once the charter is done. >=20 > Comments on this charter are welcome. I expect to put it on the 10 > July IESG telechat for initial approval, after which it will go out > for IETF and external review. So, comments here by 4 July, please. I ask what is intended with the following words in the charter: > - The timezone data distribution protocol should be "web friendly" to > allow browser-based calendar clients easy access to the data and API. The reason why I ask is because there are a number of issues in the = current I-D which I do believe is sub-optimal, and just must he hashed = out. I do though see the text above might be used as arguments to kill = such a discussion. I want to know explicitly whether the following = discussions are in scope or not, and if they are not, when and how IETF = are going to address them as I see big problems with the increased = number of specifications that build on these assumptions: 1. Use of SRV records together with HTTP/1.1 referring to "security as = in the HTTP specification" (including HTTPS) and not more Me: I think it could be interesting if this protocol end up explicitly = being HTTP/2 using the strengths of HTTP/2 2. Use of TXT resource records in DNS, and "well known paths" Me: Why is not either a new RR Type defined, or reuse of the URI RR Type = given prefixes for the owner is defined in the I-D 3. Use of "free flow JSON" in the result of the GET Me: Do we know yet how to reference JSON in a normative way? I guess so = -- good in that case, and we should do it more -- and maybe look = explicitly how to transport JSON in HTTP/2 (see above under 1) 4. Use of "standard HTTP security", is that good enough Me: Should we not immediately force the data to be digitally signed, and = how is that done, is that not something we should look at in a generic = way for HTTP/2, i.e. define "if we want to return a signed JSON blob in = HTTP/2, this is how to do it" so that it can be reused in more than one = specification Now, this is written far too early in the morning (before coffee), but = the overall question is whether those kind of discussions are ok in this = wg or whether they should be held elsewhere, and if so, where? Patrik From nobody Sat Jun 21 06:53:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977591A0381 for ; Sat, 21 Jun 2014 06:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2oDUQvH1V5s for ; Sat, 21 Jun 2014 06:53:34 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7DFD1A037C for ; Sat, 21 Jun 2014 06:53:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 28A4B6A3E444; Sat, 21 Jun 2014 09:53:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54CMnZS3S-K8; Sat, 21 Jun 2014 09:53:30 -0400 (EDT) Received: from [10.0.1.22] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id B1A146A3E438; Sat, 21 Jun 2014 09:53:29 -0400 (EDT) Date: Sat, 21 Jun 2014 09:53:27 -0400 From: Cyrus Daboo To: Eliot Lear , Barry Leiba , Apps Discuss Message-ID: In-Reply-To: <53A50CD7.9060703@cisco.com> References: <53A50CD7.9060703@cisco.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=2204 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/cSgvjI69szheOqc7iei6g9uy824 Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jun 2014 13:53:36 -0000 Hi Eliot, --On June 21, 2014 at 6:40:55 AM +0200 Eliot Lear wrote: > If there is the possibility of multiple sources of naming of timezones, > then there needs to be a way to differentiate those sources, and so > naming cannot be entirely out of scope. Rather, the scope should be > limited to differentiating the sources. Yes. I think that is what we were trying to say when indicating that a=20 "namespace prefix" mechanism can be considered. Do you think this point in=20 the proposed charter needs further clarification: - The naming process for timezone identifiers. The working group can consider adding a mechanism, such as a "namespace" prefix, to differentiate different timezone sources, but the nature of the = timezone identifiers used will be controlled by the sources themselves. > Also, if there is to be a conversion from Olson to this, we should > determine who is responsible for that conversion. I think the intent is that "publishers" will continue to publish timezone=20 data in their own format, but the top-level "providers" that use that data=20 will be on the hook for the necessary conversions. Right now we are only=20 suggesting a conversion to iCalendar to satisfy the immediate needs of the=20 calendaring and scheduling folks. However, in the longer term the service=20 could also be used to distribute other formats - for example the "zoneinfo" = files used by many OS's. All that would be needed for that is a suitable=20 MIME type (and perhaps a more formal description of the zoneinfo format=20 itself). Obviously there is a security implication from this approach: the IANA data = is signed as a whole (somewhat unofficially by the TZ coordinator), but the = individual timezone definitions derived from it won't be signed by the=20 same. So clients will need some form of implicit trust in the top-level=20 providers who do the conversion. But that does bring up the question of=20 whether the derived data pieces should each be signed so that when they are = delivered by secondary servers, clients can verify they match what the=20 top-level provider has (I think this is what Patrik F=C3=A4ltstr=C3=B6m is=20 suggesting in his response (point 4). --=20 Cyrus Daboo From nobody Sat Jun 21 07:30:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D4C1A0386 for ; Sat, 21 Jun 2014 07:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayangvyjK118 for ; Sat, 21 Jun 2014 07:29:54 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D711A0096 for ; Sat, 21 Jun 2014 07:29:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id C96FF6A3EE2F; Sat, 21 Jun 2014 10:29:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoP4vPZqrNta; Sat, 21 Jun 2014 10:29:51 -0400 (EDT) Received: from [10.0.1.22] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 5DE8E6A3EE21; Sat, 21 Jun 2014 10:29:51 -0400 (EDT) Date: Sat, 21 Jun 2014 10:29:49 -0400 From: Cyrus Daboo To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Message-ID: <2561110D84090D0D19BD5940@cyrus.local> In-Reply-To: References: X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=4272 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0keJt97skuq6RqmzcqLYS3xhz8Q Cc: Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jun 2014 14:29:56 -0000 Hi Patrik, --On June 21, 2014 at 6:31:29 AM +0100 Patrik F=C3=A4ltstr=C3=B6m = =20 wrote: >> Comments on this charter are welcome. I expect to put it on the 10 >> July IESG telechat for initial approval, after which it will go out >> for IETF and external review. So, comments here by 4 July, please. > > I ask what is intended with the following words in the charter: > >> - The timezone data distribution protocol should be "web friendly" to >> allow browser-based calendar clients easy access to the data and API. > > The reason why I ask is because there are a number of issues in the > current I-D which I do believe is sub-optimal, and just must he hashed > out. I do though see the text above might be used as arguments to kill > such a discussion. One of the key use cases here is to support "thin" clients that don't want=20 to be bothered with the complexity of expanding recurrence rules and=20 exceptions in order to determine local time UTC offsets for arbitrary=20 points in time. For those we have the "expand" action that allows them to=20 request the server to do the recurrence expansion and send back the offsets = over a specified range of time. The starting point for this work was the=20 discovery of the fact that several web calendar apps actually had their own = "private" service that did just that. I think it is important to note that standards-based calendar clients=20 (i.e., ones using iCalendar) are predominantly HTTP based - either via=20 CalDAV or web. So that does need to be an important consideration. > I want to know explicitly whether the following > discussions are in scope or not, and if they are not, when and how IETF > are going to address them as I see big problems with the increased number > of specifications that build on these assumptions: > 1. Use of SRV records together with HTTP/1.1 referring to "security as in > the HTTP specification" (including HTTPS) and not more > > Me: I think it could be interesting if this protocol end up explicitly > being HTTP/2 using the strengths of HTTP/2 I am not sure I see why this would need to be explicitly tied to HTTP/2,=20 versus using either HTTP/1 or HTTP/2. Do we really expect protocols to only = support HTTP/2 and not HTTP/1 (certainly in the near term)? > 2. Use of TXT resource records in DNS, and "well known paths" > > Me: Why is not either a new RR Type defined, or reuse of the URI RR Type > given prefixes for the owner is defined in the I-D I have used SRV+TXT/.well-known in RFC6764 - though I think most=20 deployments of that have ignored the TXT record and just stuck with=20 SRV->.well-known. The following will give examples of that: dig _caldavs._tcp.google.com srv dig _caldavs._tcp.icloud.com srv dig _caldavs._tcp.yahoo.com srv Of course I am familiar with draft-faltstrom-uri and had that been=20 available, and viable from a deployment standpoint, it would probably have=20 been the better choice. > 3. Use of "free flow JSON" in the result of the GET > > Me: Do we know yet how to reference JSON in a normative way? I guess so > -- good in that case, and we should do it more -- and maybe look > explicitly how to transport JSON in HTTP/2 (see above under 1) Well we do have RFC7159 now, and there is also draft-bray-i-json which may=20 be the best option to use. > 4. Use of "standard HTTP security", is that good enough > > Me: Should we not immediately force the data to be digitally signed, and > how is that done, is that not something we should look at in a generic > way for HTTP/2, i.e. define "if we want to return a signed JSON blob in > HTTP/2, this is how to do it" so that it can be reused in more than one > specification I think it is probably important for the data to be signed by top-level=20 providers so that clients who make use of a secondary provider can be=20 assured that the integrity of the data has been preserved. However, there=20 may be cases where that is not possible - e.g., a secondary provider whose=20 sole use is by "internet of things" clients that only care about present=20 and future data - in which case the secondary provider may choose to=20 deliver truncated timezone data, with all the (often large) historical=20 rules removed. That said, I am sure there is plenty of scope for making use of JOSE here. --=20 Cyrus Daboo From nobody Sat Jun 21 07:52:28 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113B91A03AE for ; Sat, 21 Jun 2014 07:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vn757t1OZKgb for ; Sat, 21 Jun 2014 07:52:23 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CFC61A03A7 for ; Sat, 21 Jun 2014 07:52:23 -0700 (PDT) Received: from [10.196.195.173] (218-193.icannmeeting.org [199.91.193.218]) by mail.frobbit.se (Postfix) with ESMTPSA id 53C9322D1E; Sat, 21 Jun 2014 16:52:20 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_AFAE705B-6709-4189-8CD2-10A0AEB4E3E3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <2561110D84090D0D19BD5940@cyrus.local> Date: Sat, 21 Jun 2014 15:52:18 +0100 Message-Id: <136D06EC-40AB-4EFF-9413-D2729E818F55@frobbit.se> References: <2561110D84090D0D19BD5940@cyrus.local> To: Cyrus Daboo X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9BI26HXk_L7gqL3wg9a0PZiEW7E Cc: Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jun 2014 14:52:26 -0000 --Apple-Mail=_AFAE705B-6709-4189-8CD2-10A0AEB4E3E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 21 jun 2014, at 15:29, Cyrus Daboo wrote: > Hi Patrik, Hi Cyrus! > --On June 21, 2014 at 6:31:29 AM +0100 Patrik F=E4ltstr=F6m = wrote: >=20 >>> Comments on this charter are welcome. I expect to put it on the 10 >>> July IESG telechat for initial approval, after which it will go out >>> for IETF and external review. So, comments here by 4 July, please. >>=20 >> I ask what is intended with the following words in the charter: >>=20 >>> - The timezone data distribution protocol should be "web friendly" = to >>> allow browser-based calendar clients easy access to the data and = API. >>=20 >> The reason why I ask is because there are a number of issues in the >> current I-D which I do believe is sub-optimal, and just must he = hashed >> out. I do though see the text above might be used as arguments to = kill >> such a discussion. > One of the key use cases here is to support "thin" clients that don't = want to be bothered with the complexity of expanding recurrence rules = and exceptions in order to determine local time UTC offsets for = arbitrary points in time. For those we have the "expand" action that = allows them to request the server to do the recurrence expansion and = send back the offsets over a specified range of time. The starting point = for this work was the discovery of the fact that several web calendar = apps actually had their own "private" service that did just that. Understood. The question here is whether this spec should "follow" and = only use features that exists on the market today, or "driver" that = pushes a good design onto the market. What I hear you say is that it is to be a "follower". My point is that I think it is important to know *now* at the time of = chartering. > I think it is important to note that standards-based calendar clients = (i.e., ones using iCalendar) are predominantly HTTP based - either via = CalDAV or web. So that does need to be an important consideration. Understood. >> I want to know explicitly whether the following >> discussions are in scope or not, and if they are not, when and how = IETF >> are going to address them as I see big problems with the increased = number >> of specifications that build on these assumptions: >=20 >> 1. Use of SRV records together with HTTP/1.1 referring to "security = as in >> the HTTP specification" (including HTTPS) and not more >>=20 >> Me: I think it could be interesting if this protocol end up = explicitly >> being HTTP/2 using the strengths of HTTP/2 >=20 > I am not sure I see why this would need to be explicitly tied to = HTTP/2, versus using either HTTP/1 or HTTP/2. Do we really expect = protocols to only support HTTP/2 and not HTTP/1 (certainly in the near = term)? Agree, but the question is whether a protocol could be optimized for = HTTP/2 and then there might be a "backward compatibility" (with lower = functionality, not as optimal) for HTTP/1. >> 2. Use of TXT resource records in DNS, and "well known paths" >>=20 >> Me: Why is not either a new RR Type defined, or reuse of the URI RR = Type >> given prefixes for the owner is defined in the I-D >=20 > I have used SRV+TXT/.well-known in RFC6764 - though I think most = deployments of that have ignored the TXT record and just stuck with = SRV->.well-known. The following will give examples of that: >=20 > dig _caldavs._tcp.google.com srv > dig _caldavs._tcp.icloud.com srv > dig _caldavs._tcp.yahoo.com srv >=20 > Of course I am familiar with draft-faltstrom-uri and had that been = available, and viable from a deployment standpoint, it would probably = have been the better choice. That draft is blocked by review in the IETF for reasons I am author has = no idea why it is blocked. I have requested publication a number of = times from our dear AD's. That said, the Resource Record Type has been registered for quite some = time now as Resource Record Types do not need RFCs for registrations. >> 3. Use of "free flow JSON" in the result of the GET >>=20 >> Me: Do we know yet how to reference JSON in a normative way? I guess = so >> -- good in that case, and we should do it more -- and maybe look >> explicitly how to transport JSON in HTTP/2 (see above under 1) >=20 > Well we do have RFC7159 now, and there is also draft-bray-i-json which = may be the best option to use. Good. >> 4. Use of "standard HTTP security", is that good enough >>=20 >> Me: Should we not immediately force the data to be digitally signed, = and >> how is that done, is that not something we should look at in a = generic >> way for HTTP/2, i.e. define "if we want to return a signed JSON blob = in >> HTTP/2, this is how to do it" so that it can be reused in more than = one >> specification >=20 > I think it is probably important for the data to be signed by = top-level providers so that clients who make use of a secondary provider = can be assured that the integrity of the data has been preserved. = However, there may be cases where that is not possible - e.g., a = secondary provider whose sole use is by "internet of things" clients = that only care about present and future data - in which case the = secondary provider may choose to deliver truncated timezone data, with = all the (often large) historical rules removed. >=20 > That said, I am sure there is plenty of scope for making use of JOSE = here. Ok. Patrik --Apple-Mail=_AFAE705B-6709-4189-8CD2-10A0AEB4E3E3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTpZwirMabGguI180RAiVeAJsGV+ZCEeYX7NoxV/k0faEvK7r0+wCbBN8v 6gvP13ggpKtKqD7NBdojUr8= =Kbt+ -----END PGP SIGNATURE----- --Apple-Mail=_AFAE705B-6709-4189-8CD2-10A0AEB4E3E3-- From nobody Sat Jun 21 15:40:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546981B2823; Sat, 21 Jun 2014 15:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZtWrrv-A2zo; Sat, 21 Jun 2014 15:40:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FCE1A0309; Sat, 21 Jun 2014 15:40:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140621224002.29949.29185.idtracker@ietfa.amsl.com> Date: Sat, 21 Jun 2014 15:40:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hgoteBiWFshYfFfOnInDwO9b3jM Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Adrian Farrel's No Objection on draft-ietf-appsawg-sieve-duplicate-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 22:40:04 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-appsawg-sieve-duplicate-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A small point that is not at the level of a Discuss, but... Are there not some implications on the integrity of the message ID on a message that should be stated. Clearly, if a message ID can be touched, the message can be made to appear to be a duplicate causing the sieve to throw it out. From nobody Sat Jun 21 16:06:36 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87751B282F; Sat, 21 Jun 2014 16:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAXp3Q04xrYZ; Sat, 21 Jun 2014 16:06:23 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0301B2826; Sat, 21 Jun 2014 16:06:23 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P9A4M182800057BN@mauve.mrochek.com>; Sat, 21 Jun 2014 16:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1403391670; bh=UozvYnEokBuPYhO6MurFjGKnKb2eMCDfTKRfjyHce0s=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=fXVCy7Ig1yId5aFndsPDyaA5bmtQR0FbpX4lVUR1qkloTnPNl+khYHZN/8VS3Th2s VW5IHIiul1ViQKkoSMQ/Q5CNB8v7Q7WGR8FMqTkO9x+BVSeJ4EpLHWoz1mmv3UJX/U ovnczPC27RJgzz2BIwEEcs8G4BhmlKIdulY2JR7A= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Sat, 21 Jun 2014 16:01:08 -0700 (PDT) Message-id: <01P9A4LZRC5K0049PU@mauve.mrochek.com> Date: Sat, 21 Jun 2014 15:54:56 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 21 Jun 2014 15:40:02 -0700" <20140621224002.29949.29185.idtracker@ietfa.amsl.com> References: <20140621224002.29949.29185.idtracker@ietfa.amsl.com> To: Adrian Farrel Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/rVIPtfLPj92WN8TTIiPNZ3Mpy1s Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, The IESG , apps-discuss@ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org Subject: Re: [apps-discuss] Adrian Farrel's No Objection on draft-ietf-appsawg-sieve-duplicate-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jun 2014 23:06:25 -0000 > Adrian Farrel has entered the following ballot position for > draft-ietf-appsawg-sieve-duplicate-07: No Objection > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > A small point that is not at the level of a Discuss, but... > Are there not some implications on the integrity of the message ID on a > message that should be stated. Clearly, if a message ID can be touched, > the message can be made to appear to be a duplicate causing the sieve to > throw it out. If a message-id can be touched, so can the message. What's to prevent someone from removing the message content, or inserting a known virus, or for that matter modifying the envelope so the message doesn't even make it to the user? If you have the ability to modify a message in transit, there are a myriad of things you can do to it that would render it undeliverable, insure that it gets discarded, etc. Out of all these things, why would you pick one that not only requires that the recipient be using a particular Sieve extension in a particular way, but also requires knowledge of more than one message? I'm really not seeing an actual issue here. Ned From tki@tki.so Fri Jun 20 08:37:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139101B281C for ; Fri, 20 Jun 2014 08:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iy46ULynzcH7 for ; Fri, 20 Jun 2014 08:37:45 -0700 (PDT) Received: from SNT004-OMC4S37.hotmail.com (snt004-omc4s37.hotmail.com [65.55.90.240]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C7B1B2833 for ; Fri, 20 Jun 2014 08:37:36 -0700 (PDT) Received: from SNT153-W39 ([65.55.90.199]) by SNT004-OMC4S37.hotmail.com with Microsoft SMTPSVC(7.5.7601.22701); Fri, 20 Jun 2014 08:37:35 -0700 X-TMN: [DtoDM2OWVlL5sdYFE/Ie/XMazphoeJBs] X-Originating-Email: [tki@tki.so] Message-ID: Content-Type: multipart/alternative; boundary="_d1714cfc-50ec-4821-874b-b56bb98885e2_" From: Tki April To: t.petch , Barry Leiba , Apps Discuss Date: Fri, 20 Jun 2014 08:37:35 -0700 Importance: Normal In-Reply-To: <043201cf8c8d$194d2fc0$4001a8c0@gateway.2wire.net> References: <20140328105940.ADCCF7FC2CB@rfc-editor.org> , <043201cf8c8d$194d2fc0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2014 15:37:35.0981 (UTC) FILETIME=[8F59B9D0:01CF8C9D] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8gDqgqNWOasKHgVrmMDC9roqYkw X-Mailman-Approved-At: Sat, 21 Jun 2014 21:28:11 -0700 Subject: Re: [apps-discuss] [Technical Errata Reported] RFC1459 (3938) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jun 2014 15:45:10 -0000 --_d1714cfc-50ec-4821-874b-b56bb98885e2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When I reported this erratum=2C I recognized that RFC 1459 was updatedby RF= C2810-2813=2C but was curious to find out that no one had pointedout the cl= early missing sentence. I do understand that it is not a criticalmatter. ThanksMyunggyun Seo > From: ietfc@btconnect.com > To: barryleiba@computer.org=3B apps-discuss@ietf.org > CC: tki@tki.so > Subject: Re: [apps-discuss] [Technical Errata Reported] RFC1459 (3938) > Date: Fri=2C 20 Jun 2014 14:32:14 +0100 >=20 > Barry >=20 > RFC1459 s4.2.3.1 is updated by RFC2812 s3.2.3 and=2C in part=2C by RFC281= 1 > s4. >=20 > Comparing those two last with RFC1459=2C I think it clear that a page has > been missed=2C giving the Numeric Replies and Examples. >=20 > The equivalent to the truncated sentence=2C > "When using the 'o' and 'b' options=2C a restriction on a total of three > per mode command has been imposed. That is=2C any combination of 'o' > and" > is now > " Note that there is a maximum limit of three (3) changes per > command for modes that take a parameter." >=20 > I think that the erratum should point out that RFC1459 has been > updated - Obsoleted I would call it - and that a comprehensive > description can be found in the RFC281x. Trying to reconstruct the > missing page seems unproductive. >=20 > I am curious whether or not the raiser of this was aware of the later > RFC=2C which seem to me to resolve any issues. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Barry Leiba" > To: "Apps Discuss" > Cc: "Myunggyun Jonathan Aldo Seo" > Sent: Wednesday=2C April 16=2C 2014 4:56 PM >=20 > > Myunggyun Jonathan Aldo Seo has reported the errata below=2C on RFC > > 1459=2C the IRC protocol. He's correct that the last paragraph of > > Section 4.2.3.1 has clearly been truncated. But=2C as this is a > > more-than-20-year-old document=2C it's likely hard to know what the tex= t > > was intended to say. > > > > Here's Section 4.2.3.1 in its entirety: > > > > ------------------------------------- > > 4.2.3.1 Channel modes > > > > Parameters: {[+|-]|o|p|s|i|t|n|b|v} [] [] > > [] > > > > The MODE command is provided so that channel operators may change > the > > characteristics of `their' channel. It is also required that > servers > > be able to change channel modes so that channel operators may be > > created. > > > > The various modes available for channels are as follows: > > > > o - give/take channel operator privileges=3B > > p - private channel flag=3B > > s - secret channel flag=3B > > i - invite-only channel flag=3B > > t - topic settable by channel operator only flag=3B > > n - no messages to channel from clients on the outside=3B > > m - moderated channel=3B > > l - set the user limit to channel=3B > > b - set a ban mask to keep users out=3B > > v - give/take the ability to speak on a moderated channel=3B > > k - set a channel key (password). > > > > When using the 'o' and 'b' options=2C a restriction on a total of > three > > per mode command has been imposed. That is=2C any combination of 'o= ' > > and > > ------------------------------------- > > > > I would like to mark the errata report as Verified=2C but it would be > > nice to be able to suggest correct text in the report. Can anyone > > help figure out what was supposed to be there? If not=2C I'll likely > > mark it "Held For Document Update" instead. > > > > Barry > > > > On Fri=2C Mar 28=2C 2014 at 6:59 AM=2C RFC Errata System > > wrote: > > > The following errata report has been submitted for RFC1459=2C > > > "Internet Relay Chat Protocol". > > > > > > -------------------------------------- > > > You may review the report below and at: > > > http://www.rfc-editor.org/errata_search.php?rfc=3D1459&eid=3D3938 > > > > > > -------------------------------------- > > > Type: Technical > > > Reported by: Myunggyun Jonathan Aldo Seo > > > > > > Section: 4.2.3.1 > > > > > > Original Text > > > ------------- > > > When using the 'o' and 'b' options=2C a restriction on a total of > three > > > per mode command has been imposed. That is=2C any combination of > 'o' > > > and > > > > > > Corrected Text > > > -------------- > > > > > > > > > Notes > > > ----- > > > The sentence lacks the last part and does not explain what it > expected to. > > > > > > Instructions: > > > ------------- > > > This errata is currently posted as "Reported". If necessary=2C please > > > use "Reply All" to discuss whether it should be verified or > > > rejected. When a decision is reached=2C the verifying party (IESG) > > > can log in to change the status and edit the report=2C if necessary. > > > > > > -------------------------------------- > > > RFC1459 (no draft string recorded) > > > -------------------------------------- > > > Title : Internet Relay Chat Protocol > > > Publication Date : May 1993 > > > Author(s) : J. Oikarinen=2C D. Reed > > > Category : EXPERIMENTAL > > > Source : Legacy > > > Area : Legacy > > > Stream : IETF > > > Verifying Party : IESG > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 = --_d1714cfc-50ec-4821-874b-b56bb98885e2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
When I reported this erratum=2C = I recognized that RFC 1459 was =3Bup= dated
by RFC2810-2813=2C = =3Bbut was curious to find out th= at no one had =3Bpointed
out the clearly missing&nbs= p=3Bsentence. I do understand tha= t it is not =3Ba critical
matter.
<= span style=3D"font-size: 12pt=3B">
Thanks
= Myunggyun Seo

>=3B From: ietfc@btconnect.c= om
>=3B To: barryleiba@computer.org=3B apps-discuss@ietf.org
>=3B= CC: tki@tki.so
>=3B Subject: Re: [apps-discuss] [Technical Errata Rep= orted] RFC1459 (3938)
>=3B Date: Fri=2C 20 Jun 2014 14:32:14 +0100
= >=3B
>=3B Barry
>=3B
>=3B RFC1459 s4.2.3.1 is updated by= RFC2812 s3.2.3 and=2C in part=2C by RFC2811
>=3B s4.
>=3B
&g= t=3B Comparing those two last with RFC1459=2C I think it clear that a page = has
>=3B been missed=2C giving the Numeric Replies and Examples.
&g= t=3B
>=3B The equivalent to the truncated sentence=2C
>=3B "When= using the 'o' and 'b' options=2C a restriction on a total of three
>= =3B per mode command has been imposed. That is=2C any combination of 'o= '
>=3B and"
>=3B is now
>=3B " Note that there is a maxim= um limit of three (3) changes per
>=3B command for modes that take = a parameter."
>=3B
>=3B I think that the erratum should point ou= t that RFC1459 has been
>=3B updated - Obsoleted I would call it - and= that a comprehensive
>=3B description can be found in the RFC281x. T= rying to reconstruct the
>=3B missing page seems unproductive.
>= =3B
>=3B I am curious whether or not the raiser of this was aware of = the later
>=3B RFC=2C which seem to me to resolve any issues.
>= =3B
>=3B Tom Petch
>=3B
>=3B ----- Original Message -----<= br>>=3B From: "Barry Leiba" <=3Bbarryleiba@computer.org>=3B
>=3B= To: "Apps Discuss" <=3Bapps-discuss@ietf.org>=3B
>=3B Cc: "Myungg= yun Jonathan Aldo Seo" <=3Btki@tki.so>=3B
>=3B Sent: Wednesday=2C = April 16=2C 2014 4:56 PM
>=3B
>=3B >=3B Myunggyun Jonathan Ald= o Seo has reported the errata below=2C on RFC
>=3B >=3B 1459=2C the = IRC protocol. He's correct that the last paragraph of
>=3B >=3B Sec= tion 4.2.3.1 has clearly been truncated. But=2C as this is a
>=3B >= =3B more-than-20-year-old document=2C it's likely hard to know what the tex= t
>=3B >=3B was intended to say.
>=3B >=3B
>=3B >=3B H= ere's Section 4.2.3.1 in its entirety:
>=3B >=3B
>=3B >=3B --= -----------------------------------
>=3B >=3B 4.2.3.1 Channel modes<= br>>=3B >=3B
>=3B >=3B Parameters: <=3Bchannel>=3B {[+|-]= |o|p|s|i|t|n|b|v} [<=3Blimit>=3B] [<=3Buser>=3B]
>=3B >=3B = [<=3Bban mask>=3B]
>=3B >=3B
>=3B >=3B T= he MODE command is provided so that channel operators may change
>=3B = the
>=3B >=3B characteristics of `their' channel. It is also req= uired that
>=3B servers
>=3B >=3B be able to change channel = modes so that channel operators may be
>=3B >=3B created.
>= =3B >=3B
>=3B >=3B The various modes available for channels are= as follows:
>=3B >=3B
>=3B >=3B o - give/take cha= nnel operator privileges=3B
>=3B >=3B p - private channel= flag=3B
>=3B >=3B s - secret channel flag=3B
>=3B &= gt=3B i - invite-only channel flag=3B
>=3B >=3B = t - topic settable by channel operator only flag=3B
>=3B >=3B = n - no messages to channel from clients on the outside=3B
>=3B = >=3B m - moderated channel=3B
>=3B >=3B l - = set the user limit to channel=3B
>=3B >=3B b - set a ban = mask to keep users out=3B
>=3B >=3B v - give/take the abi= lity to speak on a moderated channel=3B
>=3B >=3B k - set= a channel key (password).
>=3B >=3B
>=3B >=3B When using = the 'o' and 'b' options=2C a restriction on a total of
>=3B three
&= gt=3B >=3B per mode command has been imposed. That is=2C any combinat= ion of 'o'
>=3B >=3B and
>=3B >=3B -----------------------= --------------
>=3B >=3B
>=3B >=3B I would like to mark the e= rrata report as Verified=2C but it would be
>=3B >=3B nice to be abl= e to suggest correct text in the report. Can anyone
>=3B >=3B help = figure out what was supposed to be there? If not=2C I'll likely
>=3B = >=3B mark it "Held For Document Update" instead.
>=3B >=3B
>= =3B >=3B Barry
>=3B >=3B
>=3B >=3B On Fri=2C Mar 28=2C 2014= at 6:59 AM=2C RFC Errata System
>=3B >=3B <=3Brfc-editor@rfc-edit= or.org>=3B wrote:
>=3B >=3B >=3B The following errata report has= been submitted for RFC1459=2C
>=3B >=3B >=3B "Internet Relay Chat= Protocol".
>=3B >=3B >=3B
>=3B >=3B >=3B ---------------= -----------------------
>=3B >=3B >=3B You may review the report b= elow and at:
>=3B >=3B >=3B http://www.rfc-editor.org/errata_searc= h.php?rfc=3D1459&=3Beid=3D3938
>=3B >=3B >=3B
>=3B >=3B = >=3B --------------------------------------
>=3B >=3B >=3B Type:= Technical
>=3B >=3B >=3B Reported by: Myunggyun Jonathan Aldo Seo= <=3Btki@tki.so>=3B
>=3B >=3B >=3B
>=3B >=3B >=3B Sec= tion: 4.2.3.1
>=3B >=3B >=3B
>=3B >=3B >=3B Original Text=
>=3B >=3B >=3B -------------
>=3B >=3B >=3B When usin= g the 'o' and 'b' options=2C a restriction on a total of
>=3B three>=3B >=3B >=3B per mode command has been imposed. That is=2C any= combination of
>=3B 'o'
>=3B >=3B >=3B and
>=3B >= =3B >=3B
>=3B >=3B >=3B Corrected Text
>=3B >=3B >=3B -= -------------
>=3B >=3B >=3B
>=3B >=3B >=3B
>=3B >= =3B >=3B Notes
>=3B >=3B >=3B -----
>=3B >=3B >=3B The = sentence lacks the last part and does not explain what it
>=3B expecte= d to.
>=3B >=3B >=3B
>=3B >=3B >=3B Instructions:
>= =3B >=3B >=3B -------------
>=3B >=3B >=3B This errata is curr= ently posted as "Reported". If necessary=2C please
>=3B >=3B >=3B = use "Reply All" to discuss whether it should be verified or
>=3B >= =3B >=3B rejected. When a decision is reached=2C the verifying party (IES= G)
>=3B >=3B >=3B can log in to change the status and edit the rep= ort=2C if necessary.
>=3B >=3B >=3B
>=3B >=3B >=3B ------= --------------------------------
>=3B >=3B >=3B RFC1459 (no draft = string recorded)
>=3B >=3B >=3B ----------------------------------= ----
>=3B >=3B >=3B Title : Internet Relay Chat Prot= ocol
>=3B >=3B >=3B Publication Date : May 1993
>=3B >= =3B >=3B Author(s) : J. Oikarinen=2C D. Reed
>=3B >=3B &= gt=3B Category : EXPERIMENTAL
>=3B >=3B >=3B Source = : Legacy
>=3B >=3B >=3B Area : Legacy
= >=3B >=3B >=3B Stream : IETF
>=3B >=3B >=3B Ver= ifying Party : IESG
>=3B >=3B >=3B
>=3B >=3B
>=3B = >=3B _______________________________________________
>=3B >=3B app= s-discuss mailing list
>=3B >=3B apps-discuss@ietf.org
>=3B >= =3B https://www.ietf.org/mailman/listinfo/apps-discuss
>=3B
=
= --_d1714cfc-50ec-4821-874b-b56bb98885e2_-- From nobody Sat Jun 21 23:30:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DAF1A04CD for ; Sat, 21 Jun 2014 23:30:20 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wui3JNtvgX3w for ; Sat, 21 Jun 2014 23:30:19 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD1C1A01C5 for ; Sat, 21 Jun 2014 23:30:18 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id r20so2559619wiv.14 for ; Sat, 21 Jun 2014 23:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5sXomR6NppVLx9C61Hrnrce1m/jHxwOCr6Z7XmhFylQ=; b=eEIsqPd69jtcJ/+oomT1YyNdpFMTC6xwtzC85QbBIIOnEbsNPAFG12MaJT1BMhjU43 OEr9a1D93qFgbuhSFLOawtBjyuPpDxvKmkzICFzaFQExn0IeIcHZ5orJnId913biF/3t BqD5Csj9uYdIUYo6LFCLEzhqbbRg3L63mHyGNBNavNIHVtwgugQyih4j47nW0VEdmXm0 GW68+Y+ZpJNmIWmAhidIR+LUwx3BKEueShyRyL+msrZYAAvl2sY2o2arSbtR1KSGgdIB wKZF6S4rUIQBlDJuAsDe6NBx9jFTM2KoCK5SQcbcA7op7kcCgRdbqOgZn+GrdrzjESuE cjxg== MIME-Version: 1.0 X-Received: by 10.194.243.104 with SMTP id wx8mr17102144wjc.32.1403418616984; Sat, 21 Jun 2014 23:30:16 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Sat, 21 Jun 2014 23:30:16 -0700 (PDT) In-Reply-To: References: Date: Sat, 21 Jun 2014 23:30:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e014940f022fce404fc66dc3c Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wraFOBtK2Bv70XWmUa68iie6_P4 Subject: Re: [apps-discuss] IETF 90 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jun 2014 06:30:20 -0000 --089e014940f022fce404fc66dc3c Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 7:26 AM, Murray S. Kucherawy wrote: > Colleagues, > > The window is open for us to request a meeting slot for Toronto. We'll be > requesting our usual APPSAWG/APPAREA Monday morning 9:30 slot with the > usual conflict set. > > Please propose agenda items for this meeting in response to this thread. > We'll have our usual updates from the co-chairs and ADs and will be > inviting chairs of BoFs and newly formed working groups to give short > presentations on what's happening during the week. > > If you are working on a document in APPSAWG that requires face time to > resolve some issues, or would like to make or request a presentation on a > particular topic, please let us know ASAP. Our preliminary agenda is due > to the Secretariat on Friday, June 20th. > We received only one reply to this, so at the moment, apart from our usual administrivia and new WG/BoF overviews, this is going to be a pretty short meeting with a pretty large "Any Other Business" slot. Second call -- please submit agenda requests ASAP. -MSK, APPSAWG co-chair --089e014940f022fce404fc66dc3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 27, 2014 at 7:26 AM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
Colleagues,<= br>
The window is open for us to request a meeting slot for Toront= o.=C2=A0 We'll be requesting our usual APPSAWG/APPAREA Monday morning 9= :30 slot with the usual conflict set.

Please propose agenda items for this meeting in response to this = thread.=C2=A0 We'll have our usual updates from the co-chairs and ADs a= nd will be inviting chairs of BoFs and newly formed working groups to give = short presentations on what's happening during the week.

If you are working on a document in APPSAWG that requires face time to = resolve some issues, or would like to make or request a presentation on a p= articular topic, please let us know ASAP.=C2=A0 Our preliminary agenda is d= ue to the Secretariat on Friday, June 20th.

We received only one reply to = this, so at the moment, apart from our usual administrivia and new WG/BoF o= verviews, this is going to be a pretty short meeting with a pretty large &q= uot;Any Other Business" slot.

Second call -- please submit agenda requests ASAP.

-MSK, APPSAWG co-chair
=C2=A0
--089e014940f022fce404fc66dc3c-- From nobody Sun Jun 22 04:13:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF941B279C for ; Sun, 22 Jun 2014 04:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.451 X-Spam-Level: X-Spam-Status: No, score=-7.451 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT_NbhLmMnfQ for ; Sun, 22 Jun 2014 04:13:53 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056AD1A035F for ; Sun, 22 Jun 2014 04:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10659; q=dns/txt; s=iport; t=1403435633; x=1404645233; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=V/8zveZU0jr10GPnHwfW2PBz/Yhx3EmpoJL1cJdTEpM=; b=Wg7fUldcBlMf5dIqUVH0P89TDagf4KbXCajNrQQVdCv6d1F4Azu2xv7b CMXCia6E9s1X4u18rUH69cUYEDjECZp5x+EaVhefopQXX/prWPB7OIVCp TQurmkTVKM6Sr9cH2xEiIMb3DYLHh2vbHXkawKzPvl2nAi2E62VNld7aZ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsFAFe5plOtJssW/2dsb2JhbABZhyanNgEBAQEBAQUBmTUBgRl1hAMBAQEDASNVBgsLGAkWCwICCQMCAQIBRQYBDAYCAQGINgioLp1kF4VjiEFfgneBTAEDmkyLR4gcggCBRDuBMQ X-IronPort-AV: E=Sophos; i="5.01,523,1400025600"; d="scan'208,217"; a="94910763" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 22 Jun 2014 11:13:51 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.161.100]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5MBDobw005245; Sun, 22 Jun 2014 11:13:50 GMT Message-ID: <53A6BA6E.9000404@cisco.com> Date: Sun, 22 Jun 2014 13:13:50 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Cyrus Daboo , Barry Leiba , Apps Discuss References: <53A50CD7.9060703@cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------060208000208020400020303" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Je1lfkumgdKWrF0qA8ud4TnfNMw Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jun 2014 11:13:56 -0000 This is a multi-part message in MIME format. --------------060208000208020400020303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 6/21/14, 3:53 PM, Cyrus Daboo wrote: > Hi Eliot, > > --On June 21, 2014 at 6:40:55 AM +0200 Eliot Lear wrote: > >> If there is the possibility of multiple sources of naming of timezones, >> then there needs to be a way to differentiate those sources, and so >> naming cannot be entirely out of scope. Rather, the scope should be >> limited to differentiating the sources. > > Yes. I think that is what we were trying to say when indicating that a > "namespace prefix" mechanism can be considered. Do you think this > point in the proposed charter needs further clarification: > > - The naming process for timezone identifiers. The working group can > consider adding a mechanism, such as a "namespace" prefix, to > differentiate different timezone sources, but the nature of the > timezone > identifiers used will be controlled by the sources themselves. Perfect. > >> Also, if there is to be a conversion from Olson to this, we should >> determine who is responsible for that conversion. > > I think the intent is that "publishers" will continue to publish > timezone data in their own format, but the top-level "providers" that > use that data will be on the hook for the necessary conversions. Right > now we are only suggesting a conversion to iCalendar to satisfy the > immediate needs of the calendaring and scheduling folks. However, in > the longer term the service could also be used to distribute other > formats - for example the "zoneinfo" files used by many OS's. All that > would be needed for that is a suitable MIME type (and perhaps a more > formal description of the zoneinfo format itself). > > Obviously there is a security implication from this approach: the IANA > data is signed as a whole (somewhat unofficially by the TZ > coordinator), but the individual timezone definitions derived from it > won't be signed by the same. So clients will need some form of > implicit trust in the top-level providers who do the conversion. But > that does bring up the question of whether the derived data pieces > should each be signed so that when they are delivered by secondary > servers, clients can verify they match what the top-level provider has > (I think this is what Patrik Fältström is suggesting in his response > (point 4). > Ok. So scaling this doesn't fall on IANA's head, nor does IANA have to publish alternate formats, right? If so, THAT should be made crystal clear in the charter. So should the possibility that this group may ask for some adjustments to how data is signed by the TZ maintainer, if that is a possibility. I'd suggest that the tz list be kept abreast of this. Also, I am a little concerned about the laundry list of requirements found in the charter. In particular: > - The timezone data distribution protocol should also offer an API to > allow thin clients to easily make use of timezone data by querying for > UTC offsets, offloading the sometimes complex work of expanding > recurrence rules to the service. This API should be extensible to > support other types of timezone operations in the future. To be clear, your starting point does not offer an API. It is amenable to one, perhaps. But that won't really be known until there is one. I think you really meant "capability" and not "API". Whether this is the same or different protocols is IMHO an important design question that should be decided now, and I'm glad you've asserted a proposal. In looking at draft-douglass-timezone-service it requires a pretty fully understanding of CalDAV. Is that indeed appropriate for a thin client? > - The timezone data distribution protocol will initially be targeted at > iCalendar-based clients, but should be flexible enough to deliver > timezone data in other formats. IMHO interoperability demands that this statement be justified. IMHO that's a matter for a working group to debate over. To a lesser extent I have concerns about this statement: > The timezone data distribution protocol should be "web friendly" to > allow browser-based calendar clients easy access to the data and API. This seems to be a "let's do it in JSON" requirement. IMHO there is little need for this statement, given the starting point. Eliot --------------060208000208020400020303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 6/21/14, 3:53 PM, Cyrus Daboo wrote:
Hi Eliot,

--On June 21, 2014 at 6:40:55 AM +0200 Eliot Lear <lear@cisco.com> wrote:

If there is the possibility of multiple sources of naming of timezones,
then there needs to be a way to differentiate those sources, and so
naming cannot be entirely out of scope.  Rather, the scope should be
limited to differentiating the sources.

Yes. I think that is what we were trying to say when indicating that a "namespace prefix" mechanism can be considered. Do you think this point in the proposed charter needs further clarification:

   - The naming process for timezone identifiers.  The working group can
   consider adding a mechanism, such as a "namespace" prefix, to
   differentiate different timezone sources, but the nature of the timezone
   identifiers used will be controlled by the sources themselves.

Perfect.

Also, if there is to be a conversion from Olson to this, we should
determine who is responsible for that conversion.

I think the intent is that "publishers" will continue to publish timezone data in their own format, but the top-level "providers" that use that data will be on the hook for the necessary conversions. Right now we are only suggesting a conversion to iCalendar to satisfy the immediate needs of the calendaring and scheduling folks. However, in the longer term the service could also be used to distribute other formats - for example the "zoneinfo" files used by many OS's. All that would be needed for that is a suitable MIME type (and perhaps a more formal description of the zoneinfo format itself).

Obviously there is a security implication from this approach: the IANA data is signed as a whole (somewhat unofficially by the TZ coordinator), but the individual timezone definitions derived from it won't be signed by the same. So clients will need some form of implicit trust in the top-level providers who do the conversion. But that does bring up the question of whether the derived data pieces should each be signed so that when they are delivered by secondary servers, clients can verify they match what the top-level provider has (I think this is what Patrik Fältström is suggesting in his response (point 4).


Ok.  So scaling this doesn't fall on IANA's head, nor does IANA have to publish alternate formats, right?  If so, THAT should be made crystal clear in the charter.  So should the possibility that this group may ask for some adjustments to how data is signed by the TZ maintainer, if that is a possibility.  I'd suggest that the tz list be kept abreast of this.

Also, I am a little concerned about the laundry list of requirements found in the charter.  In particular:

- The timezone data distribution protocol should also offer an API to
allow thin clients to easily make use of timezone data by querying for
UTC offsets, offloading the sometimes complex work of expanding
recurrence rules to the service. This API should be extensible to
support other types of timezone operations in the future.

To be clear, your starting point does not offer an API.  It is amenable to one, perhaps.  But that won't really be known until there is one.  I think you really meant "capability" and not "API".  Whether this is the same or different protocols is IMHO an important design question that should be decided now, and I'm glad you've asserted a proposal.  In looking at draft-douglass-timezone-service it requires a pretty fully understanding of CalDAV.  Is that indeed appropriate for a thin client?

- The timezone data distribution protocol will initially be targeted at
iCalendar-based clients, but should be flexible enough to deliver
timezone data in other formats.

IMHO interoperability demands that this statement be justified.  IMHO that's a matter for a working group to debate over.

To a lesser extent I have concerns about this statement:

 The timezone data distribution protocol should be "web friendly" to
allow browser-based calendar clients easy access to the data and API.

This seems to be a "let's do it in JSON" requirement.  IMHO there is little need for this statement, given the starting point.

Eliot
--------------060208000208020400020303-- From nobody Sun Jun 22 04:47:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAED1B292B; Sun, 22 Jun 2014 04:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sbawC0WpKZ4; Sun, 22 Jun 2014 04:47:33 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5133E1B2921; Sun, 22 Jun 2014 04:47:32 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5MBlUEQ022424; Sun, 22 Jun 2014 12:47:30 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5MBlSlF022417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 22 Jun 2014 12:47:29 +0100 From: "Adrian Farrel" To: "'Ned Freed'" References: <20140621224002.29949.29185.idtracker@ietfa.amsl.com> <01P9A4LZRC5K0049PU@mauve.mrochek.com> In-Reply-To: <01P9A4LZRC5K0049PU@mauve.mrochek.com> Date: Sun, 22 Jun 2014 12:47:28 +0100 Message-ID: <005201cf8e0f$bf3aa920$3daffb60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMnke4J5PiP4tSfuLbqd3qanhFo7wHmISs0mL3H2kA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20772.006 X-TM-AS-Result: No--27.432-10.0-31-10 X-imss-scan-details: No--27.432-10.0-31-10 X-TMASE-MatchedRID: vbSD0OnL8/LaOWCt37RI5rAcrYExeE00gHzgwy8qV5rjB19nvhZ7jRmz bknjanDfefqT5UST24nxTwx4UJIMcttYagCyhdujdXu122+iJtqmuYKn5GOaKPTQlbJEyKb294m WpQQzED9rzxXBi0LbvSjguZOCXfrenPecQ/hKOMC7bIst2UfDBA2AVSpm3nkDLfPI8FJF6vUjDr hrReC9RDTlWVFAk31g+6bI4L940xzmYx6DxF+ydfSG/+sPtZVkG1B4SLmTJ4PKtjImX1B2fiOqq vcT7F2I5RlEVaicFdsaEFjr5u92xy5/omJer0I9tvnlOJ61K3oWJ4VXIXjAExxUkJPe1WBq7W77 TXnsTTvcLXICYhttOAkAdXysfBBfZOvBkpRSmBamG+fak9r3atg/RWw4PQT+myiLZetSf8kue4V h9pZKpn3mXSdV7KK4QiE5bJj38wALbigRnpKlKT4yqD4LKu3A Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LN_PjH9-XqYNHr4TRcKaUkdCvfo Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, 'The IESG' , apps-discuss@ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org Subject: Re: [apps-discuss] Adrian Farrel's No Objection on draft-ietf-appsawg-sieve-duplicate-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 11:47:36 -0000 Hi Ned, Sounds reasonable. My thinking was that it would be fun to make a very tiny mod to a message (possibly too small to be obvious) and cause the recipient to discard it itself. But you're right, the security is an all or nothing thing. Adrian > -----Original Message----- > From: Ned Freed [mailto:ned.freed@mrochek.com] > Sent: 21 June 2014 23:55 > To: Adrian Farrel > Cc: The IESG; appsawg-chairs@tools.ietf.org; draft-ietf-appsawg-sieve- > duplicate@tools.ietf.org; ned+ietf@mrochek.com; apps-discuss@ietf.org > Subject: Re: Adrian Farrel's No Objection on draft-ietf-appsawg-sieve-duplicate- > 07: (with COMMENT) > > > Adrian Farrel has entered the following ballot position for > > draft-ietf-appsawg-sieve-duplicate-07: No Objection > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > A small point that is not at the level of a Discuss, but... > > Are there not some implications on the integrity of the message ID on a > > message that should be stated. Clearly, if a message ID can be touched, > > the message can be made to appear to be a duplicate causing the sieve to > > throw it out. > > If a message-id can be touched, so can the message. What's to prevent someone > from removing the message content, or inserting a known virus, or for > that matter modifying the envelope so the message doesn't even make > it to the user? > > If you have the ability to modify a message in transit, there are a myriad > of things you can do to it that would render it undeliverable, insure > that it gets discarded, etc. Out of all these things, why would you pick > one that not only requires that the recipient be using a particular Sieve > extension in a particular way, but also requires knowledge of more than > one message? > > I'm really not seeing an actual issue here. > > Ned From nobody Sun Jun 22 07:48:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D485F1B2976 for ; Sun, 22 Jun 2014 07:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFwh0Qfn7jsD for ; Sun, 22 Jun 2014 07:48:31 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427EE1B2975 for ; Sun, 22 Jun 2014 07:48:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 33E3F6A59042; Sun, 22 Jun 2014 10:48:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbMpM_WUfq9e; Sun, 22 Jun 2014 10:48:25 -0400 (EDT) Received: from [10.0.1.22] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id F21E86A59025; Sun, 22 Jun 2014 10:48:24 -0400 (EDT) Date: Sun, 22 Jun 2014 10:48:15 -0400 From: Cyrus Daboo To: Eliot Lear , Apps Discuss Message-ID: <065D5F1EA39155C33ADDD3D1@cyrus.local> In-Reply-To: <53A6BA6E.9000404@cisco.com> References: <53A50CD7.9060703@cisco.com> <53A6BA6E.9000404@cisco.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=3391 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/spkpGKTwp0gCslwbs7k4cMtzODs Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jun 2014 14:48:33 -0000 Hi Eliot, --On June 22, 2014 at 1:13:50 PM +0200 Eliot Lear wrote: >> Obviously there is a security implication from this approach: the IANA >> data is signed as a whole (somewhat unofficially by the TZ >> coordinator), but the individual timezone definitions derived from it >> won't be signed by the same. So clients will need some form of >> implicit trust in the top-level providers who do the conversion. But >> that does bring up the question of whether the derived data pieces >> should each be signed so that when they are delivered by secondary >> servers, clients can verify they match what the top-level provider has >> (I think this is what Patrik F=C3=A4ltstr=C3=B6m is suggesting in his = response >> (point 4). >> > > Ok. So scaling this doesn't fall on IANA's head, nor does IANA have to > publish alternate formats, right? If so, THAT should be made crystal > clear in the charter. So should the possibility that this group may ask > for some adjustments to how data is signed by the TZ maintainer, if that > is a possibility. I'd suggest that the tz list be kept abreast of this. How about adding the following text to the charter's "out of scope" = section: - Any changes to the IANA timezone database process or infrastructure, as=20 documented in RFC 6557, other than recommendations for possible security=20 enhancements. >> - The timezone data distribution protocol should also offer an API to >> allow thin clients to easily make use of timezone data by querying for >> UTC offsets, offloading the sometimes complex work of expanding >> recurrence rules to the service. This API should be extensible to >> support other types of timezone operations in the future. > > To be clear, your starting point does not offer an API. It is amenable > to one, perhaps. But that won't really be known until there is one. I > think you really meant "capability" and not "API". Whether this is the > same or different protocols is IMHO an important design question that > should be decided now, and I'm glad you've asserted a proposal. In > looking at draft-douglass-timezone-service it requires a pretty fully > understanding of CalDAV. Is that indeed appropriate for a thin client? No - the current draft has no dependency on CalDAV whatsoever - in fact=20 CalDAV is not mentioned in the draft at all.=20 draft-daboo-caldav-timezone-ref does discuss how to incorporate the=20 timezone distribution service into CalDAV to improve performance and=20 reliability there. As I mentioned in a reply to Patrik F=C3=A4ltstr=C3=B6m, the initial = impetus for=20 this work came from the discovery that several web calendar implementations = had written their own timezone service to provide "thin client" timezone=20 expansion apis. In addition to improving the overal distribution process,=20 providing for such an api should be a key requirement - though as you point = out there is the possibility it could be decoupled from the distribution=20 piece. > To a lesser extent I have concerns about this statement: > >> The timezone data distribution protocol should be "web friendly" to >> allow browser-based calendar clients easy access to the data and API. > > This seems to be a "let's do it in JSON" requirement. IMHO there is > little need for this statement, given the starting point. OK, that point is probably redundant given the one preceding it, and can be = removed. --=20 Cyrus Daboo From nobody Sun Jun 22 22:22:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1ED1B2992 for ; Sun, 22 Jun 2014 22:22:47 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wc6AAd4MFIuM for ; Sun, 22 Jun 2014 22:22:45 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012C41B286A for ; Sun, 22 Jun 2014 22:22:44 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id k14so6072867wgh.18 for ; Sun, 22 Jun 2014 22:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fmWYjYXK3T8PV/EEGlKg/W+7hREkHfRd3CXLMR48a64=; b=tMIXDCbe6B97Uej8gdUFy0AxUYLhcH/gGIK8aqtrm8y0YgHcqyeqIFTJVUYr6hKBls 2XE+56umhZqyamvVAlLWpFSSn7z5ChERfQ8fVyWKXympI/TBoYKN/CgosXkUZOkHQJNw 7ACDPkIkPC6wcnIg5hNhQPvAntNBy8uDm5cn4x8V451vthD+aucll8QjW4CuHEvoi71d OVPOuRs7LEubRKUBRjWVoC5s/rfcWe+bC9uE9W9NJx5NlyVIkyOfrur9dRgAav6+81os hRwfzo4npgrs/oVpyacuUadrpRaOSQknF5ZG9o/ITbX1omW+vyV8DxnTqvl5ckuyEnUX o7og== MIME-Version: 1.0 X-Received: by 10.180.228.39 with SMTP id sf7mr22821084wic.26.1403500963672; Sun, 22 Jun 2014 22:22:43 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Sun, 22 Jun 2014 22:22:43 -0700 (PDT) Date: Sun, 22 Jun 2014 22:22:43 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a1134d18a61ba4704fc7a081b Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gT_uovJzwEVO7VCgk8cmLBPzNOE Subject: [apps-discuss] Draft submission deadline coming up X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 05:22:47 -0000 --001a1134d18a61ba4704fc7a081b Content-Type: text/plain; charset=UTF-8 Just a friendly reminder: If you have any document edits made but not posted, or plan to make some, or have a new one to submit and discuss in Toronto, the cutoff for document submission prior to the Toronto meeting is July 4th. Submit early, submit often. -MSK --001a1134d18a61ba4704fc7a081b Content-Type: text/html; charset=UTF-8
Just a friendly reminder:

If you have any document edits made but not posted, or plan to make some, or have a new one to submit and discuss in Toronto, the cutoff for document submission prior to the Toronto meeting is July 4th.

Submit early, submit often.

-MSK
--001a1134d18a61ba4704fc7a081b-- From nobody Mon Jun 23 07:29:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6023D1B2AF3; Mon, 23 Jun 2014 07:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x_I6ss1SDqo; Mon, 23 Jun 2014 07:29:47 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1811B296B; Mon, 23 Jun 2014 07:29:47 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9075520FB7; Mon, 23 Jun 2014 10:29:43 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 23 Jun 2014 10:29:43 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=6BS2ftl61UrUUbOB832NMy3i2/0=; b=yllr03VKOiJUhpWgfRpePySyxv2m mi2IYopoCC3ArV3Zl9Bma5vD+B2b9Urm7kBoZ0vE2rlmZOJ5+UdQs71rmnw1tyEG XJS+Ly5GIZwqrlUv7GKx4HxI12LGxNdAIfKkcYV7BX5fqUNTDOCkn0pTHiIzVgjR ioJt8oo+MV/ULOQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=6BS2ftl61UrUUbOB832NMy 3i2/0=; b=YoadG215m6j5BY2LLnEIFNHgLfBaYZMH/pmOO/7T/vErK3lqV6gkVK auoKc7nSfKsDGhKKtGouiQg/ed+WqTdcEIaYq3cAMMN05zTgJAG4VCopfmUyuaPl H6I8ELBb5FLfRtRfp9l44FVH6AWdObFhwu9f2pDhiTS3vVON2gfkM= X-Sasl-enc: QytUddSBR6Nfschyc1FkZ2G4q8yzkq4H/E8Fz13X/Sbw 1403533781 Received: from [10.21.146.102] (unknown [128.107.239.234]) by mail.messagingengine.com (Postfix) with ESMTPA id 72905680184; Mon, 23 Jun 2014 10:29:34 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Mon, 23 Jun 2014 15:29:32 +0100 From: Alissa Cooper To: Stephan Bosch , The IESG Message-ID: Thread-Topic: Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> In-Reply-To: <53A3E7EB.1030604@rename-it.nl> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/avZHyTR2E-11pVmUM1htLd2RPYc Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 14:29:50 -0000 Hi Stephan,=20 Thanks for your responses. My responses to some issues are below and the rest are in my other note to Barry. On 6/20/14, 12:51 AM, "Stephan Bosch" wrote: >Hi Alissa, > >On 6/20/2014 2:40 AM, Alissa Cooper wrote: >> Alissa Cooper has entered the following ballot position for >> draft-ietf-appsawg-sieve-duplicate-07: Discuss >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> o Section 3.3:=20 >> "A default expiration time of around 7 days is usually >> appropriate. ... If that limit is exceeded by the ":seconds" >>argument, >> the >> maximum value MUST silently be substituted" >> >> The suggested default seems really long, especially for the example use >> case described in Section 1. On the other hand, it seems odd that the >> user's choice would be overriden by the preset maximum. This would make >> more sense to me if the default expiration were shorter and the user >> could override it with a longer :seconds argument if he wanted. What is >> the rationale for doing it the opposite way? > >The default was chosen in Sieve mailing list discussions, but in essence >it is pretty arbitrary. It is mainly based on the period in which a >series of duplicate messages may arrive with a margin of a few more days. I find it a bit surprising that receipt of a duplicate multiple days after the first message is received is that commonplace on today=E2=80=99s Internet. Is there any data around to back that up? > >The rationale for a maximum is to prevent users from having the ability >to create duplicate tracking list entries that linger indefinitely. Well, =E2=80=9Cindefinitely=E2=80=9D wouldn=E2=80=99t necessarily be possible, because if the= user specifies nothing then it=E2=80=99s the default, and otherwise he could be required to specify _something_, correct? But I can appreciate that you don=E2=80=99t want to impose a long, arbitrary retention requirement. Is the idea that the maximum would be surfaced to the user if he=E2=80=99s using some GUI to create a duplicate filter? It just seems odd that the user=E2=80=99s choice would be silently overridden and he wouldn=E2=80=99t know until duplicate messages star= t showing up sooner than expected. Alissa > >> o Section 6:=20 >> It seems like this section is missing a discussion of the privacy >> considerations associated with enabling the duplicate test. In the case >> where the Sieve filter is implemented server side, making use of the >> duplicate test means that some record of the receipt of a particular >> message will be persisted (for as long as specified by the logic in >> Section 3.3) even if the user downloads his messages or deletes a >> received message on the server that matches a test string in the >> meantime. If I want to filter all messages with duplicate message IDs, >> for example, this puts a >> requirement on the server to maintain a list of the message IDs of all >> messages I=E2=80=99ve received (for the amount of time specified by the timing >> parameters). So if a third party wanted to find out that list, it could >> go to the operator >> of the server and ask for it. This introduces a privacy risk that is not >> discussed in the document and is exacerbated by the long default >> expiration time mentioned above. Tests that make use of the :header or >> :uniqueid arguments are also potentially problematic since the list of >> strings to match is kept on the server. It seems like these aspects >> should at least be noted in the document for implementers to consider. >> >> o Section 6:=20 >> Sieve scripts that include duplicate tests contain potentially sensitive >> information (e.g., subject or body strings). So it seems like the >>scripts >> should be confidentiality protected in transit. I checked with Barry and >> he said that there is no RFC that specifies if/when scripts should be >> protected in transit, and I understand that this document is probably >>not >> the right place to specify required behavior there, but I'd like to >> discuss (more with the ADs than the authors) if there is some plan for >> specifying that behavior somewhere. >> >> o Section 6:=20 >> I think it would make sense to require that the tracked message list be >> stored with an equivalent level of protection as the user's messages >> themselves. E.g., if message headers and bodies are stored encrypted, >> then the duplicate tracking list should be as well. And the duplicate >> tracking list should be subject to the same access controls as the >> mailbox (perhaps this is obvious but I'm not sure). > >This is a very interesting point of view. I had not thought of privacy >concerns relating to the duplicate tracking list. > >Probably, the main reason we have not considered this is that the >document states the following: > > NOTE: The necessary mechanism to track duplicate messages is very > similar to the mechanism that is needed for tracking duplicate > responses for the "vacation" [VACATION >TION>] action. One way to implement > the necessary mechanism for the "duplicate" test is therefore to > store a hash of the tracked unique ID and, if provided, the ":handle" > argument. > >There is no tractable way to reverse a hash into its original string >value, meaning that the entries in the duplicate tracking list would >have very little value for an attacker. > >Of course, if implementations choose a different approach that uses >entries that can yield the original string values, there would be a real >concern. I propose adding a sentence or two pointing out that duplicate >tracking list entries should not contain the plain user strings for >privacy reasons, or, alternatively, that the tracked message list be >stored with an equivalent level of protection as the user's messages >themselves. > >The same considerations apply to the vacation extension (RFC 5230). > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> o Section 3.1: >> "When the ":uniqueid" argument is used, such normalization >> concerns are the responsibility of the user." >> >> I don't quite get this. Do we expect users to, e.g., specify that >> uniqueid strings should only be compared after conversion to UTF-8? That >> would seem to rely on a level of technical sophistication that almost no >> users actually have. > >I am not sure what exactly you mean here. The normalization concerns >listed before that sentence all apply to header field content, something >the author of a sieve script cannot control directly. With ":uniqueid" >the script author is directly responsible for the composition of the >unique ID value. As long as the encoding is chosen consistently, the >encoding does not matter for successfully matching it to past values in >the duplicate tracking list. It can also be some sort of binary value if >appropriate; whatever the application demands. The quoted sentence >mainly points to the fact that for some applications it can be useful to >have such normalization for ":uniqueid" as well, e.g. to trim leading >and trailing white space. However, the script author will have to >implement this explicitly, since the duplicate test will not do this >implicitly. > >> o Section 3.2: >> "This means that it does not matter whether values are >> obtained from the message ID header, from an arbitrary header >> specified using the ":header" argument or explicitly from the >> ":uniqueid" argument. >> >> I had trouble understanding what "it does not matter" meant in this >> sentence. I would suggest: >> >> "This means that the values in the duplicate list should be used for >> duplicate testing regardless of whether they were >> obtained from the message ID header, from an arbitrary header >> specified using the ":header" argument or explicitly from the >> ":uniqueid" argument." > >Ok, works for me. > >Regards, > >Stephan. From nobody Mon Jun 23 07:30:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44AE1B2B00; Mon, 23 Jun 2014 07:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMt5V_GOqza6; Mon, 23 Jun 2014 07:30:05 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619CD1B2AF0; Mon, 23 Jun 2014 07:30:05 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 23E2220FFA; Mon, 23 Jun 2014 10:29:52 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 23 Jun 2014 10:29:53 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=DjGeDnciWU84uewgwigzlpN6G/M=; b=zBQ39fjvAZ2TU8GKS3l5Syb+rm8G d4cDSo8KMHW9pwSc/OEMivIqqPQbH4zpWb1chP6nBWuwx436D5TUIBhMJy+/7BSf BK4WK/7w+fL4C7e1qoygRmqqoT7x7u1RlbBqtHZjsGlYGu6x1WY8J9ikyzEpckhu drR8GijK1Bo2UfY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=DjGeDnciWU84uewgwigzlp N6G/M=; b=Bwsc1i99XRWxYLTYlFBFyL/4Q7H9leth3EN29MQ/jJZdU3rZDAGkc9 9XUYBoBLDWZJpFVW9tFAlVG7BRU3N3eoY8vtK9VnAacKnw9Bbt3iZrrhh4OubVdC X5F00omyEcT5d62CCEvlAbr/y9Zj5EieA6bzgdp/wzuMImUC/dzyI= X-Sasl-enc: ZhLze/WnKwmfNMRkvIv5vBL3o4kfEMnNlmHka9UxvsgF 1403533791 Received: from [10.21.146.102] (unknown [128.107.239.234]) by mail.messagingengine.com (Postfix) with ESMTPA id 44BD6680184; Mon, 23 Jun 2014 10:29:44 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Mon, 23 Jun 2014 15:29:39 +0100 From: Alissa Cooper To: Barry Leiba , Stephan Bosch Message-ID: Thread-Topic: Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_3p01XfT7jAqgKtZ9TPgEK2Q8SY Cc: "appsawg-chairs@tools.ietf.org" , "ned+ietf@mrochek.com" , The IESG , Apps Discuss , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 14:30:11 -0000 Hi Barry, Thanks, comments inline. On 6/20/14, 7:57 AM, "Barry Leiba" wrote: >> This is a very interesting point of view. I had not thought of privacy >> concerns relating to the duplicate tracking list. >> >> Probably, the main reason we have not considered this is that the >> document states the following: >> >> NOTE: The necessary mechanism to track duplicate messages is very >> similar to the mechanism that is needed for tracking duplicate >> responses for the "vacation" [VACATION >>>ATION>] action. One way to implement >> the necessary mechanism for the "duplicate" test is therefore to >> store a hash of the tracked unique ID and, if provided, the ":handle" >> argument. >> >> There is no tractable way to reverse a hash into its original string >> value, meaning that the entries in the duplicate tracking list would >> have very little value for an attacker. >> >> Of course, if implementations choose a different approach that uses >> entries that can yield the original string values, there would be a real >> concern. I propose adding a sentence or two pointing out that duplicate >> tracking list entries should not contain the plain user strings for >> privacy reasons, or, alternatively, that the tracked message list be >> stored with an equivalent level of protection as the user's messages >> themselves. >> >> The same considerations apply to the vacation extension (RFC 5230). > >I think a good way to resolve this would be to put something like what >you propose (a sentence or two) into the Security Considerations, to >add that note that this applies to Vacation as well, and to have this >document "update" 5230. Specifically: > >1. Add two paragraphs to Section 6: > >The list of unique IDs used for duplicate tracking can include >privacy-sensitive information, such as Message-ID values, content of >subject lines, and content extracted from message bodies. It is >important to protect that information, either by obscuring it through >hashing (see the note at the end of Section 3.2) or by storing it with >a level of access control equivalent to that of the messages >themselves. I think the last sentence above should be at least a SHOULD. Otherwise the above text is good. But, there is another privacy aspect that is not addressed by the text above and deserves some mention. Suppose I am a law enforcement official or a private investigator in a divorce lawsuit or some such, and I get a hold of a list of message IDs from Email Provider X or passive traffic analysis or wherever. If I go to Email Provider Y and ask whether Jane Doe has received mail containing any of those IDs, the fact that Email Provider Y hashed the IDs doesn=E2=80=99t prevent it from producing that information. Meanwhile, if Jane downloaded or deleted any of those messages, she might think that he email provider no longer has a record of them, but that=E2=80=99s not the case. There aren=E2=80=99t too many good ways to close this expectation gap. For the case where, say, Jane is an IMAP user and she deletes a message, could that trigger removal of the ID from the duplicate tracking list? I don=E2=80=99t know much about Sieve but from the explanation I got from Barry that didn=E2=80=99t sound likely. The other option is to try to inform the user about the retention implications of setting up a duplicate filter. I know that we don=E2=80=99t want to wade into UI considerations, but at the very least I think highlighting this issue and the potential UI implications for implementers is important. > >The same considerations apply to the Vacation extension [VACATION], >and this updates the Security Considerations of that document (RFC >5230, Section 8) accordingly. Would be nice to fix this but I agree with Pete that doing it from this document seems odd. Let=E2=80=99s see what text we settle on and maybe we can think about an errata? Or is it too much for an errata if it ends up having normative language in it? > >2. Add a paragraph to Section 1: > >The Security Considerations section of this document (see Section 6) >updates the Security Considerations for RFC 5230 [VACATION]. > >3. Add "Updates: 5230" to the document header. > >The update to 5230 is optional, but I think it's easy and useful. > >>> "When the ":uniqueid" argument is used, such normalization >>> concerns are the responsibility of the user." >>> >>> I don't quite get this. Do we expect users to, e.g., specify that >>> uniqueid strings should only be compared after conversion to UTF-8? >>>That >>> would seem to rely on a level of technical sophistication that almost >>>no >>> users actually have. >> >> I am not sure what exactly you mean here. The normalization concerns >> listed before that sentence all apply to header field content, something >> the author of a sieve script cannot control directly. With ":uniqueid" >> the script author is directly responsible for the composition of the >> unique ID value. [etc...] > >The problem here, really, is "the user", I think. > >What you really want to say, and something I don't think would make >Alissa blink, is this: > >NEW >When the ":uniqueid" argument is used, any normalization >needs to be done in the Sieve script itself, as the unique ID >is created. >END Yes, this solves my issue. > >Barry From nobody Mon Jun 23 07:47:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76911B2961; Mon, 23 Jun 2014 07:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpdWSvgLqKUC; Mon, 23 Jun 2014 07:47:33 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C871A0387; Mon, 23 Jun 2014 07:47:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 250E86A73254; Mon, 23 Jun 2014 10:47:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9a0QLZrp-OoG; Mon, 23 Jun 2014 10:47:31 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id AC5066A73249; Mon, 23 Jun 2014 10:47:27 -0400 (EDT) Date: Mon, 23 Jun 2014 10:47:23 -0400 From: Cyrus Daboo To: Alissa Cooper , Barry Leiba , Stephan Bosch Message-ID: In-Reply-To: References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=1747 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ld38JyN0eLamwBMMMUHzt3yEeDo Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, The IESG , Apps Discuss , draft-ietf-appsawg-sieve-duplicate@tools.ietf.org Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 14:47:42 -0000 Hi Alissa, --On June 23, 2014 at 3:29:39 PM +0100 Alissa Cooper =20 wrote: >> 1. Add two paragraphs to Section 6: >> >> The list of unique IDs used for duplicate tracking can include >> privacy-sensitive information, such as Message-ID values, content of >> subject lines, and content extracted from message bodies. It is >> important to protect that information, either by obscuring it through >> hashing (see the note at the end of Section 3.2) or by storing it with >> a level of access control equivalent to that of the messages >> themselves. > > I think the last sentence above should be at least a SHOULD. Otherwise = the > above text is good. > > But, there is another privacy aspect that is not addressed by the text > above and deserves some mention. Suppose I am a law enforcement official > or a private investigator in a divorce lawsuit or some such, and I get a > hold of a list of message IDs from Email Provider X or passive traffic > analysis or wherever. If I go to Email Provider Y and ask whether Jane = Doe > has received mail containing any of those IDs, the fact that Email > Provider Y hashed the IDs doesn=E2=80=99t prevent it from producing that > information. Meanwhile, if Jane downloaded or deleted any of those > messages, she might think that he email provider no longer has a record = of > them, but that=E2=80=99s not the case. > But I think this goes back to what Ned was saying. If an attacker got hold=20 of the message-ids then in all likelihood they also have the other headers=20 in the message including the recipient email address - which would be=20 enough to "prove" delivery - in spite of the fact that Jane might think=20 that deleting a message is tantamount to removing any record of it. --=20 Cyrus Daboo From nobody Mon Jun 23 09:17:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E7D1B2B73 for ; Mon, 23 Jun 2014 09:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J29-p3O2xR_m for ; Mon, 23 Jun 2014 09:17:17 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2D11B2BF2 for ; Mon, 23 Jun 2014 09:07:50 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 1924EFA00F1; Mon, 23 Jun 2014 16:07:48 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1403539667-5295-5294/12/15; Mon, 23 Jun 2014 16:07:47 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Mon, 23 Jun 2014 18:07:46 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: <515c5a5d-8ff3-4f2c-a6a0-9f1842663e6c@gulbrandsen.priv.no> In-Reply-To: References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ytsbtgq9xdcwaIGAicJuTlKoSPE Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 16:17:19 -0000 On Monday, June 23, 2014 4:29:32 PM CEST, Alissa Cooper wrote: > I find it a bit surprising that receipt of a duplicate multiple days = after > the first message is received is that commonplace on today=E2=80=99s = Internet. Is > there any data around to back that up? If you exclude mail involving moderated mailing lists, then it's not = common=20 at all. But with human moderators involved, duplicates arriving on the = next=20 working day is common enough to be worth supporting. Arnt From nobody Mon Jun 23 12:48:12 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475D61B2C0F; Mon, 23 Jun 2014 12:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTci0Aj3Kz_6; Mon, 23 Jun 2014 12:48:02 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F98B1B29DA; Mon, 23 Jun 2014 12:47:57 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:51993 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WzADI-0000wR-4O; Mon, 23 Jun 2014 21:47:42 +0200 Message-ID: <53A88421.60701@rename-it.nl> Date: Mon, 23 Jun 2014 21:46:41 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kathleen Moriarty , The IESG References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> In-Reply-To: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/X62Ig-M4uJTf72XtJ6L6dbw_3eM Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 19:48:04 -0000 Hi Kathleen, On 6/23/2014 8:49 PM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-appsawg-sieve-duplicate-07: Discuss > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > The security considerations seem light, shouldn't there be a security > consideration for the possibility of overwriting a message with another? > If an attacker wants to prevent someone from receiving a certain version > of a message, couldn't this be used to achieve that goal? I don't see > anything to prevent this, with the exception of good security practices, > trusted administrators, and monitoring for any tampering on sending > servers. I'm not looking for too much of a description, but a statement > on this possible risk. Replacing a targeted message with a falsification needs to occur before the targeted message arrives at the Sieve interpreter, otherwise it is already delivered. For the default use of the "duplicate" extension, that requires predicting the Message-ID and ensuring that the attacker's message arrives before the targeted message. Furthermore, it requires knowledge of the Sieve script at the receiving end, especially if ":header" or ":uniqueid" are used. This risk seems minimal to me. Therefore, I am not sure whether I understand the mechanism of the attack you describe. Could you elaborate? Regards, Stephan. From nobody Mon Jun 23 14:36:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400161B2D01; Mon, 23 Jun 2014 14:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDwduVPUFqo8; Mon, 23 Jun 2014 14:36:24 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4A41B2CEC; Mon, 23 Jun 2014 14:36:23 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id c11so5249433lbj.41 for ; Mon, 23 Jun 2014 14:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LgrDrmjye1mf/tYOYJSRtpN8nQXDZm3kAZdg2brLGIc=; b=NTvj7O7Z76hRTzlHzkzjrwXW3seyRsKJ1Cstp6Ry7y9Y5eDKnbADYvhW/kCJk+P5vP AFh+zpj9Gz/k06GnD/c3+KivUrQ2k4i/8FAQ0pWXicwHXfKUI5AYZ19kvPkjWZFr5vQ/ srQbFzuETPtFXiJWxAWNodTjCCInZkCRY37lM5xi8u/FwYXGOf7GESo32xA2bnsOjxao OvrNeYzsmigIZnNJnk3kZarbWvj/v/khoi1lCmdfpX5MM9sRIrGn/JQq9aNTLJ+pODic 8WT64nOp6BxMkTYrWUHYhiwmyEwvEZjJKKmYRAyTzVRn0DGH979KejWt/6F2dDM/5RI/ 2ljA== MIME-Version: 1.0 X-Received: by 10.112.150.65 with SMTP id ug1mr18033124lbb.46.1403559382134; Mon, 23 Jun 2014 14:36:22 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Mon, 23 Jun 2014 14:36:22 -0700 (PDT) In-Reply-To: References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> Date: Mon, 23 Jun 2014 17:36:22 -0400 X-Google-Sender-Auth: C2ISvaZl7jLO4u0L4z_aI16N3VI Message-ID: From: Barry Leiba To: Kathleen Moriarty Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vh6wGfyrFC-QDQepS3b8BBSA76U Cc: Apps Discuss , Stephan Bosch , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 21:36:25 -0000 >> This risk seems minimal to me. Therefore, I am not sure whether I >> understand the mechanism of the attack you describe. Could you elaborate? > > Does the above help? Not to me. Let me see if I can tease out the threat you're suggesting by asking a few questions. 1. I presume the point here is for an attacker to prevent you from getting a particular message. Secondarily, the attacker will be sending you a message, but anyone can do that anyway, so I don't see the issue there. First question: Is this correct, that the attack involves blocking a particular message (having it discarded by your delivery agent). 2. The attacker would need to know that your script is using this feature, so let's presume for now that this feature is very widely adopted. The normal mode of use would be "if duplicate then discard", so the unique ID would be the Message-ID field. Does this assumption match the threat you imagine? 3. How is the attacker going to determine the Message-ID of a message that you will get, but that you haven't gotten yet, and that the attacker wants to block? Message-ID values are not predictable. 4. Assuming the attacker can figure out a Message-ID to attack, how is the attacker going to get her message delivered before the one she wants to block? That's the only way to have the blocked message be discarded by this feature. 5. Given that an attacker would have to come up with a Message-ID to use for the attack, and then get her message delivered first so that the legitimate message is the one that's considered the discardable duplicate, do you really think this is real threat? Barry From nobody Mon Jun 23 15:02:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1361B2D07; Mon, 23 Jun 2014 15:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0Y9r_hzD6pL; Mon, 23 Jun 2014 15:02:17 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397221B2C7A; Mon, 23 Jun 2014 15:02:17 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jz11so6673260veb.16 for ; Mon, 23 Jun 2014 15:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=e9eha2j8skAPo/nnXUIUmrWIGscHuw0dt2IHH720yU8=; b=xodPYDkond5CiuHSWSp7zcxtOxG1oIGEaFqWvhdFbBsS9nMYFYnGByJm9BPkhbd/p1 dNeYHQODUT3KcAbXwFjn3Q9aJbwCUEcbmBEwmEr+qyQGN6Dm6eKnTvSSWxXCX6sGyxpK Rqe78PG6sakQ40ok7osGPKrhuEAOmTS8DtraRxaNPAtcmuGg150BEodIgU7jORDSSlbm Q4ogQ+zIXHbiuq0PZzcXe+7IM/m8eMRqgKkQeNlGH1edxYo36M7eKeXMVE5DSktIp7Zt wR5egtPw9CkbeFTQK1FsPHKaLyDbZCNL3O0kspA6YedmuWR//Er6ljDzhkkYftuVAdZM 6bfA== MIME-Version: 1.0 X-Received: by 10.221.27.8 with SMTP id ro8mr9096822vcb.30.1403560936350; Mon, 23 Jun 2014 15:02:16 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.106.73 with HTTP; Mon, 23 Jun 2014 15:02:16 -0700 (PDT) In-Reply-To: References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> Date: Mon, 23 Jun 2014 18:02:16 -0400 X-Google-Sender-Auth: 5nodBn7d5C7g8wnlEf6yOwcwZRU Message-ID: From: Barry Leiba To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/04gIAO6wiC6IfijhleemgWkCxnM Cc: Apps Discuss , Stephan Bosch , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 22:02:19 -0000 >>The list of unique IDs used for duplicate tracking can include >>privacy-sensitive information, such as Message-ID values, content of >>subject lines, and content extracted from message bodies. It is >>important to protect that information, either by obscuring it through >>hashing (see the note at the end of Section 3.2) or by storing it with >>a level of access control equivalent to that of the messages >>themselves. > > I think the last sentence above should be at least a SHOULD. Otherwise th= e > above text is good. I don't really care about 2119 language in that, and I certainly have no problem with sticking in a SHOULD. > But, there is another privacy aspect that is not addressed by the text > above and deserves some mention. Suppose I am a law enforcement official > or a private investigator in a divorce lawsuit or some such, and I get a > hold of a list of message IDs from Email Provider X or passive traffic > analysis or wherever. If I go to Email Provider Y and ask whether Jane Do= e > has received mail containing any of those IDs, the fact that Email > Provider Y hashed the IDs doesn=E2=80=99t prevent it from producing that > information. Meanwhile, if Jane downloaded or deleted any of those > messages, she might think that he email provider no longer has a record o= f > them, but that=E2=80=99s not the case. Hm. If the hashes are salted, it wouldn't be possible to just compare Message-IDs. It's probably worth suggesting salting the hashes (with something unique to each user, such as the username). On the other hand, if someone had a raw Message-ID and a court order that said, "Salt and hash this Message-ID and see if it's in Jane Doe's duplicate list," then, yes, that would work. And, yes, deleting messages won't remove them from the duplicate list -- we wouldn't want it to, because we'd still want a duplicate that arrived after the deletion to still be considered a duplicate. Only aging out will remove an entry. It's certainly easy to add a paragraph about this angle. Stephan, you want to craft something? I don't think there's any remedy you can put in, but just calling out the issue is worth a few words. It's notable, though, that server logs will often have this information anyway, and probably would expose plaintext Message-IDs for a much longer period than this will. I think this would really only be an issue with an email server that intentionally burns its logs with the intent of limiting traceability, and that needs to be made aware that this re-exposes things (including a close estimate of the timestamp when the message was delivered, by looking at the aging-out time on the list entry). >>The same considerations apply to the Vacation extension [VACATION], >>and this updates the Security Considerations of that document (RFC >>5230, Section 8) accordingly. > > Would be nice to fix this but I agree with Pete that doing it from this > document seems odd. Let=E2=80=99s see what text we settle on and maybe we= can > think about an errata? Or is it too much for an errata if it ends up > having normative language in it? Normative or not, it's not errata. And it's probably not worth rev-ing the document just for this, either. Barry From nobody Mon Jun 23 15:18:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22CE1B2D27; Mon, 23 Jun 2014 15:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.548 X-Spam-Level: * X-Spam-Status: No, score=1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_IS_IT_OUR_ACCOUNT=4.2, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvPjVXwfgWE4; Mon, 23 Jun 2014 15:18:47 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC17A1B2D36; Mon, 23 Jun 2014 15:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1403561926; x=1435097926; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7ZGzRu+NBeL8mBUzwcrgw7q6kOa0NlwLS8yO9Lx3Y34=; b=nkQL8DO5MeeGfbeGZWODzPm9IJX+Swx2ryUQT0b0H2+ijkv2F8DWjpUS WePcPOlmA+6ERsCP5HQefbL0/CxE98r/+3QJc1REacW/0slhWUnfM+1Ul X+XKtRuAK5tPu98O3I9AD0fRwPvYdJXe8Qcq1lj3z4oWZV+DKv+Y0FZzY w=; X-IronPort-AV: E=McAfee;i="5600,1067,7478"; a="67295438" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 23 Jun 2014 15:18:46 -0700 X-IronPort-AV: E=Sophos;i="5.01,533,1400050800"; d="scan'208";a="700581779" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Jun 2014 15:18:45 -0700 Received: from presnick-mac.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 23 Jun 2014 15:18:45 -0700 Message-ID: <53A8A7C5.80102@qti.qualcomm.com> Date: Mon, 23 Jun 2014 15:18:45 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ep-i60RV0Yl0P3-_xs_zoTDZLdU Cc: Apps Discuss , Stephan Bosch , "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , Kathleen Moriarty , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 22:18:50 -0000 On 6/23/14 2:36 PM, Barry Leiba wrote: > 3. How is the attacker going to determine the Message-ID of a message > that you will get, but that you haven't gotten yet, and that the > attacker wants to block? Message-ID values are not predictable. > Well, that's not entirely true. Most Message-IDs are generated using some algorithm that could conceivably be known and re-created: It is certainly true that most Message-IDs use the current date and time as part of the left-hand-side, along with other information, in a well-known order. So: > 4. Assuming the attacker can figure out a Message-ID to attack, how is > the attacker going to get her message delivered before the one she > wants to block? That's the only way to have the blocked message be > discarded by this feature. > Imagine that I want you not to get a piece of mail that is sent out at the end of the month telling you some important piece of information (like the number of failed log-in attempts to your account, or the number of traffic tickets issued for a particular truck you own). I know that the service sending this mail always sends on the first of the month at midnight exactly, and I know the algorithm that they use to generate Message-IDs, **and it doesn't include some randomly generated gobbledygook as part of it.** If I send you a message just prior to when you're supposed to get your important message with the Message-ID I was able to predict and recreate, I can get you to discard the message. Now, the big question is: Do people algorithmically generate Message-IDs without random gobbledygook? I don't really know the answer to that. But given that 5322 doesn't require a particular algorithm that includes random data, it's certainly possible that this could be used for ill. > 5. Given that an attacker would have to come up with a Message-ID to > use for the attack, and then get her message delivered first so that > the legitimate message is the one that's considered the discardable > duplicate, do you really think this is real threat? > I'm not sure. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Jun 23 15:29:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151411A038B; Mon, 23 Jun 2014 15:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.322 X-Spam-Level: **** X-Spam-Status: No, score=4.322 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FM_IS_IT_OUR_ACCOUNT=4.2, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EChbSc5FpfPe; Mon, 23 Jun 2014 15:29:50 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992F61A0331; Mon, 23 Jun 2014 15:29:49 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id w7so5456725lbi.35 for ; Mon, 23 Jun 2014 15:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mDqGzsBnSZoX2TkkXIS2L6Nh6van5b0gruMQE9hfSVc=; b=nIoi9npjo1+0tkFOtJKnNt6zOIoTsIHIOhy7tfhQFo/7eEwhkw9HAA9qT9c58hFHQk 7wCTD4q/RzAcEM2Q+IdKtsAj6Pm0mkhvYvJLCnP6R7eL5zKNAkBIK1zE9UJD1emV5Gcl TUhTUsrrtFItbZT3KjVEg+oPZIjmKlyvZIXRBj0pm6aY7cEsZ0aqcRBrsTNjiEwANhs2 o68G15gMCkiVaLT490RILlScHnVANo4SkI0do3xi/uZA1dEzs9+Y/Og+zZ9NLG13fbkH zQ/vb0cKOfx8MkgPlGYMm7OqLe5KD4EpGgwL4FXgPr8aL1ZOwPREeOPzj+n1tPboMg2j 1j6g== MIME-Version: 1.0 X-Received: by 10.112.169.68 with SMTP id ac4mr17080049lbc.43.1403562587861; Mon, 23 Jun 2014 15:29:47 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Mon, 23 Jun 2014 15:29:47 -0700 (PDT) In-Reply-To: <53A8A7C5.80102@qti.qualcomm.com> References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> Date: Mon, 23 Jun 2014 18:29:47 -0400 X-Google-Sender-Auth: BlomD0fdVRil3Sl__KTBHKhQU80 Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gwmgHWncWKTlMusGjqD_esjOt2U Cc: Apps Discuss , Stephan Bosch , "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , Kathleen Moriarty , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 22:29:51 -0000 > Imagine that I want you not to get a piece of mail that is sent out at the > end of the month telling you some important piece of information (like the > number of failed log-in attempts to your account, or the number of traffic > tickets issued for a particular truck you own). I know that the service > sending this mail always sends on the first of the month at midnight > exactly, and I know the algorithm that they use to generate Message-IDs, > **and it doesn't include some randomly generated gobbledygook as part of > it.** If I send you a message just prior to when you're supposed to get your > important message with the Message-ID I was able to predict and recreate, I > can get you to discard the message. Oh, please: this is a movie-plot threat most bizarre. It requires a specific situation, a specific implementation, and so much advance knowledge that you might as well put on a tinfoil hat. I honestly can't countenance putting advice about these flights of imagination into all of our RFCs. Really, Pete? Barry From nobody Mon Jun 23 15:31:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AE81A038B; Mon, 23 Jun 2014 15:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.821 X-Spam-Level: **** X-Spam-Status: No, score=4.821 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FM_IS_IT_OUR_ACCOUNT=4.2, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKe3yvkHJREH; Mon, 23 Jun 2014 15:31:28 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB4B1A0331; Mon, 23 Jun 2014 15:31:27 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id w7so5355792lbi.21 for ; Mon, 23 Jun 2014 15:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0yn73o7jp1R9InDpETEMI5bVIMN1OhhcNKm0tAZSHog=; b=IMQ7KlNkbSYgpIw9Ftz5ZbCeaCSypyGU9jszz6YTBrJpBajzNIw0/6NDSU2HE7ZY6z 6hdVsNVEMcd3ocYG6lnELRWgsFzRq2a6mlU0gAUgcYv5RIfbyVoJbu2XfZV2mNgPoNeY 9gVQc975VZ76EVl/2bp0xOzZFt0Y3k2CMvZtHBUTmsJEvFsJaEaxMQJx8uZlWykuB7gY IQvTlMmjaCp3mJ2RoTj27cZL3vQArNcJtuKokkhbHy4EBnF2/S8lUwaMVH76t50ywBDQ /Eg16M8ZJExvwT0BwdY9TpVgNZrkyC17qlTgTmkPNt5Z0PZrdtP4X5QDWctxIsAIWD0E UVLw== MIME-Version: 1.0 X-Received: by 10.152.42.138 with SMTP id o10mr6386742lal.36.1403562686101; Mon, 23 Jun 2014 15:31:26 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Mon, 23 Jun 2014 15:31:26 -0700 (PDT) In-Reply-To: References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> Date: Mon, 23 Jun 2014 18:31:26 -0400 X-Google-Sender-Auth: JjKRF0zOVQPg_COT-b6XlpDKajY Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/c6UzyAp16Jbr5yl1e7c8hZAMjTY Cc: Apps Discuss , Stephan Bosch , "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , Kathleen Moriarty , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 22:31:29 -0000 On re-reading this, I think my response comes off as rude, when I didn't intend that. I did mean to dismiss your suggestion as silly, but I did not mean to dismiss it rudely. Sorry. Barry On Mon, Jun 23, 2014 at 6:29 PM, Barry Leiba wrote: >> Imagine that I want you not to get a piece of mail that is sent out at the >> end of the month telling you some important piece of information (like the >> number of failed log-in attempts to your account, or the number of traffic >> tickets issued for a particular truck you own). I know that the service >> sending this mail always sends on the first of the month at midnight >> exactly, and I know the algorithm that they use to generate Message-IDs, >> **and it doesn't include some randomly generated gobbledygook as part of >> it.** If I send you a message just prior to when you're supposed to get your >> important message with the Message-ID I was able to predict and recreate, I >> can get you to discard the message. > > Oh, please: this is a movie-plot threat most bizarre. It requires a > specific situation, a specific implementation, and so much advance > knowledge that you might as well put on a tinfoil hat. > > I honestly can't countenance putting advice about these flights of > imagination into all of our RFCs. Really, Pete? > > Barry From nobody Mon Jun 23 15:44:47 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4791B2D27; Mon, 23 Jun 2014 15:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.147 X-Spam-Level: * X-Spam-Status: No, score=1.147 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_IS_IT_OUR_ACCOUNT=4.2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6s8NWr_8G0M; Mon, 23 Jun 2014 15:44:35 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C271A03B1; Mon, 23 Jun 2014 15:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1403563475; x=1435099475; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6cAz9aO65ywG9JIPdP5NrexJFY1fjw+rvgww44ZbRm8=; b=NOtP25V62zRUGWfxcs/O3tGS70OrESB4jEeFNv3JtMyFXdJl5xWdk2J9 Ql81+iMjZLJGyDrZqSLEOEpM++SXMp/i4HsLrHQww04yHyQidXf3wmHmR VJFN7rOlteSe92nJrxFkqXb/+nWYfWeUK4zUpnpYze2Q7DA9Uwte361tM 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7478"; a="44941138" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 23 Jun 2014 15:44:34 -0700 X-IronPort-AV: E=Sophos;i="5.01,533,1400050800"; d="scan'208";a="754789403" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Jun 2014 15:44:34 -0700 Received: from presnick-mac.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 23 Jun 2014 15:44:34 -0700 Message-ID: <53A8ADD3.70504@qti.qualcomm.com> Date: Mon, 23 Jun 2014 15:44:35 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/F2b6r-XchcnYM72iA_2f5NmrGzk Cc: Apps Discuss , Stephan Bosch , Kathleen Moriarty , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 22:44:36 -0000 On 6/23/14 3:31 PM, Barry Leiba wrote: > On re-reading this, I think my response comes off as rude, when I > didn't intend that. I did mean to dismiss your suggestion as silly, > but I did not mean to dismiss it rudely. Sorry. > No offense taken. I took it as good-natured poking fun. On the actual point: > On Mon, Jun 23, 2014 at 6:29 PM, Barry Leiba wrote: > >>> Imagine that I want you not to get a piece of mail that is sent out at the >>> end of the month telling you some important piece of information (like the >>> number of failed log-in attempts to your account, or the number of traffic >>> tickets issued for a particular truck you own). I know that the service >>> sending this mail always sends on the first of the month at midnight >>> exactly, and I know the algorithm that they use to generate Message-IDs, >>> **and it doesn't include some randomly generated gobbledygook as part of >>> it.** If I send you a message just prior to when you're supposed to get your >>> important message with the Message-ID I was able to predict and recreate, I >>> can get you to discard the message. >>> >> Oh, please: this is a movie-plot threat most bizarre. It requires a >> specific situation, a specific implementation, and so much advance >> knowledge that you might as well put on a tinfoil hat. >> >> I honestly can't countenance putting advice about these flights of >> imagination into all of our RFCs. Really, Pete? First, I only write these movie scripts; I ain't no critic. ;-) More seriously, I don't think this is a big wide gaping security hole. But this is a relatively novel use of Message-ID, and there may be folks who use crappy Message-IDs who haven't thought of the possibility of someone discarding a message that has an identical Message-ID. This is more an operational problem than a security one, and still likely not a big one. But it's worth the thought. For me, this feature is likely to cut down on spam, as certain spammers have the (convenient) habit of reusing the same Message-ID. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Jun 23 16:03:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D227A1A03B4; Mon, 23 Jun 2014 16:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxE2Zmcrsbtj; Mon, 23 Jun 2014 16:03:44 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF4A1B2D2D; Mon, 23 Jun 2014 16:03:43 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s5NN3b4F001151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Jun 2014 16:03:40 -0700 Message-ID: <53A8B201.9050602@dcrocker.net> Date: Mon, 23 Jun 2014 16:02:25 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Barry Leiba , Pete Resnick References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 23 Jun 2014 16:03:41 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Jsa8nWPa94q3KAGUL1MthWzyx78 Cc: Apps Discuss , Stephan Bosch , Kathleen Moriarty , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 23 Jun 2014 23:03:47 -0000 > On re-reading this, I think my response comes off as rude, when I > didn't intend that. I did mean to dismiss your suggestion as silly, > but I did not mean to dismiss it rudely. We should consider memorializing this bit of text as a universal IETF classic squib. Our version of an apology for all seasons... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 23 16:25:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52F11A02B0 for ; Mon, 23 Jun 2014 16:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPZEZeL60SFT for ; Mon, 23 Jun 2014 16:25:15 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90DC41A026A for ; Mon, 23 Jun 2014 16:25:15 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id md12so6431374pbc.17 for ; Mon, 23 Jun 2014 16:25:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j1cBqpT7cYKQ2hJI5PZ9iVyzjJgkDy1xLssKDmyrvWo=; b=TU61OGdc+kAt/ACENI+l/FiXMmlNQTnryFdgveOYj4zTa5CYZuGbT99nBIr4X7o6JG m8X3v4HJBi9O5dR7vYeHTOSKu4W+3Ogg41kcM8prNn9Lia2zbWCUBh/gQUv4NxSBFhdz GytxBW1yxvnVJe4unnmQP1vLkdu2Z4ID0ydbJhizbhKldpqj3s/JmyHgULKDR+ApxB+u j7j00GsQZ8Sw2GdJ/Ui/gZX7PqdDC/Zf3Y/7LzqPuk9R2ccVh/ZYdXVbO6ISWwaVMLbb y/UcTrlgQaWMVoaexMbXhjOW1ERZ3tTRDJo96OPqUa4kBSlYBDNkX5UPEBtn1pLCNUkU x8aQ== X-Gm-Message-State: ALoCoQlTQ0w7z1V3U9aUZr9Jcpuv9cemIVgC6lUsgppHMZQSMkkaq4S8scSByol3kpDNaLKDmGyJ MIME-Version: 1.0 X-Received: by 10.68.189.137 with SMTP id gi9mr33325717pbc.79.1403565915149; Mon, 23 Jun 2014 16:25:15 -0700 (PDT) Sender: mark@coactus.com Received: by 10.70.22.134 with HTTP; Mon, 23 Jun 2014 16:25:15 -0700 (PDT) X-Originating-IP: [192.0.216.13] In-Reply-To: References: Date: Mon, 23 Jun 2014 19:25:15 -0400 X-Google-Sender-Auth: 5wDrHMxJK5VRq858Isx-YCgO91Y Message-ID: From: Mark Baker To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mgfNUvn-INsniv3lIqhUOj0gd1s Cc: Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 23:25:18 -0000 I had a quick look at draft-douglass-timezone-service. While I agree it makes ample sense to use HTTP for this, and REST as a guide for doing so (as claimed by the draft), it isn't REST at all as it opts to use predefined parameters rather than hypermedia. The use of a custom URI scheme somewhat addresses this issue from a Web architecture POV, ensuring that only those clients that know of the scheme - and therefore the parameters - can proceed. But then that's a pretty large barrier to other non-TZ agents that might want to pull down TZ data, or even to TZ tools that might want to make use of generic HTTP tools and libraries like curl/libcurl, XMLHttpRequest, etc.. Depending upon how serious the authors/would-be-group-members are about using HTTP to maximum benefit, I suppose the charter could call this out... Just my 2c. From nobody Mon Jun 23 16:54:35 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C021A03B1; Mon, 23 Jun 2014 16:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYd2xcKnv7Us; Mon, 23 Jun 2014 16:54:25 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E8A1A02B0; Mon, 23 Jun 2014 16:54:25 -0700 (PDT) Received: from minnie.bitsea.ca (minnie.bitsea.ca [IPv6:2604:8800:137::7]) (authenticated bits=0) by orthanc.ca (8.14.7/8.14.7) with ESMTP id s5NNrinL064099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jun 2014 16:53:46 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Content-Type: multipart/signed; boundary="Apple-Mail=_6A8C67C5-9961-44FD-B615-ACC7FBE678AF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Lyndon Nerenberg In-Reply-To: <53A8A7C5.80102@qti.qualcomm.com> Date: Mon, 23 Jun 2014 16:53:43 -0700 Message-Id: References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7HG_otcEQ2Sx7pRsun2xSl0uv3I Cc: Apps Discuss , Stephan Bosch , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Barry Leiba , "ned+ietf@mrochek.com" , Kathleen Moriarty Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 23:54:27 -0000 --Apple-Mail=_6A8C67C5-9961-44FD-B615-ACC7FBE678AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 23, 2014, at 3:18 PM, Pete Resnick = wrote: > Well, that's not entirely true. Most Message-IDs are generated using = some algorithm that could conceivably be known and re-created: It is = certainly true that most Message-IDs use the current date and time as = part of the left-hand-side, along with other information, in a = well-known order.=20 Message-Id came along as a target for the References header. It was = intended to be unique, but not cryptographically so. A cheap way to build a Message-Id was sprintf(foo, "%d.%d@%s", getpid(), = ctime(NULL), gethostname()); At the time, that was pretty much guaranteed to generate a suitably = unique value. It was never intended =96 let alone anticipated =96 that the message-id = should be a cryptographically anonymous value. You cannot assume any properties of a Message-ID, other than what fits = the syntax of RFC822. =20 --lyndon --Apple-Mail=_6A8C67C5-9961-44FD-B615-ACC7FBE678AF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJTqL4HAAoJEG8PnXiV/JnUZLIP/Rj4mcluIXp+E10iKCnrCR1j bW6NxLZk6UGBpO5nxjJM+uFnpqPr4ZbGuVD2WQorZI4k6i4zyGyBB1ghgqAMS8Mm j6T9iuFvGri2/yuuFxQuzuLgmWmav2Kxhv6Hnhzv3/TEtClJFxOg5W2hluNoZodX 7x3vZ73TlW8gg+moJVZgQi8LTLMwpPPbMDvxMr8Ikkbj074ML7i5or7xd4Zvacia 286mdM7ioRDpPrzHDmoDt0FYZxd3s9zQrC9KOR+z4SXsC9y6pEbFGa1JhiwFRwu+ CrEzt9omHnl+XidGx/YdDQvVcliBEgCnJzfbSX35m10h2yhnkSk6JLpWR2aiXqB2 TQG0vd56/vbk9q69hF+OcRg3KICtQFiidDloecTzd5vOAV7N1yNAITmmVTNhw2mZ 5waxDW0mxZC/1YiD7fOGVSqYS1l/D+b7CmUmDNCawk13mS2Qy1m4mU0xNe9nNftL pDnvBiwYrbOaFAxEDOysHOmmDcnKoen71gKbaqKI5fNxs1Y0YcclFshHMzSlKN3H 1Lk1hi71G44acbNff7klfAJNC5LLXtTpQv46DDukyq3iR11iE4rXfBt+i34M+g+N fDlVcGTYoQKYjC8PKEquGe7hsPAASs7SxcZHIDNsCZdqYcdMuxLBhNWwtc7wFeB3 wZ6RepQEG4kGWPrP3u1O =lb23 -----END PGP SIGNATURE----- --Apple-Mail=_6A8C67C5-9961-44FD-B615-ACC7FBE678AF-- From nobody Tue Jun 24 03:56:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0731B2A1F; Tue, 24 Jun 2014 03:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-dUW95IRR9A; Tue, 24 Jun 2014 03:56:53 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118051B2A4A; Tue, 24 Jun 2014 03:54:23 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so157264lbj.17 for ; Tue, 24 Jun 2014 03:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6j8lzwiKXilEoo29c6Jy+FhIv+WbfSf4UoGs927SM7M=; b=kzq5obMBIdrVgWAup21WZxQWklpbMj98+DvdGo9S6PXix1B4frm/UGAolukiJhYnww on4jihqhUKYpAw9FQ4IhNmR9nRFZCDqr7IRx2irJveeSsGQ95/U4pCGGy9VSYFv+uzs0 GhXvaXMHbuFPsDTbFVQy/98SM6+GLaeLlkngaWe1T9WAeUQF1rKp8DqyQljh/WHeZJmG eGXXVEPftKQeQyq4DJZROEzwSnizH0Cs+ZAgBV8KzGDwHyEqG43KnQ3Oyw0WS+Qqh25q i4PNCASH0B971+sh5iMK3qWgOi1YfrB2H4bptK5PpngjtS9qUh7qBLXiB0Tn3zcTAhi2 tZ9g== MIME-Version: 1.0 X-Received: by 10.112.173.201 with SMTP id bm9mr167772lbc.16.1403607262279; Tue, 24 Jun 2014 03:54:22 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Tue, 24 Jun 2014 03:54:22 -0700 (PDT) In-Reply-To: <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> Date: Tue, 24 Jun 2014 06:54:22 -0400 X-Google-Sender-Auth: hV6XmRahSM9-vaMARsqC1zfWu0s Message-ID: From: Barry Leiba To: Kathleen Moriarty Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ogDIXAMpVvh4N-P_xfOtltnQnZU Cc: Apps Discuss , Stephan Bosch , Pete Resnick , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 10:56:55 -0000 > Actually, not so bizarre. You'd be surprised the lengths folks go to as > part of spear phishing attacks. These are real attacks because they > are effective. This feature could be used as part of one. No, it can't. It neither prevents nor abets phishing, and I can't imagine the scenario where it could. > In any case, I did read it wrong and would like some explicit text that > says what is deleted. Nothing is deleted, as such. The document is quite clear that if a message comes in, and its unique ID is already in the list, then a "duplicate" test returns "true". I don't see that anything more needs to be said about that. The duplicates are only deleted if the script says to do that ("if duplicate then discard;"). The script can use other actions in addition or instead. > I think there should also be a statement similar to Lyndon's response > on the fields used and possible risks. Even include it is not likely. I think it's a very bad idea to start putting descriptions of wildly odd things that people contrive, and calling them "threats", into every RFC. It distracts us from the *real* issues that people need to worry about when they're deploying this stuff. This is simply NOT a real threat. Let's not call it one. Barry From nobody Tue Jun 24 05:41:44 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603E11B2946; Tue, 24 Jun 2014 05:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPh0cFim6yrK; Tue, 24 Jun 2014 05:41:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A68631B2905; Tue, 24 Jun 2014 05:41:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140624124139.8447.64691.idtracker@ietfa.amsl.com> Date: Tue, 24 Jun 2014 05:41:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZhiENkqh9UhGRYSSt-i0SygOpTs Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Brian Haberman's No Objection on draft-ietf-appsawg-sieve-duplicate-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 12:41:41 -0000 Brian Haberman has entered the following ballot position for draft-ietf-appsawg-sieve-duplicate-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I will watch, with interest, the discussion of Alissa's DISCUSS points. From nobody Tue Jun 24 06:57:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2461B2A24; Tue, 24 Jun 2014 06:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdoIQZ8veMHU; Tue, 24 Jun 2014 06:57:07 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9FB1B294B; Tue, 24 Jun 2014 06:57:06 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id 10so494671lbg.15 for ; Tue, 24 Jun 2014 06:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=x0iQ8GRGe0oyj7Tvw5zOX7lSZ1hvzX8s9zHTKTt3pRs=; b=Czh6/ZhIT75XNRkrm8sJiQe5aP5I6Zf3rtdHurr77RZyDn0U04VpVg+weDryYpj0Bh MIZc7WghzUNO0DXq7eutImyKjzzCMu60ZhvCaValk+DLSvdGFs3xT8MwSmU2tfH5NLzK r2fjU2647ipN/ShKw3b6ZLohRK4zZ0l+G7CApkHaEWpUTiNGVcqv683Q9+mEEvSs2ihm /Nh9fvsMRMnN5o4NujP0dI3nxZAuAIjJ7CNwG5rVEKs4l1qn8ubDGMPFSPKf9Os8BHgu g5uKw41DzdnpvsfRzJ/A5FatU9/kwEa0BRdclkOO2noGP9JxhE2R46EEYi5Q4fMHZi1a FX+A== MIME-Version: 1.0 X-Received: by 10.112.34.170 with SMTP id a10mr723248lbj.11.1403618225218; Tue, 24 Jun 2014 06:57:05 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Tue, 24 Jun 2014 06:57:05 -0700 (PDT) In-Reply-To: <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> Date: Tue, 24 Jun 2014 09:57:05 -0400 X-Google-Sender-Auth: PB9pzgV28ZRUcXoj3U0M4GhqqYc Message-ID: From: Barry Leiba To: Kathleen Moriarty Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YIel8IRFkWC0L7oSEqOCjMdelpU Cc: Apps Discuss , Stephan Bosch , Pete Resnick , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 13:57:09 -0000 >> No, it can't. It neither prevents nor abets phishing, and I can't >> imagine the scenario where it could. >> > For Spear phishing, yes, this is possible. Martin explained a feasible example. What Martin described isn't phishing. But let's cut out the flailing: Please post specific text that would address your concern, so we can evaluate it. Maybe that'll get this resolved better. >>> In any case, I did read it wrong and would like some explicit text that >>> says what is deleted. >> >> Nothing is deleted, as such. The document is quite clear that if a >> message comes in, and its unique ID is already in the list, then a >> "duplicate" test returns "true". I don't see that anything more needs >> to be said about that. The duplicates are only deleted if the script >> says to do that ("if duplicate then discard;"). The script can use >> other actions in addition or instead. > > Deleting is one of the options in the intro. It's an example; there are also two other examples of how duplicates can be handled, there in the same sentence. This extension only provides a test that returns "true" or "false". What the script does with that test is up to the script. > Can you read through the > draft again as it does not clearly state what is getting moved to a > folder or deleted (if they choose to) - original message or messages > in the queue. I kinda think that's important and led to my misread of > a key point. The document repeated refers to "duplicates" and "duplicate messages". If I handed you something, then later handed you an identical thing, would you ever consider the *first* one to be the duplicate? I can't imagine. It's clear that it's the second (and subsequent) arrivals that are "duplicates" of the first. Section 3 lays out how it works. The first time we see a given unique ID, the test returns false and the unique ID is added to the duplicate tracking list. If we ever see the same unique ID again, the "duplicate" test returns "true". I have read it again, and I don't see how that's not clear. Again, what text, exactly, would you want changed? Barry From nobody Tue Jun 24 06:59:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1481B2A2A; Tue, 24 Jun 2014 06:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhtxZPxgVZNf; Tue, 24 Jun 2014 06:59:13 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30AA61B294B; Tue, 24 Jun 2014 06:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1403618353; x=1435154353; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wyqsJsnredmWzkcbR2kbu51B/II474EB+lm37OTSgyI=; b=A+kY6M61Xx1PMgVR3qtZ3FLWudWax0r/OjTGnBMcUYtKMsTGFmaWFDAq UwJW4FhzRAKF9ktEbdUVrVb8UwgGXR4T4Gsk2IoDO0Abd01aaKglEf4t0 zWzKBG+58CCxy6f6kOO13QD9o79cXIIvdVEU1+Ku0fIa0A3XEnFLGVSYQ c=; X-IronPort-AV: E=McAfee;i="5600,1067,7478"; a="67453700" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 24 Jun 2014 06:59:12 -0700 X-IronPort-AV: E=Sophos;i="5.01,538,1400050800"; d="scan'208";a="29966837" Received: from nasanexhc03.na.qualcomm.com ([10.46.56.181]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Jun 2014 06:59:12 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC03.na.qualcomm.com (10.46.56.181) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 24 Jun 2014 06:59:11 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 24 Jun 2014 06:59:09 -0700 Message-ID: <53A98428.106@qti.qualcomm.com> Date: Tue, 24 Jun 2014 06:59:04 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Kathleen Moriarty References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> In-Reply-To: <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Xiki7oEc3D-T11cAM_0WBGxhdco Cc: Apps Discuss , Stephan Bosch , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Barry Leiba , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 13:59:15 -0000 On 6/24/14 5:03 AM, Kathleen Moriarty wrote: >>> In any case, I did read it wrong and would like some explicit text that >>> says what is deleted. >>> >> Nothing is deleted, as such. The document is quite clear that if a >> message comes in, and its unique ID is already in the list, then a >> "duplicate" test returns "true". I don't see that anything more needs >> to be said about that. The duplicates are only deleted if the script >> says to do that ("if duplicate then discard;"). The script can use >> other actions in addition or instead. >> > Deleting is one of the options in the intro. Can you read through the draft again as it does not clearly state what is getting moved to a folder or deleted (if they choose to) - original message or messages in the queue. I kinda think that's important and led to my misread of a key point. > So let's be clear: The document itself doesn't define *anything* to do once you've determined that you have a duplicate by using this test; Barry's right on this point. You could delete the message, or store it in some folder, or delete the original and keep the duplicate, or delete all of your mailboxes, or spam the entire world. After all, it's a test in a script. And we certainly don't want to say, "Security consideration: Using this test could delete all of your mailboxes or spam the entire world". That would be silly. What I'm ambivalent about is whether this document should strengthen the last paragraph of section 3 (whether there or in the Sec. Cons. section) to be clear that Message-IDs are not necessarily unique, either through the fault of benign generators who just don't do such a good job, or through some attacker trying to do something obnoxious, and therefore script writers should be conservative in taking action based solely on the Message-ID indicating a duplicate. (And to be sure, this is only a warning to script writers about what is or is not reasonable; it's not a particular vulnerability in this new mechanism. A script writer could delete all of its mailboxes or spam the entire world based on all sorts of things available in sieve.) So, your call. Maybe worth adding something. But there needn't be any grand warnings of impending horror. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Jun 24 07:07:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0D01B2A35 for ; Tue, 24 Jun 2014 07:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYmIzZXvJqn7 for ; Tue, 24 Jun 2014 07:07:08 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EDB51B2934 for ; Tue, 24 Jun 2014 07:07:08 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 510D2FA0034; Tue, 24 Jun 2014 14:07:06 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1403618825-5295-5294/12/20; Tue, 24 Jun 2014 14:07:05 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Tue, 24 Jun 2014 16:07:04 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: In-Reply-To: <53A98428.106@qti.qualcomm.com> References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> <53A98428.106@qti.qualcomm.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dQjkOQCmdML45JNsoMqCHavbWIY Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 14:07:10 -0000 On Tuesday, June 24, 2014 3:59:04 PM CEST, Pete Resnick wrote: > So, your call. Maybe worth adding something. But there needn't > be any grand warnings of impending horror. +1 If you want to DoS someone into not receiving a particular message, then surely there are easier ways than predicting the message-id exactly. You could spam five hundred nearby users with a hundred messages each containing similar text and watch the spam filter learn. Arnt From nobody Tue Jun 24 07:47:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7631B2AAE; Tue, 24 Jun 2014 07:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcxug9kdo6d2; Tue, 24 Jun 2014 07:47:02 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 363291B2A4E; Tue, 24 Jun 2014 07:46:58 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5OEkuDG029259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Jun 2014 09:46:56 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s5OEktwY007522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Jun 2014 09:46:56 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s5OEkt3f012082; Tue, 24 Jun 2014 09:46:55 -0500 (CDT) Message-ID: <53A98FF9.1050802@bell-labs.com> Date: Tue, 24 Jun 2014 09:49:29 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/X4wDihyq_mX41LrWfC_V3reR5t8 Cc: draft-ietf-straw-sip-traceroute.all@tools.ietf.org, IESG IESG Subject: [apps-discuss] APPSDIR review of draft-ietf-straw-sip-traceroute-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 14:47:06 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​ http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-straw-sip-traceroute-02 Title: A Media-based Traceroute Function for the Session Initiation Protocol (SIP) Reviewer: Vijay K. Gurbani Review Date: Jun 24-2014 IETF Last Call Date: Jul-04-2014 IESG Telechat Date: Jul-10-2014 Summary: This draft is ready for publication as a Proposed Standard. Some nits and a confirmation (1 minor issue) below will require some attention. Major: 0 Minor: 1 Nits: Various Minor: - Just a confirmation: we are not defining a Required or Supported token for the traceroute mechanism described in the draft? S3, second paragraph states that, "or if the next-hop is a B2BUA that supports this mechanism, and if the B2BUA allows such testing from the requesting UAC," Here, our implicit assumption is that a B2BUA functionality will be upgraded automatically such that if it sees a M-F of 0 it create a media loopback session. If the B2BUA does not support creation of media loopback sessions, it simply sends a 483. In addition, B2BUAs that support creation of media streams MUST insert a SIP Reason header field cause value of 483. It seems that the support of the traceroute mechanisms requires some non-trivial steps by the B2BUA. But we are doing this without requiring any tokens in Required or Supported header and depending on configured policies (c.f., S3.2). Yes? - S3, third paragraph: Before creating another INV with a M-F of 1, the UAC should tear down the previous session. This is implicit behaviour of any sane implementation course, but should be stated nonetheless. Nits: - Abstract: s/field, in order to/field to/ s/generated which result/generated that result/ s/mechanism, in order to test/mechanism to/ - S2: s/rich-ringtones/rich ringtones/ s/As more and more SIP domains get deployed and interconnect/As increasingly more SIP domains get deployed and interconnected/ s/If failures or degradation occur in the media plane, it is difficult to determine where in the media path they occur./When a failure or degradation occurs in the media plane, it is difficult to determine where in the media path it occurred./ s/and media crossing/and media traversing/ s/to be able to progressively test/to progressively test/ s/will be crossed/will be traversed/ s/what URIs to/which URIs to/ -S3: s/originating UAC generates/originating UAC (Alice) generates/ s/a target AoR/a target AoR (Bob)/ Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Tue Jun 24 08:59:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2C31B2E01; Tue, 24 Jun 2014 08:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJmWhAhnFeck; Tue, 24 Jun 2014 08:59:27 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BABA1B2E20; Tue, 24 Jun 2014 08:54:20 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id 10so743909lbg.1 for ; Tue, 24 Jun 2014 08:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5FBxKlExKWzVTod4kRGHTtZ1vX4KD1ouSFFOTliG7Q0=; b=q/adg6hcvC4kTokCrluQNcJJaKbooqmqzrxofXb9fOCmGLtKIeh0G3K83dLHhmxUtc HihmMmUsfmaKVVOu1airdHQQx338pvx1TvoXMgdAZ/TVPvQiVsy6rjH+2CB+PG1npRyU pr4aG+EJ+Y105hLT23sG14GpgnaIP82WFAgLzAE5OOORRFR5/4tTlMa9/ZERx2AHlsDQ LyhY9LJO6wlcaQQFysTL9iLO70NfiX6EhsxW86TB9A2E7byFphfbPErbstap6L8HxbGR h1fFVjRXaeY2SxiQsl7qkk0xnDn4+JcY18OsC319JuZNFaGDGmrj/vKX93W0U189qQG4 fwNw== MIME-Version: 1.0 X-Received: by 10.112.172.103 with SMTP id bb7mr1098180lbc.59.1403625258459; Tue, 24 Jun 2014 08:54:18 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Tue, 24 Jun 2014 08:54:18 -0700 (PDT) In-Reply-To: References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> <53A98428.106@qti.qualcomm.com> Date: Tue, 24 Jun 2014 11:54:18 -0400 X-Google-Sender-Auth: I2gkiu2ymBOMIijPNz1EqxIe8Kc Message-ID: From: Barry Leiba To: Kathleen Moriarty Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/c9llIny7Nh4gbKJ41zmlw-4Dc2g Cc: Apps Discuss , Stephan Bosch , Pete Resnick , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 15:59:29 -0000 > In Section 3, how about adding a sentence to the end of this paragraph > (paragraph, then proposed sentence): > > In its basic form, the "duplicate" test keeps track of which messages > were seen before by this test during an earlier Sieve execution. > Messages are by default identified by their message ID as contained > in the Message-ID header. The "duplicate" test evaluates to "true" > when the message was seen before and it evaluates to "false" when it > > was not. > > Proposed sentence: > Any possible actions to subsequently received duplicate messages would > be determined by a script in the Sieve filter. That would truly be an odd thing to say: anyone implementing Sieve has to quite thoroughly understand the difference between tests and actions, because both have been implemented for the base spec long before getting to this extension. I think the core point that you're trying to make (about which the duplicates are) might be better done with some other re-wording. I think this might make the whole thing about duplicate messages clearer: OLD In its basic form, the "duplicate" test keeps track of which messages were seen before by this test during an earlier Sieve execution. Messages are by default identified by their message ID as contained in the Message-ID header. The "duplicate" test evaluates to "true" when the message was seen before and it evaluates to "false" when it was not. NEW The "duplicate" test identifies the message by a "unique ID", and, using that unique ID, keeps track of which messages were seen by a "duplicate" test during an earlier Sieve execution. In its basic form, the test gets the unique ID from the content of the message's Message-ID header. The "duplicate" test evaluates to "true" when the message was seen before and it evaluates to "false" when it was not. END OLD As a side-effect, the "duplicate" test adds the message ID to an internal duplicate tracking list once the Sieve execution finishes successfully. This way, the same test will evaluate to "true" during the next Sieve execution in which that message ID is encountered. Note that this side-effect is performed only when the "duplicate" test is actually evaluated. If the "duplicate" test is nested in a control structure or it is not the first item of an "allof" or "anyof" test list, its evaluation depends on the result of preceding tests, which may produce unexpected results. NEW As a side-effect, the "duplicate" test adds the unique ID to an internal duplicate tracking list once the Sieve execution finishes successfully. The first time a particular unique ID is seen, the message is not a duplicate, and the unique ID is added to the tracking list. If a future Sieve execution sees a message whose unique ID appears in the tracking list, that test will evaluate to "true", and that message will be considered a duplicate. Note that this side-effect is performed only when the "duplicate" test is actually evaluated. If the "duplicate" test is nested in a control structure or it is not the first item of an "allof" or "anyof" test list, its evaluation depends on the result of preceding tests, which may produce unexpected results. END If you really do want to say that this is only a test, and that it takes no actions on its own, please believe me when I say that that's entirely unnecessary, and even silly, in the context of implementing Sieve. The only thing about that that needs to be said is the side effect the test has, and that's there. >> So, your call. Maybe worth adding something. But there needn't be any >> grand warnings of impending horror. > > I agree here and thanks for the clear write up. A warning is all I was > looking to see added to cover our bases on pointing out security > considerations with using this added feature. > > Script writers using the duplicate test evaluation should be aware that > Message-IDs are not necessarily unique either through the fault of benign > generators or attackers at some point prior to the Sieve filter injecting a > message with the properties used by the duplicate Sieve filter. As such, > script writers may opt to be conservative when considering actions taken on > duplicate messages. I'm OK with that almost as it is. If we're really addressing Message-IDs I think the last sentence would work better like this: "Therefore, scripts are well advised to be conservative with respect to actions taken when duplicate messages are identified only by Message-ID." 1. Scripts are most often created automatically, so "script writers" would be a little odd. Personifying "scripts" covers cases of both human writers and automated generators. 2. It's not the duplicate messages themselves, but how the duplicates are identified. Scripts that nest the "duplicate" test in other conditional constructs could be fine in this regard, as could scripts that use the ":uniqueid" tag to build the unique ID from other things than just the Message-ID. Stephan, what do you think of all this? Barry From nobody Tue Jun 24 09:29:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990FB1B2AB9; Tue, 24 Jun 2014 09:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nGGj3YHyHqm; Tue, 24 Jun 2014 09:29:16 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02EE1B2AE1; Tue, 24 Jun 2014 09:29:16 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s5OGT7nG025376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2014 09:29:11 -0700 Message-ID: <53A9A70A.1070608@dcrocker.net> Date: Tue, 24 Jun 2014 09:27:54 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Barry Leiba , Kathleen Moriarty References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 24 Jun 2014 09:29:12 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jMxXyV51DVlYxiGzh8P-I59QMIw Cc: Apps Discuss , Stephan Bosch , Pete Resnick , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 24 Jun 2014 16:29:18 -0000 On 6/24/2014 3:54 AM, Barry Leiba wrote: > I think it's a very bad idea to start putting descriptions of wildly > odd things that people contrive, and calling them "threats", into > every RFC. It distracts us from the *real* issues that people need to > worry about when they're deploying this stuff. Having now watched this exchange I think the above raises what appears to be the larger issue. Security Considerations sections need to cover the specifics of the material covered by the document, and not include basic tutorial material on security threats and mitigations. Similarly, the section is not intended for the kind of highly detailed (and therefore obscure) discussion of threats or mitigations done in a formal threats analysis. To impose requirements that start looking like that kind of detail is to impose a DOS on IETF work. We seem to have this sort of disparity of expectations on security issues with some regularity over the years. So here is a simple suggestion: When there is a Discuss on security-related issue, the AD should: 1. Explain how it is specific to the material in the document -- rather than being generic threats and mitigations 2. How likely the scenario is 3. How serious the threat is to the use of what is covered in the document. 4. Propose text -- or guidance in the formulation of text -- to mitigate the threat that is presented by not covering the threat in the document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 24 10:31:47 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91A61A03E1; Mon, 23 Jun 2014 17:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcXHA3MFtaRb; Mon, 23 Jun 2014 17:08:50 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAB21A03D8; Mon, 23 Jun 2014 17:08:49 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P9CZD40SJ4006G65@mauve.mrochek.com>; Mon, 23 Jun 2014 17:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1403568215; bh=L9oFXJgGyBizbn8V3GUkEAW81/GDiJ/EwoJqsbrUGG4=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=Ng9tgOXfg/Qnu20IeudkjJ3ZXUdhCiWgC7bXrMC3+GF3fKFf2lOhLnnwHf1lyF4C/ 894h72c+tYUpbpBJshvyQShdViDfPgBXNc8cG78Rvmeky+uqYR3HIokd+ZGAMsJdFz CA+RDtxW0/FTsnH8FIIgEIXkXY6q1bRpQlHTuKmY= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Mon, 23 Jun 2014 17:03:32 -0700 (PDT) Message-id: <01P9CZD1NV2E0049PU@mauve.mrochek.com> Date: Mon, 23 Jun 2014 17:03:22 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 23 Jun 2014 16:02:25 -0700" <53A8B201.9050602@dcrocker.net> References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <53A8B201.9050602@dcrocker.net> To: Dave Crocker Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xLCkBgVp9XxWttOrIbi4oRNVczU X-Mailman-Approved-At: Tue, 24 Jun 2014 10:31:44 -0700 Cc: Apps Discuss , Stephan Bosch , Pete Resnick , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , Kathleen Moriarty , "appsawg-chairs@tools.ietf.org" , The IESG , Barry Leiba , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 00:08:51 -0000 > > On re-reading this, I think my response comes off as rude, when I > > didn't intend that. I did mean to dismiss your suggestion as silly, > > but I did not mean to dismiss it rudely. > We should consider memorializing this bit of text as a universal IETF > classic squib. Our version of an apology for all seasons... +1 Ned From nobody Tue Jun 24 10:32:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254481B2C2F; Mon, 23 Jun 2014 11:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tcg-mK5037K3; Mon, 23 Jun 2014 11:49:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 672E21B2C3F; Mon, 23 Jun 2014 11:49:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 11:49:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/yu9iv1VHCNeqUOpDN68I-1fgL1w X-Mailman-Approved-At: Tue, 24 Jun 2014 10:31:54 -0700 Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 18:49:22 -0000 X-List-Received-Date: Mon, 23 Jun 2014 18:49:22 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-appsawg-sieve-duplicate-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The security considerations seem light, shouldn't there be a security consideration for the possibility of overwriting a message with another? If an attacker wants to prevent someone from receiving a certain version of a message, couldn't this be used to achieve that goal? I don't see anything to prevent this, with the exception of good security practices, trusted administrators, and monitoring for any tampering on sending servers. I'm not looking for too much of a description, but a statement on this possible risk. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Alissa's discusses and will watch for the responses to address privacy and to protect the identifiers used. From nobody Tue Jun 24 10:32:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67C81A0308; Mon, 23 Jun 2014 13:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkRKAlDbDIJU; Mon, 23 Jun 2014 13:11:46 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1771B2C0F; Mon, 23 Jun 2014 13:11:45 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id z11so5215281lbi.38 for ; Mon, 23 Jun 2014 13:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rwsIehQMmzCio9aQw+5ZdygAw+SonS7lOZt7HoqvOkE=; b=S2mDrtpSwRstEXGKBdgaVuftAlq+dbVRJy+lWYP97FNADUNY8Acg2+ifDV/Ng6zToN eOuZ31/WBZV8yS90wndSqhv1cX9GFroi+QK/WfSOBGUdg8qRkpjgBwmHLeRE4uO8dlMO 2hOONYYg9BqaJZ6IgZjZaM7GpHqAh+KcErWW2KBOZm+72PYx8yPBYKqBD5ei0no7s4/9 Mfa9va9/S2Neg73Re0HllHgRJJs2//cNizBcD/D/PSe8Nfb8SOzGHZjBCyIRYdlZTZoX cdR4AodX6/vXTo06MecPe50uer/92I+YgHorcP6NsDHZJyvJxizMGCKkob5cXnvj3uda ASTA== MIME-Version: 1.0 X-Received: by 10.152.36.134 with SMTP id q6mr19053605laj.29.1403554304024; Mon, 23 Jun 2014 13:11:44 -0700 (PDT) Received: by 10.112.253.198 with HTTP; Mon, 23 Jun 2014 13:11:43 -0700 (PDT) In-Reply-To: <53A88421.60701@rename-it.nl> References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> Date: Mon, 23 Jun 2014 16:11:43 -0400 Message-ID: From: Kathleen Moriarty To: Stephan Bosch Content-Type: multipart/alternative; boundary=047d7b5d91efb6e61104fc8673b5 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/yd-mRIK2fWzYSibX72LLjV7Rih8 X-Mailman-Approved-At: Tue, 24 Jun 2014 10:31:57 -0700 Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, The IESG , apps-discuss@ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 20:11:49 -0000 --047d7b5d91efb6e61104fc8673b5 Content-Type: text/plain; charset=UTF-8 Hi Stephan, Thanks for the quick response, mine is in-line. On Mon, Jun 23, 2014 at 3:46 PM, Stephan Bosch wrote: > Hi Kathleen, > > On 6/23/2014 8:49 PM, Kathleen Moriarty wrote: > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-appsawg-sieve-duplicate-07: Discuss > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > The security considerations seem light, shouldn't there be a security > > consideration for the possibility of overwriting a message with another? > > If an attacker wants to prevent someone from receiving a certain version > > of a message, couldn't this be used to achieve that goal? I don't see > > anything to prevent this, with the exception of good security practices, > > trusted administrators, and monitoring for any tampering on sending > > servers. I'm not looking for too much of a description, but a statement > > on this possible risk. > > Replacing a targeted message with a falsification needs to occur before > the targeted message arrives at the Sieve interpreter, otherwise it is > already delivered. For the default use of the "duplicate" extension, > that requires predicting the Message-ID and ensuring that the attacker's > message arrives before the targeted message. Furthermore, it requires > knowledge of the Sieve script at the receiving end, especially if > ":header" or ":uniqueid" are used. > Yes, I figured it would be easy to do from a point prior to the receiving host with the sieve interpreter, hence my assumption above as the sending server. Use of this filter could lead to such a problem even though the attack starts on the sending server. Since the compete message is not checked to ensure it is the same as the previous, there are ways to accomplish this type of attack. In adding this capability, which relies on limited fields for the comparison to detect duplicates, it is subject to the described attack. Sure, the attack originates at the sending MTA or some point before the receiving Sieve interpreter, but would not be possible of a fuller comparison were performed. Essentially, this is a risk that should be made known in the security consideration section that happens when you start using this feature. Could you add a few sentences on the risk? Since the Sieve filter can choose how the comparison is known, include that the specific implementation knowledge is required, making it more difficult to perform (not impossible though, so there is still a risk). > > This risk seems minimal to me. Therefore, I am not sure whether I > understand the mechanism of the attack you describe. Could you elaborate? > Does the above help? Thanks, Kathleen > > Regards, > > Stephan. > > -- Best regards, Kathleen --047d7b5d91efb6e61104fc8673b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephan,

Thanks for the quick respon= se, mine is in-line.


On Mon, Jun 23, 2014 at 3:46 PM, Stephan Bosch <stephan@rena= me-it.nl> wrote:
Hi Kathleen,

On 6/23/2014 8:49 PM, Kathleen Moriarty wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-appsawg-sieve-duplicate-07: Discuss
>
> ------------------------------------------------= ----------------------
> DISCUSS:
> ----------------------------------------------------------------------=
>
> The security considerations seem light, shouldn't there be a secur= ity
> consideration for the possibility of overwriting a message with anothe= r?
> If an attacker wants to prevent someone from receiving a certain versi= on
> of a message, couldn't this be used to achieve that goal? =C2=A0I = don't see
> anything to prevent this, with the exception of good security practice= s,
> trusted administrators, and monitoring for any tampering on sending > servers. =C2=A0I'm not looking for too much of a description, but = a statement
> on this possible risk.

Replacing a targeted message with a falsification needs to occur befo= re
the targeted message arrives at the Sieve interpreter, otherwise it is
already delivered. For the default use of the "duplicate" extensi= on,
that requires predicting the Message-ID and ensuring that the attacker'= s
message arrives before the targeted message. Furthermore, it requires
knowledge of the Sieve script at the receiving end, especially if
":header" or ":uniqueid" are used.
=C2=A0
Yes, I figured it would be easy to do from a point prior = to the receiving host with the sieve interpreter, hence my assumption above= as the sending server. =C2=A0Use of this filter could lead to such a probl= em even though the attack starts on the sending server. =C2=A0Since the com= pete message is not checked to ensure it is the same as the previous, there= are ways to accomplish this type of attack. =C2=A0In adding this capabilit= y, which relies on limited fields for the comparison to detect duplicates, = it is subject to the described attack. =C2=A0Sure, the attack originates at= the sending MTA or some point before the receiving Sieve interpreter, but = would not be possible of a fuller comparison were performed. =C2=A0Essentia= lly, this is a risk that should be made known in the security consideration= section that happens when you start using this feature.

Could you add a few sentences on the risk? =C2=A0Since = the Sieve filter can choose how the comparison is known, include that the s= pecific implementation knowledge is required, making it more difficult to p= erform (not impossible though, so there is still a risk).
=C2=A0

This risk seems minimal to me. Therefore, I am not sure whether I
understand the mechanism of the attack you describe. Could you elaborate?

Does the above help? =C2=A0
Thanks,
Kathleen=C2=A0

Regards,

Stephan.




--

Best regards,
Kathleen
--047d7b5d91efb6e61104fc8673b5-- From nobody Tue Jun 24 10:32:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992751A063A; Mon, 23 Jun 2014 18:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.099 X-Spam-Level: **** X-Spam-Status: No, score=4.099 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_IS_IT_OUR_ACCOUNT=4.2, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRirG_8Bg7J7; Mon, 23 Jun 2014 18:40:27 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B7C1A053B; Mon, 23 Jun 2014 18:40:27 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id r5so6768676qcx.8 for ; Mon, 23 Jun 2014 18:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=85ei2HeaLh0SZ3uw/RHPx71bTS3YDpT+FCansl+Cfu0=; b=y+zlVzQfPIXinPLwNipVx4bB6ad24UxlyvETsGBEmBrAGbE8gKhDdumjbMha/fWi7A ckvFiLElNXdgwHFbW/Z14aDOv6A53OjDoJYvcz5RpuqHmC9WCOuX5erQFHHohPrMmFu1 /qtsDeEMqhP1wsfVYlIEKfGu0BPseyRg6LRLJpzPM/She3y5zwE4PFjed1th3EeEhyJ1 Zb4k/52oZmuUIrgT0ho+WXpMJOeHXgM+2AX2tYWGBS2r4ceD0i2VE4TiLKjsn7T7kPkY 2c+pUpZzlbA8zm3U16Ud/sBHBIPrCllIfQd7cCgwbIDL7yHQ9MajATY7ykDb3+cI/hDx 8gjQ== X-Received: by 10.140.97.33 with SMTP id l30mr37566291qge.19.1403574026376; Mon, 23 Jun 2014 18:40:26 -0700 (PDT) Received: from [192.168.1.4] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id b10sm12687285qgf.7.2014.06.23.18.40.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Jun 2014 18:40:24 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D167) In-Reply-To: <53A8A7C5.80102@qti.qualcomm.com> Date: Mon, 23 Jun 2014 21:40:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <93BD4470-CD8B-493F-B067-CE287E3AFD68@gmail.com> References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> To: Pete Resnick Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/F0cZreLheB9rJQ1NBg39N61kFXw X-Mailman-Approved-At: Tue, 24 Jun 2014 10:31:58 -0700 Cc: Apps Discuss , Stephan Bosch , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Barry Leiba , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 01:40:29 -0000 Hi, Head out for a swim around Walden Pond and mail exploded! Response in line a= nd thanks for the discussion and imagination, having led incident response t= eams, if there is a hole, it will be found ;-) I had to go back several messages because text was cut in subsequent ones to= get to the bottom of this. Sent from my iPhone > On Jun 23, 2014, at 6:18 PM, Pete Resnick wrot= e: >=20 >> On 6/23/14 2:36 PM, Barry Leiba wrote: >> 3. How is the attacker going to determine the Message-ID of a message >> that you will get, but that you haven't gotten yet, and that the >> attacker wants to block? Message-ID values are not predictable. >=20 > Well, that's not entirely true. Most Message-IDs are generated using some a= lgorithm that could conceivably be known and re-created: It is certainly tru= e that most Message-IDs use the current date and time as part of the left-ha= nd-side, along with other information, in a well-known order. So: I agree with Pete here, if someone was determined, they would figure this ou= t. FYI - when you are defending against state sponsored hackers, I would as= sume they could figure out the message ID or do something in flight. =20 >=20 >> 4. Assuming the attacker can figure out a Message-ID to attack, how is >> the attacker going to get her message delivered before the one she >> wants to block? That's the only way to have the blocked message be >> discarded by this feature. Two part response, this could be part of a phishing attack, replacing a real= message. Now, I just reread the draft and see where the problem is, it doesn't explic= itly state that the subsequent messages are the ones deleted. It makes sens= e that would be the case off the message queue, but text would be helpful, m= aybe in section 3.2 or sooner? It does show up in the examples, but that's t= he only place I could find. I read the draft incorrectly and somehow got the impression that the subsequ= ent message would replace the original. Not sure what made me think that, t= he noise around me and thinking of cases where people correct messages (not i= n the draft). Thanks, Kathleen=20 >=20 > Imagine that I want you not to get a piece of mail that is sent out at the= end of the month telling you some important piece of information (like the n= umber of failed log-in attempts to your account, or the number of traffic ti= ckets issued for a particular truck you own). I know that the service sendin= g this mail always sends on the first of the month at midnight exactly, and I= know the algorithm that they use to generate Message-IDs, **and it doesn't i= nclude some randomly generated gobbledygook as part of it.** If I send you a= message just prior to when you're supposed to get your important message wi= th the Message-ID I was able to predict and recreate, I can get you to disca= rd the message. >=20 > Now, the big question is: Do people algorithmically generate Message-IDs w= ithout random gobbledygook? I don't really know the answer to that. But give= n that 5322 doesn't require a particular algorithm that includes random data= , it's certainly possible that this could be used for ill. >=20 >> 5. Given that an attacker would have to come up with a Message-ID to >> use for the attack, and then get her message delivered first so that >> the legitimate message is the one that's considered the discardable >> duplicate, do you really think this is real threat? >=20 > I'm not sure. >=20 > pr >=20 > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 From nobody Tue Jun 24 10:32:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13031A0426; Mon, 23 Jun 2014 18:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEYKhMllEmvQ; Mon, 23 Jun 2014 18:42:41 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C0F1B2796; Mon, 23 Jun 2014 18:42:41 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id r5so6782476qcx.36 for ; Mon, 23 Jun 2014 18:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I6VIheipEGLYM6MMfPS6aXc3jMTIzEgOx/M9YUNmNjg=; b=be6nJlposo5JPsvpulTvTHM3p7xMim1aHKb85KwdE5EA7+/x6GBRyKlwvhjimA8fOZ UUjCru4zyNLAdjX9JvS1v8nUKNbcGZP7sS2vOQvA1hPY+otsE/rbau/6rUNWx0eEjl7R zbWrR2qqNpyUI3EbSZoIBf+j+XT+3+W0NdTEqDQD4tK/x/ZryqUYhPUclNhJC3A1QKtR 5/rpMdDkYsPOaycDiMl0I/hSjLoi2IEWcewnevt5m5w1DKZp1j0IwVzrw2IBuN28a1/Z oXRTkknDcu1nj8a3D6CeSsHrD71D0KMyz6EpIu4bTN3v6WcQrrjA8P4xbUGuvc/MXTNM ZFjw== X-Received: by 10.140.104.225 with SMTP id a88mr35465974qgf.91.1403574160488; Mon, 23 Jun 2014 18:42:40 -0700 (PDT) Received: from [192.168.1.4] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id r4sm33025440qat.42.2014.06.23.18.42.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Jun 2014 18:42:39 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Mon, 23 Jun 2014 21:42:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <86B14A12-AFB6-41B5-9C9D-BC711181272E@gmail.com> References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> To: Lyndon Nerenberg Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/opcGipco4qzQV6bqsZm_NJ8SvnQ X-Mailman-Approved-At: Tue, 24 Jun 2014 10:31:59 -0700 Cc: Apps Discuss , Stephan Bosch , Pete Resnick , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Barry Leiba , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 01:42:46 -0000 Hi Lyndon, Thanks for the additional response, see in-line. Sent from my iPhone > On Jun 23, 2014, at 7:53 PM, Lyndon Nerenberg wrote: >=20 >=20 >> On Jun 23, 2014, at 3:18 PM, Pete Resnick wro= te: >>=20 >> Well, that's not entirely true. Most Message-IDs are generated using some= algorithm that could conceivably be known and re-created: It is certainly t= rue that most Message-IDs use the current date and time as part of the left-= hand-side, along with other information, in a well-known order.=20 >=20 > Message-Id came along as a target for the References header. It was inten= ded to be unique, but not cryptographically so. Yes and that's fine. My point wasn't to change this, but to state the risk o= f relying on it. Thanks, Kathleen=20 =20 >=20 > A cheap way to build a Message-Id was sprintf(foo, "%d.%d@%s", getpid(), c= time(NULL), gethostname()); >=20 > At the time, that was pretty much guaranteed to generate a suitably unique= value. >=20 > It was never intended =E2=80=93 let alone anticipated =E2=80=93 that the m= essage-id should be a cryptographically anonymous value. >=20 > You cannot assume any properties of a Message-ID, other than what fits the= syntax of RFC822. =20 >=20 > --lyndon >=20 From nobody Tue Jun 24 10:32:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5498E1A083D; Mon, 23 Jun 2014 18:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.2 X-Spam-Level: ** X-Spam-Status: No, score=2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_IS_IT_OUR_ACCOUNT=4.2, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RKHl8NIo0O1; Mon, 23 Jun 2014 18:49:27 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394731A05CB; Mon, 23 Jun 2014 18:49:27 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id hw13so6511184qab.31 for ; Mon, 23 Jun 2014 18:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PBf6PZ5dcXjk5VvrF+u9+hJ+LNg0EIbMSxDaemukaZo=; b=pvyM8GZJ3VECTiwJBisGb8RS1/kt9KKoQV0ufYs8WglSFI691uwi6s4pjbd5HYYeLh WI7mQVmTJwrFjSyEc6jkWmhvLPerI1+sKC9y7veOE74/KYbFVnD70C0YJvZx2XJA6Fo7 42DQYZyGIYjIoKprmIghCNE2BR/CqWS8XPVxgDkj9YfWZB18oElGdtILHGmJG7k1PprQ 498Jh1ilJQ+15+Bs+WxCTw+MzSTbyxfwq0jkXylo12ucIpGa4croJFKerpqlWqp6wxTL +W32mXfktHqFdAYL57sW2XjUX7TL7Od4tYCkt3TOw/+vybAtN1WxqIuxfpJjWmyVS5ro V8xg== X-Received: by 10.140.51.37 with SMTP id t34mr26480084qga.50.1403574566375; Mon, 23 Jun 2014 18:49:26 -0700 (PDT) Received: from [192.168.1.4] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id s2sm33057067qaj.36.2014.06.23.18.49.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Jun 2014 18:49:24 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Mon, 23 Jun 2014 21:49:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> To: Barry Leiba Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Sor-AEX4PthZfAQFapHK3VCO2RA X-Mailman-Approved-At: Tue, 24 Jun 2014 10:32:00 -0700 Cc: Apps Discuss , Stephan Bosch , Pete Resnick , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 01:49:28 -0000 Actually, not so bizarre. You'd be surprised the lengths folks go to as par= t of spear phishing attacks. These are real attacks because they are effect= ive. This feature could be used as part of one. In any case, I did read it wrong and would like some explicit text that says= what is deleted. I think there should also be a statement similar to Lyndon's response on the= fields used and possible risks. Even include it is not likely. Thanks, Kathleen=20 Sent from my iPhone On Jun 23, 2014, at 6:29 PM, Barry Leiba wrote: >> Imagine that I want you not to get a piece of mail that is sent out at th= e >> end of the month telling you some important piece of information (like th= e >> number of failed log-in attempts to your account, or the number of traffi= c >> tickets issued for a particular truck you own). I know that the service >> sending this mail always sends on the first of the month at midnight >> exactly, and I know the algorithm that they use to generate Message-IDs, >> **and it doesn't include some randomly generated gobbledygook as part of >> it.** If I send you a message just prior to when you're supposed to get y= our >> important message with the Message-ID I was able to predict and recreate,= I >> can get you to discard the message. >=20 > Oh, please: this is a movie-plot threat most bizarre. It requires a > specific situation, a specific implementation, and so much advance > knowledge that you might as well put on a tinfoil hat. >=20 > I honestly can't countenance putting advice about these flights of > imagination into all of our RFCs. Really, Pete? >=20 > Barry From nobody Tue Jun 24 10:32:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044D21B28C2; Tue, 24 Jun 2014 05:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1z5gWnASbkj; Tue, 24 Jun 2014 05:04:02 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900EE1B2878; Tue, 24 Jun 2014 05:04:01 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id r5so149300qcx.8 for ; Tue, 24 Jun 2014 05:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0ArT4H/znzYDRurCIcWBG5kIgCJ0mybLdQ08mHJ+OwI=; b=WadX4Mk6lEO6ZOAg5sBYdENtIdDP45R1KQHNwUszdhQNaVryDoZuwgOy8kR8GYcXK1 2/wVN4oRTYuY1ivw/OUu8vkEQCVbpRRLPZODjqXJe645hj5FTa7RYz+2acj6lPqRll1r DznUBw6tbH847ESrpORttnbX4OHal7/C6ikSBqBDx6NV2I+myh/0kPCcSm7XBop+Ur1s mHi5dBC1h+C9tLx+wUMrY75TkhROkJX6JhB9uQXcBmPYk0qF+wX3lLM/6TFiUck6eMKu YuHqGIF3PH08gV8XZx9SC9rnrrOzixn8BIWyhTj5oJZ77dv8qzjrR3vc2ZaW9o5xvX8M rOrw== X-Received: by 10.224.156.132 with SMTP id x4mr590344qaw.101.1403611440810; Tue, 24 Jun 2014 05:04:00 -0700 (PDT) Received: from [192.168.1.4] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id o10sm134897qah.3.2014.06.24.05.03.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Jun 2014 05:03:58 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Tue, 24 Jun 2014 08:03:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> To: Barry Leiba Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/PLLdFvzY2s0JvNYbwMs55t2wlPc X-Mailman-Approved-At: Tue, 24 Jun 2014 10:32:01 -0700 Cc: Apps Discuss , Stephan Bosch , Pete Resnick , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 12:04:04 -0000 Barry, Sent from my iPhone On Jun 24, 2014, at 6:54 AM, Barry Leiba wrote: >> Actually, not so bizarre. You'd be surprised the lengths folks go to as >> part of spear phishing attacks. These are real attacks because they >> are effective. This feature could be used as part of one. >=20 > No, it can't. It neither prevents nor abets phishing, and I can't > imagine the scenario where it could. >=20 For Spear phishing, yes, this is possible. Martin explained a feasible exam= ple. There are very real spear phishing attacks that go to great lengths to= fool the recipient into thinking the message is real. Conference mailings a= nd airline plans have been used in these real attacks. I think it's naive t= o assume something that has no protections except timing and a text ID are i= mmune to such problems and can't be used by attackers.=20 If a call helps, I'll walk you through spear phishing examples. I'll be at the FIRST conference tomorrow and Friday (speaking), so I can pro= bably get some new ones from attendees. >> In any case, I did read it wrong and would like some explicit text that >> says what is deleted. >=20 > Nothing is deleted, as such. The document is quite clear that if a > message comes in, and its unique ID is already in the list, then a > "duplicate" test returns "true". I don't see that anything more needs > to be said about that. The duplicates are only deleted if the script > says to do that ("if duplicate then discard;"). The script can use > other actions in addition or instead. Deleting is one of the options in the intro. Can you read through the draft= again as it does not clearly state what is getting moved to a folder or del= eted (if they choose to) - original message or messages in the queue. I kin= da think that's important and led to my misread of a key point. >=20 >> I think there should also be a statement similar to Lyndon's response >> on the fields used and possible risks. Even include it is not likely. >=20 > I think it's a very bad idea to start putting descriptions of wildly > odd things that people contrive, and calling them "threats", into > every RFC. It distracts us from the *real* issues that people need to > worry about when they're deploying this stuff. There are no considerations in this draft. A feature is being added that add= s a risk, letting people know about it shouldn't be out of the question. I d= on't think this is widely odd. We can wait until it gets used and update th= e draft later or add a statement that says plain text values are used for th= is feature, which has a potential for abuse if a sender is aware that the fe= ature is in use and how it is implemented at a destination. Spear phishing builds on the examples Pete and Martin provided. Let's as a c= onference is being organized and a mass mailing is going out. Competitors o= f the host typically attend. A few are singled out and receive a message wi= th a special link to the conference site that downloads and installs malware= to spy on the user (this is very real, I've looked at systems post infectio= n before). Or a special word or PDF is attached to a few of the messages th= at does something similar because of a vulnerability in one of those product= s. In spear phishing, targets are watched for a while and methods to fool them a= re devised over time. This stuff is not made up. The conference one has be= en used, this feature just gives an opportunity to have the message look mor= e like the others. Regards, Kathleen=20 >=20 > This is simply NOT a real threat. Let's not call it one. > Barry From nobody Tue Jun 24 10:32:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A721B2D67; Tue, 24 Jun 2014 08:30:04 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0asQlXJ6Vov; Tue, 24 Jun 2014 08:30:00 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD711B2D72; Tue, 24 Jun 2014 08:27:04 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so688075lbj.17 for ; Tue, 24 Jun 2014 08:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QCL9khtnanDAh68JJn2sHWrqgUn7iBH9IqkurXS90Zg=; b=bRvi1RLgC4XEodlkOB8ugN3FjW8sYh/0WO3SdlDu/tQVgd7Rctt6cXpE9aT5P1E0pK NPqUtjVsD91AVBVhzb2fwZNVibKypjT+l6VQQOvoIeTpD9O0PPUqZfeK5qrBeShUV3Tz nNbp2+PCXKrpvDHe10gprajF5iWBYLYM04B7/DGUkrJ1kR6yfpLGZIGwYu36UePLZ4xD DR2Pg/jZagZ16x1TvGiWZQvMybdLVb9PU6mcQ+xaZTqamH3qQ2/vxQ154qwU6a3nX3Dc p9Tpb0uXCJDkFxPF/NXTRWrD6ChF4g6xRDgEfH7RUIJd8FQ0ql5e6bTfGixB/Zof9+1y hsNA== MIME-Version: 1.0 X-Received: by 10.152.1.99 with SMTP id 3mr1090311lal.43.1403623622091; Tue, 24 Jun 2014 08:27:02 -0700 (PDT) Received: by 10.112.253.198 with HTTP; Tue, 24 Jun 2014 08:27:02 -0700 (PDT) In-Reply-To: <53A98428.106@qti.qualcomm.com> References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> <53A98428.106@qti.qualcomm.com> Date: Tue, 24 Jun 2014 11:27:02 -0400 Message-ID: From: Kathleen Moriarty To: Pete Resnick Content-Type: multipart/alternative; boundary=089e013c6ae264aaa704fc9697ba Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/klx9DD9UrAvmDYZeAkGxhTIB3YU X-Mailman-Approved-At: Tue, 24 Jun 2014 10:32:01 -0700 Cc: Apps Discuss , Stephan Bosch , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Barry Leiba , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 15:30:04 -0000 --089e013c6ae264aaa704fc9697ba Content-Type: text/plain; charset=UTF-8 Thank you all for the discussion on this! It's helped to clear up some points, at least for me. Proposed text to be altered if needed is included in-line. On Tue, Jun 24, 2014 at 9:59 AM, Pete Resnick wrote: > On 6/24/14 5:03 AM, Kathleen Moriarty wrote: > > In any case, I did read it wrong and would like some explicit text that >>>> says what is deleted. >>>> >>>> >>> Nothing is deleted, as such. The document is quite clear that if a >>> message comes in, and its unique ID is already in the list, then a >>> "duplicate" test returns "true". I don't see that anything more needs >>> to be said about that. The duplicates are only deleted if the script >>> says to do that ("if duplicate then discard;"). The script can use >>> other actions in addition or instead. >>> >>> >> Deleting is one of the options in the intro. Can you read through the >> draft again as it does not clearly state what is getting moved to a folder >> or deleted (if they choose to) - original message or messages in the queue. >> I kinda think that's important and led to my misread of a key point. >> >> > > So let's be clear: The document itself doesn't define *anything* to do > once you've determined that you have a duplicate by using this test; > Barry's right on this point. You could delete the message, or store it in > some folder, or delete the original and keep the duplicate, or delete all > of your mailboxes, or spam the entire world. After all, it's a test in a > script. And we certainly don't want to say, "Security consideration: Using > this test could delete all of your mailboxes or spam the entire world". > That would be silly. > Sure, agreed. I wasn't debating that point and think it is clear that the script takes the action, not the duplicate feature. In Section 3, how about adding a sentence to the end of this paragraph (paragraph, then proposed sentence): In its basic form, the "duplicate" test keeps track of which messages were seen before by this test during an earlier Sieve execution. Messages are by default identified by their message ID as contained in the Message-ID header. The "duplicate" test evaluates to "true" when the message was seen before and it evaluates to "false" when it was not. Proposed sentence: Any possible actions to subsequently received duplicate messages would be determined by a script in the Sieve filter. > What I'm ambivalent about is whether this document should strengthen the > last paragraph of section 3 (whether there or in the Sec. Cons. section) to > be clear that Message-IDs are not necessarily unique, either through the > fault of benign generators who just don't do such a good job, or through > some attacker trying to do something obnoxious, and therefore script > writers should be conservative in taking action based solely on the > Message-ID indicating a duplicate. (And to be sure, this is only a warning > to script writers about what is or is not reasonable; it's not a particular > vulnerability in this new mechanism. A script writer could delete all of > its mailboxes or spam the entire world based on all sorts of things > available in sieve.) > > So, your call. Maybe worth adding something. But there needn't be any > grand warnings of impending horror. I agree here and thanks for the clear write up. A warning is all I was looking to see added to cover our bases on pointing out security considerations with using this added feature. Script writers using the duplicate test evaluation should be aware that Message-IDs are not necessarily unique either through the fault of benign generators or attackers at some point prior to the Sieve filter injecting a message with the properties used by the duplicate Sieve filter. As such, script writers may opt to be conservative when considering actions taken on duplicate messages. Edit away! Thanks! Kathleen > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > -- Best regards, Kathleen --089e013c6ae264aaa704fc9697ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you all for the discussion on this! =C2=A0It's h= elped to clear up some points, at least for me. =C2=A0Proposed text to be a= ltered if needed is included in-line.


On Tue, Jun 24, 2014 at 9:59 AM, Pete Resnick <presnick@qti.qualco= mm.com> wrote:
On 6/24/14 5:03 AM, Kathleen Moriarty wrote:

In any case, I did read it wrong and would like some explicit text that
says what is deleted.
=C2=A0 =C2=A0 =C2=A0 =C2=A0
Nothing is deleted, as such. =C2=A0The document is quite clear that if a message comes in, and its unique ID is already in the list, then a
"duplicate" test returns "true". =C2=A0I don't see = that anything more needs
to be said about that. =C2=A0The duplicates are only deleted if the script<= br> says to do that ("if duplicate then discard;"). =C2=A0The script = can use
other actions in addition or instead.
=C2=A0 =C2=A0 =C2=A0
Deleting is one of the options in the intro. =C2=A0Can you read through the= draft again as it does not clearly state what is getting moved to a folder= or deleted (if they choose to) - original message or messages in the queue= . =C2=A0I kinda think that's important and led to my misread of a key p= oint.
=C2=A0 =C2=A0

So let's be clear: The document itself doesn't define *anything* to= do once you've determined that you have a duplicate by using this test= ; Barry's right on this point. You could delete the message, or store i= t in some folder, or delete the original and keep the duplicate, or delete = all of your mailboxes, or spam the entire world. After all, it's a test= in a script. And we certainly don't want to say, "Security consid= eration: Using this test could delete all of your mailboxes or spam the ent= ire world". That would be silly.

Sure, agreed. I wasn't debating that p= oint and think it is clear that the script takes the action, not the duplic= ate feature.

In Section 3, how about adding a sent= ence to the end of this paragraph (paragraph, then proposed sentence): 

   In its basic form,=
 the "duplicate" test keeps track of which messages
   were seen before by this test during an earlier Sieve execution.
   Messages are by default identified by their message ID as contained
   in the Message-ID header.  The "duplicate" test evaluates to &=
quot;true"
   when the message was seen before and it evaluates to "false" w=
hen it=C2=A0
=C2=A0 =C2=A0 =C2=A0 was not.=C2=A0

Proposed sentence:
=C2=A0 =C2=A0 =C2=A0Any possible actions to su= bsequently received duplicate messages would be determined by a script in t= he Sieve filter. =C2=A0


What I'm ambivalent about is whether this document should strengthen th= e last paragraph of section 3 (whether there or in the Sec. Cons. section) = to be clear that Message-IDs are not necessarily unique, either through the= fault of benign generators who just don't do such a good job, or throu= gh some attacker trying to do something obnoxious, and therefore script wri= ters should be conservative in taking action based solely on the Message-ID= indicating a duplicate. (And to be sure, this is only a warning to script = writers about what is or is not reasonable; it's not a particular vulne= rability in this new mechanism. A script writer could delete all of its mai= lboxes or spam the entire world based on all sorts of things available in s= ieve.)

So, your call. Maybe worth adding something. But there needn't be any g= rand warnings of impending horror.

I agree = here and thanks for the clear write up. =C2=A0A warning is all I was lookin= g to see added to cover our bases on pointing out security considerations w= ith using this added feature.

Script writers using the duplicate test evaluation shou= ld be aware that Message-IDs are not necessarily unique either through the = fault of benign generators or attackers at some point prior to the Sieve fi= lter injecting a message with the properties used by the duplicate Sieve fi= lter. =C2=A0As such, script writers may opt to be conservative when conside= ring actions taken on duplicate messages. =C2=A0

Edit away!

Thanks!
K= athleen
=C2=A0
pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478




--
=

Best regards,
Kathleen
--089e013c6ae264aaa704fc9697ba-- From nobody Tue Jun 24 10:32:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EA91B2D7C; Tue, 24 Jun 2014 09:55:15 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0LcjZLVQy7n; Tue, 24 Jun 2014 09:55:13 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC981B2D99; Tue, 24 Jun 2014 09:55:12 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id 10so865385lbg.9 for ; Tue, 24 Jun 2014 09:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zvm8zwf4+uNsqM6gL9240gpoY7CjhwZ8Vp8c1e8kAKg=; b=kq6O4csuxSQgctyeo5OG2/BALbfzZqOY4c+oBu5+q8SRum28Gae0V3PPxN14akleuc bR8NLcMLxNxA06Gw0RDgwaTQ7t+3aKUNRvBADRto6qkuf06Bcl3t3jhHragkojpW4oDL CCYO4Ovr/IknB6ZAsWFeuNnbvhiyvlsv9WaymxDUf0U7BXRhSwCRLdPciaIMtksrqR9e f9sL+xqSXklrk6odnv1E0Dgai/p2eo9mBo4FVr1PIInCbGk9I+ZjEL5XLQe0k1UylMxi SDCW0PuQ/kNglbhz0gAHlfO1o6Dq6k6AqAryuXwnoSrn/nkpBqNtb7RJXnMlaHxYdgcJ RJWQ== MIME-Version: 1.0 X-Received: by 10.112.122.113 with SMTP id lr17mr618287lbb.105.1403628910304; Tue, 24 Jun 2014 09:55:10 -0700 (PDT) Received: by 10.112.253.198 with HTTP; Tue, 24 Jun 2014 09:55:10 -0700 (PDT) In-Reply-To: References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> <53A98428.106@qti.qualcomm.com> Date: Tue, 24 Jun 2014 12:55:10 -0400 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7bfcf74a98645e04fc97d211 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/i9O0BtkiE2u4Ifb6PoQUc7a6OoA X-Mailman-Approved-At: Tue, 24 Jun 2014 10:32:02 -0700 Cc: Apps Discuss , Stephan Bosch , Pete Resnick , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 16:55:16 -0000 --047d7bfcf74a98645e04fc97d211 Content-Type: text/plain; charset=UTF-8 Barry, Thanks for taking the time to discuss this. Response in-line. On Tue, Jun 24, 2014 at 11:54 AM, Barry Leiba wrote: > > In Section 3, how about adding a sentence to the end of this paragraph > > (paragraph, then proposed sentence): > > > > In its basic form, the "duplicate" test keeps track of which messages > > were seen before by this test during an earlier Sieve execution. > > Messages are by default identified by their message ID as contained > > in the Message-ID header. The "duplicate" test evaluates to "true" > > when the message was seen before and it evaluates to "false" when it > > > > was not. > > > > Proposed sentence: > > Any possible actions to subsequently received duplicate messages > would > > be determined by a script in the Sieve filter. > > That would truly be an odd thing to say: anyone implementing Sieve has > to quite thoroughly understand the difference between tests and > actions, because both have been implemented for the base spec long > before getting to this extension. > > I think the core point that you're trying to make (about which the > duplicates are) might be better done with some other re-wording. I > think this might make the whole thing about duplicate messages > clearer: > > OLD > In its basic form, the "duplicate" test keeps track of which messages > were seen before by this test during an earlier Sieve execution. > Messages are by default identified by their message ID as contained > in the Message-ID header. The "duplicate" test evaluates to "true" > when the message was seen before and it evaluates to "false" when it > was not. > NEW > The "duplicate" test identifies the message by a "unique ID", and, > using that unique ID, keeps track of which messages were seen > by a "duplicate" test during an earlier Sieve execution. In its basic > form, the test gets the unique ID from the content of the message's > Message-ID header. The "duplicate" test evaluates to "true" when > the message was seen before and it evaluates to "false" when it > was not. > END > WFM and thank you. My words were meant to help the discussion and get edited as needed. You are more familiar with the terminology used by the group. > > OLD > As a side-effect, the "duplicate" test adds the message ID to an > internal duplicate tracking list once the Sieve execution finishes > successfully. This way, the same test will evaluate to "true" during > the next Sieve execution in which that message ID is encountered. > Note that this side-effect is performed only when the "duplicate" > test is actually evaluated. If the "duplicate" test is nested in a > control structure or it is not the first item of an "allof" or > "anyof" test list, its evaluation depends on the result of preceding > tests, which may produce unexpected results. > NEW > As a side-effect, the "duplicate" test adds the unique ID to an > internal duplicate tracking list once the Sieve execution finishes > successfully. The first time a particular unique ID is seen, the > message is not a duplicate, and the unique ID is added to the > tracking list. If a future Sieve execution sees a message whose > unique ID appears in the tracking list, that test will evaluate to > "true", and that message will be considered a duplicate. > > Note that this side-effect is performed only when the "duplicate" > test is actually evaluated. If the "duplicate" test is nested in a > control structure or it is not the first item of an "allof" or > "anyof" test list, its evaluation depends on the result of preceding > tests, which may produce unexpected results. > END > WFM, thank you! > > If you really do want to say that this is only a test, and that it > takes no actions on its own, please believe me when I say that that's > entirely unnecessary, and even silly, in the context of implementing > Sieve. The only thing about that that needs to be said is the side > effect the test has, and that's there. > That's fine, it was in the discussion thread, so I used it. Your wroding work. If Stephan is good with it, we should be okay? Thanks! Kathleen > > >> So, your call. Maybe worth adding something. But there needn't be any > >> grand warnings of impending horror. > > > > I agree here and thanks for the clear write up. A warning is all I was > > looking to see added to cover our bases on pointing out security > > considerations with using this added feature. > > > > Script writers using the duplicate test evaluation should be aware that > > Message-IDs are not necessarily unique either through the fault of benign > > generators or attackers at some point prior to the Sieve filter > injecting a > > message with the properties used by the duplicate Sieve filter. As such, > > script writers may opt to be conservative when considering actions taken > on > > duplicate messages. > > I'm OK with that almost as it is. If we're really addressing > Message-IDs I think the last sentence would work better like this: > > "Therefore, scripts are well advised to be conservative with respect > to actions taken when duplicate messages are identified only by > Message-ID." > > 1. Scripts are most often created automatically, so "script writers" > would be a little odd. Personifying "scripts" covers cases of both > human writers and automated generators. > > 2. It's not the duplicate messages themselves, but how the duplicates > are identified. Scripts that nest the "duplicate" test in other > conditional constructs could be fine in this regard, as could scripts > that use the ":uniqueid" tag to build the unique ID from other things > than just the Message-ID. > > Stephan, what do you think of all this? > > Barry > -- Best regards, Kathleen --047d7bfcf74a98645e04fc97d211 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Barry,

Thanks for taking the time to di= scuss this. =C2=A0Response in-line.


<= div class=3D"gmail_quote">On Tue, Jun 24, 2014 at 11:54 AM, Barry Leiba <barryleiba@computer.org> wrote:
> In Section 3, how about= adding a sentence to the end of this paragraph
> (paragraph, then proposed sentence):
>
> =C2=A0 =C2=A0In its basic form, the "duplicate" test keeps t= rack of which messages
> =C2=A0 =C2=A0were seen before by this test during an earlier Sieve exe= cution.
> =C2=A0 =C2=A0Messages are by default identified by their message ID as= contained
> =C2=A0 =C2=A0in the Message-ID header. =C2=A0The "duplicate"= test evaluates to "true"
> =C2=A0 =C2=A0when the message was seen before and it evaluates to &quo= t;false" when it
>
> =C2=A0 =C2=A0 =C2=A0 was not.
>
> Proposed sentence:
> =C2=A0 =C2=A0 =C2=A0Any possible actions to subsequently received dupl= icate messages would
> be determined by a script in the Sieve filter.

That would truly be an odd thing to say: anyone implementing Sieve ha= s
to quite thoroughly understand the difference between tests and
actions, because both have been implemented for the base spec long
before getting to this extension.

I think the core point that you're trying to make (about which the
duplicates are) might be better done with some other re-wording. =C2=A0I think this might make the whole thing about duplicate messages
clearer:

OLD
=C2=A0 =C2=A0In its basic form, the "duplicate" t= est keeps track of which messages
=C2=A0 =C2=A0were seen before by this test during an earlier Sieve executio= n.
=C2=A0 =C2=A0Messages are by default identified by their message ID as cont= ained
=C2=A0 =C2=A0in the Message-ID header. =C2=A0The "duplicate" test= evaluates to "true"
=C2=A0 =C2=A0when the message was seen before and it evaluates to "fal= se" when it
=C2=A0 =C2=A0was not.
NEW
=C2=A0 =C2=A0The "duplicate" test identifies the message by a &qu= ot;unique ID", and,
=C2=A0 =C2=A0using that unique ID, =C2=A0keeps track of which messages were= seen
=C2=A0 =C2=A0by a "duplicate" test during an earlier Sieve execut= ion. =C2=A0In its basic
=C2=A0 =C2=A0form, the test gets the unique ID from the content of the mess= age's
=C2=A0 =C2=A0Message-ID header. =C2=A0The "duplicate&q= uot; test evaluates to "true" when
=C2=A0 =C2=A0the message was seen before and it evaluates to "false&qu= ot; when it
=C2=A0 =C2=A0was not.
END

WFM and thank you. =C2=A0My w= ords were meant to help the discussion and get edited as needed. =C2=A0You = are more familiar with the terminology used by the group.
=C2=A0= =C2=A0

OLD
=C2=A0 =C2=A0As a side-effect, the "duplicate" test adds the mess= age ID to an
=C2=A0 =C2=A0internal duplicate tracking list once the Sieve execution fini= shes
=C2=A0 =C2=A0successfully. =C2=A0This way, the same test will evaluate to &= quot;true" during
=C2=A0 =C2=A0the next Sieve execution in which that message ID is encounter= ed.
=C2=A0 =C2=A0Note that this side-effect is performed only when the "du= plicate"
=C2=A0 =C2=A0test is actually evaluated. =C2=A0If the "duplicate"= test is nested in a
=C2=A0 =C2=A0control structure or it is not the first item of an "allo= f" or
=C2=A0 =C2=A0"anyof" test list, its evaluation depends on the res= ult of preceding
=C2=A0 =C2=A0tests, which may produce unexpected results.
NEW
=C2=A0 =C2=A0As a side-effect, the "duplicate" test adds the uniq= ue ID to an
=C2=A0 =C2=A0internal duplicate tracking list once the Sieve execution fini= shes
=C2=A0 =C2=A0successfully. =C2=A0The first time a particular unique ID is s= een, the
=C2=A0 =C2=A0message is not a duplicate, and the unique ID is added to the<= br> =C2=A0 =C2=A0tracking list. =C2=A0If a future Sieve execution sees a messag= e whose
=C2=A0 =C2=A0unique ID appears in the tracking list, that test will evaluat= e to
=C2=A0 =C2=A0"true", and that message will be considered a duplic= ate.

=C2=A0 =C2=A0Note that this side-effect is performed only when the "du= plicate"
=C2=A0 =C2=A0test is actually evaluated. =C2=A0If the "duplicate"= test is nested in a
=C2=A0 =C2=A0control structure or it is not the first item of an "allo= f" or
=C2=A0 =C2=A0"anyof" test list, its evaluation depends on the res= ult of preceding
=C2=A0 =C2=A0tests, which may produce unexpected results.
END

WFM, thank you!=C2=A0

If you really do want to say that this is only a test, and that it
takes no actions on its own, please believe me when I say that that's entirely unnecessary, and even silly, in the context of implementing
Sieve. =C2=A0The only thing about that that needs to be said is the side effect the test has, and that's there.
That's = fine, it was in the discussion thread, so I used it. =C2=A0Your wroding wor= k. =C2=A0If Stephan is good with it, we should be okay?=C2=A0
Thanks!
Kathleen

>> So, your call. Maybe worth adding something. But there needn't= be any
>> grand warnings of impending horror.
>
> I agree here and thanks for the clear write up. =C2=A0A warning is all= I was
> looking to see added to cover our bases on pointing out security
> considerations with using this added feature.
>
> Script writers using the duplicate test evaluation should be aware tha= t
> Message-IDs are not necessarily unique either through the fault of ben= ign
> generators or attackers at some point prior to the Sieve filter inject= ing a
> message with the properties used by the duplicate Sieve filter. =C2=A0= As such,
> script writers may opt to be conservative when considering actions tak= en on
> duplicate messages.

I'm OK with that almost as it is. =C2=A0If we're really addre= ssing
Message-IDs I think the last sentence would work better like this:

"Therefore, scripts are well advised to be conservative with respect to actions taken when duplicate messages are identified only by
Message-ID."

1. Scripts are most often created automatically, so "script writers&qu= ot;
would be a little odd. =C2=A0Personifying "scripts" covers cases = of both
human writers and automated generators.

2. It's not the duplicate messages themselves, but how the duplicates are identified. =C2=A0Scripts that nest the "duplicate" test in o= ther
conditional constructs could be fine in this regard, as could scripts
that use the ":uniqueid" tag to build the unique ID from other th= ings
than just the Message-ID.

Stephan, what do you think of all this?

Barry



--

Best regards,
Kathleen
--047d7bfcf74a98645e04fc97d211-- From nobody Tue Jun 24 11:17:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E411A0153 for ; Tue, 24 Jun 2014 11:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.639 X-Spam-Level: * X-Spam-Status: No, score=1.639 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8-c4XWHsbe5 for ; Tue, 24 Jun 2014 11:17:25 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9C21A03FD for ; Tue, 24 Jun 2014 11:17:18 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P9E1DPXWW0005QUD@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 24 Jun 2014 11:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1403633528; bh=2NF0ex6kNgkpxOb3vAmQeYR5bY9xgbf7eIShwCubTmw=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=I5AyMSQrQy0MjWDkDhj0ACQXtIXwrP08l3funOkv8H8h8Vo9iu1x1tXXf5poBeY7J uCdCN/ABCRYHxLB6dB8CxBYCpSKjgksP9GY17itAkSvDF6OX+W+CYCw8cKvs5sI0hd Z7xNsUKVJHvetZK78IdlrN0r7G5eeL6Za1qje6gk= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Tue, 24 Jun 2014 11:12:06 -0700 (PDT) Message-id: <01P9E1DOSSZO0049PU@mauve.mrochek.com> Date: Tue, 24 Jun 2014 08:04:02 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 24 Jun 2014 16:07:04 +0200" References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> <53A98428.106@qti.qualcomm.com> To: Arnt Gulbrandsen Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5YH9mv84II2owqS1MpXErTNOeHw Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 18:17:27 -0000 > On Tuesday, June 24, 2014 3:59:04 PM CEST, Pete Resnick wrote: > > So, your call. Maybe worth adding something. But there needn't > > be any grand warnings of impending horror. > +1 > If you want to DoS someone into not receiving a particular message, then > surely there are easier ways than predicting the message-id exactly. You > could spam five hundred nearby users with a hundred messages each > containing similar text and watch the spam filter learn. Exactly. And you failed to mention having to know that the recipient is using this particular extension in a particular way. Plus this attack is going to leave traces in the server's logs if it is successful, and if those traces are discovered it will be a giant red flag that something naughty was done. (In contrast, the spam training attack you describe is highly unlikely to leave such traces.) So to do this effectively means it would be really nice to be able to modify the server's logs after the fact. Taken together this means the attacker has to have intimate knowledge of - and likely access to - both the sending and receiving environment. It beggers belief that someone who has this won't also have access to some other, far more practial, attack. And this brings us to the more general point: It's vital that security considerations in this sort of document have at least some sense of proportion and context. The IESG really needs to start taking this into account in their comments and discusses. It's often the case that an assortment of fanciful and/or farfetched attacks can be constructed against systems, services, protocols, cryptographic primitives, and so on. (Bruce Schneier calls these things "movie plot attacks", but I don't think this is a useful characterization because it misses all sorts of things that would never fly in a script.) Now, elucidation and promulgation of attacks against cryptographic primitives makes all sorts of sense even when those attacks are wildly impractical. For one thing, these primitives are used in a wide variety of environments and what's impractical in one place may be practical in another. And for another, making it clear that the best attacks known are completely ineffective tends to build, rather than reduce, confidence in this space. But I don't think this is true when it comes to specific services and protocols that slot into specific services in specific ways. I think a lot more selectivity is called for in such cases. First and foremost, these discussions cost us all a lot of time, time which I seriously question is not better spent elsewhere. Second, there's a tendency for WGs to just quietly agree to add text to address the concern that was raised in order to make it go away, which risks falling into "Boy who cried wolf!" territory. Third, when this leads to bulking up, qualifying, or convoluting what used to be clear, consise prose in the service of fanciful security concerns the result is almost always poorer than the original. (And as a person whose email address is on a lot of RFCs, and who often gets contacted when people have questions, I can assure everyone this is NOT an idle concern.) My favorite example of all this - and one in the same space as the present document - is something that happened between RFC 3028 and RFC 5228. This is a long, sad, story, but I want to focus on the sentence in the former RFC that says, "The language is not Turing-complete: it provides no way to write a loop or a function and variables are not provided." Given how often Sieve is extended, this criteria is actually pretty darned important: We do not want someone to modify the language or define an extension that on subsequent inspection provides a means to perform a DOS attack on an MDA that implements it. So designers and implementors really need to think about this issue. Yet this very sentence came under fire during the RFC 5228 revision. Someone on the IESG pointed out that it might be possible to use Sieve redirect/notify/vacation/whatever to loop a message around indefinitely, at which point you could use header tests and modification actions to implement a Turing machine. Ergo, the language is in fact Turing complete! Gotcha! That sentence needs to go! Except of course this would make the email *system* Turing complete, not the Sieve language. And if infinite loops are possible who cares if Sieve is then used to compute a factorial or whatever on top of the looping message? It's the loop that's the problem, not the Turing completeness you can build on top of that. (We also go to a lot of trouble in our specifications to insure that loops can't be created if things are implemented correctly.) But the ensuing discussion of this and several other IMNSHO equally ridiculous points cost us a lot of time, and if memory serves, conference calls were actually required to resolve the matter. Which had the side effect of sapping most of the remaining energy of the working group and driving off a couple of active contributers. But it sure did lead to that sentence being modified. It now says, "The base language was not designed to be Turing-complete: it does not have a loop control structure or functions." Was the change worth it? I think the answer is an emphatic "no", and to be blunt I still find the entire episode to be galling 6 years later. Returning to the matter at hand, I remain to be convinced that this is an issue that's worth addressing. What will convince me is suggested text that describes the issue in accurate and practical fashion. If such text can be constructed I have no problem seeing it added to the document. But more generally, this seems to be yet another case where we're attempting to address the newly perceived shortcoming of the core email service in a document tangential to the specification of that service. (I refrained from commenting on the privacy concern thread, but given the operational reality that all but the most security conscious servers routinely keep detailed logs of the metadata for every message that's sent or received for a considerable period, and we provide exactly zero guidance as to the best practices for handling such logs, I find the need to describe best practcies for handling a bunch of hash values to be a bit overblown.) And even if it were practical to craft such text - I suspect there's far less agreement on what these newly perceived shortcomings are than you might think - putting such material in a place where it's unlikely in the extreme to have mainstream impact is at best a waste of time. Ned From nobody Tue Jun 24 12:07:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF601B2E88 for ; Tue, 24 Jun 2014 12:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBvNNgKZfxPa for ; Tue, 24 Jun 2014 12:07:14 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0998F1B285B for ; Tue, 24 Jun 2014 12:07:13 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id wn1so862681obc.37 for ; Tue, 24 Jun 2014 12:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PByhaRqiKSKnb7p9reRuI2KE+v9HcqcQbZ0ztSasWUI=; b=GM/3HtZV88pn77TL5Qmev1CFyYp6468QTCu3kdc3WLxGD4NEvOM1uv9pkea+3rQ9dX WvP/J0htLBiu4vsRIeTGapTll+knyRYhU+jubWErM6BfJJAEJFGzl2Krx2QzZFOnRbwa WrnyGIUXCyunT8D2Jv7o518N6DGdjvDZra5nw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PByhaRqiKSKnb7p9reRuI2KE+v9HcqcQbZ0ztSasWUI=; b=g1doxxNw3zJS1K04dd7WWREL0uc5Ns6qKsgzBxiegNgss/6RK3yST8YyzDyLPQH3bf BTIiTBivJUrO2D84mBu1Ai+91BawlWQBxU7t8zJP76B0tPJbIgcWmPpANawyHC84xnYo kl23DdCptTb5pJ774lCoeQ3oiTfk8n8x30sncAIFVLVK2dfuyZg91ykzFKpYT5FVOaHQ 9rHUVkTVLBLh71WFx4w6CdkNqG1pYO6/V+qO3ihOHALmvwNf5R4K6XI3ejSe6KlFR3KY OH3ky6fhamZvrLXvHPtXhz93nSrRc6+Fu5lDO1NafEnOWupQoKmaApUKKNzIikgKjpIm Cv8Q== X-Gm-Message-State: ALoCoQlj0HhiGAVe+BpPT6l3s41euBvvg/aEvLIcnbXxI7ynIFI73zUlj6VUaxStovAMCGHTTg9Q MIME-Version: 1.0 X-Received: by 10.60.132.171 with SMTP id ov11mr3013814oeb.46.1403636833494; Tue, 24 Jun 2014 12:07:13 -0700 (PDT) Received: by 10.60.60.100 with HTTP; Tue, 24 Jun 2014 12:07:13 -0700 (PDT) In-Reply-To: <01P9E1DOSSZO0049PU@mauve.mrochek.com> References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> <53A98428.106@qti.qualcomm.com> <01P9E1DOSSZO0049PU@mauve.mrochek.com> Date: Tue, 24 Jun 2014 20:07:13 +0100 Message-ID: From: Dave Cridland To: Ned Freed Content-Type: multipart/alternative; boundary=047d7b4724f8dabeca04fc99aa32 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/k7qeMKQNeMCBnmTZPJvSx6qVOO0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 19:07:17 -0000 --047d7b4724f8dabeca04fc99aa32 Content-Type: text/plain; charset=UTF-8 I've got to agree with this. I was going to craft a sufficiently sarcastic further suggestion of some ridiculously contrived security flaw we had to document to underline this point, but I couldn't actually think of anything more contrived than the potential flaw of someone phishing by pre-overwriting an email that ... I mean, really. Even if it occurred, the end users writing these scripts are not the audience of this RFC, and wouldn't notice the advice. I'm sorry to say that the discussion smacks of security bikeshedding. Yes, it's possible to write Sieve scripts which can expose you to security flaws - much worse cases than this. It's also possible to publish your password on Twitter, yet the HTTPbis RFCs do not, to the best of my knowledge, warn about this in their Security Considerations. This isn't a matter of whether or not that might form good advice - I happen to hold the opinion that publishing your password on Twitter is almost certainly a bad idea - but whether the people likely to do so read RFCs. On 24 June 2014 16:04, Ned Freed wrote: > On Tuesday, June 24, 2014 3:59:04 PM CEST, Pete Resnick wrote: >> > So, your call. Maybe worth adding something. But there needn't >> > be any grand warnings of impending horror. >> > > +1 >> > > If you want to DoS someone into not receiving a particular message, then >> surely there are easier ways than predicting the message-id exactly. You >> could spam five hundred nearby users with a hundred messages each >> containing similar text and watch the spam filter learn. >> > > Exactly. And you failed to mention having to know that the recipient is > using > this particular extension in a particular way. Plus this attack is going to > leave traces in the server's logs if it is successful, and if those traces > are > discovered it will be a giant red flag that something naughty was done. (In > contrast, the spam training attack you describe is highly unlikely to leave > such traces.) So to do this effectively means it would be really nice to be > able to modify the server's logs after the fact. > > Taken together this means the attacker has to have intimate knowledge of - > and > likely access to - both the sending and receiving environment. It beggers > belief that someone who has this won't also have access to some other, far > more > practial, attack. > > And this brings us to the more general point: It's vital that security > considerations in this sort of document have at least some sense of > proportion > and context. The IESG really needs to start taking this into account in > their > comments and discusses. > > It's often the case that an assortment of fanciful and/or farfetched > attacks > can be constructed against systems, services, protocols, cryptographic > primitives, and so on. (Bruce Schneier calls these things "movie plot > attacks", > but I don't think this is a useful characterization because it misses all > sorts > of things that would never fly in a script.) > > Now, elucidation and promulgation of attacks against cryptographic > primitives > makes all sorts of sense even when those attacks are wildly impractical. > For > one thing, these primitives are used in a wide variety of environments and > what's impractical in one place may be practical in another. And for > another, making it clear that the best attacks known are completely > ineffective > tends to build, rather than reduce, confidence in this space. > > But I don't think this is true when it comes to specific services and > protocols > that slot into specific services in specific ways. I think a lot more > selectivity is called for in such cases. > > First and foremost, these discussions cost us all a lot of time, time > which I > seriously question is not better spent elsewhere. > > Second, there's a tendency for WGs to just quietly agree to add text to > address > the concern that was raised in order to make it go away, which risks > falling > into "Boy who cried wolf!" territory. > > Third, when this leads to bulking up, qualifying, or convoluting what used > to > be clear, consise prose in the service of fanciful security concerns the > result > is almost always poorer than the original. (And as a person whose email > address > is on a lot of RFCs, and who often gets contacted when people have > questions, I > can assure everyone this is NOT an idle concern.) > > My favorite example of all this - and one in the same space as the present > document - is something that happened between RFC 3028 and RFC 5228. This > is a > long, sad, story, but I want to focus on the sentence in the former RFC > that > says, "The language is not Turing-complete: it provides no way to write a > loop > or a function and variables are not provided." > > Given how often Sieve is extended, this criteria is actually pretty darned > important: We do not want someone to modify the language or define an > extension > that on subsequent inspection provides a means to perform a DOS attack on > an > MDA that implements it. So designers and implementors really need to think > about this issue. > > Yet this very sentence came under fire during the RFC 5228 revision. > Someone on > the IESG pointed out that it might be possible to use Sieve > redirect/notify/vacation/whatever to loop a message around indefinitely, > at > which point you could use header tests and modification actions to > implement a > Turing machine. Ergo, the language is in fact Turing complete! Gotcha! That > sentence needs to go! > > Except of course this would make the email *system* Turing complete, not > the > Sieve language. And if infinite loops are possible who cares if Sieve is > then > used to compute a factorial or whatever on top of the looping message? > It's the > loop that's the problem, not the Turing completeness you can build on top > of > that. (We also go to a lot of trouble in our specifications to insure that > loops can't be created if things are implemented correctly.) > > But the ensuing discussion of this and several other IMNSHO equally > ridiculous > points cost us a lot of time, and if memory serves, conference calls were > actually required to resolve the matter. Which had the side effect of > sapping > most of the remaining energy of the working group and driving off a couple > of > active contributers. > > But it sure did lead to that sentence being modified. It now says, "The > base > language was not designed to be Turing-complete: it does not have a loop > control structure or functions." > > Was the change worth it? I think the answer is an emphatic "no", and to be > blunt I still find the entire episode to be galling 6 years later. > > Returning to the matter at hand, I remain to be convinced that this is an > issue > that's worth addressing. What will convince me is suggested text that > describes > the issue in accurate and practical fashion. If such text can be > constructed I > have no problem seeing it added to the document. > > But more generally, this seems to be yet another case where we're > attempting to > address the newly perceived shortcoming of the core email service in a > document > tangential to the specification of that service. (I refrained from > commenting > on the privacy concern thread, but given the operational reality that all > but > the most security conscious servers routinely keep detailed logs of the > metadata for every message that's sent or received for a considerable > period, > and we provide exactly zero guidance as to the best practices for handling > such > logs, I find the need to describe best practcies for handling a bunch of > hash > values to be a bit overblown.) > > And even if it were practical to craft such text - I suspect there's far > less > agreement on what these newly perceived shortcomings are than you might > think - putting such material in a place where it's unlikely in the extreme > to have > mainstream impact is at best a waste of time. > > Ned > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --047d7b4724f8dabeca04fc99aa32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've got to agree with this. I was going to craft a su= fficiently sarcastic further suggestion of some ridiculously contrived secu= rity flaw we had to document to underline this point, but I couldn't ac= tually think of anything more contrived than the potential flaw of someone = phishing by pre-overwriting an email that ... I mean, really. Even if it oc= curred, the end users writing these scripts are not the audience of this RF= C, and wouldn't notice the advice.

I'm sorry to say that the discussion smacks of security = bikeshedding.

Yes, it's possible to write Siev= e scripts which can expose you to security flaws - much worse cases than th= is. It's also possible to publish your password on Twitter, yet the HTT= Pbis RFCs do not, to the best of my knowledge, warn about this in their Sec= urity Considerations. This isn't a matter of whether or not that might = form good advice - I happen to hold the opinion that publishing your passwo= rd on Twitter is almost certainly a bad idea - but whether the people likel= y to do so read RFCs.


On 24 J= une 2014 16:04, Ned Freed <ned.freed@mrochek.com> wrote:=
On Tuesday, June 24, 2014 3:59:04 PM CEST, Pete Resnick wrote:
> So, your call. Maybe worth adding something. But there needn't
> be any grand warnings of impending horror.

+1

If you want to DoS someone into not receiving a particular message, then surely there are easier ways than predicting the message-id exactly. You could spam five hundred nearby users with a hundred messages each
containing similar text and watch the spam filter learn.

Exactly. And you failed to mention having to know that the recipient is usi= ng
this particular extension in a particular way. Plus this attack is going to=
leave traces in the server's logs if it is successful, and if those tra= ces are
discovered it will be a giant red flag that something naughty was done. (In=
contrast, the spam training attack you describe is highly unlikely to leave=
such traces.) So to do this effectively means it would be really nice to be=
able to modify the server's logs after the fact.

Taken together this means the attacker has to have intimate knowledge of - = and
likely access to - both the sending and receiving environment. It beggers belief that someone who has this won't also have access to some other, = far more
practial, attack.

And this brings us to the more general point: It's vital that security<= br> considerations in this sort of document have at least some sense of proport= ion
and context. The IESG really needs to start taking this into account in the= ir
comments and discusses.

It's often the case that an assortment of fanciful and/or farfetched at= tacks
can be constructed against systems, services, protocols, cryptographic
primitives, and so on. (Bruce Schneier calls these things "movie plot = attacks",
but I don't think this is a useful characterization because it misses a= ll sorts
of things that would never fly in a script.)

Now, elucidation and promulgation of attacks against cryptographic primitiv= es
makes all sorts of sense even when those attacks are wildly impractical. Fo= r
one thing, these primitives are used in a wide variety of environments and<= br> what's impractical in one place may be practical in another. And for another, making it clear that the best attacks known are completely ineffec= tive
tends to build, rather than reduce, confidence in this space.

But I don't think this is true when it comes to specific services and p= rotocols
that slot into specific services in specific ways. I think a lot =C2=A0more=
selectivity is called for in such cases.

First and foremost, these discussions cost us all a lot of time, time which= I
seriously question is not better spent elsewhere.

Second, there's a tendency for WGs to just quietly agree to add text to= address
the concern that was raised in order to make it go away, which risks fallin= g
into "Boy who cried wolf!" territory.

Third, when this leads to bulking up, qualifying, or convoluting what used = to
be clear, consise prose in the service of fanciful security concerns the re= sult
is almost always poorer than the original. (And as a person whose email add= ress
is on a lot of RFCs, and who often gets contacted when people have question= s, I
can assure everyone this is NOT an idle concern.)

My favorite example of all this - and one in the same space as the present<= br> document - is something that happened between RFC 3028 and RFC 5228. This i= s a
long, sad, story, but I want to focus on the sentence in the former RFC tha= t
says, "The language is not Turing-complete: it provides no way to writ= e a loop
or a function and variables are not provided."

Given how often Sieve is extended, this criteria is actually pretty darned<= br> important: We do not want someone to modify the language or define an exten= sion
that on subsequent inspection provides a means to perform a DOS attack on a= n
MDA that implements it. So designers and implementors really need to think<= br> about this issue.

Yet this very sentence came under fire during the RFC 5228 revision. Someon= e on
the IESG pointed out that it might be possible to use Sieve
redirect/notify/vacation/whatever to loop a message around indefinit= ely, at
which point you could use header tests and modification actions to implemen= t a
Turing machine. Ergo, the language is in fact Turing complete! Gotcha! That=
sentence needs to go!

Except of course this would make the email *system* Turing complete, not th= e
Sieve language. And if infinite loops are possible who cares if Sieve is th= en
used to compute a factorial or whatever on top of the looping message? It&#= 39;s the
loop that's the problem, not the Turing completeness you can build on t= op of
that. (We also go to a lot of trouble in our specifications to insure that<= br> loops can't be created if things are implemented correctly.)

But the ensuing discussion of this and several other IMNSHO equally ridicul= ous
points cost us a lot of time, and if memory serves, conference calls were actually required to resolve the matter. Which had the side effect of sappi= ng
most of the remaining energy of the working group and driving off a couple = of
active contributers.

But it sure did lead to that sentence being modified. It now says, "Th= e base
language was not designed to be Turing-complete: it does not have a loop control structure or functions."

Was the change worth it? I think the answer is an emphatic "no", = and to be
blunt I still find the entire episode to be galling 6 years later.

Returning to the matter at hand, I remain to be convinced that this is an i= ssue
that's worth addressing. What will convince me is suggested text that d= escribes
the issue in accurate and practical fashion. If such text can be constructe= d I
have no problem seeing it added to the document.

But more generally, this seems to be yet another case where we're attem= pting to
address the newly perceived shortcoming of the core email service in a docu= ment
tangential to the specification of that service. (I refrained from commenti= ng
on the privacy concern thread, but given the operational reality that all b= ut
the most security conscious servers routinely keep detailed logs of the
metadata for every message that's sent or received for a considerable p= eriod,
and we provide exactly zero guidance as to the best practices for handling = such
logs, I find the need to describe best practcies for handling a bunch of ha= sh
values to be a bit overblown.)

And even if it were practical to craft such text - I suspect there's fa= r less
agreement on what these newly perceived shortcomings are than you might thi= nk - putting such material in a place where it's unlikely in the extrem= e to have
mainstream impact is at best a waste of time.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned


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

--047d7b4724f8dabeca04fc99aa32-- From nobody Tue Jun 24 13:15:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5760D1B2790; Tue, 24 Jun 2014 13:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbGDSUaioZYa; Tue, 24 Jun 2014 13:14:53 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB5D1B2793; Tue, 24 Jun 2014 13:14:51 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:61741 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WzX6c-0002MW-FG; Tue, 24 Jun 2014 22:14:20 +0200 Message-ID: <53A9DBC1.9000301@rename-it.nl> Date: Tue, 24 Jun 2014 22:12:49 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kathleen Moriarty , Barry Leiba References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> <53A98428.106@qti.qualcomm.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------050901090200020008050502" X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00, HTML_MESSAGE autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vzqgwoFYmi9xpgq5uOLM2Pd4k6U Cc: Apps Discuss , Pete Resnick , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 20:14:56 -0000 This is a multi-part message in MIME format. --------------050901090200020008050502 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Kathleen, Barry, On 6/24/2014 6:55 PM, Kathleen Moriarty wrote: > Barry, > > Thanks for taking the time to discuss this. Response in-line. > > > On Tue, Jun 24, 2014 at 11:54 AM, Barry Leiba > wrote: > > > OLD > In its basic form, the "duplicate" test keeps track of which > messages > were seen before by this test during an earlier Sieve execution. > Messages are by default identified by their message ID as contained > in the Message-ID header. The "duplicate" test evaluates to "true" > when the message was seen before and it evaluates to "false" > when it > was not. > NEW > The "duplicate" test identifies the message by a "unique ID", and, > using that unique ID, keeps track of which messages were seen > by a "duplicate" test during an earlier Sieve execution. In > its basic > form, the test gets the unique ID from the content of the message's > Message-ID header. The "duplicate" test evaluates to "true" when > the message was seen before and it evaluates to "false" when it > was not. > END > > > WFM and thank you. My words were meant to help the discussion and get > edited as needed. You are more familiar with the terminology used by > the group. WFM. Actually, this also resolves an issue I still had with this section about mentioning the concept of a generic "unique ID" earlier. I had no inspiration on how to do this nicely, but I think this will do the trick. > OLD > As a side-effect, the "duplicate" test adds the message ID to an > internal duplicate tracking list once the Sieve execution finishes > successfully. This way, the same test will evaluate to "true" > during > the next Sieve execution in which that message ID is encountered. > Note that this side-effect is performed only when the "duplicate" > test is actually evaluated. If the "duplicate" test is nested in a > control structure or it is not the first item of an "allof" or > "anyof" test list, its evaluation depends on the result of > preceding > tests, which may produce unexpected results. > NEW > As a side-effect, the "duplicate" test adds the unique ID to an > internal duplicate tracking list once the Sieve execution finishes > successfully. The first time a particular unique ID is seen, the > message is not a duplicate, and the unique ID is added to the > tracking list. If a future Sieve execution sees a message whose > unique ID appears in the tracking list, that test will evaluate to > "true", and that message will be considered a duplicate. > > Note that this side-effect is performed only when the "duplicate" > test is actually evaluated. If the "duplicate" test is nested in a > control structure or it is not the first item of an "allof" or > "anyof" test list, its evaluation depends on the result of > preceding > tests, which may produce unexpected results. > END > > > WFM, thank you! OK. This is better. > > If you really do want to say that this is only a test, and that it > takes no actions on its own, please believe me when I say that that's > entirely unnecessary, and even silly, in the context of implementing > Sieve. The only thing about that that needs to be said is the side > effect the test has, and that's there. > > That's fine, it was in the discussion thread, so I used it. Your > wroding work. If Stephan is good with it, we should be okay? Yes. > > Script writers using the duplicate test evaluation should be > aware that > > Message-IDs are not necessarily unique either through the fault > of benign > > generators or attackers at some point prior to the Sieve filter > injecting a > > message with the properties used by the duplicate Sieve filter. > As such, > > script writers may opt to be conservative when considering > actions taken on > > duplicate messages. > > I'm OK with that almost as it is. If we're really addressing > Message-IDs I think the last sentence would work better like this: > > "Therefore, scripts are well advised to be conservative with respect > to actions taken when duplicate messages are identified only by > Message-ID." > I can agree with this text with Barry's modification, but where do you want to put this? At the end of Section 3 or in the Security Considerations? If it is best put in Section 3 I should merge it somehow with the last paragraph. > 1. Scripts are most often created automatically, so "script writers" > would be a little odd. Personifying "scripts" covers cases of both > human writers and automated generators. > I checked for other occasions in the specification where this may have occurred, but so far I don't seem to have referred to the script authors. So, doing it like this should be OK and I don't have to change things elsewhere. > 2. It's not the duplicate messages themselves, but how the duplicates > are identified. Scripts that nest the "duplicate" test in other > conditional constructs could be fine in this regard, as could scripts > that use the ":uniqueid" tag to build the unique ID from other things > than just the Message-ID. > What does this remark refer to? > Stephan, what do you think of all this? > See above. Regards, Stephan. --------------050901090200020008050502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Kathleen, Barry,

On 6/24/2014 6:55 PM, Kathleen Moriarty wrote:
Barry,

Thanks for taking the time to discuss this.  Response in-line.


On Tue, Jun 24, 2014 at 11:54 AM, Barry Leiba <barryleiba@computer.org> wrote:

OLD
   In its basic form, the "duplicate" test keeps track of which messages
   were seen before by this test during an earlier Sieve execution.
   Messages are by default identified by their message ID as contained
   in the Message-ID header.  The "duplicate" test evaluates to "true"
   when the message was seen before and it evaluates to "false" when it
   was not.
NEW
   The "duplicate" test identifies the message by a "unique ID", and,
   using that unique ID,  keeps track of which messages were seen
   by a "duplicate" test during an earlier Sieve execution.  In its basic
   form, the test gets the unique ID from the content of the message's
   Message-ID header.  The "duplicate" test evaluates to "true" when
   the message was seen before and it evaluates to "false" when it
   was not.
END

WFM and thank you.  My words were meant to help the discussion and get edited as needed.  You are more familiar with the terminology used by the group.

WFM. Actually, this also resolves an issue I still had with this section about mentioning the concept of a generic "unique ID" earlier. I had no inspiration on how to do this nicely, but I think this will do the trick.

OLD
   As a side-effect, the "duplicate" test adds the message ID to an
   internal duplicate tracking list once the Sieve execution finishes
   successfully.  This way, the same test will evaluate to "true" during
   the next Sieve execution in which that message ID is encountered.
   Note that this side-effect is performed only when the "duplicate"
   test is actually evaluated.  If the "duplicate" test is nested in a
   control structure or it is not the first item of an "allof" or
   "anyof" test list, its evaluation depends on the result of preceding
   tests, which may produce unexpected results.
NEW
   As a side-effect, the "duplicate" test adds the unique ID to an
   internal duplicate tracking list once the Sieve execution finishes
   successfully.  The first time a particular unique ID is seen, the
   message is not a duplicate, and the unique ID is added to the
   tracking list.  If a future Sieve execution sees a message whose
   unique ID appears in the tracking list, that test will evaluate to
   "true", and that message will be considered a duplicate.

   Note that this side-effect is performed only when the "duplicate"
   test is actually evaluated.  If the "duplicate" test is nested in a
   control structure or it is not the first item of an "allof" or
   "anyof" test list, its evaluation depends on the result of preceding
   tests, which may produce unexpected results.
END

WFM, thank you!

OK. This is better.


If you really do want to say that this is only a test, and that it
takes no actions on its own, please believe me when I say that that's
entirely unnecessary, and even silly, in the context of implementing
Sieve.  The only thing about that that needs to be said is the side
effect the test has, and that's there.
That's fine, it was in the discussion thread, so I used it.  Your wroding work.  If Stephan is good with it, we should be okay?

Yes.

> Script writers using the duplicate test evaluation should be aware that
> Message-IDs are not necessarily unique either through the fault of benign
> generators or attackers at some point prior to the Sieve filter injecting a
> message with the properties used by the duplicate Sieve filter.  As such,
> script writers may opt to be conservative when considering actions taken on
> duplicate messages.

I'm OK with that almost as it is.  If we're really addressing
Message-IDs I think the last sentence would work better like this:

"Therefore, scripts are well advised to be conservative with respect
to actions taken when duplicate messages are identified only by
Message-ID."

I can agree with this text with Barry's modification, but where do you want to put this? At the end of Section 3 or in the Security Considerations? If it is best put in Section 3 I should merge it somehow with the last paragraph.

1. Scripts are most often created automatically, so "script writers"
would be a little odd.  Personifying "scripts" covers cases of both
human writers and automated generators.

I checked for other occasions in the specification where this may have occurred, but so far I don't seem to have referred to the script authors.  So, doing it like this should be OK and I don't have to change things elsewhere.

2. It's not the duplicate messages themselves, but how the duplicates
are identified.  Scripts that nest the "duplicate" test in other
conditional constructs could be fine in this regard, as could scripts
that use the ":uniqueid" tag to build the unique ID from other things
than just the Message-ID.

What does this remark refer to?

Stephan, what do you think of all this?

See above.

Regards,

Stephan.

--------------050901090200020008050502-- From nobody Tue Jun 24 13:38:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87A91B2837; Tue, 24 Jun 2014 13:37:58 -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=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjyM4yxMqTTG; Tue, 24 Jun 2014 13:37:57 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B5C1B27BB; Tue, 24 Jun 2014 13:37:55 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:62230 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WzXTB-0002q9-7I; Tue, 24 Jun 2014 22:37:39 +0200 Message-ID: <53A9E138.1010406@rename-it.nl> Date: Tue, 24 Jun 2014 22:36:08 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Barry Leiba , Alissa Cooper References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Dqg9bbI3nR-8fTD6g_txEVmysHI Cc: "appsawg-chairs@tools.ietf.org" , "ned+ietf@mrochek.com" , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , Apps Discuss , The IESG Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 20:37:58 -0000 Hi Barry, Alissa, On 6/24/2014 12:02 AM, Barry Leiba wrote: >>> The list of unique IDs used for duplicate tracking can include >>> privacy-sensitive information, such as Message-ID values, content of >>> subject lines, and content extracted from message bodies. It is >>> important to protect that information, either by obscuring it through >>> hashing (see the note at the end of Section 3.2) or by storing it with >>> a level of access control equivalent to that of the messages >>> themselves. >> I think the last sentence above should be at least a SHOULD. Otherwise the >> above text is good. > I don't really care about 2119 language in that, and I certainly have > no problem with sticking in a SHOULD. Works for me too. Summarizing, I intend to add the following text to the Security Considerations: The list of unique IDs used for duplicate tracking can include privacy-sensitive information, such as Message-ID values, content of subject lines, and content extracted from message bodies. Implementations SHOULD protect that information, either by obscuring it through hashing (see the note at the end of Section 3.2) or by storing it with a level of access control equivalent to that of the messages themselves. >> But, there is another privacy aspect that is not addressed by the text >> above and deserves some mention. Suppose I am a law enforcement official >> or a private investigator in a divorce lawsuit or some such, and I get a >> hold of a list of message IDs from Email Provider X or passive traffic >> analysis or wherever. If I go to Email Provider Y and ask whether Jane Doe >> has received mail containing any of those IDs, the fact that Email >> Provider Y hashed the IDs doesn’t prevent it from producing that >> information. Meanwhile, if Jane downloaded or deleted any of those >> messages, she might think that he email provider no longer has a record of >> them, but that’s not the case. > If the hashes are salted, it wouldn't be possible to just compare > Message-IDs. It's probably worth suggesting salting the hashes (with > something unique to each user, such as the username). > > On the other hand, if someone had a raw Message-ID and a court order > that said, "Salt and hash this Message-ID and see if it's in Jane > Doe's duplicate list," then, yes, that would work. And, yes, deleting > messages won't remove them from the duplicate list -- we wouldn't want > it to, because we'd still want a duplicate that arrived after the > deletion to still be considered a duplicate. Only aging out will > remove an entry. > > It's certainly easy to add a paragraph about this angle. Stephan, you > want to craft something? I don't think there's any remedy you can put > in, but just calling out the issue is worth a few words. I can add the following sentence to the paragraph above: However, these measures will not prevent an entity that has access to the duplicate tracking list from querying whether messages with certain Message-ID values were received. As this operation is the essence of the "duplicate" test, this cannot be prevented. Hmm, I am not entirely happy with this wording. Feel free to provide suggestions. > It's notable, though, that server logs will often have this > information anyway, and probably would expose plaintext Message-IDs > for a much longer period than this will. I think this would really > only be an issue with an email server that intentionally burns its > logs with the intent of limiting traceability, and that needs to be > made aware that this re-exposes things (including a close estimate of > the timestamp when the message was delivered, by looking at the > aging-out time on the list entry). Not sure whether I should mention this as well. Let's keep things concise. Regards, Stephan. From nobody Tue Jun 24 14:14:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F91C1B2919; Tue, 24 Jun 2014 14:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.443 X-Spam-Level: * X-Spam-Status: No, score=1.443 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JX2Y5MHLOYYI; Tue, 24 Jun 2014 14:14:36 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5541B2A51; Tue, 24 Jun 2014 14:03:26 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:62834 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WzXrw-0003PG-6F; Tue, 24 Jun 2014 23:03:13 +0200 Message-ID: <53A9E736.9080709@rename-it.nl> Date: Tue, 24 Jun 2014 23:01:42 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alissa Cooper , The IESG References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JqBqPbV8-Ihf4wcEJqEPsW6XgdM Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 21:14:38 -0000 Hi Alissa, On 6/23/2014 4:29 PM, Alissa Cooper wrote: > On 6/20/14, 12:51 AM, "Stephan Bosch" wrote: >> On 6/20/2014 2:40 AM, Alissa Cooper wrote: >>> o Section 3.3: >>> "A default expiration time of around 7 days is usually >>> appropriate. ... If that limit is exceeded by the ":seconds" >>> argument, >>> the >>> maximum value MUST silently be substituted" >>> >>> The suggested default seems really long, especially for the example use >>> case described in Section 1. On the other hand, it seems odd that the >>> user's choice would be overriden by the preset maximum. This would make >>> more sense to me if the default expiration were shorter and the user >>> could override it with a longer :seconds argument if he wanted. What is >>> the rationale for doing it the opposite way? >> The default was chosen in Sieve mailing list discussions, but in essence >> it is pretty arbitrary. It is mainly based on the period in which a >> series of duplicate messages may arrive with a margin of a few more days. > I find it a bit surprising that receipt of a duplicate multiple days after > the first message is received is that commonplace on today’s Internet. Is > there any data around to back that up? Arnt mentioned one example. I am no expert on this; I couldn't tell you. If I remember correctly, Alexey Melnikov proposed the default of seven days. The "vacation" extension specification [RFC5230] mentions retention periods with similar magnitude (for ":days" argument). >> The rationale for a maximum is to prevent users from having the ability >> to create duplicate tracking list entries that linger indefinitely. > Well, “indefinitely” wouldn’t necessarily be possible, because if the user > specifies nothing then it’s the default, and otherwise he could be > required to specify _something_, correct? True, but that something could be e.g. 2**32, which is pretty close to indefinitely. > But I can appreciate that you don’t want to impose a long, arbitrary retention requirement. Is the idea that the maximum would be surfaced to the user if he’s using some GUI to > create a duplicate filter? My implementation can provide a warning when this situation occurs. In the case of a GUI this would be returned through ManageSieve with the WARNINGS response code; http://tools.ietf.org/html/rfc5804#section-1.3 . I am not sure whether other implementations would do this or whether GUIs actually show these warnings, but at least there is a specification of this facility. I could add text that implementations SHOULD issue a warning when a maximum ":seconds" value is substituted over what the user specified. > It just seems odd that the user’s choice would > be silently overridden and he wouldn’t know until duplicate messages start > showing up sooner than expected. Keep in mind that much of this is modeled after "vacation" [RFC5230] and "vacation-seconds" [RFC6131]. In those cases the minimum and maximum are also substituted silently. Regards, Stephan. From nobody Tue Jun 24 17:56:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA781B2A01; Tue, 24 Jun 2014 17:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.047 X-Spam-Level: X-Spam-Status: No, score=0.047 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9a_Ha0rQKvH; Tue, 24 Jun 2014 17:56:05 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 315271B291A; Tue, 24 Jun 2014 17:56:05 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P9EFB11Q740061K2@mauve.mrochek.com>; Tue, 24 Jun 2014 17:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1403657450; bh=yNbmoYSGXC9U1n0CMqAzmd6baevKS3Sp8zuYBlsAHIU=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=qBP67Zz4PqaU2Lh+ayh6jowf2hW7UFQ3Rs+A2liVgzzp2zcRdBZdXdVotUU00AWMc 812T+wfmU/W5CGvqSiHtgKOAp5x5Pfg694TGnLIDzVnSiF6dYs5FA2pXMekXByh5Yb xXzgY4VMMzmnFgw9Nz8LEHKfzfTOBscQyj1F/2nI= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Tue, 24 Jun 2014 17:50:46 -0700 (PDT) Message-id: <01P9EFAYDH680049PU@mauve.mrochek.com> Date: Tue, 24 Jun 2014 15:32:18 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 24 Jun 2014 23:01:42 +0200" <53A9E736.9080709@rename-it.nl> References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A9E736.9080709@rename-it.nl> To: Stephan Bosch Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7SOdDmDISflQI0xdeGPPb0Lt6wE Cc: apps-discuss@ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, appsawg-chairs@tools.ietf.org, The IESG , ned+ietf@mrochek.com Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 00:56:08 -0000 > >>> The suggested default seems really long, especially for the example use > >>> case described in Section 1. Am I missing something? The first example is a straightfoward one where message-id duplicates are filed to a special "Trash/Duplicate" folder. In such a case basically the longer the retention interval the better things work. Given the way message-ids are typically generated by most clients it's not like the longer interval increases the liklihood of a duplicate occurring. If the longer retention period has a downside for the user I am not seeing it. So whether or not a 7 day retention is problematic really depends on the server environment. If you're running a server for relatively small number of users, i.e.., a small to medium sized enterprises, schools, small to medium sized ISPs, etc. given the high liklihood that not everyone will opt to use this, and given the power and capabilities of modern server hardware, I seriously doubt that a 7 day default will cause any problems. An single instance of memcached can handle an awful lot of entries of this type. Of course a large ISP/MSP with users numbering in the many millions is going to face a very different set of tradeoffs. But I have a sneaking suspicion that in the unfortunately unlikely event that such a concern would bother to offer this capability, they are capable of picking appropriate defaults, which the document certainly allows. And more generaly, it's not the the necessary expertise to size database back ends of various sorts is hard to come by. > >>> On the other hand, it seems odd that the > >>> user's choice would be overriden by the preset maximum. I don't know if anyone else has pointed this out, but that's not quite how it works. The user's choice is only overridden if it exceeds the maximum. And reason for that is simple: All servers need to prevent users from creating entries that last for absurdly long periods, and in cases where the number of retained entries is a potential problem, to prevent users from overloading the system. > >>> This would make > >>> more sense to me if the default expiration were shorter and the user > >>> could override it with a longer :seconds argument if he wanted. What is > >>> the rationale for doing it the opposite way? Again, that's not how it works. There are two values involved: A default and a maximum. The default is what's used when no value is specified, whereas is, well, the maximum. And the draft I don't really think the text is unclear about the distinction between defaults and maximums, but if it is then it definitely needs to be changed. And FWIW, my implementation of this also implements a minimum that is silently substituted if a user goes under the value. My rationale for having this is so something sensible is done when users screw up and enter absurdly low values, then complain when their problem isn't solved. But I don't think this is sufficiently useful that it belongs in the standard. > >> The default was chosen in Sieve mailing list discussions, but in essence > >> it is pretty arbitrary. It is mainly based on the period in which a > >> series of duplicate messages may arrive with a margin of a few more days. > > I find it a bit surprising that receipt of a duplicate multiple days after > > the first message is received is that commonplace on today’s Internet. Is > > there any data around to back that up? > Arnt mentioned one example. I am no expert on this; I couldn't tell you. > If I remember correctly, Alexey Melnikov proposed the default of seven days. It's fairly uncommon for there to be significant delays, but that is largely irrelevant. The point it is does happen, and when it does and duplicates get through, users who have done to the trouble of setting this up will see them and complain. And since email is often seen as a cost, not a value-added service, trading off a bit more hardware - even if it comes to that - for fewer support calls is not a bad idea. > The "vacation" extension specification [RFC5230] mentions retention > periods with similar magnitude (for ":days" argument). And for similar reasons: Getting multiple vacation replies is fairly irritating. > >> The rationale for a maximum is to prevent users from having the ability > >> to create duplicate tracking list entries that linger indefinitely. > > Well, “indefinitely” wouldn’t necessarily be possible, because if the user > > specifies nothing then it’s the default, and otherwise he could be > > required to specify _something_, correct? > True, but that something could be e.g. 2**32, which is pretty close to > indefinitely. I confess I don't understand this at all. > > But I can appreciate that you don’t want to impose a long, arbitrary > > retention requirement. Is the idea that the maximum would be surfaced > > to the user if he’s using some GUI create a duplicate filter? > My implementation can provide a warning when this situation occurs. In > the case of a GUI this would be returned through ManageSieve with the > WARNINGS response code; http://tools.ietf.org/html/rfc5804#section-1.3 . > I am not sure whether other implementations would do this or whether > GUIs actually show these warnings, but at least there is a specification > of this facility. That's not a bad idea, although I note that nothing says the maximum that's in effect when the sieve is created is going to be the same as the one in effect when the sieve is executed. > I could add text that implementations SHOULD issue a warning when a > maximum ":seconds" value is substituted over what the user specified. I don't have a problem with that as long as it's specific to managesieve. There's really no straightforward viable path for reporting warnings at sieve execution time. (The closest thing we have to that would be the addition of a header, but the odds of anyone seeing it are so low there's really no point.) And I don't think this extension is the right place to get into the issue of hawo to provide warnings from sieve at executiion OTOH, I think we may have crossed the line into overdesign here. Ned From nobody Tue Jun 24 19:13:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776721B2A3B; Tue, 24 Jun 2014 19:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VecbQn7iKlh; Tue, 24 Jun 2014 19:13:46 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id E6D1C1A854D; Tue, 24 Jun 2014 19:13:45 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P9EI1CFGK0005U2R@mauve.mrochek.com>; Tue, 24 Jun 2014 19:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1403662112; bh=OqJbQG8QvuLXc/kfJfVKvMSmeB1F0BVzDzb07D2lYR8=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=eF0Hmo/hvXrtuwlVTRi4vNTZ7M65quX2fdfbvevRIEO20BBgSdvWzBh60oeKzUbIA 3CDWihjCzzKVRM8YwnbrXCreX4JIpkAwXBMFM1wMBJRYV3bNlmgyCZwcEcjAnrseFU sv9lWNfqesughfyxfBCv/T1znMvX6zBw8WEvhuuY= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Tue, 24 Jun 2014 19:08:29 -0700 (PDT) Message-id: <01P9EI1ACTHC0049PU@mauve.mrochek.com> Date: Tue, 24 Jun 2014 19:02:37 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 24 Jun 2014 11:54:18 -0400" References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> <53A98428.106@qti.qualcomm.com> To: Barry Leiba Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dZXCJBZZOFBIOiPbBbytLcsLEUY Cc: Apps Discuss , Stephan Bosch , Pete Resnick , "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , Kathleen Moriarty , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 02:13:48 -0000 > > In Section 3, how about adding a sentence to the end of this paragraph > > (paragraph, then proposed sentence): > > > > In its basic form, the "duplicate" test keeps track of which messages > > were seen before by this test during an earlier Sieve execution. > > Messages are by default identified by their message ID as contained > > in the Message-ID header. The "duplicate" test evaluates to "true" > > when the message was seen before and it evaluates to "false" when it > > > > was not. > > > > Proposed sentence: > > Any possible actions to subsequently received duplicate messages would > > be determined by a script in the Sieve filter. > That would truly be an odd thing to say: anyone implementing Sieve has > to quite thoroughly understand the difference between tests and > actions, because both have been implemented for the base spec long > before getting to this extension. > I think the core point that you're trying to make (about which the > duplicates are) might be better done with some other re-wording. I > think this might make the whole thing about duplicate messages > clearer: > OLD > In its basic form, the "duplicate" test keeps track of which messages > were seen before by this test during an earlier Sieve execution. > Messages are by default identified by their message ID as contained > in the Message-ID header. The "duplicate" test evaluates to "true" > when the message was seen before and it evaluates to "false" when it > was not. > NEW > The "duplicate" test identifies the message by a "unique ID", and, > using that unique ID, keeps track of which messages were seen > by a "duplicate" test during an earlier Sieve execution. In its basic > form, the test gets the unique ID from the content of the message's > Message-ID header. The "duplicate" test evaluates to "true" when > the message was seen before and it evaluates to "false" when it > was not. > END > OLD > As a side-effect, the "duplicate" test adds the message ID to an > internal duplicate tracking list once the Sieve execution finishes > successfully. This way, the same test will evaluate to "true" during > the next Sieve execution in which that message ID is encountered. > Note that this side-effect is performed only when the "duplicate" > test is actually evaluated. If the "duplicate" test is nested in a > control structure or it is not the first item of an "allof" or > "anyof" test list, its evaluation depends on the result of preceding > tests, which may produce unexpected results. > NEW > As a side-effect, the "duplicate" test adds the unique ID to an > internal duplicate tracking list once the Sieve execution finishes > successfully. The first time a particular unique ID is seen, the > message is not a duplicate, and the unique ID is added to the > tracking list. If a future Sieve execution sees a message whose > unique ID appears in the tracking list, that test will evaluate to > "true", and that message will be considered a duplicate. > Note that this side-effect is performed only when the "duplicate" > test is actually evaluated. If the "duplicate" test is nested in a > control structure or it is not the first item of an "allof" or > "anyof" test list, its evaluation depends on the result of preceding > tests, which may produce unexpected results. > END I'm ambivalent about the first change, but the second one is definitely an improvment. The heritage of where this started as purely a message-id thing has proven difficult to eradicate. > If you really do want to say that this is only a test, and that it > takes no actions on its own, please believe me when I say that that's > entirely unnecessary, and even silly, in the context of implementing > Sieve. The only thing about that that needs to be said is the side > effect the test has, and that's there. +1 > >> So, your call. Maybe worth adding something. But there needn't be any > >> grand warnings of impending horror. > > > > I agree here and thanks for the clear write up. A warning is all I was > > looking to see added to cover our bases on pointing out security > > considerations with using this added feature. > > > > Script writers using the duplicate test evaluation should be aware that > > Message-IDs are not necessarily unique either through the fault of benign > > generators or attackers at some point prior to the Sieve filter injecting a > > message with the properties used by the duplicate Sieve filter. As such, > > script writers may opt to be conservative when considering actions taken on > > duplicate messages. > I'm OK with that almost as it is. If we're really addressing > Message-IDs I think the last sentence would work better like this: > "Therefore, scripts are well advised to be conservative with respect > to actions taken when duplicate messages are identified only by > Message-ID." > 1. Scripts are most often created automatically, so "script writers" > would be a little odd. Personifying "scripts" covers cases of both > human writers and automated generators. > 2. It's not the duplicate messages themselves, but how the duplicates > are identified. Scripts that nest the "duplicate" test in other > conditional constructs could be fine in this regard, as could scripts > that use the ":uniqueid" tag to build the unique ID from other things > than just the Message-ID. > Stephan, what do you think of all this? I think all this is fine, although I doubt it's going to reach an audience for which it matters. Ned From nobody Tue Jun 24 23:30:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144D81B2AEC; Tue, 24 Jun 2014 23:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0khK1i9fOP8S; Tue, 24 Jun 2014 23:30:02 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ECC71B2AEB; Tue, 24 Jun 2014 23:30:01 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id gf5so399316lab.36 for ; Tue, 24 Jun 2014 23:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iXB7jKzlMGOWWp3BFM/rydhb2SSNIVE/Sah42FNSgIY=; b=vpbjA227s11I2XAB8/VrzBnfv0YYZOiMaq3PB+bC+8b3XGDGi0NOVOcEFOXYyu+yqK 2zXJA4RiaviCSbeck8v7h1Thk50YY1d5g80Yq7idA8gW5jNz6QFaOXBzrq6jixfjSNCG ikYcXO1YztXSrKrcY2i3E5Af00ujf1zG8AITaPRC+qkKKb4DcZ0c/N0om8vHA5WCn4H0 4+96p5uIaThV6DS/kn1RQllXwxco+oLBTXKVEF175rthqvLSn22onz16r6eedTRm3KlH gk22WCsKpowPibrmiJzsMsz4uZPZu1iglZ19yKilK8JEEwdu55HN56V8MTGO6spd1DSG tjsQ== MIME-Version: 1.0 X-Received: by 10.112.146.10 with SMTP id sy10mr461755lbb.64.1403677799718; Tue, 24 Jun 2014 23:29:59 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Tue, 24 Jun 2014 23:29:59 -0700 (PDT) In-Reply-To: <53A9DBC1.9000301@rename-it.nl> References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> <53A98428.106@qti.qualcomm.com> <53A9DBC1.9000301@rename-it.nl> Date: Wed, 25 Jun 2014 02:29:59 -0400 X-Google-Sender-Auth: t_okbLgW_tG6rD6UIdd1yPcLcLw Message-ID: From: Barry Leiba To: Stephan Bosch Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/UH3qj98LhQDWG_-hag86Kdy40F0 Cc: Apps Discuss , "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , Kathleen Moriarty , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 06:30:03 -0000 >> > Script writers using the duplicate test evaluation should be aware that >> > Message-IDs are not necessarily unique either through the fault of >> > benign >> > generators or attackers at some point prior to the Sieve filter >> > injecting a >> > message with the properties used by the duplicate Sieve filter. As >> > such, >> > script writers may opt to be conservative when considering actions taken >> > on >> > duplicate messages. >> >> I'm OK with that almost as it is. If we're really addressing >> Message-IDs I think the last sentence would work better like this: >> >> "Therefore, scripts are well advised to be conservative with respect >> to actions taken when duplicate messages are identified only by >> Message-ID." > > I can agree with this text with Barry's modification, but where do you want > to put this? At the end of Section 3 or in the Security Considerations? If > it is best put in Section 3 I should merge it somehow with the last > paragraph. I think it's best to stick it into the Security Considerations. >> 2. It's not the duplicate messages themselves, but how the duplicates >> are identified. Scripts that nest the "duplicate" test in other >> conditional constructs could be fine in this regard, as could scripts >> that use the ":uniqueid" tag to build the unique ID from other things >> than just the Message-ID. > > What does this remark refer to? That was just explaining my edits to Kathleen; no action for you there. Barry From nobody Tue Jun 24 23:38:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30081B2A89; Tue, 24 Jun 2014 23:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6SzaFPOgoRx; Tue, 24 Jun 2014 23:38:41 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5A61B2AE0; Tue, 24 Jun 2014 23:38:39 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:64058 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Wzgqe-0005GI-IP; Wed, 25 Jun 2014 08:38:30 +0200 Message-ID: <53AA6DFF.9070008@rename-it.nl> Date: Wed, 25 Jun 2014 08:36:47 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Barry Leiba References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> <53A98428.106@qti.qualcomm.com> <53A9DBC1.9000301@rename-it.nl> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/H6x0SioYZFzxtjszzTCejhZH98M Cc: Apps Discuss , "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , Kathleen Moriarty , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 06:38:43 -0000 Hi Barry, On 6/25/2014 8:29 AM, Barry Leiba wrote: >>>> Script writers using the duplicate test evaluation should be aware that >>>> Message-IDs are not necessarily unique either through the fault of >>>> benign >>>> generators or attackers at some point prior to the Sieve filter >>>> injecting a >>>> message with the properties used by the duplicate Sieve filter. As >>>> such, >>>> script writers may opt to be conservative when considering actions taken >>>> on >>>> duplicate messages. >>> I'm OK with that almost as it is. If we're really addressing >>> Message-IDs I think the last sentence would work better like this: >>> >>> "Therefore, scripts are well advised to be conservative with respect >>> to actions taken when duplicate messages are identified only by >>> Message-ID." >> I can agree with this text with Barry's modification, but where do you want >> to put this? At the end of Section 3 or in the Security Considerations? If >> it is best put in Section 3 I should merge it somehow with the last >> paragraph. > I think it's best to stick it into the Security Considerations. OK, will do. Regards, Stephan. From nobody Tue Jun 24 23:55:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C701B2AEB; Tue, 24 Jun 2014 23:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hULd-fU9qBKp; Tue, 24 Jun 2014 23:55:46 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50A191B2AED; Tue, 24 Jun 2014 23:55:45 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:64422 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Wzh7I-0005aR-CY; Wed, 25 Jun 2014 08:55:42 +0200 Message-ID: <53AA7206.7040905@rename-it.nl> Date: Wed, 25 Jun 2014 08:53:58 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ned Freed References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A9E736.9080709@rename-it.nl> <01P9EFAYDH680049PU@mauve.mrochek.com> In-Reply-To: <01P9EFAYDH680049PU@mauve.mrochek.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/rika0mRYyD55fHvG00mmxdmVv74 Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 06:55:49 -0000 Hi Ned, On 6/25/2014 12:32 AM, Ned Freed wrote: >>>>> The suggested default seems really long, especially for the example use >>>>> case described in Section 1. > Am I missing something? The first example is a straightfoward one where > message-id duplicates are filed to a special "Trash/Duplicate" folder. In such > a case basically the longer the retention interval the better things work. > Given the way message-ids are typically generated by most clients it's not like > the longer interval increases the liklihood of a duplicate occurring. > > If the longer retention period has a downside for the user I am not seeing it. Alissa mentions this in the context of privacy concerns. A longer retention period means that potentially privacy-sensitive data would be kept longer. With that point of view, longer retention periods are undesirable. >>>> The rationale for a maximum is to prevent users from having the ability >>>> to create duplicate tracking list entries that linger indefinitely. >>> Well, “indefinitely” wouldn’t necessarily be possible, because if the user >>> specifies nothing then it’s the default, and otherwise he could be >>> required to specify _something_, correct? >>> >> True, but that something could be e.g. 2**32, which is pretty close to >> indefinitely. > I confess I don't understand this at all. Alissa means that a truly infinite retention time is not possible; either a default value is used or the user needs to specify a concrete value using the ":seconds" argument. However, the ":seconds" argument can take very large values. If this value is parsed as a 32 bit unsigned integer, it could be set to 2**32-1, which is a century and a few decades. I would call that close enough to infinity in this case. That is why it is wise to enforce a maximum. >> But I can appreciate that you don’t want to impose a long, arbitrary >> retention requirement. Is the idea that the maximum would be surfaced >> to the user if he’s using some GUI create a duplicate filter? >> My implementation can provide a warning when this situation occurs. In >> the case of a GUI this would be returned through ManageSieve with the >> WARNINGS response code; http://tools.ietf.org/html/rfc5804#section-1.3 . >> I am not sure whether other implementations would do this or whether >> GUIs actually show these warnings, but at least there is a specification >> of this facility. > That's not a bad idea, although I note that nothing says the maximum that's > in effect when the sieve is created is going to be the same as the one > in effect when the sieve is executed. True. >> I could add text that implementations SHOULD issue a warning when a >> maximum ":seconds" value is substituted over what the user specified. > I don't have a problem with that as long as it's specific to managesieve. > There's really no straightforward viable path for reporting warnings at sieve > execution time. (The closest thing we have to that would be the addition of a > header, but the odds of anyone seeing it are so low there's really no point.) I have a run-time per-user log file for that, but currently users cannot actually read this. > And I don't think this extension is the right place to get into the issue of > hawo to provide warnings from sieve at executiion. I agree. Regards, Stephan. From nobody Wed Jun 25 01:28:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C801A1B2B0C; Wed, 25 Jun 2014 01:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceEif1Jj1C_g; Wed, 25 Jun 2014 01:28:39 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id C5A031B2AF6; Wed, 25 Jun 2014 01:28:38 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P9EV435YN4000FNA@mauve.mrochek.com>; Wed, 25 Jun 2014 01:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1403684601; bh=FS1Vy7MCEXmrT2PWMRzXsSxeEh+4ZH803VMvUiKBcLs=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=FNiExbw/No00ciM3c15wMNpLy6hpnK8bKkv43lI8eiOxIG4vWxHgYgy3aRdGrioXg 2Stz0c1aucOu4dFUwwcG6lUc1b7WOc8tRTI/53yWxWvFJRujH682a64cWK9O509yGa VRk/rI5Bpt5gvVusctLnuEio4bRSYJgtiiV79fDM= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=UTF-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Wed, 25 Jun 2014 01:23:18 -0700 (PDT) Message-id: <01P9EV40R78G0049PU@mauve.mrochek.com> Date: Wed, 25 Jun 2014 00:18:46 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 25 Jun 2014 08:53:58 +0200" <53AA7206.7040905@rename-it.nl> References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A9E736.9080709@rename-it.nl> <01P9EFAYDH680049PU@mauve.mrochek.com> <53AA7206.7040905@rename-it.nl> To: Stephan Bosch Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hXjqQGUBCwg0hn5hHTX6mfPOBF8 Cc: Ned Freed , apps-discuss@ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, appsawg-chairs@tools.ietf.org, The IESG , ned+ietf@mrochek.com Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 08:28:40 -0000 > Hi Ned, > On 6/25/2014 12:32 AM, Ned Freed wrote: > >>>>> The suggested default seems really long, especially for the example use > >>>>> case described in Section 1. > > Am I missing something? The first example is a straightfoward one where > > message-id duplicates are filed to a special "Trash/Duplicate" folder. In such > > a case basically the longer the retention interval the better things work. > > Given the way message-ids are typically generated by most clients it's not like > > the longer interval increases the liklihood of a duplicate occurring. > > > > If the longer retention period has a downside for the user I am not seeing it. > Alissa mentions this in the context of privacy concerns. A longer > retention period means that potentially privacy-sensitive data would be > kept longer. With that point of view, longer retention periods are > undesirable. Since I find the privacy concern as a whole to be unpersuasive, I don't see it as a concern here. > >>>> The rationale for a maximum is to prevent users from having the ability > >>>> to create duplicate tracking list entries that linger indefinitely. > >>> Well, “indefinitely” wouldn’t necessarily be possible, because if the user > >>> specifies nothing then it’s the default, and otherwise he could be > >>> required to specify _something_, correct? > >>> > >> True, but that something could be e.g. 2**32, which is pretty close to > >> indefinitely. > > I confess I don't understand this at all. > Alissa means that a truly infinite retention time is not possible; > either a default value is used or the user needs to specify a concrete > value using the ":seconds" argument. However, the ":seconds" argument > can take very large values. If this value is parsed as a 32 bit unsigned > integer, it could be set to 2**32-1, which is a century and a few > decades. I would call that close enough to infinity in this case. That > is why it is wise to enforce a maximum. OK. > >> But I can appreciate that you don’t want to impose a long, arbitrary > >> retention requirement. Is the idea that the maximum would be surfaced > >> to the user if he’s using some GUI create a duplicate filter? > >> My implementation can provide a warning when this situation occurs. In > >> the case of a GUI this would be returned through ManageSieve with the > >> WARNINGS response code; http://tools.ietf.org/html/rfc5804#section-1.3 . > >> I am not sure whether other implementations would do this or whether > >> GUIs actually show these warnings, but at least there is a specification > >> of this facility. > > That's not a bad idea, although I note that nothing says the maximum that's > > in effect when the sieve is created is going to be the same as the one > > in effect when the sieve is executed. > True. > >> I could add text that implementations SHOULD issue a warning when a > >> maximum ":seconds" value is substituted over what the user specified. > > I don't have a problem with that as long as it's specific to managesieve. > > There's really no straightforward viable path for reporting warnings at sieve > > execution time. (The closest thing we have to that would be the addition of a > > header, but the odds of anyone seeing it are so low there's really no point.) > I have a run-time per-user log file for that, but currently users cannot > actually read this. We also write such things to a log - you know, the same one that contains message transaction metadata like message-ids. A log which in our experience is always enabled and retained for a lot longer than a week. Ned From nobody Wed Jun 25 03:58:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22D51B2B7F for ; Wed, 25 Jun 2014 03:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gpo6L_vdLyuz for ; Wed, 25 Jun 2014 03:58:09 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D06B1B2B66 for ; Wed, 25 Jun 2014 03:58:09 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 35A02223D4 for ; Wed, 25 Jun 2014 06:58:07 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 25 Jun 2014 06:58:08 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=ZykINQjNb75nNbeqBF0n+zh8ZrU=; b=xLSr3DxC7cjkbdh+QNo4K87n21mU P8rEbnPKLiRYSl+znoZJiQukckhz1n2PlQMZUCV0u1etC24cptobFarX2qOTFPMm XXLgybS3wJM3ESO9dl7PFpE2frll/kR4PL/pR4139g+7xTaJcFxj8J5ygBS3+XcO rNMt9XLRvIhLCa4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=ZykINQjNb75nNbeqBF0n+z h8ZrU=; b=OVUCq+lmcCZ4PcZM2BHdcdZy78+Po2P6hpfOg1W7C3ZGBAStDGzENy BhKLO/ujoHjmVqY2lG9DGzLL2Fs5aprnm0kPn7hNTJAesx8eUjlU3u0U5EWw3V/W 9ulXteoayB0A9rQlrMaMJXRPgeBg9+LPgeOWI9e9uKz2zBXuHfrv8= X-Sasl-enc: JKQHqrkOavvagoE9i5w1fxkXKSyKl4zM/lydjlJX6afb 1403693886 Received: from [10.21.90.84] (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id E9F7BC007AE; Wed, 25 Jun 2014 06:58:02 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Wed, 25 Jun 2014 11:58:00 +0100 From: Alissa Cooper To: Ned Freed , Stephan Bosch Message-ID: Thread-Topic: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A9E736.9080709@rename-it.nl> <01P9EFAYDH680049PU@mauve.mrochek.com> <53AA7206.7040905@rename-it.nl> <01P9EV40R78G0049PU@mauve.mrochek.com> In-Reply-To: <01P9EV40R78G0049PU@mauve.mrochek.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ICtwYfsAPSdDXvKiAi1xylaFw-o Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 10:58:12 -0000 Hi all, Top posting to try to assemble a response to all the recent messages here. I took Stephan=E2=80=99s text and some observations from the thread and put this text together for Section 6: "The list of unique IDs used for duplicate tracking can include privacy-sensitive information, such as Message-ID values, content of subject lines, and content extracted from message bodies. Implementations SHOULD protect that information, by obscuring it through hashing (see the note at the end of Section 3.2) and/or by storing it with a level of access control equivalent to that of the messages themselves. These measures will not prevent an entity that has access to the duplicate tracking list from querying whether messages with certain Message-ID values were received. As this operation is the essence of the "duplicate" test, this cannot be prevented, and may violate the expectations of the user. For example, a user who downloads or deletes a message may expect that no record of it remains on the server, but that will not be true if its Message-ID is persisted on the server in the duplicate tracking list. It's notable, however, that server logs will often store the information present on the duplicate tracking list anyway, and probably would expose plaintext Message-IDs for a much longer period than this mechanism would. Users of email services that intentionally delete such logs with the intent of limiting traceability should be made aware that use of the duplicate tracking mechanism re-exposes this information for the duration of the expiry interval. In those situations, a shorter default expiry may also be appropriate since users of these services may be willing to trade off a more limited retention of the duplicate tracking list information against the fact that every duplicate will not necessarily be eliminated with a shorter expiry." What do you think? Thanks, Alissa On 6/25/14, 8:18 AM, "Ned Freed" wrote: >> Hi Ned, > >> On 6/25/2014 12:32 AM, Ned Freed wrote: >> >>>>> The suggested default seems really long, especially for the >>example use >> >>>>> case described in Section 1. >> > Am I missing something? The first example is a straightfoward one >>where >> > message-id duplicates are filed to a special "Trash/Duplicate" >>folder. In such >> > a case basically the longer the retention interval the better things >>work. >> > Given the way message-ids are typically generated by most clients >>it's not like >> > the longer interval increases the liklihood of a duplicate occurring. >> > >> > If the longer retention period has a downside for the user I am not >>seeing it. > >> Alissa mentions this in the context of privacy concerns. A longer >> retention period means that potentially privacy-sensitive data would be >> kept longer. With that point of view, longer retention periods are >> undesirable. > >Since I find the privacy concern as a whole to be unpersuasive, I don't >see >it as a concern here. > >> >>>> The rationale for a maximum is to prevent users from having the >>ability >> >>>> to create duplicate tracking list entries that linger indefinitely. >> >>> Well, =E2=80=9Cindefinitely=E2=80=9D wouldn=E2=80=99t necessarily be possible, because= if >>the user >> >>> specifies nothing then it=E2=80=99s the default, and otherwise he could be >> >>> required to specify _something_, correct? >> >>> >> >> True, but that something could be e.g. 2**32, which is pretty close >>to >> >> indefinitely. >> > I confess I don't understand this at all. > >> Alissa means that a truly infinite retention time is not possible; >> either a default value is used or the user needs to specify a concrete >> value using the ":seconds" argument. However, the ":seconds" argument >> can take very large values. If this value is parsed as a 32 bit unsigned >> integer, it could be set to 2**32-1, which is a century and a few >> decades. I would call that close enough to infinity in this case. That >> is why it is wise to enforce a maximum. > >OK. > >> >> But I can appreciate that you don=E2=80=99t want to impose a long, arbitrar= y >> >> retention requirement. Is the idea that the maximum would be surfaced >> >> to the user if he=E2=80=99s using some GUI create a duplicate filter? >> >> My implementation can provide a warning when this situation occurs. >>In >> >> the case of a GUI this would be returned through ManageSieve with the >> >> WARNINGS response code; >>http://tools.ietf.org/html/rfc5804#section-1.3 . >> >> I am not sure whether other implementations would do this or whether >> >> GUIs actually show these warnings, but at least there is a >>specification >> >> of this facility. >> > That's not a bad idea, although I note that nothing says the maximum >>that's >> > in effect when the sieve is created is going to be the same as the one >> > in effect when the sieve is executed. > >> True. > >> >> I could add text that implementations SHOULD issue a warning when a >> >> maximum ":seconds" value is substituted over what the user specified. >> > I don't have a problem with that as long as it's specific to >>managesieve. >> > There's really no straightforward viable path for reporting warnings >>at sieve >> > execution time. (The closest thing we have to that would be the >>addition of a >> > header, but the odds of anyone seeing it are so low there's really no >>point.) > >> I have a run-time per-user log file for that, but currently users cannot >> actually read this. > >We also write such things to a log - you know, the same one that contains >message transaction metadata like message-ids. A log which in our >experience >is always enabled and retained for a lot longer than a week. > > Ned > From nobody Wed Jun 25 05:20:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9851B2AF3; Wed, 25 Jun 2014 05:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8EhI1Qsh7cj; Wed, 25 Jun 2014 05:19:56 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E301B2AE4; Wed, 25 Jun 2014 05:19:55 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id hz20so685803lab.14 for ; Wed, 25 Jun 2014 05:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xilP17+3AWrQzB3jmEzXyfC9IimoRugo9sZQnyaG7n4=; b=Gm7Hh5VNaAG5VM+Z/a+PMzXPCKDDRsWv63Oo5fGGsJmL+gbnczcMsbIxNPSFUn91eP g7U90Cec7waKiIh95qnKLsaVQOLCxCS50kV+hx+5p55Oj+BtmgyFAyYVEbVZvpFYdJpM MD9WCx7LxibiAswLjhLZ1ujR4NZzThh1cACOMuVWEEZXvdskeUM84ITS/hp3LM+Rffdm COeD5da4i+FiSgRQH55QVt9j4RZ6bABZ1GHscWZ0NREwGn4w9r5dv8u97x2N2xCJDL7R V6Auwr5WhfqHFclqFRU5BpaCcFbo6K6ARerWpFbqnRvnL8lAVulkpz2kJDq8ZA1wwCGw lA9g== MIME-Version: 1.0 X-Received: by 10.112.42.80 with SMTP id m16mr1697578lbl.66.1403698794075; Wed, 25 Jun 2014 05:19:54 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Wed, 25 Jun 2014 05:19:53 -0700 (PDT) In-Reply-To: References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A9E736.9080709@rename-it.nl> <01P9EFAYDH680049PU@mauve.mrochek.com> <53AA7206.7040905@rename-it.nl> <01P9EV40R78G0049PU@mauve.mrochek.com> Date: Wed, 25 Jun 2014 08:19:53 -0400 X-Google-Sender-Auth: pePwKWFE5Ihknt1ZcqAjlAUWXF8 Message-ID: From: Barry Leiba To: Alissa Cooper Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KAFpR64dqbcaSSrr-bfLsU8wUaU Cc: Ned Freed , Apps Discuss , Stephan Bosch , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 12:20:02 -0000 This is fine with me. Stephan, if it's OK with you also, please fold in the changes coming from Alissa's and Kathleen's comments, and post a revised I-D as soon as you can. If you can do it before the Thursday telechat, A & K can clear their discusses. Barry On Wed, Jun 25, 2014 at 6:58 AM, Alissa Cooper wrote: > Hi all, > > Top posting to try to assemble a response to all the recent messages here. > > I took Stephan's text and some observations from the thread and put this > text together for Section 6: > > "The list of unique IDs used for duplicate tracking can include > privacy-sensitive information, such as Message-ID values, content of > subject lines, and content extracted from message bodies. Implementations > SHOULD protect that information, by obscuring it through hashing (see the > note at the end of Section 3.2) and/or by storing it with a level of > access control equivalent to that of the messages themselves. > > These measures will not prevent an entity that has access to the duplicate > tracking list from querying whether messages with certain Message-ID > values were received. As this operation is the essence of the "duplicate" > test, this cannot be prevented, and may violate the expectations of the > user. For example, a user who downloads or deletes a message may expect > that no record of it remains on the server, but that will not be true if > its Message-ID is persisted on the server in the duplicate tracking list. > > It's notable, however, that server logs will often store the information > present on the duplicate tracking list anyway, and probably would expose > plaintext Message-IDs for a much longer period than this mechanism would. > Users of email services that intentionally delete such logs with the > intent of limiting traceability should be made aware that use of the > duplicate tracking mechanism re-exposes this information for the duration > of the expiry interval. In those situations, a shorter default expiry may > also be appropriate since users of these services may be willing to trade > off a more limited retention of the duplicate tracking list information > against the fact that every duplicate will not necessarily be eliminated > with a shorter expiry." > > What do you think? > > Thanks, > Alissa > > > > On 6/25/14, 8:18 AM, "Ned Freed" wrote: > >>> Hi Ned, >> >>> On 6/25/2014 12:32 AM, Ned Freed wrote: >>> >>>>> The suggested default seems really long, especially for the >>>example use >>> >>>>> case described in Section 1. >>> > Am I missing something? The first example is a straightfoward one >>>where >>> > message-id duplicates are filed to a special "Trash/Duplicate" >>>folder. In such >>> > a case basically the longer the retention interval the better things >>>work. >>> > Given the way message-ids are typically generated by most clients >>>it's not like >>> > the longer interval increases the liklihood of a duplicate occurring. >>> > >>> > If the longer retention period has a downside for the user I am not >>>seeing it. >> >>> Alissa mentions this in the context of privacy concerns. A longer >>> retention period means that potentially privacy-sensitive data would be >>> kept longer. With that point of view, longer retention periods are >>> undesirable. >> >>Since I find the privacy concern as a whole to be unpersuasive, I don't >>see >>it as a concern here. >> >>> >>>> The rationale for a maximum is to prevent users from having the >>>ability >>> >>>> to create duplicate tracking list entries that linger indefinitely. >>> >>> Well, "indefinitely" wouldn't necessarily be possible, because if >>>the user >>> >>> specifies nothing then it's the default, and otherwise he could be >>> >>> required to specify _something_, correct? >>> >>> >>> >> True, but that something could be e.g. 2**32, which is pretty close >>>to >>> >> indefinitely. >>> > I confess I don't understand this at all. >> >>> Alissa means that a truly infinite retention time is not possible; >>> either a default value is used or the user needs to specify a concrete >>> value using the ":seconds" argument. However, the ":seconds" argument >>> can take very large values. If this value is parsed as a 32 bit unsigned >>> integer, it could be set to 2**32-1, which is a century and a few >>> decades. I would call that close enough to infinity in this case. That >>> is why it is wise to enforce a maximum. >> >>OK. >> >>> >> But I can appreciate that you don't want to impose a long, arbitrary >>> >> retention requirement. Is the idea that the maximum would be surfaced >>> >> to the user if he's using some GUI create a duplicate filter? >>> >> My implementation can provide a warning when this situation occurs. >>>In >>> >> the case of a GUI this would be returned through ManageSieve with the >>> >> WARNINGS response code; >>>http://tools.ietf.org/html/rfc5804#section-1.3 . >>> >> I am not sure whether other implementations would do this or whether >>> >> GUIs actually show these warnings, but at least there is a >>>specification >>> >> of this facility. >>> > That's not a bad idea, although I note that nothing says the maximum >>>that's >>> > in effect when the sieve is created is going to be the same as the one >>> > in effect when the sieve is executed. >> >>> True. >> >>> >> I could add text that implementations SHOULD issue a warning when a >>> >> maximum ":seconds" value is substituted over what the user specified. >>> > I don't have a problem with that as long as it's specific to >>>managesieve. >>> > There's really no straightforward viable path for reporting warnings >>>at sieve >>> > execution time. (The closest thing we have to that would be the >>>addition of a >>> > header, but the odds of anyone seeing it are so low there's really no >>>point.) >> >>> I have a run-time per-user log file for that, but currently users cannot >>> actually read this. >> >>We also write such things to a log - you know, the same one that contains >>message transaction metadata like message-ids. A log which in our >>experience >>is always enabled and retained for a lot longer than a week. >> >> Ned >> > > From nobody Wed Jun 25 06:46:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80231B2CAA; Wed, 25 Jun 2014 06:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDqfWhleBU4X; Wed, 25 Jun 2014 06:46:11 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459D41B2C94; Wed, 25 Jun 2014 06:46:10 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 929E322B3B; Wed, 25 Jun 2014 09:46:05 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 25 Jun 2014 09:46:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=5tdLWG5Ms4myuJ2dvmkgeNRTY08=; b=pTvfsRajrYz+qejYO6JA8V9hRWnh U+jLIJRfRaH5+AjaZQJUvHtChMIIhJY6vI5Ec4U8M1VbeUMgH0d4Mq7NerCGz7vc ZIta2zZ0BhajwHp0l6LIVlQj/12Nwe9jfPrzQT1rd7yUMQyKH2vyZvdhocToIjla 6+xagpT+msORzj0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=5tdLWG5Ms4myuJ2dvmkgeN RTY08=; b=GGkWfoURMcC/wH7XXe5s+F3ZkhBoa/GPGNxNmG5+640rydofjd1n5Z ufagV3U7qlSujTcWv78G4vbQmi/redKqBdmV9jMjfH1zfUNr61/j6dR0t7CxDs0j HLgxwgivhQnvoFUWrqWLsSt6qIDwI86FZbDoivd3HySqP9KB1NPqo= X-Sasl-enc: JJe2tDYG1JlbbLRZTORv4qTafelqBLnYq4TiEKwJWIl+ 1403703965 Received: from [10.21.149.231] (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 8C0E6680099; Wed, 25 Jun 2014 09:45:59 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Wed, 25 Jun 2014 14:45:55 +0100 From: Alissa Cooper To: Barry Leiba Message-ID: Thread-Topic: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A9E736.9080709@rename-it.nl> <01P9EFAYDH680049PU@mauve.mrochek.com> <53AA7206.7040905@rename-it.nl> <01P9EV40R78G0049PU@mauve.mrochek.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DwGuuaBdkUSPVIpd0X9_Gr9iEJU Cc: Ned Freed , Apps Discuss , Stephan Bosch , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 13:46:13 -0000 On 6/25/14, 1:19 PM, "Barry Leiba" wrote: >This is fine with me. Stephan, if it's OK with you also, please fold >in the changes coming from Alissa's and Kathleen's comments, and post >a revised I-D as soon as you can. If you can do it before the >Thursday telechat, A & K can clear their discusses. > >Barry I would still be interested in discussing this bit of my DISCUSS: o Section 6: Sieve scripts that include duplicate tests contain potentially sensitive information (e.g., subject or body strings). So it seems like the scripts should be confidentiality protected in transit. I checked with Barry and he said that there is no RFC that specifies if/when scripts should be protected in transit, and I understand that this document is probably not the right place to specify required behavior there, but I'd like to discuss (more with the ADs than the authors) if there is some plan for specifying that behavior somewhere. Thanks, Alissa From nobody Wed Jun 25 06:49:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40841B2CAA for ; Wed, 25 Jun 2014 06:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TlywOBknMc7 for ; Wed, 25 Jun 2014 06:49:46 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7171B2CA6 for ; Wed, 25 Jun 2014 06:49:46 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id uy5so2009788obc.8 for ; Wed, 25 Jun 2014 06:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OqNsj4iLly5DGgJYOBNnxpauTgQyE4Q/OPyPXgDvAps=; b=OUXOg8t2CYbpOS2mJrHKlW4I3PhmDbiKC/24gUD0brOTI46vx5xyteRiE1YLOuqQM7 tZFbPOI3CDtlLlfoKcuAChH9GkiP7SLEf2Wkg0oNau7lLRHgKkuu5GjdWoDeQGRh/879 GPdQJlG/xmH8TfSpoIY8yMb7SyTJt0Vsws38k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OqNsj4iLly5DGgJYOBNnxpauTgQyE4Q/OPyPXgDvAps=; b=fzdmL429HsgFfwBbMUjq9Tm2CFPc4YBhO8GFr1LIQDp7pMU84UnVcP71QpA21rHGw6 46jLNc4YfO2oMW5ISLP/BcAiG2126S78vM62DzkLYeEHSUQmtWj520oaR0usocXKcMpn vn8ViDqGdXB9Yfmi4LX0iqjUW86C0y0mqLPG9sHsWRVL9qN6W+AIHPy6r9eDXlQA1RX3 hRF7F+g7XUpNQRw6lkSEHEe72AkdPSzxnLu4Ar/1oYXECNU3LGL8LuB9ZRYmrYdcrY+1 QpMmOtiv5nMUtVsnlCAuws2CfNQ1RMfjwEQPBgdhmSKjIFCRrhtWgVtLEcEatv9kpy3T oeZQ== X-Gm-Message-State: ALoCoQnmEGlSwjDLKfeq0imXllo+OZ74JIIdaR2qfhRUPp1QNalzD4ZdkaSm594Yt3P7gvQd1P6y MIME-Version: 1.0 X-Received: by 10.182.158.68 with SMTP id ws4mr15771obb.86.1403704185895; Wed, 25 Jun 2014 06:49:45 -0700 (PDT) Received: by 10.60.60.100 with HTTP; Wed, 25 Jun 2014 06:49:45 -0700 (PDT) In-Reply-To: References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A9E736.9080709@rename-it.nl> <01P9EFAYDH680049PU@mauve.mrochek.com> <53AA7206.7040905@rename-it.nl> <01P9EV40R78G0049PU@mauve.mrochek.com> Date: Wed, 25 Jun 2014 14:49:45 +0100 Message-ID: From: Dave Cridland To: Alissa Cooper Content-Type: multipart/alternative; boundary=089e013cc0865f4f1904fca95929 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZKh1QIHgBI7QNtUnIqodOjYL4TY Cc: Ned Freed , Apps Discuss , Stephan Bosch , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Barry Leiba , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 13:49:48 -0000 --089e013cc0865f4f1904fca95929 Content-Type: text/plain; charset=UTF-8 On 25 June 2014 14:45, Alissa Cooper wrote: > I would still be interested in discussing this bit of my DISCUSS: > > o Section 6: > Sieve scripts that include duplicate tests contain potentially sensitive > information (e.g., subject or body strings). So it seems like the scripts > should be confidentiality protected in transit. I checked with Barry and he > said that there is no RFC that specifies if/when scripts should be > protected in > transit, and I understand that this document is probably not the right > place to > specify required behavior there, but I'd like to discuss (more with the ADs > than the authors) if there is some plan for specifying that behavior > somewhere. > http://tools.ietf.org/html/rfc5804#section-5 covers this to some degree, I think. Dave. --089e013cc0865f4f1904fca95929 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 25 June 2014 14:45, Alissa Cooper <alissa@cooperw.in>= wrote:
I would still be interested in discussing = this bit of my DISCUSS:

o Section 6:
Sieve scripts that include duplicate tests contain potentially sensitive information (e.g., subject or body strings). So it seems like the scripts should be confidentiality protected in transit. I checked with Barry and he=
said that there is no RFC that specifies if/when scripts should be
protected in
transit, and I understand that this document is probably not the right
place to
specify required behavior there, but I'd like to discuss (more with the= ADs
than the authors) if there is some plan for specifying that behavior
somewhere.

http://tools.ietf.org/html/rfc5804#secti= on-5 covers this to some degree, I think.

Dave= .=C2=A0
--089e013cc0865f4f1904fca95929-- From nobody Wed Jun 25 07:18:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB8E1B2CC1; Wed, 25 Jun 2014 07:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cU6LEUYFiFZl; Wed, 25 Jun 2014 07:18:03 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A391B2CC0; Wed, 25 Jun 2014 07:18:03 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id s7so1913915lbd.16 for ; Wed, 25 Jun 2014 07:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gfnExmx/gDiOd3RY8e7nMPyknViAGaOf2R1tKgU0c/8=; b=sN5dframZJ4XYuWN9PfRybQKbZ+191AJvlZf8JZPelQiqAoK7FMyRjIZkbDnzbqaIl meaWTTbwimx4uGZilRW46FaU+cgdWmDBr0seaswNhzs3n95Zl5jKM5nCxQW9vKohKVyy V5LJhmTsyMAMMYcrLCzFa/2gcIeZj/kuhR784EWWCn1r6+1pxrQz5SUF0+pxMe44Pc1R jRTxHh0WzIiEiO+YTM+KCX7fD6DSJl6/4aJ+om99riIENrVnTH0klPm38y5Yakm+IscB 2nKuaQEp9gKIVd3zD8rCX3P+7Tzl0G6T/vmugaYd+CPuZgCZp/rTB0kRmhGOJr8X0YkF q1yg== MIME-Version: 1.0 X-Received: by 10.152.43.17 with SMTP id s17mr1209867lal.81.1403705881461; Wed, 25 Jun 2014 07:18:01 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Wed, 25 Jun 2014 07:18:01 -0700 (PDT) In-Reply-To: References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A9E736.9080709@rename-it.nl> <01P9EFAYDH680049PU@mauve.mrochek.com> <53AA7206.7040905@rename-it.nl> <01P9EV40R78G0049PU@mauve.mrochek.com> Date: Wed, 25 Jun 2014 10:18:01 -0400 X-Google-Sender-Auth: 1a0ARWPkp0q-0snWTh1QU9-nec0 Message-ID: From: Barry Leiba To: Alissa Cooper Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-FrzdJFxYk4X3BimSGRVRd50omY Cc: Ned Freed , Apps Discuss , Stephan Bosch , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 14:18:05 -0000 > I would still be interested in discussing this bit of my DISCUSS: > > o Section 6: > Sieve scripts that include duplicate tests contain potentially sensitive > information (e.g., subject or body strings). Actually, no more so than any Sieve script. Filtering on patterns is reasonably common, and I don't think duplicate detection will increase that. > So it seems like the scripts > should be confidentiality protected in transit. I checked with Barry and he > said that there is no RFC that specifies if/when scripts should be > protected in > transit, and I understand that this document is probably not the right > place to > specify required behavior there, but I'd like to discuss (more with the ADs > than the authors) if there is some plan for specifying that behavior > somewhere. As I said when you checked with me, this is entirely out of scope for this document. If someone should want to do an update to ManageSieve or some such, that'd be fine, but it's got nothing to do with this extension. Barry From nobody Wed Jun 25 09:58:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774E61B2A1B for ; Wed, 25 Jun 2014 09:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uySlX-A1HI-6 for ; Wed, 25 Jun 2014 09:58:22 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239411B2A10 for ; Wed, 25 Jun 2014 09:58:22 -0700 (PDT) Received: from [31.55.0.251] (port=5758 helo=[10.67.37.27]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WzqWY-0002JK-Lp; Wed, 25 Jun 2014 09:58:20 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_6F018C78-27E0-4395-92F3-3F1A279BD3F5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Eric Burger In-Reply-To: Date: Wed, 25 Jun 2014 17:58:15 +0100 Message-Id: <4E431292-40D7-48E3-B201-C7EA009A9B5D@standardstrack.com> References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A9E736.9080709@rename-it.nl> <01P9EFAYDH680049PU@mauve.mrochek.com> <53AA7206.7040905@rename-it.nl> <01P9EV40R78G0049PU@mauve.mrochek.com> To: Alissa Cooper X-Mailer: Apple Mail (2.1878.2) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger-l+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_-q5NvzZWFC1BC2pDH6MvLlMsU0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 16:58:27 -0000 --Apple-Mail=_6F018C78-27E0-4395-92F3-3F1A279BD3F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 inline On Jun 25, 2014, at 11:58 AM, Alissa Cooper wrote: > Hi all, >=20 > Top posting to try to assemble a response to all the recent messages = here. >=20 > I took Stephan=92s text and some observations from the thread and put = this > text together for Section 6: >=20 > "The list of unique IDs used for duplicate tracking can include > privacy-sensitive information, such as Message-ID values, content of > subject lines, and content extracted from message bodies. = Implementations > SHOULD protect that information, by obscuring it through hashing (see = the > note at the end of Section 3.2) and/or by storing it with a level of > access control equivalent to that of the messages themselves. SHOULD=85. unless what? SHOULD without =91unless=92 =3D MAY =3D don=92t = bother. > These measures will not prevent an entity that has access to the = duplicate > tracking list from querying whether messages with certain Message-ID > values were received. As this operation is the essence of the = "duplicate" > test, this cannot be prevented, and may violate the expectations of = the > user. For example, a user who downloads or deletes a message may = expect > that no record of it remains on the server, but that will not be true = if > its Message-ID is persisted on the server in the duplicate tracking = list. Really? Let=92s take the case of the US. I think the Lois Lerner affair = will make the 12 people who didn=92t know that a deleted email is not = gone aware that deleted emails are not gone. If we care about that, = let=92s write a BCP that says a sending system SHOULD delete all copies = of sent messages, because the recipient has an expectation that if they = delete a message, ALL copies of the message go away. If we are trying to protect the privacy of a person who has no = expectation of privacy, are we protecting anything? > It's notable, however, that server logs will often store the = information > present on the duplicate tracking list anyway, and probably would = expose > plaintext Message-IDs for a much longer period than this mechanism = would. > Users of email services that intentionally delete such logs with the > intent of limiting traceability should be made aware that use of the > duplicate tracking mechanism re-exposes this information for the = duration > of the expiry interval. That=92s nice, but how? I am glad the language does not move us from the = protocol police into the implementation police. > In those situations, a shorter default expiry may > also be appropriate since users of these services may be willing to = trade > off a more limited retention of the duplicate tracking list = information > against the fact that every duplicate will not necessarily be = eliminated > with a shorter expiry." >=20 > What do you think? I think Joe Average will have no clue what we are talking about. Joe = Average wonders why he gets multiple copies of the same email. Joe = Average will be really mystified if he thinks he is getting a service = that will stop those duplicates and yet he still gets them. Also, = consider the hypothetical user from two paragraphs ago who delusionally = thinks that deleting an email makes it go away. They will freak out when = it shows up again. This line of reasoning is why if you really care about such issues, you = will not trust your email processing to a service provider. You will do = everything at the edge. If you do trust your email processing to a = service provider=85 you trust your email processing to the service = provider. [snip] --Apple-Mail=_6F018C78-27E0-4395-92F3-3F1A279BD3F5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTqv+oAAoJEDY/T2tCIPW3028P/3LPQrqSMHROJlcCItgrc9/e 5xsK+YnXbjwkVeRQQJlYe7KpiDiwaQ4EkXJwMlK6ITGpDztUg6nKfNuO5N6m4MJW zdbdEfBzk6f95bqT87TU4GiJGZWwEb0RQjMnBws1NSy5zYqIqZ9BpnKvjyesPuMV l52opvvQnDTnIDlCg2036gfR/LNtX/YQYh3ZpQcgegfEjRGZa1awyXtyiIfOh1tK jseQnEmYgn8wNZvBMu51CRhno4Ka2fCkUO6lWPvdrNhTHVBIXdrVEu/0nzp7KH5L L4fnkH950VsecxT/6QDxMkjBQ9tEcD/FxayyKmiCzBd9AD+7dJ9b86BzgjASPeRa Wb7yBClcDmN2VsqMaLhVq6ENAjjq7eWqX20MsmupouPmYwCCpCRv/R04zfm1D3wj hMSQ8xhKuhJH2G9aJB44JkH+oNfta0SzBAQLtZNyQIgkf1RPXs25oQPblRdsXL8j hzMiyIF4i3fVXraei4O1AfiS/pIO/ws7vg36qjRR/xatVFZlolvENJlV1qY+sDAy +Od9EUOftLT/PYe0mP5wxcDVb4wtl0HaG1L72IboWmZewxQo7U5VXy0rT1pFUG3s Zce/Gc7wuE8U+1iAgsUzQdW+U6qJe2Kltf8k2gGzh6Vq784wGmP9MKhrxfzcYWxb 4y4Tim0s3dfgQSEhRtaJ =CZg3 -----END PGP SIGNATURE----- --Apple-Mail=_6F018C78-27E0-4395-92F3-3F1A279BD3F5-- From nobody Wed Jun 25 10:00:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7FF1B2D4B; Wed, 25 Jun 2014 10:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTMn-5e-Mf-J; Wed, 25 Jun 2014 10:00:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9031B2A4F; Wed, 25 Jun 2014 10:00:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140625170022.6498.7940.idtracker@ietfa.amsl.com> Date: Wed, 25 Jun 2014 10:00:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7kWs55wK5OSvXrYzqWDLo3DUa6A Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Pete Resnick's No Objection on draft-ietf-appsawg-sieve-duplicate-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 17:00:30 -0000 Pete Resnick has entered the following ballot position for draft-ietf-appsawg-sieve-duplicate-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have no objection to this extension; I think it will be helpful for some folks. Interestingly, I can't see ever using it myself: When I get duplicates from a mailing list, I *always* want the one that was sent from the list, with the List-* header fields on it, and *not* the one sent directly to me. Unfortunately, the one from the list is almost always going to arrive after the one sent directly to me, and the extension doesn't give me enough state to find the message(s) that came in earlier so I can decide which one to keep. But like I said, I can see others using this. As to specific comments: As a side-effect, the "duplicate" test adds the message ID to an internal duplicate tracking list once the Sieve execution finishes successfully. I think this may have been mentioned in response to someone else's comment, but perhaps this should be: As a side-effect, the "duplicate" test adds a unique identifier (again, by default the contents of the Message-ID header field) to an internal duplicate tracking list once the Sieve execution finishes successfully. And then change other occurrences of "message ID" to "unique identifier" elsewhere in the document as appropriate. From nobody Wed Jun 25 10:26:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208CE1B2D8B for ; Wed, 25 Jun 2014 10:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFvmSJrOGHh8 for ; Wed, 25 Jun 2014 10:26:28 -0700 (PDT) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644721B2D90 for ; Wed, 25 Jun 2014 10:26:17 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id jx11so2382129veb.33 for ; Wed, 25 Jun 2014 10:26:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=7ut/bRqTpuXcKnUnxjb5nkEuW6p9pX29x0V3nvU3EGA=; b=QkOiL+5felbTX5t5OHcznkRTknZCzyCGRUD7PG4F0DQD43OUQLhqoK32KoobPnzwl2 84JMAP9j+bpJI/7EfMbsZHbjSdV3nGoIfeF26LXdqYZpCGcusN2o/pfBYs78KD1Qr9/I rUVKNP5jiU2nUHe6jq/R2UfBN5mA6ce3zG0jW5XEbMUbAPg7CajTfsJxMII/0ciuDR78 pxg5iAoliM0DeqFvPaC7LP2pkyinBhWRcD/LY+E8JTRN4cj5FdCWvaARvujZt3GQXL0O wSxYeXthDyWpwneGy3KP+CndIIAUJoHpAIpzR3yCLDlIzfqz0O7QkprECz5rPOvQMJYj scIA== X-Gm-Message-State: ALoCoQkk4sRJUo+LPfswayyOXybrBptbu6+tgJAFbg/YDmkdbhqHCqh5aqpHs8YtXgB97DaiW7Wo X-Received: by 10.220.95.2 with SMTP id b2mr1847259vcn.61.1403717176219; Wed, 25 Jun 2014 10:26:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.49.199 with HTTP; Wed, 25 Jun 2014 10:25:56 -0700 (PDT) X-Originating-IP: [24.84.235.32] From: Tim Bray Date: Wed, 25 Jun 2014 10:25:56 -0700 Message-ID: To: "apps-discuss@ietf.org" , draft-ietf-mile-enum-reference-format.all@tools.ietf.org, mile@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mvx72FgI8uk4OUdoy5EwhsLdNyc Cc: The IESG Subject: [apps-discuss] Apps Area review of draft-ietf-mile-enum-reference-format-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 17:26:30 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please seehttp://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorat= e ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document:draft-ietf-mile-enum-reference-format-05 Title: IODEF Enumeration Reference Format Reviewer:Tim Bray Review Date: June 25, 2014 There are problems in this document which should be addressed before publication. 1. The description uses many technical terms without first either defining them or giving a reference for their meaning: =E2=80=9CReference class=E2=80=9D, =E2=80=9CEnumeration values=E2=80=9D, "enumeration identifi= ers and their references=E2=80=9D. This reviewer found the spec really hard to understan= d due to the heavy use of specialized language with no definition of terms. NOTE: It may be reasonable to decide that this specification is only intended to be read by those who are already sufficiently expert to understand the terms, in which case this wouldn=E2=80=99t be a problem. 2. Why introduce two child elements, rather than just add an attribute? Here=E2=80=99s the example: 1 CXI-1234-XYZ An attribute would feel more idiomatic. Why not CXI-1234-XYZ ? Suggested improvements to the spec: Abstract: This at least should be comprehensible to nonspecialists. Here is a suggested rewrite: The The Incident Object Description Exchange Format (IODEF) is an XML construct which contains identifiers, using an element called ReferenceName, that come from enumerations of fixed string values. At the moment the content of ReferenceName is just a string field, which is unsatisfactory because it is necessary to know both the value and the enumeration from which it comes. This specification changes the definition of ReferenceName by adding structure which identifies both the value and the enumeration from which it comes. This is done indirectly through an IANA registry. In the first paragraph of section 2, the word =E2=80=9Cresulting=E2=80=9D i= s wrong. I think the sentence is trying to say =E2=80=9Cto require that the ReferenceN= ame element identify both the enumeration from which the name comes and the name itself, and to identify enumerations via an IANA registry, which includes useful metadata such as a link to the enumeration=E2=80=99s specification.=E2=80=9D FIGURE 1 identifies the structure of Reference *before* this draft. Why not provide before-and-after pictures? Section 2, para beginning =E2=80=9CPer IODEF=E2=80=9D, language is clumsy = =E2=80=9Cspecific references, such as ... are referenced.=E2=80=9D Perhaps something like =E2=80=9Cbecomes problematic when the ReferenceName comes from a particular enumeration such as CVE [CVE], CCE [CCE], or CPE [CPE] and it is not obvious to an implementer how to determine which. One solution, presented here, is to add structure to the ReferenceName to identify both the value and the enumeration it comes from=E2=80=9C. Section 2.1, should the title become something like =E2=80=9CRevised ReferenceName Format=E2=80=9D? Also, sort of roundabout. How about =E2=80=9C... and requires a child eleme= nts named "Index" and "ID"; the first contains an integer which identifies an entry in an IANA registry (see Section 4), which specifies the specification the actual enumeration value, provided as the content of the =E2=80=9CID=E2=80=9D child element. Or, as suggested above, make Index= an attribute, then you don=E2=80=99t need ID. The name =E2=80=9CIndex=E2=80=9D is lousy. Yes, it=E2=80=99s an integer in= dex into an IANA registry, but element names should describe what the content means, not its data format. This identifies is a enumeration or a namespace or a specification. Maybe SpecIndex? or Enumeration? Also, in the IANA table, shouldn=E2=80=99t the spec say something about wha= t kind of thing the Specification URI is supposed to identify? An I-D? An RFC? An XSD? --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) From nobody Wed Jun 25 11:08:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275E01B2DC9; Wed, 25 Jun 2014 11:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7QXICXezeEz; Wed, 25 Jun 2014 11:08:22 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709F51B2DD0; Wed, 25 Jun 2014 11:07:17 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id s5PI7DQ9024256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Jun 2014 13:07:14 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s5PI7DRj006692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Jun 2014 13:07:13 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s5PI77tf025602; Wed, 25 Jun 2014 13:07:13 -0500 (CDT) Message-ID: <53AB1065.6030905@bell-labs.com> Date: Wed, 25 Jun 2014 13:09:41 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Emil Ivov , "apps-discuss@ietf.org" , draft-ietf-mmusic-latching@tools.ietf.org References: <537F520E.3060501@bell-labs.com> <538663F1.4080709@jitsi.org> <538C8820.1090900@bell-labs.com> <53A0B8CA.3080107@jitsi.org> In-Reply-To: <53A0B8CA.3080107@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7n9EElb7FHgeXNsdkViZAruLLbQ Cc: IESG IESG , mmusic Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-mmusic-latching-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 18:08:26 -0000 On 06/17/2014 04:53 PM, Emil Ivov wrote: > Hey Vijay, > > Apologies for the delay! I believe we have addressed all comments and a > new version is available here: > > Html: http://tools.ietf.org/html/draft-ietf-mmusic-latching-08 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-08 > > Please see inline for the rest of my responses (points of accord removed): [...] Emil: Closing the loop on this one since I was pressed for time last week (traveling). I am fine with your proposed changes and the diffs look good. I have no further comments. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Wed Jun 25 18:39:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647B21B2ED0; Wed, 25 Jun 2014 18:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYFgPgA69_hk; Wed, 25 Jun 2014 18:39:00 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id BAC8A1B2ECE; Wed, 25 Jun 2014 18:38:59 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P9FV3N6MW00052KW@mauve.mrochek.com>; Wed, 25 Jun 2014 18:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1403746427; bh=MWMBM7xIb2/rUbeH95Nk8EeyWClFnMXdlLAXQGR7tDI=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=YBaRISuSKRFzalhTH1uVyUBx8VkG7KpNn1xTjXGudTDpuDZBYGroHGkt2tjr79N0S AFirDu8VWQ+D8Blqp+IH0EaIPRj2AQxTdz1d6no3+kQA8KGluoLP4UtQhUuzJosUhZ 61Hyqxs3wqnH8MV2TjhycwDBZD2X/VbCXsn+W3DM= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Wed, 25 Jun 2014 18:33:44 -0700 (PDT) Message-id: <01P9FV3KN7620049PU@mauve.mrochek.com> Date: Wed, 25 Jun 2014 18:24:05 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 25 Jun 2014 10:18:01 -0400" References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A9E736.9080709@rename-it.nl> <01P9EFAYDH680049PU@mauve.mrochek.com> <53AA7206.7040905@rename-it.nl> <01P9EV40R78G0049PU@mauve.mrochek.com> To: Barry Leiba Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YBVe6UUanTdtZu3J1D3ty8HyEqc Cc: Ned Freed , Apps Discuss , Stephan Bosch , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 01:39:02 -0000 > > I would still be interested in discussing this bit of my DISCUSS: > > > > o Section 6: > > Sieve scripts that include duplicate tests contain potentially sensitive > > information (e.g., subject or body strings). > Actually, no more so than any Sieve script. Filtering on patterns is > reasonably common, and I don't think duplicate detection will increase > that. Probably less so. Consider: # Banking rule autogenerated based on user preference settings if address :domain "from" "bankofamerica.com" { fileinto "Banking"; } provides a much bigger set of clues for spear phishing than any previous examples given in this thread. if address "from" "myboss@mycompany.com" { fileinto "stupidstuff"; } is not something you want your boss to see. if address :detail "pager" { redirect "XXXXXXXXXX@att.com"; } creates a subaddress you probably don't want just anyone to use. And on and on and on. > > So it seems like the scripts > > should be confidentiality protected in transit. I checked with Barry and he > > said that there is no RFC that specifies if/when scripts should be > > protected in > > transit, and I understand that this document is probably not the right > > place to > > specify required behavior there, but I'd like to discuss (more with the ADs > > than the authors) if there is some plan for specifying that behavior > > somewhere. > As I said when you checked with me, this is entirely out of scope for > this document. If someone should want to do an update to ManageSieve > or some such, that'd be fine, but it's got nothing to do with this > extension. Indeed. It may even be out of scope of the core Sieve specifications, since user preferences and addressbooks are even more likely to provide a basis for unwelcome privacy intrusions. If this is going to be addressed in an IETF specification it probably needs to be done in as general a way as possible. Address books in particular have been widely exploited; there's nothing at all theoretical about the attack surface they present. Ned From nobody Wed Jun 25 18:45:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5131B2ED6; Wed, 25 Jun 2014 18:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYxz3iKp6Ixg; Wed, 25 Jun 2014 18:45:32 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 212A91B2EDB; Wed, 25 Jun 2014 18:45:32 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P9FVBPJ6Q8006PUA@mauve.mrochek.com>; Wed, 25 Jun 2014 18:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1403746817; bh=rzVAz1mALzZ+rgBGj5Ne4XihsMExBVmG6LYwKmPXMSc=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=PuG1NvuV639F8X1B6fk2bxPNy/wPi7rKRbd+z0PgXzSI7n3Naguuc7VHZ2mTdelYk h8BQyTEAoZRx25jBURVw5sL4GS+EpE9oVpj5lcj3f9O2EOZbXI/859kkpq71aAQJQU pyIQXqFGrGXsYXjSFUNy2ldTGJ8txDhBhef9R8VY= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Wed, 25 Jun 2014 18:40:15 -0700 (PDT) Message-id: <01P9FVBNQ1K40049PU@mauve.mrochek.com> Date: Wed, 25 Jun 2014 18:36:46 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 25 Jun 2014 10:00:22 -0700" <20140625170022.6498.7940.idtracker@ietfa.amsl.com> References: <20140625170022.6498.7940.idtracker@ietfa.amsl.com> To: Pete Resnick Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5EXRQY0bu3KL1CkI6QIF9Nl_O14 Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, The IESG , apps-discuss@ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org Subject: Re: [apps-discuss] Pete Resnick's No Objection on draft-ietf-appsawg-sieve-duplicate-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 01:45:34 -0000 > Pete Resnick has entered the following ballot position for > draft-ietf-appsawg-sieve-duplicate-07: No Objection > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > I have no objection to this extension; I think it will be helpful for > some folks. Interestingly, I can't see ever using it myself: When I get > duplicates from a mailing list, I *always* want the one that was sent > from the list, with the List-* header fields on it, and *not* the one > sent directly to me. Unfortunately, the one from the list is almost > always going to arrive after the one sent directly to me, and the > extension doesn't give me enough state to find the message(s) that came > in earlier so I can decide which one to keep. But like I said, I can see > others using this. I note in that this particular issue was discussed at some length on the list. Unfortunately providing a mechanism capable of doing what Pete (and others, myself included) want is quite nontrivial given the current architecture of email. > As to specific comments: > As a side-effect, the "duplicate" test adds the message ID to an > internal duplicate tracking list once the Sieve execution finishes > successfully. > I think this may have been mentioned in response to someone else's > comment, but perhaps this should be: > As a side-effect, the "duplicate" test adds a unique identifier > (again, by default the contents of the Message-ID header field) to an > internal duplicate tracking list once the Sieve execution finishes > successfully. Barry (I think) suggested text earlier that addresses this. > And then change other occurrences of "message ID" to "unique identifier" > elsewhere in the document as appropriate. That's a good idea. Ned From nobody Wed Jun 25 21:12:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0177E1B2B69; Wed, 25 Jun 2014 03:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YgcClPjl6f7; Wed, 25 Jun 2014 03:41:54 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF7E1B2B67; Wed, 25 Jun 2014 03:41:54 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id cm18so1378309qab.0 for ; Wed, 25 Jun 2014 03:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zQVNZmXzcUbGIpFCKzkJHCrYH1SFJK1uoWQ2emoFPM4=; b=PCN7CksxabP38Qh3MRDc1PY3P3S/8UyxUo2stvunJ1ettRqO5YGRzzQ1LfVqUN+TXp c4bnmU6iCcgK+HfBMk8nxufzh3R/kLagIJxieD7uuIFxbWhDv85rN3tLzF1BQU05UGep 3fM8Iwfx8DY5sP8fU3cl8CJ+5j2EUsjAwSkfR+F/nvEUTAg8e051LmDaC3Su1UGAf8Kf HpK8cgvJaZlpB4AzwD0dz6StdnueMVJKzky3qAV7SoEWcf3bnTyAhj3JYvEHq/Tw6aEo IhPTQ9VajHWG4z1GnIDn8x+ItEvYZB6nfJfRmbKx1VJmz/BR5glL+EecDko4lXFeZpJM SdDw== X-Received: by 10.224.80.67 with SMTP id s3mr10112597qak.92.1403692913488; Wed, 25 Jun 2014 03:41:53 -0700 (PDT) Received: from [192.168.1.4] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id k5sm5334075qao.30.2014.06.25.03.41.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 03:41:52 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D167) In-Reply-To: <53AA6DFF.9070008@rename-it.nl> Date: Wed, 25 Jun 2014 06:41:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <99A8F5C0-C4CD-400E-BD06-1C1017FA193B@gmail.com> References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> <53A98428.106@qti.qualcomm.com> <53A9DBC1.9000301@rename-it.nl> <53AA6DFF.9070008@rename-it.nl> To: Stephan Bosch Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JyAX8OskCk_nOyWo6_EYMsYnBCo X-Mailman-Approved-At: Wed, 25 Jun 2014 21:12:05 -0700 Cc: Apps Discuss , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Barry Leiba , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 10:41:56 -0000 Thank you, all! That sounds good. Sent from my iPhone > On Jun 25, 2014, at 2:36 AM, Stephan Bosch wrote: >=20 > Hi Barry, >=20 > On 6/25/2014 8:29 AM, Barry Leiba wrote: >>>>> Script writers using the duplicate test evaluation should be aware tha= t >>>>> Message-IDs are not necessarily unique either through the fault of >>>>> benign >>>>> generators or attackers at some point prior to the Sieve filter >>>>> injecting a >>>>> message with the properties used by the duplicate Sieve filter. As >>>>> such, >>>>> script writers may opt to be conservative when considering actions tak= en >>>>> on >>>>> duplicate messages. >>>> I'm OK with that almost as it is. If we're really addressing >>>> Message-IDs I think the last sentence would work better like this: >>>>=20 >>>> "Therefore, scripts are well advised to be conservative with respect >>>> to actions taken when duplicate messages are identified only by >>>> Message-ID." >>> I can agree with this text with Barry's modification, but where do you w= ant >>> to put this? At the end of Section 3 or in the Security Considerations? I= f >>> it is best put in Section 3 I should merge it somehow with the last >>> paragraph. >> I think it's best to stick it into the Security Considerations. >=20 > OK, will do. >=20 > Regards, >=20 > Stephan. From nobody Thu Jun 26 01:04:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BC81B2AF1; Thu, 26 Jun 2014 01:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCzhqsWc19gd; Thu, 26 Jun 2014 01:04:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A704D1B2AF4; Thu, 26 Jun 2014 01:04:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626080411.16932.58425.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 01:04:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XIDTp_H62PMbGRCvN2SLXvQ8oys Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-sieve-duplicate-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 08:04:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Sieve Email Filtering: Detecting Duplicate Deliveries Author : Stephan Bosch Filename : draft-ietf-appsawg-sieve-duplicate-08.txt Pages : 14 Date : 2014-06-26 Abstract: This document defines a new test command "duplicate" for the "Sieve" email filtering language. This test adds the ability to detect duplications. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header or other parts of the message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-sieve-duplicate-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 26 01:04:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A7B1B2AFF for ; Thu, 26 Jun 2014 01:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JvcQTDeIynA; Thu, 26 Jun 2014 01:04:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5441B2B05; Thu, 26 Jun 2014 01:04:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, ned+ietf@mrochek.com, apps-discuss@ietf.org, barryleiba@computer.org, Kathleen.Moriarty.ietf@gmail.com, alissa@cooperw.in X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626080411.16932.26513.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 01:04:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bi51p8OIeMzWucGnnKtgUdlSDdI Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-sieve-duplicate-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 08:04:16 -0000 A new version (-08) has been submitted for draft-ietf-appsawg-sieve-duplicate: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-sieve-duplicate-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-sieve-duplicate-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Jun 26 01:06:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472101B2AFF; Thu, 26 Jun 2014 01:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgQHXGSK9tBB; Thu, 26 Jun 2014 01:06:30 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6FEF1B2AE6; Thu, 26 Jun 2014 01:06:29 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:59538 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1X04h3-0000Bg-Tn; Thu, 26 Jun 2014 10:06:12 +0200 Message-ID: <53ABD42A.3010704@rename-it.nl> Date: Thu, 26 Jun 2014 10:04:58 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alissa Cooper , The IESG References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> In-Reply-To: <53A3E7EB.1030604@rename-it.nl> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SD6S3442TDChclRsCeTff1Ap8WM Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 08:06:32 -0000 Hi Alissa, On 6/20/2014 9:51 AM, Stephan Bosch wrote: >> o Section 3.2: >> "This means that it does not matter whether values are >> obtained from the message ID header, from an arbitrary header >> specified using the ":header" argument or explicitly from the >> ":uniqueid" argument. >> >> I had trouble understanding what "it does not matter" meant in this >> sentence. I would suggest: >> >> "This means that the values in the duplicate list should be used for >> duplicate testing regardless of whether they were >> obtained from the message ID header, from an arbitrary header >> specified using the ":header" argument or explicitly from the >> ":uniqueid" argument." > Ok, works for me. Applied in -08. Regards, Stephan. From nobody Thu Jun 26 01:10:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21071B2AF1; Thu, 26 Jun 2014 01:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tv-6N94rcsKP; Thu, 26 Jun 2014 01:10:22 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D9D1B2AFF; Thu, 26 Jun 2014 01:10:20 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:59743 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1X04ky-0000HL-3X; Thu, 26 Jun 2014 10:10:09 +0200 Message-ID: <53ABD51C.4010408@rename-it.nl> Date: Thu, 26 Jun 2014 10:09:00 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alissa Cooper References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A9E736.9080709@rename-it.nl> <01P9EFAYDH680049PU@mauve.mrochek.com> <53AA7206.7040905@rename-it.nl> <01P9EV40R78G0049PU@mauve.mrochek.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Fubfoy5IO-X1dHML2KQQynzYZWk Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 08:10:23 -0000 Hi Alissa, On 6/25/2014 12:58 PM, Alissa Cooper wrote: > "The list of unique IDs used for duplicate tracking can include > privacy-sensitive information, such as Message-ID values, content of > subject lines, and content extracted from message bodies. Implementations > SHOULD protect that information, by obscuring it through hashing (see the > note at the end of Section 3.2) and/or by storing it with a level of > access control equivalent to that of the messages themselves. > > These measures will not prevent an entity that has access to the duplicate > tracking list from querying whether messages with certain Message-ID > values were received. As this operation is the essence of the "duplicate" > test, this cannot be prevented, and may violate the expectations of the > user. For example, a user who downloads or deletes a message may expect > that no record of it remains on the server, but that will not be true if > its Message-ID is persisted on the server in the duplicate tracking list. > > It's notable, however, that server logs will often store the information > present on the duplicate tracking list anyway, and probably would expose > plaintext Message-IDs for a much longer period than this mechanism would. > Users of email services that intentionally delete such logs with the > intent of limiting traceability should be made aware that use of the > duplicate tracking mechanism re-exposes this information for the duration > of the expiry interval. In those situations, a shorter default expiry may > also be appropriate since users of these services may be willing to trade > off a more limited retention of the duplicate tracking list information > against the fact that every duplicate will not necessarily be eliminated > with a shorter expiry." Applied in -08. But I made the final paragraph a bit shorter. Regards, Stephan. From nobody Thu Jun 26 01:12:36 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05181B2AF1; Thu, 26 Jun 2014 01:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbLG62GMTtSL; Thu, 26 Jun 2014 01:12:32 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145491B2AF4; Thu, 26 Jun 2014 01:12:31 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:59818 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1X04mv-0000J3-KF; Thu, 26 Jun 2014 10:12:15 +0200 Message-ID: <53ABD595.3000901@rename-it.nl> Date: Thu, 26 Jun 2014 10:11:01 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kathleen Moriarty , Barry Leiba References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> <53A98428.106@qti.qualcomm.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------060506090103020500040907" X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00, HTML_MESSAGE autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gThJiH32lJxDDFBCZsCeaSkLeoQ Cc: Apps Discuss , Pete Resnick , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 08:12:34 -0000 This is a multi-part message in MIME format. --------------060506090103020500040907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Kathleen, Barry, On 6/24/2014 6:55 PM, Kathleen Moriarty wrote: > On Tue, Jun 24, 2014 at 11:54 AM, Barry Leiba > wrote: > > > OLD > In its basic form, the "duplicate" test keeps track of which > messages > were seen before by this test during an earlier Sieve execution. > Messages are by default identified by their message ID as contained > in the Message-ID header. The "duplicate" test evaluates to "true" > when the message was seen before and it evaluates to "false" > when it > was not. > NEW > The "duplicate" test identifies the message by a "unique ID", and, > using that unique ID, keeps track of which messages were seen > by a "duplicate" test during an earlier Sieve execution. In > its basic > form, the test gets the unique ID from the content of the message's > Message-ID header. The "duplicate" test evaluates to "true" when > the message was seen before and it evaluates to "false" when it > was not. > END > > > WFM and thank you. My words were meant to help the discussion and get > edited as needed. You are more familiar with the terminology used by > the group. > > > OLD > As a side-effect, the "duplicate" test adds the message ID to an > internal duplicate tracking list once the Sieve execution finishes > successfully. This way, the same test will evaluate to "true" > during > the next Sieve execution in which that message ID is encountered. > Note that this side-effect is performed only when the "duplicate" > test is actually evaluated. If the "duplicate" test is nested in a > control structure or it is not the first item of an "allof" or > "anyof" test list, its evaluation depends on the result of > preceding > tests, which may produce unexpected results. > NEW > As a side-effect, the "duplicate" test adds the unique ID to an > internal duplicate tracking list once the Sieve execution finishes > successfully. The first time a particular unique ID is seen, the > message is not a duplicate, and the unique ID is added to the > tracking list. If a future Sieve execution sees a message whose > unique ID appears in the tracking list, that test will evaluate to > "true", and that message will be considered a duplicate. > > Note that this side-effect is performed only when the "duplicate" > test is actually evaluated. If the "duplicate" test is nested in a > control structure or it is not the first item of an "allof" or > "anyof" test list, its evaluation depends on the result of > preceding > tests, which may produce unexpected results. > END > > > WFM, thank you! Applied in -08. Regards, Stephan. --------------060506090103020500040907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Kathleen, Barry,

On 6/24/2014 6:55 PM, Kathleen Moriarty wrote:
On Tue, Jun 24, 2014 at 11:54 AM, Barry Leiba <barryleiba@computer.org> wrote:

OLD
   In its basic form, the "duplicate" test keeps track of which messages
   were seen before by this test during an earlier Sieve execution.
   Messages are by default identified by their message ID as contained
   in the Message-ID header.  The "duplicate" test evaluates to "true"
   when the message was seen before and it evaluates to "false" when it
   was not.
NEW
   The "duplicate" test identifies the message by a "unique ID", and,
   using that unique ID,  keeps track of which messages were seen
   by a "duplicate" test during an earlier Sieve execution.  In its basic
   form, the test gets the unique ID from the content of the message's
   Message-ID header.  The "duplicate" test evaluates to "true" when
   the message was seen before and it evaluates to "false" when it
   was not.
END

WFM and thank you.  My words were meant to help the discussion and get edited as needed.  You are more familiar with the terminology used by the group.
  
OLD
   As a side-effect, the "duplicate" test adds the message ID to an
   internal duplicate tracking list once the Sieve execution finishes
   successfully.  This way, the same test will evaluate to "true" during
   the next Sieve execution in which that message ID is encountered.
   Note that this side-effect is performed only when the "duplicate"
   test is actually evaluated.  If the "duplicate" test is nested in a
   control structure or it is not the first item of an "allof" or
   "anyof" test list, its evaluation depends on the result of preceding
   tests, which may produce unexpected results.
NEW
   As a side-effect, the "duplicate" test adds the unique ID to an
   internal duplicate tracking list once the Sieve execution finishes
   successfully.  The first time a particular unique ID is seen, the
   message is not a duplicate, and the unique ID is added to the
   tracking list.  If a future Sieve execution sees a message whose
   unique ID appears in the tracking list, that test will evaluate to
   "true", and that message will be considered a duplicate.

   Note that this side-effect is performed only when the "duplicate"
   test is actually evaluated.  If the "duplicate" test is nested in a
   control structure or it is not the first item of an "allof" or
   "anyof" test list, its evaluation depends on the result of preceding
   tests, which may produce unexpected results.
END

WFM, thank you!

Applied in -08.

Regards,

Stephan.


--------------060506090103020500040907-- From nobody Thu Jun 26 01:13:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065291B2F2E; Thu, 26 Jun 2014 01:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1Gw3ngMvNu4; Thu, 26 Jun 2014 01:13:44 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78B01B2AF1; Thu, 26 Jun 2014 01:13:43 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:59844 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1X04oJ-0000K7-4l; Thu, 26 Jun 2014 10:13:41 +0200 Message-ID: <53ABD5EB.3080708@rename-it.nl> Date: Thu, 26 Jun 2014 10:12:27 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Barry Leiba References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> <53A98428.106@qti.qualcomm.com> <53A9DBC1.9000301@rename-it.nl> <53AA6DFF.9070008@rename-it.nl> In-Reply-To: <53AA6DFF.9070008@rename-it.nl> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3vq-uo7VoAKQbnaj-Od6J44VZO0 Cc: Apps Discuss , "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , Kathleen Moriarty , The IESG , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 08:13:48 -0000 Hi Kathleen, Barry, On 6/25/2014 8:36 AM, Stephan Bosch wrote: >>>>> Script writers using the duplicate test evaluation should be aware that >>>>> Message-IDs are not necessarily unique either through the fault of >>>>> benign >>>>> generators or attackers at some point prior to the Sieve filter >>>>> injecting a >>>>> message with the properties used by the duplicate Sieve filter. As >>>>> such, >>>>> script writers may opt to be conservative when considering actions taken >>>>> on >>>>> duplicate messages. >>>> I'm OK with that almost as it is. If we're really addressing >>>> Message-IDs I think the last sentence would work better like this: >>>> >>>> "Therefore, scripts are well advised to be conservative with respect >>>> to actions taken when duplicate messages are identified only by >>>> Message-ID." >>> I can agree with this text with Barry's modification, but where do you want >>> to put this? At the end of Section 3 or in the Security Considerations? If >>> it is best put in Section 3 I should merge it somehow with the last >>> paragraph. >> I think it's best to stick it into the Security Considerations. > OK, will do. Applied in -08. Regards, Stephan. From nobody Thu Jun 26 01:16:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37631B2AF5; Thu, 26 Jun 2014 01:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqDoM2hk5660; Thu, 26 Jun 2014 01:16:16 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1AD1B2AF1; Thu, 26 Jun 2014 01:16:16 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:59886 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1X04ql-0000O4-Kb; Thu, 26 Jun 2014 10:16:09 +0200 Message-ID: <53ABD683.3070002@rename-it.nl> Date: Thu, 26 Jun 2014 10:14:59 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ned Freed , Pete Resnick References: <20140625170022.6498.7940.idtracker@ietfa.amsl.com> <01P9FVBNQ1K40049PU@mauve.mrochek.com> In-Reply-To: <01P9FVBNQ1K40049PU@mauve.mrochek.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/p0Du9DIPV4SPQ2nAU54_m2jq5dk Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, The IESG , apps-discuss@ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org Subject: Re: [apps-discuss] Pete Resnick's No Objection on draft-ietf-appsawg-sieve-duplicate-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 08:16:18 -0000 Hi Pete, Ned, On 6/26/2014 3:36 AM, Ned Freed wrote: >> Pete Resnick has entered the following ballot position for >> draft-ietf-appsawg-sieve-duplicate-07: No Objection >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> And then change other occurrences of "message ID" to "unique identifier" >> elsewhere in the document as appropriate. > That's a good idea. Applied in -08. Regards, Stephan. From nobody Thu Jun 26 01:28:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D711B2F3B; Thu, 26 Jun 2014 01:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijn8ZNU3iSlr; Thu, 26 Jun 2014 01:28:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C8F1B2F3C; Thu, 26 Jun 2014 01:28:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626082844.30260.67659.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 01:28:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bHDCJuApmqAirVA9N9cuuetknwI Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Alissa Cooper's No Objection on draft-ietf-appsawg-sieve-duplicate-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 08:28:45 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-appsawg-sieve-duplicate-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS points. As for protecting scripts/address books in transit, per Ned's email, I would be interested to know if there is anyone interested in taking that work up. Or if not, if we could at least note it somewhere as an outstanding vulnerability -- maybe at https://trac.tools.ietf.org/group/ppm-legacy-review/ (which I can't load right now because the tools site seems to be down, so not sure if that is a good place)? From nobody Thu Jun 26 01:30:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCC11B2F3C; Thu, 26 Jun 2014 01:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BGp-z-qo6_R; Thu, 26 Jun 2014 01:30:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3AA1B2F40; Thu, 26 Jun 2014 01:30:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626083041.30509.91548.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 01:30:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/WCt9fi4hl1D7BjI9W6bQCcMem9k Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-sieve-duplicate-09.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 08:30:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Sieve Email Filtering: Detecting Duplicate Deliveries Author : Stephan Bosch Filename : draft-ietf-appsawg-sieve-duplicate-09.txt Pages : 14 Date : 2014-06-26 Abstract: This document defines a new test command "duplicate" for the "Sieve" email filtering language. This test adds the ability to detect duplications. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header or other parts of the message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-sieve-duplicate-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 26 01:30:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6981B2F3E for ; Thu, 26 Jun 2014 01:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIAZC_84Si2r; Thu, 26 Jun 2014 01:30:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D7B1B2F44; Thu, 26 Jun 2014 01:30:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, ned+ietf@mrochek.com, apps-discuss@ietf.org, barryleiba@computer.org, Kathleen.Moriarty.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626083041.30509.99619.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 01:30:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZKj1e2xcdJOiCtoVwkN-9Y7J2ro Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-sieve-duplicate-09.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 08:30:45 -0000 A new version (-09) has been submitted for draft-ietf-appsawg-sieve-duplicate: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-sieve-duplicate-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-sieve-duplicate-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Jun 26 01:32:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405741B2AD5; Thu, 26 Jun 2014 01:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJdzOrEZV37P; Thu, 26 Jun 2014 01:32:45 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8691B2F3C; Thu, 26 Jun 2014 01:32:44 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:60351 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1X056e-0000hk-Lq; Thu, 26 Jun 2014 10:32:38 +0200 Message-ID: <53ABDA5C.7010000@rename-it.nl> Date: Thu, 26 Jun 2014 10:31:24 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alissa Cooper , Barry Leiba References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/OuARaKKi5XBT6s80aPPidjJBIv4 Cc: "appsawg-chairs@tools.ietf.org" , "ned+ietf@mrochek.com" , The IESG , Apps Discuss , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 08:32:47 -0000 Hi Alissa, Barry, On 6/23/2014 4:29 PM, Alissa Cooper wrote: > On 6/20/14, 7:57 AM, "Barry Leiba" wrote: > >>>> "When the ":uniqueid" argument is used, such normalization >>>> concerns are the responsibility of the user." >>>> >>>> I don't quite get this. Do we expect users to, e.g., specify that >>>> uniqueid strings should only be compared after conversion to UTF-8? >>>> That >>>> would seem to rely on a level of technical sophistication that almost >>>> no >>>> users actually have. >>> I am not sure what exactly you mean here. The normalization concerns >>> listed before that sentence all apply to header field content, something >>> the author of a sieve script cannot control directly. With ":uniqueid" >>> the script author is directly responsible for the composition of the >>> unique ID value. [etc...] >> The problem here, really, is "the user", I think. >> >> What you really want to say, and something I don't think would make >> Alissa blink, is this: >> >> NEW >> When the ":uniqueid" argument is used, any normalization >> needs to be done in the Sieve script itself, as the unique ID >> is created. >> END > Yes, this solves my issue. Overlooked this one for -08, sorry. Addressed in -09. Regards, Stephan. From nobody Thu Jun 26 01:35:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55B91B2F44; Thu, 26 Jun 2014 01:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMe5LDpWBkJT; Thu, 26 Jun 2014 01:35:43 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543911B2AF1; Thu, 26 Jun 2014 01:35:43 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:60409 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1X059e-0000mJ-3o; Thu, 26 Jun 2014 10:35:41 +0200 Message-ID: <53ABDB15.7070900@rename-it.nl> Date: Thu, 26 Jun 2014 10:34:29 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Barry Leiba References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A9E736.9080709@rename-it.nl> <01P9EFAYDH680049PU@mauve.mrochek.com> <53AA7206.7040905@rename-it.nl> <01P9EV40R78G0049PU@mauve.mrochek.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/50cW4FBMVdOgYdeUkHvNY-9PU6w Cc: "appsawg-chairs@tools.ietf.org" , "ned+ietf@mrochek.com" , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , Apps Discuss , The IESG Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 08:35:44 -0000 Hi Barry, On 6/25/2014 2:19 PM, Barry Leiba wrote: > This is fine with me. Stephan, if it's OK with you also, please fold > in the changes coming from Alissa's and Kathleen's comments, and post > a revised I-D as soon as you can. If you can do it before the > Thursday telechat, A & K can clear their discusses. I think I have addressed all agreed changes. It took me more than one version, because I overlooked one change (It is never good to be in a bit of a hurry). Regards, Stephan. From nobody Thu Jun 26 01:53:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716CD1B2CF5; Thu, 26 Jun 2014 01:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1_Ta8Qdu1QE; Thu, 26 Jun 2014 01:53:26 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2183B1B2F4F; Thu, 26 Jun 2014 01:53:25 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id s18so1598726lam.6 for ; Thu, 26 Jun 2014 01:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pykftPdO+dKroxoMNcrHyteimSa0v1VIwKzUAadD0yI=; b=g51rbOoj2HKGD1XVo0ox5teiOU4Hfu3Uzog9K/vednuzvOL9JtdNFfDPIsKPdny6bT irvUC4OYAlRuJqO8rx9F6KSWue3txY/XNrkVtGjgCZ1jEu4T2lyIAwhJZnnUj4Z9cFUA e+Am+Yi0RzVo9hKX/I9JKAMZMEiQThzytwg4x1151+h/SwI6Owm9ZOgG8X1jcpoYeuoX Y8RRaz/JpS8zzoRspwfhAbCCki4kxfW3SHHW2HoS9zX9BfD2R9gqmK2YyKI11CibB1kr cSlGq4G9gjCCjC7Chegr9wi772CGIUf9sbqukhIhT0MLq8sYWgU+8seHhesILuIiD92A 4dYg== MIME-Version: 1.0 X-Received: by 10.152.23.136 with SMTP id m8mr10134315laf.2.1403772804428; Thu, 26 Jun 2014 01:53:24 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Thu, 26 Jun 2014 01:53:24 -0700 (PDT) In-Reply-To: <53ABDB15.7070900@rename-it.nl> References: <20140620004041.5801.22430.idtracker@ietfa.amsl.com> <53A3E7EB.1030604@rename-it.nl> <53A9E736.9080709@rename-it.nl> <01P9EFAYDH680049PU@mauve.mrochek.com> <53AA7206.7040905@rename-it.nl> <01P9EV40R78G0049PU@mauve.mrochek.com> <53ABDB15.7070900@rename-it.nl> Date: Thu, 26 Jun 2014 04:53:24 -0400 X-Google-Sender-Auth: 5qvFPrhohr2PO5-YF5eRedAfDfo Message-ID: From: Barry Leiba To: Stephan Bosch Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/yTg7Ve0KU9RDqc-GN8WzwU90yP4 Cc: "appsawg-chairs@tools.ietf.org" , "ned+ietf@mrochek.com" , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , Apps Discuss , The IESG Subject: Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 08:53:27 -0000 > I think I have addressed all agreed changes. It took me more than one > version, because I overlooked one change (It is never good to be in a > bit of a hurry). Meh... revisions are cheap. Alissa has cleared her DISCUSS. We'll if Kathleen agrees as well, when she wakes up in the morning (Alissa and I are in Europe this week). Barry From nobody Thu Jun 26 03:47:35 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE68D1B2B3C; Thu, 26 Jun 2014 03:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_uDS2U8zIQQ; Thu, 26 Jun 2014 03:47:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 591D11B2B35; Thu, 26 Jun 2014 03:47:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626104727.25948.90086.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 03:47:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Q70RK2aa8wtlNnpGEo1YY7qumuI Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-sieve-duplicate-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 10:47:29 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-appsawg-sieve-duplicate-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I wondered what'd happen if you used a DKIM-Signature header with this, but I guess it should just work. However, I don't recall if that header value is ok to compare case-sensitive (e.g. "d=" might not be?). I don't think any of your examples show how to do the tolower thing with a header field value, (or is that the default for "set"?) so I guess you could add one that does, but up to you, since I assume the intended readership know this stuff. Nothing to do with this draft in the end, but I think the security/privacy discussion ended up raising a couple of interesting issues that might be worth revisiting if/when someone has energy: those were a) if we could make some good privacy-friendly (but also admin friendly) recommendations about logging mail and b) if we could consider the privacy implications of sieve scripts or other filters (I liked the "stupid boss" folder name one, and am guilty of that for some of my own mail:-) and what those might expose. For (a) I could imagine a useful informational RFC, not sure for (b). From nobody Thu Jun 26 04:13:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33C01B2B12; Thu, 26 Jun 2014 04:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsSp9yAssiBr; Thu, 26 Jun 2014 04:13:43 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694A11B2A61; Thu, 26 Jun 2014 04:13:42 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id w7so2760482lbi.7 for ; Thu, 26 Jun 2014 04:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xzarMRqKFdMClecRtCYbiK/YZ2JE0pM0WXKSFgluzOc=; b=BS2GrvYohRK/OgTvgd9IhFmniKKNG/MdCGLg+MzL2zb7a+Rk3YebL4jFYYAriNQMBl +4Iz6rwLYxKZySI7lHNBx5LBuRUE94n6gp6q9uZ3siKBJIW5SGRiU7ZR4CxxCAwGo97A xJkPNoB52mg5S5+4KQX6432oApPHXNgpKkOa/38Qt/MZJNkw/Dl9x1sFlpttO3R8yX/w 2ZbJsuG7YHjohwcLcm0yCCEb2EVkCl/XAlUngZ3r1BcZ7hu/cvpVBAOjLl2hyxxSKtTP hFKEchEt3Q0YdpItNChxWiAk1Wm4fAMbi2r0QhDJBz1QuTuo2FoAiXCF9iO953cY9Fmw mUUw== MIME-Version: 1.0 X-Received: by 10.112.173.201 with SMTP id bm9mr10005217lbc.16.1403781220621; Thu, 26 Jun 2014 04:13:40 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Thu, 26 Jun 2014 04:13:40 -0700 (PDT) In-Reply-To: <20140626104727.25948.90086.idtracker@ietfa.amsl.com> References: <20140626104727.25948.90086.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 07:13:40 -0400 X-Google-Sender-Auth: 1s7Ouwep1h-15tAUQA4h5YuO-i4 Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oPkn1ie8WbpgNxJi_DjGQvobru0 Cc: "appsawg-chairs@tools.ietf.org" , "ned+ietf@mrochek.com" , The IESG , Apps Discuss , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-sieve-duplicate-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 11:13:44 -0000 > I wondered what'd happen if you used a DKIM-Signature > header with this, but I guess it should just work. Yeh, I think it should just work. For that case, I actually think the best approach would be to use the Variables extension to extract the hash from the DKIM "b=" tag, and use that for the unique ID. But even using the whole header field should work fine. > However, I don't recall if that header value is ok to > compare case-sensitive (e.g. "d=" might not be?). I'd think that shouldn't be an issue. If you're really looking for duplicates, it's probably fine to only consider them duplicates if they're exact matches. > Nothing to do with this draft in the end, but I think the > security/privacy discussion ended up raising a couple of > interesting issues that might be worth revisiting if/when > someone has energy: those were a) if we could make some > good privacy-friendly (but also admin friendly) > recommendations about logging mail and b) if we could > consider the privacy implications of sieve scripts or > other filters (I liked the "stupid boss" folder name one, > and am guilty of that for some of my own mail:-) and what > those might expose. For (a) I could imagine a useful > informational RFC, not sure for (b). Yeh. I think a "privacy issues with email deployment" document might be interesting to have. I don't know who would have the interest and energy to do it. Barry From nobody Thu Jun 26 04:57:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754DB1B2B5C; Thu, 26 Jun 2014 04:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vlhT68Kg6nE; Thu, 26 Jun 2014 04:57:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C93701B2B55; Thu, 26 Jun 2014 04:57:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626115717.25312.94352.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 04:57:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vURGEb5njhk591qOFI709l_S9HM Cc: Stefan Winter , appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Benoit Claise's No Objection on draft-ietf-appsawg-sieve-duplicate-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 11:57:19 -0000 Benoit Claise has entered the following ballot position for draft-ietf-appsawg-sieve-duplicate-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Background info: While doing a PC migration, along with an email migration, I found myself in the situation where - I had some duplicate emails in thunderbird - Some of my emails were already manually classified into folders. So it was hard to discover those without redoing the manual classification. This thunderbird add-on , http://removedupes.mozdev.org/, was very helpful to me. Discussing with Stephan Bosch, I understand that Thunderbird add-on is used to remove duplicates from the user's mailbox, after delivery, while this Sieve extension is used to detect duplicates while they are being delivered. This is performed using a persistent duplicate tracking list with unique ID values (typically the Message-ID) of previous deliveries and not by searching the destination folder(s) for messages with a matching ID. The issue with the SIEVE extension is that you have to enable this functionality in advance ... when you know that you're going to do something dangerous. Maybe that works ... but that reminds me of access-list management: "No, I will not do anything stupid! ... oops, I can't access my device any longer!". Or maybe you probably expect this SIEVE extension to be always on? I don't think it's mentioned. Along the same line (and with my use case in mind): Implementations SHOULD let entries in the tracking list expire after a short period of time. I was thinking: "short" = seconds, or minute. So not applicable to my email/PC migration use case. I saw later: A default expiration time of around 7 days is usually appropriate. Good. I like your 4 examples, but the one I was more interested into was: can we send the duplicates into the same folder. That would allow me to troubleshoot the root cause being the duplicates (subscribed to 2 mailing lists, synch issue, redirection, etc.) Bottom line: this draft could be improved by discussing the use cases you have in mind. Certainly not a blocking factor though From nobody Thu Jun 26 07:58:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9B51B2B90; Thu, 26 Jun 2014 07:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlNm1uqwaizp; Thu, 26 Jun 2014 07:58:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A633A1B2B99; Thu, 26 Jun 2014 07:11:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626141111.26730.58745.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 07:11:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_cly_XIB6645MilrI5xRTkwg2RM Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 14:58:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Email Authentication Status Codes Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-email-auth-codes-03.txt Pages : 7 Date : 2014-06-26 Abstract: There is at present no way to return a status code to an email client that indicates a message is being rejected or deferred specifically because of email authentication failures. This document registers codes for this purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-email-auth-codes-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-email-auth-codes-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 26 09:23:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04F61B30EE for ; Thu, 26 Jun 2014 09:23:40 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBB41s8rEC9j for ; Thu, 26 Jun 2014 09:23:37 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A101B3156 for ; Thu, 26 Jun 2014 08:41:36 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so3880830wgg.8 for ; Thu, 26 Jun 2014 08:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/nI7esNKGOJ+RkFvcQf6RzYWNpnW8q1DkPXXZi277Lo=; b=BWjzhGZYc4JMQDXq9KkfK9GcRqjsv5A3TKyew0Khj/OEhiJIei8HRft8lxSqGaFubI ob1IH8Gki+c0a9tIPEZPf5Q8SwfRujsfH7Kqy0H6hwl1vXK7s62sHUDeOF0G1ZDC1GHV DWTl35Rb6nR13Akei+hgE3L4AJ/mM8JmKJlQ/lrVposuDPAxcHdbLr4qMVaLkUmjObFc I0/LV3T+s/pgZgGAo37b/LnazxLV9bLzwt2f5QiaaDsJF9Fk1phgmZWejFLr213lSoS9 FIuzMBCj2WLawJBhGjNggL7wE+T+qcHFuaYqNrJYyfuykZL2BDiRNFwG/gLvymQAg3ey rrqg== MIME-Version: 1.0 X-Received: by 10.180.198.178 with SMTP id jd18mr5266465wic.24.1403797294316; Thu, 26 Jun 2014 08:41:34 -0700 (PDT) Received: by 10.180.19.74 with HTTP; Thu, 26 Jun 2014 08:41:34 -0700 (PDT) In-Reply-To: <20140626141111.26730.58745.idtracker@ietfa.amsl.com> References: <20140626141111.26730.58745.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 08:41:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b624e0e10895f04fcbf0758 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QiHRIIIpuYZuvVSdPV4Hos2Liig Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 16:23:41 -0000 --047d7b624e0e10895f04fcbf0758 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 26, 2014 at 7:11 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group Working > Group of the IETF. > > Title : Email Authentication Status Codes > Author : Murray S. Kucherawy > Filename : draft-ietf-appsawg-email-auth-codes-03.txt > Pages : 7 > Date : 2014-06-26 > > Abstract: > There is at present no way to return a status code to an email client > that indicates a message is being rejected or deferred specifically > because of email authentication failures. This document registers > codes for this purpose. > WGLC has been awfully quiet, so I'm taking this opportunity to post collected feedback to date. Still four days left for people to comment! -MSK --047d7b624e0e10895f04fcbf0758 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 26, 2014 at 7:11 AM, <internet-drafts= @ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Applications Area Working Group Work= ing Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Emai= l Authentication Status Codes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Murr= ay S. Kucherawy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-appsawg-email-auth-codes-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-06-26

Abstract:
=C2=A0 =C2=A0There is at present no way to return a status code to an email= client
=C2=A0 =C2=A0that indicates a message is being rejected or deferred specifi= cally
=C2=A0 =C2=A0because of email authentication failures. =C2=A0This document = registers
=C2=A0 =C2=A0codes for this purpose.

WG= LC has been awfully quiet, so I'm taking this opportunity to post colle= cted feedback to date.=C2=A0 Still four days left for people to comment!
-MSK
--047d7b624e0e10895f04fcbf0758-- From nobody Thu Jun 26 09:34:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D289E1B2B2F; Thu, 26 Jun 2014 04:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngMrocPhn_Gn; Thu, 26 Jun 2014 04:07:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0CE1B2B32; Thu, 26 Jun 2014 04:07:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626110717.12978.8030.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 04:07:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dTjxiCqD835yYMURvNTq2VboPP0 X-Mailman-Approved-At: Thu, 26 Jun 2014 09:34:42 -0700 Cc: appsawg-chairs@tools.ietf.org, ned+ietf@mrochek.com, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Kathleen Moriarty's No Objection on draft-ietf-appsawg-sieve-duplicate-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 11:07:20 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-appsawg-sieve-duplicate-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for clarifying my questions in the updated text! From nobody Thu Jun 26 09:34:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A321B2B2F; Thu, 26 Jun 2014 04:08:23 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaIkRSrLCN1j; Thu, 26 Jun 2014 04:08:21 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA191B2A9D; Thu, 26 Jun 2014 04:08:20 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id ty20so1753764lab.3 for ; Thu, 26 Jun 2014 04:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x6QlGr9p/0z+tf73F8Tz1kXWy5KC+hwUi8G/LwE7nmM=; b=00/vA69Z+mHv/jbGWhyid7eATftwnu0LnAav2Y7aGhkETxFuImLbNEjD3LIoHf86+j rwrP/4eNw+CEtvyrg+0iHATrA6NCKy7KaaNMbDzZup6doQ5LVyj2mqWM5139cadinPfm gl207Lutt8dv52j155qxLhyfK2pU7s2p5A8nmqdccs7EEsmMkv8nzsb8phoCiZrONRb+ GBooevCr8G5yfp6uEeiw4eO1gFNipWrPuG1CCpF4LfHQg5qtPWxAbHjY615OF7IMslFP ZIDYC9K1d5+Q6FE4kji0+HFXatxQPHd+Pjx3gMb7KEAsAbNlnyydr8QIyB3nKV7syBpc s/cg== MIME-Version: 1.0 X-Received: by 10.153.6.9 with SMTP id cq9mr894817lad.92.1403780898854; Thu, 26 Jun 2014 04:08:18 -0700 (PDT) Received: by 10.112.253.198 with HTTP; Thu, 26 Jun 2014 04:08:18 -0700 (PDT) In-Reply-To: <53ABD5EB.3080708@rename-it.nl> References: <20140623184900.17262.22283.idtracker@ietfa.amsl.com> <53A88421.60701@rename-it.nl> <53A8A7C5.80102@qti.qualcomm.com> <300281C7-B2DE-4419-984E-02F08EE32191@gmail.com> <8D7155B0-BC65-43A3-BE35-CB0CA702A358@gmail.com> <53A98428.106@qti.qualcomm.com> <53A9DBC1.9000301@rename-it.nl> <53AA6DFF.9070008@rename-it.nl> <53ABD5EB.3080708@rename-it.nl> Date: Thu, 26 Jun 2014 07:08:18 -0400 Message-ID: From: Kathleen Moriarty To: Stephan Bosch Content-Type: multipart/alternative; boundary=001a11349dc0d19b5a04fcbb3593 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/IolqambduOQ8Y-gTxUiFa-h99P8 X-Mailman-Approved-At: Thu, 26 Jun 2014 09:34:42 -0700 Cc: Apps Discuss , "draft-ietf-appsawg-sieve-duplicate@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Barry Leiba , "ned+ietf@mrochek.com" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 11:08:23 -0000 --001a11349dc0d19b5a04fcbb3593 Content-Type: text/plain; charset=UTF-8 Thank you, Stephan, the updated text looks good and I cleared my discuss. Thanks for taking time to work through the discussion and resulting text. On Thu, Jun 26, 2014 at 4:12 AM, Stephan Bosch wrote: > Hi Kathleen, Barry, > > On 6/25/2014 8:36 AM, Stephan Bosch wrote: > >>>>> Script writers using the duplicate test evaluation should be aware > that > >>>>> Message-IDs are not necessarily unique either through the fault of > >>>>> benign > >>>>> generators or attackers at some point prior to the Sieve filter > >>>>> injecting a > >>>>> message with the properties used by the duplicate Sieve filter. As > >>>>> such, > >>>>> script writers may opt to be conservative when considering actions > taken > >>>>> on > >>>>> duplicate messages. > >>>> I'm OK with that almost as it is. If we're really addressing > >>>> Message-IDs I think the last sentence would work better like this: > >>>> > >>>> "Therefore, scripts are well advised to be conservative with respect > >>>> to actions taken when duplicate messages are identified only by > >>>> Message-ID." > >>> I can agree with this text with Barry's modification, but where do you > want > >>> to put this? At the end of Section 3 or in the Security > Considerations? If > >>> it is best put in Section 3 I should merge it somehow with the last > >>> paragraph. > >> I think it's best to stick it into the Security Considerations. > > OK, will do. > > Applied in -08. > > Regards, > > Stephan. > -- Best regards, Kathleen --001a11349dc0d19b5a04fcbb3593 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you, Stephan, the updated text looks good and I clea= red my discuss. =C2=A0Thanks for taking time to work through the discussion= and resulting text.


On Thu, Jun 26, 2014 at 4:12 AM, Stephan Bosch <stephan@rename-it.nl> wrote:
Hi Kathleen, Barry,

On 6/25/2014 8:36 AM, Stephan Bosch wrote:
>>>>> Script writers using the duplicate test evaluation sho= uld be aware that
>>>>> Message-IDs are not necessarily unique either through = the fault of
>>>>> benign
>>>>> generators or attackers at some point prior to the Sie= ve filter
>>>>> injecting a
>>>>> message with the properties used by the duplicate Siev= e filter. =C2=A0As
>>>>> such,
>>>>> script writers may opt to be conservative when conside= ring actions taken
>>>>> on
>>>>> duplicate messages.
>>>> I'm OK with that almost as it is. =C2=A0If we're r= eally addressing
>>>> Message-IDs I think the last sentence would work better li= ke this:
>>>>
>>>> "Therefore, scripts are well advised to be conservati= ve with respect
>>>> to actions taken when duplicate messages are identified on= ly by
>>>> Message-ID."
>>> I can agree with this text with Barry's modification, but = where do you want
>>> to put this? At the end of Section 3 or in the Security Consid= erations? If
>>> it is best put in Section 3 I should merge it somehow with the= last
>>> paragraph.
>> I think it's best to stick it into the Security Considerations= .
> OK, will do.

Applied in -08.

Regards,

Stephan.



--
=

Best regards,
Kathleen
--001a11349dc0d19b5a04fcbb3593-- From nobody Thu Jun 26 09:35:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1A01B2C24 for ; Thu, 26 Jun 2014 08:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDvKE5XXARYj for ; Thu, 26 Jun 2014 08:37:07 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD771B3151 for ; Thu, 26 Jun 2014 07:43:28 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cc10so1175893wib.5 for ; Thu, 26 Jun 2014 07:43:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=muwJFxgoOirOMwAtbS6SeBeY2YiCB+Hg2XJiBEkjVtg=; b=dBbE6BuGVYWY/dVwz/R6AjbJB43G7LojwkavKBqee9qbvaO6qdiO10o06qqZPIa6Pq Tp7I+H9lyW7rNkdpRtL6AV4Y9wSsA5ikzBpIHTrcWRJrNr9/Qzd8kZXeBtX3buLCWg2+ sJt2RrejJ9DZjILiWBmwuxvXq3VyGY9ZuvqaQjuRq/ljc8VzU4tP5/gIrzMw44fhbdwP LBOwIKwU0F7vEf1qT6w6ktJFlNdgsaqGHkj817EXoeDpBW2BnXRRSYTUxRniWTKOGssO NN1OUqZaYTsYMy3sABZoioekudVPAoKGnbrV8ApZfpRg8ktMyC3wIrnbzjWL5D7GS7nE ux0Q== X-Gm-Message-State: ALoCoQnOMhOTuJq+2VteEpDkRVNofq1xplQ/Tki8WZa4PhiMUerlnYspMPryp2BXB0mmF89m9bVj X-Received: by 10.195.13.102 with SMTP id ex6mr17960304wjd.48.1403793802772; Thu, 26 Jun 2014 07:43:22 -0700 (PDT) Received: from [192.168.1.119] ([88.203.232.9]) by mx.google.com with ESMTPSA id i4sm25186350wib.21.2014.06.26.07.43.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 07:43:21 -0700 (PDT) Message-ID: <53AC3179.1010900@jitsi.org> Date: Thu, 26 Jun 2014 17:43:05 +0300 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Vijay K. Gurbani" , "apps-discuss@ietf.org" , draft-ietf-mmusic-latching@tools.ietf.org References: <537F520E.3060501@bell-labs.com> <538663F1.4080709@jitsi.org> <538C8820.1090900@bell-labs.com> <53A0B8CA.3080107@jitsi.org> <53AB1065.6030905@bell-labs.com> In-Reply-To: <53AB1065.6030905@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/e5TzQta-_P_FEk6D_QQiOVh_A_U X-Mailman-Approved-At: Thu, 26 Jun 2014 09:34:53 -0700 Cc: IESG IESG , mmusic Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-mmusic-latching-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 15:37:11 -0000 Great! Thanks very much Vijay! Emil On 25.06.14, 21:09, Vijay K. Gurbani wrote: > On 06/17/2014 04:53 PM, Emil Ivov wrote: >> Hey Vijay, >> >> Apologies for the delay! I believe we have addressed all comments and a >> new version is available here: >> >> Html: http://tools.ietf.org/html/draft-ietf-mmusic-latching-08 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-08 >> >> Please see inline for the rest of my responses (points of accord >> removed): > [...] > > Emil: Closing the loop on this one since I was pressed for time last > week (traveling). > > I am fine with your proposed changes and the diffs look good. I have no > further comments. > > Cheers, > > - vijay -- https://jitsi.org From nobody Thu Jun 26 10:21:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D5D1B2B32 for ; Thu, 26 Jun 2014 10:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIBKVIYrqBQz; Thu, 26 Jun 2014 10:21:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 759C91B2B83; Thu, 26 Jun 2014 10:21:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, ned+ietf@mrochek.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626172155.23515.8918.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 10:21:55 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/OsbkFF0LpEBNixPU3sToWreJVTU Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 17:21:57 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ From nobody Thu Jun 26 12:31:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180A71B2D17 for ; Thu, 26 Jun 2014 12:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDelKy87fGOx for ; Thu, 26 Jun 2014 12:31:17 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977D11B2CFF for ; Thu, 26 Jun 2014 12:31:16 -0700 (PDT) X-AuditID: c1b4fb2d-f798a6d000000e9b-ea-53ac75020403 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6A.5A.03739.2057CA35; Thu, 26 Jun 2014 21:31:14 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.222]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Thu, 26 Jun 2014 21:31:14 +0200 From: Salvatore Loreto To: "apps-discuss@ietf.org Discuss" Thread-Topic: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-email-auth-codes Thread-Index: AQHPkXUwRdTj3igg2kupoQ7qsKqmOQ== Date: Thu, 26 Jun 2014 19:31:13 +0000 Message-ID: References: <96700B03-80FF-4C2B-9887-2C3133EA4E86@ericsson.com> In-Reply-To: <96700B03-80FF-4C2B-9887-2C3133EA4E86@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_C32737D1F343435690753181B1D424CCericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+JvjS5T6Zpgg+X9BharX65gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtpLFgULxCu+XtnA3MD4X7iLkZNDQsBE4t+6W8wQtpjEhXvr 2boYuTiEBI4ySuw++x3KWcIosfnPMjaQKjYBM4nnD7eAdYgIWEvM/7AbzBYWiJL4cf0FG0Q8 WmLz77+sELaexNPbk8HiLAKqEsfPXQSzeQXsJZaeng/WKwRkL3+/hRHE5hRwkLjWNhUszgh0 0fdTa5hAbGYBcYlbT+YzQVwqILFkz3moq0UlXj7+xwphK0ksuv0ZqIYDqD5ZYsrjYIhVghIn Zz5hmcAoMgvJpFkIVbOQVEGU6Egs2P2JDcLWlli28DUzjH3mwGOoVmuJ/xNrkZUsYORYxSha nFpcnJtuZKyXWpSZXFycn6eXl1qyiREYVQe3/Nbdwbj6teMhRgEORiUe3oXxa4KFWBPLiitz DzFKc7AoifMuOjcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj0K9PV29ETQm21i9uXaeu KpnC47jHP/2jlY7qrKmreTXWNN1be+p4sWsKp4/S55tyE+3PMHh6Npzq/X3UP3BmWEVwt92V leHnmOdOlT6scGgdk6bU4UunHq188thr+ynO7MKDTFv+Hy3/75Q9jXnf2TjR7+5HT3dIVU/Z e1eiVoTtSm1FxnFZJZbijERDLeai4kQAkFYURIsCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LR4SUqqkTaASswox_SvBoEWmlgI Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 19:31:19 -0000 --_000_C32737D1F343435690753181B1D424CCericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable as reminder this WGLC ends in 4 days, on June 30, 2012 br Salvatore On Jun 13, 2014, at 12:12 PM, Salvatore Loreto > wrote: Colleagues, This note starts a Working Group Last Call for draft-ietf-appsawg-email-aut= h-codes-02. There has been a good mail discussion and couple of versions and now it see= ms to be stable and ready. Please provide review comments either on this list or privately to draft-ku= cherawy-email-auth-codes@tools.ietf.org on or before June 30, 2014. Also, if any participant has knowledge of IPR that needs to be declared on = this work, please do so, as required by BCPs 78 and 79. SM is fulfilling the duties of document shepherd. --_000_C32737D1F343435690753181B1D424CCericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5CCDA7AFE4F2454EA37B5BC25495A1E4@ericsson.com> Content-Transfer-Encoding: quoted-printable
as reminder 

this WGLC ends in 4 days, on June 30, 2012

br
Salvatore


On Jun 13, 2014, at 12:12 PM, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:<= /div>
Colleagues,

This note starts a Working Group Last Cal= l for draft-ietf-appsawg-email-auth-codes-02. 
There has been a good mail discussion and couple of versions and now i= t seems to be
stable and ready.

Please provide review comments either on this list or privately to&nbs= p;draft-kuc= herawy-email-auth-codes@tools.ietf.org on or before June 30, 2014.=

Also, if any participant has knowledge of IPR that needs to be declared on = this work, please do so, as required by BCPs 7= 8 and 79.

SM is fulfilling the duties of document shepherd.


--_000_C32737D1F343435690753181B1D424CCericssoncom_-- From nobody Fri Jun 27 09:50:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FFB1B2953 for ; Fri, 27 Jun 2014 09:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_Z7fohQKAO4 for ; Fri, 27 Jun 2014 09:50:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E59BB1B2B2C for ; Fri, 27 Jun 2014 09:49:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140627164959.21362.87986.idtracker@ietfa.amsl.com> Date: Fri, 27 Jun 2014 09:49:59 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sawdKJRGB8uuu6NQ0sUTBigez5Q Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 16:50:02 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-nullmx", set due date to June 2014 from May 2014. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Fri Jun 27 10:04:59 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9786C1B2964 for ; Fri, 27 Jun 2014 10:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXCJaSdLFrNm for ; Fri, 27 Jun 2014 10:04:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F741B2B3F for ; Fri, 27 Jun 2014 10:04:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140627170453.27435.53018.idtracker@ietfa.amsl.com> Date: Fri, 27 Jun 2014 10:04:53 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/j0BC8oUm48FnSZYUxJ9gCgBH1Rw Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 17:04:56 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-email-auth-codes", set due date to July 2014 from November 2014. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Fri Jun 27 10:58:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767D01A064C; Fri, 27 Jun 2014 10:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiSGXBrNlwlL; Fri, 27 Jun 2014 10:58:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E57001A03E0; Fri, 27 Jun 2014 10:57:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140627175754.3192.47880.idtracker@ietfa.amsl.com> Date: Fri, 27 Jun 2014 10:57:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VKQlU0ExPOJs87Pw1zahvcVJyJA Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 17:58:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A NULL MX Resource Record for Domains that Accept No Mail Authors : John Levine Mark Delany Filename : draft-ietf-appsawg-nullmx-05.txt Pages : 6 Date : 2014-06-27 Abstract: Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately this means that the A/ AAAA record is taken to be mail server address even when that address does not accept mail. The NULL MX RR formalizes the existing mechanism by which a domain announces that it accepts no mail, which permits significant operational efficiencies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-nullmx-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-nullmx-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 27 11:00:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E2B1A04C2 for ; Fri, 27 Jun 2014 11:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY7PpcwZoNay for ; Fri, 27 Jun 2014 11:00:31 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993961A03B4 for ; Fri, 27 Jun 2014 11:00:31 -0700 (PDT) Received: (qmail 19148 invoked from network); 27 Jun 2014 18:00:30 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 27 Jun 2014 18:00:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d3b7.53adb13e.k1406; i=johnl@user.iecc.com; bh=/MKA2JCrj6XVGqkFHn9he6WSiI8X9ijWjQb65qj9glA=; b=dt2c2n5kVIXiPw0ZpYZdFG/sHza5LaxmHVKY7GyMXDUIHPVdgSuBcQFgO7yYOLAZHb0FK3LrliqJRg1c5rKloZlI+TvT+zv536Nitf942TRAjI5ZNicxByH1sNSmMujH4ZRX7v/23f9bE45D/JHKZ7fvjmMdR8xFwcspFbYBdBREHGeXyGyTNews/ymj5LcY9uVn8dgRlvou3w8nAeOuNpLRDT/HCVLAWOO86sOqFHoB/y2Dy3736wW/5mylkC0+ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d3b7.53adb13e.k1406; olt=johnl@user.iecc.com; bh=/MKA2JCrj6XVGqkFHn9he6WSiI8X9ijWjQb65qj9glA=; b=Do01rcZ/GF8t3BEhE6GohUmkYelEJENu+8DTIW4kl84UfmM9JvatPbFP7Vz+Q6Y77nyK6KboYe8xYm8cpmqgvNMawtjBGpDZSwqDt2fPkaYb9oshyWV47eHMtFmgO4lfF+iUPnBoO8TzVH9QmwcBpcC3qDobkMNdlaqvpbYpsmopor+kBM1MeBP3xA+bCSxe//st2fg13lVGJa2tAY4jZHwgUqUeHSJt/Ql8R9m/x7+eivtThEk2YhB8u4fV0yDE Date: 27 Jun 2014 18:00:08 -0000 Message-ID: <20140627180008.54198.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <20140627175754.3192.47880.idtracker@ietfa.amsl.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3scwdtwcegMABrX6VREnfJedA8k Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jun 2014 18:00:33 -0000 This version fixes ID nits and has a little more minor editorial cleanup. For the record, I confirm that to my direct, personal knowledge there is no IPR related to this document. R's, John >A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : A NULL MX Resource Record for Domains that Accept No Mail > Authors : John Levine > Mark Delany > Filename : draft-ietf-appsawg-nullmx-05.txt > Pages : 6 > Date : 2014-06-27 > >Abstract: > Internet mail determines the address of a receiving server through > the DNS, first by looking for an MX record and then by looking for an > A/AAAA record as a fallback. Unfortunately this means that the A/ > AAAA record is taken to be mail server address even when that address > does not accept mail. The NULL MX RR formalizes the existing > mechanism by which a domain announces that it accepts no mail, which > permits significant operational efficiencies. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-appsawg-nullmx-05 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-nullmx-05 From nobody Sat Jun 28 06:41:44 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561E51A034A for ; Sat, 28 Jun 2014 06:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8je4Gta-6Ep for ; Sat, 28 Jun 2014 06:41:37 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF721A0268 for ; Sat, 28 Jun 2014 06:41:37 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id i13so4869960qae.5 for ; Sat, 28 Jun 2014 06:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=iM1xasI3C6wp3/bvQ6u3/1CDrh+OgYNadzh2NwFhm+I=; b=kTSzvNlev/w24PDhLo0/jpgsYXTlSkXa5fURu65x9iOQZgbD6kA2fv/c4VmyRXmyhp YgnvZFum0+g/wrvG2y50man8Sw4RM5EYlQC3IjuxVmhhHL31HDKQATrRqW/GsrjfgcpU D7cVhKtNNvaIZlwf0dLZigGHfZRLJd10LM152bSGzLxF81qbiXb0Z01Ip9/0DT5jCpsv tjq4l+t7HpQqwI9HqOZL/Bi+T1BACf9r+Ilb1udgZj+vMgYly7T2jhOVBJbaNyikYBvC a8xJDDnVcs7VFWKdnKawhO8aR+dbZnuLARIEY4eAonFnQfVE8kS8gAD7VcvS+UF+EcHo GuRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=iM1xasI3C6wp3/bvQ6u3/1CDrh+OgYNadzh2NwFhm+I=; b=dFkePAWVSOtS/ElW1Kv4/yFShTlsyCil+kLtpfN5EJ7ouhJp4iKsa2W7SNhnSJsek5 TGf23cXM2j2w2AvYgjpt8H1Z9x9DosWPb2ZoMvV6BxmzB/04liis7X3ckb6utFQLjz9y uPeUYy7ntFZcTlkZEVqoNUYxDVh2IrQ929knc9DfOT5VKP9bcdzKBCgey7fCOYITa15u wO4wATMAZTtsFz0ZNgOAVL32ugRKlkJWQULobrO7lJ0GWzjl1e/gr0ywVv+4cV4l8ozW uyujf8m81Qr0ODzX1qr3N6TR3K0OJLJSWCzUlusZjRewOyePH5uR87HJldakPqkhHls3 hXtQ== X-Gm-Message-State: ALoCoQlrcg3inSu8bHuDWMND+cVO2kmA7jvoBM8q/yFSKagcxUNITIsp4EOB+ZOBhfme0UhvGCaX X-Received: by 10.224.2.196 with SMTP id 4mr33924942qak.60.1403962896239; Sat, 28 Jun 2014 06:41:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.58.1 with HTTP; Sat, 28 Jun 2014 06:41:14 -0700 (PDT) From: Wei Chuang Date: Sat, 28 Jun 2014 06:41:14 -0700 Message-ID: To: dmarc@ietf.org, apps-discuss Content-Type: multipart/alternative; boundary=001a11c3bfdeb57cf404fce595cc Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/CP4teQ8JlBW8-xaP7DL1jXrGrl8 Subject: [apps-discuss] DKIM Forwarding History (Provenance) Proposal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jun 2014 13:41:41 -0000 --001a11c3bfdeb57cf404fce595cc Content-Type: text/plain; charset=ISO-8859-1 We propose the following enhancement to DKIM for tracking message changes relevant to authentication as a message is forwarded and modified by mail providers, typically mailing lists. At each SMTP delivery step, starting with the original sender and through all intermediate forwarders, the message must be DKIM signed. Each intermediate forwarder then adds a diff so that the recipient can recover the message as received by that forwarder and any earlier version. This change enables the recipient to verify the authenticity of the message and allows a more accurate decision for preventing abuse. In addition, it answers the problem of handling DMARC domains relayed through mailing lists. The advantage of this is that the recipient can recover the DKIM signed and verified message as received by the intermediate mail provider by reverse patching the diff, and can repeatedly apply this as necessary to recover the message sent by the original sender. Observing all versions of messages is most useful for Spam and Phishing detection in evaluating the reputation of the message. In particular one can observe the original sender's intent, and this is useful for example to verify that the original sender meant to send along a particular mail forwarding path or mailing-list. This proposal would introduce a new MIME CONTENT-TYPE: multipart/dkim-forwarding-history that would contain the diffs. Diffs between successive versions of the message are added sequentially as subparts to dkim-forwarding-history part. Diff parts are treated as attachments so that the user doesn't get confused by the contents. This particular proposal only works with 7-bit encoding, and a future proposal will deal with 8bit and binary. This process is illustrated in the example later. Note this isn't a full proposal as we would like the concept to be considered first. If this discussion is successful, we would like to also discuss a related improvement to SPF and DMARC, as well as the binary encoding change. At the conclusion we can have a longer discussion about the details of CONTENT-TYPE: multipart/dkim-forwarding-history or write a draft that tightly specifies how this works. ===== DKIM Forwarding History illustrative example Message is generated at Mymail and sent to mailing-list Yourgroup. Yourgroup modifies the subject line to indicate to the user which mailinglist the message went through. Then it is delivered to a Forwardmail which forwards without visible modifications to its ultimate destination at recipient@dest.org. Despite the lack of visible changes, the message at Forwardmail is likely modified with at least a Received header appended. At each intermediate domain, the SMTP server takes a diff of the message as it is to be sent including any modifications, and the received version excluding the diff contents and excluding the new DKIM signature since that's computed after the diff. The diff content is appended to the any previous diff content as an attachment. All diff content resides in a multipart/dkim-forwarding-history MIME part. After that, DKIM signing is done includes the header, original body, and diffs. If there is a previous DKIM header, it is removed, so that it is clear what the ownership is. The new DKIM header is added to the message header. Here's the message content that would be seen by the user. Original message: From: sender@mymail.com To: big-mailinglist@yourgroup.com Subject: I'm testing how DKIM forwarding history versioning works. This example illustrates how using diff and patch can obtain the message versions. -Sender Yourgroup message: From: sender@mymail.com To: big-mailinglist@yourgroup.com Subject: [big-mailinglist] I'm testing how DKIM forwarding history versioning works. This example illustrates how using diff and patch can obtain the message versions. -Sender Forwardmail message: From: sender@mymail.com To: big-mailinglist@yourgroup.com Subject: [big-mailinglist] I'm testing how DKIM forwarding history versioning works. This example illustrates how using diff and patch can obtain the message versions. -Sender Here's the more detailed description with the abbreviated RFC5322 message. Original message generated at mymail.com and sent to yourgroup.com. ====== DKIM-Signature: d=mymail.com ... From: sender@mymail.com To: big-mailinglist@yourgroup.com Subject: I'm testing how DKIM forwarding history versioning works. Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This example illustrates how using diff and patch can obtain the message versions. -Sender Yourgroup mailing list takes ownership of message and composes the following which is sent to Forwardmail. ===== DKIM-Signature: d=yourgroup.com ... From: sender@mymail.com To: big-mailinglist@yourgroup.com Subject: [big-mailinglist] I'm testing how DKIM forwarding history versioning works. Content-Type: multipart/mixed; boundary="ABC123" --ABC123 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This example illustrates how using diff and patch can obtain the message versions. -Sender --ABC123 Content-Type: multipart/dkim-forwarding-history; boundary="DFH456" --DFH456 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="message-25june2014_1301.patch" *** original-message-25june2014_1301.txt 2014-06-26 07:21:11.472671000 -0700 --- yourgroup-message-25june2014_1301.txt 2014-06-26 07:23:18.110909000 -0700 *************** *** 1 **** - DKIM-Signature: d=mymail.com ... --- 0 ---- *************** *** 4 **** ! Subject: I'm testing how DKIM forwarding history versioning works. --- 3,7 ---- ! Subject: [big-mailinglist] I'm testing how DKIM forwarding history versioning works. ! Content-Type: multipart/mixed; ! boundary="ABC123" ! ! --ABC123 *************** *** 9 **** --- 13,14 ---- + --ABC123 + --ABC123-- --DFH456-- --ABC123-- Forwarder Forwardmail takes ownership of message, composes the following and sends to recipient@dest.org. ===== DKIM-Signature: d=forwardmail.com ... From: sender@mymail.com To: big-mailinglist@yourgroup.com Subject: [big-mailinglist] I'm testing how DKIM forwarding history versioning works. Content-Type: multipart/mixed; boundary="ABC123" --ABC123 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This example illustrates how using diff and patch can obtain the message versions. -Sender --ABC123 Content-Type: multipart/dkim-forwarding-history; boundary="DFH456" --DFH456 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="message-25june2014_1301.patch" *** original-message-25june2014_1301.txt 2014-06-26 07:21:11.472671000 -0700 --- yourgroup-message-25june2014_1301.txt 2014-06-26 07:23:18.110909000 -0700 *************** *** 1 **** - DKIM-Signature: d=mymail.com ... --- 0 ---- *************** *** 4 **** ! Subject: I'm testing how DKIM forwarding history versioning works. --- 3,7 ---- ! Subject: [big-mailinglist] I'm testing how DKIM forwarding history versioning works. ! Content-Type: multipart/mixed; ! boundary="ABC123" ! ! --ABC123 *************** *** 9 **** --- 13,14 ---- + --ABC123 + --ABC123-- --DFH456 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="message-25june2014_1302.patch" *** yourgroup-message-25june2014_1302.txt 2014-06-26 07:43:31.055270000 -0700 *** forwardmail-message-25june2014_1302.txt 2014-06-26 07:43:13.518164000 -0700 *** 1 **** - DKIM-Signature: d=yourgroup.com ... --- 0 ---- --DFH456-- --ABC123-- --001a11c3bfdeb57cf404fce595cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

We propose the following enhancement to DKIM for tracking = message changes relevant to authentication as a message is forwarded and mo= dified by mail providers, typically mailing lists. At each SMTP delivery st= ep, starting with the original sender and through all intermediate forwarde= rs, the message must be DKIM signed. =A0Each intermediate forwarder then ad= ds a diff so that the recipient can recover the message as received by that= forwarder and any earlier version. =A0This change enables the recipient to= verify the authenticity of the message and allows a more accurate decision= for preventing abuse. In addition, it answers the problem of handling DMAR= C domains relayed through mailing lists. =A0The advantage of this is that t= he recipient can recover the DKIM signed and verified message as received b= y the intermediate mail provider by reverse patching the diff, and can repe= atedly apply this as necessary to recover the message sent by the original = sender. =A0Observing all versions of messages is most useful for Spam and P= hishing detection in evaluating the reputation of the message. =A0In partic= ular one can observe the original sender's intent, and this is useful f= or example to verify that the original sender meant to send along a particu= lar mail forwarding path or mailing-list.

This proposal would introduce a ne= w MIME CONTENT-TYPE: multipart/dkim-forwarding-history that would contain t= he diffs. =A0Diffs between successive versions of the message are added seq= uentially as subparts to dkim-forwarding-history part. =A0Diff parts are tr= eated as attachments so that the user doesn't get confused by the conte= nts. =A0This particular proposal only works with 7-bit encoding, and a futu= re proposal will deal with 8bit and binary. =A0This process is illustrated = in the example later.


Note this isn't a full proposal as we would like the concept = to be considered first. =A0If this discussion is successful, we would like = to also discuss a related improvement to SPF and DMARC, as well as the bina= ry encoding change. =A0At the conclusion we can have a longer discussion ab= out the details of CONTENT-TYPE: multipart/dkim-forwarding-history or write= a draft that tightly specifies how this works.


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

= DKIM Forwarding History illustrative example


Message is generated at Mymail and sent to mailing-list Yourgroup= . =A0Yourgroup modifies the subject line to indicate to the user which mail= inglist the message went through. =A0Then it is delivered to a Forwardmail = which forwards without visible modifications to its ultimate destination at= recipient@dest.org. =A0Despite t= he lack of visible changes, the message at Forwardmail is likely modified w= ith at least a Received header appended.


At each intermediate domain, the SMTP server takes a diff of the = message as it is to be sent including any modifications, and the received v= ersion excluding the diff contents and excluding the new DKIM signature sin= ce that's computed after the diff. =A0The diff content is appended to t= he any previous diff content as an attachment. =A0All diff content resides = in a multipart/dkim-forwarding-history MIME part. =A0After that, DKIM signi= ng is done includes the header, original body, and diffs. =A0If there is a = previous DKIM header, it is removed, so that it is clear what the ownership= is. The new DKIM header is added to the message header.


Here's the message content that would be seen by the user.

=
Original message:
 =A0From: sender@mymail.c= om
 =A0To: big-m= ailinglist@yourgroup.com
 =A0Subject: I'm testing how DKIM forwarding history versi= oning works.

 =A0This example illustrates how u= sing diff and patch can obtain the message versions.
 =A0-Sender

Yourgroup message: =A0From: sender@mymail.c= om
 =A0To: big-m= ailinglist@yourgroup.com
 =A0Subject: [big-mailinglist] I'm testing how DKIM forwar= ding history versioning works.
 =A0
 =A0This example illustrates how using diff and patch can obta= in the message versions.
 =A0-Sender

Forwardmail message:<= br class=3D""> =A0From: sender@mymail.c= om
 =A0To: big-m= ailinglist@yourgroup.com
 =A0Subject: [big-mailinglist] I'm testing how DKIM forwar= ding history versioning works.
 =A0
 =A0This example illustrates how using diff and patch can obta= in the message versions.
 =A0-Sender

Here's the more detailed descr= iption with the abbreviated RFC5322 message.

Original message generated at mymail.com and sent to yourgroup.com.
=3D=3D=3D=3D=3D=3D
 =A0DKIM-Signature: d=3Dmymail.c= om ...
 =A0From: sender@mymail.c= om
 =A0To: big-m= ailinglist@yourgroup.com
 =A0Subject: I'm testing how DKIM forwarding history versi= oning works.
 =A0Content-Type: text/plain; charset=3DUS-ASCII<= br class=3D""> =A0Content-Transfer-Encoding: 7bit
 =A0
 =A0This example illustrates how using diff and patch can obta= in the message versions.
 =A0-Sender

Yourgroup mailing list takes owner= ship of message and composes the following which is sent to Forwardmail.
=3D=3D=3D=3D=3D
 =A0DKIM-Signature: d=3Dyourg= roup.com ...
 =A0From: sender@mymail.c= om
 =A0To: big-m= ailinglist@yourgroup.com
 =A0Subject: [big-mailinglist] I'm testing how DKIM forwar= ding history versioning works.
 =A0Content-Type: multipart/mixed;
 =A0 <= /span>boundary=3D"ABC123"
 =A0
 =A0--ABC123
 =A0Content-Type: text/plain; charset=3DUS-ASCII<= br class=3D""> =A0Content-Transfer-Encoding: 7bit
 =A0
 =A0This example illustrates how using diff and patch can obta= in the message versions.
 =A0-Sender
 =A0--ABC123
 =A0Content-Type: multipart/dkim-forwarding-history;
 =A0 <= /span>boundary=3D"DFH456"

 =A0--DFH456
 =A0Content-Type: text/plain; charset=3DUS-ASCII<= br class=3D""> =A0Content-Transfer-Encoding: 7bit
 =A0Content-Disposition: attachment;
 =A0 <= /span>filename=3D"message-25june2014_1301.patch"

 =A0*** original-message-25june201= 4_1301.txt <= /span>2014-06-26 07:21:11.472671000 -0700
 =A0--- yourgroup-message-25june2014_1301.txt 2014-06-26 07:2= 3:18.110909000 -0700
 =A0***************
 =A0*** 1 ****
 =A0- DKIM-Signature: d=3Dmymail= .com ...
 =A0--- 0 ----
 =A0***************
 =A0*** 4 ****
 =A0! Subject: I'm testing how DKIM forwarding history ver= sioning works.
 =A0--- 3,7 ----
 =A0! Subject: [big-mailinglist] I'm testing how DKIM forw= arding history versioning works.
 =A0! Content-Type: multipart/mixed;
 =A0! =A0=A0=A0=A0=A0=A0boundary=3D"ABC123"
 =A0!
=A0! --ABC123
 =A0***************
 =A0*** 9 ****
 =A0--- 13,14 ----
 =A0+ --ABC123
 =A0+ --ABC123--
 =A0--DFH456--
 =A0--ABC123--


Forwarder Forwardmail takes ownership of message, composes the= following and sends to recipient@des= t.org.
=3D=3D=3D=3D=3D
 =A0DKIM-Signature: d=3Dfor= wardmail.com ...
 =A0From: sender@mymail.c= om
 =A0To: big-m= ailinglist@yourgroup.com
 =A0Subject: [big-mailinglist] I'm testing how DKIM forwar= ding history versioning works.
 =A0Content-Type: multipart/mixed;
 =A0 <= /span>boundary=3D"ABC123"
 =A0
 =A0--ABC123
 =A0Content-Type: text/plain; charset=3DUS-ASCII<= br class=3D""> =A0Content-Transfer-Encoding: 7bit
 =A0
 =A0This example illustrates how using diff and patch can obta= in the message versions.
 =A0-Sender
 =A0--ABC123
 =A0Content-Type: multipart/dkim-forwarding-history;
 =A0 <= /span>boundary=3D"DFH456"

 =A0--DFH456
 =A0Content-Type: text/plain; charset=3DUS-ASCII<= br class=3D""> =A0Content-Transfer-Encoding: 7bit
 =A0Content-Disposition: attachment;
 =A0 <= /span>filename=3D"message-25june2014_1301.patch"

 =A0*** original-message-25june201= 4_1301.txt <= /span>2014-06-26 07:21:11.472671000 -0700
 =A0--- yourgroup-message-25june2014_1301.txt 2014-06-26 07:2= 3:18.110909000 -0700
 =A0***************
 =A0*** 1 ****
 =A0- DKIM-Signature: d=3Dmymail= .com ...
 =A0--- 0 ----
 =A0***************
 =A0*** 4 ****
 =A0! Subject: I'm testing how DKIM forwarding history ver= sioning works.
 =A0--- 3,7 ----
 =A0! Subject: [big-mailinglist] I'm testing how DKIM forw= arding history versioning works.
 =A0! Content-Type: multipart/mixed;
 =A0! =A0=A0=A0=A0=A0=A0boundary=3D"ABC123"
 =A0!
=A0! --ABC123
 =A0***************
 =A0*** 9 ****
 =A0--- 13,14 ----
 =A0+ --ABC123
 =A0+ --ABC123--
 =A0--DFH456
 =A0Content-Type: text/plain; charset=3DUS-ASCII<= br class=3D""> =A0Content-Transfer-Encoding: 7bit
 =A0Content-Disposition: attachment;
 =A0 <= /span>filename=3D"message-25june2014_1302.patch"

 =A0*** yourgroup-message-25june20= 14_1302.txt = 2014-06-26 07:43:31.055270000 -0700
 =A0*** forwardmail-message-25june2014_1302.txt =A0=A0=A0=A0= =A0=A02014-06-26 07:43:13.518164000 -0700
 =A0*** 1 ****
 =A0- DKIM-Signature: d=3Dyou= rgroup.com ...
 =A0--- 0 ----
 =A0--DFH456--
 =A0--ABC123--


--001a11c3bfdeb57cf404fce595cc-- From nobody Sat Jun 28 08:22:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D1A1A0354 for ; Sat, 28 Jun 2014 08:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.102 X-Spam-Level: X-Spam-Status: No, score=-100.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mM0PJ8k7RxmY for ; Sat, 28 Jun 2014 08:22:38 -0700 (PDT) Received: from secure.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 713101A034E for ; Sat, 28 Jun 2014 08:22:38 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2002; t=1403968949; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=1G2rellS6jhUnbKZ9Gw8WyPUfEo=; b=hGwHLoW/ezAFJHH+YWA4 UAhKBRnVz3XWs8DSIGK/raq6oLtMJpCzj5K/X8QOI0RXtlFp1BVP16N4X3zolLOJ 58PfMVj2yNrlD4FGWVsObqM4vPPw8VueZ7VMVlmRFih8XweE5GNvCU6XrZLvXjFx TmzHRBEWXAFCjr8kmG3Pvoo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 28 Jun 2014 11:22:29 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3449054340.7425.5820; Sat, 28 Jun 2014 11:22:28 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2002; t=1403968748; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=DbvSZNN aG16ckngxizjOCPCDPyVzUCJTPjjuzwUjvPg=; b=gTLyQSFhnAsffBtTtwnEDmJ lg8WrQ3Id+sRYBOAi+IzKQecvqDlKT/BANmHyRfRxQKFqKV/cmSLepmUW4wb6nyt zRECaobubtoIzqlBYJwjdBTphZ9G0TnM1ft0lO89ExO9sLVhZmKw8R5wgaUmNTP6 7Ikg4CvAnKWcy7N/+Sss= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 28 Jun 2014 11:19:08 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3465394406.9.1380; Sat, 28 Jun 2014 11:19:06 -0400 Message-ID: <53AEDDB5.8080702@isdg.net> Date: Sat, 28 Jun 2014 11:22:29 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Wei Chuang , dmarc@ietf.org, apps-discuss References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wxKPOTYZV7ToHBscVfHhub1k7eQ Subject: Re: [apps-discuss] [dmarc-ietf] DKIM Forwarding History (Provenance) Proposal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jun 2014 15:22:41 -0000 On 6/28/2014 9:41 AM, Wei Chuang wrote: > Note this isn't a full proposal as we would like the concept to be > considered first. If this discussion is successful, we would like to also > discuss a related improvement to SPF and DMARC, as well as the binary > encoding change. At the conclusion we can have a longer discussion about > the details of CONTENT-TYPE: multipart/dkim-forwarding-history or write a > draft that tightly specifies how this works. Wei, Any "chain of trust" idea will work with a honored client/server negotiated protocol steps and ideals. The problem has always been in dealing with the deviation from the ideal protocol steps and compliancy expectations. So if you have a protocol ABC, what are the benefits of this ABC processing? What is the payoff for the compliant mail receiver? What is the payoff for the originating/author domain? What happens when there is deviation, something broke in the chain of MIME diffs? What do you want receivers to do? You must think of the massive volume of wasteful mail processing. Not everyone is going to do this just for nothing. It has to have a meaningful payoff, and today that payoff comes in the form of mail filtering policies with rejection/quarantine/discard author domain policy concepts. So if your proposal says: "If you follow these steps, the author domain is OK with you (because you asked him) honoring rejection, if you see a problem, then there is something wrong with it and its better (trust the author policy) if you just reject it." then we you got something to consider. But I think in this case, your proposal is a higher processing complexity factor when all you need to do is ask the author if the final/last signature in the chain is an trusted and/or authorized signer domain. If you are not asking the author (directly or indirectly) if any of this forwarding stuff is ok, then I think you have a security conflict (loophole) to consider. -- HLS From nobody Sat Jun 28 17:02:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2F11A01E4 for ; Sat, 28 Jun 2014 17:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBUah36UUVGA for ; Sat, 28 Jun 2014 17:02:11 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795C61A01E1 for ; Sat, 28 Jun 2014 17:02:11 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id x3so5914663qcv.10 for ; Sat, 28 Jun 2014 17:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PulpK46ZuP3ix/aYEGqHt2m4FxJD5zN0uYFRunQBab0=; b=EZt0t0AnTkWOTLJNCLAxArt74SwcwKOmu9IzQVcOHtMuPOqFEWSeF7uMFQc326xYXG EMvXA1xFSPP/LkRq++Qv0X9eBgwUZIGinQUcC7/2Ad/yWBvl0rZWkvrpyGm4/+6MXu/G ZNeg/BJF+/I8B4XmEALmfbZzPQoqtQSGaxGK5yPruGtxZ2/I6AFaC9EdNkkxmnoenxZ7 Q41q97uYmggDchA/yKyBA6FVZIDyhGc8i7fxg+PIi3aU2Zw5CYt/9bhkcnB5Se8mQycr oEWkrG9BH4ZORLJGWxoB+7Y3t2lTQlGjSk5a426Eiv375HTxRseuKLEX5LwyDtSUHTaD T2YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PulpK46ZuP3ix/aYEGqHt2m4FxJD5zN0uYFRunQBab0=; b=UCI7BIn6TfkZnych8L4mC4/FTbd8U5eqT8fK+cw47URiRuKNq/ucc2BQzmv9tbZJHz x1lpDN7h82qVFrhZzrvMYlTXH64U/bvuyEkwJsHoHMXRBvyWYo3/vAlJNatrZ2r4jELD dTEpZftaHt8tbgLaD7HL+O+f2tw2giIs4IUEdCXM0NtmQKwKeZ/bmE+7veQr2jEhVs5L 17GNqs22K5LTDV3vkrFV8/KeB2tdggIUolRYvxJ54vLzgwfLE8iaw6Pxwld3kQsGapW8 JAh7HlIQomM+98sxQKY5L/qLz7UcWkQiO/jWVpV1QcT8bm7s3XVqFdRYAKEpYRbnkg36 Q3qA== X-Gm-Message-State: ALoCoQmhnAYhMlX2xKR1zbrpFxkiUc8d3uwGyvKCAq5VMwHftDqgcvD+DDY+ZnZPV8JIFRzxcTWF X-Received: by 10.140.107.132 with SMTP id h4mr19100685qgf.83.1404000130522; Sat, 28 Jun 2014 17:02:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.58.1 with HTTP; Sat, 28 Jun 2014 17:01:49 -0700 (PDT) In-Reply-To: <53AEDDB5.8080702@isdg.net> References: <53AEDDB5.8080702@isdg.net> From: Wei Chuang Date: Sat, 28 Jun 2014 17:01:49 -0700 Message-ID: To: Hector Santos Content-Type: multipart/alternative; boundary=001a113a79960b813204fcee4142 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iWdGcAhP6gpj74_Fc_T674b5IXc Cc: dmarc@ietf.org, apps-discuss Subject: Re: [apps-discuss] [dmarc-ietf] DKIM Forwarding History (Provenance) Proposal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2014 00:02:15 -0000 --001a113a79960b813204fcee4142 Content-Type: text/plain; charset=ISO-8859-1 Hi Hector On Sat, Jun 28, 2014 at 8:22 AM, Hector Santos wrote: > On 6/28/2014 9:41 AM, Wei Chuang wrote: > >> Note this isn't a full proposal as we would like the concept to be >> considered first. If this discussion is successful, we would like to also >> discuss a related improvement to SPF and DMARC, as well as the binary >> encoding change. At the conclusion we can have a longer discussion about >> the details of CONTENT-TYPE: multipart/dkim-forwarding-history or write a >> draft that tightly specifies how this works. >> > > Wei, > > Any "chain of trust" idea will work with a honored client/server > negotiated protocol steps and ideals. > > The problem has always been in dealing with the deviation from the ideal > protocol steps and compliancy expectations. > > So if you have a protocol ABC, what are the benefits of this ABC > processing? What is the payoff for the compliant mail receiver? What is > the payoff for the originating/author domain? The benefit is that the recipient can authenticate the originating sender and in particular a particular action such as sending to a mailing list, yet allow intermediate domains to modify messages. It may be that a user has a filter to see all messages from the original sender. This is jumping ahead a bit, but the current DMARC paradigm is for the mailing list to own the message and rewrite the RFC5322.FROM which make this difficult. In addition SPAM filters likely can benefit from being able to process the original message and know message was authenticated by the original sending domain. > What happens when there is deviation, something broke in the chain of MIME > diffs? What do you want receivers to do? > In this proposal, it would be the same as failing DKIM RFC 6376 verification. It ought to be treated as information the recipient domain can use for additional Spam processing etc but not necessarily indicate reject or other action. This proposal is meant to build infrastructure that can be used to enhance DMARC in a subsequent proposal. By itself this proposal primarily provides extra information (well a strong guarantee on the authenticity and modifications) for Spam processing. > > You must think of the massive volume of wasteful mail processing. Not > everyone is going to do this just for nothing. It has to have a meaningful > payoff, and today that payoff comes in the form of mail filtering policies > with rejection/quarantine/discard author domain policy concepts. > > So if your proposal says: > > "If you follow these steps, the author domain > is OK with you (because you asked him) honoring > rejection, if you see a problem, then there is > something wrong with it and its better (trust the > author policy) if you just reject it." > > then we you got something to consider. > > But I think in this case, your proposal is a higher processing complexity > factor when all you need to do is ask the author if the final/last > signature in the chain is an trusted and/or authorized signer domain. If > you are not asking the author (directly or indirectly) if any of this > forwarding stuff is ok, then I think you have a security conflict > (loophole) to consider. > > I'm probably misunderstanding your intent. Here's a stab at a response: Passing the DKIM Provenance verification is meant to provide a stronger verification from a purported original sender. If intermediates want to claim that a mail came from some original sender, then they have to provide evidence. If they don't due maliciousness or otherwise, they don't have to include such evidence but they won't get any benefit of claiming the reputation of the original sender. -Wei PS It was mentioned offline that the discussion on dmarc@ietf is currently restricted to building the WG charter. First apologies I missed that. Second I can restrict subsequent discussion to apps-discuss if that's preferred by the WG. --001a113a79960b813204fcee4142 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hector

On Sat, Jun 28, 2014 at 8:22 AM, Hector Santos <hsa= ntos@isdg.net> wrote:
On 6/28/2014 9:41 AM, Wei Chuang wrote:
Note this isn't a full proposal as we would like the concept to be
considered first. =A0If this discussion is successful, we would like to als= o
discuss a related improvement to SPF and DMARC, as well as the binary
encoding change. =A0At the conclusion we can have a longer discussion about=
the details of CONTENT-TYPE: multipart/dkim-forwarding-history or wr= ite a
draft that tightly specifies how this works.

Wei,

Any "chain of trust" idea will work with a honored client/server = negotiated protocol steps and ideals.

The problem has always been in dealing with the deviation from the ideal pr= otocol steps and compliancy expectations.

So if you have a protocol ABC, what are the benefits of this ABC processing= ? =A0What is the payoff for the compliant mail receiver? =A0What is the pay= off for the originating/author domain? =A0

The benefit is that the recipient can authenticate the originating sender a= nd in particular a particular action such as sending to a mailing list, yet= allow intermediate domains to modify messages. =A0It may be that a user ha= s a filter to see all messages from the original sender. =A0This is jumping= ahead a bit, but the current DMARC paradigm is for the mailing list to own= the message and rewrite the RFC5322.FROM which make this difficult. =A0In = addition SPAM filters likely can benefit from being able to process the ori= ginal message and know message was authenticated by the original sending do= main.
=A0
What happens when there is deviation, someth= ing broke in the chain of MIME diffs? =A0What do you want receivers to do?<= br>

In this proposal, it would be the same as = failing DKIM RFC=A06376=A0verification. =A0It ought to be treated as information the recipient d= omain can use for additional Spam processing etc but not necessarily indica= te reject or other action. =A0This proposal is meant to build infrastructur= e that can be used to enhance DMARC in a subsequent proposal. =A0By itself = this proposal primarily provides extra information (well a strong guarantee= on the authenticity and modifications) for Spam processing.
=A0

You must think of the massive volume of wasteful mail processing. Not every= one is going to do this just for nothing. It has to have a meaningful payof= f, and today that payoff comes in the form of mail filtering policies with = rejection/quarantine/discard author domain policy concepts.

So if your proposal says:

=A0 =A0"If you follow these steps, the author domain
=A0 =A0 is OK with you (because you asked him) honoring
=A0 =A0 rejection, if you see a problem, then there is
=A0 =A0 something wrong with it and its better (trust the
=A0 =A0 author policy) if you just reject it."

then we you got something to consider.

But I think in this case, your proposal is a higher processing complexity f= actor when all you need to do is ask the author if the final/last signature= in the chain is an trusted and/or authorized signer domain. =A0 If you are= not asking the author (directly or indirectly) if any of this forwarding s= tuff is ok, then I think you have a security conflict (loophole) to conside= r.


I'm probably misunde= rstanding your intent. =A0Here's a stab at a response: Passing the DKIM= Provenance verification is meant to provide a stronger verification from a= purported original sender. =A0If intermediates want to claim that a mail c= ame from some original sender, then they have to provide evidence. =A0If th= ey don't due maliciousness or otherwise, they don't have to include= such evidence but they won't get any benefit of claiming the reputatio= n of the original sender.

-Wei

PS It was mentioned = offline that the discussion on dmarc@ietf is currently restricted to buildi= ng the WG charter. =A0First apologies I missed that. =A0Second I can restri= ct subsequent discussion to apps-discuss if that's preferred by the WG.=

--001a113a79960b813204fcee4142-- From nobody Sat Jun 28 18:26:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBE11A01E7 for ; Sat, 28 Jun 2014 18:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiyXgXJhEn-K for ; Sat, 28 Jun 2014 18:26:16 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347971A01E6 for ; Sat, 28 Jun 2014 18:26:15 -0700 (PDT) Received: (qmail 93743 invoked from network); 29 Jun 2014 01:26:14 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 29 Jun 2014 01:26:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13cfe.53af6b36.k1406; i=johnl@user.iecc.com; bh=WpzVPBtNyFbPjnp3ApupzbQDnZr3uyfw3z4nqd+2KiM=; b=vSLSAuV09qyExJ1xczOOqnor1cdnGpKYIXcDJbtKrvVWn+nQYN7NFf5lnZbO6sGKbl1MCPySlUsQV5AzzVXGYYHzfM2QtLHmpew9Q7jDHTQSCihHUqx/BnbzGPVg6RnQerQXfzZXkIS9MwH2VfFdHZxP0w7xFJOhVFoTQryQGNHjQYTZvSmhBMZ966KkUDjobObkjmJynrGtcrNlC4/fF92d26TrNR3GDyEVasqFpn527nOhVHiHRmfqY/r0YmQv DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13cfe.53af6b36.k1406; olt=johnl@user.iecc.com; bh=WpzVPBtNyFbPjnp3ApupzbQDnZr3uyfw3z4nqd+2KiM=; b=moivppxx0w41yUkUDyPGG0GBtTdD4JHleQKu86ldtYiIeS5YNNv3HcWCJ6sK0So1i3Yu9QWnMhflyOxe7SeAoeEbQuXDut+sTpjwSSUh51afSGUaAZrrz44vvIp5LAKmJ2awHTVPw4OjySPd/3Ps1hpTIrqyb5Os7krkUTLJgoaYhsiQgCo8P2wf778umRpatSaPNrEeIMUFhDoNZ7neJRUL2CagMWQkOXeV2GXev9fsPYw0xBKm+z+2JLpK2AaZ Date: 29 Jun 2014 01:25:52 -0000 Message-ID: <20140629012552.81149.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wFtH4jsKft2XJBh46HekcqpeN68 Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2014 01:26:18 -0000 >This proposal would introduce a new MIME CONTENT-TYPE: >multipart/dkim-forwarding-history that would contain the diffs. It's an interesting idea, but I see two immediate issues: a) it requires extensive changes to both list managers and MUAs, which history tells us are not likely to happen b) the problem it solves doesn't seem to be the one we have It is my impression that a host that appears to be a forwarder will act pretty consistently, making whatever changes it makes to the messages coming through. So if it starts sending spam, that's almost certainly because for some reason (poor filtering, spoofing, etc) it's forwarding mail that was already spam when it arrived at the forwarder. So if the forwarder can pass through enough info to reconstruct not the original message, but the original authentication info, which will say among other things whether the original message was DMARC aligned. That's specifically what Original-Authentication-Results is intended to do, and one of the things you could do with my weak conditional signatures. They're not bulletproof, but they don't have to be if you believe that it's not common for well behaved forwarders to suddenly turn malicious. Beyond that, there'd be the issue of deciding how much change was "too much". There are some fairly normal changes that lists make that are semantically minor but cause vast changes to the message text, e.g., reordering or deleting parts. recoding from 8bit to base64, or flattening HTML to text. R's, John From nobody Sun Jun 29 07:58:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40EAC1A0021 for ; Sun, 29 Jun 2014 07:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTxXtI52i8gs for ; Sun, 29 Jun 2014 07:58:39 -0700 (PDT) Received: from secure.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 04FFC1A001B for ; Sun, 29 Jun 2014 07:58:38 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=15856; t=1404053911; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=DWqEA9G BR66fhXDk5Apxhccl4gU=; b=jwbAFIUAg+8OaaQ7PE9L0Mw2cL5QQKaGvCKJ68B 2w2OfzBfkvU750B/fVDd4gJohkrvPQ+uk10azps4vLSGBkXjjcKN1Zs04KxXV1hx MrNaMLqpeiMhXKT3rcCBl/BQFUFLTGB+REEl417frz7H3fXA7KAN5ilyqc1FPEmP 4FSU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sun, 29 Jun 2014 10:58:31 -0400 Received: from [192.168.1.67] (99-121-4-27.lightspeed.miamfl.sbcglobal.net [99.121.4.27]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3534015433.687.1100; Sun, 29 Jun 2014 10:58:30 -0400 References: <53AEDDB5.8080702@isdg.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-86302092-99B1-4050-A843-122F42CA0F0C Content-Transfer-Encoding: 7bit Message-Id: <4A3194BC-A940-4365-B848-BD930650B33F@isdg.net> X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Sun, 29 Jun 2014 10:58:27 -0400 To: Wei Chuang Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FqBI1wWCaQxNjsqToXWGvMlCZg0 Cc: "dmarc@ietf.org" , apps-discuss Subject: Re: [apps-discuss] [dmarc-ietf] DKIM Forwarding History (Provenance) Proposal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2014 14:58:44 -0000 --Apple-Mail-86302092-99B1-4050-A843-122F42CA0F0C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Wei, =20 IMO, your proposal is on par with the engineering considerations needed to d= evelop and mold the charter. Your proposal intent is to preserve the integr= ity and indirectly, the authorization for forwarding, resigning mail. The d= raft charter has its own even higher complex ideas for the same intent. My i= ntent is to keep it simple with 3rd party authorization framework and I don'= t see any other better method than a DNS-based lookup method for resigning a= uthorization or allowance. I believe in strong rejection author domain poli= cies. You can't standardize random, subjective heuristic methods, but you ca= n standardize deterministic protocol methods. This is the wider, network per= sistent and consistent solution that everyone can use.=20 If your offline moderation control messenger intent was to steer the work to= wards a specific more. complex, DKIM changing direction, and any negative di= scussion about it or censoring other better alternatives, and specifically a= uthorization methods, are out of scope, then I don't wish to spend any more t= ime, money and resources in what I strongly believe is going to be a big was= te of time, doesn't resolve the problem, nor does it eliminate the need to d= o DNS lookups. =20 The ADs need to consider more engineering solutions views that are outside t= he same typical folks who have long had control of this project. We are her= e today because the DKIM project leaders were incorrect in their presumption= s about the market needs, directions and they seem to be repeating it again.= I don't want to go thru this costly error again. The draft charter as wri= tten is too complex and IMO, it will not solve the main problem we always ha= d which is how to authorize and scale resigners. =20 Your idea is really not that different than what Murray and Dave want to pur= sue in the draft with a higher level DKIM processing complexity, long term p= rospects which I believe are not necessary and probably unrealistic to belie= ve people are going to blindly accept with even more expense in long term ex= perimentation. DKIM was just made into an STD document last year and already= there is consideration in changing. Thanks -- Hector Santos http://www.santronics.com > On Jun 28, 2014, at 8:01 PM, Wei Chuang wrote: >=20 > Hi Hector >=20 >> On Sat, Jun 28, 2014 at 8:22 AM, Hector Santos wrote: >>> On 6/28/2014 9:41 AM, Wei Chuang wrote: >>> Note this isn't a full proposal as we would like the concept to be >>> considered first. If this discussion is successful, we would like to al= so >>> discuss a related improvement to SPF and DMARC, as well as the binary >>> encoding change. At the conclusion we can have a longer discussion abou= t >>> the details of CONTENT-TYPE: multipart/dkim-forwarding-history or write a= >>> draft that tightly specifies how this works. >>=20 >> Wei, >>=20 >> Any "chain of trust" idea will work with a honored client/server negotiat= ed protocol steps and ideals. >>=20 >> The problem has always been in dealing with the deviation from the ideal p= rotocol steps and compliancy expectations. >>=20 >> So if you have a protocol ABC, what are the benefits of this ABC processi= ng? What is the payoff for the compliant mail receiver? What is the payoff= for the originating/author domain? =20 >=20 > The benefit is that the recipient can authenticate the originating sender a= nd in particular a particular action such as sending to a mailing list, yet a= llow intermediate domains to modify messages. It may be that a user has a f= ilter to see all messages from the original sender. This is jumping ahead a= bit, but the current DMARC paradigm is for the mailing list to own the mess= age and rewrite the RFC5322.FROM which make this difficult. In addition SPA= M filters likely can benefit from being able to process the original message= and know message was authenticated by the original sending domain. > =20 >> What happens when there is deviation, something broke in the chain of MIM= E diffs? What do you want receivers to do? >=20 > In this proposal, it would be the same as failing DKIM RFC 6376 verificati= on. It ought to be treated as information the recipient domain can use for a= dditional Spam processing etc but not necessarily indicate reject or other a= ction. This proposal is meant to build infrastructure that can be used to e= nhance DMARC in a subsequent proposal. By itself this proposal primarily pr= ovides extra information (well a strong guarantee on the authenticity and mo= difications) for Spam processing. > =20 >>=20 >> You must think of the massive volume of wasteful mail processing. Not eve= ryone is going to do this just for nothing. It has to have a meaningful payo= ff, and today that payoff comes in the form of mail filtering policies with r= ejection/quarantine/discard author domain policy concepts. >>=20 >> So if your proposal says: >>=20 >> "If you follow these steps, the author domain >> is OK with you (because you asked him) honoring >> rejection, if you see a problem, then there is >> something wrong with it and its better (trust the >> author policy) if you just reject it." >>=20 >> then we you got something to consider. >>=20 >> But I think in this case, your proposal is a higher processing complexity= factor when all you need to do is ask the author if the final/last signatur= e in the chain is an trusted and/or authorized signer domain. If you are n= ot asking the author (directly or indirectly) if any of this forwarding stuf= f is ok, then I think you have a security conflict (loophole) to consider. >=20 > I'm probably misunderstanding your intent. Here's a stab at a response: P= assing the DKIM Provenance verification is meant to provide a stronger verif= ication from a purported original sender. If intermediates want to claim th= at a mail came from some original sender, then they have to provide evidence= . If they don't due maliciousness or otherwise, they don't have to include s= uch evidence but they won't get any benefit of claiming the reputation of th= e original sender. >=20 > -Wei >=20 > PS It was mentioned offline that the discussion on dmarc@ietf is currently= restricted to building the WG charter. First apologies I missed that. Sec= ond I can restrict subsequent discussion to apps-discuss if that's preferred= by the WG. >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-86302092-99B1-4050-A843-122F42CA0F0C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Wei,  

IMO, your proposal is on par with the engineering considerations needed to= develop and mold the charter.  Your proposal intent is to preserve the= integrity and indirectly, the authorization for forwarding, resigning mail.=   The draft charter has its own even higher complex ideas for the same= intent.  My intent is to keep it simple with 3rd party authorization f= ramework and I don't see any other better method than a DNS-based lookup met= hod for resigning authorization or allowance.  I believe in strong reje= ction author domain policies. You can't standardize random, subjective heuri= stic methods, but you can standardize deterministic protocol methods. This i= s the wider, network persistent and consistent solution that everyone can us= e. 

If your offline moderation control messeng= er intent was to steer the work towards a specific more. complex, DKIM chang= ing direction, and any negative discussion about it or censoring other bette= r alternatives, and specifically authorization methods, are out of scope, th= en I don't wish to spend any more time, money and resources in what I strong= ly believe is going to be a big waste of time, doesn't resolve the problem, n= or does it eliminate the need to do DNS lookups.  

=
The ADs need to consider more engineering solutions views that are outs= ide the same typical folks who have long had control of this project.  = We are here today because the DKIM project leaders were incorrect in their p= resumptions about the market needs, directions and they seem to be repeating= it again.  I don't want to go thru this costly error again.  The d= raft charter as written is too complex and IMO, it will not solve the main p= roblem we always had which is how to authorize and scale resigners.  &n= bsp;

Your idea is really not that different than wh= at Murray and Dave want to pursue in the draft with a higher level DKIM proc= essing complexity, long term prospects which I believe are not necessary and= probably unrealistic to believe people are going to blindly accept with eve= n more expense in long term experimentation. DKIM was just made into an STD d= ocument last year and already there is consideration in changing.
=
Thanks

<= /div>

On Jun 28, 2014, at 8:01 PM, Wei Chuang <weihaw@google.com> wrote:

Hi Hector

On Sat, Jun 28, 2014 at 8:22 AM, He= ctor Santos <hsantos@isdg.net> wrote:
On 6/28/2014 9:41 AM, Wei Chuang wrote:
Note this isn't a full proposal as we would like the concept to be
considered first.  If this discussion is successful, we would like to a= lso
discuss a related improvement to SPF and DMARC, as well as the binary
encoding change.  At the conclusion we can have a longer discussion abo= ut
the details of CONTENT-TYPE: multipart/dkim-forwarding-history or wri= te a
draft that tightly specifies how this works.

Wei,

Any "chain of trust" idea will work with a honored client/server negotiated p= rotocol steps and ideals.

The problem has always been in dealing with the deviation from the ideal pro= tocol steps and compliancy expectations.

So if you have a protocol ABC, what are the benefits of this ABC processing?=  What is the payoff for the compliant mail receiver?  What is the= payoff for the originating/author domain?  

The benefit is that the recipient can authenticate the originating sender an= d in particular a particular action such as sending to a mailing list, yet a= llow intermediate domains to modify messages.  It may be that a user ha= s a filter to see all messages from the original sender.  This is jumpi= ng ahead a bit, but the current DMARC paradigm is for the mailing list to ow= n the message and rewrite the RFC5322.FROM which make this difficult.  = In addition SPAM filters likely can benefit from being able to process the o= riginal message and know message was authenticated by the original sending d= omain.
 
What happens when there is deviation, someth= ing broke in the chain of MIME diffs?  What do you want receivers to do= ?

In this proposal, it would be the same as f= ailing DKIM RFC 6376&nbs= p;verification.  It ought to be treated as information the recip= ient domain can use for additional Spam processing etc but not necessarily i= ndicate reject or other action.  This proposal is meant to build infras= tructure that can be used to enhance DMARC in a subsequent proposal.  B= y itself this proposal primarily provides extra information (well a strong g= uarantee on the authenticity and modifications) for Spam processing.
 

You must think of the massive volume of wasteful mail processing. Not everyo= ne is going to do this just for nothing. It has to have a meaningful payoff,= and today that payoff comes in the form of mail filtering policies with rej= ection/quarantine/discard author domain policy concepts.

So if your proposal says:

   "If you follow these steps, the author domain
    is OK with you (because you asked him) honoring
    rejection, if you see a problem, then there is
    something wrong with it and its better (trust the
    author policy) if you just reject it."

then we you got something to consider.

But I think in this case, your proposal is a higher processing complexity fa= ctor when all you need to do is ask the author if the final/last signature i= n the chain is an trusted and/or authorized signer domain.   If you are= not asking the author (directly or indirectly) if any of this forwarding st= uff is ok, then I think you have a security conflict (loophole) to consider.=


I'm probably misunderstan= ding your intent.  Here's a stab at a response: Passing the DKIM Proven= ance verification is meant to provide a stronger verification from a purport= ed original sender.  If intermediates want to claim that a mail came fr= om some original sender, then they have to provide evidence.  If they d= on't due maliciousness or otherwise, they don't have to include such evidenc= e but they won't get any benefit of claiming the reputation of the original s= ender.

-Wei

PS It was mentioned o= ffline that the discussion on dmarc@ietf is currently restricted to building= the WG charter.  First apologies I missed that.  Second I can res= trict subsequent discussion to apps-discuss if that's preferred by the WG.

____________________= ___________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mai= lman/listinfo/dmarc
= --Apple-Mail-86302092-99B1-4050-A843-122F42CA0F0C-- From nobody Sun Jun 29 14:59:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092C11A0030; Sun, 29 Jun 2014 14:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alR9GJ6PkXaK; Sun, 29 Jun 2014 14:58:59 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64B21A002B; Sun, 29 Jun 2014 14:58:59 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.242.155.89]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 967B822E1F4; Sun, 29 Jun 2014 17:58:52 -0400 (EDT) Message-ID: <53B08C20.30805@seantek.com> Date: Sun, 29 Jun 2014 14:58:56 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: urn-nid@ietf.org, saag@ietf.org, apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/WDZfXOhDgzIPA1Aw9O5PLcf4hmg Subject: [apps-discuss] draft-seantek-certspec-03; request review and URN assignment X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2014 21:59:01 -0000 Hello URN/Apps folks, and SAAG folks: A new version of the Internet-Draft draft-seantek-certspec (03) has been = posted to the IETF repository. I would like to notify this list for comme= ntary, and utlimately to apply for the URN NID 'cert'. Compared to 02 last year, this version addresses concerns raised both on = and off the lists. The ABNF is tighter. URNBIS work is referenced more co= nsistently, instead of the legacy RFC 2141. issuersn (issuer and serial n= umber) is given extensive consideration, and is both more restrictive (in= the strict grammar in Section 5.3.1) and more well-defined (in the relax= ed grammar for human input in Appendix A). Appendix B now represents the = state-of-the-art for mandatory LDAP attributes. Kind regards, Sean ************** A new version of I-D, draft-seantek-certspec-03.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-certspec Revision: 03 Title: A Uniform Resource Name (URN) Namespace for Certificates Document date: 2014-06-29 Group: Individual Submission Pages: 21 URL:http://www.ietf.org/internet-drafts/draft-seantek-certspec-03.txt Status:https://datatracker.ietf.org/doc/draft-seantek-certspec/ Htmlized:http://tools.ietf.org/html/draft-seantek-certspec-03 Diff:http://www.ietf.org/rfcdiff?url2=3Ddraft-seantek-certspec-03 Abstract: Digital certificates are used in many systems and protocols to identify and authenticate parties. This document describes a Uniform= Resource Name (URN) namespace that identifies certificates. These URNs can be used when certificates need to be identified by value or reference. From nobody Sun Jun 29 16:54:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E312F1A0051 for ; Sun, 29 Jun 2014 16:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.671 X-Spam-Level: X-Spam-Status: No, score=0.671 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dK2lx4O4Mus8 for ; Sun, 29 Jun 2014 16:54:01 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187DF1A004E for ; Sun, 29 Jun 2014 16:54:00 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id x12so5747812qac.21 for ; Sun, 29 Jun 2014 16:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Hlo/fnzvpV1ETv8neLn0VGINrZbT57UDU50VQUmh3Wo=; b=memClb5QLKy5PLl/cvb5y5iC0C1MKjf8hjqK4rkRg2S6bV/MP+Fu/d/kfr1rIorQ2a poXP2phcUgYtwbAgHNrGScuPe4m+PYOqXGn+eStadppadFwJkpqWhLlowoesEl2w2IeY 6N6eS+BYROs7MduMafi3pm/0ym7S9hD4KkQ/YM1sl6/i6x2Q1WnpUmnpym3X5uLWGLdb p480GtnR/4An7TW9bJjhFohEfr+01Z0BBeeif8nPsSRszoqxw8UUL/2NnqrpXxJeoA0M zFYu+VdOyGfH6Q8eMPpolfo/g42TJR9s7vQGdDTeSAoc5lRTg726c0L8YFVx/XL62VwX e+gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Hlo/fnzvpV1ETv8neLn0VGINrZbT57UDU50VQUmh3Wo=; b=bZiZJitKh3D1KzXLxdjgJHvMecjIhvUmNiYQia3/q/b0Pp5sJI3ueBgUrm+F8RjtDi hCxqZEzom58VIVNZ6Hk2sKpfu5zxE5TfmTxWNymtcpM7tw5IewMO1aeuSN3zg7HPfQMq kY2+qYDMxYWfy3eR9p+l+ZOMv407TW+dt0DWjwyOY2m9sHzJp5lmY9IjU6zhnIXWt2iP 0qmzl+ZuN169dzhMCel530dO7S3UwzI0sag8kWWRozx+z2zHdXuXWIBIEK7OlOKv0cUz fgFwJ4NHF+tjyNQFjnK85deAX0zdB+gAhNw4narzjDTvdx1j1Jn5H5eirZZFpbI0obdW D33w== X-Gm-Message-State: ALoCoQlgvDCKATizKzuwcDcQSAvgaCGGW8shaWD6cUgrR9uGy76FXKq22hoLSzI4CK1d7wNwWthl X-Received: by 10.224.104.10 with SMTP id m10mr55731957qao.27.1404086040124; Sun, 29 Jun 2014 16:54:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.58.1 with HTTP; Sun, 29 Jun 2014 16:53:39 -0700 (PDT) In-Reply-To: <4A3194BC-A940-4365-B848-BD930650B33F@isdg.net> References: <53AEDDB5.8080702@isdg.net> <4A3194BC-A940-4365-B848-BD930650B33F@isdg.net> From: Wei Chuang Date: Sun, 29 Jun 2014 16:53:39 -0700 Message-ID: To: Hector Santos Content-Type: multipart/alternative; boundary=001a11c1ca16a80aa504fd024106 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JqPz-wZXAYp0yaav9Sxi5fZcfvM Cc: "dmarc@ietf.org" , apps-discuss Subject: Re: [apps-discuss] [dmarc-ietf] DKIM Forwarding History (Provenance) Proposal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2014 23:54:04 -0000 --001a11c1ca16a80aa504fd024106 Content-Type: text/plain; charset=ISO-8859-1 Hi Hector, On Sun, Jun 29, 2014 at 7:58 AM, Hector Santos wrote: > Hi Wei, > > IMO, your proposal is on par with the engineering considerations needed to > develop and mold the charter. Your proposal intent is to preserve the > integrity and indirectly, the authorization for forwarding, resigning mail. > The draft charter has its own even higher complex ideas for the same > intent. My intent is to keep it simple with 3rd party authorization > framework and I don't see any other better method than a DNS-based lookup > method for resigning authorization or allowance. I believe in strong > rejection author domain policies. You can't standardize random, subjective > heuristic methods, but you can standardize deterministic protocol methods. > This is the wider, network persistent and consistent solution that everyone > can use. > > If your offline moderation control messenger intent was to steer the work > towards a specific more. complex, DKIM changing direction, and any negative > discussion about it or censoring other better alternatives, and > specifically authorization methods, are out of scope, then I don't wish to > spend any more time, money and resources in what I strongly believe is > going to be a big waste of time, doesn't resolve the problem, nor does it > eliminate the need to do DNS lookups. > > The person sending me mail offline was just mentioning the WG status as justifying why he brought his conversation offline. I had seen comments regarding the charter status in some recent emails, but when I looked for the ground rules for the mailing list, couldn't find it. I was updated that a spam filter removed the earlier ground rules email. > The ADs need to consider more engineering solutions views that are outside > the same typical folks who have long had control of this project. We are > here today because the DKIM project leaders were incorrect in their > presumptions about the market needs, directions and they seem to be > repeating it again. I don't want to go thru this costly error again. The > draft charter as written is too complex and IMO, it will not solve the main > problem we always had which is how to authorize and scale resigners. > > Your idea is really not that different than what Murray and Dave want to > pursue in the draft with a higher level DKIM processing complexity, long > term prospects which I believe are not necessary and probably unrealistic > to believe people are going to blindly accept with even more expense in > long term experimentation. DKIM was just made into an STD document last > year and already there is consideration in changing. > This proposal means to use DKIM as a building block and doesn't call for changing the DKIM spec. I think there's an opportunity with DMARC IETF standardization process to revisit some of the features that restrict its deployment. The ultimate direction of these proposals will be advance some ideas to address them. I agree that changing the goal posts is a difficult thing, but then preventing Spam and Phishing on our users is also a pretty powerful motivator. I would say that DKIM, SPF, and DMARC are attractive tools to prevent Spam and Phishing and making changes to facilitating their deployment is justified. -Wei > > Thanks > > -- > Hector Santos > http://www.santronics.com > > On Jun 28, 2014, at 8:01 PM, Wei Chuang wrote: > > Hi Hector > > On Sat, Jun 28, 2014 at 8:22 AM, Hector Santos wrote: > >> On 6/28/2014 9:41 AM, Wei Chuang wrote: >> >>> Note this isn't a full proposal as we would like the concept to be >>> considered first. If this discussion is successful, we would like to >>> also >>> discuss a related improvement to SPF and DMARC, as well as the binary >>> encoding change. At the conclusion we can have a longer discussion about >>> the details of CONTENT-TYPE: multipart/dkim-forwarding-history or write >>> a >>> draft that tightly specifies how this works. >>> >> >> Wei, >> >> Any "chain of trust" idea will work with a honored client/server >> negotiated protocol steps and ideals. >> >> The problem has always been in dealing with the deviation from the ideal >> protocol steps and compliancy expectations. >> >> So if you have a protocol ABC, what are the benefits of this ABC >> processing? What is the payoff for the compliant mail receiver? What is >> the payoff for the originating/author domain? > > > The benefit is that the recipient can authenticate the originating sender > and in particular a particular action such as sending to a mailing list, > yet allow intermediate domains to modify messages. It may be that a user > has a filter to see all messages from the original sender. This is jumping > ahead a bit, but the current DMARC paradigm is for the mailing list to own > the message and rewrite the RFC5322.FROM which make this difficult. In > addition SPAM filters likely can benefit from being able to process the > original message and know message was authenticated by the original sending > domain. > > >> What happens when there is deviation, something broke in the chain of >> MIME diffs? What do you want receivers to do? >> > > In this proposal, it would be the same as failing DKIM RFC 6376 verification. > It ought to be treated as information the recipient domain can use for > additional Spam processing etc but not necessarily indicate reject or other > action. This proposal is meant to build infrastructure that can be used to > enhance DMARC in a subsequent proposal. By itself this proposal primarily > provides extra information (well a strong guarantee on the authenticity and > modifications) for Spam processing. > > >> >> You must think of the massive volume of wasteful mail processing. Not >> everyone is going to do this just for nothing. It has to have a meaningful >> payoff, and today that payoff comes in the form of mail filtering policies >> with rejection/quarantine/discard author domain policy concepts. >> >> So if your proposal says: >> >> "If you follow these steps, the author domain >> is OK with you (because you asked him) honoring >> rejection, if you see a problem, then there is >> something wrong with it and its better (trust the >> author policy) if you just reject it." >> >> then we you got something to consider. >> >> But I think in this case, your proposal is a higher processing complexity >> factor when all you need to do is ask the author if the final/last >> signature in the chain is an trusted and/or authorized signer domain. If >> you are not asking the author (directly or indirectly) if any of this >> forwarding stuff is ok, then I think you have a security conflict >> (loophole) to consider. >> >> > I'm probably misunderstanding your intent. Here's a stab at a response: > Passing the DKIM Provenance verification is meant to provide a stronger > verification from a purported original sender. If intermediates want to > claim that a mail came from some original sender, then they have to provide > evidence. If they don't due maliciousness or otherwise, they don't have to > include such evidence but they won't get any benefit of claiming the > reputation of the original sender. > > -Wei > > PS It was mentioned offline that the discussion on dmarc@ietf is > currently restricted to building the WG charter. First apologies I missed > that. Second I can restrict subsequent discussion to apps-discuss if > that's preferred by the WG. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a11c1ca16a80aa504fd024106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Hector,

On Sun, Jun 29, 2014 at 7:58 AM, Hector Santos <hsantos@= isdg.net> wrote:
Hi Wei, =A0

IMO, your proposal is on par with the engineering considera= tions needed to develop and mold the charter. =A0Your proposal intent is to= preserve the integrity and indirectly, the authorization for forwarding, r= esigning mail. =A0 The draft charter has its own even higher complex ideas = for the same intent. =A0My intent is to keep it simple with 3rd party autho= rization framework and I don't see any other better method than a DNS-b= ased lookup method for resigning authorization or allowance. =A0I believe i= n strong rejection author domain policies. You can't standardize random= , subjective heuristic methods, but you can standardize deterministic proto= col methods. This is the wider, network persistent and consistent solution = that everyone can use.=A0

If your offline moderation control messenger intent was= to steer the work towards a specific more. complex, DKIM changing directio= n, and any negative discussion about it or censoring other better alternati= ves, and specifically authorization methods, are out of scope, then I don&#= 39;t wish to spend any more time, money and resources in what I strongly be= lieve is going to be a big waste of time, doesn't resolve the problem, = nor does it eliminate the need to do DNS lookups. =A0


The person sending me= mail offline was just mentioning the WG status as justifying why he brough= t his conversation offline. =A0I had seen comments regarding the charter st= atus in some recent emails, but when I looked for the ground rules for the = mailing list, couldn't find it. =A0I was updated that a spam filter rem= oved the earlier ground rules email.
=A0
<= div>The ADs need to consider more engineering solutions views that are outs= ide the same typical folks who have long had control of this project. =A0We= are here today because the DKIM project leaders were incorrect in their pr= esumptions about the market needs, directions and they seem to be repeating= it again. =A0I don't want to go thru this costly error again. =A0The d= raft charter as written is too complex and IMO, it will not solve the main = problem we always had which is how to authorize and scale resigners. =A0=A0=

Your idea is really not that different than what Murray= and Dave want to pursue in the draft with a higher level DKIM processing c= omplexity, long term prospects which I believe are not necessary and probab= ly unrealistic to believe people are going to blindly accept with even more= expense in long term experimentation. DKIM was just made into an STD docum= ent last year and already there is consideration in changing.

This proposal means to use DKIM as a= building block and doesn't call for changing the DKIM spec. =A0I think= there's an opportunity with DMARC IETF standardization process to revi= sit some of the features that restrict its deployment. =A0The ultimate dire= ction of these proposals will be advance some ideas to address them. =A0I a= gree that changing the goal posts is a difficult thing, but then preventing= Spam and Phishing on our users is also a pretty powerful motivator. =A0I w= ould say that DKIM, SPF, and DMARC are attractive tools to prevent Spam and= Phishing and making changes to facilitating their deployment is justified.=

-Wei
=A0
=

Thanks

--Hector Santos

On Jun 28, 2014,= at 8:01 PM, Wei Chuang <weihaw@google.com> wrote:

Hi Hector

On Sat, Ju= n 28, 2014 at 8:22 AM, Hector Santos <hsantos@isdg.net> wrote= :
On 6/28/2014 9:41 AM, Wei Chuang wrote:
Note this isn't a full proposal as we would like the concept to be
considered first. =A0If this discussion is successful, we would like to als= o
discuss a related improvement to SPF and DMARC, as well as the binary
encoding change. =A0At the conclusion we can have a longer discussion about=
the details of CONTENT-TYPE: multipart/dkim-forwarding-history or wr= ite a
draft that tightly specifies how this works.

Wei,

Any "chain of trust" idea will work with a honored client/server = negotiated protocol steps and ideals.

The problem has always been in dealing with the deviation from the ideal pr= otocol steps and compliancy expectations.

So if you have a protocol ABC, what are the benefits of this ABC processing= ? =A0What is the payoff for the compliant mail receiver? =A0What is the pay= off for the originating/author domain? =A0

The benefit is that the recipient can authenticate the originating sender a= nd in particular a particular action such as sending to a mailing list, yet= allow intermediate domains to modify messages. =A0It may be that a user ha= s a filter to see all messages from the original sender. =A0This is jumping= ahead a bit, but the current DMARC paradigm is for the mailing list to own= the message and rewrite the RFC5322.FROM which make this difficult. =A0In = addition SPAM filters likely can benefit from being able to process the ori= ginal message and know message was authenticated by the original sending do= main.
=A0
What happens when there is deviation, someth= ing broke in the chain of MIME diffs? =A0What do you want receivers to do?<= br>

In this proposal, it would be the same as = failing DKIM RFC=A06376=A0verification. =A0It ought to be treated as information the recipient d= omain can use for additional Spam processing etc but not necessarily indica= te reject or other action. =A0This proposal is meant to build infrastructur= e that can be used to enhance DMARC in a subsequent proposal. =A0By itself = this proposal primarily provides extra information (well a strong guarantee= on the authenticity and modifications) for Spam processing.
=A0

You must think of the massive volume of wasteful mail processing. Not every= one is going to do this just for nothing. It has to have a meaningful payof= f, and today that payoff comes in the form of mail filtering policies with = rejection/quarantine/discard author domain policy concepts.

So if your proposal says:

=A0 =A0"If you follow these steps, the author domain
=A0 =A0 is OK with you (because you asked him) honoring
=A0 =A0 rejection, if you see a problem, then there is
=A0 =A0 something wrong with it and its better (trust the
=A0 =A0 author policy) if you just reject it."

then we you got something to consider.

But I think in this case, your proposal is a higher processing complexity f= actor when all you need to do is ask the author if the final/last signature= in the chain is an trusted and/or authorized signer domain. =A0 If you are= not asking the author (directly or indirectly) if any of this forwarding s= tuff is ok, then I think you have a security conflict (loophole) to conside= r.


I'm probably misunde= rstanding your intent. =A0Here's a stab at a response: Passing the DKIM= Provenance verification is meant to provide a stronger verification from a= purported original sender. =A0If intermediates want to claim that a mail c= ame from some original sender, then they have to provide evidence. =A0If th= ey don't due maliciousness or otherwise, they don't have to include= such evidence but they won't get any benefit of claiming the reputatio= n of the original sender.

-Wei

PS It was mentioned = offline that the discussion on dmarc@ietf is currently restricted to buildi= ng the WG charter. =A0First apologies I missed that. =A0Second I can restri= ct subsequent discussion to apps-discuss if that's preferred by the WG.=

_______= ________________________________________
dmarc mailing list=
dmarc@= ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

--001a11c1ca16a80aa504fd024106-- From nobody Sun Jun 29 18:37:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E351A008C for ; Sun, 29 Jun 2014 18:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.271 X-Spam-Level: * X-Spam-Status: No, score=1.271 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0lB7Lq0yAE1 for ; Sun, 29 Jun 2014 18:37:12 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3C61A0080 for ; Sun, 29 Jun 2014 18:37:12 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id i50so1425188qgf.14 for ; Sun, 29 Jun 2014 18:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CAsDD3M60PWdObSauK4uzUjxb6f13r1tB7f372ipBDg=; b=NcnZ7o1UFlRclWELaokhSZGFcLd/NkF1OD/X+BPwG03HlaJr37dz2mFHRigYbGl+P4 r1/xz6LX3szXwu7oas3aGk4deFDGZCXiIQmxKOWIK5nLTNyfI+OvCdQX6tPxFe8NDUjc cqtESJHY7DZhDRba3RQauTHvKjKTrTMw1AJD0PxS7C7o0r7yKjbxMOUM7xNnmOFWSo14 t4PhDN7Jj2zc8QCi1ddeu/Uxr9zxRSHI4HjWWaClzfOriqO21Dq0UbUJH/tz0m6YJVJL zuQYpOglPKrxSLIELxQjKEinQ6dA2CBoCiONY0c2AMxn1d/WHDrkarrrf78ybF3EHxPl wLKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CAsDD3M60PWdObSauK4uzUjxb6f13r1tB7f372ipBDg=; b=aRITZWUQwHTEAFtMSTO3h/zCNqTRE5tfPItLfPItsR6u0B2T3j47eutFd/6cndvGdD E+DzAu22MIPObzDi5y3tjRpPfZmp5DeC265FkA9DUY82vjfh7ib/9/jgE7k3VxCqeCn1 Be9lX7VkLzq2nYkFrApV+f3mR1kLDp+yOKCfjp1d4C3y3SixS1JuLT2Hj6f7+Iuirf3N UEFetWP+xgRqwqEsSx4yxpE5FGKqK9cgObZPWw1KLeF1LbApNthYksBWVtRD/7iVa/zo wZ64ycuGWrHJe2VkSbCVasbbWO1MujhKAhLUanx6a96iFx5C7hnVmtCwbnK+BDaA/qgR FhSg== X-Gm-Message-State: ALoCoQmWGvqcVSWeiUZAMLg5WHRdp9kKr7LpxrfkW7BBlQkwpGpqq4tYE+zoCDZrj5X5CfSPX3uy X-Received: by 10.140.94.225 with SMTP id g88mr51620237qge.101.1404092231825; Sun, 29 Jun 2014 18:37:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.58.1 with HTTP; Sun, 29 Jun 2014 18:36:51 -0700 (PDT) In-Reply-To: <20140629012552.81149.qmail@joyce.lan> References: <20140629012552.81149.qmail@joyce.lan> From: Wei Chuang Date: Sun, 29 Jun 2014 18:36:51 -0700 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=001a113a7f16b5e02e04fd03b21b Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RwaJrWfb6mCL0pVQISYK69jkKV4 Cc: apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2014 01:37:14 -0000 --001a113a7f16b5e02e04fd03b21b Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 28, 2014 at 6:25 PM, John Levine wrote: > >This proposal would introduce a new MIME CONTENT-TYPE: > >multipart/dkim-forwarding-history that would contain the diffs. > > It's an interesting idea, but I see two immediate issues: > > a) it requires extensive changes to both list managers and MUAs, which > history tells us are not likely to happen > But change is being forced upon list managers in particular by the Yahoo and AOL DMARC p=reject change. My understanding is the change though is fairly suboptimal i.e. fixes the immediate problem but introduces new issues such as modifying RFC5322.FROM which hurts UX. I would think these providers if they have to make a change would prefer something that is general, doesn't impact the generally understood user experience with mailing lists e.g. modifying subject lines or footers and provides the security that DMARC verifies for. Keep also in mind that the underlying reason why Yahoo and AOL went to p=reject, Spam and Phishing, are threats that increase in quantity and sophistication in time. I would hope that it is forward looking to assume that some change is necessary to deal with them. > > b) the problem it solves doesn't seem to be the one we have > > It is my impression that a host that appears to be a forwarder will > act pretty consistently, making whatever changes it makes to the > messages coming through. So if it starts sending spam, that's almost > certainly because for some reason (poor filtering, spoofing, etc) it's > forwarding mail that was already spam when it arrived at the > forwarder. So if the forwarder can pass through enough info to > reconstruct not the original message, but the original authentication > info, which will say among other things whether the original message > was DMARC aligned. > > That's specifically what Original-Authentication-Results is intended > to do, and one of the things you could do with my weak conditional > signatures. They're not bulletproof, but they don't have to be if you > believe that it's not common for well behaved forwarders to suddenly > turn malicious. > OAR asks the receiver to trust the forwarder / mailing-list. This is okay for larger scale providers where the reputation can be well established. But smaller forwarder will be at a disadvantage since there's less evidence of past behavior. The conditional signatures approach is fairly general, but the initial sender has know the complete forwarding path message may take. This could be a problem in particular with mailing-lists where there are multiple such paths in the fanout. > > Beyond that, there'd be the issue of deciding how much change was "too > much". There are some fairly normal changes that lists make that are > semantically minor but cause vast changes to the message text, e.g., > reordering or deleting parts. recoding from 8bit to base64, Transport encoding changes can be handled by additional MIME metadata I think. > or > flattening HTML to text. > Agreed. That type of conversion will definitely add more overhead and increase message size. I would think in some circumstances this diff is desired because the change is potentially significant. > > R's, > John > thanks for the many insights, -Wei --001a113a7f16b5e02e04fd03b21b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Jun 28, 2014 at 6:25 PM, John Levine <= johnl@taugh.com>= ; wrote:
>This proposal would introduce a new MI= ME CONTENT-TYPE:
>multipart/dkim-forwarding-history that would contain the diffs.

It's an interesting idea, but I see two immediate issues:

a) it requires extensive changes to both list managers and MUAs, which
history tells us are not likely to happen

But change is being forced upon list managers in particular by the Yahoo= and AOL DMARC p=3Dreject change. =A0My understanding is the change though = is fairly suboptimal i.e. fixes the immediate problem but introduces new is= sues such as modifying RFC5322.FROM which hurts UX. =A0I would think these = providers if they have to make a change would prefer something that is gene= ral, doesn't impact the generally understood user experience with maili= ng lists e.g. modifying subject lines or footers and provides the security = that DMARC verifies for. =A0Keep also in mind that the underlying reason wh= y Yahoo and AOL went to p=3Dreject, Spam and Phishing, are threats that inc= rease in quantity and sophistication in time. =A0I would hope that it is fo= rward looking to assume that some change is necessary to deal with them.=A0=
=A0

b) the problem it solves doesn't seem to be the one we have

It is my impression that a host that appears to be a forwarder will
act pretty consistently, making whatever changes it makes to the
messages coming through. =A0So if it starts sending spam, that's almost=
certainly because for some reason (poor filtering, spoofing, etc) it's<= br> forwarding mail that was already spam when it arrived at the
forwarder. =A0So if the forwarder can pass through enough info to
reconstruct not the original message, but the original authentication
info, which will say among other things whether the original message
was DMARC aligned.

That's specifically what Original-Authentication-Results is intended to do, and one of the things you could do with my weak conditional
signatures. =A0They're not bulletproof, but they don't have to be i= f you
believe that it's not common for well behaved forwarders to suddenly turn malicious.

OAR asks the receiver t= o trust the forwarder / mailing-list. =A0 This is okay for larger scale pro= viders where the reputation can be well established. =A0But smaller forward= er will be at a disadvantage since there's less evidence of past behavi= or. =A0The conditional signatures approach is fairly general, but the initi= al sender has know the complete forwarding path message may take. =A0This c= ould be a problem in particular with mailing-lists where there are multiple= such paths in the fanout.
=A0

Beyond that, there'd be the issue of deciding how much change was "= ;too
much". =A0There are some fairly normal changes that lists make that ar= e
semantically minor but cause vast changes to the message text, e.g.,
reordering or deleting parts. recoding from 8bit to base64,

Transport encoding changes can be handled by additional M= IME metadata I think.
=A0
or
flattening HTML to text.

Agreed. That t= ype of conversion will definitely add more overhead and increase message si= ze. =A0I would think in some circumstances this diff is desired because the= change is potentially significant.
=A0

R's,
John

thanks for the many insights,
-Wei=A0

--001a113a7f16b5e02e04fd03b21b-- From nobody Sun Jun 29 19:38:33 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63801A00E9 for ; Sun, 29 Jun 2014 19:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BU486X0pj16B for ; Sun, 29 Jun 2014 19:38:28 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947C01A00E5 for ; Sun, 29 Jun 2014 19:38:28 -0700 (PDT) Received: (qmail 4188 invoked from network); 30 Jun 2014 02:38:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=105b.53b0cda3.k1406; bh=RM49p1+RuEGFqUzibRDPrJJZ271lPCQPrgPOO4KN7sQ=; b=Xrd8Kdt12bxoxERapUbDoZ1fHmbMcJYqltj/0ImAvuiTawUhS/57pw5MFlSS83apB/FaFjdTAwp6BRH2CVghbrF3jqMaLO5DKbsahkJVITuEHCKXQenWF72U47GDc6v5eGARWsaxNGqfZmO7vwMPO7a7FUr+ssniPbfaco9lAlgp71nR/4XR6R2QgsWUJH3y0LWif/WH7BXdD7TDZLHZQKPIRJdpYLYVHBsP5y7fl7KiGU2lvpLW8+zdRt2aARlT DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=105b.53b0cda3.k1406; bh=RM49p1+RuEGFqUzibRDPrJJZ271lPCQPrgPOO4KN7sQ=; b=yfBBscyJ+2FE4peq4InKXGfL5eQQZsB71pCQZqhzD8WcqKbXddNXmCBbbt+15vyT3UIYCebkijMyCFI+gf1RuZyKib1Cw9rqN+CrWUcCyTeVIUbs0bPRWlJIywVek7Wp3TT0GSHNJwrllsU/4VrkYo7MfdEjgB4gwCXrocY4BcJqy7UKgGhYITH89Cf8C128v9KC/kBc1kCbNlDC84+4G6pkNGecj6tvPIgzt6H6PDvqVpTQ6R1BuW5NUghEIeWj Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 30 Jun 2014 02:38:27 -0000 Date: 29 Jun 2014 22:38:26 -0400 Message-ID: From: "John R Levine" To: "Wei Chuang" In-Reply-To: References: <20140629012552.81149.qmail@joyce.lan> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1rsAnfSo44tHegUuaHORRc_AzMY Cc: apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2014 02:38:30 -0000 >> a) it requires extensive changes to both list managers and MUAs, which >> history tells us are not likely to happen > > But change is being forced upon list managers in particular by the Yahoo > and AOL DMARC p=reject change. Forced on list managers, but not on MUA authors. If we can get MUA authors to change the way they display list mail, we could do something much simpler like the message wrapping that's an option in recent versions of Mailman. >> That's specifically what Original-Authentication-Results is intended >> to do, and one of the things you could do with my weak conditional >> signatures. They're not bulletproof, but they don't have to be if you >> believe that it's not common for well behaved forwarders to suddenly >> turn malicious. > > OAR asks the receiver to trust the forwarder / mailing-list. This is okay > for larger scale providers where the reputation can be well established. > But smaller forwarder will be at a disadvantage since there's less > evidence of past behavior. If spammers send enough fake forwarded mail that it's an issue for small mail systems, I expect the operators will use shared whitelists of known forwarders. I talk to a lot of other small mail system operators, and most of them are only dimly aware of DMARC as that thing that screws up AOL and Yahoo mail. On my system, the only use the filters make of DKIM is to reject unsigned mail from a fixed list of major phish targets, a spamassassin feature that predates DMARC by many years. I just don't seem them (us, really) implementing something as complex as your proposal, particularly if it turns out that it needs a lot of tweaking to avoid false positives. > The conditional signatures approach is fairly general, but the initial > sender has know the complete forwarding path message may take. This > could be a problem in particular with mailing-lists where there are > multiple such paths in the fanout. The sender only needs to know the forwarders that break DKIM signatures, for lists is just the first one you send to. On the lists I've seen with multiple paths, the fanout just relays the mail without rewriting it. Do you still see a lot of lists with multiple fanout visible to the recipients? It was common 20 years ago, but now everything is fast enough that you'd need a phenomenally large list for it to be useful. The only one I subscribe to that big is Dave Farber's IP list, and the fanout is only visible in the Received: headers. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Mon Jun 30 10:08:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A241A03C0; Mon, 30 Jun 2014 10:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Thn1kTJY9dky; Mon, 30 Jun 2014 10:07:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7F61A0397; Mon, 30 Jun 2014 10:07:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140630170757.27164.41689.idtracker@ietfa.amsl.com> Date: Mon, 30 Jun 2014 10:07:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QXZBKNyNSNuMcwZgzeCWioRGNSk Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-merge-patch-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 17:07:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : JSON Merge Patch Authors : Paul Hoffman James M Snell Filename : draft-ietf-appsawg-json-merge-patch-03.txt Pages : 11 Date : 2014-06-30 Abstract: This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a subset of target resource's content. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-merge-patch-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 30 10:23:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D241A03EA for ; Mon, 30 Jun 2014 10:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voAtSYLkr1MG for ; Mon, 30 Jun 2014 10:23:04 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E161A03C9 for ; Mon, 30 Jun 2014 10:22:56 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s5UHMsCb029922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 30 Jun 2014 10:22:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Jun 2014 10:22:54 -0700 References: <20140630170757.27164.41689.idtracker@ietfa.amsl.com> To: IETF Apps Discuss Message-Id: <211EFBCD-6605-414B-8680-652C98214B5E@vpnc.org> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/IG_3efWihOWaESa8VkjjHO20-zs Subject: [apps-discuss] Post-WG-LC changes in draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2014 17:23:04 -0000 Greetings. James has added me as co-editor on appsawg-json-merge-patch, = and I incorporated the changes from WG LC. The most prominent change is = clarifying the use of nulls in the patch document, but there were others = as well. If there are no more changes, the chairs can move this on to the ADs for = review. --Paul Hoffman= From nobody Mon Jun 30 11:09:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DC71A02DE for ; Mon, 30 Jun 2014 11:09:11 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iIpvtn8ZKt5 for ; Mon, 30 Jun 2014 11:09:05 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5433C1A040E for ; Mon, 30 Jun 2014 11:09:01 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id k14so8390264wgh.6 for ; Mon, 30 Jun 2014 11:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bFTe+06EjuZeMefhR0aB6PngkASSibLlERTqEh3hRwk=; b=iYTr3lislb8N7EvXBA9/+R/jTo/+RZxjmPot0nz5IAXUM7COBHS8Pfk7d6W//qHZtM 50zGUhFnUJ6L5oZ22pBH8h5bNODeGTYOpHyPiAC83TZANCn+Lu8j/2TSaAaVz5RTqpsU MM5Hxu51ffRfc+xsK85IEr3PvU8hGRiYhzWwXouVqJr7g/+u0FSilMNXn6SQgC9aEYKZ lZAye13eaujiXyoLofZuXvqBX1DBTgFvXLrLByvTjvwzbQSWd+cOr+bEolQjS/+/QAP2 cpgIODywsAT901yCqKp27Ooy4nl5t29xX42yaZVMqCDwz3mk1tPxNE2dSxsyjx/pk7Vw OjQg== MIME-Version: 1.0 X-Received: by 10.180.98.130 with SMTP id ei2mr4673255wib.24.1404151740006; Mon, 30 Jun 2014 11:09:00 -0700 (PDT) Received: by 10.180.19.74 with HTTP; Mon, 30 Jun 2014 11:08:59 -0700 (PDT) In-Reply-To: <211EFBCD-6605-414B-8680-652C98214B5E@vpnc.org> References: <20140630170757.27164.41689.idtracker@ietfa.amsl.com> <211EFBCD-6605-414B-8680-652C98214B5E@vpnc.org> Date: Mon, 30 Jun 2014 11:08:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Paul Hoffman Content-Type: multipart/alternative; boundary=14dae9cdcc5dac8b2e04fd118de8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Sim1pff1rlZlhEaSSPHVAnYZqEA Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Post-WG-LC changes in draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2014 18:09:11 -0000 --14dae9cdcc5dac8b2e04fd118de8 Content-Type: text/plain; charset=UTF-8 Thanks, Paul. I'll give this a couple of days for people to reply and then send it along. If anyone would like to shepherd this document, so as to give someone the experience of doing so, please let us know (appsawg-chairs@tools.ietf.org). If not, I'll do the writeup myself. -MSK On Mon, Jun 30, 2014 at 10:22 AM, Paul Hoffman wrote: > Greetings. James has added me as co-editor on appsawg-json-merge-patch, > and I incorporated the changes from WG LC. The most prominent change is > clarifying the use of nulls in the patch document, but there were others as > well. > > If there are no more changes, the chairs can move this on to the ADs for > review. > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --14dae9cdcc5dac8b2e04fd118de8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Paul.=C2=A0 I'll give this a couple of da= ys for people to reply and then send it along.

If anyone would= like to shepherd this document, so as to give someone the experience of do= ing so, please let us know (appsawg-chairs@tools.ietf.org).=C2=A0 If not, I'll do the writeup= myself.

-MSK


On Mon, Jun 30, 2014 at 10:22 AM, Paul Hoffman <<= a href=3D"mailto:paul.hoffman@vpnc.org" target=3D"_blank">paul.hoffman@vpnc= .org> wrote:
Greetings. James has added me as co-editor o= n appsawg-json-merge-patch, and I incorporated the changes from WG LC. The = most prominent change is clarifying the use of nulls in the patch document,= but there were others as well.

If there are no more changes, the chairs can move this on to the ADs for re= view.

--Paul Hoffman
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--14dae9cdcc5dac8b2e04fd118de8-- From nobody Mon Jun 30 11:22:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27681A041D for ; Mon, 30 Jun 2014 11:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEwjAF42Xiq0 for ; Mon, 30 Jun 2014 11:22:42 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7241A040D for ; Mon, 30 Jun 2014 11:22:42 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id i50so2361057qgf.28 for ; Mon, 30 Jun 2014 11:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=m25cDhCK8nj4GRLsTU9wvvNpOj7upD4DHX9SSMO67gk=; b=hNlAqNVcGIB1qsD5ag5Bsbc1EDkG9VPfuUqNF5tj3IeaC+PTUaSqdtnQKP7Q4O3Pd/ k3/pMpEe7Y97YDMXL+F6fyuuplyqGp5ALsNj00RO/amZJ2w9Gb3GJGHDOMcKX8MrGil5 qGWBtyXhw+sETXGYrijg6fEDLpf39pgi6nk4UxLJ6M8ioYUvLk7z3mJ5MuSTtV0xXlkl badjGX+dUvAxG7sPce+BgPzdmt6IEr68a3ylkF9mJuvTNH/kzHjBDVUA13t1SGq5QWdU mDy3DnjNPLpytHywuQo/xPtqPQ+IntRE3CUbpS2LQ7rNfD1KYTlWDYOfrEomLZIpDE2y lZww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=m25cDhCK8nj4GRLsTU9wvvNpOj7upD4DHX9SSMO67gk=; b=LybmMhiDXLyu2F+GDmVCJCcZChuQEkamkOvEfvaSnR01uJTtdPhhCc4Nk2JOq5Xcsj 8AQnE+5RkeEg5E2YikVa7YUIBUCLzOB0alrpUisYic/WXBP4Jzu/1rNqEDrUCQIYv5d3 ZHQhFBIy+rKudykX0l4hdoV4Nga6aJd/aPk38VY9grntHFWW8jgw8G1gNX0M8c+4nr9y MFZmtvcI4F1lSKrc0PX5rNce2/AuL9MgnComezBf7Rz/VuJ/fnYfQSoBud7WCdhzffhJ rSNVsuhZaEt86Q8osmop5mtuFxwPYqP6WvU2MadffIfgVZ1zQ2fRqOQIDTx1RuD9y1C6 MRTA== X-Gm-Message-State: ALoCoQmfG2wBGtXL+hymGkcJS4OMcqPVuHzTFRfRAFpNUne0D0XuhhpSH0FqcbMKzCPw6a0lXIzo X-Received: by 10.140.28.37 with SMTP id 34mr61132870qgy.28.1404152561476; Mon, 30 Jun 2014 11:22:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.58.1 with HTTP; Mon, 30 Jun 2014 11:22:20 -0700 (PDT) In-Reply-To: References: <20140629012552.81149.qmail@joyce.lan> From: Wei Chuang Date: Mon, 30 Jun 2014 11:22:20 -0700 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=001a11393d42a351c704fd11be32 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6nUypN7i2swOGqvCpUF-KsF67OA Cc: apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2014 18:22:44 -0000 --001a11393d42a351c704fd11be32 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 29, 2014 at 7:38 PM, John R Levine wrote: > a) it requires extensive changes to both list managers and MUAs, which >>> history tells us are not likely to happen >>> >> >> But change is being forced upon list managers in particular by the Yahoo >> and AOL DMARC p=reject change. >> > > Forced on list managers, but not on MUA authors. If we can get MUA > authors to change the way they display list mail, we could do something > much simpler like the message wrapping that's an option in recent versions > of Mailman. With message wrapping, my understanding is it wraps the original message in a MIME part. If that's the case, then that's pretty much the storage (or more) of doing the diff. And if both parties do a DKIM signing, then its almost the all the way there to this proposal. Yes there is some conformance burden but it provides much greater security guarantees. The MUA owners are certainly feeling pressure from Spam and Phishing. I'd imagine they'd be willing to change if they saw enough benefit. > > > That's specifically what Original-Authentication-Results is intended >>> to do, and one of the things you could do with my weak conditional >>> signatures. They're not bulletproof, but they don't have to be if you >>> believe that it's not common for well behaved forwarders to suddenly >>> turn malicious. >>> >> >> OAR asks the receiver to trust the forwarder / mailing-list. This is >> okay >> for larger scale providers where the reputation can be well established. >> But smaller forwarder will be at a disadvantage since there's less >> evidence of past behavior. >> > > If spammers send enough fake forwarded mail that it's an issue for small > mail systems, I expect the operators will use shared whitelists of known > forwarders. I talk to a lot of other small mail system operators, and most > of them are only dimly aware of DMARC as that thing that screws up AOL and > Yahoo mail. The lack of pick up of smaller providers of particularly DKIM is what drove this proposal. We did a survey of DKIM and SPF pick up for personal mail, and observed that large provider were using DKIM, but there was a dramatic drop off as the providers got smaller. SPF had a drop off too, but less pronounced. This is disappointing in that DKIM provides a stronger security guarantee, and has less restrictions on its deployment than SPF (if one excludes DMARC constraints). Is it only lack of awareness? I doubt that otherwise we'd see both SPF and DKIM drop off in equal measure. Its not due to X509 PKI complexity as DKIM doesn't require that. In any case, we were wondering if its due in part to the warts that DMARC has (meaning imposes on DKIM / SPF), hence this proposal. > On my system, the only use the filters make of DKIM is to reject unsigned > mail from a fixed list of major phish targets, a spamassassin feature that > predates DMARC by many years. > > I just don't seem them (us, really) implementing something as complex as > your proposal, particularly if it turns out that it needs a lot of tweaking > to avoid false positives. Actually this proposal is supposed to resolve the tweaking that is needed today with DMARC. What tweaking do see you will be required? Agreed that there will be a cost in additional CPU processing time (diff), greater message size and eng effort for conformance. But besides that? (And granted the DMARC part of the proposal isn't out yet) > > > The conditional signatures approach is fairly general, but the initial >> sender has know the complete forwarding path message may take. This could >> be a problem in particular with mailing-lists where there are multiple such >> paths in the fanout. >> > > The sender only needs to know the forwarders that break DKIM signatures, > for lists is just the first one you send to. On the lists I've seen with > multiple paths, the fanout just relays the mail without rewriting it. > > Do you still see a lot of lists with multiple fanout visible to the > recipients? It was common 20 years ago, but now everything is fast enough > that you'd need a phenomenally large list for it to be useful. The only > one I subscribe to that big is Dave Farber's IP list, and the fanout is > only visible in the Received: headers. > > No specific example- it was meant hypothetically. But in the lore here, the internet is such as vast place with so permutations of messages and providers, that if something can break, invariably it will. thanks, -Wei Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > --001a11393d42a351c704fd11be32 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Jun 29, 2014 at 7:38 PM, John R Levine &l= t;johnl@taugh.com&= gt; wrote:
a) it requires extensive changes to both list managers and MUAs, which
history tells us are not likely to happen

But change is being forced upon list managers in particular by the Yahoo and AOL DMARC p=3Dreject change.

Forced on list managers, but not on MUA authors. =A0If we can get MUA autho= rs to change the way they display list mail, we could do something much sim= pler like the message wrapping that's an option in recent versions of M= ailman.

With message wrapping, my understanding is it wraps the= original message in a MIME part. =A0If that's the case, then that'= s pretty much the storage (or more) of doing the diff. =A0And if both parti= es do a DKIM signing, then its almost the all the way there to this proposa= l. =A0Yes there is some conformance burden but it provides much greater sec= urity guarantees. =A0The MUA owners are certainly feeling pressure from Spa= m and Phishing. =A0I'd imagine they'd be willing to change if they = saw enough benefit.
=A0


That's specifically what Original-Authentication-Results is inte= nded
to do, and one of the things you could do with my weak conditional
signatures. =A0They're not bulletproof, but they don't have to be i= f you
believe that it's not common for well behaved forwarders to suddenly turn malicious.

OAR asks the receiver to trust the forwarder / mailing-list. =A0 This is ok= ay
for larger scale providers where the reputation can be well established. But smaller forwarder will be at a disadvantage since there's less
evidence of past behavior.

If spammers send enough fake forwarded mail that it's an issue for smal= l mail systems, I expect the operators will use shared whitelists of known = forwarders. =A0I talk to a lot of other small mail system operators, and mo= st of them are only dimly aware of DMARC as that thing that screws up AOL a= nd Yahoo mail. =A0

The lack of pick up of smaller providers of particularl= y DKIM is what drove this proposal. =A0We did a survey of DKIM and SPF pick= up for personal mail, and observed that large provider were using DKIM, bu= t there was a dramatic drop off as the providers got smaller. =A0SPF had a = drop off too, but less pronounced. =A0 This is disappointing in that DKIM p= rovides a stronger security guarantee, and has less restrictions on its dep= loyment than SPF (if one excludes DMARC constraints). =A0Is it only lack of= awareness? =A0I doubt that otherwise we'd see both SPF and DKIM drop o= ff in equal measure. =A0Its not due to X509 PKI complexity as DKIM doesn= 9;t require that. =A0In any case, we were wondering if its due in part to t= he warts that DMARC has (meaning imposes on DKIM / SPF), hence this proposa= l.=A0
=A0
On my system, the only use the filters make = of DKIM is to reject unsigned mail from a fixed list of major phish targets= , a spamassassin feature that predates DMARC by many years.

I just don't seem them (us, really) implementing something as complex a= s your proposal, particularly if it turns out that it needs a lot of tweaki= ng to avoid false positives.

Actually this = proposal is supposed to resolve the tweaking that is needed today with DMAR= C. =A0What tweaking do see you will be required? =A0Agreed that there will = be a cost in additional CPU processing time (diff), =A0greater message size= and eng effort for conformance. =A0But besides that? =A0(And granted the D= MARC part of the proposal isn't out yet) =A0
=A0


The conditional signatures approach is fairly general, but the initial send= er has know the complete forwarding path message may take. =A0This could be= a problem in particular with mailing-lists where there are multiple such p= aths in the fanout.

The sender only needs to know the forwarders that break DKIM signatures, fo= r lists is just the first one you send to. =A0On the lists I've seen wi= th multiple paths, the fanout just relays the mail without rewriting it.
Do you still see a lot of lists with multiple fanout visible to the recipie= nts? =A0It was common 20 years ago, but now everything is fast enough that = you'd need a phenomenally large list for it to be useful. =A0The only o= ne I subscribe to that big is Dave Farber's IP list, and the fanout is = only visible in the Received: headers.


No specific example- it was meant hypo= thetically. =A0But in the lore here, the internet is such as vast place wit= h so permutations of messages and providers, that if something can break, i= nvariably it will.
=A0
thanks,
-Wei

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

--001a11393d42a351c704fd11be32-- From nobody Mon Jun 30 11:31:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204041A04F1 for ; Mon, 30 Jun 2014 11:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEQP1E-4If3S for ; Mon, 30 Jun 2014 11:31:44 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43CF1A0495 for ; Mon, 30 Jun 2014 11:31:43 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id k15so6700707qaq.2 for ; Mon, 30 Jun 2014 11:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=O9bY3K37uslDKlxV37vjSXbwnLGep923UCZDmMZB+/g=; b=jlaR8m3ot1di+5pVMh+38ws4hdBww/O/5umM8pxTNeFDTsDUeisbyRmB9CHc5I57/l dymOUjVuBa6QrfoWTOtgmPV5NMd5a/GvtVjM+5ERYgBa1Lel/plPB5/+pP691D5Mb9Jg LOwpOeDzww2ItHQyHGlbIYzC5LV0bi7YRAQExfjB5PDzM6k67/9H0AhdH7fQFd8AW69i HQIcR1m5ND/4S40JSkhOVzSznlaEVljBlba5Dtq3G9jbYrxdvf0OZgKI/l90eyshO3zv yn+ibpOJNAw1xCFD5f4J2Q8swPulWMv717yMGctGn9EStRGtif6nwkPIOgpw3RxyWpVF xw8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=O9bY3K37uslDKlxV37vjSXbwnLGep923UCZDmMZB+/g=; b=nJu6WNJlOzpuJQqaE5ESf/gc7L68pKoETmuLNVTR9GQf8xpp5BmavWhRJ+HEzJnzfY mdi4t/dCfBqqZPHL9B7Az1LvWs8RxFGkptF1bvTihe9+3DrEkMnseb8+A6yr6iPf+8Kh 9NQLiar3f56/vR2pUtRU/1yHhbp7xGkShkNDGR9imcqNrQEIaN/AQxN6uX5IrwgTuQzZ Uf8M+N48fPL8PCkL1YQ5tvidW5CJ2wFSMGHFgk6Kn+Kvc1/R2tbEE0PKSmvgtYIHUcgG GYjVvVjp3rB9qdyjCZl7dG0mAotsNqW4VIoqdLPei23B4RENWAPhxg4jivzSCBm98kqi B4qw== X-Gm-Message-State: ALoCoQkMpa3laE2cT2+hfHXWFvd+6t4WOXeoFnRQeIx4r2qTR8X2zTl01YHgjOnJ59gY8dL8Ehjf X-Received: by 10.229.178.202 with SMTP id bn10mr61783042qcb.6.1404153102933; Mon, 30 Jun 2014 11:31:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.58.1 with HTTP; Mon, 30 Jun 2014 11:31:21 -0700 (PDT) In-Reply-To: References: <53AEDDB5.8080702@isdg.net> From: Wei Chuang Date: Mon, 30 Jun 2014 11:31:21 -0700 Message-ID: To: Hector Santos Content-Type: multipart/alternative; boundary=001a11c2be92e93dc004fd11de26 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ql6lRb5P8WMXm-05zlE31il2Xm4 Cc: "dmarc@ietf.org" , apps-discuss Subject: Re: [apps-discuss] [dmarc-ietf] DKIM Forwarding History (Provenance) Proposal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2014 18:31:45 -0000 --001a11c2be92e93dc004fd11de26 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 28, 2014 at 5:01 PM, Wei Chuang wrote: > > > PS It was mentioned offline that the discussion on dmarc@ietf is > currently restricted to building the WG charter. First apologies I missed > that. Second I can restrict subsequent discussion to apps-discuss if > that's preferred by the WG. > > I got in touch with the moderators. The list discussion is still charter oriented, so I'm moving any discussion of this proposal to apps-discuss@ietf.org. Hopefully the charter discussion wraps up soon. Thanks, -Wei --001a11c2be92e93dc004fd11de26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Jun 28, 2014 at 5:01 PM, Wei Chuang <<= a href=3D"mailto:weihaw@google.com" target=3D"_blank">weihaw@google.com= > wrote:


PS It was mentioned offline that the discussion on= dmarc@ietf is currently restricted to building the WG charter. =A0First ap= ologies I missed that. =A0Second I can restrict subsequent discussion to ap= ps-discuss if that's preferred by the WG.


I got in= touch with the moderators. =A0The list discussion is still charter oriente= d, so I'm moving any discussion of this proposal to apps-discuss@ietf.org. =A0Hopefully the charter d= iscussion wraps up soon. =A0

Thanks,
-Wei=A0

--001a11c2be92e93dc004fd11de26-- From nobody Mon Jun 30 11:53:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A629B1A03FD for ; Mon, 30 Jun 2014 11:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7ImUE7lbNwG for ; Mon, 30 Jun 2014 11:53:00 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B5F1A03D4 for ; Mon, 30 Jun 2014 11:53:00 -0700 (PDT) Received: (qmail 82906 invoked from network); 30 Jun 2014 18:52:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=143d7.53b1b20b.k1406; bh=ZHVu4tRSJlbMu+W48xL5zXehhAWiw1EjGLK02HRLqNQ=; b=p1OidiHAQtNw1xdq8DVrwVHi51YuCKi1lQq/Llq0shRB7hn5GFkSxNjhFDI5l9fWyr9kXmY6wlx+9LECETehUNFE68Fh+BoPMkktDf4EzRKk9bQcqZCAVzQRQFmA/usdmsi8xxPMHNyzKDFQUsEMXEqcUtagNHKUd2dfGL0RfmlPHsuwQDrfZT0QYrnt64eh62HM9Cq/yaaj7bhiKAzXbH35KdurHx65r8ap9oe2J0bWIQ6fr7OjFIheipoZCtqT DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=143d7.53b1b20b.k1406; bh=ZHVu4tRSJlbMu+W48xL5zXehhAWiw1EjGLK02HRLqNQ=; b=MoHrWJOBXZYS1Iu9LP84nsJ0jVt3Uf7kTiVb8Y3SwbJ0/z5CQY7XcafIJnChvYTdahcj3K6EpLPebiCks1MS+bOZgCHgrIwlHlNU1ZrevT9tYFc5yvdUck8hENaOaubpCQ5CitnC29QH1HmLVU2d4RgKjKvCDtdv2ay74EPk5BQxxaOB9WMeek2YVevWMleDSxWeoi/f4/jI35GJOWahGfEG9Kd8cKlIiUS05BcMV+KyrevpTb4u+BaS7A5/VisY Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 30 Jun 2014 18:52:59 -0000 Date: 30 Jun 2014 14:52:58 -0400 Message-ID: From: "John R Levine" To: "Wei Chuang" In-Reply-To: References: <20140629012552.81149.qmail@joyce.lan> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Qha63W7amsQ1Y-gj-BEcAJ_GiD8 Cc: apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2014 18:53:01 -0000 >> Forced on list managers, but not on MUA authors. If we can get MUA >> authors to change the way they display list mail, we could do something >> much simpler like the message wrapping that's an option in recent versions >> of Mailman. > > With message wrapping, my understanding is it wraps the original message in > a MIME part. If that's the case, then that's pretty much the storage (or > more) of doing the diff. There's a major practical difference: the message wrap hack is essentially a single message digest. List managers already have code to build digests, and MUAs can display them, if not always very beautifully. Lists do not have code to save the original message, then later use some diff'ing algorithm to create new message parts that no MUA knows how to display. >> I just don't seem them (us, really) implementing something as complex as >> your proposal, particularly if it turns out that it needs a lot of tweaking >> to avoid false positives. > > Actually this proposal is supposed to resolve the tweaking that is needed > today with DMARC. What tweaking do see you will be required? Incoming mail filters will have to look at the diffs and apply some yet to be invented heuristics to analyse the them and decide whether the before and after versions are "too different". I have no idea what a satisfactory definition of "too different" is, and would be surprised if anyone else did. There isn't even a generally accepted version of diff syntax -- programs like the freeware "patch" have extensive heuristics to try to decode all of the various diff formats they have to deal with. Anyway, the two of us have been arguing in a vacuum. Let's see what other people thing. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Mon Jun 30 17:31:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395D51A0394 for ; Mon, 30 Jun 2014 17:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.798 X-Spam-Level: * X-Spam-Status: No, score=1.798 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xL-X0UO6gSva for ; Mon, 30 Jun 2014 17:31:11 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 63CE11A0439 for ; Mon, 30 Jun 2014 17:31:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,578,1399989600"; d="scan'208";a="21879413" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 01 Jul 2014 10:22:52 +1000 X-IronPort-AV: E=McAfee;i="5600,1067,7485"; a="288441748" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcavi.tcif.telstra.com.au with ESMTP; 01 Jul 2014 10:31:08 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Tue, 1 Jul 2014 10:31:07 +1000 From: "Manger, James" To: Paul Hoffman , IETF Apps Discuss Date: Tue, 1 Jul 2014 10:31:06 +1000 Thread-Topic: [apps-discuss] Post-WG-LC changes in draft-ietf-appsawg-json-merge-patch Thread-Index: Ac+Uh/p8dim3RIITS1K/pJHRq0pBlQANRRxQ Message-ID: <255B9BB34FB7D647A506DC292726F6E115496E8CC6@WSMSG3153V.srv.dir.telstra.com> References: <20140630170757.27164.41689.idtracker@ietfa.amsl.com> <211EFBCD-6605-414B-8680-652C98214B5E@vpnc.org> In-Reply-To: <211EFBCD-6605-414B-8680-652C98214B5E@vpnc.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BTW5TzOd3oN2AC0Src4TW75fd5I Subject: Re: [apps-discuss] Post-WG-LC changes in draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2014 00:31:12 -0000 UGF1bCwNCg0KPiAgZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tbWVyZ2UtcGF0Y2gtMDMNCg0KVGhh bmtzIGZvciBzdGVwcGluZyB1cCB0byBlZGl0IHRoaXMgZG9jdW1lbnQuDQoNCj4gSWYgdGhlcmUg YXJlIG5vIG1vcmUgY2hhbmdlcywgdGhlIGNoYWlycyBjYW4gbW92ZSB0aGlzIG9uIHRvIHRoZSBB RHMgZm9yIHJldmlldy4NCg0KTW9yZSBjaGFuZ2VzIGFyZSByZXF1aXJlZC4NCg0KMS4NCkNvbnNp ZGVyIGEgcGF0Y2ggc3VjaCBhcyB7Im5hbWUiOiJKb2huIiwgImFnZSI6bnVsbH0uDQpXaGVuIGFw cGxpZWQgdG8gKGllIG1lcmdlZCB3aXRoKSBhIHRhcmdldCB0aGUgcmVzdWx0IHNob3VsZCBhbHdh eXMgYmUgKDEpIGFuIG9iamVjdCwgKDIpIHdpdGggYSAibmFtZSI6IkpvaG4iIG1lbWJlciwgYW5k ICgzKSBubyAiYWdlIiBtZW1iZXIuDQoNClVuZm9ydHVuYXRlbHkgdGhlIGRyYWZ0LTAzIHJ1bGVz IGRvbid0IGd1YXJhbnRlZSB0aGlzLg0KSWYgdGhlIHRhcmdldCB3YXMgYW4gYXJyYXksIGZvciBp bnN0YW5jZSwgdGhlIHJlc3VsdCBpcyB7Im5hbWUiOiJKb2huIiwgImFnZSI6bnVsbH0hDQpTZWN0 aW9uIDIgcnVsZXMgMSBhbmQgMi5EIGFyZSB0aGUgcHJvYmxlbXMuDQoNCk9uZSB3YXkgdG8gZGVz Y3JpYmUgdGhlIGNvcnJlY3QgcnVsZSB3b3VsZCBiZSB0byBzYXk6IHdoZW4gdGhlIHBhdGNoIHZh bHVlIGlzIGFuIG9iamVjdCwgYnV0IHRoZSB0YXJnZXQgdmFsdWUgaXMgbm90IChpbmNsdWRpbmcg d2hlbiB0aGUgdGFyZ2V0IHZhbHVlIGlzIHVuZGVmaW5lZCksIHRoZW4gbWVyZ2UgdGhlIHBhdGNo IHZhbHVlIHdpdGggYW4gZW1wdHkgb2JqZWN0IHt9IHRvIGdldCB0aGUgcmVzdWx0Lg0KDQoNCjIu DQpBcHBlbmRpeCBBIGhhcyBkcm9wcGVkIGFuIGltcG9ydGFudCBjYXNlOiB3aGVuIGEgbmVzdGVk IG51bGwgY2F1c2VzIGFuIGVtcHR5IG9iamVjdCB0byBiZSBhZGRlZCB0byB0aGUgdGFyZ2V0Lg0K VGFyZ2V0IHt9IG1lcmdlZCB3aXRoIHBhdGNoIHsiYSI6eyJiYiI6eyJjY2MiOm51bGx9fX0gZ2l2 ZXMgeyJhIjp7ImJiIjp7fX19Lg0KDQoNCjMuDQpUaGUgbWVyZ2UgYmVoYXZpb3VyIGluIGRyYWZ0 LTAzIGlzIG5vdyBkZWxpYmVyYXRlbHkgdW5kZWZpbmVkIGlmIHRoZSBwYXRjaCBpcyBub3QgYW4g b2JqZWN0IG9yIGFycmF5LiBIb3dldmVyLCBpdCBpcyBhbHNvIHVuZGVmaW5lZCBpZiB0aGUgdGFy Z2V0IGlzIG5vdCBhbiBvYmplY3Qgb3IgYXJyYXkuIFRoaXMgdW5kZWZpbmVkIGJlaGF2aW91ciBj YW4gb25seSBkbyBoYXJtLiBNYW55IGltcGxlbWVudGF0aW9ucyB3aWxsIGludm9sdmUgYSBtZXJn ZSh0YXJnZXQsIHBhdGNoKSBmdW5jdGlvbiB0aGF0IGFjY2VwdHMgYW55IEpTT04gZm9yIGl0cyBh cmd1bWVudHMgc28gd2UgbWF5IGFzIHdlbGwgZGVmaW5lIGFsbCB0aGUgcmVzdWx0cy4gSXQgaXMg YWxzbyBzdHJhbmdlIHRvIG1lbnRpb24gYXJyYXlzIGV4cGxpY2l0bHkgYXMgbWVyZ2UtcGF0Y2gg dHJlYXRzIGFycmF5cyBqdXN0IGxpa2UgYSBwcmltaXRpdmUuDQoNCi0tDQpKYW1lcyBNYW5nZXIN Cg== From nobody Mon Jun 30 23:31:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DBA1B27C7 for ; Mon, 30 Jun 2014 23:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_54=0.6, J_CHICKENPOX_56=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOjqpn2A-5P5 for ; Mon, 30 Jun 2014 23:31:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6AD71B27C9 for ; Mon, 30 Jun 2014 23:31:49 -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.5/8.14.5) with ESMTP id s616VjVc028682; Tue, 1 Jul 2014 08:31:45 +0200 (CEST) Received: from [192.168.217.145] (p5489156F.dip0.t-ipconnect.de [84.137.21.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9879BF85; Tue, 1 Jul 2014 08:31:44 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115496E8CC6@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 1 Jul 2014 08:31:43 +0200 X-Mao-Original-Outgoing-Id: 425889102.985082-9dbc8b217fea9873130ebe4a96351a24 Content-Transfer-Encoding: quoted-printable Message-Id: <8186C77A-9628-4033-9CBA-8B4CCCFC6F62@tzi.org> References: <20140630170757.27164.41689.idtracker@ietfa.amsl.com> <211EFBCD-6605-414B-8680-652C98214B5E@vpnc.org> <255B9BB34FB7D647A506DC292726F6E115496E8CC6@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/WgbfkQdNOSYtLQbvUYug6wfhf3s Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] Post-WG-LC changes in draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2014 06:31:51 -0000 Good points. Here is my implementation: def merge_patch(orig, patch) if Hash =3D=3D=3D patch orig =3D {} unless Hash =3D=3D=3D orig patch.each do |k, v| if v.nil? orig.delete(k) else orig[k] =3D merge_patch(orig[k], v) end end orig else patch end end # yep, that's 15 lines. This could serve to replace the Appendix B. This implementation does not have the bug that you mention: > 3. > The merge behaviour in draft-03 is now deliberately undefined if the = patch is not an object or array. However, it is also undefined if the = target is not an object or array. This undefined behaviour can only do = harm. Many implementations will involve a merge(target, patch) function = that accepts any JSON for its arguments so we may as well define all the = results. It is also strange to mention arrays explicitly as merge-patch = treats arrays just like a primitive. Therefore, it does not check against the examples: Mismatch:=20 orig: {"a":"foo"} patch: null draft: "Invalid Example" actual: null Mismatch:=20 orig: {"a":"foo"} patch: "bar" draft: "Invalid Example" actual: =93bar" It does check against your example: {} {"a":{"bb": {"a":{"bb":{}}} {"ccc":null}}} I believe the above implementation is exactly what merge-patch should = do, and the text should be updated accordingly. Gr=FC=DFe, Carsten From nobody Mon Jun 30 23:38:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053971A02E2 for ; Mon, 30 Jun 2014 23:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8zbfCke-ehI for ; Mon, 30 Jun 2014 23:38:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCDD1B278C for ; Mon, 30 Jun 2014 23:38:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140701063852.18986.2443.idtracker@ietfa.amsl.com> Date: Mon, 30 Jun 2014 23:38:52 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KZfuCSBkGkP2bAbZLle0XTrdBTI Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 06:38:54 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-json-merge-patch", set due date to August 2014 from February 2014. URL: http://datatracker.ietf.org/wg/appsawg/charter/