Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-16.txt

From: [email-masked]
Date: Fri, 16 Oct 2020 11:34:58 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring Extensions WG of the IETF.

        Title           : Event Publishing Extensions to iCalendar
        Author          : Michael Douglass
	Filename        : draft-ietf-calext-eventpub-extensions-16.txt
	Pages           : 36
	Date            : 2020-10-16

Abstract:
   This specification updates RFC5545 by introducing a number of new
   iCalendar properties and components which are of particular use for
   event publishers and in social networking.

   This specification also defines a new STRUCTURED-DATA property for
   iCalendar RFC5545 to allow for data that is directly pertinent to an
   event or task to be included with the calendar data.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-16
https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-16

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Дилян Палаузов <[email-masked]>
Date: Sat, 17 Oct 2020 23:42:40 +0300

Hello,

10.  Privacy Considerations
10.1.  Tracking

   Properties with a "URI" value type can expose their users to privacy
   leaks as any network access of the URI data can be tracked.  Clients
   SHOULD NOT automatically download data referenced by the URI without
   explicit instruction from users.

How about using data: uris, and fmttype parameter for the content-type,
that contain vCard, instead of having STRUCTURED-
LOCATION;VALUE=URI:https://example.example/abc.vcf?

What is the way to download the referenced vCard simultaneously with
the iCalendar, apart from the data: uri?  I have now a bright idea: the
STRUCTURED-DATA is changed from PROPERTY to COMPONENT with UID and is
unencoded (as far as possible) blob.  Then instead of
VALUE=URI:https:// one can write VALUE=URI:attachment: or
VALUE=URI:cid: (which is supposed to mean the URI within STRUCTURED-
DATA).  This basically unifies (base64 decoded) attachments and
structured-data.

1.2.  Terms Used in This Document
  Event:  When the word 'event' is used (perhaps with a capitalised 'E'
  we are referring to gatherings, formal or informal.  For example a
  sports event, a party or a concert.

The square braket is not closed.

What is the puropose of a PARTICIPANT in a VFREEBUSY component?  Can
you give a use-case?

6.2.  Calendar Address
      The CALENDAR-ADDRESS property if present will provide a cal-
      address.  If an ATTENDEE property has the same value the
      participant is considered schedulable.  The PARTICIPANT component
      can be used to contain additional meta-data related to the
      attendee.

      If there is a related ATTENDEE proeprty then all parameters must
      be applied in that property.

      This property is defined by the following notation:
         caladdressparam   = *(
                     (";" schedulestatusparam)
         )

proeprty ⇒ property

schedulestatusparam exists only for scheduled ATTENDEEs, probably only
for CalDAV-scheduled (as opposed to iMIP scheduled by the CUA)
attendees.  A PARTICIPANT/CALENDAR-ADDRESS is only scheduled, if there
is a corresponding ATTENDEE with the same value, in which case the
ATTENDEE gets the schedulestatusparam.  What does PARTICIPANT/CALENDAR-
ADDRESS do with schedulestatusparam?

3.  Typed References
   Using STRUCTURED-LOCATION, rich information about multiple locations
   can be communicated, for example, address, region, country, postal
   code as well as other information such as parking availability.

Can you provide an example, that communicates postal code, address and
region for a STRUCTURED-LOCATION?

5.3.  Order

  orderparam = "ORDER" "=" integer ;Must be greater than or equal to 1
  
space after semi-colon.

6.3.  Styled-Description
   Property Parameters:  IANA, non-standard, id, alternate text
      representation, format type, derived and language property
      parameters can be specified on this property.

https://www.iana.org/assignments/icalendar/icalendar.xhtml does not
contain id property, neither does ABNF for styleddescparam.  It would
be good if the above Property Parameters are enumerated in the same
order, that is used in the subsequent Formal Definition for
styleddescparam.

When RFC 5545 defines Property Parameters for a Property it puts AND
before the last value.  draft-ietf-calext-eventpub-extensions uses
three times OR, twice AND before the last Property Parameter in the
enumeration.  The usage of the Oxford comma is inconsistent.

6.4.  Structured-Location

   Value type:  There is no default value type for this property.  The
      value type can be set to URI or TEXT.

Please provide an example for VALUE=TEXT, that uses all parameters.  I
want to see how LABEL and the TEXT value differ.
      
   Description:
      When a LABEL parameter is supplied the language of the label
      SHOULD match that of the content and of the LANGUAGE parameter if
      present.

My understanding is that, apart from NAME at VCALENDAR-level and
DESCRIPTION, but e.g. not for SUMMARY, any property/parameter can have
up to one LANGUAGE and there is no way to specify the same information
alternating in different languages in the same iCalendar object.  This
forces the user to read the information in whatever language it is
provided, or skip it based on visual scan, as there is no alternative.
LANGUAGE cannot be presented to the user.  Does anybody have use cases
for LANGUAGE in iCalendar?

If elaborating on LANGUAGE is done here, it shall specify that multiple
LABELs can be set, each for a different language.

   Use of the related parameter:  This allows a location to define the
      start and/or end timezone of the associated component.  If a
      location is specified with a RELATED parameter then the affected
      DTSTART or DTEND properties MUST be specified as floating DATE-
      TIME value.

STRUCTURED-LOCATION has no TZID property and can, but does not have to,
point to vCard URI that may, but has not to, contain TZ.  The draft
does not spell that the URI behing structloc can be a vCard.  How does
STRUCTURED-LOCATION substitute the time zone information, if DTSTART is
floating DATE-TIME?  The current way to specify different timezones for
a trip is to use different TZID parameters for DTSTART and DTEND.  Why
does the current way need to be changed?  Lets say a CUA(server)
implements eventspub and it uses floating times in DTSTART/DTEND with
STRUCTURED-LOCATION to signal that the timezones of the start/end are
different.  The CUA creates an iCalendar objects and sends it to a
different CUA.  The recipient implements RFC 5545 correctly.  It would
understand, that the start/end timezones are different, if TZID in
DTSTART/DTEND said so.  But the received DTSTART/DTEND are floating
time and the recipient does not understand STRUCTURED-LOCATION, or for
privacy reasons the recipient does not want to download the data
pointed by STRUCTURED-DATA;VALUE=URI: . Shall users disclose their IP
address to get the timezone of DTSTART from now on?

6.6.  Structured-Data
   Value Type:  TEXT, BINARY or URI

For the other properties is spelled explicitly, that there is no
default value type, but for this one and the other properties the same
is implied by https://tools.ietf.org/html/rfc7986#section-3 .

5.4.  Schema
Example:

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

This is a very good idea.  ld+json provides means to communicate from
the CUA, over a publisher to search engines information about an event,
that is not mapped in iCalendar.  E.g. if there are fees.  Is it
possible to not-base64 encode json, and use something like

     STRUCTURED-DATA;FMTTYPE=application/ld+json;VALUE=TEXT;
      SCHEMA="https://schema.org/FlightReservation":{"brum":"
      wups","zz":true}
      
?

schema.org can define e.g name (corresponding to SUMMARY).  SUMMARY can
be present only once (in one language).  STRUCTURED-DATA can be
specified many times, but has no LANGUAGE property.  What is the way to
write SUMMARY⇔NAME for an event in three languages and put this in a
single iCalendar object?

What does it mean to have many STRUCTURED-DATA?

Greetings
  Дилян

В 11:34 -0700 на 16.10.2020 (пт), [email-masked] написа:
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify