Subject: [calsify] Stephen Farrell's Discuss on draft-ietf-calext-availability-03: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 05 Jul 2016 08:00:46 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-calext-availability-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-calext-availability/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

section 9: First, thanks for this, good to see it here.
Second, is "might need to be removed" sufficient in the 2nd
para? I don't think it is really. Wouldn't it be better to
say something more like "unless other information (e.g. a
user preference) is available, such attributes MUST be
removed"? If so, then I'd also add the list of attributes
or property values that are ok to leave in, or the list
that MUST be removed.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- abstract - what're iCalendar and iTIP? Better to not use
such in the abstract if you can think of a way to explain in
natural language.

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 05 Jul 2016 13:25:22 -0400

Hi Stephen,

Well, as explained in the next sentence, there are situations where a user 
might want someone else to know there whereabouts (e.g., family members). 
So I would rather not habe a "MUST be removed". Perhaps a better statement 
is this:

   When "VAVAILABILITY" components are sent to or shared with other
   calendar users, care has to be taken not to expose more information
   than is needed by each recipient.  For example, a business owner will
   likely not want their customers to know where they might be or what
   they might be doing, but family members might be willing to expose
   such information to each other.  Thus, calendaring systems allowing
   "VAVAILABILITY" components to be sent or shared to other calendar
   users, MUST provide a way for non-essential properties to be removed
   (e.g., "SUMMARY", "LOCATION", and "DESCRIPTION").

Would that work for you?

The RFC editor has been happy in the past with just having "iCalendar" 
(without even a reference, e.g., 
<https://datatracker.ietf.org/doc/rfc7809/>). I will add (RFC 5545) and 
(RFC 5546) references in there. If the RFC editor prefers something 
different know, then we can change that.

-- 
Cyrus Daboo

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 5 Jul 2016 18:36:59 +0100

Hiya,

On 05/07/16 18:25, Cyrus Daboo wrote:
> Well, as explained in the next sentence, there are situations where a
> user might want someone else to know there whereabouts (e.g., family
> members). So I would rather not habe a "MUST be removed". Perhaps a
> better statement is this:
> 

That's better yes, and enough for me to clear the discuss. But I do
still wonder which'd be more likely to be implemented and to have the
desired effect, so let's see if others chime in on the choice between:

- <these> attributes MUST be removed by default unless there's other
  information available (my suggestion), or,
- implementations MUST provide a way to remove (yours)

And to be clear, I would be fine if "other information" was such that
all my work calendar stuff was visible to colleagues on the basis that
I and they use the same infrastructure, so I'm not trying to argue that
each user needs to specifically ok everything, as I agree that'd be
unworkable.

If nobody else has an opinion and you publish a revision as per your
suggested text, I'll clear and make this a comment.

S