[calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-eventpub-extensions-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-calext-eventpub-extensions-13: 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-eventpub-extensions/



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

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:
----------------------------------------------------------------------

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.