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

[Tim Hare <[e-mail]>]

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.

 

 

 

From: calsify [mailto:[e-mail]] On Behalf Of Michael Douglass
Sent: Friday, April 3, 2020 6:55 PM
To: [e-mail]
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, [e-mail] <mailto:[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] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/calsify