Skip to main content

Event Publishing Extensions to iCalendar
draft-ietf-calext-eventpub-extensions-19

Yes

(Alexey Melnikov)

No Objection

(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
(Magnus Westerlund)
(Suresh Krishnan)

Note: This ballot was opened for revision 12 and is now closed.

Murray Kucherawy
No Objection
Comment (2021-01-04 for -17) Sent
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.
Roman Danyliw
(was Discuss) No Objection
Comment (2019-10-16 for -15) Sent for earlier
Thank you for addressing my DISCUSS items.
Warren Kumari
No Objection
Comment (2019-05-29 for -13) Not sent
I apologize - I run out of time to fully review this document, and so I'm balloting "NoObj" in the "I read the protocol action, and I trust the sponsoring AD so have no problem and / or this is outside my area of expertise or have no cycles" sense of the term.
Éric Vyncke
No Objection
Comment (2019-05-18 for -12) Sent
Thanks for the work everyone has put into this document. I liked the section 3.1 'use cases' providing insights on the goal, same for the section about extended examples.

I only have one comment and a couple of nits.

== COMMENT ==


-- Section 4 --

If this syntax replaces completely or partly the one of RFC 5545, then it should be clear in the text (and I have seen that other iCal RFC use the same introduction). What about the other RFC that also update RFC 5545? Is their syntax also impacted?


== NITS ==

-- Section 1  --

Please introduce VCARD before using the word, other words in this section are obvious to the reader.

-- Section 2 --

Missing a '.' at the end of first paragraph.

-- Section 5.4 --

Please use https://example.org rather than https://schema.org or is it a reference, existing URI ?

-- Section 13 --

Last sentence ends with a ','
Alexey Melnikov Former IESG member
Yes
Yes (for -12) Unknown

                            
Barry Leiba Former IESG member
(was No Objection, Discuss) Yes
Yes (2021-01-14 for -18) Sent for earlier
Thanks very much for the changes in Section 9.1, and I think we're now at the best place we can reasonable be here.  Well done.

Thanks also for the changes to clarify the ABNF, and for handling all the other comments.
Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (2020-01-24 for -15) Sent
Thanks for addressing my DISCUSS. Original comment:

Please respond to the Gen-ART review.

The abstract should mention the update to RFC 7986 and the introduction should explain what is updated.

Section 11:

"This specification does not
   introduce any additional privacy concerns beyond those described in
   [RFC5545]."

This seems untrue given the sentence that follows it, so this should be deleted.
Alvaro Retana Former IESG member
No Objection
No Objection (for -12) Not sent

                            
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2020-12-29 for -16) Sent
Thank you for addressing my Discuss points!

The new FlightReservation in §5.4 looks much more plausible; thanks.  I
guess I shouldn't complain that the dates are in 2017...

Section 5.1

While I can't fault the move from param-value to [list of quoted
string], I don't remember what the motivation was for that change.

Section 6.2

   If there is a related ATTENDEE proeprty then all parameters must

nit: s/proeprty/property/

Section 7.2

   For backwards compatibility wuth existing clients and servers when    
   used to schedule events and tasks the ATTENDEE property MUST be used 
   to specify the sheduling parameters as defined for that property.       

nit: s/sheduling/scheduling/

   For other, future uses the CALENDAR-ADDRESS property MUST be used to
   specify those parameters.

I trust the responsible AD to ensure that this new requirement has
received the appropriate level of (WG and community) review.

Section 9

Thanks for the updates to the Security Considerations; they're a big
help!  I did make one further suggested improvement in my response
to my previous ballot's email thread.

Appendix B

At least some of the new versions are in 2020, not 2019
Deborah Brungard Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2019-05-24 for -12) Sent
A couple of comments/questions:

1) “In addition the SOURCE property defined in [RFC7986] is redefined to
   allow VALUE=TEXT and broaden its usage.”
As you redefine the SOURCE property, this document should probably update RFC7986.

2) “This section defines updates to the tables defined in [RFC5545] and new tables.”
I wouldn’t think that the table in RFC5545 need to be “updated”. Isn’t the whole purpose of having a registry that you don’t need to update another document in order to extend the table elements? I would recommend to just define the new and updated elements.

3) “These tables may be updated using the same
   approaches laid down in Section 8.2.1 of [RFC5545]”
I find the use of the word “may” here a bit blurry. I would propose simply “are updated”.

4) Why is this document Proposed Standard? The shepherd write-up sounds like the review and deployment of these extension is currently very limited and therefore experimental might be more appropriate…? It’s looks like the change of the SOURCE property needs standards track, however, maybe it would be better to split this up in a separate document then?

5) Can you maybe further elaborate what the use case for the Order Property Parameter is?

6) “When a LABEL parameter is supplied the language of the label must
      match that of the content and of the LANGUAGE parameter if
      present.”
Shouldn’t this be a normative MUST? Or actually probably a SHOULD?
Suresh Krishnan Former IESG member
No Objection
No Objection (for -13) Not sent