Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.txt

[Michael Douglass <[e-mail]>]

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, [e-mail] 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/calsify