Subject: [calsify] draft-ietf-calext-jscalendar-icalendar-02

From: Ken Murchison <[email-masked]>
Date: Sat, 19 Dec 2020 13:50:13 -0500

All,

I just had cause to consult jscalendar-icalendar Section 2.1 
<draft-ietf-calext-jscalendar-icalendar-02> and I have a couple of issues:

 1. Why is this value specified to be the entire date-time plus
    fractional seconds?  Wouldn't the fractional seconds be sufficient?
 2. The definition of the parameter is incorrect:
     1. It doesn't include the game of the parameter in the definition
     2. The value isn't DATE-TIME or DURATION, its value is an extension
        of date-time.  If keeping a full time representation it should
        be something like "date-time "." 1*DIGIT

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

---

From: Michael Douglass <[email-masked]>
Date: Mon, 21 Dec 2020 00:09:26 -0500

On 12/19/20 13:50, Ken Murchison wrote:
>      2. The value isn't DATE-TIME or DURATION, its value is an
>         extension of date-time.  If keeping a full time representation
>         it should be something like "date-time "." 1*DIGIT
>
1.This was my suggestion - way back in April

As I recall my main problem with the previous approach - which was just 
the fractional part - was that it led to ambiguities and having to 
define how the full value was rounded to produce the truncated iCalendar 
value. Having the full value means you just choose to use either the 
(possibly adjusted) property value or the (possibly more accurate) 
FRACTIONAL parameter value. No processing or worrying about edge cases.

2. I think FRACTIONAL can be used for DURATION as well as as for DTSTART 
and the abnf is wrong anyway. We have

fractional-param = DATE-TIME or DURATION

shouldn't it be something like

fractional-param = "FRACTIONAL" = (date-time | dur-value) ["." 1*DIGIT]
; Value is extended date-time when used with the DTSTART property
; Value is extended dur-value when used with the DURATION property

and we need abnf for etending DTSTART and DURATION

> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 21 Dec 2020 08:11:37 +0100

On Mon, Dec 21, 2020, at 6:09 AM, Michael Douglass wrote:
>>  1. Why is this value specified to be the entire date-time plus fractional seconds?  Wouldn't the fractional seconds be sufficient?

We even agreed to this change, and while I implemented it in April, I did not update the RFC. My apologies, I just came to realize last week. I will update it in the next days.

Cheers,
Robert

---

From: Ken Murchison <[email-masked]>
Date: Mon, 21 Dec 2020 07:17:04 -0500

Hi Mike,

On 12/21/20 12:09 AM, Michael Douglass wrote:
>>         extension of date-time.  If keeping a full time
>>         representation it should be something like "date-time "." 1*DIGIT
>>
> As I recall my main problem with the previous approach - which was 
> just the fractional part - was that it led to ambiguities and having 
> to define how the full value was rounded to produce the truncated 
> iCalendar value. Having the full value means you just choose to use 
> either the (possibly adjusted) property value or the (possibly more 
> accurate) FRACTIONAL parameter value. No processing or worrying about 
> edge cases.
>

Now that you refreshed my memory, I do recall this discussion. If we 
allow the fractional part to be positive OR negative, doesn't this solve 
the rounding problem?  If the full value is rounded with value R, the 
fractional part can be set to -R.

> 2. I think FRACTIONAL can be used for DURATION as well as as for 
> DTSTART and the abnf is wrong anyway. We have
>

If we're going to keep FRACTIONAL as being the full value, we will have 
to be more creative with the ABNF because date-time has [time-utc] as 
its last component, and for durations, we probably only want/need the 
fractional part when the duration includes dur-second.  So perhaps:

fractional-param = "FRACTIONAL" "=" (date-time-frac / dur-frac)

date-time-frac = date "T" time-frac

time-frac = time-hour time-minute time-second frac-sec [time-utc]

frac-sec = "." 1*DIGIT

dur-frac = (["+"] / "-") "P" dur-day dur-time-frac

dur-time-frac = 1*DIGIT "H" 1*DIGIT "M" dur-second frac-sec

Having gone through this exercise, I think it would be a lot simpler to 
just do:

fractional-param = "FRACTIONAL" "=" (["+"] / "-") "." 1*DIGIT

-- 

Kenneth Murchison

---

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 21 Dec 2020 13:31:24 +0100

As noted in my previous email: we already agreed to not set the complete timestamp in the FRACTIONAL parameter value. 

Instead we will set a SUBSECONDS parameter which will be defined to a FLOAT value with MUST be positive and less than 1.0.

Cheers,
Robert

>>> I just had cause to consult jscalendar-icalendar Section 2.1 <https://www.fastmail.com/mail/draft-ietf-calext-jscalendar-icalendar-02?u=e4d9409a> and I have a couple of issues:

>>>    2. The value isn't DATE-TIME or DURATION, its value is an extension of date-time.  If keeping a full time representation it should be something like "date-time "." 1*DIGIT
>> As I recall my main problem with the previous approach - which was just the fractional part - was that it led to ambiguities and having to define how the full value was rounded to produce the truncated iCalendar value. Having the full value means you just choose to use either the (possibly adjusted) property value or the (possibly more accurate) FRACTIONAL parameter value. No processing or worrying about edge cases.

> Now that you refreshed my memory, I do recall this discussion.  If we allow the fractional part to be positive OR negative, doesn't this solve the rounding problem?  If the full value is rounded with value R, the fractional part can be set to -R.

>> 2. I think FRACTIONAL can be used for DURATION as well as as for DTSTART and the abnf is wrong anyway. We have

> If we're going to keep FRACTIONAL as being the full value, we will have to be more creative with the ABNF because date-time has [time-utc] as its last component, and for durations, we probably only want/need the fractional part when the duration includes dur-second.  So perhaps:

> Having gone through this exercise, I think it would be a lot simpler to just do:

---

From: Ken Murchison <[email-masked]>
Date: Mon, 21 Dec 2020 07:42:01 -0500

On 12/21/20 7:31 AM, Robert Stepanek wrote:
> As noted in my previous email: we already agreed to not set the 
> complete timestamp in the FRACTIONAL parameter value.
>
> Instead we will set a SUBSECONDS parameter which will be defined to a 
> FLOAT value with MUST be positive and less than 1.0.

OK, but if it MUST be positive, don't we still have the issue that Mike 
brought up regarding rounding?  Or we will state that the property value 
MUST NOT be rounded up.

>>>> </mail/draft-ietf-calext-jscalendar-icalendar-02?u=e4d9409a> and I 
>>>> have a couple of issues:
>>>>
>>> accurate) FRACTIONAL parameter value. No processing or worrying 
>>> about edge cases.
>>>
>>
>> allow the fractional part to be positive OR negative, doesn't this 
>> solve the rounding problem?  If the full value is rounded with value 
>> R, the fractional part can be set to -R.
>>
>> If we're going to keep FRACTIONAL as being the full value, we will 
>> have to be more creative with the ABNF because date-time has 
>> [time-utc] as its last component, and for durations, we probably only 
>> want/need the fractional part when the duration includes dur-second.  
>> So perhaps:
>>
>> [email-masked] <mailto:[email-masked]>
>> <https://www.ietf.org/mailman/listinfo/calsify>
>>
>
>

---

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 21 Dec 2020 13:54:18 +0100

On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote:
> OK, but if it MUST be positive, don't we still have the issue that Mike brought up regarding rounding?  Or we will state that the property value MUST NOT be rounded up.

It MUST NOT be rounded, because any client aware of SUBSECONDS would then calculate with a wrong value. The SUBSECONDS parameter only defines the fractional seconds part.

Cheers,
Robert

---

From: Ken Murchison <[email-masked]>
Date: Mon, 21 Dec 2020 08:03:39 -0500

On 12/21/20 7:54 AM, Robert Stepanek wrote:
>>> Instead we will set a SUBSECONDS parameter which will be defined to 
>>> a FLOAT value with MUST be positive and less than 1.0.
>>
>> OK, but if it MUST be positive, don't we still have the issue that 
>> Mike brought up regarding rounding?  Or we will state that the 
>> property value MUST NOT be rounded up.
>>
>
> It MUST NOT be rounded, because any client aware of SUBSECONDS would 
> then calculate with a wrong value. The SUBSECONDS parameter only 
> defines the fractional seconds part.

OK.  WFM

---

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 21 Dec 2020 16:31:55 +0100

I have updated the RFC draft on Github. Here is the excerpt, I appreciate any feedback:

2.1.  SUBSECOND parameter

   Parameter name:  SUBSECOND

   Purpose:  To specify fractional seconds for time values and
      durations.

   Description:  This parameter MAY be specified on properties of type
      DATE-TIME, DURATION and TIME.  It MUST be a FLOAT value less than
      1.0 and MUST NOT be negative.  Implementations MUST ignore
      presence of the SUBSECOND parameter on RECURRENCE-ID properties
      when determining recurrence overrides.

   Format Definition:

   This parameter is defined by the following notation:

       subsecond-param = "SUBSECOND" "=" float

   Example:

       DTSTART;SUBSECOND=0.0123:20111205T040506

On Mon, Dec 21, 2020, at 2:03 PM, Ken Murchison wrote:

Kenneth Murchison

---

From: Michael Douglass <[email-masked]>
Date: Mon, 21 Dec 2020 11:13:27 -0500

Now I'm confused:

The draft 1 had a SUBSECOND parameter:

 From version 1:

   Example:  DTSTART;SUBSECOND=0.03:20190605T133015

The discussion around April this year included this:

>> [...] 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.

So I updated the draft so that version 2 had the full value.

I still felt this is the best approach.

By having the full value in the parameter we avoid implementors needing 
to know if the property value is a rounded or truncated number.

On 12/21/20 10:31, Robert Stepanek wrote:
>>>>> Instead we will set a SUBSECONDS parameter which will be defined 
>>>>> to a FLOAT value with MUST be positive and less than 1.0.
>>>>

---

From: Michael Douglass <[email-masked]>
Date: Mon, 21 Dec 2020 11:25:39 -0500

There's another issue which is touched on in the FRACTIONAL form of the 
spec -

how does a client figure out that the property value no longer matches 
the parameter?

e.g jscalendar aware system sends

DTSTART;SUBSECOND=0.0123:20201205T040506

Old client updates DTSTART but does as it should and preserves the SUBSECOND

DTSTART;SUBSECOND=0.0123:20201205T050000

The SUBSECOND parameter was for the old value. I guess we can see it 
changed but we need to have wording in there such as I added to the 
FRACTIONAL version.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 21 Dec 2020 14:45:01 -0500

>        when determining recurrence overrides.

This last sentence could be a problem if we ever have support for 
sub-seconds in RRULEs.  In fact, there is a PR in libical for adding 
support for recurrences with millisecond precision.  In this case, the 
SUBSECOND parameter on RECURRENCE-ID would be critical in determining 
the correct instance to override.

As an aside, I'm considering writing a draft which documents a variation 
of what is in the PR.

>         subsecond-param = "SUBSECOND" "=" float

Does it make sense to use the float type here if we have to qualify that 
its range is (0.0, 1.0)?  We could just use

"." 1*DIGIT

---

From: Michael Douglass <[email-masked]>
Date: Mon, 21 Dec 2020 14:51:34 -0500

> the correct instance to override.
True - the smart grid people have been asking for the same and they use 
recurrences also. RDATE, EXDATE as well. Possibly anywhere there's a 
date-time.

I've also had conversations about issues around logging - that means 
create dates, modification dates etc.

The one second precision in timestamps is already a problem. It's 
perfectly possible for multiple systems to pass many scheduling messages 
within the space of a second.

> As an aside, I'm considering writing a draft which documents a 
> variation of what is in the PR.
>
>
>
>>     Format Definition:
>>
> Does it make sense to use the float type here if we have to qualify 
> that its range is (0.0, 1.0)?  We could just use
>
> "." 1*DIGIT
>
>
>
>>     Example:
>>
>>>> It MUST NOT be rounded, because any client aware of SUBSECONDS 
>>>> would then calculate with a wrong value. The SUBSECONDS parameter 
>>>> only defines the fractional seconds part.
>>>
>>>
>>> OK.  WFM
>>>
>>> -- 
>>> Kenneth Murchison

---

From: "Robert Stepanek" <[email-masked]>
Date: Tue, 22 Dec 2020 09:33:26 +0100

I thought we had reversed the FRACTIONAL idea earlier this year, but probably I am not remembering that right. In any case, it's great to continue that conversation because it seems clear that neither approach currently covers all of our requirements.

If there is demand for subsecond precision in iCalendar in addition to what we need for JSCalendar, then a separate draft looks like the right next step to me. This is then also the place where we define the FRACTIONAL or SUBSECOND or other parameters, in addition to how to deal with recurrences. The JSCalendar mapping can then build on that.

Cheers,
Robert

On Mon, Dec 21, 2020, at 8:51 PM, Michael Douglass wrote:

>> This last sentence could be a problem if we ever have support for sub-seconds in RRULEs.  In fact, there is a PR in libical for adding support for recurrences with millisecond precision.  In this case, the SUBSECOND parameter on RECURRENCE-ID would be critical in determining the correct instance to override.

> True - the smart grid people have been asking for the same and they use recurrences also. RDATE, EXDATE as well. Possibly anywhere there's a date-time.

> I've also had conversations about issues around logging - that means create dates, modification dates etc.

> The one second precision in timestamps is already a problem. It's perfectly possible for multiple systems to pass many scheduling messages within the space of a second.

>> As an aside, I'm considering writing a draft which documents a variation of what is in the PR.

>> Does it make sense to use the float type here if we have to qualify that its range is (0.0, 1.0)?  We could just use 

Kenneth Murchison
calsify mailing list
Kenneth Murchison
calsify mailing list