[calsify] On draft-ietf-calext-eventpub-extensions-18

[Дилян Палаузов <[e-mail]>]

Hello Michael,

thank for the update.  I am sorry that it took so long to review your
answer. I like the idea of extending iCalendar to make it more suitable
to publish event data.  I like the idea of extending iCalendar to make
it more suitable to publish event data.

Please provide use case/example for a VFREEBUSY component with
PARTICIPANT.

Who is supposed to read the STYLED-DESCRIPTION in a VFREEBUSY
component? 

Section 5.2 Schema

Why are quotes necessary?

The SCHEMA parameter is redundant in regards to the base-64 decoded
data. In the provided example it is implied by the @type propery of the
VALUE and by FMTTYPE=application/ld+json.

The base64-decoded example contains:

<script type="application/ld+json"> 
{ 
"@context": "http://schema.org", 
"@type": "FlightReservation", 
...
} 
} 
</script>
Are the <script> tags intended?

This example uses references to “schema.org” as “http://”. I have seen
other references using instead ”https://schema.org/...”. The latter
corresponds to the examples provided by the website
https://schema.org/FlightReservation .

Can the example be provided as base64-decoded text (VALUE=TEXT)?

Section 5.3 Derived

I do not understand who is supposed to update the property, if the
client shall not do it. In the provided example the same data can be
provided twice: as rich-text-format and as html. Lets say the client
changes the rtf part. Will the html text stay then outdated?


Section 6.6. Structured-Data

One of the provided arguments against reuing the ATTACH property and
instead having then new STRUCTURED-DATA propery is, that some
implementations strip the BINARY (embedded) content of ATTACH and
replace it with STRUCTURED-DATA. Exactly the same will happen with
STRUCTURED-DATA: implementations will strip it and replace it with
VALUE=URI. I propose not adding STRUCTURED-DATA property, but amusing
implementations to display FMTTYPE=applicaiton/ld+json to the users,
when it is within ATTACH, e.g. with VALUE=TEXT.

Just because ATTACH was not enough, IMAGE was introduced. If you want
to publish now an event with attached picture, do you have to use
ATTACH or IMAGE? Probably both, by including the payload twice, to make
it work with all CUAs. To save bandwith, servers may convert the
value/payload from BINARY to URI.  If STRUCTURED-DATA is introduced to
transmit the data in a backward compatible way to all CUAs, iCalendar
generators will put the same information in STRUCTURED-DATA and in
ATTACH, thus twice.

Some text would be nice how to avoid redundancy of the data, if the
same information is contained both in STRUCTURED-DATA/ld+json and in
the iCalendar object. E.g. shall the DTSTART information be mapped to
ld+json while the iCalendar object is generated?


Section 7.1. Participant

Why is it necessary to have “Schedulable participants”, provided that
all the scheduling is anyway done based on the ATTENDEE property (for
the same participant)? I propose skipping the “schedulable
participants’ from the specification. In turn the dtstamp, seq, last-
mod properties can be removed, as these have to be the same as of the
outside component.


Section 7.1.1. Schedulable Participant
For backwards compatibility wuth existing → with existing. 

Section 8.2. Example 2

PARTICIPANT-TYPE:ACTIVE: Why does this end with a colon?

The example is in fact about a meeting containg three participants: two
ATTENDEEs and a PARTICIPANT, who is not an attendee. Please extend the
example to contain at the same time: an attendee and participants, who
coincide; an attendee who is not a participant; and a participant, who
is not an attendee, with corresponding describing text. (A remote
participant and not-scheduled participants are two independent things).

Please insert Extended examples with ORDER, DERIVED and STRUCTURED-
DATA, that is at the same time available as vCard and as ld+json.

Greetings
Дилян

On Sun, 2021-01-03 at 16:15 -0500, Michael Douglass wrote:
> I'm about to submit an updated version 17
> I made some changes both as a result of points raised here and also
> as a result of the call during the IETF 109 virtual meeting.
> To summarize the main points:
> There was concern expressed about relating start/end to a location.
> This was partially in response to jscalendar but I think as it stood
> it has too many problems. I'm removing that. I suspect in the
> jscalendar mapping we'll add back a relation but it will only be to
> allow round-tripping.
> As discussed in the IETF 109 meeting I've changed the STRUCTURED-
> LOCATION property into a VLOCATION component. This allows that
> component to contain a STRCTURED-DATA property providing the
> information - possibly as a data-url to avoid downloads. It's
> essentially what I was trying to do with STRUCTURED-LOCATION.
> Similarly for STRUCTURED-RESOURCE. These changes also make it a
> closer match to what's happening with jscalendar.
> Some PARTICIPANT examples were missing the UID
> Additionally I've revised the abnf along the lines suggested by Barry
> Leiba for other drafts.
> On 11/11/20 23:10, Michael Douglass wrote:
> 
> > 
> > Thank you for the time you put into this. I've attempted to cover
> > all of it below. Some points lead to further questions.
> > On 10/17/20 16:42, Дилян Палаузов wrote:
> > 
> > > 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.
> > I'm not sure this gains us much. As a property there are a number
> > of ways to represent the value (including a data uri. And doesn't
> > uri::cid only work for mail?
> > This has got me thinking about the other structured-xxx properties.
> > Making the location a component would make sense
> > BEGIN:VLOCATION
> > STRUCTURED-DATA:...
> > DESCRIPTION:...
> > UID:...
> > END:VLOCATION
> > 
> > makes a lot of sense. It also allows us to populate the location
> > with properties describe it. Which does take us almost back to
> > where we started with VVENUE. However, I've avoided trying to
> > duplicate vcard in the location - embedding it as structured data
> > using a vcard (or other contacts) schema seems to make much more
> > sense. 
> > 
> > 
> > > 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.
> > Done
> > 
> > > What is the puropose of a PARTICIPANT in a VFREEBUSY component?  Can
> > > you give a use-case?
> > Much the same as elsewhere - to provide further information about
> > the attendee/organizer. 
> > I guess it might help to know the timezone or location of the
> > participants as that might affect what you report as free.
> > 
> > > 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
> > Done
> > 
> > > 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?
> > I can't remember now why I added all the attendee parameters to the
> > calendar address. I'm going to remove them.
> > 
> > 
> > > 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?
> > I meant in a vcard reference - I'll say so.
> > 
> > > 5.3.  Order
> > > 
> > >   orderparam = "ORDER" "=" integer ;Must be greater than or equal to 1
> > >   
> > > space after semi-colon
> > Done
> > 
> > > .
> > > 
> > > 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.
> > Fixed.
> > 
> > > 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?
> > 5545 has this text (Section 3.1.2):
> > Multi-valued properties MUST NOT be used to specify multiple language variants of
> >    the same value.
> > To my mind this does make the parameter pretty useless - however I
> > guess you can auto translate it - which might work a lot better now
> > but still be inadequate.
> > Interestingly rfc7986 says for NAME and DESCRIPTION:
> > This property can be specified multiple times in an iCalendar object.  
> > However, each property MUST represent the name of the calendar in a different language.
> > I talked over the issue and we think this is possibly on oversight
> > on the part of Cyrus. We may need an errata. 
> > My wording as regards the LABEL parameter is only to ensure that
> > the label and content match.
> > 
> > 
> > > If elaborating on LANGUAGE is done here, it shall specify that multiple
> > > LABELs can be set, each for a different language.
> > I'm not intending to introduce proper localization of iCalendar -
> > at least with this spec. 
> > Jscalendar introduces the idea of localization which I hope will do
> > a better job of handling languages than 5545 does. We probably need
> > an iCalendar extension for this so we can map them. 
> > 
> > 
> > 
> > 
> > >    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?
> > I will probably drop this. I think it started off as an attempt to
> > align with jscalendar but it doesn't make much sense I think. 
> > 
> > > 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 .
> > Done
> > 
> > > 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?
> > That will happen with localization  - no way at the moment.
> > 
> > > What does it mean to have many STRUCTURED-DATA?
> > I guess I need to add text to specify that multiple STRUCTURED-DATA
> > MUST represent different information - NOT the same information in
> > different languages. However, woudl it make sense to have the same
> > information in a different representation - e.g. json and html? One
> > for processing and one for display. 
> > 
> > > Greetings
> > >   Дилян
> > > 
> > > В 11:34 -0700 на 16.10.2020 (пт), [e-mail] написа:
> > > 
> > > > 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/
> > > > 
> > > > 
> > > > _______________________________________________
> > > > calsify mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/calsify
> > > _______________________________________________
> > > calsify mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/calsify