From nobody Sat Aug 4 08:50:01 2018 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 F3E3E130E9F for ; Thu, 2 Aug 2018 18:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3TKQbKOCmdJ for ; Thu, 2 Aug 2018 18:58:33 -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 856CF130E60 for ; Thu, 2 Aug 2018 18:58:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5D79EB81715; Thu, 2 Aug 2018 18:58:33 -0700 (PDT) To: cyrus@daboo.name, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, daniel.migault@ericsson.com, d3e3e3@gmail.com, mozilla@kewis.ch X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: dpa-ietf@aegee.org, calsify@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180803015833.5D79EB81715@rfc-editor.org> Date: Thu, 2 Aug 2018 18:58:33 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Sat, 04 Aug 2018 08:50:00 -0700 Subject: [calsify] [Technical Errata Reported] RFC7986 (5449) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 01:58:36 -0000 The following errata report has been submitted for RFC7986, "New Properties for iCalendar". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5449 -------------------------------------- Type: Technical Reported by: Дилян Палаузов Section: 5.9 COLOR Pr Original Text ------------- Description: ...The value is a case-insensitive color name taken from the CSS3 set of names, defined in Section 4.3 of [W3C.REC-css3-color- 20110607]. Example: The following is an example of this property: COLOR:turquoise Corrected Text -------------- Description: ...The value is either a case-insensitive color name taken from the CSS3 set of names, defined in Section 4.3 of [W3C.REC- css3-color-20110607], or a lower-cased rgb() functional notation with absolute values specified in Section 4.2.1 of the same document. Examples: The following are examples of this property: COLOR:turquoise COLOR:rgb(61\,211\,68) Notes ----- draft-daboo-icalendar-extensions-07 removed the possibily to have RGB colours for COLOR. CSS3 included color names, that browsers at that time suppored, originating from X11's rgb.txt. The color names and values were randomly chosen. The minimal distance between the colors isn't consistent. One motivation for creating a color name were hardware capabilities - an argument which isn't valid for 20 years now. There is no reason to limit the number of possible values for COLOR. A user interface for choosing a named color has either to offer the user the possibility to choose from a pre-filled list of colors, which could clutter the interface, or let the user choose any RGB color and narrow it later to the closest color with CSS3 name. This narrowing isn't trivial and performing it seems like having an RFC running in itself. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7986 (draft-ietf-calext-extensions-05) -------------------------------------- Title : New Properties for iCalendar Publication Date : October 2016 Author(s) : C. Daboo Category : PROPOSED STANDARD Source : Calendaring Extensions Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Mon Aug 6 10:44:24 2018 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 C89F0130E5B for ; Mon, 6 Aug 2018 10:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_NONE=-0.0001, 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 X6jACRDwXFwT for ; Mon, 6 Aug 2018 10:44:15 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 B109B130DF0 for ; Mon, 6 Aug 2018 10:44:14 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id v9-v6so11289663ljk.4 for ; Mon, 06 Aug 2018 10:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YWkFupvxo6/TR8SurZxQwlcXIr9QgIPZ4sk+pfEYsjY=; b=IWS7+SDFAGSZ4+Jb2HGJw+wEBE1JrQ6+iR0pTk6Wr8PRjLB5DhBhGdMYrvk1pw81J2 mW+c5P4p4a1yYzUL92OotVwK4rHL4NJl8weeSyAUIq24FFPY7fEn4RHq7KqykpidDTRO Nd9MMfs/ZmLduNJWFX7YXSG/BelDYc1pMpqpTKpzksFTnUjs+XIyBJLXmYayC7N8hJBe IObd1hOmtt/28i5I/v592EfWEuuUkw13qgdMNjhqzOSgKBAIEqtL8BqnDYQA+KXFqcAV gPYOothor9W1l8qMrYa4CAxPBKvxeyDta5LP2O2wf5cGPFFPGJQpwpqvAHiiQ3vInPYw hQEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YWkFupvxo6/TR8SurZxQwlcXIr9QgIPZ4sk+pfEYsjY=; b=lZuuMOpZ0bFJSIBLWBmrFKVbtHB1G7Si/+DccZJQpvsWNeC3xtr/Tci6Zfin/QIFB9 YjA794RigDBH7qvfel+WO8//+N7TS5zue73MoEinnGY7p61I6BHiZZrsZu2N4feegy42 cNfN6pXPo36aXbyZcvJbHHxcOjURjnWbZyhSHLh5km+yWNjNaiDBF35aAANF60HJKoqz L1Qly28MP19vwg8zGT2YRrcFdJIg+EwRK5ZrDS/2zwoa0AIyPzTUyrvluFyobhM8shFB /Eq/Gb02DtmJVyk+YsVYkYp99T2xCMUOBtyq9VwwJhTX6wHMxJ8h8HRJFMmkOzy6H+I8 o4Cg== X-Gm-Message-State: AOUpUlGb8BRDhVLTVRzhLlK1AWJGsq1HYofUZe8CWPPBzWAksqtxDid6 8hIGbMa92l+58zPncyEzgZyh4xZUilFLzn7twX0Nqg== X-Google-Smtp-Source: AAOMgpdsyp3B7B76mX00H1yeHL1iTuQGpoReAXnxl94Abc1wCjIRMUD5qqkA/sRo4XQkqOB6ThBF0R1BbOW0MIegG3o= X-Received: by 2002:a2e:750d:: with SMTP id q13-v6mr12799753ljc.148.1533577453035; Mon, 06 Aug 2018 10:44:13 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 2002:a2e:5295:0:0:0:0:0 with HTTP; Mon, 6 Aug 2018 10:44:12 -0700 (PDT) In-Reply-To: <708d48bc-e213-1386-ff7b-23a476000774@gmail.com> References: <708d48bc-e213-1386-ff7b-23a476000774@gmail.com> From: Daniel Migault Date: Mon, 6 Aug 2018 13:44:12 -0400 X-Google-Sender-Auth: VqaRJUrP7IVaPn_Fc-6DruY2Pnc Message-ID: To: Michael Douglass Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary="00000000000052e7b40572c7d329" Archived-At: Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 17:44:21 -0000 --00000000000052e7b40572c7d329 Content-Type: text/plain; charset="UTF-8" Hi, Just catching up. Is the current version addressing all comments, or do we expect another version coming in the few next days ? Yours, Daniel On Wed, May 16, 2018 at 1:33 AM, Michael Douglass wrote: > Thank you for the comments - I've submitted a new draft to address these > and just realised I didn't address any of Robert's issues. > > I'll deal with those in day or so. > > On 5/15/18 23:07, Daniel Migault wrote: > > Hi, > > Please find some comments. These comments are indicative. > > Yours, > Daniel > > Abstract: > The header indicates that RFC 5545,and RFC 5546 are updated. This must be > also stated in the Abstract and in the introduction. > > Some text added > > > > 1. Introduction > > """ > Current practice is to embed this information as links in the > description or to add x-properties. > """ > > It is not clear to me how to use x-properties. Is it a notation ? In > addition, I am also wondering if this does not designate the LABEL > property. If that is correct, maybe that could be explicitly stated to > better understand section 5. > > I've changed the text to refer to non-standard properties and provided a > reference to the section in 5545. > > LABEL is a parameter used to provide a human-readable label for properties > - something like the alt attribute in html - so no - that is a different > usage > > > > The conventions needs to be updated according to RFC 8174 > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > [RFC2119]. > > Done > > > 3. Typed References > > """ > perhaps > for indexing or the presentation of additional related information > for the user. > """ > > Thought English is not my natural language, there might be a nit there. > > perhaps > for indexing or presentating the additional related information > to the user. > -- > > Changed to: > > perhaps for indexing or the > presenting of additional related information for the user. > > > > """ > Using STRUCTURED-LOCATION, information about a number of interesting > locations can be communicated, for example, parking, restaurants and > the venue. Servers and clients can retrieve the objects when storing > the event and use them to index by geographic location. > """ > > It is not clear from the text that the location information mentioned > above (e.g. address, region, country, postal code) that motivated the > STRUCTURED-LOCATION are part STRUCTURED-LOCATION. Thus I would also mention > them > > > Using STRUCTURED-LOCATION, information about a number of interesting > locations can be communicated, for example, address, region, country, > postal code as well as other informations such as the parking, restaurants > and > the venue. Servers and clients can retrieve the objects when storing > the event and use them to index by geographic location. > > Done > > --- > > 3.1.2. Itineraries > > > """ > The contact information can > provide detailed information about the booking agent, the airlines > and car hire companies and the hotel. > """ > > Looks to me that there is an additional "and". > > Removed > > > > > 5. New Property Parameters > > """ > This specification makes use of the LABEL property parameter which is > defined in [RFC7986] > """ > > My understanding is that the parameters described in this section apply to > the LABEL property.. It seems to me that this is the first time the LABEL > properties and associated parameters are mentioned in the document. In > other words, I have hard time finding where this section is introduced in > the previous sections such as the introduction. If I am correct, maybe that > could be clarified in the introduction. > > LABEL is a parameter - it turns up in the ABNF for a number of the > properties defined here. The phrase "property parameter" was pulled out of > that spec - from 5545 as well. "LABEL parameter" is a little clearer I > think. I'll try that. > > > It seems to me that the document is structured with a kind of bottom - up > approach. parameters < properties < components. Thus I am wondering if > there are any reasons for not having the Calendar Components at the very > end instead of at the beginning. > > I am also wondering if that would not be more easy to read the document > with Participant Types and Resource Types listed within their respective > Properties. > > I see what you mean now. Makes sense. > > > > > On Tue, May 15, 2018 at 1:12 PM, Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> Hi, >> >> draft-ietf-calext-eventpub-extensions [1] is already on WGLC. We would >> like to sufficient reviews to move the document to the IESG. If you have >> not yet commented the document, please provide your feedbacks by May 29 so >> we can move the document forward. >> >> Yours, >> Calext co-chairs. >> >> >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub- >> extensions/ >> > > > > _______________________________________________ > calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > --00000000000052e7b40572c7d329 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
Just catching up. Is the current v= ersion addressing all comments, or do we expect another version coming in t= he few next days ?

Yours,
Daniel

On W= ed, May 16, 2018 at 1:33 AM, Michael Douglass <mikeadouglass@gmail.c= om> wrote:
=20 =20 =20

Thank you for the comments - I've submitted a new draft to address these and just realised I didn't address any of Robert= 9;s issues.

I'll deal with those in day or so.


On 5/15/18 23:07, Da= niel Migault wrote:
Hi,

Please find some comments. These comments are indicative.

Yours,
Daniel

Abstract:
The header indicates that RFC 5545,and RFC 5546 are updated. This must be also stated in the Abstract and in the introduction.
Some text added


1.=C2=A0 Introduction

"""
Current practice is to embed this information as links in the
=C2=A0=C2=A0 description or to add x-properties.
"""

It is not clear to me how to use x-properties. Is it a notation ? In addition, I am also wondering if this does not designate the LABEL property. If that is correct, maybe that could be explicitly stated to better understand section 5.
 I've changed the text to refer to non-standard properties and provided a reference to the section in 5545.

LABEL is a parameter used to provide a human-readable label for properties - something like the alt attribute in html - so no - that is a different usage

    

      

        


          

          The conventions needs to be updated according to RFC 8174

          

          =C2=A0=C2=A0 The key words "MUST", "MUST NOT"=
, "REQUIRED", "SHALL",
          "SHALL NOT",

          =C2=A0=C2=A0 "SHOULD", "SHOULD NOT", "RE=
COMMENDED", "NOT RECOMMENDED",
          "MAY", and

          =C2=A0=C2=A0 "OPTIONAL" in this document are to be inte=
rpreted as
          described in

          =C2=A0=C2=A0 [RFC2119].

        

      

    

    Done

    

      

        


          3.=C2=A0 Typed References

          

          """

          =C2=A0=C2=A0 perhaps

          =C2=A0=C2=A0 for indexing or the presentation of additional relat=
ed
          information

          =C2=A0=C2=A0 for the user.

          """

          

          Thought English is not my natural language, there might be a
          nit there. 

          

          =C2=A0=C2=A0 perhaps

          =C2=A0=C2=A0 for indexing or presentating the additional related
          information

          =C2=A0=C2=A0 to the user.

          --

        

      

    

    Changed to:

    

    perhaps for indexing or the

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 presenting of additional rel=
ated information for the user.

    

      

        


          

          """

          Using STRUCTURED-LOCATION, information about a number of
          interesting

          =C2=A0=C2=A0 locations can be communicated, for example, parking,
          restaurants and

          =C2=A0=C2=A0 the venue.=C2=A0 Servers and clients can retrieve th=
e objects
          when storing

          =C2=A0=C2=A0 the event and use them to index by geographic locati=
on.

          """

          

          It is not clear from the text that the location information
          mentioned above (e.g. address, region, country, postal code)
          that motivated the STRUCTURED-LOCATION are part
          STRUCTURED-LOCATION. Thus I would also mention them 

          

          

          Using STRUCTURED-LOCATION, information about a number of
          interesting

          =C2=A0=C2=A0 locations can be communicated, for example, address,
          region, country, postal code as well as other informations
          such as the parking, restaurants and

          =C2=A0=C2=A0 the venue.=C2=A0 Servers and clients can retrieve th=
e objects
          when storing

          =C2=A0=C2=A0 the event and use them to index by geographic locati=
on.

          

        

      

    

    Done

    

      

        
---

          

          3.1.2.=C2=A0 Itineraries

          

          

          """

          The contact information can

          =C2=A0=C2=A0 provide detailed information about the booking agent=
, the
          airlines

          =C2=A0=C2=A0 and car hire companies and the hotel.

          """

          

          Looks to me that there is an additional "and".

        

      

    

    Removed

    

      

        


          

          

          5.=C2=A0 New Property Parameters

          

          """

          =C2=A0=C2=A0 This specification makes use of the LABEL property
          parameter which is

          =C2=A0=C2=A0 defined in [RFC7986]

          """

          

          My understanding is that the parameters described in this
          section apply to the LABEL property.. It seems to me that this
          is the first time the LABEL properties and associated
          parameters are mentioned in the document. In other words, I
          have hard time finding where this section is introduced=C2=A0 in
          the previous sections such as the introduction. If I am
          correct, maybe that could be clarified in the introduction. 

        

      

    

    LABEL is a parameter - it turns up in the ABNF for a number of the
    properties defined here. The phrase "property parameter" was =
pulled
    out of that spec - from 5545 as well. "LABEL parameter" is a =
little
    clearer I think. I'll try that.

    

      

        


          It seems to me that the document is structured with a kind of
          bottom - up approach. parameters < properties <
          components. Thus I am wondering if there are any reasons for
          not having the Calendar Components at the very end instead of
          at the beginning.

        

      

    

    

      

        
I am also wondering if that would not be more easy to read
          the document with Participant Types and Resource Types listed
          within their respective Properties. 

          

        

      

    

    I see what you mean now. Makes sense.

    

      

        


          

        

      

      


        
On Tue, May 15, 2018 at 1:12 PM, Daniel
          Migault <daniel.migault@ericsson.com>
          wrote:

          

            

              
Hi, 

              

              


              

              
draft-ietf-calext-eventpub-extensions [1] is
                already on WGLC. We would like to sufficient reviews to
                move the document to the IESG. If you have not yet
                commented the document, please provide your feedbacks by
                May 29 so we can move the document forward. 

              

              


              

              
Yours, 

              

              
Calext co-chairs.

              

              


              

              


              

              


              

              
            

          

        

        

      

      

      

      

      
___________________________________=
____________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/m=
ailman/listinfo/calsify


    

    

  



_______________________________________________

calsify mailing list

calsify@ietf.org

https://www.ietf.org/mailman/listinfo/calsify<=
br>




--00000000000052e7b40572c7d329--


From nobody Mon Aug  6 10:58:41 2018
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 A52BB130E44 for ; Mon,  6 Aug 2018 10:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 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_NONE=-0.0001, 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 SPcpx0bKoBcH for ; Mon,  6 Aug 2018 10:58:32 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 54BEE130E77 for ; Mon,  6 Aug 2018 10:58:32 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id j19-v6so11305545ljc.7 for ; Mon, 06 Aug 2018 10:58:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=d2vaPRnFKZRLKTzP/Vn4/rAKHmoClDiAzITBOHqbrbM=; b=Tafa/J6rF7hg39BjzmElstUwyE8mU2vPCxBqVjO2g5IkefwF6t2D6kKohmJFOS/GkZ OvEA+JMK0OgOVVSWRCj1XvDV0wWpm28Z02A67/8y/pd0x9794Ya7MzvcImOL1R1JKB2w j6SNm58lXnhNDQGduKgf4B4C+xefZ7aEFdSAaup8YLueSslmtHSHQmpMlKuxm0KRhaKF 23+aUgRcvoUOsXxOnewfHetNBe9DPtGWhoIcy2PSYBw1JVVr8KYmsmjhvzm6tdDIiWHT BlXYYPWlQBf8MwhGwrwlIxrV+m7IH6zfdIdrg8zgb/t7+s15DgiWqad1qse1pld0BEqi irNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=d2vaPRnFKZRLKTzP/Vn4/rAKHmoClDiAzITBOHqbrbM=; b=teI+kOARkVaDlzinRFKVnRO0WWOD6vs/D6kEeEC6vwAkNYZcYIV0DMxj6zxXSlocv2 wzV//Tj6vMtt/QJ4EVJ4WdfKPq+DFzsEhW9vkTnpuztZyKISI1KVPW3LQyrnZVlG5iYA 28FBWCzhQKvsPY8tvUSUSIPywiZwUTHnddhyqLy7LcN3jnVSubJTpZyzXExZVwJnAGyF Q/gp/r6HJL+3NcEMV6AzacK/VjHC0hb4DfWrI7Fy98UXLNtVZJ2Pnw8izjXIXIA7FlKd RvhyNWuNngP89T5pdPeMPzcglbUGTQHtcWbZ7ShccoUrQxtt+PwTLSkjrHIJd0AP9l3X aS6w==
X-Gm-Message-State: AOUpUlFUjwhOihInut/ZgwpD0XtYw54OdxNo6wpyI5skl8d2gSUFGNlP 3KSNIwDoJk74ZwB2cWLBm/0uAWtjvZrkWeePZVY=
X-Google-Smtp-Source: AAOMgpfawwGtR7FhSmo87qVxdNYfOJOkVjwX5gtaraQMLQiE3cJlfoXYYlqH671Sh6k4l6zLmLsEY7pcsFuucotZ+88=
X-Received: by 2002:a2e:1d50:: with SMTP id d77-v6mr13210271ljd.104.1533578310498;  Mon, 06 Aug 2018 10:58:30 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 2002:a2e:5295:0:0:0:0:0 with HTTP; Mon, 6 Aug 2018 10:58:29 -0700 (PDT)
In-Reply-To: 
References:   <708d48bc-e213-1386-ff7b-23a476000774@gmail.com> 
From: Daniel Migault 
Date: Mon, 6 Aug 2018 13:58:29 -0400
X-Google-Sender-Auth: RIwTbowPVRYMLYslJNMd4jezlds
Message-ID: 
To: Michael Douglass 
Cc: calsify@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006ec60a0572c80637"
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Aug 2018 17:58:36 -0000

--0000000000006ec60a0572c80637
Content-Type: text/plain; charset="UTF-8"

In order to get a rough idea of the consensus to move that draft forward to
the IESG, I would also appreciate your support on approving the document.
Please let us know if you believe the document is ready to be moved
forward.

If you have implemented it, it would also be much appreciate to write the
review.

Yours,
Daniel

On Mon, Aug 6, 2018 at 1:44 PM, Daniel Migault 
wrote:

> Hi,
> Just catching up. Is the current version addressing all comments, or do we
> expect another version coming in the few next days ?
>
> Yours,
> Daniel
>
> On Wed, May 16, 2018 at 1:33 AM, Michael Douglass  > wrote:
>
>> Thank you for the comments - I've submitted a new draft to address these
>> and just realised I didn't address any of Robert's issues.
>>
>> I'll deal with those in day or so.
>>
>> On 5/15/18 23:07, Daniel Migault wrote:
>>
>> Hi,
>>
>> Please find some comments. These comments are indicative.
>>
>> Yours,
>> Daniel
>>
>> Abstract:
>> The header indicates that RFC 5545,and RFC 5546 are updated. This must be
>> also stated in the Abstract and in the introduction.
>>
>> Some text added
>>
>>
>>
>> 1.  Introduction
>>
>> """
>> Current practice is to embed this information as links in the
>>    description or to add x-properties.
>> """
>>
>> It is not clear to me how to use x-properties. Is it a notation ? In
>> addition, I am also wondering if this does not designate the LABEL
>> property. If that is correct, maybe that could be explicitly stated to
>> better understand section 5.
>>
>> I've changed the text to refer to non-standard properties and provided a
>> reference to the section in 5545.
>>
>> LABEL is a parameter used to provide a human-readable label for
>> properties - something like the alt attribute in html - so no - that is a
>> different usage
>>
>>
>>
>> The conventions needs to be updated according to RFC 8174
>>
>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>    "OPTIONAL" in this document are to be interpreted as described in
>>    [RFC2119].
>>
>> Done
>>
>>
>> 3.  Typed References
>>
>> """
>>    perhaps
>>    for indexing or the presentation of additional related information
>>    for the user.
>> """
>>
>> Thought English is not my natural language, there might be a nit there.
>>
>>    perhaps
>>    for indexing or presentating the additional related information
>>    to the user.
>> --
>>
>> Changed to:
>>
>> perhaps for indexing or the
>>         presenting of additional related information for the user.
>>
>>
>>
>> """
>> Using STRUCTURED-LOCATION, information about a number of interesting
>>    locations can be communicated, for example, parking, restaurants and
>>    the venue.  Servers and clients can retrieve the objects when storing
>>    the event and use them to index by geographic location.
>> """
>>
>> It is not clear from the text that the location information mentioned
>> above (e.g. address, region, country, postal code) that motivated the
>> STRUCTURED-LOCATION are part STRUCTURED-LOCATION. Thus I would also mention
>> them
>>
>>
>> Using STRUCTURED-LOCATION, information about a number of interesting
>>    locations can be communicated, for example, address, region, country,
>> postal code as well as other informations such as the parking, restaurants
>> and
>>    the venue.  Servers and clients can retrieve the objects when storing
>>    the event and use them to index by geographic location.
>>
>> Done
>>
>> ---
>>
>> 3.1.2.  Itineraries
>>
>>
>> """
>> The contact information can
>>    provide detailed information about the booking agent, the airlines
>>    and car hire companies and the hotel.
>> """
>>
>> Looks to me that there is an additional "and".
>>
>> Removed
>>
>>
>>
>>
>> 5.  New Property Parameters
>>
>> """
>>    This specification makes use of the LABEL property parameter which is
>>    defined in [RFC7986]
>> """
>>
>> My understanding is that the parameters described in this section apply
>> to the LABEL property.. It seems to me that this is the first time the
>> LABEL properties and associated parameters are mentioned in the document.
>> In other words, I have hard time finding where this section is introduced
>> in the previous sections such as the introduction. If I am correct, maybe
>> that could be clarified in the introduction.
>>
>> LABEL is a parameter - it turns up in the ABNF for a number of the
>> properties defined here. The phrase "property parameter" was pulled out of
>> that spec - from 5545 as well. "LABEL parameter" is a little clearer I
>> think. I'll try that.
>>
>>
>> It seems to me that the document is structured with a kind of bottom - up
>> approach. parameters < properties < components. Thus I am wondering if
>> there are any reasons for not having the Calendar Components at the very
>> end instead of at the beginning.
>>
>> I am also wondering if that would not be more easy to read the document
>> with Participant Types and Resource Types listed within their respective
>> Properties.
>>
>> I see what you mean now. Makes sense.
>>
>>
>>
>>
>> On Tue, May 15, 2018 at 1:12 PM, Daniel Migault <
>> daniel.migault@ericsson.com> wrote:
>>
>>> Hi,
>>>
>>> draft-ietf-calext-eventpub-extensions [1] is already on WGLC. We would
>>> like to sufficient reviews to move the document to the IESG. If you have
>>> not yet commented the document, please provide your feedbacks by May 29 so
>>> we can move the document forward.
>>>
>>> Yours,
>>> Calext co-chairs.
>>>
>>>
>>>
>>> [1] https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-
>>> extensions/
>>>
>>
>>
>>
>> _______________________________________________
>> calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify
>>
>>
>>
>> _______________________________________________
>> calsify mailing list
>> calsify@ietf.org
>> https://www.ietf.org/mailman/listinfo/calsify
>>
>>
>

--0000000000006ec60a0572c80637
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


In order to get a rough idea of the consensus to move=
 that draft forward to the IESG, I would also appreciate your support on ap=
proving the document. Please let us know if you believe the document is rea=
dy to be moved forward. 

If you have implement=
ed it, it would also be much appreciate to write the review. 

Yours, 
Daniel
 

On Mon, Aug 6, 2018 at 1:44 PM,=
 Daniel Migault <daniel.migault@ericsson.com> wrot=
e:
Hi, 
Just catching up. Is the current version addressing all comments, or do =
we expect another version coming in the few next days ?

Yours, 
Daniel

On=
 Wed, May 16, 2018 at 1:33 AM, Michael Douglass <mikeadouglass@gmail=
.com> wrote:

 =20
   =20
 =20
  

    
Thank you for the comments - I've submitted a new draft to
      address these and just realised I didn't address any of Robert=
9;s
      issues.

    
I'll deal with those in day or so.

    

    

    
On 5/15/18 23:07, Daniel Migault wrote:

    

    

      

        
Hi, 

        

        


        

        
Please find some comments. These comments are indicative.
        


        

        
Yours, 

        

        
Daniel

        


        

        
Abstract:

        
The header indicates that RFC 5545,and RFC 5546 are
          updated. This must be also stated in the Abstract and in the
          introduction. 

        

      

    

    Some text added

    

      

        


        

        


        

        
1.=C2=A0 Introduction

          

          """

          Current practice is to embed this information as links in the

          =C2=A0=C2=A0 description or to add x-properties.

          """

          

          It is not clear to me how to use x-properties. Is it a
          notation ? In addition, I am also wondering if this does not
          designate the LABEL property. If that is correct, maybe that
          could be explicitly stated to better understand section 5.

        

      

    

    I've changed the text to refer to non-standard properties and
    provided a reference to the section in 5545. 

    

    LABEL is a parameter used to provide a human-readable label for
    properties - something like the alt attribute in html - so no - that
    is a different usage

    

    

      

        


          

          The conventions needs to be updated according to RFC 8174

          

          =C2=A0=C2=A0 The key words "MUST", "MUST NOT"=
, "REQUIRED", "SHALL",
          "SHALL NOT",

          =C2=A0=C2=A0 "SHOULD", "SHOULD NOT", "RE=
COMMENDED", "NOT RECOMMENDED",
          "MAY", and

          =C2=A0=C2=A0 "OPTIONAL" in this document are to be inte=
rpreted as
          described in

          =C2=A0=C2=A0 [RFC2119].

        

      

    

    Done

    

      

        


          3.=C2=A0 Typed References

          

          """

          =C2=A0=C2=A0 perhaps

          =C2=A0=C2=A0 for indexing or the presentation of additional relat=
ed
          information

          =C2=A0=C2=A0 for the user.

          """

          

          Thought English is not my natural language, there might be a
          nit there. 

          

          =C2=A0=C2=A0 perhaps

          =C2=A0=C2=A0 for indexing or presentating the additional related
          information

          =C2=A0=C2=A0 to the user.

          --

        

      

    

    Changed to:

    

    perhaps for indexing or the

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 presenting of additional rel=
ated information for the user.

    

      

        


          

          """

          Using STRUCTURED-LOCATION, information about a number of
          interesting

          =C2=A0=C2=A0 locations can be communicated, for example, parking,
          restaurants and

          =C2=A0=C2=A0 the venue.=C2=A0 Servers and clients can retrieve th=
e objects
          when storing

          =C2=A0=C2=A0 the event and use them to index by geographic locati=
on.

          """

          

          It is not clear from the text that the location information
          mentioned above (e.g. address, region, country, postal code)
          that motivated the STRUCTURED-LOCATION are part
          STRUCTURED-LOCATION. Thus I would also mention them 

          

          

          Using STRUCTURED-LOCATION, information about a number of
          interesting

          =C2=A0=C2=A0 locations can be communicated, for example, address,
          region, country, postal code as well as other informations
          such as the parking, restaurants and

          =C2=A0=C2=A0 the venue.=C2=A0 Servers and clients can retrieve th=
e objects
          when storing

          =C2=A0=C2=A0 the event and use them to index by geographic locati=
on.

          

        

      

    

    Done

    

      

        
---

          

          3.1.2.=C2=A0 Itineraries

          

          

          """

          The contact information can

          =C2=A0=C2=A0 provide detailed information about the booking agent=
, the
          airlines

          =C2=A0=C2=A0 and car hire companies and the hotel.

          """

          

          Looks to me that there is an additional "and".

        

      

    

    Removed

    

      

        


          

          

          5.=C2=A0 New Property Parameters

          

          """

          =C2=A0=C2=A0 This specification makes use of the LABEL property
          parameter which is

          =C2=A0=C2=A0 defined in [RFC7986]

          """

          

          My understanding is that the parameters described in this
          section apply to the LABEL property.. It seems to me that this
          is the first time the LABEL properties and associated
          parameters are mentioned in the document. In other words, I
          have hard time finding where this section is introduced=C2=A0 in
          the previous sections such as the introduction. If I am
          correct, maybe that could be clarified in the introduction. 

        

      

    

    LABEL is a parameter - it turns up in the ABNF for a number of the
    properties defined here. The phrase "property parameter" was =
pulled
    out of that spec - from 5545 as well. "LABEL parameter" is a =
little
    clearer I think. I'll try that.

    

      

        


          It seems to me that the document is structured with a kind of
          bottom - up approach. parameters < properties <
          components. Thus I am wondering if there are any reasons for
          not having the Calendar Components at the very end instead of
          at the beginning.

        

      

    

    

      

        
I am also wondering if that would not be more easy to read
          the document with Participant Types and Resource Types listed
          within their respective Properties. 

          

        

      

    

    I see what you mean now. Makes sense.

    

      

        


          

        

      

      


        
On Tue, May 15, 2018 at 1:12 PM, Daniel
          Migault <daniel.migault@ericsson.com>
          wrote:

          

            

              
Hi, 

              

              


              

              
draft-ietf-calext-eventpub-extensions [1] is
                already on WGLC. We would like to sufficient reviews to
                move the document to the IESG. If you have not yet
                commented the document, please provide your feedbacks by
                May 29 so we can move the document forward. 

              

              


              

              
Yours, 

              

              
Calext co-chairs.

              

              


              

              


              

              


              

              
            

          

        

        

      

      

      

      

      
______________________________________________=
_
calsify mailing list
calsify@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/calsify


    

    

  



_______________________________________________

calsify mailing list

calsify@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/calsify<=
br>







--0000000000006ec60a0572c80637--


From nobody Mon Aug  6 11:52:53 2018
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 DF166130F02 for ; Mon,  6 Aug 2018 11:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 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_NONE=-0.0001, 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 bnKkMSCu90ok for ; Mon,  6 Aug 2018 11:52:48 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 4C7A4130EE4 for ; Mon,  6 Aug 2018 11:52:48 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id n96-v6so9835768lfi.1 for ; Mon, 06 Aug 2018 11:52:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XPxy24YBYeM5U6VffgJI9bl9DAh8xYZHTMtOe5ISazM=; b=fEd9WX0QDmOavr10stlkmR4f1H99dzkqCsWVMinZnrK+j3L0Fbygv77twcPrfazY3W JxH2kpbiOaJ7Kts+/i1yKWgH9YjSF3Izf531KSExoWMbGdGcuh0raoJYshuTRMc9YFXq 8uubXxVuURTD1o896KjlbDiG8ROciVT9yoBLz0kanrPG9GLM+odG3z6XH08gBpPjZzCm KjzNEboZrGYJomgUi/qBC5ION8rrc4MwsGeHzbeLFeAlqYinwo2yLtdE9rsF0FuAl5Hi ZwmM0WFTgBI0M7XRgNpXbAna/5MD9kOoPK13MsOH5YYclOagnWANyH9yvACklZbVQICf dYzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XPxy24YBYeM5U6VffgJI9bl9DAh8xYZHTMtOe5ISazM=; b=mx/FkDo4SAY3WZvTNERUiq2zx8RXiY+OEUNzAtxoZJgUwtHk4ltfDrv0pReBWGWr+N HjBTcZGK0fVEam9VfgJsje/GQGgqM71juj9/UStMrIWDw1HoTvKURf8y17HJJHYwGTEK 8wjxR+C7JobXlpPtmsJ9AjfW3HBi/u0BEH1i75yfOvGWcacjp+yBdoRaHVBl9hHHh+M8 qZYsAvWd0aX5AUkIwSU2nd3A2McaTzDy/4pmyrn0jFGA+8KL8TqJi9lU3MbHc1BTQrLo wu1Vwq7LvCGA6WAnRDCISjhkHoF3ypMhpAPxe+rhzNFQ6OP7DirVLoI5OPqTpYoqotIX bKiA==
X-Gm-Message-State: AOUpUlHvVCNlo3oB+p1ynhVwxyRENVifrsubDtgrVkWOG3JWuZLxGGR1 mTZNq6gzgMSMA90ZR7RTUWa6rZ9ngtSckmNM3AV/e7al
X-Google-Smtp-Source: AAOMgpdL0aj0CamghmOcd8Md6przESbmi8zhoJKsXI4f8VmZVWAsJSMRu4FjRN/vNQfgyEuoMX5lvvyxJXV04pROQxY=
X-Received: by 2002:a19:e40d:: with SMTP id b13-v6mr12806633lfh.141.1533581566490;  Mon, 06 Aug 2018 11:52:46 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 2002:a2e:5295:0:0:0:0:0 with HTTP; Mon, 6 Aug 2018 11:52:45 -0700 (PDT)
In-Reply-To: 
References:   <708d48bc-e213-1386-ff7b-23a476000774@gmail.com>  
From: Daniel Migault 
Date: Mon, 6 Aug 2018 14:52:45 -0400
X-Google-Sender-Auth: 9F1_pQWfJph_yVPIlRTgbiEvhUw
Message-ID: 
To: Michael Douglass 
Cc: calsify@ietf.org
Content-Type: multipart/alternative; boundary="000000000000813d0e0572c8c801"
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Aug 2018 18:52:52 -0000

--000000000000813d0e0572c8c801
Content-Type: text/plain; charset="UTF-8"

Hi,

Initiating the shepherd write-up here are my additional comments:

1) running the nits raises some minor issues so please remove the '[' and
']' in the abstract.

OLD:

   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.

NEW:

   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.

2)

I do not see the following reference mentioned in the text. Maybe it could
be removed. If you prefer to keep it, maybe informational may be the right
category for it.

   [W3C.REC-xml-20060816]
              Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
              Edition)", World Wide Web Consortium Recommendation REC-
              xml-20060816, August 2006,
              .


3) I do not see the update of RFC 5546 being discussed in the introduction.
Could you please add some text ?


4) IANA section,

I suggest to add the URL to the IANA registry as an informative reference.
https://www.iana.org/assignments/icalendar/icalendar.xhtml#properties


section 12.1.{1,2,3} I would remove the term "Registration" to make sure
the title of the section match the registry. Similarly, I would replace
Property by Properties to match the registries.

Yours,
Daniel

On Mon, Aug 6, 2018 at 1:58 PM, Daniel Migault 
wrote:

> In order to get a rough idea of the consensus to move that draft forward
> to the IESG, I would also appreciate your support on approving the
> document. Please let us know if you believe the document is ready to be
> moved forward.
>
> If you have implemented it, it would also be much appreciate to write the
> review.
>
> Yours,
> Daniel
>
> On Mon, Aug 6, 2018 at 1:44 PM, Daniel Migault <
> daniel.migault@ericsson.com> wrote:
>
>> Hi,
>> Just catching up. Is the current version addressing all comments, or do
>> we expect another version coming in the few next days ?
>>
>> Yours,
>> Daniel
>>
>> On Wed, May 16, 2018 at 1:33 AM, Michael Douglass <
>> mikeadouglass@gmail.com> wrote:
>>
>>> Thank you for the comments - I've submitted a new draft to address these
>>> and just realised I didn't address any of Robert's issues.
>>>
>>> I'll deal with those in day or so.
>>>
>>> On 5/15/18 23:07, Daniel Migault wrote:
>>>
>>> Hi,
>>>
>>> Please find some comments. These comments are indicative.
>>>
>>> Yours,
>>> Daniel
>>>
>>> Abstract:
>>> The header indicates that RFC 5545,and RFC 5546 are updated. This must
>>> be also stated in the Abstract and in the introduction.
>>>
>>> Some text added
>>>
>>>
>>>
>>> 1.  Introduction
>>>
>>> """
>>> Current practice is to embed this information as links in the
>>>    description or to add x-properties.
>>> """
>>>
>>> It is not clear to me how to use x-properties. Is it a notation ? In
>>> addition, I am also wondering if this does not designate the LABEL
>>> property. If that is correct, maybe that could be explicitly stated to
>>> better understand section 5.
>>>
>>> I've changed the text to refer to non-standard properties and provided a
>>> reference to the section in 5545.
>>>
>>> LABEL is a parameter used to provide a human-readable label for
>>> properties - something like the alt attribute in html - so no - that is a
>>> different usage
>>>
>>>
>>>
>>> The conventions needs to be updated according to RFC 8174
>>>
>>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>>    "OPTIONAL" in this document are to be interpreted as described in
>>>    [RFC2119].
>>>
>>> Done
>>>
>>>
>>> 3.  Typed References
>>>
>>> """
>>>    perhaps
>>>    for indexing or the presentation of additional related information
>>>    for the user.
>>> """
>>>
>>> Thought English is not my natural language, there might be a nit there.
>>>
>>>    perhaps
>>>    for indexing or presentating the additional related information
>>>    to the user.
>>> --
>>>
>>> Changed to:
>>>
>>> perhaps for indexing or the
>>>         presenting of additional related information for the user.
>>>
>>>
>>>
>>> """
>>> Using STRUCTURED-LOCATION, information about a number of interesting
>>>    locations can be communicated, for example, parking, restaurants and
>>>    the venue.  Servers and clients can retrieve the objects when storing
>>>    the event and use them to index by geographic location.
>>> """
>>>
>>> It is not clear from the text that the location information mentioned
>>> above (e.g. address, region, country, postal code) that motivated the
>>> STRUCTURED-LOCATION are part STRUCTURED-LOCATION. Thus I would also mention
>>> them
>>>
>>>
>>> Using STRUCTURED-LOCATION, information about a number of interesting
>>>    locations can be communicated, for example, address, region, country,
>>> postal code as well as other informations such as the parking, restaurants
>>> and
>>>    the venue.  Servers and clients can retrieve the objects when storing
>>>    the event and use them to index by geographic location.
>>>
>>> Done
>>>
>>> ---
>>>
>>> 3.1.2.  Itineraries
>>>
>>>
>>> """
>>> The contact information can
>>>    provide detailed information about the booking agent, the airlines
>>>    and car hire companies and the hotel.
>>> """
>>>
>>> Looks to me that there is an additional "and".
>>>
>>> Removed
>>>
>>>
>>>
>>>
>>> 5.  New Property Parameters
>>>
>>> """
>>>    This specification makes use of the LABEL property parameter which is
>>>    defined in [RFC7986]
>>> """
>>>
>>> My understanding is that the parameters described in this section apply
>>> to the LABEL property.. It seems to me that this is the first time the
>>> LABEL properties and associated parameters are mentioned in the document.
>>> In other words, I have hard time finding where this section is introduced
>>> in the previous sections such as the introduction. If I am correct, maybe
>>> that could be clarified in the introduction.
>>>
>>> LABEL is a parameter - it turns up in the ABNF for a number of the
>>> properties defined here. The phrase "property parameter" was pulled out of
>>> that spec - from 5545 as well. "LABEL parameter" is a little clearer I
>>> think. I'll try that.
>>>
>>>
>>> It seems to me that the document is structured with a kind of bottom -
>>> up approach. parameters < properties < components. Thus I am wondering if
>>> there are any reasons for not having the Calendar Components at the very
>>> end instead of at the beginning.
>>>
>>> I am also wondering if that would not be more easy to read the document
>>> with Participant Types and Resource Types listed within their respective
>>> Properties.
>>>
>>> I see what you mean now. Makes sense.
>>>
>>>
>>>
>>>
>>> On Tue, May 15, 2018 at 1:12 PM, Daniel Migault <
>>> daniel.migault@ericsson.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> draft-ietf-calext-eventpub-extensions [1] is already on WGLC. We would
>>>> like to sufficient reviews to move the document to the IESG. If you have
>>>> not yet commented the document, please provide your feedbacks by May 29 so
>>>> we can move the document forward.
>>>>
>>>> Yours,
>>>> Calext co-chairs.
>>>>
>>>>
>>>>
>>>> [1] https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-
>>>> extensions/
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify
>>>
>>>
>>>
>>> _______________________________________________
>>> calsify mailing list
>>> calsify@ietf.org
>>> https://www.ietf.org/mailman/listinfo/calsify
>>>
>>>
>>
>

--000000000000813d0e0572c8c801
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi, 

Initiating the shep=
herd write-up here are my additional comments:

1) =
running the nits raises some minor issues so please remove the '[' =
and ']' in the abstract.

OLD:

=C2=A0=C2=A0 This speci=
fication updates [RFC5545]=C2=A0 and [RFC5546] by introducing a
=C2=A0=
=C2=A0 number of new iCalendar properties and components which are of
=
=C2=A0=C2=A0 particular use for event publishers and in social networking.<=
br>
NEW:

=C2=A0=C2=A0 This specification updates RFC5545 and RFC5=
546 by introducing a
=C2=A0=C2=A0 number of new iCalendar properties and=
 components which are of
=C2=A0=C2=A0 particular use for event publisher=
s and in social networking.

2)

I do not see the following ref=
erence mentioned in the text. Maybe it could be removed. If you prefer to k=
eep it, maybe informational may be the right category for it.

=C2=A0=
=C2=A0 [W3C.REC-xml-20060816]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Bray, T., Paoli, J., Sperberg-McQueen,=
 M., Maler, E., and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 F. Yergeau, "Extensible Markup Language (X=
ML) 1.0 (Fourth
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 Edition)", World Wide Web Consortium Recommen=
dation REC-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 xml-20060816, August 2006,
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <http://www.w3.org/TR/2006/REC-xml-20=
060816>.


3) I do not see the update of RFC 5546 being dis=
cussed in the introduction. Could you please add some text ?
=C2=A0
<=
br>4) IANA section,

I suggest to add the URL to the IANA registry as=
 an informative reference.
https://www.iana.org/assignments/icale=
ndar/icalendar.xhtml#properties


section 12.1.{1,2,3} I would=
 remove the term "Registration" to make sure the title of the sec=
tion match the registry. Similarly, I would replace Property by Properties =
to match the registries.

Yours, 
Daniel
=


On Mo=
n, Aug 6, 2018 at 1:58 PM, Daniel Migault <daniel.migault@ericss=
on.com> wrote:
In order to get a rough idea of the consensus to move that draft =
forward to the IESG, I would also appreciate your support on approving the =
document. Please let us know if you believe the document is ready to be mov=
ed forward. 

If you have implemented it, it wo=
uld also be much appreciate to write the review. 

<=
div>Yours, 
Daniel
 

On =
Mon, Aug 6, 2018 at 1:44 PM, Daniel Migault <daniel.migault@er=
icsson.com> wrote:
Hi, 
Just catching up. Is the current version a=
ddressing all comments, or do we expect another version coming in the few n=
ext days ?

Yours, 
Daniel
<=
/div>

On =
Wed, May 16, 2018 at 1:33 AM, Michael Douglass <mikeadouglass@gmail.=
com> wrote:

 =20
   =20
 =20
  

    
Thank you for the comments - I've submitted a new draft to
      address these and just realised I didn't address any of Robert=
9;s
      issues.

    
I'll deal with those in day or so.

    

    

    
On 5/15/18 23:07, Daniel Migault wrote:

    

    

      

        
Hi, 

        

        


        

        
Please find some comments. These comments are indicative.
        


        

        
Yours, 

        

        
Daniel

        


        

        
Abstract:

        
The header indicates that RFC 5545,and RFC 5546 are
          updated. This must be also stated in the Abstract and in the
          introduction. 

        

      

    

    Some text added

    

      

        


        

        


        

        
1.=C2=A0 Introduction

          

          """

          Current practice is to embed this information as links in the

          =C2=A0=C2=A0 description or to add x-properties.

          """

          

          It is not clear to me how to use x-properties. Is it a
          notation ? In addition, I am also wondering if this does not
          designate the LABEL property. If that is correct, maybe that
          could be explicitly stated to better understand section 5.

        

      

    

    I've changed the text to refer to non-standard properties and
    provided a reference to the section in 5545. 

    

    LABEL is a parameter used to provide a human-readable label for
    properties - something like the alt attribute in html - so no - that
    is a different usage

    

    

      

        


          

          The conventions needs to be updated according to RFC 8174

          

          =C2=A0=C2=A0 The key words "MUST", "MUST NOT"=
, "REQUIRED", "SHALL",
          "SHALL NOT",

          =C2=A0=C2=A0 "SHOULD", "SHOULD NOT", "RE=
COMMENDED", "NOT RECOMMENDED",
          "MAY", and

          =C2=A0=C2=A0 "OPTIONAL" in this document are to be inte=
rpreted as
          described in

          =C2=A0=C2=A0 [RFC2119].

        

      

    

    Done

    

      

        


          3.=C2=A0 Typed References

          

          """

          =C2=A0=C2=A0 perhaps

          =C2=A0=C2=A0 for indexing or the presentation of additional relat=
ed
          information

          =C2=A0=C2=A0 for the user.

          """

          

          Thought English is not my natural language, there might be a
          nit there. 

          

          =C2=A0=C2=A0 perhaps

          =C2=A0=C2=A0 for indexing or presentating the additional related
          information

          =C2=A0=C2=A0 to the user.

          --

        

      

    

    Changed to:

    

    perhaps for indexing or the

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 presenting of additional rel=
ated information for the user.

    

      

        


          

          """

          Using STRUCTURED-LOCATION, information about a number of
          interesting

          =C2=A0=C2=A0 locations can be communicated, for example, parking,
          restaurants and

          =C2=A0=C2=A0 the venue.=C2=A0 Servers and clients can retrieve th=
e objects
          when storing

          =C2=A0=C2=A0 the event and use them to index by geographic locati=
on.

          """

          

          It is not clear from the text that the location information
          mentioned above (e.g. address, region, country, postal code)
          that motivated the STRUCTURED-LOCATION are part
          STRUCTURED-LOCATION. Thus I would also mention them 

          

          

          Using STRUCTURED-LOCATION, information about a number of
          interesting

          =C2=A0=C2=A0 locations can be communicated, for example, address,
          region, country, postal code as well as other informations
          such as the parking, restaurants and

          =C2=A0=C2=A0 the venue.=C2=A0 Servers and clients can retrieve th=
e objects
          when storing

          =C2=A0=C2=A0 the event and use them to index by geographic locati=
on.

          

        

      

    

    Done

    

      

        
---

          

          3.1.2.=C2=A0 Itineraries

          

          

          """

          The contact information can

          =C2=A0=C2=A0 provide detailed information about the booking agent=
, the
          airlines

          =C2=A0=C2=A0 and car hire companies and the hotel.

          """

          

          Looks to me that there is an additional "and".

        

      

    

    Removed

    

      

        


          

          

          5.=C2=A0 New Property Parameters

          

          """

          =C2=A0=C2=A0 This specification makes use of the LABEL property
          parameter which is

          =C2=A0=C2=A0 defined in [RFC7986]

          """

          

          My understanding is that the parameters described in this
          section apply to the LABEL property.. It seems to me that this
          is the first time the LABEL properties and associated
          parameters are mentioned in the document. In other words, I
          have hard time finding where this section is introduced=C2=A0 in
          the previous sections such as the introduction. If I am
          correct, maybe that could be clarified in the introduction. 

        

      

    

    LABEL is a parameter - it turns up in the ABNF for a number of the
    properties defined here. The phrase "property parameter" was =
pulled
    out of that spec - from 5545 as well. "LABEL parameter" is a =
little
    clearer I think. I'll try that.

    

      

        


          It seems to me that the document is structured with a kind of
          bottom - up approach. parameters < properties <
          components. Thus I am wondering if there are any reasons for
          not having the Calendar Components at the very end instead of
          at the beginning.

        

      

    

    

      

        
I am also wondering if that would not be more easy to read
          the document with Participant Types and Resource Types listed
          within their respective Properties. 

          

        

      

    

    I see what you mean now. Makes sense.

    

      

        


          

        

      

      


        
On Tue, May 15, 2018 at 1:12 PM, Daniel
          Migault <daniel.migault@ericsson.com>
          wrote:

          

            

              
Hi, 

              

              


              

              
draft-ietf-calext-eventpub-extensions [1] is
                already on WGLC. We would like to sufficient reviews to
                move the document to the IESG. If you have not yet
                commented the document, please provide your feedbacks by
                May 29 so we can move the document forward. 

              

              


              

              
Yours, 

              

              
Calext co-chairs.

              

              


              

              


              

              


              

              
            

          

        

        

      

      

      

      

      
______________________________________________=
_
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify


    

    

  



_______________________________________________

calsify mailing list

calsify@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/calsify<=
br>










--000000000000813d0e0572c8c801--


From nobody Mon Aug  6 16:40:00 2018
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 E691A128CB7 for ; Mon,  6 Aug 2018 16:39:58 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mnF2JPCNkUnG for ; Mon,  6 Aug 2018 16:39:55 -0700 (PDT)
Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (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 07704130E02 for ; Mon,  6 Aug 2018 16:39:55 -0700 (PDT)
Received: by mail-qt0-x243.google.com with SMTP id t5-v6so15940181qtn.3 for ; Mon, 06 Aug 2018 16:39:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=j1qTGqouIS85OCEqyGIxlUziP1TrvnHYDbTDjR4kaoo=; b=iuhL3SmoIkoewRRyeUpyZ6jNrButg8AOJoQnuPJmJmL/JuoWkHJxk/eNAVfFo/73XI uOOEtOimRpPy0bkC2nWlAKvhPlkLWdjw28V+ztl/Lsq0JhpB2MaOYm7o07JwGtoJ6FS5 /Gm8iDmSZY/VtuDy/H+Z9Xw5oiJeBHfz/0ZQCYqFYic5FoutTLPnr/KKsNWQuaKbbr/L mDtoNrovYjR6R4FPUGg/sFlOs8aAE0YDErRqgDvGcLLF1+hZHwOmj+Kmb/5VNhTGCZnt J6cKrbndAbXhTU955zCFC/k8s5baTg7Foc5uQ89f2sQJgh21Cw+NZ1+MFpxYp2u6pvCF w8AA==
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-language; bh=j1qTGqouIS85OCEqyGIxlUziP1TrvnHYDbTDjR4kaoo=; b=SSpYTC5uyKEhk0NGn2S7YoLeCw8qHIOLkz/DBEp7+mzCNTbRvhL7fJhlhxMbYUTEYN HR+u86DSt4Gz/6XVhV0qgZc1SzaWem5AiQpCYuGGrER7DmGTbWV5rnOGvDdLuMVbB/1K b2+m9Fm6BFGd5n1RNu553wl8ta28bUDGUyLGJ5ZVyZvhCfmlr9T6v6pOZ8yCgxwM7uSN csFibRVpgzA3wyayOkPVv3wNFNc3qexbZZ36ZGedlCFlS1ejYitWpjTJjsWxoB93LL4D WmPFDgTMxe5J4nnxnNKUR1Tqyyrr2VTaayoTmejTxl4WMNc2/eZnPiyiUY1d4Ry/vTRI YoHg==
X-Gm-Message-State: AOUpUlEHnUadsxqu04gQEqwZR2bAHOswORgZmZ6EWLV7Yanusmvn5H56 iRm4reZgWhT4xv3sLmVUY8YzpRPu
X-Google-Smtp-Source: AAOMgpeK73oFkzJ7bIrZR8TF3KwKRDC9ICqCCr45dTUiegsV6ONgmjn1UjCjin1wcGv9Oq6/lGTm5w==
X-Received: by 2002:ac8:493:: with SMTP id s19-v6mr16079024qtg.159.1533598793990;  Mon, 06 Aug 2018 16:39:53 -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 u4-v6sm1923350qtj.12.2018.08.06.16.39.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 16:39:53 -0700 (PDT)
To: Daniel Migault 
Cc: calsify@ietf.org
References:   <708d48bc-e213-1386-ff7b-23a476000774@gmail.com>   
From: Michael Douglass 
Message-ID: <61af20a8-21e4-0e10-f914-a176696c2aee@gmail.com>
Date: Mon, 6 Aug 2018 19:39:52 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------E45532AF4883BEEE179BC99D"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Aug 2018 23:39:59 -0000

This is a multi-part message in MIME format.
--------------E45532AF4883BEEE179BC99D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Thanks Daniel

I'll try and deal with most of these tonight


On 8/6/18 14:52, Daniel Migault wrote:
> Hi,
>
> Initiating the shepherd write-up here are my additional comments:
>
> 1) running the nits raises some minor issues so please remove the '[' 
> and ']' in the abstract.
>
> OLD:
>
>    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.
>
> NEW:
>
>    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.
>
> 2)
>
> I do not see the following reference mentioned in the text. Maybe it 
> could be removed. If you prefer to keep it, maybe informational may be 
> the right category for it.
>
>    [W3C.REC-xml-20060816]
>               Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
>               F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
>               Edition)", World Wide Web Consortium Recommendation REC-
>               xml-20060816, August 2006,
>               .
>
>
> 3) I do not see the update of RFC 5546 being discussed in the 
> introduction. Could you please add some text ?
>
>
> 4) IANA section,
>
> I suggest to add the URL to the IANA registry as an informative reference.
> https://www.iana.org/assignments/icalendar/icalendar.xhtml#properties
>
>
> section 12.1.{1,2,3} I would remove the term "Registration" to make 
> sure the title of the section match the registry. Similarly, I would 
> replace Property by Properties to match the registries.
>
> Yours,
> Daniel
>
> On Mon, Aug 6, 2018 at 1:58 PM, Daniel Migault 
> > wrote:
>
>     In order to get a rough idea of the consensus to move that draft
>     forward to the IESG, I would also appreciate your support on
>     approving the document. Please let us know if you believe the
>     document is ready to be moved forward.
>
>     If you have implemented it, it would also be much appreciate to
>     write the review.
>
>     Yours,
>     Daniel
>
>     On Mon, Aug 6, 2018 at 1:44 PM, Daniel Migault
>     >
>     wrote:
>
>         Hi,
>         Just catching up. Is the current version addressing all
>         comments, or do we expect another version coming in the few
>         next days ?
>
>         Yours,
>         Daniel
>
>         On Wed, May 16, 2018 at 1:33 AM, Michael Douglass
>         > wrote:
>
>             Thank you for the comments - I've submitted a new draft to
>             address these and just realised I didn't address any of
>             Robert's issues.
>
>             I'll deal with those in day or so.
>
>
>             On 5/15/18 23:07, Daniel Migault wrote:
>>             Hi,
>>
>>             Please find some comments. These comments are indicative.
>>
>>             Yours,
>>             Daniel
>>
>>             Abstract:
>>             The header indicates that RFC 5545,and RFC 5546 are
>>             updated. This must be also stated in the Abstract and in
>>             the introduction.
>             Some text added
>>
>>
>>             1.  Introduction
>>
>>             """
>>             Current practice is to embed this information as links in the
>>                description or to add x-properties.
>>             """
>>
>>             It is not clear to me how to use x-properties. Is it a
>>             notation ? In addition, I am also wondering if this does
>>             not designate the LABEL property. If that is correct,
>>             maybe that could be explicitly stated to better
>>             understand section 5.
>             I've changed the text to refer to non-standard properties
>             and provided a reference to the section in 5545.
>
>             LABEL is a parameter used to provide a human-readable
>             label for properties - something like the alt attribute in
>             html - so no - that is a different usage
>>
>>
>>             The conventions needs to be updated according to RFC 8174
>>
>>                The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
>>             "SHALL NOT",
>>                "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
>>             RECOMMENDED", "MAY", and
>>                "OPTIONAL" in this document are to be interpreted as
>>             described in
>>                [RFC2119].
>             Done
>>
>>             3.  Typed References
>>
>>             """
>>                perhaps
>>                for indexing or the presentation of additional related
>>             information
>>                for the user.
>>             """
>>
>>             Thought English is not my natural language, there might
>>             be a nit there.
>>
>>                perhaps
>>                for indexing or presentating the additional related
>>             information
>>                to the user.
>>             --
>             Changed to:
>
>             perhaps for indexing or the
>                     presenting of additional related information for
>             the user.
>>
>>
>>             """
>>             Using STRUCTURED-LOCATION, information about a number of
>>             interesting
>>                locations can be communicated, for example, parking,
>>             restaurants and
>>                the venue.  Servers and clients can retrieve the
>>             objects when storing
>>                the event and use them to index by geographic location.
>>             """
>>
>>             It is not clear from the text that the location
>>             information mentioned above (e.g. address, region,
>>             country, postal code) that motivated the
>>             STRUCTURED-LOCATION are part STRUCTURED-LOCATION. Thus I
>>             would also mention them
>>
>>
>>             Using STRUCTURED-LOCATION, information about a number of
>>             interesting
>>                locations can be communicated, for example, address,
>>             region, country, postal code as well as other
>>             informations such as the parking, restaurants and
>>                the venue.  Servers and clients can retrieve the
>>             objects when storing
>>                the event and use them to index by geographic location.
>>
>             Done
>>             ---
>>
>>             3.1.2.  Itineraries
>>
>>
>>             """
>>             The contact information can
>>                provide detailed information about the booking agent,
>>             the airlines
>>                and car hire companies and the hotel.
>>             """
>>
>>             Looks to me that there is an additional "and".
>             Removed
>>
>>
>>
>>             5.  New Property Parameters
>>
>>             """
>>                This specification makes use of the LABEL property
>>             parameter which is
>>                defined in [RFC7986]
>>             """
>>
>>             My understanding is that the parameters described in this
>>             section apply to the LABEL property.. It seems to me that
>>             this is the first time the LABEL properties and
>>             associated parameters are mentioned in the document. In
>>             other words, I have hard time finding where this section
>>             is introduced  in the previous sections such as the
>>             introduction. If I am correct, maybe that could be
>>             clarified in the introduction.
>             LABEL is a parameter - it turns up in the ABNF for a
>             number of the properties defined here. The phrase
>             "property parameter" was pulled out of that spec - from
>             5545 as well. "LABEL parameter" is a little clearer I
>             think. I'll try that.
>>
>>             It seems to me that the document is structured with a
>>             kind of bottom - up approach. parameters < properties <
>>             components. Thus I am wondering if there are any reasons
>>             for not having the Calendar Components at the very end
>>             instead of at the beginning.
>>             I am also wondering if that would not be more easy to
>>             read the document with Participant Types and Resource
>>             Types listed within their respective Properties.
>>
>             I see what you mean now. Makes sense.
>>
>>
>>
>>             On Tue, May 15, 2018 at 1:12 PM, Daniel Migault
>>             >             > wrote:
>>
>>                 Hi,
>>
>>                 draft-ietf-calext-eventpub-extensions [1] is already
>>                 on WGLC. We would like to sufficient reviews to move
>>                 the document to the IESG. If you have not yet
>>                 commented the document, please provide your feedbacks
>>                 by May 29 so we can move the document forward.
>>
>>                 Yours,
>>                 Calext co-chairs.
>>
>>
>>
>>                 [1]
>>                 https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/
>>                 
>>
>>
>>
>>
>>             _______________________________________________
>>             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
>             
>
>
>
>


--------------E45532AF4883BEEE179BC99D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Thanks Daniel

    

    
I'll try and deal with most of these tonight

    

    

    
On 8/6/18 14:52, Daniel Migault wrote:

    

    

      
      

        
Hi, 

        

        


        

        
Initiating the shepherd write-up here are my additional
          comments:

        


        

        
1) running the nits raises some minor issues so please
          remove the '[' and ']' in the abstract.

          

          OLD:

          

             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.

          

          NEW:

          

             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.

          

          2)

          

          I do not see the following reference mentioned in the text.
          Maybe it could be removed. If you prefer to keep it, maybe
          informational may be the right category for it.

          

             [W3C.REC-xml-20060816]

                        Bray, T., Paoli, J., Sperberg-McQueen, M.,
          Maler, E., and

                        F. Yergeau, "Extensible Markup Language (XML)
          1.0 (Fourth

                        Edition)", World Wide Web Consortium
          Recommendation REC-

                        xml-20060816, August 2006,

                        <http://www.w3.org/TR/2006/REC-xml-20060816>.

          

          

          3) I do not see the update of RFC 5546 being discussed in the
          introduction. Could you please add some text ?

           

          

          4) IANA section,

          

          I suggest to add the URL to the IANA registry as an
          informative reference.

          https://www.iana.org/assignments/icalendar/icalendar.xhtml#properties

          

          

          section 12.1.{1,2,3} I would remove the term "Registration" to
          make sure the title of the section match the registry.
          Similarly, I would replace Property by Properties to match the
          registries.

          

        

        
Yours, 

        

        
Daniel

        

      

      


        
On Mon, Aug 6, 2018 at 1:58 PM, Daniel
          Migault <daniel.migault@ericsson.com>
          wrote:

          

            

              
In order to get a rough idea of the consensus to move
                that draft forward to the IESG, I would also appreciate
                your support on approving the document. Please let us
                know if you believe the document is ready to be moved
                forward. 

              

              


              

              
If you have implemented it, it would also be much
                appreciate to write the review. 

              

              


              

              
Yours, 

              

              
Daniel

              

            

            

              

                


                  
On Mon, Aug 6, 2018 at 1:44
                    PM, Daniel Migault <daniel.migault@ericsson.com>
                    wrote:

                    

                      

                        
Hi, 

                        

                        
Just catching up. Is the current version
                          addressing all comments, or do we expect
                          another version coming in the few next days ?

                        


                        

                        
Yours, 

                        

                        
Daniel

                        

                      

                      

                        

                          


                            
On Wed, May 16,
                              2018 at 1:33 AM, Michael Douglass <mikeadouglass@gmail.com>
                              wrote:

                              

                                

                                  
Thank you for the comments - I've
                                    submitted a new draft to address
                                    these and just realised I didn't
                                    address any of Robert's issues.

                                  
I'll deal with those in day or so.

                                  

                                   

                                    
On
                                      5/15/18 23:07, Daniel Migault
                                      wrote:

                                    

                                  
                                    

                                      

                                        
Hi, 

                                        

                                        


                                        

                                        
Please find some comments.
                                          These comments are indicative.

                                        


                                        

                                        
Yours, 

                                        

                                        
Daniel

                                        


                                        

                                        
Abstract:

                                        
The header indicates that
                                          RFC 5545,and RFC 5546 are
                                          updated. This must be also
                                          stated in the Abstract and in
                                          the introduction. 

                                        

                                      

                                    

                                   Some text added

                                    

                                      

                                        


                                        

                                        


                                        

                                        
1.  Introduction

                                          

                                          """

                                          Current practice is to embed
                                          this information as links in
                                          the

                                             description or to add
                                          x-properties.

                                          """

                                          

                                          It is not clear to me how to
                                          use x-properties. Is it a
                                          notation ? In addition, I am
                                          also wondering if this does
                                          not designate the LABEL
                                          property. If that is correct,
                                          maybe that could be explicitly
                                          stated to better understand
                                          section 5.

                                        

                                      

                                    

                                   I've changed the text to refer
                                  to non-standard properties and
                                  provided a reference to the section in
                                  5545. 

                                  

                                  LABEL is a parameter used to provide a
                                  human-readable label for properties -
                                  something like the alt attribute in
                                  html - so no - that is a different
                                  usage

                                    

                                      

                                        


                                          

                                          The conventions needs to be
                                          updated according to RFC 8174

                                          

                                             The key words "MUST", "MUST
                                          NOT", "REQUIRED", "SHALL",
                                          "SHALL NOT",

                                             "SHOULD", "SHOULD NOT",
                                          "RECOMMENDED", "NOT
                                          RECOMMENDED", "MAY", and

                                             "OPTIONAL" in this document
                                          are to be interpreted as
                                          described in

                                             [RFC2119].

                                        

                                      

                                    

                                   Done

                                    

                                      

                                        


                                          3.  Typed References

                                          

                                          """

                                             perhaps

                                             for indexing or the
                                          presentation of additional
                                          related information

                                             for the user.

                                          """

                                          

                                          Thought English is not my
                                          natural language, there might
                                          be a nit there. 

                                          

                                             perhaps

                                             for indexing or
                                          presentating the additional
                                          related information

                                             to the user.

                                          --

                                        

                                      

                                    

                                   Changed to:

                                    

                                    perhaps for indexing or the

                                           presenting of
                                  additional related information for the
                                  user.

                                    

                                      

                                        


                                          

                                          """

                                          Using STRUCTURED-LOCATION,
                                          information about a number of
                                          interesting

                                             locations can be
                                          communicated, for example,
                                          parking, restaurants and

                                             the venue.  Servers and
                                          clients can retrieve the
                                          objects when storing

                                             the event and use them to
                                          index by geographic location.

                                          """

                                          

                                          It is not clear from the text
                                          that the location information
                                          mentioned above (e.g. address,
                                          region, country, postal code)
                                          that motivated the
                                          STRUCTURED-LOCATION are part
                                          STRUCTURED-LOCATION. Thus I
                                          would also mention them 

                                          

                                          

                                          Using STRUCTURED-LOCATION,
                                          information about a number of
                                          interesting

                                             locations can be
                                          communicated, for example,
                                          address, region, country,
                                          postal code as well as other
                                          informations such as the
                                          parking, restaurants and

                                             the venue.  Servers and
                                          clients can retrieve the
                                          objects when storing

                                             the event and use them to
                                          index by geographic location.

                                          

                                        

                                      

                                    

                                   Done

                                    

                                      

                                        
---

                                          

                                          3.1.2.  Itineraries

                                          

                                          

                                          """

                                          The contact information can

                                             provide detailed
                                          information about the booking
                                          agent, the airlines

                                             and car hire companies and
                                          the hotel.

                                          """

                                          

                                          Looks to me that there is an
                                          additional "and".

                                        

                                      

                                    

                                   Removed

                                  

                                    

                                      


                                          

                                          

                                          5.  New Property Parameters

                                          

                                          """

                                             This specification makes
                                          use of the LABEL property
                                          parameter which is

                                             defined in [RFC7986]

                                          """

                                          

                                         My understanding is that
                                        the parameters described in this
                                        section apply to the LABEL
                                        property.. It seems to me that
                                        this is the first time the LABEL
                                        properties and associated
                                        parameters are mentioned in the
                                        document. In other words, I have
                                        hard time finding where this
                                        section is introduced  in the
                                        previous sections such as the
                                        introduction. If I am correct,
                                        maybe that could be clarified in
                                        the introduction. 

                                      

                                    

                                  

                                  LABEL is a parameter - it turns up in
                                  the ABNF for a number of the
                                  properties defined here. The phrase
                                  "property parameter" was pulled out of
                                  that spec - from 5545 as well. "LABEL
                                  parameter" is a little clearer I
                                  think. I'll try that.

                                    

                                      

                                        


                                          It seems to me that the
                                          document is structured with a
                                          kind of bottom - up approach.
                                          parameters < properties
                                          < components. Thus I am
                                          wondering if there are any
                                          reasons for not having the
                                          Calendar Components at the
                                          very end instead of at the
                                          beginning.

                                        

                                      

                                    

                                    

                                      

                                        
I am also wondering if that
                                          would not be more easy to read
                                          the document with Participant
                                          Types and Resource Types
                                          listed within their respective
                                          Properties. 

                                          

                                        

                                      

                                    

                                   I see what you mean now. Makes
                                  sense.

                                  

                                      

                                        


                                          

                                        

                                      

                                      


                                        
On Tue,
                                          May 15, 2018 at 1:12 PM,
                                          Daniel Migault <daniel.migault@ericsson.com>
                                          wrote:

                                          

                                            

                                              
Hi, 

                                              

                                              


                                              

                                              
draft-ietf-calext-eventpub-extensions
                                                [1] is already on WGLC.
                                                We would like to
                                                sufficient reviews to
                                                move the document to the
                                                IESG. If you have not
                                                yet commented the
                                                document, please provide
                                                your feedbacks by May 29
                                                so we can move the
                                                document forward. 

                                              

                                              


                                              

                                              
Yours, 

                                              

                                              
Calext co-chairs.

                                              

                                              


                                              

                                              


                                              

                                              


                                              

                                              
                                            

                                          

                                        

                                        

                                      

                                      

                                      

                                      

                                    
                                      
_______________________________________________
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

                                

                              

                            

                            

                          

                        

                      

                    

                  

                  

                

              

            

          

        

        

      

    

    

  


--------------E45532AF4883BEEE179BC99D--


From nobody Mon Aug  6 20:13:53 2018
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 E6D74130F1C for ; Mon,  6 Aug 2018 20:13:51 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wovm8vAsGBYK for ; Mon,  6 Aug 2018 20:13:50 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 2D0BD130E27 for ; Mon,  6 Aug 2018 20:13:50 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id q12-v6so16333542qtp.6 for ; Mon, 06 Aug 2018 20:13:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=6i42PoYnw0uxzRDtLqE1PDL18pnH9/yuT80hiBm9cYU=; b=qZH5x9bVA0Np9Y6H/gaz5NOZaIDSx/jp/e7SRFr8NTToso/pmu+c02mC/5r9KLENS0 Kbxmym1Pjb1vxrOpQEjDIuIfy0KylRUVAm4+UfOakpL3AVDe6Epqp38/oQ+tfqWOBDId lXvK7U57Yw+u1lR0NZJA79WcLqRYT5y+ivwwag3jSJEhHTh7WJd25xa0xwL4euGgS1Hj nxfkS5Ji4WQ0u+EJkRcoSR8XUc16kOZjXwx+Ea6fo4RqNQrgrAWP4rBqKIQj9dCuw5yD sr++aFDqh6/XZuF46XhN7EzzxI/P/FwoTZFt8OFnq/7f6ZFay+MKR774Dj4eBCaax4OF wm5g==
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-language; bh=6i42PoYnw0uxzRDtLqE1PDL18pnH9/yuT80hiBm9cYU=; b=qRHmcTOemzaAsCbVeE8kkYX7iYkOcFBOg2lXDXPE5zxPMdjupz2l3QojOtE61pTcw0 dZwqTboLe7c8dxa/DrFTKc+sOPm48KYjDb+7spEVTvO9fg+XMJl/VqMLzL5VRQVvXgXs noOsOJ+ImJe8UFy3P/P7q0DFwzra9xYb7NmeMmMIcmKGA85aOiL2/V9E3f8ADfnqIAH0 DEhMnuiwE2ZIiylEfaPAZBU0iTUCQuYUVjF7aNac3xIVXMW4t7g0hRGKCd9lPfytgtSO dgHJAg42ZN0G3j6JQBXUgqIxVm68RSiN+8DLOhoe5FKSupCohiqghM8eZ3XDtz3K8Bys ZtvQ==
X-Gm-Message-State: AOUpUlEYpB6MgR6x8KUSI2Vo78/4w39+77vNKZzxeVkcVarMGgi7lnjM PnF0vwssyZ3LBivjBq1stD3+cMz/
X-Google-Smtp-Source: AAOMgpdPjpTRahbDFFl/S3zmlBmywUVncn317Nrn3ho0NIN8g/p73F7ugQjRLkjc1CbB3eAHsOCUgw==
X-Received: by 2002:aed:3f7c:: with SMTP id q57-v6mr17264462qtf.256.1533611629209;  Mon, 06 Aug 2018 20:13:49 -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 190-v6sm123823qkg.31.2018.08.06.20.13.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 20:13:48 -0700 (PDT)
To: Daniel Migault 
Cc: calsify@ietf.org
References:   <708d48bc-e213-1386-ff7b-23a476000774@gmail.com>   
From: Michael Douglass 
Message-ID: <623de6c5-0aa3-1abf-9b05-22304d9fb813@gmail.com>
Date: Mon, 6 Aug 2018 23:13:48 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------8AE21D16817AEC5F396971BE"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Aug 2018 03:13:52 -0000

This is a multi-part message in MIME format.
--------------8AE21D16817AEC5F396971BE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 8/6/18 14:52, Daniel Migault wrote:
> Hi,
>
> Initiating the shepherd write-up here are my additional comments:
>
> 1) running the nits raises some minor issues so please remove the '[' 
> and ']' in the abstract.
>
> OLD:
>
>    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.
>
> NEW:
>
>    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 appears to be an artifact of xml2rfc - there are no square brackets 
in the XML. Is theer some trick to avoiding them? Here's the source:

This specification updates   and
  by introducing a number of new iCalendar


--------------8AE21D16817AEC5F396971BE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 8/6/18 14:52, Daniel Migault wrote:

    

    

      
      

        
Hi, 

        

        


        

        
Initiating the shepherd write-up here are my additional
          comments:

        


        

        
1) running the nits raises some minor issues so please
          remove the '[' and ']' in the abstract.

          

          OLD:

          

             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.

          

          NEW:

          

             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 appears to be an artifact of xml2rfc - there are no square
    brackets in the XML. Is theer some trick to avoiding them? Here's
    the source:

    

    
This specification updates <xref target='RFC5545'/>  and
<xref target='RFC5546'/> by introducing a number of new iCalendar



  


--------------8AE21D16817AEC5F396971BE--


From nobody Mon Aug  6 20:36:27 2018
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 AAA61130E06 for ; Mon,  6 Aug 2018 20:36:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 zIu7mjw_hLue for ; Mon,  6 Aug 2018 20:36:22 -0700 (PDT)
Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (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 5072712F1AB for ; Mon,  6 Aug 2018 20:36:22 -0700 (PDT)
Received: by mail-qk0-x241.google.com with SMTP id u21-v6so10515590qku.2 for ; Mon, 06 Aug 2018 20:36:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=uwgZ5bE/wZ198Vt9tGnaR/sXBRj4LN8Z2RsvSdWr6Vs=; b=R9rRmEjkP3ktkmAsCRbAwSHZhwje5ZuCZr26n/EkvWmJhtozLCKHa2OBIuqoFvWTvy 6gLxcIeGSp0a3TU34sKqBi5mW6q4XjpnV5XPcla0XLxEa5X9y7EAJA7MZrp/Y5SthKqA 4tqJLj8xsgpYO4ohwSUPmnjyqMpL6FwPKUJzZfkxJlT6oX7GddKVKQmMi+z0MhoYsptm TOzrVGnTU1QkTrJfTHC2MNy8B+Jl1aFpWnqAA+s2r7Nr6Og08hugUZ9gHTiNCZRRK8rv 61rw+7Ei2J92HYqeCrWXonaay8DYCJDnyFyKr5Zaw5hpWXdYB73ljD4t9wX68YiUxj6i YEpQ==
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-language; bh=uwgZ5bE/wZ198Vt9tGnaR/sXBRj4LN8Z2RsvSdWr6Vs=; b=O9+ELqGKm/GhPtJ6hWxDbMC2GdYQXNTTjvV0tt+WIBsh52tdzjPITr7sLAVn96TnDy VszoQxWFOmfB69KtYDRfHRFjzLuVTjldeKMluKOGP5JGWq3Cp96q/VrG/juMmBARIwCz SpfOjeRouDPyUYMPiTBtAHPj9PiUn20tp13ICslFoKL+aM5+LM6nABMmmCTdZiLDV3sG Zn4nmBOkAwM7Vr0OO1uz+QVHDnd//ChLomGFC8drX6jtjItNIMHWIVRbb1RduIO7GQhJ CeWqiYupjWHtPb09jUlYPDXYoiUIsHUoxnX9AK7jlGcmYHhAyu9poRCAprBDCq1UDMSK zj/Q==
X-Gm-Message-State: AOUpUlFLL1fciy029sdU2RVlfpcibyWH5fkQ0QILG7oO08dQGFhxCpR8 +z3bNc+NmTWlUbSwpVBqOAe7ap21
X-Google-Smtp-Source: AAOMgpfZaM3OybG1hil9USMh1UzhahHQAJz5yVRC3bTRDuXz92zOqefNZff2AW/qwte+AQGy7lH+4Q==
X-Received: by 2002:a37:1f53:: with SMTP id f80-v6mr15218267qkf.1.1533612981061;  Mon, 06 Aug 2018 20:36:21 -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 a66-v6sm115295qkf.96.2018.08.06.20.36.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 20:36:20 -0700 (PDT)
To: Daniel Migault 
Cc: calsify@ietf.org
References:   <708d48bc-e213-1386-ff7b-23a476000774@gmail.com>   
From: Michael Douglass 
Message-ID: 
Date: Mon, 6 Aug 2018 23:36:19 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------50EADAA4BDF25D7BB9475264"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Aug 2018 03:36:26 -0000

This is a multi-part message in MIME format.
--------------50EADAA4BDF25D7BB9475264
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 8/6/18 14:52, Daniel Migault wrote:
> Hi,
>
> Initiating the shepherd write-up here are my additional comments:
>
> 1) running the nits raises some minor issues so please remove the '[' 
> and ']' in the abstract.
>
> OLD:
>
>    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.
>
> NEW:
>
>    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.
See previous message - seems to be xml2rfc
>
> 2)
>
> I do not see the following reference mentioned in the text. Maybe it 
> could be removed. If you prefer to keep it, maybe informational may be 
> the right category for it.
>
>    [W3C.REC-xml-20060816]
>               Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
>               F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
>               Edition)", World Wide Web Consortium Recommendation REC-
>               xml-20060816, August 2006,
>               .
>
Removed
>
> 3) I do not see the update of RFC 5546 being discussed in the 
> introduction. Could you please add some text ?
>
Removed the updates reference. 5546 is mentioned but I don't belieev 
updated in any way.
>
> 4) IANA section,
>
> I suggest to add the URL to the IANA registry as an informative reference.
> https://www.iana.org/assignments/icalendar/icalendar.xhtml#properties
>
Done
>
> section 12.1.{1,2,3} I would remove the term "Registration" to make 
> sure the title of the section match the registry. Similarly, I would 
> replace Property by Properties to match the registries.
Done
>
> Yours,
> Daniel
Thanks - Mike
>
> On Mon, Aug 6, 2018 at 1:58 PM, Daniel Migault 
> > wrote:
>
>     In order to get a rough idea of the consensus to move that draft
>     forward to the IESG, I would also appreciate your support on
>     approving the document. Please let us know if you believe the
>     document is ready to be moved forward.
>
>     If you have implemented it, it would also be much appreciate to
>     write the review.
>
>     Yours,
>     Daniel
>
>     On Mon, Aug 6, 2018 at 1:44 PM, Daniel Migault
>     >
>     wrote:
>
>         Hi,
>         Just catching up. Is the current version addressing all
>         comments, or do we expect another version coming in the few
>         next days ?
>
>         Yours,
>         Daniel
>
>         On Wed, May 16, 2018 at 1:33 AM, Michael Douglass
>         > wrote:
>
>             Thank you for the comments - I've submitted a new draft to
>             address these and just realised I didn't address any of
>             Robert's issues.
>
>             I'll deal with those in day or so.
>
>
>             On 5/15/18 23:07, Daniel Migault wrote:
>>             Hi,
>>
>>             Please find some comments. These comments are indicative.
>>
>>             Yours,
>>             Daniel
>>
>>             Abstract:
>>             The header indicates that RFC 5545,and RFC 5546 are
>>             updated. This must be also stated in the Abstract and in
>>             the introduction.
>             Some text added
>>
>>
>>             1.  Introduction
>>
>>             """
>>             Current practice is to embed this information as links in the
>>                description or to add x-properties.
>>             """
>>
>>             It is not clear to me how to use x-properties. Is it a
>>             notation ? In addition, I am also wondering if this does
>>             not designate the LABEL property. If that is correct,
>>             maybe that could be explicitly stated to better
>>             understand section 5.
>             I've changed the text to refer to non-standard properties
>             and provided a reference to the section in 5545.
>
>             LABEL is a parameter used to provide a human-readable
>             label for properties - something like the alt attribute in
>             html - so no - that is a different usage
>>
>>
>>             The conventions needs to be updated according to RFC 8174
>>
>>                The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
>>             "SHALL NOT",
>>                "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
>>             RECOMMENDED", "MAY", and
>>                "OPTIONAL" in this document are to be interpreted as
>>             described in
>>                [RFC2119].
>             Done
>>
>>             3.  Typed References
>>
>>             """
>>                perhaps
>>                for indexing or the presentation of additional related
>>             information
>>                for the user.
>>             """
>>
>>             Thought English is not my natural language, there might
>>             be a nit there.
>>
>>                perhaps
>>                for indexing or presentating the additional related
>>             information
>>                to the user.
>>             --
>             Changed to:
>
>             perhaps for indexing or the
>                     presenting of additional related information for
>             the user.
>>
>>
>>             """
>>             Using STRUCTURED-LOCATION, information about a number of
>>             interesting
>>                locations can be communicated, for example, parking,
>>             restaurants and
>>                the venue.  Servers and clients can retrieve the
>>             objects when storing
>>                the event and use them to index by geographic location.
>>             """
>>
>>             It is not clear from the text that the location
>>             information mentioned above (e.g. address, region,
>>             country, postal code) that motivated the
>>             STRUCTURED-LOCATION are part STRUCTURED-LOCATION. Thus I
>>             would also mention them
>>
>>
>>             Using STRUCTURED-LOCATION, information about a number of
>>             interesting
>>                locations can be communicated, for example, address,
>>             region, country, postal code as well as other
>>             informations such as the parking, restaurants and
>>                the venue.  Servers and clients can retrieve the
>>             objects when storing
>>                the event and use them to index by geographic location.
>>
>             Done
>>             ---
>>
>>             3.1.2.  Itineraries
>>
>>
>>             """
>>             The contact information can
>>                provide detailed information about the booking agent,
>>             the airlines
>>                and car hire companies and the hotel.
>>             """
>>
>>             Looks to me that there is an additional "and".
>             Removed
>>
>>
>>
>>             5.  New Property Parameters
>>
>>             """
>>                This specification makes use of the LABEL property
>>             parameter which is
>>                defined in [RFC7986]
>>             """
>>
>>             My understanding is that the parameters described in this
>>             section apply to the LABEL property.. It seems to me that
>>             this is the first time the LABEL properties and
>>             associated parameters are mentioned in the document. In
>>             other words, I have hard time finding where this section
>>             is introduced  in the previous sections such as the
>>             introduction. If I am correct, maybe that could be
>>             clarified in the introduction.
>             LABEL is a parameter - it turns up in the ABNF for a
>             number of the properties defined here. The phrase
>             "property parameter" was pulled out of that spec - from
>             5545 as well. "LABEL parameter" is a little clearer I
>             think. I'll try that.
>>
>>             It seems to me that the document is structured with a
>>             kind of bottom - up approach. parameters < properties <
>>             components. Thus I am wondering if there are any reasons
>>             for not having the Calendar Components at the very end
>>             instead of at the beginning.
>>             I am also wondering if that would not be more easy to
>>             read the document with Participant Types and Resource
>>             Types listed within their respective Properties.
>>
>             I see what you mean now. Makes sense.
>>
>>
>>
>>             On Tue, May 15, 2018 at 1:12 PM, Daniel Migault
>>             >             > wrote:
>>
>>                 Hi,
>>
>>                 draft-ietf-calext-eventpub-extensions [1] is already
>>                 on WGLC. We would like to sufficient reviews to move
>>                 the document to the IESG. If you have not yet
>>                 commented the document, please provide your feedbacks
>>                 by May 29 so we can move the document forward.
>>
>>                 Yours,
>>                 Calext co-chairs.
>>
>>
>>
>>                 [1]
>>                 https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/
>>                 
>>
>>
>>
>>
>>             _______________________________________________
>>             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
>             
>
>
>
>


--------------50EADAA4BDF25D7BB9475264
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 8/6/18 14:52, Daniel Migault wrote:

    

    

      
      

        
Hi, 

        

        


        

        
Initiating the shepherd write-up here are my additional
          comments:

        


        

        
1) running the nits raises some minor issues so please
          remove the '[' and ']' in the abstract.

          

          OLD:

          

             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.

          

          NEW:

          

             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.

        

      

    

    See previous message - seems to be xml2rfc

    

      

        


          2)

          

          I do not see the following reference mentioned in the text.
          Maybe it could be removed. If you prefer to keep it, maybe
          informational may be the right category for it.

          

             [W3C.REC-xml-20060816]

                        Bray, T., Paoli, J., Sperberg-McQueen, M.,
          Maler, E., and

                        F. Yergeau, "Extensible Markup Language (XML)
          1.0 (Fourth

                        Edition)", World Wide Web Consortium
          Recommendation REC-

                        xml-20060816, August 2006,

                        <http://www.w3.org/TR/2006/REC-xml-20060816>.

          

        

      

    

    Removed

    

      

        


          3) I do not see the update of RFC 5546 being discussed in the
          introduction. Could you please add some text ?

           

        

      

    

    Removed the updates reference. 5546 is mentioned but I don't belieev
    updated in any way.

    

      

        


          4) IANA section,

          

          I suggest to add the URL to the IANA registry as an
          informative reference.

          https://www.iana.org/assignments/icalendar/icalendar.xhtml#properties

          

        

      

    

    Done

    

      

        


          section 12.1.{1,2,3} I would remove the term "Registration" to
          make sure the title of the section match the registry.
          Similarly, I would replace Property by Properties to match the
          registries.

        

      

    

    Done

    

      

        


        

        
Yours, 

        

        
Daniel

        

      

    

    Thanks - Mike

    

      


        
On Mon, Aug 6, 2018 at 1:58 PM, Daniel
          Migault <daniel.migault@ericsson.com>
          wrote:

          

            

              
In order to get a rough idea of the consensus to move
                that draft forward to the IESG, I would also appreciate
                your support on approving the document. Please let us
                know if you believe the document is ready to be moved
                forward. 

              

              


              

              
If you have implemented it, it would also be much
                appreciate to write the review. 

              

              


              

              
Yours, 

              

              
Daniel

              

            

            

              

                


                  
On Mon, Aug 6, 2018 at 1:44
                    PM, Daniel Migault <daniel.migault@ericsson.com>
                    wrote:

                    

                      

                        
Hi, 

                        

                        
Just catching up. Is the current version
                          addressing all comments, or do we expect
                          another version coming in the few next days ?

                        


                        

                        
Yours, 

                        

                        
Daniel

                        

                      

                      

                        

                          


                            
On Wed, May 16,
                              2018 at 1:33 AM, Michael Douglass <mikeadouglass@gmail.com>
                              wrote:

                              

                                

                                  
Thank you for the comments - I've
                                    submitted a new draft to address
                                    these and just realised I didn't
                                    address any of Robert's issues.

                                  
I'll deal with those in day or so.

                                  

                                   

                                    
On
                                      5/15/18 23:07, Daniel Migault
                                      wrote:

                                    

                                  
                                    

                                      

                                        
Hi, 

                                        

                                        


                                        

                                        
Please find some comments.
                                          These comments are indicative.

                                        


                                        

                                        
Yours, 

                                        

                                        
Daniel

                                        


                                        

                                        
Abstract:

                                        
The header indicates that
                                          RFC 5545,and RFC 5546 are
                                          updated. This must be also
                                          stated in the Abstract and in
                                          the introduction. 

                                        

                                      

                                    

                                   Some text added

                                    

                                      

                                        


                                        

                                        


                                        

                                        
1.  Introduction

                                          

                                          """

                                          Current practice is to embed
                                          this information as links in
                                          the

                                             description or to add
                                          x-properties.

                                          """

                                          

                                          It is not clear to me how to
                                          use x-properties. Is it a
                                          notation ? In addition, I am
                                          also wondering if this does
                                          not designate the LABEL
                                          property. If that is correct,
                                          maybe that could be explicitly
                                          stated to better understand
                                          section 5.

                                        

                                      

                                    

                                   I've changed the text to refer
                                  to non-standard properties and
                                  provided a reference to the section in
                                  5545. 

                                  

                                  LABEL is a parameter used to provide a
                                  human-readable label for properties -
                                  something like the alt attribute in
                                  html - so no - that is a different
                                  usage

                                    

                                      

                                        


                                          

                                          The conventions needs to be
                                          updated according to RFC 8174

                                          

                                             The key words "MUST", "MUST
                                          NOT", "REQUIRED", "SHALL",
                                          "SHALL NOT",

                                             "SHOULD", "SHOULD NOT",
                                          "RECOMMENDED", "NOT
                                          RECOMMENDED", "MAY", and

                                             "OPTIONAL" in this document
                                          are to be interpreted as
                                          described in

                                             [RFC2119].

                                        

                                      

                                    

                                   Done

                                    

                                      

                                        


                                          3.  Typed References

                                          

                                          """

                                             perhaps

                                             for indexing or the
                                          presentation of additional
                                          related information

                                             for the user.

                                          """

                                          

                                          Thought English is not my
                                          natural language, there might
                                          be a nit there. 

                                          

                                             perhaps

                                             for indexing or
                                          presentating the additional
                                          related information

                                             to the user.

                                          --

                                        

                                      

                                    

                                   Changed to:

                                    

                                    perhaps for indexing or the

                                           presenting of
                                  additional related information for the
                                  user.

                                    

                                      

                                        


                                          

                                          """

                                          Using STRUCTURED-LOCATION,
                                          information about a number of
                                          interesting

                                             locations can be
                                          communicated, for example,
                                          parking, restaurants and

                                             the venue.  Servers and
                                          clients can retrieve the
                                          objects when storing

                                             the event and use them to
                                          index by geographic location.

                                          """

                                          

                                          It is not clear from the text
                                          that the location information
                                          mentioned above (e.g. address,
                                          region, country, postal code)
                                          that motivated the
                                          STRUCTURED-LOCATION are part
                                          STRUCTURED-LOCATION. Thus I
                                          would also mention them 

                                          

                                          

                                          Using STRUCTURED-LOCATION,
                                          information about a number of
                                          interesting

                                             locations can be
                                          communicated, for example,
                                          address, region, country,
                                          postal code as well as other
                                          informations such as the
                                          parking, restaurants and

                                             the venue.  Servers and
                                          clients can retrieve the
                                          objects when storing

                                             the event and use them to
                                          index by geographic location.

                                          

                                        

                                      

                                    

                                   Done

                                    

                                      

                                        
---

                                          

                                          3.1.2.  Itineraries

                                          

                                          

                                          """

                                          The contact information can

                                             provide detailed
                                          information about the booking
                                          agent, the airlines

                                             and car hire companies and
                                          the hotel.

                                          """

                                          

                                          Looks to me that there is an
                                          additional "and".

                                        

                                      

                                    

                                   Removed

                                  

                                    

                                      


                                          

                                          

                                          5.  New Property Parameters

                                          

                                          """

                                             This specification makes
                                          use of the LABEL property
                                          parameter which is

                                             defined in [RFC7986]

                                          """

                                          

                                         My understanding is that
                                        the parameters described in this
                                        section apply to the LABEL
                                        property.. It seems to me that
                                        this is the first time the LABEL
                                        properties and associated
                                        parameters are mentioned in the
                                        document. In other words, I have
                                        hard time finding where this
                                        section is introduced  in the
                                        previous sections such as the
                                        introduction. If I am correct,
                                        maybe that could be clarified in
                                        the introduction. 

                                      

                                    

                                  

                                  LABEL is a parameter - it turns up in
                                  the ABNF for a number of the
                                  properties defined here. The phrase
                                  "property parameter" was pulled out of
                                  that spec - from 5545 as well. "LABEL
                                  parameter" is a little clearer I
                                  think. I'll try that.

                                    

                                      

                                        


                                          It seems to me that the
                                          document is structured with a
                                          kind of bottom - up approach.
                                          parameters < properties
                                          < components. Thus I am
                                          wondering if there are any
                                          reasons for not having the
                                          Calendar Components at the
                                          very end instead of at the
                                          beginning.

                                        

                                      

                                    

                                    

                                      

                                        
I am also wondering if that
                                          would not be more easy to read
                                          the document with Participant
                                          Types and Resource Types
                                          listed within their respective
                                          Properties. 

                                          

                                        

                                      

                                    

                                   I see what you mean now. Makes
                                  sense.

                                  

                                      

                                        


                                          

                                        

                                      

                                      


                                        
On Tue,
                                          May 15, 2018 at 1:12 PM,
                                          Daniel Migault <daniel.migault@ericsson.com>
                                          wrote:

                                          

                                            

                                              
Hi, 

                                              

                                              


                                              

                                              
draft-ietf-calext-eventpub-extensions
                                                [1] is already on WGLC.
                                                We would like to
                                                sufficient reviews to
                                                move the document to the
                                                IESG. If you have not
                                                yet commented the
                                                document, please provide
                                                your feedbacks by May 29
                                                so we can move the
                                                document forward. 

                                              

                                              


                                              

                                              
Yours, 

                                              

                                              
Calext co-chairs.

                                              

                                              


                                              

                                              


                                              

                                              


                                              

                                              
                                            

                                          

                                        

                                        

                                      

                                      

                                      

                                      

                                    
                                      
_______________________________________________
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

                                

                              

                            

                            

                          

                        

                      

                    

                  

                  

                

              

            

          

        

        

      

    

    

  


--------------50EADAA4BDF25D7BB9475264--


From nobody Mon Aug  6 20:45:28 2018
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 D35ED130E31; Mon,  6 Aug 2018 20:45:26 -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.83.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: calsify@ietf.org
Message-ID: <153361352682.26812.17456909195532930218@ietfa.amsl.com>
Date: Mon, 06 Aug 2018 20:45:26 -0700
Archived-At: 
Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-08.txt
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Aug 2018 03:45:27 -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-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/


From nobody Mon Aug  6 20:47:23 2018
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 BFBC8130E31 for ; Mon,  6 Aug 2018 20:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 J_cr8Jto_Q49 for ; Mon,  6 Aug 2018 20:47:20 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 AD1A9130DF3 for ; Mon,  6 Aug 2018 20:47:19 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id u21-v6so10526115qku.2 for ; Mon, 06 Aug 2018 20:47:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=c61E+kbuAKAQG9MOwkmJIQy6xUtRkHyt+LbsCl8TJjc=; b=IqNN4kLScDCATX9NfH158EQtguFKKaCYMa/nwla0CYYJ4xHd+sLxx0hd4US4vrto+C Mz0dPfqoa+0w+BqPpdB6I+09M6F/Qsyjp0tFhocOHD3Q8ThVTk6S3uDHVlvjlIJQvzdG fc6fPR/F/XslgB2Tt4N0kKYckwwuS0yabaTG8952gmdGIHPIIjr0uLsUubBkNzeziak1 5uY3BCVSPF26pcxbZKKLAKDiybw6gkTv18qLju8eZMCPzw6mkC2dtj8AIUp/9D0UXnSZ wLqTRRlI9gA92JHJSVhqENryhBrM5s31r09TGw6yjMMRPn0GEyRHa/ylNtXXeTD4eeJJ Trbg==
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-language; bh=c61E+kbuAKAQG9MOwkmJIQy6xUtRkHyt+LbsCl8TJjc=; b=D1eVpaaa38cmgdEpgCOr+TZerXihhRdjT9bC9zpevcgTi3sbr/J5jnERc66B6DIutu emJiln36wAYYEjVs8tceHAQzpR7AqkZkHxThifrl/z0RQSnH0Y1WOnmaQOr5tGhVtG7i fOsBmhvX+/nwzEDZAP4bsjNGFI49gfYGiGXL2NFBNG9f0nxQqhtWIpGIWcfiIIpeSSdq ScF11WLiT3QK1vRG7Evp/1u5g5G0OHrQRPwIdU1Q5zL0H52DeMpWWypXn0ZxUVr8UQLp b85z59/wv5GG3AohKRcnMRlCRCm2tj1bCS6ytiSh7uAOEDe9eq/EXwUl4vAmAKv4BwWa YdCQ==
X-Gm-Message-State: AOUpUlFVhvODtMt7nP5aSmlV8UhyHQEI8oPHumVEdSNRGwMns+OlmXew VfVkyZr7JFX5JmcJvaEkm7utbnpa
X-Google-Smtp-Source: AA+uWPzeFUQW1MgxlKwfQky5lnw7ZeeiWPvycnBdp9oX+ZQS4nPyWwV4n1HwjtFRbMh8HISq8t7HMw==
X-Received: by 2002:ae9:e318:: with SMTP id v24-v6mr151526qkf.299.1533613638537;  Mon, 06 Aug 2018 20:47:18 -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 v192-v6sm255556qkb.0.2018.08.06.20.47.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 20:47:18 -0700 (PDT)
To: Daniel Migault 
Cc: calsify@ietf.org
References:   <708d48bc-e213-1386-ff7b-23a476000774@gmail.com> 
From: Michael Douglass 
Message-ID: 
Date: Mon, 6 Aug 2018 23:47:17 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------E8A6E93A0F037DE4214CF700"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Aug 2018 03:47:23 -0000

This is a multi-part message in MIME format.
--------------E8A6E93A0F037DE4214CF700
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I just posted a version 08 to address the issues in these messages

Thanks - Mike


On 8/6/18 13:44, Daniel Migault wrote:
> Hi,
> Just catching up. Is the current version addressing all comments, or 
> do we expect another version coming in the few next days ?
>
> Yours,
> Daniel
>
> On Wed, May 16, 2018 at 1:33 AM, Michael Douglass 
> > wrote:
>
>     Thank you for the comments - I've submitted a new draft to address
>     these and just realised I didn't address any of Robert's issues.
>
>     I'll deal with those in day or so.
>
>
>     On 5/15/18 23:07, Daniel Migault wrote:
>>     Hi,
>>
>>     Please find some comments. These comments are indicative.
>>
>>     Yours,
>>     Daniel
>>
>>     Abstract:
>>     The header indicates that RFC 5545,and RFC 5546 are updated. This
>>     must be also stated in the Abstract and in the introduction.
>     Some text added
>>
>>
>>     1.  Introduction
>>
>>     """
>>     Current practice is to embed this information as links in the
>>        description or to add x-properties.
>>     """
>>
>>     It is not clear to me how to use x-properties. Is it a notation ?
>>     In addition, I am also wondering if this does not designate the
>>     LABEL property. If that is correct, maybe that could be
>>     explicitly stated to better understand section 5.
>     I've changed the text to refer to non-standard properties and
>     provided a reference to the section in 5545.
>
>     LABEL is a parameter used to provide a human-readable label for
>     properties - something like the alt attribute in html - so no -
>     that is a different usage
>>
>>
>>     The conventions needs to be updated according to RFC 8174
>>
>>        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>>     NOT",
>>        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
>>     "MAY", and
>>        "OPTIONAL" in this document are to be interpreted as described in
>>        [RFC2119].
>     Done
>>
>>     3.  Typed References
>>
>>     """
>>        perhaps
>>        for indexing or the presentation of additional related information
>>        for the user.
>>     """
>>
>>     Thought English is not my natural language, there might be a nit
>>     there.
>>
>>        perhaps
>>        for indexing or presentating the additional related information
>>        to the user.
>>     --
>     Changed to:
>
>     perhaps for indexing or the
>             presenting of additional related information for the user.
>>
>>
>>     """
>>     Using STRUCTURED-LOCATION, information about a number of interesting
>>        locations can be communicated, for example, parking,
>>     restaurants and
>>        the venue.  Servers and clients can retrieve the objects when
>>     storing
>>        the event and use them to index by geographic location.
>>     """
>>
>>     It is not clear from the text that the location information
>>     mentioned above (e.g. address, region, country, postal code) that
>>     motivated the STRUCTURED-LOCATION are part STRUCTURED-LOCATION.
>>     Thus I would also mention them
>>
>>
>>     Using STRUCTURED-LOCATION, information about a number of interesting
>>        locations can be communicated, for example, address, region,
>>     country, postal code as well as other informations such as the
>>     parking, restaurants and
>>        the venue.  Servers and clients can retrieve the objects when
>>     storing
>>        the event and use them to index by geographic location.
>>
>     Done
>>     ---
>>
>>     3.1.2.  Itineraries
>>
>>
>>     """
>>     The contact information can
>>        provide detailed information about the booking agent, the airlines
>>        and car hire companies and the hotel.
>>     """
>>
>>     Looks to me that there is an additional "and".
>     Removed
>>
>>
>>
>>     5.  New Property Parameters
>>
>>     """
>>        This specification makes use of the LABEL property parameter
>>     which is
>>        defined in [RFC7986]
>>     """
>>
>>     My understanding is that the parameters described in this section
>>     apply to the LABEL property.. It seems to me that this is the
>>     first time the LABEL properties and associated parameters are
>>     mentioned in the document. In other words, I have hard time
>>     finding where this section is introduced  in the previous
>>     sections such as the introduction. If I am correct, maybe that
>>     could be clarified in the introduction.
>     LABEL is a parameter - it turns up in the ABNF for a number of the
>     properties defined here. The phrase "property parameter" was
>     pulled out of that spec - from 5545 as well. "LABEL parameter" is
>     a little clearer I think. I'll try that.
>>
>>     It seems to me that the document is structured with a kind of
>>     bottom - up approach. parameters < properties < components. Thus
>>     I am wondering if there are any reasons for not having the
>>     Calendar Components at the very end instead of at the beginning.
>>     I am also wondering if that would not be more easy to read the
>>     document with Participant Types and Resource Types listed within
>>     their respective Properties.
>>
>     I see what you mean now. Makes sense.
>>
>>
>>
>>     On Tue, May 15, 2018 at 1:12 PM, Daniel Migault
>>     >     > wrote:
>>
>>         Hi,
>>
>>         draft-ietf-calext-eventpub-extensions [1] is already on WGLC.
>>         We would like to sufficient reviews to move the document to
>>         the IESG. If you have not yet commented the document, please
>>         provide your feedbacks by May 29 so we can move the document
>>         forward.
>>
>>         Yours,
>>         Calext co-chairs.
>>
>>
>>
>>         [1]
>>         https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/
>>         
>>
>>
>>
>>
>>     _______________________________________________
>>     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
>     
>
>


--------------E8A6E93A0F037DE4214CF700
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
I just posted a version 08 to address the issues in these
      messages

    
Thanks - Mike

    

    

    
On 8/6/18 13:44, Daniel Migault wrote:

    

    

      
      

        
Hi, 

        

        
Just catching up. Is the current version addressing all
          comments, or do we expect another version coming in the few
          next days ?

        


        

        
Yours, 

        

        
Daniel

        

      

      


        
On Wed, May 16, 2018 at 1:33 AM,
          Michael Douglass <mikeadouglass@gmail.com>
          wrote:

          

            

              
Thank you for the comments - I've submitted a new draft
                to address these and just realised I didn't address any
                of Robert's issues.

              
I'll deal with those in day or so.

              

               

                
On
                  5/15/18 23:07, Daniel Migault wrote:

                

              
                

                  

                    
Hi, 

                    

                    


                    

                    
Please find some comments. These comments are
                      indicative.

                    


                    

                    
Yours, 

                    

                    
Daniel

                    


                    

                    
Abstract:

                    
The header indicates that RFC 5545,and RFC 5546
                      are updated. This must be also stated in the
                      Abstract and in the introduction. 

                    

                  

                

               Some text added

                

                  

                    


                    

                    


                    

                    
1.  Introduction

                      

                      """

                      Current practice is to embed this information as
                      links in the

                         description or to add x-properties.

                      """

                      

                      It is not clear to me how to use x-properties. Is
                      it a notation ? In addition, I am also wondering
                      if this does not designate the LABEL property. If
                      that is correct, maybe that could be explicitly
                      stated to better understand section 5.

                    

                  

                

               I've changed the text to refer to non-standard
              properties and provided a reference to the section in
              5545. 

              

              LABEL is a parameter used to provide a human-readable
              label for properties - something like the alt attribute in
              html - so no - that is a different usage

                

                  

                    


                      

                      The conventions needs to be updated according to
                      RFC 8174

                      

                         The key words "MUST", "MUST NOT", "REQUIRED",
                      "SHALL", "SHALL NOT",

                         "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
                      RECOMMENDED", "MAY", and

                         "OPTIONAL" in this document are to be
                      interpreted as described in

                         [RFC2119].

                    

                  

                

               Done

                

                  

                    


                      3.  Typed References

                      

                      """

                         perhaps

                         for indexing or the presentation of additional
                      related information

                         for the user.

                      """

                      

                      Thought English is not my natural language, there
                      might be a nit there. 

                      

                         perhaps

                         for indexing or presentating the additional
                      related information

                         to the user.

                      --

                    

                  

                

               Changed to:

                

                perhaps for indexing or the

                       presenting of additional related
              information for the user.

                

                  

                    


                      

                      """

                      Using STRUCTURED-LOCATION, information about a
                      number of interesting

                         locations can be communicated, for example,
                      parking, restaurants and

                         the venue.  Servers and clients can retrieve
                      the objects when storing

                         the event and use them to index by geographic
                      location.

                      """

                      

                      It is not clear from the text that the location
                      information mentioned above (e.g. address, region,
                      country, postal code) that motivated the
                      STRUCTURED-LOCATION are part STRUCTURED-LOCATION.
                      Thus I would also mention them 

                      

                      

                      Using STRUCTURED-LOCATION, information about a
                      number of interesting

                         locations can be communicated, for example,
                      address, region, country, postal code as well as
                      other informations such as the parking,
                      restaurants and

                         the venue.  Servers and clients can retrieve
                      the objects when storing

                         the event and use them to index by geographic
                      location.

                      

                    

                  

                

               Done

                

                  

                    
---

                      

                      3.1.2.  Itineraries

                      

                      

                      """

                      The contact information can

                         provide detailed information about the booking
                      agent, the airlines

                         and car hire companies and the hotel.

                      """

                      

                      Looks to me that there is an additional "and".

                    

                  

                

               Removed

              

                

                  


                      

                      

                      5.  New Property Parameters

                      

                      """

                         This specification makes use of the LABEL
                      property parameter which is

                         defined in [RFC7986]

                      """

                      

                     My understanding is that the parameters
                    described in this section apply to the LABEL
                    property.. It seems to me that this is the first
                    time the LABEL properties and associated parameters
                    are mentioned in the document. In other words, I
                    have hard time finding where this section is
                    introduced  in the previous sections such as the
                    introduction. If I am correct, maybe that could be
                    clarified in the introduction. 

                  

                

              

              LABEL is a parameter - it turns up in the ABNF for a
              number of the properties defined here. The phrase
              "property parameter" was pulled out of that spec - from
              5545 as well. "LABEL parameter" is a little clearer I
              think. I'll try that.

                

                  

                    


                      It seems to me that the document is structured
                      with a kind of bottom - up approach. parameters
                      < properties < components. Thus I am
                      wondering if there are any reasons for not having
                      the Calendar Components at the very end instead of
                      at the beginning.

                    

                  

                

                

                  

                    
I am also wondering if that would not be more
                      easy to read the document with Participant Types
                      and Resource Types listed within their respective
                      Properties. 

                      

                    

                  

                

               I see what you mean now. Makes sense.

              

                  

                    


                      

                    

                  

                  


                    
On Tue, May 15, 2018 at
                      1:12 PM, Daniel Migault <daniel.migault@ericsson.com>
                      wrote:

                      

                        

                          
Hi, 

                          

                          


                          

                          
draft-ietf-calext-eventpub-extensions
                            [1] is already on WGLC. We would like to
                            sufficient reviews to move the document to
                            the IESG. If you have not yet commented the
                            document, please provide your feedbacks by
                            May 29 so we can move the document forward.
                            

                          

                          


                          

                          
Yours, 

                          

                          
Calext co-chairs.

                          

                          


                          

                          


                          

                          


                          

                          
                        

                      

                    

                    

                  

                  

                  

                  

                
                  
_______________________________________________
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

            

          

        

        

      

    

    

  


--------------E8A6E93A0F037DE4214CF700--


From nobody Tue Aug  7 05:29:41 2018
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 DF0C5130E21 for ; Tue,  7 Aug 2018 05:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 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_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 WwBTFPrHNFnK for ; Tue,  7 Aug 2018 05:29:37 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 22BBF130EB9 for ; Tue,  7 Aug 2018 05:29:36 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id n96-v6so11513208lfi.1 for ; Tue, 07 Aug 2018 05:29:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=iNbvx/4RDh18la27fPpdZD6cHATNVM0Ss1a6CSY8vV8=; b=dtsFI8FKtoFrPAv4kllJLsqrNPyULgIJwFPWI8IxZcDQKiiX8I2gKMoR13F+PblXe/ anDMrHhz9WGxeSlk3tjF5ohjM257GL7CRJh+QV3tl2jbjUOyIntSliF8Oy1h3iIbmy7A zwC9gyjrVEuLG/yWzMCwhpNBKZHPoCqHRT4fSq5t2EQyfhN0CqYLu5IykZ8BSh/Gpu67 iGSG5g2+W+Yo0RPlci8QjvMK+tnTE/wQ0TeiSlSA0gNT7a0hpJiwCmObOchCyyzxykLL a0UcTXQCrzHgNOwVUqq1TQNQrhPWjRxBHuMJS+JdyjV7ciyNvNzCbD8TRMpZHpjTJKOx dVdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=iNbvx/4RDh18la27fPpdZD6cHATNVM0Ss1a6CSY8vV8=; b=i0HmgeDFzyPejSKlwshFarN+hW38bYNRt9TTlT1AyUiw4GJe52UswUPOwCv2eACTK2 qL4qvMPlTiWy5MKwZ/qxGKvpoRw0Gv+8ik9sS3osxpmzvAH3LCq7HD1YdQ5ESnlHEsMr y9tOLaCMbGCthTNo8+ZJgQFSMlncEw9qyG28op23OJwcmz4P7m9l4kOZLHpxmmm7DjZ+ LQ6UTkoPlQaJU5kaeSfUw0zcPT13az0GZ2bLOohasJEzpCklxF0FVcsdLA88fOp9Kfc3 T1M4I4BIuPxLkugnMkLzCXCI8g5dGYGjbNwmEM2GPIenR/n2lFf7eqhG3Lo+Pzj/O760 d97A==
X-Gm-Message-State: AOUpUlFmzuoIKXpvxEZsQLcj48SvUAMflD2OUFgx3oiPKYxTWyzDth0I T6e6T398t9ufZlpv+KUk9fGCbt6UDNLXiuBHZnwUgNPz
X-Google-Smtp-Source: AAOMgpcfJQ8k1j2o55t0pVE/nPbvqtrSuM4FETEyc55SNahEjBmd/oo+uWisnTiw30bv3x70k7eZaIayZBGgEDHXOIw=
X-Received: by 2002:a19:1749:: with SMTP id n70-v6mr13798626lfi.54.1533644975123;  Tue, 07 Aug 2018 05:29:35 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 2002:a2e:5295:0:0:0:0:0 with HTTP; Tue, 7 Aug 2018 05:29:34 -0700 (PDT)
In-Reply-To: <623de6c5-0aa3-1abf-9b05-22304d9fb813@gmail.com>
References:   <708d48bc-e213-1386-ff7b-23a476000774@gmail.com>    <623de6c5-0aa3-1abf-9b05-22304d9fb813@gmail.com>
From: Daniel Migault 
Date: Tue, 7 Aug 2018 08:29:34 -0400
X-Google-Sender-Auth: PpgpnzOTIqSOdVp_9q0yJ8vRSaQ
Message-ID: 
To: Michael Douglass 
Cc: calsify@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f431170572d78bf9"
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Aug 2018 12:29:40 -0000

--000000000000f431170572d78bf9
Content-Type: text/plain; charset="UTF-8"

Hi Thanks for the update Michael!

I think the trick is to simply put in the xml:

This specification updates RFC5545  andRFC5546 by introducing a number
of new iCalendar

Yours,
Daniel

On Mon, Aug 6, 2018 at 11:13 PM, Michael Douglass 
wrote:

>
>
> On 8/6/18 14:52, Daniel Migault wrote:
>
> Hi,
>
> Initiating the shepherd write-up here are my additional comments:
>
> 1) running the nits raises some minor issues so please remove the '[' and
> ']' in the abstract.
>
> OLD:
>
>    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.
>
> NEW:
>
>    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 appears to be an artifact of xml2rfc - there are no square brackets
> in the XML. Is theer some trick to avoiding them? Here's the source:
>
> This specification updates   and by introducing a number of new iCalendar
>
>
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify
>
>

--000000000000f431170572d78bf9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Thanks for the update Michael!

I think the trick is to simply put in the xml:

This specification updates RFC5545  a=
nd
RFC5546=
 by introducing a number of new iCalendar
Yours, 
Daniel

On Mon, Aug 6, 2018 at 11:13 PM, Michael Douglass <=
mikeadouglass@gmail.com> wrote:

 =20
   =20
 =20
  

    


    

    

    
On 8/6/18 14:52, Da=
niel Migault wrote:

    

    

     =20
      

        
Hi, 

        

        


        

        
Initiating the shepherd write-up here are my additional
          comments:

        


        

        
1) running the nits raises some minor issues so please
          remove the '[' and ']' in the abstract.

          

          OLD:

          

          =C2=A0=C2=A0 This specification updates [RFC5545]=C2=A0 and [RFC5=
546] by
          introducing a

          =C2=A0=C2=A0 number of new iCalendar properties and components wh=
ich are
          of

          =C2=A0=C2=A0 particular use for event publishers and in social
          networking.

          

          NEW:

          

          =C2=A0=C2=A0 This specification updates RFC5545 and RFC5546 by
          introducing a

          =C2=A0=C2=A0 number of new iCalendar properties and components wh=
ich are
          of

          =C2=A0=C2=A0 particular use for event publishers and in social
          networking.

          

        

      

    

    This appears to be an artifact of xml2rfc - there are no square
    brackets in the XML. Is theer some trick to avoiding them? Here's
    the source:

    

    
This specification updates <xref target=3D'RFC5545'<=
span style=3D"background-color:#efefef">/>  and
<xref target=3D'=
;RFC5546'/> b=
y introducing a number of new iCalendar



  



_______________________________________________

calsify mailing list

calsify@ietf.org

https://www.ietf.org/mailman/listinfo/calsify<=
br>




--000000000000f431170572d78bf9--


From nobody Tue Aug  7 05:37:36 2018
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 E65B3130E5B for ; Tue,  7 Aug 2018 05:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 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_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 r4i3UBqaIstu for ; Tue,  7 Aug 2018 05:37:31 -0700 (PDT)
Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 30944130FE5 for ; Tue,  7 Aug 2018 05:37:30 -0700 (PDT)
Received: by mail-lj1-x243.google.com with SMTP id f8-v6so13304927ljk.1 for ; Tue, 07 Aug 2018 05:37:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vAV/5tZhzRyaSlqokCOizObsAKUvkr9EXr0bEbQQF60=; b=mDCLrnaHfzIIzIFmgkSQAQYTp6vIYlIgr2njUxPlxMbZYl2OPwvPhlhlMIl3BUD1Ur Ie+fuZ/FULMSN1x6WJFO7QUoHKDXHQPljy3k29cXzyM7kw+TJ6sRtGqf15QPcNQFCcji bzKbj/zoXEZImG5okEdNYbWtawd4fUXCiTHwQHOHL6FP/N93whW14CRxV1GGGzwEgOm0 uujS/viALiyBCG+FkpPMlBzctgJgXt5qrjtk/h1/tAm4gtMNjwrO3+tc8uoLoqoz2Kd1 FjbUfsZzfmcldz5lbEL3d7oMTj7tbO3Z6LE1arODvIcmn9RXPzeBeQKndOnT2S2b+aGU b0pA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vAV/5tZhzRyaSlqokCOizObsAKUvkr9EXr0bEbQQF60=; b=gMhjgLyLyxbb5jGK1Ho3LQ7TycR1I0wz6pmBRNntgqdoEso34bXQ8b0lt+xJWWKjAL KZtTFNE4hPdTsb88lSOs5N4gAFOdADaalWKu0Gd9/1yOqElL5ala/2uACa9qmxR1HK2R uhF078j8iSQq0rARIjjkZuxoqRL6EPU0MPGscVWjZQWmYJpzQw7CXG4Shg3KBq3aPfYV nbijL93E3xL2A91jeizxGiHwuebaGuBA+gjfwVVKaoUFeVPBfC1TlXUcEBrWTuUhyVwf NkiSwOAPGkDT1c4CJt4BKdOBL7RqsdwXdpRqc3l0jn2hkRS/6+j65q06chVKB7G9uIDW YlNg==
X-Gm-Message-State: AOUpUlEHWiEeJlJpkxovDD/lvjUFRABVsnH57ekmnmha0YwEsM2tqU/G 6MeOJ/oVtCGSPEO1wKpASrQtfahX2g5k0HJB8uM=
X-Google-Smtp-Source: AAOMgpew9TfB25LNfwfm+vCVcVf55x/L/fr66Y4Vz4fWRCqYFOcAaNPiC7nDMoGQmWkInQ//UhziXZy9ZTx4O81D3rQ=
X-Received: by 2002:a2e:750d:: with SMTP id q13-v6mr15049773ljc.148.1533645448426;  Tue, 07 Aug 2018 05:37:28 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 2002:a2e:5295:0:0:0:0:0 with HTTP; Tue, 7 Aug 2018 05:37:27 -0700 (PDT)
In-Reply-To: 
References:   <708d48bc-e213-1386-ff7b-23a476000774@gmail.com>    
From: Daniel Migault 
Date: Tue, 7 Aug 2018 08:37:27 -0400
X-Google-Sender-Auth: VgW5U-Ao53SF6xZo2m-UPXz4oUA
Message-ID: 
To: Michael Douglass 
Cc: calsify@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002a3a410572d7a8a9"
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Aug 2018 12:37:35 -0000

--0000000000002a3a410572d7a8a9
Content-Type: text/plain; charset="UTF-8"

Hi,

The abstract should also remove the reference to 5546 as the ref has been
removed from header and introduction.

Yours,
Daniel

On Mon, Aug 6, 2018 at 11:36 PM, Michael Douglass 
wrote:

>
>
> On 8/6/18 14:52, Daniel Migault wrote:
>
> Hi,
>
> Initiating the shepherd write-up here are my additional comments:
>
> 1) running the nits raises some minor issues so please remove the '[' and
> ']' in the abstract.
>
> OLD:
>
>    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.
>
> NEW:
>
>    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.
>
> See previous message - seems to be xml2rfc
>
>
> 2)
>
> I do not see the following reference mentioned in the text. Maybe it could
> be removed. If you prefer to keep it, maybe informational may be the right
> category for it.
>
>    [W3C.REC-xml-20060816]
>               Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
>               F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
>               Edition)", World Wide Web Consortium Recommendation REC-
>               xml-20060816, August 2006,
>               .
>
> Removed
>
>
> 3) I do not see the update of RFC 5546 being discussed in the
> introduction. Could you please add some text ?
>
>
> Removed the updates reference. 5546 is mentioned but I don't belieev
> updated in any way.
>
>
> 4) IANA section,
>
> I suggest to add the URL to the IANA registry as an informative reference.
> https://www.iana.org/assignments/icalendar/icalendar.xhtml#properties
>
> Done
>
>
> section 12.1.{1,2,3} I would remove the term "Registration" to make sure
> the title of the section match the registry. Similarly, I would replace
> Property by Properties to match the registries.
>
> Done
>
>
> Yours,
> Daniel
>
> Thanks - Mike
>
>
> On Mon, Aug 6, 2018 at 1:58 PM, Daniel Migault <
> daniel.migault@ericsson.com> wrote:
>
>> In order to get a rough idea of the consensus to move that draft forward
>> to the IESG, I would also appreciate your support on approving the
>> document. Please let us know if you believe the document is ready to be
>> moved forward.
>>
>> If you have implemented it, it would also be much appreciate to write the
>> review.
>>
>> Yours,
>> Daniel
>>
>> On Mon, Aug 6, 2018 at 1:44 PM, Daniel Migault <
>> daniel.migault@ericsson.com> wrote:
>>
>>> Hi,
>>> Just catching up. Is the current version addressing all comments, or do
>>> we expect another version coming in the few next days ?
>>>
>>> Yours,
>>> Daniel
>>>
>>> On Wed, May 16, 2018 at 1:33 AM, Michael Douglass <
>>> mikeadouglass@gmail.com> wrote:
>>>
>>>> Thank you for the comments - I've submitted a new draft to address
>>>> these and just realised I didn't address any of Robert's issues.
>>>>
>>>> I'll deal with those in day or so.
>>>>
>>>> On 5/15/18 23:07, Daniel Migault wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please find some comments. These comments are indicative.
>>>>
>>>> Yours,
>>>> Daniel
>>>>
>>>> Abstract:
>>>> The header indicates that RFC 5545,and RFC 5546 are updated. This must
>>>> be also stated in the Abstract and in the introduction.
>>>>
>>>> Some text added
>>>>
>>>>
>>>>
>>>> 1.  Introduction
>>>>
>>>> """
>>>> Current practice is to embed this information as links in the
>>>>    description or to add x-properties.
>>>> """
>>>>
>>>> It is not clear to me how to use x-properties. Is it a notation ? In
>>>> addition, I am also wondering if this does not designate the LABEL
>>>> property. If that is correct, maybe that could be explicitly stated to
>>>> better understand section 5.
>>>>
>>>> I've changed the text to refer to non-standard properties and provided
>>>> a reference to the section in 5545.
>>>>
>>>> LABEL is a parameter used to provide a human-readable label for
>>>> properties - something like the alt attribute in html - so no - that is a
>>>> different usage
>>>>
>>>>
>>>>
>>>> The conventions needs to be updated according to RFC 8174
>>>>
>>>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>>>    "OPTIONAL" in this document are to be interpreted as described in
>>>>    [RFC2119].
>>>>
>>>> Done
>>>>
>>>>
>>>> 3.  Typed References
>>>>
>>>> """
>>>>    perhaps
>>>>    for indexing or the presentation of additional related information
>>>>    for the user.
>>>> """
>>>>
>>>> Thought English is not my natural language, there might be a nit there.
>>>>
>>>>    perhaps
>>>>    for indexing or presentating the additional related information
>>>>    to the user.
>>>> --
>>>>
>>>> Changed to:
>>>>
>>>> perhaps for indexing or the
>>>>         presenting of additional related information for the user.
>>>>
>>>>
>>>>
>>>> """
>>>> Using STRUCTURED-LOCATION, information about a number of interesting
>>>>    locations can be communicated, for example, parking, restaurants and
>>>>    the venue.  Servers and clients can retrieve the objects when storing
>>>>    the event and use them to index by geographic location.
>>>> """
>>>>
>>>> It is not clear from the text that the location information mentioned
>>>> above (e.g. address, region, country, postal code) that motivated the
>>>> STRUCTURED-LOCATION are part STRUCTURED-LOCATION. Thus I would also mention
>>>> them
>>>>
>>>>
>>>> Using STRUCTURED-LOCATION, information about a number of interesting
>>>>    locations can be communicated, for example, address, region,
>>>> country, postal code as well as other informations such as the parking,
>>>> restaurants and
>>>>    the venue.  Servers and clients can retrieve the objects when storing
>>>>    the event and use them to index by geographic location.
>>>>
>>>> Done
>>>>
>>>> ---
>>>>
>>>> 3.1.2.  Itineraries
>>>>
>>>>
>>>> """
>>>> The contact information can
>>>>    provide detailed information about the booking agent, the airlines
>>>>    and car hire companies and the hotel.
>>>> """
>>>>
>>>> Looks to me that there is an additional "and".
>>>>
>>>> Removed
>>>>
>>>>
>>>>
>>>>
>>>> 5.  New Property Parameters
>>>>
>>>> """
>>>>    This specification makes use of the LABEL property parameter which is
>>>>    defined in [RFC7986]
>>>> """
>>>>
>>>> My understanding is that the parameters described in this section apply
>>>> to the LABEL property.. It seems to me that this is the first time the
>>>> LABEL properties and associated parameters are mentioned in the document.
>>>> In other words, I have hard time finding where this section is introduced
>>>> in the previous sections such as the introduction. If I am correct, maybe
>>>> that could be clarified in the introduction.
>>>>
>>>> LABEL is a parameter - it turns up in the ABNF for a number of the
>>>> properties defined here. The phrase "property parameter" was pulled out of
>>>> that spec - from 5545 as well. "LABEL parameter" is a little clearer I
>>>> think. I'll try that.
>>>>
>>>>
>>>> It seems to me that the document is structured with a kind of bottom -
>>>> up approach. parameters < properties < components. Thus I am wondering if
>>>> there are any reasons for not having the Calendar Components at the very
>>>> end instead of at the beginning.
>>>>
>>>> I am also wondering if that would not be more easy to read the document
>>>> with Participant Types and Resource Types listed within their respective
>>>> Properties.
>>>>
>>>> I see what you mean now. Makes sense.
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, May 15, 2018 at 1:12 PM, Daniel Migault <
>>>> daniel.migault@ericsson.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> draft-ietf-calext-eventpub-extensions [1] is already on WGLC. We
>>>>> would like to sufficient reviews to move the document to the IESG. If you
>>>>> have not yet commented the document, please provide your feedbacks by May
>>>>> 29 so we can move the document forward.
>>>>>
>>>>> Yours,
>>>>> Calext co-chairs.
>>>>>
>>>>>
>>>>>
>>>>> [1] https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-
>>>>> extensions/
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
>

--0000000000002a3a410572d7a8a9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi, 

The abstract should=
 also remove the reference to 5546 as the ref has been removed from header =
and introduction. 

Yours, 
Danie=
l
 

On Mon, Aug 6, 2018 at 11:36 PM, Michael Douglass <mikeadouglass@gm=
ail.com> wrote:

 =20
   =20
 =20
  

    


    

    

    
On 8/6/18 14:52, D=
aniel Migault wrote:

    

    

     =20
      

        
Hi, 

        

        


        

        
Initiating the shepherd write-up here are my additional
          comments:

        


        

        
1) running the nits raises some minor issues so please
          remove the '[' and ']' in the abstract.

          

          OLD:

          

          =C2=A0=C2=A0 This specification updates [RFC5545]=C2=A0 and [RFC5=
546] by
          introducing a

          =C2=A0=C2=A0 number of new iCalendar properties and components wh=
ich are
          of

          =C2=A0=C2=A0 particular use for event publishers and in social
          networking.

          

          NEW:

          

          =C2=A0=C2=A0 This specification updates RFC5545 and RFC5546 by
          introducing a

          =C2=A0=C2=A0 number of new iCalendar properties and components wh=
ich are
          of

          =C2=A0=C2=A0 particular use for event publishers and in social
          networking.

        

      

    

    See previous message - seems to be xml2rfc

    

      

        


          2)

          

          I do not see the following reference mentioned in the text.
          Maybe it could be removed. If you prefer to keep it, maybe
          informational may be the right category for it.

          

          =C2=A0=C2=A0 [W3C.REC-xml-20060816]

          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 Bray, T., Paoli, J., Sperberg-McQueen, M.,
          Maler, E., and

          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 F. Yergeau, "Extensible Markup Language (XML)
          1.0 (Fourth

          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 Edition)", World Wide Web Consortium
          Recommendation REC-

          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 xml-20060816, August 2006,

          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 <http://www.w3.org/TR/2006/REC-xml-20060816>.<=
br>
          

        

      

    

    Removed

    

      

        


          3) I do not see the update of RFC 5546 being discussed in the
          introduction. Could you please add some text ?

          =C2=A0

        

      

    

    Removed the updates reference. 5546 is mentioned but I don't beliee=
v
    updated in any way.

    

      

        


          4) IANA section,

          

          I suggest to add the URL to the IANA registry as an
          informative reference.

          https://www.iana.org/assignments/ic=
alendar/icalendar.xhtml#properties

          

        

      

    

    Done

    

      

        


          section 12.1.{1,2,3} I would remove the term "Registration&q=
uot; to
          make sure the title of the section match the registry.
          Similarly, I would replace Property by Properties to match the
          registries.

        

      

    

    Done

    

      

        


        

        
Yours, 

        

        
Daniel

        

      

    

    Thanks - Mike


    

      


        
On Mon, Aug 6, 2018 at 1:58 PM, Daniel
          Migault <daniel.migault@ericsson.com>
          wrote:

          

            

              
In order to get a rough idea of the consensus to move
                that draft forward to the IESG, I would also appreciate
                your support on approving the document. Please let us
                know if you believe the document is ready to be moved
                forward. 

              

              


              

              
If you have implemented it, it would also be much
                appreciate to write the review. 

              

              


              

              
Yours, 

              

              
Daniel

              

            

            

              

                


                  
On Mon, Aug 6, 2018 at 1:44
                    PM, Daniel Migault <daniel.migault@ericsson.=
com>
                    wrote:

                    

                      

                        
Hi, 

                        

                        
Just catching up. Is the current version
                          addressing all comments, or do we expect
                          another version coming in the few next days ?
                        


                        

                        
Yours, 

                        

                        
Daniel

                        

                      

                      

                        

                          


                            
On Wed, May 16,
                              2018 at 1:33 AM, Michael Douglass <m=
ikeadouglass@gmail.com>
                              wrote:

                              

                                

                                  
Thank you for the comments - I've
                                    submitted a new draft to address
                                    these and just realised I didn't
                                    address any of Robert's issues.

                                  
I'll deal with those in day or so.=


                                  

                                   

                                    

                                      

                                        
Hi, 

                                        

                                        


                                        

                                        
Please find some comments.
                                          These comments are indicative.
                                        


                                        

                                        
Yours, 

                                        

                                        
Daniel

                                        


                                        

                                        
Abstract:

                                        
The header indicates that
                                          RFC 5545,and RFC 5546 are
                                          updated. This must be also
                                          stated in the Abstract and in
                                          the introduction. 

                                        

                                      

                                    

                                   Some text added

                                    

                                      

                                        


                                        

                                        


                                        

                                        
1.=C2=A0 Introduction

                                          

                                          """

                                          Current practice is to embed
                                          this information as links in
                                          the

                                          =C2=A0=C2=A0 description or to ad=
d
                                          x-properties.

                                          """

                                          

                                          It is not clear to me how to
                                          use x-properties. Is it a
                                          notation ? In addition, I am
                                          also wondering if this does
                                          not designate the LABEL
                                          property. If that is correct,
                                          maybe that could be explicitly
                                          stated to better understand
                                          section 5.

                                        

                                      

                                    

                                   I've changed the text to refe=
r
                                  to non-standard properties and
                                  provided a reference to the section in
                                  5545. 

                                  

                                  LABEL is a parameter used to provide a
                                  human-readable label for properties -
                                  something like the alt attribute in
                                  html - so no - that is a different
                                  usage

                                    

                                      

                                        


                                          

                                          The conventions needs to be
                                          updated according to RFC 8174

                                          

                                          =C2=A0=C2=A0 The key words "=
MUST", "MUST
                                          NOT", "REQUIRED", =
"SHALL",
                                          "SHALL NOT",

                                          =C2=A0=C2=A0 "SHOULD", =
"SHOULD NOT",
                                          "RECOMMENDED", "NO=
T
                                          RECOMMENDED", "MAY"=
;, and

                                          =C2=A0=C2=A0 "OPTIONAL"=
 in this document
                                          are to be interpreted as
                                          described in

                                          =C2=A0=C2=A0 [RFC2119].

                                        

                                      

                                    

                                   Done

                                    

                                      

                                        


                                          3.=C2=A0 Typed References

                                          

                                          """

                                          =C2=A0=C2=A0 perhaps

                                          =C2=A0=C2=A0 for indexing or the
                                          presentation of additional
                                          related information

                                          =C2=A0=C2=A0 for the user.

                                          """

                                          

                                          Thought English is not my
                                          natural language, there might
                                          be a nit there. 

                                          

                                          =C2=A0=C2=A0 perhaps

                                          =C2=A0=C2=A0 for indexing or
                                          presentating the additional
                                          related information

                                          =C2=A0=C2=A0 to the user.

                                          --

                                        

                                      

                                    

                                   Changed to:

                                    

                                    perhaps for indexing or the

                                   =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 presenting of
                                  additional related information for the
                                  user.

                                    

                                      

                                        


                                          

                                          """

                                          Using STRUCTURED-LOCATION,
                                          information about a number of
                                          interesting

                                          =C2=A0=C2=A0 locations can be
                                          communicated, for example,
                                          parking, restaurants and

                                          =C2=A0=C2=A0 the venue.=C2=A0 Ser=
vers and
                                          clients can retrieve the
                                          objects when storing

                                          =C2=A0=C2=A0 the event and use th=
em to
                                          index by geographic location.

                                          """

                                          

                                          It is not clear from the text
                                          that the location information
                                          mentioned above (e.g. address,
                                          region, country, postal code)
                                          that motivated the
                                          STRUCTURED-LOCATION are part
                                          STRUCTURED-LOCATION. Thus I
                                          would also mention them 

                                          

                                          

                                          Using STRUCTURED-LOCATION,
                                          information about a number of
                                          interesting

                                          =C2=A0=C2=A0 locations can be
                                          communicated, for example,
                                          address, region, country,
                                          postal code as well as other
                                          informations such as the
                                          parking, restaurants and

                                          =C2=A0=C2=A0 the venue.=C2=A0 Ser=
vers and
                                          clients can retrieve the
                                          objects when storing

                                          =C2=A0=C2=A0 the event and use th=
em to
                                          index by geographic location.

                                          

                                        

                                      

                                    

                                   Done

                                    

                                      

                                        
---

                                          

                                          3.1.2.=C2=A0 Itineraries

                                          

                                          

                                          """

                                          The contact information can

                                          =C2=A0=C2=A0 provide detailed
                                          information about the booking
                                          agent, the airlines

                                          =C2=A0=C2=A0 and car hire compani=
es and
                                          the hotel.

                                          """

                                          

                                          Looks to me that there is an
                                          additional "and".

                                        

                                      

                                    

                                   Removed

                                  

                                    

                                      


                                          

                                          

                                          5.=C2=A0 New Property Parameters<=
br>
                                          

                                          """

                                          =C2=A0=C2=A0 This specification m=
akes
                                          use of the LABEL property
                                          parameter which is

                                          =C2=A0=C2=A0 defined in [RFC7986]=


                                          """

                                          

                                         My understanding is that
                                        the parameters described in this
                                        section apply to the LABEL
                                        property.. It seems to me that
                                        this is the first time the LABEL
                                        properties and associated
                                        parameters are mentioned in the
                                        document. In other words, I have
                                        hard time finding where this
                                        section is introduced=C2=A0 in the
                                        previous sections such as the
                                        introduction. If I am correct,
                                        maybe that could be clarified in
                                        the introduction. 

                                      

                                    

                                  

                                  LABEL is a parameter - it turns up in
                                  the ABNF for a number of the
                                  properties defined here. The phrase
                                  "property parameter" was pulled=
 out of
                                  that spec - from 5545 as well. "LABE=
L
                                  parameter" is a little clearer I
                                  think. I'll try that.

                                    

                                      

                                        


                                          It seems to me that the
                                          document is structured with a
                                          kind of bottom - up approach.
                                          parameters < properties
                                          < components. Thus I am
                                          wondering if there are any
                                          reasons for not having the
                                          Calendar Components at the
                                          very end instead of at the
                                          beginning.

                                        

                                      

                                    

                                    

                                      

                                        
I am also wondering if that
                                          would not be more easy to read
                                          the document with Participant
                                          Types and Resource Types
                                          listed within their respective
                                          Properties. 

                                          

                                        

                                      

                                    

                                   I see what you mean now. Makes
                                  sense.

                                  

                                      

                                        


                                          

                                        

                                      

                                      


                                        
On Tue,
                                          May 15, 2018 at 1:12 PM,
                                          Daniel Migault =
<daniel=
.migault@ericsson.com>
                                          wrote:

                                          

                                            

                                              
Hi, 

                                              

                                              


                                              

                                              
draft-ietf-calext-eventp=
ub-extensions
                                                [1] is already on WGLC.
                                                We would like to
                                                sufficient reviews to
                                                move the document to the
                                                IESG. If you have not
                                                yet commented the
                                                document, please provide
                                                your feedbacks by May 29
                                                so we can move the
                                                document forward. 

                                              

                                              


                                              

                                              
Yours, 

                                              

                                              
Calext co-chairs.

                                              

                                              


                                              

                                              


                                              

                                              


                                              

                                              
                                            

                                          

                                        

                                        

                                      

                                      

                                      

                                      

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


                                    

                                  

                                

                                

                                ______________________________________=
_________

                                calsify mailing list

                                calsify@ietf.org

                                https://www.ietf.org/ma=
ilman/listinfo/calsify

                                

                              

                            

                            

                          

                        

                      

                    

                  

                  

                

              

            

          

        

        

      

    
    

  


_______________________________________________

calsify mailing list

calsify@ietf.org

https://www.ietf.org/mailman/listinfo/calsify<=
br>




--0000000000002a3a410572d7a8a9--


From nobody Tue Aug  7 05:53:28 2018
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 38B9E128CFD for ; Tue,  7 Aug 2018 05:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 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_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 OoN4wORKfNUq for ; Tue,  7 Aug 2018 05:53:24 -0700 (PDT)
Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 ABADD124BE5 for ; Tue,  7 Aug 2018 05:53:23 -0700 (PDT)
Received: by mail-lf1-x141.google.com with SMTP id a134-v6so11557734lfe.6 for ; Tue, 07 Aug 2018 05:53:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=ahTmPdevjgtlTSdPvOXC8zSp8FIqKHAoGDFqY4aCYBc=; b=qKhmXmprf2CYvF/ahWIqlDGXBLafX/O/WAYUhEOKOhj7FxXnGNt74vRcTq2uOA8h5b 6OmF03Kyheocp5xnQjhx+4F/lQYlHSwdr69UU0/MIDm2/qDkG5S3iWKq4hapknbogztK FgHuILKLYxsVEh45uMLSK9t2mYgiju1HxV+GqnYeZwiF9VYjODgIHvVJzZpNDWZZflem frpIpTYZA+bb6fN/5GAFidhhNnTay9oJZnPhTJLQXGMBWKJOi7+RZnm2ldY6hiYYbQVu NaWJ9Z33/Jh0mY1FFG3tEdpZJJ4KTvEoVwLdV73GOlwNmx4T+NK/szY7Y+CQ3wbmI7nR l2yQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=ahTmPdevjgtlTSdPvOXC8zSp8FIqKHAoGDFqY4aCYBc=; b=gcnJiANmT+qbtXW86wU6dJ6Gm4nz/w6XxyNWcV8A/R0ESUkkQo5o15U4PLBDLdaWQu vWyMWHaQtDzdLlAcck5lWWGu8E4/M6kQ3tstJEA389vgXOqYzAh/9IdAZ15NffBw3T1V eJiXjgQyYyESpu/8MEb9sp+7Y1jpwWlx2tX/k+NPZr45VJaYhr5A4iG7A3wgOKEYA2r2 bz4SefJBQrMa076D8S8E7QzvTqpKnv3W/E9XMXvFyJld2CaQZV9P6K7sIa63bRuVa33E o0juTNrTJbfSInxJIpSRp9a8+J5GJw43gfCxRfnNM7nhNuxSa34JtooV4N0en1QubopJ 0vrA==
X-Gm-Message-State: AOUpUlHPBw+6CTwIFWHLne1laKRrXM1HG0LDRzoR+u/grh5Lgs0Fo3dM w6Mmahu86kaIrF6RD03LkplGi5mDzRnlJg/BKwvRuw==
X-Google-Smtp-Source: AAOMgpcotwH4mDhnjgqFX/OPefi5q7x2zQmDkmsfjZsEcAGAc4U4mQP/B1lqpvsHrjxS0xUFd6NuISDE26sqe3po7qo=
X-Received: by 2002:a19:d095:: with SMTP id h143-v6mr13919946lfg.16.1533646401622;  Tue, 07 Aug 2018 05:53:21 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 2002:a2e:5295:0:0:0:0:0 with HTTP; Tue, 7 Aug 2018 05:53:20 -0700 (PDT)
In-Reply-To: <153361352682.26812.17456909195532930218@ietfa.amsl.com>
References: <153361352682.26812.17456909195532930218@ietfa.amsl.com>
From: Daniel Migault 
Date: Tue, 7 Aug 2018 08:53:20 -0400
X-Google-Sender-Auth: JBronZjrFX8oFG9USdU_ShXcb5g
Message-ID: 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary="000000000000fad7420572d7e04b"
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.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Aug 2018 12:53:26 -0000

--000000000000fad7420572d7e04b
Content-Type: text/plain; charset="UTF-8"

Dear WG,

The IETF process requires more transparency. As a result, it would help if
we could have a few reviews as well as some feed backs/position/support of
the draft  from the Calconnect community. If you have any plan to implement
it, informing us is also appreciated.

If statement on a public list might be problematic, you can send me a
private email as well or you can also "proxy" though a Calconnect member.
Let me know what could be you preferred way.

Yours,
Daniel

On Mon, Aug 6, 2018 at 11:45 PM,  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
>

--000000000000fad7420572d7e04b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Dear WG, 

The IETF proce=
ss requires more transparency. As a result, it would help if we could have =
a few reviews as well as some feed backs/position/support of the draft=C2=
=A0 from the Calconnect community. If you have any plan to implement it, in=
forming us is also appreciated.=C2=A0 

If stat=
ement on a public list might be problematic, you can send me a private emai=
l as well or you can also "proxy" though a Calconnect member. Let=
 me know what could be you preferred way.=C2=A0 =C2=A0 

<=
/div>
Yours, 
Daniel=C2=A0 

On Mon, Aug 6, 2018 at 11:45 PM=
,  <internet-drafts@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Calendaring Extensions WG of the IETF.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 Event Publishing Extensions to iCalendar

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Mich=
ael Douglass

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-calext-eventpub-extensions-08.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 32

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2018-08-06



Abstract:

=C2=A0 =C2=A0This specification updates [RFC5545] and [RFC5546] by introduc=
ing a

=C2=A0 =C2=A0number of new iCalendar properties and components which are of=


=C2=A0 =C2=A0particular use for event publishers and in social networking.<=
br>


=C2=A0 =C2=A0This specification also defines a new STRUCTURED-DATA property=
 for

=C2=A0 =C2=A0iCalendar [RFC5545] to allow for data that is directly pertine=
nt to

=C2=A0 =C2=A0an 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.ie=
tf.org/doc/html/draft-ietf-calext-eventpub-extensions-08



A diff from the previous version is available at:

https://www.ietf.org/rfc=
diff?url2=3Ddraft-ietf-calext-eventpub-extensions-08





Please note that it may take a couple of minutes from the time of submissio=
n

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<=
br>




--000000000000fad7420572d7e04b--


From nobody Tue Aug  7 14:05:22 2018
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 15FB41310E4 for ; Tue,  7 Aug 2018 14:05:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 yfumG-kr4RZM for ; Tue,  7 Aug 2018 14:05:12 -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 757D41310E1 for ; Tue,  7 Aug 2018 14:05:10 -0700 (PDT)
Received: by mail-qt0-x235.google.com with SMTP id w26-v6so79099qto.5 for ; Tue, 07 Aug 2018 14:05:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Ebp3fwLyiikuXUnhpngCP5XajGuN2pvgL237zjvAMvg=; b=ATpSHhUXlUnwG5JruPBAe/YUq4RgjEW3XCpRmsWzcWFdezZZcH9J71YS38J89VRPTu xhAE5JGm4ugasJGO3LaMMVbtX9/NX/K/vgD9JWqWCVFyKYfjD3dwf97IcJ42V42u7vUG FhetotskLqnlPwb51INiobmS+RpGj+a0vVD7cVi3il+KNRXd3WMbEMBKiJL7qUjCKDl6 xoGLreWJnZZf1NuAkSXhotAnL/jq/TfCMw9eojWti13o1rQW1UJSiHf/ON9MrlEisI2y eUk3L/Q7dhB6na2oRYR64z7TSrYH7bxBFarMaooDj2eTuXcBxQY6NjJpm5JS52kH57tW Jrtw==
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-language; bh=Ebp3fwLyiikuXUnhpngCP5XajGuN2pvgL237zjvAMvg=; b=bJYMCm7pLd/jGrxEpXC5j3liKG7iqbK8QzZr7BjY/dHnnDSEncmL/BOjMLqzLBX6UW Cr+cziTDNGGSpvxsVGd2yGbSivUiJDIzkszL4Qasq7b3ATZA4eObG7NQBX2DIbodmFVM akVOF1fqre0I/1qn9H9ZTDOQ2OIhAKY66/mpX+5wuWwThX2vFnq60+KSQPyfoHCxeDtn JhtlplxCbdWbdK9pGFOg9dJqxnPP+Bi+78zL352Onh5rL4Ecl3hR8e6EYsQV9yDe1aYz FtymfgLloZVDpKcemRHsthKD6ZVIxWoCam6A+9jC3ivR/rv/Ylw4rASz21Q3/o5GVNzI kicA==
X-Gm-Message-State: AOUpUlGfBd2nLnJd3PZVuVDpnUk1KeBNPxwAUjFoxcRYg+qINgq9xLn7 /dAiEjV51odTA7Rgv0X9zwkgdAxL
X-Google-Smtp-Source: AA+uWPzHSKv2FXMeWh9ot+On3A/jgCRKdNP+7OgSfuEI0WDWOhFVWIB6KxX/K7zWFXQ4w+XOhLtwFA==
X-Received: by 2002:ac8:3615:: with SMTP id m21-v6mr41521qtb.297.1533675909384;  Tue, 07 Aug 2018 14:05:09 -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 c184-v6sm1358304qkd.43.2018.08.07.14.05.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Aug 2018 14:05:08 -0700 (PDT)
To: Daniel Migault 
Cc: calsify@ietf.org
References:   <708d48bc-e213-1386-ff7b-23a476000774@gmail.com>     
From: Michael Douglass 
Message-ID: <297e6b6e-5d5c-438b-a0ae-aa7fe3533116@gmail.com>
Date: Tue, 7 Aug 2018 17:05:07 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------9521B67DC3F05EA452553915"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Aug 2018 21:05:19 -0000

This is a multi-part message in MIME format.
--------------9521B67DC3F05EA452553915
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

The text references 5546 because implementors need to understand how 
this is made backwards compatible with that spec. Shoudl that be an 
informative reference?

e.g.

Section 3.1.1

There may be an iTip [RFC5546] meeting request for the piano tuner
who will arrive before the performance.  Other members of staff may



On 8/7/18 08:37, Daniel Migault wrote:
> Hi,
>
> The abstract should also remove the reference to 5546 as the ref has 
> been removed from header and introduction.
>
> Yours,
> Daniel
>
> On Mon, Aug 6, 2018 at 11:36 PM, Michael Douglass 
> > wrote:
>
>
>
>     On 8/6/18 14:52, Daniel Migault wrote:
>>     Hi,
>>
>>     Initiating the shepherd write-up here are my additional comments:
>>
>>     1) running the nits raises some minor issues so please remove the
>>     '[' and ']' in the abstract.
>>
>>     OLD:
>>
>>        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.
>>
>>     NEW:
>>
>>        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.
>     See previous message - seems to be xml2rfc
>>
>>     2)
>>
>>     I do not see the following reference mentioned in the text. Maybe
>>     it could be removed. If you prefer to keep it, maybe
>>     informational may be the right category for it.
>>
>>        [W3C.REC-xml-20060816]
>>                   Bray, T., Paoli, J., Sperberg-McQueen, M., Maler,
>>     E., and
>>                   F. Yergeau, "Extensible Markup Language (XML) 1.0
>>     (Fourth
>>                   Edition)", World Wide Web Consortium Recommendation
>>     REC-
>>                   xml-20060816, August 2006,
>>                   >     >.
>>
>     Removed
>>
>>     3) I do not see the update of RFC 5546 being discussed in the
>>     introduction. Could you please add some text ?
>>
>     Removed the updates reference. 5546 is mentioned but I don't
>     belieev updated in any way.
>>
>>     4) IANA section,
>>
>>     I suggest to add the URL to the IANA registry as an informative
>>     reference.
>>     https://www.iana.org/assignments/icalendar/icalendar.xhtml#properties
>>     
>>
>     Done
>>
>>     section 12.1.{1,2,3} I would remove the term "Registration" to
>>     make sure the title of the section match the registry. Similarly,
>>     I would replace Property by Properties to match the registries.
>     Done
>>
>>     Yours,
>>     Daniel
>     Thanks - Mike
>
>>
>>     On Mon, Aug 6, 2018 at 1:58 PM, Daniel Migault
>>     >     > wrote:
>>
>>         In order to get a rough idea of the consensus to move that
>>         draft forward to the IESG, I would also appreciate your
>>         support on approving the document. Please let us know if you
>>         believe the document is ready to be moved forward.
>>
>>         If you have implemented it, it would also be much appreciate
>>         to write the review.
>>
>>         Yours,
>>         Daniel
>>
>>         On Mon, Aug 6, 2018 at 1:44 PM, Daniel Migault
>>         >         > wrote:
>>
>>             Hi,
>>             Just catching up. Is the current version addressing all
>>             comments, or do we expect another version coming in the
>>             few next days ?
>>
>>             Yours,
>>             Daniel
>>
>>             On Wed, May 16, 2018 at 1:33 AM, Michael Douglass
>>             >             > wrote:
>>
>>                 Thank you for the comments - I've submitted a new
>>                 draft to address these and just realised I didn't
>>                 address any of Robert's issues.
>>
>>                 I'll deal with those in day or so.
>>
>>
>>                 On 5/15/18 23:07, Daniel Migault wrote:
>>>                 Hi,
>>>
>>>                 Please find some comments. These comments are
>>>                 indicative.
>>>
>>>                 Yours,
>>>                 Daniel
>>>
>>>                 Abstract:
>>>                 The header indicates that RFC 5545,and RFC 5546 are
>>>                 updated. This must be also stated in the Abstract
>>>                 and in the introduction.
>>                 Some text added
>>>
>>>
>>>                 1. Introduction
>>>
>>>                 """
>>>                 Current practice is to embed this information as
>>>                 links in the
>>>                    description or to add x-properties.
>>>                 """
>>>
>>>                 It is not clear to me how to use x-properties. Is it
>>>                 a notation ? In addition, I am also wondering if
>>>                 this does not designate the LABEL property. If that
>>>                 is correct, maybe that could be explicitly stated to
>>>                 better understand section 5.
>>                 I've changed the text to refer to non-standard
>>                 properties and provided a reference to the section in
>>                 5545.
>>
>>                 LABEL is a parameter used to provide a human-readable
>>                 label for properties - something like the alt
>>                 attribute in html - so no - that is a different usage
>>>
>>>
>>>                 The conventions needs to be updated according to RFC
>>>                 8174
>>>
>>>                    The key words "MUST", "MUST NOT", "REQUIRED",
>>>                 "SHALL", "SHALL NOT",
>>>                    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
>>>                 RECOMMENDED", "MAY", and
>>>                    "OPTIONAL" in this document are to be interpreted
>>>                 as described in
>>>                    [RFC2119].
>>                 Done
>>>
>>>                 3.  Typed References
>>>
>>>                 """
>>>                    perhaps
>>>                    for indexing or the presentation of additional
>>>                 related information
>>>                    for the user.
>>>                 """
>>>
>>>                 Thought English is not my natural language, there
>>>                 might be a nit there.
>>>
>>>                    perhaps
>>>                    for indexing or presentating the additional
>>>                 related information
>>>                    to the user.
>>>                 --
>>                 Changed to:
>>
>>                 perhaps for indexing or the
>>                 presenting of additional related information for the
>>                 user.
>>>
>>>
>>>                 """
>>>                 Using STRUCTURED-LOCATION, information about a
>>>                 number of interesting
>>>                    locations can be communicated, for example,
>>>                 parking, restaurants and
>>>                    the venue. Servers and clients can retrieve the
>>>                 objects when storing
>>>                    the event and use them to index by geographic
>>>                 location.
>>>                 """
>>>
>>>                 It is not clear from the text that the location
>>>                 information mentioned above (e.g. address, region,
>>>                 country, postal code) that motivated the
>>>                 STRUCTURED-LOCATION are part STRUCTURED-LOCATION.
>>>                 Thus I would also mention them
>>>
>>>
>>>                 Using STRUCTURED-LOCATION, information about a
>>>                 number of interesting
>>>                    locations can be communicated, for example,
>>>                 address, region, country, postal code as well as
>>>                 other informations such as the parking, restaurants and
>>>                    the venue. Servers and clients can retrieve the
>>>                 objects when storing
>>>                    the event and use them to index by geographic
>>>                 location.
>>>
>>                 Done
>>>                 ---
>>>
>>>                 3.1.2. Itineraries
>>>
>>>
>>>                 """
>>>                 The contact information can
>>>                    provide detailed information about the booking
>>>                 agent, the airlines
>>>                    and car hire companies and the hotel.
>>>                 """
>>>
>>>                 Looks to me that there is an additional "and".
>>                 Removed
>>>
>>>
>>>
>>>                 5.  New Property Parameters
>>>
>>>                 """
>>>                    This specification makes use of the LABEL
>>>                 property parameter which is
>>>                    defined in [RFC7986]
>>>                 """
>>>
>>>                 My understanding is that the parameters described in
>>>                 this section apply to the LABEL property.. It seems
>>>                 to me that this is the first time the LABEL
>>>                 properties and associated parameters are mentioned
>>>                 in the document. In other words, I have hard time
>>>                 finding where this section is introduced  in the
>>>                 previous sections such as the introduction. If I am
>>>                 correct, maybe that could be clarified in the
>>>                 introduction.
>>                 LABEL is a parameter - it turns up in the ABNF for a
>>                 number of the properties defined here. The phrase
>>                 "property parameter" was pulled out of that spec -
>>                 from 5545 as well. "LABEL parameter" is a little
>>                 clearer I think. I'll try that.
>>>
>>>                 It seems to me that the document is structured with
>>>                 a kind of bottom - up approach. parameters <
>>>                 properties < components. Thus I am wondering if
>>>                 there are any reasons for not having the Calendar
>>>                 Components at the very end instead of at the beginning.
>>>                 I am also wondering if that would not be more easy
>>>                 to read the document with Participant Types and
>>>                 Resource Types listed within their respective
>>>                 Properties.
>>>
>>                 I see what you mean now. Makes sense.
>>>
>>>
>>>
>>>                 On Tue, May 15, 2018 at 1:12 PM, Daniel Migault
>>>                 >>                 > wrote:
>>>
>>>                     Hi,
>>>
>>>                     draft-ietf-calext-eventpub-extensions [1] is
>>>                     already on WGLC. We would like to sufficient
>>>                     reviews to move the document to the IESG. If you
>>>                     have not yet commented the document, please
>>>                     provide your feedbacks by May 29 so we can move
>>>                     the document forward.
>>>
>>>                     Yours,
>>>                     Calext co-chairs.
>>>
>>>
>>>
>>>                     [1]
>>>                     https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/
>>>                     
>>>
>>>
>>>
>>>
>>>                 _______________________________________________
>>>                 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
>>                 
>>
>>
>>
>>
>
>
>     _______________________________________________
>     calsify mailing list
>     calsify@ietf.org 
>     https://www.ietf.org/mailman/listinfo/calsify
>     
>
>


--------------9521B67DC3F05EA452553915
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
The text references 5546 because implementors need to understand
      how this is made backwards compatible with that spec. Shoudl that
      be an informative reference?

    
e.g.

    
Section 3.1.1

    

    
There may be an iTip [RFC5546] meeting request for the piano tuner
who will arrive before the performance.  Other members of staff may




    

    
On 8/7/18 08:37, Daniel Migault wrote:

    

    

      
      

        
Hi, 

        

        


        

        
The abstract should also remove the reference to 5546 as
          the ref has been removed from header and introduction. 

        

        


        

        
Yours, 

        

        
Daniel

        

      

      


        
On Mon, Aug 6, 2018 at 11:36 PM,
          Michael Douglass <mikeadouglass@gmail.com>
          wrote:

          

            

                


                

                

                
On
                  8/6/18 14:52, Daniel Migault wrote:

                

              
                

                  

                    
Hi, 

                    

                    


                    

                    
Initiating the shepherd write-up here are my
                      additional comments:

                    


                    

                    
1) running the nits raises some minor issues so
                      please remove the '[' and ']' in the abstract.

                      

                      OLD:

                      

                         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.

                      

                      NEW:

                      

                         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.

                    

                  

                

               See previous message - seems to be xml2rfc

                

                  

                    


                      2)

                      

                      I do not see the following reference mentioned in
                      the text. Maybe it could be removed. If you prefer
                      to keep it, maybe informational may be the right
                      category for it.

                      

                         [W3C.REC-xml-20060816]

                                    Bray, T., Paoli, J.,
                      Sperberg-McQueen, M., Maler, E., and

                                    F. Yergeau, "Extensible Markup
                      Language (XML) 1.0 (Fourth

                                    Edition)", World Wide Web Consortium
                      Recommendation REC-

                                    xml-20060816, August 2006,

                                    <http://www.w3.org/TR/2006/REC-xml-20060816>.

                      

                    

                  

                

               Removed

                

                  

                    


                      3) I do not see the update of RFC 5546 being
                      discussed in the introduction. Could you please
                      add some text ?

                       

                    

                  

                

               Removed the updates reference. 5546 is mentioned
              but I don't belieev updated in any way.

                

                  

                    


                      4) IANA section,

                      

                      I suggest to add the URL to the IANA registry as
                      an informative reference.

                      https://www.iana.org/assignments/icalendar/icalendar.xhtml#properties

                      

                    

                  

                

               Done

                

                  

                    


                      section 12.1.{1,2,3} I would remove the term
                      "Registration" to make sure the title of the
                      section match the registry. Similarly, I would
                      replace Property by Properties to match the
                      registries.

                    

                  

                

               Done

              

                

                  


                  

                  
Yours, 

                  

                  
Daniel

                  

                

              

              Thanks - Mike
              

                


                  

                    


                      
On Mon, Aug 6, 2018 at
                        1:58 PM, Daniel Migault <daniel.migault@ericsson.com>
                        wrote:

                        

                          

                            
In order to get a rough idea of the
                              consensus to move that draft forward to
                              the IESG, I would also appreciate your
                              support on approving the document. Please
                              let us know if you believe the document is
                              ready to be moved forward. 

                            

                            


                            

                            
If you have implemented it, it would
                              also be much appreciate to write the
                              review. 

                            

                            


                            

                            
Yours, 

                            

                            
Daniel

                            

                          

                          

                            

                              


                                
On Mon, Aug 6,
                                  2018 at 1:44 PM, Daniel Migault <daniel.migault@ericsson.com>
                                  wrote:

                                  

                                    

                                      
Hi, 

                                      

                                      
Just catching up. Is the
                                        current version addressing all
                                        comments, or do we expect
                                        another version coming in the
                                        few next days ?

                                      


                                      

                                      
Yours, 

                                      

                                      
Daniel

                                      

                                    

                                    

                                      

                                        


                                          
On
                                            Wed, May 16, 2018 at 1:33
                                            AM, Michael Douglass <mikeadouglass@gmail.com>
                                            wrote:

                                            

                                              

                                                
Thank you for the
                                                  comments - I've
                                                  submitted a new draft
                                                  to address these and
                                                  just realised I didn't
                                                  address any of
                                                  Robert's issues.

                                                
I'll deal with those
                                                  in day or so.

                                                

                                                 

                                                  
On
                                                    5/15/18 23:07,
                                                    Daniel Migault
                                                    wrote:

                                                  

                                                
                                                  

                                                    

                                                      
Hi, 

                                                      

                                                      


                                                      

                                                      
Please find
                                                        some comments.
                                                        These comments
                                                        are indicative.

                                                      


                                                      

                                                      
Yours, 

                                                      

                                                      
Daniel

                                                      


                                                      

                                                      
Abstract:

                                                      
The header
                                                        indicates that
                                                        RFC 5545,and RFC
                                                        5546 are
                                                        updated. This
                                                        must be also
                                                        stated in the
                                                        Abstract and in
                                                        the
                                                        introduction. 

                                                      

                                                    

                                                  

                                                 Some text added

                                                  

                                                    

                                                      


                                                      

                                                      


                                                      

                                                      
1. 
                                                        Introduction

                                                        

                                                        """

                                                        Current practice
                                                        is to embed this
                                                        information as
                                                        links in the

                                                           description
                                                        or to add
                                                        x-properties.

                                                        """

                                                        

                                                        It is not clear
                                                        to me how to use
                                                        x-properties. Is
                                                        it a notation ?
                                                        In addition, I
                                                        am also
                                                        wondering if
                                                        this does not
                                                        designate the
                                                        LABEL property.
                                                        If that is
                                                        correct, maybe
                                                        that could be
                                                        explicitly
                                                        stated to better
                                                        understand
                                                        section 5.

                                                      

                                                    

                                                  

                                                 I've changed the
                                                text to refer to
                                                non-standard properties
                                                and provided a reference
                                                to the section in 5545.
                                                

                                                

                                                LABEL is a parameter
                                                used to provide a
                                                human-readable label for
                                                properties - something
                                                like the alt attribute
                                                in html - so no - that
                                                is a different usage

                                                  

                                                    

                                                      


                                                        

                                                        The conventions
                                                        needs to be
                                                        updated
                                                        according to RFC
                                                        8174

                                                        

                                                           The key words
                                                        "MUST", "MUST
                                                        NOT",
                                                        "REQUIRED",
                                                        "SHALL", "SHALL
                                                        NOT",

                                                           "SHOULD",
                                                        "SHOULD NOT",
                                                        "RECOMMENDED",
                                                        "NOT
                                                        RECOMMENDED",
                                                        "MAY", and

                                                           "OPTIONAL" in
                                                        this document
                                                        are to be
                                                        interpreted as
                                                        described in

                                                           [RFC2119].

                                                      

                                                    

                                                  

                                                 Done

                                                  

                                                    

                                                      


                                                        3.  Typed
                                                        References

                                                        

                                                        """

                                                           perhaps

                                                           for indexing
                                                        or the
                                                        presentation of
                                                        additional
                                                        related
                                                        information

                                                           for the user.

                                                        """

                                                        

                                                        Thought English
                                                        is not my
                                                        natural
                                                        language, there
                                                        might be a nit
                                                        there. 

                                                        

                                                           perhaps

                                                           for indexing
                                                        or presentating
                                                        the additional
                                                        related
                                                        information

                                                           to the user.

                                                        --

                                                      

                                                    

                                                  

                                                 Changed to:

                                                  

                                                  perhaps for indexing
                                                  or the

                                                        
                                                presenting of additional
                                                related information for
                                                the user.

                                                  

                                                    

                                                      


                                                        

                                                        """

                                                        Using
                                                        STRUCTURED-LOCATION,
                                                        information
                                                        about a number
                                                        of interesting

                                                           locations can
                                                        be communicated,
                                                        for example,
                                                        parking,
                                                        restaurants and

                                                           the venue. 
                                                        Servers and
                                                        clients can
                                                        retrieve the
                                                        objects when
                                                        storing

                                                           the event and
                                                        use them to
                                                        index by
                                                        geographic
                                                        location.

                                                        """

                                                        

                                                        It is not clear
                                                        from the text
                                                        that the
                                                        location
                                                        information
                                                        mentioned above
                                                        (e.g. address,
                                                        region, country,
                                                        postal code)
                                                        that motivated
                                                        the
                                                        STRUCTURED-LOCATION
                                                        are part
                                                        STRUCTURED-LOCATION.
                                                        Thus I would
                                                        also mention
                                                        them 

                                                        

                                                        

                                                        Using
                                                        STRUCTURED-LOCATION,
                                                        information
                                                        about a number
                                                        of interesting

                                                           locations can
                                                        be communicated,
                                                        for example,
                                                        address, region,
                                                        country, postal
                                                        code as well as
                                                        other
                                                        informations
                                                        such as the
                                                        parking,
                                                        restaurants and

                                                           the venue. 
                                                        Servers and
                                                        clients can
                                                        retrieve the
                                                        objects when
                                                        storing

                                                           the event and
                                                        use them to
                                                        index by
                                                        geographic
                                                        location.

                                                        

                                                      

                                                    

                                                  

                                                 Done

                                                  

                                                    

                                                      
---

                                                        

                                                        3.1.2. 
                                                        Itineraries

                                                        

                                                        

                                                        """

                                                        The contact
                                                        information can

                                                           provide
                                                        detailed
                                                        information
                                                        about the
                                                        booking agent,
                                                        the airlines

                                                           and car hire
                                                        companies and
                                                        the hotel.

                                                        """

                                                        

                                                        Looks to me that
                                                        there is an
                                                        additional
                                                        "and".

                                                      

                                                    

                                                  

                                                 Removed

                                                

                                                  

                                                    


                                                        

                                                        

                                                        5.  New Property
                                                        Parameters

                                                        

                                                        """

                                                           This
                                                        specification
                                                        makes use of the
                                                        LABEL property
                                                        parameter which
                                                        is

                                                           defined in
                                                        [RFC7986]

                                                        """

                                                        

                                                       My
                                                      understanding is
                                                      that the
                                                      parameters
                                                      described in this
                                                      section apply to
                                                      the LABEL
                                                      property.. It
                                                      seems to me that
                                                      this is the first
                                                      time the LABEL
                                                      properties and
                                                      associated
                                                      parameters are
                                                      mentioned in the
                                                      document. In other
                                                      words, I have hard
                                                      time finding where
                                                      this section is
                                                      introduced  in the
                                                      previous sections
                                                      such as the
                                                      introduction. If I
                                                      am correct, maybe
                                                      that could be
                                                      clarified in the
                                                      introduction. 

                                                    

                                                  

                                                

                                                LABEL is a parameter -
                                                it turns up in the ABNF
                                                for a number of the
                                                properties defined here.
                                                The phrase "property
                                                parameter" was pulled
                                                out of that spec - from
                                                5545 as well. "LABEL
                                                parameter" is a little
                                                clearer I think. I'll
                                                try that.

                                                  

                                                    

                                                      


                                                        It seems to me
                                                        that the
                                                        document is
                                                        structured with
                                                        a kind of bottom
                                                        - up approach.
                                                        parameters <
                                                        properties <
                                                        components. Thus
                                                        I am wondering
                                                        if there are any
                                                        reasons for not
                                                        having the
                                                        Calendar
                                                        Components at
                                                        the very end
                                                        instead of at
                                                        the beginning.

                                                      

                                                    

                                                  

                                                  

                                                    

                                                      
I am also
                                                        wondering if
                                                        that would not
                                                        be more easy to
                                                        read the
                                                        document with
                                                        Participant
                                                        Types and
                                                        Resource Types
                                                        listed within
                                                        their respective
                                                        Properties. 

                                                        

                                                      

                                                    

                                                  

                                                 I see what you
                                                mean now. Makes sense.

                                                

                                                    

                                                      


                                                        

                                                      

                                                    

                                                    


                                                      
On
                                                        Tue, May 15,
                                                        2018 at 1:12 PM,
                                                        Daniel Migault <daniel.migault@ericsson.com>
                                                        wrote:

                                                        

                                                          

                                                          
Hi, 

                                                          

                                                          


                                                          

                                                          
draft-ietf-calext-eventpub-extensions
                                                          [1] is already
                                                          on WGLC. We
                                                          would like to
                                                          sufficient
                                                          reviews to
                                                          move the
                                                          document to
                                                          the IESG. If
                                                          you have not
                                                          yet commented
                                                          the document,
                                                          please provide
                                                          your feedbacks
                                                          by May 29 so
                                                          we can move
                                                          the document
                                                          forward. 

                                                          

                                                          


                                                          

                                                          
Yours, 

                                                          

                                                          
Calext
                                                          co-chairs.

                                                          

                                                          


                                                          

                                                          


                                                          

                                                          


                                                          

                                                          
                                                          

                                                        

                                                      

                                                      

                                                    

                                                    

                                                    

                                                    

                                                  
                                                    
_______________________________________________
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

                                              

                                            

                                          

                                          

                                        

                                      

                                    

                                  

                                

                                

                              

                            

                          

                        

                      

                      

                    

                  

                  

                

              

            

            

            _______________________________________________

            calsify mailing list

            calsify@ietf.org

            https://www.ietf.org/mailman/listinfo/calsify

            

          

        

        

      

    

    

  


--------------9521B67DC3F05EA452553915--


From nobody Tue Aug  7 15:03:28 2018
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 8C0F0131100 for ; Tue,  7 Aug 2018 15:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, 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 is5n3nwjZPbu for ; Tue,  7 Aug 2018 15:03:21 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 692D91310FE for ; Tue,  7 Aug 2018 15:03:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533679399; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=imaWcAjLF25OGbcojal7xoYubzhixsB8Vfpf07NfH8c=; b=eLgxCoZrBRuCxMQA+cc+sEQyiD5P4YNkz07ZnABNb4aDWS5l6yK7aXFjKS3xyMk1 Se2Qm16N9oD+6C4MWY+Pz4gtboJZlbGPnCBUq7tXXRDkZHNwQBkoCSzVGCjpwS7z ekH9B3SBjMoY05YzKyymj2HP5ZrRTncD6fyPWGWGXDE=;
X-AuditID: c618062d-bdbff70000004941-60-5b6a17273772
Received: from EUSASMB505.ericsson.se (Unknown_Domain [147.117.188.223]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id FF.B9.18753.7271A6B5; Wed,  8 Aug 2018 00:03:19 +0200 (CEST)
Received: from EUSASMB503.ericsson.se (147.117.188.221) by EUSASMB505.ericsson.se (147.117.188.230) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 7 Aug 2018 18:03:18 -0400
Received: from EUSASMB503.ericsson.se ([147.117.188.239]) by EUSASMB503.ericsson.se ([147.117.188.239]) with mapi id 15.01.1466.003; Tue, 7 Aug 2018 18:03:18 -0400
From: Daniel Migault 
To: Michael Douglass 
CC: "calsify@ietf.org" 
Thread-Topic: [calsify] draft-ietf-calext-eventpub-extensions-06
Thread-Index: AQHULa0gdSb3bORE1U6k5MqmSiRdwqSzRd2AgAAPKYCAAJJJgIAAlzCAgACN2ID//8sOYA==
Date: Tue, 7 Aug 2018 22:03:18 +0000
Message-ID: <8a411e79d31b417ea7cf46222e2a2a5e@ericsson.com>
References:   <708d48bc-e213-1386-ff7b-23a476000774@gmail.com>      <297e6b6e-5d5c-438b-a0ae-aa7fe3533116@gmail.com>
In-Reply-To: <297e6b6e-5d5c-438b-a0ae-aa7fe3533116@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.8]
Content-Type: multipart/alternative; boundary="_000_8a411e79d31b417ea7cf46222e2a2a5eericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyuXTPfV118axog497lCw2vWhmtZiy7AGb A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVx+uQspoJ7n5kq+r78ZG9gbHnF1MXIySEh YCLRcmMiSxcjF4eQwDFGia7PExghnO+MEtNaOtggnOWMEl8eXQNrYRMwkmg71M8OYosI6Ens 3ngPzGYW0JR4sfM9K4gtLGAvsfLeAVaIGgeJmRfOMEPYYRLfNn4Bs1kEVCS+dTSD1fAKWEvs O70KatkZFom5ZxeCLeMUsJXYd2YxC4jNKCAm8f3UGiaIZeISt57Mh/pBQGLJnvPMELaoxMvH /1ghbEWJz6dvQB2XLPH45F52iGWCEidnPmGZwCg6C8moWUjKZiEpm8XIAfbb+l36ECWKElO6 H7JD2BoSrXPmsiOLL2BkX8XIUVpckJObbmSwiREYXcck2HR3MN6f7nmIUYCDUYmHV4A9K1qI NbGsuDL3EKMEB7OSCG9yXWa0EG9KYmVValF+fFFpTmrxIUZpDhYlcd4znrxRQgLpiSWp2amp BalFMFkmDk6pBsaDld1Sazyeno/N3GX8qDDY6Hfx+aBdip1ODpvmKJgJMje1VRrGGGSrGMRO /WxWH8FQaR71/oes01we/Vr/WzbV0VePnnl0kPUEd2V84HsPA56kP7s/7/ReOm/l9SsHmJlU mO1fnpCy1/3R3p9t8nCpuGjNTnGZEK6olOrbOd+nPRK+tzSmRImlOCPRUIu5qDgRAMMO2k+q AgAA
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Aug 2018 22:03:25 -0000

--_000_8a411e79d31b417ea7cf46222e2a2a5eericssoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgTWljaGFlbCwNCg0KU28gSSBhbSBub3Qgc2F5aW5nIHRoYXQgNTU0NiBoYXMgdG8gYmUgcmVt
b3ZlZCBldmVyeXdoZXJlLiBXaGF0IEkgd2FzIG1lbnRpb25pbmcgaXMgdG8gaGF2ZSB3aGF0IGlz
IGJlaW5nIHVwZGF0ZWQgY29oZXJlbnQgYWNyb3NzIHRoZSBzZWN0aW9ucyAoSGVhZGVyLCBhYnN0
cmFjdCwgaW50cm8pLiBUaHVzIEkgd2FzIGp1c3Qgc3VnZ2VzdGluZyB0byByZXBsYWNlIGluIHRo
ZSBhYnN0cmFjdDoNCg0KT0xEOg0KVGhpcyBzcGVjaWZpY2F0aW9uIHVwZGF0ZXMgW1JGQzU1NDVd
IGFuZCBbUkZDNTU0Nl0NCk5FVzoNClRoaXMgc3BlY2lmaWNhdGlvbiB1cGRhdGVzIFtSRkM1NTQ1
XQ0KDQpUaGlzIGlzIHdoYXQgSSBmb3VuZCBjdXJyZW50bHkgaW4gdGhlIGRyYWZ0Og0KDQpJbiB0
aGUgaGVhZGVyOg0KICAgICBVcGRhdGVzOiA1NTQ1IChpZiBhcHByb3ZlZCkNCkluIHRoZSBhYnN0
cmFjdDoNCiAgICBUaGlzIHNwZWNpZmljYXRpb24gdXBkYXRlcyBbUkZDNTU0NV0gYW5kIFtSRkM1
NTQ2XQ0KSW4gdGhlIGludHJvZHVjdGlvbjoNCiAgICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgW1JG
QzU1NDVdDQoNCkluIHRoZSByZW1haW5pbmcgb2YgdGhlIGRvY3VtZW50IDU1NDYgbmVlZHMgdG8g
c3RheSBhcyBpdCBpcy4gSXQgaXMgYSBTdGFuZGFyZHMgVHJhY2ssIHNvIGEgbm9ybWF0aXZlIHJl
ZmVyZW5jZSBpcyBhcHByb3ByaWF0ZWQuDQoNCkkgYXBvbG9neSBmb3IgdGhlIGNvbmZ1c2lvbiDw
n5iJDQoNCllvdXJzLA0KRGFuaWVsDQoNCkZyb206IE1pY2hhZWwgRG91Z2xhc3MgPG1pa2VhZG91
Z2xhc3NAZ21haWwuY29tPg0KU2VudDogVHVlc2RheSwgQXVndXN0IDA3LCAyMDE4IDU6MDUgUE0N
ClRvOiBEYW5pZWwgTWlnYXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPg0KQ2M6IGNh
bHNpZnlAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY2Fsc2lmeV0gZHJhZnQtaWV0Zi1jYWxleHQt
ZXZlbnRwdWItZXh0ZW5zaW9ucy0wNg0KDQoNClRoZSB0ZXh0IHJlZmVyZW5jZXMgNTU0NiBiZWNh
dXNlIGltcGxlbWVudG9ycyBuZWVkIHRvIHVuZGVyc3RhbmQgaG93IHRoaXMgaXMgbWFkZSBiYWNr
d2FyZHMgY29tcGF0aWJsZSB3aXRoIHRoYXQgc3BlYy4gU2hvdWRsIHRoYXQgYmUgYW4gaW5mb3Jt
YXRpdmUgcmVmZXJlbmNlPw0KDQplLmcuDQoNClNlY3Rpb24gMy4xLjENCg0KVGhlcmUgbWF5IGJl
IGFuIGlUaXAgW1JGQzU1NDZdIG1lZXRpbmcgcmVxdWVzdCBmb3IgdGhlIHBpYW5vIHR1bmVyDQoN
CndobyB3aWxsIGFycml2ZSBiZWZvcmUgdGhlIHBlcmZvcm1hbmNlLiAgT3RoZXIgbWVtYmVycyBv
ZiBzdGFmZiBtYXkNCg0KDQoNCg0KDQpPbiA4LzcvMTggMDg6MzcsIERhbmllbCBNaWdhdWx0IHdy
b3RlOg0KSGksDQoNClRoZSBhYnN0cmFjdCBzaG91bGQgYWxzbyByZW1vdmUgdGhlIHJlZmVyZW5j
ZSB0byA1NTQ2IGFzIHRoZSByZWYgaGFzIGJlZW4gcmVtb3ZlZCBmcm9tIGhlYWRlciBhbmQgaW50
cm9kdWN0aW9uLg0KDQpZb3VycywNCkRhbmllbA0KDQpPbiBNb24sIEF1ZyA2LCAyMDE4IGF0IDEx
OjM2IFBNLCBNaWNoYWVsIERvdWdsYXNzIDxtaWtlYWRvdWdsYXNzQGdtYWlsLmNvbTxtYWlsdG86
bWlrZWFkb3VnbGFzc0BnbWFpbC5jb20+PiB3cm90ZToNCg0KDQoNCk9uIDgvNi8xOCAxNDo1Miwg
RGFuaWVsIE1pZ2F1bHQgd3JvdGU6DQpIaSwNCg0KSW5pdGlhdGluZyB0aGUgc2hlcGhlcmQgd3Jp
dGUtdXAgaGVyZSBhcmUgbXkgYWRkaXRpb25hbCBjb21tZW50czoNCg0KMSkgcnVubmluZyB0aGUg
bml0cyByYWlzZXMgc29tZSBtaW5vciBpc3N1ZXMgc28gcGxlYXNlIHJlbW92ZSB0aGUgJ1snIGFu
ZCAnXScgaW4gdGhlIGFic3RyYWN0Lg0KDQpPTEQ6DQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiB1
cGRhdGVzIFtSRkM1NTQ1XSAgYW5kIFtSRkM1NTQ2XSBieSBpbnRyb2R1Y2luZyBhDQogICBudW1i
ZXIgb2YgbmV3IGlDYWxlbmRhciBwcm9wZXJ0aWVzIGFuZCBjb21wb25lbnRzIHdoaWNoIGFyZSBv
Zg0KICAgcGFydGljdWxhciB1c2UgZm9yIGV2ZW50IHB1Ymxpc2hlcnMgYW5kIGluIHNvY2lhbCBu
ZXR3b3JraW5nLg0KDQpORVc6DQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiB1cGRhdGVzIFJGQzU1
NDUgYW5kIFJGQzU1NDYgYnkgaW50cm9kdWNpbmcgYQ0KICAgbnVtYmVyIG9mIG5ldyBpQ2FsZW5k
YXIgcHJvcGVydGllcyBhbmQgY29tcG9uZW50cyB3aGljaCBhcmUgb2YNCiAgIHBhcnRpY3VsYXIg
dXNlIGZvciBldmVudCBwdWJsaXNoZXJzIGFuZCBpbiBzb2NpYWwgbmV0d29ya2luZy4NClNlZSBw
cmV2aW91cyBtZXNzYWdlIC0gc2VlbXMgdG8gYmUgeG1sMnJmYw0KDQoNCjIpDQoNCkkgZG8gbm90
IHNlZSB0aGUgZm9sbG93aW5nIHJlZmVyZW5jZSBtZW50aW9uZWQgaW4gdGhlIHRleHQuIE1heWJl
IGl0IGNvdWxkIGJlIHJlbW92ZWQuIElmIHlvdSBwcmVmZXIgdG8ga2VlcCBpdCwgbWF5YmUgaW5m
b3JtYXRpb25hbCBtYXkgYmUgdGhlIHJpZ2h0IGNhdGVnb3J5IGZvciBpdC4NCg0KICAgW1czQy5S
RUMteG1sLTIwMDYwODE2XQ0KICAgICAgICAgICAgICBCcmF5LCBULiwgUGFvbGksIEouLCBTcGVy
YmVyZy1NY1F1ZWVuLCBNLiwgTWFsZXIsIEUuLCBhbmQNCiAgICAgICAgICAgICAgRi4gWWVyZ2Vh
dSwgIkV4dGVuc2libGUgTWFya3VwIExhbmd1YWdlIChYTUwpIDEuMCAoRm91cnRoDQogICAgICAg
ICAgICAgIEVkaXRpb24pIiwgV29ybGQgV2lkZSBXZWIgQ29uc29ydGl1bSBSZWNvbW1lbmRhdGlv
biBSRUMtDQogICAgICAgICAgICAgIHhtbC0yMDA2MDgxNiwgQXVndXN0IDIwMDYsDQogICAgICAg
ICAgICAgIDxodHRwOi8vd3d3LnczLm9yZy9UUi8yMDA2L1JFQy14bWwtMjAwNjA4MTY+Lg0KUmVt
b3ZlZA0KDQoNCjMpIEkgZG8gbm90IHNlZSB0aGUgdXBkYXRlIG9mIFJGQyA1NTQ2IGJlaW5nIGRp
c2N1c3NlZCBpbiB0aGUgaW50cm9kdWN0aW9uLiBDb3VsZCB5b3UgcGxlYXNlIGFkZCBzb21lIHRl
eHQgPw0KDQpSZW1vdmVkIHRoZSB1cGRhdGVzIHJlZmVyZW5jZS4gNTU0NiBpcyBtZW50aW9uZWQg
YnV0IEkgZG9uJ3QgYmVsaWVldiB1cGRhdGVkIGluIGFueSB3YXkuDQoNCg0KNCkgSUFOQSBzZWN0
aW9uLA0KDQpJIHN1Z2dlc3QgdG8gYWRkIHRoZSBVUkwgdG8gdGhlIElBTkEgcmVnaXN0cnkgYXMg
YW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlLg0KaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVu
dHMvaWNhbGVuZGFyL2ljYWxlbmRhci54aHRtbCNwcm9wZXJ0aWVzDQpEb25lDQoNCg0Kc2VjdGlv
biAxMi4xLnsxLDIsM30gSSB3b3VsZCByZW1vdmUgdGhlIHRlcm0gIlJlZ2lzdHJhdGlvbiIgdG8g
bWFrZSBzdXJlIHRoZSB0aXRsZSBvZiB0aGUgc2VjdGlvbiBtYXRjaCB0aGUgcmVnaXN0cnkuIFNp
bWlsYXJseSwgSSB3b3VsZCByZXBsYWNlIFByb3BlcnR5IGJ5IFByb3BlcnRpZXMgdG8gbWF0Y2gg
dGhlIHJlZ2lzdHJpZXMuDQpEb25lDQoNCg0KWW91cnMsDQpEYW5pZWwNClRoYW5rcyAtIE1pa2UN
Cg0KDQoNCk9uIE1vbiwgQXVnIDYsIDIwMTggYXQgMTo1OCBQTSwgRGFuaWVsIE1pZ2F1bHQgPGRh
bmllbC5taWdhdWx0QGVyaWNzc29uLmNvbTxtYWlsdG86ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24u
Y29tPj4gd3JvdGU6DQpJbiBvcmRlciB0byBnZXQgYSByb3VnaCBpZGVhIG9mIHRoZSBjb25zZW5z
dXMgdG8gbW92ZSB0aGF0IGRyYWZ0IGZvcndhcmQgdG8gdGhlIElFU0csIEkgd291bGQgYWxzbyBh
cHByZWNpYXRlIHlvdXIgc3VwcG9ydCBvbiBhcHByb3ZpbmcgdGhlIGRvY3VtZW50LiBQbGVhc2Ug
bGV0IHVzIGtub3cgaWYgeW91IGJlbGlldmUgdGhlIGRvY3VtZW50IGlzIHJlYWR5IHRvIGJlIG1v
dmVkIGZvcndhcmQuDQoNCklmIHlvdSBoYXZlIGltcGxlbWVudGVkIGl0LCBpdCB3b3VsZCBhbHNv
IGJlIG11Y2ggYXBwcmVjaWF0ZSB0byB3cml0ZSB0aGUgcmV2aWV3Lg0KDQpZb3VycywNCkRhbmll
bA0KDQpPbiBNb24sIEF1ZyA2LCAyMDE4IGF0IDE6NDQgUE0sIERhbmllbCBNaWdhdWx0IDxkYW5p
ZWwubWlnYXVsdEBlcmljc3Nvbi5jb208bWFpbHRvOmRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNv
bT4+IHdyb3RlOg0KSGksDQpKdXN0IGNhdGNoaW5nIHVwLiBJcyB0aGUgY3VycmVudCB2ZXJzaW9u
IGFkZHJlc3NpbmcgYWxsIGNvbW1lbnRzLCBvciBkbyB3ZSBleHBlY3QgYW5vdGhlciB2ZXJzaW9u
IGNvbWluZyBpbiB0aGUgZmV3IG5leHQgZGF5cyA/DQoNCllvdXJzLA0KRGFuaWVsDQoNCk9uIFdl
ZCwgTWF5IDE2LCAyMDE4IGF0IDE6MzMgQU0sIE1pY2hhZWwgRG91Z2xhc3MgPG1pa2VhZG91Z2xh
c3NAZ21haWwuY29tPG1haWx0bzptaWtlYWRvdWdsYXNzQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpU
aGFuayB5b3UgZm9yIHRoZSBjb21tZW50cyAtIEkndmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IHRv
IGFkZHJlc3MgdGhlc2UgYW5kIGp1c3QgcmVhbGlzZWQgSSBkaWRuJ3QgYWRkcmVzcyBhbnkgb2Yg
Um9iZXJ0J3MgaXNzdWVzLg0KDQpJJ2xsIGRlYWwgd2l0aCB0aG9zZSBpbiBkYXkgb3Igc28uDQoN
Ck9uIDUvMTUvMTggMjM6MDcsIERhbmllbCBNaWdhdWx0IHdyb3RlOg0KSGksDQoNClBsZWFzZSBm
aW5kIHNvbWUgY29tbWVudHMuIFRoZXNlIGNvbW1lbnRzIGFyZSBpbmRpY2F0aXZlLg0KDQpZb3Vy
cywNCkRhbmllbA0KDQpBYnN0cmFjdDoNClRoZSBoZWFkZXIgaW5kaWNhdGVzIHRoYXQgUkZDIDU1
NDUsYW5kIFJGQyA1NTQ2IGFyZSB1cGRhdGVkLiBUaGlzIG11c3QgYmUgYWxzbyBzdGF0ZWQgaW4g
dGhlIEFic3RyYWN0IGFuZCBpbiB0aGUgaW50cm9kdWN0aW9uLg0KU29tZSB0ZXh0IGFkZGVkDQoN
Cg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiIiIg0KQ3VycmVudCBwcmFjdGljZSBpcyB0byBlbWJl
ZCB0aGlzIGluZm9ybWF0aW9uIGFzIGxpbmtzIGluIHRoZQ0KICAgZGVzY3JpcHRpb24gb3IgdG8g
YWRkIHgtcHJvcGVydGllcy4NCiIiIg0KDQpJdCBpcyBub3QgY2xlYXIgdG8gbWUgaG93IHRvIHVz
ZSB4LXByb3BlcnRpZXMuIElzIGl0IGEgbm90YXRpb24gPyBJbiBhZGRpdGlvbiwgSSBhbSBhbHNv
IHdvbmRlcmluZyBpZiB0aGlzIGRvZXMgbm90IGRlc2lnbmF0ZSB0aGUgTEFCRUwgcHJvcGVydHku
IElmIHRoYXQgaXMgY29ycmVjdCwgbWF5YmUgdGhhdCBjb3VsZCBiZSBleHBsaWNpdGx5IHN0YXRl
ZCB0byBiZXR0ZXIgdW5kZXJzdGFuZCBzZWN0aW9uIDUuDQpJJ3ZlIGNoYW5nZWQgdGhlIHRleHQg
dG8gcmVmZXIgdG8gbm9uLXN0YW5kYXJkIHByb3BlcnRpZXMgYW5kIHByb3ZpZGVkIGEgcmVmZXJl
bmNlIHRvIHRoZSBzZWN0aW9uIGluIDU1NDUuDQoNCkxBQkVMIGlzIGEgcGFyYW1ldGVyIHVzZWQg
dG8gcHJvdmlkZSBhIGh1bWFuLXJlYWRhYmxlIGxhYmVsIGZvciBwcm9wZXJ0aWVzIC0gc29tZXRo
aW5nIGxpa2UgdGhlIGFsdCBhdHRyaWJ1dGUgaW4gaHRtbCAtIHNvIG5vIC0gdGhhdCBpcyBhIGRp
ZmZlcmVudCB1c2FnZQ0KDQoNCg0KVGhlIGNvbnZlbnRpb25zIG5lZWRzIHRvIGJlIHVwZGF0ZWQg
YWNjb3JkaW5nIHRvIFJGQyA4MTc0DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBO
T1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hP
VUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJOT1QgUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kDQog
ICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRl
c2NyaWJlZCBpbg0KICAgW1JGQzIxMTldLg0KRG9uZQ0KDQoNCjMuICBUeXBlZCBSZWZlcmVuY2Vz
DQoNCiIiIg0KICAgcGVyaGFwcw0KICAgZm9yIGluZGV4aW5nIG9yIHRoZSBwcmVzZW50YXRpb24g
b2YgYWRkaXRpb25hbCByZWxhdGVkIGluZm9ybWF0aW9uDQogICBmb3IgdGhlIHVzZXIuDQoiIiIN
Cg0KVGhvdWdodCBFbmdsaXNoIGlzIG5vdCBteSBuYXR1cmFsIGxhbmd1YWdlLCB0aGVyZSBtaWdo
dCBiZSBhIG5pdCB0aGVyZS4NCg0KICAgcGVyaGFwcw0KICAgZm9yIGluZGV4aW5nIG9yIHByZXNl
bnRhdGluZyB0aGUgYWRkaXRpb25hbCByZWxhdGVkIGluZm9ybWF0aW9uDQogICB0byB0aGUgdXNl
ci4NCi0tDQpDaGFuZ2VkIHRvOg0KDQpwZXJoYXBzIGZvciBpbmRleGluZyBvciB0aGUNCiAgICAg
ICAgcHJlc2VudGluZyBvZiBhZGRpdGlvbmFsIHJlbGF0ZWQgaW5mb3JtYXRpb24gZm9yIHRoZSB1
c2VyLg0KDQoNCg0KIiIiDQpVc2luZyBTVFJVQ1RVUkVELUxPQ0FUSU9OLCBpbmZvcm1hdGlvbiBh
Ym91dCBhIG51bWJlciBvZiBpbnRlcmVzdGluZw0KICAgbG9jYXRpb25zIGNhbiBiZSBjb21tdW5p
Y2F0ZWQsIGZvciBleGFtcGxlLCBwYXJraW5nLCByZXN0YXVyYW50cyBhbmQNCiAgIHRoZSB2ZW51
ZS4gIFNlcnZlcnMgYW5kIGNsaWVudHMgY2FuIHJldHJpZXZlIHRoZSBvYmplY3RzIHdoZW4gc3Rv
cmluZw0KICAgdGhlIGV2ZW50IGFuZCB1c2UgdGhlbSB0byBpbmRleCBieSBnZW9ncmFwaGljIGxv
Y2F0aW9uLg0KIiIiDQoNCkl0IGlzIG5vdCBjbGVhciBmcm9tIHRoZSB0ZXh0IHRoYXQgdGhlIGxv
Y2F0aW9uIGluZm9ybWF0aW9uIG1lbnRpb25lZCBhYm92ZSAoZS5nLiBhZGRyZXNzLCByZWdpb24s
IGNvdW50cnksIHBvc3RhbCBjb2RlKSB0aGF0IG1vdGl2YXRlZCB0aGUgU1RSVUNUVVJFRC1MT0NB
VElPTiBhcmUgcGFydCBTVFJVQ1RVUkVELUxPQ0FUSU9OLiBUaHVzIEkgd291bGQgYWxzbyBtZW50
aW9uIHRoZW0NCg0KDQpVc2luZyBTVFJVQ1RVUkVELUxPQ0FUSU9OLCBpbmZvcm1hdGlvbiBhYm91
dCBhIG51bWJlciBvZiBpbnRlcmVzdGluZw0KICAgbG9jYXRpb25zIGNhbiBiZSBjb21tdW5pY2F0
ZWQsIGZvciBleGFtcGxlLCBhZGRyZXNzLCByZWdpb24sIGNvdW50cnksIHBvc3RhbCBjb2RlIGFz
IHdlbGwgYXMgb3RoZXIgaW5mb3JtYXRpb25zIHN1Y2ggYXMgdGhlIHBhcmtpbmcsIHJlc3RhdXJh
bnRzIGFuZA0KICAgdGhlIHZlbnVlLiAgU2VydmVycyBhbmQgY2xpZW50cyBjYW4gcmV0cmlldmUg
dGhlIG9iamVjdHMgd2hlbiBzdG9yaW5nDQogICB0aGUgZXZlbnQgYW5kIHVzZSB0aGVtIHRvIGlu
ZGV4IGJ5IGdlb2dyYXBoaWMgbG9jYXRpb24uDQpEb25lDQoNCi0tLQ0KDQozLjEuMi4gIEl0aW5l
cmFyaWVzDQoNCg0KIiIiDQpUaGUgY29udGFjdCBpbmZvcm1hdGlvbiBjYW4NCiAgIHByb3ZpZGUg
ZGV0YWlsZWQgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGJvb2tpbmcgYWdlbnQsIHRoZSBhaXJsaW5l
cw0KICAgYW5kIGNhciBoaXJlIGNvbXBhbmllcyBhbmQgdGhlIGhvdGVsLg0KIiIiDQoNCkxvb2tz
IHRvIG1lIHRoYXQgdGhlcmUgaXMgYW4gYWRkaXRpb25hbCAiYW5kIi4NClJlbW92ZWQNCg0KDQoN
Cg0KNS4gIE5ldyBQcm9wZXJ0eSBQYXJhbWV0ZXJzDQoNCiIiIg0KICAgVGhpcyBzcGVjaWZpY2F0
aW9uIG1ha2VzIHVzZSBvZiB0aGUgTEFCRUwgcHJvcGVydHkgcGFyYW1ldGVyIHdoaWNoIGlzDQog
ICBkZWZpbmVkIGluIFtSRkM3OTg2XQ0KIiIiDQoNCk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0
aGUgcGFyYW1ldGVycyBkZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uIGFwcGx5IHRvIHRoZSBMQUJF
TCBwcm9wZXJ0eS4uIEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhpcyBpcyB0aGUgZmlyc3QgdGltZSB0
aGUgTEFCRUwgcHJvcGVydGllcyBhbmQgYXNzb2NpYXRlZCBwYXJhbWV0ZXJzIGFyZSBtZW50aW9u
ZWQgaW4gdGhlIGRvY3VtZW50LiBJbiBvdGhlciB3b3JkcywgSSBoYXZlIGhhcmQgdGltZSBmaW5k
aW5nIHdoZXJlIHRoaXMgc2VjdGlvbiBpcyBpbnRyb2R1Y2VkICBpbiB0aGUgcHJldmlvdXMgc2Vj
dGlvbnMgc3VjaCBhcyB0aGUgaW50cm9kdWN0aW9uLiBJZiBJIGFtIGNvcnJlY3QsIG1heWJlIHRo
YXQgY291bGQgYmUgY2xhcmlmaWVkIGluIHRoZSBpbnRyb2R1Y3Rpb24uDQpMQUJFTCBpcyBhIHBh
cmFtZXRlciAtIGl0IHR1cm5zIHVwIGluIHRoZSBBQk5GIGZvciBhIG51bWJlciBvZiB0aGUgcHJv
cGVydGllcyBkZWZpbmVkIGhlcmUuIFRoZSBwaHJhc2UgInByb3BlcnR5IHBhcmFtZXRlciIgd2Fz
IHB1bGxlZCBvdXQgb2YgdGhhdCBzcGVjIC0gZnJvbSA1NTQ1IGFzIHdlbGwuICJMQUJFTCBwYXJh
bWV0ZXIiIGlzIGEgbGl0dGxlIGNsZWFyZXIgSSB0aGluay4gSSdsbCB0cnkgdGhhdC4NCg0KDQpJ
dCBzZWVtcyB0byBtZSB0aGF0IHRoZSBkb2N1bWVudCBpcyBzdHJ1Y3R1cmVkIHdpdGggYSBraW5k
IG9mIGJvdHRvbSAtIHVwIGFwcHJvYWNoLiBwYXJhbWV0ZXJzIDwgcHJvcGVydGllcyA8IGNvbXBv
bmVudHMuIFRodXMgSSBhbSB3b25kZXJpbmcgaWYgdGhlcmUgYXJlIGFueSByZWFzb25zIGZvciBu
b3QgaGF2aW5nIHRoZSBDYWxlbmRhciBDb21wb25lbnRzIGF0IHRoZSB2ZXJ5IGVuZCBpbnN0ZWFk
IG9mIGF0IHRoZSBiZWdpbm5pbmcuDQpJIGFtIGFsc28gd29uZGVyaW5nIGlmIHRoYXQgd291bGQg
bm90IGJlIG1vcmUgZWFzeSB0byByZWFkIHRoZSBkb2N1bWVudCB3aXRoIFBhcnRpY2lwYW50IFR5
cGVzIGFuZCBSZXNvdXJjZSBUeXBlcyBsaXN0ZWQgd2l0aGluIHRoZWlyIHJlc3BlY3RpdmUgUHJv
cGVydGllcy4NCkkgc2VlIHdoYXQgeW91IG1lYW4gbm93LiBNYWtlcyBzZW5zZS4NCg0KDQoNCk9u
IFR1ZSwgTWF5IDE1LCAyMDE4IGF0IDE6MTIgUE0sIERhbmllbCBNaWdhdWx0IDxkYW5pZWwubWln
YXVsdEBlcmljc3Nvbi5jb208bWFpbHRvOmRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbT4+IHdy
b3RlOg0KSGksDQoNCmRyYWZ0LWlldGYtY2FsZXh0LWV2ZW50cHViLWV4dGVuc2lvbnMgWzFdIGlz
IGFscmVhZHkgb24gV0dMQy4gV2Ugd291bGQgbGlrZSB0byBzdWZmaWNpZW50IHJldmlld3MgdG8g
bW92ZSB0aGUgZG9jdW1lbnQgdG8gdGhlIElFU0cuIElmIHlvdSBoYXZlIG5vdCB5ZXQgY29tbWVu
dGVkIHRoZSBkb2N1bWVudCwgcGxlYXNlIHByb3ZpZGUgeW91ciBmZWVkYmFja3MgYnkgTWF5IDI5
IHNvIHdlIGNhbiBtb3ZlIHRoZSBkb2N1bWVudCBmb3J3YXJkLg0KDQpZb3VycywNCkNhbGV4dCBj
by1jaGFpcnMuDQoNCg0KDQpbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh
ZnQtaWV0Zi1jYWxleHQtZXZlbnRwdWItZXh0ZW5zaW9ucy8NCg0KDQoNCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KY2Fsc2lmeSBtYWlsaW5nIGxp
c3QNCg0KY2Fsc2lmeUBpZXRmLm9yZzxtYWlsdG86Y2Fsc2lmeUBpZXRmLm9yZz4NCg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYWxzaWZ5DQoNCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNhbHNpZnkgbWFpbGluZyBsaXN0
DQpjYWxzaWZ5QGlldGYub3JnPG1haWx0bzpjYWxzaWZ5QGlldGYub3JnPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYWxzaWZ5DQoNCg0KDQoNCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNhbHNpZnkgbWFpbGluZyBsaXN0
DQpjYWxzaWZ5QGlldGYub3JnPG1haWx0bzpjYWxzaWZ5QGlldGYub3JnPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYWxzaWZ5DQoNCg0K

--_000_8a411e79d31b417ea7cf46222e2a2a5eericssoncom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvOw0KCXBh
bm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu
TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlw
ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy
IE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu
bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At
YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0
ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN
Cglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUy
MQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp
biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv
c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl
ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv
IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i
ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv
aGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp
bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkhpIE1pY2hhZWwsIDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3
aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+U28gSSBhbSBub3Qgc2F5aW5nIHRo
YXQgNTU0NiBoYXMgdG8gYmUgcmVtb3ZlZCBldmVyeXdoZXJlLiBXaGF0IEkgd2FzIG1lbnRpb25p
bmcgaXMgdG8gaGF2ZSB3aGF0IGlzIGJlaW5nIHVwZGF0ZWQgY29oZXJlbnQgYWNyb3NzIHRoZSBz
ZWN0aW9ucyAoSGVhZGVyLCBhYnN0cmFjdCwgaW50cm8pLiBUaHVzIEkgd2FzIGp1c3Qgc3VnZ2Vz
dGluZyB0byByZXBsYWNlDQogaW4gdGhlIGFic3RyYWN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iY29sb3I6d2luZG93dGV4dCI+T0xEOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5UaGlzIHNwZWNpZmlj
YXRpb24gdXBkYXRlcyBbUkZDNTU0NV0gYW5kIFtSRkM1NTQ2XTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5O
RVc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOndpbmRvd3RleHQiPlRoaXMgc3BlY2lmaWNhdGlvbiB1cGRhdGVzIFtSRkM1NTQ1
XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+VGhpcyBpcyB3aGF0
IEkgZm91bmQgY3VycmVudGx5IGluIHRoZSBkcmFmdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImNvbG9yOndpbmRvd3RleHQiPkluIHRoZSBoZWFkZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBVcGRhdGVzOiA1NTQ1IChpZiBhcHByb3ZlZCkmbmJzcDsmbmJz
cDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5JbiB0aGUgYWJzdHJhY3Q6PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv
d3RleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24gdXBkYXRlcyBbUkZD
NTU0NV0gYW5kIFtSRkM1NTQ2XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5JbiB0aGUgaW50cm9kdWN0aW9u
OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCB1cGRh
dGVzIFtSRkM1NTQ1XQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0
Ij5JbiB0aGUgcmVtYWluaW5nIG9mIHRoZSBkb2N1bWVudCA1NTQ2IG5lZWRzIHRvIHN0YXkgYXMg
aXQgaXMuIEl0IGlzIGEgU3RhbmRhcmRzIFRyYWNrLCBzbyBhIG5vcm1hdGl2ZSByZWZlcmVuY2Ug
aXMgYXBwcm9wcmlhdGVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0
ZXh0Ij5JIGFwb2xvZ3kgZm9yIHRoZSBjb25mdXNpb24gPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu
ZG93dGV4dCI+JiMxMjg1MjE7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPllvdXJzLCA8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6
d2luZG93dGV4dCI+RGFuaWVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk
ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i
PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gTWljaGFlbCBEb3VnbGFzcyAmbHQ7bWlr
ZWFkb3VnbGFzc0BnbWFpbC5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVn
dXN0IDA3LCAyMDE4IDU6MDUgUE08YnI+DQo8Yj5Ubzo8L2I+IERhbmllbCBNaWdhdWx0ICZsdDtk
YW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBjYWxzaWZ5QGll
dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY2Fsc2lmeV0gZHJhZnQtaWV0Zi1jYWxl
eHQtZXZlbnRwdWItZXh0ZW5zaW9ucy0wNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPlRo
ZSB0ZXh0IHJlZmVyZW5jZXMgNTU0NiBiZWNhdXNlIGltcGxlbWVudG9ycyBuZWVkIHRvIHVuZGVy
c3RhbmQgaG93IHRoaXMgaXMgbWFkZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIHRoYXQgc3Bl
Yy4gU2hvdWRsIHRoYXQgYmUgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlPzxvOnA+PC9vOnA+PC9w
Pg0KPHA+ZS5nLjxvOnA+PC9vOnA+PC9wPg0KPHA+U2VjdGlvbiAzLjEuMTxvOnA+PC9vOnA+PC9w
Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OyxzZXJpZiI+VGhlcmUgbWF5IGJlIGFu
IGlUaXAgW1JGQzU1NDZdIG1lZXRpbmcgcmVxdWVzdCBmb3IgdGhlIHBpYW5vIHR1bmVyPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LHNlcmlm
Ij53aG8gd2lsbCBhcnJpdmUgYmVmb3JlIHRoZSBwZXJmb3JtYW5jZS4mbmJzcDsgT3RoZXIgbWVt
YmVycyBvZiBzdGFmZiBtYXk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJh
Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7TWVubG8mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA4LzcvMTggMDg6MzcsIERhbmllbCBNaWdh
dWx0IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SGksIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5UaGUgYWJzdHJhY3Qgc2hvdWxkIGFsc28gcmVtb3ZlIHRoZSByZWZl
cmVuY2UgdG8gNTU0NiBhcyB0aGUgcmVmIGhhcyBiZWVuIHJlbW92ZWQgZnJvbSBoZWFkZXIgYW5k
IGludHJvZHVjdGlvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5Zb3VycywgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5EYW5pZWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBdWcgNiwgMjAxOCBhdCAxMTozNiBQTSwgTWlj
aGFlbCBEb3VnbGFzcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2VhZG91Z2xhc3NAZ21haWwuY29t
IiB0YXJnZXQ9Il9ibGFuayI+bWlrZWFkb3VnbGFzc0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm
dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl
ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHA+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA4LzYvMTggMTQ6NTIsIERhbmllbCBNaWdhdWx0IHdyb3Rl
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SGksIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5Jbml0aWF0aW5nIHRoZSBzaGVwaGVyZCB3cml0ZS11cCBoZXJlIGFyZSBteSBhZGRp
dGlvbmFsIGNvbW1lbnRzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4xKSBydW5uaW5nIHRoZSBuaXRzIHJhaXNlcyBzb21lIG1pbm9yIGlzc3Vl
cyBzbyBwbGVhc2UgcmVtb3ZlIHRoZSAnWycgYW5kICddJyBpbiB0aGUgYWJzdHJhY3QuPGJyPg0K
PGJyPg0KT0xEOjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24gdXBk
YXRlcyBbUkZDNTU0NV0mbmJzcDsgYW5kIFtSRkM1NTQ2XSBieSBpbnRyb2R1Y2luZyBhPGJyPg0K
Jm5ic3A7Jm5ic3A7IG51bWJlciBvZiBuZXcgaUNhbGVuZGFyIHByb3BlcnRpZXMgYW5kIGNvbXBv
bmVudHMgd2hpY2ggYXJlIG9mPGJyPg0KJm5ic3A7Jm5ic3A7IHBhcnRpY3VsYXIgdXNlIGZvciBl
dmVudCBwdWJsaXNoZXJzIGFuZCBpbiBzb2NpYWwgbmV0d29ya2luZy48YnI+DQo8YnI+DQpORVc6
PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlvbiB1cGRhdGVzIFJGQzU1
NDUgYW5kIFJGQzU1NDYgYnkgaW50cm9kdWNpbmcgYTxicj4NCiZuYnNwOyZuYnNwOyBudW1iZXIg
b2YgbmV3IGlDYWxlbmRhciBwcm9wZXJ0aWVzIGFuZCBjb21wb25lbnRzIHdoaWNoIGFyZSBvZjxi
cj4NCiZuYnNwOyZuYnNwOyBwYXJ0aWN1bGFyIHVzZSBmb3IgZXZlbnQgcHVibGlzaGVycyBhbmQg
aW4gc29jaWFsIG5ldHdvcmtpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VlIHByZXZpb3VzIG1lc3NhZ2UgLSBz
ZWVtcyB0byBiZSB4bWwycmZjPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48
YnI+DQoyKTxicj4NCjxicj4NCkkgZG8gbm90IHNlZSB0aGUgZm9sbG93aW5nIHJlZmVyZW5jZSBt
ZW50aW9uZWQgaW4gdGhlIHRleHQuIE1heWJlIGl0IGNvdWxkIGJlIHJlbW92ZWQuIElmIHlvdSBw
cmVmZXIgdG8ga2VlcCBpdCwgbWF5YmUgaW5mb3JtYXRpb25hbCBtYXkgYmUgdGhlIHJpZ2h0IGNh
dGVnb3J5IGZvciBpdC48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgW1czQy5SRUMteG1sLTIwMDYw
ODE2XTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCcmF5LCBULiwgUGFvbGksIEouLCBTcGVy
YmVyZy1NY1F1ZWVuLCBNLiwgTWFsZXIsIEUuLCBhbmQ8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgRi4gWWVyZ2VhdSwgJnF1b3Q7RXh0ZW5zaWJsZSBNYXJrdXAgTGFuZ3VhZ2UgKFhNTCkgMS4w
IChGb3VydGg8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRWRpdGlvbikmcXVvdDssIFdvcmxk
IFdpZGUgV2ViIENvbnNvcnRpdW0gUmVjb21tZW5kYXRpb24gUkVDLTxicj4NCiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyB4bWwtMjAwNjA4MTYsIEF1Z3VzdCAyMDA2LDxicj4NCiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cDovL3d3dy53My5vcmcvVFIvMjAwNi9SRUMteG1sLTIw
MDYwODE2IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy53My5vcmcvVFIvMjAwNi9SRUMteG1s
LTIwMDYwODE2PC9hPiZndDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVtb3ZlZDxicj4NCjxicj4NCjxvOnA+PC9v
OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjMpIEkg
ZG8gbm90IHNlZSB0aGUgdXBkYXRlIG9mIFJGQyA1NTQ2IGJlaW5nIGRpc2N1c3NlZCBpbiB0aGUg
aW50cm9kdWN0aW9uLiBDb3VsZCB5b3UgcGxlYXNlIGFkZCBzb21lIHRleHQgPzxicj4NCiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlJlbW92ZWQgdGhlIHVwZGF0ZXMgcmVmZXJlbmNlLiA1NTQ2IGlzIG1lbnRp
b25lZCBidXQgSSBkb24ndCBiZWxpZWV2IHVwZGF0ZWQgaW4gYW55IHdheS48YnI+DQo8YnI+DQo8
bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjQpIElBTkEgc2VjdGlvbiw8YnI+DQo8YnI+
DQpJIHN1Z2dlc3QgdG8gYWRkIHRoZSBVUkwgdG8gdGhlIElBTkEgcmVnaXN0cnkgYXMgYW4gaW5m
b3JtYXRpdmUgcmVmZXJlbmNlLjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlhbmEub3JnL2Fz
c2lnbm1lbnRzL2ljYWxlbmRhci9pY2FsZW5kYXIueGh0bWwjcHJvcGVydGllcyIgdGFyZ2V0PSJf
YmxhbmsiPmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2ljYWxlbmRhci9pY2FsZW5k
YXIueGh0bWwjcHJvcGVydGllczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb25lPGJyPg0KPGJyPg0KPG86cD48
L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0Kc2Vj
dGlvbiAxMi4xLnsxLDIsM30gSSB3b3VsZCByZW1vdmUgdGhlIHRlcm0gJnF1b3Q7UmVnaXN0cmF0
aW9uJnF1b3Q7IHRvIG1ha2Ugc3VyZSB0aGUgdGl0bGUgb2YgdGhlIHNlY3Rpb24gbWF0Y2ggdGhl
IHJlZ2lzdHJ5LiBTaW1pbGFybHksIEkgd291bGQgcmVwbGFjZSBQcm9wZXJ0eSBieSBQcm9wZXJ0
aWVzIHRvIG1hdGNoIHRoZSByZWdpc3RyaWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvbmU8YnI+DQo8YnI+DQo8
bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllv
dXJzLCA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkRhbmllbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyAtIE1pa2UgPG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBdWcgNiwgMjAxOCBhdCAxOjU4IFBNLCBE
YW5pZWwgTWlnYXVsdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhbmllbC5taWdhdWx0QGVyaWNzc29u
LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbTwvYT4mZ3Q7
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt
YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SW4gb3JkZXIgdG8gZ2V0IGEgcm91Z2ggaWRlYSBvZiB0aGUgY29uc2Vu
c3VzIHRvIG1vdmUgdGhhdCBkcmFmdCBmb3J3YXJkIHRvIHRoZSBJRVNHLCBJIHdvdWxkIGFsc28g
YXBwcmVjaWF0ZSB5b3VyIHN1cHBvcnQgb24gYXBwcm92aW5nIHRoZSBkb2N1bWVudC4gUGxlYXNl
IGxldCB1cyBrbm93IGlmIHlvdSBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyByZWFkeSB0byBiZSBt
b3ZlZCBmb3J3YXJkLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPklmIHlvdSBoYXZlIGltcGxlbWVudGVkIGl0LCBpdCB3b3VsZCBhbHNvIGJl
IG11Y2ggYXBwcmVjaWF0ZSB0byB3cml0ZSB0aGUgcmV2aWV3Lg0KPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdXJzLCA8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhbmllbDxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk9uIE1vbiwgQXVnIDYsIDIwMTggYXQgMTo0NCBQTSwgRGFuaWVsIE1pZ2F1bHQgJmx0OzxhIGhy
ZWY9Im1haWx0bzpkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5k
YW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCA8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3QgY2F0
Y2hpbmcgdXAuIElzIHRoZSBjdXJyZW50IHZlcnNpb24gYWRkcmVzc2luZyBhbGwgY29tbWVudHMs
IG9yIGRvIHdlIGV4cGVjdCBhbm90aGVyIHZlcnNpb24gY29taW5nIGluIHRoZSBmZXcgbmV4dCBk
YXlzID88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+WW91cnMsIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+RGFuaWVsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXkgMTYsIDIwMTggYXQgMTozMyBBTSwg
TWljaGFlbCBEb3VnbGFzcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2VhZG91Z2xhc3NAZ21haWwu
Y29tIiB0YXJnZXQ9Il9ibGFuayI+bWlrZWFkb3VnbGFzc0BnbWFpbC5jb208L2E+Jmd0OyB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu
LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHA+VGhhbmsgeW91IGZvciB0
aGUgY29tbWVudHMgLSBJJ3ZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCB0byBhZGRyZXNzIHRoZXNl
IGFuZCBqdXN0IHJlYWxpc2VkIEkgZGlkbid0IGFkZHJlc3MgYW55IG9mIFJvYmVydCdzIGlzc3Vl
cy48bzpwPjwvbzpwPjwvcD4NCjxwPkknbGwgZGVhbCB3aXRoIHRob3NlIGluIGRheSBvciBzby48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDUvMTUvMTggMjM6MDcsIERhbmllbCBN
aWdhdWx0IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+SGksIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgZmluZCBzb21lIGNvbW1lbnRzLiBUaGVzZSBjb21t
ZW50cyBhcmUgaW5kaWNhdGl2ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+WW91cnMsIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+RGFuaWVsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGhlYWRlciBpbmRpY2F0ZXMgdGhhdCBS
RkMgNTU0NSxhbmQgUkZDIDU1NDYgYXJlIHVwZGF0ZWQuIFRoaXMgbXVzdCBiZSBhbHNvIHN0YXRl
ZCBpbiB0aGUgQWJzdHJhY3QgYW5kIGluIHRoZSBpbnRyb2R1Y3Rpb24uDQo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T
b21lIHRleHQgYWRkZWQ8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4mbmJzcDsgSW50cm9kdWN0aW9uPGJyPg0KPGJy
Pg0KJnF1b3Q7JnF1b3Q7JnF1b3Q7PGJyPg0KQ3VycmVudCBwcmFjdGljZSBpcyB0byBlbWJlZCB0
aGlzIGluZm9ybWF0aW9uIGFzIGxpbmtzIGluIHRoZTxicj4NCiZuYnNwOyZuYnNwOyBkZXNjcmlw
dGlvbiBvciB0byBhZGQgeC1wcm9wZXJ0aWVzLjxicj4NCiZxdW90OyZxdW90OyZxdW90Ozxicj4N
Cjxicj4NCkl0IGlzIG5vdCBjbGVhciB0byBtZSBob3cgdG8gdXNlIHgtcHJvcGVydGllcy4gSXMg
aXQgYSBub3RhdGlvbiA/IEluIGFkZGl0aW9uLCBJIGFtIGFsc28gd29uZGVyaW5nIGlmIHRoaXMg
ZG9lcyBub3QgZGVzaWduYXRlIHRoZSBMQUJFTCBwcm9wZXJ0eS4gSWYgdGhhdCBpcyBjb3JyZWN0
LCBtYXliZSB0aGF0IGNvdWxkIGJlIGV4cGxpY2l0bHkgc3RhdGVkIHRvIGJldHRlciB1bmRlcnN0
YW5kIHNlY3Rpb24gNS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv
dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ3ZlIGNoYW5nZWQgdGhlIHRleHQgdG8gcmVmZXIg
dG8gbm9uLXN0YW5kYXJkIHByb3BlcnRpZXMgYW5kIHByb3ZpZGVkIGEgcmVmZXJlbmNlIHRvIHRo
ZSBzZWN0aW9uIGluIDU1NDUuDQo8YnI+DQo8YnI+DQpMQUJFTCBpcyBhIHBhcmFtZXRlciB1c2Vk
IHRvIHByb3ZpZGUgYSBodW1hbi1yZWFkYWJsZSBsYWJlbCBmb3IgcHJvcGVydGllcyAtIHNvbWV0
aGluZyBsaWtlIHRoZSBhbHQgYXR0cmlidXRlIGluIGh0bWwgLSBzbyBubyAtIHRoYXQgaXMgYSBk
aWZmZXJlbnQgdXNhZ2U8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpUaGUgY29udmVudGlvbnMgbmVlZHMg
dG8gYmUgdXBkYXRlZCBhY2NvcmRpbmcgdG8gUkZDIDgxNzQ8YnI+DQo8YnI+DQombmJzcDsmbmJz
cDsgVGhlIGtleSB3b3JkcyAmcXVvdDtNVVNUJnF1b3Q7LCAmcXVvdDtNVVNUIE5PVCZxdW90Oywg
JnF1b3Q7UkVRVUlSRUQmcXVvdDssICZxdW90O1NIQUxMJnF1b3Q7LCAmcXVvdDtTSEFMTCBOT1Qm
cXVvdDssPGJyPg0KJm5ic3A7Jm5ic3A7ICZxdW90O1NIT1VMRCZxdW90OywgJnF1b3Q7U0hPVUxE
IE5PVCZxdW90OywgJnF1b3Q7UkVDT01NRU5ERUQmcXVvdDssICZxdW90O05PVCBSRUNPTU1FTkRF
RCZxdW90OywgJnF1b3Q7TUFZJnF1b3Q7LCBhbmQ8YnI+DQombmJzcDsmbmJzcDsgJnF1b3Q7T1BU
SU9OQUwmcXVvdDsgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVz
Y3JpYmVkIGluPGJyPg0KJm5ic3A7Jm5ic3A7IFtSRkMyMTE5XS48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb25lPGJy
Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGJyPg0KMy4mbmJzcDsgVHlwZWQgUmVmZXJlbmNlczxicj4NCjxicj4NCiZxdW90OyZx
dW90OyZxdW90Ozxicj4NCiZuYnNwOyZuYnNwOyBwZXJoYXBzPGJyPg0KJm5ic3A7Jm5ic3A7IGZv
ciBpbmRleGluZyBvciB0aGUgcHJlc2VudGF0aW9uIG9mIGFkZGl0aW9uYWwgcmVsYXRlZCBpbmZv
cm1hdGlvbjxicj4NCiZuYnNwOyZuYnNwOyBmb3IgdGhlIHVzZXIuPGJyPg0KJnF1b3Q7JnF1b3Q7
JnF1b3Q7PGJyPg0KPGJyPg0KVGhvdWdodCBFbmdsaXNoIGlzIG5vdCBteSBuYXR1cmFsIGxhbmd1
YWdlLCB0aGVyZSBtaWdodCBiZSBhIG5pdCB0aGVyZS4gPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7
IHBlcmhhcHM8YnI+DQombmJzcDsmbmJzcDsgZm9yIGluZGV4aW5nIG9yIHByZXNlbnRhdGluZyB0
aGUgYWRkaXRpb25hbCByZWxhdGVkIGluZm9ybWF0aW9uPGJyPg0KJm5ic3A7Jm5ic3A7IHRvIHRo
ZSB1c2VyLjxicj4NCi0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhbmdlZCB0bzo8YnI+DQo8YnI+DQpwZXJoYXBz
IGZvciBpbmRleGluZyBvciB0aGU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgcHJlc2VudGluZyBvZiBhZGRpdGlvbmFsIHJlbGF0ZWQgaW5mb3JtYXRpb24g
Zm9yIHRoZSB1c2VyLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K
PGJyPg0KJnF1b3Q7JnF1b3Q7JnF1b3Q7PGJyPg0KVXNpbmcgU1RSVUNUVVJFRC1MT0NBVElPTiwg
aW5mb3JtYXRpb24gYWJvdXQgYSBudW1iZXIgb2YgaW50ZXJlc3Rpbmc8YnI+DQombmJzcDsmbmJz
cDsgbG9jYXRpb25zIGNhbiBiZSBjb21tdW5pY2F0ZWQsIGZvciBleGFtcGxlLCBwYXJraW5nLCBy
ZXN0YXVyYW50cyBhbmQ8YnI+DQombmJzcDsmbmJzcDsgdGhlIHZlbnVlLiZuYnNwOyBTZXJ2ZXJz
IGFuZCBjbGllbnRzIGNhbiByZXRyaWV2ZSB0aGUgb2JqZWN0cyB3aGVuIHN0b3Jpbmc8YnI+DQom
bmJzcDsmbmJzcDsgdGhlIGV2ZW50IGFuZCB1c2UgdGhlbSB0byBpbmRleCBieSBnZW9ncmFwaGlj
IGxvY2F0aW9uLjxicj4NCiZxdW90OyZxdW90OyZxdW90Ozxicj4NCjxicj4NCkl0IGlzIG5vdCBj
bGVhciBmcm9tIHRoZSB0ZXh0IHRoYXQgdGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uIG1lbnRpb25l
ZCBhYm92ZSAoZS5nLiBhZGRyZXNzLCByZWdpb24sIGNvdW50cnksIHBvc3RhbCBjb2RlKSB0aGF0
IG1vdGl2YXRlZCB0aGUgU1RSVUNUVVJFRC1MT0NBVElPTiBhcmUgcGFydCBTVFJVQ1RVUkVELUxP
Q0FUSU9OLiBUaHVzIEkgd291bGQgYWxzbyBtZW50aW9uIHRoZW0NCjxicj4NCjxicj4NCjxicj4N
ClVzaW5nIFNUUlVDVFVSRUQtTE9DQVRJT04sIGluZm9ybWF0aW9uIGFib3V0IGEgbnVtYmVyIG9m
IGludGVyZXN0aW5nPGJyPg0KJm5ic3A7Jm5ic3A7IGxvY2F0aW9ucyBjYW4gYmUgY29tbXVuaWNh
dGVkLCBmb3IgZXhhbXBsZSwgYWRkcmVzcywgcmVnaW9uLCBjb3VudHJ5LCBwb3N0YWwgY29kZSBh
cyB3ZWxsIGFzIG90aGVyIGluZm9ybWF0aW9ucyBzdWNoIGFzIHRoZSBwYXJraW5nLCByZXN0YXVy
YW50cyBhbmQ8YnI+DQombmJzcDsmbmJzcDsgdGhlIHZlbnVlLiZuYnNwOyBTZXJ2ZXJzIGFuZCBj
bGllbnRzIGNhbiByZXRyaWV2ZSB0aGUgb2JqZWN0cyB3aGVuIHN0b3Jpbmc8YnI+DQombmJzcDsm
bmJzcDsgdGhlIGV2ZW50IGFuZCB1c2UgdGhlbSB0byBpbmRleCBieSBnZW9ncmFwaGljIGxvY2F0
aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkRvbmU8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS08YnI+DQo8YnI+DQozLjEuMi4mbmJzcDsg
SXRpbmVyYXJpZXM8YnI+DQo8YnI+DQo8YnI+DQomcXVvdDsmcXVvdDsmcXVvdDs8YnI+DQpUaGUg
Y29udGFjdCBpbmZvcm1hdGlvbiBjYW48YnI+DQombmJzcDsmbmJzcDsgcHJvdmlkZSBkZXRhaWxl
ZCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgYm9va2luZyBhZ2VudCwgdGhlIGFpcmxpbmVzPGJyPg0K
Jm5ic3A7Jm5ic3A7IGFuZCBjYXIgaGlyZSBjb21wYW5pZXMgYW5kIHRoZSBob3RlbC48YnI+DQom
cXVvdDsmcXVvdDsmcXVvdDs8YnI+DQo8YnI+DQpMb29rcyB0byBtZSB0aGF0IHRoZXJlIGlzIGFu
IGFkZGl0aW9uYWwgJnF1b3Q7YW5kJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlbW92ZWQ8YnI+DQo8YnI+
DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
YnI+DQo8YnI+DQo8YnI+DQo1LiZuYnNwOyBOZXcgUHJvcGVydHkgUGFyYW1ldGVyczxicj4NCjxi
cj4NCiZxdW90OyZxdW90OyZxdW90Ozxicj4NCiZuYnNwOyZuYnNwOyBUaGlzIHNwZWNpZmljYXRp
b24gbWFrZXMgdXNlIG9mIHRoZSBMQUJFTCBwcm9wZXJ0eSBwYXJhbWV0ZXIgd2hpY2ggaXM8YnI+
DQombmJzcDsmbmJzcDsgZGVmaW5lZCBpbiBbUkZDNzk4Nl08YnI+DQomcXVvdDsmcXVvdDsmcXVv
dDs8YnI+DQo8YnI+DQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIHBhcmFtZXRlcnMgZGVz
Y3JpYmVkIGluIHRoaXMgc2VjdGlvbiBhcHBseSB0byB0aGUgTEFCRUwgcHJvcGVydHkuLiBJdCBz
ZWVtcyB0byBtZSB0aGF0IHRoaXMgaXMgdGhlIGZpcnN0IHRpbWUgdGhlIExBQkVMIHByb3BlcnRp
ZXMgYW5kIGFzc29jaWF0ZWQgcGFyYW1ldGVycyBhcmUgbWVudGlvbmVkIGluIHRoZSBkb2N1bWVu
dC4gSW4gb3RoZXIgd29yZHMsIEkgaGF2ZSBoYXJkIHRpbWUgZmluZGluZw0KIHdoZXJlIHRoaXMg
c2VjdGlvbiBpcyBpbnRyb2R1Y2VkJm5ic3A7IGluIHRoZSBwcmV2aW91cyBzZWN0aW9ucyBzdWNo
IGFzIHRoZSBpbnRyb2R1Y3Rpb24uIElmIEkgYW0gY29ycmVjdCwgbWF5YmUgdGhhdCBjb3VsZCBi
ZSBjbGFyaWZpZWQgaW4gdGhlIGludHJvZHVjdGlvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxBQkVMIGlzIGEg
cGFyYW1ldGVyIC0gaXQgdHVybnMgdXAgaW4gdGhlIEFCTkYgZm9yIGEgbnVtYmVyIG9mIHRoZSBw
cm9wZXJ0aWVzIGRlZmluZWQgaGVyZS4gVGhlIHBocmFzZSAmcXVvdDtwcm9wZXJ0eSBwYXJhbWV0
ZXImcXVvdDsgd2FzIHB1bGxlZCBvdXQgb2YgdGhhdCBzcGVjIC0gZnJvbSA1NTQ1IGFzIHdlbGwu
ICZxdW90O0xBQkVMIHBhcmFtZXRlciZxdW90OyBpcyBhIGxpdHRsZSBjbGVhcmVyIEkgdGhpbmsu
IEknbGwgdHJ5IHRoYXQuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgZG9j
dW1lbnQgaXMgc3RydWN0dXJlZCB3aXRoIGEga2luZCBvZiBib3R0b20gLSB1cCBhcHByb2FjaC4g
cGFyYW1ldGVycyAmbHQ7IHByb3BlcnRpZXMgJmx0OyBjb21wb25lbnRzLiBUaHVzIEkgYW0gd29u
ZGVyaW5nIGlmIHRoZXJlIGFyZSBhbnkgcmVhc29ucyBmb3Igbm90IGhhdmluZyB0aGUgQ2FsZW5k
YXIgQ29tcG9uZW50cyBhdCB0aGUgdmVyeSBlbmQgaW5zdGVhZCBvZiBhdCB0aGUgYmVnaW5uaW5n
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi
PkkgYW0gYWxzbyB3b25kZXJpbmcgaWYgdGhhdCB3b3VsZCBub3QgYmUgbW9yZSBlYXN5IHRvIHJl
YWQgdGhlIGRvY3VtZW50IHdpdGggUGFydGljaXBhbnQgVHlwZXMgYW5kIFJlc291cmNlIFR5cGVz
IGxpc3RlZCB3aXRoaW4gdGhlaXIgcmVzcGVjdGl2ZSBQcm9wZXJ0aWVzLg0KPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SSBzZWUgd2hhdCB5b3UgbWVhbiBub3cuIE1ha2VzIHNlbnNlLjxicj4NCjxicj4NCjxvOnA+PC9v
OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTWF5IDE1LCAyMDE4IGF0IDE6MTIgUE0sIERh
bmllbCBNaWdhdWx0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24u
Y29tIiB0YXJnZXQ9Il9ibGFuayI+ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h
cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5IaSwgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPmRyYWZ0LWlldGYtY2FsZXh0LWV2ZW50cHViLWV4dGVuc2lvbnMgWzFd
IGlzIGFscmVhZHkgb24gV0dMQy4gV2Ugd291bGQgbGlrZSB0byBzdWZmaWNpZW50IHJldmlld3Mg
dG8gbW92ZSB0aGUgZG9jdW1lbnQgdG8gdGhlIElFU0cuIElmIHlvdSBoYXZlIG5vdCB5ZXQgY29t
bWVudGVkIHRoZSBkb2N1bWVudCwgcGxlYXNlIHByb3ZpZGUgeW91ciBmZWVkYmFja3MgYnkgTWF5
IDI5IHNvIHdlIGNhbiBtb3ZlIHRoZSBkb2N1bWVudA0KIGZvcndhcmQuIDxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3VycywgPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYWxleHQgY28tY2hh
aXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+WzFdIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0
LWlldGYtY2FsZXh0LWV2ZW50cHViLWV4dGVuc2lvbnMvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNhbGV4dC1ldmVudHB1Yi1l
eHRlbnNpb25zLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N
CjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5jYWxzaWZ5IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpjYWxzaWZ5QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
Y2Fsc2lmeUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NhbHNpZnkiIHRhcmdldD0iX2JsYW5r
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NhbHNpZnk8L2E+PG86cD48
L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPGJyPg0KY2Fsc2lmeSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls
dG86Y2Fsc2lmeUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNhbHNpZnlAaWV0Zi5vcmc8L2E+
PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYWxz
aWZ5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9jYWxzaWZ5PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+DQpjYWxzaWZ5IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9
Im1haWx0bzpjYWxzaWZ5QGlldGYub3JnIj5jYWxzaWZ5QGlldGYub3JnPC9hPjxicj4NCjxhIGhy
ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Fsc2lmeSIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Fsc2lmeTwv
YT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_8a411e79d31b417ea7cf46222e2a2a5eericssoncom_--


From nobody Tue Aug  7 20:54:05 2018
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 5AB1B128CB7 for ; Tue,  7 Aug 2018 20:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 i9eQ4DJIl7xO for ; Tue,  7 Aug 2018 20:53:59 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8145A1286E3 for ; Tue,  7 Aug 2018 20:53:59 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id w26-v6so971836qto.5 for ; Tue, 07 Aug 2018 20:53:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=bM1EvXPmnJGxQhb4nlQI6aTtGS0VHIO4eB0eAD/A4vU=; b=R53vN2fQbZhCeaIzG4rgNk4lU74mCnIdKsGN3OxAbDzB1+h9N4OloLrA7NhADu1zxr QvmCopRHZ87bLy3as88cq7h59vhSkR10wYkw9m47ZVJWC9gGIUx3peolkYQaYl8TvUrs +O4ZAk4GiF9amB6oZHLxQhKWGvJA5fOwrinma7xR8ZvJZSJ28PrEfAPK48cBmcEA45IX w2pBY02m55QpMgqbZQh1uTgwiE2Mshmxa29Y/7ynIruW7hpR/UblZctsmkT2oH4VZetO 0hBiLm0bU2Ncb+mV7y7a4UWm/Kj1vkjwI3NH7P9zEu1up/0nGhMMnURwa/PGWq31J4Vr 2b0g==
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-language; bh=bM1EvXPmnJGxQhb4nlQI6aTtGS0VHIO4eB0eAD/A4vU=; b=Fv499ll7pqbDU2R0eNth1ajcf+cAVmT7QoD3ZPp1FYx4Jx3Yu4VYwZPKL1qft8DKGQ niSbAccn5XGUBTJdLz6m2Ny3V+r2P0L/Ahp72gFUQYr2PXjkYIO2KZITZviFCAkGM9GN tqePCQb9Sp4eM/gI9YSk909ddWlciDD+aKX+NGF6GoyjZqS9nWpEPaxlADwOnkv4KzZ0 q2pq0Ur3ov8O4n+RwtntKz67ivh4qiw3+iPZ/8DxgWL7IhnNgZIkSV3tBdakBCtbXX2u G4CzvnStoJW6BCUCQa2K1EseY2iFgITIiZcjVRGADQJxITmTBmQzUSU2r618yNIIf2AO +Tfw==
X-Gm-Message-State: AOUpUlGnIKGLfuv5NoOCkazJzL5V/PIgdNzNoIWk2bKx6tMWV8gVilWa xQWt9GHlL1BYLvse6sBFdDiscZ8y
X-Google-Smtp-Source: AA+uWPy0TxEyI8BzZhUc4LpskEEevTfLQTpQVEQyQ8Afc2533Qrh3RIm0rC3mwRw5vL/bZI+dQryUQ==
X-Received: by 2002:ac8:2fc2:: with SMTP id m2-v6mr1080182qta.273.1533700438297;  Tue, 07 Aug 2018 20:53:58 -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 a6-v6sm2022450qth.8.2018.08.07.20.53.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Aug 2018 20:53:57 -0700 (PDT)
To: Daniel Migault 
Cc: "calsify@ietf.org" 
References:   <708d48bc-e213-1386-ff7b-23a476000774@gmail.com>      <297e6b6e-5d5c-438b-a0ae-aa7fe3533116@gmail.com> <8a411e79d31b417ea7cf46222e2a2a5e@ericsson.com>
From: Michael Douglass 
Message-ID: <66b9c365-c720-f9c3-4c98-c208f472370c@gmail.com>
Date: Tue, 7 Aug 2018 23:53:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <8a411e79d31b417ea7cf46222e2a2a5e@ericsson.com>
Content-Type: multipart/alternative; boundary="------------CD0F9A93490C4FC1746CBFAB"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Aug 2018 03:54:03 -0000

This is a multi-part message in MIME format.
--------------CD0F9A93490C4FC1746CBFAB
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Thanks Daniel.


On 8/7/18 18:03, Daniel Migault wrote:
>
> Hi Michael,
>
> So I am not saying that 5546 has to be removed everywhere. What I was 
> mentioning is to have what is being updated coherent across the 
> sections (Header, abstract, intro). Thus I was just suggesting to 
> replace in the abstract:
>
> OLD:
>
> This specification updates [RFC5545] and [RFC5546]
>
> NEW:
>
> This specification updates [RFC5545]
>
> This is what I found currently in the draft:
>
> In the header:
>
> Updates: 5545 (if approved)
>
> In the abstract:
>
>     This specification updates [RFC5545] and [RFC5546]
>
> In the introduction:
>
>     This document updates [RFC5545]
>
> In the remaining of the document 5546 needs to stay as it is. It is a 
> Standards Track, so a normative reference is appropriated.
>
> I apology for the confusion 😉
>
No need - I appreciate the help getting it right
>
> Yours,
>
> Daniel
>
> *From:*Michael Douglass 
> *Sent:* Tuesday, August 07, 2018 5:05 PM
> *To:* Daniel Migault 
> *Cc:* calsify@ietf.org
> *Subject:* Re: [calsify] draft-ietf-calext-eventpub-extensions-06
>
> The text references 5546 because implementors need to understand how 
> this is made backwards compatible with that spec. Shoudl that be an 
> informative reference?
>
> e.g.
>
> Section 3.1.1
>
> There may be an iTip [RFC5546] meeting request for the piano tuner
> who will arrive before the performance.  Other members of staff may
>
> On 8/7/18 08:37, Daniel Migault wrote:
>
>     Hi,
>
>     The abstract should also remove the reference to 5546 as the ref
>     has been removed from header and introduction.
>
>     Yours,
>
>     Daniel
>
>     On Mon, Aug 6, 2018 at 11:36 PM, Michael Douglass
>     > wrote:
>
>         On 8/6/18 14:52, Daniel Migault wrote:
>
>             Hi,
>
>             Initiating the shepherd write-up here are my additional
>             comments:
>
>             1) running the nits raises some minor issues so please
>             remove the '[' and ']' in the abstract.
>
>             OLD:
>
>                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.
>
>             NEW:
>
>                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.
>
>         See previous message - seems to be xml2rfc
>
>
>             2)
>
>             I do not see the following reference mentioned in the
>             text. Maybe it could be removed. If you prefer to keep it,
>             maybe informational may be the right category for it.
>
>                [W3C.REC-xml-20060816]
>                           Bray, T., Paoli, J., Sperberg-McQueen, M.,
>             Maler, E., and
>                           F. Yergeau, "Extensible Markup Language
>             (XML) 1.0 (Fourth
>                           Edition)", World Wide Web Consortium
>             Recommendation REC-
>                           xml-20060816, August 2006,
>                           .
>
>         Removed
>
>
>             3) I do not see the update of RFC 5546 being discussed in
>             the introduction. Could you please add some text ?
>
>         Removed the updates reference. 5546 is mentioned but I don't
>         belieev updated in any way.
>
>
>             4) IANA section,
>
>             I suggest to add the URL to the IANA registry as an
>             informative reference.
>             https://www.iana.org/assignments/icalendar/icalendar.xhtml#properties
>
>         Done
>
>
>             section 12.1.{1,2,3} I would remove the term
>             "Registration" to make sure the title of the section match
>             the registry. Similarly, I would replace Property by
>             Properties to match the registries.
>
>         Done
>
>             Yours,
>
>             Daniel
>
>         Thanks - Mike
>
>
>
>             On Mon, Aug 6, 2018 at 1:58 PM, Daniel Migault
>                          > wrote:
>
>                 In order to get a rough idea of the consensus to move
>                 that draft forward to the IESG, I would also
>                 appreciate your support on approving the document.
>                 Please let us know if you believe the document is
>                 ready to be moved forward.
>
>                 If you have implemented it, it would also be much
>                 appreciate to write the review.
>
>                 Yours,
>
>                 Daniel
>
>                 On Mon, Aug 6, 2018 at 1:44 PM, Daniel Migault
>                                  > wrote:
>
>                     Hi,
>
>                     Just catching up. Is the current version
>                     addressing all comments, or do we expect another
>                     version coming in the few next days ?
>
>                     Yours,
>
>                     Daniel
>
>                     On Wed, May 16, 2018 at 1:33 AM, Michael Douglass
>                                          > wrote:
>
>                         Thank you for the comments - I've submitted a
>                         new draft to address these and just realised I
>                         didn't address any of Robert's issues.
>
>                         I'll deal with those in day or so.
>
>                         On 5/15/18 23:07, Daniel Migault wrote:
>
>                             Hi,
>
>                             Please find some comments. These comments
>                             are indicative.
>
>                             Yours,
>
>                             Daniel
>
>                             Abstract:
>
>                             The header indicates that RFC 5545,and RFC
>                             5546 are updated. This must be also stated
>                             in the Abstract and in the introduction.
>
>                         Some text added
>
>                             1. Introduction
>
>                             """
>                             Current practice is to embed this
>                             information as links in the
>                                description or to add x-properties.
>                             """
>
>                             It is not clear to me how to use
>                             x-properties. Is it a notation ? In
>                             addition, I am also wondering if this does
>                             not designate the LABEL property. If that
>                             is correct, maybe that could be explicitly
>                             stated to better understand section 5.
>
>                         I've changed the text to refer to non-standard
>                         properties and provided a reference to the
>                         section in 5545.
>
>                         LABEL is a parameter used to provide a
>                         human-readable label for properties -
>                         something like the alt attribute in html - so
>                         no - that is a different usage
>
>
>
>                             The conventions needs to be updated
>                             according to RFC 8174
>
>                                The key words "MUST", "MUST NOT",
>                             "REQUIRED", "SHALL", "SHALL NOT",
>                                "SHOULD", "SHOULD NOT", "RECOMMENDED",
>                             "NOT RECOMMENDED", "MAY", and
>                                "OPTIONAL" in this document are to be
>                             interpreted as described in
>                                [RFC2119].
>
>                         Done
>
>
>                             3.  Typed References
>
>                             """
>                                perhaps
>                                for indexing or the presentation of
>                             additional related information
>                                for the user.
>                             """
>
>                             Thought English is not my natural
>                             language, there might be a nit there.
>
>                                perhaps
>                                for indexing or presentating the
>                             additional related information
>                                to the user.
>                             --
>
>                         Changed to:
>
>                         perhaps for indexing or the
>                                 presenting of additional related
>                         information for the user.
>
>
>
>                             """
>                             Using STRUCTURED-LOCATION, information
>                             about a number of interesting
>                                locations can be communicated, for
>                             example, parking, restaurants and
>                                the venue. Servers and clients can
>                             retrieve the objects when storing
>                                the event and use them to index by
>                             geographic location.
>                             """
>
>                             It is not clear from the text that the
>                             location information mentioned above (e.g.
>                             address, region, country, postal code)
>                             that motivated the STRUCTURED-LOCATION are
>                             part STRUCTURED-LOCATION. Thus I would
>                             also mention them
>
>
>                             Using STRUCTURED-LOCATION, information
>                             about a number of interesting
>                                locations can be communicated, for
>                             example, address, region, country, postal
>                             code as well as other informations such as
>                             the parking, restaurants and
>                                the venue. Servers and clients can
>                             retrieve the objects when storing
>                                the event and use them to index by
>                             geographic location.
>
>                         Done
>
>                             ---
>
>                             3.1.2. Itineraries
>
>
>                             """
>                             The contact information can
>                                provide detailed information about the
>                             booking agent, the airlines
>                                and car hire companies and the hotel.
>                             """
>
>                             Looks to me that there is an additional "and".
>
>                         Removed
>
>
>
>
>                             5.  New Property Parameters
>
>                             """
>                                This specification makes use of the
>                             LABEL property parameter which is
>                                defined in [RFC7986]
>                             """
>
>                             My understanding is that the parameters
>                             described in this section apply to the
>                             LABEL property.. It seems to me that this
>                             is the first time the LABEL properties and
>                             associated parameters are mentioned in the
>                             document. In other words, I have hard time
>                             finding where this section is introduced
>                             in the previous sections such as the
>                             introduction. If I am correct, maybe that
>                             could be clarified in the introduction.
>
>                         LABEL is a parameter - it turns up in the ABNF
>                         for a number of the properties defined here.
>                         The phrase "property parameter" was pulled out
>                         of that spec - from 5545 as well. "LABEL
>                         parameter" is a little clearer I think. I'll
>                         try that.
>
>
>                             It seems to me that the document is
>                             structured with a kind of bottom - up
>                             approach. parameters < properties <
>                             components. Thus I am wondering if there
>                             are any reasons for not having the
>                             Calendar Components at the very end
>                             instead of at the beginning.
>
>                             I am also wondering if that would not be
>                             more easy to read the document with
>                             Participant Types and Resource Types
>                             listed within their respective Properties.
>
>                         I see what you mean now. Makes sense.
>
>                             On Tue, May 15, 2018 at 1:12 PM, Daniel
>                             Migault                              > wrote:
>
>                                 Hi,
>
>                                 draft-ietf-calext-eventpub-extensions
>                                 [1] is already on WGLC. We would like
>                                 to sufficient reviews to move the
>                                 document to the IESG. If you have not
>                                 yet commented the document, please
>                                 provide your feedbacks by May 29 so we
>                                 can move the document forward.
>
>                                 Yours,
>
>                                 Calext co-chairs.
>
>                                 [1]
>                                 https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/
>
>
>
>                             _______________________________________________
>
>                             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
>
>
>         _______________________________________________
>         calsify mailing list
>         calsify@ietf.org 
>         https://www.ietf.org/mailman/listinfo/calsify
>


--------------CD0F9A93490C4FC1746CBFAB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Thanks Daniel.

    

    

    
On 8/7/18 18:03, Daniel Migault wrote:

    

    

      
      
      
      

        
Hi Michael,
            

        
 

        
So I am not
            saying that 5546 has to be removed everywhere. What I was
            mentioning is to have what is being updated coherent across
            the sections (Header, abstract, intro). Thus I was just
            suggesting to replace in the abstract:

        
 

        
OLD:

        
This
            specification updates [RFC5545] and [RFC5546]

        
NEW:

        
This
            specification updates [RFC5545]

        
 

        
This is what
            I found currently in the draft:

        
 

        
In the
            header:

        
    
            Updates: 5545 (if approved)   
            

        
In the
            abstract:

        
    This
            specification updates [RFC5545] and [RFC5546]

        
In the
            introduction:

        
    This
            document updates [RFC5545]
            

        
 

        
In the
            remaining of the document 5546 needs to stay as it is. It is
            a Standards Track, so a normative reference is appropriated.
            

        
 

        
I apology
            for the confusion 
          😉

      

    

    No need - I appreciate the help getting it right

    

      

        

        
 

        
Yours, 

        
Daniel

        
 

        

          

            
From: Michael Douglass
                <mikeadouglass@gmail.com>
                

                Sent: Tuesday, August 07, 2018 5:05 PM

                To: Daniel Migault
                <daniel.migault@ericsson.com>

                Cc: calsify@ietf.org

                Subject: Re: [calsify]
                draft-ietf-calext-eventpub-extensions-06

          

        

        
 

        
The text references 5546 because implementors need to
          understand how this is made backwards compatible with that
          spec. Shoudl that be an informative reference?

        
e.g.

        
Section 3.1.1

        
There may be an iTip [RFC5546] meeting request for the piano tuner

        
who will arrive before the performance.  Other members of staff may

        
 

        
 

        
 

        

          
On 8/7/18 08:37, Daniel Migault wrote:

        

        

          

            

              
Hi, 

            

            

              
 

            

            

              
The abstract should also remove the
                reference to 5546 as the ref has been removed from
                header and introduction.
                

            

            

              
 

            

            

              
Yours, 

            

            

              
Daniel

            

          

          

            
 

            

              
On Mon, Aug 6, 2018 at 11:36 PM,
                Michael Douglass <mikeadouglass@gmail.com>
                wrote:

              

                

                  
 

                  
 

                  

                    
On 8/6/18 14:52, Daniel Migault
                      wrote:

                  

                  

                    

                      

                        
Hi, 

                      

                      

                        
 

                      

                      

                        
Initiating the shepherd
                          write-up here are my additional comments:

                      

                      

                        
 

                      

                      

                        
1) running the nits raises
                          some minor issues so please remove the '[' and
                          ']' in the abstract.

                          

                          OLD:

                          

                             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.

                          

                          NEW:

                          

                             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.

                      

                    

                  

                  
See previous message - seems to
                    be xml2rfc

                    

                    

                  

                    

                      

                        


                          2)

                          

                          I do not see the following reference mentioned
                          in the text. Maybe it could be removed. If you
                          prefer to keep it, maybe informational may be
                          the right category for it.

                          

                             [W3C.REC-xml-20060816]

                                        Bray, T., Paoli, J.,
                          Sperberg-McQueen, M., Maler, E., and

                                        F. Yergeau, "Extensible Markup
                          Language (XML) 1.0 (Fourth

                                        Edition)", World Wide Web
                          Consortium Recommendation REC-

                                        xml-20060816, August 2006,

                                        <http://www.w3.org/TR/2006/REC-xml-20060816>.

                      

                    

                  

                  
Removed

                    

                    

                  

                    

                      

                        


                          3) I do not see the update of RFC 5546 being
                          discussed in the introduction. Could you
                          please add some text ?

                           

                      

                    

                  

                  
Removed the updates reference.
                    5546 is mentioned but I don't belieev updated in any
                    way.

                    

                    

                  

                    

                      

                        


                          4) IANA section,

                          

                          I suggest to add the URL to the IANA registry
                          as an informative reference.

                          https://www.iana.org/assignments/icalendar/icalendar.xhtml#properties

                      

                    

                  

                  
Done

                    

                    

                  

                    

                      

                        


                          section 12.1.{1,2,3} I would remove the term
                          "Registration" to make sure the title of the
                          section match the registry. Similarly, I would
                          replace Property by Properties to match the
                          registries.

                      

                    

                  

                  
Done

                    

                    

                  

                    

                      

                        
 

                      

                      

                        
Yours, 

                      

                      

                        
Daniel

                      

                    

                  

                  
Thanks - Mike 

                  

                    

                      


                        

                        

                      

                        

                          
 

                          

                            
On Mon, Aug 6, 2018 at
                              1:58 PM, Daniel Migault <daniel.migault@ericsson.com>
                              wrote:

                            

                              

                                

                                  
In order to get a
                                    rough idea of the consensus to move
                                    that draft forward to the IESG, I
                                    would also appreciate your support
                                    on approving the document. Please
                                    let us know if you believe the
                                    document is ready to be moved
                                    forward.
                                    

                                

                                

                                  
 

                                

                                

                                  
If you have
                                    implemented it, it would also be
                                    much appreciate to write the review.
                                    

                                

                                

                                  
 

                                

                                

                                  
Yours, 

                                

                                

                                  
Daniel

                                

                              

                              

                                

                                  

                                    
 

                                    

                                      
On Mon, Aug
                                        6, 2018 at 1:44 PM, Daniel
                                        Migault <daniel.migault@ericsson.com>
                                        wrote:

                                      

                                        

                                          

                                            
Hi, 

                                          

                                          

                                            
Just
                                              catching up. Is the
                                              current version addressing
                                              all comments, or do we
                                              expect another version
                                              coming in the few next
                                              days ?

                                          

                                          

                                            
 

                                          

                                          

                                            
Yours,
                                              

                                          

                                          

                                            
Daniel

                                          

                                        

                                        

                                          

                                            

                                              
 

                                              

                                                
On
                                                  Wed, May 16, 2018 at
                                                  1:33 AM, Michael
                                                  Douglass <mikeadouglass@gmail.com>
                                                  wrote:

                                                

                                                  

                                                    
Thank you for the
                                                      comments - I've
                                                      submitted a new
                                                      draft to address
                                                      these and just
                                                      realised I didn't
                                                      address any of
                                                      Robert's issues.

                                                    
I'll deal with
                                                      those in day or
                                                      so.

                                                    
 

                                                    

                                                      
On
                                                        5/15/18 23:07,
                                                        Daniel Migault
                                                        wrote:

                                                    

                                                    

                                                      

                                                        

                                                          
Hi,
                                                          

                                                        

                                                        

                                                          
 

                                                        

                                                        

                                                          
Please
                                                          find some
                                                          comments.
                                                          These comments
                                                          are
                                                          indicative.

                                                        

                                                        

                                                          
 

                                                        

                                                        

                                                          
Yours,
                                                          

                                                        

                                                        

                                                          
Daniel

                                                        

                                                        

                                                          
 

                                                        

                                                        

                                                          
Abstract:

                                                        

                                                        

                                                          
The
                                                          header
                                                          indicates that
                                                          RFC 5545,and
                                                          RFC 5546 are
                                                          updated. This
                                                          must be also
                                                          stated in the
                                                          Abstract and
                                                          in the
                                                          introduction.
                                                          

                                                        

                                                      

                                                    

                                                    
Some
                                                      text added

                                                      

                                                      

                                                    

                                                      

                                                        

                                                          
 

                                                        

                                                        

                                                          
 

                                                        

                                                        

                                                          
1. 
                                                          Introduction

                                                          

                                                          """

                                                          Current
                                                          practice is to
                                                          embed this
                                                          information as
                                                          links in the

                                                             description
                                                          or to add
                                                          x-properties.

                                                          """

                                                          

                                                          It is not
                                                          clear to me
                                                          how to use
                                                          x-properties.
                                                          Is it a
                                                          notation ? In
                                                          addition, I am
                                                          also wondering
                                                          if this does
                                                          not designate
                                                          the LABEL
                                                          property. If
                                                          that is
                                                          correct, maybe
                                                          that could be
                                                          explicitly
                                                          stated to
                                                          better
                                                          understand
                                                          section 5.

                                                        

                                                      

                                                    

                                                    
I've
                                                      changed the text
                                                      to refer to
                                                      non-standard
                                                      properties and
                                                      provided a
                                                      reference to the
                                                      section in 5545.
                                                      

                                                      

                                                      LABEL is a
                                                      parameter used to
                                                      provide a
                                                      human-readable
                                                      label for
                                                      properties -
                                                      something like the
                                                      alt attribute in
                                                      html - so no -
                                                      that is a
                                                      different usage

                                                      

                                                      

                                                    

                                                      

                                                        

                                                          


                                                          

                                                          The
                                                          conventions
                                                          needs to be
                                                          updated
                                                          according to
                                                          RFC 8174

                                                          

                                                             The key
                                                          words "MUST",
                                                          "MUST NOT",
                                                          "REQUIRED",
                                                          "SHALL",
                                                          "SHALL NOT",

                                                             "SHOULD",
                                                          "SHOULD NOT",
                                                          "RECOMMENDED",
                                                          "NOT
                                                          RECOMMENDED",
                                                          "MAY", and

                                                             "OPTIONAL"
                                                          in this
                                                          document are
                                                          to be
                                                          interpreted as
                                                          described in

                                                             [RFC2119].

                                                        

                                                      

                                                    

                                                    
Done

                                                      

                                                      

                                                    

                                                      

                                                        

                                                          


                                                          3.  Typed
                                                          References

                                                          

                                                          """

                                                             perhaps

                                                             for
                                                          indexing or
                                                          the
                                                          presentation
                                                          of additional
                                                          related
                                                          information

                                                             for the
                                                          user.

                                                          """

                                                          

                                                          Thought
                                                          English is not
                                                          my natural
                                                          language,
                                                          there might be
                                                          a nit there. 

                                                          

                                                             perhaps

                                                             for
                                                          indexing or
                                                          presentating
                                                          the additional
                                                          related
                                                          information

                                                             to the
                                                          user.

                                                          --

                                                        

                                                      

                                                    

                                                    
Changed
                                                      to:

                                                      

                                                      perhaps for
                                                      indexing or the

                                                              presenting
                                                      of additional
                                                      related
                                                      information for
                                                      the user.

                                                      

                                                      

                                                    

                                                      

                                                        

                                                          


                                                          

                                                          """

                                                          Using
                                                          STRUCTURED-LOCATION,
                                                          information
                                                          about a number
                                                          of interesting

                                                             locations
                                                          can be
                                                          communicated,
                                                          for example,
                                                          parking,
                                                          restaurants
                                                          and

                                                             the venue. 
                                                          Servers and
                                                          clients can
                                                          retrieve the
                                                          objects when
                                                          storing

                                                             the event
                                                          and use them
                                                          to index by
                                                          geographic
                                                          location.

                                                          """

                                                          

                                                          It is not
                                                          clear from the
                                                          text that the
                                                          location
                                                          information
                                                          mentioned
                                                          above (e.g.
                                                          address,
                                                          region,
                                                          country,
                                                          postal code)
                                                          that motivated
                                                          the
                                                          STRUCTURED-LOCATION
                                                          are part
                                                          STRUCTURED-LOCATION.
                                                          Thus I would
                                                          also mention
                                                          them
                                                          

                                                          

                                                          

                                                          Using
                                                          STRUCTURED-LOCATION,
                                                          information
                                                          about a number
                                                          of interesting

                                                             locations
                                                          can be
                                                          communicated,
                                                          for example,
                                                          address,
                                                          region,
                                                          country,
                                                          postal code as
                                                          well as other
                                                          informations
                                                          such as the
                                                          parking,
                                                          restaurants
                                                          and

                                                             the venue. 
                                                          Servers and
                                                          clients can
                                                          retrieve the
                                                          objects when
                                                          storing

                                                             the event
                                                          and use them
                                                          to index by
                                                          geographic
                                                          location.

                                                        

                                                      

                                                    

                                                    
Done

                                                      

                                                      

                                                    

                                                      

                                                        

                                                          
---

                                                          

                                                          3.1.2. 
                                                          Itineraries

                                                          

                                                          

                                                          """

                                                          The contact
                                                          information
                                                          can

                                                             provide
                                                          detailed
                                                          information
                                                          about the
                                                          booking agent,
                                                          the airlines

                                                             and car
                                                          hire companies
                                                          and the hotel.

                                                          """

                                                          

                                                          Looks to me
                                                          that there is
                                                          an additional
                                                          "and".

                                                        

                                                      

                                                    

                                                    
Removed

                                                      

                                                      

                                                    

                                                      

                                                        

                                                          


                                                          

                                                          

                                                          5.  New
                                                          Property
                                                          Parameters

                                                          

                                                          """

                                                             This
                                                          specification
                                                          makes use of
                                                          the LABEL
                                                          property
                                                          parameter
                                                          which is

                                                             defined in
                                                          [RFC7986]

                                                          """

                                                          

                                                          My
                                                          understanding
                                                          is that the
                                                          parameters
                                                          described in
                                                          this section
                                                          apply to the
                                                          LABEL
                                                          property.. It
                                                          seems to me
                                                          that this is
                                                          the first time
                                                          the LABEL
                                                          properties and
                                                          associated
                                                          parameters are
                                                          mentioned in
                                                          the document.
                                                          In other
                                                          words, I have
                                                          hard time
                                                          finding where
                                                          this section
                                                          is introduced 
                                                          in the
                                                          previous
                                                          sections such
                                                          as the
                                                          introduction.
                                                          If I am
                                                          correct, maybe
                                                          that could be
                                                          clarified in
                                                          the
                                                          introduction.
                                                          

                                                        

                                                      

                                                    

                                                    
LABEL
                                                      is a parameter -
                                                      it turns up in the
                                                      ABNF for a number
                                                      of the properties
                                                      defined here. The
                                                      phrase "property
                                                      parameter" was
                                                      pulled out of that
                                                      spec - from 5545
                                                      as well. "LABEL
                                                      parameter" is a
                                                      little clearer I
                                                      think. I'll try
                                                      that.

                                                      

                                                      

                                                    

                                                      

                                                        

                                                          


                                                          It seems to me
                                                          that the
                                                          document is
                                                          structured
                                                          with a kind of
                                                          bottom - up
                                                          approach.
                                                          parameters
                                                          <
                                                          properties
                                                          <
                                                          components.
                                                          Thus I am
                                                          wondering if
                                                          there are any
                                                          reasons for
                                                          not having the
                                                          Calendar
                                                          Components at
                                                          the very end
                                                          instead of at
                                                          the beginning.

                                                        

                                                      

                                                    

                                                    

                                                      

                                                        

                                                          
I am also wondering if that would not be
                                                          more easy to
                                                          read the
                                                          document with
                                                          Participant
                                                          Types and
                                                          Resource Types
                                                          listed within
                                                          their
                                                          respective
                                                          Properties.
                                                          

                                                        

                                                      

                                                    

                                                    
I
                                                      see what you mean
                                                      now. Makes sense.

                                                      

                                                      

                                                    

                                                      

                                                        

                                                          
 

                                                        

                                                      

                                                      

                                                        
 

                                                        

                                                          
On
                                                          Tue, May 15,
                                                          2018 at 1:12
                                                          PM, Daniel
                                                          Migault <daniel.migault@ericsson.com>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Hi,
                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
draft-ietf-calext-eventpub-extensions
                                                          [1] is already
                                                          on WGLC. We
                                                          would like to
                                                          sufficient
                                                          reviews to
                                                          move the
                                                          document to
                                                          the IESG. If
                                                          you have not
                                                          yet commented
                                                          the document,
                                                          please provide
                                                          your feedbacks
                                                          by May 29 so
                                                          we can move
                                                          the document
                                                          forward. 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
Yours,
                                                          

                                                          

                                                          

                                                          
Calext
                                                          co-chairs.

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
 

                                                          

                                                          
                                                          

                                                          

                                                        

                                                        
 

                                                      

                                                      


                                                        

                                                        

                                                      
_______________________________________________

                                                      
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

                                                

                                              

                                              
 

                                            

                                          

                                        

                                      

                                    

                                    
 

                                  

                                

                              

                            

                          

                          
 

                        

                      

                      
 

                    

                  

                

                


                  _______________________________________________

                  calsify mailing list

                  calsify@ietf.org

                  https://www.ietf.org/mailman/listinfo/calsify

              

            

            
 

          

        

        
 

      

    

    

  


--------------CD0F9A93490C4FC1746CBFAB--


From nobody Mon Aug 13 09:09:13 2018
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 B406C130E02 for ; Mon, 13 Aug 2018 09:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeLE8SR_H564 for ; Mon, 13 Aug 2018 09:09:10 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30ADD128CF2 for ; Mon, 13 Aug 2018 09:09:10 -0700 (PDT)
Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 2C3B121B96; Mon, 13 Aug 2018 12:09:09 -0400 (EDT)
Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 13 Aug 2018 12:09:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=AuxD4bDO5G9jCoXuYECWBoNJMSp5J k5qbmciR7OZbiQ=; b=H9Pwh1dTk2nvQq51lipFCeB2ZxHTZGE1mZUebFC+UtWyg x5RvlDtL0bqduI3BfGs+/P1esIJ/ufFbyl8DiE0r9AlqqVBgMypYw3yF7bK5Bjqj hk3yK3d08JfvQ+xVx/8S7RbXqWViRMoI9DMWskrcDvR0RYOIjIbg0QFBe6Wh9Mhx dvRbNzZ8jNlGYIn2rziPNs5Gh1zfRBrUsGswCtXU7u09FwvKB+8Cc/s64cZl8bPQ wSN2FoWYEX5a2fBkWub66pslFwxI/HK0gKjv5rg5PwpTUEX5nPmGEPNjgU1YBDnH WuFe/QxWILTMY9USGwRZ4eiQtL0kUEoAUn0op50WQ==
X-ME-Proxy:      
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 55303E21FD; Mon, 13 Aug 2018 12:09:08 -0400 (EDT)
Message-Id: <1534176548.3038328.1472620184.47962A3E@webmail.messagingengine.com>
From: Robert Stepanek 
To: calsify@ietf.org
Cc: Neil Jenkins , Bron Gondwana , Ken Murchison 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-cdcda536
Date: Mon, 13 Aug 2018 18:09:08 +0200
Archived-At: 
Subject: [calsify] Requesting JSCalendar WGLC
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Aug 2018 16:09:12 -0000

About  a month ago we updated the JSCalendar RFC draft to version 05 since workgroup adoption:  https://tools.ietf.org/html/draft-ietf-calext-jscalendar

It addresses the feedback we got in the last months, including IETF 101 and the calsify mailing list. Additionally, we got feedback from CalConnect members, up to and including latest CalConnect XLII in June 2018. If anyone does not find their input addressed, please let us know.

We kindly ask the workgroup chairs to start last call for this RFC draft, if there aren't any objections. Our goal is to finalize the RFC in the next 4 weeks.

Thanks,
Robert


From nobody Sat Aug 18 16:37:58 2018
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 D87D6130E31 for ; Sat, 18 Aug 2018 16:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org
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 xuTGJ9OzbZ50 for ; Sat, 18 Aug 2018 16:37:54 -0700 (PDT)
Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 8A16C12785F for ; Sat, 18 Aug 2018 16:37:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1534635472; i=dkim+sm-localhost@aegee.org; r=y; bh=DOSYlhCsw08eKrFDa2DJAq2VxlNU2L4iAGMoM+TOhcs=; h=Date:From:To:Subject; b=pbXczWDQaQ/79pz1/Jb8FpkMXOhpy1PYQixYHR3Rc6EeNCM66QHKbbZdH0A5iPIKL f4X1/BThLnsPOKMn8SjQ9JXhOadaktX+myYW+yi6Rziek3vvff15phS1wnGznZKPpn pHmBjDq0/7UEqsFreoaIdMl1Fv2wq4+i2WhmVf9v3fK3GMWSc9yHobkKDiSIxPPB0D 5upVhdFywA9jLWajELPRRKfC4n7n45Di3iEFyRZynzGWzCHW9JYWRvpLIfI5UUZcpF iT5T1tfrK8NqlPFbmw17VuLq3D6Sg5wrXhBqAEPdgj5dUnX6OyW5QslK5+z/p46cSA 9DaDOCC1cCUJuP1knU1uFnqapK+motJmbDTMLcGoU9Y5M8ZMYuc95lJxsfQXnv9G4V RbEFNPHnlgxPRpv3zjatum7hdyAUKcOIrsXdjdLioz17B/BLghJ3pta1+ikmQKG+Uf J7bDqrQUg/V7UJ6d8q+Ist4/I06srsZzLqIawsDxLvq6L4+UsVeKs6UnqBenrTSUwy Axg+028XFkQOk4mhvezei2SiDPDPfW5OPestloBTJc5zIE+SjuqvXYPq2Fi0h/kWbT 0bfRKRopWI6Fd3FYyG1bjNmYb6fzG5fsG+4fS5svBU+iDB/A2JbaSZHSvfK8CUtpVj fV+C1sX60e6PjVo4OTVRxD8M=
Authentication-Results: mail.aegee.org/w7INbqL5012981; dkim=none
Received: from mail.aegee.org (localhost [127.0.0.1]) by mail.aegee.org (8.15.2/8.15.2) with ESMTP id w7INbqL5012981 for ; Sat, 18 Aug 2018 23:37:52 GMT
Received: from c-76-102-151-26.hsd1.ca.comcast.net (c-76-102-151-26.hsd1.ca.comcast.net [76.102.151.26]) by webmail.aegee.org (Horde Framework) with HTTPS; Sat, 18 Aug 2018 23:37:52 +0000
Date: Sat, 18 Aug 2018 23:37:52 +0000
Message-ID: <20180818233752.Horde.esUJKQWOiboWHLScyO3X6Rq@webmail.aegee.org>
From: Dilyan Palauzov 
To: calsify@ietf.org
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.100.1 at mail.aegee.org
X-Virus-Status: Clean
Archived-At: 
Subject: [calsify] Client "Bootstrapping" Procedures for CalDAV/CardDAV for passwordless access
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Aug 2018 23:37:57 -0000

Hello,

RFC6764 "Locating Services for Calendaring Extensions to WebDAV  
(CalDAV) and vCard Extensions to WebDAV (CardDAV)", Section 6.  Client  
"Bootstrapping" Procedures suggests asking the user for minimal amount  
of data - email address or URL and a password, to complete the  
configuration.

RFC 4918 "HTTP Extensions for Web Distributed Authoring and Versioning  
(WebDAV)" - Appendix E.  Guidance for Clients Desiring to Authenticate  
says:

    Thus, the WebDAV client would be able to authenticate
    with its first couple requests to the server, provided it had a way
    to get the authentication challenge from the server with realm name,
    nonce, and other challenge information.  Note that the results of
    some requests might vary according to whether or not the client is
    authenticated -- a PROPFIND might return more visible resources if
    the client is authenticated, yet not fail if the client is anonymous. [...]

My understanding is, that a CalDAV server can offer public and private  
calendars.  When users authenticate, they see the own, internal and  
public calendars, but if they don't authenticate (=anybody on the  
globe) can see the public calendar.  In particular, for the same  
requests the server can return different answers, depending on whether  
the user is authenticated, but never return 401 to force user  
authentication.

How shall the bootstraping work for public calendars?  Entering  
anonomous@domain with any password would work, but this is unnecessary  
complicated and any user using this mechanism would ask herself how  
can be software engineers so stupid to require users to enter useless  
information.

What about closing the gap by writing one more bootstraping scenario:
* for a CalDAV server:
   (modify first bullet, by inserting *possibly*; inject more bullets)
           +  Minimal input from a user would consist of a calendar user
              address and possibly a password.  A calendar user  
address is defined
              by iCalendar [RFC5545] to be a URI [RFC3986].  Provided a
              user identifier and a domain name can be extracted from the
              URI, this simple "bootstrapping" configuration can be done.

        + When no password is provided by the user, the client shall  
assume that the server offers anonymous access and should try the  
bootraping without a password, before forcing the user to enter one on  
401 Unauthenticated response
        + When password is provided by the user, the client must send  
WWW-Authenticate when obtaining the DAV:current-user-principal and all  
subsequent reqeusts, even if the server has not returned 401  
Unauthenticated

The explicit "password" is a little bit funny, as the client can use  
WWW-Authenticate: Negotiate/GSSAPI-SPNEGO/KerberosV without any  
password, but I cannot think on a better wording.

Greetings
   Дилян


From nobody Sat Aug 18 18:55:48 2018
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 C96B0130E6A for ; Sat, 18 Aug 2018 18:55:46 -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 znlgdyRMNMBO for ; Sat, 18 Aug 2018 18:55:44 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 4DE201294D7 for ; Sat, 18 Aug 2018 18:55:44 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id t5-v6so12810318qtn.3 for ; Sat, 18 Aug 2018 18:55:44 -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=ayDqZ4njccX+fYU5grk/2ZE5WKTC4UF3xDIjxb2wQus=; b=V8UkD8JH7nTOdvLyvxfLsMhuYhkJlM3OYrDOs1CqZGqnIFcutn3rgqvbK95dxE1eRV 9DELJ3YZ8uC+1Kmyq8/vK493ET1Ocwth8oZCARcEFowAYrct0qEHJwoN5hli8S4tWWCx ZtDdflso9wWh+lo1AUiyfMH948/qTsjRSXfA7r90eoHWajxs5UXVt8vVrnd/5DsCN0gN uOS1D9aB76R7PTqhPdI5oz9lu5hegH0dYRcXBOUCPHgiT8LrVQcd/4xxT+1+YqZ7BKJz 1ScIeD1Jzfdg6yXgUpYwiS7Vsg9Im0BBZKoWgwl3QdKb0wkyGII7rFFLhXrGpVmOVNkg 7yKA==
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=ayDqZ4njccX+fYU5grk/2ZE5WKTC4UF3xDIjxb2wQus=; b=isceLLkEv47tAJ1x9zuqH3XvkxZ3kHoanr5ZcQzNShZUXgJQIHbWGO5OAJqLH92lFw wAFTb2JXPvZfwogCVhFgj0jDmmbbAg9ZkTfE/DASCoVG+VYw198JbN3XKHehUOLmlz5n 9MMq0v6XRJEgGNqmXinO7bkm4H21GW8jfqTEkrQVEQVDc9Ej52QTz3drgVHoN2xj5+PM ExmuSWqhnQJ/Z+xLBIX9jGY4Wy/3RFHZBIRHSchpcZltNcBHiTKGZwrLnK9/ri4q7wsj w0jF1/ZruBbEzm2Y3tAyXlkt3pihpb/VDinE9DUPkX1OEtxhQ3oHNsxwqprZQkPQFqQU ciuA==
X-Gm-Message-State: AOUpUlGKqFMnTlNJMA02W1/CsR9HU0Tua5FWrns3G30nSlP3zM4Lk6Ot CL2J+USoZltGfIO4gCEyMKpTYl5h
X-Google-Smtp-Source: AA+uWPyxR/1maHkRBu6iMgdWi4p4CgWcPLT9KBKsuYaEL3n6MDqTBWK/bh981U+qsUjcZn4RF9CnpA==
X-Received: by 2002:ac8:1888:: with SMTP id s8-v6mr1004027qtj.268.1534643743236;  Sat, 18 Aug 2018 18:55:43 -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 a4-v6sm3751641qtn.26.2018.08.18.18.55.42 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Aug 2018 18:55:42 -0700 (PDT)
To: calsify@ietf.org
References: <20180818233752.Horde.esUJKQWOiboWHLScyO3X6Rq@webmail.aegee.org>
From: Michael Douglass 
Message-ID: <821258b3-8eb0-fc80-e023-ef2c8e8f68ef@gmail.com>
Date: Sat, 18 Aug 2018 21:55:41 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20180818233752.Horde.esUJKQWOiboWHLScyO3X6Rq@webmail.aegee.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] Client "Bootstrapping" Procedures for CalDAV/CardDAV for passwordless access
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Aug 2018 01:55:47 -0000

On 8/18/18 19:37, Dilyan Palauzov wrote:
> Hello,
>
> RFC6764 "Locating Services for Calendaring Extensions to WebDAV 
> (CalDAV) and vCard Extensions to WebDAV (CardDAV)", Section 6. Client 
> "Bootstrapping" Procedures suggests asking the user for minimal amount 
> of data - email address or URL and a password, to complete the 
> configuration.
>
> RFC 4918 "HTTP Extensions for Web Distributed Authoring and Versioning 
> (WebDAV)" - Appendix E.  Guidance for Clients Desiring to Authenticate 
> says:
>
>    Thus, the WebDAV client would be able to authenticate
>    with its first couple requests to the server, provided it had a way
>    to get the authentication challenge from the server with realm name,
>    nonce, and other challenge information.  Note that the results of
>    some requests might vary according to whether or not the client is
>    authenticated -- a PROPFIND might return more visible resources if
>    the client is authenticated, yet not fail if the client is 
> anonymous. [...]
>
> My understanding is, that a CalDAV server can offer public and private 
> calendars.  When users authenticate, they see the own, internal and 
> public calendars, but if they don't authenticate (=anybody on the 
> globe) can see the public calendar.  In particular, for the same 
> requests the server can return different answers, depending on whether 
> the user is authenticated, but never return 401 to force user 
> authentication.
>
> How shall the bootstraping work for public calendars?  Entering 
> anonomous@domain with any password would work, but this is unnecessary 
> complicated and any user using this mechanism would ask herself how 
> can be software engineers so stupid to require users to enter useless 
> information.
Bedework offers authenticated and unauthenticated CalDAV. 
Unauthenticated is actually not part of the spec as the spec mandates 
basic auth. Most other forms of auth don't work with CalDAV (as specified).

For basic auth it's quite easy. Put authenticated on one context and 
unauth on another. Then the server can challenge on the first request to 
the authenticated context. Never chanllenge on the unauth.
>
> What about closing the gap by writing one more bootstraping scenario:
> * for a CalDAV server:
>   (modify first bullet, by inserting *possibly*; inject more bullets)
>           +  Minimal input from a user would consist of a calendar user
>              address and possibly a password.  A calendar user address 
> is defined
>              by iCalendar [RFC5545] to be a URI [RFC3986]. Provided a
>              user identifier and a domain name can be extracted from the
>              URI, this simple "bootstrapping" configuration can be done.
>
>        + When no password is provided by the user, the client shall 
> assume that the server offers anonymous access and should try the 
> bootraping without a password, before forcing the user to enter one on 
> 401 Unauthenticated response
>        + When password is provided by the user, the client must send 
> WWW-Authenticate when obtaining the DAV:current-user-principal and all 
> subsequent reqeusts, even if the server has not returned 401 
> Unauthenticated
>
> The explicit "password" is a little bit funny, as the client can use 
> WWW-Authenticate: Negotiate/GSSAPI-SPNEGO/KerberosV without any 
> password, but I cannot think on a better wording.
>
> Greetings
>   Дилян
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify


From nobody Sat Aug 18 20:09:23 2018
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 F27FD130E16 for ; Sat, 18 Aug 2018 20:09:22 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org
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 Un09kkZTVAZe for ; Sat, 18 Aug 2018 20:09:21 -0700 (PDT)
Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 BD7BA130DED for ; Sat, 18 Aug 2018 20:09:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1534648158; i=dkim+sm-localhost@aegee.org; r=y; bh=rHE9gSjXhgIjp1VvBqnqPabA5XyM308lzM1cuvSfiJg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=H5148RsAdkDU26fWmh2V9SCxPQ/X7ar2RlSuASqc0XRlPMtwXFMdLtzw6giuN3WSa EeTaVofX7GZwCZxU/jAiq9opeGaCzCMZf/7Fkp3uUgbnyD98L9xEmqxXXmYvfu1M2B b8fzRlUtH0b7Pw5SNc9iYgx7Ghp/jx/7a9WIphFRYbiCuwmy2gJKc+zITr1e9wDvc9 jxBloPFssbqV8Thk0MLYgWhSc9SIpV8bb7nzFCxu2VixlKHA2qxbbR8HbXwCmUpI8a 5WRw1uShyWdu0dWEASzTMmOv64DZZibME86xEyuIuWpTIrYQFmqYP6KwHiwrDlGHvy 2VL+S05mS+G4hHScZ+074+gwlUuyHYsPPsxJlrYtT/C71hlILehvgpwMsWYRScS+p0 W+LqVY9zS+QJXVuKArAGAcM7uiFFtBcDrUh8a5vUwnR2uGsu9XbPFacyNgelxewcYs lgKKoZrnp4I7KE9N+3ek8LR3n2Cdpq7KAEkgu9VFhCcGznkxG7++BgDvZmwYNiMJ1l djtn69VBtrBhCzZWqpxIydB3xqrEPVNSVuhTbl+zu0l3d9hsugRBdABH36suntNco/ h8BkIaBBY0bkp9BnxPmHDlLkkdeIhQR/VUcg87e1/WtBxIF0K/oRMi0a9afm9riub5 zd+VT2Gv5y/g+HdI8Zjy3KiU=
Authentication-Results: mail.aegee.org/w7J39ICw002315; dkim=none
Received: from mail.aegee.org (localhost [127.0.0.1]) by mail.aegee.org (8.15.2/8.15.2) with ESMTP id w7J39ICw002315; Sun, 19 Aug 2018 03:09:18 GMT
Received: from c-76-102-151-26.hsd1.ca.comcast.net (c-76-102-151-26.hsd1.ca.comcast.net [76.102.151.26]) by webmail.aegee.org (Horde Framework) with HTTPS; Sun, 19 Aug 2018 03:09:18 +0000
Date: Sun, 19 Aug 2018 03:09:18 +0000
Message-ID: <20180819030918.Horde.QhV2Wf7cFO4nBkr4bCOLKvj@webmail.aegee.org>
From: Dilyan Palauzov 
To: Michael Douglass 
Cc: calsify@ietf.org
References: <20180818233752.Horde.esUJKQWOiboWHLScyO3X6Rq@webmail.aegee.org> <821258b3-8eb0-fc80-e023-ef2c8e8f68ef@gmail.com>
In-Reply-To: <821258b3-8eb0-fc80-e023-ef2c8e8f68ef@gmail.com>
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.100.1 at mail.aegee.org
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [calsify] Client "Bootstrapping" Procedures for CalDAV/CardDAV for passwordless access
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Aug 2018 03:09:23 -0000

Hello Michael,

where precisely is HTTP Basic Authentication required for  
CalDAV/CardDAV and what is the purpose of this requirement?

https://tools.ietf.org/html/rfc4918#section-20.1  [WebDAV core RFC]  
requires support for Digest authentication, permitting other  
authentications, but appendix E states
    Note that the results of
    some requests might vary according to whether or not the client is
    authenticated -- a PROPFIND might return more visible resources if
    the client is authenticated, yet not fail if the client is anonymous.

so WebDAV does not require authentication.

In RFC4791 CalDAV I cannot find such requirements, too.

What do you mean by putting authenticated and unauthenticated  
resources in different context?  Do you suggest to use different  
domains, which allow the bootstrapping process to find different URLs?  
  This will help with clients which send passwords only after  
receiving 401, but will not help with clients which insist on having a  
password before performing the bootstrapping.

https://tools.ietf.org/html/rfc6352#section-9.3 [CardDAV, Client  
Configuration] adds:
    Given support for SRV records (Section 11) and DAV:current-user-
    principal-URL [RFC5397], users only need enter a user identifier,
    host name, and password to configure their client.  The client would
    take the host name and do an SRV lookup to locate the CardDAV server,
    then execute an authenticated PROPFIND on the root/resource looking
    for the DAV:current-user-principal-URL property.

So clients waiting for 401 before authenticating on performing this  
PROPFIND are indeed formally wrong.

But are CalDAV/CardDAV clients required to authenticate on purpose,  
was this an oversight, not to state clearer that unauthenticated  
accesses is bad idea, and what what speaks against clarifying this now?

Greetings
   Дилян

----- Message from Michael Douglass  ---------
    Date: Sat, 18 Aug 2018 21:55:41 -0400
    From: Michael Douglass 
Subject: Re: [calsify] Client "Bootstrapping" Procedures for  
CalDAV/CardDAV for passwordless access
      To: calsify@ietf.org


> On 8/18/18 19:37, Dilyan Palauzov wrote:
>> Hello,
>>
>> RFC6764 "Locating Services for Calendaring Extensions to WebDAV  
>> (CalDAV) and vCard Extensions to WebDAV (CardDAV)", Section 6.  
>> Client "Bootstrapping" Procedures suggests asking the user for  
>> minimal amount of data - email address or URL and a password, to  
>> complete the configuration.
>>
>> RFC 4918 "HTTP Extensions for Web Distributed Authoring and  
>> Versioning (WebDAV)" - Appendix E.  Guidance for Clients Desiring  
>> to Authenticate says:
>>
>>    Thus, the WebDAV client would be able to authenticate
>>    with its first couple requests to the server, provided it had a way
>>    to get the authentication challenge from the server with realm name,
>>    nonce, and other challenge information.  Note that the results of
>>    some requests might vary according to whether or not the client is
>>    authenticated -- a PROPFIND might return more visible resources if
>>    the client is authenticated, yet not fail if the client is  
>> anonymous. [...]
>>
>> My understanding is, that a CalDAV server can offer public and  
>> private calendars.  When users authenticate, they see the own,  
>> internal and public calendars, but if they don't authenticate  
>> (=anybody on the globe) can see the public calendar.  In  
>> particular, for the same requests the server can return different  
>> answers, depending on whether the user is authenticated, but never  
>> return 401 to force user authentication.
>>
>> How shall the bootstraping work for public calendars?  Entering  
>> anonomous@domain with any password would work, but this is  
>> unnecessary complicated and any user using this mechanism would ask  
>> herself how can be software engineers so stupid to require users to  
>> enter useless information.
> Bedework offers authenticated and unauthenticated CalDAV.  
> Unauthenticated is actually not part of the spec as the spec  
> mandates basic auth. Most other forms of auth don't work with CalDAV  
> (as specified).
>
> For basic auth it's quite easy. Put authenticated on one context and  
> unauth on another. Then the server can challenge on the first  
> request to the authenticated context. Never chanllenge on the unauth.
>>
>> What about closing the gap by writing one more bootstraping scenario:
>> * for a CalDAV server:
>>   (modify first bullet, by inserting *possibly*; inject more bullets)
>>           +  Minimal input from a user would consist of a calendar user
>>              address and possibly a password.  A calendar user  
>> address is defined
>>              by iCalendar [RFC5545] to be a URI [RFC3986]. Provided a
>>              user identifier and a domain name can be extracted from the
>>              URI, this simple "bootstrapping" configuration can be done.
>>
>>        + When no password is provided by the user, the client shall  
>> assume that the server offers anonymous access and should try the  
>> bootraping without a password, before forcing the user to enter one  
>> on 401 Unauthenticated response
>>        + When password is provided by the user, the client must  
>> send WWW-Authenticate when obtaining the DAV:current-user-principal  
>> and all subsequent reqeusts, even if the server has not returned  
>> 401 Unauthenticated
>>
>> The explicit "password" is a little bit funny, as the client can  
>> use WWW-Authenticate: Negotiate/GSSAPI-SPNEGO/KerberosV without any  
>> password, but I cannot think on a better wording.
>>
>> Greetings
>>   Дилян
>>
>> _______________________________________________
>> 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


----- End message from Michael Douglass  -----



From nobody Tue Aug 21 08:23:35 2018
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 0AA551274D0 for ; Tue, 21 Aug 2018 08:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level: 
X-Spam-Status: No, score=-4.309 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 nnt69s7V51Tm for ; Tue, 21 Aug 2018 08:23:31 -0700 (PDT)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76760126CB6 for ; Tue, 21 Aug 2018 08:23:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1534865009; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4aMijKAZS6dTYr8HVElezuj1pY1BFjiSZi7u2Rwqs3A=; b=TisvwVbMNxnTdhNXA+IneMKPF3awaL5mVis5fppLdnxSz6qI63sTn3wstPoZaQCb 5U9fm1j3Habph2Xv9v6SLlMazgtt9FC+/xt49gIoxN8aWfp813m8fv+76Cnem+yP 6m3AXPN95OoZfhKTe28GdQ83kV85DKy0fuUUaGkv8JA=;
X-AuditID: c6180641-49dff70000002b50-3e-5b7c2e71808c
Received: from EUSASMB504.ericsson.se (Unknown_Domain [147.117.188.222]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id D6.BC.11088.17E2C7B5; Tue, 21 Aug 2018 17:23:29 +0200 (CEST)
Received: from EUSASMB503.ericsson.se (147.117.188.221) by EUSASMB504.ericsson.se (147.117.188.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 21 Aug 2018 11:23:29 -0400
Received: from EUSASMB503.ericsson.se ([147.117.188.239]) by EUSASMB503.ericsson.se ([147.117.188.239]) with mapi id 15.01.1466.003; Tue, 21 Aug 2018 11:23:29 -0400
From: Daniel Migault 
To: "calsify@ietf.org" 
Thread-Topic: WGLC draft-ietf-calext-jscalendar-05
Thread-Index: AdQ5Ycc+C54BlnL/TfyGmYL4mMkvSA==
Date: Tue, 21 Aug 2018 15:23:29 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.8]
Content-Type: multipart/alternative; boundary="_000_b5befbd3cddd4a61a43a56ee5b74c856ericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXTPPd1CvZpog/ZtxhabXjSzOjB6LFny kymAMYrLJiU1J7MstUjfLoEro2vXLsaCPcoVH7cvY21gvCXXxcjJISFgIvF5w0G2LkYuDiGB Y4wST88/ZgdJCAn8YJTYdDEOIrGCUeLZq0WsIAk2ASOJtkP9YEUiApoSu6/2gMWFBXQlVvce ZYOIG0n0PrrJCGHrSTy6MB+snkVAVWL/3G1MIDavgLXEgYWLWEBsRgExie+n1oDFmQXEJW49 mc8EcZ2AxJI955khbFGJl4//sULYihKfT99gh6hPlvi36SM7xExBiZMzn7BMYBSahWTULCRl s5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWMHKXFBTm56UaGmxiBoX9Mgs1xB+Pe Xs9DjAIcjEo8vPFqNdFCrIllxZW5hxglOJiVRHgXna+OFuJNSaysSi3Kjy8qzUktPsQozcGi JM57zpM3SkggPbEkNTs1tSC1CCbLxMEp1cDYE601N2LB41kxPjUrZ8tuilpzYGfONS6BvfPM b1z5W37s47JLskyB4dYLRO4LnTx/5H5b7vwlU48oNdte23Vp+pq1EUmTJI5IqQisXrdt50+Z Wc6zX0w1d8rZnh2h8e/VqhTvmEMTNl6IP/ZPd9sUe7fUJQVR7PkbZsu3+r3h/Xwy7giHwok3 aUosxRmJhlrMRcWJAJXbVi95AgAA
Archived-At: 
Subject: [calsify] WGLC draft-ietf-calext-jscalendar-05
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Aug 2018 15:23:34 -0000

--_000_b5befbd3cddd4a61a43a56ee5b74c856ericssoncom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

This email starts a WGLC for the draft-ietf-calext-jscalendar [1]. Please p=
rovide your feed backs on the mailing list by September 4.

This is am important piece of work for the calext WG, so we expect a signif=
icant number of reviews and support before moving this forward to the IESG.

One of the main issue the chairs have with the calext WG is that we are usu=
ally short in term of reviews before sending a document to the IESG. We exp=
ect the situation will improve especially with that draft. So please be awa=
re that reviews really matters in our IETF process.

Known Implementations are also an important piece of information, so please=
 provide implementations you are aware of/ working on.

If you have issues providing publicly reviews, feel free to contact me priv=
ately.

Yours,
Daniel


[1] https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/

--_000_b5befbd3cddd4a61a43a56ee5b74c856ericssoncom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi, 


 


This email starts a WGLC for the draft-ietf-calext-j=
scalendar [1]. Please provide your feed backs on the mailing list by Septem=
ber 4.



 


This is am important piece of work for the calext WG=
, so we expect a significant number of reviews and support before moving th=
is forward to the IESG.



 


One of the main issue the chairs have with the calex=
t WG is that we are usually short in term of reviews before sending a docum=
ent to the IESG. We expect the situation will improve especially with that =
draft. So please be aware that reviews
 really matters in our IETF process. 


 


Known Implementations are also an important piece of=
 information, so please provide implementations you are aware of/ working o=
n.


 


If you have issues providing publicly reviews, feel =
free to contact me privately.


 


Yours, 


Daniel 


 


 


[1] https://datatracker.ietf.org/doc/draft-ietf-cale=
xt-jscalendar/






--_000_b5befbd3cddd4a61a43a56ee5b74c856ericssoncom_--


From nobody Mon Aug 27 07:22:06 2018
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 6B844130ED8 for ; Mon, 27 Aug 2018 07:21:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apthorpia-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 Bt8lDHyipp2d for ; Mon, 27 Aug 2018 07:21:54 -0700 (PDT)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 7545C130EFB for ; Mon, 27 Aug 2018 07:21:54 -0700 (PDT)
Received: by mail-pf1-x435.google.com with SMTP id k21-v6so7809796pff.11 for ; Mon, 27 Aug 2018 07:21:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apthorpia-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=3hqidA+UhLJPTNVDCSWQgFfUIy1IzSoRtz5Boo6QCis=; b=j7/oVNEkisNHi3j45IuJA5J7kSu/SMUCirSqd0IwBcM6cDJc+q1tGSN1fJ44UBKtGB YsrFWI6+rjwd5LQEGxO+X7tzQ6bm96XLQuCLR6k0DuIe0ude3vrzz6YqrtYlnabu/NsA 8FxaV6FxQ4yyU20Ihxglc0jyp3OWsxVYlFHdd3gwI3VS0eBT3HYAaFcig4mxecyllHQD kOmf7OE70rRg1cnLjKQK0mOJFWlTaBLqoEcPo/ugwl7shOjUFZ5GEVYYWrlrw2cuR8aG k4GCmmSNQ1DNBWDo1pmSOKAZYr1b9O/OkCNAYbS0L3STIAbeGfX2gZuisOUC/lCUb+yP /3HQ==
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=3hqidA+UhLJPTNVDCSWQgFfUIy1IzSoRtz5Boo6QCis=; b=UlFG2l4ns2/79EChTiLDMuY29LbLYYXhJdA3tHcXEvTabhYxy/CPrKKIr6qBm5Rvaa pxrTVLtMq0U8JrwrydVtbixSmMyFEOvPBJ0ukii8Xw4fhLtF8KAq5fPqzLnNZiMMgR3k lJJQRf/cvxb9SG2N9WXpiSlLdVVIjFmJKqoQqSD98H1MliksheZqduBoXplMEtGzIkwN NknICxXstCceSt/E8ixfR4zNIk2XWOGenCHLge33GGymXJv3573IInPK0aojHcYt4a3L yys4DbFlhZepOWr0+3kQUf0Ccn9FVp2WERjyEsmFfJWB/Ciu+KhnVAioJ/XuMFgwVBIH DyFg==
X-Gm-Message-State: APzg51B1jblQYo/iCCs0RjRwxcxAEQ34YK4BSeIIAVNm1T0CN2TbykZG nbFdZWpKy9eQ0uD78UcxSb728q7nSOY=
X-Google-Smtp-Source: ANB0VdZkZ78LzWyBqbKfrI7S1iQLwEI7fbOUQfqemLl4pb35RtC7WIU0oO06WEqFBnyqarGkM6ZEHw==
X-Received: by 2002:a65:5c83:: with SMTP id a3-v6mr12800689pgt.164.1535379713867;  Mon, 27 Aug 2018 07:21:53 -0700 (PDT)
Received: from [192.168.2.109] ([175.156.157.4]) by smtp.gmail.com with ESMTPSA id z5-v6sm20644649pfh.83.2018.08.27.07.21.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 07:21:52 -0700 (PDT)
To: Robert Stepanek , calsify@ietf.org
Cc: Ken Murchison 
References: <1534176548.3038328.1472620184.47962A3E@webmail.messagingengine.com>
From: Adrian Apthorp 
Message-ID: 
Date: Mon, 27 Aug 2018 22:21:49 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <1534176548.3038328.1472620184.47962A3E@webmail.messagingengine.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: 
Subject: Re: [calsify] Requesting JSCalendar WGLC
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Aug 2018 14:22:06 -0000

Robert,

Just a couple of comments for clarification:

1) I don't see the previous comment I made on task status addressed 
(section 5.2.8). As worded it implies that 'status' refers to the 
scheduling status when in fact it is the overall status of the task.

2) Great to see 'pending' and 'failed' statuses are included. However 
the definition of 'pending' needs to be clarified to distinguish from 
'needs-action'. We proposed 'created and accepted, but has not yet 
started'. There's a bit more on the valid states and state changes in 
the Tasks draft. See examples at the end of the document.

I have one more significant comment that I've raised before. I see an 
opportunity to change 5.2.5 from 'completed' to a general purpose last 
status change time stamp 'status_changed'. i.e. If the task has 
completed then the value of 'status_changed' is the completed time. I 
know this is a more significant change but mitigates 'completed' 
becoming a redundant element with a potential future change.

Cheers


Adrian


On 14/08/18 00:09, Robert Stepanek wrote:
> About  a month ago we updated the JSCalendar RFC draft to version 05 since workgroup adoption:  https://tools.ietf.org/html/draft-ietf-calext-jscalendar
>
> It addresses the feedback we got in the last months, including IETF 101 and the calsify mailing list. Additionally, we got feedback from CalConnect members, up to and including latest CalConnect XLII in June 2018. If anyone does not find their input addressed, please let us know.
>
> We kindly ask the workgroup chairs to start last call for this RFC draft, if there aren't any objections. Our goal is to finalize the RFC in the next 4 weeks.
>
> Thanks,
> Robert
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify



From nobody Thu Aug 30 02:05:18 2018
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 4C75112F1A2; Thu, 30 Aug 2018 02:05: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.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: calsify@ietf.org
Message-ID: <153561991025.3128.17199133283283558597@ietfa.amsl.com>
Date: Thu, 30 Aug 2018 02:05:10 -0700
Archived-At: 
Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-06.txt
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Aug 2018 09:05:10 -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           : JSCalendar: A JSON representation of calendar data
        Authors         : Neil Jenkins
                          Robert Stepanek
	Filename        : draft-ietf-calext-jscalendar-06.txt
	Pages           : 53
	Date            : 2018-08-30

Abstract:
   This specification defines a data model and JSON representation of
   calendar data that can be used for storage and data exchange in a
   calendaring and scheduling environment.  It aims to be an alternative
   to the widely deployed iCalendar data format and to be unambiguous,
   extendable and simple to process.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-calext-jscalendar-06
https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-06


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 Thu Aug 30 02:08:18 2018
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 A35811277BB for ; Thu, 30 Aug 2018 02:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRzFUrnudt9K for ; Thu, 30 Aug 2018 02:08:10 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D20A12008A for ; Thu, 30 Aug 2018 02:08:10 -0700 (PDT)
Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 5473B20F20 for ; Thu, 30 Aug 2018 05:08:09 -0400 (EDT)
Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 30 Aug 2018 05:08:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=mcgL1kGQyLs5Huz5edkIrtf8CMjk+ 8OjVDTLh1IywvA=; b=MVAq1IIwR1DSYWoT4aNb7AYI+zPPozN6chMQjFio8yXLj gollFxZOmMgIN9UXlMAlP9WFOeQx4M3n3bOd6MXj+wZSBmQx9pDZ5xwPuJesX6AC /pWn46mvmqkIYqt9MPORilYfjKYpbLkL6Wt90l0lYzebpYfmvlLgSHSoYp1faMd9 gUbQtXaaZD2X1yEoUSSkC3gyk7zfb7/KAKc1+gRS9oQuLuHKrWj23zFdVDdOLvll XMORRWrH8IZI7K3CU4h/NtGpJihCjvHszAvXO2yJGNyHdMuBZMq1wy1bOJRg+z2q Mp71+bVAl91yohe+x7pDZA1eYwH4sp+tGGs+T/xCA==
X-ME-Proxy:      
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id BEDDAE229E; Thu, 30 Aug 2018 05:08:07 -0400 (EDT)
Message-Id: <1535620087.162329.1491059832.7225FE84@webmail.messagingengine.com>
From: Robert Stepanek 
To: calsify@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_15356200871623290"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-76c9aaa1
Date: Thu, 30 Aug 2018 11:08:07 +0200
Archived-At: 
Subject: [calsify] Updated JSCalendar draft calext-06
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Aug 2018 09:08:17 -0000

This is a multi-part message in MIME format.

--_----------=_15356200871623290
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"

Thanks for your feedback on WGLC so far. I have just uploaded an
updated version 06[1] of the JSCalendar RFC draft document,
incorporated your input.
This version includes the following notable changes:

 * *recurrenceRule*: the recurrence evaluation for yearly frequencies
   with no byYearDay has been updated (section 4.3.1[2]). The diff on
   the Git repository highlights the differences: see here[3]
 * *estimatedDuration*: the recommendation to estimate the property
   value within the planned task time-frame has been removed. The
   estimation is left to the application (section 5.2.4[4]).
 * *method*: the iTIP method property on a JSCalendar object was
   erroneously defined to translate to a VEVENT/VTODO METHOD property.
   But the METHOD property in iCalendar is defined on the VCALENDAR
   component (section 6.4[5]).
 * *JSTask status and completed:* the JSTask status property has been
   redefined to define the overall status of a task. The completed
   property has been replaced with the statusUpdatedAt property
   (section 6.2[6]).
The complete version history for the document is available on the
Github repo[7].
Cheers,
Robert

Links:

  1. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-06
  2. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-06#section-4.3.1
  3. https://github.com/CalConnect/PUBLIC_DRAFTS/commit/292e01a848691480a3dbb3a30f4c608b1e504f43#diff-9086f322bca623a30c8136fcfca365f7
  4. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-06#section-5.2.4
  5. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-06#section-6.4
  6. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-06#section-6.2
  7. https://github.com/CalConnect/PUBLIC_DRAFTS/commits/master/jscalendar

--_----------=_15356200871623290
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"








Thanks for your feedback on WGLC so far. I have just uploaded an=
 updated version 06 of the JSCalendar RFC draft document, incorporated you=
r input.





This version includes the following notable changes:





  • recurrenceRule: the recurrence evaluation for yearly frequen=
cies with no byYearDay has been updated (section 4.3.1). The=
 diff on the Git repository highlights the differences: see here
  • estimatedDuration: the recommendation to estimate the property value w=
ithin the planned task time-frame has been removed. The estimation is left =
to the application (section 5.2.4).
  • method: the iTIP method property on a JSCalendar object was erroneously defined =
to translate to a VEVENT/VTODO METHOD property. But the METHOD property in =
iCalendar is defined on the VCALENDAR component (section 6.4).=

  • JSTask status and completed: the JSTask status property=
 has been redefined to define the overall status of a task. The completed p=
roperty has been replaced with the statusUpdatedAt property (section 6.2).



The complete version history for the document is available on the Github repo. 





Cheers,


Robert




--_----------=_15356200871623290--


From nobody Thu Aug 30 02:09:25 2018
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 F12321277BB for ; Thu, 30 Aug 2018 02:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrfpvuOsjdEI for ; Thu, 30 Aug 2018 02:09:20 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A2C130DC0 for ; Thu, 30 Aug 2018 02:09:20 -0700 (PDT)
Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 1134821BE2 for ; Thu, 30 Aug 2018 05:09:19 -0400 (EDT)
Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 30 Aug 2018 05:09:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=ho6+fseCOIeByahUi2LVI0401gYW2 gQex4Du4//TrJg=; b=qr04o+AYryKyjr7bh5QSMl6+7//UBwXgQ6Dk5/066JUNO RE6RC94IPA+5yvnLkyJZaY5WbILf44OsqTDQIGGMHafveUdZOmygb+obQsw6C7ry NLQc5kIa3JL2fNpiprO0DmugzemTFqUlnXfuokdF2z9ARJ0X9I5Ig4f8BLpNPQB/ P0VeFNVMFvDL4zKW1A1M47OOUWP3FPI3aOPM6rDJNGI4MEbOA4XCUPNrW8o72Acf E+j4lTWRbl4d6oPBtNPun/UVLJj+LUvlj7W/iwoEwu/X5NDcpQCdX9JvH72yw0Pf ASX7E3g2sjjZ39w57M7/fOFYQ3CPcy1OfkPmF1OkA==
X-ME-Proxy:      
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id AB752E229E; Thu, 30 Aug 2018 05:09:18 -0400 (EDT)
Message-Id: <1535620158.162328.1491072080.2C47352D@webmail.messagingengine.com>
From: Robert Stepanek 
To: calsify@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-76c9aaa1
Date: Thu, 30 Aug 2018 11:09:18 +0200
Archived-At: 
Subject: [calsify] JSCalendar: what to do with JSTask?
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Aug 2018 09:09:23 -0000

I would like to discuss the status of JSTask and its readiness for acceptance:

The JSCalendar specification defines object types for events, tasks and groups. The event and group objects have underwent years of discussion and there seems to be general consensus of their definition. However, the task object hasn't received that much attention. Much of the definition of JSTtask properties is based on a pending iCalendar VTODO RFC update: https://tools.ietf.org/html/draft-apthorp-ical-tasks-01

With JSTask most likely becoming a standard before its updated iCalendar counterpart, I wonder if the current JSTask specification is all that stable? Is there the risk of  defining a snapshot of an ongoing discussion? If there is, we could split off JSTask from the JSCalendar specification. The current specification should it make easy to define additional object types in separate RFC documents.

Looking forward to your feedback.

Robert


From nobody Thu Aug 30 06:48:24 2018
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 F3A59130E85 for ; Thu, 30 Aug 2018 06:48:22 -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 B2BXVIb1lt53 for ; Thu, 30 Aug 2018 06:48:21 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 47112130E6F for ; Thu, 30 Aug 2018 06:48:21 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id z8-v6so9801208qto.9 for ; Thu, 30 Aug 2018 06:48:21 -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=41wk/tB41qlviKhqfRPeeRXrFP0yXj6hDQ3b6yv3f2o=; b=Nl8Ikft2FGuVC0c4z9lbWR1M2VWSwCbLfmmLozaPLKpZBRPJWVRgxhK2S0HGua3vdP 2hgiK8qyOG0HqkxFN1wcNRTOf3I27VFMDNC0QIZvjd50Ym2ClI68L/Yu5GhAdbqnNDnM coYwrH+XSGDXYROUvtTi7iRU5laExkOoJ0MFpuH2a2iZNCyvXxk7Tbih43LotUdN3X4Q F2TYDRh9CwGLWB0tnqGQkqZir7eqL9EpEREfaFGBJG1fcgKoYCA4pLW72eYRBvATdMmZ A5CeOJPfqrxmXLDa/9vSCwnv4vlFcV767qTRKyhSeWzlsfjIumq+6yHho+tqGifASbtq g7LQ==
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=41wk/tB41qlviKhqfRPeeRXrFP0yXj6hDQ3b6yv3f2o=; b=kh9xOXq6kD5Pht0JmsOBmVsUuccvf6H90jYRWp4rQYq+I4vm6zVr2AAGLie4cWms0T SyZAQGP1xvVWZyE/EmItlOPFJWqLqgjVBOAtmtAii+JPArGy9IWuFVKA6g+eTlUtKkUm 1mNkf8yb7OY6W7nN54zdfVl27N7Tnka1vIvrducAL6Rb9fB3W/7Xg2lc38ySnIzrdVfb P6/G8UQu7HXwr+hZhhpUVw93ak+/Xa3CQunhBuLcc7hTAAioaG1iaMC2cX7tfluIyykb 14zgQS77Zqi3Yp+rcp3K1cqbFXE7/zqT6wTKO2lZTeEFuVgD7KL1LI/qsdRGPyVRdkIr APPA==
X-Gm-Message-State: APzg51Bnauy047dru6ito8GvgIfWgP0/smEnQ9mdtQll945IDxbZAlRJ v1fk8BW3gYYkzDI2cjaoNk/bvFlj
X-Google-Smtp-Source: ANB0VdbpZa7K8x/S47FnUb49OKEimDwVMmI3t3XW0QWxC2I0yhHu/KPwt0QkFuKftdKeCji7ZJI0Yw==
X-Received: by 2002:aed:2f83:: with SMTP id m3-v6mr11632172qtd.96.1535636900371;  Thu, 30 Aug 2018 06:48:20 -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 t11-v6sm4319598qkt.28.2018.08.30.06.48.19 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Aug 2018 06:48:19 -0700 (PDT)
To: calsify@ietf.org
References: <1535620158.162328.1491072080.2C47352D@webmail.messagingengine.com>
From: Michael Douglass 
Message-ID: <5eb08950-5d3a-ba80-7fdd-653f48ce5792@gmail.com>
Date: Thu, 30 Aug 2018 09:48:18 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <1535620158.162328.1491072080.2C47352D@webmail.messagingengine.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] JSCalendar: what to do with JSTask?
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Aug 2018 13:48:23 -0000

In iCalendar and the current JsCalendar much of what makes up a task is 
well defined.

I take the point about some of the newer properties but they're a 
relatively small part of the daft.

However, in other areas we've taken the opportunity to extend the model 
so I don't see these as much different.

I'm currently in the process of developing an app which relies heavily 
on tasks and the ease of translating from tasks to derived events and 
which uses json for messaging. I think this is a vital part of the spec 
and should remain.


On 8/30/18 05:09, Robert Stepanek wrote:
> I would like to discuss the status of JSTask and its readiness for acceptance:
>
> The JSCalendar specification defines object types for events, tasks and groups. The event and group objects have underwent years of discussion and there seems to be general consensus of their definition. However, the task object hasn't received that much attention. Much of the definition of JSTtask properties is based on a pending iCalendar VTODO RFC update: https://tools.ietf.org/html/draft-apthorp-ical-tasks-01
>
> With JSTask most likely becoming a standard before its updated iCalendar counterpart, I wonder if the current JSTask specification is all that stable? Is there the risk of  defining a snapshot of an ongoing discussion? If there is, we could split off JSTask from the JSCalendar specification. The current specification should it make easy to define additional object types in separate RFC documents.
>
> Looking forward to your feedback.
>
> Robert
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify


From nobody Thu Aug 30 07:01:54 2018
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 6D314130E11 for ; Thu, 30 Aug 2018 07:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhj9u08XBt8n for ; Thu, 30 Aug 2018 07:01:49 -0700 (PDT)
Received: from notes1.egenconsulting.com (static-host-108-174-96-49.epbinternet.com [108.174.96.49]) by ietfa.amsl.com (Postfix) with ESMTP id A3F01130DCF for ; Thu, 30 Aug 2018 07:01:49 -0700 (PDT)
Auto-Submitted: auto-generated
From: Pat R Egen 
To: calsify@ietf.org
Message-ID: 
Date: Thu, 30 Aug 2018 10:01:46 -0400
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 9.0.1FP7|August 17, 2016) at 08/30/2018 10:01:49 AM
MIME-Version: 1.0
Content-type: multipart/alternative;  Boundary="0__=0ABB086ADFDE966F8f9e8a93df938690918c0ABB086ADFDE966F"
Content-Disposition: inline
Archived-At: 
Subject: [calsify] AUTO: Pat R Egen is out of the office (returning 08/31/2018)
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Aug 2018 14:01:53 -0000

--0__=0ABB086ADFDE966F8f9e8a93df938690918c0ABB086ADFDE966F
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable



I am out of the office until 08/31/2018.

If you need help or have a question please contact
support@egenconsulting.com.


Note: This is an automated response to your message  "[SPAM]
[MessageScore][testmode] [calsify] I-D Action:
draft-ietf-calext-jscalendar-06.txt" sent on 8/30/2018 5:05:10 AM.

This is the only notification you will receive while this person is awa=
y.=

--0__=0ABB086ADFDE966F8f9e8a93df938690918c0ABB086ADFDE966F
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable



I am out of the office until 08=
/31/2018.



If you need help or have a =
question please contact support@egenconsulting.com.





Note: Thi=
s is an automated response to your message  "[SPAM] [MessageScore][testmode] [calsify=
] I-D Action: draft-ietf-calext-jscalendar-06.txt" sent on =
8/30/2018 5:05:10 AM=
. 



This is t=
he only notification you will receive while this person is away.=
=

--0__=0ABB086ADFDE966F8f9e8a93df938690918c0ABB086ADFDE966F--


From nobody Thu Aug 30 07:04:41 2018
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 5C448130E20 for ; Thu, 30 Aug 2018 07:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J69vwWVNnZCM for ; Thu, 30 Aug 2018 07:04:38 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9A7130DCF for ; Thu, 30 Aug 2018 07:04:38 -0700 (PDT)
Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 01CDC21F38 for ; Thu, 30 Aug 2018 10:04:37 -0400 (EDT)
Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 30 Aug 2018 10:04:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=pkGcrG Tzh3xH+T+Ciy78cyupi1xucv34furWGYAqnZg=; b=WG8I7oZSiLOLUL6qyGtor2 nkeH7gwpXK7x2hoJrFv8kkvRA6Gwy2M6SyPgE3aCpjlQOv4wkvZBTtrnynaEBq2x YVqlxu7rqhmhxnK3xQRJwbGv80a0MyUhhToaalebUK0U3Y3TDB49sMGr0/XNKKMv QtuT75575CAie3029Ia7bJU4hLiPz0YJXZ4x7dNgChbGPILcd1qVGFt4/O3m82l0 xLut/Q1mWOrJwe3mj5lavHjqJxXHDj5OlMTyxirB+EAXpDYROlyMCCna8YHkUhBc XmpAtPfVsI/rLHCiEXgHcaKpvjpJ4Dm6F8u9B0tJg7I4RusijdX3bH3oX8ZzUImQ ==
X-ME-Proxy:      
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4508CE229E; Thu, 30 Aug 2018 10:04:36 -0400 (EDT)
Message-Id: <1535637876.374476.1491356408.2B9BD317@webmail.messagingengine.com>
From: Robert Stepanek 
To: calsify@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-76c9aaa1
Date: Thu, 30 Aug 2018 16:04:36 +0200
References: <1535620158.162328.1491072080.2C47352D@webmail.messagingengine.com> <5eb08950-5d3a-ba80-7fdd-653f48ce5792@gmail.com>
In-Reply-To: <5eb08950-5d3a-ba80-7fdd-653f48ce5792@gmail.com>
Archived-At: 
Subject: Re: [calsify] JSCalendar: what to do with JSTask?
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Aug 2018 14:04:39 -0000

On Thu, Aug 30, 2018, at 15:48, Michael Douglass wrote:

> I'm currently in the process of developing an app which relies heavily 
> on tasks and the ease of translating from tasks to derived events and 
> which uses json for messaging. I think this is a vital part of the spec 
> and should remain.

I'm happy to hear that the proposed JSTask object is already useful in implementations. My concern is: is it ripe for standardization? It looks to me as if the discussion on a "better VTODO" is split on two draft documents, and it'd be sub-optimal if the two specifications come to different conclusions. I'm not involved in the discussions around VTODO, probably my concerns are unnecessary.

Cheers,
Robert


From nobody Thu Aug 30 20:16:15 2018
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 C573512DD85; Thu, 30 Aug 2018 20:16:13 -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.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: calsify@ietf.org
Message-ID: <153568537377.3324.16807132452273069111@ietfa.amsl.com>
Date: Thu, 30 Aug 2018 20:16:13 -0700
Archived-At: 
Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-09.txt
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Aug 2018 03:16:14 -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-09.txt
	Pages           : 32
	Date            : 2018-08-30

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-09
https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-09


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/