From nobody Wed Aug 9 17:14:33 2017 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D34126DD9 for ; Wed, 9 Aug 2017 17:14:31 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 QYJjI6eWzBQe for ; Wed, 9 Aug 2017 17:14:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF1A126C2F for ; Wed, 9 Aug 2017 17:14:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CAB68B81503; Wed, 9 Aug 2017 17:14:16 -0700 (PDT) To: bernard.desruisseaux@oracle.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, lear@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: georges@mhsoftware.com, calsify@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170810001416.CAB68B81503@rfc-editor.org> Date: Wed, 9 Aug 2017 17:14:16 -0700 (PDT) Archived-At: Subject: [calsify] [Technical Errata Reported] RFC5545 (5082) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 00:14:32 -0000 The following errata report has been submitted for RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5082 -------------------------------------- Type: Technical Reported by: George Sexton Section: 3.8.7.3 Original Text ------------- N/A Corrected Text -------------- The value must not be in the future. Notes ----- If future values are allowed for LAST-MODIFIED, it makes it very difficult for software to perform change management for a VEVENT. Say for example, an event is imported from a source and the VEVENT has a future date. For example, December 20 2017 12:00:00Z That event is then edited and assigned the actual correct date and time. Say August 9 2017 13:45:44Z. Software that examines the VEVENT's LAST-MODIFIED to determine if the VEVENT record has been modified will not see the VEVENT is updated. In order for different systems to perform change management, the value for LAST-MODIFIED should NEVER be a future date. Instructions: ------------- This erratum 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 can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5545 (draft-ietf-calsify-rfc2445bis-10) -------------------------------------- Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Publication Date : September 2009 Author(s) : B. Desruisseaux, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG From nobody Mon Aug 14 09:21:27 2017 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C62124207; Mon, 14 Aug 2017 09:21:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-calext-caldav-attachments@ietf.org, calext-chairs@ietf.org, mozilla@kewis.ch, calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150272768600.436.2676554419442638858.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 09:21:26 -0700 Archived-At: Subject: [calsify] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-calext-caldav-attachments-03=3A_=28with_COMMENT=29?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 16:21:26 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-calext-caldav-attachments-03: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-calext-caldav-attachments/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- To be honest I find the solution to publish this as informational a bit strange given it is implemeted and deployed. However, this is really not my expetise. From nobody Tue Aug 15 12:11:43 2017 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F01126BF3; Tue, 15 Aug 2017 12:11:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-calext-caldav-attachments@ietf.org, calext-chairs@ietf.org, mozilla@kewis.ch, calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150282429587.21073.18089035009674224535.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 12:11:35 -0700 Archived-At: Subject: [calsify] Warren Kumari's No Objection on draft-ietf-calext-caldav-attachments-03: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 19:11:36 -0000 Warren Kumari has entered the following ballot position for draft-ietf-calext-caldav-attachments-03: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-calext-caldav-attachments/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Mirja's concerns / confusion on the change from PS to Informational. I read the background / shepherds write-up with explains this, but am still not hugely comfortable with the situation -- if it is PS material, and is implemented by a number of folk, PS seems acceptable -- but then again, I fully get the desire to just get it shipped and done. I had thought that I'd made some notes somewhere on an earlier version, but can no longer find them. I'm fairly sure that they were written on a plane heading somewhere, and were only minor nits, so... From nobody Wed Aug 16 15:16:46 2017 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A32EC132733; Wed, 16 Aug 2017 15:16:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-calext-caldav-attachments@ietf.org, calext-chairs@ietf.org, mozilla@kewis.ch, calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150292180466.12103.5598790566803871517.idtracker@ietfa.amsl.com> Date: Wed, 16 Aug 2017 15:16:44 -0700 Archived-At: Subject: [calsify] Ben Campbell's No Objection on draft-ietf-calext-caldav-attachments-03: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 22:16:45 -0000 Ben Campbell has entered the following ballot position for draft-ietf-calext-caldav-attachments-03: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-calext-caldav-attachments/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Loosely related to Mirja's comment: The abstract mentions why this is informational. That information should be repeated in the Introduction. It would be helpful to see that expanded (in the introduction) to explain what the non-standard bits are, and if there are preferred approaches (whether standards or potential standards.) - 3.12.2: "Access to the managed attachments store in a calendar object resource SHOULD be restricted to only those calendar users who have access to that calendar object either directly, or indirectly (via being an attendee who would receive a scheduling message)." Why not MUST? When might it make sense to allow others to access attachments? From nobody Wed Aug 16 16:02:48 2017 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A921326A3; Wed, 16 Aug 2017 16:02:47 -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 autolearn_force=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 N4EUNvSqcByG; Wed, 16 Aug 2017 16:02:43 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (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 AAC97132480; Wed, 16 Aug 2017 16:02:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B847476B784B; Wed, 16 Aug 2017 19:02:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FbY3TYRRgDb; Wed, 16 Aug 2017 19:02:42 -0400 (EDT) Received: from [10.0.1.16] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id ACCB876B7840; Wed, 16 Aug 2017 19:02:40 -0400 (EDT) Date: Wed, 16 Aug 2017 19:02:38 -0400 From: Cyrus Daboo To: Ben Campbell , The IESG cc: draft-ietf-calext-caldav-attachments@ietf.org, mozilla@kewis.ch, calext-chairs@ietf.org, calsify@ietf.org Message-ID: In-Reply-To: <150292180466.12103.5598790566803871517.idtracker@ietfa.amsl.com> References: <150292180466.12103.5598790566803871517.idtracker@ietfa.amsl.com> 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=1137 Archived-At: Subject: Re: [calsify] Ben Campbell's No Objection on draft-ietf-calext-caldav-attachments-03: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 23:02:47 -0000 Hi Ben, --On August 16, 2017 at 3:16:44 PM -0700 Ben Campbell wrote: > - 3.12.2: "Access to the managed attachments store in a calendar object > resource SHOULD be restricted to only those calendar users who have > access to that calendar object either directly, or indirectly (via > being an attendee who would receive a scheduling message)." > > Why not MUST? When might it make sense to allow others to access > attachments? Well there are several different ways in which a calendar user might have access to another calendar users' data - such as delegation and sharing. But perhaps that is implied by the statement above. How about (with one typo fixed too): Access to the managed attachments stored in a calendar object resource MUST be restricted to only those calendar users who are authorized to access that calendar object either directly, or indirectly (via being an attendee who would receive a scheduling message). (If the above is acceptable I will leave it to Ken to make the change since he has the "edit token". Or Alexey can add as an RFC editor note.) -- Cyrus Daboo From nobody Wed Aug 16 18:18:55 2017 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491FB132391; Wed, 16 Aug 2017 18:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 vaqodUFpvcTx; Wed, 16 Aug 2017 18:18:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC1A126BF0; Wed, 16 Aug 2017 18:18:44 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7H1IUNV071338 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Aug 2017 20:18:35 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Wed, 16 Aug 2017 20:18:30 -0500 Cc: The IESG , draft-ietf-calext-caldav-attachments@ietf.org, mozilla@kewis.ch, calext-chairs@ietf.org, calsify@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150292180466.12103.5598790566803871517.idtracker@ietfa.amsl.com> To: Cyrus Daboo X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [calsify] Ben Campbell's No Objection on draft-ietf-calext-caldav-attachments-03: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 01:18:48 -0000 > On Aug 16, 2017, at 6:02 PM, Cyrus Daboo wrote: >=20 > Hi Ben, >=20 > --On August 16, 2017 at 3:16:44 PM -0700 Ben Campbell = wrote: >=20 >> - 3.12.2: "Access to the managed attachments store in a calendar = object >> resource SHOULD be restricted to only those calendar users who = have >> access to that calendar object either directly, or indirectly (via >> being an attendee who would receive a scheduling message)." >>=20 >> Why not MUST? When might it make sense to allow others to access >> attachments? >=20 > Well there are several different ways in which a calendar user might = have access to another calendar users' data - such as delegation and = sharing. But perhaps that is implied by the statement above. How about = (with one typo fixed too): >=20 > Access to the managed attachments stored in a calendar object = resource > MUST be restricted to only those calendar users who are authorized to > access that calendar object either directly, or indirectly (via being > an attendee who would receive a scheduling message). That works for me. (Although I would have also been happy with a SHOULD = along with some guidance on when it might make sense to do otherwise.) >=20 > (If the above is acceptable I will leave it to Ken to make the change = since he has the "edit token". Or Alexey can add as an RFC editor note.) >=20 > --=20 > Cyrus Daboo >=20 From nobody Wed Aug 16 19:14:30 2017 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6890E1321F0; Wed, 16 Aug 2017 19:14:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-calext-caldav-attachments@ietf.org, calext-chairs@ietf.org, mozilla@kewis.ch, calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150293606942.12436.9685335940269519919.idtracker@ietfa.amsl.com> Date: Wed, 16 Aug 2017 19:14:29 -0700 Archived-At: Subject: [calsify] Adam Roach's No Objection on draft-ietf-calext-caldav-attachments-03: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 02:14:29 -0000 Adam Roach has entered the following ballot position for draft-ietf-calext-caldav-attachments-03: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-calext-caldav-attachments/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Regarding concerns from others on the topic of document status: even without the ARTART review, I would have DISCUSSed the top-level issues identified by Julian, and in particular the hardcoding of query strings. I would be quite uncomfortable with the precedent of a PS document going out in that form. I'm a little squeamish about having it in an Informational document, but given the apparently pervasive deployment indicated by section 7, I suppose it's better to have it documented than not. Section 3.2 is ambiguous about whether the use of "calendar-managed-attachments-no-recurrance" is in addition to or instead of "calendar-managed-attachments." In this sentence, please replace "the server MUST include" with "the server MUST also include" or "the server MUST instead include", depending on what is intended here. I'd be happy if section 3.12.3 indicated that such redirects are performed with 307 or 308 responses, as other redirect codes change the method from POST to GET. Presumably, when section 7 is removed, section 11.3 is to also be removed? The document should indicate this. Please expand iTIP (iCalendar Transport-independent Interoperability Protocol) on first use. From nobody Thu Aug 17 06:39:51 2017 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE8B132400; Thu, 17 Aug 2017 06:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=SmREOs52; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XHyRIG67 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 GT3ttmjOCQsC; Thu, 17 Aug 2017 06:39: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 5D7B31323CE; Thu, 17 Aug 2017 06:39:47 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C480820A0C; Thu, 17 Aug 2017 09:39:46 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 17 Aug 2017 09:39:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=TaVQMiGTmFZfUQ+nq1XoSopSrT2yn uqWrh81rf0UhhY=; b=SmREOs52/EwiFdHTt3wLZykhKvbh2cnGaNfOOJCFxLce3 f9ocMduBqdCKQZlEfh1Kays1ZXsZPX4ihGxf7lzi2eEY0uFFDvaxaFeMuzdILLHD KdjK5fKGtsOPc9J0faf3VbepdF30ttZxQAIA8atDYida7HjkjuHUk1GJDi1Q/Wbi UF5bdRpWk7tq+SvKSAKcQ1KgPk3nbn7mv10UDFdUyOZ+VyIvy/d7dWMj7xK04fVt i+sCyMbwqLSIdEIX5u5rxSC39wRGPJ9mKmyFVr7CXY6AUkIvx9j0z0TsrTQ9GGKG b+E0Qvm40U0gywyZ6n8tRrtcXrK0PlR4Q3dNWDjyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=TaVQMi GTmFZfUQ+nq1XoSopSrT2ynuqWrh81rf0UhhY=; b=XHyRIG67rMuj1LUE+/x5cc NvzZnqeAenMztQkU6WX5E2bx3cguuZRxT41BTAzWgM1RYWA600T/vavJ2NhxYnyp TOAZpQHJGd11yL07OiaCfdlj/tP1fZASmpZvqfYiDQJxqQ/suEi9XxhsdWaG/RMI MdrSGz4vjDKsyc7A9cugspCkOGk9rlB5Fdtph9UL5FSZbiHS6HHgO20dYGPQNaE8 FbjrmMOZJYFfYuSNwNvdz/BHs6pgYAz0p01BByNFoqVZPMVNI2xBii9kckJ9VfAO qPeUyVez8hptcKct52Rt2ek+BnEVzOsBaXT5rANWy/3/gdk/rKyRv7gL7hC2O7GQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A3FAF9E308; Thu, 17 Aug 2017 09:39:46 -0400 (EDT) Message-Id: <1502977186.40303.1076432640.1CF2BC64@webmail.messagingengine.com> From: Alexey Melnikov To: Cyrus Daboo Cc: calext-chairs@ietf.org, draft-ietf-calext-caldav-attachments@ietf.org, The IESG , mozilla@kewis.ch, calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 In-Reply-To: References: <150292180466.12103.5598790566803871517.idtracker@ietfa.amsl.com> Date: Thu, 17 Aug 2017 14:39:46 +0100 Archived-At: Subject: Re: [calsify] Ben Campbell's No Objection on draft-ietf-calext-caldav-attachments-03: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 13:39:50 -0000 Cyrus, On Thu, Aug 17, 2017, at 02:18 AM, Ben Campbell wrote: > > > On Aug 16, 2017, at 6:02 PM, Cyrus Daboo wrote: > > > > Hi Ben, > > > > --On August 16, 2017 at 3:16:44 PM -0700 Ben Campbell wrote: > > > >> - 3.12.2: "Access to the managed attachments store in a calendar object > >> resource SHOULD be restricted to only those calendar users who have > >> access to that calendar object either directly, or indirectly (via > >> being an attendee who would receive a scheduling message)." > >> > >> Why not MUST? When might it make sense to allow others to access > >> attachments? > > > > Well there are several different ways in which a calendar user might have access to another calendar users' data - such as delegation and sharing. But perhaps that is implied by the statement above. How about (with one typo fixed too): > > > > Access to the managed attachments stored in a calendar object resource > > MUST be restricted to only those calendar users who are authorized to > > access that calendar object either directly, or indirectly (via being > > an attendee who would receive a scheduling message). > > That works for me. (Although I would have also been happy with a SHOULD > along with some guidance on when it might make sense to do otherwise.) > > > > > (If the above is acceptable I will leave it to Ken to make the change since he has the "edit token". Or Alexey can add as an RFC editor note.) I am happy with your proposal as well. From nobody Mon Aug 21 02:33:33 2017 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915FB13236D; Mon, 21 Aug 2017 02:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com 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 S5nRdFm6Szmf; Mon, 21 Aug 2017 02:33:31 -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 1E70713219B; Mon, 21 Aug 2017 02:33:31 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 84CF220D11; Mon, 21 Aug 2017 05:33:30 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute1.internal (MEProxy); Mon, 21 Aug 2017 05:33:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=ex35w4dMveCVbn8PSe9MH/H/P45oM t/ekit2eY3RVWI=; b=nvNYfnpfV8DqblcIC5R0HmckWg6hSbRh/0/7OxHXl4XDJ 8ouJjoZuDCJQ04sInRqG+LkKHfZ5ZypWLuYX1RPbVsb42mzB0i6dtlIWAE5IYv9k XoOp4Hjz4l59QU9Vhdw2CTxfTLH72qU3Jl+Tf5C63c8pifwhKojYVDL2AYW56iJ4 V97/TESe8isPd0w9bYyBWALZdE8VoU2wkRGwvK8ovIL8gMSizKtgprJtF7v0UEzh xkCAoiPBcrE1LteuEpp03Tulj8/8zvfWBnJ7YCUsv6dBWChu1dwMw9Yddg3SqwZu b+RA4wyTEWsivx7TjxwdPZi9t2jeLxlReiHAGtmjg== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6B539956F6; Mon, 21 Aug 2017 05:33:30 -0400 (EDT) Message-Id: <1503308010.2063518.1079799216.5578F6F7@webmail.messagingengine.com> From: Robert Stepanek To: dispatch@ietf.org, calsify@ietf.org Cc: Bron Gondwana , Neil Jenkins MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 Date: Mon, 21 Aug 2017 11:33:30 +0200 Archived-At: Subject: [calsify] RFC draft for JSCalendar, an alternative to iCalendar X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 09:33:32 -0000 Hi, A couple of days ago we uploaded a draft for a new JSON-based representation of calendar data: https://datatracker.ietf.org/doc/draft-jenkins-jscalendar/ The draft is the result of extensive discussions within the CalConnect calendaring consortium, and we already know of at least two implementations of the current spec (one at FastMail). My IETF contact Alexey Melnikov advised me to ask for your review and feedback on the spec and where to dispatch it for future discussion. I'll be happy to answer any questions around the spec. Thanks in advance, Cheers, Robert