Subject: [calsify] Murray Kucherawy's No Objection on draft-ietf-calext-eventpub-extensions-17: (with COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Mon, 04 Jan 2021 11:44:03 -0800

Murray Kucherawy has entered the following ballot position for
draft-ietf-calext-eventpub-extensions-17: No Objection

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-eventpub-extensions/

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

Section 1.2 says "For example, we may want to record who is participating in a
public event", but the Privacy Considerations section doesn't say anything
about the fact that this could collect data about people who are interested in
the event, even if they don't go (though the location issue is mentioned). 
Also, especially since 2020, the public event could be a purely online event,
where location data isn't part of the issue.  (Alternatively, if this is meant
to address in-person events only, that would be useful to say up front.)

Section 6.2 (and other sections, but I noticed it here): ABNF literal strings
are case-insensitive.  That means, for example, that the ABNF here would allow
"ACTIVE" for a "partvalue", but would also allow "active", "AcTiVe", etc.  Is
that acceptable?  (This probably applies to lots of prior CALEXT documents -- I
admittedly didn't check -- so it may not be worth fixing here.)

Section 6.4:

   Property Parameters:  IANA, or non-standard property parameters can
      be specified on this property.

I think that should be "IANA-registered"?  Same issue in Sections 6.5 and 6.6.

Section 7: I believe the ABNF here needs a once-over.

Section 9.2: For the threat described in the first paragraph, are there any
possible mitigations to suggest?

Section 10.2: In "without that participants express permission", that should be
"participant's".  There's also a period missing at the end of the second last
paragraph, though as it reads, it's possible there's even some intended text
missing.

Section 11.2: The rules for making registrations into both the existing
registries and these new ones are striking.  RFC 8126 doesn't even create a
category that is a combination of Expert Review and Standards Action, but
that's what this spells out.  And I wonder what would happen if we were to
publish a Standards Track RFC (which has IETF consensus) with which the
Designated Expert disagreed.  I'm not asking for anything to change here given
that consistency with the existing registries is probably desirable, but it
does set an unusually high bar for registrations.

---

From: Michael Douglass <[email-masked]>
Date: Wed, 13 Jan 2021 11:54:19 -0500

On 1/4/21 14:44, Murray Kucherawy via Datatracker wrote:
> Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html

I'll add some extra text- Something like:

OLD

The addition of location information to the new participant component
provides information about the location of participants at a given
time.  This information MUST NOT be distributed to other participants
without that participants express permission.  Agents processing and
distributing calendar data must be aware that it has the property of
providing information about a future time when a given individual may
be at a particular location, which could enable targeted attacks
against that individual.

NEW

   The addition of location information to the new participant
   component provides information about the location of
   participants at a given time. This information MUST NOT be
   distributed to other participants without those participants
   express permission. Note that there may be a number of
   participants who may be unaware of their inclusion in the
   data.

   Agents processing and distributing
   calendar data must be aware that it has the property of
   providing information about a future time when a given
   individual may be at a particular location, which could
   enable targeted attacks against that individual.

END

> admittedly didn't check -- so it may not be worth fixing here.)

I've been working on my ical4j implementation of this and I was having 
the same thoughts.

I looked at rfc4589 - the location types registry - and all the values 
are lower case. There doesn't appear to be any text to specify whether 
or not they are case sensitive values.

5545 says in section 2 "enumerated property values, and property 
parameter values are case-insensitive." - thus ACTIVE and aCtIvE are 
intended to be the same.

However, jscalendar - which we need to be able to map to and from 
says:(Section 3) "Property names and values are case-sensitive."

So 4589 doesn't say anything, 5545 says insensitive jscalendar says 
sensitive.

I'm inclined to at least redo the participant and resource types in 
lower case. jscalendar has a lot of places where it uses the icalendar 
converted to lower case.

> I think that should be "IANA-registered"?  Same issue in Sections 6.5 and 6.6.
Fixed
> Section 7: I believe the ABNF here needs a once-over.
Barry had some fixes I will apply
> possible mitigations to suggest?
Added some text
> paragraph, though as it reads, it's possible there's even some intended text
Fixed
> does set an unusually high bar for registrations.

I'm inclined to agree - with all the points. If the general feeling is I 
should come up with more manageable constraints I can do that.

>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Barry Leiba <[email-masked]>
Date: Wed, 13 Jan 2021 12:13:38 -0500

> 5545 says in section 2 "enumerated property values, and property parameter values are case-insensitive."
> - thus ACTIVE and aCtIvE are intended to be the same.
>
> However, jscalendar - which we need to be able to map to and from says:(Section 3) "Property names and
> values are case-sensitive."

I don't see a problem here: clearly, mapping from iCalendar to
jsCalendar will fold to lower case, and mapping from jsCalendar to
iCalendar will preserve lower case.  Do you see a problem (as opposed
to a "Gee, why did we make them different?" question)?

> I'm inclined to agree - with all the points. If the general feeling is I should come up with more manageable
> constraints I can do that.

As I've said to Murray off list, I think this is a broader issue that
we should fix in an update of 5545, rather than trying to fix it here.
You aren't actually specifying registration policies in this document,
but are instead using the registration policies in the base iCalendar
by reference.  I think that's the right way to go for now.

Barry

---

From: Michael Douglass <[email-masked]>
Date: Wed, 13 Jan 2021 12:31:56 -0500

> to a "Gee, why did we make them different?" question)?

I think it was an uncompleted thought. The relations draft uses link 
relations and it turns out they are specified to be case-insensitive 
(https://tools.ietf.org/html/rfc8288 section 2.1.1) so we have values 
like (from 
https://www.iana.org/assignments/link-relations/link-relations.xhtml) 
"convertedFrom".

It just feels like we have no consistency across standards in how values 
like these should be matched. I'm inclined to think case-insensitivity 
is the only safe option.

> by reference.  I think that's the right way to go for now.
Good.