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

[Michael Douglass <[e-mail]>]

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