[calsify] draft-ietf-calext-jscalendar - thoughts

[Doug Royer <[e-mail]>]

On another thread (in [e-mail]) someone declared 
draft-ietf-calext-jscalendar as a replacement for iCalendar [RFC5545]. 
Not sure if that was the official position or an individuals view. I 
initially read the draft and updates with the idea that it was another 
representation of iCalendar.

First, a ton of hard work was done on this draft. My comments below are 
my second thoughts after hearing it is a replacement and not a 
representation of iCalendar. So I re-read this draft with replacement in 
mind. These are not necessarily problems, just thoughts and questions.

  **I understand that many of these topics may have been discussed on 
the mailing list. However, if not in the spec when released, they will 
be confusing. **

1. If it is a replacement for iCalendar, please provide a list of 
obsoleted properties and and some kind of migration path for the 
replacement. Some comments in the spec imply obsoleted properties, they 
are not named at all in this spec. (DTEND for example - which I think 
should have never made it into iCalendar). Is this by design? If so, 
what exactly?

2. Ambiguous ways of representing the same event. When it comes to 
recurring events, they can still be represented with an RRULE 
(recurrenceRule) OR with RDATE (recurrenceDates), or a combination. I 
could not find mention of a preferred way. (Something like use 
recurrenceRule only, except when it is not possible, then add 
recurrenceDates, and/or recurrenceOverrides ).

2.1 Same with updates to events that have recurrences. EXACTLY what is 
sent in the update? A complete replacement? Just what changes? These are 
also ambiguous in iCalendar/iTIP/iMIP.

3. iTIP/iMIP Is a jCal iTIP/iMIP replacement in the works? If not, those 
rescheduling ambiguities still exist. What (exactly) to send back when 
requesting a change to the schedule. Send the entire object, just the 
recurrence-id that is being requested with the proposed updates? Or what?

3.1 Are jCal iTIP/iMIP messages sent in jCal format or iCalendar format?
What is the jCal mapping for the iTIP/iMIP objects? How are PUBLISH, 
REQUEST, REPLY, ADD, ... method represented in jCal? As this spec does 
not mention them, does a CUA send them out in iCalendar format, even 
when the original message was in jCal format? Is there a plan? Or are 
the iTIP methods to be declared obsolete?

4. How does this relate to WebDAV and its objects, methods, or 
procedures? Only a brief mention is included.

5. Is a iCalendar to jCal migration path specification in the works?

6. Unrelated to ambiguous. Why are alarms/alerts still sent? Does anyone 
accept an alarm the organizer sends out? Example, I live 30 minutes 
away. What good is a 5-minute alarm to me? What do you do if someone 
sends an updated alarm/alert in an iTIP COUNTER? Is it ignored? Used as 
the suggested update?

6.1 Will people really be sharing the 'snoozed' property of an 
alarm/alert with others?

6.2 Alarm/alert "...  *acknowledged*: "UTCDate" (optional)

       When the user has permanently dismissed the alert the client MUST
       set this to the current time in UTC.  Other clients which sync
       this property can then automatically dismiss or suppress duplicate
       alerts (alerts with the same alert id that triggered on or before
       this date-time).

Is there a plan to separate user specific data from shared data? Clearly 
this is not to be shared with the organizer or other participants. And 
is not supposed to be updated on the master object from the organizer. 
(Thinking WebDAV where everyone can share the same link to the same event).

Their seems to be two kinds of data, API data (alerts) and public data 
(what the organizer would send). What implementations send back and 
forth between participant and organizer is not defined (ambiguous).

This is kind of talked about under "4.6.1 localizations", but I 
understand 'localizations' to mean language specific, not private data.
See useDefaultAlerts under localizations.

6.3 Where is valarm? Gone? Alert mentions alarms, yet no definition of 
alarm.

7. Under "Security Considerations"
Should it mention "do not send private data to organizer"? And a list of 
what NOT to send: Alarms, Alert updates/snooze/...

8. I am confused by highlighting meaning of *this*, _this_, and "this" 
As described in 1.3 and the highlighting methods throughout this spec.
I have not seen these used in a draft before.

9. The term "master object" is used once and not defined. Is this the 
organizer object? Or the users copy?

10. The 'JSGroup' object seems to be new to jCalendar and iCalendar. Did 
I miss something in past documents?

11. Color (4.2.10). Can't imagine implements would not just totally 
ignore this property from organizer.

12. _excluded_ property (4.3.2). I assume (ambiguous) if it can ever be 
set to false? Can I send it in object set to false at all? When would it 
be valid to set it to false? What is the point of ever being able to 
send one set to false?

13. Should alerts be excluded from a 'PatchObject'?

14. In 4.4.3 privacy: what is a 'sharee'? Is a sharee a participant? Or 
a non-Participant? How can a completely hidden ("as though it did not 
exist") calendar be shared?

14.1 Is any calendar event shared when it has more than 1 participant? 
(ambiguous) Or does shared mean the same object is shared between 
participants (as in one persistent storage object shared between 
participants)? Because if the objects have multiple copies (one per 
calendar user agent), then what does secret mean? Does it mean that 
calendar user agents MUST NOT make the event viewable by others in their 
own calendars? So they would just mark it as unavailable time (ambiguous).


14.2 Public, so can I limit what I share and still call it public. Can I 
for example limit the viewing of other participants, but otherwise make 
it public?

14.3 "private" and "hidden ... [from]... sharee". From participants? Or 
just from  non-participants?

14.4 Are not ALL calendar objects shared when there is more than one 
participant?

14.5 The same iTIP problem exists. When a participant updates their 
attendee status, and the calendar is public, what exactly does (if 
anything) the organizer send out to other participants? I would prefer 
nothing at all.

15. 4.4.5 participants "memberOf" Exactly how is this used? It is a new 
property to calendar - correct?


-- 

Doug Royer - (http://DougRoyer.US)
[e-mail]
714-989-6135