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

[Michael Douglass <[e-mail]>]

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