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

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