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

[Michael Douglass <[e-mail]>]

Thanks for the comments.

I'm hoping to get a full reply out this week.

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.
>
>
> 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 (пт), [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