[caldav] Comments on draft-desruisseaux-caldav-sched-09

[Keith Jay Gillis <[e-mail]>]

Hi,

If I'm reading the draft correctly, the server automatically adds
scheduling objects to the default calendar in response to scheduling
requests without giving the user an opportunity to review them. I might
be misunderstanding parts of the draft, but this behavior seems like it
could cause problems.

In draft-desruisseaux-caldav-sched-09 §B.3 the notification has TRANSP
set to OPAQUE. Would the TRANSP property of the scheduling object added
to the default calendar be set the same way? If freebusy altering events
are added to the calendar without confirmation, someone could make you
appear busy when you are actually free. If the incorrect information
isn't removed quickly, it could make planning a meeting difficult for
someone using the freebusy information. This might not be an issue if
events with the attendee's PARTSTAT set to anything other than CONFIRMED
are excluded from freebusy and if the server only automatically adds
events with PARTSTAT set to NEEDS-ACTION. RFC 4791 §7.10 specifies
something similar to using PARTSTAT where freebusy is derived from
TRANSP and STATUS. 

Would unconfirmed events be treated as though CLASS was set to PRIVATE?
Could an automatically added event be used to make someone believe you
are attending an event you are not actually attending?

I know ACLs could be used to prevent the malicious addition of events to
the default calendar. What if you want to receive events from someone
you do not completely trust? Would you have to choose between blocking
them, and not receiving any invitations from them, or allowing them, and
risking abuse? Would requests from blocked users be dropped without
alerting the recipient?

I'm also curious about how the management of ACLs would work. Would
these ACLs typically be set to deny by default? If so, would an
organizer of an event that involved people from multiple organizations,
who might not have added the organizer to their ACLs, need to contact
the potential attendees through some out-of-band means to request that
the organizer be added to the attendees ACLs before the organizer could
send invitations? That would be cumbersome.

The draft does not make the relationship between server-to-server
delivery of invitations and the features described in the draft clear.
Draft 04 made it clear in §4.2 ¶4 with "note that remote delivery
mechanisms are not defined in this specification". A similar sentence in
draft 09 might help.

Thanks,
Keith