From nobody Wed Apr 3 03:33:11 2019 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 A8E131200B9 for ; Wed, 3 Apr 2019 03:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 C7ujuSToqVR5 for ; Wed, 3 Apr 2019 03:33:04 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A5D211200B7 for ; Wed, 3 Apr 2019 03:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1554287582; d=isode.com; s=june2016; i=@isode.com; bh=oILFyG7IipQefHZZYPswR8kYya5p9GuvWXOklPOkerg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ir53st17sPQ8EKul0X+c7gHtO5lPMPI9V6sVMoR9P6aRbMMRmNd8nNWn0QRcey9lfj288+ yERcEnGWpKgUZPb9HV+kGvouWrPU4yHTc5NasTVEcIh/VTGxddCZ4z+FLCNIxVkKflUJls lQajS9YtFo9d41wrBIL9TH5LOn7p4So=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 3 Apr 2019 11:33:02 +0100 To: Michael Douglass Cc: calsify@ietf.org References: <009b5762-3b36-61c7-86a4-716391b6ed43@isode.com> <7446205e-303e-74e5-d375-30b210f6eb39@gmail.com> From: Alexey Melnikov Message-ID: Date: Wed, 3 Apr 2019 11:32:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <7446205e-303e-74e5-d375-30b210f6eb39@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------72BCFCE9A50FB3D482B339D7" Content-Language: en-GB Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-eventpub-extensions-10 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 10:33:09 -0000 --------------72BCFCE9A50FB3D482B339D7 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Michael, Some specific comments above. Please post -12 at your earliest=20 convenience so that I can progress the document. On 29/03/2019 04:49, Michael Douglass wrote: > > Hi Alexey- sorry I missed this. Some questions and comments below: > > On 10/29/18 08:37, Alexey Melnikov wrote: >> Hi, >> >> I've done my review of the document. Other people found some of the=20 >> same issues, so you might have already fixed some of them. >> Also note that I might ask for an extra review from people more=20 >> familiar with use of geo-location in IETF protocols. >> >> In Section 3: XML and JSON need Informative References. > > The text I have is > > these extensions as a component rather than a property. This is a > better match for the way XML and JSON handles such structures and > allows richer definitions. > > This is just a reference to the hierarchical nature of XML and JSON=20 > rather than any particular data representation. What should I be=20 > referencing? > RFC 8259 for JSON, for XML > >> >> In 7.3: >> Due to use of RFC 2119 "SHOULD": "text/html" needs an Normative=20 >> Reference, most likely to HTML5. > > I have: > > resource is not given by the "FMTTYPE" parameter. If the media > type remains unknown, calendar applications SHOULD treat it as > type "text/html". This still mean that there is a need for a normative reference. Use the=20 W3C document. >> In 7.6: >> =C2=A0=C2=A0 Property Name:=C2=A0 STRUCTURED-DATA >> >> =C2=A0=C2=A0 Purpose:=C2=A0 This property specifies ancillary data associ= ated with the >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 calendar component. >> >> This is rather vague and I think this has implications for Security=20 >> Considerations (so you should mention something there), because=20 >> anything can be stuffed here, including executable content. >> >> =C2=A0=C2=A0 Value Type:=C2=A0 TEXT, BINARY or URI >> >> But the ABNF: >> >> =C2=A0=C2=A0=C2=A0=C2=A0 sdataprop=C2=A0=C2=A0 =3D "STRUCTURED-DATA" sdat= aparam >> =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 (":" text) / >> =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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ";"= "ENCODING" "=3D" "BASE64" >> =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 ";"= "VALUE" "=3D" "BINARY" >> =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 ":"= binary >> =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=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 ";"= "VALUE" "=3D" "URI" >> =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 ":"= uri >> =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=C2=A0=C2=A0=C2=A0=C2=A0 CRLF >> >> doesn't include TEXT "value" choice I think I missed "text" above, so this is a non issue. >> >> 8.1.=C2=A0 Participant >> >> =C2=A0=C2=A0 Component name:=C2=A0 PARTICIPANT >> >> =C2=A0=C2=A0 Purpose:=C2=A0 This component provides information about a p= articipant in >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 an event or optionally a plain text typed = value. >> >> What does "or optionally a plain text typed value" mean here? This is=20 >> a component, not a single property. > > Yes - hangover from earlier. Changed to > > This component provides information about a participant > in an event or task. > >> Format Definition: >> >> =C2=A0=C2=A0 This property is defined by the following notation: >> >> =C2=A0=C2=A0=C2=A0=C2=A0 participantc=C2=A0 =3D "BEGIN" ":" "PARTICIPANT"= CRLF >> =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 partprop *alarmc >> =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 "END" ":" "PARTICIPANT" CRLF >> >> Is inclusion of "alarmc" intentional? (If it is, that is fine. I just=20 >> think I check.) > That I can't remember - it has the flavor of per-user properties.=20 > However I can remove it. I don't mind, but if it remains you need to add an explanation. >> >> =C2=A0=C2=A0 Example: >> >> =C2=A0=C2=A0 The following is an example of this component.=C2=A0 It cont= ains a SOURCE >> =C2=A0=C2=A0 property which points to a VCARD providing information about= the >> =C2=A0=C2=A0 event participant. >> >> =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 BEGIN:PARTICIPANT >> =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 PARTICIPANT-TYPE:PRINCIPAL_= PERFORMER >> >> PRINCIPAL_PERFORMER is not defined as a valid value for=20 >> PARTICIPANT-TYPE. >> >> SOURCE:http://dir.example.com/vcard/aviolinist.vcf >> =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 END:PARTICIPANT >> >> >> =C2=A0=C2=A0 The following is an example for the primary contact. >> >> =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 BEGIN: PARTICIPANT >> =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 SOURCE;FMTTYPE=3Dtext/vcard= ; >> http://dir.example.com/vcard/contacts/contact1.vcf >> =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 PARTICIPANT-TYPE:PRIMARY-CO= NTACT >> >> PRIMARY-CONTACT is not defined either. >> >> =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 DESCRIPTION:A contact: >> =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 END:PARTICIPANT > Changed to PERFORMER and CONTACT >> >> >> >> In Section 9.1: >> >> =C2=A0=C2=A0 STRUCTURED-LOCATION;LABEL=3D"The venue": >> http://dir.example.com/venues/big-hall.vcf >> =C2=A0=C2=A0 STRUCTURED-LOCATION;LABEL=3D"The venue": >> http://dir.example.com/venues/parking.vcf >> >> Should different instances have different LABEL values? > Done in v-11 >> >> >> >> 11.=C2=A0 Privacy Considerations >> >> I think this section needs to talk about unintended exposure of Geo=20 >> location. >> > Could you elaborate - are we talking about geo location of participants? > Yes.. > > That's beginning to sound like an update to 5546 > Understanding of privacy concerns has evolved since RFC 5546 was=20 published. You just need to mention possible issues here. I am quite=20 certain that you will get a blocking DISCUSS comment during IESG review=20 if you don't. >> 12.2.=C2=A0 New Registration Tables >> >> =C2=A0=C2=A0 This section defines new registration tables for PARTICIPANT= -TYPE and >> =C2=A0=C2=A0 RESTYPE values.=C2=A0 These tables may be updated using the = same >> =C2=A0=C2=A0 approaches laid down in Section 8.2.1 of [RFC5545] >> >> Section 8.2.1 of [RFC5545] implies that IANA registration procedure=20 >> is "Expert Review" >> or "Specification Required" (which implies "Expert Review"). Please=20 >> clarify this for IANA here. > > And it looks like that section has an error. It states... > > designated expert and published in an RFC. A Standards Track RFC is > REQUIRED for the registration of new value data types that modify > existing properties, as well as for the registration of participation > status values to be used in "VEVENT" calendar components. > > partstat is used for tasks so it should really have been less specific. > > Returning to your comment... > > I duplicated the approach taken in e.g.=20 > https://tools.ietf.org/html/rfc6638 so I think that the text ought to=20 > be fine. However - I have to admit I hadn't fully absorbed the=20 > implications so I do need to send emails to the specified lists > If the procedure is clear for IANA, then it is fine with me. --------------72BCFCE9A50FB3D482B339D7 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Michael,

Some specific comments above. Please post -12 at your earliest convenience so that I can progress the document.

On 29/03/2019 04:49, Michael Douglass wrote:

Hi Alexey- sorry I missed this. Some questions and comments below:

On 10/29/18 08:37, Alexey Melnikov wrote:
Hi,

I've done my review of the document. Other people found some of the same issues, so you might have already fixed some of them.
Also note that I might ask for an extra review from people more familiar with use of geo-location in IETF protocols.

In Section 3: XML and JSON need Informative References.

The text I have is

these extensions as a component rather than a property.  This is =
a
better match for the way XML and JSON handles such structures and
allows richer definitions.

This is just a reference to the hierarchical nature of XML and JSON rather than any particular data representation. What should I be referencing?

RFC 8259 for JSON, <https://www.w3.org/TR/2008/REC-xml-20081126/> fo= r XML


In 7.3:
Due to use of RFC 2119 "SHOULD": "text/html" needs an Normative Reference, most likely to HTML5.

I have:

resource is not given by the "FMTTYPE" parameter.  If the media
type remains unknown, calendar applications SHOULD treat it as
type "text/html".
This still mean that there is a need for a normative reference. Use the W3C document.

In 7.6:
=C2=A0=C2=A0 Property Name:=C2=A0 STRUCTURED-DATA

=C2=A0=C2=A0 Purpose:=C2=A0 This property specifies ancillary data a= ssociated with the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 calendar component.

This is rather vague and I think this has implications for Security Considerations (so you should mention something there), because anything can be stuffed here, including executable content.

=C2=A0=C2=A0 Value Type:=C2=A0 TEXT, BINARY or URI

But the ABNF:

=C2=A0=C2=A0=C2=A0=C2=A0 sdataprop=C2=A0=C2=A0 =3D "STRUCTURED-DATA"= sdataparam
=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 (":" text= ) /
=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ";" "ENCODING" "=3D" "BASE64"
=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 ";" "VALUE" "=3D" "BINARY"
=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 ":" binary
=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=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 ";" "VALUE" "=3D" "URI"
=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 ":" uri
=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=C2=A0=C2=A0=C2=A0=C2=A0 CRLF

doesn't include TEXT "value" choice
I think I missed "text" above, so this is a non issue.

8.1.=C2=A0 Participant

=C2=A0=C2=A0 Component name:=C2=A0 PARTICIPANT

=C2=A0=C2=A0 Purpose:=C2=A0 This component provides information abou= t a participant in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 an event or optionally a plain text t= yped value.

What does "or optionally a plain text typed value" mean here? This is a component, not a single property.

Yes - hangover from earlier. Changed to 

This component provides information about a participant
in an event or task.
=C2=A0= =C2=A0 Format Definition:

=C2=A0=C2=A0 This property is defined by the following notation:
=C2=A0=C2=A0=C2=A0=C2=A0 participantc=C2=A0 =3D "BEGIN" ":" "PARTICI= PANT" CRLF
=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 partprop *alarmc
=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 "END" ":" "PARTICIPANT" CRLF

Is inclusion of "alarmc" intentional? (If it is, that is fine. I just think I check.)
That I can't remember - it has the flavor of per-user properties. However I can remove it.
I don't mind, but if it remains you need to add an explanation.

=C2=A0=C2=A0 Example:

=C2=A0=C2=A0 The following is an example of this component.=C2=A0 It= contains a SOURCE
=C2=A0=C2=A0 property which points to a VCARD providing information = about the
=C2=A0=C2=A0 event participant.

=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 BEGIN:PARTICIPANT =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 PARTICIPANT-TYPE:PRIN= CIPAL_PERFORMER

PRINCIPAL_PERFORMER is not defined as a valid value for PARTICIPANT-TYPE.

SOURCE:http://dir.example.com/vcard/aviolinist.v= cf
=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 END:PARTICIPANT


=C2=A0=C2=A0 The following is an example for the primary contact.
=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 BEGIN: PARTICIPANT =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 SOURCE;FMTTYPE=3Dtext= /vcard;
http://dir.example.com/vcard/contacts/con= tact1.vcf
=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 PARTICIPANT-TYPE:PRIM= ARY-CONTACT

PRIMARY-CONTACT is not defined either.

=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 DESCRIPTION:A contact= :
=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 END:PARTICIPANT
Changed to PERFORMER and CONTACT



In Section 9.1:

=C2=A0=C2=A0 STRUCTURED-LOCATION;LABEL=3D"The venue":
=C2=A0=C2=A0=C2=A0 http://dir.example.com/venues/big-hall.vc= f
=C2=A0=C2=A0 STRUCTURED-LOCATION;LABEL=3D"The venue":
=C2=A0=C2=A0=C2=A0 http://dir.example.com/venues/parking.vcf=

Should different instances have different LABEL values?
Done in v-11



11.=C2=A0 Privacy Considerations

I think this section needs to talk about unintended exposure of Geo location.

Could you elaborate - are we talking about geo location of participants?

Yes..

That's beginning to sound like an update to 5546

Understanding of privacy concerns has evolved since RFC 5546 was published. You just need to mention possible issues here. I am quite certain that you will get a blocking DISCUSS comment during IESG review if you don't.

12.2.=C2=A0 New Registration Tables

=C2=A0=C2=A0 This section defines new registration tables for PARTICIPANT-TYPE and
=C2=A0=C2=A0 RESTYPE values.=C2=A0 These tables may be updated using= the same
=C2=A0=C2=A0 approaches laid down in Section 8.2.1 of [RFC5545]

Section 8.2.1 of [RFC5545] implies that IANA registration procedure is "Expert Review"
or "Specification Required" (which implies "Expert Review"). Please clarify this for IANA here.

And it looks like that section has an error. It states...

   designated expert and published in an RFC.  A Standards Track =
RFC is
   REQUIRED for the registration of new value data types that modify
   existing properties, as well as for the registration of participation
   status values to be used in "VEVENT" calendar components.

partstat is used for tasks so it should really have been less specific.

Returning to your comment...

I duplicated the approach taken in e.g. https://tools.ietf.org/html/rfc6638 so I think that the text ought to be fine. However - I have to admit I hadn't fully absorbed the implications so I do need to send emails to the specified lists

If the procedure is clear for IANA, then it is fine with me.

--------------72BCFCE9A50FB3D482B339D7-- From nobody Mon Apr 8 19:29:35 2019 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 80B7512013C for ; Mon, 8 Apr 2019 19:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 p59WEX36LIsk for ; Mon, 8 Apr 2019 19:29:32 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 BDFF4120077 for ; Mon, 8 Apr 2019 19:29:32 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id w20so9335912qka.7 for ; Mon, 08 Apr 2019 19:29:32 -0700 (PDT) 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:content-language; bh=8mtEjI5d/CSgEgdUMdGaXNyIM8XUDfMIWHVk/iWhAaE=; b=Z86kdqTnkTvrt6BE6jREtvemHaQw4quetEuLuBCSqzcg1ycAOLcivdaeOay7EvzOqq Fq/qmAbDzI4W2/voS+eApw+0N1YHTX6vYUyw+nK2pHMeUohgr3FHe3mN3/jG504Lutf1 RW4Hk+BlYTdAVPwXFS937Avpfa3ZWvnKYNjvDATHJrhNCLTwY0BQq0t+uAmIWV13u7Gn CNRdVdg3mpQbvh4uHFZsJJHNR+Of4Ob0fyOVkicZb9UDa5hYbd2haGnVwh4fSO1Ci1r2 yIzfEWfR9ibfXNkODQ3/OFmmt6FLI3pKbc5pQH7dSc2YbOSbilYL1dnFxORzPRB89oG3 Fu4Q== 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 :content-language; bh=8mtEjI5d/CSgEgdUMdGaXNyIM8XUDfMIWHVk/iWhAaE=; b=izKaxkTe9J2fRimDb7WrMOLFonqruzE1huiesdjUt+maTor3wvgBzAxDYU966ZpBTt 5L2KXKtJ6QpL5OMujfdmeGOzkRyAsTfzps06v81+bUsDs0Ff8WofCnsul5SNk5SwnW8S EMAbjx+SH8lSfbN0AeTx3/VrghsOdXOa3Hl+Fq5K6d4HgcHIpkNuvRZ0dvsfRblYt/Gg tFFBg8spgeqh8BBS7W7AjEAn52h3+WAUFrmGTsDv3DwPNzFZO5o7LSs+rSVzoT1Qxq7v hqWZqV86blJsNAfLzywouUNREZbUTt7rarJxQbOPMf3KjrlLhCoy1IfkCSmcxrs7jq4x metA== X-Gm-Message-State: APjAAAVZQ+Cf1fhwEhtuXJ/jsRfYUvSNwr2hmpp5EH8En/+1s9THeeu2 IFI8sa8g5jfdUnsS5y2RJKdPoftUAJA= X-Google-Smtp-Source: APXvYqxjCDTOutMRw/ERBotZVwLDv9eB6aFEM6O6OVzx6ZMoqRJe90dnSoBlRpnQbhztfrSFASlMZQ== X-Received: by 2002:a05:620a:1244:: with SMTP id a4mr24513296qkl.282.1554776971795; Mon, 08 Apr 2019 19:29:31 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id n188sm17556357qkb.40.2019.04.08.19.29.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 19:29:30 -0700 (PDT) To: calsify@ietf.org References: <153361352682.26812.17456909195532930218@ietfa.amsl.com> <93d39276a169c52490c3507015064369cd309976.camel@aegee.org> From: Michael Douglass Message-ID: <8cb41a3c-7f4f-a269-6683-cf62747c2794@gmail.com> Date: Mon, 8 Apr 2019 22:29:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <93d39276a169c52490c3507015064369cd309976.camel@aegee.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-08.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 02:29:34 -0000 Sorry - i missed this. Incorporated into version 12. Thanks for the catching the typos. On 10/10/18 03:51, Дилян Палаузов wrote: > Hello, > > Section 3.1.2.1 Reserving facilities > “The current ATTENDEE property dos not allow for the additon of…” > dos → does? > > Section 6. Redefined Property SOURCE > “Conformance: This property MAY be appear in any iCalendar component.” > Without “be”? > > Section 7.4 Structured-Location > As there is no default value type, the value type must be provided > every time explicitly. In the example at the end of section 7.4 this > was not done, neither in the Section 9.1 Example 1. > > For the latter example two structured locations show the same > LABEL. This might not be very good, as the UI will show both > locations as equivalent. Perhaps a more descriptibe label, that > distinguishes both structured-locations? > > Section 8.1. Participant > Conformance: “This component MAY *be* appear in any > iCalendar component.” > > Can VFREEBUSY or VAVAILABILITY contain PARTICIPANT. Thanks. Added to freebusy. Availability doesn't have attendeed > > Why doesn't the component name start with V? It aligns more with jscal. But I guess i's just a convention. > > Section 8.1 Participant first example in draft-ietf-calext-eventpub- > extensions-*07*: please verify that the new lines are presented > correctly. Reading the epub variant shows no new line after BEGIN: > PARTICIPANT and before PARTICIPANT-TYPE, so likely the source file of > the draft needs dome tweaking. > > Greetings > Дилян > > > On Mon, 2018-08-06 at 20:45 -0700, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Calendaring Extensions WG of the IETF. >> >> Title : Event Publishing Extensions to iCalendar >> Author : Michael Douglass >> Filename : draft-ietf-calext-eventpub-extensions-08.txt >> Pages : 32 >> Date : 2018-08-06 >> >> Abstract: >> This specification updates [RFC5545] and [RFC5546] by introducing 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-08 >> https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-08 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-08 >> >> >> 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/ >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Mon Apr 8 19:31:24 2019 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 C72FE120375; Mon, 8 Apr 2019 19:31:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <155477707073.30022.1767425713568430776@ietfa.amsl.com> Date: Mon, 08 Apr 2019 19:31:10 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-12.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 02:31:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : Event Publishing Extensions to iCalendar Author : Michael Douglass Filename : draft-ietf-calext-eventpub-extensions-12.txt Pages : 34 Date : 2019-04-08 Abstract: This specification updates RFC5545 by introducing 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-12 https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-12 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 Mon Apr 15 09:07:21 2019 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 12F811203DF; Mon, 15 Apr 2019 09:07:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: daniel.migault@ericsson.com, draft-ietf-calext-eventpub-extensions@ietf.org, Daniel Migault , calext-chairs@ietf.org, calsify@ietf.org, alexey.melnikov@isode.com Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155534444001.10836.4918464706630882842.idtracker@ietfa.amsl.com> Date: Mon, 15 Apr 2019 09:07:20 -0700 Archived-At: Subject: [calsify] Last Call: (Event Publishing Extensions to iCalendar) to Proposed Standard X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 16:07:20 -0000 The IESG has received a request from the Calendaring Extensions WG (calext) to consider the following document: - 'Event Publishing Extensions to iCalendar' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification updates RFC5545 by introducing 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Apr 15 22:38:17 2019 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 A0083120118; Mon, 15 Apr 2019 22:38:14 -0700 (PDT) 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, 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=fastmailteam.com header.b=WQdRcCll; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CbAze9bq 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 eIRBwtTeqgFS; Mon, 15 Apr 2019 22:38:12 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EF412025B; Mon, 15 Apr 2019 22:38:12 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 30D0A239D9; Tue, 16 Apr 2019 01:38:11 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 16 Apr 2019 01:38:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=BYvR9OcZc8Xte2fhkPnjs+HE6nO3yqtVpSCyWiu KoIc=; b=WQdRcCllL+Nvg90ZIswy97C36yNFzDeK1OJexWs37yeKc6xhyoXImf6 CMkFkQls3DNSWGWEG4OH0O9UM3hMex8M4ElyqrCWClJA1J8b6fmndCVSEmUXv89g dbMqKuiz8Ese1C0rg36Sr/wwUrWxaebF5sr48Tx+8wNyeToEmVTmqcP1XchOmOuv EWriDBW36ojk+iCsBTmQdT8cSW8tAFWdQdOY5kEIBOl+uE/gOkAASLb39TXTZoUA vnmp5PCxMm5fmxfcaHxv59WijhaexkHKaGhH4WsCvUzn4mEmlSLCsOMDLx16zf+r si2np83aSVAfk9XD9jba7EuruXuMDnA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=BYvR9OcZc8Xte2fhkPnjs+HE6nO3y qtVpSCyWiuKoIc=; b=CbAze9bqsp8lNvnbTl728ykGcd+XQFQrt995NWXlU0W0o MlY86Wq14JwYGtzWer12rBu5jSNxQ1vEXghLf6yQIlXoe3Tullv3Cn01+7e6ePRs JG8XHdM+gRsxDA90w1AVad5Oc2fQaK7go9Z6iEzOF8hWD4Vdg82ESr/PnenjF5dW RdSuiiZnoMXF8SHmQ6MCb7TlAAveFKpCkNx3jJTTmpRmxX7Qr6T8KM7WGmdyq+4w IZUh4hAt7AKEja9CpMCMMsrzv6pVjNWMYmmJtWSsL42JVWUHRxOyWSK82VTdBqz4 rePUz/5AaO4HLg9A51z3BRG5+rx1go++wkzQbza4Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrfedtgdeljecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrg hrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7326F2069B; Tue, 16 Apr 2019 01:38:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-442-g0747b46-fmstable-20190416v2 Mime-Version: 1.0 X-Me-Personality: 56629417 Message-Id: <0d26c814-19a9-4634-991d-911aa8be009e@www.fastmail.com> Date: Tue, 16 Apr 2019 01:38:09 -0400 From: "Bron Gondwana" To: calsify@ietf.org, jmap@ietf.org, caldeveloper-l@lists.calconnect.org Content-Type: multipart/alternative; boundary=7de10601843b4e34831af6e3fefc985c Archived-At: Subject: [calsify] Looking for a co-author for JMAP Calendars X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 05:38:15 -0000 --7de10601843b4e34831af6e3fefc985c Content-Type: text/plain Hi All, The JMAP working group at IETF is looking for a co-author to work on a JMAP spec for calendar access. This can be anybody with some calendar experience who's willing to help! An initial draft is here: https://datatracker.ietf.org/doc/draft-jenkins-jmapcalendars/ There is still considerable work to do, particularly around how scheduling will interact, and whether events can be present in multiple calendars simultaneously in the same way that Email objects can be in multiple Mailboxes over in jmap-mail. Obviously we'd love to have somebody from outside FastMail who brings different background and experience to help with the document! Neil is happy to stay on as a co-editor as well. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --7de10601843b4e34831af6e3fefc985c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,

The JMAP working group at IETF is l= ooking for a co-author to work on a JMAP spec for calendar access. = This can be anybody with some calendar experience who's willing to help= !

An initial draft is here:


The= re is still considerable work to do, particularly around how scheduling = will interact, and whether events can be present in multiple calendars s= imultaneously in the same way that Email objects can be in multiple Mail= boxes over in jmap-mail.

=
Obviously we'd love to have some= body from outside FastMail who brings different background and experienc= e to help with the document!  Neil is happy to stay on as a co-edit= or as well.

Cheers,

Bron.

--
  Bron Gondwana, C= EO, FastMail Pty Ltd
  brong@fast= mailteam.com


--7de10601843b4e34831af6e3fefc985c-- From nobody Mon Apr 22 11:14:30 2019 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 D3901120128; Mon, 22 Apr 2019 11:14:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz via Datatracker To: Cc: draft-ietf-calext-eventpub-extensions.all@ietf.org, ietf@ietf.org, calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Rich Salz Message-ID: <155595686177.21216.4076761255030943970@ietfa.amsl.com> Date: Mon, 22 Apr 2019 11:14:21 -0700 Archived-At: Subject: [calsify] Secdir last call review of draft-ietf-calext-eventpub-extensions-12 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 18:14:22 -0000 Reviewer: Rich Salz Review result: Has Nits This is the SECDIR last-call review, intended to be input to the Security AD's. Ready with nits. The Security Considerations and Privacy Considerations are short, but they seem to reasonably refer to already-published documents. Following are nits I noticed. Abstract "a number of new iCalendar properties and components" -> "a new iCalendar component and a number of properties" Maybe stike "iCalendar" Sec 1, STRUCTURED-DATA. In my opinion the confirmation code would be the most useful new info :) Sec 1, SOURCE Is it redefined or extended? Sec 2, para 2. "In a break with this 'tradition' ..." --> "Breaking with this practice, ..." Sec 3, "When a calendar client receives a calendar component" Should the second calendar be CALENDAR? Should the first be "iCalendar"? Sec 3.1.1, uppercase "vcard"? Sec 3.1.2.1 "non of which" --> "none of which" Sec 4 Perhaps add a sentence saying where this syntax is defined. Is this the complete iCalendar spec or is it just changing a few things? Sec 5.1, etc "as laid down in" Is kind of informal wording. Sec 6, the notation has "value=URI" but the example has "URL" (Sec 7.3, etc., uses URI in both parts) Sec 10, "applications using" Is "acting on" better? From nobody Tue Apr 23 06:02:52 2019 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 6616912042D; Tue, 23 Apr 2019 06:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 mJgtyg-AL91c; Tue, 23 Apr 2019 06:02:49 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730084.outbound.protection.outlook.com [40.107.73.84]) (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 DA870120429; Tue, 23 Apr 2019 06:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fgnshjnX6hY74jeoUypE04h8e/79anQ6QcqWnitx16M=; b=jV5QSgIMiUPyuzTzZ2JRclQW5mjoCtt+3w/HXe0TZuVWLzltyFqB8rSwkvosfFeZE4SzO8617yM0XuUMFFBOl2bYA7P8dAygEoOzqnH4RpFrliRIb32jb5bPx9zf5EQ0Cll6TXgoFi7mnRfrOgZo10H637uDPe2WhMt8hgu0/qc= Received: from MN2PR15MB3310.namprd15.prod.outlook.com (20.179.21.142) by MN2PR15MB2941.namprd15.prod.outlook.com (20.178.252.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.16; Tue, 23 Apr 2019 13:02:42 +0000 Received: from MN2PR15MB3310.namprd15.prod.outlook.com ([fe80::1526:901b:cb1a:5fef]) by MN2PR15MB3310.namprd15.prod.outlook.com ([fe80::1526:901b:cb1a:5fef%3]) with mapi id 15.20.1813.017; Tue, 23 Apr 2019 13:02:42 +0000 From: Daniel Migault To: Rich Salz , "secdir@ietf.org" CC: "draft-ietf-calext-eventpub-extensions.all@ietf.org" , "ietf@ietf.org" , "calsify@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-calext-eventpub-extensions-12 Thread-Index: AQHU+Tc7pc5UYH8MwUCRn5sj/IlATaZJtyFw Date: Tue, 23 Apr 2019 13:02:42 +0000 Message-ID: References: <155595686177.21216.4076761255030943970@ietfa.amsl.com> In-Reply-To: <155595686177.21216.4076761255030943970@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; x-originating-ip: [192.75.88.130] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 58d2e83c-d93f-4155-eac5-08d6c7ebf901 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR15MB2941; x-ms-traffictypediagnostic: MN2PR15MB2941: x-microsoft-antispam-prvs: x-forefront-prvs: 0016DEFF96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(346002)(39860400002)(376002)(396003)(199004)(189003)(13464003)(51914003)(4326008)(110136005)(54906003)(66946007)(66476007)(73956011)(66556008)(66446008)(71200400001)(99286004)(6436002)(229853002)(66066001)(64756008)(8936002)(71190400001)(7696005)(86362001)(2501003)(14454004)(7736002)(76176011)(44832011)(33656002)(305945005)(478600001)(2906002)(26005)(76116006)(256004)(14444005)(186003)(74316002)(3846002)(6246003)(53936002)(476003)(11346002)(5660300002)(97736004)(6116002)(316002)(81166006)(6506007)(81156014)(486006)(25786009)(8676002)(53546011)(52536014)(102836004)(68736007)(446003)(9686003)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR15MB2941; H:MN2PR15MB3310.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: iI27AL15Bj4z9TcBMjbhm6fheg1lzsrVgwEYepsvKc/ncYb9Bcbnc3LbkjY/S6lHS8RO1ZUalT9/G+EhoZm5LpENcz2dJEkkNIvxjPNGw3fSzyJy7Z2QOGjwV4DPwq3ZEW+vnWF12YQbVhrDzKlSE0FoFS6Wq7mVbsgoQJw4vnblmwc7WV36P3vawHit3+XYqWj127w8/n9SknxivwKtrvzEQ9RlSmtH/unNLQJHmqVCPvZ00v7E4RXGmnlLT9QFlCaHVWPvH4sc0BLBh5MDDXX/4LKIHO+q8vagqayzInTtOB5TpxanY+Zj0tm+36mF9AsfqahgivuQ4qmeQQdhC6Wxjs4PUwoRkP3Uj+G9I4UHlZFSKiiP75234dBRfoOjvibpzyqs8WA0YK+utDT6CuGBTd2WbdqywBDJI2lmUS4= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 58d2e83c-d93f-4155-eac5-08d6c7ebf901 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2019 13:02:42.6707 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR15MB2941 Archived-At: Subject: Re: [calsify] Secdir last call review of draft-ietf-calext-eventpub-extensions-12 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 13:02:52 -0000 VGhhbmtzIGZvciB0aGUgcmV2aWV3IFJpY2ghDQpZb3VycywgDQpEYW5pZWwNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJpY2ggU2FseiB2aWEgRGF0YXRyYWNrZXIgPG5vcmVw bHlAaWV0Zi5vcmc+IA0KU2VudDogTW9uZGF5LCBBcHJpbCAyMiwgMjAxOSAyOjE0IFBNDQpUbzog c2VjZGlyQGlldGYub3JnDQpDYzogZHJhZnQtaWV0Zi1jYWxleHQtZXZlbnRwdWItZXh0ZW5zaW9u cy5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGNhbHNpZnlAaWV0Zi5vcmcNClN1YmplY3Q6 IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY2FsZXh0LWV2ZW50cHViLWV4 dGVuc2lvbnMtMTINCg0KUmV2aWV3ZXI6IFJpY2ggU2Fseg0KUmV2aWV3IHJlc3VsdDogSGFzIE5p dHMNCg0KVGhpcyBpcyB0aGUgU0VDRElSIGxhc3QtY2FsbCByZXZpZXcsIGludGVuZGVkIHRvIGJl IGlucHV0IHRvIHRoZSBTZWN1cml0eSBBRCdzLg0KDQpSZWFkeSB3aXRoIG5pdHMuDQoNClRoZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBhbmQgUHJpdmFjeSBDb25zaWRlcmF0aW9ucyBhcmUgc2hv cnQsIGJ1dCB0aGV5IHNlZW0gdG8gcmVhc29uYWJseSByZWZlciB0byBhbHJlYWR5LXB1Ymxpc2hl ZCBkb2N1bWVudHMuDQoNCkZvbGxvd2luZyBhcmUgbml0cyBJIG5vdGljZWQuDQoNCkFic3RyYWN0 ICJhIG51bWJlciBvZiBuZXcgaUNhbGVuZGFyIHByb3BlcnRpZXMgYW5kIGNvbXBvbmVudHMiIC0+ ICJhIG5ldyBpQ2FsZW5kYXIgY29tcG9uZW50IGFuZCBhIG51bWJlciBvZiBwcm9wZXJ0aWVzIiAg TWF5YmUgc3Rpa2UgImlDYWxlbmRhciINCg0KU2VjIDEsIFNUUlVDVFVSRUQtREFUQS4gSW4gbXkg b3BpbmlvbiB0aGUgY29uZmlybWF0aW9uIGNvZGUgd291bGQgYmUgdGhlIG1vc3QgdXNlZnVsIG5l dyBpbmZvIDopDQoNClNlYyAxLCBTT1VSQ0UgSXMgaXQgcmVkZWZpbmVkIG9yIGV4dGVuZGVkPw0K DQpTZWMgMiwgcGFyYSAyLiAgIkluIGEgYnJlYWsgd2l0aCB0aGlzICd0cmFkaXRpb24nIC4uLiIg LS0+ICJCcmVha2luZyB3aXRoIHRoaXMgcHJhY3RpY2UsIC4uLiINCg0KU2VjIDMsICJXaGVuIGEg Y2FsZW5kYXIgY2xpZW50IHJlY2VpdmVzIGEgY2FsZW5kYXIgY29tcG9uZW50IiBTaG91bGQgdGhl IHNlY29uZCBjYWxlbmRhciBiZSBDQUxFTkRBUj8gU2hvdWxkIHRoZSBmaXJzdCBiZSAiaUNhbGVu ZGFyIj8NCg0KU2VjIDMuMS4xLCB1cHBlcmNhc2UgInZjYXJkIj8NCg0KU2VjIDMuMS4yLjEgIm5v biBvZiB3aGljaCIgLS0+ICJub25lIG9mIHdoaWNoIg0KDQpTZWMgNCBQZXJoYXBzIGFkZCBhIHNl bnRlbmNlIHNheWluZyB3aGVyZSB0aGlzIHN5bnRheCBpcyBkZWZpbmVkLiBJcyB0aGlzIHRoZSBj b21wbGV0ZSBpQ2FsZW5kYXIgc3BlYyBvciBpcyBpdCBqdXN0IGNoYW5naW5nIGEgZmV3IHRoaW5n cz8NCg0KU2VjIDUuMSwgZXRjICJhcyBsYWlkIGRvd24gaW4iIElzIGtpbmQgb2YgaW5mb3JtYWwg d29yZGluZy4NCg0KU2VjIDYsIHRoZSBub3RhdGlvbiBoYXMgInZhbHVlPVVSSSIgYnV0IHRoZSBl eGFtcGxlIGhhcyAiVVJMIiAoU2VjIDcuMywgZXRjLiwgdXNlcyBVUkkgaW4gYm90aCBwYXJ0cykN Cg0KU2VjIDEwLCAiYXBwbGljYXRpb25zIHVzaW5nIiBJcyAiYWN0aW5nIG9uIiBiZXR0ZXI/DQoN Cg0K From nobody Tue Apr 23 07:57:00 2019 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 90A9C120033 for ; Tue, 23 Apr 2019 07:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sphericalcowgroup-com.20150623.gappssmtp.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 0G8IH6xkwRDa for ; Tue, 23 Apr 2019 07:56:41 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 0772D1203E9 for ; Tue, 23 Apr 2019 07:56:40 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id c190so4970935qke.9 for ; Tue, 23 Apr 2019 07:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sphericalcowgroup-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=5NFBL185QZVEpCuj6eVajLRQYiAXyxm9CgKlZoUY3cA=; b=ywlbYjDeQ9wLpRNTJV2Xd1aCKsDAHnJcN51/C/rDvUWRkQhQcDUUeUXZJiMKEL2Mh3 1hqKmM/6hO9fbNB9xN9eJxwD9R3ZzGPrkNdgbVVb6U+U/V60wz/pq7Je0cZVD1vxaXt/ SsYhVPbUZrT18GNpnLm2VYUhMyWQ93mKzFA0eXSxyDy4RLvgus6QF3v+Cogx1JERGYsT 49KuVCzItiTsrceOYGEZ+i0zkP5k8ENjoctS4sY8owB9pSqNAVw/rrc/NdkvkGSwRcCm 3ccSjLBCIkX6tM9svD4aXi0LE/1PiE8EgnvLDfwzyth2Rz0d95PvRAQL8KWRcD5QoAbH InyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=5NFBL185QZVEpCuj6eVajLRQYiAXyxm9CgKlZoUY3cA=; b=S7VNEk9a8QHntQNQs64bN/VGa6h+4AcKXRcHa7uzIOEiEWmYBeIcnaHS+rTA1tqyel qMhOKDYmd8Ir3G1o51h0Jt2N430JIX1EJ6Y7BAaK+sVW6yWRi4jIQEmN+j+AdtMQrVl7 GRRaDnKDZIR19kMySC15jMybhObKj5vH08x/Uag+9Mnmw7Q3ZoL+BRT4DCC4MU3Ka4Q0 MxYnH7CUdUHsQHeZ4KOlt5W4NNsy50WpoB3p4+lsaev1CmOTy3WOz4ypk8nDr70Fo5kA WSsesrcAn/yEg5dAYlYIlSvH1ZmpMrJlKzo6jAD0LFVJAC+y2ahDfq79F7uDVM+9v1RZ yJcg== X-Gm-Message-State: APjAAAXMg3ENNxhh5WtmeJRIrRtEYcggGaPgURbSs+RzfcqQ7UvKKo7R bpv4UEJmWJkMZLYfmzlpEjiWToewWLo= X-Google-Smtp-Source: APXvYqzRrnAnDR6fOB4niF0a0urhF3iYZd8WRSCzdTpfYfK5WSNIe4xtxhYggJIbpwXDne8l8TbaJg== X-Received: by 2002:ae9:f00e:: with SMTP id l14mr20043781qkg.127.1556031398522; Tue, 23 Apr 2019 07:56:38 -0700 (PDT) Received: from a-192-168-131-11.dynapool.vpn.nyu.edu (vpnrasa-wwh-pat-01.natpool.nyu.edu. [216.165.95.84]) by smtp.gmail.com with ESMTPSA id x8sm9343729qtj.45.2019.04.23.07.56.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Apr 2019 07:56:37 -0700 (PDT) To: Daniel Migault , Rich Salz , "secdir@ietf.org" Cc: "draft-ietf-calext-eventpub-extensions.all@ietf.org" , "ietf@ietf.org" , "calsify@ietf.org" References: <155595686177.21216.4076761255030943970@ietfa.amsl.com> From: Michael Douglass Message-ID: Date: Tue, 23 Apr 2019 10:56:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [calsify] Secdir last call review of draft-ietf-calext-eventpub-extensions-12 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 14:56:43 -0000 Thanks for the comments: All useful - and yes - I'll add the confirmation code. I'll incorporate these changes On 4/23/19 09:02, Daniel Migault wrote: > Thanks for the review Rich! > Yours, > Daniel > > -----Original Message----- > From: Rich Salz via Datatracker > Sent: Monday, April 22, 2019 2:14 PM > To: secdir@ietf.org > Cc: draft-ietf-calext-eventpub-extensions.all@ietf.org; ietf@ietf.org; calsify@ietf.org > Subject: Secdir last call review of draft-ietf-calext-eventpub-extensions-12 > > Reviewer: Rich Salz > Review result: Has Nits > > This is the SECDIR last-call review, intended to be input to the Security AD's. > > Ready with nits. > > The Security Considerations and Privacy Considerations are short, but they seem to reasonably refer to already-published documents. > > Following are nits I noticed. > > Abstract "a number of new iCalendar properties and components" -> "a new iCalendar component and a number of properties" Maybe stike "iCalendar" > > Sec 1, STRUCTURED-DATA. In my opinion the confirmation code would be the most useful new info :) > > Sec 1, SOURCE Is it redefined or extended? > > Sec 2, para 2. "In a break with this 'tradition' ..." --> "Breaking with this practice, ..." > > Sec 3, "When a calendar client receives a calendar component" Should the second calendar be CALENDAR? Should the first be "iCalendar"? > > Sec 3.1.1, uppercase "vcard"? > > Sec 3.1.2.1 "non of which" --> "none of which" > > Sec 4 Perhaps add a sentence saying where this syntax is defined. Is this the complete iCalendar spec or is it just changing a few things? > > Sec 5.1, etc "as laid down in" Is kind of informal wording. > > Sec 6, the notation has "value=URI" but the example has "URL" (Sec 7.3, etc., uses URI in both parts) > > Sec 10, "applications using" Is "acting on" better? > > From nobody Tue Apr 23 23:50:08 2019 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 2BA4A12013C for ; Tue, 23 Apr 2019 23:50:06 -0700 (PDT) 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, 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=fastmailteam.com header.b=a5wo7NWi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Xk9RmCXB 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 NWNjVfZfexZB for ; Tue, 23 Apr 2019 23:50:04 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2322112004C for ; Tue, 23 Apr 2019 23:50:04 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2565922247; Wed, 24 Apr 2019 02:50:03 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 24 Apr 2019 02:50:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=qEof EXzv+n95cCmdvl/C5HZhS40uDE45KL4yARg2mNA=; b=a5wo7NWiAnHQzHcfgqvO sEaqCxza1x5UOCbCZWK9viYx+tAhjt+sfRlEiWZKKbIjsLkaKpjsbc1MnB7qXGKg 7Dwv8tZw/yjy9a2gr/TeCiIRAQGHQKR2PyTMPtP7TWkRJ5DB8WxTdV5kq2DSILyt JYfSGFDKJJnnXglplUhPq9yEKy9NPGB81rsyZkhJQ70ygIFTFFPt8XXnTuvE68et HX8gf1TsgK7+D7MF+nRka9b/3eD/V0U4WT8cpkfvAjkBi+AuclPairwCiZX9G7jQ E8Ob8LkIuony67uIDTxnRWD1AExC2qSjv1zjXb4GO2Ntt4nnTuZn+vi3sBj9zP67 kQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=qEofEX zv+n95cCmdvl/C5HZhS40uDE45KL4yARg2mNA=; b=Xk9RmCXBXgLkhjHbeLhRQd Q5yDD168uzB/ei7isFA0BXWFw7jHGcQ44bSe+3wRmApUXyenCGtAoBziwWH/idv4 4MbVOYj1erqm0A4ye+mKtU6ZSPVn2GoW5STpQUEfL0Fd75tJhPNBFmPGz9yxvr47 ppF+UBcx4ZMoYOB3jdr3VoZDz5HRQHhfOPUbLU0/fSeWtrUSlWeSkgi9ZXeuJTwC EhdJuU3US6eSHFADajIbo8xjpgBd6NJpQmUc+wM6bAzq1xnhg9W9ABbA069/voN1 27FVcOi6R1A2E6JZ5TmIbl+4EsiD5CMoEait8p+yXYwa9mdNtCukseIaRLZqiZiA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeelgdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgnecurfgrrhgr mhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6B649205F7; Wed, 24 Apr 2019 02:50:02 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-443-g918f9d3-fmstable-20190416v3 Mime-Version: 1.0 Message-Id: In-Reply-To: <0d660d52-4771-409c-a91f-031ad103404f@www.fastmail.com> References: <0d660d52-4771-409c-a91f-031ad103404f@www.fastmail.com> Date: Wed, 24 Apr 2019 02:50:01 -0400 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=6e9b8d35d7654ea1adbd9ce62f65d613 Archived-At: Subject: Re: [calsify] Call for adoption of vpoll - please reply by April 15 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 06:50:06 -0000 --6e9b8d35d7654ea1adbd9ce62f65d613 Content-Type: text/plain As there have been no objections, Mike - if you could please upload this document as draft-ietf-calext-vpoll-00 we can get moving on it! Cheers, Bron. On Tue, Mar 26, 2019, at 21:03, Bron Gondwana wrote: > Hi All, > > As discussed in the Prague meeting, this is a formal call for adoption of work on a mechanism for consensus scheduling of events, based on the VPOLL work which can be seen in: > > https://github.com/CalConnect/PUBLIC_DRAFTS/tree/master/vpoll > > and > > https://www.ietf.org/archive/id/draft-york-vpoll-04.txt > > It is expected that after adopting this work, we would aim for Q3 2019 as a milestone for working group last call, with a possibility of dealing with it earlier if the current documents process quickly! > > Please reply to this message by April 15th if you do not wish the working group to adopt this work. > > Regards, > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --6e9b8d35d7654ea1adbd9ce62f65d613 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
As there have been no objections, Mike - if you could= please upload this document as draft-ietf-calext-vpoll-00 we can get mo= ving on it!

Cheers,

Bron.

O= n Tue, Mar 26, 2019, at 21:03, Bron Gondwana wrote:
Hi All,

As discussed in the Prague meeting, this is a formal call for = adoption of work on a mechanism for consensus scheduling of events, base= d on the VPOLL work which can be seen in:


and<= br>


It is expected that after adopting this work, we would aim= for Q3 2019 as a milestone for working group last call, with a possibil= ity of dealing with it earlier if the current documents process quickly!=

Please reply to this message by April 15th if you do not= wish the working group to adopt this work.

Regards,
<= /div>

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


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

=

--
&= nbsp; Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com

--6e9b8d35d7654ea1adbd9ce62f65d613-- From nobody Tue Apr 23 23:53:21 2019 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 3B1FD1201D7 for ; Tue, 23 Apr 2019 23:53:20 -0700 (PDT) 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, 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=fastmailteam.com header.b=SyqkbldA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3RuGPQsy 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 lZoxO3asxG8a for ; Tue, 23 Apr 2019 23:53:18 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 445771201D3 for ; Tue, 23 Apr 2019 23:53:18 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0B5792222E for ; Wed, 24 Apr 2019 02:53:17 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 24 Apr 2019 02:53:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=IgToAhY mLKfIsqn5JEEbojiN5OXhtMgzfZuuUwpEhJI=; b=SyqkbldAJDyedx1AB63ZLYm VkJr6KATYa6pJl1GuRHAn4ouVDLSVFndu4S1UsyJb7+yj4qi4+QvA7tBurHe3zjJ KdQjjL8wRsVxFBpS5fRGQBDIzMACvHWvhAnDvr/5bdpB4vjIkhHM4osT9p6wfPBe WxXrEGP1jwC8SYyZMvyvrXAzlvbZcdsa9H0SI5ml3gVDmISFkb18pKBMWGE9PQpH MdB6i1exn8uu53QXAv/wfKyDhtww3aYs34a4GlAlEjeRw8AFZBK6dBH22GHW3Uvt 6aMvnriw1nxnAafR1eHEmqYuMwg10A6P1385r+v9BSi68F6ANB/h6w4Qts5OlrQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=IgToAh YmLKfIsqn5JEEbojiN5OXhtMgzfZuuUwpEhJI=; b=3RuGPQsyyMoESZGNAknZNa vAN0awPh6WZc6d+ND32h/GqhGhafFSvWDek32dPTgOfyWf8v2mYSFk+6Xwi2IiI9 At5IjzMv0YEOwkQ+K6hwo3MOsu6ySyhxQBQTF8kBsNZoImzABqU3YftPKezgLOzs puaVmHxWFZ/LcUu33/LmKOPwGcBdwKd5LUS7lSIiPmEHzWkzQrizle8UKEdHS+cy QNpMmPzgb+fMBHvqR7nZ28omqqrdsTG/ZwlUkNV+b3IP2p0KNLT3pDt0lZxc1BL+ /L/M6CgNz44SHt0gRqIhM+RvZPGZtu0sJIcn8cFr9TIcPJhZ2rO0nirWiMon6XXw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeelgdduuddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepghhithhhuhgsrdgtoh hmpdhivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5F512206AC; Wed, 24 Apr 2019 02:53:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-443-g918f9d3-fmstable-20190416v3 Mime-Version: 1.0 Message-Id: <5907ffaa-9656-4455-be4e-3c2783ae473d@beta.fastmail.com> In-Reply-To: References: Date: Wed, 24 Apr 2019 02:53:05 -0400 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=766d58d85cd448549c9c1ff64dddadbe Archived-At: Subject: Re: [calsify] =?utf-8?q?Call_for_adoption_of_subscription_upgrade_-_?= =?utf-8?q?please_reply_by_April_15?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 06:53:20 -0000 --766d58d85cd448549c9c1ff64dddadbe Content-Type: text/plain As there have been no objections, Mike - if you could please upload this document as draft-ietf-calext-subscription-upgrade-00 that would be great. Also - would you like to ask for a co-author? It's a pretty short document, so it might not need it. Cheers, Bron. On Tue, Mar 26, 2019, at 21:04, Bron Gondwana wrote: > Hi All, > > As discussed in the Prague meeting, this is a formal call for adoption of work on a mechanism for upgrading .ics calendar feeds to more efficient sychronisation mechanisms, based on the documents here: > > https://github.com/CalConnect/PUBLIC_DRAFTS/tree/master/subscription-upgrade > > and > > https://www.ietf.org/archive/id/draft-douglass-subscription-upgrade-03.txt > > It is expected that after adopting this work, we would aim for Q3 2019 as a milestone for working group last call, with a possibility of dealing with it earlier if the current documents process quickly! > > Please reply to this message by April 15th if you do not wish the working group to adopt this work. > > Regards, > > Bron.. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --766d58d85cd448549c9c1ff64dddadbe Content-Type: text/html Content-Transfer-Encoding: quoted-printable
As there have been no objections, Mike - if you could= please upload this document as draft-ietf-calext-subscription-upgrade-0= 0 that would be great.

Also - would you like to ask for a= co-author?  It's a pretty short document, so it might not need it.=

Cheers,
Bron.

On T= ue, Mar 26, 2019, at 21:04, Bron Gondwana wrote:
Hi All,

As discussed in the Prague meeting, this is a formal call for ado= ption of work on a mechanism for upgrading .ics calendar feeds to more e= fficient sychronisation mechanisms, based on the documents here:


and
=

=
It is expected that after adopting thi= s work, we would aim for Q3 2019 as a milestone for working group last c= all, with a possibility of dealing with it earlier if the current docume= nts process quickly!

Please reply to this message by Apri= l 15th if you do not wish the working group to adopt this work.

Regards,

Bron..

--
  Bron Gondwana, CEO, Fas= tMail Pty Ltd
  brong@fastmail= team.com


_________________________________= ______________
calsify mailing list
calsify@= ietf.org
https://www.ietf.org/mailman/listinfo/calsify
=


=
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


=
--766d58d85cd448549c9c1ff64dddadbe-- From nobody Sun Apr 28 02:58:39 2019 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 BB6EF12004F; Sun, 28 Apr 2019 02:58:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu via Datatracker To: Cc: draft-ietf-calext-eventpub-extensions.all@ietf.org, ietf@ietf.org, calsify@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Dan Romascanu Message-ID: <155644551863.20986.430303451434247977@ietfa.amsl.com> Date: Sun, 28 Apr 2019 02:58:38 -0700 Archived-At: Subject: [calsify] Genart last call review of draft-ietf-calext-eventpub-extensions-12 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2019 09:58:39 -0000 Reviewer: Dan Romascanu Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-calext-eventpub-extensions-12 Reviewer: Dan Romascanu Review Date: 2019-04-28 IETF LC End Date: 2019-04-29 IESG Telechat date: Not scheduled for a telechat Summary: This is a clear and detailed document updating RFC 5545 to include new properties and components to iCalendar. The document is READY for publication. I found a number of minor issues as well as a few nits which should be clarified and fixed in the further editing process. Major issues: Minor issues: 1. The document uses the term 'event' which has many meanings in many contexts. It would be useful to include or reference a definition of what is meant by 'event' in the context of iCalendar 2. The Abstract mentions that some of the updates are useful for social networking. I could not find any support for this claim in the text, with the exception mybe of mentioning 'social calendaring' in Section 3, which is also a vague term (or at least I do not know where it is defined or referred in the IETF). I suggest to either clarify, or drop these mentions. 3. In Section 3: > Using STRUCTURED-LOCATION, information about a number of interesting locations can be communicated, for example, address, region, country, Isn't it rather 'supplementary information about the location' than 'information about a number of interesting locations'? 4. Inconsistent use/non-use of keywords. In 5.2: 'This parameter MAY be specified on STRUCTURED-RESOURCE and provides a way to differentiate multiple properties.' while in 5.5: 'This property parameter can be specified on any property when the value is derived from some other property or properties.' I suggest to decide on a consistent use of either MAY or 'can'. Nits/editorial comments: 1. In Section 2: > This is a better match for the way [W3C.REC-xml-20081126] and JSON, [RFC8259] handles such structures and allows richer definitions. Fix grammar (plural) 2. In the use cases in Section 3, there are many optional parameters, and the use of conditional in the text may be more appropriate. For example in 3.1.1: 'In addition, there will be sponsorship information for sponsors of the event' better 'In addition, there may be sponsorship information for sponsors of the event' 3. In Section 3.1.2.1 s/A meeting may have 10 attendees non of which are co-located/A meeting may have 10 attendees, none of which are co-located/ 4. I do not know if Appendix B will be kept, but in case it will be, there is a typo in: > Fix PARTTYPE/PARTICPANT-TYPE inconsistency