From owner-ietf-mta-filters@mail.imc.org Sun Feb 1 07:24:08 2009 Return-Path: X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7443A69B4 for ; Sun, 1 Feb 2009 07:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9-y7hfj-4c7 for ; Sun, 1 Feb 2009 07:24:07 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3C6583A6948 for ; Sun, 1 Feb 2009 07:24:07 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11FFEaP093667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 08:15:14 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11FFEld093666; Sun, 1 Feb 2009 08:15:14 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11FFCZF093660 for ; Sun, 1 Feb 2009 08:15:13 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [92.40.116.35] (92.40.116.35.sub.mbb.three.co.uk [92.40.116.35]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 1 Feb 2009 15:15:09 +0000 Message-ID: <4985BC59.2040302@isode.com> Date: Sun, 01 Feb 2009 15:14:33 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Adam Roach CC: SIEVE Working Group , draft-ietf-sieve-notify-sip-message@tools.ietf.org, Cullen Jennings , Lisa Dusseault , Mary Barnes , RAI Area Subject: Re: draft-ietf-sieve-notify-sip-message References: <4967C072.4080205@nostrum.com> In-Reply-To: <4967C072.4080205@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Adam Roach wrote: > Mary Barnes has asked me to perform an expert review on > draft-ietf-sieve-notify-sip-message for the RAI area. Hi Adam, Thank you for the review and sorry for the slow response. > Overall, the approach in the document seems good. However, there are > two relatively minor details that cause me some concern. I think these > should be rather straightforward to fix. > > My first area of concern is that, while this seems a reasonable way to > perform this functionality in SIP, I don't think it's the only > reasonable way to do it in SIP. Consequently, this document needs to > take care not to preclude future SIP mechanisms for SIEVE > notifications. For example, the conveyance of more semantic > information in a PUBLISH message would be quite useful when there is a > dynamically changing community of parties interested in receiving > notifications. (The PUBLISH would be sent to an event agent, which > could then receive SUBSCRIBE requests from interested parties). This > may be applicable, for example, when monitoring shared resources, such > as technical support email queues. > > However, the draft makes an implicit assumption that any SIEVE > notification method URI starting with "sip:" necessarily will make use > of the mechanism it defines, and never any other. There is no means > for disambiguating among multiple mechanisms. In fact, the draft seems > to go out of its way to ruin an extensibility mechanism that it would > have automatically inherited from SIP: "The URI parameter 'method' > MUST be ignored, because only the MESSAGE method is allowed by this > specification." Right. I agree that allowing other SIP methods might be useful in the future. > I would suggest that the draft be amended to either *require* a > "method" URI parameter (with "MESSAGE" indicating the mechanism > described in this document), or to include additional information in > the ":options" tag that explicitly indicates the use of this > document's mechanism. I think requiring the method URI parameter would be best. > My second area of concern is with the handling of the "From" header > field. The draft-ietf-sieve-notify document clearly intends the > ":from" value to indicate the value that is typically rendered to the > contacted party as the source of the message. This intended behavior > is upheld by the language in section 2.3 of > draft-ietf-sieve-notify-mailto-10 (it places this value in the SMTP > "From:" header, and even suggests using the value in the "RCPT FROM" > command -- despite the easy availability of an SMTP "Reply-To:" > header). This mismatch in semantics between the protocols causes me > concern, as it may surprise users to have radically different > treatment of the value in the ":from" tag among protocols. Given the > text in the base sieve-notify document, I believe that the behavior in > sieve-notify-mailto is correct, and that the behavior in > sieve-notify-sip should be modified to align with it. Ok, you've convinced me that use of the SIP Reply-To header field is not a good idea. Are you recommending use of the From SIP header field? > (Indication of the sending server can be made via other means, such as > the SIP Call-Info: header field). > > Responses to the SIEVE working group mailing list, CC me. From owner-ietf-mta-filters@mail.imc.org Mon Feb 2 09:47:12 2009 Return-Path: X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA7E28C211 for ; Mon, 2 Feb 2009 09:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no5byllnAZoa for ; Mon, 2 Feb 2009 09:47:11 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 058E63A6ABA for ; Mon, 2 Feb 2009 09:47:07 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12HaoWc058140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 10:36:50 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12HaolI058139; Mon, 2 Feb 2009 10:36:50 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12HaoQp058133 for ; Mon, 2 Feb 2009 10:36:50 -0700 (MST) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id 4A27C28C259; Mon, 2 Feb 2009 09:36:32 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , sieve mailing list , sieve chair Subject: Protocol Action: 'The Sieve mail filtering language - extensions for checking mailbox status and accessing mailbox metadata' to Proposed Standard Message-Id: <20090202173632.4A27C28C259@core3.amsl.com> Date: Mon, 2 Feb 2009 09:36:32 -0800 (PST) Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'The Sieve mail filtering language - extensions for checking mailbox status and accessing mailbox metadata ' as a Proposed Standard This document is the product of the Sieve Mail Filtering Language Working Group. The IESG contact persons are Lisa Dusseault and Chris Newman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-melnikov-sieve-imapext-metadata-08.txt Technical Summary The SIEVE mail filtering language - extension for accessing mailbox metadata extension provides a way for a SIEVE script to test annotations stored on an IMAP server supporting the METADATA extension. Working Group Summary This document has been discussed and reviewed in the SIEVE Working Group. There is consensus in the Working Group to publish this document as a Proposed Standard. Document Quality A number of implementors have expressed interest in this extension. Personal Document Shepherd: Cyrus Daboo AD: Lisa Dusseault Note to RFC Editor In Abstract, add to the end of the sentence: , as well as for checking for mailbox existence and controlling mailbox creation on fileinto action In Section 1, add the second paragraph that reads: This document also defines an extension for checking for mailbox existence and controlling mailbox creation on fileinto action. In Section 5, add at the end of the second paragraph: For example, if the Sieve script is stored in LDAP and the script can't be retrieved when a message is processed, then the agent performing Sieve processing can, for example, assume that the script doesn't exist, or delay message delivery until the script can be retrieved successfully. Annotations should be treated as if they are a part of the script itself, so a temporary failure to retrieve them should be handled in the same way as a temporary failure to retrieve the Sieve script itself. In Section 5, add at the end of the third paragraph: For example, if Sieve scripts are retrieved using LDAP secured with TLS encryption, then the protocol used to retrieve annotations must use a comparable mechanism for providing connection confidentiality. In particular the protocol used to retrieve annotations must not be lacking encryption. From owner-ietf-mta-filters@mail.imc.org Tue Feb 3 05:45:27 2009 Return-Path: X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A707B3A6AF7 for ; Tue, 3 Feb 2009 05:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvJP4sWOPZ8r for ; Tue, 3 Feb 2009 05:45:26 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 6168B3A6AC3 for ; Tue, 3 Feb 2009 05:45:26 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13Da9F8015595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 06:36:09 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n13Da9t7015594; Tue, 3 Feb 2009 06:36:09 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13DZvHJ015580 for ; Tue, 3 Feb 2009 06:36:08 -0700 (MST) (envelope-from robertburrelldonkin@gmail.com) Received: by fk-out-0910.google.com with SMTP id 19so1619890fkr.10 for ; Tue, 03 Feb 2009 05:35:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=mHIgcM5Uw3Z8ia80je3BMRud/Eq647Pag5Zm/5s+Lq8=; b=IBpg/aCQJHhSTVH2YcU3L6CF7TQIIS5DsM2AovimGn8POCkIaz4mtmV7DldJv+sMuW OVShkLCSbRKY8z7rG9fmverJGIwwEfcf3heSaTbrkmqDQOqp1cmuK0srdwaiutVAiACd tpIHT5CiRSQ0HwEi0LWPyvTjo3Wx9sBgcYA3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=SE+iOHVLKFFtYLAvCm2P2WHzc//x1GTX8kZwZjPI1P29Kwmhau1/tWpNFNC1bWjnR+ 86/iXfIKprRpvOT/YlPjkDbvyq+SpFonutGHbd1FeEZgEQLcMhFE8b8mo+jie7xIqRZR PdyoaQCipo9NGaT+VURJqFwv4UbzAME5ywOHE= MIME-Version: 1.0 Received: by 10.181.61.2 with SMTP id o2mr2089527bkk.49.1233668156111; Tue, 03 Feb 2009 05:35:56 -0800 (PST) Date: Tue, 3 Feb 2009 13:35:56 +0000 Message-ID: Subject: [draft-freed-sieve-in-xml-02] Nonimating Code Components From: Robert Burrell Donkin To: MTA filtering mailing list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Apologies for the lateness of this submission. Note that this is a general issue and no criticism of the current draft is intended. Background ---------- 1. The IETF has issued a number of documents clarifying it's positions on rights issues required from contributors including RFC5377, BCP78 and BCP79. A license policy [1] has been issued by the IETF Trust together with a list of standard code components [2]. Code components are made available under a permissive open source license categorised in the "Simplified BSD License" family [3]. Some rights issues still remain unresolved or are delegated to the appropriate working group. 2. The Apache Software Foundation requires that the rights for all source committed are audited. In particular, specific checks are required for all documents which are not originally created by the contributor. These include both legal and ethical checks. I understand that this auditing is common amongst open source organisations. 3. draft-freed-sieve-in-xml contains section of source including the XML Schema (Appendix B) and RelaxNG (Appendix C) schemata, an extended example (Appendix A) and a stylesheet (Appendix D). 3A. These are likely to be generally useful to implementors of the specification, educators and expert users. 3B. Rights to create and publish derivative works are required before the most effective use of these material can be made. 4. As I understand it (using the terms from [1] and [2]) this material may be categorised as follows: 4A. The extended example (Appendix A) is at best only arguably a standard code component 4B. The XML Schema (Appendix B) is a standard code component 4C. The RelaxNG schema (Appendix C) is a standard code component 4D. The stylesheet (Appendix D) is at best only arguably a standard code component [1] "Legal Provisions Relating to IETF Documents" http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf [2] "Code Components List" http://trustee.ietf.org/docs/Code-Components-List-11-10-08.txt [3] "Open Source Initiative OSI - The BSD License:Licensing" http://opensource.org/licenses/bsd-license.php Issue ----- It is not clear that sufficient rights are granted to create and publish suitable derivative works of the draft so that all of the useful source contained within can be disseminated and used as widely as possible. Rights to use the useful material more widely should be clarified. Proposal -------- The working group nominates these materials (in particular Appendix A and Appendix D which do not appear to be covered in the standard list) as "code components" (as defined by [1]), and so enables them to be made widely available under the permissive open source license defined in [1]. Rationale --------- 1. One casual inspection, it might be assumed that the IETF grants enough rights to use the useful source contained in the draft. All other things being equal, rights should work as might be reasonably expected. 2. It is inconvenient for open source implementors to create clean room source for these useful documents. 3. Creating clean room implementations risks mistakes being introduced. This may reduce compatibility between implementations. From owner-ietf-mta-filters@mail.imc.org Sun Feb 8 08:26:23 2009 Return-Path: X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39733A6948 for ; Sun, 8 Feb 2009 08:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMrb6hBJhNCN for ; Sun, 8 Feb 2009 08:26:22 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id CAACE3A6828 for ; Sun, 8 Feb 2009 08:26:18 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n18GHriR058156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 09:17:53 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n18GHrLd058155; Sun, 8 Feb 2009 09:17:53 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from nostrum.com (shaman.nostrum.com [72.232.15.10]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n18GHeYB058143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 8 Feb 2009 09:17:50 -0700 (MST) (envelope-from adam@nostrum.com) Received: from hydra-3.local (ppp-70-242-118-153.dsl.rcsntx.swbell.net [70.242.118.153]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n18GHV8Z027236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 10:17:38 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <498F059B.4020901@nostrum.com> Date: Sun, 08 Feb 2009 10:17:31 -0600 From: Adam Roach User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Alexey Melnikov CC: SIEVE Working Group , draft-ietf-sieve-notify-sip-message@tools.ietf.org, Cullen Jennings , Lisa Dusseault , Mary Barnes , RAI Area Subject: Re: draft-ietf-sieve-notify-sip-message References: <4967C072.4080205@nostrum.com> <4985BC59.2040302@isode.com> In-Reply-To: <4985BC59.2040302@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.118.153 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/8965/Sun Feb 8 08:42:44 2009 on shaman.nostrum.com X-Virus-Status: Clean Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Re-sending, per list-maintainer's instructions] Alexey Melnikov wrote: > >> I would suggest that the draft be amended to either *require* a >> "method" URI parameter (with "MESSAGE" indicating the mechanism >> described in this document), or to include additional information in >> the ":options" tag that explicitly indicates the use of this >> document's mechanism. > > I think requiring the method URI parameter would be best. I agree -- that would seem to require the least specification. > >> My second area of concern is with the handling of the "From" header >> field. The draft-ietf-sieve-notify document clearly intends the >> ":from" value to indicate the value that is typically rendered to the >> contacted party as the source of the message. This intended behavior >> is upheld by the language in section 2.3 of >> draft-ietf-sieve-notify-mailto-10 (it places this value in the SMTP >> "From:" header, and even suggests using the value in the "RCPT FROM" >> command -- despite the easy availability of an SMTP "Reply-To:" >> header). This mismatch in semantics between the protocols causes me >> concern, as it may surprise users to have radically different >> treatment of the value in the ":from" tag among protocols. Given the >> text in the base sieve-notify document, I believe that the behavior >> in sieve-notify-mailto is correct, and that the behavior in >> sieve-notify-sip should be modified to align with it. > > Ok, you've convinced me that use of the SIP Reply-To header field is > not a good idea. Are you recommending use of the From SIP header field? Yes. Subject to local policy, of course -- section 3.3 of the base spec covers the policy aspects of ":from". /a From owner-ietf-mta-filters@mail.imc.org Fri Feb 27 16:12:15 2009 Return-Path: X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37123A6A9B for ; Fri, 27 Feb 2009 16:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FC3IRnjDGC40 for ; Fri, 27 Feb 2009 16:12:15 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 933213A676A for ; Fri, 27 Feb 2009 16:12:11 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1S01W9e097655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 17:01:32 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1S01WgF097654; Fri, 27 Feb 2009 17:01:32 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1S01LFE097640 for ; Fri, 27 Feb 2009 17:01:32 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.2.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 28 Feb 2009 00:01:18 +0000 Message-ID: <49A87EB7.5080504@isode.com> Date: Sat, 28 Feb 2009 00:00:55 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: Sieve WG is going to need a new co-chair Content-Type: multipart/mixed; boundary="------------040007000308050804050206" Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------040007000308050804050206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Folks, Due to the pending upgrade to IESG status, I will be stepping down as a Sieve WG co-chair after the San Francisco IETF. I've talked quickly to Cyrus about that and it looks like he will need a co-chair. If you know a good candidate, please let Cyrus Daboo , Lisa Dusseault and myself know. Volunteering for this is also encouraged. Thank you, Alexey --------------040007000308050804050206 Content-Type: message/rfc822; name="IESG appointments" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="IESG appointments" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine (Isode M-Box/14.3v2) with LMTP; Fri, 27 Feb 2009 21:04:13 +0000 (GMT) Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external) via TCP with ESMTP id for ; Fri, 27 Feb 2009 21:04:12 +0000 X-SPF-Result: PASS rufus.isode.com: domain of ietf.org designates 64.170.98.32 as permitted sender Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA68C3A6AFE; Fri, 27 Feb 2009 13:03:20 -0800 (PST) X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 3B8E53A6A6D; Fri, 27 Feb 2009 13:03:18 -0800 (PST) From: NomCom Chair To: IETF Announcement list Subject: IESG appointments Mime-Version: 1.0 Message-Id: <20090227210319.3B8E53A6A6D@core3.amsl.com> Date: Fri, 27 Feb 2009 13:03:19 -0800 (PST) X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org The 2008 / 2009 IETF Nominating committee is happy to announce the selection of individuals to serve on the IESG. First, our thanks and appreciation to those indivudals who have served who will not be continuing on the IESG. Your efforts are very much appreciated. The appointments, which have been approved by the confirming body are: IETF Chair: Russ Housley Applications AD: Alexey Melnikov Internet AD: Ralph Droms OAM AD: Ron Bonica RAI AD: Robert Sparks RTG AD: Adrian Farrel Security AD: Tim Polk Transport AD: Lars Eggert Our thanks to the incumbents who are not returning for their outstanding service, to the many qualified members of the community who offered to serve, and to the named individuals above for agreeing to serve the community on the IESG. Yours, Joel M. Halpern 2008 / 2009 IETF Nominating Committee Chair _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------040007000308050804050206-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1S01W9e097655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 17:01:32 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1S01WgF097654; Fri, 27 Feb 2009 17:01:32 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1S01LFE097640 for ; Fri, 27 Feb 2009 17:01:32 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.2.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 28 Feb 2009 00:01:18 +0000 Message-ID: <49A87EB7.5080504@isode.com> Date: Sat, 28 Feb 2009 00:00:55 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: Sieve WG is going to need a new co-chair Content-Type: multipart/mixed; boundary="------------040007000308050804050206" Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------040007000308050804050206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Folks, Due to the pending upgrade to IESG status, I will be stepping down as a Sieve WG co-chair after the San Francisco IETF. I've talked quickly to Cyrus about that and it looks like he will need a co-chair. If you know a good candidate, please let Cyrus Daboo , Lisa Dusseault and myself know. Volunteering for this is also encouraged. Thank you, Alexey --------------040007000308050804050206 Content-Type: message/rfc822; name="IESG appointments" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="IESG appointments" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine (Isode M-Box/14.3v2) with LMTP; Fri, 27 Feb 2009 21:04:13 +0000 (GMT) Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external) via TCP with ESMTP id for ; Fri, 27 Feb 2009 21:04:12 +0000 X-SPF-Result: PASS rufus.isode.com: domain of ietf.org designates 64.170.98.32 as permitted sender Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA68C3A6AFE; Fri, 27 Feb 2009 13:03:20 -0800 (PST) X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 3B8E53A6A6D; Fri, 27 Feb 2009 13:03:18 -0800 (PST) From: NomCom Chair To: IETF Announcement list Subject: IESG appointments Mime-Version: 1.0 Message-Id: <20090227210319.3B8E53A6A6D@core3.amsl.com> Date: Fri, 27 Feb 2009 13:03:19 -0800 (PST) X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org The 2008 / 2009 IETF Nominating committee is happy to announce the selection of individuals to serve on the IESG. First, our thanks and appreciation to those indivudals who have served who will not be continuing on the IESG. Your efforts are very much appreciated. The appointments, which have been approved by the confirming body are: IETF Chair: Russ Housley Applications AD: Alexey Melnikov Internet AD: Ralph Droms OAM AD: Ron Bonica RAI AD: Robert Sparks RTG AD: Adrian Farrel Security AD: Tim Polk Transport AD: Lars Eggert Our thanks to the incumbents who are not returning for their outstanding service, to the many qualified members of the community who offered to serve, and to the named individuals above for agreeing to serve the community on the IESG. Yours, Joel M. Halpern 2008 / 2009 IETF Nominating Committee Chair _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------040007000308050804050206-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n18GHriR058156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 09:17:53 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n18GHrLd058155; Sun, 8 Feb 2009 09:17:53 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from nostrum.com (shaman.nostrum.com [72.232.15.10]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n18GHeYB058143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 8 Feb 2009 09:17:50 -0700 (MST) (envelope-from adam@nostrum.com) Received: from hydra-3.local (ppp-70-242-118-153.dsl.rcsntx.swbell.net [70.242.118.153]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n18GHV8Z027236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 10:17:38 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <498F059B.4020901@nostrum.com> Date: Sun, 08 Feb 2009 10:17:31 -0600 From: Adam Roach User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Alexey Melnikov CC: SIEVE Working Group , draft-ietf-sieve-notify-sip-message@tools.ietf.org, Cullen Jennings , Lisa Dusseault , Mary Barnes , RAI Area Subject: Re: draft-ietf-sieve-notify-sip-message References: <4967C072.4080205@nostrum.com> <4985BC59.2040302@isode.com> In-Reply-To: <4985BC59.2040302@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.118.153 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/8965/Sun Feb 8 08:42:44 2009 on shaman.nostrum.com X-Virus-Status: Clean Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Re-sending, per list-maintainer's instructions] Alexey Melnikov wrote: > >> I would suggest that the draft be amended to either *require* a >> "method" URI parameter (with "MESSAGE" indicating the mechanism >> described in this document), or to include additional information in >> the ":options" tag that explicitly indicates the use of this >> document's mechanism. > > I think requiring the method URI parameter would be best. I agree -- that would seem to require the least specification. > >> My second area of concern is with the handling of the "From" header >> field. The draft-ietf-sieve-notify document clearly intends the >> ":from" value to indicate the value that is typically rendered to the >> contacted party as the source of the message. This intended behavior >> is upheld by the language in section 2.3 of >> draft-ietf-sieve-notify-mailto-10 (it places this value in the SMTP >> "From:" header, and even suggests using the value in the "RCPT FROM" >> command -- despite the easy availability of an SMTP "Reply-To:" >> header). This mismatch in semantics between the protocols causes me >> concern, as it may surprise users to have radically different >> treatment of the value in the ":from" tag among protocols. Given the >> text in the base sieve-notify document, I believe that the behavior >> in sieve-notify-mailto is correct, and that the behavior in >> sieve-notify-sip should be modified to align with it. > > Ok, you've convinced me that use of the SIP Reply-To header field is > not a good idea. Are you recommending use of the From SIP header field? Yes. Subject to local policy, of course -- section 3.3 of the base spec covers the policy aspects of ":from". /a Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13Da9F8015595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 06:36:09 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n13Da9t7015594; Tue, 3 Feb 2009 06:36:09 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13DZvHJ015580 for ; Tue, 3 Feb 2009 06:36:08 -0700 (MST) (envelope-from robertburrelldonkin@gmail.com) Received: by fk-out-0910.google.com with SMTP id 19so1619890fkr.10 for ; Tue, 03 Feb 2009 05:35:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=mHIgcM5Uw3Z8ia80je3BMRud/Eq647Pag5Zm/5s+Lq8=; b=IBpg/aCQJHhSTVH2YcU3L6CF7TQIIS5DsM2AovimGn8POCkIaz4mtmV7DldJv+sMuW OVShkLCSbRKY8z7rG9fmverJGIwwEfcf3heSaTbrkmqDQOqp1cmuK0srdwaiutVAiACd tpIHT5CiRSQ0HwEi0LWPyvTjo3Wx9sBgcYA3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=SE+iOHVLKFFtYLAvCm2P2WHzc//x1GTX8kZwZjPI1P29Kwmhau1/tWpNFNC1bWjnR+ 86/iXfIKprRpvOT/YlPjkDbvyq+SpFonutGHbd1FeEZgEQLcMhFE8b8mo+jie7xIqRZR PdyoaQCipo9NGaT+VURJqFwv4UbzAME5ywOHE= MIME-Version: 1.0 Received: by 10.181.61.2 with SMTP id o2mr2089527bkk.49.1233668156111; Tue, 03 Feb 2009 05:35:56 -0800 (PST) Date: Tue, 3 Feb 2009 13:35:56 +0000 Message-ID: Subject: [draft-freed-sieve-in-xml-02] Nonimating Code Components From: Robert Burrell Donkin To: MTA filtering mailing list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Apologies for the lateness of this submission. Note that this is a general issue and no criticism of the current draft is intended. Background ---------- 1. The IETF has issued a number of documents clarifying it's positions on rights issues required from contributors including RFC5377, BCP78 and BCP79. A license policy [1] has been issued by the IETF Trust together with a list of standard code components [2]. Code components are made available under a permissive open source license categorised in the "Simplified BSD License" family [3]. Some rights issues still remain unresolved or are delegated to the appropriate working group. 2. The Apache Software Foundation requires that the rights for all source committed are audited. In particular, specific checks are required for all documents which are not originally created by the contributor. These include both legal and ethical checks. I understand that this auditing is common amongst open source organisations. 3. draft-freed-sieve-in-xml contains section of source including the XML Schema (Appendix B) and RelaxNG (Appendix C) schemata, an extended example (Appendix A) and a stylesheet (Appendix D). 3A. These are likely to be generally useful to implementors of the specification, educators and expert users. 3B. Rights to create and publish derivative works are required before the most effective use of these material can be made. 4. As I understand it (using the terms from [1] and [2]) this material may be categorised as follows: 4A. The extended example (Appendix A) is at best only arguably a standard code component 4B. The XML Schema (Appendix B) is a standard code component 4C. The RelaxNG schema (Appendix C) is a standard code component 4D. The stylesheet (Appendix D) is at best only arguably a standard code component [1] "Legal Provisions Relating to IETF Documents" http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf [2] "Code Components List" http://trustee.ietf.org/docs/Code-Components-List-11-10-08.txt [3] "Open Source Initiative OSI - The BSD License:Licensing" http://opensource.org/licenses/bsd-license.php Issue ----- It is not clear that sufficient rights are granted to create and publish suitable derivative works of the draft so that all of the useful source contained within can be disseminated and used as widely as possible. Rights to use the useful material more widely should be clarified. Proposal -------- The working group nominates these materials (in particular Appendix A and Appendix D which do not appear to be covered in the standard list) as "code components" (as defined by [1]), and so enables them to be made widely available under the permissive open source license defined in [1]. Rationale --------- 1. One casual inspection, it might be assumed that the IETF grants enough rights to use the useful source contained in the draft. All other things being equal, rights should work as might be reasonably expected. 2. It is inconvenient for open source implementors to create clean room source for these useful documents. 3. Creating clean room implementations risks mistakes being introduced. This may reduce compatibility between implementations. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12HaoWc058140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 10:36:50 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12HaolI058139; Mon, 2 Feb 2009 10:36:50 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12HaoQp058133 for ; Mon, 2 Feb 2009 10:36:50 -0700 (MST) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id 4A27C28C259; Mon, 2 Feb 2009 09:36:32 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , sieve mailing list , sieve chair Subject: Protocol Action: 'The Sieve mail filtering language - extensions for checking mailbox status and accessing mailbox metadata' to Proposed Standard Message-Id: <20090202173632.4A27C28C259@core3.amsl.com> Date: Mon, 2 Feb 2009 09:36:32 -0800 (PST) Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'The Sieve mail filtering language - extensions for checking mailbox status and accessing mailbox metadata ' as a Proposed Standard This document is the product of the Sieve Mail Filtering Language Working Group. The IESG contact persons are Lisa Dusseault and Chris Newman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-melnikov-sieve-imapext-metadata-08.txt Technical Summary The SIEVE mail filtering language - extension for accessing mailbox metadata extension provides a way for a SIEVE script to test annotations stored on an IMAP server supporting the METADATA extension. Working Group Summary This document has been discussed and reviewed in the SIEVE Working Group. There is consensus in the Working Group to publish this document as a Proposed Standard. Document Quality A number of implementors have expressed interest in this extension. Personal Document Shepherd: Cyrus Daboo AD: Lisa Dusseault Note to RFC Editor In Abstract, add to the end of the sentence: , as well as for checking for mailbox existence and controlling mailbox creation on fileinto action In Section 1, add the second paragraph that reads: This document also defines an extension for checking for mailbox existence and controlling mailbox creation on fileinto action. In Section 5, add at the end of the second paragraph: For example, if the Sieve script is stored in LDAP and the script can't be retrieved when a message is processed, then the agent performing Sieve processing can, for example, assume that the script doesn't exist, or delay message delivery until the script can be retrieved successfully. Annotations should be treated as if they are a part of the script itself, so a temporary failure to retrieve them should be handled in the same way as a temporary failure to retrieve the Sieve script itself. In Section 5, add at the end of the third paragraph: For example, if Sieve scripts are retrieved using LDAP secured with TLS encryption, then the protocol used to retrieve annotations must use a comparable mechanism for providing connection confidentiality. In particular the protocol used to retrieve annotations must not be lacking encryption. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11FFEaP093667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 08:15:14 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11FFEld093666; Sun, 1 Feb 2009 08:15:14 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11FFCZF093660 for ; Sun, 1 Feb 2009 08:15:13 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [92.40.116.35] (92.40.116.35.sub.mbb.three.co.uk [92.40.116.35]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 1 Feb 2009 15:15:09 +0000 Message-ID: <4985BC59.2040302@isode.com> Date: Sun, 01 Feb 2009 15:14:33 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Adam Roach CC: SIEVE Working Group , draft-ietf-sieve-notify-sip-message@tools.ietf.org, Cullen Jennings , Lisa Dusseault , Mary Barnes , RAI Area Subject: Re: draft-ietf-sieve-notify-sip-message References: <4967C072.4080205@nostrum.com> In-Reply-To: <4967C072.4080205@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Adam Roach wrote: > Mary Barnes has asked me to perform an expert review on > draft-ietf-sieve-notify-sip-message for the RAI area. Hi Adam, Thank you for the review and sorry for the slow response. > Overall, the approach in the document seems good. However, there are > two relatively minor details that cause me some concern. I think these > should be rather straightforward to fix. > > My first area of concern is that, while this seems a reasonable way to > perform this functionality in SIP, I don't think it's the only > reasonable way to do it in SIP. Consequently, this document needs to > take care not to preclude future SIP mechanisms for SIEVE > notifications. For example, the conveyance of more semantic > information in a PUBLISH message would be quite useful when there is a > dynamically changing community of parties interested in receiving > notifications. (The PUBLISH would be sent to an event agent, which > could then receive SUBSCRIBE requests from interested parties). This > may be applicable, for example, when monitoring shared resources, such > as technical support email queues. > > However, the draft makes an implicit assumption that any SIEVE > notification method URI starting with "sip:" necessarily will make use > of the mechanism it defines, and never any other. There is no means > for disambiguating among multiple mechanisms. In fact, the draft seems > to go out of its way to ruin an extensibility mechanism that it would > have automatically inherited from SIP: "The URI parameter 'method' > MUST be ignored, because only the MESSAGE method is allowed by this > specification." Right. I agree that allowing other SIP methods might be useful in the future. > I would suggest that the draft be amended to either *require* a > "method" URI parameter (with "MESSAGE" indicating the mechanism > described in this document), or to include additional information in > the ":options" tag that explicitly indicates the use of this > document's mechanism. I think requiring the method URI parameter would be best. > My second area of concern is with the handling of the "From" header > field. The draft-ietf-sieve-notify document clearly intends the > ":from" value to indicate the value that is typically rendered to the > contacted party as the source of the message. This intended behavior > is upheld by the language in section 2.3 of > draft-ietf-sieve-notify-mailto-10 (it places this value in the SMTP > "From:" header, and even suggests using the value in the "RCPT FROM" > command -- despite the easy availability of an SMTP "Reply-To:" > header). This mismatch in semantics between the protocols causes me > concern, as it may surprise users to have radically different > treatment of the value in the ":from" tag among protocols. Given the > text in the base sieve-notify document, I believe that the behavior in > sieve-notify-mailto is correct, and that the behavior in > sieve-notify-sip should be modified to align with it. Ok, you've convinced me that use of the SIP Reply-To header field is not a good idea. Are you recommending use of the From SIP header field? > (Indication of the sending server can be made via other means, such as > the SIP Call-Info: header field). > > Responses to the SIEVE working group mailing list, CC me.