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

On 1/4/21 14:44, Murray Kucherawy via Datatracker wrote:
> 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 tohttps://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.)

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

> 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.)

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.

> 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.
Fixed
> Section 7: I believe the ABNF here needs a once-over.
Barry had some fixes I will apply
> Section 9.2: For the threat described in the first paragraph, are there any
> possible mitigations to suggest?
Added some text
> 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.
Fixed
> 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.

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
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify