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

Summary: Has 4 DISCUSSes. Needs one more YES or NO OBJECTION position to pass.

Alissa Cooper Discuss

Discuss (2019-05-29)
Section 7.6:

" The format type and schema parameters can be specified on this
      property and are RECOMMENDED for text or inline binary encoded
      content information."

Doesn't this need to be REQUIRED rather than RECOMMENDED in order for it to improve rather than potentially worsen interoperability?

Section 8.1:

"User agents MUST NOT include this information
      without informing the participant."

This seems like it needs to say "without the participant's express permission." (As in https://www.w3.org/TR/geolocation-API).
Comment (2019-05-29)
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.

Roman Danyliw Discuss

Discuss (2019-05-29)
Per the Security Considerations section, [RFC3986] and [W3C.REC-html51-20171003] were helpful.

I was hoping to see cautionary text for the potentially danger of handling/parsing arbitrary binaries as allowed by STRUCTURED DATA.  I didn’t see it in downstream references.
I also tried to find the referenced section suggested by “Security considerations relating to the ‘ATTACH’ property, as described in [RFC5545]” but could not.  It’s not the explicit Security Considerations (Section 7 of [RFC5545) or in the definition of Attachment (Section 3.8.1.1 of [RFC5545]).  Do you mean Section 3.1.3, Binary Content?  Could you please make it clear which section you meant.
Comment (2019-05-29)
(1) Sections 5.1. and 5.2 state “New resource types SHOULD be registered in the manner laid down in this specification.”  It would be cleared if you explicitly referenced the relevant IANA section.

(2) Section 6.  Doesn't the sentence “[t]he SOURCE property defined in [RFC7986]  is redefined …” suggests that this document should also officially update RFC7986?

(3) Editorial nits:

Global.  “vcard” and “VCARD” is used interchangeably.  Recommend choosing one and being consistent

Section 2.  Misplaced comma?.  s/JSON,  [RFC8259]/JSON [RFC8259]

Section 3.  Typo.  s/informations/information/

Section 3.1.2. Typo. s/traveller/traveler/

Section 3.1.2.1.  Typo. s/non/none/

Section 7.5.  Typo.  s/sevices/services/

Section 9.2.  Typo.  s/plaaning/planning/

Benjamin Kaduk Discuss

Discuss (2019-05-28)
I want to talk some about the redefinition of SOURCE.  While I agree
that the original definition's applicability is more narrow than it
needs to be, that doesn't seem to be enough to convince me that there's
enough justification to make it so broad as to provide vcard information
about a participant or an event link-back, as opposed to just the
canonical source of updates for a given object/component.  I must
apologize for having essentially not done a search of the WG discussion
archives for this topic, and pointers into the archive could help to
convince me that this redefinition is a stable, interoperable, and
backwards-compatible choice.

The example in Section 5.4:

     STRUCTURED-DATA;FMTTYPE=application/ld+json;
      SCHEMA="https://schema.org/FlightReservation";
      ENCODING=BASE64;VALUE=BINARY:Zm9vYmFy

contains an inline value that doesn't seem to decode to a valid
FlightReservation JSON object.

Perhaps I'm misreading, but the ABNF in Section 7.6 does not seem to
allow for an explicit VALUE=TEXT parameter to be given, and the
description does not list TEXT as the default value type.  (I note that
the listed example does include VALUE=TEXT, causing this to rise to a
Discuss-level internal inconsistency.)

Similarly, the examples in Section 8.1 seem incomplete, since they omit
the REQUIRED dtstamp and uid properties.
Comment (2019-05-28)
Section 3

   The properties defined here can all reference external meta-data
   which may be used by applications to provide enhanced value to users.

This sentence seems to raise my hackles for two reasons: (1) it reads
like marketing copy and not a technical specification, and (2) it calls
to mind analogies to all the privacy-harming technologies that have
become pervasive in HTML mail and the web ecosystem: tracking pixels,
call-home URLs, etc..  While I agree that loading remote content can be
helpful, it is definitely a dual-use technology; I appreciate that the
privacy considerations attempt to cover the risks of remote content.
Perhaps there is additional room to nod to those risks at this point in
the document.

   Using STRUCTURED-LOCATION, information about a number of interesting
   locations can be communicated, for example, address, region, country,
   postal code as well as other informations such as the parking,
   restaurants and the venue.  [...]

nit: "the parking" is incomplete; perhaps "parking availability"?
nit: "restaurants" is also incomplete; perhaps "nearby restaurants"?

                           In social calendaring it is often important
   to identify the active participants in the event, for example a
   school sports team, and the inactive participants, for example the
   parents.

I share the directorate reviewer's confusion as to what "social
calendaring" is.

Section 3.1.1

            In addition, there will be sponsorship information for
   sponsors of the event and perhaps paid sponsorship properties
   essentially advertising local establishments.

I'm not sure how much precedent the IETF has for facilitating
advertising as a specific goal.

Section 3.1.2.1

   A meeting may have 10 attendees non of which are co-located.  The

nit: s/non/none/

   current ATTENDEE property does not allow for the addition of such
   meta-data.  The PARTICIPANT property allows attendees to specify
   their location.

nit: PARTICIPANT is a component, not a property.

Section 4

Please be more concrete about what actually is changing, e.g., the
addition of participantc to eventc/todoc/journalc, as well as the more
obvious incremental addition to the properties' ABNF.
Making the reader cross-reference to RFC 5545 for each ABNF production is
rather unfriendly.

Section 5.2

Is a video remote conferencing facility assumed to also provide audio
functionality?

Section 5.3

nit: "lowest level of ordering" is perhaps ambiguous (though the
subsequent clarification is not); I'd suggest just "as being ordered
last".

   Example uses:  The ORDER may be applied to the PARTICIPANT-TYPE
      property to indicate the relative importance of the participant,
      for example as a sponsor or a performer.  For example, ORDER=1
      could define the principal performer or soloist.

side note: It's not very clear to me that it's going to be possible to
assign a complete ordering to all participants once events start getting
complicated.  There is the option of just leaving a single low-priority
"everybody else" bucket and not worrying too hard, but this feels like
something easy that gets a quick win but will not be a full solution.
(Which, to be clear, is not necessarily bad.)

Section 5.5

While I'm sympathetic to not actually putting a full HTML styled
description in the example, I'd suggest at least putting in the closing
</html> tag.

Section 7.1

nit: is there a reason for active participants to be taking a "role" but
inactive ones taking a "part"?

Section 7.3

It's not clear to me when one would attach an alternative representation
to a STYLED-DESCRIPTION rather than just adding the other representation
as another STYLED-DESCRIPTION in its own right.  Presumably this just
means I'm not an iCalendar expert, but maybe there is something more
subtle going on here.

Section 7.4

Do we want a reference to RFC 7986 again for the LABEL parameter?

      When used in a component the value of this property provides
      information about the event venue or of related services such as
      parking, dining, stations etc..

Does this hold universally for all components (e.g., even PARTICIPANT) or
only some of them?

I don't understand all the discussion about the "Use of the related
parameter", which is presumably just my lack of familiarity with
iCalendar in general.  But it's surprising that we'd have to worry about
timezones and such for events/todos related to a structured *location*.

Section 7.5

     strucewaval   = ( uri / text )

"strucewaval" seems like a typo and does not appear elsewhere in the
document.

Section 8.1

   Conformance:  This component can be specified multiple times in a
      "VEVENT", "VTODO", "VJOURNAL", or "VFREEBUSY" calendar component.

   Description:  This component provides information about a participant
      in an event, task or poll.  [...]

Why do these two lists have different cardinality?

   Privacy Issues:  When a LOCATION is supplied it provides information
      about the location of a participant at a given time or times.
      This may represent an unacceptable privacy risk for some
      participants.  User agents MUST NOT include this information
      without informing the participant.

How is this "informing" supposed to work when the participant is not a
human (e.g., an organizational SPONSOR or a sports team)?

Also, it seems likely that there may be attributes (parameters) other
than location that a given individual may not wish to be disclosed, or
at least disclosed globally.

In the last example:

                     BEGIN: PARTICIPANT
                     SOURCE;FMTTYPE=text/vcard;

this last semicolon should be a colon?

                      http://dir.example.com/vcard/contacts/contact1.vcf
                     PARTICIPANT-TYPE:CONTACT
                     DESCRIPTION:A contact:

The last colon here is superflous?

                     END:PARTICIPANT

Section 8.2

It's not entirely clear to me that we need this much discussion about
schedulable PARTICPANTs -- can't we get most of the way with the
status quo of ATTENDEE properties being schedulable, and just noting
that for such ATTENDEEs, the matching PARTICIPANT may have additional
(e.g., location) information?

Section 9.1

This example seems to illustrate a weakness of STRUCTURED-LOCATION,
namely that it relies upon the human readaing the LABEL parameter to
understand what type of relationship the location has to the event.  It
seems that calendaring software would be able to present a better
interface if there was some structured information available about the
type of location, as well as the freeform string of the label.

Section 9.2

The time gap between DTSTAMP and CREATED is rather large; is that
intended?

It might also be helpful to give some indication of the meeting room
where the event is nominally occurring, so as to make the "At home"
location more clearly a remote location.

Section 10

Potential additional security considerations: the target of the
CALENDAR-ADDRESS URLs may have access control on them, and not all
recipients of the property may be authorized to access the referenced
calendar.  Such access control is properly a matter for the owner of the
calendar in question, but it may still be appropriate to mention it
here.

   Security considerations relating to the "ATTACH" property, as
   described in [RFC5545], are applicable to the "STRUCTURED-DATA"
   property.

I had a quick look in RFC 5545, and neither the labelled Security
Considerations section nor any mention of "ATTACH" (with quotes) seemed
to cover such security considerations.  What am I missing?

   When processing HTML content applications need to be aware of the
   many security and privacy issues as described in the IANA
   considerations section of [W3C.REC-html51-20171003]

nits: this needs at least a comma after "content", and possibly another
comma before "as described".

Section 11

There may be some privacy considerations relating to the ORDER
parameter, as it provides an indication of some entity (the
organizer's?) perception of the relative importance of other
participants.

   The addition of location information to the new participant component
   provides information about the location of participants at a given
   time.

We probably should go a little further and note that this may facilitate
tracking of individuals or malicious actions targeted against them at
the known location/time pair.

Barry Leiba Discuss

Discuss (2019-05-27)
Thanks for the work in this document; I think there’s useful stuff here, and I appreciate what it took to put it together.  One thing at the DISCUSS level:

— Section 10 —
It’s good to refer to RFC 3986 for URI-related security considerations, and all of them do apply here.

Something else that comes to mind that comes along with a set of new URIs is whether they actually point to what they say they do.  I don’t see that there’s any way to verify that they do, and I’m very skeptical about the effectiveness of warning an end user about this sort of thing, for many reasons.  I can see why allowing URIs is convenient and compelling, but I’m very heavily concerned about tracking and other privacy leaks, malicious and deceptive content, and other such problems, especially considering the prevalence of abusive calendar invitations these days.

I’m not sure what the answer is here, but let’s have a discussion about it and see where we can go with it.

Update: We will discuss this in the calext interim meeting, jointly with CalConnect.
Comment (2019-05-27)
— Section 3 —
As with Section 1, you’re going into detail about the properties and component, details that again seem out of place.  Again, I suggest moving those details into the sections that define those items, and promoting Section 3.1 to be Section 3 (so Section 3 becomes the “Use Cases”).


======== Resolved comments below; thanks for addressing them. ========

— Section 1 —
This strikes me as far too much detail for the Introduction.  You give a bit of detail about each component, property, and parameter — details that should simply be left for the definitions that come later.  Even listing them isn’t necessary, because there’s a table of contents.  Having all that in the Introduction puts it out of context: it’s too early in the document for a reader to get the details, and it comes out as rather disorganized, scattered.

I suggest merging the paragraph about the PARTICIPANT component into the second paragraph of Section 2, and then removing everything after that from Section 1 entirely.  The information should instead go into an introductory paragraph in each added element’s definition section.

— Section 2 —

   This is a
   better match for the way [W3C.REC-xml-20081126] and JSON, [RFC8259]
   handles such structures and allows richer definitions.

There’s an extraneous comma after “JSON”, and it should be “handle” to match the plural subject.

— Sections 5.2, 7.1, and 8.1 —
Please see BCP 178 (RFC 6648), and then remove x-name and x-prop.  Thanks.

— Section 5.3 —

      Its value MUST be an integer greater than or equal to 1 that
      quantifies the order with 1 being the first in the ordering.

You quantify cardinal numbers, not ordinal numbers.  I think “specifies” is the word you want here.

      A given value, or the
      absence of a value, MUST NOT be interpreted on its own.

I don’t understand what this means; can you explain?

      This parameter MAY be applied to any property that allows multiple
      instances.

What about properties that don’t allow multiple instances?  This MAY is unnecessary because you already have the equivalent “OPTIONAL” at the beginning if the definition.  I think your intent here is this:

NEW
      This parameter MUST NOT be applied to a property that does not
      allow multiple instances.
END

— Section 6 —

   Purpose:  This property provides a reference to information about a
      component such as a participant possibly as a vcard or optionally
      a plain text typed value.

This sentence needs some punctuation or rephrasing in order to make sense.  Can you try?

— Section 8.1 —

   Description:  This component provides information about an
      participant in an event, task or poll.

Make it “a participant”.

Alexey Melnikov Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2019-05-29)
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.

Mirja Kühlewind No Objection

Comment (2019-05-24 for -12)
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?

Alvaro Retana No Objection

Éric Vyncke No Objection

Comment (2019-05-18 for -12)
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 ','

Magnus Westerlund No Objection

Adam Roach No Record

Martin Vigoureux No Record