Subject: [calsify] Shepherd Review of draft-ietf-calext-caldav-attachments

From: Philipp Kewisch <[email-masked]>
Date: Thu, 13 Apr 2017 12:05:55 +0200

Hello All,

I've gotten around to finishing my review on this document. Aside from a
minor typo, I have two simple questions, just to clarify out of personal
interest:

>    Specific instance  A specific iCalendar instance is targeted by using
>       its "RECURRENCE-ID" value as the item value.  That value MUST
>       correspond to the RECURRENCE-ID value as stored in the calendar
>       object resource (i.e. without any conversion to UTC).  If multiple
>       items of this form are used, they MUST be unique values.
Can you clarify why you chose to not allow specifying this value in any
form, so that the server does timezone translation if needed?
>        D.  Upon successful creation of the attachment resource, and
>            modification of the targeted calendar object resource, the
>            server MUST return an appropriate HTTP success status
>            response and include a "Cal-Managed-ID" header field
>            containing the "MANAGED-ID" parameter value of the newly
>            created "ATTACH" property.  
Any specific reason to shorten "Calendar" to "Cal" here?

>  Malicious content could be introduced into the Calendar Server by way
>    of a managed attachment, and propagated to many end users via
>    scheduling.  Servers SHOULD check managed attachments for malicious
>    or inappropriate content.  Upon detecting of such content, servers
>    SHOULD remove the attachment, following the rules described in
>    Section 3.12.5.
"Calendar Server" should probably be lowercase here, as you are not
referring to a specific product.

I've added the shepherd writeup to the datatracker, there were no
irregularities. With those questions clarified I think this is good to
go. Thank you for working on this document, I am looking forward to
having it published.

Kind Regards,
Philipp

---

From: Ken Murchison <[email-masked]>
Date: Thu, 13 Apr 2017 14:25:55 -0400

> form, so that the server does timezone translation if needed?

I don't recall the exact reason, but presumably its so that the server 
can simply match the RECURRENCE-ID by value without having to do any 
translation.  Perhaps Cyrus and/or Arnaud remember the exact reasoning.

> Any specific reason to shorten "Calendar" to "Cal" here?

No technical reason as I recall.  I'd recommend against changing it now 
given the existence of a lot of Apple-deployed code.

> referring to a specific product.

Agreed.  I will make this change.

I also need to look at Gren Elliot's review again and make any necessary 
changes.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Paul B Hill <[email-masked]>
Date: Thu, 13 Apr 2017 20:56:20 +0000

Hi,

If I recall correctly, while letting the server simply match the RECURRENCE-ID is a nice side effect, there are edge cases where the requirement is essential in order to guarantee the correct behavior. Recurring meetings happen over a span of time AND timezone definitions change over time. The timezone definitions include not only the offset at a particular time of year, but also the geographic region to which the rule applies. When the specification was being developed there was one region that had overlapping timezones and the choice of which timezone was applied implied a political affiliation (in a war zone.) Performing a translation on each server to which the iCalendar instance may be forwarded prior to storage could lead to confusion.  Of course, the organizer may reside in an area where there is timezone instability over the duration of the recurrence, but presumably, the organizer would be in the best position to know that an issue updates as needed. 

Paul

-----Original Message-----
From: calsify [mailto:[email-masked]] On Behalf Of Ken Murchison
Sent: Thursday, April 13, 2017 2:26 PM
To: Philipp Kewisch <[email-masked]>; Calsify <[email-masked]>
Cc: [email-masked]
Subject: Re: [calsify] Shepherd Review of draft-ietf-calext-caldav-attachments

On 04/13/2017 06:05 AM, Philipp Kewisch wrote:
> Hello All,
>
> I've gotten around to finishing my review on this document. Aside from 
> a minor typo, I have two simple questions, just to clarify out of 
> personal
> interest:
>
> Can you clarify why you chose to not allow specifying this value in 
> any form, so that the server does timezone translation if needed?

I don't recall the exact reason, but presumably its so that the server can simply match the RECURRENCE-ID by value without having to do any translation.  Perhaps Cyrus and/or Arnaud remember the exact reasoning.

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 14 Apr 2017 11:11:47 -0400

Hi Philipp,
Thanks for you review.

> form, so that the server does timezone translation if needed?

I think we wanted to avoid the need for the server or client to have to do 
any conversions, which could prove problematic particularly if the time 
zone definitions the client and server have differ (which was something 
that could happen at the time we wrote the initial spec, but is now less 
likely to happen with the time zones by reference feature).

> Any specific reason to shorten "Calendar" to "Cal" here?

I don't recall any specific version for that choice. However, it would be 
best not to change that given that existing deployments do make use of it.

> referring to a specific product.

Agreed. Ken can make that change.

-- 
Cyrus Daboo