From nobody Thu Apr 2 16:06:34 2020 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 1FC263A1BCC; Thu, 2 Apr 2020 16:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 C7rfmWqaC2qX; Thu, 2 Apr 2020 16:06:30 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 B32033A1BCB; Thu, 2 Apr 2020 16:06:29 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id y3so1320442qky.8; Thu, 02 Apr 2020 16:06:29 -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-language; bh=k46/73+atseiRLEraSpZ9Tr/etPQniBHsaYm0Ma9WmE=; b=M+/H8wmkk/x5IK5wpl297qw0oQXnnr8Pbl2kM+Og0T4X427S5btC8mSZ54sytJnxp1 XzLBW9Tw7YFsW7QqLCdeW2y/aZHZjEHaOm+43Fjyih/j4Ox5NzQazXmW3bUJMg4Y6aRA nFRw5swwB/d3SFIstoXKxVgi0ZZVj0QADKQ+pFqIxPzri8fjAs/L8c5Ye/gbv7rILpVR hmpRd3ST3L4SfLZBBjjlfcpUecbJ57eYlYrPfPBfmPiS7OZd2zjvPnATjKKllmfxIviA m7y+4s6ufPsLknmPMcVzA1KC2+zQVJbG8u1YtKTR3JZcnpScjAqL12z2krvYBbHd1aqa qSRQ== 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-language; bh=k46/73+atseiRLEraSpZ9Tr/etPQniBHsaYm0Ma9WmE=; b=sGkZ0iXJgy7WJCYXnw3Vjw/OyfGyPxJPQPLdeDS2VTwDWm8zhPh7pOr/VCzFTffgWO k8/TGkq6YX2pFghbnGeI1balOSf7lnkerQMukfYdse2FPjbltDBH8oZXnAj4ohvC1noQ hyOTJrR9IoDEFeDeAM4NtIHj6Ue+zGawM6jbIE7Ll+iJpjfaYVTIqsM9KOu+95RG+d3F ONA36c1qf5L8vZ9ZDbnD8skU76M3yMvmnECz8F17Iw8+a89BM7TnB44SM2/DJHik06Yo Nj6o25+1S7n0cU5P8MUnmq9oN/zCQCO2mJJ+INjE7sTnRfaEBAMpes/91f00p9VAek9K sOZw== X-Gm-Message-State: AGi0PuaLoZA3DltpravYUtZVoAe/lmw2tdNp7SCvrbS6XCO/S/jlDM72 0EUUkth6Yrm3xhsYVTAHJlcuFpPx4X4= X-Google-Smtp-Source: APiQypI4poyHEUKqicS+nMoVuWUXX6+zsDmxUL67K3LocNqZM8JzypJYfUeEW8nCzsen1cCLLIl28g== X-Received: by 2002:a37:a057:: with SMTP id j84mr6128569qke.108.1585868788443; Thu, 02 Apr 2020 16:06:28 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id x6sm4610656qke.43.2020.04.02.16.06.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Apr 2020 16:06:27 -0700 (PDT) To: calsify@ietf.org, internet-drafts@ietf.org, i-d-announce@ietf.org References: <158363619759.25642.15164071767646081255@ietfa.amsl.com> From: Michael Douglass Message-ID: Date: Thu, 2 Apr 2020 19:06:27 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <158363619759.25642.15164071767646081255@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------11B1D8E9661E7A2AC2B182D6" Content-Language: en-US Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 23:06:32 -0000 This is a multi-part message in MIME format. --------------11B1D8E9661E7A2AC2B182D6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I have to apologize for the lateness of these issues I want to raise but I've started implementing the mapping of icalendar to JSCalendar and I'm already running into some problems. I've only looked at a few properties so far. In general - while I initially thought an informational spec would be fine for describing the mappings - I'm now of the opinion it has to be mandated where possible. Otherwise we're going to have a whole mess of incompatible implementations. Privacy <-> CLASS The first was the use of "secret" instead of "confidential" for the privacy property. The result is that a simple conversion to lowercase for jscalendar isn't sufficient. I know neither authors want to change at this late stage but I mention it (again) because this will be a perpetual annoyance. link <->ATTACH, IMAGE, URL ATTACH and IMAGE seem fine (reltype of enclosure and icon resp.) but URL doesn't. The description of rel has this: Links with a rel of "describedby" SHOULD be considered by the client to be an alternative representation of the description. Is that supposed to be the same as URL - it doesn't match the description for URL in 5545? I think the spec needs to explicitly state that URL MUST be represented by a link with a given rel - I'd suggest "alternate" because that seems closer to what is intended in 5545. comments <-> COMMENT comments is only specified for timezone rules. It needs to be valid for all or some indication of how to handle them needs to be provided. There is an issue in 5545 with COMMENT in scheduling e.g. is a comment meant only for the organizer? That could be tightened up. GEO, PERCENT-COMPLETE What are we supposed to do with these? updated <-> DTSTAMP, LAST-MODIFIED I don't understand why 5545 has 2 values - however I think we need a better statement of how to map 2 values on to 1 - something about the later of the 2? More to follow... On 3/7/20 21:56, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Calendaring Extensions WG of the IETF. > > Title : JSCalendar: A JSON representation of calendar data > Authors : Neil Jenkins > Robert Stepanek > Filename : draft-ietf-calext-jscalendar-26.txt > Pages : 77 > Date : 2020-03-07 > > 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 > and, over time, successor to the widely deployed iCalendar data > format, and to be unambiguous, extendable, and simple to process. In > contrast to the jCal format, which is also JSON-based, JSCalendar is > not a direct mapping from iCalendar, but defines the data model > independently and expands semantics where appropriate. > > > 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-26 > https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-26 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-26 > > > 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 --------------11B1D8E9661E7A2AC2B182D6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I have to apologize for the lateness of these issues I want to raise but I've started implementing the mapping of icalendar to JSCalendar and I'm already running into some problems.

I've only looked at a few properties so far.

In general - while I initially thought an informational spec would be fine for describing the mappings - I'm now of the opinion it has to be mandated where possible. Otherwise we're going to have a whole mess of incompatible implementations.

Privacy <-> CLASS

The first was the use of "secret" instead of "confidential" for the privacy property. The result is that a simple conversion to lowercase for jscalendar isn't sufficient. I know neither authors want to change at this late stage but I mention it (again) because this will be a perpetual annoyance.

link <->ATTACH, IMAGE, URL

ATTACH and IMAGE seem fine (reltype of enclosure and icon resp.) but URL doesn't.

The description of rel has this:

  Links with a rel of "describedby" SHOULD be considered by the
      client to be an alternative representation of the description.

Is that supposed to be the same as URL - it doesn't match the description for URL in 5545?

I think the spec needs to explicitly state that URL MUST be represented by a link with a given rel - I'd suggest "alternate" because that seems closer to what is intended in 5545.


comments <-> COMMENT

comments is only specified for timezone rules. It needs to be valid for all or some indication of how to handle them needs to be provided.

There is an issue in 5545 with COMMENT in scheduling e.g. is a comment meant only for the organizer? That could be tightened up.

GEO, PERCENT-COMPLETE

What are we supposed to do with these?

updated <-> DTSTAMP, LAST-MODIFIED

I don't understand why 5545 has 2 values - however I think we need a better statement of how to map 2 values on to 1 - something about the later of the 2?

More to follow...


On 3/7/20 21:56, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring Extensions WG of the IETF.

        Title           : JSCalendar: A JSON representation of calendar data
        Authors         : Neil Jenkins
                          Robert Stepanek
	Filename        : draft-ietf-calext-jscalendar-26.txt
	Pages           : 77
	Date            : 2020-03-07

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
   and, over time, successor to the widely deployed iCalendar data
   format, and to be unambiguous, extendable, and simple to process.  In
   contrast to the jCal format, which is also JSON-based, JSCalendar is
   not a direct mapping from iCalendar, but defines the data model
   independently and expands semantics where appropriate.


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-26
https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-26

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


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
--------------11B1D8E9661E7A2AC2B182D6-- From nobody Fri Apr 3 14:29:30 2020 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 2769C3A0BAE for ; Fri, 3 Apr 2020 14:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 YLCX6jq37V3F for ; Fri, 3 Apr 2020 14:29:25 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0: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 B36643A0BB6 for ; Fri, 3 Apr 2020 14:29:25 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id x16so8780387ilp.12 for ; Fri, 03 Apr 2020 14:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=qY38PFZ0ze3t/ar0ZcJF3iIOtFogSZSbEcHzzDBhPLs=; b=Y8vRKZDmFyiI44PrcQZHN51O46epQsQW6vIgqJpGBvElE1AdNK31qrkACjVVBLBfwS 9Iy2B3s9ot8Vb7VoFKHt4MTzAqIESx8svE97FSROhZ/1ESMDnzvheXOoP81PxRFxvJIe CCQHKk3KNcOe8LcPqT3hfjeyqe4YwQ6USbB4eKCmcorRyr/yJBmALCq6RZ3y+GcCI8C2 IycRVyoQBBpycb8ssPjCVr46GC91+bhQYduMwtXO/RB11E1xIkp41NFoozQYyuhT3975 GHzmiynPuIOgelPPFldtpHqez3/rfz9C9WQ0DceuDlIMO9d+/XeD6SgLzwtUJWkzQtzg zrsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=qY38PFZ0ze3t/ar0ZcJF3iIOtFogSZSbEcHzzDBhPLs=; b=lix25u5/Q1eXZGj7PY0ol7Myi8O0s6kL1A7AIwssF5L3MB17h4tTKmwOD0Xnn6aOUy 4PWOdjHS/Cytw6giVHwoXmrIPXvG6xzTLFbFjw1sJJM8S+E9RHQr/Gfs/eO3DDtihu22 ySaJ4Be3NrPdGXRKqLUkcJD25sPdmu9F3/pg50VoM2Qd8UYEjR6q4JG7y/duZyOiyJLA TfWyc3FOzj0G2x8sDwB71zJq8X3IiqKO+dA25bj7VSrNXDjmwN1mLB23Lkyh6KN6vQuY mbQ/A7AB8WsJElyhjr/M6CS5dRgj5vzh32RDk3u9PBAScxklr5awHz9gURbuWCPNtOK8 wLhg== X-Gm-Message-State: AGi0PuarGfQzXXmLJ87FaJa463Ah1UWtpao5/oR8ZU86HMXbTBCNsKq6 6h/aUTy18pz2CbcdPmdtz3mf666rDdk= X-Google-Smtp-Source: APiQypIE5Xiz5x50/sN6fJXlklJrf7f33c8O8TxrrVNxQsyAG4QDVCJY4mby2eeZzSzvlGmbODVBrA== X-Received: by 2002:a92:5c5c:: with SMTP id q89mr10846867ilb.195.1585949364466; Fri, 03 Apr 2020 14:29:24 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id i16sm3165075ils.40.2020.04.03.14.29.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Apr 2020 14:29:24 -0700 (PDT) From: Michael Douglass To: calsify@ietf.org References: <158363619759.25642.15164071767646081255@ietfa.amsl.com> Message-ID: <89e9d6f2-9632-6c17-adfc-0a1977f15fcc@gmail.com> Date: Fri, 3 Apr 2020 17:29:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EEBFA8577899351A2AAE78BB" Content-Language: en-US Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 21:29:28 -0000 This is a multi-part message in MIME format. --------------EEBFA8577899351A2AAE78BB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Further comments below On 4/2/20 19:06, Michael Douglass wrote: > > I have to apologize for the lateness of these issues I want to raise > but I've started implementing the mapping of icalendar to JSCalendar > and I'm already running into some problems. > > I've only looked at a few properties so far. > > In general - while I initially thought an informational spec would be > fine for describing the mappings - I'm now of the opinion it has to be > mandated where possible. Otherwise we're going to have a whole mess of > incompatible implementations. > > Privacy <-> CLASS > > The first was the use of "secret" instead of "confidential" for the > privacy property. The result is that a simple conversion to lowercase > for jscalendar isn't sufficient. I know neither authors want to change > at this late stage but I mention it (again) because this will be a > perpetual annoyance. > > link <->ATTACH, IMAGE, URL > > ATTACH and IMAGE seem fine (reltype of enclosure and icon resp.) but > URL doesn't. > > The description of rel has this: > > Links with a rel of "describedby" SHOULD be considered by the > client to be an alternative representation of the description. > > Is that supposed to be the same as URL - it doesn't match the > description for URL in 5545? > > I think the spec needs to explicitly state that URL MUST be > represented by a link with a given rel - I'd suggest "alternate" > because that seems closer to what is intended in 5545. > > > comments <-> COMMENT > > comments is only specified for timezone rules. It needs to be valid > for all or some indication of how to handle them needs to be provided. > > There is an issue in 5545 with COMMENT in scheduling e.g. is a comment > meant only for the organizer? That could be tightened up. > CONTACT There's no mapping suggested. CONTACT is vital for event publication. I'd suggest following the approach in eventpub - add a participantType property to participant participantTypes: "String[Boolean]" (mandatory) Defines the type of participation in events or tasks. Participants can be individuals or organizations, for example attendees, a soccer team, the spectators, or the musicians. At least one type MUST be specified for the participant. The keys in the set MUST be one of the following values, a value registered in the IANA JSCalendar Enum Registry, or a vendor-specific value: * "attendee": A participant attending a meeting. * "active": A participant taking an active role - for example a team member. * "inactive": A participant taking an inactive part - for example an audience member. * "sponsor": A sponsor of the event. The order property may be used with this participant type to define the relative order of multiple sponsors. * "contact": Contact information for the event. The order property may be used with this participant type to define the relative order of multiple contacts. * "booking-contact": Contact information for reservations or payment * "emergency-contact": Contact in case of emergency * "publicity-contact": Contact for publicity * "planner-contact: Contact for the event planner or organizer * "performer": A performer - for example the soloist or the accompanist. The order property may be used with this participant type to define the relative order of multiple performers. For example, "order": 1 could define the principal performer or soloist. * "speaker": Speaker at an event Change the participant description: ... If this property is set with a participant type of "attendee", then the "replyTo" property of this calendar object MUST define at least one reply method. ... o roles: "String[Boolean]" (mandatory for participantType = "attendee") > GEO, PERCENT-COMPLETE > > What are we supposed to do with these? > > updated <-> DTSTAMP, LAST-MODIFIED > > I don't understand why 5545 has 2 values - however I think we need a > better statement of how to map 2 values on to 1 - something about the > later of the 2? > > More to follow... > > > On 3/7/20 21:56, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Calendaring Extensions WG of the IETF. >> >> Title : JSCalendar: A JSON representation of calendar data >> Authors : Neil Jenkins >> Robert Stepanek >> Filename : draft-ietf-calext-jscalendar-26.txt >> Pages : 77 >> Date : 2020-03-07 >> >> 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 >> and, over time, successor to the widely deployed iCalendar data >> format, and to be unambiguous, extendable, and simple to process. In >> contrast to the jCal format, which is also JSON-based, JSCalendar is >> not a direct mapping from iCalendar, but defines the data model >> independently and expands semantics where appropriate. >> >> >> 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-26 >> https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-26 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-26 >> >> >> 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 --------------EEBFA8577899351A2AAE78BB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Further comments below

On 4/2/20 19:06, Michael Douglass wrote:

I have to apologize for the lateness of these issues I want to raise but I've started implementing the mapping of icalendar to JSCalendar and I'm already running into some problems.

I've only looked at a few properties so far.

In general - while I initially thought an informational spec would be fine for describing the mappings - I'm now of the opinion it has to be mandated where possible. Otherwise we're going to have a whole mess of incompatible implementations.

Privacy <-> CLASS

The first was the use of "secret" instead of "confidential" for the privacy property. The result is that a simple conversion to lowercase for jscalendar isn't sufficient. I know neither authors want to change at this late stage but I mention it (again) because this will be a perpetual annoyance.

link <->ATTACH, IMAGE, URL

ATTACH and IMAGE seem fine (reltype of enclosure and icon resp.) but URL doesn't.

The description of rel has this:

  Links with a rel of "describedby" SHOULD be considered by the
      client to be an alternative representation of the description.

Is that supposed to be the same as URL - it doesn't match the description for URL in 5545?

I think the spec needs to explicitly state that URL MUST be represented by a link with a given rel - I'd suggest "alternate" because that seems closer to what is intended in 5545.


comments <-> COMMENT

comments is only specified for timezone rules. It needs to be valid for all or some indication of how to handle them needs to be provided.

There is an issue in 5545 with COMMENT in scheduling e.g. is a comment meant only for the organizer? That could be tightened up.

CONTACT

There's no mapping suggested. CONTACT is vital for event publication. I'd suggest following the approach in eventpub - add a participantType property to participant

participantTypes: "String[Boolean]" (mandatory)

Defines the type of participation in
events or tasks.  Participants can be individuals or
organizations, for example attendees, a soccer team, the spectators, or the
musicians.
      At least one type MUST be specified for the participant.  The keys
      in the set MUST be one of the following values, a value registered
      in the IANA JSCalendar Enum Registry, or a vendor-specific value:

      *  "attendee": A participant attending a meeting.

      *  "active": A participant taking an active role - for example a team
         member.

      * "inactive":  A participant taking an inactive part - for example an
      audience member.

      * "sponsor":  A sponsor of the event.  The order property may be used
        with this participant type to define the relative order of
        multiple sponsors.

      * "contact":  Contact information for the event.  The order property may
        be used with this participant type to define the relative order of
        multiple contacts.


      * "booking-contact":  Contact information for reservations or payment

      * "emergency-contact":  Contact in case of emergency

      * "publicity-contact":  Contact for publicity

      * "planner-contact:  Contact for the event planner or organizer

      * "performer":  A performer - for example the soloist or the accompanist.
      The order property may be used with this participant type to
      define the relative order of multiple performers.  For example,
      "order": 1 could define the principal performer or soloist.

      * "speaker":  Speaker at an event

Change the participant description:
...
   If this property is set with a participant type of "attendee", then the "replyTo" property of this calendar
   object MUST define at least one reply method.
...
   o  roles: "String[Boolean]" (mandatory for participantType = "attendee")
 

GEO, PERCENT-COMPLETE

What are we supposed to do with these?

updated <-> DTSTAMP, LAST-MODIFIED

I don't understand why 5545 has 2 values - however I think we need a better statement of how to map 2 values on to 1 - something about the later of the 2?

More to follow...


On 3/7/20 21:56, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring Extensions WG of the IETF.

        Title           : JSCalendar: A JSON representation of calendar data
        Authors         : Neil Jenkins
                          Robert Stepanek
	Filename        : draft-ietf-calext-jscalendar-26.txt
	Pages           : 77
	Date            : 2020-03-07

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
   and, over time, successor to the widely deployed iCalendar data
   format, and to be unambiguous, extendable, and simple to process.  In
   contrast to the jCal format, which is also JSON-based, JSCalendar is
   not a direct mapping from iCalendar, but defines the data model
   independently and expands semantics where appropriate.


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-26
https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-26

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


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
--------------EEBFA8577899351A2AAE78BB-- From nobody Fri Apr 3 15:55:09 2020 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 91CE33A0DB9 for ; Fri, 3 Apr 2020 15:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 xah3yjz-sW7b for ; Fri, 3 Apr 2020 15:55:03 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 6DE443A0DB4 for ; Fri, 3 Apr 2020 15:55:03 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id n1so4490199qvz.4 for ; Fri, 03 Apr 2020 15:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=P592uH0fQh7QUy/W+y2cqOuTL46/BUe63ArlLpJnL3I=; b=V95z1k0VpGIDaqDEGfreELIWtTosZICqry1UNOZ3w35enKBcXGUzE2aaUTe3Zqkbyj VjeNBgkgTZttpJdd1CpF03wriErdSRVZQ1w+jIFtn6vkj0JHOtZh72S1ZP2FjToCEVOz JpA3bt62QCP2c6/M1mUlX6j+92Zu4doBULJPGeTl2avTcqsv7U6oF/OoAErN7PX0SZg2 U9Xa47bSS7r0jH0de79SlA5PcOrR/UNGKfkHEbleIxuFA6CdCpMZKQQYaJn9+tamM8gK QG0lhM05HZBeLtBjtWlOM2vuOjgfOs9FL/k0IuzemyjOqSelbWMoRckO8aWyt/OjtKSx ZAnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=P592uH0fQh7QUy/W+y2cqOuTL46/BUe63ArlLpJnL3I=; b=X4LK+k3du86mygplmfBTUuO2YtMT8JNAkhU0/8Oy2EcIZ7elZmVZcspim78fKFQt/z qKMDBIyg887voblJWe96nVSTzHA+9AVJyCp6SRGq+exTJX/bbigfZtwPCwoNWOnvHXlk Nb078WX8N4cgv4Ag0ynR0OAtROWWyuQCat6/5HLGs1MTFjFRFUHrdEHNwPpbbsqI6Mjd 6Ppam+tYs+vmAzBcvyYe9YPWImO77P4viNEMkdpT3GV+CXK3fbWRuS5h/Xu7fUJ2CZev UVNY0fNOcb1nCbPBZryD8fe5rTx3dALzf9M9JaGw4Gsjqu13QBJ13woYKVyFH3t2erzl vBRA== X-Gm-Message-State: AGi0PubOHcLIyzNS2KPMsIDdegoTA/zGBr229LeG54oDHSOCPBmTHx2U krwQ8ooK91W3AfiKfr1TQSjm8IaJWDg= X-Google-Smtp-Source: APiQypLDCGL69PooSkXGhKtZIFYdGC0S18qsW6Ck4pc+M7pG15y6Tkuy14Esl4WCMo9fIIgOdyEkrw== X-Received: by 2002:a05:6214:801:: with SMTP id df1mr10775504qvb.73.1585954502154; Fri, 03 Apr 2020 15:55:02 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id n124sm714629qke.104.2020.04.03.15.55.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Apr 2020 15:55:01 -0700 (PDT) From: Michael Douglass To: calsify@ietf.org References: <158363619759.25642.15164071767646081255@ietfa.amsl.com> <89e9d6f2-9632-6c17-adfc-0a1977f15fcc@gmail.com> Message-ID: <5db6d2e1-8512-5f32-94d0-6f7057481a3d@gmail.com> Date: Fri, 3 Apr 2020 18:55:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <89e9d6f2-9632-6c17-adfc-0a1977f15fcc@gmail.com> Content-Type: multipart/alternative; boundary="------------A205ADD10AF68BE5BE092969" Content-Language: en-US Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 22:55:07 -0000 This is a multi-part message in MIME format. --------------A205ADD10AF68BE5BE092969 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 4/3/20 17:29, Michael Douglass wrote: > > Further comments below > > On 4/2/20 19:06, Michael Douglass wrote: >> >> I have to apologize for the lateness of these issues I want to raise >> but I've started implementing the mapping of icalendar to JSCalendar >> and I'm already running into some problems. >> >> I've only looked at a few properties so far. >> >> In general - while I initially thought an informational spec would be >> fine for describing the mappings - I'm now of the opinion it has to >> be mandated where possible. Otherwise we're going to have a whole >> mess of incompatible implementations. >> >> Privacy <-> CLASS >> >> The first was the use of "secret" instead of "confidential" for the >> privacy property. The result is that a simple conversion to lowercase >> for jscalendar isn't sufficient. I know neither authors want to >> change at this late stage but I mention it (again) because this will >> be a perpetual annoyance. >> >> link <->ATTACH, IMAGE, URL >> >> ATTACH and IMAGE seem fine (reltype of enclosure and icon resp.) but >> URL doesn't. >> >> The description of rel has this: >> >> Links with a rel of "describedby" SHOULD be considered by the >> client to be an alternative representation of the description. >> >> Is that supposed to be the same as URL - it doesn't match the >> description for URL in 5545? >> >> I think the spec needs to explicitly state that URL MUST be >> represented by a link with a given rel - I'd suggest "alternate" >> because that seems closer to what is intended in 5545. >> >> >> comments <-> COMMENT >> >> comments is only specified for timezone rules. It needs to be valid >> for all or some indication of how to handle them needs to be provided. >> >> There is an issue in 5545 with COMMENT in scheduling e.g. is a >> comment meant only for the organizer? That could be tightened up. >> > CONTACT > > There's no mapping suggested. CONTACT is vital for event publication. > I'd suggest following the approach in eventpub - add a participantType > property to participant > Having looked again I thought this could probably be handled just by changing the wording for participant as I suggested and extending the roles values. However I think that's conceptually more complicated, "participantTypes": {"attendee": true} "roles": {"optional": true} is easier to understand than "participantTypes": {"optional": true} implying this is an optional attendee. Changing role "attendee" to "required" or "expected" might make sense > participantTypes: "String[Boolean]" (mandatory) > > Defines the type of participation in > events or tasks. Participants can be individuals or > organizations, for example attendees, a soccer team, the spectators, or the > musicians. > At least one type MUST be specified for the participant. The keys > in the set MUST be one of the following values, a value registered > in the IANA JSCalendar Enum Registry, or a vendor-specific value: > > * "attendee": A participant attending a meeting. > > * "active": A participant taking an active role - for example a team > member. > > * "inactive": A participant taking an inactive part - for example an > audience member. > > * "sponsor": A sponsor of the event. The order property may be used > with this participant type to define the relative order of > multiple sponsors. > > * "contact": Contact information for the event. The order property may > be used with this participant type to define the relative order of > multiple contacts. > > > * "booking-contact": Contact information for reservations or payment > > * "emergency-contact": Contact in case of emergency > > * "publicity-contact": Contact for publicity > > * "planner-contact: Contact for the event planner or organizer > > * "performer": A performer - for example the soloist or the accompanist. > The order property may be used with this participant type to > define the relative order of multiple performers. For example, > "order": 1 could define the principal performer or soloist. > > * "speaker": Speaker at an event > > Change the participant description: > ... > If this property is set with a participant type of "attendee", then the "replyTo" property of this calendar > object MUST define at least one reply method. > ... > o roles: "String[Boolean]" (mandatory for participantType = "attendee") I've got another question on mapping: In your mapping draft you say: An iCalendar ORGANIZER maps to both the replyTo property and a participant with role "owner". If an ATTENDEE with the same CAL- ADDRESS value exists, then it maps to the same participant as the ORGANIZER participant. What if the attendee and organizer have different SENT-BY parameters? And what is SENT-BY mapped to? I think the 2 ought to be kept separate. > >> >> GEO, PERCENT-COMPLETE >> >> What are we supposed to do with these? >> >> updated <-> DTSTAMP, LAST-MODIFIED >> >> I don't understand why 5545 has 2 values - however I think we need a >> better statement of how to map 2 values on to 1 - something about the >> later of the 2? >> >> More to follow... >> >> >> On 3/7/20 21:56, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Calendaring Extensions WG of the IETF. >>> >>> Title : JSCalendar: A JSON representation of calendar data >>> Authors : Neil Jenkins >>> Robert Stepanek >>> Filename : draft-ietf-calext-jscalendar-26.txt >>> Pages : 77 >>> Date : 2020-03-07 >>> >>> 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 >>> and, over time, successor to the widely deployed iCalendar data >>> format, and to be unambiguous, extendable, and simple to process. In >>> contrast to the jCal format, which is also JSON-based, JSCalendar is >>> not a direct mapping from iCalendar, but defines the data model >>> independently and expands semantics where appropriate. >>> >>> >>> 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-26 >>> https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-26 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-26 >>> >>> >>> 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 --------------A205ADD10AF68BE5BE092969 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 4/3/20 17:29, Michael Douglass wrote:

Further comments below

On 4/2/20 19:06, Michael Douglass wrote:

I have to apologize for the lateness of these issues I want to raise but I've started implementing the mapping of icalendar to JSCalendar and I'm already running into some problems.

I've only looked at a few properties so far.

In general - while I initially thought an informational spec would be fine for describing the mappings - I'm now of the opinion it has to be mandated where possible. Otherwise we're going to have a whole mess of incompatible implementations.

Privacy <-> CLASS

The first was the use of "secret" instead of "confidential" for the privacy property. The result is that a simple conversion to lowercase for jscalendar isn't sufficient. I know neither authors want to change at this late stage but I mention it (again) because this will be a perpetual annoyance.

link <->ATTACH, IMAGE, URL

ATTACH and IMAGE seem fine (reltype of enclosure and icon resp.) but URL doesn't.

The description of rel has this:

  Links with a rel of "describedby" SHOULD be considered by the
      client to be an alternative representation of the description.

Is that supposed to be the same as URL - it doesn't match the description for URL in 5545?

I think the spec needs to explicitly state that URL MUST be represented by a link with a given rel - I'd suggest "alternate" because that seems closer to what is intended in 5545.


comments <-> COMMENT

comments is only specified for timezone rules. It needs to be valid for all or some indication of how to handle them needs to be provided.

There is an issue in 5545 with COMMENT in scheduling e.g. is a comment meant only for the organizer? That could be tightened up.

CONTACT

There's no mapping suggested. CONTACT is vital for event publication. I'd suggest following the approach in eventpub - add a participantType property to participant

Having looked again I thought this could probably be handled just by changing the wording for participant as I suggested and extending the roles values. However I think that's conceptually more complicated,

"participantTypes": {"attendee": true}

"roles": {"optional": true}

is easier to understand than

"participantTypes": {"optional": true}

implying this is an optional attendee.

Changing role "attendee" to "required" or "expected" might make sense

participantTypes: "String[Boolean]" (mandatory)

Defines the type of participation in
events or tasks.  Participants can be individuals or
organizations, for example attendees, a soccer team, the spectators, or the
musicians.
      At least one type MUST be specified for the participant.  The keys
      in the set MUST be one of the following values, a value registered
      in the IANA JSCalendar Enum Registry, or a vendor-specific value:

      *  "attendee": A participant attending a meeting.

      *  "active": A participant taking an active role - for example a team
         member.

      * "inactive":  A participant taking an inactive part - for example an
      audience member.

      * "sponsor":  A sponsor of the event.  The order property may be used
        with this participant type to define the relative order of
        multiple sponsors.

      * "contact":  Contact information for the event.  The order property may
        be used with this participant type to define the relative order of
        multiple contacts.


      * "booking-contact":  Contact information for reservations or payment

      * "emergency-contact":  Contact in case of emergency

      * "publicity-contact":  Contact for publicity

      * "planner-contact:  Contact for the event planner or organizer

      * "performer":  A performer - for example the soloist or the accompanist.
      The order property may be used with this participant type to
      define the relative order of multiple performers.  For example,
      "order": 1 could define the principal performer or soloist.

      * "speaker":  Speaker at an event

Change the participant description:
...
   If this property is set with a participant type of "attendee", then the "replyTo" property of this calendar
   object MUST define at least one reply method.
...
   o  roles: "String[Boolean]" (mandatory for participantType = "attendee")


I've got another question on mapping:

In your mapping draft you say:

An iCalendar ORGANIZER maps to both the replyTo property and a
   participant with role "owner".  If an ATTENDEE with the same CAL-
   ADDRESS value exists, then it maps to the same participant as the
   ORGANIZER participant.

What if the attendee and organizer have different SENT-BY parameters? And what is SENT-BY mapped to?

I think the 2 ought to be kept separate.

 

GEO, PERCENT-COMPLETE

What are we supposed to do with these?

updated <-> DTSTAMP, LAST-MODIFIED

I don't understand why 5545 has 2 values - however I think we need a better statement of how to map 2 values on to 1 - something about the later of the 2?

More to follow...


On 3/7/20 21:56, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring Extensions WG of the IETF.

        Title           : JSCalendar: A JSON representation of calendar data
        Authors         : Neil Jenkins
                          Robert Stepanek
	Filename        : draft-ietf-calext-jscalendar-26.txt
	Pages           : 77
	Date            : 2020-03-07

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
   and, over time, successor to the widely deployed iCalendar data
   format, and to be unambiguous, extendable, and simple to process.  In
   contrast to the jCal format, which is also JSON-based, JSCalendar is
   not a direct mapping from iCalendar, but defines the data model
   independently and expands semantics where appropriate.


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-26
https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-26

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


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
--------------A205ADD10AF68BE5BE092969-- From nobody Fri Apr 3 16:26:21 2020 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 478AF3A0ED7 for ; Fri, 3 Apr 2020 16:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=RjM09W9Z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rVZR+SuM 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 P598sZvKpm08 for ; Fri, 3 Apr 2020 16:26:16 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C121B3A0ED5 for ; Fri, 3 Apr 2020 16:26:16 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id D4F046EB; Fri, 3 Apr 2020 19:26:15 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Fri, 03 Apr 2020 19:26:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=7HT7fUF w+YDdhdeR2zn+zm0QveZpmk3uoA3G2acHFJ8=; b=RjM09W9ZASS6AAfZBpw+6ld kJlWAhDBOO/REI140q/k2I/nGheSqvJIaW++GqRJz3bjnU2OTEghf9nj5BxdKqvw +41Bc6L50L+sL8LSnrasLEg+SwMgelK/zzCpYAbvyEy8jVHDvIdUn8gkZTkA4Zfb CriuHnFY4YN76inlwwXIoRWxFWCgsverv0XePpagwFrqKyZjKQFxS3eyws8iEj0q fQxLawJzEK5CIfrPgwAflFmAW47Uwpb5bILjjcWhwbWj2xK4u2VJcLZBXlZN5FB1 +brTmGGLBWFYAc4kYKOc1S4avvdXJv23G8Vcr6IERz15rtdpdSxYRm4gxEtpD5w= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=7HT7fU Fw+YDdhdeR2zn+zm0QveZpmk3uoA3G2acHFJ8=; b=rVZR+SuMmwbw1p8ZgWZEuj LeSc2oQc/59f83/Fee6MGyN7ySmb8xl8VWec/Rgro1jIRwWWRHCKwfX0XVoUZvJX rpdz8dNO7PBmRPXhzRfXy6+X2uzkcSkVuUWPVL0zypjR0IPE02W9l11G007ii/XF ECxsLCkH6u5CPGSMWFQYBmHbZ9T4XUW+DdmcgUmCP2jueiQLOqw6gYKc9L4ZhPnT 6hnHzfk4BZ3/cLQ7WSmaBZ4IaUvVU2vOmzsA9DB5SC5kFy/y+0mQtaRyAY3SodDj V/C3tPKusH6NPEfOLj18ZjwoqSYDEreqyLaIAHm/CfM41bJrMJtfV85L0+CjiGZg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtdejgddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhg sehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 02FCD180090; Fri, 3 Apr 2020 19:26:15 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1082-g13d7805-fmstable-20200403v1 Mime-Version: 1.0 Message-Id: <7c364eb4-ad8a-4bbf-85c4-d859d7e23b20@dogfood.fastmail.com> In-Reply-To: References: Date: Sat, 04 Apr 2020 10:25:53 +1100 From: "Bron Gondwana" To: calsify@ietf.org, calconnect-l@lists.calconnect.org Content-Type: multipart/alternative; boundary=26f5128960974e499f5f470bae4f05c1 Archived-At: Subject: Re: [calsify] =?utf-8?q?Planning_for_an_interim_meeting_co-located_w?= =?utf-8?q?ith_CalConnect_in_April?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 23:26:20 -0000 --26f5128960974e499f5f470bae4f05c1 Content-Type: text/plain Should we still hold this meeting? Maybe. If so, I'd like to move it a little earlier though, since 4pm London is 1am Melbourne! If we go a couple of hours earlier to 2pm London, we bring it back to 11pm Melbourne and 9am New York - it's still early for US West Coast, but I think that's the best compromise for the timezones where our people are. Cheers, Bron. On Fri, Jan 17, 2020, at 09:39, Bron Gondwana wrote: > Hi All, > > CalConnect's next meeting is in Nottingham UK from April 20-24. > > I expect we will hold the meeting at the end of the day UK time in order to make as much as possible of Europe and the USA available to attend (sorry Australia!) > > Right now we have wide flexibility on the timing - does anyone who is likely to attend have any specific days that will not work so we can avoid those days. Please let me know. > > Thanks, > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --26f5128960974e499f5f470bae4f05c1 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Should we still hold this meeting?  Maybe. = If so, I'd like to move it a little earlier though, since 4pm London is= 1am Melbourne!  If we go a couple of hours earlier to 2pm London, = we bring it back to 11pm Melbourne and 9am New York - it's still early f= or US West Coast, but I think that's the best compromise for the timezon= es where our people are.

=
Cheers,

Bron.
=

On Fri, Jan 17, 2= 020, at 09:39, Bron Gondwana wrote:
Hi All,

CalConn= ect's next meeting is in Nottingham UK from April 20-24.

= I expect we will hold the meeting at the end of the day UK time in order= to make as much as possible of Europe and the USA available to attend (= sorry Australia!)

<= div style=3D"font-family:Arial;">Right now we have wide flexibility on t= he timing - does anyone who is likely to attend have any specific days t= hat will not work so we can avoid those days.  Please let me know.<= br>

Thanks,

Bron= .

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


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


<= div>--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--26f5128960974e499f5f470bae4f05c1-- From nobody Fri Apr 3 17:41:24 2020 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 863AC3A05A7 for ; Fri, 3 Apr 2020 17:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 Sh7w4w60NFCx for ; Fri, 3 Apr 2020 17:41:22 -0700 (PDT) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 CDC883A05A6 for ; Fri, 3 Apr 2020 17:41:21 -0700 (PDT) Received: by mail-vk1-xa36.google.com with SMTP id s194so2491977vkb.11 for ; Fri, 03 Apr 2020 17:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LqfixqzdXIJjpg9BcESx9XKxUwXA0oULp+H18wqc/vg=; b=ESR6MgwpB9cWMgm+vxnH0ZAMNpN+0jIH5SsyqP3nGXUQNU8LIfhAI10y49RqdaTbhN V48a4UJRUdog/v8vYSVmij2NulbfQwKX7agb4QEQD5O9uEqqj11nnrZzpGhz6pwpw4kS ROyfye3Xe1B0XTuZYehu1Mm2RFisW6WLWGiDBFm5Sxwrw9han9Xi1jMLMH52CKYq8DgW 7ZsSnTeeNxQf13GPViJf0sRIRDXPu+Y70QQliDMu7S9oF5o/Q+ymIQui/64nx/ZaTj9N CXZ5iPegPIlq6pSNBtkd1gJ7gmPXNGHZX5bOXiHVlfpOpDU0LDJ8B6yuJ/cB4VDSl95X bWDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LqfixqzdXIJjpg9BcESx9XKxUwXA0oULp+H18wqc/vg=; b=mkveMfUzx2fNfM1pb3AorAfXYoXHAZ0M0jhwSe45N+heXUTaASA95O70ME2aHgwpa4 sQ5J/AHVOULmnFOa055NFYFIEwhIJjpuRZEGw5JErQ48ncgaise/LQf04pPUYIXYa0JZ Bll7A12IiNxCdVvy0WQPo+h1o3GPUswo4/xuKNpo9rvHjFDaylDhwP04QbeSeuLR3a/z 2oJ0ucWb8HaSnZhBQSSaENaZ+V/+DOtBF9ClJIaVdgY/60Zsfy+d3rQMLlbsYEyRhg3a VmRnpSpqrdStGLVA96gTh90igEATUJ8r/fEfH9hJvq2/93swDoTCuXjjfVEy1hIKhOm0 Lfeg== X-Gm-Message-State: AGi0PubXs9TURwqc2MdfNFZ6kIaW8Nmzq15dFE5PjKneRrDJ/CA7194t 0AGmfFzoP+1obdFG+Gjm/nYWv/bAbvwQE/PEqZAc8g== X-Google-Smtp-Source: APiQypLulxUioPhsOSevCx8qJ8SqbLCaoLjQHtE70bRbLeXZGLEVQcxyXl0D3zrYs4nuYBD7PWAplxCPi6N2wB7Lw64= X-Received: by 2002:a1f:a2d0:: with SMTP id l199mr8461408vke.77.1585960880795; Fri, 03 Apr 2020 17:41:20 -0700 (PDT) MIME-Version: 1.0 References: <7c364eb4-ad8a-4bbf-85c4-d859d7e23b20@dogfood.fastmail.com> In-Reply-To: <7c364eb4-ad8a-4bbf-85c4-d859d7e23b20@dogfood.fastmail.com> From: Daniel Migault Date: Fri, 3 Apr 2020 20:41:09 -0400 Message-ID: To: Bron Gondwana Cc: IETF-Calsify , calconnect-l@lists.calconnect.org Content-Type: multipart/alternative; boundary="000000000000ed753a05a26c4a82" Archived-At: Subject: Re: [calsify] Planning for an interim meeting co-located with CalConnect in April X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2020 00:41:23 -0000 --000000000000ed753a05a26c4a82 Content-Type: text/plain; charset="UTF-8" Feel free to change the time. Yours, Daniel On Fri, Apr 3, 2020 at 7:26 PM Bron Gondwana wrote: > Should we still hold this meeting? Maybe. If so, I'd like to move it a > little earlier though, since 4pm London is 1am Melbourne! If we go a > couple of hours earlier to 2pm London, we bring it back to 11pm Melbourne > and 9am New York - it's still early for US West Coast, but I think that's > the best compromise for the timezones where our people are. > > Cheers, > > Bron. > > On Fri, Jan 17, 2020, at 09:39, Bron Gondwana wrote: > > Hi All, > > CalConnect's next meeting is in Nottingham UK from April 20-24. > > I expect we will hold the meeting at the end of the day UK time in order > to make as much as possible of Europe and the USA available to attend > (sorry Australia!) > > Right now we have wide flexibility on the timing - does anyone who is > likely to attend have any specific days that will not work so we can avoid > those days. Please let me know. > > Thanks, > > Bron.. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Daniel Migault Ericsson --000000000000ed753a05a26c4a82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Feel free to change the time.=C2=A0
Yours,=C2=A0
=
Daniel

On Fri, Apr 3, 2020 at 7:26 PM Bron Gondwana <brong@fastmailteam.com> wrote:
Should we still hold this meeting?=C2=A0 Maybe.= =C2=A0 If so, I'd like to move it a little earlier though, since 4pm Lo= ndon is 1am Melbourne!=C2=A0 If we go a couple of hours earlier to 2pm Lond= on, we bring it back to 11pm Melbourne and 9am New York - it's still ea= rly for US West Coast, but I think that's the best compromise for the t= imezones where our people are.
Cheers,

Bron.
<= div style=3D"font-family:Arial">
On Fri, Jan 17, 2020, at 09:= 39, Bron Gondwana wrote:
Hi All,

Cal= Connect's next meeting is in Nottingham UK from April 20-24.
<= div style=3D"font-family:Arial">
= I expect we will hold the meeting at the end of the day UK time in order to= make as much as possible of Europe and the USA available to attend (sorry = Australia!)

Right now we have wide flexibility on the timing - d= oes anyone who is likely to attend have any specific days that will not wor= k so we can avoid those days.=C2=A0 Please let me know.

Thanks,

Bron..

--
=C2=A0 Bron Gondwana, CEO, Fastmail Pty L= td


____________________________________= ___________
calsify mailing list

=

--
=C2=A0 Bron Gondwana, = CEO, Fastmail Pty Ltd


________________= _______________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify


--
Daniel Migault
Ericsson
--000000000000ed753a05a26c4a82-- From nobody Sat Apr 4 19:36:38 2020 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 8011B3A10E6 for ; Sat, 4 Apr 2020 19:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 rLQQmD2JztVk for ; Sat, 4 Apr 2020 19:36:33 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 7274D3A10ED for ; Sat, 4 Apr 2020 19:36:33 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id Kv5EjpWjdlbu3Kv9Dja9aX; Sun, 05 Apr 2020 02:36:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1586054191; bh=IfYMnySfgkUeZPbvmGaTICRevehCgsvh9NGSziy9S48=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=BTJfo4E30SljhN9YQXpe6iU9cRBaOn0PC5OlL5gguTOGrHuEkplOji/je99LBR5oa NQjqJQ9i3NQk3UgYfASAEMskLuzBOQACDgXwSOlhWD0Ga3wSjoK9wyeWMs6G7jwfAF 9IY5ZZqU6ldnXYIJZRTSqA+RDFNQxSnJWQPzILy8qv4w+BLXNYBgceS9eyPxmcd0Oz MKVwfWStCw+p8zUEEXVVZfgnP5+75awKzPwJ4Us4zdujRoG9u/BGfsi0P7X9PS1ftX y3QT7+/Iiz9460HXjk8nUIZSY5W9rhbqOWstIuK6/sXQmZuORMQV/0mTClGIwep0/8 n8s16XjcxAEcQ== Received: from THARE ([98.192.130.240]) by resomta-ch2-01v.sys.comcast.net with ESMTPA id Kv9CjqlNhyB3rKv9Cjwl1f; Sun, 05 Apr 2020 02:36:31 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduhedrtdelgdeitdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfhfjgfufffkgggtofhtsegrtdhgpedvtdejnecuhfhrohhmpedfvfhimhcujfgrrhgvfdcuoefvihhmjfgrrhgvsegtohhmtggrshhtrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeelkedrudelvddrudeftddrvdegtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopefvjfettffgpdhinhgvthepleekrdduledvrddufedtrddvgedtpdhmrghilhhfrhhomhepthhimhhhrghrvgestghomhgtrghsthdrnhgvthdprhgtphhtthhopegtrghlshhifhihsehivghtfhdrohhrghdprhgtphhtthhopehmihhkvggrughouhhglhgrshhssehgmhgrihhlrdgtohhm X-Xfinity-VMeta: sc=-100.00;st=legit From: "Tim Hare" To: "'Michael Douglass'" , References: <158363619759.25642.15164071767646081255@ietfa.amsl.com> <89e9d6f2-9632-6c17-adfc-0a1977f15fcc@gmail.com> <5db6d2e1-8512-5f32-94d0-6f7057481a3d@gmail.com> In-Reply-To: <5db6d2e1-8512-5f32-94d0-6f7057481a3d@gmail.com> Date: Sat, 4 Apr 2020 22:36:28 -0400 Message-ID: <028801d60af3$031951d0$094bf570$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0289_01D60AD1.7C09ADA0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGmjtK7MABMD18P8ce4wURb5WWCKQFHLmF7AkkncSoBxRRAY6ieG5gg Content-Language: en-us Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 02:36:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0289_01D60AD1.7C09ADA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable As for DTSTAMP and LAST-MODIFIED, RFC States ------------------------------------------- Property Name: DTSTAMP =20 Purpose: In the case of an iCalendar object that specifies a "METHOD" property, this property specifies the date and time that the instance of the iCalendar object was created. In the case of an iCalendar object that doesn't specify a "METHOD" property, this property specifies the date and time that the information associated with the calendar component was last revised in the calendar store. =20 Property Name: LAST-MODIFIED =20 Purpose: This property specifies the date and time that the information associated with the calendar component was last revised in the calendar store. =20 Note: This is analogous to the modification date and time for a file in the file system. =20 So, when an item has a METHOD such as REQUEST then this is the time the = object was created, NOT the time the object was last created in the = calendar store. If no METHOD is specified (this is not part of a = scheduling flow, for example) then they serve the same purpose. If I = were creating files or objects I would use both in any case. Tim Hare Interested Bystander, Non-Inc. =20 =20 =20 From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of Michael = Douglass Sent: Friday, April 3, 2020 6:55 PM To: calsify@ietf.org Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.txt =20 =20 On 4/3/20 17:29, Michael Douglass wrote: Further comments below On 4/2/20 19:06, Michael Douglass wrote: I have to apologize for the lateness of these issues I want to raise but = I've started implementing the mapping of icalendar to JSCalendar and I'm = already running into some problems. I've only looked at a few properties so far. In general - while I initially thought an informational spec would be = fine for describing the mappings - I'm now of the opinion it has to be = mandated where possible. Otherwise we're going to have a whole mess of = incompatible implementations. Privacy <-> CLASS The first was the use of "secret" instead of "confidential" for the = privacy property. The result is that a simple conversion to lowercase = for jscalendar isn't sufficient. I know neither authors want to change = at this late stage but I mention it (again) because this will be a = perpetual annoyance. link <->ATTACH, IMAGE, URL=20 ATTACH and IMAGE seem fine (reltype of enclosure and icon resp.) but URL = doesn't.=20 The description of rel has this: Links with a rel of "describedby" SHOULD be considered by the client to be an alternative representation of the description. Is that supposed to be the same as URL - it doesn't match the = description for URL in 5545? I think the spec needs to explicitly state that URL MUST be represented = by a link with a given rel - I'd suggest "alternate" because that seems = closer to what is intended in 5545. =20 comments <-> COMMENT comments is only specified for timezone rules. It needs to be valid for = all or some indication of how to handle them needs to be provided. There is an issue in 5545 with COMMENT in scheduling e.g. is a comment = meant only for the organizer? That could be tightened up. CONTACT There's no mapping suggested. CONTACT is vital for event publication. = I'd suggest following the approach in eventpub - add a participantType = property to participant Having looked again I thought this could probably be handled just by = changing the wording for participant as I suggested and extending the = roles values. However I think that's conceptually more complicated,=20 "participantTypes": {"attendee": true} "roles": {"optional": true} is easier to understand than=20 "participantTypes": {"optional": true} implying this is an optional attendee. Changing role "attendee" to "required" or "expected" might make sense participantTypes: "String[Boolean]" (mandatory) =20 Defines the type of participation in events or tasks. Participants can be individuals or organizations, for example attendees, a soccer team, the spectators, or = the musicians. At least one type MUST be specified for the participant. The keys in the set MUST be one of the following values, a value registered in the IANA JSCalendar Enum Registry, or a vendor-specific value: =20 * "attendee": A participant attending a meeting. =20 * "active": A participant taking an active role - for example a = team member. =20 * "inactive": A participant taking an inactive part - for example = an audience member. =20 * "sponsor": A sponsor of the event. The order property may be = used with this participant type to define the relative order of multiple sponsors. =20 * "contact": Contact information for the event. The order = property may be used with this participant type to define the relative order = of multiple contacts. =20 =20 * "booking-contact": Contact information for reservations or = payment =20 * "emergency-contact": Contact in case of emergency =20 * "publicity-contact": Contact for publicity =20 * "planner-contact: Contact for the event planner or organizer =20 * "performer": A performer - for example the soloist or the = accompanist. The order property may be used with this participant type to define the relative order of multiple performers. For example, "order": 1 could define the principal performer or soloist. =20 * "speaker": Speaker at an event =20 Change the participant description: .... If this property is set with a participant type of "attendee", then = the "replyTo" property of this calendar object MUST define at least one reply method. .... o roles: "String[Boolean]" (mandatory for participantType =3D = "attendee") =20 I've got another question on mapping: In your mapping draft you say: An iCalendar ORGANIZER maps to both the replyTo property and a participant with role "owner". If an ATTENDEE with the same CAL- ADDRESS value exists, then it maps to the same participant as the ORGANIZER participant. What if the attendee and organizer have different SENT-BY parameters? = And what is SENT-BY mapped to? I think the 2 ought to be kept separate. =20 =20 GEO, PERCENT-COMPLETE What are we supposed to do with these? updated <-> DTSTAMP, LAST-MODIFIED I don't understand why 5545 has 2 values - however I think we need a = better statement of how to map 2 values on to 1 - something about the = later of the 2? More to follow... =20 On 3/7/20 21:56, internet-drafts@ietf.org = wrote: A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Calendaring Extensions WG of the IETF. =20 Title : JSCalendar: A JSON representation of calendar = data Authors : Neil Jenkins Robert Stepanek Filename : draft-ietf-calext-jscalendar-26.txt Pages : 77 Date : 2020-03-07 =20 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 and, over time, successor to the widely deployed iCalendar data format, and to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also JSON-based, JSCalendar is not a direct mapping from iCalendar, but defines the data model independently and expands semantics where appropriate. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-26 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-26 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-calext-jscalendar-26 =20 =20 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. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 =20 _______________________________________________ calsify mailing list calsify@ietf.org =20 https://www.ietf.org/mailman/listinfo/calsify ------=_NextPart_000_0289_01D60AD1.7C09ADA0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

As for DTSTAMP and LAST-MODIFIED,=C2=A0=C2=A0 RFC = States

-------------------------------------------

=C2=A0=C2=A0 Property Name:=C2=A0 DTSTAMP

 

=C2=A0=C2=A0 = Purpose:=C2=A0 In the case of an iCalendar object that specifies = a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "METHOD" property, this = property specifies the date and time that

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the instance of the iCalendar = object was created.=C2=A0 In the case of

=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0an iCalendar object that doesn't = specify a "METHOD" property, this

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 property specifies the date and = time that the information

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 associated with the calendar = component was last revised in the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 calendar = store.

 

=C2=A0=C2=A0 = Property Name:=C2=A0 LAST-MODIFIED

 

=C2=A0=C2=A0 = Purpose:=C2=A0 This property specifies the date and time that = the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 information associated with the = calendar component was last

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 revised in the calendar = store.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note: This is = analogous to the modification date and time for = a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 file in the file = system.

 

So, when an item has a METHOD such as REQUEST then this is the time the = object was created, NOT the time the object was last created in the = calendar store.=C2=A0=C2=A0=C2=A0 If no METHOD is specified (this is not = part of a scheduling flow, for example) then they serve the same = purpose. =C2=A0=C2=A0If I were creating files or objects I would use = both in any case.

Tim Hare
Interested Bystander, = Non-Inc.

 

 

 

From:<= /b> = calsify [mailto:calsify-bounces@ietf.org] On Behalf Of Michael = Douglass
Sent: Friday, April 3, 2020 6:55 PM
To: = calsify@ietf.org
Subject: Re: [calsify] I-D Action: = draft-ietf-calext-jscalendar-26.txt

 

 

On 4/3/20 17:29, Michael Douglass = wrote:

Further comments = below

On 4/2/20 19:06, Michael = Douglass wrote:

I have to apologize = for the lateness of these issues I want to raise but I've started = implementing the mapping of icalendar to JSCalendar and I'm already = running into some problems.

I've only looked at a few = properties so far.

In general - while I initially = thought an informational spec would be fine for describing the mappings = - I'm now of the opinion it has to be mandated where possible. Otherwise = we're going to have a whole mess of incompatible = implementations.

Privacy <-> = CLASS

The first was the use of "secret" = instead of "confidential" for the privacy property. The result = is that a simple conversion to lowercase for jscalendar isn't = sufficient. I know neither authors want to change at this late stage but = I mention it (again) because this will be a perpetual = annoyance.

link <->ATTACH, IMAGE, URL =

ATTACH and IMAGE seem fine (reltype = of enclosure and icon resp.) but URL doesn't.

The = description of rel has this:

=C2=A0 Links with a rel =
of "describedby" SHOULD be considered by =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 client to be an =
alternative representation of the description.

Is = that supposed to be the same as URL - it doesn't match the description = for URL in 5545?

I think the spec needs to explicitly = state that URL MUST be represented by a link with a given rel - I'd = suggest "alternate" because that seems closer to what is = intended in 5545.

 

comments = <-> COMMENT

comments is only specified for = timezone rules. It needs to be valid for all or some indication of how = to handle them needs to be provided.

There is an issue = in 5545 with COMMENT in scheduling e.g. is a comment meant only for the = organizer? That could be tightened = up.

CONTACT

There's no = mapping suggested. CONTACT is vital for event publication. I'd suggest = following the approach in eventpub - add a participantType property to = participant

Having looked again I thought = this could probably be handled just by changing the wording for = participant as I suggested and extending the roles values. However I = think that's conceptually more complicated, =

"participantTypes": {"attendee": = true}

"roles": {"optional": = true}

is easier to understand than =

"participantTypes": {"optional": = true}

implying this is an optional = attendee.

Changing role "attendee" to = "required" or "expected" might make = sense

participantTypes: =
"String[Boolean]" =
(mandatory)
 
Defines the =
type of participation in
events or tasks.=C2=A0 =
Participants can be individuals or
organizations, =
for example attendees, a soccer team, the spectators, or =
the
musicians.
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 At least one type MUST be specified for the =
participant.=C2=A0 The =
keys
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the set MUST =
be one of the following values, a value =
registered
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the =
IANA JSCalendar Enum Registry, or a vendor-specific =
value:
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 *=C2=A0 "attendee": A participant attending a =
meeting.
 
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 *=C2=A0 "active": A participant taking an =
active role - for example a =
team
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 =
member.
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 * "inactive":=C2=A0 A participant taking an =
inactive part - for example =
an
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 audience =
member.
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 * "sponsor":=C2=A0 A sponsor of the event.=C2=A0 =
The order property may be =
used
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
with this participant type to define the relative order =
of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
multiple =
sponsors.
 
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 * "contact":=C2=A0 Contact information for the =
event.=C2=A0 The order property =
may
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 be =
used with this participant type to define the relative order =
of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
multiple =
contacts.
 
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * =
"booking-contact":=C2=A0 Contact information for reservations =
or =
payment
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 * "emergency-contact":=C2=A0 Contact in case of =
emergency
 
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 * "publicity-contact":=C2=A0 Contact for =
publicity
 
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 * "planner-contact:=C2=A0 Contact for the event =
planner or =
organizer
 
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 * "performer":=C2=A0 A performer - for example =
the soloist or the =
accompanist.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The =
order property may be used with this participant type =
to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 define the =
relative order of multiple performers.=C2=A0 For =
example,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
"order": 1 could define the principal performer or =
soloist.
 
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 * "speaker":=C2=A0 Speaker at an =
event
 
Change the =
participant =
description:
....
=C2=A0=C2=A0 =
If this property is set with a participant type of "attendee", =
then the "replyTo" property of this =
calendar
=C2=A0=C2=A0 object MUST define at least =
one reply =
method.
....
=C2=A0=C2=A0 =
o=C2=A0 roles: "String[Boolean]" (mandatory for =
participantType =3D =
"attendee")

 

I've got another question on mapping:

In your = mapping draft you say:

An iCalendar ORGANIZER maps to =
both the replyTo property and a
=C2=A0=C2=A0 =
participant with role "owner".=C2=A0 If an ATTENDEE with the =
same CAL-
=C2=A0=C2=A0 ADDRESS value exists, then =
it maps to the same participant as the
=C2=A0 =
=C2=A0ORGANIZER participant.

What if the attendee and = organizer have different SENT-BY parameters? And what is SENT-BY mapped = to?

I think the 2 ought to be kept = separate.

 
 
GEO, =
PERCENT-COMPLETE
What are we supposed to do with =
these?
updated <-> DTSTAMP, =
LAST-MODIFIED
I don't understand why 5545 has 2 values =
- however I think we need a better statement of how to map 2 values on =
to 1 - something about the later of the 2?
More to =
follow...
 
On 3/7/20 21:56, internet-drafts@ietf.org =
wrote:
A New Internet-Draft =
is available from the on-line Internet-Drafts =
directories.
This draft is a work item of the =
Calendaring Extensions WG of the =
IETF.
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 =
Title=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : =
JSCalendar: A JSON representation of calendar =
data
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
Authors=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Neil =
Jenkins
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Robert =
Stepanek
=C2=A0=C2=A0=C2=A0=C2=A0 =
Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : =
draft-ietf-calext-jscalendar-26.txt
=C2=A0=C2=A0=C2=A0=
=C2=A0 Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
: 77
=C2=A0=C2=A0=C2=A0=C2=A0 =
Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : =
2020-03-07
 
Abstract:
=C2=A0=C2=A0 This specification defines a data model =
and JSON representation of
=C2=A0=C2=A0 calendar =
data that can be used for storage and data exchange in =
a
=C2=A0=C2=A0 calendaring and scheduling =
environment.=C2=A0 It aims to be an =
alternative
=C2=A0=C2=A0 and, over time, successor =
to the widely deployed iCalendar data
=C2=A0=C2=A0 =
format, and to be unambiguous, extendable, and simple to process.=C2=A0 =
In
=C2=A0=C2=A0 contrast to the jCal format, which =
is also JSON-based, JSCalendar is
=C2=A0=C2=A0 not =
a direct mapping from iCalendar, but defines the data =
model
=C2=A0=C2=A0 independently and expands =
semantics where =
appropriate.
 
 =

The IETF datatracker status page for this draft =
is:
h=
ttps://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/
 
There are also htmlized =
versions available at:
http=
s://tools.ietf.org/html/draft-ietf-calext-jscalendar-26
https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-=
26
 
A diff from the =
previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-calext-jscalendar-26
 
 
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/
 
 <=
/o:p>
_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/calsify
------=_NextPart_000_0289_01D60AD1.7C09ADA0-- From nobody Sat Apr 4 20:14:47 2020 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 74C7C3A12C7 for ; Sat, 4 Apr 2020 20:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 kybwpyRnTeKk for ; Sat, 4 Apr 2020 20:14:42 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 C1D503A12C4 for ; Sat, 4 Apr 2020 20:14:41 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id 13so361898qko.10 for ; Sat, 04 Apr 2020 20:14:41 -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-language; bh=sNEWG78SYIhfOqQgjXnESsu4VR1R7mlNjr7AyfcBIb8=; b=tP/sZmdkLn2hpSi8AU7BT7Hfs3tf2h+MUAk7IZqER5kR8qsL8asZDbBC/XC4VZhcvw Xarifvx4qIzgj4ngX5Fqqga2jOMynANjAM8Odch4aLQxO+qpaEuDCTN8Zw0Q86MPejZu R6nfb1W2RuypSFu45ruS+BYpRGFKFcDxgP1e4XHIs9OurJC9fL6G1xGOTv1KjdgI55XO k3IR4U+C4OPa/M7ciygBBALi0yF+7K95WzHRAotMSH/3yQQ6sTonbKMhO5JR6m8Bcvyq gP8WLYyUj5HMfTSRH6JeKO0PfewruLMLLphdLAcLwRCSxuXmy2Pv2CFGq0zXLjlaRB6g gheA== 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-language; bh=sNEWG78SYIhfOqQgjXnESsu4VR1R7mlNjr7AyfcBIb8=; b=iCvH30M9MSg/H2Rq9A0K3N+LmwkyVVplFpLFnUdwF+ABpTZ6EuFePhJ8dNhcE2tyHI Zx0K9VAYAnq8HeXUkAlqHLnaR+j1pTXbT7vaNFzVJMJ/T29Cu0PaYTPVTT9bOgUiaubS ehooT4LtyAjgJzZ0N5EbW/2gVgz9wGZ+EwLl2q9NeMR3fYepOo1ZXguZTQSkQ2H0oBYG PEfE8JwEjwetK30pDkas70iXVu2KGGfIUUmt/u4tbcKjyHK2N+AYfywJAE0T/uzvEc2w MNO2H2B1ZLAtlLK0yqevGfkhU43TQL6Ev8M0yc2ZMsbpuBn8TMo6pFBOw050W0dgoCeW +JTA== X-Gm-Message-State: AGi0PuZExVE2IwN7DjFB7bUimKQFu+lH+80/nZr6+dmym2UEq8KgWmCu Apb7mdxqEWg8fptA4z3eUgZYKXFelOU= X-Google-Smtp-Source: APiQypL+SsoeKJFO+3jWtYZRERmyRcUrAkj/vsyYurL5DAA8McsR2szJGrGD4HgBprOMl1hv2f0dpg== X-Received: by 2002:a37:2e44:: with SMTP id u65mr9421025qkh.42.1586056480198; Sat, 04 Apr 2020 20:14:40 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id p1sm10999026qkf.73.2020.04.04.20.14.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Apr 2020 20:14:39 -0700 (PDT) To: Tim Hare , calsify@ietf.org References: <158363619759.25642.15164071767646081255@ietfa.amsl.com> <89e9d6f2-9632-6c17-adfc-0a1977f15fcc@gmail.com> <5db6d2e1-8512-5f32-94d0-6f7057481a3d@gmail.com> <028801d60af3$031951d0$094bf570$@comcast.net> From: Michael Douglass Message-ID: Date: Sat, 4 Apr 2020 23:14:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <028801d60af3$031951d0$094bf570$@comcast.net> Content-Type: multipart/alternative; boundary="------------E9D1919924984BDD1D3E5955" Content-Language: en-US Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 03:14:45 -0000 This is a multi-part message in MIME format. --------------E9D1919924984BDD1D3E5955 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 4/4/20 22:36, Tim Hare wrote: > > As for DTSTAMP and LAST-MODIFIED,   RFC States > > ------------------------------------------- > > Property Name:  DTSTAMP > > Purpose:  In the case of an iCalendar object that specifies a > > "METHOD" property, this property specifies the date and time that > > the instance of the iCalendar object was created.  In the case of > >  an iCalendar object that doesn't specify a "METHOD" property, this > > property specifies the date and time that the information > > associated with the calendar component was last revised in the > > calendar store. > > Property Name:  LAST-MODIFIED > > Purpose:  This property specifies the date and time that the > > information associated with the calendar component was last > > revised in the calendar store. > > Note: This is analogous to the modification date and time for a > >          file in the file system. > > So, when an item has a METHOD such as REQUEST then this is the time > the object was created, NOT the time the object was last created in > the calendar store.    If no METHOD is specified (this is not part of > a scheduling flow, for example) then they serve the same purpose.   If > I were creating files or objects I would use both in any case. > > Tim Hare > Interested Bystander, Non-Inc. > Well - I saw the words but I couldn't figure out what the practical difference is. If there really is a practical difference and we should be setting these differently then it suggests the mapping in jscalendar needs to be revised. There is a scheduleUpdated property in the participant - is that what corresponds to the itip usage of DTSTAMP? > *From:*calsify [mailto:calsify-bounces@ietf.org] *On Behalf Of > *Michael Douglass > *Sent:* Friday, April 3, 2020 6:55 PM > *To:* calsify@ietf.org > *Subject:* Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.txt > > On 4/3/20 17:29, Michael Douglass wrote: > > Further comments below > > On 4/2/20 19:06, Michael Douglass wrote: > > I have to apologize for the lateness of these issues I want to > raise but I've started implementing the mapping of icalendar > to JSCalendar and I'm already running into some problems. > > I've only looked at a few properties so far. > > In general - while I initially thought an informational spec > would be fine for describing the mappings - I'm now of the > opinion it has to be mandated where possible. Otherwise we're > going to have a whole mess of incompatible implementations. > > Privacy <-> CLASS > > The first was the use of "secret" instead of "confidential" > for the privacy property. The result is that a simple > conversion to lowercase for jscalendar isn't sufficient. I > know neither authors want to change at this late stage but I > mention it (again) because this will be a perpetual annoyance. > > link <->ATTACH, IMAGE, URL > > ATTACH and IMAGE seem fine (reltype of enclosure and icon > resp.) but URL doesn't. > > The description of rel has this: > >   Links with a rel of "describedby" SHOULD be considered by the > >       client to be an alternative representation of the description. > > Is that supposed to be the same as URL - it doesn't match the > description for URL in 5545? > > I think the spec needs to explicitly state that URL MUST be > represented by a link with a given rel - I'd suggest > "alternate" because that seems closer to what is intended in 5545. > > comments <-> COMMENT > > comments is only specified for timezone rules. It needs to be > valid for all or some indication of how to handle them needs > to be provided. > > There is an issue in 5545 with COMMENT in scheduling e.g. is a > comment meant only for the organizer? That could be tightened up. > > CONTACT > > There's no mapping suggested. CONTACT is vital for event > publication. I'd suggest following the approach in eventpub - add > a participantType property to participant > > Having looked again I thought this could probably be handled just by > changing the wording for participant as I suggested and extending the > roles values. However I think that's conceptually more complicated, > > "participantTypes": {"attendee": true} > > "roles": {"optional": true} > > is easier to understand than > > "participantTypes": {"optional": true} > > implying this is an optional attendee. > > Changing role "attendee" to "required" or "expected" might make sense > > participantTypes: "String[Boolean]" (mandatory) > > Defines the type of participation in > > events or tasks.  Participants can be individuals or > > organizations, for example attendees, a soccer team, the spectators, or the > > musicians. > >       At least one type MUST be specified for the participant.  The keys > >       in the set MUST be one of the following values, a value registered > >       in the IANA JSCalendar Enum Registry, or a vendor-specific value: > >       *  "attendee": A participant attending a meeting. > >       *  "active": A participant taking an active role - for example a team > >          member. > >       * "inactive":  A participant taking an inactive part - for example an > >       audience member. > >       * "sponsor":  A sponsor of the event.  The order property may be used > >         with this participant type to define the relative order of > >         multiple sponsors. > >       * "contact":  Contact information for the event.  The order property may > >         be used with this participant type to define the relative order of > >         multiple contacts. > >       * "booking-contact":  Contact information for reservations or payment > >       * "emergency-contact":  Contact in case of emergency > >       * "publicity-contact":  Contact for publicity > >       * "planner-contact:  Contact for the event planner or organizer > >       * "performer":  A performer - for example the soloist or the accompanist. > >       The order property may be used with this participant type to > >       define the relative order of multiple performers.  For example, > >       "order": 1 could define the principal performer or soloist. > >       * "speaker":  Speaker at an event > > Change the participant description: > > .... > >    If this property is set with a participant type of "attendee", then the "replyTo" property of this calendar > >    object MUST define at least one reply method. > > .... > >    o  roles: "String[Boolean]" (mandatory for participantType = "attendee") > > I've got another question on mapping: > > In your mapping draft you say: > > An iCalendar ORGANIZER maps to both the replyTo property and a >    participant with role "owner".  If an ATTENDEE with the same CAL- >    ADDRESS value exists, then it maps to the same participant as the >    ORGANIZER participant. > > What if the attendee and organizer have different SENT-BY parameters? > And what is SENT-BY mapped to? > > I think the 2 ought to be kept separate. > > > > GEO, PERCENT-COMPLETE > > What are we supposed to do with these? > > updated <-> DTSTAMP, LAST-MODIFIED > > I don't understand why 5545 has 2 values - however I think we > need a better statement of how to map 2 values on to 1 - > something about the later of the 2? > > More to follow... > > On 3/7/20 21:56, internet-drafts@ietf.org > wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Calendaring Extensions WG of the IETF. > >         Title           : JSCalendar: A JSON representation of calendar data > >         Authors         : Neil Jenkins > >                           Robert Stepanek > >      Filename        : draft-ietf-calext-jscalendar-26.txt > >      Pages           : 77 > >      Date            : 2020-03-07 > > 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 > >    and, over time, successor to the widely deployed iCalendar data > >    format, and to be unambiguous, extendable, and simple to process.  In > >    contrast to the jCal format, which is also JSON-based, JSCalendar is > >    not a direct mapping from iCalendar, but defines the data model > >    independently and expands semantics where appropriate. > > 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-26 > > https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-26 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-26 > > 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 > --------------E9D1919924984BDD1D3E5955 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 4/4/20 22:36, Tim Hare wrote:

As for DTSTAMP and LAST-MODIFIED,   RFC States

-------------------------------------------

   Property Name:  DTSTAMP

 

   Purpose:  In the case of an iCalendar object that specifies a

      "METHOD" property, this property specifies the date and time that

      the instance of the iCalendar object was created.  In the case of

      an iCalendar object that doesn't specify a "METHOD" property, this

      property specifies the date and time that the information

      associated with the calendar component was last revised in the

      calendar store.

 

   Property Name:  LAST-MODIFIED

 

   Purpose:  This property specifies the date and time that the

      information associated with the calendar component was last

      revised in the calendar store.

 

         Note: This is analogous to the modification date and time for a

         file in the file system.

 

So, when an item has a METHOD such as REQUEST then this is the time the object was created, NOT the time the object was last created in the calendar store.    If no METHOD is specified (this is not part of a scheduling flow, for example) then they serve the same purpose.   If I were creating files or objects I would use both in any case.

Tim Hare
Interested Bystander, Non-Inc.

Well - I saw the words but I couldn't figure out what the practical difference is. If there really is a practical difference and we should be setting these differently then it suggests the mapping in jscalendar needs to be revised.

There is a scheduleUpdated property in the participant - is that what corresponds to the itip usage of DTSTAMP?

 

 

 

From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of Michael Douglass
Sent: Friday, April 3, 2020 6:55 PM
To: calsify@ietf.org
Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.txt

 

 

On 4/3/20 17:29, Michael Douglass wrote:

Further comments below

On 4/2/20 19:06, Michael Douglass wrote:

I have to apologize for the lateness of these issues I want to raise but I've started implementing the mapping of icalendar to JSCalendar and I'm already running into some problems.

I've only looked at a few properties so far.

In general - while I initially thought an informational spec would be fine for describing the mappings - I'm now of the opinion it has to be mandated where possible. Otherwise we're going to have a whole mess of incompatible implementations.

Privacy <-> CLASS

The first was the use of "secret" instead of "confidential" for the privacy property. The result is that a simple conversion to lowercase for jscalendar isn't sufficient. I know neither authors want to change at this late stage but I mention it (again) because this will be a perpetual annoyance.

link <->ATTACH, IMAGE, URL

ATTACH and IMAGE seem fine (reltype of enclosure and icon resp.) but URL doesn't.

The description of rel has this:

  Links with a rel of "describedby" SHOULD be considered by the
      client to be an alternative representation of the description.

Is that supposed to be the same as URL - it doesn't match the description for URL in 5545?

I think the spec needs to explicitly state that URL MUST be represented by a link with a given rel - I'd suggest "alternate" because that seems closer to what is intended in 5545.

 

comments <-> COMMENT

comments is only specified for timezone rules. It needs to be valid for all or some indication of how to handle them needs to be provided.

There is an issue in 5545 with COMMENT in scheduling e.g. is a comment meant only for the organizer? That could be tightened up.

CONTACT

There's no mapping suggested. CONTACT is vital for event publication. I'd suggest following the approach in eventpub - add a participantType property to participant

Having looked again I thought this could probably be handled just by changing the wording for participant as I suggested and extending the roles values. However I think that's conceptually more complicated,

"participantTypes": {"attendee": true}

"roles": {"optional": true}

is easier to understand than

"participantTypes": {"optional": true}

implying this is an optional attendee.

Changing role "attendee" to "required" or "expected" might make sense

participantTypes: "String[Boolean]" (mandatory)
 
Defines the type of participation in
events or tasks.  Participants can be individuals or
organizations, for example attendees, a soccer team, the spectators, or the
musicians.
      At least one type MUST be specified for the participant.  The keys
      in the set MUST be one of the following values, a value registered
      in the IANA JSCalendar Enum Registry, or a vendor-specific value:
 
      *  "attendee": A participant attending a meeting.
 
      *  "active": A participant taking an active role - for example a team
         member.
 
      * "inactive":  A participant taking an inactive part - for example an
      audience member.
 
      * "sponsor":  A sponsor of the event.  The order property may be used
        with this participant type to define the relative order of
        multiple sponsors.
 
      * "contact":  Contact information for the event.  The order property may
        be used with this participant type to define the relative order of
        multiple contacts.
 
 
      * "booking-contact":  Contact information for reservations or payment
 
      * "emergency-contact":  Contact in case of emergency
 
      * "publicity-contact":  Contact for publicity
 
      * "planner-contact:  Contact for the event planner or organizer
 
      * "performer":  A performer - for example the soloist or the accompanist.
      The order property may be used with this participant type to
      define the relative order of multiple performers.  For example,
      "order": 1 could define the principal performer or soloist.
 
      * "speaker":  Speaker at an event
 
Change the participant description:
....
   If this property is set with a participant type of "attendee", then the "replyTo" property of this calendar
   object MUST define at least one reply method.
....
   o  roles: "String[Boolean]" (mandatory for participantType = "attendee")

 

I've got another question on mapping:

In your mapping draft you say:

An iCalendar ORGANIZER maps to both the replyTo property and a
   participant with role "owner".  If an ATTENDEE with the same CAL-
   ADDRESS value exists, then it maps to the same participant as the
   ORGANIZER participant.

What if the attendee and organizer have different SENT-BY parameters? And what is SENT-BY mapped to?

I think the 2 ought to be kept separate.

 
 

GEO, PERCENT-COMPLETE

What are we supposed to do with these?

updated <-> DTSTAMP, LAST-MODIFIED

I don't understand why 5545 has 2 values - however I think we need a better statement of how to map 2 values on to 1 - something about the later of the 2?

More to follow...

 

On 3/7/20 21:56, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring Extensions WG of the IETF.
 
        Title           : JSCalendar: A JSON representation of calendar data
        Authors         : Neil Jenkins
                          Robert Stepanek
     Filename        : draft-ietf-calext-jscalendar-26.txt
     Pages           : 77
     Date            : 2020-03-07
 
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
   and, over time, successor to the widely deployed iCalendar data
   format, and to be unambiguous, extendable, and simple to process.  In
   contrast to the jCal format, which is also JSON-based, JSCalendar is
   not a direct mapping from iCalendar, but defines the data model
   independently and expands semantics where appropriate.
 
 
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-26
https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-26
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-26
 
 
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
--------------E9D1919924984BDD1D3E5955-- From nobody Sat Apr 4 21:31:54 2020 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 877DA3A1392 for ; Sat, 4 Apr 2020 21:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 v2S8n8KjKG6D for ; Sat, 4 Apr 2020 21:31:50 -0700 (PDT) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 D05233A1391 for ; Sat, 4 Apr 2020 21:31:49 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id t4so5805802qvz.8 for ; Sat, 04 Apr 2020 21:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=gP8bFzG7dvc4WihoNb58QThWIMALPiOEv9jtBt+U4OE=; b=DC/1wt8oJTNcHK5JuNirWafbfXuX9SGPbd90gWBmLGCb+Yc6GG81kWo3a6WzYpw/fG TTREaSurfEZlbIfdr45tKbgwiYsqf3e3rlD+8afJCT2VjGHySBOOeTB+oErpNWaI9Vxm GXyEYmbM2XnOB7GEAxKTAcmj5UJWcebg2oDCD54CBEYDaLOeCm042NXd3qNcaYq08Rdt PWfP8Aa02UB8OH4pMXmS6CLjlbfJ1CZQ5FlcqScGgoKQFWvih5rqjmSsOONPDj7uFnMB 1zXBrIeUi8q0alv27YUN+B/f6F/PnsdaxY5tswBKyeM9HTt8Ml4iqB8sWy46wQ0Xs5m4 7eSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=gP8bFzG7dvc4WihoNb58QThWIMALPiOEv9jtBt+U4OE=; b=ZqcwZmyS1mANHp6kJGJBxrJKh7eJetnB5pG7g4qwsOLCuWagqNjIumz6EMITCfr4CG sYd6bASxyJh+KI/O3OzVv5hnw0VR4QtjHpdthmbhvpm+0n9GnEFq2THBjVyGQb7zYREq MKQt21xYMYm+jmLG8ulTe/RWeFfPntAxHDEyKWWFdSxrSV+QZObFDydW3QZQfoRzUeaO OkPlqKPB2lU97LKzZZqPukutayHGRd6qW6TWZNq7yKN9esUXy6FUaSQp/1hvyK3okyqE OfFenwLAZTUMEWjg5D5K/cQFqbQSUhfqVQq7YzNidr4uCYhIFGY4Zq8qih1ACJa71B5t s1Uw== X-Gm-Message-State: AGi0PuavorIOdGeOBn0UyOvwQfNrN/WzvfryNQ8iNqJdhBINCWesH0qa F3SU/J11Y0eLcXcEurXAuaZPaLZ+T8g= X-Google-Smtp-Source: APiQypJ9UBTJLGwsDRMxGaINpquXLskpT3UqUFpBv73xUhd4WsdDNCnMMeV22bzMx354B4CA7yU/Bg== X-Received: by 2002:a0c:9162:: with SMTP id q89mr14873849qvq.225.1586061108512; Sat, 04 Apr 2020 21:31:48 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id l7sm10856019qkb.47.2020.04.04.21.31.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Apr 2020 21:31:47 -0700 (PDT) From: Michael Douglass To: calsify@ietf.org References: <158363619759.25642.15164071767646081255@ietfa.amsl.com> <89e9d6f2-9632-6c17-adfc-0a1977f15fcc@gmail.com> <5db6d2e1-8512-5f32-94d0-6f7057481a3d@gmail.com> Message-ID: Date: Sun, 5 Apr 2020 00:31:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <5db6d2e1-8512-5f32-94d0-6f7057481a3d@gmail.com> Content-Type: multipart/alternative; boundary="------------1ED123738E348E259C620186" Content-Language: en-US Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 04:31:53 -0000 This is a multi-part message in MIME format. --------------1ED123738E348E259C620186 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Date time issues. The definition of the SUBSECOND parameter needs to be in the jscalendar spec. I'm not sure about the statement: SUBSECOND MUST NOT be used in date- time calculations or comparisons in iCalendar. The smart grid people were asking about having subseconds some time ago so the use of this parameter goes beyond just mapping. Also what about fractional values > 0.5? Really we should round to nearest? Would it be better to have e.g. a FRACTIONAL parameter with the whole date-time and allow the value to be the rounded value.? On 4/3/20 18:55, Michael Douglass wrote: > > > On 4/3/20 17:29, Michael Douglass wrote: >> >> Further comments below >> >> On 4/2/20 19:06, Michael Douglass wrote: >>> >>> I have to apologize for the lateness of these issues I want to raise >>> but I've started implementing the mapping of icalendar to JSCalendar >>> and I'm already running into some problems. >>> >>> I've only looked at a few properties so far. >>> >>> In general - while I initially thought an informational spec would >>> be fine for describing the mappings - I'm now of the opinion it has >>> to be mandated where possible. Otherwise we're going to have a whole >>> mess of incompatible implementations. >>> >>> Privacy <-> CLASS >>> >>> The first was the use of "secret" instead of "confidential" for the >>> privacy property. The result is that a simple conversion to >>> lowercase for jscalendar isn't sufficient. I know neither authors >>> want to change at this late stage but I mention it (again) because >>> this will be a perpetual annoyance. >>> >>> link <->ATTACH, IMAGE, URL >>> >>> ATTACH and IMAGE seem fine (reltype of enclosure and icon resp.) but >>> URL doesn't. >>> >>> The description of rel has this: >>> >>> Links with a rel of "describedby" SHOULD be considered by the >>> client to be an alternative representation of the description. >>> >>> Is that supposed to be the same as URL - it doesn't match the >>> description for URL in 5545? >>> >>> I think the spec needs to explicitly state that URL MUST be >>> represented by a link with a given rel - I'd suggest "alternate" >>> because that seems closer to what is intended in 5545. >>> >>> >>> comments <-> COMMENT >>> >>> comments is only specified for timezone rules. It needs to be valid >>> for all or some indication of how to handle them needs to be provided. >>> >>> There is an issue in 5545 with COMMENT in scheduling e.g. is a >>> comment meant only for the organizer? That could be tightened up. >>> >> CONTACT >> >> There's no mapping suggested. CONTACT is vital for event publication. >> I'd suggest following the approach in eventpub - add a >> participantType property to participant >> > Having looked again I thought this could probably be handled just by > changing the wording for participant as I suggested and extending the > roles values. However I think that's conceptually more complicated, > > "participantTypes": {"attendee": true} > > "roles": {"optional": true} > > is easier to understand than > > "participantTypes": {"optional": true} > > implying this is an optional attendee. > > Changing role "attendee" to "required" or "expected" might make sense > >> participantTypes: "String[Boolean]" (mandatory) >> >> Defines the type of participation in >> events or tasks. Participants can be individuals or >> organizations, for example attendees, a soccer team, the spectators, or the >> musicians. >> At least one type MUST be specified for the participant. The keys >> in the set MUST be one of the following values, a value registered >> in the IANA JSCalendar Enum Registry, or a vendor-specific value: >> >> * "attendee": A participant attending a meeting. >> >> * "active": A participant taking an active role - for example a team >> member. >> >> * "inactive": A participant taking an inactive part - for example an >> audience member. >> >> * "sponsor": A sponsor of the event. The order property may be used >> with this participant type to define the relative order of >> multiple sponsors. >> >> * "contact": Contact information for the event. The order property may >> be used with this participant type to define the relative order of >> multiple contacts. >> >> >> * "booking-contact": Contact information for reservations or payment >> >> * "emergency-contact": Contact in case of emergency >> >> * "publicity-contact": Contact for publicity >> >> * "planner-contact: Contact for the event planner or organizer >> >> * "performer": A performer - for example the soloist or the accompanist. >> The order property may be used with this participant type to >> define the relative order of multiple performers. For example, >> "order": 1 could define the principal performer or soloist. >> >> * "speaker": Speaker at an event >> >> Change the participant description: >> ... >> If this property is set with a participant type of "attendee", then the "replyTo" property of this calendar >> object MUST define at least one reply method. >> ... >> o roles: "String[Boolean]" (mandatory for participantType = "attendee") > > > I've got another question on mapping: > > In your mapping draft you say: > > An iCalendar ORGANIZER maps to both the replyTo property and a > participant with role "owner". If an ATTENDEE with the same CAL- > ADDRESS value exists, then it maps to the same participant as the > ORGANIZER participant. > > What if the attendee and organizer have different SENT-BY parameters? > And what is SENT-BY mapped to? > > I think the 2 ought to be kept separate. > >> >>> >>> GEO, PERCENT-COMPLETE >>> >>> What are we supposed to do with these? >>> >>> updated <-> DTSTAMP, LAST-MODIFIED >>> >>> I don't understand why 5545 has 2 values - however I think we need a >>> better statement of how to map 2 values on to 1 - something about >>> the later of the 2? >>> >>> More to follow... >>> >>> >>> On 3/7/20 21:56, internet-drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> This draft is a work item of the Calendaring Extensions WG of the IETF. >>>> >>>> Title : JSCalendar: A JSON representation of calendar data >>>> Authors : Neil Jenkins >>>> Robert Stepanek >>>> Filename : draft-ietf-calext-jscalendar-26.txt >>>> Pages : 77 >>>> Date : 2020-03-07 >>>> >>>> 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 >>>> and, over time, successor to the widely deployed iCalendar data >>>> format, and to be unambiguous, extendable, and simple to process. In >>>> contrast to the jCal format, which is also JSON-based, JSCalendar is >>>> not a direct mapping from iCalendar, but defines the data model >>>> independently and expands semantics where appropriate. >>>> >>>> >>>> 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-26 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-26 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-26 >>>> >>>> >>>> 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 --------------1ED123738E348E259C620186 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Date time issues.

The definition of the SUBSECOND parameter needs to be in the jscalendar spec. I'm not sure about the statement:

 SUBSECOND MUST NOT be used in date-
      time calculations or comparisons in  iCalendar.

The smart grid people were asking about having subseconds some time ago so the use of this parameter goes beyond just mapping. Also what about fractional values > 0.5? Really we should round to nearest? Would it be better to have e.g. a FRACTIONAL parameter with the whole date-time and allow the value to be the rounded value.?

On 4/3/20 18:55, Michael Douglass wrote:


On 4/3/20 17:29, Michael Douglass wrote:

Further comments below

On 4/2/20 19:06, Michael Douglass wrote:

I have to apologize for the lateness of these issues I want to raise but I've started implementing the mapping of icalendar to JSCalendar and I'm already running into some problems.

I've only looked at a few properties so far.

In general - while I initially thought an informational spec would be fine for describing the mappings - I'm now of the opinion it has to be mandated where possible. Otherwise we're going to have a whole mess of incompatible implementations.

Privacy <-> CLASS

The first was the use of "secret" instead of "confidential" for the privacy property. The result is that a simple conversion to lowercase for jscalendar isn't sufficient. I know neither authors want to change at this late stage but I mention it (again) because this will be a perpetual annoyance.

link <->ATTACH, IMAGE, URL

ATTACH and IMAGE seem fine (reltype of enclosure and icon resp.) but URL doesn't.

The description of rel has this:

  Links with a rel of "describedby" SHOULD be considered by the
      client to be an alternative representation of the description.

Is that supposed to be the same as URL - it doesn't match the description for URL in 5545?

I think the spec needs to explicitly state that URL MUST be represented by a link with a given rel - I'd suggest "alternate" because that seems closer to what is intended in 5545.


comments <-> COMMENT

comments is only specified for timezone rules. It needs to be valid for all or some indication of how to handle them needs to be provided.

There is an issue in 5545 with COMMENT in scheduling e.g. is a comment meant only for the organizer? That could be tightened up.

CONTACT

There's no mapping suggested. CONTACT is vital for event publication. I'd suggest following the approach in eventpub - add a participantType property to participant

Having looked again I thought this could probably be handled just by changing the wording for participant as I suggested and extending the roles values. However I think that's conceptually more complicated,

"participantTypes": {"attendee": true}

"roles": {"optional": true}

is easier to understand than

"participantTypes": {"optional": true}

implying this is an optional attendee.

Changing role "attendee" to "required" or "expected" might make sense

participantTypes: "String[Boolean]" (mandatory)

Defines the type of participation in
events or tasks.  Participants can be individuals or
organizations, for example attendees, a soccer team, the spectators, or the
musicians.
      At least one type MUST be specified for the participant.  The keys
      in the set MUST be one of the following values, a value registered
      in the IANA JSCalendar Enum Registry, or a vendor-specific value:

      *  "attendee": A participant attending a meeting.

      *  "active": A participant taking an active role - for example a team
         member.

      * "inactive":  A participant taking an inactive part - for example an
      audience member.

      * "sponsor":  A sponsor of the event.  The order property may be used
        with this participant type to define the relative order of
        multiple sponsors.

      * "contact":  Contact information for the event.  The order property may
        be used with this participant type to define the relative order of
        multiple contacts.


      * "booking-contact":  Contact information for reservations or payment

      * "emergency-contact":  Contact in case of emergency

      * "publicity-contact":  Contact for publicity

      * "planner-contact:  Contact for the event planner or organizer

      * "performer":  A performer - for example the soloist or the accompanist.
      The order property may be used with this participant type to
      define the relative order of multiple performers.  For example,
      "order": 1 could define the principal performer or soloist.

      * "speaker":  Speaker at an event

Change the participant description:
...
   If this property is set with a participant type of "attendee", then the "replyTo" property of this calendar
   object MUST define at least one reply method.
...
   o  roles: "String[Boolean]" (mandatory for participantType = "attendee")


I've got another question on mapping:

In your mapping draft you say:

An iCalendar ORGANIZER maps to both the replyTo property and a
   participant with role "owner".  If an ATTENDEE with the same CAL-
   ADDRESS value exists, then it maps to the same participant as the
   ORGANIZER participant.

What if the attendee and organizer have different SENT-BY parameters? And what is SENT-BY mapped to?

I think the 2 ought to be kept separate.

 

GEO, PERCENT-COMPLETE

What are we supposed to do with these?

updated <-> DTSTAMP, LAST-MODIFIED

I don't understand why 5545 has 2 values - however I think we need a better statement of how to map 2 values on to 1 - something about the later of the 2?

More to follow...


On 3/7/20 21:56, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring Extensions WG of the IETF.

        Title           : JSCalendar: A JSON representation of calendar data
        Authors         : Neil Jenkins
                          Robert Stepanek
	Filename        : draft-ietf-calext-jscalendar-26.txt
	Pages           : 77
	Date            : 2020-03-07

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
   and, over time, successor to the widely deployed iCalendar data
   format, and to be unambiguous, extendable, and simple to process.  In
   contrast to the jCal format, which is also JSON-based, JSCalendar is
   not a direct mapping from iCalendar, but defines the data model
   independently and expands semantics where appropriate.


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-26
https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-26

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


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
--------------1ED123738E348E259C620186-- From nobody Wed Apr 8 19:37:11 2020 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 5D1883A05AA for ; Wed, 8 Apr 2020 19:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 lwH7NAEO91zz for ; Wed, 8 Apr 2020 19:37:09 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 225BE3A073D for ; Wed, 8 Apr 2020 19:37:08 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id t11so8861902ils.1 for ; Wed, 08 Apr 2020 19:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=dynVyTVJ/u1JZqbBM5vCMiM8r7icsXPkNZwrbb8EAJo=; b=PBEOr7r7lktXTHW+DkvMYgMLXCTMW3VCKV3tpzgHQlr2Gl/AZfzmjn5d4RoU+FkTLP zjLTJp/hyME/Ajpg0A+V2zeLFUM2Yk9fPseGotCDjjpck9x3aVkDgV5Q9GwCgPFkMrT7 IQrQovMGsiG4EKm8BrDVcu3VuROndVxHnQHsBevQTkQPmKbHLoV9XDZA4WCthL0COIAC eKtgbfG9icbjThTQAoFW0wsYVUd62pAzU5j2cFHs3OJGgDn47gNwKhzDGEsJQyYmZ0d/ V99mC/pF8XCQL5RIpF+BJUUQifrfkoqQMVLWaf1TRfqea9IYIn2SrbvQzXHkMs8d8Fpw Hi2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=dynVyTVJ/u1JZqbBM5vCMiM8r7icsXPkNZwrbb8EAJo=; b=mlFxocG7nkUXyOt/t403/UCwYUeHQap+lpX/BSoTwxeUdKzegfjeiFKq/emyKRaP4T HX6rP90IXMt8NqMM6VYU8S8tbOVTUKN+3c2HRXUq1+mSy6nsletCjH+jeG84P6oJLDjV zcl8VaC0YZIa1/4xNYwft/O9N/Wi5p+1d2NdnPBQc19Crw/9pU7taY1HHUPzvvKIcuH5 p9/f6CyNFuszzoeRXNnRO/36Oe+dbnchTyUYt2kxblmRCvZNg+jVs/pH6/Wp+PsG6Qrk /eKEW8j4drWfC1zas4GbQUu9B2cp3bmi3qJZFqAB9P/We0/V2USFxA0V3325jop+KD/i F0DA== X-Gm-Message-State: AGi0PuY+P7NCbSr+UVKC6qyQn+yIIsXaD9KtPjV3JBgk4nqN63Ualx2Q CJes+6penSS6DGbQEU2/di4= X-Google-Smtp-Source: APiQypJpoibf6TXWKuTFT+gdf3EwuwsG6dWLCfLxbllZ8lQhd4pYFSGl8QqV1mS1oAS+JoLhE9RS0g== X-Received: by 2002:a92:985d:: with SMTP id l90mr3086096ili.108.1586399828312; Wed, 08 Apr 2020 19:37:08 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id k9sm1339396iof.26.2020.04.08.19.37.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Apr 2020 19:37:07 -0700 (PDT) To: calsify@ietf.org, Ken Murchison , Bron Gondwana , Jenkins Neil , Robert Stepanek From: Michael Douglass Message-ID: Date: Wed, 8 Apr 2020 22:37:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [calsify] draft-ietf-calext-jscalendar-26 and mappings to iCalendar X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 02:37:10 -0000 Hi. We had a call today to discuss where to go with the issue of mappings and we are in agreement that the mappings need to be a standards track document. Briefly the reasons are: 1. We need to mandate the mappings that should be used so that downstream services can reliably convert back. 2. These mappings may require the specification of properties and values (e.g. for LINK relationships) which can only be done in such a document. My personal belief is that specifying the mappings should not take too long - very little of it needs to be controversial. The question remains as to whether this should be 1. sections in the jscalendar spec or 2. a separate document. Robert prefers option 1 because we are already a long way on in the process. I'll let him and others expand on that. I prefer option 2 because if these mappings are a requirement they are much harder to miss and a little more convenient. Additionally I think jscalendar MUST state that certain values (e.g. for link rel) are reserved for mapping to iCalendar and that leads to in effect the same situation - jscalendar has to wait for the mapping so it may as well be one document. As for the mappings themselves - I have offered to help produce the content for the spec - wherever it lives and I will repost the issues I already posted as one message per issue to try to reduce the clutter I hope this reflects the opinions of Robert and Ken - please correct me if not... From nobody Wed Apr 8 23:54:37 2020 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 9C2003A0CED for ; Wed, 8 Apr 2020 23:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=qSz9XkXT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=1l41feO4 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 ihpvU1HhrPzG for ; Wed, 8 Apr 2020 23:54:34 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0893A0CEC for ; Wed, 8 Apr 2020 23:54:33 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id EE2435C00A2; Thu, 9 Apr 2020 02:54:32 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute7.internal (MEProxy); Thu, 09 Apr 2020 02:54:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=xWZen7+ 17BbobVYKDn3JZBaG3fHRALP+PKGfYcLwN/g=; b=qSz9XkXTxncpbuo8V1K7Mtl HD+gO7k8+rr2JfcVf4QssJXE7n5ytqaJwLxuJBhB9HpQWAaPZqt2cu3wpcN9IAJx suVIVZlGNw1W1piMvGkqA+Rzi6FFijQsDPyCyZfq0y7Z0wKtojidZBbeQ1hKt1L4 7AVw3faLRnczB2Z1IphnZcHAHl5i5UWn3flQFJU2iPOPCuAzZ5ydf/4bwpfl0Rdu i56FR68Cs/kY/6mki9leRP2fqrSDeg6I/vLbrFRfOwVDn+BfjY+9nM6zY/QM4xav erR0by4SzYRV46NTERsAcmq8NbnL/E+YwMoFenRlajxMeA36lF1pUbuXbJg26+A= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=xWZen7 +17BbobVYKDn3JZBaG3fHRALP+PKGfYcLwN/g=; b=1l41feO43Fe595elq+rLZR oUWIvUOiEENu4FzQ4Eji6k9O2a4xszP+Oh+EumPP9V6BeYfhS4vjSUw9xgWwl4zV sORmXlMPMvBQZmW2WQH0jKO2P2NFbBG4KOtGYOqFHUcdGKSjUY8FGKAFTe4fQ8Uc DrbhdRkzF+noeAOv1tm1XNrRT88Ja6u3a2v9NgNR62qGyTu9zacvGdoFXazoBUdK LKq9775YkfbS7ko6B3tyaAN3Lo6wF2Ue5yDetcBB+NF1WgiYi5IaaVuoYobP8aaL 8WRbf7/B5PGbLwcfq147tXwreZo8yrTpLHfV36rZV8LImwXrixhnPO+ExniZJ3mg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekgdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdftohgs vghrthcuufhtvghprghnvghkfdcuoehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtoh hmqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrghilhhtvggrmh drtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 542B6180090; Thu, 9 Apr 2020 02:54:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1104-g203475c-fmstable-20200408v2 Mime-Version: 1.0 Message-Id: <7e5829d9-d600-4841-8924-00002c9ead54@www.fastmail.com> In-Reply-To: References: Date: Thu, 09 Apr 2020 08:54:11 +0200 From: "Robert Stepanek" To: "Michael Douglass" , calsify@ietf.org, "Ken Murchison" , "Bron Gondwana" , "Neil Jenkins" Content-Type: multipart/alternative; boundary=baecf5bfd3024c20b1a6b3c367d84d74 Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar-26 and mappings to iCalendar X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 06:54:36 -0000 --baecf5bfd3024c20b1a6b3c367d84d74 Content-Type: text/plain Hi Mike, On Thu, Apr 9, 2020, at 4:37 AM, Michael Douglass wrote: > We had a call today to discuss where to go with the issue of mappings > and we are in agreement that the mappings need to be a standards track > document Yes, fully agree. > The question remains as to whether this should be > > 1. sections in the jscalendar spec or > > 2. a separate document. > > Robert prefers option 1 because we are already a long way on in the > process. I'll let him and others expand on that. > > I prefer option 2 because if these mappings are a requirement they are > much harder to miss and a little more convenient. I think you got this wrong. I prefer option 2, whereas I understood you would prefer option 1? I prefer to define a mapping spec as a separate document, and keep the JSCalendar spec as-is. > As for the mappings themselves - I have offered to help produce the > content for the spec - wherever it lives and I will repost the issues I > already posted as one message per issue to try to reduce the clutter I'm happy you'll join as co-author. The (currently outdated) spec source is located at https://github.com/CalConnect/PUBLIC_DRAFTS/blob/master/jscalendar/draft-ietf-calext-jscalendar-icalendar.xml Cheers, Robert --baecf5bfd3024c20b1a6b3c367d84d74 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Mike,

On Thu, Apr 9, 2020, at 4:37 AM, Michael Douglass= wrote:
We had a call = today to discuss where to go with the issue of mappings 
<= div>and we are in agreement that the mappings need to be a standards tra= ck 
document

Yes, fully agree.

The question remains as to whether this should be
=

1. sections in the jscalendar spec or
=
2. a separate document.

Robe= rt prefers option 1 because we are already a long way on in the 
process. I'll let him and others expand on that.

I prefer option 2 because if these mappings are a requ= irement they are 
much harder to miss and a little mo= re convenient.

I think you got= this wrong. I prefer option 2, whereas I understood you would prefer op= tion 1? I prefer to define a mapping spec as a separate document, and ke= ep the JSCalendar spec as-is.

As for the mappings themselves - I have offered to= help produce the 
content for the spec - wherever it= lives and I will repost the issues I 
already posted= as one message per issue to try to reduce the clutter

I'm happy you'll join as co-author. The (curren= tly outdated) spec source is located at https://github.com/CalConnect/PUBLIC_DRAFTS/blob/maste= r/jscalendar/draft-ietf-calext-jscalendar-icalendar.xml

Cheers,
Robert
--baecf5bfd3024c20b1a6b3c367d84d74-- From nobody Sat Apr 11 12:39:30 2020 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 3CF083A1859 for ; Sat, 11 Apr 2020 12:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 6Iiv8NYYj-GY for ; Sat, 11 Apr 2020 12:39:28 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 2714C3A1858 for ; Sat, 11 Apr 2020 12:39:28 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id f16so4986336ilj.9 for ; Sat, 11 Apr 2020 12:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=bE6IYriUfn5p60rNWIMd/YCoMyeb0GbKV9YkSrYTCGI=; b=YSq2QPeAlUHRVYE67xY1nbw9x8srOh9zjf/l/nTIycu+M2+ifPaWePScqRynZZGtlU Juqc7TSVmKoUl/pdyO89dZedZlRKIUWL5mgc1rcpjByAwHj/boDiUivYn9payB+pU3Uo Znp15/ATwdlDqDn2ORIzSEnytgWb4QQ1lmBFiORXC/Cm3Q+hN1SQPlGyJijpzcSxWOIj 2bWSvefzIkXOOE5vsaICi/BRiI3NYmFFNTYUJW2/GCrtTl3KzMlQ/e5a4oUM2Vq6rpfF aEsACZ2eo3qFNXLarPUA1Twn+BkPvNaot6y/9dNTBqoa00ZePL2WLnsDpGZjuOLdvbc0 lWGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=bE6IYriUfn5p60rNWIMd/YCoMyeb0GbKV9YkSrYTCGI=; b=bM69DyIUJg73OWATqvvhN8PgmmdiGy7SpQahNH8xYJXbYGogVGsUD30/xQugKs4+ah e445Qws5dEgcNlaL2Tl5zPFq/dmL/QZfJBK+1Ks92YECNKyR6xXzJKogonNB9Gims1Js U8GVNXc8GjCfx7EQngVwTpJKixQOrBH8VqyPScVJfz90TnBK92BXdpHveGl03cL/YV7h ANoK7PgaLPrHqZuCctGAdXqEgpAeu917sKG0haJYlGwagL4HKJerpoilhseNqhdH3qUB kRtC5Xiiccqv7YxP5W8BbZTzp2C3e43ratEMaeuaTe/qVLOa+4JFzYJ0uu7lGsYiOEry vTjA== X-Gm-Message-State: AGi0PubISV75zsAsROiEZSSwMhfMdQN5EwQoY8VIEp3EhGIwdBlz0nim ci+urX8+A9CEAS7uN166y9r62Vjf X-Google-Smtp-Source: APiQypKGL3Ve3X1mcf1xpNzgaJMYaW4Ie5rxuAnzf8AgIr43MC6DeLH0HLcJqAnEfB2jdQ+U4KrrPA== X-Received: by 2002:a92:9f93:: with SMTP id z19mr6983595ilk.85.1586633967116; Sat, 11 Apr 2020 12:39:27 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id b5sm2079571ilf.23.2020.04.11.12.39.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Apr 2020 12:39:26 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <0acd2f76-cfbc-e43c-cb74-9577faa99528@gmail.com> Date: Sat, 11 Apr 2020 15:39:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [calsify] jscalendar-icalendar mapping - vtimezone X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2020 19:39:29 -0000 I'm completely fine with the default being by reference. It may be good to strengthen the language in  section 1.4.9 A concern is we're not allowing standalone timezone defs. I see 2 uses for that: 1: a group containing a lot of events that all use the same custom timezone - having to repeat that per event is bulky. (probably not a major case but...). I guess the first event could be considered the definition but that's messy. 2. More important - how do we deliver jscalendar format timezones from tzdist? Could we simply allow a timezones property as another alternative in JSGroup? From nobody Sat Apr 11 12:54:29 2020 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 AF3373A1892 for ; Sat, 11 Apr 2020 12:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 Z52hakY92Vy9 for ; Sat, 11 Apr 2020 12:54:26 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 C605B3A1891 for ; Sat, 11 Apr 2020 12:54:26 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id d2so4677090ilc.0 for ; Sat, 11 Apr 2020 12:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=gxfxhPhh0kznxbHMP21C+GE4iYSJrI92uekZ01abPoU=; b=DPhkNE30VFaqgdbT5zwqWpa0FdGfxsahsQND/p8W92S0j2CRUUFIcDL+43gcbNRSAx Gf1xuiIl/mFa0hDYcD07KdTjbzrCatTuLZm9esKbce0HdOe+Hy5R/hhzqUGTUguJtIV9 i3+xVtWDnPoYtxFLpNK7XxuqJiv1v8OJJWmLCZb/LVHY1Iw+6mecnbV8fuZRrYzvhbUQ R1iaQLYoTUsTkYOgDk3AYe1a5RDSa+cjm5izOpchGrKfSHQFbqx7ZZWst59jryJvuz0y D4CrHlVw04jEySyU/mI459R5nVh818rntrwywM0Cj5KfiXmedM+T/M7T49p6ir8k52PA 2GaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=gxfxhPhh0kznxbHMP21C+GE4iYSJrI92uekZ01abPoU=; b=bJX8AOPcPZGdzL5dSSKQgndKhNXE9f9o2sA8yIcin2AVOgyLDnfW5liLbyDsThckOB KcJhN8NhBFY0xhD7vWDybNtLyfd0kvm4Qwk2sg0RSxyMcX2O9qYIASkORfuI9iApIrYo leNWS1cy8R/Ld++PbSzCmYvCcu3cL5vsldh4n9SXpwmdJHYC5IGCWgZ+RsCHUV8aoXHq JTeq+gUQ3Mb5wb+F587IGaaegjEhiQF6WH1/5QDx/ysDR81WNOVvHGu/2EqrbVAoJ0aq bcM5a+sEgUZZ8/GnvIWqo05SFDQGKDghBtXhTLuqNnDCMap/dZq8+iu/utfAdCqW08s/ i9Nw== X-Gm-Message-State: AGi0Pubylk6CJGJ9yGZEuxm2ZbipMfeRoXu+TsPSR3rG4yA1ERupdUrm SxaoTTyoIsa7At1q698t2qpBMy9Q X-Google-Smtp-Source: APiQypIbK7pIJq3UWfJjsZy5fxgTBA9+rSfMCabZ13ElcE2EdT3tap7KAgMel+ln3dnIZBsOWy3usw== X-Received: by 2002:a92:c14a:: with SMTP id b10mr11084372ilh.139.1586634865726; Sat, 11 Apr 2020 12:54:25 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id t86sm2089411ili.82.2020.04.11.12.54.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Apr 2020 12:54:25 -0700 (PDT) To: calsify@ietf.org From: Michael Douglass Message-ID: <2bac5257-fe7e-a306-0a6f-583533e0fe41@gmail.com> Date: Sat, 11 Apr 2020 15:54:24 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------83C9A1DADB9897D85A02223F" Content-Language: en-US Archived-At: Subject: [calsify] draft-ietf-calext-jscalendar-26 - section 3.1 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2020 19:54:29 -0000 This is a multi-part message in MIME format. --------------83C9A1DADB9897D85A02223F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I think this paragraph is incorrect (section 3.1): JSCalendar aims to provide unambiguous definitions for value types and properties, but does not define a general normalization or equivalence method for JSCalendar objects and types. This is because the notion of equivalence might range from byte-level equivalence to semantic equivalence, depending on the respective use case (for example, the CalDAV protocol [RFC4791 ] requires octet equivalence of the encoded calendar object to determine ETag equivalence). It's not CalDAV that requires that - it's https://tools.ietf.org/html/rfc7232#section-2.3 I absolutely agree we shouldn't make the same mistake of using etags as change tokens - there is no allowance for semantic equivalence (though there's some suggestion weak etags might work.) I would be inclined to either delete (for example, the CalDAV protocol [RFC4791 ] requires octet equivalence of the encoded calendar object to determine ETag equivalence) The paragraph at the end may be an appropriate place to say "use a change token" Considering this, the definition of equivalence and normalization is left to client and server implementations and to be negotiated by a calendar exchange protocol or defined elsewhere. --------------83C9A1DADB9897D85A02223F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I think this paragraph is incorrect (section 3.1):

   JSCalendar aims to provide unambiguous definitions for value types
   and properties, but does not define a general normalization or
   equivalence method for JSCalendar objects and types.  This is because
   the notion of equivalence might range from byte-level equivalence to
   semantic equivalence, depending on the respective use case (for
   example, the CalDAV protocol [RFC4791] requires octet equivalence of
   the encoded calendar object to determine ETag equivalence).

It's not CalDAV that requires that - it's https://tools.ietf.org/html/rfc7232#section-2.3

I absolutely agree we shouldn't make the same mistake of using etags as change tokens - there is no allowance for semantic equivalence (though there's some suggestion weak etags might work.) I would be inclined to either delete

 (for
   example, the CalDAV protocol [RFC4791] requires octet equivalence of
   the encoded calendar object to determine ETag equivalence)

The paragraph at the end may be an appropriate place to say "use a change token"

   Considering this, the definition of equivalence and normalization is
   left to client and server implementations and to be negotiated by a
   calendar exchange protocol or defined elsewhere.





--------------83C9A1DADB9897D85A02223F-- From nobody Sat Apr 11 13:05:09 2020 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 477253A18B4 for ; Sat, 11 Apr 2020 13:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 3LreSi3G4f5f for ; Sat, 11 Apr 2020 13:05:07 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 A1DE23A18B2 for ; Sat, 11 Apr 2020 13:05:06 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id b12so5328101ion.8 for ; Sat, 11 Apr 2020 13:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=i7v1Qpz/FX0wgajW6sJQWy2QrQCCpErWfxEIbRcyxvQ=; b=JasY4A0olXK+ka6v3Q3tYUhVnFiFtPf1xh2zBIeB9qmevOSnMbwN/qiELysWZKVCx6 0Y2WsVW114zc9xMHEbAOJk7B+1A18mt6/kJV1H/8NgAuxdeGLCyfB1Sd6kCp3+EY39rF 77a0zzYsQi0e88h3/ymhP6cHDWenaDLt5Wwv8nBIyRK5uDieiu7SNP2sta0wWO7Jl8qV Dd7K1YBs+c1dbjwPPWhe5XXsa6gszgaTTv4aEMfta9FE7feV2pFNaIR1z5x4+oNXREdo sQn/xets5uWCSb8LN5dElPx3EvPNLGlDG+N+mXeeu1zaSAdl+W+74GCRG+dhvXat6ZYS /PxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=i7v1Qpz/FX0wgajW6sJQWy2QrQCCpErWfxEIbRcyxvQ=; b=hLaTti8yNGMVvsCp1FJbfm0wEaXYNqDpXc5lYALII8FckCDhCa8YSEl+zrd1SEoppZ CvECAixf1gR2aAOQOBRJKCjT0kvPz52gGgAYEdf0KLDd5gbrJlLW75YOzEUhLvIHSAKj H7rmr1I9ChKZ21E/jxttaLSXwFDJQYizzvZbQBNYwRc9kmBxli6GH2PpK13TlB5rgcnO RikzJVGYktw1l6dwih9ZxiXG8jc3NcfxFxJxfEuFEYpJmJHK8TiZDdkrtjx4uoiA7edU xaaWcBTcfVFQm/unh/+ew7Z44VMtVjIXxTeQ4+7fMJDdw0bu3KxIVoagZpnmdsAwXeof UW7w== X-Gm-Message-State: AGi0PuZ8qh57pJqhKGG6tTWMIv36ni3qVJPSkakuv1v94PBchUJkuqKM 4XUdQ39dcinE8Io/AtpYlu50JHGE X-Google-Smtp-Source: APiQypL1f04g07DbXDAX927wFbiqqJE0UuRS7dDPgxqozyr6ekIIiFsOyCZ9928QtIgCGULH+PqjSw== X-Received: by 2002:a6b:2b91:: with SMTP id r139mr9821981ior.61.1586635505620; Sat, 11 Apr 2020 13:05:05 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id z8sm942356ilq.61.2020.04.11.13.05.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Apr 2020 13:05:05 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <236a87e7-c4af-485f-e839-4bc2a0cbb9ff@gmail.com> Date: Sat, 11 Apr 2020 16:05:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [calsify] jscalendar-icalendar mapping - CALSCALE X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2020 20:05:09 -0000 I seem to recall that CALSCALE was dropped because only one value is used. Is that so? It's not mentioned anywhere From nobody Mon Apr 13 09:46:37 2020 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 254353A1A2B for ; Mon, 13 Apr 2020 09:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 IyWkP_aXjd-D for ; Mon, 13 Apr 2020 09:46:33 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 C56753A1A28 for ; Mon, 13 Apr 2020 09:46:33 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id z12so9066787ilb.10 for ; Mon, 13 Apr 2020 09:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=4jHkPukf7cZuJktUjUyxgBd/BO8AcPMg7uNMnmnqSRs=; b=Wt2v5N09LgFOPY9wQ3Z5SpmoKh17Y1RCC9M5ZkkdUz6NwhLGWbfO4eOOikH6nTJyFr 3CnQpmYzyC1QX+Bph7yNvE+EWail6O/lZKxQmrzeSSwtJKw9tOI/fEKRE2HXHIdqbWoz Y0ek/Jxma5p2AfzEamhlcEfWIeD36CwIAIgdZWF9gu4m202Mr3ZU3HcUzD2HaazRmByl 57r5eOcR3FBUoeEXJAZtSmyn9DrTFUoJTfYdYnXtlDXnJ7BgtbYcAlksPAA0sLGHXwHY 0VIgisxefS2xiN8fnXA5F+aJBC0qGLmLk+K+khKJIPA4zIkAeAup6PVJf+DF6mXJEzaT CSmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=4jHkPukf7cZuJktUjUyxgBd/BO8AcPMg7uNMnmnqSRs=; b=s0bsv2p0n4rnAETvagJGFBWsAeBuJpLKdXmv1fo22Yh/1ywa0Y9icaA48beActOL8C FjME6m0CK0xuuL52VcGatkiSH3MfrJ1RhyEgh+RZqgD+sSXJmGWPcjbjkAw4VLrfhzlx 4HfIoPTkQe54mOgbJw4Y08mOzyQPHJlrLM0Si1+pdUPbSghCN1Q4zMKrYNXswTP5YN+4 Ojh9khyv59GcZAoQF1qhXKm0KTYtqcF5MtP2wctmkTkRWp3EY9jFrUagEUIuBAz8qIHt HuTLLj0H+Pvf6S2YBjBupM0PTKM9ySZlCQZZ5lHnlD05jSuFOvdhwRPAESEnoVdWUyPg 4iWw== X-Gm-Message-State: AGi0PubgFYakRBxgaVnAOCrpErcuS3EdYwQL2S7xlfpR94GMPyVeVQLA y5z6TXjpF4yLmPVcsINw8YRso+jY X-Google-Smtp-Source: APiQypJEOC17mL4Raai3E5YI0c7WfLo0IDX7aDUvrsVyuelrIri5evvG3+BQn001zVI4M2Q/YWDaBg== X-Received: by 2002:a92:c14a:: with SMTP id b10mr18496851ilh.139.1586796392638; Mon, 13 Apr 2020 09:46:32 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id t86sm3989687ili.82.2020.04.13.09.46.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Apr 2020 09:46:32 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <0852749c-acde-b4b5-eef2-05da36ef1afc@gmail.com> Date: Mon, 13 Apr 2020 12:46:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [calsify] jscalendar and versioning X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 16:46:35 -0000 As I attempt to define and implement mappings I've come to realize that it's a major mistake not to have a jscalendar version embedded in the data model. We spend so much time with 5545 updates worrying about backwards compatibility - even though we tried to make it easier with that spec we still cannot change anything. Adding something is risky enough. The result is we stuck with a 1980s defined data model we hardly dare touch. If we build in versioning from the start we don't have that problem. We still have to support older versions  (to some extent) but at least we know where we are. So - when we have jscalendar widely deployed and we discover we can't add a feature because it means changing something - as we will - we can implement it as a new version of jscalendar. As long as we support the older version things work fine. And assuming that no version means 1.0 isn't enough... From nobody Mon Apr 13 15:27:01 2020 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 BE9773A1F88 for ; Mon, 13 Apr 2020 15:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=WvIHvWfZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BZ3CLAdZ 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 1TX6mX3uKHpF for ; Mon, 13 Apr 2020 15:26:58 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43FB23A1F86 for ; Mon, 13 Apr 2020 15:26:58 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7A6615C0165 for ; Mon, 13 Apr 2020 18:26:57 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Mon, 13 Apr 2020 18:26:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=ufTCeVN V2zjlXvVgZ4Ut6ay+TQ1PfUpH32y0pxUJPrI=; b=WvIHvWfZm6xyukjXzi8lEpG o8+XZJZs9m4uQmmmclCL3c5JanWEc2+UMbPKdKUda3cfp1PhoyKMyV9rMMnCPXub dx1A7FM8evhUF7nbgJReNoA9GLqYqi5d1+XYi04eCCTqXJDO5GSb/5Y0zshS7df6 /0WofK0rv9BgJcaCMiQXSU0noxwuhSfjme4kLiACAFP0tNctSvhzKEgk8PyL0HRt N1Jep7T0Q1Xhlw2Wr7HPULNTMW4zWqKIimH/6t/mDWeAJkB/l3QeR+Af3R6uvP8h YJYUENqd4u4bC6huiGsrd3IRx4G4XzYy78gzzN8K1H4sYE9RpmunBZxnNleY/vQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ufTCeV NV2zjlXvVgZ4Ut6ay+TQ1PfUpH32y0pxUJPrI=; b=BZ3CLAdZWS9aXY/fOqQVIO 4rKCCTNEQMjMm0XfmhQXIJHNmBjiya1n2O8fsCw5cMtFetRyDfy27o+vvhnvZr6w h9CxEJksbhNS3XYKOHwHWuCclvfwW6tTebclaA9afQEISC3hQ9Vnto/9EOJbKU2j yA8e9qWuiwTKhYDvYsd4v5qOVwxjHkEoJM/4uDWAtb6tHN4wc+cfQ5I4JpsuMlPL 5GaAmYDUzWUt8gBr8g69KqneEmfRkluKBGj26DVna4jDmu6cRR65WahzIxFLVtMY PJuDMpZfaInQhb95Gx1LLFCxM+/QnjT4/WxJ2q/NY+v1De4TXmRGlilfLqtRa9GQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfedtgddtfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuvehluhhsthgvrhfuihiivgepudenucfrrg hrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 325FE180091; Mon, 13 Apr 2020 18:26:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1104-g203475c-fmstable-20200408v2 Mime-Version: 1.0 Message-Id: <5e3b90d5-53fe-4a0a-a3f9-1f8bcd60e2da@dogfood.fastmail.com> In-Reply-To: <0852749c-acde-b4b5-eef2-05da36ef1afc@gmail.com> References: <0852749c-acde-b4b5-eef2-05da36ef1afc@gmail.com> Date: Tue, 14 Apr 2020 08:26:04 +1000 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=1c27e2d57e8843a68a0b8ed215bc6630 Archived-At: Subject: Re: [calsify] jscalendar and versioning X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 22:27:00 -0000 --1c27e2d57e8843a68a0b8ed215bc6630 Content-Type: text/plain On Tue, Apr 14, 2020, at 02:46, Michael Douglass wrote: > As I attempt to define and implement mappings I've come to realize that > it's a major mistake not to have a jscalendar version embedded in the > data model. > > We spend so much time with 5545 updates worrying about backwards > compatibility - even though we tried to make it easier with that spec we > still cannot change anything. Adding something is risky enough. The > result is we stuck with a 1980s defined data model we hardly dare touch. > > If we build in versioning from the start we don't have that problem. We > still have to support older versions (to some extent) but at least we > know where we are. > > So - when we have jscalendar widely deployed and we discover we can't > add a feature because it means changing something - as we will - we can > implement it as a new version of jscalendar. As long as we support the > older version things work fine. > > And assuming that no version means 1.0 isn't enough... Should it be '@type': 'text/jscalendar1' and then we can define the additional versions as new types? Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --1c27e2d57e8843a68a0b8ed215bc6630 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, Apr 14, 2020, at 02:46, Michael Douglass wrote:
As I attempt to define and implement mappings I've come to realize = that 
it's a major mista= ke not to have a jscalendar version embedded in the 
data model.

We spend so much= time with 5545 updates worrying about backwards 
compatibility - even though we tried to make i= t easier with that spec we 
still cannot change anything. Adding something is risky enough. The&= nbsp;
result is we stuck with= a 1980s defined data model we hardly dare touch.

If we b= uild in versioning from the start we don't have that problem. We 
still have to support older ve= rsions  (to some extent) but at least we 
know where we are.

So - when we have= jscalendar widely deployed and we discover we can't 
add a feature because it means changing so= mething - as we will - we can 
implement it as a new version of jscalendar. As long as we suppor= t the 
older version thi= ngs work fine.

And assuming that no version means 1.0 isn= 't enough...
Should it be '@type': 'text/jsc= alendar1' and then we can define the additional versions as new types?

Bron.

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


= --1c27e2d57e8843a68a0b8ed215bc6630-- From nobody Mon Apr 13 20:06:36 2020 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 25CB83A08A8 for ; Mon, 13 Apr 2020 20:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=KKo1EWsd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RG9b1hc8 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 XWj6kl-WVoWz for ; Mon, 13 Apr 2020 20:06:33 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91DBA3A08A5 for ; Mon, 13 Apr 2020 20:06:33 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id BA9FA5C00EE for ; Mon, 13 Apr 2020 23:06:32 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 13 Apr 2020 23:06:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=5+VHd/k ZOB8JK+E+FgqOoueaO1lpO6X2dBBmNvPOx6Y=; b=KKo1EWsdFNv0+04sfn704ih YHre6hl4YEh2rlPxZhwfmRXwxY1MzlSBsesLcmZp79IzIKYKEy+a0U74LXoEeQuL 4smRDgSn8YozUQmW1U7SrAorALJwUSMS+ztUh2pZRwNcZQdxC1lMoDYKp6l40oX/ 5Zzeaad5G9ajkA7rrubQMrk3sihIp98MrOZ7p9DbxbervhdSEVkLUhP8U+1AZlAE aX+sCjnymqoKvbG1vMg6b8h9ZKpGAypD8Vuc9SLJrFGSu+J5JtGwP0p7iysntGHE npJHKKUO/hqDsqUS6QWusQecxTieA7lRn7Zc2Xl2/Uerb9qSfnUgQCBeB7lBCMQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=5+VHd/ kZOB8JK+E+FgqOoueaO1lpO6X2dBBmNvPOx6Y=; b=RG9b1hc8bMCjCJQsaILmoS iBYkZLKFpWKI8O2eaOOWUHKQ86VbzOyvnZp5F9A7gnNFd0AKdKZVgMMD8+OFIc5X WP3tZE65EK4EpY6aXYBUgfg4EpEBN3VXlDLwCv7M7gPOvqXkgBdJZ9NqQNIJ2hHo 6mAx6gFown0mvYMpJo4GYrC7+HFWM7uUPFKyxwZWdwmzVr3MsglxpU1ZzetpSrPl 8B6eHv8yZ2UV2F++UhjdXbKGVv6RJ7TQ1Re68W4BnXbKlAtUQFQiCME56BaZBzjq A8j40wFypWiaO4CoJ+3yOC8JpDVIoZKzUTkQH8KN0y3b9J2U/aihiN3ZRqmnACkQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfedtgdeitdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5ECE0180091; Mon, 13 Apr 2020 23:06:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1130-gd0f8b30-fmstable-20200414v1 Mime-Version: 1.0 Message-Id: <64162aa2-c7e2-47c2-868c-5d13e0491655@beta.fastmail.com> In-Reply-To: <0852749c-acde-b4b5-eef2-05da36ef1afc@gmail.com> References: <0852749c-acde-b4b5-eef2-05da36ef1afc@gmail.com> Date: Tue, 14 Apr 2020 13:06:17 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=7041e577ed024d4f84ea82b35549a16a Archived-At: Subject: Re: [calsify] jscalendar and versioning X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 03:06:35 -0000 --7041e577ed024d4f84ea82b35549a16a Content-Type: text/plain On Tue, 14 Apr 2020, at 02:46, Michael Douglass wrote: > As I attempt to define and implement mappings I've come to realize that > it's a major mistake not to have a jscalendar version embedded in the > data model. There are two big issues with adding a version number: 1. It is likely to be "1.0" for quite some time. This means a lot of implementations will just ignore it, causing it to be meaningless should you try to update it. 2. It's a data format not a protocol. In some contexts two parties would be able to negotiate a version, but in others (such as publishing an event more broadly) they would not. I think the existing extension mechanism for adding new properties is sufficient to allow future changes; should you really need to redefine the semantics of an existing property, you would instead define a new one. Up-to-date clients would generate both old and new properties (using the best semantic translation they can to the old one); older clients would ignore the unknown new property and use the old one. Neil. --7041e577ed024d4f84ea82b35549a16a Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, 14 Apr = 2020, at 02:46, Michael Douglass wrote:
As I attempt to define and implement mappings I've com= e to realize that 
it's a major mistake not to have a= jscalendar version embedded in the 
data model.
<= /div>

There are two big issues with addi= ng a version number:
  1. It is likely to be "1.0" for quite= some time. This means a lot of implementations will just ignore it, cau= sing it to be meaningless should you try to update it.
  2. It's = a data format not a protocol. In some contexts two parties would be able= to negotiate a version, but in others (such as publishing an event more= broadly) they would not.
I think the existing extens= ion mechanism for adding new properties is sufficient to allow future ch= anges; should you really need to redefine the semantics of an existing p= roperty, you would instead define a new one. Up-to-date clients would ge= nerate both old and new properties (using the best semantic translation = they can to the old one); older clients would ignore the unknown new pro= perty and use the old one.

Neil.
<= /body> --7041e577ed024d4f84ea82b35549a16a-- From nobody Mon Apr 13 20:24:05 2020 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 C5AC63A0909 for ; Mon, 13 Apr 2020 20:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 8mOPmLgexVnG for ; Mon, 13 Apr 2020 20:24:02 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0: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 18DEB3A0908 for ; Mon, 13 Apr 2020 20:24:02 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id i2so9789608ils.12 for ; Mon, 13 Apr 2020 20:24:02 -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-language; bh=xw0ppQntzSgzJXi8gUn+osPwClnMn8P1e4MSEofy3eg=; b=E+CJX1Oh7EiXaTNYGtGfiZCbedKiziaI+h4YKtPEvrDExnrRY1et2nDEykYqmyrfct X9TSYS0HDuXDlHty1ZNLLIKk4KCEyeDijwdDUbuftNfQJGs4A4i5vImxCCAvp1awAPVO TFHQKV9ixQB3/SYdjdm8B6fFSmmAyXnnma51sVsZJ9j2ITJLRxtXrlPBSqilFT8B0uVJ rNeAv6WQ7Xt5Mfe8OTGc8os8HBOLK9cg+640Z+Jbc49z8nHxLT014hlGUzLmIK1CPikH SA3cpd2VDI2BsRBio+ehNZod2HP+sVc9obvQHFZBKZFjYDKEjulIxxR2UN+PWeHeKR8v YEmw== 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-language; bh=xw0ppQntzSgzJXi8gUn+osPwClnMn8P1e4MSEofy3eg=; b=P4TUH1WzQjK0BYyvthCOVJ8AaOfh58JprK2EB8JjRZENuoHxHP3hq4LD0aJw4gFNcv otL6uWg/R7/dWf+cFpk+JHFc3AVpQmTvkEvKH//mOkXnrTdBEpkUKiDW5USIBsyQZobz kKyB9M1UifPKHIzbCQ2BIcXC4WrIp+vMo9zncFSIXLfvkwi3ImSGXzoFfOUWnIxD57nT vPjuw/+umcrV45rsH/1X3jc8zQq0ZcD9wNBuw2iqNtwCVzrOsRn+7SMxbraFSuLw8RMl 7iXTydnPuTtiBWY1wxNVqFAMzukiUJhKtRYt0Yygx8NTmXCJ5n+0BPySbN9e1yaeGISm OAIQ== X-Gm-Message-State: AGi0PuZ3GcCzzIPZYc/2hbTlla7b92J16LFapfiZC0GApMK+qleismyn WWgn1optq/QTn42jXxUa4tSi0zuF X-Google-Smtp-Source: APiQypLMe+ILYl2i8ebjEinUweFGFfS0rUUm0oMEkVKWMlkl1vvE4oQqotBjVnzLWGFmizFqezRudw== X-Received: by 2002:a05:6e02:f43:: with SMTP id y3mr21555908ilj.112.1586834640998; Mon, 13 Apr 2020 20:24:00 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id h69sm4531293ila.68.2020.04.13.20.24.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Apr 2020 20:24:00 -0700 (PDT) To: calsify@ietf.org References: <0852749c-acde-b4b5-eef2-05da36ef1afc@gmail.com> <64162aa2-c7e2-47c2-868c-5d13e0491655@beta.fastmail.com> From: Michael Douglass Message-ID: <3c126be0-faf1-3a61-09c5-305b74d3debf@gmail.com> Date: Mon, 13 Apr 2020 23:23:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <64162aa2-c7e2-47c2-868c-5d13e0491655@beta.fastmail.com> Content-Type: multipart/alternative; boundary="------------68855FAB9B29CEAE92EE7BF8" Content-Language: en-US Archived-At: Subject: Re: [calsify] jscalendar and versioning X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 03:24:04 -0000 This is a multi-part message in MIME format. --------------68855FAB9B29CEAE92EE7BF8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 4/13/20 23:06, Neil Jenkins wrote: > On Tue, 14 Apr 2020, at 02:46, Michael Douglass wrote: >> As I attempt to define and implement mappings I've come to realize that >> it's a major mistake not to have a jscalendar version embedded in the >> data model. > > There are two big issues with adding a version number: > > 1. It is likely to be "1.0" for quite some time. This means a lot of > implementations will just ignore it, causing it to be meaningless > should you try to update it. > 2. It's a data format not a protocol. In some contexts two parties > would be able to negotiate a version, but in others (such as > publishing an event more broadly) they would not. > > I think the existing extension mechanism for adding new properties is > sufficient to allow future changes; should you really need to redefine > the semantics of an existing property, you would instead define a new > one. Up-to-date clients would generate both old and new properties > (using the best semantic translation they can to the old one); older > clients would ignore the unknown new property and use the old one. Point 1. - It doesn't have to be 1.0 for a long time. It will be if we never change it I guess but we should. Point 2. I understand but in the absence of any useful version number how do I know what the creator of a data item intends? And in the absence of a useful version number what could they negotiate if the opportunity is there? For a simple static download of data sure - you may have to use the earliest version for maximum acceptability - but any protocol can allow for some negotiation. Even a simple GET can use accept. Almost every change we make to iCalendar has involved us in lengthy discussions on whether or not something is backwards compatible - and that's because we never bumped the version making it useless. We've used all the tricks to get around this - we end us defining completely new properties instead of updating old ones. > > Neil. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------68855FAB9B29CEAE92EE7BF8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 4/13/20 23:06, Neil Jenkins wrote:
On Tue, 14 Apr 2020, at 02:46, Michael Douglass wrote:
As I attempt to define and implement mappings I've come to realize that 
it's a major mistake not to have a jscalendar version embedded in the 
data model.

There are two big issues with adding a version number:
  1. It is likely to be "1.0" for quite some time. This means a lot of implementations will just ignore it, causing it to be meaningless should you try to update it.
  2. It's a data format not a protocol. In some contexts two parties would be able to negotiate a version, but in others (such as publishing an event more broadly) they would not.
I think the existing extension mechanism for adding new properties is sufficient to allow future changes; should you really need to redefine the semantics of an existing property, you would instead define a new one. Up-to-date clients would generate both old and new properties (using the best semantic translation they can to the old one); older clients would ignore the unknown new property and use the old one.

Point 1. - It doesn't have to be 1.0 for a long time. It will be if we never change it I guess but we should.

Point 2. I understand but in the absence of any useful version number how do I know what the creator of a data item intends? And in the absence of a useful version number what could they negotiate if the opportunity is there? For a simple static download of data sure - you may have to use the earliest version for maximum acceptability - but any protocol can allow for some negotiation. Even a simple GET can use accept.

Almost every change we make to iCalendar has involved us in lengthy discussions on whether or not something is backwards compatible - and that's because we never bumped the version making it useless. We've used all the tricks to get around this - we end us defining completely new properties instead of updating old ones.



Neil.

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------68855FAB9B29CEAE92EE7BF8-- From nobody Tue Apr 14 09:15:35 2020 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 D92F73A0A67 for ; Tue, 14 Apr 2020 09:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 HvV02sQaKmbF for ; Tue, 14 Apr 2020 09:15:27 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 0BDB93A0B4D for ; Tue, 14 Apr 2020 09:14:31 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id r20so121718pfh.9 for ; Tue, 14 Apr 2020 09:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=c6HLzLV1iYjUBSKEkMnOAOmRnFk26i6DuFnUgXKVWzs=; b=GNO0FGdmMlaJmEikbbNxtYg2kETnkxU4dHOYAk0KFNdioFI0i+gvjyrpe5tlAd8tG7 exyFhmAKKoA7hFL9B40xODfyXikW2Ym8f9nL75jiOmvQecpOeK6b/P4SmKG8clCaZRLQ +1jzyFJrLZMd3nlNUFkl4nj4s5sutvDrIQJRG4A76BtuNJsW8VbKCxBCH9Lhma4Gdqn7 /7Z3LfpLzdDknec0g/6smmhcu9bLgknIAMTUS7Gwiu2VxDViDKVl/3VJKCCM07bKjbxw sOfTmBRXJJlYZLv2stFq04mmmqmaV9yBoe0zTcJQ5GYrgp2utYz3Qfv+4gAjN5wQK29j EsbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=c6HLzLV1iYjUBSKEkMnOAOmRnFk26i6DuFnUgXKVWzs=; b=hIIfiHRPvkJME9gIh2DUOFsv2RczHQm87BVQuudwOSpPO1APZF1tLVnNzEaMISPyrI a9jVnHJfS1ixaipcwxvXPI4Zxqh5TveeMQes5AtGfFzlAYXC3ooCGcrcWp2tk02oaNkR RuEwr7Kx07Yp5vRDhXXztwgl1POpgA3ExlKRXTmHMwx5V9kqRnyn7jXVHBObb+8Dazy6 jwEkhMv/ALwwBZmJ9up93O96ZjsbOusKlYfSSWMHSv6zyAej1IoArsuUkcdWOs6ycUeB TH9sU1wRkMkpjo9ZXb/E9gmojkNWGT+2MnhEFRbLvD1Zq/G/GpejD/n4SMTH3WLIVCTB 0dTQ== X-Gm-Message-State: AGi0Pua3IvucqjFq2Fjb0AB7qgZR2Uor0NT9DH/Fd6i+9rVbFRNU5kKf SM3At20luZlJQ8BINQzUL+BT3ME+tj/Y6so= X-Google-Smtp-Source: APiQypIrKXhtEkzFrr76OsGDfPHqI5n5KhrhAt7SHpDWUuLXT/Ks5ywgW4G0u7B1+FaTcZdzxKsQhg== X-Received: by 2002:a63:5023:: with SMTP id e35mr22114098pgb.165.1586880869901; Tue, 14 Apr 2020 09:14:29 -0700 (PDT) Received: from [192.168.1.7] ([174.27.79.225]) by smtp.googlemail.com with ESMTPSA id g6sm11446721pfr.56.2020.04.14.09.14.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Apr 2020 09:14:28 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <0852749c-acde-b4b5-eef2-05da36ef1afc@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: <1d2aa54f-efc2-17cc-b274-29eaa4942800@gmail.com> Date: Tue, 14 Apr 2020 10:14:27 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <0852749c-acde-b4b5-eef2-05da36ef1afc@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] jscalendar and versioning X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 16:15:33 -0000 On 4/13/20 10:46 AM, Michael Douglass wrote: > As I attempt to define and implement mappings I've come to realize that it's a major mistake not to have a jscalendar version embedded in the data model. > ... > ...> And assuming that no version means 1.0 isn't enough... The 1.0 in VCALENDAR is the version number of the data format. It has not changed. I would suggest that if the jscalendar data format is something that will change over time, that the version of the data model somehow be identifiable to a parser in the data stream. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Tue Apr 14 20:02:05 2020 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 89F293A15C9 for ; Tue, 14 Apr 2020 20:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=HEJ2x4fr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lgO3cVnI 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 4B6por2sgHia for ; Tue, 14 Apr 2020 20:02:02 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5353B3A15C8 for ; Tue, 14 Apr 2020 20:02:02 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 76FE6677 for ; Tue, 14 Apr 2020 23:02:01 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Tue, 14 Apr 2020 23:02:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=A7hdM4U hso5rFpv4z/8WfICid57kmRLFmH9ykVigqAs=; b=HEJ2x4fr1fRZ/EIuZoKAinN TTRe+JJihRlPi96CKKhPUCflqmZueBlDowcL/DjNPc6/ArIzWCWE/jk19JPlmTeQ nJYoOR9knM8nVH5TKAtjVFJPbYW/3z1k8rW1qC4pRKjYJwdhZDeHXfCLXeJYphBn VA4kym7RpNZIvsde1y2SlOb4vIHco/FAQGiZRmtGsJVf7J6K11aSU4lHFw4UTiMw oeYslZPOKqLMBVCFyO/+3GyJuhXJBlw9wKqSlFk7tUioRhvdEEKgBAT1eoNGelUp I0URaYhYEzAvtfIBskCn1IH6kUfIctLqPMtnWosVd9kuqYoEoqtdDPIxwtWHBaQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=A7hdM4 Uhso5rFpv4z/8WfICid57kmRLFmH9ykVigqAs=; b=lgO3cVnI/y9kfCS7ojjFOM jP49fUzBIc3GhW0/PTmBZE76GTfW0s5fZrO7+EQN3p+BSlodv5uO9DgXBUHkJcbB j06xlnObmWM4Y2f6mjoe7TvSWyY6H6tBXkrgb8YMQ3Bk3owASDVSnMQrRfA3F1yO vH+JpV2Tk4WVwoNOHE6sNs7NemTn1b66nlIn/YJQUfDxX2RHDcKAjQtJJti/krXG Fwif+aa0eyz5htO0F87mDYnN3yFIi6ExnHEuS9WkbFMMclrf4G4Fo5iFwzesxVb1 RuWQEqyu31Vh6kRP7F4qGwOgGRc1RF85klZ4VBTzwjIUk/fdIph+7Pw9F9xTrbwQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfedvgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D090E180091; Tue, 14 Apr 2020 23:02:00 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1131-g3221b37-fmstable-20200415v1 Mime-Version: 1.0 Message-Id: <7f791a80-6c27-49fc-b7f3-6a6218f2d17d@beta.fastmail.com> In-Reply-To: <236a87e7-c4af-485f-e839-4bc2a0cbb9ff@gmail.com> References: <236a87e7-c4af-485f-e839-4bc2a0cbb9ff@gmail.com> Date: Wed, 15 Apr 2020 13:02:00 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=b4e52354770c4c23bdc829baa31e9bf9 Archived-At: Subject: Re: [calsify] jscalendar-icalendar mapping - CALSCALE X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 03:02:04 -0000 --b4e52354770c4c23bdc829baa31e9bf9 Content-Type: text/plain On Sun, 12 Apr 2020, at 06:05, Michael Douglass wrote: > I seem to recall that CALSCALE was dropped because only one value is used. > Is that so? Yes. > It's not mentioned anywhere Because it's not relevant to the JSCalendar spec. It's only relevant to the iCalendar <-> JSCalendar conversion document. Neil. --b4e52354770c4c23bdc829baa31e9bf9 Content-Type: text/html
On Sun, 12 Apr 2020, at 06:05, Michael Douglass wrote:
I seem to recall that CALSCALE was dropped because only one value is used.
Is that so?

Yes.

It's not mentioned anywhere

Because it's not relevant to the JSCalendar spec. It's only relevant to the iCalendar <-> JSCalendar conversion document.

Neil.
--b4e52354770c4c23bdc829baa31e9bf9-- From nobody Tue Apr 14 20:31:46 2020 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 D5EC13A1640 for ; Tue, 14 Apr 2020 20:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=WM5KINBG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=czXOWQ7s 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 NwnXseegT4lW for ; Tue, 14 Apr 2020 20:31:44 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937E03A163E for ; Tue, 14 Apr 2020 20:31:44 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B09DB699; Tue, 14 Apr 2020 23:31:43 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Tue, 14 Apr 2020 23:31:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=FjhvKd8 Z4vSke8Vs5mrdu3Eo3kEYRswMXYQaM9BIPLg=; b=WM5KINBGMayZ3odNwqlHp4u 1ay63bGzB0JmSPU8hBUze6GznPyRG0PslUzKWZvbHFU+3D8Z11Q8dn9ckHTNW8G2 zMKyCCx2RE0Vs25lSkeuvAXQArDIS+V/SBRHhtzWLo5Dz0FQHoj942oX2SeYjhOW U8d9W1AENZvoHOSZA3NS2pYAjDIQO+PwqOFIrn/Gm9WbggVIQmKTTcBiLFtwsGjB Zl43154XJ2ElHuv2XEsayo06MC5rdQFi/iA0T2K24SKRyN9ZTMURaCn4KNzepO/I BPljmrfUp7vjsA0Eg3A17HK4Aqc+dq7zSHkfwN845+pV8aVVVBWAmmS8KEnSltg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=FjhvKd 8Z4vSke8Vs5mrdu3Eo3kEYRswMXYQaM9BIPLg=; b=czXOWQ7sNVw8Q++fBT4Lxk 2gDrKnULQaZqsZATEQkfo+mscZ9qtwsrOrbzWy8M0ORyvKViCsL1kt7GUAz8upHz FkNRU37r0zN0OMmCd2BR/p988SsK9pzFDA2of9JCdSGB4Yi0txMEs1/S0HfbC/om jnL9Yc+KQvZk6mr8B+dQaCXGjBD7tlAs6mt2JQrFWFdGyIe7v9hfAaU+rYaI9Abt 2wWt++NHgSGl/LBHLTUwV/g0/daNgQsRGS0z82jGTxviksV7dA3oUeGRpV92Nm9s wxMbqkwh5BUB6ZnvF/IwvNpHSr+iGt03TsmRrDbTVhXFsvSYLrsBIHU4y+RL69cw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfedvgdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhl jhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6A965180091; Tue, 14 Apr 2020 23:31:42 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1131-g3221b37-fmstable-20200415v1 Mime-Version: 1.0 Message-Id: <62b56395-b012-4594-a5fe-baf41c6a79ae@beta.fastmail.com> In-Reply-To: <7e5829d9-d600-4841-8924-00002c9ead54@www.fastmail.com> References: <7e5829d9-d600-4841-8924-00002c9ead54@www.fastmail.com> Date: Wed, 15 Apr 2020 13:31:42 +1000 From: "Neil Jenkins" To: "Robert Stepanek" , "Michael Douglass" , calsify@ietf.org, "Ken Murchison" , "Bron Gondwana" Content-Type: multipart/alternative; boundary=dca37c27f0364b7d9e947d12d33854f3 Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar-26 and mappings to iCalendar X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 03:31:46 -0000 --dca37c27f0364b7d9e947d12d33854f3 Content-Type: text/plain I agree with Robert: this should remain a separate document. Both because the JSCalendar document is basically done and we'd really like to not hold it up further (it's taken forever) but more importantly it makes the document less intimidating for implementers that don't care about iCalendar, as they won't have a huge load of irrelevant (to them) complicated text to ignore. Neil. --dca37c27f0364b7d9e947d12d33854f3 Content-Type: text/html
I agree with Robert: this should remain a separate document. Both because the JSCalendar document is basically done and we'd really like to not hold it up further (it's taken forever) but more importantly it makes the document less intimidating for implementers that don't care about iCalendar, as they won't have a huge load of irrelevant (to them) complicated text to ignore.

Neil.
--dca37c27f0364b7d9e947d12d33854f3-- From nobody Thu Apr 16 16:07:39 2020 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 7F7113A12E7; Thu, 16 Apr 2020 16:07:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158707845735.14170.12045091390504764822@ietfa.amsl.com> Date: Thu, 16 Apr 2020 16:07:37 -0700 Archived-At: Subject: [calsify] Calendaring Extensions (calext) WG Virtual Meeting: 2020-04-21 CHANGED X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 23:07:38 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Calendaring Extensions (calext) Working Group will hold a virtual interim meeting on 2020-04-21 from 14:00 to 15:30 Europe/London (13:00 to 14:30 UTC). Agenda: Specific details TBA closer to the date, however we will be covering existing drafts as well as anything which has come up during first 2 days of the CalConnect meeting: https://www.calconnect.org/events/calconnect-xlvii-april-20-24-2020 Information about remote participation: https://zoom.us/j/4574164360 or dial in by phone, see https://zoom.us/zoomconference for local numbers From nobody Sat Apr 18 23:50:51 2020 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 776B43A1A62 for ; Sat, 18 Apr 2020 23:50:49 -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=[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 YkfsGa3WhQT1 for ; Sat, 18 Apr 2020 23:50:48 -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 400E93A1A61 for ; Sat, 18 Apr 2020 23:50:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E0BEAF40709; Sat, 18 Apr 2020 23:50:46 -0700 (PDT) To: bernard.desruisseaux@oracle.com, superuser@gmail.com, barryleiba@computer.org, lear@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: LarsHenriksen@get2net.dk, calsify@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200419065046.E0BEAF40709@rfc-editor.org> Date: Sat, 18 Apr 2020 23:50:46 -0700 (PDT) Archived-At: Subject: [calsify] [Technical Errata Reported] RFC5545 (6109) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 06:50:49 -0000 The following errata report has been submitted for RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6109 -------------------------------------- Type: Technical Reported by: Lars Henriksen Section: 3.6.1 Original Text ------------- The anniversary type of "VEVENT" can span more than one date (i.e., "DTEND" property value is set to a calendar date after the "DTSTART" property value). Corrected Text -------------- The anniversary type of "VEVENT" can span more than one date (i.e., "DTEND" property value is set to a calendar date at least two days after the "DTSTART" property value). Notes ----- "DTEND" comes, by definition (3.8.2.2), always after "DTSTART". The span (duration) is the difference between the two. 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. -------------------------------------- RFC5545 (draft-ietf-calsify-rfc2445bis-10) -------------------------------------- Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Publication Date : September 2009 Author(s) : B. Desruisseaux, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG From nobody Sun Apr 19 03:42:33 2020 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 59E003A0A99 for ; Sun, 19 Apr 2020 03:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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=googlemail.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 7amnlIK059mL for ; Sun, 19 Apr 2020 03:42:31 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 B5F543A0A54 for ; Sun, 19 Apr 2020 03:42:30 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id u127so6766465wmg.1 for ; Sun, 19 Apr 2020 03:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=lU4xJd15t5eiReLHEsOLk6OYIGKzdHLh/OSE6vxxVYQ=; b=eDiMqXJHNvbuIUzE3SBuO6ChtvR5YBqZHUrwYEHZ2d6zu5gaxHPRo05yZat/9eE7zE IZrTVtgtOHXDDLztc8rlbIBW6KmQ1XlgjuP4NbVkEBdzGp9Uxgn+QvGNqzWdJ5njSSyE BEj+AECKqz3wBzQe9MoT4wQq5RUhhY51NQ7Eu+yaYS2taXaP67A/Hvgfbac8ODVfWGcx ATI9idXomMTAsrycHQ6eeBrdG0fPDJoCLS7LtIM48/SsTeZ3VijcVw1eq0DQ74Vev3nW plW33ttUPdFajhpeLOO0/GfZDWJ6xSFQWsKBp7B0y7mmInxShl1tZxeFwtGmhAQxabbU gkNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=lU4xJd15t5eiReLHEsOLk6OYIGKzdHLh/OSE6vxxVYQ=; b=H48TIZtsbPQkZAC3dkc7xFgdrcn4fISRulTFBeU/aUVqrVN17mxFlj9nx5L2AtK176 3iB22lwrJaX4FMrZXGtI77fFT7e/CZpNoRmCdKclqlVok+U2+4KsxA7Z5EEWUr216i1q 8k3nG/h2t8L6B/jdJhKM3bfufkKsY0rKTcgguCUl7I//aN8gO/v282Sggh8kzvgq7Lub GDfQZOlC7r6b55h/s6rcoyWfrjUzlkKmpMaFWPFpUyAtuT/FXbjzpICAD7sm/IW5tyBu sbJI81CvPmlfgQWxhmDGrd9MA71EaGNu0wglmNEL5kuky6c5mnyPsExPRomMj9jDLx/U ARsg== X-Gm-Message-State: AGi0PuboWpRTDgDRO8dSGkD1wIe8EJIBQI359qephPj/SZpWC8dV1ncU TxsqPWrHuthw6SHbMsXedPk= X-Google-Smtp-Source: APiQypISO81+uhPl6KPaWtyhcJoekjXCZt0qj6aelEY4aIIQSVvMUY25BMzjuQcskipG+ilc4zAK9A== X-Received: by 2002:a1c:f012:: with SMTP id a18mr11895736wmb.41.1587292949080; Sun, 19 Apr 2020 03:42:29 -0700 (PDT) Received: from [192.168.1.107] (ppp-46-244-245-32.dynamic.mnet-online.de. [46.244.245.32]) by smtp.gmail.com with ESMTPSA id a67sm15954485wmc.30.2020.04.19.03.42.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Apr 2020 03:42:28 -0700 (PDT) From: Michael H Deckers X-Google-Original-From: Michael H Deckers To: RFC Errata System , bernard.desruisseaux@oracle.com, superuser@gmail.com, barryleiba@computer.org, lear@cisco.com Cc: calsify@ietf.org, LarsHenriksen@get2net.dk References: <20200419065046.E0BEAF40709@rfc-editor.org> Message-ID: <737e7301-7671-9f1a-2782-62963db8d3c2@googlemail.com> Date: Sun, 19 Apr 2020 10:42:19 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200419065046.E0BEAF40709@rfc-editor.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6109) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 10:42:32 -0000 On 2020-04-19 06:50, RFC Errata System wrote: > The following errata report has been submitted for RFC5545, > "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6109 > > -------------------------------------- > Type: Technical > Reported by: Lars Henriksen > > Section: 3.6.1 > > Original Text > ------------- > The anniversary type of "VEVENT" can span more than one date (i.e., "DTEND" > property value is set to a calendar date after the "DTSTART" property value). > > Corrected Text > -------------- > The anniversary type of "VEVENT" can span more than one date (i.e., "DTEND" > property value is set to a calendar date at least two days after the "DTSTART" > property value). > > Notes > ----- > "DTEND" comes, by definition (3.8.2.2), always after "DTSTART". The span (duration) is the difference between the two.     I find the last sentence of the Note misleading.     The expression          "span more than one date"     does not state the duration of the event -- it     rather is meant to say that the interval contains     a midnight in its interior (at which the date     changes).     Since the DTSTARTs and DTENDs of anniversaries     are DATEs, the length must be at least two days     so that a midnight can be in the interior.     I propose to reword the Note to:        "DTEND" comes, by definition (3.8.2.2), always after "DTSTART".        An event spans two or more dates if it contains a midnight        instant strictly between DTSTART and DTEND. When DTSTART and        DTEND are DATEs then this can happen only if the length        of the event is two days or more.     Michael Deckers. > 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. > > -------------------------------------- > RFC5545 (draft-ietf-calsify-rfc2445bis-10) > -------------------------------------- > Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) > Publication Date : September 2009 > Author(s) : B. Desruisseaux, Ed. > Category : PROPOSED STANDARD > Source : Calendaring and Scheduling Standards Simplification > Area : Applications > Stream : IETF > Verifying Party : IESG > From nobody Sun Apr 19 05:07:46 2020 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 836753A044F for ; Sun, 19 Apr 2020 05:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.7 X-Spam-Level: X-Spam-Status: No, score=-7.7 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 jiFZysL0cLfm for ; Sun, 19 Apr 2020 05:07:42 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49FEA3A044E for ; Sun, 19 Apr 2020 05:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18118; q=dns/txt; s=iport; t=1587298062; x=1588507662; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ObrPMmk5BiJ6bLhxj1PFkxEY1xHPKWNeRH7xHRsAKoo=; b=ZG+RQflQmXvTScpjXlDzjd7dWXStI7Iny2gmk43grLzZchEblm+EG9Ib dDTr/JvqW3QtRS+woFdWdnEKLyMNq1/nxPVp8J9O85kaYsNqsHLpO9Vyb xvJVKNLnAkc2wOleXO8q3teeeL0mQU5SoI78pmBzTb3800NanLmkWq9iC s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAADJPpxe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWcHAQELAYEkWIFtIBIqhB2IImCHZyWZU4F7CgEBAQwBAS8EAQG?= =?us-ascii?q?ERAKCMzQJDgIDAQELAQEFAQEBAgEFBG2FYoVxAQEBAQIBI1YFCwsYKgICVwY?= =?us-ascii?q?TgltLgl0grkF1gTKFT4UkgTgBjFKCAIERJwwQgk0+gQSGXDKCLQSOJIk4ijC?= =?us-ascii?q?PdYJOgmmKP4pDHYJWiE6ESogDhGGpGYM/AgQGBQIVgVI5gVczGggbFWUBgj4?= =?us-ascii?q?+EhgNkXCOMj8DMI9UAQE?= X-IronPort-AV: E=Sophos; i="5.72,403,1580774400"; d="scan'208,217"; a="25394513" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Apr 2020 12:07:23 +0000 Received: from [10.61.239.22] ([10.61.239.22]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 03JC7MDG003361 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Apr 2020 12:07:23 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_54246145-D9F3-46C4-B6D4-61E1B00EB75C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 19 Apr 2020 14:07:22 +0200 In-Reply-To: <20200419065046.E0BEAF40709@rfc-editor.org> Cc: bernard.desruisseaux@oracle.com, superuser@gmail.com, barryleiba@computer.org, LarsHenriksen@get2net.dk, calsify@ietf.org To: RFC Errata System References: <20200419065046.E0BEAF40709@rfc-editor.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.239.22, [10.61.239.22] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6109) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 12:07:44 -0000 --Apple-Mail=_54246145-D9F3-46C4-B6D4-61E1B00EB75C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Lars and Michael Please see below. > On 19 Apr 2020, at 08:50, RFC Errata System = wrote: >=20 > Type: Technical > Reported by: Lars Henriksen >=20 > Section: 3.6.1 >=20 > Original Text > ------------- > The anniversary type of "VEVENT" can span more than one date (i.e., = "DTEND" > property value is set to a calendar date after the "DTSTART" property = value). >=20 > Corrected Text > -------------- > The anniversary type of "VEVENT" can span more than one date (i.e., = "DTEND" > property value is set to a calendar date at least two days after the = "DTSTART" > property value). >=20 > Notes > ----- > "DTEND" comes, by definition (3.8.2.2), always after "DTSTART". The = span (duration) is the difference between the two. It is important to review the wider context of this text: The "VEVENT" is also the calendar component used to specify an anniversary or daily reminder within a calendar. These events have a DATE value type for the "DTSTART" property instead of the default value type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it MUST be specified as a DATE value also. The anniversary type of "VEVENT" can span more than one date (i.e., "DTEND" property value is set to a calendar date after the "DTSTART" property value). If such a "VEVENT" has a "DURATION" property, it MUST be specified as a "dur-day" or "dur-week" value. What this says to me is that DTSTART and DTEND MUST use DATE values and = that DTEND value MAY be greater than that of DTSTART, but it doesn=E2=80=99= t have to be with regard to VEVENT. This situation is a little = different with VFREEBUSY. The text in Section 3.8.2.2 states the = following: Property Name: DTEND Purpose: This property specifies the date and time that a calendar component ends. Value Type: The default value type is DATE-TIME. The value type can be set to a DATE value type. Property Parameters: IANA, non-standard, value data type, and time zone identifier property parameters can be specified on this property. Conformance: This property can be specified in "VEVENT" or "VFREEBUSY" calendar components. Description: Within the "VEVENT" calendar component, this property defines the date and time by which the event ends. The value type of this property MUST be the same as the "DTSTART" property, and its value MUST be later in time than the value of the "DTSTART" property. Furthermore, this property MUST be specified as a date with local time if and only if the "DTSTART" property is also specified as a date with local time. Within the "VFREEBUSY" calendar component, this property defines the end date and time for the free or busy time information. The time MUST be specified in the UTC time format. The value MUST be later in time than the value of the "DTSTART" property. What is clear is that a VEVENT may include a DATE in both DTSTART and = DTEND, and that the value MAY be the same. What is LESS clear is = whether a VFREEBUSY can include a date. The grammar for DTSTART and = DTEND makes clear that either DATE or DATE-TIME may be specified, but = the text in Section 3.6.2 is also prescriptive, where as the text in = Section 3.6.4 on VFREEBUSY is not quite so clear. I would suggest that if there is an erratum here, then it is in either = Section 3.6.4 or in 3.8.2.2 in which it should be made clear whether = DATE can be used with DTSTART/DTEND in a VFREEBUSY clause. For certain, = if a DATE value is used, my view is that the DTSTART and DTEND values = MAY be the same, and that the emboldened text above would be erroneous. Eliot =20= --Apple-Mail=_54246145-D9F3-46C4-B6D4-61E1B00EB75C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Lars and Michael

Please see below.

On 19 Apr 2020, at 08:50, RFC = Errata System <rfc-editor@rfc-editor.org> wrote:

Type: Technical
Reported by: Lars Henriksen <LarsHenriksen@get2net.dk>

Section: 3.6.1

Original Text
-------------
The anniversary type of "VEVENT" = can span more than one date (i.e., "DTEND"
property value = is set to a calendar date after the "DTSTART" property value).

Corrected Text
--------------
The anniversary type of "VEVENT" can span more than one date = (i.e., "DTEND"
property value is set to a calendar date at = least two days after the "DTSTART"
property value).

Notes
-----
"DTEND" = comes, by definition (3.8.2.2), always after "DTSTART". The span = (duration) is the difference between the two.


It is important to = review the wider context of this text:


  =     The "VEVENT" is also the calendar component used to = specify an
      anniversary or daily reminder within a = calendar.  These events
      have a DATE value = type for the "DTSTART" property instead of the
  =     default value type of DATE-TIME.  If such a "VEVENT" = has a "DTEND"
      property, it MUST be specified as a DATE = value also.  The
      anniversary type of = "VEVENT" can span more than one date (i.e.,
  =     "DTEND" property value is set to a calendar date after = the
      "DTSTART" property value).  If such = a "VEVENT" has a "DURATION"
      property, it MUST = be specified as a "dur-day" or "dur-week" value.


What this says to me is that = DTSTART and DTEND  MUST use DATE values and that DTEND value MAY be = greater than that of DTSTART, but it doesn=E2=80=99t have to be with regard to VEVENT.  This situation is a little = different with VFREEBUSY.  The text in Section 3.8.2.2 states the = following:

   Property Name:  DTEND

   Purpose:  This property specifies the date = and time that a calendar
  =     component ends.

   Value Type:  The default value type is = DATE-TIME.  The value type can
      be set to a DATE value = type.

   Property Parameters:  IANA, non-standard, = value data type, and time
  =     zone identifier property parameters can be specified on = this
      = property.

   Conformance:  This = property can be specified in "VEVENT" or
      "VFREEBUSY" = calendar components.

   Description:  Within = the "VEVENT" calendar component, this property
  =     defines the date and time by which the event ends.  = The value type
      of this property MUST be the same as the = "DTSTART" property, and
      its value MUST be = later in time than the value of the "DTSTART"
  =     property.  Furthermore, this property MUST be = specified as a date
      with local time if and only if the = "DTSTART" property is also
      specified as a date = with local time.

  =     Within the "VFREEBUSY" calendar component, this property = defines
      the end date and time for the free or = busy time information.  The
      time MUST be = specified in the UTC time format.  The value MUST = be
      later in time than the = value of the "DTSTART" property.

What is clear is = that a VEVENT may include a DATE in both DTSTART and DTEND, and that the = value MAY be the same.  What is LESS clear = is whether a VFREEBUSY can include a date.  The grammar for DTSTART = and DTEND makes clear that either DATE or DATE-TIME may be specified, = but the text in Section 3.6.2 is also prescriptive, where as the text in = Section 3.6.4 on VFREEBUSY is not quite so clear.
I would suggest that if there is an = erratum here, then it is in either Section 3.6.4 or in 3.8.2.2 in which = it should be made clear whether DATE can be used with DTSTART/DTEND in a = VFREEBUSY clause.  For certain, if a DATE value is used, my view is that the DTSTART and DTEND = values MAY be the same, and that the emboldened text above would be = erroneous.

Eliot



 
= --Apple-Mail=_54246145-D9F3-46C4-B6D4-61E1B00EB75C-- From nobody Sun Apr 19 05:59:06 2020 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 195BF3A087E for ; Sun, 19 Apr 2020 05:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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=googlemail.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 oFTzwqqISqru for ; Sun, 19 Apr 2020 05:59:03 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 AC12F3A087C for ; Sun, 19 Apr 2020 05:59:03 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id k11so8612758wrp.5 for ; Sun, 19 Apr 2020 05:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=JmwzCO8Hmy7dPLhwN5l3S335ECTBj/r4jQhwbvCZQVU=; b=uXAsP2VOMMACFdLbC8BET5npD6GTvXcmiDpzVfZIekPyshFUl5Lqk+O/YSee01YMFO h3DKOm723GSoSUFINoJ3FASN1x3g3xDc3dMhH6MBhg47j9/XLcIZJjl19YO95WLeiDZY hIkcVp5xEhzEhVLBfENGOULo3xxL6xWZhAO0TSG4fgHcIUIYl6ZtKFRG29LPYi2bL7VE fcWA+AdJO38rfnuTxLpphkOqW/Xo6dsLOgCR3hNKDwPa4ze/oX2TMaiPaNIxS00Yf/ze U8Mr99MI0mAsJZFLlJJLpFrsEbcxqEdlDlugP8NmVuo01myVyb94IkRA1I35VyrtG+bS Yb6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=JmwzCO8Hmy7dPLhwN5l3S335ECTBj/r4jQhwbvCZQVU=; b=ufYtK7jkCCC7JWyRb3kDWRCZUr950qhigq/U90Ae+DkgXP+vzM+jaD/5T21c2aeM8n vbRZBzzy8mVvycc4dLtS2mXZOodM8L8XAoTwyFyBDei0qgBA9bmzmMh/iCZmLQSCXHcB WpXshPNgdxLqjqZu5aJim1BmczvJZsWzGokjH5fOi+nPhJrEFyAF58dn+fNu5HYXCSpS xKuB+XdnAQS0y9txCZaPdLxsGBKCbt+5f/Fx1sKV8nBnLdUTLuQ/EdOQh0rT0EY1ALzn dL5mMOSI7RhzHgSBRc2+RlOcgBOUU/Q/BMQoy+JF+f2bvW0/MW0cmxqFP71knrZbXEoL i/bg== X-Gm-Message-State: AGi0PuZsnlmTLoeaAcVkeELU1JKJx0ic4mqKGwUra7MkIcFnRDnccRLT HyDbQLGHv2GXn3wbGyvU54M= X-Google-Smtp-Source: APiQypK/l0DMxBNhUfWyw1VMimtbqTzQaHYe7QgL+dkrWve+uU9iuFsJJgZXxvsihrPZUWJeMiMswg== X-Received: by 2002:adf:ee0c:: with SMTP id y12mr14779796wrn.0.1587301142038; Sun, 19 Apr 2020 05:59:02 -0700 (PDT) Received: from [192.168.1.107] (ppp-46-244-245-32.dynamic.mnet-online.de. [46.244.245.32]) by smtp.gmail.com with ESMTPSA id a205sm15449412wmh.29.2020.04.19.05.59.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Apr 2020 05:59:01 -0700 (PDT) From: Michael H Deckers X-Google-Original-From: Michael H Deckers To: Eliot Lear , RFC Errata System Cc: calsify@ietf.org, barryleiba@computer.org, superuser@gmail.com, LarsHenriksen@get2net.dk References: <20200419065046.E0BEAF40709@rfc-editor.org> Message-ID: Date: Sun, 19 Apr 2020 12:58:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6109) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 12:59:05 -0000    On 2020-04-19 12:07, Eliot Lear wrote: > It is important to review the wider context of this text: > > > The "VEVENT" is also the calendar component used to specify an > anniversary or daily reminder within a calendar. These events > have a DATE value type for the "DTSTART" property instead of the > default value type of DATE-TIME. If such a "VEVENT" has a "DTEND" > property, it MUST be specified as a DATE value also. The > anniversary type of "VEVENT" can span more than one date (i.e., > "DTEND" property value is set to a calendar date after the > "DTSTART" property value). If such a "VEVENT" has a "DURATION" > property, it MUST be specified as a "dur-day" or "dur-week" value. > > > What this says to me is that DTSTART and DTEND MUST use DATE values and that DTEND value MAY be greater than that of DTSTART, but it doesn’t have to be with regard to VEVENT. ..[snip]    In my opinion, a DTEND value can _never_ be the same    as a DTSTART value, by:        3.8.2.2. Date-Time End        ...        Description: Within the "VEVENT" calendar component, this property        defines the date and time by which the event ends. The value type        of this property MUST be the same as the "DTSTART" property, and        its value MUST be later in time than the value of the "DTSTART"            ^^^^^^^^^^^^^^^^^^^^^^^^^^^        property.    This applies to all DTENDs within a VEVENT, and the same text is    used in the next paragraph for DTENDs within VFREEBUSY. I do not    see that anniversaries or daily reminders (being VEVENTs) take    exception to this MUST rule.    Regards    Michael Deckers. From nobody Sun Apr 19 06:24:20 2020 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 246663A090C for ; Sun, 19 Apr 2020 06:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 bO6biuzkq-LS for ; Sun, 19 Apr 2020 06:24:15 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3302E3A090B for ; Sun, 19 Apr 2020 06:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=980; q=dns/txt; s=iport; t=1587302655; x=1588512255; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=3QF1E1Z4gtkQeeg30ZWJLemKBJqq7LVwZn1UFpeefSs=; b=KKuLZIuoGBEA8d6ztDhz4QAjfOat4K91eBoxEDdQ1UR/zpy0vno4ow/k 6Q/NVUubnUtVjQv4jUN/0YbfSLQ8hccspB+XezptmaXNDBDnsHiMRCN/s 0960KOCvJgihbvXyNQtxQqvfx0qItQ4kL8IVXrTt8nrccaEWN/e8zgt7T c=; X-IPAS-Result: =?us-ascii?q?A0AmAAA0UJxe/xbLJq1mHAEBAQEBBwEBEQEEBAEBgWcHA?= =?us-ascii?q?QELAYF8gW0gEoRHiCJgh2clmVOBewcDAQEBDAEBLwQBAYREAoIzNAkOAgMBA?= =?us-ascii?q?QEDAgMBAQEBBQEBAQIBBQRthWKFcgEEASNWEAsaAiYCAlcGgm5Lgl0grWkBT?= =?us-ascii?q?HWBMopxN1cqAYxSggCBEScMEIJNPoEEg0qDEjKCLQSyAYJOgmmVAh2Pboxkq?= =?us-ascii?q?RmDPwIEBgUCFYFSOYFXMxoIGxVlAYI/PRIYDZFwjjI/A5AEAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.72,403,1580774400"; d="scan'208";a="23133131" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Apr 2020 13:24:13 +0000 Received: from [10.61.239.22] ([10.61.239.22]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 03JDOCjK028618 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Apr 2020 13:24:12 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: Date: Sun, 19 Apr 2020 15:24:12 +0200 Cc: Eliot Lear , RFC Errata System , barryleiba@computer.org, superuser@gmail.com, calsify@ietf.org, LarsHenriksen@get2net.dk Content-Transfer-Encoding: quoted-printable Message-Id: <83ACDE3F-8348-4AF9-B157-742E79E8D19C@cisco.com> References: <20200419065046.E0BEAF40709@rfc-editor.org> To: Michael H Deckers X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.239.22, [10.61.239.22] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6109) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 13:24:18 -0000 Hi Michael >=20 > In my opinion, a DTEND value can _never_ be the same > as a DTSTART value, by: >=20 > 3.8.2.2. Date-Time End > ... > Description: Within the "VEVENT" calendar component, this = property > defines the date and time by which the event ends. The value = type > of this property MUST be the same as the "DTSTART" property, = and > its value MUST be later in time than the value of the "DTSTART" > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > property. >=20 > This applies to all DTENDs within a VEVENT, and the same text is > used in the next paragraph for DTENDs within VFREEBUSY. I do not > see that anniversaries or daily reminders (being VEVENTs) take > exception to this MUST rule. If this is the case, then how would you express the holiday =E2=80=9CNew = Year=E2=80=99s Day=E2=80=9D such that it applies to everyone in their = respective wall clock times? Eliot= From nobody Sun Apr 19 06:24:47 2020 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 107C33A090D for ; Sun, 19 Apr 2020 06:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=SJ22Jev9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NyzLQCHy 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 igM93VuoSkwV for ; Sun, 19 Apr 2020 06:24:42 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7D63A090A for ; Sun, 19 Apr 2020 06:24:42 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 344B9489 for ; Sun, 19 Apr 2020 09:24:42 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Sun, 19 Apr 2020 09:24:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=KLXs60w hAZsquI8feQTclRe0H+PdweE2WZ0/l+MB2A0=; b=SJ22Jev9OchXP993J+3+MNe nHFpDjNllKa19EduSM2Q/wTlDLq8w77oIAmN8jywUeNsjyGbAAnOE8nzvMNYiYsX JQZSzBrhjPz2vCjs3irE8sJJLisV5OqvTzzinmKUlb7alKBTEpgTqslkCjC1q8Kv QzmxaW61sl5BMnaZD4uEX4JX9Pj79qrnU9YAAjTKgon03yPg/tSorP2tia1GHNa2 GmXwXKwWliXU3h8i3sy3Yt9KXwS0DIWECD2Q5zy0aQdPzQuPacUKoFtZAec1tH7T xX3+xQ4mlDd5LzHxo7XRciE8E+uybY5fpDz6KNLXAFW0GAN3QMR1rrEPthFNwUA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=KLXs60 whAZsquI8feQTclRe0H+PdweE2WZ0/l+MB2A0=; b=NyzLQCHyJijchgK9tcUoLU xgGwemC4/yEwxZSTpWwcPoj9oOLNcVMvF0UtjhoTxYE0tKgjLbmHbMMuU0UkSqsm HOHULgcn/qS5LQv7wLtizrctw3cD3DOY2ycw18YktSwHsMZDBYlVJnCuQFsD1l38 oN2WX2wm1Vi6fWHR6dw/diq3EsPd/h52mqxreIoW+cop/5rS6LjUwgF2jeRGFO1v uleYbpli7tfP+/mzZn9gFEDIKVjELHJv3KGT1qsYrUhMA4hDVxpND4Wl7MuxLV7q 52u9YAmRDhFICN++b8sto4fu6I3wojAyuhKFhQBbexWNfbXBVDm8X+ujQ8M+NrQw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgedugdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7F5B2180091; Sun, 19 Apr 2020 09:24:41 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1131-g3221b37-fmstable-20200415v1 Mime-Version: 1.0 Message-Id: <01ada2b6-4e2d-4098-a605-9ced8005b2b1@dogfood.fastmail.com> In-Reply-To: References: <20200419065046.E0BEAF40709@rfc-editor.org> Date: Sun, 19 Apr 2020 23:24:11 +1000 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=238cc7a929b247e7a3498c245d252210 Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6109) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 13:24:45 -0000 --238cc7a929b247e7a3498c245d252210 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sun, Apr 19, 2020, at 22:58, Michael H Deckers wrote: > On 2020-04-19 12:07, Eliot Lear wrote: > > It is important to review the wider context of this text: > > > > > > The "VEVENT" is also the calendar component used to specify an > > anniversary or daily reminder within a calendar. These events > > have a DATE value type for the "DTSTART" property instead of the > > default value type of DATE-TIME. If such a "VEVENT" has a "DTEND" > > property, it MUST be specified as a DATE value also. The > > anniversary type of "VEVENT" can span more than one date (i.e., > > "DTEND" property value is set to a calendar date after the > > "DTSTART" property value). If such a "VEVENT" has a "DURATION" > > property, it MUST be specified as a "dur-day" or "dur-week" value. > > > > > > What this says to me is that DTSTART and DTEND MUST use DATE values = and that DTEND value MAY be greater than that of DTSTART, but it doesn=E2= =80=99t have to be with regard to VEVENT. ..[snip] >=20 >=20 > In my opinion, a DTEND value can _never_ be the same > as a DTSTART value, by: >=20 > 3.8.2.2. Date-Time End > ... > Description: Within the "VEVENT" calendar component, this property > defines the date and time by which the event ends. The value type > of this property MUST be the same as the "DTSTART" property, and > its value MUST be later in time than the value of the "DTSTART" > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > property. >=20 > This applies to all DTENDs within a VEVENT, and the same text is > used in the next paragraph for DTENDs within VFREEBUSY. I do not > see that anniversaries or daily reminders (being VEVENTs) take > exception to this MUST rule. DTEND is so much worse than DURATION for many reasons, and this mess is = one of them. We see enough events with DTEND before DTSTART in the real = world, let alone zero-length events (though the 10-year-long event which= recurred every day was one of the more impressive horror shows to cause= discomfort in the recurrence expansion code). Sadly as with any "MUST" on an archival data format, there are really tw= o choices when you receive one of these - treat it as malformed and reje= ct it, or try to make sense of it. We make sense of backwards DTEND and = DTSTART by switching them - and handle zero length events as occurring a= t the moment - because that generally makes the user happier than an err= or message. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --238cc7a929b247e7a3498c245d252210 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Sun, Apr 19, 2020, at 22:58, Michael H Deckers wrote:
   On 2020-04-19 12:07, Eliot Lear wrote:
> It is important to review the wider co= ntext of this text:
>
<= /div>
>
>        The "VEVEN= T" is also the calendar component used to specify an
>        a= nniversary or daily reminder within a calendar.  These events
>     =    have a DATE value type for the "DTSTART" property instead o= f the
>   &= nbsp;    default value type of DATE-TIME.  If such a= "VEVENT" has a "DTEND"
>&= nbsp;       property, it MUST be specified= as a DATE value also.  The
>        anniversary type of "= VEVENT" can span more than one date (i.e.,
>        "DTEND" pro= perty value is set to a calendar date after the
>        "DTSTA= RT" property value).  If such a "VEVENT" has a "DURATION"
=
>     &nbs= p;  property, it MUST be specified as a "dur-day" or "dur-week" val= ue.
>
>
>= ; What this says to me is that DTSTART and DTEND  MUST use DATE val= ues and that DTEND value MAY be greater than that of DTSTART, but it doe= sn=E2=80=99t have to be with regard to VEVENT. ..[snip]

<= br>
   In my opinion, a= DTEND value can _never_ be the same
   as a DTSTART value, by:

  =      3.8.2.2. Date-Time End
       ...
       Desc= ription: Within the "VEVENT" calendar component, this property
=
       d= efines the date and time by which the event ends. The value type
      = of this property MUST be the same as the "DTSTART" property, and
      = ; its value MUST be later in time than the value of the "DTSTART"
      = ;     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
       property.<= br>

   This applies to all DTENDs within a VEVENT, = and the same text is
 &n= bsp; used in the next paragraph for DTENDs within VFREEBUSY. I do not
   see that anniversa= ries or daily reminders (being VEVENTs) take
   exception to this MUST rule.

DTEND is so much worse than DURATION for many reasons, and= this mess is one of them.  We see enough events with DTEND before = DTSTART in the real world, let alone zero-length events (though the 10-y= ear-long event which recurred every day was one of the more impressive h= orror shows to cause discomfort in the recurrence expansion code).

Sadly as with any "MUST" on an archival data format, there are= really two choices when you receive one of these - treat it as malforme= d and reject it, or try to make sense of it.  We make sense of back= wards DTEND and DTSTART by switching them - and handle zero length event= s as occurring at the moment - because that generally makes the user hap= pier than an error message.
<= br>
Bron.


--
  Bron Gondwana, CE= O, Fastmail Pty Ltd
  brong@fastmailteam.com


--238cc7a929b247e7a3498c245d252210-- From nobody Sun Apr 19 07:24:00 2020 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 7EB3A3A0A82 for ; Sun, 19 Apr 2020 07:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 947qRgIaCfUO for ; Sun, 19 Apr 2020 07:23:57 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13E43A0A80 for ; Sun, 19 Apr 2020 07:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=274; q=dns/txt; s=iport; t=1587306237; x=1588515837; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ixPzaBjM9/Y+hXz2+VubYiW98Xdh+54VUwXSR3D8aaw=; b=JstcGG2MD8XZ5zuZB2N+fec2FslgQyT0IcqhTDjE+YyCHLz6rGwIqFlz xq5gkib1oYFXIFeRCJeNGAwWxXj9LyiKZyy6sc4xkiNTNF5kegrftJ3F7 xUYzDtJcgUBRIrsns6FLlAA8BK6xofRp4NNNu+d7YqmoO7ofVPrHvxatS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DpAgCbXpxe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuDaiASjUmHZpAki08KAQEBDAEBLwQBAYREAoIzOBMCAwEBCwE?= =?us-ascii?q?BBQEBAQIBBQRthWKFcgY6PxALRlcGgzmCfa4sgieFT4UUgTiMU4IAgTgMEIJ?= =?us-ascii?q?NPoEEg0qDRIItBLIBgk6CaZUCHYJFAY0ojGSpGYM/AgQGBQIVgWkigVczGgg?= =?us-ascii?q?bFWUBgj89EhgNkXCOMj8DkAQBAQ?= X-IronPort-AV: E=Sophos;i="5.72,403,1580774400"; d="scan'208";a="25396137" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Apr 2020 14:23:55 +0000 Received: from [10.61.239.22] ([10.61.239.22]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 03JENrcw000368 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Apr 2020 14:23:54 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <01ada2b6-4e2d-4098-a605-9ced8005b2b1@dogfood.fastmail.com> Date: Sun, 19 Apr 2020 16:23:53 +0200 Cc: calsify@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <34A5C454-D29F-4466-8A00-90ABF0010DD3@cisco.com> References: <20200419065046.E0BEAF40709@rfc-editor.org> <01ada2b6-4e2d-4098-a605-9ced8005b2b1@dogfood.fastmail.com> To: Bron Gondwana X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.239.22, [10.61.239.22] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6109) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 14:23:59 -0000 Hi Bron, Lots of horror stories. So long as a DATE is taken to mean = DDDDDDDDT000000, and that events begin on that moment and end the second = before that moment, then the text is okay. This is how I believe Apple = interprets it and I think is common. Eliot= From nobody Sun Apr 19 07:26:50 2020 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 4C56B3A0A93 for ; Sun, 19 Apr 2020 07:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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=googlemail.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 62VxGqvLaNl8 for ; Sun, 19 Apr 2020 07:26:47 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 F10423A0A92 for ; Sun, 19 Apr 2020 07:26:46 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id k1so8792056wrx.4 for ; Sun, 19 Apr 2020 07:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Us0Y4h0HdwHWN/BVT0FnyAeGDMpco/h+gcOxJHxObCY=; b=vVq1pKQhEfj0P2Mv0TfEbJ2hufCFUl08w4ZJAe9FeluVa6lyA3EcKXf9vSiamF9s+A xY0PpA4nvhLwKmfU5mBCSDm0Ps/adM5tpHcH6SfwFnQkoaQ2mI/2GBv0jY9ouzQTQ+YT 44tjbn8kYGKHlcjyDa0vXU53tR7Ulkb9TwuzxWLU+/CIK9sZrt0683wg+DvSUy6LM0z6 KSBJ/83amRWN6CJCpohRQxqLjKkxOwJ7MWZkwzlwRMKVNbAgmBDlHDK8M035i4VhN9m0 F0STeMveLhqnAQ6I/SX/1ejV9+6Myb8v5+OvUAIj/NhNrwyw8NjulB0jq1sQzyqdCMzz o4lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Us0Y4h0HdwHWN/BVT0FnyAeGDMpco/h+gcOxJHxObCY=; b=sCLHw9I/XtsY17j/PRuImCvzRBmfxo2JQCtbSn26l48Z86ouM7pdC89CQWNfK3R7UJ 1leu2eA8pkjncE1HZXqq5QMFymiSoiA4wwPx5O6LFH/wvRsBFDhst1kaqQrHmo9cwolF 52nTiryULxLET5MC2L2J/7IwoCbmCUuGAuqBu5/X9CCwELR3FBP4IXcGRSvBkb4NNwLD U2KgWTx1LcKdJbBWUbp2eUPmqlkrLBr8o4JfCj15D/a3sP6+ERSXMZxf20sjX4BILTGR yr6JimQL5fTFUVQYh1o3AUK48z6uvVL/51kVoKdOe5t3g3lk53bQ3mP0dk3dlW+PSlan OgcQ== X-Gm-Message-State: AGi0Pubt39LyIbMJK39Rs/rKlbj1zgezSqsDmn269uujNNQFyHXVy3nC y+FwFLxYTj/QfQwhEvMNW9k= X-Google-Smtp-Source: APiQypI4Gn/IomZEea80dvDM2Fg2fm+VpzZpEchKyqaegAwuTS5rnRG+NHfzyYTljU8xA4Qa9ZYAdg== X-Received: by 2002:adf:a3d5:: with SMTP id m21mr14115695wrb.54.1587306404330; Sun, 19 Apr 2020 07:26:44 -0700 (PDT) Received: from [192.168.1.107] (ppp-46-244-245-32.dynamic.mnet-online.de. [46.244.245.32]) by smtp.gmail.com with ESMTPSA id i13sm34771392wro.50.2020.04.19.07.26.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Apr 2020 07:26:43 -0700 (PDT) From: Michael H Deckers X-Google-Original-From: Michael H Deckers To: Eliot Lear Cc: Eliot Lear , RFC Errata System , barryleiba@computer.org, superuser@gmail.com, calsify@ietf.org, LarsHenriksen@get2net.dk References: <20200419065046.E0BEAF40709@rfc-editor.org> <83ACDE3F-8348-4AF9-B157-742E79E8D19C@cisco.com> Message-ID: <6c8e9f84-c171-c4ac-95ad-099d5a67d8f6@googlemail.com> Date: Sun, 19 Apr 2020 14:26:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <83ACDE3F-8348-4AF9-B157-742E79E8D19C@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] [notation of 1 d events] RFC5545 (6109) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 14:26:48 -0000    On 2020-04-19 13:24, Eliot Lear asked,    under the condition that DTEND values must    always be after the corresponding DTSTART values: > If this is the case, then how would you express the holiday “New Year’s Day” such that it applies to everyone in their respective wall clock times?    [This is no longer related with the original question.]    It suffices to give the DTSTART value as a DATE without any    DTEND or DURATION since the default duration is 1 d in this    case ([3.6.1 Event component, p 54]); but one can also give    explicitly either the DURATION value "P1D" or the "non-inclusive"    DTEND value such as "2020-01-02".    Michael Deckers. From nobody Sun Apr 19 11:18:06 2020 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 D5AE93A0EDA for ; Sun, 19 Apr 2020 11:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=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 4G3fLdSAEw_E for ; Sun, 19 Apr 2020 11:18:02 -0700 (PDT) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (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 2D2B23A0EE3 for ; Sun, 19 Apr 2020 11:18:01 -0700 (PDT) Received: by mail-io1-f44.google.com with SMTP id u11so8375881iow.4 for ; Sun, 19 Apr 2020 11:18:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0OwdDAw5BkqT4KJFtuhkCVK7U9fZLdrVma5HKysTRb0=; b=jqxFRo9PKbFb+BldmuPV9ZbKVYq1rW/R7ryk3jsNe7jM8quGQhMV/WKPTFV90+xENh +OVJnDZgGZFez3uSDXganw/KmTaHT79vXp4LKyb51PjDlYENK/fbDFgQwfOMN2V3cTaN IGtII/PSxf+FXXSAInZOIz0NHx6Z8IS8F1a5EmwCZXQldwcHxUovgMA6nmwqOJi1Qjw/ sCDJua/3VTvROyc35tMaGa9DWzC8As/dKUGCg1fIwA5CUGIJU1Q0vXk118tD7Wu71InQ 4fRSjDRClTsj+ZqGbG4wMmbddNb+/WFI4eo0w3D9+Ia/bT86m2BDAkQW9hQokrS7kWLN oSPQ== X-Gm-Message-State: AGi0PuYZcWvBGoK4jA7eUfaQyrcP8vMYh5gL3ctU41ka8kt2KeNNOOOg sViiZaEYSICsV7OHjb1pyEJysnwt2T6ycUxOMI4= X-Google-Smtp-Source: APiQypIJ1ECI9VL2tTCzt49p9bycuyQkWyZ7XmbSz8PyXYt8y7ry6Ap0d+8IcFYOk/QkCPLjRUovQobLckHRnN4EDhM= X-Received: by 2002:a5e:df06:: with SMTP id f6mr12266316ioq.177.1587320280975; Sun, 19 Apr 2020 11:18:00 -0700 (PDT) MIME-Version: 1.0 References: <20200419065046.E0BEAF40709@rfc-editor.org> In-Reply-To: From: Barry Leiba Date: Sun, 19 Apr 2020 14:17:50 -0400 Message-ID: To: Eliot Lear Cc: RFC Errata System , Bernard Desruisseaux , Murray Kucherawy , LarsHenriksen@get2net.dk, calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6109) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 18:18:05 -0000 It strikes me that this is not an erratum, and that the report is a request for an update, rather than a report of an actual editing error at the time of publication. My inclination is to mark it "Rejected", though I can be convinced that "Held for Document Update" is the right answer, based on the discussion. Bernard and Eliot, do you think HFDU is appropriate here? Barry On Sun, Apr 19, 2020 at 8:07 AM Eliot Lear wrote: > > Hi Lars and Michael > > Please see below. > > On 19 Apr 2020, at 08:50, RFC Errata System w= rote: > > Type: Technical > Reported by: Lars Henriksen > > Section: 3.6.1 > > Original Text > ------------- > The anniversary type of "VEVENT" can span more than one date (i.e., "DTEN= D" > property value is set to a calendar date after the "DTSTART" property val= ue). > > Corrected Text > -------------- > The anniversary type of "VEVENT" can span more than one date (i.e., "DTEN= D" > property value is set to a calendar date at least two days after the "DTS= TART" > property value). > > Notes > ----- > "DTEND" comes, by definition (3.8.2.2), always after "DTSTART". The span = (duration) is the difference between the two. > > > > It is important to review the wider context of this text: > > > The "VEVENT" is also the calendar component used to specify an > anniversary or daily reminder within a calendar. These events > have a DATE value type for the "DTSTART" property instead of the > default value type of DATE-TIME. If such a "VEVENT" has a "DTEND" > property, it MUST be specified as a DATE value also. The > anniversary type of "VEVENT" can span more than one date (i.e., > "DTEND" property value is set to a calendar date after the > "DTSTART" property value). If such a "VEVENT" has a "DURATION" > property, it MUST be specified as a "dur-day" or "dur-week" value. > > > What this says to me is that DTSTART and DTEND MUST use DATE values and = that DTEND value MAY be greater than that of DTSTART, but it doesn=E2=80=99= t have to be with regard to VEVENT. This situation is a little different w= ith VFREEBUSY. The text in Section 3.8.2.2 states the following: > > Property Name: DTEND > > Purpose: This property specifies the date and time that a calendar > component ends. > > Value Type: The default value type is DATE-TIME. The value type can > be set to a DATE value type. > > Property Parameters: IANA, non-standard, value data type, and time > zone identifier property parameters can be specified on this > property. > > Conformance: This property can be specified in "VEVENT" or > "VFREEBUSY" calendar components. > > Description: Within the "VEVENT" calendar component, this property > defines the date and time by which the event ends. The value type > of this property MUST be the same as the "DTSTART" property, and > its value MUST be later in time than the value of the "DTSTART" > property. Furthermore, this property MUST be specified as a date > with local time if and only if the "DTSTART" property is also > specified as a date with local time. > > Within the "VFREEBUSY" calendar component, this property defines > the end date and time for the free or busy time information. The > time MUST be specified in the UTC time format. The value MUST be > later in time than the value of the "DTSTART" property. > > What is clear is that a VEVENT may include a DATE in both DTSTART and DTE= ND, and that the value MAY be the same. What is LESS clear is whether a VF= REEBUSY can include a date. The grammar for DTSTART and DTEND makes clear = that either DATE or DATE-TIME may be specified, but the text in Section 3.6= .2 is also prescriptive, where as the text in Section 3.6.4 on VFREEBUSY is= not quite so clear. > > I would suggest that if there is an erratum here, then it is in either Se= ction 3.6.4 or in 3.8.2.2 in which it should be made clear whether DATE can= be used with DTSTART/DTEND in a VFREEBUSY clause. For certain, if a DATE = value is used, my view is that the DTSTART and DTEND values MAY be the same= , and that the emboldened text above would be erroneous. > > Eliot > > > > From nobody Sun Apr 19 12:34:27 2020 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 4E74C3A102F for ; Sun, 19 Apr 2020 12:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.317 X-Spam-Level: X-Spam-Status: No, score=-0.317 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=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 n6vbpzLkNlJe for ; Sun, 19 Apr 2020 12:34:23 -0700 (PDT) Received: from mail-il1-f173.google.com (mail-il1-f173.google.com [209.85.166.173]) (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 CC7943A102E for ; Sun, 19 Apr 2020 12:34:23 -0700 (PDT) Received: by mail-il1-f173.google.com with SMTP id z12so7582274ilb.10 for ; Sun, 19 Apr 2020 12:34:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lJTuZxvNqxEz9nsl/n53Wwmxg4R4GsYQfWpZJcchGTQ=; b=foweBacHCYQ/bkTFkqimDP1tui3rE2gSiyxQ6AFCucWz54A9fywECC70Z3u+uX0dj1 tYDOKmtT8HL/hcRGY0MqMiLgvHHsH9dkdthCdiw2QHiv8kfdshvBIzBRdL2g2xCWbStP C0NeX1nC/3cjP+SXsxg/4i4xD4Rdt19XtZXQrWlPPXP2CUVPfyResN2Gpxcs25OSOS2b KYBtqYEt6IubqiT9vFIGWHKVJv478wasVS/VPTFkWG6ZK80uGP5TlDg0fqLoVxFG6QBR Oh8fFfCfITufJLI3LCr2cuRt1h7BzfRNCUOUNYbEmSLNb5e2VC+JMeVc3wzgZ+sE22GX VYPA== X-Gm-Message-State: AGi0PubZTtmTb3WnX2of/sq/J6Q4dIbm4q0UbIn48Fqj7/Yhrb61tVwd waZ3uvEV6cxGutSKtu/UmnE1KyLQcrALm3oO0HI= X-Google-Smtp-Source: APiQypIrn5Au7qmld95XNReqqed56uj2IIbT6oJTkraKOcTK6bx1KLTcMiJAi6p+uGlQ/5SzKBCBOYRMQhiUM361ZFQ= X-Received: by 2002:a92:1d5c:: with SMTP id d89mr12691414ild.140.1587324862911; Sun, 19 Apr 2020 12:34:22 -0700 (PDT) MIME-Version: 1.0 References: <20200419065046.E0BEAF40709@rfc-editor.org> <20200419192307.GA3130@euklid.home> In-Reply-To: <20200419192307.GA3130@euklid.home> From: Barry Leiba Date: Sun, 19 Apr 2020 15:34:12 -0400 Message-ID: To: Lars Henriksen Cc: Bernard Desruisseaux , Eliot Lear , Murray Kucherawy , RFC Errata System , calsify@ietf.org Content-Type: multipart/alternative; boundary="00000000000098da1405a3a9de4f" Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6109) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 19:34:25 -0000 --00000000000098da1405a3a9de4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Errata reports are meant to report errors that were missed during publication. Specifically, they=E2=80=99re things that would have been fixe= d at the time, had they been caught then. We often get reports about things that we now realize are wrong, but we did not consider them wrong at the time. We also often get reports about things that people wish were written differently, for various reason. In both of those cases, the document says what it was intended to say: no errata are involved. Here, we have something more on the edge: the document says exactly what was meant at the time. You are pointing out an issue,which, as I see from the discussion, is a valid discussion point. Had you brought it up in the working group, it might very well have resulted in different text in the RFC. That=E2=80=99s why I=E2=80=99m considering =E2=80=9CHeld for Document Updat= e=E2=80=9D: any fix for this is out of the limited scope for errata, and will need more discussion to resolve the correct text. See the IESG statement about errata handling for more information about all this: https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ Barry On Sun, Apr 19, 2020 at 3:23 PM Lars Henriksen wrote: > On Sun, Apr 19, 2020 at 02:17:50PM -0400, Barry Leiba wrote: > > It strikes me that this is not an erratum, and that the report is a > > request for an update, rather than a report of an actual editing error > > at the time of publication. > > What's the difference between "an erratum", "a request for an update" and > "an actual editing error"? > > > My inclination is to mark it "Rejected", ... > > The RFC contains a false statement. How else am I supposed to report it? > > Lars Henriksen > --00000000000098da1405a3a9de4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Errata reports are meant to report errors that were = missed during publication. Specifically, they=E2=80=99re things that would = have been fixed at the time, had they been caught then.

We often get reports about things tha= t we now realize are wrong, but we did not consider them wrong at the time.=

We also often get repor= ts about things that people wish were written differently, for various reas= on.

In both of those cas= es, the document says what it was intended to say: no errata are involved.<= /div>

Here, we have something = more on the edge: the document says exactly what was meant at the time.=C2= =A0 You are pointing out an issue,which, as I see from the discussion, is a= valid discussion point.=C2=A0 Had you brought it up in the working group, = it might very well have resulted in different text in the RFC.

That=E2=80=99s why I=E2=80=99m consi= dering =E2=80=9CHeld for Document Update=E2=80=9D: any fix for this is out = of the limited scope for errata, and will need more discussion to resolve t= he correct text.

See the= IESG statement about errata handling for more information about all this: = =C2=A0

Barry

On Sun, Apr 19, 2020 at 3:23 PM Lars Henriksen <LarsHenriksen@get2net.dk> wrote= :
On Sun, Apr 19, 2020 at 02:17:50PM -0400, Barry= Leiba wrote:
> It strikes me that this is not an erratum, and that the report is a > request for an update, rather than a report of an actual editing error=
> at the time of publication.

What's the difference between "an erratum", "a request f= or an update" and
"an actual editing error"?

> My inclination is to mark it "Rejected", ...

The RFC contains a false statement. How else am I supposed to report it?
Lars Henriksen
--00000000000098da1405a3a9de4f-- From nobody Sun Apr 19 13:12:37 2020 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 AAF5B3A10DD for ; Sun, 19 Apr 2020 13:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 e0csAn5KvoeS for ; Sun, 19 Apr 2020 13:12:30 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 CAFCD3A1096 for ; Sun, 19 Apr 2020 13:12:30 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id w1so8573263iot.7 for ; Sun, 19 Apr 2020 13:12:30 -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-language; bh=bt0QBjU6CH0yAQGT7Shx6j7WW772wEKBT0B58ql8Bfs=; b=ippMNddO3J9jkOh/zvaQc2eUWhadL5+wb2ZesIuThmQUYku4gRXEXr+eBZ13pThlTw bCi8/UOisx28cnPrBpwjtc3xJnbkgJmj8rRGEjCt0JFo15GeW7UW54I9bKmOOYLVs2XZ UMnpOzZmNLSNxQsL9hruO7k71LpCCzV8floX3pvbm9M0WbdM7+KAbaGqvy5da5D33yx4 fQXs8bJRCZwRF9N4ObktBY4oPGwO7ccgW8BRlizmYjJP9TYzIrNO0zPzg9oig5JE2alA IA2TqtXoTnUDZIjfgFEEOO3oubOR1BeTE2vlifgtHG0Y9uS9mwe2h2G3LEXGUVmbvz+e cDAQ== 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-language; bh=bt0QBjU6CH0yAQGT7Shx6j7WW772wEKBT0B58ql8Bfs=; b=AexB68l1m2lLJRNsC0OVIzw6xFpHAtNNXVwJLjN1cvGrxb1GXs+ocV/dAYEbY4RSuk OnbryGAfbIuRTn9G4t/qq5BNV+bTvWFcL7/B89J0Lz8a1QuFJ3Y+igixwk5cHMFOmjI5 yKXynYrK1NLFjpjrY6P+waU1p9SU9zYvX13+m2spAI4YhuQ/Ndvk4qw3yFZYu+KNIrkF pyZ4aPwLFCSzDxqzMvc8bzc1hm59f8e3bsq/MjbqJGfL7U1HCc4ZLHKW7MVUaE5gzCJq Dc5dwe87jR9iNhlKF2zljNYNdbK4G1fDUP2W6sJgDVIgj/H/66naWkdQrrvKZhE2myKD o2pQ== X-Gm-Message-State: AGi0PuZ90hWN6SCaxK/ZxD9T3xmtOFa8ou4tfWW9pN8+HfGWgvknVniw bv3PXrpAi0COnZVluOhBPVA= X-Google-Smtp-Source: APiQypKnvCipM2fTpjniVLIHAxihZTLKwnvOI/3Wvc2nOHCzmRlLOcURQSNN+SVCWKxZuGY0M3RzRw== X-Received: by 2002:a5d:9354:: with SMTP id i20mr12544361ioo.207.1587327150074; Sun, 19 Apr 2020 13:12:30 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id q29sm10601088ill.65.2020.04.19.13.12.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Apr 2020 13:12:29 -0700 (PDT) To: Neil Jenkins , Robert Stepanek , calsify@ietf.org, Ken Murchison , Bron Gondwana References: <7e5829d9-d600-4841-8924-00002c9ead54@www.fastmail.com> <62b56395-b012-4594-a5fe-baf41c6a79ae@beta.fastmail.com> From: Michael Douglass Message-ID: Date: Sun, 19 Apr 2020 16:12:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <62b56395-b012-4594-a5fe-baf41c6a79ae@beta.fastmail.com> Content-Type: multipart/alternative; boundary="------------6CB63F5C9309177CDA5FB7B1" Content-Language: en-US Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar-26 and mappings to iCalendar X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 20:12:36 -0000 This is a multi-part message in MIME format. --------------6CB63F5C9309177CDA5FB7B1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 4/14/20 23:31, Neil Jenkins wrote: > I agree with Robert: this should remain a separate document. Both > because the JSCalendar document is basically done and we'd really like > to not hold it up further (it's taken forever) jscalendar - 2yrs 8mths rfc5545 - 4yrs rfc5546 - 4yrs 2mths caldav - 2yrs 8mths caldav-scheduling - 7 years eventpub - 9yrs and counting... > but more importantly it makes the document less intimidating for > implementers that don't care about iCalendar, as they won't have a > huge load of irrelevant (to them) complicated text to ignore. I'm not committed to one or the other but I do believe that doing this properly - and avoiding years of interoperability issues - is going to mean some changes to the jscalendar spec. I don't think it needs to take long - at least to ensure that jscalendar is going to be correctly mappable. > > Neil. --------------6CB63F5C9309177CDA5FB7B1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 4/14/20 23:31, Neil Jenkins wrote:
I agree with Robert: this should remain a separate document. Both because the JSCalendar document is basically done and we'd really like to not hold it up further (it's taken forever)

jscalendar - 2yrs 8mths

rfc5545 - 4yrs

rfc5546 - 4yrs 2mths

caldav - 2yrs 8mths

caldav-scheduling - 7 years

eventpub - 9yrs and counting...

but more importantly it makes the document less intimidating for implementers that don't care about iCalendar, as they won't have a huge load of irrelevant (to them) complicated text to ignore.

I'm not committed to one or the other but I do believe that doing this properly - and avoiding years of interoperability issues - is going to mean some changes to the jscalendar spec.

I don't think it needs to take long - at least to ensure that jscalendar is going to be correctly mappable.


Neil.
--------------6CB63F5C9309177CDA5FB7B1-- From nobody Sun Apr 19 14:33:03 2020 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 D5C4C3A1218 for ; Sun, 19 Apr 2020 14:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 BXxL4DDwIIDb for ; Sun, 19 Apr 2020 14:32:59 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7753A1216 for ; Sun, 19 Apr 2020 14:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=877; q=dns/txt; s=iport; t=1587331979; x=1588541579; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=igx936bPWDuQM1JXKOzcpgIb6KWQ/J8aeSRb5VCG6yc=; b=VkbRupHq4L8BsstggevsSpnwqVOKUnGe7OVENkJZ1vfS67NsLcn7+3+S X207GFtGowbibWv3DFCC/L8/hKcSyKtvv6qXPiO33R7p72+/I0JjFw99t IXtyq7M28pXa38irnHZOerQeoly0d9TJum7apnYxizY8vKFQF1wH0Mznd s=; X-IPAS-Result: =?us-ascii?q?A0DqAwAMwpxe/xbLJq1mHAEBAQEBBwEBEQEEBAEBgXuBf?= =?us-ascii?q?YFtIBKER4kCh2ebcwoBAQEMAQEvBAEBhEQCgjM4EwIDAQEBAwIDAQEBAQUBA?= =?us-ascii?q?QECAQUEbYVihXIGI1YQCxoCJgICVwaCbkuCfa4AdYEyimaBDiqMU4IAgTgME?= =?us-ascii?q?IFPfj6BBINKgxIygi0EsgGCToJpiwyJdh2CVo0YJ4w9kUKXV4M/AgQGBQIVg?= =?us-ascii?q?WkigVczGggbFWUBgj89EhgNkWQMC4EEAQmNGT8DkAQBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.72,404,1580774400"; d="scan'208";a="23138262" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Apr 2020 21:32:57 +0000 Received: from [10.61.218.226] ([10.61.218.226]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 03JLWukX029101 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Apr 2020 21:32:56 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: Date: Sun, 19 Apr 2020 23:32:56 +0200 Cc: Lars Henriksen , Bernard Desruisseaux , Murray Kucherawy , RFC Errata System , calsify@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <20DE9003-A9DC-4948-B73A-FBDE224D1981@cisco.com> References: <20200419065046.E0BEAF40709@rfc-editor.org> <20200419192307.GA3130@euklid.home> To: Barry Leiba X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.218.226, [10.61.218.226] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6109) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 21:33:01 -0000 Barry, Having had a second, third, and fourth read, I think the text should be = marked hold for update.=20 Lars is correct that the text in that section does not support the case = where an event is 2 days long. Is this a serious interoperability = problem? In order for it to be so, a calendar agent would have to = improperly represent all anniversaries, and that would be spotted pretty = quickly against any other calendar agent. This having been said, were we to open the document, I would probably = unbury text out of Section 3.6.1 (see Our Blissful Anniversary) that = talks about DATE DTENDs and copy that into Section 3.8.2.2 and make it = plainly normative. The issue here is the use of the term "non-inclusive=E2=80=9D makes = perfect intuitive sense for a DATE-TIME event but less so for DATE = events. We should clean that up. Eliot From nobody Sun Apr 19 17:07:30 2020 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 7B8433A09DB for ; Sun, 19 Apr 2020 17:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.317 X-Spam-Level: X-Spam-Status: No, score=-0.317 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=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 47tu0Df1Zdbd for ; Sun, 19 Apr 2020 17:07:27 -0700 (PDT) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (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 0BA883A09C7 for ; Sun, 19 Apr 2020 17:07:26 -0700 (PDT) Received: by mail-io1-f44.google.com with SMTP id e9so1491206iok.9 for ; Sun, 19 Apr 2020 17:07:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RYkL3VYbVnKeedQXuhclDOrvT74vO8ajxPmaYNj0T6U=; b=gz12Bd2sBOSooZBiZ8oGvIOavCb/sKGlZnaDwc0lqz4nGTGjZv7LHYvXs2JLOoSJmq VJgZm84P2BsBKC4ssYVJLqtJ3Kz6il3UAkXN1NREaT9greDajREMuXlfbvP3hkS/9w8s 7Eh+xNtfXd+lp8HRevZ6dBQQw9eQKmjOaw3fp5p6jgi4j/cNfCn/ULXaiWSexkMd/siD 9BJUPhEG3HzUpTV8uNopoPmJG1RhKaGN+6LRUvKStzGI/6t6+ZePwOVdCczC5xcMTGAk F0Gmz4Bxg3tjPjQhFTCcpKME3V9oqpLlg40Q+BDSrzdJHVe5dwQcru3l5zDhTcgYOkQX rlDg== X-Gm-Message-State: AGi0PubKd0Idx5+jJ8mVE7NBQbXZCaZYdDwdxuCciUqrc0NjSVQgYg+R bOelXpk/T2e5rABV00d1Ye3scpmTO+g6lOz39dA= X-Google-Smtp-Source: APiQypLlMi6pm3dIrml5C9XunM4tS/ptkuOgpzwvD/nWcag/gvDdQB5zzkL9vSilMmKnGtaTIyf5CWx5789aNBb9N54= X-Received: by 2002:a05:6638:22a:: with SMTP id f10mr13606770jaq.59.1587341245999; Sun, 19 Apr 2020 17:07:25 -0700 (PDT) MIME-Version: 1.0 References: <20200419065046.E0BEAF40709@rfc-editor.org> <20200419192307.GA3130@euklid.home> <20DE9003-A9DC-4948-B73A-FBDE224D1981@cisco.com> In-Reply-To: <20DE9003-A9DC-4948-B73A-FBDE224D1981@cisco.com> From: Barry Leiba Date: Sun, 19 Apr 2020 20:07:15 -0400 Message-ID: To: Eliot Lear Cc: Bernard Desruisseaux , Lars Henriksen , Murray Kucherawy , RFC Errata System , calsify@ietf.org Content-Type: multipart/alternative; boundary="0000000000001aeeb305a3adaf18" Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6109) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 00:07:28 -0000 --0000000000001aeeb305a3adaf18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok, that sounds reasonable. Does anyone object to HFDU here? Barry On Sun, Apr 19, 2020 at 5:33 PM Eliot Lear wrote: > Barry, > > Having had a second, third, and fourth read, I think the text should be > marked hold for update. > > Lars is correct that the text in that section does not support the case > where an event is 2 days long. Is this a serious interoperability > problem? In order for it to be so, a calendar agent would have to > improperly represent all anniversaries, and that would be spotted pretty > quickly against any other calendar agent. > > This having been said, were we to open the document, I would probably > unbury text out of Section 3.6.1 (see Our Blissful Anniversary) that talk= s > about DATE DTENDs and copy that into Section 3.8.2.2 and make it plainly > normative. > > The issue here is the use of the term "non-inclusive=E2=80=9D makes perfe= ct > intuitive sense for a DATE-TIME event but less so for DATE events. We > should clean that up. > > Eliot > > --0000000000001aeeb305a3adaf18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok, that sounds reasonable.=C2=A0 Does anyone object= to HFDU here?

Bar= ry

On Sun, Apr 19, 2020 at 5:33 PM Eliot Lear &= lt;lear@cisco.com> wrote:
Barry,

Having had a second, third, and fourth read, I think the text should be mar= ked hold for update.

Lars is correct that the text in that section does not support the case whe= re an event is 2 days long.=C2=A0 Is this a serious interoperability proble= m?=C2=A0 In order for it to be so, a calendar agent would have to improperl= y represent all anniversaries, and that would be spotted pretty quickly aga= inst any other calendar agent.

This having been said, were we to open the document, I would probably unbur= y text out of Section 3.6.1 (see Our Blissful Anniversary) that talks about= DATE DTENDs and copy that into Section 3.8.2.2 and make it plainly normati= ve.

The issue here is the use of the term "non-inclusive=E2=80=9D makes pe= rfect intuitive sense for a DATE-TIME event but less so for DATE events.=C2= =A0 We should clean that up.

Eliot

--0000000000001aeeb305a3adaf18-- From nobody Sun Apr 19 18:42:57 2020 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 9B5723A0BD8 for ; Sun, 19 Apr 2020 18:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 pcY9obGwqltj for ; Sun, 19 Apr 2020 18:42:50 -0700 (PDT) Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 655E43A0BC3 for ; Sun, 19 Apr 2020 18:42:40 -0700 (PDT) Received: by mail-il1-x143.google.com with SMTP id c16so1306651ilr.3 for ; Sun, 19 Apr 2020 18:42:40 -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-transfer-encoding:content-language; bh=bidvIYv9eaBTyeu3zypC2J/dxJGCAcw0wkHgCcWAG5c=; b=cQZ9JVrIouUUP2Evx5i0KtS7wBw3bdxEi2mr95Kim7rASH8ywOduJVngXcb7ynBSYH NpMIwcdOzZa+kVdMYc0X9bdyfVc7SaoX5kUvI+rG1D5XygdyCs0qs8bOt7K0HnEypGOc yPIceoIUBcs5aWZ4eEq20GsYdRWAOn84/obwQN1GcXmzrCk7b6pxPrLnJQwmRVhy7JVY QEEseL2FhqvGVrqkiGqHO28mWIf3KUsqvOpiUL1TdGRpTpQ6DfE/MdinEEy8MDLwXb9B 1QTWEOMKKtbZhWnwqEr7coDxlN9MofBfLWhELPBshhVlCaex1D0FPi7Dm0zrck5fWtZa A8ew== 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=bidvIYv9eaBTyeu3zypC2J/dxJGCAcw0wkHgCcWAG5c=; b=GY5Ya0gBeujVf7kvK3q5zGDhLkKziO2Ul89jjRn6QW1XfKBMYBkUspqFFe5WnjVxQd XVbalH2H02QZrcvpQ+45Alv9yBpLdsRv725YiPg0NgeEoDtksK/ki5l/+GhR9ZXouFeJ apAgfzCUrKaHvhbCKhNmqdnct61Pi7I0QIkjPDMOaa8d8W+ow9QWAaHpTlfrFwPyv4IX FSJyWM/znFo4l0TrgBoU/ZtynBW/7tgynGVRX28XfazvYXiRxxhlCBkgvNM/mlL247Ro C0lfptMlxe+24yE6F/I92D7xH/VvwKtQyfbHT+vn9ZAXw9mPB19/jRedTsGK2OeFEbw2 2RVQ== X-Gm-Message-State: AGi0PuYoOCSxVEp1ZywMBs9tbczm1VTOkG3xWdPV4haw+yAjQ2Ikpum6 j9oC5eFCTbwxPvBoDpAKD9M= X-Google-Smtp-Source: APiQypLGF0mlyjwFysj/4RZzu2AHxqA6RRbUPlbeKkvXgwto5oeRGNCQ+YzbB4w93yr15yuvAhjINg== X-Received: by 2002:a92:5e4d:: with SMTP id s74mr5758425ilb.278.1587346959615; Sun, 19 Apr 2020 18:42:39 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id s75sm4094367ilc.86.2020.04.19.18.42.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Apr 2020 18:42:38 -0700 (PDT) To: Eliot Lear , Michael H Deckers Cc: RFC Errata System , superuser@gmail.com, calsify@ietf.org, barryleiba@computer.org, LarsHenriksen@get2net.dk References: <20200419065046.E0BEAF40709@rfc-editor.org> <83ACDE3F-8348-4AF9-B157-742E79E8D19C@cisco.com> From: Michael Douglass Message-ID: <6b62207e-fa54-951f-fe31-b66cb3b6748e@gmail.com> Date: Sun, 19 Apr 2020 21:42:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <83ACDE3F-8348-4AF9-B157-742E79E8D19C@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6109) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 01:42:56 -0000 On 4/19/20 09:24, Eliot Lear wrote: > Hi Michael > >> In my opinion, a DTEND value can _never_ be the same >> as a DTSTART value, by: >> >> 3.8.2.2. Date-Time End >> ... >> Description: Within the "VEVENT" calendar component, this property >> defines the date and time by which the event ends. The value type >> of this property MUST be the same as the "DTSTART" property, and >> its value MUST be later in time than the value of the "DTSTART" >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> property. >> >> This applies to all DTENDs within a VEVENT, and the same text is >> used in the next paragraph for DTENDs within VFREEBUSY. I do not >> see that anniversaries or daily reminders (being VEVENTs) take >> exception to this MUST rule. > > If this is the case, then how would you express the holiday “New Year’s Day” such that it applies to everyone in their respective wall clock times? That's the only possibility with VALUE=DATE, it's a floating value - i.e no timezone so always interpreted locally. And there's two ways (ignoring duration): DTSTART;VALUE=DATE: 20210101 DTEND;VALUE=DATE:20210102 or just DTSTART;VALUE=DATE: 20210101 Start is inclusive, end exclusive > > Eliot > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Sun Apr 19 18:57:34 2020 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 376BF3A0C12 for ; Sun, 19 Apr 2020 18:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 KM_jWvQIdP_i for ; Sun, 19 Apr 2020 18:57:31 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 256CE3A0C11 for ; Sun, 19 Apr 2020 18:57:31 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id u11so9269789iow.4 for ; Sun, 19 Apr 2020 18:57:30 -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-language; bh=L30bUHYQuupy53n2umNCfB8hoTdZmxMUjHRjli4f+yk=; b=HYOeo4LCPh5qtrBBWKnxsI70QcOHOqH17pih6QcUKIrLLqi7Bl7AlWgf7UNLMvnFoq /2KZVHfbQQDtoeiegIVlOeC+r/IfbTyHfPgYaeZSjHVAm5hwGwChw/P8ZV6zBosgSiHB MNkuGlFHKBvIQTv0+unuvh6Mqbxiifv0eP9nlynpG/BAjS3ktrbisSIh4Aib5dlI19bx PvJwMcR2KrLTU8ae0agn45ISCm2wxzG+ngNo6TRAzldo6eM0xRqn3gEx5PLE1vOWvrBu 87gjjwRCqXh3Jh/teaZtfTuE+Yo3VDQMIJcDU2OwF9IxLoFwWw7cKmNoAPyIkwymAJaJ Qttw== 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-language; bh=L30bUHYQuupy53n2umNCfB8hoTdZmxMUjHRjli4f+yk=; b=OJCweGMXB6ez3raPO1/km1B46It+6Exrx/0eLLphPXyPBxTZuM+JzReRfpIrccTvbh KhTxVGn7s3Vb/Y35WMbfwi6bHpoX5qnqzvNiYQEGt1IhbO3713VL9nLSjZhi2xmlg9L9 eFN6LBDf17gfnTECyNu40aS+oR6T6NYzoz2iAQMt82xecJow7muuvrkYlfPOosqhHhWZ 6GmM4CS0p6HBgm+PcV2gLN74S5GkfcpE7LjURMxC5r7x+6ViHl/AMo5r+KrMzYGIbGbV Qf0wAQhzhRnRx/IK+9uZgTsfWG7qhqv4AMej+hB61Qv6+eVBM6CPFCkp07rbyTD1MvfM Avxg== X-Gm-Message-State: AGi0Pub5AgqcAUSnJzPD/Pl0OL9/WD88XI4JQRoyFdkbsy7TNGyqtV2x /PTZZwtSvS8jWrrZSnJad6SFGeCjkw0= X-Google-Smtp-Source: APiQypIq57G7Y/3XFdUADM6WcbMuGywXxIfVEH0h+1TNLdmwHw6JQdm6PatHFVVWpsaulaQzc8xepw== X-Received: by 2002:a02:cbac:: with SMTP id v12mr13086002jap.103.1587347850059; Sun, 19 Apr 2020 18:57:30 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id f5sm3519562iok.4.2020.04.19.18.57.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Apr 2020 18:57:29 -0700 (PDT) To: calsify@ietf.org References: <20200419065046.E0BEAF40709@rfc-editor.org> <20200419192307.GA3130@euklid.home> <20DE9003-A9DC-4948-B73A-FBDE224D1981@cisco.com> From: Michael Douglass Message-ID: <2333aa11-593e-69d8-710c-a62afa113558@gmail.com> Date: Sun, 19 Apr 2020 21:57:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------578CF5E7DB23FDED9AF0EA3F" Content-Language: en-US Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6109) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 01:57:33 -0000 This is a multi-part message in MIME format. --------------578CF5E7DB23FDED9AF0EA3F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This text has been in place since 2445. On 4/19/20 20:07, Barry Leiba wrote: > Ok, that sounds reasonable.  Does anyone object to HFDU here? > > Barry > > On Sun, Apr 19, 2020 at 5:33 PM Eliot Lear > wrote: > > Barry, > > Having had a second, third, and fourth read, I think the text > should be marked hold for update. > > Lars is correct that the text in that section does not support the > case where an event is 2 days long.  Is this a serious > interoperability problem?  In order for it to be so, a calendar > agent would have to improperly represent all anniversaries, and > that would be spotted pretty quickly against any other calendar agent. > > This having been said, were we to open the document, I would > probably unbury text out of Section 3.6.1 (see Our Blissful > Anniversary) that talks about DATE DTENDs and copy that into > Section 3.8.2.2 and make it plainly normative. > > The issue here is the use of the term "non-inclusive” makes > perfect intuitive sense for a DATE-TIME event but less so for DATE > events.  We should clean that up. > Why? Makes perfect sense to me - as in the 1 day example. As it stands it's all consistent. Doesn't mean people get it right but that's a different problem. Going back to the original text: > The > anniversary type of "VEVENT" can span more than one date (i.e., > "DTEND" property value is set to a calendar date after the > "DTSTART" property value). The biggest problem as I see it is that it's a completely meaningless addition to the explanation. All it's trying to say is that a recurring event with VALUE=DATE can be more than one day long - which should come as no surprise to anybody. I suspect they dug their own hole by referring to them as anniversary events rather than all-day - then realisd people think of anniversaries as a single day thing. I'd say: 1. The attempted explanation is wrong. 2. It's pointless. So we could just remove it. However - it's been around for 22 years and we've just noticed. > > Eliot > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------578CF5E7DB23FDED9AF0EA3F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

This text has been in place since 2445.


On 4/19/20 20:07, Barry Leiba wrote:
Ok, that sounds reasonable.  Does anyone object to HFDU here?

Barry

On Sun, Apr 19, 2020 at 5:33 PM Eliot Lear <lear@cisco.com> wrote:
Barry,

Having had a second, third, and fourth read, I think the text should be marked hold for update.

Lars is correct that the text in that section does not support the case where an event is 2 days long.  Is this a serious interoperability problem?  In order for it to be so, a calendar agent would have to improperly represent all anniversaries, and that would be spotted pretty quickly against any other calendar agent.

This having been said, were we to open the document, I would probably unbury text out of Section 3.6.1 (see Our Blissful Anniversary) that talks about DATE DTENDs and copy that into Section 3.8.2.2 and make it plainly normative.

The issue here is the use of the term "non-inclusive” makes perfect intuitive sense for a DATE-TIME event but less so for DATE events.  We should clean that up.

Why?

Makes perfect sense to me - as in the 1 day example.

As it stands it's all consistent. Doesn't mean people get it right but that's a different problem.

Going back to the original text:

The
      anniversary type of "VEVENT" can span more than one date (i.e.,
      "DTEND" property value is set to a calendar date after the
      "DTSTART" property value).


The biggest problem as I see it is that it's a completely meaningless addition to the explanation. All it's trying to say is that a recurring event with VALUE=DATE can be more than one day long - which should come as no surprise to anybody. I suspect they dug their own hole by referring to them as anniversary events rather than all-day - then realisd people think of anniversaries as a single day thing.

I'd say:

1. The attempted explanation is wrong.

2. It's pointless.

So we could just remove it.

However - it's been around for 22 years and we've just noticed.



Eliot


_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------578CF5E7DB23FDED9AF0EA3F-- From nobody Sun Apr 19 21:30:44 2020 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 613DA3A0F1D for ; Sun, 19 Apr 2020 21:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 ZyQTLKVfXpYV for ; Sun, 19 Apr 2020 21:30:41 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 D8EBB3A0F4C for ; Sun, 19 Apr 2020 21:30:22 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id w20so9514333iob.2 for ; Sun, 19 Apr 2020 21:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=mbimsTSEh1UEhfay0MB6zZxgCLWPoBFIL97kwtUayQw=; b=goHlFRyQdbNvCCo0+eQqbU6eYdJ6ZQRclIcBKOO0C+A3K2oiyxfytsCZ03vIgQWXrc m98O7MqVSXRhktbPVcuQMBZoTBxY2RxLg4x1VDtEaoP2zoi8F+QDa5YQDAsx/gxRJJZh VinFVG0NOQXgd0984aNfVfuJbmPXWkzsIMB6LdNqa0vLc2v0+2agRCfBBgVr7tlkpWAX wuNTyW/aYV63SuI92qlJiyD80+UgfYpbhTx0Ve6LP0RATfv8VSHCfwUq9iNqQcnuJPAU mKvkUudMFMx5uhVVfT1iwxSEEA2B41uLrcKE8kD6lDcEscJmjNu7fX7QGlIIviyz45GY SvvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=mbimsTSEh1UEhfay0MB6zZxgCLWPoBFIL97kwtUayQw=; b=swYyCSFt73Gk4I2EyYeg99/BqFuAoL0UHn3awcz/D6hsyGjksCuI+prm/3tYgUm5R7 KKZA0yHw8nvYVS+ziqo9dr+FW15wlxsNU2W3LXNm3ByMn0FGWLfbKYWLoKdf+qcGVUws MGr0UFa6pE6GF96en57inQBmL8kSYyr2PDKe6TnTh8RAKdB7VOZp/SzSJh2+RWMTzAlw TiKxgJt/LdQqEMpce4/vbzxbEBiia8nV/8fPz2kUbDGLNxmPTCpbbT3e24wTH5RC7bqW a2sayZQA1AdzpK61xp483f3QzktKZpGYDtrU2hKTe2XoleNDV3CluXDUEYsCNTJt0ntj 3JGw== X-Gm-Message-State: AGi0PuZqpSL1pD+Vq1pR7rqNtD/6xJY9iVGDgkAH5CJ1CLfyZpxLxZFO ShtRnQjCi/r3Ifav7y2Hj5r3Mwtz/gU= X-Google-Smtp-Source: APiQypIe+H6juAV9fDyNfU20C6BESfPuGlhxs6qXr+3SDNNXtosVxUrbft/rBwOEzzg1uTXnXKaczQ== X-Received: by 2002:a6b:7419:: with SMTP id s25mr13969578iog.45.1587357021942; Sun, 19 Apr 2020 21:30:21 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id r1sm2936248ilg.61.2020.04.19.21.30.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Apr 2020 21:30:21 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: Date: Mon, 20 Apr 2020 00:30:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B526325FC6301DE2D4B573DF" Content-Language: en-US Archived-At: Subject: [calsify] jscalendar - attachments X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 04:30:44 -0000 This is a multi-part message in MIME format. --------------B526325FC6301DE2D4B573DF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Trying to come up with examples and I started with the 5545 example ATTACH:CID:jsmith.part3.960817T083000.xyzMail@example.com The jscalendar spec says: o href: "String" (mandatory) A URI from which the resource may be fetched. This MAY be a "data:" URL [RFC2397 ], but it is recommended that the file be hosted on a server to avoid embedding arbitrarily large data in JSCalendar object instances. o cid: "String" (optional) This MUST be a valid "content-id" value according to the definition ofSection 2 in [RFC2392] . The value MUST be unique within this Link object but has no meaning beyond that. It MAY be different from the link id for this Link object. Should it be one of href or cid is mandatory? If not how is the above represented? --------------B526325FC6301DE2D4B573DF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Trying to come up with examples and I started with the 5545 example

      ATTACH:CID:jsmith.part3.960817T083000.xyzMail@example.com

The jscalendar spec says:

   o  href: "String" (mandatory)

      A URI from which the resource may be fetched.

      This MAY be a "data:" URL [RFC2397], but it is recommended that
      the file be hosted on a server to avoid embedding arbitrarily
      large data in JSCalendar object instances.

   o  cid: "String" (optional)

      This MUST be a valid "content-id" value according to the
      definition of Section 2 in [RFC2392].  The value MUST be unique
      within this Link object but has no meaning beyond that.  It MAY be
      different from the link id for this Link object.

Should it be one of href or cid is mandatory? If not how is the above represented?


--------------B526325FC6301DE2D4B573DF-- From nobody Mon Apr 20 05:06:44 2020 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 C70653A0BD6 for ; Mon, 20 Apr 2020 05:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 CUJciVoZwBSi for ; Mon, 20 Apr 2020 05:06:29 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E63B3A0860 for ; Mon, 20 Apr 2020 05:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4590; q=dns/txt; s=iport; t=1587384389; x=1588593989; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Se17nCnOztYesFRq5DVjO96SKfPE+bYDcVUewyipYe0=; b=JdXNAe7kEH/Cf9Jdma9DnrRHXOr0Jibv/QY7M8QIZiFN2E+gkMhgAeZB VqIDoaRXFGJkNQ4FlQiPlzkByyN1FzNzaf9wnqsyw9NF6TTwAfTPsQKDO nEzOpjITCdSIfebchMPkxu8ZRJObVEaHFa7S1FHB+5kh+m55P12stTvi0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAwBWj51e/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBfYFuIBIqhB2JAogMiXKJUogKCgEBAQwBAS8EAQGERAKCMzg?= =?us-ascii?q?TAgMBAQsBAQUBAQECAQUEbYVihXEBAQEBAgEjVgULCwQKCicDAgIhJREGE4J?= =?us-ascii?q?bS4JMAw4grkZ1gTKFT4JsDYIigTiMU4IAgTgcgU9+PoEEgRqFQjKCLQSxN0q?= =?us-ascii?q?CToJpkD2ERR2Pboxkm2yNLYM/AgQGBQIVgWkigVYzGggbFWUBgj4+EhgNkWQ?= =?us-ascii?q?MC44nPwMwj1QBAQ?= X-IronPort-AV: E=Sophos; i="5.72,406,1580774400"; d="scan'208,217"; a="25481129" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Apr 2020 12:06:27 +0000 Received: from [10.61.222.215] ([10.61.222.215]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 03KC6Q4Q021184 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Apr 2020 12:06:27 GMT From: Eliot Lear Message-Id: <56D37193-CD07-4B1B-B13F-8D52731C96D5@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7ABFB030-0A3D-42EA-AFC9-43A978D71DBD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 20 Apr 2020 14:06:26 +0200 In-Reply-To: <2333aa11-593e-69d8-710c-a62afa113558@gmail.com> Cc: calsify@ietf.org To: Michael Douglass References: <20200419065046.E0BEAF40709@rfc-editor.org> <20200419192307.GA3130@euklid.home> <20DE9003-A9DC-4948-B73A-FBDE224D1981@cisco.com> <2333aa11-593e-69d8-710c-a62afa113558@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.222.215, [10.61.222.215] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6109) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 12:06:43 -0000 --Apple-Mail=_7ABFB030-0A3D-42EA-AFC9-43A978D71DBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Michael, > On 20 Apr 2020, at 03:57, Michael Douglass > wrote: >>=20 >> This having been said, were we to open the document, I would probably = unbury text out of Section 3.6.1 (see Our Blissful Anniversary) that = talks about DATE DTENDs and copy that into Section 3.8.2.2 and make it = plainly normative. >>=20 >> The issue here is the use of the term "non-inclusive=E2=80=9D makes = perfect intuitive sense for a DATE-TIME event but less so for DATE = events. We should clean that up. > Why? >=20 > Makes perfect sense to me - as in the 1 day example. >=20 > As it stands it's all consistent. Doesn't mean people get it right but = that's a different problem. >=20 >=20 Think about it in human language terms: When we say that a meeting has a start time of 2:00pm and an end time of = 3:00pm, people understand that they can schedule another event at = 3:00pm. But when we say that an event has a start date of January 1 and = an end date of January 2, people don=E2=80=99t think automagically that = the event will run from January 1 00:00:00 to January 2 00:00:00 minus = one second. And when you tell them that the event will be January 1, = they understand it to mean just that. I am not suggesting a normative behavior change, just better explanatory = text when the document opens up again. Eliot= --Apple-Mail=_7ABFB030-0A3D-42EA-AFC9-43A978D71DBD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Michael,

On 20 Apr 2020, at 03:57, Michael Douglass = <mikeadouglass@gmail.com> wrote:

This having been said, were we to open the document, I would probably unbury text out of Section 3.6.1 (see Our Blissful Anniversary) that talks about DATE DTENDs and copy that into Section 3.8.2.2 and make it plainly normative.

The issue here is the use of the term "non-inclusive=E2=80=9D = makes perfect intuitive sense for a DATE-TIME event but less so for DATE events.  We should clean that up.
=

Why?

Makes perfect sense = to me - as in the 1 day example.

As it stands it's all = consistent. Doesn't mean people get it right but that's a different problem.



Think about it in human language terms:

When we say that a = meeting has a start time of 2:00pm and an end time of 3:00pm, people = understand that they can schedule another event at 3:00pm.  But = when we say that an event has a start date of January 1 and an end date = of January 2, people don=E2=80=99t think automagically that the event = will run from January 1 00:00:00 to January 2 00:00:00 minus one second. =  And when you tell them that the event will be January 1, they = understand it to mean just that.

I am not suggesting a normative = behavior change, just better explanatory text when the document opens up = again.

Eliot
= --Apple-Mail=_7ABFB030-0A3D-42EA-AFC9-43A978D71DBD-- From nobody Mon Apr 20 17:04:37 2020 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 02B053A1376 for ; Mon, 20 Apr 2020 17:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=DAQSSoIH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tfQIPB2G 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 OTtCAiG716jo for ; Mon, 20 Apr 2020 17:04:33 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 280AB3A1374 for ; Mon, 20 Apr 2020 17:04:33 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1068E78A; Mon, 20 Apr 2020 20:04:32 -0400 (EDT) Received: from imap28 ([10.202.2.78]) by compute1.internal (MEProxy); Mon, 20 Apr 2020 20:04:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=xG9t/BeCX3Cpunx/spPGtCSN1xOEc8LBgoUlMi8 J+2A=; b=DAQSSoIHgMauETORLf5TipCqW+/u/Mgak2JLFDPnQwXkQn21DiVdURK Cgo44BZfCq5Dv+xc6UjHh6Vh3dduLVqHJMcj7aqNFbVBdwKfsYv6Ybpwk4g5UPoK mnLy30yCwxl4VUDJYOkgR9WVbmEH975YSN8VDG2sSueJ0v10kPXq9u5wWgl/sc6g O2uy5hZ/YQhAQmUm4j4PQJ3t1z6FNrnFeVaUHJp4VuvExH4ky4WK7ZiMPhr0/hvv YyniZLfZNvoPg6zR+D6AqxdTyeYUgwavguRtkGplats079jaVI3CQQj0iKXfyxFN HawrHeLKomsmwW6NJcEa8ImKCU3W4Aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=xG9t/BeCX3Cpunx/spPGtCSN1xOEc 8LBgoUlMi8J+2A=; b=tfQIPB2GYPxO7PXmiy+aU6wlDUTkUyi4SHOmkF0vXlEzb r4PDjQv6CsYZ5gTNKA7ppUPCaOMqcosnrx/sTbssjtrxBNBs3LFtIk8YDSllKj46 qp4MbsyDlzEPeyUuHeA3NSB9tC8ipn2K9w4fiijBGmDTS15duvjcRKIN24IyUPmF /Y75nKbLCePdk9U/728Rk82am2u2FAnDLgAbpwwiXsRBgVInzG5S+O5qBZIHD7Du OyTsPKf82xLZ0jae+dXBLjme3mXEn7UJDkGDWKSkbSPZ5C7KpgzLRCnkve3qxX1U 9fKo2nIPRxhorcphqLBXyrf7yQyhphVGqeI6zFHsg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeeggddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpeiiohhomhdruhhspdhivghtfh drohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 104F024009E; Mon, 20 Apr 2020 20:04:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1152-g08c8976-fmstable-20200420v1 Mime-Version: 1.0 Message-Id: <169abd3a-d0e7-455f-8f73-c579af42b3dc@dogfood.fastmail.com> Date: Tue, 21 Apr 2020 10:04:10 +1000 From: "Bron Gondwana" To: calsify@ietf.org, calconnect-l@lists.calconnect.org Content-Type: multipart/alternative; boundary=9f85c7a1c2d146308318001f845e9dd9 Archived-At: Subject: [calsify] Reminder - interim meeting TODAY 21 April 2020 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 00:04:36 -0000 --9f85c7a1c2d146308318001f845e9dd9 Content-Type: text/plain CALEXT Interim Meeting, 21 April 2020 GMT 13:00 * San Francisco 6am * New York 9am * London 2pm * Vienna 3pm * Melbourne 11pm Video chat: https://zoom.us/j/4574164360 (call in https://zoom.us/zoomconference) Side channel text chat: calext@jabber.ietf.org Etherpad: https://etherpad.ietf.org:9009/p/calext-interim-apr-2020 Welcome and Note Well: 5min (Bron) * Agenda Bash * Discussion of how we work without face-to-face meetings as a forcing factor Current Drafts: 45 min * Eventpub * Series * JSCalendar * Subscription Upgrade * VAlarm Extensions * VPoll New work: 20 min * https://tools.ietf.org/html/draft-douglass-serverside-subscriptions-00 * JSCalendar extensions? * iSchedule upgrade Any other business: 20 min * Milestone review See you there! Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --9f85c7a1c2d146308318001f845e9dd9 Content-Type: text/html 
CALEXT Interim Meeting, 21 April 2020 GMT 13:00
* San Francisco 6am
* New York 9am
* London 2pm
* Vienna 3pm
* Melbourne 11pm

Video chat: https://zoom.us/j/4574164360 (call in https://zoom.us/zoomconference)
Side channel text chat: calext@jabber.ietf.org
Etherpad: https://etherpad.ietf.org:9009/p/calext-interim-apr-2020

Welcome and Note Well: 5min (Bron)
    * Agenda Bash
    * Discussion of how we work without face-to-face meetings as a forcing factor
Current Drafts: 45 min
    * Eventpub
    * Series
    * JSCalendar
    * Subscription Upgrade
    * VAlarm Extensions
    * VPoll
New work: 20 min
    * https://tools.ietf.org/html/draft-douglass-serverside-subscriptions-00
    * JSCalendar extensions?
    * iSchedule upgrade
Any other business: 20 min
    * Milestone review

See you there!

Bron.

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


--9f85c7a1c2d146308318001f845e9dd9-- From nobody Mon Apr 20 20:16:51 2020 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 C90C03A1668 for ; Mon, 20 Apr 2020 20:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Ij+wLV5k; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=M8QtqEuK 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 bPframu-fRMG for ; Mon, 20 Apr 2020 20:16:44 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B833A1663 for ; Mon, 20 Apr 2020 20:16:44 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1BAC12B6; Mon, 20 Apr 2020 23:16:42 -0400 (EDT) Received: from imap28 ([10.202.2.78]) by compute1.internal (MEProxy); Mon, 20 Apr 2020 23:16:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=gMXjHAN ECj/8LrLOoo+8NVwzV5TJZ54CTNiv2Yq+I+Q=; b=Ij+wLV5kx4YpggguSX30wXr fppwDyS7HDxXfT/v3am7AB1LT32rs9R3Gg7U91xK6RkQobA9QaBRiro1JK5xCNTo ik3nY+CSkIQqv+O6NlbnuX65oR+7qr8rtA/o36ZFOvUWiHILJD+MnwoEe8BfIXPO +XQ7JrIF97Dr2HlKgf2rI97lYcSLFK6Rt1Ts/B+M7vWlzh2zlVWv4FIjMJe5uiir 9amEio6AvfvLf68p3fnbe/A/1mIiLy3LAFAg2cVBYJ7czJsVYmJGzUDtQZ2hVFrT 7RbiPJ0ijTYHWbjw0f8xXWi6b4kBjG95m0V1uR3TYjjLhu/1495MlzMJmWgeKcA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=gMXjHA NECj/8LrLOoo+8NVwzV5TJZ54CTNiv2Yq+I+Q=; b=M8QtqEuKFet54pEnZthoPk H8NGncL9SPAnY0c5cbU1Dye7F46/icIFSohvmfkfvFmxWueSIHR/pK32dzK6Kt4U yht0f/r95LobN1iof5kST0GDS06Yh6260k+Hx+MEnFzVKnzOO9yxKdL7mWkiQuJo hNm9H1y+vmAwmC+W2xFca7kFENrjo76U4jHr2F08hBJTlGo0Rea6okyA0AyfrrRR A1yN7Ien4u4NetgCPFjjGE4XIyRkpD4zcNtYOXIL3NRx2mqVHsYFV21xo6fcSAdH 5myrBKhLofVax/AbjCxKxtHs+/lBAQU0UUrNzAI1bDqlo4VylaFFe35uWoHrwXzQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeeggdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghdpii hoohhmrdhushenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 42D4724009E; Mon, 20 Apr 2020 23:16:41 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1152-g08c8976-fmstable-20200420v1 Mime-Version: 1.0 Message-Id: <812694d6-aacc-40c3-bbc7-9c0cfa4c70ac@dogfood.fastmail.com> In-Reply-To: <169abd3a-d0e7-455f-8f73-c579af42b3dc@dogfood.fastmail.com> References: <169abd3a-d0e7-455f-8f73-c579af42b3dc@dogfood.fastmail.com> Date: Tue, 21 Apr 2020 13:16:19 +1000 From: "Bron Gondwana" To: calsify@ietf.org, calconnect-l@lists.calconnect.org Content-Type: multipart/alternative; boundary=a6fade5bb4fe439687caf2276ecdafb6 Archived-At: Subject: Re: [calsify] Reminder - interim meeting TODAY 21 April 2020 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 03:16:49 -0000 --a6fade5bb4fe439687caf2276ecdafb6 Content-Type: text/plain Apologies for the late upload, but the first revision chair slides are now uploaded: https://datatracker.ietf.org/doc/slides-interim-2020-calext-01-sessa-chair-slides/ I also recommend that in preparation for this meeting that you review the minutes of the previous meeting in Singapore: https://datatracker.ietf.org/doc/minutes-106-calext/ See you all soon. Cheers, Bron. On Tue, Apr 21, 2020, at 10:04, Bron Gondwana wrote: > CALEXT Interim Meeting, 21 April 2020 GMT 13:00 * San Francisco 6am * New York 9am * London 2pm * Vienna 3pm * Melbourne 11pm Video chat: https://zoom.us/j/4574164360 (call in https://zoom.us/zoomconference) Side channel text chat: calext@jabber.ietf.org Etherpad: https://etherpad.ietf.org:9009/p/calext-interim-apr-2020 Welcome and Note Well: 5min (Bron) * Agenda Bash * Discussion of how we work without face-to-face meetings as a forcing factor Current Drafts: 45 min * Eventpub * Series * JSCalendar * Subscription Upgrade * VAlarm Extensions * VPoll New work: 20 min * https://tools.ietf.org/html/draft-douglass-serverside-subscriptions-00 * JSCalendar extensions? * iSchedule upgrade Any other business: 20 min * Milestone review > > See you there! > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --a6fade5bb4fe439687caf2276ecdafb6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Apologies for the late upload, but the first revision= chair slides are now uploaded:


I also recommend that in preparation for thi= s meeting that you review the minutes of the previous meeting in Singapo= re:


See you all soon.

Cheers,

Bron.

On Tue, Apr 21, 2020, at 10:04, Bron Gondwana wrote:= 
CALEXT Interim Meetin=
g, 21 April 2020 GMT 13:00
* San Francisco 6am
* New York 9am
* London 2pm
* Vienna 3pm
* Melbourne 11pm

Video chat: https://zoom.us/j/4=
574164360 (call in https:=
//zoom.us/zoomconference)
Side channel text chat: calext=
@jabber.ietf.org
Etherpad: https://etherpad.ietf.org:9009/p/calext-interim-apr-2020

Welcome and Note Well: 5min (Bron)
    * Agenda Bash
    * Discussion of how we work without face-to-face meetings as a forci=
ng factor
Current Drafts: 45 min
    * Eventpub
    * Series
    * JSCalendar
    * Subscription Upgrade
    * VAlarm Extensions
    * VPoll
New work: 20 min
    * https://tools.ietf.org/html/draft-douglass-serverside-s=
ubscriptions-00
    * JSCalendar extensions?
    * iSchedule upgrade
Any other business: 20 min
    * Milestone review

See you there!

Bron= .

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

=


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


--a6fade5bb4fe439687caf2276ecdafb6-- From nobody Tue Apr 21 05:59:58 2020 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 481193A0BB2 for ; Tue, 21 Apr 2020 05:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=FIjnadLn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YG59B2w8 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 78tNbugKTO_3 for ; Tue, 21 Apr 2020 05:59:55 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ABCB3A0BB3 for ; Tue, 21 Apr 2020 05:59:55 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id E64937B5; Tue, 21 Apr 2020 08:59:53 -0400 (EDT) Received: from imap28 ([10.202.2.78]) by compute1.internal (MEProxy); Tue, 21 Apr 2020 08:59:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=ExxGY/K JdIj/sR5keDOi0PKe5R3fLtkgjuDJe2tQ0Tk=; b=FIjnadLnNpvdvFfO+OUD4d+ eLDsZPp5IeR6OdvNn+MPEAkyN0CBLTGh4+f/tcGpJ6RVonbZq9V7cf5KFrgcdZdK EbOr8nfFY6BhhYRRwMqg2wzc3UiW1sQoLfYafGYPkr3FZ8emRIn9A1n1Gf8Vxd1s 5OSx2ju/33ITj0NEEfnTTIxYK90Bccg8exCIhSWErUX7z+wEJbBaq+ImG9jhCbg+ jVzp6O2iGYNwM4G/FS9r3zgvP2gLS3282qEMzhmCdtHmXUFR4isj1sKmRmEzB4qx 8LCovNdJ9NDc4xIr+T3ogjtmiGqOR9nDCHax0yhhZI+qmc5TbjALXZUTqDNqeVA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ExxGY/ KJdIj/sR5keDOi0PKe5R3fLtkgjuDJe2tQ0Tk=; b=YG59B2w8Z1SpSXxjn/LONN KTbRbPxHQSEH5HqC/f9pYAyXEWozBQ30X+JJrViCfTiGekeyIDluA2hnU1eZSaIe 0X03LBnIVMUboZUpNdSKeXm0RBqiFekaaAahlbts7JWEA51LDAHqQfM9iobhQ4bl duH7wNr5CUoPvGAhwN+DMB1oCg6GDLchosqrx61IlPgO8CsciCBqWq3QgOhJ29Sz Wtn8Scvxz0t7Z3sr5n3Azz7pqw5njEtFWc+QXgRc2FEZ9rkdZ6nzbI5a21D+ePHh 292tgeupADRZlvIK/EXDRekq7Kz5AsARqG6jkPj2U8WZ4QPIzrhT9Dm9TYiaUjEw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeehgdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpeiiohhomhdruhhspdhivg htfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1ACE024009E; Tue, 21 Apr 2020 08:59:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1152-g08c8976-fmstable-20200420v1 Mime-Version: 1.0 Message-Id: <23a5c7ba-e929-4142-bc63-af6781f72210@dogfood.fastmail.com> In-Reply-To: <169abd3a-d0e7-455f-8f73-c579af42b3dc@dogfood.fastmail.com> References: <169abd3a-d0e7-455f-8f73-c579af42b3dc@dogfood.fastmail.com> Date: Tue, 21 Apr 2020 22:59:32 +1000 From: "Bron Gondwana" To: calsify@ietf.org, calconnect-l@lists.calconnect.org Content-Type: multipart/alternative; boundary=79330a6395e54d63b9e12af9b89fdd91 Archived-At: Subject: Re: [calsify] Reminder - interim meeting TODAY 21 April 2020 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 12:59:58 -0000 --79330a6395e54d63b9e12af9b89fdd91 Content-Type: text/plain Meeting NOW! See you there :) On Tue, Apr 21, 2020, at 10:04, Bron Gondwana wrote: > CALEXT Interim Meeting, 21 April 2020 GMT 13:00 * San Francisco 6am * New York 9am * London 2pm * Vienna 3pm * Melbourne 11pm Video chat: https://zoom.us/j/4574164360 (call in https://zoom.us/zoomconference) Side channel text chat: calext@jabber.ietf.org Etherpad: https://etherpad.ietf.org:9009/p/calext-interim-apr-2020 Welcome and Note Well: 5min (Bron) * Agenda Bash * Discussion of how we work without face-to-face meetings as a forcing factor Current Drafts: 45 min * Eventpub * Series * JSCalendar * Subscription Upgrade * VAlarm Extensions * VPoll New work: 20 min * https://tools.ietf.org/html/draft-douglass-serverside-subscriptions-00 * JSCalendar extensions? * iSchedule upgrade Any other business: 20 min * Milestone review > > See you there! > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --79330a6395e54d63b9e12af9b89fdd91 Content-Type: text/html
Meeting NOW!  See you there :)

On Tue, Apr 21, 2020, at 10:04, Bron Gondwana wrote:
CALEXT Interim Meeting, 21 April 2020 GMT 13:00
* San Francisco 6am
* New York 9am
* London 2pm
* Vienna 3pm
* Melbourne 11pm

Video chat: https://zoom.us/j/4574164360 (call in https://zoom.us/zoomconference)
Side channel text chat: calext@jabber.ietf.org
Etherpad: https://etherpad.ietf.org:9009/p/calext-interim-apr-2020

Welcome and Note Well: 5min (Bron)
    * Agenda Bash
    * Discussion of how we work without face-to-face meetings as a forcing factor
Current Drafts: 45 min
    * Eventpub
    * Series
    * JSCalendar
    * Subscription Upgrade
    * VAlarm Extensions
    * VPoll
New work: 20 min
    * https://tools.ietf.org/html/draft-douglass-serverside-subscriptions-00
    * JSCalendar extensions?
    * iSchedule upgrade
Any other business: 20 min
    * Milestone review

See you there!

Bron.

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



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

--79330a6395e54d63b9e12af9b89fdd91-- From nobody Tue Apr 21 08:05:32 2020 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 5C1083A0DFA for ; Tue, 21 Apr 2020 08:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=bpk865dT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=R8l0JRnM 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 k7MowMBqDwOs for ; Tue, 21 Apr 2020 08:05:24 -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 9BE093A0E74 for ; Tue, 21 Apr 2020 07:53:27 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3EDDA5C00DD for ; Tue, 21 Apr 2020 10:53:26 -0400 (EDT) Received: from imap28 ([10.202.2.78]) by compute7.internal (MEProxy); Tue, 21 Apr 2020 10:53:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=muCHmXM e3OXARj4l/sw5MC0YUqRk4AJnAsPFSgmkL6U=; b=bpk865dTP3xl/qmuP9OdxNI S27HHUk9FmVX7dniKYNWIm1jyxVzuUOguBeAM8TIJgdk0QrRtZXn+Ywb8kVDWeTs /F8vncowk0xoK36yV6l7FPfbMKnizwWL1wtRQTVytW8Drkdp8JzA7dC2NFb3gfTr AOU8l/TWInJ8CdCA2LXhmhvft8lvHqkQtyfLwPHd5hOfbn3m+GsjJWa1C52P0hNr kH3VNSt7pQTDMObxhtRtBBWyyrtg8A0D7qCfYReLPjy5FKPzV2WboMJmU40zw/i5 FoVQ7M+BRGpyGiTfX1yDESwV0hv0tbh4ABB5m2Tbooks6bYHYt4+APIMeAyikyg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=muCHmX Me3OXARj4l/sw5MC0YUqRk4AJnAsPFSgmkL6U=; b=R8l0JRnM4Fx+/1WN4KYM1u /Iwh40hzQ+zW3DvMGU1JipoUTk1QTYWPw8xgfk8C7ikTUSJGP1rqOheFndtmdw80 PHFyZFDbAM4xFEuJBnqHr4ePxQ03DDP0ZVto6q1lPpr9WzpVFvmqeh260/KG2t3p qqi1pUjMWNNbZ1ycvD1a8PMdfY7vA8qacWa4jOAxd89S9O+InsxhbB7/7190s79u FIEWqE1vv5Fqbn/+kHczH6AprRnTG8El5m2M9PYk7KXml+oXvNu5K8Eie8ijsqzT GDM0kQzJsD8PQ9iC1Qq2EGL4lRFGLIeDc1jrFEQdRbgWDvDP/FqjeV2cnIYqBn5A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeehgdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D9FD824009E; Tue, 21 Apr 2020 10:53:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 21 Apr 2020 16:53:05 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=3e8d1c46c877473f9008db3f447516af Archived-At: Subject: Re: [calsify] jscalendar - attachments X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 15:05:29 -0000 --3e8d1c46c877473f9008db3f447516af Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 20, 2020, at 6:30 AM, Michael Douglass wrote: > Trying to come up with examples and I started with the 5545 example > ATTACH:CID:jsmith.part3.960817T083000.xyzMail@example.com >=20 > The jscalendar spec says: > o href: "String" (mandatory) A URI from which the resource may be fetched. This MAY be a "data:" URL [RFC2397 ], but it is recommended that the file be hosted on a server to avoid embedding arbitrarily large data in JSCalendar object instances. o cid: "String" (optional) This MUST be a valid "content-id" value according to the definition of Section=C2=A02 in [RFC2392] . The value MUST be unique within this Link object but has no meaning beyond that. It MAY be= different from the link id for this Link object. >=20 > Should it be one of href or cid is mandatory? If not how is the above = represented href should be the only mandatory property of a Link object. This partic= ular example would map to a Link object with href set to the CID URL. The cid property in a JSEvent only is useful if the description of the e= vent is formatted in HTML. The description could then contain something = like and reference a particular a Link tha= t way. BTW, I don't understand the idea behind this example in RFC5545. A CID U= RL attachment in a stand-alone VEVENT doesn't make sense to me. I could = only imagine it to be useful if the iCalendar data is a text/calendar pa= rt of some MIME message, where some other body part has the "Content-Id"= header set to that CID URL. Probably I'm missing something here? Cheers, Robert --3e8d1c46c877473f9008db3f447516af Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, Apr 20,= 2020, at 6:30 AM, Michael Douglass wrote:

Trying to come up with examples and I started with th= e 5545 example

      ATTACH:CID:jsmith.part3.960817T083000.xyzMail@example.com

The jscalendar spec says:

=
   o  href: "String" (mandatory)

      A URI from which the resource may be fetched.

      This MAY be a "data:" URL [RFC2397], but it is recommended =
that
      the file be hosted on a server to avoid embedding arbitrarily
      large data in JSCalendar object instances.

   o  cid: "String" (optional)

      This MUST be a valid "content-id" value according to the
      definition of Section 2 in [RFC2392].  The value MUST be unique
      within this Link object but has no meaning beyond that.  It MAY be=

      different from the link id for this Link object.

Should it be one of href or cid is mandatory? If not how is= the above represented


href sho= uld be the only mandatory property of a Link object. This particular exa= mple would map to a Link object with href set to the CID URL.
<= div>
The cid property in a JSEvent only is useful if the d= escription of the event is formatted in HTML. The description could then= contain something like <img src=3D"cid:myimagecid"/> and reference a particular a Link that = way.

BTW, I don't understand the idea behin= d this example in RFC5545. A CID URL attachment in a stand-alone VEVENT = doesn't make sense to me. I could only imagine it to be useful if the iC= alendar data is a text/calendar part of some MIME message, where some ot= her body part has the "Content-Id" header set to that CID URL. Probably = I'm missing something here?

Cheers,
Robert


--3e8d1c46c877473f9008db3f447516af-- From nobody Wed Apr 22 05:16:08 2020 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 567793A0ADB for ; Wed, 22 Apr 2020 05:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Z41LdOlU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IdC4hDFn 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 PMiTKBzMw8VV for ; Wed, 22 Apr 2020 05:15:41 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B17B3A0AD5 for ; Wed, 22 Apr 2020 05:15:41 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DAE1D5C0083; Wed, 22 Apr 2020 08:15:40 -0400 (EDT) Received: from imap28 ([10.202.2.78]) by compute1.internal (MEProxy); Wed, 22 Apr 2020 08:15:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=cf4P8AmexPexnbxXHoBXy3OW0ZkrCzB8g3c1db/ GC2I=; b=Z41LdOlURlu7gam3mJP9X/8RSbMN1EYDJsDkN1Sljrk0B5tceMDO3zk kg27my6fdqtOK0UUFGIvoCw+98SuCPJ/Ckch36FSzUlnx9IbHcQQ0aQ9fXXpNjvK O/a554xoFlg0sJ0smoMDlv+D7vr+ReYD0aSrxxZKqyPE6qtR0iyxrpiQ6I+4eVYz c2SRO+vov6ENXMk2BZ48cYwV2SAEUUSmbZjM3AjZNQ3+NiEAqQwc0zPrBZOIXXXA Rua5c5VNYJJHqHgD/hYcLKYEuwL2tpK+af2RzkHD+vRB1KvAsnhwARtc9umLGIrf IfHZbvjhhK1g2xwCD/3172BowFhbVmg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=cf4P8AmexPexnbxXHoBXy3OW0ZkrC zB8g3c1db/GC2I=; b=IdC4hDFnb+XWEmcCivJhxXreK6Bu5KiXt648pds5kbtkG /t6hxwHbBWVQlfBkq/sWcmPtaDwzYMoWVq5GpdXoztv0R9Br/phT9dnk3J107xpU OlIfJUrCdfuC4E/P+SXmWvhxJbABzam3s65rR2YMknCksJ235jT+y8SpoZU39zYH 7p5+7SZHs5tGlvlkcutcuZT20atXcvJhbAD9NVJCsB3K3I5c8QB78psMXHN81Ex5 MhH7XJnxIUZpcYoLNiP4yybxOCm/pVnnwJnEeJh7Mk1cUQx1EoWKyAUNOLNiqMYL Kro0dm41mwflBJRJWMR4Hw/5phAS+2mOefJvWAtRA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeejgdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghdphhgrtg hkmhgurdhiohenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 403C524009F; Wed, 22 Apr 2020 08:15:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <05ebdd4e-b35e-4615-966f-41ea066a000c@dogfood.fastmail.com> Date: Wed, 22 Apr 2020 22:15:19 +1000 From: "Bron Gondwana" To: calsify@ietf.org, calconnect-l@lists.calconnect.org Content-Type: multipart/alternative; boundary=10c58e0cd6f94949b9592eb916ffdcff Archived-At: Subject: [calsify] Minutes of Interim Meeting and action points. X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 12:15:46 -0000 --10c58e0cd6f94949b9592eb916ffdcff Content-Type: text/plain The minutes are up - canonical URL: https://datatracker.ietf.org/meeting/interim-2020-calext-01/materials/minutes-interim-2020-calext-01-202004211400 Action Points from the meeting are as follows: *Barry:** * * Barry to review EVENTPUB updated security wording from Mike *Bron:** * * Bron to issue WGLC for VAlarm Extensions * Bron to issue Call for Adoption of Serverside Subscription draft. * Bron to update milestones for CALEXT working group *Henk:** * * Henk to prepare CDDL spec for JSCalendar format and send to the mailing list *Ken:** * * Ken to work with Mike on iterating VPoll spec *Mike:** * * Mike to put information in the security section of eventpub and add text to each of the URIs referencing it - and check that change directly with Barry * Mike to look at subscription upgrade draft again * Mike to update series draft * Mike to work with Ken on iterating VPoll spec *Robert:* * Robert to reply to Mike's email to the list about JSCalendar implementation experience Full minutes pasted below for your convenience: Minutes - CALEXT Virtual Interim, 21 Apr 2020 GMT 13:00 - 14:30 Agenda: = Welcome and Note Well: 5min (Bron) * Agenda Bash * Discussion of how we work without face-to-face meetings as a forcing factor Current Drafts: 45 min * Eventpub * Series * JSCalendar * Subscription Upgrade * VAlarm Extensions * VPoll New work: 20 min * https://tools.ietf.org/html/draft-douglass-serverside-subscriptions-00 * JSCalendar extensions? * iSchedule upgrade Any other business: 20 min * Milestone review Minutes: = Agenda Bash: == * Henk Leaving early and wants to talk about JSCalendar, so we'll promote JSCalendar to earlier. * Forcing factor - we acknowledged that it's an issue, but didn't get time at the end to discuss further. Eventpub: == * Notes from Singapore were: "put the data in, URI for updates" - or maybe even wait for a BCP on usage of URIs in data formats. * Mike: * The extended question is how to handle URI in general. There is no one rule fits all to determine if the URI needs to be downloaded or not. * The situation is similar to CONTACT in RFC5545 - a link to a VCARD would be more likely to be always uptodate (Bron: but it is also more likely to change or go away - bad for archival, maybe we don't care in every use case) * Can we say "URLs SHOULD NOT be automatically downloaded unless the user has turned on an option". Also talk about phishing and tracking in the security considerations. * It would be better to have a BCP to refer to, but we don't want to block this. * There may be things in eventpub which would be good to change for jscalendar too, we'll see when we get there. * Barry: should not wait for a BCP on it, though we probably should work on a document. Recommending at a non normative level that the use be request. The problem is clearly to the use of URI to distribute malware. It doesn't need to be heaps, just a few paragraphs. ACTION: Mike will put information in the security section and add text to each of the URIs referencing it - and check that change directly with Barry. JSCalendar: == * Mike has been working on a library for jscalendar similar to ical4j. * Maping does not seem explicit enough with many more MUST. The conversion needs to be deterministic because both formats will co-exist for the next 10+ years, so data will roundtrip between them multiple times. * Issues like: "where do you put the location property" and if you have more than one, which one is the default. The one associated to GEOLOC should be tagged explicitly. * Similar issues with contact property. There needs to be something on the one which is the default to say "this is the one that is special in icalendar" - they have to be a participant in JSCalendar, but then how do you know which was the contact in the original ICalendar? * Robert: very keen to define an exact set of mapping. Don't want it to be part of JSCalendar, should be a separate doc. Would very much not like to bake into the JSCalendar format translation guidelines. * Mike: agree we have to be able to move on, but also have to coexist. Anything new in ICALENDAR has to be compatible with JSCalendar - but it needs to be able to round-trip for now. * We must at least reserve some rel types and add flags to participant, etc. * Mike has started building a list. * Discussion of "ATTACH" becoming a link type, and what it means to update just an attachment on an override. Talked about deep patches. * Daniel: we've already got things as two documents with the translation guide. * Mike: doesn't matter if it's one document or two. But they're linked and we need to complete them together. There's many years of dealing with the upgrade issues in ICalendar. Think it would be better in one document - but either way, think we can't say JSCalendar is done until we've got the mapping. * Best way to find issues is to go through RFC5545 and try mapping each property and see what comes up. * Lots of discussion about versioning and whether it's necessary: * Mike says yes * Many others "you can always add new properties, if you're updating existing then it's fraught regardless of version numbers". * Bron: if your software only knows about 3.2 and 3.3 comes along, can you process anything at all if you don't know what semantics have changed? Better to add new fields (extend the API) and deprecate existing ones so software can generate one or the other. * Henk is interesting in JSCard - doing IETF versions of schemas for JSON (CBOR): * Big fan of ical and vcard. * Interested in this work in general. * Maybe we would be interested in having this in a formal data language? * Would be able to have a well definied structure. * At the moment it's complex and maybe ambiguous wording. * Mike: short answer: yes we're interested. How it's packaged matters. * Robert: any machine readable description is always good. * Don't know if it would be need to be put into the spec? * Effort is definitely of value. * Mike: would be great if the IETF didn't treat these documents as immutable! (we got sidetracked into that chestnut for a while) * Henk: data definition could include extension points. The formal definition can handle extensions. * Daniel: when do you think you could do it by? * Henk: Took about 3 hours to create a specific definition for JSContact: - https://hackmd.io/Cyjqhux8SYaEIkf4ylPImg?edit - Written in RFC8610 CDDL. * Robert: are there any RFCs written in it yet? * Henk: So far only COSE, but it wasn't an RFC yet. There are about 40 drafts now using it. * Bron: main risk is which one is the normative if there's a difference. * Alexey: we can specify which in the document. Discussion of versioning: with objects you can avoid items that you don't know. From the WG discussions, there is not a consensus on whether the version needs to be added or not. This needs to be discussed in more detail on the list. ACTION: Henk will send something to the list in the next few days with a CDDL spec. ACTION: Robert will answer Mike's email about implementation experience. Series: == * pretty much where it was last time. ACTION: Waiting for Mike to update it. Subscription Upgrade: == * No change since last time. ACTION: Mike will look at again. VAlarm Extensions: == * Ken updated with initial text back in December. * Also re-introduced the "related-to" property to snoozed reltype. * Daniel: main aspect is "don't ignore privacy concerns" but nothing more we can do. Just need to acknowledge that there is a risk. * Bron: Should we just do a WGLC and see if any objections come up. * Robert: were there default alarms defined? * Ken: we removed it, because there wasn't a way to tell. Apple does something crazy with alarms set back in the past as a hacky way to override default alarms. * Robert - agree that we shouldn't add it back. Also messy with old default alarms. * Suggest - separate draft to handle default alarms. * Mike: default alarms is nice - could implement it if you don't have icalendar baggage. We could do it nicely in JSCalendar. Don't need to update this draft. ACTION: Bron to issue WGLC. VPoll: == * Have made the changes, but there's still iterating to do. ACTION: Mike and Ken will continue iterating (again) and discuss on the list. Serverside Subscription: == * Apple already have an implementation * This is still a personal draft - we should adopt the work and see if we can get Apple to help us make it match their implementation. ACTION: Bron to do Call for Adoption with existing draft starting point. Milestones: = * JSCalendar - if we push on, June 2020 * VAlarm - May 2020 * Scheduling Controls - May 2020 * VPoll - Oct 2020 * Series - leave at June 2020. * Subscription Upgrade - July 2020. * Server Side Subscription - do by Oct 2020. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --10c58e0cd6f94949b9592eb916ffdcff Content-Type: text/html Content-Transfer-Encoding: quoted-printable
The minutes are up - canonical URL:

Action P= oints from the meeting are as follows:

Barry:
* Barry to review EVENTPUB= updated security wording from Mike

Bron:
* Bron to issue WGLC for VAlar= m Extensions
* Bron to issue = Call for Adoption of Serverside Subscription draft.
* Bron to update milestones for CALEXT working grou= p

Henk:
* Henk to prepare CDDL spec for JSCalendar format and send to th= e mailing list

Ken:
* Ken to work with Mike on iterating VPoll spec
<= /div>

Mike:
* Mike to put information in the security section of eventpub and add = text to each of the URIs referencing it - and check that change dir= ectly with Barry
* Mike to lo= ok at subscription upgrade draft again
* Mike to update series draft
* Mike to work with Ken on iterating VPoll spec

Robert:
* Robert to reply to Mike's email to the list about = JSCalendar implementation experience


Full minutes pasted below for your convenience:<= br>

Minutes - CALEXT Virtual Interim, 21 Apr 2020 GMT 13:00 -= 14:30

Agenda:
= =3D

Welcome and Note Well: 5min (Bron)
    * Agenda Bash
    * Discussion of how we w= ork without face-to-face meetings as a
      forcing factor
Current Drafts: 45 min
    * Eventpub
    * Series
    * JSCalendar
    * Subscription Upgrade
=
    * VAlarm Extensions=
    * VPoll
New work: 20 min
    * https://to= ols.ietf.org/html/draft-douglass-serverside-subscriptions-00
    * JSCalendar exte= nsions?
    * = iSchedule upgrade
Any other b= usiness: 20 min
  &= nbsp; * Milestone review

=
Minutes:
=3D

<= /div>
Agenda Bash:
=3D=3D
<= br>
* Henk Leaving early and want= s to talk about JSCalendar,
&= nbsp; so we'll promote JSCalendar to earlier.
* Forcing factor - we acknowledged that it's an issue, = but
  didn't get time at= the end to discuss further.
=
Eventpub:
=3D=3D

* Notes from Singapore we= re: "put the data in, URI for updates" - or maybe
  even wait for a BCP on usage of URIs in data= formats.
* Mike:
   * The extended question is = how to handle URI in general. There is
     no one rule fits all to determine if = the URI needs to be
 &nb= sp;   downloaded or not.
   * The situation is similar to CONTACT in RFC5545 - a = link to a VCARD
  &= nbsp;  would be more likely to be always uptodate (Bron: but it is = also
    = more likely to change or go away - bad for archival, maybe we don't
=
     care in= every use case)
* Can we say= "URLs SHOULD NOT be automatically downloaded unless the
  user has turned on an option".  = Also talk about phishing and tracking
  in the security considerations.
* It would be better to have a BCP to refer to, but w= e don't want to
  block = this.
* There may be things i= n eventpub which would be good to change for
  jscalendar too, we'll see when we get there.
<= /div>
* Barry: should not wait for a BC= P on it, though we probably should
  work on a document. Recommending at a non normative level t= hat the
  use be request= . The problem is clearly to the use of URI to
  distribute malware.  It doesn't need to be = heaps, just a few paragraphs.

ACTION: Mike will put infor= mation in the security section and add
        text to each of the= URIs referencing it - and check that
        change directly with= Barry.

JSCalendar:
=3D=3D

* Mike has been working on a library for jscal= endar similar to ical4j.
* Ma= ping does not seem explicit enough with many more MUST. The conversion
  needs to be determinist= ic because both formats will co-exist for the
  next 10+ years, so data will roundtrip between t= hem multiple times.
* Issues = like: "where do you put the location property" and if you have
=
  more than one, which one is the= default. The one associated to GEOLOC
  should be tagged explicitly.
* Similar issues with contact property.  There nee= ds to be something on
  = the one which is the default to say "this is the one that is special
=
  in icalendar" - they have= to be a participant in JSCalendar, but then
  how do you know which was the contact in the orig= inal ICalendar?
* Robert: ver= y keen to define an exact set of mapping.  Don't want it to
  be part of JSCalendar, should= be a separate doc. Would very much not
  like to bake into the JSCalendar format translation gu= idelines.
* Mike: agree we ha= ve to be able to move on, but also have to coexist.
  Anything new in ICALENDAR has to be compatib= le with JSCalendar - but
&nbs= p; it needs to be able to round-trip for now.
* We must at least reserve some rel types and add flags= to participant,
  etc.<= br>
* Mike has started building a= list.
   * Discuss= ion of "ATTACH" becoming a link type, and what it means to
     update just an at= tachment on an override.  Talked about deep patches.
* Daniel: we've already got things as two d= ocuments with the translation
  guide.
* Mike: doesn'= t matter if it's one document or two.  But they're linked
=
  and we need to complete them to= gether.  There's many years of dealing
  with the upgrade issues in ICalendar.  Think = it would be better in one
&nb= sp; document - but either way, think we can't say JSCalendar is done unt= il
  we've got the mappi= ng.
* Best way to find issues= is to go through RFC5545 and try mapping each
  property and see what comes up.
* Lots of discussion about versioning and wh= ether it's necessary:
  = * Mike says yes
  * Many= others "you can always add new properties, if you're updating
=
    existing then it's = fraught regardless of version numbers".
  * Bron: if your software only knows about 3.2 and 3.3 = comes along, can
  =   you process anything at all if you don't know what semantics have=
    changed?&= nbsp; Better to add new fields (extend the API) and deprecate
<= div style=3D"font-family:Arial;">    existing ones so sof= tware can generate one or the other.
* Henk is interesting in JSCard - doing IETF versions of schemas=
  for JSON (CBOR):
<= /div>
  * Big fan of ical and vcar= d.
  * Interested in thi= s work in general.
  * M= aybe we would be interested in having this in a formal data language?
  * Would be able to have = a well definied structure.
&n= bsp; * At the moment it's complex and maybe ambiguous wording.
=
  * Mike: short answer: yes we're= interested.  How it's packaged matters.
  * Robert: any machine readable description is al= ways good.
  * Don't kno= w if it would be need to be put into the spec?
  * Effort is definitely of value.
  * Mike: would be great if the IETF d= idn't treat these documents
&= nbsp;   as immutable! (we got sidetracked into that chestnut f= or a while)
  * Henk: da= ta definition could include extension points.  The formal
=
    definition can hand= le extensions.
  * Danie= l: when do you think you could do it by?
  * Henk: Took about 3 hours to create a specific defin= ition for JSContact:
     - Written in RFC8610 = CDDL.
  * Robert: are th= ere any RFCs written in it yet?
  * Henk: So far only COSE, but it wasn't an RFC yet.  Ther= e are about
   = ; 40 drafts now using it.
&nb= sp; * Bron: main risk is which one is the normative if there's a differe= nce.
  * Alexey: we can = specify which in the document.

Discussion of versioning: = with objects you can avoid items that you don't
know. From the WG discussions, there is not a consens= us on whether the
version nee= ds to be added or not. This needs to be discussed in more
detail on the list.

ACTION: = Henk will send something to the list in the next few days with a
      =   CDDL spec.

<= div style=3D"font-family:Arial;">ACTION: Robert will answer Mike's email= about implementation experience.

Series:
=3D=3D

* pretty much where it= was last time.

ACTION: Waiting for Mike to update it.


Subscription Up= grade:
=3D=3D

= * No change since last time.
=
ACTION: Mike will look at ag= ain.

VAlarm Extensions:
=3D=3D

* Ken updated with initial text back in = December.
* Also re-introduce= d the "related-to" property to snoozed reltype.
* Daniel: main aspect is "don't ignore privacy concer= ns" but nothing
  more w= e can do.  Just need to acknowledge that there is a risk.
=
* Bron: Should we just do a WGLC and s= ee if any objections come up.
* Robert: were there default alarms defined?
* Ken: we removed it, because there wasn't a way to tel= l.  Apple does
  so= mething crazy with alarms set back in the past as a hacky way to
  override default alarms.
<= /div>
* Robert - agree that we shouldn'= t add it back.  Also messy with old
  default alarms.
* Suggest - separate draft to handle default alarms.
* Mike: default alarms is nice - could imp= lement it if you don't have
&= nbsp; icalendar baggage.  We could do it nicely in JSCalendar. = ; Don't need
  to update= this draft.

ACTION: Bron to issue WGLC.

V= Poll:
=3D=3D

*= Have made the changes, but there's still iterating to do.

ACTION: Mike and Ken will continue iterating (again) and discuss on th= e list.

Serverside Subscription:
=3D=3D

<= /div>
* Apple already have an implement= ation
* This is still a perso= nal draft - we should adopt the work and see
  if we can get Apple to help us make it match thei= r implementation.

<= div style=3D"font-family:Arial;">ACTION: Bron to do Call for Adoption wi= th existing draft starting point.

Milestones:
=3D
  * JSCalendar - if we push on, June 2020
  * VAlarm - May 2020
  * Scheduling Controls - May 2020
  * VPoll - Oct 2020
  * Series - leave at June 2020.
  * Subscription Upgrade - Ju= ly 2020.
  * Server Side= Subscription - do by Oct 2020.

--
  Bron G= ondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.c= om


<= /div> --10c58e0cd6f94949b9592eb916ffdcff-- From nobody Wed Apr 22 05:22:55 2020 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 6D3643A0B02 for ; Wed, 22 Apr 2020 05:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=gGEOmkBO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HgSqqSgO 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 Lt9SWmH_u2WY for ; Wed, 22 Apr 2020 05:22:53 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 035603A0A80 for ; Wed, 22 Apr 2020 05:22:52 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4C4545C0144 for ; Wed, 22 Apr 2020 08:22:52 -0400 (EDT) Received: from imap28 ([10.202.2.78]) by compute1.internal (MEProxy); Wed, 22 Apr 2020 08:22:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=4CD8sjECNuxoK8Xc3slCvg/vFWZKngMF4wu3vDE tPzY=; b=gGEOmkBOqkYPtncviN4AN14OKep4ULEbFKIvPjd1c9vDO8/jLnMhP9z 3ZhPdTaUnN87O/uRi/Yi70zeRsSl5McLKk+P5J8ZjuqtshZdwJISuKReWDuNzNqF DZmqmSpl2qAplekVUv1jKb2oywt/RbM1UgR2+7i7CA40hImEAYx3/tYBvjdKsOUe e+mDoJlULuPfW/K/yI+z8s/2PeBPOStnfLfBINgS8hsEmA4k/jGwoiULbtFeoxpi cVoUb6LCgcWkU/3OCOfODgQ84Vtugaaz0wbQAyyL1Zo5DOg1WH8u2iyHXwAPRjr6 b/7IDF4oBsnHayyCqn9l/uchQTUoVTA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=4CD8sjECNuxoK8Xc3slCvg/vFWZKn gMF4wu3vDEtPzY=; b=HgSqqSgO/8CrUMgi3Vs/wKf/Y9RS/mmy5fP7uVeG4UL8w IRqdQdMQU0iqwJiLYMfT19gIh+1qCPD4NlfSqarblHUp64L2E7c0bTIlyYlYSnbi 3aWstTcYB4JtEmnZJQJoQmK8r4RE7kU0bD9RDBDpaOVCDHyniDpAkBL2BXciDYfR bBvvuh+m5kIvhsWPBL6IJnjmgsPR+thGo1UNbVv0c4HIhkorBlY4+QrurNQuPu6q xJl/uAwRdnwChi8T74w+fF9K2TJu291Uw5hKmquBzCpkEyA19/z+PTfPA7n9qQKF LFjxsNScSR7NJkPGg2/M8KViCwEjVHoJx37u86MUQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeejgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D5D2E24009E; Wed, 22 Apr 2020 08:22:51 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <280f31e7-ffdc-4ef0-a95e-aa03dc40a28a@dogfood.fastmail.com> Date: Wed, 22 Apr 2020 22:22:30 +1000 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=447c024a967c45529bf901108b882c12 Archived-At: Subject: [calsify] Call for adoption: draft-douglass-serverside-subscriptions X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 12:22:55 -0000 --447c024a967c45529bf901108b882c12 Content-Type: text/plain The draft is expired, but it's here: https://datatracker.ietf.org/doc/draft-douglass-serverside-subscriptions/ As per the virtual interim meeting yesterday, there is interest in this work. This draft would be a starting point, but is not necessarily the final product. If you have any issues with this working group taking on the work, please reply here by *Wednesday May 6th.* Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --447c024a967c45529bf901108b882c12 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

As per the virtual interim meeting yesterday, there is int= erest in this work.

This draft would be a starting point,= but is not necessarily the final product.

If you have an= y issues with this working group taking on the work, please reply here b= y Wednesday May 6th.
<= br>
Cheers,

Bron.

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

=

--447c024a967c45529bf901108b882c12-- From nobody Wed Apr 22 05:30:30 2020 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 2D5673A0B3E for ; Wed, 22 Apr 2020 05:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=cwDw2uKb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=X4wkVLpq 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 fAB-E8mKZwHK for ; Wed, 22 Apr 2020 05:30:23 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5933A0C48 for ; Wed, 22 Apr 2020 05:30:13 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 988EB5C0181 for ; Wed, 22 Apr 2020 08:30:12 -0400 (EDT) Received: from imap28 ([10.202.2.78]) by compute1.internal (MEProxy); Wed, 22 Apr 2020 08:30:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=+Q2nz4U6jeizag4eB0gKW1erraV5/GFA50dIZm5 iSSY=; b=cwDw2uKbjcj97kfGQE45pYQgp7QdwsDMZyVUe/QbJfLZqJAwr0eTTar PEFrIgQkWiCNyB1OL7wosuzthcM2IUwxrCKOGVpa9sCT92l3yWKo67MgHbEoi4lN Uzylo2ncnfhl/zGMmXnau7GBDtnRutxbVSjawHlxqVl7PAn8+IcjJkeVSNAxOb1v 8oY+GiWeuchqUeFL2u4P8BhqxjFiVWel0fmuNbtq+VxuHamak6zmWeIRuu5P/d89 bpGFrp5f2MJvPD7wI+jruVK2sVienucoqPS0NMw/zweS2LU3ZzFXidWXiEZyMLIe CMkYoJ1DQ0felzQLEa7FoPt3pvzxAHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=+Q2nz4U6jeizag4eB0gKW1erraV5/ GFA50dIZm5iSSY=; b=X4wkVLpqeq6CRC6B/75HWW2/42bxXsKPa94Cz1rxutUjx +nZuaP7VfFJrXb2FeUKI/NuLqCo8DsPkb+7MkSh/6yOrS1+Elr/ULtf/v29YaMTw XI5Hc93H19WrMCWpgLG+mObLtmWgxNf55h6NfgwvYvcflLpyJDQ+/WVl//5ekyFR cAi1Et6gKaxKKu+xG6HrCn4iNxNOS1qqXKUOuYITzglqCStuMEgOilKG+52xuJ99 eNAOThdfZEKMfTbWYrrafZY8cur+D264F9To6gWe5u1zyfVsfzL6vyyvL0gQGjJi s1XJHI7xVkRmoULi51JuqfZnwMSAIW0wAYZ6GQY8Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeejgdeglecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6976A24009F; Wed, 22 Apr 2020 08:30:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <1e51cd80-feac-4fbf-87dd-5528599d836d@dogfood.fastmail.com> Date: Wed, 22 Apr 2020 22:29:20 +1000 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=a12da3b7b6c0424a8baacd7a87afb2a7 Archived-At: Subject: [calsify] Working Group Last Call: draft-ietf-calext-valarm-extensions-01 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 12:30:26 -0000 --a12da3b7b6c0424a8baacd7a87afb2a7 Content-Type: text/plain As there's been no feedback on the list about this document and Ken believes it's complete, we agreed in yesterday's interim meeting to take this one to WGLC. We'll make it 3 weeks, so you have until *Wednesday 13 May *to review and respond to this document. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --a12da3b7b6c0424a8baacd7a87afb2a7 Content-Type: text/html
As there's been no feedback on the list about this document and Ken believes it's complete, we agreed in yesterday's interim meeting to take this one to WGLC.

We'll make it 3 weeks, so you have until Wednesday 13 May to review and respond to this document.

Cheers,

Bron.

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


--a12da3b7b6c0424a8baacd7a87afb2a7-- From nobody Wed Apr 22 05:35:53 2020 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 66B123A0B1E for ; Wed, 22 Apr 2020 05:35:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158755895240.24566.14950246150800805381@ietfa.amsl.com> Date: Wed, 22 Apr 2020 05:35:52 -0700 From: IETF Secretariat Archived-At: Subject: [calsify] Milestones changed for calext WG X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 12:35:52 -0000 Changed milestone "Update charter/milestones to reflect current and planned work", resolved as "Done". Changed milestone "Submit valarm document to IESG for publication", set due date to May 2020 from December 2019. Changed milestone "Submit scheduling controls document to IESG for publication", set due date to May 2020 from February 2020. Changed milestone "Send JSCalendar draft to IESG", set due date to June 2020 from December 2019. Changed milestone "Submit vpoll document to IESG for publication", set due date to October 2020 from April 2020. URL: https://datatracker.ietf.org/wg/calext/about/ From nobody Wed Apr 22 06:19:51 2020 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 ED0A13A0C0E for ; Wed, 22 Apr 2020 06:19:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158756158795.18028.9888581215407659697@ietfa.amsl.com> Date: Wed, 22 Apr 2020 06:19:47 -0700 From: IETF Secretariat Archived-At: Subject: [calsify] Milestones changed for calext WG X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 13:19:49 -0000 Changed milestone "Adopt a draft for Server Side Subscription", set state to active from review, accepting new milestone. Changed milestone "Submit Subscription Upgrade document to IESG for publication", set state to active from review, accepting new milestone. Changed milestone "Submit Serverside Subscription draft to IESG for publication", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/calext/about/ From nobody Wed Apr 29 20:13:58 2020 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 E58E13A0EB3 for ; Wed, 29 Apr 2020 20:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 O4GeG-lyshhH for ; Wed, 29 Apr 2020 20:13:51 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 5CA463A0E91 for ; Wed, 29 Apr 2020 20:13:51 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id i16so4548217ils.12 for ; Wed, 29 Apr 2020 20:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=QasvU/E9owRkFE1kT2CUFVCCArNDmhxK/pUJ4wCssPo=; b=X+f4wyf9nqhQDT9rOsYhMipHOAh0mgfR0G48hFxl/nBNkUruJ9qJcvwuMNq4zj/NtM II69rnyVrKo9UFHs/ZwxhMcxLSHXfqckaeL2QYXKNgQ4kVORGdxIwTSUUFj+1iZPrkHz J8eGNTkd9MN/nk//wgJ055gi8hZKkAwfu4Ejy21z3zhzCgIc6gdzl4yPW7PfBLZh7zC+ 0vZYnN91F090iGjVWEVSijL0V4axrIxpK2pUVgN3jQyhloZYpPtNSEpnwcyIiWAUjcco DHsCBPhIsE6ha1ESX0PCoFKOMZQKz8T08Glae2zVjeAmHTmJTwS7rk2O/YZtC0zsg9sQ tWyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=QasvU/E9owRkFE1kT2CUFVCCArNDmhxK/pUJ4wCssPo=; b=nuLTiHzISj1kPHItNvnq/A1RBAKcfIeU55vbxaGHK1dJZ4XDttIIsf7d3b8RPVFRld ocMG/YhveX8/l+Sy46G8TC2cufTk/v6tgua3fpmIJYyi5KNgeCoBNXvWreQyU6D4T9Vo 7DIEityakDgD5r41bPsBbnVb06kDqighuFIZ2gJvfil0jtr1wAdnhlnJdxVr9FP3eS0U 7wHefl8UGxNLVzkBVwejt9T0o+QsGIGgAN+v2QC5wrbi0EvP/jL3byz90rJ48bCSJYP/ MNNYDRGwFYbaUCoWUoZxhQQ12+Oyyd3w0kcGDBf8tRAuwQNlu6hk7De6r+CucQQxtHyL 56uw== X-Gm-Message-State: AGi0PuZbDtY1DKKx5e9Kbkf39k9qLiDit2FEa0v6l9Gwd3/J1Dw9mfhg i5n9mpNF1CuP/s/LwEzLZGeoaC7E4RY= X-Google-Smtp-Source: APiQypIwJZF0jLTQFblRR1AfXFz7vLGo70w4UhSfRmGra0TnnVbFgDqg8Ua2UD/bHaA3t9mrsPIW3Q== X-Received: by 2002:a92:cb42:: with SMTP id f2mr1521060ilq.101.1588216430255; Wed, 29 Apr 2020 20:13:50 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id n23sm1528510ioh.6.2020.04.29.20.13.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Apr 2020 20:13:49 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: Date: Wed, 29 Apr 2020 23:13:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [calsify] JSCalendar and eventpub - participant and contacts X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 03:13:57 -0000 There's no mapping suggested for CONTACT which is vital for event publication. I'd suggest following the approach in eventpub - add a participantType property to jscalendar participant. e.g. "participantTypes": {"attendee": true} Changing role "attendee" to "required" or "expected" might make sense also. Also bringing jscalendar participant into line with eventpub extensions so we can do a consistent mapping between them. This means adding the following to jscalendar: order -  Positive number. structuredData - with "encoding" and "value" properties. The current CONTACT property is a plain text value and typically has no more than a phone number (which was one of the points of eventpub). To deal with the current situation we need to have a place to put that phone number. As a fallback I considered encoding the value as a data uri. I'm not that keen on the idea so perhaps we need a jscalendar and eventpub property to hold a plain-text value. I'd rather not call it value or text as both names turn up in parameters and types. plainText? There are a couple of additional changes needed to eventpub: PARTICIPANT-TYPE needs to be allowed more than once and ATTENDEE should be added as a value. Comments? From nobody Thu Apr 30 06:28:33 2020 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 0D0783A09E8 for ; Thu, 30 Apr 2020 06:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=lY2llHIK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VPY6F29x 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 N2Rdel6QoRDo for ; Thu, 30 Apr 2020 06:28:29 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5813A09E4 for ; Thu, 30 Apr 2020 06:28:29 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8DE175C00DD for ; Thu, 30 Apr 2020 09:28:28 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute7.internal (MEProxy); Thu, 30 Apr 2020 09:28:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=UIMIzXe I4ODCkI6xyQLNlaJLWkxPW/yc1VFA8jcuyWg=; b=lY2llHIKJXAkBvq7yyQhEBb +WVMPOHaNRB6TmwhXb+nufkg37YweO40CqBVeGiWZ6VMbVTUFPjpSDm+plp0sXWW KWR8Pn88YMOR5o9T6sQjjvZWlDr7HsTGIGmpEWlYUQfHIBVdCcZaS3LFOuQwPi5i mzEdCa00fNwpOjKL2Oolf0P5DZKrcnzWR0xUMeG/KB5jKHsWEBw0AdDQYCmGjA8E a3GJeeeFb4WnDaqbNTBBrFDsyWhS2pCpnTUyzQF/kLnD3kCrMnU/5iKecL4w3dIB QzNh43yVlvIOY0Nnx6uG0HFtCleR/rSBsQnCGe+NUxXMhOvCQc5Z5JCoKRvJ/6g= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=UIMIzX eI4ODCkI6xyQLNlaJLWkxPW/yc1VFA8jcuyWg=; b=VPY6F29x03dZ29hrm4jqsy fW4ByoGSEfKxHRmMR7xi46MDU7anqGJLqfWtAnvPLtitWPJmi25G7iGCHG/18f72 Gaw6X9OBRZuIafDZxww2tf6ENJvQeXABAueR26022MBNEBP8QuI/FdglVfBIei6J JupNRPn1pEAw4zAwnzbhJJirbSyDrQFbVRJRyCPObDQJFBkJ7rufrvCInqo0BWDM Rl+v7barfG+g16pJqaSkWJQylU4NLsF7aAslcNrVeXPZd2Ff7iKX2umWnLh3nROU weUQO2kWLbhWYYxLWpuPCVZAH63pjVHDE6O0M8tJRck8wym9MmBr2ZR9eHHezWtQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieehgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeehgeeuvddtke fhtefgueefgfdvueetgeeffeelhedvudegjeejhfetuefgveevieenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2C3E4180091; Thu, 30 Apr 2020 09:28:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <7e0ab50b-3a6a-4d79-8903-7974e8b47247@www.fastmail.com> In-Reply-To: References: Date: Thu, 30 Apr 2020 15:28:06 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=e17f5037d64c47a7b7e20e51f7cecd50 Archived-At: Subject: Re: [calsify] JSCalendar and eventpub - participant and contacts X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 13:28:31 -0000 --e17f5037d64c47a7b7e20e51f7cecd50 Content-Type: text/plain Hi Mike, On Thu, Apr 30, 2020, at 5:13 AM, Michael Douglass wrote: > There's no mapping suggested for CONTACT which is vital for event > publication. CONTACT allows both textual representation and a URI value. We could register a new "content" rel type at IANA and use a JSCalendar Link object? It could point to a VCARD, include free text in a data: URI (with an according text/plain contentType), or later also point to a JSCard. > I'd suggest following the approach in eventpub - add a > participantType property to jscalendar participant. > e.g. > "participantTypes": {"attendee": true} Wouldn't it be enough to map these participant types to a JSCalendar Participant role? All that would need to be done is to add their definition to the JSCalendar IANA Enum registry. The JSCalendar spec for Participant roles explicitly allows this. > Changing role "attendee" to "required" or "expected" might make sense also. The current spec already defines the attendee role as "the participant is expected to attend". Since it's a direct mapping of an iCalendar ATTENDEE, why not keep their naming in sync? > > Also bringing jscalendar participant into line with eventpub extensions > so we can do a consistent mapping between them. > > This means adding the following to jscalendar: > > order - Positive number. Defining an order on arbitrary properties or values is indeed something that the current JSCalendar Participant does not provide. Which JSCalendar properties could be impacted by ORDER? For participant types, is there a well-defined order of types and can the order of same participant types differ between participants? > structuredData - with "encoding" and "value" properties. I understand that STRUCTURED-DATA got introduced because ATTACH does not allow for text data. Wouldn't a JSCalendar Link object suffice? We might want to add an optional "schema" property to the Link object of type URI? Cheers, Robert --e17f5037d64c47a7b7e20e51f7cecd50 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Mike,

On Thu, Apr 30, 2020, at 5:13 AM, Michael Douglas= s wrote:
Th= ere's no mapping suggested for CONTACT which is vital for event 
publication.

CONTA= CT allows both textual representation and a URI value. We could register= a new "content" rel type at IANA and use a JSCalendar Link object? It c= ould point to a VCARD, include free text in a data: URI (with an accordi= ng text/plain contentType), or later also point to a JSCard.

I'd sug= gest following the approach in eventpub - add a 
part= icipantType property to jscalendar participant.
e.g.
"participantTypes": {"attendee": true}

Wouldn't it be enough to map these participant types t= o a JSCalendar Participant role? All that would need to be done is to ad= d their definition to the JSCalendar IANA Enum registry. The JSCalendar = spec for Participant roles explicitly allows this.

Changing role "at= tendee" to "required" or "expected" might make sense also.

The current spec already defines the attend= ee role as "the participant is expected to attend".  Since it's a d= irect mapping of an iCalendar ATTENDEE, why not keep their naming in syn= c?


Also bringing jscalendar participant into line wit= h eventpub extensions 
so we can do a consistent mapp= ing between them.

This means adding the fol= lowing to jscalendar:

order -  Positiv= e number.

Defining an order on= arbitrary properties or values is indeed something that the current JSC= alendar Participant does not provide. Which JSCalendar properties could = be impacted by ORDER? For participant types, is there a well-defined ord= er of types and can the order of same participant types differ between p= articipants?

structuredData - with "encoding" and "value" properties= .

 I understand that = ;STRUCTURED-DATA got introduced because ATTACH does not allow for text d= ata. Wouldn't a JSCalendar Link object suffice? We might want to add an = optional "schema" property to the Link object of type URI?

Cheers,
Robert

--e17f5037d64c47a7b7e20e51f7cecd50-- From nobody Thu Apr 30 06:30:58 2020 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 82D103A09F1 for ; Thu, 30 Apr 2020 06:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=kTIkaEzl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WnW2HZza 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 fKtFPgJIdZVM for ; Thu, 30 Apr 2020 06:30:43 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 492AC3A09F6 for ; Thu, 30 Apr 2020 06:30:43 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9EAC05C008C for ; Thu, 30 Apr 2020 09:30:42 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute7.internal (MEProxy); Thu, 30 Apr 2020 09:30:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=Hmih7lQ wamGLUGf7aAKXuVFxfJUIctA2mqtv+UAgD6Y=; b=kTIkaEzl1mThqk7iinV7vgq J1e3HioEd9bVRM5cJwBPn06kL+ClZH6GOLC0NpgSkqaYnHYUQ2SB1lyJGmXTD9wF Wppb9ch8gZJ+tHugBcjwy4GpeuBGM2pxOfdvFLTctfjdDNAt4dMfaC2VEvgJ01nU +8B5pXK8Vgg9j7tmiH3x+7MqOOhL+cS07pblqCZxX6X+g1HVDbk3PTpd8MrNCetf Eb/gdQsn01PHqXxG/nf6H3XPMX8WboEq0UMYJAyrlSQaZRhn1u7Nh0l99gM2AmJn UPCOgynk9DO1PDp5SiPXBjF5q/qY+JOXPNy6MOV+KaSTQefDSEboidcGpLf5Jng= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Hmih7l QwamGLUGf7aAKXuVFxfJUIctA2mqtv+UAgD6Y=; b=WnW2HZzaqubCjZhOjp4aSD 23MYwwasPai+T5fkaYAKgfOa6wnl9ww4sMZIo0iOOSEj1571lZ/VO1UFKjlLQu+3 oFQT1+vEwt0XauhBShgU8cxwNrIeN02rC9uZ+Kc/eq4224UV4L6Bx3UQfM9hY1xA KJsJmgCwV+Iht7kmaNeE0whxf1RSw32oGLGqDDoZKd04gXOJI0EOFcGys//TzCY2 n4Kiiv0QX1kCWCk2t4NYZw3NmKbsOTlBgiAIwjd2Z/SACzFGY6Cf+L1+GoKY2dON N+ULyfW95gTnw3HK9w/coP24+xZWAY/0Lb5DVkIbMi8QA4PlCTR01BsnXBuLWcdg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieehgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeethfffffekue ekveelleeglefhgeefjeeugeetkeejkefgtdfhheehvdehhedvhfenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomheprhhsthhosehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 62186180091; Thu, 30 Apr 2020 09:30:42 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <5325889f-bb61-4c27-b5d6-c499a050df36@www.fastmail.com> In-Reply-To: <2bac5257-fe7e-a306-0a6f-583533e0fe41@gmail.com> References: <2bac5257-fe7e-a306-0a6f-583533e0fe41@gmail.com> Date: Thu, 30 Apr 2020 15:30:22 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=f35804be0f3e47df9edf73f0dac5fe1e Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar-26 - section 3.1 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 13:30:47 -0000 --f35804be0f3e47df9edf73f0dac5fe1e Content-Type: text/plain On Sat, Apr 11, 2020, at 9:54 PM, Michael Douglass wrote: > I think this paragraph is incorrect (section 3.1): > [...] > I would be inclined to either delete > (for example, the CalDAV protocol [RFC4791 ] requires octet equivalence of the encoded calendar object to determine ETag equivalence) > The paragraph at the end may be an appropriate place to say "use a change token" > Considering this, the definition of equivalence and normalization is left to client and server implementations and to be negotiated by a calendar exchange protocol or defined elsewhere Yes, thanks for the correction. I'll update the spec draft. Cheers, Robert --f35804be0f3e47df9edf73f0dac5fe1e Content-Type: text/html
On Sat, Apr 11, 2020, at 9:54 PM, Michael Douglass wrote:

I think this paragraph is incorrect (section 3.1):

[...]
I would be inclined to either delete
 (for
   example, the CalDAV protocol [RFC4791] requires octet equivalence of
   the encoded calendar object to determine ETag equivalence)

The paragraph at the end may be an appropriate place to say "use a change token"

   Considering this, the definition of equivalence and normalization is
   left to client and server implementations and to be negotiated by a
   calendar exchange protocol or defined elsewhere

Yes, thanks for the correction. I'll update the spec draft.

Cheers,
Robert

--f35804be0f3e47df9edf73f0dac5fe1e-- From nobody Thu Apr 30 07:00:29 2020 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 7CF7A3A07AA for ; Thu, 30 Apr 2020 07:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=DEWyLZsi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J803D6BD 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 UEZLn8ZmX_oK for ; Thu, 30 Apr 2020 07:00:20 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45DBD3A07A6 for ; Thu, 30 Apr 2020 07:00:20 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 87E885C00AA for ; Thu, 30 Apr 2020 10:00:19 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute7.internal (MEProxy); Thu, 30 Apr 2020 10:00:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=59o4FHV 1aaH78YnF4pO/+kDp0ollt01hD46hH3E051E=; b=DEWyLZsiMlHp6/X/S/n6nky DkEogIexXLfLKkDJfdDFaonu10KNec8aII4JEBr7+sfFtGX6ZpBROvmeKajO9Gy4 xgtW0ajiZ48lFXWDE6TwzgGDZQtSOYWZWyMwIQyBwbCXk1KoGzxV8tNPhISU7+D1 9FLOXHHCD7FdZFaH319klwFCaTND6kqPg/JBzehDcMDj1yvdctW+Yt4/WeK7RFMS HJwnt+oRqTH7nfLLpiSZK+CTq5unA1byTx7eBjFmPP293scqW5lfy/EKcdRG7FEc IMHK7HE24Oa/+ktXqQ9yIlnRLq7esCMvZV4uhyM0aACoJoy/AkIY9tl4AGcdspQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=59o4FH V1aaH78YnF4pO/+kDp0ollt01hD46hH3E051E=; b=J803D6BDLMCJKqMNihk6Hq 6W4DkkmOfdtwb3soIbZ4PDtgMMgAVkgjSoVXhlovRnEeD+ZZAd1BaBaPhVSovYYl hbVsI+RqtRjNTkT/OX2fYqNoqLcsIvrT4O4z/r7iDcxAn1isY4dqVaBKdkQOWgO9 s8n7Gie86wfcHRof9MuVCx6j5j11tH9n0uO84cqqDQr5110yzPQs1H3sYa2juFCr vNSnfwZTmlTD6kJdJDzEK8OAd6FrXOaIdyAOYRsGMugvtfwraY19eGHPrt1IC+aw yth3u9/cEi9bGJfKtJ9mbCsw4Z+VW/Ikqo4QjM+RbuoqJUKGYuAJ0Q8PMwQ5NMsQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieehgdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeehvdevheevfe egfeefheettdehvdefheffkeetgeefleevleegveeiheejfeffffenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2A6A3180093; Thu, 30 Apr 2020 10:00:19 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <37561926-fd32-4cba-b03d-bab3df827bb1@www.fastmail.com> In-Reply-To: References: <158363619759.25642.15164071767646081255@ietfa.amsl.com> <89e9d6f2-9632-6c17-adfc-0a1977f15fcc@gmail.com> <5db6d2e1-8512-5f32-94d0-6f7057481a3d@gmail.com> Date: Thu, 30 Apr 2020 15:59:50 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=671f81bc1f7e46d49f9842828bb24374 Archived-At: Subject: Re: [calsify] =?utf-8?q?SUBSECOND_=28was=3A_I-D_Action=3A_draft-ietf?= =?utf-8?q?-calext-jscalendar-26=2Etxt=29?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 14:00:25 -0000 --671f81bc1f7e46d49f9842828bb24374 Content-Type: text/plain On Sun, Apr 5, 2020, at 6:31 AM, Michael Douglass wrote: > Date time issues. > The definition of the SUBSECOND parameter needs to be in the jscalendar spec. >From what I recall we agreed to define the iCalendar-JSCalendar specific mappings in the mapping RFC draft? And make that a standard document, rather than informational? > > I'm not sure about the statement: > SUBSECOND MUST NOT be used in date- time calculations or comparisons in iCalendar. Yes, let's remove that statement. > > [...] Also what about fractional values > 0.5? Really we should round to nearest? Would it be better to have e.g. a FRACTIONAL parameter with the whole date-time and allow the value to be the rounded value.? As discussed in our call a couple of weeks ago, it would be best if we could just allow fractional seconds in DATE-TIME values. But that will break loads of iCalendar parser, so it will have to remain wishful thinking. Both FRACTIONAL and SUBSECONDS have their flaws. I originally thought that the SUBSECONDS parameter is the better choice, but now that we talk about it, I come to prefer your FRACTIONAL idea. We could define the FRACTIONAL parameter to contain the complete datetime including fractional seconds. A client that is aware of that parameter must both set the FRACTIONAL parameter and the date-time property value. The property value must contain the rounded value of FRACTIONAL. Time values with fractional seconds always round up to the next second. The value of the FRACTIONAL parameter must be ignored, if its rounded value does not match the property value. What do you think? Cheers, Robert --671f81bc1f7e46d49f9842828bb24374 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Sun, Apr 5, = 2020, at 6:31 AM, Michael Douglass wrote:

Date time issues.

The definition = of the SUBSECOND parameter needs to be in the jscalendar spec.


From wha= t I recall we agreed to define the iCalendar-JSCalendar specific mapping= s in the mapping RFC draft? And make that a standard document, rather th= an informational?


I'm not sure about the statement:
 SUBSECOND MUST NOT be used in date-
      time calculations or comparisons in  iCalendar.

Yes, let's remove that statement.


[...] Also what about fractional values > 0.= 5? Really we should round to nearest? Would it be better to have e.g. a FRACTIONAL parameter= with the whole date-time and allow the value to be the rounded value.?


As discussed in ou= r call a couple of weeks ago, it would be best if we could just allow fr= actional seconds in DATE-TIME values. But that will break loads of iCale= ndar parser, so it will have to remain wishful thinking.
<= br>
Both FRACTIONAL and SUBSECONDS have their flaws. I origina= lly thought that the SUBSECONDS parameter is the better choice, but now = that we talk about it, I come to prefer your FRACTIONAL idea.
<= div>
We could define the FRACTIONAL parameter to contain t= he complete datetime including fractional seconds. A client that is awar= e of that parameter must both set the FRACTIONAL parameter and the date-= time property value. The property value must contain the rounded value o= f FRACTIONAL. Time values with fractional seconds always round up to the= next second. The value of the FRACTIONAL parameter must be ignored, if = its rounded value does not match the property value.

<= /div>
What do you think?

Cheers,
Robert
--671f81bc1f7e46d49f9842828bb24374-- From nobody Thu Apr 30 08:48:42 2020 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 75BB13A1259 for ; Thu, 30 Apr 2020 08:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 f79anIae96Za for ; Thu, 30 Apr 2020 08:48:33 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 229763A0B63 for ; Thu, 30 Apr 2020 08:47:29 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id u189so1802835ilc.4 for ; Thu, 30 Apr 2020 08:47:29 -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-language; bh=aOe0+mcRjgsWAGuMqeE7Jsyw8kqQ0IAKh7iqB8oQkWg=; b=TSnTFmBjq0a1i9Ls/piC30rhByRd1ckHkxihBlyZg0vC3k15tbIFhrXIHSufROov63 7EUfxxiwb5x13tHoZzl+giBkqS50V8nWuJQPLzCyd4hXtf2fFGELXJVUif+qnYDWvEDg Ed/pMqqaoriO2uxGqa3bQPrHCKTDz8NWVJPJV58IJPnysCS9hdH1K7IJXhUbh3CTjtY5 kv6xlQB8yxadYiUr4H/wBiROYlK7WMKG9Sz4afiWvXL2ZF1VEWML+bTC+Nm/BxsFOFbF WkhLjxZV31BuDLfxIoUuXmQJNNX8374qO0TQ44aU9T5vqkppWzSukkwg4bPnE7Wj4/Hr AmEg== 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-language; bh=aOe0+mcRjgsWAGuMqeE7Jsyw8kqQ0IAKh7iqB8oQkWg=; b=N8Sg8kxLQGd2oFWPEUG1Hy/WVxSKIy/sL/RWcgfATNyD1JsucYUScD8z7u8DQPkkyV k2yfMLDgjhOTkW1ys/6POR1sCGLRpWioea/7vYAR/XXT8OfGtaIOX49IPyJVmBdQ53Zi PG9ejJ/L1f37iP4bQWMJTCoJp5v7rF04Ag9f0sGWQqQBCoxp91qDgqYysgFKjUFDHnUl ANxpJQBn77KbsEAKgNS1XdjjVWWkBk2L+RrDyx2KRHTc91bCziAbz+bUoXYJDt1iKcig NGEMn9MAJCtddhjSPwG7fabHwQyi25ALhnNumnc7+50Tu3UkDQgsue2GVo3S0RItthiS ipNQ== X-Gm-Message-State: AGi0PuYQFvpk9sAbpoUyqcaO6dAMR26xHysyWgH+BwLzHOu9i0TZtlQc M7Qsu9pQrMW0bs9X0nnVhanclW2WWAY= X-Google-Smtp-Source: APiQypKq6KgKVLi7Q3NVwo1g2QEPf7seJQN9qjiqnmoeET0Mnv1BkNsADdkBzP2xBXt5SrOC9IgxbA== X-Received: by 2002:a92:c14f:: with SMTP id b15mr2744002ilh.134.1588261647930; Thu, 30 Apr 2020 08:47:27 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id m14sm66572ilq.68.2020.04.30.08.47.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Apr 2020 08:47:27 -0700 (PDT) To: calsify@ietf.org References: <158363619759.25642.15164071767646081255@ietfa.amsl.com> <89e9d6f2-9632-6c17-adfc-0a1977f15fcc@gmail.com> <5db6d2e1-8512-5f32-94d0-6f7057481a3d@gmail.com> <37561926-fd32-4cba-b03d-bab3df827bb1@www.fastmail.com> From: Michael Douglass Message-ID: <065b41de-93ab-e055-2056-90be002f3601@gmail.com> Date: Thu, 30 Apr 2020 11:47:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <37561926-fd32-4cba-b03d-bab3df827bb1@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------DDC63194266B7D3A2F5A272F" Content-Language: en-US Archived-At: Subject: Re: [calsify] SUBSECOND X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 15:48:40 -0000 This is a multi-part message in MIME format. --------------DDC63194266B7D3A2F5A272F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 4/30/20 09:59, Robert Stepanek wrote: > On Sun, Apr 5, 2020, at 6:31 AM, Michael Douglass wrote: >> >> Date time issues. >> >> The definition of the SUBSECOND parameter needs to be in the >> jscalendar spec. >> > > From what I recall we agreed to define the iCalendar-JSCalendar > specific mappings in the mapping RFC draft? And make that a standard > document, rather than informational? Yes - my comment was an earlier though. If we're producing a standards=-track mapping it's fine there. > >> >> I'm not sure about the statement: >> SUBSECOND MUST NOT be used in date- >> time calculations or comparisons in iCalendar. > > Yes, let's remove that statement. > >> [...] Also what about fractional values > 0.5? Really we should round >> to nearest? Would it be better to have e.g. a FRACTIONAL parameter >> with the whole date-time and allow the value to be the rounded value.? >> > > As discussed in our call a couple of weeks ago, it would be best if we > could just allow fractional seconds in DATE-TIME values. But that will > break loads of iCalendar parser, so it will have to remain wishful > thinking. > > Both FRACTIONAL and SUBSECONDS have their flaws. I originally thought > that the SUBSECONDS parameter is the better choice, but now that we > talk about it, I come to prefer your FRACTIONAL idea. > > We could define the FRACTIONAL parameter to contain the complete > datetime including fractional seconds. A client that is aware of that > parameter must both set the FRACTIONAL parameter and the date-time > property value. The property value must contain the rounded value of > FRACTIONAL. Time values with fractional seconds always round up to the > next second. The value of the FRACTIONAL parameter must be ignored, if > its rounded value does not match the property value. > > What do you think? This seems a simpler approach. I know at least ical4j rounds subseconds values so there's not much work to be done other than provide the parameter. I'll update the mapping. > > Cheers, > Robert > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------DDC63194266B7D3A2F5A272F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 4/30/20 09:59, Robert Stepanek wrote:
On Sun, Apr 5, 2020, at 6:31 AM, Michael Douglass wrote:

Date time issues.

The definition of the SUBSECOND parameter needs to be in the jscalendar spec.


From what I recall we agreed to define the iCalendar-JSCalendar specific mappings in the mapping RFC draft? And make that a standard document, rather than informational?
Yes - my comment was an earlier though. If we're producing a standards=-track mapping it's fine there.


I'm not sure about the statement:
 SUBSECOND MUST NOT be used in date-
      time calculations or comparisons in  iCalendar.

Yes, let's remove that statement.


        
[...] Also what about fractional values > 0.5? Really we
          should round to nearest? Would it be better to have e.g. a
          FRACTIONAL parameter with the whole date-time and allow the
          value to be the rounded value.?

        

      

      


      

      
As discussed in our call a couple of weeks ago, it would be
        best if we could just allow fractional seconds in DATE-TIME
        values. But that will break loads of iCalendar parser, so it
        will have to remain wishful thinking.

      

      


      

      
Both FRACTIONAL and SUBSECONDS have their flaws. I originally
        thought that the SUBSECONDS parameter is the better choice, but
        now that we talk about it, I come to prefer your FRACTIONAL
        idea.

      

      


      

      
We could define the FRACTIONAL parameter to contain the
        complete datetime including fractional seconds. A client that is
        aware of that parameter must both set the FRACTIONAL parameter
        and the date-time property value. The property value must
        contain the rounded value of FRACTIONAL. Time values with
        fractional seconds always round up to the next second. The value
        of the FRACTIONAL parameter must be ignored, if its rounded
        value does not match the property value.

      

      


      

      
What do you think?

      

    

    
This seems a simpler approach. I know at least ical4j rounds
      subseconds values so there's not much work to be done other than
      provide the parameter.

    
I'll update the mapping.

    

    

      


      

      
Cheers,

      

      
Robert

      

      

      

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


    

  


--------------DDC63194266B7D3A2F5A272F--


From nobody Thu Apr 30 09:12:10 2020
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 C6F393A0B92 for ; Thu, 30 Apr 2020 09:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 6AUkyZKQ6QAN for ; Thu, 30 Apr 2020 09:12:05 -0700 (PDT)
Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 99E5A3A0B9D for ; Thu, 30 Apr 2020 09:12:05 -0700 (PDT)
Received: by mail-il1-x12f.google.com with SMTP id c16so1880494ilr.3 for ; Thu, 30 Apr 2020 09:12:05 -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-language; bh=PHOUyj45lVoZGChu4T/eO4wg3rX+6661cw7rq0yrxpY=; b=S3iMS7xSXxppX//NyrinTpmARdrt/2VGKzswzb47nyBJbaTLTuvDyccIl3/nCfLgwd SM3qmDnOcRNd0PZ3+Ww11nIXBWb/pgZ9JSUKHSPDGynSFy+qlcxlDxBuS+TeX7igHUXU VwI/M9oAYPWBAK9XgtojeM1fkALgMcKkGXGGnNEuQMLHdqZ1/dzWnQqoczrjB6eYnA1G xxSAUusVr/Jwp+JV0mbtTlV+x0np0QNCuDVEZfefzy7G4GEoS0b0Lx9qgOwhQ48CVh1K mCZO4ht7QttgLT52J0HFM8MiVWG2ltQZihCHNKe9btAkBb9liMvza9xFytBChJ44liDL u0Zw==
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-language; bh=PHOUyj45lVoZGChu4T/eO4wg3rX+6661cw7rq0yrxpY=; b=nEeKeGnnzZntVhO58SJPH7DltxIqIVobxLuysOPV6J+hE68mhu5Pv963sWqU3DmUxL c6kkYFMI/z8FeKq0o8Mj6Wp7fCY/F1fHfiz3uyD5EC7BFYxRg6fFM1xf+ZIhWBoxKlc5 nb8cJd3kSyeZHxUdEK9f8i4xgfWAXYTV95kN3JLBRfoSG0AukHMsFh12UAw6XICRJZPy SxijZh9cWubYFatxktiJVyDGuhkRrh6Oio9O3lFMaiqjlqaqSQyIfiLXsprTY3b3Qc9y cQlnR92QtN6BTNrxri0Y/9BZBmfgLxl4UtnYsyA2z/XkC9bRfbsoaDqG5lQ+4gJ82DmD jrXQ==
X-Gm-Message-State: AGi0PuYKFe/JhGE8N8e9emG083u8E8Dqg5jYaKTgW5ipJf8BqcsiV5jA wwGkw6GYIPsP35T8SAdSrhqH3wkCJlo=
X-Google-Smtp-Source: APiQypJD1O+PF39DJ9lvPuiuFjPJz+z3GNt4q41c0Pg9QfNaDbLIIfvXTdtZMMVlBlVP1qzOf+dtkg==
X-Received: by 2002:a05:6e02:802:: with SMTP id u2mr2754262ilm.163.1588263124627;  Thu, 30 Apr 2020 09:12:04 -0700 (PDT)
Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id k22sm9537iot.32.2020.04.30.09.12.03 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Apr 2020 09:12:03 -0700 (PDT)
To: calsify@ietf.org
References: <2bac5257-fe7e-a306-0a6f-583533e0fe41@gmail.com> <5325889f-bb61-4c27-b5d6-c499a050df36@www.fastmail.com>
From: Michael Douglass 
Message-ID: <04a8ae6d-ea9f-657d-9d25-1952d66ca8c8@gmail.com>
Date: Thu, 30 Apr 2020 12:12:02 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <5325889f-bb61-4c27-b5d6-c499a050df36@www.fastmail.com>
Content-Type: multipart/alternative; boundary="------------DEB6F8EA1643DCD8D7CA1EB8"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-jscalendar-26 - section 3.1
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2020 16:12:08 -0000

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

Another typo in section 7.3

discusses security risk related to URIs.

should be

discusses security risks related to URIs.

On 4/30/20 09:30, Robert Stepanek wrote:
> On Sat, Apr 11, 2020, at 9:54 PM, Michael Douglass wrote:
>>
>> I think this paragraph is incorrect (section 3.1):
>>
>> [...]
>> I would be inclined to either delete
>>   (for
>>     example, the CalDAV protocol [RFC4791  ] requires octet equivalence of
>>     the encoded calendar object to determine ETag equivalence)
>>
>> The paragraph at the end may be an appropriate place to say "use a 
>> change token"
>>
>>     Considering this, the definition of equivalence and normalization is
>>     left to client and server implementations and to be negotiated by a
>>     calendar exchange protocol or defined elsewhere
>
> Yes, thanks for the correction. I'll update the spec draft.
>
> Cheers,
> Robert
>
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify

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


  
    
  
  
    
Another typo in section 7.3

    
discusses security risk related to URIs.

should be 

discusses security risks related to URIs.

    
On 4/30/20 09:30, Robert Stepanek
      wrote:

    

    

      
      
      
      
On Sat, Apr 11, 2020, at 9:54 PM, Michael Douglass wrote:

      

      

        
I think this paragraph is incorrect (section 3.1):

        

        
[...]


        
I would be inclined to either delete

        

        
 (for
   example, the CalDAV protocol [RFC4791] requires octet equivalence of
   the encoded calendar object to determine ETag equivalence)


        
The paragraph at the end may be an appropriate place to say
          "use a change token"

        

        
   Considering this, the definition of equivalence and normalization is
   left to client and server implementations and to be negotiated by a
   calendar exchange protocol or defined elsewhere


      

      


      

      
Yes, thanks for the correction. I'll update the spec draft.

      

      


      

      
Cheers,

      

      
Robert

      

      


      

      

      

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


    

  


--------------DEB6F8EA1643DCD8D7CA1EB8--


From nobody Thu Apr 30 09:31:56 2020
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 983C83A0D83 for ; Thu, 30 Apr 2020 09:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 wMPo1auAHQlS for ; Thu, 30 Apr 2020 09:31:45 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 961BC3A0D2A for ; Thu, 30 Apr 2020 09:31:21 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id k6so2134750iob.3 for ; Thu, 30 Apr 2020 09:31: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-language; bh=EySH30/85GKLwcH8R4AxgBKWGpGg+OqKpqVCv6WCQBI=; b=RCBNm8DM4FxEyuA/xExIJNKt4QARQ/kt8IoDGuHnIgMe1BDKRh5jV22mJiE+yoC2kk uIh61PgeVv9R+x0p7P2ZDonFurjtPfIk9WO2RmOMmhA8ThaecFQJVnwehDnxXOplAlvY 6qq0OEPslNm4vohSGqPwKs/XqMb4Syc4YMTKUysSpfzxmDhDNqN6nrj8CgrwN/v3x+mI hH0B9LDy2CbGqnOE47iW3EvzNGntzAiiQ7sImnf53Zq+jYSZC+Aj/0uN7ZTbv9PXrWfX rBHIwNnaAzAbNXkqugZ99rWFdo5uB8TG5sIibNvgxnUlQnOmaRd36VBhSaJPNCj9d/0l YS8A==
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-language; bh=EySH30/85GKLwcH8R4AxgBKWGpGg+OqKpqVCv6WCQBI=; b=fz40Ug0/sGOPMZiLafGd45d7lVFkcjv8sWym4eugwQmR6SPQu3WIbsvslwz/sv9HwW TuWbloh/bdnVqdtHr7OdDUt0KhOJSIgrmlcZjAQXNT4ijCoPzg+5q48E1NUfp4A2tc/K 0UKvhYnfwoZNu8m8A6cUszwFp8cGTqqzT4qZTGZ26Sk5Ry/ZtglvPDvtr1PXaolSamfd vsTshnr/PzWPTcEF/qF9pbea5sFuRDVOfmeQ3DGyWHuVOBd825vIrUVySVAZ2gc3BzNk RLWhsxYNu3qkVn6hITqqOLWZ2CB5nj9PEb2FGGUEKLA/M8fweTYH6G9XdZrq3AR6liJv Qk5A==
X-Gm-Message-State: AGi0PuaGogpK21nemIyxaanj04IRbz8RIhTIvSAjsx0eE7URwLYQl8s4 3uHB3RPSJCdVX7JDQ6lhmdEo3RDSCnQ=
X-Google-Smtp-Source: APiQypKBgVYs430uxoWJ33eEIFLI7W22SE3nWR36+gcpWAy1DwJXV57mfRq6BeBeyMS2RNoI5Qcs6g==
X-Received: by 2002:a02:cd91:: with SMTP id l17mr2644235jap.34.1588264280210;  Thu, 30 Apr 2020 09:31:20 -0700 (PDT)
Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id x11sm102734ilm.64.2020.04.30.09.31.19 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Apr 2020 09:31:19 -0700 (PDT)
To: calsify@ietf.org
References:  <7e0ab50b-3a6a-4d79-8903-7974e8b47247@www.fastmail.com>
From: Michael Douglass 
Message-ID: <7b503698-ae45-9d43-22bb-20961e4cb754@gmail.com>
Date: Thu, 30 Apr 2020 12:31:19 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <7e0ab50b-3a6a-4d79-8903-7974e8b47247@www.fastmail.com>
Content-Type: multipart/alternative; boundary="------------B66C24B221B7C7B380D934AB"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] JSCalendar and eventpub - participant and contacts
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2020 16:31:55 -0000

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

Part of my concern here is to ensure that jscalendar is compatible with 
the eventpub work.

On 4/30/20 09:28, Robert Stepanek wrote:
> Hi Mike,
>
> On Thu, Apr 30, 2020, at 5:13 AM, Michael Douglass wrote:
>> There's no mapping suggested for CONTACT which is vital for event
>> publication.
>
> CONTACT allows both textual representation and a URI value. We could 
> register a new "content" rel type at IANA and use a JSCalendar Link 
> object? It could point to a VCARD, include free text in a data: URI 
> (with an according text/plain contentType), or later also point to a 
> JSCard.
>
>> I'd suggest following the approach in eventpub - add a
>> participantType property to jscalendar participant.
>> e.g.
>> "participantTypes": {"attendee": true}
>
> Wouldn't it be enough to map these participant types to a JSCalendar 
> Participant role? All that would need to be done is to add their 
> definition to the JSCalendar IANA Enum registry. The JSCalendar spec 
> for Participant roles explicitly allows this.
>
>> Changing role "attendee" to "required" or "expected" might make sense 
>> also.
>
> The current spec already defines the attendee role as "the participant 
> is expected to attend".  Since it's a direct mapping of an iCalendar 
> ATTENDEE, why not keep their naming in sync?

I don't see it as a direct mapping. 5545 has a role of chair, required, 
optional or non-participant.

I think jscalendar has conflated type and role. What I'm suggesting is a 
more direct mapping. As we add more participant types other roles are 
likely to be needed.

And now I look again at eventpub I think I've done the same thing there 
with contacts. I defined the roles

      partvalue    = ("ACTIVE"
                      / "INACTIVE"
                      / "SPONSOR"
                      / "CONTACT"
                      / "BOOKING-CONTACT"
                      / "EMERGENCY-CONTACT"
                      / "PUBLICITY-CONTACT"
                      / "PLANNER-CONTACT"
                      / "PERFORMER"
                      / "SPEAKER"
                      / iana-token)     ; Other IANA-registered
                                        ; values


I think adding a PARTICIPANT-ROLE property might be better and more 
extensible.

>
>>
>> Also bringing jscalendar participant into line with eventpub extensions
>> so we can do a consistent mapping between them.
>>
>> This means adding the following to jscalendar:
>>
>> order -  Positive number.
>
> Defining an order on arbitrary properties or values is indeed 
> something that the current JSCalendar Participant does not provide. 
> Which JSCalendar properties could be impacted by ORDER? For 
> participant types, is there a well-defined order of types and can the 
> order of same participant types differ between participants?
For event publication it was felt useful to identify the more important 
participants of a given type (principal performer, main contact etc). 
For the purposes of mapping we can probably wait for this one.
>
>> structuredData - with "encoding" and "value" properties..
>
>  I understand that STRUCTURED-DATA got introduced because ATTACH does 
> not allow for text data. Wouldn't a JSCalendar Link object suffice? We 
> might want to add an optional "schema" property to the Link object of 
> type URI?

STRUCTURED-DATA got introduced because it was too risky - for backward 
compatibility reasons - to update ATTACH. It does allow us to carry a 
payload of well defined non-calendar data. link might do it with a 
schema property.


>
> Cheers,
> Robert
>
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify

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


  
    
  
  
    
Part of my concern here is to ensure that jscalendar is
      compatible with the eventpub work.

    
On 4/30/20 09:28, Robert Stepanek
      wrote:

    

    

      
      
      
      
Hi Mike,

      

      


      

      
On Thu, Apr 30, 2020, at 5:13 AM, Michael Douglass wrote:

      

      

        
There's no mapping suggested for CONTACT which is vital for
          event 

        

        
publication.

        

      

      


      

      
CONTACT allows both textual representation and a URI value.
        We could register a new "content" rel type at IANA and use a
        JSCalendar Link object? It could point to a VCARD, include free
        text in a data: URI (with an according text/plain contentType),
        or later also point to a JSCard.

      

      


      

      

        
I'd suggest following the approach in eventpub - add a 

        

        
participantType property to jscalendar participant.

        

        
e.g.

        

        
"participantTypes": {"attendee": true}

        

      

      


      

      
Wouldn't it be enough to map these participant types to a
        JSCalendar Participant role? All that would need to be done is
        to add their definition to the JSCalendar IANA Enum registry.
        The JSCalendar spec for Participant roles explicitly allows
        this.

      

      


      

      

        
Changing role "attendee" to "required" or "expected" might
          make sense also.

        

      

      


      

      
The current spec already defines the attendee role as "the
        participant is expected to attend".  Since it's a direct mapping
        of an iCalendar ATTENDEE, why not keep their naming in sync?

      

    

    
I don't see it as a direct mapping. 5545 has a role of chair,
      required, optional or non-participant.

    
I think jscalendar has conflated type and role. What I'm
      suggesting is a more direct mapping. As we add more participant
      types other roles are likely to be needed. 

    

    
And now I look again at eventpub I think I've done the same thing
      there with contacts. I defined the roles

    
     partvalue    = ("ACTIVE"
                     / "INACTIVE"
                     / "SPONSOR"
                     / "CONTACT"
                     / "BOOKING-CONTACT"
                     / "EMERGENCY-CONTACT"
                     / "PUBLICITY-CONTACT"
                     / "PLANNER-CONTACT"
                     / "PERFORMER"
                     / "SPEAKER"
                     / iana-token)     ; Other IANA-registered
                                       ; values


    


    

    
I think adding a PARTICIPANT-ROLE property might be better and
      more extensible.

    

    

      


      

      

        


        

        
Also bringing jscalendar participant into line with
          eventpub extensions 

        

        
so we can do a consistent mapping between them.

        

        


        

        
This means adding the following to jscalendar:

        

        


        

        
order -  Positive number.

        

      

      


      

      
Defining an order on arbitrary properties or values is indeed
        something that the current JSCalendar Participant does not
        provide. Which JSCalendar properties could be impacted by ORDER?
        For participant types, is there a well-defined order of types
        and can the order of same participant types differ between
        participants?

      

    

    For event publication it was felt useful to identify the more
    important participants of a given type (principal performer, main
    contact etc). For the purposes of mapping we can probably wait for
    this one. 

    

      


      

      

        
structuredData - with "encoding" and "value" properties..

        

      

      


      

      
 I understand that STRUCTURED-DATA got introduced because
        ATTACH does not allow for text data. Wouldn't a JSCalendar Link
        object suffice? We might want to add an optional "schema"
        property to the Link object of type URI?

      

    

    
STRUCTURED-DATA got introduced because it was too risky - for
      backward compatibility reasons - to update ATTACH. It does allow
      us to carry a payload of well defined non-calendar data. link
      might do it with a schema property.

    

    


    

    

      


      

      
Cheers,

      

      
Robert

      

      


      

      

      

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


    

  


--------------B66C24B221B7C7B380D934AB--


From nobody Thu Apr 30 20:52:11 2020
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 413DD3A03F2 for ; Thu, 30 Apr 2020 20:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=OaoIGoy7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RLp97p/X
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 Mx5i6aiCo8wU for ; Thu, 30 Apr 2020 20:52:06 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F113A03F1 for ; Thu, 30 Apr 2020 20:52:06 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 44E975C0196 for ; Thu, 30 Apr 2020 23:52:05 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Thu, 30 Apr 2020 23:52:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=pbWvZPR a3VNwKMB3FFdReZ6OttSg/HWOqgaoXI5rslQ=; b=OaoIGoy7nuvjreu8jadhup1 xA1gLSkdML2IYj9o1zfOY0vVKexdEAkOWHt0hxSY9kRL7EWhsvK2bykKfWghlBr+ TTuQy5u2G3GVhF/VvtnouC/IMqASrp5857LJByXDR2lv16t1X8P/8WsGLqQNXgLX qen4HG5Ray+/MdyN5VLJwptj+ssEji8Nxc9pM2KoZuOHS6DlASanbUP3h6AdYgPy JsK6euPcqm/v1wrc+OYC/8AD6jzTg/Jl6gAqlP4bOVfF+RVxnysJj10bj2kBLUUx 0UAgRGTuknAxk1zTSp4jEQT9206xoFIEJeC4ouvtcAQDZbkLSzbmzT913iW/DUw= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=pbWvZP Ra3VNwKMB3FFdReZ6OttSg/HWOqgaoXI5rslQ=; b=RLp97p/XYPNx3xqn2rD7gM cWW/U1bs7cJ9DUwvD/f5GtpfNS34Oqedh5lFxJOK4zeO8aLLK8ApT6/A9Hjv44a1 iy51aFCLnQn3tWvVnoVjkQPj/rvKqs9DvuVrQBEe4Mzv204VEr4Caq4Uy1f4WykK Oe988+Eu8BU2lhltgFwHWkZdTPLDIqEsGuah8ZbQSrpJr5AQLcPiY6CEnkHYTHWG Edm6mbYSRRLydHqI3wuY3kuHj4vuAgGHLnKdp2hFR+nmyLcJn1x5c9kuDG+eH1zS PhZI8DcdawPPaJdVtUPaB3P/Pdg8seXRf0l8HqSnllHbg/NXaf6LzuBKCLZLNkLA ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieeigdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevvdetvdduleekhf eghfetfeettdelhfehfeevffevleekuddtudffieevjeevhfenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id E0968180091; Thu, 30 Apr 2020 23:52:04 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: <9dc2a473-57f2-4430-8f3b-c12e7be46bfc@beta.fastmail.com>
In-Reply-To: <7b503698-ae45-9d43-22bb-20961e4cb754@gmail.com>
References:  <7e0ab50b-3a6a-4d79-8903-7974e8b47247@www.fastmail.com> <7b503698-ae45-9d43-22bb-20961e4cb754@gmail.com>
Date: Fri, 01 May 2020 13:52:03 +1000
From: "Neil Jenkins" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=1f58d9be37ac48f7a103f68f8362a03e
Archived-At: 
Subject: Re: [calsify] JSCalendar and eventpub - participant and contacts
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 May 2020 03:52:10 -0000

--1f58d9be37ac48f7a103f68f8362a03e
Content-Type: text/plain

On Fri, 1 May 2020, at 02:31, Michael Douglass wrote:
>      partvalue    = ("ACTIVE"
                     / "INACTIVE"
                     / "SPONSOR"
                     / "CONTACT"
                     / "BOOKING-CONTACT"
                     / "EMERGENCY-CONTACT"
                     / "PUBLICITY-CONTACT"
                     / "PLANNER-CONTACT"
                     / "PERFORMER"
                     / "SPEAKER"
                     / iana-token)     ; Other IANA-registered
                                       ; values

Not sure what active/inactive are meant to mean, but the rest of these can all be registered as participant roles in the JScalendar Enum registry. We don't need a new property.

Neil.
--1f58d9be37ac48f7a103f68f8362a03e
Content-Type: text/html


On Fri, 1 May 2020, at 02:31, Michael Douglass wrote:
     partvalue    = ("ACTIVE"
                     / "INACTIVE"
                     / "SPONSOR"
                     / "CONTACT"
                     / "BOOKING-CONTACT"
                     / "EMERGENCY-CONTACT"
                     / "PUBLICITY-CONTACT"
                     / "PLANNER-CONTACT"
                     / "PERFORMER"
                     / "SPEAKER"
                     / iana-token)     ; Other IANA-registered
                                       ; values

Not sure what active/inactive are meant to mean, but the rest of these can all be registered as participant roles in the JScalendar Enum registry. We don't need a new property.

Neil.

--1f58d9be37ac48f7a103f68f8362a03e--


From nobody Thu Apr 30 21:02:06 2020
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 586573A0522 for ; Thu, 30 Apr 2020 21:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=qMK4bD/r; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XLTG0Duk
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 W0V3DlMgaqpq for ; Thu, 30 Apr 2020 21:02:03 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB6C3A04BB for ; Thu, 30 Apr 2020 21:02:02 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E92265C00E2 for ; Fri,  1 May 2020 00:02:01 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Fri, 01 May 2020 00:02:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=AovsLIg 6nstYqEO7cDf4M87pqsUVLcn6Kcb1Jx1fgf8=; b=qMK4bD/reLHVPjt2O0WdoMA 0AH+iVZ39GH7DQ9YdtQaNRYQ0SZe6s32foC+69B3iE1uNFyv3UkCisDrHndNn4pl y6D2/B5DbWXcKF+eqelcSzB/91zYGXWftaLFTXvb+SffeRcQ1OIxuAV9HFBCy172 ElGGVbK2oCEnqpYy/JGoO9dhhd2ov2fDOsBP6XaqEmRRW7zFMV8juoqgtcwePUWN L50Ac4uV5kJCImG9D4tugZhYD5gJmNtvbdyjln7yIbVw/2N2sON3z+dQmye2IJZE KnY75aoMUmu5+GKA+AdmumOglPPx61y1sAUfR7GTz3kJgcFhnfD3QGAQ2f4+Sxg= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=AovsLI g6nstYqEO7cDf4M87pqsUVLcn6Kcb1Jx1fgf8=; b=XLTG0Duk41bMSlnUH8FwHQ QwVRBpTCBlVyv5SCIlRMW+lhtKEsTTXIgMHOWYJ+Q/dmT8m2mkXlUpFybT12AJZ2 DKm7QShFFXhIad476UVcC5nClFQpS9RsSBPNrXenL4DjGnYY1x7TuYFNRAzWoPTu CfljzWSDZpbVFn+rE9KsDP3H2fMflgU0AFT4MGXjKpmnijTLP6+JMZqe9ryWAjdN n9wedppVHNpV7RQjmnZgycr9KFrap2SgGiC+LtLJ+1nt8un44SmHlflguZemvaU+ EBOA1gTYAGJe4G2cHHDF5yj8vvtm8veD9Qi8M5C+wbfUTnz64AA4V+rdzgIbhclg ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieeigdejiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevvdetvdduleekhf eghfetfeettdelhfehfeevffevleekuddtudffieevjeevhfenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 917F5180091; Fri,  1 May 2020 00:02:01 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: <59fea220-d7b0-4883-9c10-ff8dd3963e77@beta.fastmail.com>
In-Reply-To: 
References: <158363619759.25642.15164071767646081255@ietfa.amsl.com>  <89e9d6f2-9632-6c17-adfc-0a1977f15fcc@gmail.com> <5db6d2e1-8512-5f32-94d0-6f7057481a3d@gmail.com> <028801d60af3$031951d0$094bf570$@comcast.net> 
Date: Fri, 01 May 2020 14:02:01 +1000
From: "Neil Jenkins" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=bf862a9a5ce7482184ad0be27e8ae5b2
Archived-At: 
Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.txt
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 May 2020 04:02:05 -0000

--bf862a9a5ce7482184ad0be27e8ae5b2
Content-Type: text/plain

On Sun, 5 Apr 2020, at 13:14, Michael Douglass wrote:
> There is a scheduleUpdated property in the participant - is that what corresponds to the itip usage of DTSTAMP?


Yes. This is the only case where the two differ: in the iMIP response it's when the invitee set their RSVP as opposed to when the organiser last updated the event. The organiser actually needs to store this per-attendee anyway to be able to process iMIP messages properly, so we added an explicit property for this in JSCalendar.

Neil.
--bf862a9a5ce7482184ad0be27e8ae5b2
Content-Type: text/html


On Sun, 5 Apr 2020, at 13:14, Michael Douglass wrote:
There is a scheduleUpdated property in the participant - is that
      what corresponds to the itip usage of DTSTAMP?

Yes. This is the only case where the two differ: in the iMIP response it's when the invitee set their RSVP as opposed to when the organiser last updated the event. The organiser actually needs to store this per-attendee anyway to be able to process iMIP messages properly, so we added an explicit property for this in JSCalendar.

Neil.

--bf862a9a5ce7482184ad0be27e8ae5b2--


From nobody Thu Apr 30 21:11:16 2020
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 232963A0773 for ; Thu, 30 Apr 2020 21:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=OPg0C5tC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UmMCtHKF
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 2JDQKdxPc6jv for ; Thu, 30 Apr 2020 21:11:12 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3F33A076F for ; Thu, 30 Apr 2020 21:11:10 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 788CC5C008C for ; Fri,  1 May 2020 00:11:09 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Fri, 01 May 2020 00:11:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=oqEeA4j FO5W3JdWPbsEjwN/x3TEalhY0k/y2RHSHcmM=; b=OPg0C5tCNU62H1ZKZFRGHTR bwEpfwUUHUN2L/6McJeOORssOeAn+7hS8Jf+Z9gwim4ta0209Fj7upVw1J0JtCu0 LDLgqTWAA3vWR3RHyUbKYQaAp1GiCTpRkFWRZnKgfr9/cVvS8aj0hERgMCvD0Svk 0vraMnHUMWQ9sQlOxzO1a/Or1K/RK1Umk9d++T+Xq4nd2bLaRBTeIMCpRWlsASi3 VzUsvnS88IUhh8WuNXAw2DRIAbKy17xhkqZVSFvRTIEwlB7ddY8TAfrjnZtKxSmd NTdOaY6HfSQ4Iz3xdCtq9LeIVPOyO3ruzayEr7ZpgYAzUGa74u7j8Al3bFK47gg= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=oqEeA4 jFO5W3JdWPbsEjwN/x3TEalhY0k/y2RHSHcmM=; b=UmMCtHKFnjsDJUk6wogQKW QVSb9KhNpknxwkijl5fc3838CpBWcTnCp0m4tdE9q7JqJctvdufxc0vi0M7/eNTe Vue5uZc1IEi+t8WTVwdoFA4gR+R8s26bAFlS4KbLaJ7emoOCeCOoInvK4Nrtk9lN qpzIp8pkKnRCVaVUBS1dMI2GYm6ioap7hVLywS+OvBj1+PB07Nu4XVDQNKn3TTea f/XALv1+BQuDuQu814zbfNdyFueZFRT1ntBAZXA/htitl2X661IR5VBlErlKuxSy IygP636HEGiJYV4aB6S7pbu4nFb57yzqd9OltYe6IeSLPsnmrwJc92o61iWq309A ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieeigdejkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevvdetvdduleekhf eghfetfeettdelhfehfeevffevleekuddtudffieevjeevhfenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id B5AB8180091; Fri,  1 May 2020 00:11:08 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <5db6d2e1-8512-5f32-94d0-6f7057481a3d@gmail.com>
References: <158363619759.25642.15164071767646081255@ietfa.amsl.com>  <89e9d6f2-9632-6c17-adfc-0a1977f15fcc@gmail.com> <5db6d2e1-8512-5f32-94d0-6f7057481a3d@gmail.com>
Date: Fri, 01 May 2020 14:11:08 +1000
From: "Neil Jenkins" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=a43ed9ea1ad34345a6c488304e0be20a
Archived-At: 
Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.txt
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 May 2020 04:11:14 -0000

--a43ed9ea1ad34345a6c488304e0be20a
Content-Type: text/plain

On Sat, 4 Apr 2020, at 09:55, Michael Douglass wrote:
> In your mapping draft you say:

> An iCalendar ORGANIZER maps to both the replyTo property and a
   participant with role "owner".  If an ATTENDEE with the same CAL-
   ADDRESS value exists, then it maps to the same participant as the
   ORGANIZER participant.
> And what is SENT-BY mapped to?


Hmm, we don't have a mapping for SENT-BY, but this could be easily added as an extra property on the participant object (does anyone know if this is used in the wild out of interest?).

> What if the attendee and organizer have different SENT-BY parameters?

You could make this property multi-valued I guess, to record anyone that has acted as the participant at different points during the event's history.

Neil.
--a43ed9ea1ad34345a6c488304e0be20a
Content-Type: text/html


On Sat, 4 Apr 2020, at 09:55, Michael Douglass wrote:
In your mapping draft you say:
An iCalendar ORGANIZER maps to both the replyTo property and a
   participant with role "owner".  If an ATTENDEE with the same CAL-
   ADDRESS value exists, then it maps to the same participant as the
   ORGANIZER participant.
And what is SENT-BY mapped to?

Hmm, we don't have a mapping for SENT-BY, but this could be easily added as an extra property on the participant object (does anyone know if this is used in the wild out of interest?).

What if the attendee and organizer have different SENT-BY
      parameters?

You could make this property multi-valued I guess, to record anyone that has acted as the participant at different points during the event's history.

Neil.

--a43ed9ea1ad34345a6c488304e0be20a--