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

[Benjamin Kaduk <[e-mail]>]

Hi Michael,

An only somewhat less delayed counter-response, inline.

On Fri, Oct 16, 2020 at 02:35:10PM -0400, Michael Douglass wrote:
> A rather delayed reply to your original message:
> 
> Thank you for the suggestions.
> 
> I'll submit a version 16 to refresh the draft and, I hope, fix the 
> remaining issues
> 
> Note that I'd like in particular some feedback on the security/privacy 
> section.
> 
> On 5/28/19 20:08, Benjamin Kaduk via Datatracker wrote:
> > 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.
> 
> This one I fixed with version 14. My comment and your reply at the time was:
> 
> > On this particular issue I've come round to agreeing with the points
> > made here and in other messages. As an alternative i was considering
> > suggesting dropping the VALUE=TEXT. Having a vcard inline can always be
> > handled with a data uri.
> >
> > However, it seems to me that I can come closer to the intent by using
> > the STRUCTURED-DATA property - it is intended to provide supporting data
> > and of course there's no backwards compatibility issues.
> >
> > Does this seem an appropriate way forward?
> Your reply...
> > It seems appropriate to me (with the caveat that I am not a domain expert
> > here).
> 
> >
> > 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.
> You were correct - fixed the example in version 14
> >
> > 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.)
> This I missed - updated ABNF to make VALUE=TEXT required
> >
> > Similarly, the examples in Section 8.1 seem incomplete, since they omit
> > the REQUIRED dtstamp and uid properties.
> In v16 I made dtstamp optional. It is only needed for scheduling. Added 
> UID to the examples.

Thanks for these; I think we're all set on the Discuss front, now, and I'll
update my ballot position in the datatracker after I send this message.

> >
> >
> > ----------------------------------------------------------------------
> > 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.
> OK - toned it down a bit and added a caution.

Thanks; the new formulation is much easier on my eyes.

> >     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.
> Added a section to describe what was meant
> >
> > 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.
> 
> The IETF - like many organizations - welcomes sponsorship and provides 
> advertising:
> 
> https://ietf.org/about/support/meeting-sponsorship/
> 
> Having the opportunity to highlight that information is useful to event 
> organizers.
> 
> >
> > 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.
> Fixed:
> >
> > 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.
> Added comments to the ABNF
> >
> > 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.
> Done.
> >
> > Section 7.1
> >
> > nit: is there a reason for active participants to be taking a "role" but
> > inactive ones taking a "part"?
> no -p changed
> >
> > 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?
> Added a bunch
> >
> >        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*.
> This is to align with jscalendar
> >
> > Section 7.5
> >
> >       strucewaval   = ( uri / text )
> >
> > "strucewaval" seems like a typo and does not appear elsewhere in the
> > document.
> It was - corrected
> >
> > 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?
> Changed wording
> >
> >     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.
> I've added a comment in the privacy section and referred to that. Could 
> you take a look at that please?

Yes, the new privacy (and security) considerations are much-improved!
(Unrelated to this particular comment,) I would suggest one other
improvement: currently we just say that "any network access of the URI data
can be tracked", which as a phrase suggests to me that the tracking occurs
"in the network", but of course the remote endpoint hosting the referenced
resource will have a very authoritative view of who is accessing it and
when.  So perhaps "can be tracked both by a network observer and by the
entity hosting the remote resource" (or similar)?

> > In the last example:
> >
> >                       BEGIN: PARTICIPANT
> >                       SOURCE;FMTTYPE=text/vcard;
> >
> > this last semicolon should be a colon?
> Gone as a result of other changes
> >
> >                        http://dir.example.com/vcard/contacts/contact1.vcf
> >                       PARTICIPANT-TYPE:CONTACT
> >                       DESCRIPTION:A contact:
> >
> > The last colon here is superflous?
> >
> >                       END:PARTICIPANT
> Yes
> >
> > 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?
> We lack a place in the 5545 spec for the SEQUENCE and DTSTAMP for the 
> attendee. I wanted to point out this particular use.
> >
> > 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.
> That's the point of the LOCTYPE parameter
> >
> > Section 9.2
> >
> > The time gap between DTSTAMP and CREATED is rather large; is that
> > intended?
> No - all the dates are getting old - refreshed them
> >
> > 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?
> You are correct. I used a variant of the wording for managed attachments.
> >     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.
> I've added more text and aligned this to some extent with jscalendar.

As mentioned above, I do appreciate the added text, but it doesn't seem to
capture my intended point here.  Specifically, calendaring rather
intrinsically has the property that it provides information about a future
time when a given individual will be at a particular location, which could
enable further (targeted) attacks against that individual.  Most other
sources of tracking information about people are retrospective, not
future-looking, so I wanted to have this aspect emphasized.

Thanks again for the updates!

-Ben