Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-02.txt
Daniel Migault <daniel.migault@ericsson.com> Tue, 26 September 2017 16:07 UTC
Return-Path: <daniel.migault@ericsson.com>
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 DD5B51342CF for <calsify@ietfa.amsl.com>; Tue, 26 Sep 2017 09:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level:
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 BCU0FCdfdxsW for <calsify@ietfa.amsl.com>; Tue, 26 Sep 2017 09:07:30 -0700 (PDT)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 5705C1342CA for <calsify@ietf.org>; Tue, 26 Sep 2017 09:07:30 -0700 (PDT)
X-AuditID: c6180641-0dfff70000002d27-8c-59ca34dd0ef9
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id B8.5E.11559.DD43AC95; Tue, 26 Sep 2017 13:07:09 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0352.000; Tue, 26 Sep 2017 12:07:28 -0400
From: Daniel Migault <daniel.migault@ericsson.com>
To: Michael Douglass <mikeadouglass@gmail.com>, "calsify@ietf.org" <calsify@ietf.org>
Thread-Topic: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-02.txt
Thread-Index: AQHSwebrkUYyq0e6c06GobplRW0JHaHkjBwA//+9xLCAAKiGAIDjTIyQ
Date: Tue, 26 Sep 2017 16:07:28 +0000
Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118CEEF17@eusaamb107.ericsson.se>
References: <149283227001.25909.8523949851908452110@ietfa.amsl.com> <CADZyTk=W5YPQ9xpvx8-pqmyE4OWoQQUm4xWdcnNrEvrS09uKcQ@mail.gmail.com> <CADZyTkk1eZ0LSAhH1Zp5vKGLSG+LWPQ-Nkd-LBVOoFZcgj8yCA@mail.gmail.com> <8e8c5288-8ba7-c166-a28b-393a90ff96c9@gmail.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD83FB@eusaamb107.ericsson.se> <0de097f4-be06-fa25-85ec-1ace48ec776c@gmail.com>
In-Reply-To: <0de097f4-be06-fa25-85ec-1ace48ec776c@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.12]
Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CEEF17eusaamb107erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPuO5dk1ORBitWW1lsetHMajFl2QM2 ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvjcItHwbYJzBUL/n9ja2BsaGPuYuTgkBAw kVi4lLOLkYtDSOAoo8Se7ROYIJzljBI9hw6zdjFycrAJGEm0HepnB7FFBMIlfv6+ywxiCwsE StzcPIsVIh4k8WbBFyYI203i6qbVLCA2i4CqxMTmpWD1vAK+ElemXGeDWPCbSeL8nymsIFdw CthKLNkaCVLDKCAm8f3UGrA5zALiEreezAezJQQEJJbsOc8MYYtKvHz8jxXCVpKY8/oaM0R9 vsTV/y9ZIXYJSpyc+YRlAqPwLCSjZiEpm4WkbBbQFcwCmhLrd+lDlChKTOl+yA5ha0i0zpnL jiy+gJF9FSNHaXFBTm66keEmRmCUHJNgc9zBuLfX8xCjAAejEg/vaeNTkUKsiWXFlbmHGCU4 mJVEeL8UA4V4UxIrq1KL8uOLSnNSiw8xSnOwKInzviu/ECEkkJ5YkpqdmlqQWgSTZeLglGpg NJ1p6mEqqGcnd+XoLfk3nfONo/WLthzXfCHkzrCYz6T7BN+5z4KvDHM19peeVjt6901kbZZJ gPd0Xr+gr4WS888IJ8as2ln+ovjpVyG5C0d1mp8slXhTvv8pW/uivDudEw4+vPKAX0Nkxzdu GfuXhxW5N9UssL2wKq2hRlU8X/TOXumiy+s4lViKMxINtZiLihMBothDrY4CAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/vK3vFfNdcfi7d10xEQ_aLdQMY5k>
Subject: Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-02.txt
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Sep 2017 16:07:34 -0000
Hi Michael, I am wondering if you have completed your implementation and if you believe the draft version 03 is ready to be sent to the IESG. If so, I will have a final review and ship the document. Yours, Daniel From: Michael Douglass [mailto:mikeadouglass@gmail.com] Sent: Thursday, May 04, 2017 5:01 PM To: Daniel Migault <daniel.migault@ericsson.com>; calsify@ietf.org Subject: Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-02.txt I think I will remove the STRUCTURED-RESOURCE property from the draft along with RESTYPE That was added at a time we were active with resource extensions to vcard and the assumption was that a registry of resource types would come out of that. That work has been restarted recently but we probably need to rethink the approach. It's possible that the PARTICIPANT component will work instead of a special property for resources. We can always bring out a later extension to reintroduce that property if we feel it's needed. I also noticed that I should have specified the uid property as a required property for PARTICIPANT. On 5/4/17 11:01, Daniel Migault wrote: Hi Michael, Thanks for the update. The only way I see to address the nits, is to write in plain text RFC5545 in the abstract and use the reference <xref tyarget=””/> in the introduction. I guess the nits tool looks at [.*] to list references. Yours, Daniel From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of Michael Douglass Sent: Thursday, May 04, 2017 10:55 AM To: calsify@ietf.org<mailto:calsify@ietf.org> Subject: Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-02.txt Thanks for the comments. I've published an updated version 03 and there are some comments below. A couple of particular points that need further work: ** The abstract seems to contain references ([RFC5545]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Is there a guide as to when and when not a refeence? Also the RESTYPE parameter needs more discussion On 4/30/17 15:18, Daniel Migault wrote: Hi, Please find my comments regarding the current version. The document is in good shape. Yours, Daniel 1. Introduction "Formats such as VCARD are likely to be most useful." I think we need some explanation. Is the VCARD used by the organizer or participant of the event ? If that is the case, it would be clearer to mention it explicitly. Tried to expand a little "The following properties and components are defined in this specification". As there are two kind of objects being defined, it would be clarifying for the reader to specify for each item below what category they belong to. My understanding is that only participant is a component others are properties. I've split off participant as a separate paragraph 2. Components and properties "In a break with this 'tradition' this specification introduces some of these extensions as components rather than properties." My reading is that components is not used as the iCal terminology here. More specifically, this is not an iCal component. If that is the case, maybe we could use another term. I am trying to find one but agree this is not easy. At one point I thought we would have multiple components. I've reduced it to referring to the one component 3. Typed References """ These properties are designed to handle common use cases in event publication. It is generally important to provide information about the organizers of such events. Sponsors wish to be referenced in a prominent manner. In social calendaring it is often important to identify the active participants in the event, for example a school sports team, and the inactive participants, for example the parents. """ I also have the impression that properties is not associated to teh ICal properties. In fcat I see Participant as a component. In this case saying the participant components and associated properties seems to be clearer to me at least. Left over with the move from PARTICIPANT as a property to a component. I've made that paragraph specific to PARTICIPANT 5.2. Restype """ Description: This parameter MAY be specified on STRUCTURED-RESOURCE and provides a way to differentiate multiple properties. Values for this parameter are taken from the values defined in [todo]. New resource types SHOULD be registered in the manner laid down in that specification """ [todo] needs to be completed. Yes - There was work on a vcard resource draft which was expected to get ahead of this one. That didn't happen. We'll need some discussion on where to go with that. 5.3. Order """ Description: The ORDER parameter is OPTIONAL and is used to indicate the relative ordering of the corresponding instance of a property. Its value MUST be an integer greater than or equal to 1 that quantifies the order. Lower values correspond to a higher level of ordering, with 1 being the highest. """ I would like to make sure and explicit that ordering is performed from low to high value or the reverse. Tried to get rid of some of the higher/lower language I also found one or 2 issues myself. Property PARTTYPE has 2 names - should be PARTICIPANT-TYPE Property SCHEDULE-ADDRESS - definition specified value as iana-token. Should be cal-address Property SCHEDULE-DATA - specified a data type of TEXT only - but it should be TEXT, BINARY or URI Missed format type out of the descriptive text for STYLED-DESCRIPTION Component PARTICIPANT Priority was missing from the format definition Had structuredaddress instead of scheduleaddress Follows the nits provided by the datatracker: nits: idnits 2.14.01 /tmp/draft-ietf-calext-eventpub-extensions-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC5545]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Is this referring to things like This specification also defines a new STRUCTURED-DATA property for iCalendar [RFC5545] to allow for data that is directly pertinent to Is there a guide as to when should I use a reference and when not? -- The draft header indicates that this document updates RFC5545, but the abstract doesn't seem to directly say this. It does mention RFC5545 though, so this could be OK. -- The draft header indicates that this document updates RFC5546, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC5545, updated by this document, for RFC5378 checks: 2008-10-31) (Using the creation date from RFC5546, updated by this document, for RFC5378 checks: 2008-07-14) -- 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.) -- The document date (April 21, 2017) is 9 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2434' is defined on line 1079, but no explicit reference was found in the text Deleted == Unused Reference: 'RFC3688' is defined on line 1084, but no explicit reference was found in the text Deleted == Outdated reference: draft-ietf-calext-extensions has been published as RFC 7986 Fixed ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. On Sun, Apr 30, 2017 at 2:11 PM, Daniel Migault <daniel.migault@ericsson.com<mailto:daniel.migault@ericsson.com>> wrote: Hi, This starts a Working Group Last Call for: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ Please provide your comments / reviews by May 14. Yours, Daniel ---------- Forwarded message ---------- From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> Date: Fri, Apr 21, 2017 at 11:37 PM Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-02.txt To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org> Cc: calsify@ietf.org<mailto:calsify@ietf.org> 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 : Event Publishing Extensions to iCalendar Author : Michael Douglass Filename : draft-ietf-calext-eventpub-extensions-02.txt Pages : 28 Date : 2017-04-21 Abstract: This specification introduces a number of new iCalendar properties and components which are of particular use for event publishers and in social networking. This specification also defines a new STRUCTURED-DATA property for iCalendar [RFC5545] to allow for data that is directly pertinent to an event or task to be included with the calendar data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-02 https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-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<http://tools.ietf.org>. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ calsify mailing list calsify@ietf.org<mailto:calsify@ietf.org> https://www.ietf.org/mailman/listinfo/calsify _______________________________________________ calsify mailing list calsify@ietf.org<mailto:calsify@ietf.org> https://www.ietf.org/mailman/listinfo/calsify
- Re: [calsify] I-D Action: draft-ietf-calext-event… Daniel Migault
- [calsify] I-D Action: draft-ietf-calext-eventpub-… internet-drafts
- [calsify] Fwd: I-D Action: draft-ietf-calext-even… Daniel Migault
- Re: [calsify] I-D Action: draft-ietf-calext-event… Daniel Migault
- Re: [calsify] I-D Action: draft-ietf-calext-event… Michael Douglass
- Re: [calsify] I-D Action: draft-ietf-calext-event… Daniel Migault
- Re: [calsify] I-D Action: draft-ietf-calext-event… Michael Douglass
- Re: [calsify] I-D Action: draft-ietf-calext-event… Michael Douglass
- Re: [calsify] I-D Action: draft-ietf-calext-event… Daniel Migault