From nobody Sat Oct 8 10:59:51 2016 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 1013A1295F1 for ; Sat, 8 Oct 2016 10:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 SWi6ADcVKxmv for ; Sat, 8 Oct 2016 10:59:48 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 D6A011295EF for ; Sat, 8 Oct 2016 10:59:47 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id r30so75633573ioi.1 for ; Sat, 08 Oct 2016 10:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=W2PMXHlE/t8oHusGvmJ5EW2XLMaje2LLcQKmocZbhXA=; b=UmDLBUzciJ+Ay/J1UL4qI6tvRBNYplXd188/vWG2mxfaCt/qc/b1N6j0c8rRJ+aBcc Gay+vesDtTySe5Z9RpmxDWTJxlDWdQbADjWfUPOdV0TRJeSe+6olQ/W6BtwaH/zDIXUV pGWWYQc5JSvEJ6kYmv9W/iaLlB+cozkTlJjQbR98olEetFtl2btkNlXx+pGEJSzliaEW EM1GGEZbhE19cj0H0vGSBUlHFKqiA4t+Swggwy5AxG8rC1Qh06DMgkl5JBevU9SJDdfh ad0zFk+Jbly9FQ+TnEJE9RrRz4zdGXs+VgoG3JeJUQHICUJm7ezaAgBTPVyJ3Abh2ec9 wPhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=W2PMXHlE/t8oHusGvmJ5EW2XLMaje2LLcQKmocZbhXA=; b=MVFUnTaod4+9mXMHYDi5lxMTqNvG4HkRVMjOGvLDAWm7Cqjsjkejku+nQx14snR+ya /VIsIvnfUHFfGp0PrRCQzXAuQsHnA/A7f5SdjnOnH40jXjCsicdPPkhGXP3MbJTkoBWc kKj0kzi3282Z43Gqgyqschrm5SfEVQCjHel7JOkWy9AffNZq9RD0UthNVAa8fQ2buv+I wlb+K93axk9tX9NymegGnNpyaUqiGBQfc242Hj7rhzAVaSw8Rruj/L5SD9A11l8CeRvx /UI6qBl8pEDYO0IwAPLw0qgXhPzpw6atiT56sxxgmjeueLKyK8U914/Vdb2+VWPQE2ra KRsQ== X-Gm-Message-State: AA6/9RlMACoOyEvl5v2crdusa+jCzAhtzJoK/QwSSDjB6oIx8WPN8MN5pWfo+OIvBgXqYjhav+pg403E2LmGJw== X-Received: by 10.107.28.148 with SMTP id c142mr24301489ioc.45.1475949586824; Sat, 08 Oct 2016 10:59:46 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.170.70 with HTTP; Sat, 8 Oct 2016 10:59:46 -0700 (PDT) From: Daniel Migault Date: Sat, 8 Oct 2016 19:59:46 +0200 X-Google-Sender-Auth: NJYc_ORekgQhbOzeErTVCfKjXGY Message-ID: To: calsify@ietf.org Content-Type: multipart/alternative; boundary=001a113fd4b8d46517053e5e4a32 Archived-At: Subject: [calsify] review of draft-ietf-calext-eventpub-extensions-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, 08 Oct 2016 17:59:50 -0000 --001a113fd4b8d46517053e5e4a32 Content-Type: text/plain; charset=UTF-8 Hi, *reviewed * *draft-ietf-calext-eventpub-extensions-00 Event Publishing Extensions to iCalendar. * *Please find my comment below. * *BR, Daniel* Section Introduction: >From the introduction, my understanding is that the draft will describe two new properties: 1) a new property to support HTML which is not mentionned, but I think corresponds to "styled-Description" 2) a new property "STRUCTURED-DATA" That is personnal but I would proably prefer to have all new properties mentionedn in the introduction. That is: - Associate - Styled-Description - Structured-Location - Structured-Resource - Structured-Data with a paragraph associated to each of them. This text is not clear to me. I guess that is because I do not know what "org.bedework.util.jms.events" is. """ It is generally important to provide information about the organizers of such org.bedework.util.jms.events. """ While reading the introduction, I expected the ASSOCIATE to be something similar as attendee. This is later clarified, but it might be good to clearly mention the difference in the intro, so people read the document with a good view of what an associate is. """ In social calendaring it is often important to identify the active associates in the event, for example a school sports team, and the inactive associates, for example the parents. """ section 2. Typed References The "TODO" text is not clear to me. """ The [RFC5545] LOCATION property provides only an unstructured single text value for specifying the location where an event (or "TODO" item) will occur. """ My understanding of this section is that it cites alternative of the proposed properties. I am a bit confused then why ATTACH is not part of this section. Each properties it would be helpful for the reader to mention the gaps and how the new prperties of the document solve the gaps. >From reading the section it looks to me that STRUCTURED-DATA is a more generic way to do STRUCTURED-LOCATION. Can we expect overlaps between the two properties and eventually see STRUCTURE-LOCATION deprecated one time in the future ? The section does not mention any properties associated to HTML content properties. My undertanding of it is that iCal has not seen any need for presentation until now, and leave presentation to the browser or application. Is that correct ? section 2.1. Maybe iTip meeting should have a refrence to RFC5546 Section 4. There are Components properties sdataprop is a new component 5.2. Styled-Description styleddescparam seems to have synthax problems. styleddescparam = *( ; ; The following are OPTIONAL, ; but MUST NOT occur more than once. ; (";" altrepparam) / (";" languageparam) / (";" fmttypeparam) / ; ; the following is OPTIONAL ; and MAY occur more than once ; (";" other-param) --001a113fd4b8d46517053e5e4a32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

reviewed dra= ft-ietf-calext-eventpub-extensions-00 Event Publishing Extensions to iC= alendar.

Please find my comment below.

BR,
Daniel


Section Intr= oduction:

From the introduction, my understanding is that the draft = will describe two new properties:
=C2=A0=C2=A0
1) a new property to = support HTML which is not mentionned, but I think corresponds to "styl= ed-Description"
2) a new property "STRUCTURED-DATA"
That is personnal but I would proably prefer to have all new properties m= entionedn in the introduction. That is:
=C2=A0=C2=A0 - Associate
=C2= =A0=C2=A0 - Styled-Description=C2=A0
=C2=A0=C2=A0 - Structured-Location=
=C2=A0=C2=A0 - Structured-Resource
=C2=A0=C2=A0 - Structured-Data =
=C2=A0
with a paragraph associated to each of them.=C2=A0
=C2=A0= =C2=A0
=C2=A0=C2=A0=C2=A0 =C2=A0
This text is not clear to me. I gue= ss that is because I do not know what "org.bedework.util.jms.events&qu= ot; is.

"""
=C2=A0=C2=A0 It is generally important= to provide information about
=C2=A0=C2=A0 the organizers of such org.be= dework.util.jms.events.
"""

While reading the intr= oduction, I expected the ASSOCIATE to be something similar as attendee. Thi= s is later clarified, but it might be good to clearly mention the differenc= e in the intro, so people read the document with a good view of what an ass= ociate is.

"""
=C2=A0=C2=A0 In social calendaring = it is
=C2=A0=C2=A0 often important to identify the active associates in = the event, for
=C2=A0=C2=A0 example a school sports team, and the inacti= ve associates, for
=C2=A0=C2=A0 example the parents.
""&quo= t;

section 2. Typed References

The "TODO" text is n= ot clear to me.
"""
=C2=A0=C2=A0 The [RFC5545] LOCATI= ON property provides only an unstructured single
=C2=A0=C2=A0 text value= for specifying the location where an event (or "TODO"
=C2=A0= =C2=A0 item) will occur.
"""

My understanding of t= his section is that it cites alternative of the proposed properties.
I am a bit confused then why ATTACH is not part of this section.

= Each properties it would be helpful for the reader to mention the gaps and = how the new prperties of the document solve the gaps.

From reading t= he section it looks to me that STRUCTURED-DATA is a more generic way to do = STRUCTURED-LOCATION. Can we expect overlaps between the two properties and = eventually see STRUCTURE-LOCATION deprecated one time in the future ?
The section does not mention any properties associated to HTML content pr= operties. My undertanding of it is that iCal has not seen any need for pres= entation until now, and leave presentation to the browser or application. I= s that correct ?

section 2.1.

Maybe iTip meeting should have = a refrence to RFC5546


Section 4.

There are Components pro= perties sdataprop is a new component

5.2.=C2=A0 Styled-Description<= br>
styleddescparam seems to have synthax problems.

=C2=A0=C2=A0= =C2=A0=C2=A0 styleddescparam=C2=A0=C2=A0 =3D *(
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; = The following are OPTIONAL,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ; but MUST NOT occur more than once.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 ;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (";= " altrepparam) / (";" languageparam) /
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 (";" fmttypeparam) /
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 ; the following is OPTIONAL
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 ; and MAY occur more than once
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 ;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (&quo= t;;" other-param)

=C2=A0


--001a113fd4b8d46517053e5e4a32-- From nobody Mon Oct 17 08:33:30 2016 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 01132129879; Mon, 17 Oct 2016 08:33:29 -0700 (PDT) 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.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147671840896.4507.4962271425141817622.idtracker@ietfa.amsl.com> Date: Mon, 17 Oct 2016 08:33:28 -0700 Archived-At: Cc: calsify@ietf.org Subject: [calsify] I-D Action: draft-ietf-calext-caldav-attachments-00.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: Mon, 17 Oct 2016 15:33:29 -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 : CalDAV Managed Attachments Authors : Cyrus Daboo Arnaud Quillaud Kenneth Murchison Filename : draft-ietf-calext-caldav-attachments-00.txt Pages : 32 Date : 2016-10-17 Abstract: This specification defines an extension to the calendar access protocol (CalDAV) to allow attachments associated with iCalendar data, to be stored and managed on the server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-caldav-attachments/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-calext-caldav-attachments-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 19 08:17:14 2016 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 110B91299CF for ; Wed, 19 Oct 2016 08:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 vHrTIfFv7JM1 for ; Wed, 19 Oct 2016 08:17:02 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 8E5EF129673 for ; Wed, 19 Oct 2016 08:17:02 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id f6so24879165qtd.2 for ; Wed, 19 Oct 2016 08:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=cumCrKyvemE3IR97v1ofZpE0IpKqT9/a1BJrUgM/ZeQ=; b=ttNKpgyNMdeai5QNT1FTY1ZtiVlmM9syEAyR0vheEgw/gf/pMOpF8IvbXNc4YNnEYm ucTILqhnrImY05KZ6hectZyOWoCGcxR+ByajPchFfUojMJ0GF3b7KZ9SEu4IK53dUJy6 9jT758pvHmFREBRyo2/SftLm4Mfmn2fR7PTjBeZ2wx1DBm/dQe1zaOvAdShNizMkoMlo 8BihcD8XQx++XZzoTvzENFlYsSkkKGQmV/kvNK2jaR5HXbeo/v63Y8z5F+u0YRzJVCNB mtXiUnvfA0Tr0L08rwm7wI2nF3rqOjP5j8MEPwswZj/BpkGJGbyi9n0jk9Ll5lfHu/Nu bE+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cumCrKyvemE3IR97v1ofZpE0IpKqT9/a1BJrUgM/ZeQ=; b=DWSlvAf1c35qvO5AinnygouMUgvXf7rqJVmXJ9ytudqCVNaXMyGVJ44xMbXcJhGXKr HVMGYw8O4sOvmcxUrXF9wj+g7lMbRnbfLIgHV3be+Q9coWfS5AfbovShd2hd4j05psYh 5u56ZhJ9XL8XQAGa578+bZgW73A38QGKCrR4p6tgsXWvk6ZMwBFXICZtXXx+jWr0AHx/ jvGcxVo+6XOiYanLDLj5uMM2KksgfcSQfoqa+JfE/CVWXFhO3rCmjTgstfL6l/gO2+wx PXNn59lfsQBk1H/dk0CG2URGMsyHoCEPwUxIUTMh2AgBEbjbc/UZsP/+7CcRARh2Yg9h f2Yg== X-Gm-Message-State: AA6/9RmePkQYOJ6YMSTPTmn+KTsSLHP30ML9NiwlwdkO5MOjJeReVGbHF1+upt540PGsWQ== X-Received: by 10.200.52.75 with SMTP id v11mr6347321qtb.137.1476890221012; Wed, 19 Oct 2016 08:17:01 -0700 (PDT) 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 p22sm21076216qka.43.2016.10.19.08.16.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 08:17:00 -0700 (PDT) To: calsify@ietf.org References: From: Michael Douglass Message-ID: Date: Wed, 19 Oct 2016 11:16:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.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-eventpub-extensions-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: Wed, 19 Oct 2016 15:17:12 -0000 Thanks for the comments - and sorry for the delay. I've added my responses to your comments below. I'll post a new draft in a short while: there are 2 issues at least I'd like to address: 1. Should the ASSOCIATE property really be a component? Other extensions to the iCalendar data model are requiring us to handle deeper nesting of components and in any case a component more closely matches XML and JSON representations On 10/8/16 13:59, Daniel Migault wrote: > Hi, > > /reviewed ///draft-ietf-calext-eventpub-extensions-00 /Event Publishing > Extensions to iCalendar. > > / > /Please find my comment below. > > / > /BR, > Daniel > / > / > > / > Section Introduction: > > From the introduction, my understanding is that the draft will describe > two new properties: > > 1) a new property to support HTML which is not mentionned, but I think > corresponds to "styled-Description" > 2) a new property "STRUCTURED-DATA" > > That is personnal but I would proably prefer to have all new properties > mentionedn in the introduction. That is: > - Associate > - Styled-Description > - Structured-Location > - Structured-Resource > - Structured-Data > > with a paragraph associated to each of them. Reworked the intro and moved some of the text into the STRUCTURED-DATA description > > > This text is not clear to me. I guess that is because I do not know what > "org.bedework.util.jms.events" is. > > """ > It is generally important to provide information about > the organizers of such org.bedework.util.jms.events. > """ Inserted by a 'helpful' IDE > > While reading the introduction, I expected the ASSOCIATE to be something > similar as attendee. This is later clarified, but it might be good to > clearly mention the difference in the intro, so people read the document > with a good view of what an associate is. > > """ > In social calendaring it is > often important to identify the active associates in the event, for > example a school sports team, and the inactive associates, for > example the parents. > """ I've added some text to the intro. One of the problems we face is retaining backwards compatibility. Personally I'd like to see us move towards the approach of marking an ASSOCIATE component as schedulable - this would result in that person or resource receiving an invitation. Perhaps the ATTENDEE property could be derived from the ASSOCIATE and simply hold the state. > > section 2. Typed References > > The "TODO" text is not clear to me. > """ > The [RFC5545] LOCATION property provides only an unstructured single > text value for specifying the location where an event (or "TODO" > item) will occur. > """ Replaced with specifying the location where an event or task will occur. > > My understanding of this section is that it cites alternative of the > proposed properties. > > I am a bit confused then why ATTACH is not part of this section. > > Each properties it would be helpful for the reader to mention the gaps > and how the new prperties of the document solve the gaps. > > From reading the section it looks to me that STRUCTURED-DATA is a more > generic way to do STRUCTURED-LOCATION. Can we expect overlaps between > the two properties and eventually see STRUCTURE-LOCATION deprecated one > time in the future ? That's not the intent. STRUCTURED-DATA essentially extends the event or task class with extra meta-data. For example, if the event represents a soccer match the structured-data would reference an appropriate schema and provide additional fields, such as the home team - perhaps scores after the event and so on. In essence the event becomes a soccer-match event. The STRUCTURED-LOCATION is an attribute of the event - it doesn't change its class. Part of what drove the desire for the STRUCTURED-LOCATION property is the possibility of having the event drive GPS systems. To do that we need to adequately identify the location-type - for example when driving to a venue the target is not the venue itself but parking which may be somewhat remote. I'll add more to the description to try to clarify. > > The section does not mention any properties associated to HTML content > properties. My undertanding of it is that iCal has not seen any need for > presentation until now, and leave presentation to the browser or > application. Is that correct ? There's been a long felt need for rich-text in event information - particularly in the public events area. Some systems even provide that through proprietary mechanisms. When calendaring was seen as simply a mechanism for putting together (corporate) meetings rich text was perhaps regarded as a luxury. Even for personal events - or for corporate meetings - being able to create bulleted lists etc would be useful. > > section 2.1. > > Maybe iTip meeting should have a refrence to RFC5546 Done > > > Section 4. > > There are Components properties sdataprop is a new component Not sure what the issue is here > > 5.2. Styled-Description > > styleddescparam seems to have synthax problems. > > styleddescparam = *( > ; > ; The following are OPTIONAL, > ; but MUST NOT occur more than once. > ; > (";" altrepparam) / (";" languageparam) / > (";" fmttypeparam) / > ; > ; the following is OPTIONAL > ; and MAY occur more than once > ; > (";" other-param) > > Fixed > > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > From nobody Wed Oct 19 09:29:43 2016 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 D9ED5129685 for ; Wed, 19 Oct 2016 09:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431] 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 vuQRCfHjn9rn for ; Wed, 19 Oct 2016 09:29:39 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.157.39]) (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 9AA6912955D for ; Wed, 19 Oct 2016 09:29:39 -0700 (PDT) Received: from [172.31.25.241] (VPN-172-31-25-241.VPN.CMU.LOCAL [172.31.25.241]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.15.2/8.15.1) with ESMTPSA id u9JGTbkw127352 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 19 Oct 2016 12:29:38 -0400 To: "calsify@ietf.org" References: From: Ken Murchison Organization: Carnegie Mellon University Message-ID: <4700015a-bb03-f5c8-564f-690adb93aff8@andrew.cmu.edu> Date: Wed, 19 Oct 2016 12:29:37 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.10.19.162118 X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_800_899 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, REFERENCES 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __FRAUD_CONTACT_ADDY 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT2 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NO_NAME 0, __USER_AGENT 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.78 on 128.2.157.39 Archived-At: Subject: Re: [calsify] review of draft-ietf-calext-eventpub-extensions-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: Wed, 19 Oct 2016 16:29:41 -0000 Hi Mike, On 10/19/2016 11:16 AM, Michael Douglass wrote: > Thanks for the comments - and sorry for the delay. > > I've added my responses to your comments below. > > I'll post a new draft in a short while: there are 2 issues at least > I'd like to address: > > 1. Should the ASSOCIATE property really be a component? > Other extensions to the iCalendar data model are requiring us to > handle deeper nesting of components and in any case a component more > closely matches XML and JSON representations I'm not opposed to making ASSOCIATE a component, but what other meta-data would be needed for an ASSOCIATE beyond what is currently specified to warrant the change? Do you have an example in mind that you could flesh out? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Wed Oct 19 12:15:32 2016 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 C50841295A3 for ; Wed, 19 Oct 2016 12:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 V2nWySHOc3eS for ; Wed, 19 Oct 2016 12:15:27 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 B8539126D73 for ; Wed, 19 Oct 2016 12:15:27 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id s49so32853295qta.0 for ; Wed, 19 Oct 2016 12:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=n5M2uLvWJSAsbZiCgRJqkj4Vw1zxACTvKt9+lDaQQIM=; b=OelmFqmYh4KLBua/KqTv05Hmac7WMb5ml076Ovga73xKjeR8Cbf47lzOCXPQukFQfa bwIsKj0M47eree3mIr1B2H0F5NEf5Ze5DivS9zLzp+DZNN/8aiKvqfVzkFLGtV47UZQJ m8/5BrnzyKRvloY5TJVXlpc7o00zxetfydmDXM5sEKer8HMawFwcs9u0LrWsc7x4G4zM s/lPQP30ViZsDOiu4L7F9mzMaq5o3+0IzWAcsb5Iy5G/8i8l/1SPHpWFi1V/3DhQodf9 PD5s7OfuCjrb34MWICHix6WYKpCGivnayLQ9aC2UVMgdvnegPx87Z2uMg+wgNtKEpvlx ALVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=n5M2uLvWJSAsbZiCgRJqkj4Vw1zxACTvKt9+lDaQQIM=; b=bbUTtNNRkAqon+r/tqNtQJpM8UUFA7R+CXXzuFY6nkzFGSbvU7aTlx21/kePAY+lBR bLxTZmqnqIhVTEe5L6ZgjDRdnXQUegfR+/FviKYl3WZ5WD6ETBVn3CAP27NSDhnDRA7F A546tk+Nyu+bmeyqxDTrOLGQhvnLcfOFbEUE5yVT9oEsr8s6dYd/tfMkiccH+7IDNXcC HQ9g5M4xYa9qc6lhvQpfXYsck+Ie8wwgYd7o9EyxYef5ojefnSoVbwQEMDttHEYS+LTZ Vmpaa2kWyeHrXjbcpSMxJmiixbV+UzVaN6Y1KQzdUgtxVXjtYjruzK9RkrB8MMQ8I3xL 4wSA== X-Gm-Message-State: AA6/9RlK7fSuG9JS8zMp9vdoBlOglpSZyaMkJ1HM+UkyeZyzVf+ryIazzV7pS1YST0ycwQ== X-Received: by 10.200.41.33 with SMTP id y30mr8037109qty.66.1476904526628; Wed, 19 Oct 2016 12:15:26 -0700 (PDT) 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 65sm20452409qth.0.2016.10.19.12.15.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 12:15:25 -0700 (PDT) To: calsify@ietf.org References: <4700015a-bb03-f5c8-564f-690adb93aff8@andrew.cmu.edu> From: Michael Douglass Message-ID: <33aceebe-624b-dc74-c23b-3bbbc4968a95@gmail.com> Date: Wed, 19 Oct 2016 15:15:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <4700015a-bb03-f5c8-564f-690adb93aff8@andrew.cmu.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [calsify] review of draft-ietf-calext-eventpub-extensions-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: Wed, 19 Oct 2016 19:15:31 -0000 On 10/19/16 12:29, Ken Murchison wrote: > Hi Mike, > > > On 10/19/2016 11:16 AM, Michael Douglass wrote: >> Thanks for the comments - and sorry for the delay. >> >> I've added my responses to your comments below. >> >> I'll post a new draft in a short while: there are 2 issues at least >> I'd like to address: >> >> 1. Should the ASSOCIATE property really be a component? >> Other extensions to the iCalendar data model are requiring us to >> handle deeper nesting of components and in any case a component more >> closely matches XML and JSON representations > > I'm not opposed to making ASSOCIATE a component, but what other > meta-data would be needed for an ASSOCIATE beyond what is currently > specified to warrant the change? Do you have an example in mind that > you could flesh out? So this is from https://tools.ietf.org/html/draft-apthorp-ical-tasks-01 3.4.2. Relating comments to status The GROUP parameter is used with the STATUS or ATTENDEE properties to relate an associated COMMENT property. The COMMENT property can then be used to include additional human readable information about why the associated STATUS or ATTENDEE property changed. STATUS;REASON="http://example.com/reason/delivery-failed";SUBSTATE =ERROR;MODIFIED=20130212T120000Z;GROUP=G1:FAILED COMMENT;MODIFIED=20130226T110451Z;GROUP=G1:Breakdown ATTENDEE;PARTSTAT=FAILED;MODIFIED=20130226T1104510Z;GROUP=G2: REASON="http://example.com/reason/van-break-down":mailto: xxx@example.com COMMENT;MODIFIED=20130226T110451Z;GROUP=G2:Puncture (An aside - I think the example is faulty - a ":" wheer there should eb a ";") The problem we had to address here is that we wanted a bunch of properties to be related to a specific attendee - so we used the GROUP parameter. Significantly more readable and probably easier to manipulate is the approach of putting all that inside a component Inventing one... BEGIN VATTENDEE ATTENDEE:PARTSTAT=FAILED;MODIFIED=20130226T1104510Z:xxx@example.com REASON="http://example.com/reason/van-break-down" COMMENT;MODIFIED=20130226T110451Z:Puncture END VATTENDEE In fact any attendee attributes could be stored there. I think in vpoll we ended up adopting tha approach for the voter - which could also be an associate if we made it a component From nobody Wed Oct 19 12:34:10 2016 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 5BE401296AF for ; Wed, 19 Oct 2016 12:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431] 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 RTvnWkSB6RfJ for ; Wed, 19 Oct 2016 12:34:01 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (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 099CB1296D2 for ; Wed, 19 Oct 2016 12:34:00 -0700 (PDT) Received: from [172.31.25.241] (VPN-172-31-25-241.VPN.CMU.LOCAL [172.31.25.241]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.15.2/8.15.1) with ESMTPSA id u9JJXwSU055871 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 19 Oct 2016 15:33:59 -0400 To: "calsify@ietf.org" References: <4700015a-bb03-f5c8-564f-690adb93aff8@andrew.cmu.edu> <33aceebe-624b-dc74-c23b-3bbbc4968a95@gmail.com> From: Ken Murchison Organization: Carnegie Mellon University Message-ID: <2da96ddb-ba41-0074-01cc-309482679791@andrew.cmu.edu> Date: Wed, 19 Oct 2016 15:33:58 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <33aceebe-624b-dc74-c23b-3bbbc4968a95@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.10.19.192717 X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __FRAUD_CONTACT_ADDY 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MOZILLA_USER_AGENT 0, __MULTIPLE_URI_TEXT 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT2 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NO_NAME 0, __URI_IN_BODY 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.78 on 128.2.105.203 Archived-At: Subject: Re: [calsify] review of draft-ietf-calext-eventpub-extensions-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: Wed, 19 Oct 2016 19:34:09 -0000 OK, understood. If future drafts will be using such a construct, we might as well introduce it in this draft. On 10/19/2016 03:15 PM, Michael Douglass wrote: > > > On 10/19/16 12:29, Ken Murchison wrote: >> Hi Mike, >> >> >> On 10/19/2016 11:16 AM, Michael Douglass wrote: >>> Thanks for the comments - and sorry for the delay. >>> >>> I've added my responses to your comments below. >>> >>> I'll post a new draft in a short while: there are 2 issues at least >>> I'd like to address: >>> >>> 1. Should the ASSOCIATE property really be a component? >>> Other extensions to the iCalendar data model are requiring us to >>> handle deeper nesting of components and in any case a component more >>> closely matches XML and JSON representations >> >> I'm not opposed to making ASSOCIATE a component, but what other >> meta-data would be needed for an ASSOCIATE beyond what is currently >> specified to warrant the change? Do you have an example in mind that >> you could flesh out? > > So this is from https://tools.ietf.org/html/draft-apthorp-ical-tasks-01 > > > 3.4.2. Relating comments to status > > The GROUP parameter is used with the STATUS or ATTENDEE properties to > relate an associated COMMENT property. The COMMENT property can then > be used to include additional human readable information about why > the associated STATUS or ATTENDEE property changed. > > STATUS;REASON="http://example.com/reason/delivery-failed";SUBSTATE > =ERROR;MODIFIED=20130212T120000Z;GROUP=G1:FAILED > COMMENT;MODIFIED=20130226T110451Z;GROUP=G1:Breakdown > > ATTENDEE;PARTSTAT=FAILED;MODIFIED=20130226T1104510Z;GROUP=G2: > REASON="http://example.com/reason/van-break-down":mailto: > xxx@example.com > COMMENT;MODIFIED=20130226T110451Z;GROUP=G2:Puncture > > (An aside - I think the example is faulty - a ":" wheer there should > eb a ";") > > The problem we had to address here is that we wanted a bunch of > properties to be related to a specific attendee - so we used the GROUP > parameter. > > Significantly more readable and probably easier to manipulate is the > approach of putting all that inside a component > > Inventing one... > > BEGIN VATTENDEE > ATTENDEE:PARTSTAT=FAILED;MODIFIED=20130226T1104510Z:xxx@example.com > REASON="http://example.com/reason/van-break-down" > COMMENT;MODIFIED=20130226T110451Z:Puncture > END VATTENDEE > > > In fact any attendee attributes could be stored there. I think in > vpoll we ended up adopting tha approach for the voter - which could > also be an associate if we made it a component > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Thu Oct 27 22:29:31 2016 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 198CD1294F0; Thu, 27 Oct 2016 22:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.033 X-Spam-Level: X-Spam-Status: No, score=-103.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 yuSpLFSnbFZp; Thu, 27 Oct 2016 22:29:21 -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 4CDD7129466; Thu, 27 Oct 2016 22:29:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 42BE4B811A9; Thu, 27 Oct 2016 22:29:21 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20161028052921.42BE4B811A9@rfc-editor.org> Date: Thu, 27 Oct 2016 22:29:21 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, calsify@ietf.org, rfc-editor@rfc-editor.org Subject: [calsify] RFC 7986 on New Properties for iCalendar 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, 28 Oct 2016 05:29:23 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7986 Title: New Properties for iCalendar Author: C. Daboo Status: Standards Track Stream: IETF Date: October 2016 Mailbox: cyrus@daboo.name Pages: 23 Characters: 45686 Updates: RFC 5545 I-D Tag: draft-ietf-calext-extensions-05.txt URL: https://www.rfc-editor.org/info/rfc7986 DOI: http://dx.doi.org/10.17487/RFC7986 This document defines a set of new properties for iCalendar data and extends the use of some existing properties to the entire iCalendar object. This document is a product of the Calendaring Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC