From nobody Fri Feb 3 10:14:39 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 D4AC212948B; Fri, 3 Feb 2017 10:14:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148614567386.4033.974622973440257210.idtracker@ietfa.amsl.com> Date: Fri, 03 Feb 2017 10:14:33 -0800 Archived-At: Cc: calsify@ietf.org Subject: [calsify] I-D Action: draft-ietf-calext-ical-relations-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 18:14:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions of the IETF. Title : Support for iCalendar Relationships Author : Michael Douglass Filename : draft-ietf-calext-ical-relations-01.txt Pages : 19 Date : 2017-02-03 Abstract: This specification updates RELATED-TO and introduces new iCalendar properties LINK, STRUCTURED-CATEGORY and REFID to allow better linking and grouping of iCalendar components and related data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-ical-relations/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-calext-ical-relations-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-ical-relations-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 Fri Feb 3 10:18:46 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 9C10D1294B2 for ; Fri, 3 Feb 2017 10:18:45 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3saA73gzUkD2 for ; Fri, 3 Feb 2017 10:18:44 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 2C8791294AA for ; Fri, 3 Feb 2017 10:18:44 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id x49so46319580qtc.2 for ; Fri, 03 Feb 2017 10:18:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=9g8t5/4zusCtoQF93RgxquWH29wLYSyvjaQyHHeoeqU=; b=KIkzn3MUl9cLGOVDjob7AT0F6GbtjfNWlK3dDrTd0jxBZsvpPJkWunC0d942VA1WDl oswT80iehqTWO0htEOgJLiykqAVmJYHBvJ9WJQO0mipVKhJKL55alR3cYMMdFhswDO+3 Toul698xrWL8JI0iDKkk0u+EPedzJ6dX79CZ2Lx5lkDevQzsW/fQdwv+IdRVsZYHT1/M jzN/FqGkzClEfELs2GV4zRsBihXA2NH2gCO6u5fcWvbNuq49o3WhgfdogOGNVJqkCPyN hJ3W0HY/8yPfeRmiVJJtfgd8PTtdIrSPX01qQT1mASCv2R6hk99Z6zu2eZQYjl0G2QUH yRMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=9g8t5/4zusCtoQF93RgxquWH29wLYSyvjaQyHHeoeqU=; b=D4u72US4HiUTrYpOHU5jdTlaplnbxQazF2jaPzkXe3FUJ3iTNFmKdhf/SYoBpj/2L7 jboq2uaoZPH4+9+GTWM1e/IakVljpCazHRplI2m4X53cMfVtpvISLxVEh3TBGUp10tH1 USInczakUyH+1tnsdJqWqYESRJHA1kkJ9sldylyxqXKhpfJQ7Rvz+a8ZLWb/N43nXJvj HTFQHk+BBmuPZF8We9yZ1nyoE/aH7uBXFhx2Ex+UXqz3aurDzWzU39gipIIxUELOiW1r HhUB/0Hm3pKJUhdRWJG+OokZLTUWWNbDWrcXCa9qK18y01nOe6l+ZD8gKK9gzkMPgj/u kSFQ== X-Gm-Message-State: AIkVDXIvOmUP78WShxOmlcaSy+3PVYvtZ/VOgrYbOJCUbMaN6EQssOj49HVjvYp27yWm2A== X-Received: by 10.237.42.1 with SMTP id c1mr14120634qtd.10.1486145923343; Fri, 03 Feb 2017 10:18:43 -0800 (PST) Received: from Michaels-MacBook-Pro.local (cpe-67-252-53-251.nycap.res.rr.com. [67.252.53.251]) by smtp.googlemail.com with ESMTPSA id b36sm25073631qte.21.2017.02.03.10.18.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 10:18:42 -0800 (PST) From: Michael Douglass To: Ken Murchison , Calsify References: Message-ID: <3d0cac84-3c32-14d4-fbbc-75c9841c3f54@gmail.com> Date: Fri, 3 Feb 2017 13:18:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [calsify] Review of draft-ietf-calext-ical-relations-00 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 18:18:45 -0000 Thanks Ken. Changes made and new version uploaded. One thought I'd prefer some other name than STRUCTURED-CATEGORY though I could live with it (names are often that hardest part). CATEGORY-REF might get the sense across better - even though there may eb a structured category entity out there somewhere this is really a reference to it - it may be just the path part or it may eb an absolute url but I think it's still a reference. On 1/17/17 17:11, Ken Murchison wrote: > Overall, this document looks good. Comments below. > > - There are several instances of "Icalendar", which should be changed > to "iCalendar" Done > > - Since we update the RELATED-TO property, the boilerplate should > state that this document updates RFC 5545 > Done > - Sec 1.1, last para, last sent: "These changes allows ..." -> "These > changes allow ..." > Done > - Sec 1.4, last para: Should the discussion of ATTACH handling > reference draft-ietf-calext-caldav-attachments? Done > > - Sec 4, para 1, last sent: "... a link to an component ..." -> "... a > link to a component ..." Done > > - Sec 4, Description, para 2: "It defines ..." -> "This parameter > defines ..." > Done > - Sec, 7: For the new non-TEXT properties, should we explicitly state > that there is NO default value type to force producers to always > include VALUE= so that consumers not familiar with the property don't > assume an incorrect type? > > - Sec 7.1, Description, last sent: presumably the Bedework reference > needs to be changes to something else Changed to "In addition, a structured URI value allows for hierarchical categorization of events." (refactor caused the bedework ref) > > - Sec 7.2: Value type is listed as URI, TEXT, or REFERENCE, but the > definition only shows URI and REFERENCE Fixed - I think the abnf was broken as well > > - Sec 8.1: Value type UID appears to be missing Fixed > > - Sec 10.2: I don't think STRUCTURED-CATEGORY belongs. Its not a > parameter. Removed - copy-paste error > > - Sec 10.4: I don't think REL belongs Ditto > > From nobody Fri Feb 3 10:47:50 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 1F7AA1294E5 for ; Fri, 3 Feb 2017 10:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, 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 (1024-bit key) header.d=kewis.ch header.b=MQi6jDP7; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=PKgCt1fA 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 2vc76TNE8AH9 for ; Fri, 3 Feb 2017 10:47:47 -0800 (PST) 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 666271294D5 for ; Fri, 3 Feb 2017 10:47:47 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EC99520571; Fri, 3 Feb 2017 13:47:45 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 03 Feb 2017 13:47:45 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=kewis.ch; h= 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:x-sasl-enc; s=mesmtp; bh=5uYYZbmy7pesswT qhSwWWCcT77s=; b=MQi6jDP7de3ElbyJyqlmVXK/xaujONRrYlz6UNNyrWl3lgi DZ+Gc7GYfsDoz6lvUynG8jv8Mp8x+gZzqj7aRk4fXiaUtntHR3182mmNkuF2LmKR kauvnGcu/EWfKSf4A87yVbGrnz61LX5BC4gme2PRE3a9zMMP8gF8oeBT+8vY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=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:x-sasl-enc; s= smtpout; bh=5uYYZbmy7pesswTqhSwWWCcT77s=; b=PKgCt1fAPdDK1Wd/1N7f hYa14nTiCA6hVHEbYm99fpOL3J1khfqSazNFMvag0JjyNmikafbEUzWk1bOuDnDU EMiZXr2Jk+6p79/cwqhFusohF7ihmrwZf6mZugzvwGZoccgh8umn4ab5FGD6eSm4 O4QV08LsmYgUy245t71jUaU= X-ME-Sender: X-Sasl-enc: 2BoZH8qxn+nGUhWj2nLq3QUogK5iS8jo4a36D/REOeA5 1486147665 Received: from [10.43.0.217] (unknown [109.236.136.146]) by mail.messagingengine.com (Postfix) with ESMTPA id 713CF7E53B; Fri, 3 Feb 2017 13:47:45 -0500 (EST) To: Ken Murchison , Calsify References: From: Philipp Kewisch Message-ID: Date: Fri, 3 Feb 2017 19:47:44 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:51.0) Gecko/20100101 Thunderbird/51.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [calsify] Review of draft-ietf-calext-ical-relations-00 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 18:47:49 -0000 Hi All, sorry this is just a moment to late for 01, I was actually typing this up on the plane this morning. Anyway, some comments to consider for -02. Philipp --8>-- Hi All, thanks for making the comments. I've reviewed this document with my calext co-chair role in mind. The changes Ken has suggested sound reasonable to me. Here are a few comments I would like to see discussed: > - Sec 1.4, last para: Should the discussion of ATTACH handling > reference draft-ietf-calext-caldav-attachments? I would also suggest to reword this paragraph. As the content will be permanent I believe it would be better not to reference future work. Therefore we should either publish the caldav attachments document first and then reference it, or reword it to generally explain why LINK should not be considered the same as an attachment. > > - Sec, 7: For the new non-TEXT properties, should we explicitly state > that there is NO default value type to force producers to always > include VALUE= so that consumers not familiar with the property don't > assume an incorrect type? > > - Sec 10.2: I don't think STRUCTURED-CATEGORY belongs. Its not a > parameter. I do not feel that STRUCTURED-CATEGORY can be considered a "relation", which this draft is about. Maybe it makes sense to move this to a different document? Also, some further comments: 1) Section 1.2, can you explain this property in a bit more detail? The introduction sounds very generic and from reading it without the rest of the document I wouldn't know how to use it. 2) Section 1.3, " Unlike REFID the category imparts some meaning" -- can you explain or reword "some meaning". This sounds very generic. In the next sentence I'd also suggest replacing " It is assumed" with something more concrete. 3) Section 2, the REFERENCE type seems to fulfill a very specific use case. I briefly read that xpointers can also be expressed in URIs, maybe we can just re-use that? 4) Section 3, there is something missing from the last sentence of the first paragraph 5) Section 4, are the relations strictly limited to calendar components? The text reads that way, but I was thinking it could also be other values. I would also explcitly mention which properties the reltypeparam (currently) applies to. 6) Section 4, "Applications MUST treat x-name and iana-token values they don't recognize the same way as they would the PARENT value" -- so if an unrecognized value is used, then this automatically becomes a parent? What if there is already a parent? Would that mean the item has multiple parents? I'd appreciate some clarification why the default PARENT makes sense here. 7) Section 7.3, maybe you can explain better how REFID is used in the intro to that section, specifically what kind of values would be common. I see the example later on, but that only marginally helps understand what it does. Maybe you can include a sentence that describes in what other places the REFID may be used? 8) Section 8.1, maybe you can mention non-standard at the end instead of the beginning. 9) Section 6, "VALUE=UID indicates that the associated value is the UID for a component" -- Maybe you can elaborate on what a UID formally is, with references to other documents. 10) Section 9, would it be a security concern that the relations may reference components in another system that are meant to be private? If relations between items are defined with this amount of structure, it could allow making assumptions on private components. Mike, I'd appreciate if you could also comment on the previous items and fix the nits.n. I would also appreciate if you could provide some details as to which vendors have implemented the draft so far. To anyone else reading this, please voice your concerns so we can move this draft along. Thank you very much for the work you have done on this document. I'm looking forward to the next version. Kind Regards, Philipp From nobody Fri Feb 3 10:58:03 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 994CB1294E7 for ; Fri, 3 Feb 2017 10:58:01 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=gmail.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 9YDWxVMHDqJg for ; Fri, 3 Feb 2017 10:57:59 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 2A7341294C8 for ; Fri, 3 Feb 2017 10:57:59 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id v23so48010033qtb.0 for ; Fri, 03 Feb 2017 10:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=zvevH+e7rgDp76t6NXbQNdseniEDds42qN4Io5emVxQ=; b=RvUJrKf5GNIH7eDHl3AeKfOiJQRFI+TyY+/YXaXs352DMoCQtHrpnuc2e99CZlOxnJ I+z7GBhDn2KmHMS6yulVzvFqEyb5yI0cy36S7taQCxSybe8sSP1FKJ0UGNw6IBUr2+kV L7jEpgP/GDZo33rLLGRxVVbBvHPeUZZ0z8XisN6/KUIIWMfafddJIaQpqM6D23d+FFcA doQislgEbIFetkMH2MMS7++5zR5H9koKHX3SQSXutd8tWfR/S4hDiopgIWTEewwYU6vQ G7ltKockLeCLTa7qopu86ul+aysGh1w8XuCGCw7YK5GhC2ghdHkfn7+q/ILeIOKmcplR YQ+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=zvevH+e7rgDp76t6NXbQNdseniEDds42qN4Io5emVxQ=; b=MERPJGd8urLuYWQ5CABmFT7jsI/G29MwpZsts5f7QSrw7u9T5rZ7QYM+toHPMtApnX 3CFsWWZJ8U/tgOyFUNDz0hXeJQjIu3F905aU6eRgppKPdAs2KpPNBFsMl+meQ9EKH7Uq bap1MvZBv02N8h/1Kq/R2hufFMzaxEcLXWcuq+czzNtQzdaoxHpq1Fq9K7ltH0SRI8JW WQmeZcA9diAwTAd7F2lOZ9xIRF0lfsgpoY0VTVusxYQ5ZYuXJpEWSQUVhI34mviymzxJ AGMMS/ocElUMz2cLgljmoFbnHskw+Ja+6l/JYVIIhh49Sk+hfTQd1DpQ4y6kLaLrocGG rKUw== X-Gm-Message-State: AMke39nUvR4Dy8QeOwVZqKdTaguX4Dry0rVPt5eh8ZWV2MKx1IfVD50omI3uWhtL+mhaJQ== X-Received: by 10.55.46.2 with SMTP id u2mr15916495qkh.231.1486148277928; Fri, 03 Feb 2017 10:57:57 -0800 (PST) Received: from Michaels-MacBook-Pro.local (cpe-67-252-53-251.nycap.res.rr.com. [67.252.53.251]) by smtp.googlemail.com with ESMTPSA id 126sm25097243qkl.24.2017.02.03.10.57.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 10:57:57 -0800 (PST) To: calsify@ietf.org References: From: Michael Douglass Message-ID: <71cb69cb-9637-2d37-fd61-2001645dbc2f@gmail.com> Date: Fri, 3 Feb 2017 13:57:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [calsify] Review of draft-ietf-calext-ical-relations-00 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 18:58:01 -0000 A quick reply to one point below On 2/3/17 13:47, Philipp Kewisch wrote: > Hi All, > > sorry this is just a moment to late for 01, I was actually typing this > up on the plane this morning. Anyway, some comments to consider for -02. > > Philipp > > --8>-- > > > Hi All, > > thanks for making the comments. I've reviewed this document with my > calext co-chair role in mind. The changes Ken has suggested sound > reasonable to me. Here are a few comments I would like to see discussed: > >> - Sec 1.4, last para: Should the discussion of ATTACH handling >> reference draft-ietf-calext-caldav-attachments? > I would also suggest to reword this paragraph. As the content will be > permanent I believe it would be better not to reference future work. > Therefore we should either publish the caldav attachments document first > and then reference it, or reword it to generally explain why LINK should > not be considered the same as an attachment. >> - Sec, 7: For the new non-TEXT properties, should we explicitly state >> that there is NO default value type to force producers to always >> include VALUE= so that consumers not familiar with the property don't >> assume an incorrect type? >> >> - Sec 10.2: I don't think STRUCTURED-CATEGORY belongs. Its not a >> parameter. > I do not feel that STRUCTURED-CATEGORY can be considered a "relation", > which this draft is about. Maybe it makes sense to move this to a > different document? STRUCTURED-CATEGORY is the target of relationships. During our work on tasks we felt there was a need for explicitly stating the relationship that grouped tasks or events. This type of relationship is also heavily used in public events - we use that type of relationship to create virtual collections and would like to see the approach formalised so that it can be exported. So I agree STRUCTURED-CATEGORY itself is not a relationship but it allows for the creation of relationships with a reltype. > > Also, some further comments: > > 1) Section 1.2, can you explain this property in a bit more detail? The > introduction sounds very generic and from reading it without the rest of > the document I wouldn't know how to use it. > > 2) Section 1.3, " Unlike REFID the category imparts some meaning" -- can > you explain or reword "some meaning". This sounds very generic. In the > next sentence I'd also suggest replacing " It is assumed" with something > more concrete. > > 3) Section 2, the REFERENCE type seems to fulfill a very specific use > case. I briefly read that xpointers can also be expressed in URIs, maybe > we can just re-use that? > > 4) Section 3, there is something missing from the last sentence of the > first paragraph > > 5) Section 4, are the relations strictly limited to calendar components? > The text reads that way, but I was thinking it could also be other > values. I would also explcitly mention which properties the reltypeparam > (currently) applies to. > > 6) Section 4, "Applications MUST treat x-name and iana-token values they > don't recognize the same way as they would the PARENT value" -- so if an > unrecognized value is used, then this automatically becomes a parent? > What if there is already a parent? Would that mean the item has multiple > parents? I'd appreciate some clarification why the default PARENT makes > sense here. > > 7) Section 7.3, maybe you can explain better how REFID is used in the > intro to that section, specifically what kind of values would be common. > I see the example later on, but that only marginally helps understand > what it does. Maybe you can include a sentence that describes in what > other places the REFID may be used? > > 8) Section 8.1, maybe you can mention non-standard at the end instead of > the beginning. > > 9) Section 6, "VALUE=UID indicates that the associated value is the UID > for a component" -- Maybe you can elaborate on what a UID formally is, > with references to other documents. > > 10) Section 9, would it be a security concern that the relations may > reference components in another system that are meant to be private? If > relations between items are defined with this amount of structure, it > could allow making assumptions on private components. > > Mike, I'd appreciate if you could also comment on the previous items and > fix the nits.n. > > I would also appreciate if you could provide some details as to which > vendors have implemented the draft so far. > > To anyone else reading this, please voice your concerns so we can move > this draft along. > > Thank you very much for the work you have done on this document. I'm > looking forward to the next version. > > Kind Regards, > Philipp > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Fri Feb 10 19:56:14 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 08D0412968D for ; Fri, 10 Feb 2017 19:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, 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=gmail.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 5fFI--ITqxvM for ; Fri, 10 Feb 2017 19:56:12 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 C069A129686 for ; Fri, 10 Feb 2017 19:56:11 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id u25so58373039qki.2 for ; Fri, 10 Feb 2017 19:56:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to; bh=GjeoEkem9I1CTRb43Uzw7dIMoSkJjrpBlHaf1RkfB+8=; b=iLGCqQBQ5Q8+E+qOF7NgCUGZRA1O1RiCiGIO5RujT4vfFcv9a2hWUWhW4spSD+171j NwC2qOQx7cW8C6QQNvVstdfcOdzHoSIi1eifNl60TsOfU5NGsuY4zd2/E09gOjmA5Cpt CSyt2Wva5aOPO77TfDefCunh0yUcKJ+XKvmS8ZywNspVPpRQfo0tK50nwbRTum2p6cl8 tnaT3C58oF9gYhm8RdaxztEEWuJcF6MD6qrqWoy+NeT77FyAGtYn3Tx1clVI46Pl5lOM 4L3eIZsTsumnehwWiUChDPP10WdeOD3LpaMDYgpjzWEmQwqnwd2YR2CYoSuTPr0MLDCx XBPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to; bh=GjeoEkem9I1CTRb43Uzw7dIMoSkJjrpBlHaf1RkfB+8=; b=rTxWrLbeIQuPQ7Y0G036wHG6eREQ58AKe+0Bs6x9Js6eZsVSRbLJMZdfkA9TuExnGS bK+yle2MsMr3a7/mHYd4GgheXrp4O5GXt61KgxyWF9pzKt6yrgLFL/G6Ff7CoFe0A9s+ ofXUSvjPJ65iD/r/J88PSZ5+hXFPaVPnZJp0jv1FPuMZSxznU8WjYg5zmNqZSSywjPtx ARDqHjV019yR6EAmPypd5WkBRLwxtdiGh8fDX33MCXqyk7lZv4zcIpt1QBbhPSuQzbgi ys3mKg/gAGtYRfcOZv3yK6p/ULuEwaoK+RlrZsg42fymClL01D2T9S2CQ7TCciCtKYhq Wi7Q== X-Gm-Message-State: AMke39l8mbd+qEFKWNAdp/bjC7zWWb6RCI9HGt7vCg7iy/GoH3kjQpym88xH1rzQvhdYlg== X-Received: by 10.55.46.2 with SMTP id u2mr12714133qkh.231.1486785370525; Fri, 10 Feb 2017 19:56:10 -0800 (PST) Received: from Michaels-MacBook-Pro.local (cpe-67-252-53-251.nycap.res.rr.com. [67.252.53.251]) by smtp.googlemail.com with ESMTPSA id 126sm3011115qkl.24.2017.02.10.19.56.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 19:56:09 -0800 (PST) From: Michael Douglass To: calsify@ietf.org References: Message-ID: Date: Fri, 10 Feb 2017 22:56:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------87CA6676B8E6C01D19E24AA0" Archived-At: Subject: Re: [calsify] Review of draft-ietf-calext-ical-relations-00 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 03:56:14 -0000 This is a multi-part message in MIME format. --------------87CA6676B8E6C01D19E24AA0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Thanks Philipp. I'll resubmit with some of the changes made - I'm about to head for the CalConnect conference tomorrow. Further comments On 2/3/17 13:47, Philipp Kewisch wrote: > Hi All, > > sorry this is just a moment to late for 01, I was actually typing this > up on the plane this morning. Anyway, some comments to consider for -02. No problem - took me a while to deal with Ken's comments. I'll try to be more timely with these... > Philipp > > --8>-- > > > Hi All, > > thanks for making the comments. I've reviewed this document with my > calext co-chair role in mind. The changes Ken has suggested sound > reasonable to me. Here are a few comments I would like to see discussed: > >> - Sec 1.4, last para: Should the discussion of ATTACH handling >> reference draft-ietf-calext-caldav-attachments? > I would also suggest to reword this paragraph. As the content will be > permanent I believe it would be better not to reference future work. > Therefore we should either publish the caldav attachments document first > and then reference it, or reword it to generally explain why LINK should > not be considered the same as an attachment. I guess it depends on how fast we go relative to managed attachments. I believe Ken is trying to move that along so maybe we can defer this until it's clear which will be first over the line. >> - Sec, 7: For the new non-TEXT properties, should we explicitly state >> that there is NO default value type to force producers to always >> include VALUE= so that consumers not familiar with the property don't >> assume an incorrect type? >> >> - Sec 10.2: I don't think STRUCTURED-CATEGORY belongs. Its not a >> parameter. > I do not feel that STRUCTURED-CATEGORY can be considered a "relation", > which this draft is about. Maybe it makes sense to move this to a > different document? See earlier message > Also, some further comments: > > 1) Section 1.2, can you explain this property in a bit more detail? The > introduction sounds very generic and from reading it without the rest of > the document I wouldn't know how to use it. I've added some text extracted (and modified) from the Apthorp tasks draft (which was the original motivation) > 2) Section 1.3, " Unlike REFID the category imparts some meaning" -- can > you explain or reword "some meaning". This sounds very generic. In the > next sentence I'd also suggest replacing " It is assumed" with something > more concrete. > > 3) Section 2, the REFERENCE type seems to fulfill a very specific use > case. I briefly read that xpointers can also be expressed in URIs, maybe > we can just re-use that? Are you thinking of XLink? That might be reasonable. It was a specific case but may become more general - the original motivation was the smart grid work in which iCalendar entities may point at a portion of an XML payload. That may have more general uses, for example an event may be related to a specific page in a program. > 4) Section 3, there is something missing from the last sentence of the > first paragraph It seems OK - is below what you mean? 3. Link Relation Types [RFC5988] defines two form of relation types, registered and extension. Registered relation types are added to a registry defined by [RFC5988] while extension relation types are specified as unique unregistered URIs, (at least unregistered in the [RFC5988] registry). The relation types defined here will be registered with IANA in accordance with the specifications in [RFC5988]. > 5) Section 4, are the relations strictly limited to calendar components? > The text reads that way, but I was thinking it could also be other > values. I would also explcitly mention which properties the reltypeparam > (currently) applies to. It's a parameter on RELATED-TO which explicitly states it's for calendar components only. I think it's up to the property in which it's used to define the limitations. I think the approach is that RELATED-TO is for relations between calendar components and LINK for relations to non-calendar components. I was urged (in earlier discussions) to make that distinction. > 6) Section 4, "Applications MUST treat x-name and iana-token values they > don't recognize the same way as they would the PARENT value" -- so if an > unrecognized value is used, then this automatically becomes a parent? > What if there is already a parent? Would that mean the item has multiple > parents? I'd appreciate some clarification why the default PARENT makes > sense here. That text all comes from RFC5545. I'm not that keen on defaults but I think we're stuck with it. The actual meaning of relationships may depend on the application so in some cases multiple parents may not be unreasonable - but again - these types come from 5545. > 7) Section 7.3, maybe you can explain better how REFID is used in the > intro to that section, specifically what kind of values would be common. > I see the example later on, but that only marginally helps understand > what it does. Maybe you can include a sentence that describes in what > other places the REFID may be used? > > 8) Section 8.1, maybe you can mention non-standard at the end instead of > the beginning. Reused (modified) wording from 5545 > 9) Section 6, "VALUE=UID indicates that the associated value is the UID > for a component" -- Maybe you can elaborate on what a UID formally is, > with references to other documents. > > 10) Section 9, would it be a security concern that the relations may > reference components in another system that are meant to be private? If > relations between items are defined with this amount of structure, it > could allow making assumptions on private components. Wouldn't that be true within a single collection? If the owner marked some events as private after they have been linked to then the system shoudl probably not deliver them to anybody other than the owner. The whole CLASS thing isn't well implemented anyway. I woudl suggest that creating a parent child relationship - or any other relationship - doesn't alter the way access is calculated for a specific entity. I can make that statement > Mike, I'd appreciate if you could also comment on the previous items and > fix the nits.n. OK - I might need help on this: -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) > I would also appreciate if you could provide some details as to which > vendors have implemented the draft so far. Some of this is implemented by bedework - hope to have the rest done soon. This will also require updates to ical4j (or at least the bedework fork of that project) > > To anyone else reading this, please voice your concerns so we can move > this draft along. > > Thank you very much for the work you have done on this document. I'm > looking forward to the next version. > > Kind Regards, > Philipp > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------87CA6676B8E6C01D19E24AA0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Thanks Philipp.

I'll resubmit with some of the changes made - I'm about to head for the CalConnect conference tomorrow.


Further comments


On 2/3/17 13:47, Philipp Kewisch wrote:
Hi All,

sorry this is just a moment to late for 01, I was actually typing this
up on the plane this morning. Anyway, some comments to consider for -02.
No problem - took me a while to deal with Ken's comments. I'll try to be more timely with these...
Philipp

--8>--


Hi All,

thanks for making the comments. I've reviewed this document with my
calext co-chair role in mind. The changes Ken has suggested sound
reasonable to me. Here are a few comments I would like to see discussed:


- Sec 1.4, last para: Should the discussion of ATTACH handling
reference draft-ietf-calext-caldav-attachments?

I would also suggest to reword this paragraph. As the content will be
permanent I believe it would be better not to reference future work.
Therefore we should either publish the caldav attachments document first
and then reference it, or reword it to generally explain why LINK should
not be considered the same as an attachment.
I guess it depends on how fast we go relative to managed attachments. I believe Ken is trying to move that along so maybe we can defer this until it's clear which will be first over the line.
- Sec, 7: For the new non-TEXT properties, should we explicitly state
that there is NO default value type to force producers to always
include VALUE= so that consumers not familiar with the property don't
assume an incorrect type?

- Sec 10.2: I don't think STRUCTURED-CATEGORY belongs.  Its not a
parameter.

I do not feel that STRUCTURED-CATEGORY can be considered a "relation",
which this draft is about. Maybe it makes sense to move this to a
different document?
See earlier message
Also, some further comments:

1) Section 1.2, can you explain this property in a bit more detail? The
introduction sounds very generic and from reading it without the rest of
the document I wouldn't know how to use it.
I've added some text extracted (and modified) from the Apthorp tasks draft (which was the original motivation)
2) Section 1.3, " Unlike REFID the category imparts some meaning" -- can
you explain or reword "some meaning". This sounds very generic. In the
next sentence I'd also suggest replacing " It is assumed" with something
more concrete.

3) Section 2, the REFERENCE type seems to fulfill a very specific use
case. I briefly read that xpointers can also be expressed in URIs, maybe
we can just re-use that?
Are you thinking of XLink? That might be reasonable. It was a specific case but may become more general - the original motivation was the smart grid work in which iCalendar entities may point at a portion of an XML payload. That may have more general uses, for example an event may be related to a specific page in a program.
4) Section 3, there is something missing from the last sentence of the
first paragraph
It seems OK - is below what you mean?
3.  Link Relation Types

   [RFC5988] defines two form of relation types, registered and
   extension.  Registered relation types are added to a registry defined
   by [RFC5988] while extension relation types are specified as unique
   unregistered URIs, (at least unregistered in the [RFC5988] registry).

   The relation types defined here will be registered with IANA in
   accordance with the specifications in [RFC5988].
5) Section 4, are the relations strictly limited to calendar components?
The text reads that way, but I was thinking it could also be other
values. I would also explcitly mention which properties the reltypeparam
(currently) applies to.
It's a parameter on RELATED-TO which explicitly states it's for calendar components only. I think it's up to the property in which it's used to define the limitations. I think the approach is that RELATED-TO is for relations between calendar components and LINK for relations to non-calendar components. I was urged (in earlier discussions) to make that distinction. 
6) Section 4, "Applications MUST treat x-name and iana-token values they
don't recognize the same way as they would the PARENT value" -- so if an
unrecognized value is used, then this automatically becomes a parent?
What if there is already a parent? Would that mean the item has multiple
parents? I'd appreciate some clarification why the default PARENT makes
sense here.
That text all comes from RFC5545. I'm not that keen on defaults but I think we're stuck with it.

The actual meaning of relationships may depend on the application so in some cases multiple parents may not be unreasonable - but again - these types come from 5545. 
7) Section 7.3, maybe you can explain better how REFID is used in the
intro to that section, specifically what kind of values would be common.
I see the example later on, but that only marginally helps understand
what it does. Maybe you can include a sentence that describes in what
other places the REFID may be used?

8) Section 8.1, maybe you can mention non-standard at the end instead of
the beginning.
Reused (modified) wording from 5545
9) Section 6, "VALUE=UID indicates that the associated value is the UID
for a component" -- Maybe you can elaborate on what a UID formally is,
with references to other documents.

10) Section 9, would it be a security concern that the relations may
reference components in another system that are meant to be private? If
relations between items are defined with this amount of structure, it
could allow making assumptions on private components.
Wouldn't that be true within a single collection? If the owner marked some events as private after they have been linked to then the system shoudl probably not deliver them to anybody other than the owner. The whole CLASS thing isn't well implemented anyway. I woudl suggest that creating a parent child relationship - or any other relationship - doesn't alter the way access is calculated for a specific entity. I can make that statement
Mike, I'd appreciate if you could also comment on the previous items and
fix the nits.n.
OK - I might need help on this:

 -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.)


I would also appreciate if you could provide some details as to which
vendors have implemented the draft so far.
Some of this is implemented by bedework - hope to have the rest done soon. This will also require updates to ical4j (or at least the bedework fork of that project)

To anyone else reading this, please voice your concerns so we can move
this draft along.

Thank you very much for the work you have done on this document. I'm
looking forward to the next version.

Kind Regards,
Philipp


_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify

--------------87CA6676B8E6C01D19E24AA0-- From nobody Fri Feb 10 20:07:25 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 9DA3D12969C; Fri, 10 Feb 2017 20:07:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148678603964.29167.14302539527731506421.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2017 20:07:19 -0800 Archived-At: Cc: calsify@ietf.org Subject: [calsify] I-D Action: draft-ietf-calext-ical-relations-02.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 04:07:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions of the IETF. Title : Support for iCalendar Relationships Author : Michael Douglass Filename : draft-ietf-calext-ical-relations-02.txt Pages : 19 Date : 2017-02-10 Abstract: This specification updates RELATED-TO defined in [RFC5545] and introduces new iCalendar properties LINK, STRUCTURED-CATEGORY and REFID to allow better linking and grouping of iCalendar components and related data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-ical-relations/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-calext-ical-relations-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-ical-relations-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/