From nobody Sun Nov 1 19:07:48 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5E63A0C9B for ; Sun, 1 Nov 2020 19:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwH5UTcm4rji for ; Sun, 1 Nov 2020 19:07:44 -0800 (PST) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6873A0C9E for ; Sun, 1 Nov 2020 19:07:44 -0800 (PST) Received: by mail-qv1-xf2c.google.com with SMTP id da2so3382405qvb.0 for ; Sun, 01 Nov 2020 19:07:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=aWjZL7ugLM/CKOQA7HaFIefrD734pleCP5ZyC2zgrCI=; b=X9NvWPUH4Lch2n1A7kIRnPZL+CqFeqfX7lCPIJlNbKV95mHgxcxkl+vRvZGR3oeohM 4KmMaSA84TSjRVmD58Vl2f8BqkdTgljTJiJOqxJx/KXVrcBnZV3nxdxOl3jABS6UbmIb i3Pm4j0v3ktc+oYNiErog26qpywX/C98rKmQ7fYf0FDdlnFRPxxyEj2CJ12D88/tFBh6 0H1OZ1PbJNn9Aod4gxQOdKBFMWwksh9u2eqvTrU5iLcMlrJS2dkxn3u2xT4CQsD+ZdTC 5d+DFmNLe6o2wN0eonH9mz251zNH9Bpr6LRodvkbbuslqcAZIm5bBh6Yn+qRyLmD1liP IJBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=aWjZL7ugLM/CKOQA7HaFIefrD734pleCP5ZyC2zgrCI=; b=QD2ZPNEVqyvFq/7b+SnYGXxrhacWlLlrfMEOtMo1JWbKd/Q1PzHFDnXGh691owLyiD eFqoyyA56linj1bQqGtiawWQTwxL2rqSkJuUGZqhi9YuQApSjw3FOi4Vp5VzPx4m/m96 H1GUpkx/L8lgVslNs3bNs2Cg8VoPOywzo+HL5CJCbnSTSJAi9pS7n0CQvU52EjMUmIv6 oLJu1PCk5J5YXuWj7gxwtK6wyL8KpJ52GRgHMecpP6rDUKj4QZqo0sjWTLlkO/wznpM8 lKV/zJJtdObs1viRIVrqL54C0SF0Gb/A3afnD2n4itUs89xQIZQ/W6mN3apjiT2dD5Us McWA== X-Gm-Message-State: AOAM531nDGuQbemy9vQWJx99RQE9zJnuzDij2M7lYmfUahfeMBYSaIcN RQVESinvybZbHYxVUWBqf09zbPle9BsxZA== X-Google-Smtp-Source: ABdhPJx2YLrDUmyCHsOXweTGzB4oGvADPIFRvxtQSddvQOTZePli3wFsk+MYZCTY3a/jTUavsWDXnA== X-Received: by 2002:a05:6214:ab4:: with SMTP id ew20mr20235704qvb.19.1604286462964; Sun, 01 Nov 2020 19:07:42 -0800 (PST) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id w27sm1859663qtv.29.2020.11.01.19.07.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Nov 2020 19:07:42 -0800 (PST) To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , calsify@ietf.org References: <160287329801.13575.6476139980278266084@ietfa.amsl.com> <79daa7a2a7518f9ab26060be943538f266ec92ea.camel@aegee.org> From: Michael Douglass Message-ID: Date: Sun, 1 Nov 2020 22:07:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <79daa7a2a7518f9ab26060be943538f266ec92ea.camel@aegee.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-16.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 03:07:46 -0000 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 (пт), internet-drafts@ietf.org написа: >> 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 >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Tue Nov 10 18:01:10 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0163A12E1 for ; Tue, 10 Nov 2020 18:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c5oANyfybq1 for ; Tue, 10 Nov 2020 18:01:06 -0800 (PST) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552853A12DA for ; Tue, 10 Nov 2020 18:01:06 -0800 (PST) Received: by mail-vk1-xa33.google.com with SMTP id w123so148995vka.4 for ; Tue, 10 Nov 2020 18:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0V9GlfsCMVzbjwQeRhyh0iGGK+4LqKFcU+xKG2BYaws=; b=n7MR5FYPnCWJxhbUgnguenf0n4Dl/8NcUxHhkP2JpXHGhJcDrVSn7UMeUfSC0voWUb 5G2OoyuISnRf5dpyimEf8o7ncnbPqAkXIQ5HRN52wyg5U9QcPIxE0IpOYLmOz1NoSdZT exCtfiOFgxgEQhOYrhmYDxbOUx2SZYJl2vfD0aLHmmZCO4Jy5uZxO8axLGlajijTK+5d zoPjNeRye1Fh/VaYQh+PJYXn80lVQIVU63j2s3v9W2SDWLq3iGnH3zXIv9IJK06PFS02 5eH7XrdgVGnASrLrHP9aluaq1qGgvMThRyxDVetmC+6JEXWi2FaBEJUoE5NQp5euR0Cw 6CLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0V9GlfsCMVzbjwQeRhyh0iGGK+4LqKFcU+xKG2BYaws=; b=ShCU9p/YIkanzej8y6a9HnEiLahvpaXQwI0d7YIxZXfWiidcVeEYqt8nrEelobyhRr mA/1qotNprNHXZS/as7Y3Cpp/4uYM/70CMiKeJ3infNXn9KRp+i83Qg0LIAoDP3wI2Wx Ib3eWCBQGn43Dwy6Vrsfy6t4UAGeQm9gQAMilYlv97sjSb1Pr15YDy0Uf9tk1A0VHtCr 5gk8+7fQVJUEqiRoxPQ3Yua3/nPW48LRZDwO4YJivsZe1bLLgAH5KL7elMLIdBvp/VLi Qvm81IhVtOXJJzSswQoxeXFDzxAWDarAoR5VLA+41BVKXIqmpf3dorPjswb6fB8A7Ikc rdnQ== X-Gm-Message-State: AOAM531nGr1udhvB5dIpFR/1E5WQQB0KwBmO5bxQmfTuGjozdbs6kWfu U5PT48fmrstS9eWZdWkX20IdHueJeXQtG0I5YwW3lZ2B4bs= X-Google-Smtp-Source: ABdhPJweNJ9FeT0Km6vG0IiqUyBSinK81Nm7aOQk40raI4xomFOjnL2WnTXf5S2OLlKfEjJtB/9qjCzxb3zOlRS8CwM= X-Received: by 2002:a1f:36c1:: with SMTP id d184mr12788505vka.13.1605060065094; Tue, 10 Nov 2020 18:01:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Tue, 10 Nov 2020 21:00:54 -0500 Message-ID: To: IETF-Calsify Content-Type: multipart/alternative; boundary="00000000000005eedc05b3cb2bb8" Archived-At: Subject: [calsify] Fwd: Requesting NomCom feedback X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 02:01:09 -0000 --00000000000005eedc05b3cb2bb8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Please consider providing feed backs to the nomcom! Yours, Daniel ---------- Forwarded message --------- From: STARK, BARBARA H Date: Tue, Nov 10, 2020 at 7:13 PM Subject: Requesting NomCom feedback To: WG Chairs Hi WG Chairs, First: Thanks for your help in getting volunteers for NomCom and getting nominees. Your emails to your WGs have been priceless for making the NomCom process work. My last request of you is for help with getting feedback. We've heard from the usual suspects. I really want to hear from more of the community, and the ietf and Announcement lists just don't seem to reach enough people. Below is the text I just sent out to the Announcement and ietf lists. Feel free to use this or invent your own shorter version. Thx, Barbara ---------------------------- NomCom is considering nominees for AD positions, IETF Chair, IAB, LLC Board, and IETF Trust. We need more input from the community both on specific nominees and on over-arching topics regarding what the community wants from these specific groups and wants from its leadership in general. We need *your* input. ** Deadline for community feedback is Friday November 20. ** We've paid attention to discussions on the ietf list. Issues raised there have been brought up in interviews. We've also asked questions of nominees based on feedback received, and based on the "Topics" that people said were important. We're listening to you. But most of the input to date has come from a few consistently vocal people. We need to hear from more of you. I scheduled our office hours during the 2 weeks before next week's IETF, because IETF week is so busy. We have one more left (18:00-19:00 UTC November 11). No-one but NomCom members showed up for our first 3. =E2=98= =B9 If there is demand for more office hours, I'll schedule them; but this really doesn't seem to be the preferred format for input. Most input is coming in as either - email to nomcom20@ietf.org - feedback on https://datatracker.ietf.org/nomcom/2020/feedback/ On the feedback page, the specific nominees are all listed at the top. General Topics are at the bottom. We pay attention to all the comments we get through these channels. I'll also try to hang out in Gather.Town during IETF breaks next week. I'm not going to have a specific NomCom area in Gather.Town, because it was really lonely hanging out there during IETF 108. But please feel free to hunt me down and bend my ear -- on NomCom issues or just to chat. I miss seeing all of y'all! Barbara Barbara Stark NomCom 2020 Chair --=20 Daniel Migault Ericsson --00000000000005eedc05b3cb2bb8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,=C2=A0

Please consider providing= feed backs to the nomcom!

Yours,=C2=A0
= Daniel
---------- Forwarded message ---------
From: STARK, BARBARA H &l= t;bs7652@att.com>
Date: = Tue, Nov 10, 2020 at 7:13 PM
Subject: Requesting NomCom feedback
To: = WG Chairs <wgchairs@ietf.org>= ;


Hi WG Chairs,
First: Thanks for your help in getting volunteers for NomCom and getting no= minees. Your emails to your WGs have been priceless for making the NomCom p= rocess work. My last request of you is for help with getting feedback. We&#= 39;ve heard from the usual suspects. I really want to hear from more of the= community, and the ietf and Announcement lists just don't seem to reac= h enough people.

Below is the text I just sent out to the Announcement and ietf lists. Feel = free to use this or invent your own shorter version.
Thx,
Barbara
----------------------------
NomCom is considering nominees for AD positions, IETF Chair, IAB, LLC Board= , and IETF Trust. We need more input from the community both on specific no= minees and on over-arching topics regarding what the community wants from t= hese specific groups and wants from its leadership in general. We need *you= r* input.

** Deadline for community feedback is Friday November 20. **

We've paid attention to discussions on the ietf list. Issues raised the= re have been brought up in interviews.

We've also asked questions of nominees based on feedback received, and = based on the "Topics" that people said were important.
We're listening to you.

But most of the input to date has come from a few consistently vocal people= . We need to hear from more of you.

I scheduled our office hours during the 2 weeks before next week's IETF= , because IETF week is so busy. We have one more left (18:00-19:00 UTC Nove= mber 11). No-one but NomCom members showed up for our first 3. =E2=98=B9 If= there is demand for more office hours, I'll schedule them; but this re= ally doesn't seem to be the preferred format for input.

Most input is coming in as either
=C2=A0- email to nom= com20@ietf.org
=C2=A0- feedback on https://datatracker.ietf.org/n= omcom/2020/feedback/
On the feedback page, the specific nominees are all listed at the top. Gene= ral Topics are at the bottom.
We pay attention to all the comments we get through these channels.

I'll also try to hang out in Gather.Town during IETF breaks next week. =
I'm not going to have a specific NomCom area in Gather.Town, because it= was really lonely hanging out there during IETF 108.
But please feel free to hunt me down and bend my ear -- on NomCom issues or= just to chat.
I miss seeing all of y'all!
Barbara

Barbara Stark
NomCom 2020 Chair






--
Dani= el Migault
Ericsson
--00000000000005eedc05b3cb2bb8-- From nobody Wed Nov 11 20:10:53 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792FC3A13A3 for ; Wed, 11 Nov 2020 20:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBTZEDNjZ6tm for ; Wed, 11 Nov 2020 20:10:49 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84993A13A1 for ; Wed, 11 Nov 2020 20:10:48 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id n63so3124158qte.4 for ; Wed, 11 Nov 2020 20:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=MN63i6LN6bBP8xRdSvtxrmt6jcDWihsaqyItS91doDU=; b=GeFgS0h7EffHzFegQYpm5U7gVZaeq06lVVJyO88+/gLK7AOeVuTQKv0HbzphMvcZig HAG9+IlAlY+c6hw3m9LX8MzXR6bStz5EXibiEHmmzzunRGAkcbTkozECnPlPICF17gME jurvlfM9dhjWZbhxfvdHXcIaNk/cqqKWHiNW+CDBr7+VLWekfwjdc5qo9NYGj6m6FQRE SCsDd9nCwz9tNo0eIEyMyhU++gB/LHPSCPWR1CLaeJ09Pxhkk0al6Zruo0HvgSuL0Xe3 jrrrWDLQ7p0P8M5+0Vr6x7gkbmSdRWN6PIF6U18f+OwlPsxmHlgoZ69fDh2kD+TIzf6E sBXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=MN63i6LN6bBP8xRdSvtxrmt6jcDWihsaqyItS91doDU=; b=aUwYdNPss61fwpDwPk598EaprsdcbmFqSe5/7hZsdDJmVNB3fneTUH3xmN9excNPNl 8ryaHJXwXOOIhEx7235uWOYWv9eQzG4Rmm/y6tffJ0cz4eDqawAmaQQS7Ph3Sk5+ZqHz vKTVQqewHdMSZ5gnWzFjKjgZ3D34np/UD6TZ2on7Vh25vWzDXdw5NhBLlKZpDaPlaf14 r9GKb93yGEethSLnfumx1qPsIiBDglYxB2gn2TyUnadAAT5PNm/LSEvMsNEOgo+yBebM ENo9asjchIZ2WeacYI1rYandnVcwcwLabD7O/NB06mInHmQcNSHpygarPPcmcWMU/ml6 2/fA== X-Gm-Message-State: AOAM532KzZaN+OBTo+kA2Mk9UQUHfQZTvMK8xGk0AgRRG9WRvLUDSvMl GXMir9F3Q/EOZ62gOb/Du1JOipuhGA6P+Q== X-Google-Smtp-Source: ABdhPJyqSFwrsoVaFOKGJQhxELzZI99TXdGV0ASMHc5SJITbI3HPPYn2qsa9jCS532RoARtRBhd9sA== X-Received: by 2002:aed:2321:: with SMTP id h30mr25853137qtc.213.1605154247584; Wed, 11 Nov 2020 20:10:47 -0800 (PST) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id p65sm2692861qkb.92.2020.11.11.20.10.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Nov 2020 20:10:47 -0800 (PST) To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , calsify@ietf.org References: <160287329801.13575.6476139980278266084@ietfa.amsl.com> <79daa7a2a7518f9ab26060be943538f266ec92ea.camel@aegee.org> From: Michael Douglass Message-ID: <9dc03462-7fd0-9fc1-faa1-33883a91a1c9@gmail.com> Date: Wed, 11 Nov 2020 23:10:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <79daa7a2a7518f9ab26060be943538f266ec92ea.camel@aegee.org> Content-Type: multipart/alternative; boundary="------------0E50BCD1F114A00E46F73F15" Content-Language: en-US Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-16.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 04:10:52 -0000 This is a multi-part message in MIME format. --------------0E50BCD1F114A00E46F73F15 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 (пт), internet-drafts@ietf.org написа: >> 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 >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------0E50BCD1F114A00E46F73F15 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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 (пт), internet-drafts@ietf.org написа:

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


_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------0E50BCD1F114A00E46F73F15-- From nobody Tue Nov 17 00:04:56 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB993A03FC for ; Tue, 17 Nov 2020 00:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXY7BZ9jOcHq for ; Tue, 17 Nov 2020 00:04:53 -0800 (PST) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A933A03F2 for ; Tue, 17 Nov 2020 00:04:53 -0800 (PST) Received: by mail-vk1-xa35.google.com with SMTP id i62so4338590vkb.7 for ; Tue, 17 Nov 2020 00:04:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=CP1zew5oPMENMHu1XBBXmxpy877osHGccdptdCBlBjI=; b=MTOvauR1H8hWCjeJ9bLdmF2TDFR74oq74i5p4AGtpiAezL6d9wCRcnrPck7Y3ld3dd qZEjhD0oukBeu11us4fH/+lM5PNM9tvGHktUBnRFR7E3n9IbFoCCg80XHSgXERs8nkDk mJ3TO8of13hCyBUFwK3+0LtLjNa5NtD15hF1wbiKqsbxOq8giCJzukpF+3LF1J0OpZAY zKQYuKdIKmSztf8NQkt0xRQXmO9BVI3d8277isdHDhgHlqj3Srnc5uQqSxHXKxsWvgCY ZZnHzz8/g9cwQt0Wm6SCcy3s8Qq2MmNJoyXdNsTgMx97tU8oJOlhs9DvuK60Hhx8TBbt d51A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CP1zew5oPMENMHu1XBBXmxpy877osHGccdptdCBlBjI=; b=NVFWukOzQWE+IFGVMtGz1bh1RXzmwJ8YBxtn6mz7HO2LYcx6wWsQG/M3pAbxHpFE3P 6y/jCct/n03fiCEtu5GJBsomgvZbaWPVvMnHxJah/xuLdHxMct7n96MNj4sy0ZrWqq/O o8IKbtwbdQ889dKmWvZmg60isLDGakwmlJKjrBwvW5PQ5ufIPq02vngzSGJOJNSnK6iO WibCltTSeboP1Yz4EfeSoOMUpSO01BTGIG751R1LjORVfr+qDcjmXw9IZqjUsMQ2dTxK XtaIrFdOHGFQ7L8jzLgcvvEVeiiPCkOCdJ995nbc1MPYCBRCnZQ+vg5WFylxnW5p1EDA J3hg== X-Gm-Message-State: AOAM532vSln1AZMM3UREPA34+29h3WlvUlpATJ/BBSFq9XMneVgfX5HP sQrTB2jY1VdEHb8ATBy1s0+aam1abRS5tQ47Lnkd983dkzjX8g== X-Google-Smtp-Source: ABdhPJxywuzD/Ycv7wwBMr58T7nlONB7sL03FpIoHv5HNApUI7Quy420RriyVjFClF/+R4qolzpRFen8kMvxjHcjTR0= X-Received: by 2002:a1f:ac10:: with SMTP id v16mr10161307vke.2.1605600292224; Tue, 17 Nov 2020 00:04:52 -0800 (PST) MIME-Version: 1.0 From: Daniel Migault Date: Tue, 17 Nov 2020 03:04:41 -0500 Message-ID: To: IETF-Calsify Content-Type: multipart/alternative; boundary="00000000000011c3fa05b448f3e8" Archived-At: Subject: [calsify] IETF 109 session X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 08:04:55 -0000 --00000000000011c3fa05b448f3e8 Content-Type: text/plain; charset="UTF-8" Hi, We have a calext meeting at IETF 109 on Thursday 16:00-18:00 ICT (UTC +7). If you are willing to present something, please let us know, update the agenda [1] and upload your slides [2]. Important to note, I am not sure one can join the meeting without having registered. Yours, Daniel [1] https://codimd.ietf.org/notes-ietf-109-calext [2] https://datatracker.ietf.org/meeting/109/session/calext -- Daniel Migault Ericsson --00000000000011c3fa05b448f3e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

We have a calext meeting at I= ETF 109 on Thursday 16:00-18:00 ICT (UTC +7).=C2=A0=C2=A0
=

If you are willing to present something, please let us = know, update the agenda [1] and upload your slides [2].

Important=C2=A0to note, I am not sure one can join the meeting withou= t having registered.=C2=A0

Yours,=C2=A0
= Daniel

[1]=C2=A0https://codimd.ietf.org/notes-ietf-109-calext --00000000000011c3fa05b448f3e8-- From nobody Wed Nov 18 23:02:29 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D4C3A1065; Wed, 18 Nov 2020 23:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHwrBiuAtkva; Wed, 18 Nov 2020 23:02:25 -0800 (PST) Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C8B3A1060; Wed, 18 Nov 2020 23:02:25 -0800 (PST) Received: by mail-vk1-f175.google.com with SMTP id v5so1101690vkn.12; Wed, 18 Nov 2020 23:02:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IqfBtEoNu9kWjhQpRdxk+XX3AAYVvpf15qfakFDQ4ww=; b=jyJHLsuR53YW+LLWaNqJXSXXoEBQBcNdaeypOQyAImCQUOPrzwBKnS24326VWzAcqw 1FRtj86lvWYHcQq53aXqLexAxciVXXsPB8TvY7Yxcr0ijfNhBR4tWJN3O5QD+i5xI3Ov cHUb3ap4j/NHQ5L5V2d73rPlef/Q+Y9xvOi+1YcTbUiRewuqfuN1Luf9Hc0AphSivZDv x5q/KzqcCAr5G9Ix+g5CDRyK15JqXiLcsPT7JwORUQojRv1GsCZkI7x0b+6Tng19bDRh ejwwiI38bXRND+zG8SPC6k2IGJr4/EO4icgWb1C9ePE5EabM51nTYvd5X25/ikOC1nt9 oCRw== X-Gm-Message-State: AOAM530qWIGq8IEou2EW+FDwhXbeEfY09wkrj7De01wg8RraXhHi0iLb jZLxTiz0rDf1YsYlR5p+n/EVlCpnsPSghaADlJy57OLGX85Rbw== X-Google-Smtp-Source: ABdhPJxlu0Km9bSOX1cUxuL5jA+0Um5K9/S/3kBXD1mKmB5RousZuzqSie45OiHhf4puzLeXevEzPzVZVYJvCEalcy0= X-Received: by 2002:a1f:9ed4:: with SMTP id h203mr7414399vke.1.1605769344096; Wed, 18 Nov 2020 23:02:24 -0800 (PST) MIME-Version: 1.0 References: <155908852723.25806.3708247030243239163.idtracker@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Thu, 19 Nov 2020 02:02:13 -0500 Message-ID: To: Michael Douglass Cc: Benjamin Kaduk , The IESG , draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org, calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-eventpub-extensions-13: (with DISCUSS and COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 07:02:28 -0000 Michael, for my part I like what you've added into the Security Considerations, in Sections 9.1 and 9.2. The only thing I would like to see added to what's there is something in 9.1 explicitly saying that implementations SHOULD NOT dereference URIs automatically. Perhaps something like this?: OLD See [RFC3986] for a discussion of the security considerations relating to URIs. NEW See [RFC3986] for a discussion of the security considerations relating to URIs. Because of the issues discussed there and below, clients SHOULD NOT follow URIs and fetch content automatically, and should only do so at the explicit request of the user. END Does that make sense? I might also suggest warning the user about fetching unknown/untrusted content, but I know how useless such warnings are in practice, and would prefer that servers block questionable sites and dodgy content altogether, as you already discuss in 9.2. Barry On Fri, Oct 16, 2020 at 2:36 PM Michael Douglass wrote: > > 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 > > 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 > From nobody Thu Nov 19 01:00:02 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77983A1237 for ; Thu, 19 Nov 2020 01:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=UJ1DHduL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VWqtQqzx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hxqg-izf5Yjh for ; Thu, 19 Nov 2020 00:59:59 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A3E3A12AA for ; Thu, 19 Nov 2020 00:59:50 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3855E5C0100 for ; Thu, 19 Nov 2020 03:59:50 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Thu, 19 Nov 2020 03:59:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm1; bh=68TIsKAcMY8KTDeqoMKoqwH8jePz2pDsLXADy6R wYvQ=; b=UJ1DHduLD5EykohtN5SA4mT3GdKVu9MrnLEpP+wF90J5EOV85+l5aLj FFrBCC+SQDZNjAVbbSTijWgSANiN4rC8oLPEit3j5U8uZbsxrbs+CnyAG/nWdeTN vUbLqdLopU6wbPM7DsG11YG4YHtDFl8wl7MeuRoFmG5t+Jf0AolJVKpEHw4TewzY klYfuR9/O8g+CP26CEdC6q662xSoa4tuhuwQxB7JvBQTqm6gsxabUorxIzk/vNa7 BdK5Z7BUUKfE2ih16bhhn/+97kDSbPNQItlFxmml8uYtj2dxIF3x8/MCgVzPRM+c BM6HOr3QU9KB/V8SQmJ2zMPCkxVd3Eg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=68TIsKAcMY8KTDeqoMKoqwH8jePz2 pDsLXADy6RwYvQ=; b=VWqtQqzxGij5jkS02ifwp95D28xkBURFJXrT8p6DFIKEf 57xK2oBxlq74WG0MU/Z+kDXuOLoJyHBSrjg5iXr5+R1FGU8rnaU40mbemtCl2Ga+ qt0q6sCxZtwoe+FMhs9VI5DuXhypzBh6796lptNPngVQ+OH1tQIAqpCk31GbdkCl 5PQ1+IXOGzDUahz+2oLG0ybOYD7lIp4VpFv7FG39ymguMXBdGN1n4LBAy1n/B/Zf h1zCF8kOXVq3KsclZGRPQUtcVfjm2v96DeCjGm6cpOay5mp2A+MxtV7gOUzpP2k5 w/e2Q4tcfqHxxUnNqC4aDf+ueXBxK2Vwu/QyyBoWQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefiedguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvdetteeiveeihf egiedtgeeigfduveelhefgffelgeelueehhfeitdelgedtffegnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F169E1800EA; Thu, 19 Nov 2020 03:59:49 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: Date: Thu, 19 Nov 2020 19:59:28 +1100 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=d4d7d79407e0417ba1c6368c89f02a1b Archived-At: Subject: [calsify] Meetecho room appears to be down X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 09:00:01 -0000 --d4d7d79407e0417ba1c6368c89f02a1b Content-Type: text/plain I believe they're working on it - hopefully we'll be up in the next few minutes. I will email alternative video chat details if it's not up in 15. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --d4d7d79407e0417ba1c6368c89f02a1b Content-Type: text/html
I believe they're working on it - hopefully we'll be up in the next few minutes.  I will email alternative video chat details if it's not up in 15.

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--d4d7d79407e0417ba1c6368c89f02a1b-- From nobody Thu Nov 19 01:01:59 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373E43A122D for ; Thu, 19 Nov 2020 01:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=es6KLIlf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mij239Rq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8feOplZG6PXI for ; Thu, 19 Nov 2020 01:01:54 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1EE3A1221 for ; Thu, 19 Nov 2020 01:01:54 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B3BDC5C00FB for ; Thu, 19 Nov 2020 04:01:53 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Thu, 19 Nov 2020 04:01:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=foIy91m U0Tf11dYJHYBF4VbeY+40MUhcKztbGze2HTc=; b=es6KLIlfxTrhaBEV+nYAgvj xw9JT/67axW9wq9UkEjLeOTUGB79ULnl9qPqihpYC/Bn4rWQrsU3aAtdDQuyufZq I/3sZFewbO9xjOqx84D/0X6BeICHlb4UYHSovOEEjNUKuJf0gK9Qv5gtmeR5RHxt IAdXLnbjD2+Ds/4gKNivy4nCtp/L1e3gkQnghu3qnr1w+HEVICfsXyiZQkH/aF7k cy6hVZtjdqTKwjRtl8agY1S2lAJQguq67WIKGhBdvks1MUavUCwm5GLTJe5jZb+N ihK5hhwucMIbhOXZT5RZ15Y5nhh8VkDMo09aIny0JIzEJEE278CTOGYyXcj7cxA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=foIy91 mU0Tf11dYJHYBF4VbeY+40MUhcKztbGze2HTc=; b=mij239RqVCRh4pS2+bvpWW VAe6kjW3RlhWcdQNOo8JVejYsTfLCjYFZ9lMh6PAWGBdN1PX2r8Ad7jOpjsKbt7U UO7aBMqkJG6m+mJfIOKJC4aYP1fQmPPm++yi2Irr7L417dj4oMZlAML7ZK0HciST 42sPVFxCuw6K7atdyaPxR4QnceLP2s2RVSpBZFw6D4OSWBGq42+K8l27Ukv+YayZ RYdjh6QeiNsjeYSU2zldrkWyBAeyCU7qmoFHer1KNs89b2aY14SjW0suPxQfFtwN pRCrvX3KSR9B+P6HBi73kzLkJf9LwNwrt+aY2byvoMjxnUJeXgwrIwNYQRPb17Eg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefiedguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhg sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvdduueeihe fgvdehueeujeejuedugfeigfevteefleetfeffgfdtjeejgfeuuddvnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmh grihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 44AD21800EA; Thu, 19 Nov 2020 04:01:53 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 19 Nov 2020 20:01:33 +1100 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=47c3f94f564d4dc1949b8da39b0f993f Archived-At: Subject: Re: [calsify] Meetecho room appears to be down X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 09:01:56 -0000 --47c3f94f564d4dc1949b8da39b0f993f Content-Type: text/plain Jabber is still down, so we can't chat, but the meetecho is up, so let's get going! On Thu, Nov 19, 2020, at 19:59, Bron Gondwana wrote: > I believe they're working on it - hopefully we'll be up in the next few minutes. I will email alternative video chat details if it's not up in 15. > > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --47c3f94f564d4dc1949b8da39b0f993f Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Jabber is still down, so we can't chat, but the meete= cho is up, so let's get going!

On Thu, Nov 19, 2020, at 19:59, Bron Gondwana wrote:
I believe they're working on it - hopefully we'll be up = in the next few minutes.  I will email alternative video chat detai= ls if it's not up in 15.

=
Cheers,

Bron.
=

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com



--
  B= ron Gondwana, CEO, Fastmail Pty Ltd
&n= bsp; brong@fastmailteam.com

=

--47c3f94f564d4dc1949b8da39b0f993f-- From nobody Thu Nov 19 01:52:36 2020 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B043A1307 for ; Thu, 19 Nov 2020 01:52:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160577955473.1109.8836771533722490128@ietfa.amsl.com> Date: Thu, 19 Nov 2020 01:52:34 -0800 From: IETF Secretariat Archived-At: Subject: [calsify] Milestones changed for calext WG X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 09:52:35 -0000 Changed milestone "Send JSCalendar draft to IESG", resolved as "Done". Changed milestone "Submit valarm document to IESG for publication", set due date to December 2020 from July 2020. Changed milestone "Submit icalendar relations document to IESG for publication", set due date to December 2020 from August 2020. Changed milestone "Submit scheduling controls document to IESG for publication", set due date to January 2021 from August 2020. Changed milestone "Submit JSCalendar mapping document to IESG for publication", set due date to March 2021 from September 2020. Changed milestone "Submit Serverside Subscription draft to IESG for publication", set due date to March 2021 from December 2020. Changed milestone "Submit vpoll document to IESG for publication", set due date to July 2021 from March 2021. URL: https://datatracker.ietf.org/wg/calext/about/ From nobody Thu Nov 19 02:18:44 2020 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9024C3A1377; Thu, 19 Nov 2020 02:18:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Cc: calsify@ietf.org, draft-ietf-calext-jscalendar@ietf.org, daniel.migaultf@ericsson.com, barryleiba@gmail.com, The IESG , calext-chairs@ietf.org, Daniel Migault , rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160578111856.17834.3545996771917931702@ietfa.amsl.com> Date: Thu, 19 Nov 2020 02:18:38 -0800 Archived-At: Subject: [calsify] Protocol Action: 'JSCalendar: A JSON representation of calendar data' to Proposed Standard (draft-ietf-calext-jscalendar-32.txt) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 10:18:39 -0000 The IESG has approved the following document: - 'JSCalendar: A JSON representation of calendar data' (draft-ietf-calext-jscalendar-32.txt) as Proposed Standard This document is the product of the Calendaring Extensions Working Group. The IESG contact persons are Murray Kucherawy and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ Technical Summary This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative, and over time successor to, the widely deployed iCalendar data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCal format, it is not a direct mapping from iCalendar and expands semantics where appropriate. Working Group Summary There were no controversy. Though the draft is defining an important change for calendar objects. The document did not raise any opposition. In addition, this document undergo a significant number of reviews, and lots of discussions happened at the IETF as well as during Calconnect meetings. Calconnect discussions have been reported by the co-authors as well as during interim meetings organized during Calconnect sessions. Document Quality There are a number of implementations. FastMail, has multiple implementations that works for beta users. This includes a perl implementation. The open-source Cyrus IMAP project includes a C implementation to translate from and to iCalendar. I suspect other implementations are developped and deployed including Personnel Daniel Migault is the document shepherd and Barry Leiba is the responsible AD. From nobody Thu Nov 19 11:08:56 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BFF3A1047; Thu, 19 Nov 2020 11:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wupeEgZ7jD5n; Thu, 19 Nov 2020 11:08:52 -0800 (PST) Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512243A1040; Thu, 19 Nov 2020 11:08:49 -0800 (PST) Received: by mail-vs1-f42.google.com with SMTP id s123so2993084vsc.0; Thu, 19 Nov 2020 11:08:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=D0Q318vyEcuE2fSWLXBCuG+cErWcLiIStDP1X9e9UTo=; b=kG30SeifOiK9QL7mUBtJGWkV01lqKh4/dhu/AU0VSpXtAna0CxOIhyJkMZumu266/m GWVRjlgtyWXV9yWxrYmKAcVEuJd7KFuUdFwrEdv+j0NwARl0Rm3ZvWfsCR/2kAxV36JW nwaFy+USjaGFrebjiH0+6ORUIQ8F2iiHvPLEuX96hAQDDySb40+39wxHH+MpupE/J9Yu F70FMa9jekXTNgrdtevWB21dbcuPv7NlTI4+B84L8g2EGdfSn9UcSWqUTBPX1ocQyYvU b9VFcPXXo97TXQN3gAeu6sSF29wFC5gotRN8XNKjD9aOopXPUZDcPx1cndifpz8m5q9a wSbQ== X-Gm-Message-State: AOAM5308FUPIz4w+zamrhsRIckeUYcY2qKeYbq/aYW0B4GNPNTlmD8uD Eh0K5tZmaZ0BjixO9iPGrUwObIaNS8ynq5TL3Kt1w4g10ks= X-Google-Smtp-Source: ABdhPJwKU1lhY9O9uNLkhU7noyhJ8xIbgwFlqul0bYUwxU5uKaiXdLZnzTdSzzydtpuCyAddMyrDJ3F8yB9W/bj8ctI= X-Received: by 2002:a67:ff08:: with SMTP id v8mr10062526vsp.9.1605812927444; Thu, 19 Nov 2020 11:08:47 -0800 (PST) MIME-Version: 1.0 From: Barry Leiba Date: Thu, 19 Nov 2020 14:08:35 -0500 Message-ID: To: draft-ietf-calext-ical-relations.all@ietf.org Cc: calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [calsify] AD review of draft-ietf-calext-ical-relations-05 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 19:08:54 -0000 Hi, Michael and the working group, As we discussed the ical-relations doc during the IETF 109 session, I though I'd get a jump on the publication request and do an AD review now. Here it is below. =E2=80=94 Section 1 =E2=80=94 associated meta-data. These relationships can take the following forms Nit: That needs a colon at the end of it. CATEGORIES are often used for this purpose but are problematic for application developers. It=E2=80=99s a small thing, but it might be good to briefly say why it=E2= =80=99s problematic. Linked: Entities are linked to each other through typed references. Can you be a little less terse here, or explain what you mean by =E2=80=9Ctyped references=E2=80=9D in this context? =E2=80=94 Section 1.1 =E2=80=94 and lag values and RELATED-TO is extended to allow URI values. This particular sentence would benefit from the Oxford comma after =E2=80= =9Clag values=E2=80=9D. =E2=80=94 Section 1.2 =E2=80=94 This may be, for example, to identify the tasks associated with a given project without having to communicate the task structure of the project, or, for example, in a package delivery system all tasks associated to a specific package. Another small suggestion for rephrasing (to avoid the awkward repetition of =E2=80=9Cfor example=E2=80=9D): NEW Two examples of how this may be used are to identify the tasks associated with a given project without having to communicate the task structure of the project, and to group all tasks associated to a specific package in a package delivery system. END =E2=80=A8=E2=80=A8=E2=80=94 Section 1.3 =E2=80=94 This more accurately defines what we mean by a category. It's not the words but the meaning. Two things here: 1. I=E2=80=99m not sure what =E2=80=9Cthis=E2=80=9D refers to. Is it =E2= =80=9Cthe name CONCEPT=E2=80=9D? Or is it the Simple Knowledge Organization System? 2. The sentence =E2=80=9CIt's not the words but the meaning,=E2=80=9D is ju= st sort of hanging around without being connected to anything. I=E2=80=99d really like to see this paragraph reworded. Rather than attempt to add semantics to the current property it seeems best to continue its usage as an informal tag and establish a new property with more constraints. I think this would be clearer with names on the properties (and one "e" fewer in "seems"): NEW Rather than attempt to add semantics to the existing CATEGORY property, it seems best to continue its usage as an informal tag and to establish a new CONCEPT property with more constraints. END =E2=80=94 Section 1.4 =E2=80=94 It is often necessary to relate calendar components. To what? To each other? Something else? Please say. =E2=80=94 Section 1.6 =E2=80=94 Please use the new BCP 14 boilerplate and add a normative reference to RFC = 8174. =E2=80=94 Section 2 =E2=80=94 UID: This allows for linking within a single collection and the value is assumed to be another component within that collection. Why =E2=80=9Cassumed to be=E2=80=9D? Is this any different to =E2=80=9Cthe= value is the UID of another component within that collection=E2=80=9D? For =E2=80=9Cxpointer=E2=80=9D, please be consistent in capitalizing the te= rm. I suggest using =E2=80=9CXPointer=E2=80=9D here and in Section 6, to match us= age in the reference doc. =E2=80=94 Section 3 =E2=80=94 [RFC5988] defines two forms of relation type, registered and extension. Registered relation types are added to a registry defined by [RFC5988] while extension relation types are specified as unique unregistered URIs, (at least unregistered in the [RFC5988] registry). First, RFC 8288 replaced 5988 three years ago; please change to using that as the reference. Second, the parenthetical seems odd. I suggest, =E2=80=9Cwhile extension relation types are specified as unique URIs that are not registered in the registry.=E2=80=9D Third, I strongly suggest adding section references here. So the result might be this: NEW [RFC8288] defines two forms of relation type: registered and extension. Registered relation types are added to the Link Relations registry as specified in Section 2.1.1 of [RFC8288]. Extension relation types, defined in Section 2.1.2 of [RFC8288], are specified as unique URIs that are not registered in the registry. END =E2=80=94 Section 4 =E2=80=94 Relationship parameter type values are defined in section 3.2.15. of [RFC5545]. Nit: remove the dot at the end of =E2=80=9C3.2.15=E2=80=9D (and capitalize = =E2=80=9CSection=E2=80=9D, to be consistent with how we do section references). This is probably a good time to pay attention to BCP 178 (RFC 6648) by removing the x-name construction from the ABNF (also in Section 5.1). The GAP parameter specifies the lead or lag time between the predecessor and the successor. This would benefit from a forward reference: =E2=80=9CThe GAP parameter, defined in Section 5.2, specifies=E2=80=9D the description of each temporal relationship below we refer to Task-A which contains and controls the relationship and Task-B the target of the relationship. Nit: this needs commas: =E2=80=9CTask-A, which contains and controls the relationship, and Task-B, the target=E2=80=9D. (There are a lot of missing commas throughout, and I=E2=80=99m not calling them all out; we=E2=80=99ll = leave most to the RFC Editor.) =E2=80=94 Section 5.2 =E2=80=94 Purpose: To specify the length of the gap, positive or negative between two temporaly related components. Another example of a missing comma that rates mention: after =E2=80=9Cnegat= ive=E2=80=9D. =E2=80=94 Section 7.1 =E2=80=94 Possible category resources are the various proprietary systems, for example Library of Congress, or an open source derived from something like the dmoz.org data. dmoz.org died 3.5 years ago; do we really still want to use it as an exampl= e? conceptparam =3D *( ; ; The following is OPTIONAL, ; and MAY occur more than once. ; (";" other-param) ; ) The ABNF already says that it can occur zero or more times, so the comment is supefluous. I think the comments and the nested grouping makes this more confusing than helpful, and suggest just changing it to this: NEW conceptparam =3D *(";" other-param) END SCONCEPT:http://example.com/event-types/sports CONCEPT:http://example.com/event-types/arts/music CONCEPT:http://example.com/task-types/delivery Is =E2=80=9CSCONCEPT=E2=80=9D a typo? (And is there really value in three = essentially indistinguishable examples?) =E2=80=94 Section 7.2 =E2=80=94 link =3D "LINK" linkparam / ( ";" "VALUE" "=3D" "TEXT" ":" text ) ( ";" "VALUE" "=3D" "REFERENCE" ":" text ) ( ";" "VALUE" "=3D" "URI" ":" uri ) CRLF This ABNF doesn=E2=80=99t make any sense. Are you missing some alternative= operators? linkparam =3D *( ; the following is MANDATORY ; and MAY occur more than once (";" relparam) / ; the following are MANDATORY ; but MUST NOT occur more than once (";" fmttypeparam) / (";" labelparam) / ; labelparam is defined in ... ; the following is OPTIONAL ; and MAY occur more than once (";" xparam) ) And there are multiple problems here: - Where is labelparam defined? - Where is xparam defined? - All elements of linkparam are optional, because you use =E2=80=9C*=E2=80= =9D, so how can any elements be MANDATORY? - The ABNF should make it clear, without comments, whether things are optional or mandatory and whether they can appear once or multiple times. Please re-work this ABNF, and get help from an ABNF expert if you need that= . Also, this section is exactly one that *can* benefit from multiple examples, each showing a different set of value types and parameters. =E2=80=94 Section 7.3 =E2=80=94 Description: The value of this property is a text identifier that allows associated components to be located or retrieved as a whole. For example all of the events in a travel itinerary would have the same REFID value. This seems to be more vague than necessary. May I suggest an update?: NEW Description: The value of this property is free-form text that creates an identifier for associated components. All components that use the same REFID value are associated through that value and can be located or retrieved as a group. For example, all of the events in a travel itinerary would have the same REFID value, so as to be grouped together. END =E2=80=A8 refidparam =3D *( ; the following is OPTIONAL ; and MAY occur more than once (";" xparam) ) Same comment as with conceptparam. And, again, where is xparam defined? =E2=80=94 Section 8.1 =E2=80=94 definition here extends the definition in Section 3.8.4.5. of [RFC5545] Also here: remove the dot at the end of the section number. For the ABNF in this section I have the same comments as for the ABNF in Section 7.1. In addition, this defines =E2=80=9Crelparam=E2=80=9D, but = =E2=80=9Crelparam=E2=80=9D is already defined in Section 5.1. That needs to be fixed. --=20 Barry From nobody Wed Nov 25 16:04:34 2020 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 891673A0D8B; Wed, 25 Nov 2020 16:04:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <160634906846.22402.16786725200511408411@ietfa.amsl.com> Date: Wed, 25 Nov 2020 16:04:28 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-valarm-extensions-03.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 00:04:29 -0000 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 : VALARM Extensions for iCalendar Authors : Cyrus Daboo Kenneth Murchison Filename : draft-ietf-calext-valarm-extensions-03.txt Pages : 16 Date : 2020-11-25 Abstract: This document defines a set of extensions to the iCalendar VALARM component to enhance use of alarms and improve interoperability between clients and servers. This document updates RFC5545. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-valarm-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-valarm-extensions-03 https://datatracker.ietf.org/doc/html/draft-ietf-calext-valarm-extensions-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-valarm-extensions-03 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 nobody Wed Nov 25 16:05:58 2020 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9643A0D9B; Wed, 25 Nov 2020 16:05:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, Daniel Migault , calext-chairs@ietf.org, Bron Gondwana , calsify@ietf.org, mglt.ietf@gmail.com Message-ID: <160634915689.7048.5733846161998378572@ietfa.amsl.com> Date: Wed, 25 Nov 2020 16:05:56 -0800 Archived-At: Subject: [calsify] Publication has been requested for draft-ietf-calext-valarm-extensions-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 00:05:57 -0000 Daniel Migault has requested publication of draft-ietf-calext-valarm-extensions-03 as Proposed Standard on behalf of the CALEXT working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-calext-valarm-extensions/