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

[Ken Murchison <[e-mail]>]

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.



>
> On Mon, Dec 21, 2020, at 1:17 PM, Ken Murchison wrote:
>>
>> Hi Mike,
>>
>>
>> On 12/21/20 12:09 AM, Michael Douglass wrote:
>>>
>>> On 12/19/20 13:50, Ken Murchison wrote:
>>>>
>>>> All,
>>>>
>>>> I just had cause to consult jscalendar-icalendar Section 2.1 
>>>> </mail/draft-ietf-calext-jscalendar-icalendar-02?u=e4d9409a> 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
>>>>
>>> 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.
>>>
>>
>> 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
>>>
>>> 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
>>
>>
>> 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
>> Senior Software Developer
>> Fastmail US LLC
>> _______________________________________________
>> calsify mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/calsify 
>> <https://www.ietf.org/mailman/listinfo/calsify>
>>
>
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC