New Properties for iCalendar
draft-ietf-calext-extensions-05

The author has addressed all my DISCUSS points and comments in email. (Thanks!). I've cleared on the assumption the proposed text will make it into a revision.

Dan Romacanu did the OPS DIR review. The RFC5706 does not apply.

Thanks for the updated text to address the SecDir review and Stephen's additional comments (I followed that discussion as well).

I think it'd be a fine thing if the calext WG were to consider privacy
issues with caldav in general. As it'd probably be wrong to try get
all of that done in this one document, perhaps we could try and 
see if the WG have sufficient interest and cycles to take that on?

My previous discuss text (plus an additional point about images
is below.

- I think adding some privacy considerations to this would be good,
either as new text or via references.  Did the WG consider privacy
issues? Some that occur to me are:

   - names, descriptions and identifiers here are all ones that
     might allow (re)identification in unexpected ways

   - the UID property in particular probably ought be random and
     probably ought not be re-used for anything else, some RFC2119
     SHOULD statements about that would seem like they'd be good.

   - doing a refresh against a calendar at the expected frequency
     could be a good way to re-identify someone - if I can read the
     expected frequency and some IP address connects (even all over
     TLS) at about that regularity then I can be reasonably sure
     that the client is someone subscribed to that address, and
     maybe use that to track a person's movement across various
     networks. (That's different from the text in section 7 which
     assumes that the URL is what's tracked, but the connection
     can be just as revealing, for some calendars.)

I'm not trying to insist all that analysis be documented in this
draft but I would hope that the WG have considered the issues and
how best to document those and have a plan to do that. (If I'm told
such a plan exists and what it is, I'll clear.)

This is related to, but a little different from, Kathleen's discuss,
depending on the added privacy considerations text which I've not
managed to find in the secdir review thread.  But this should be as
easily cleared I'd guess.

And another possible issue now occurs to me: I remember that one
social network had an issue where all the avatar image sizes were
nearly unique, so that even though those were all accessed over TLS,
one could identify users and their buddies by watching those be
downloaded. (That depended on how the social network in question
made avatar images available, which'll likely be different here.)
But there may be a reason to recommend normalising image sizes here
as well and to encourage only offering those over https and not
http.