[calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-ical-relations-09: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Tue, 15 February 2022 22:26 UTC
Return-Path: <noreply@ietf.org>
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 DF7973A0C9F; Tue, 15 Feb 2022 14:26:08 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-calext-ical-relations@ietf.org, calext-chairs@ietf.org, calsify@ietf.org, Bron Gondwana <brong@fastmailteam.com>, brong@fastmailteam.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.45.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <164496396877.21317.914662615752443156@ietfa.amsl.com>
Date: Tue, 15 Feb 2022 14:26:08 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/rehYQKav7ZeFU7xEUzbgWe1a458>
Subject: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-ical-relations-09: (with DISCUSS and COMMENT)
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Calendaring and Scheduling Standards Simplification <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Feb 2022 22:26:09 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-calext-ical-relations-09: 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/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-calext-ical-relations/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The ABNF for linkparam (§8.2) incorporates a "langparam" production, but that is not defined in any of this document, RFC 5455, RFC 8288, or RFC 7986. We need to define it somehow, whether by reference or directly. RFC 5545 does define a LANGUAGE parameter (our prose references a "LANG" parameter) and languageparam ABNF production, which is perhaps the simplest explanation for what was intended. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A couple broad comments before getting into the section-by-section details: I'm a little unclear on the value gained by having RELTYPE=REFID and RELTYPE=CONCEPT. If the semantics were just supposed to be "is a member of the indicated group", then why do we need a relation type to say so. But if there's some other semantics associated, where do we define those semantics? There are a number of places (e.g., §1.4) where this document uses the term "collection" in a context that suggests that it should be a defined term of iCalendar, corresponding roughly to a "site" or administrative domain, but I didn't find any usage in RFC 5545 that would correspond to what's being described here. Can we say more about what level of grouping this is intended to refer to? Section 1.1 The iCalendar [RFC5545] RELATED-TO property has no support for temporal relationships as used by standard project management tools. I am admittedly not really the target audience of this specification, but I have no idea what the "standard project management tools" are that are being referred to. Would (informative) references to a handful be appropriate? Section 1.2 REFID is used to identify a key allowing the association of components that are related to the same object and retrieval of a component based on this key. [...] This says "related to the same *object*" (emphasis mine), but the rest of the section just talks about an unstructured grouping. It seems like we could give some hint of the nature of the "object" to which all the elements of the group are related, prior to the RELTYPE=REFID definition in §5. Section 1.3 The current [RFC5545] CATEGORY property is used as a free form 'tagging' field. [...] In light of the discussion in the previous section about grouping without semantics, we might consider mentioning here that this is "tagging with semantics", just vaguely defined ones, as opposed to the REFID-type "tagging without semantics". Section 1.4 server-side management and stripping of inline data. Clients may choose to handle attachments differently from the LINK property as they are often an integral part of the message - for example, the agenda. (See the NITS entries as well, but) is it particularly noteworthy that clients might handle LINKs different from ATTACHments? They are different properties after all -- why would someone assume equivalent treatment? Section 1.5 To facilitate offline display the link type may identify important pieces of data which should be downloaded in advance. In general, the calendar entity should be self explanatory without the need to download referenced meta-data such as a web page. I'm not sure how to relate these two statements. It sounds like a "<X> may happen, but in general don't do <X>" scenario, in which case it might flow better to give the general advice first, followed by the specific scenario in which there is an exception to the general guidance. Section 2 The actual reference value can take three forms specified by the type parameter Is this list fixed for eternity or do we want to give some guidance that implementations need to prepare for future extensibility? REFERENCE: In an XML environment it may be necessary to refer to a This qualification in the description ("XML environment") suggests that perhaps the name being used for these semantics is an overly generic name. Section 4 We do have some text here about the GAP parameter that specifies the lead or lag time here, but then we go on to describe the various RELTYPE values in language like "cannot start until", "can only be completed after", etc., that is very absolute and does not acknowledge the potential for a GAP. I think it would be helpful to reframe as that we are making a comparison between the indicated pair of events, and that the relationship between when the events occur is affected by the GAP interval. (Also, the text in this section on the GAP parameter doesn't give a great sense that the lead time would be a negative gap.) Section 5 RELTYPE=FIRST: Indicates that the referenced calendar component is the first in a series the referenced calendar component is part of. I wonder if we want to explicitly contrast this with PARENT and provide an example of them being different. Section 6.1 In addition to the values defined here any value defined in [RFC8288] may be used. However these uses SHOULD be documented in an RFC updating both [RFC5545] and [RFC8288] In some sense this feels a little like saying "the current document SHOULD have documented this stuff, but we didn't". Is there anything useful to say about why this documenting can't be done now? (Oh, I guess there are rather more values in the registry than I remembered, though the number of them actually defined in RFC 8288 might be zero?) Section 8.1 Conformance: This property can be specified zero or more times in any iCalendar component. [...] Within the "VEVENT", "VTODO", or "VJOURNAL" calendar components, more than one formal category can be specified by using multiple CONCEPT properties. Are these two statements fully compatible? The former seems to give leeway to put multiple CONCEPT properties in any iCalendar component, but the latter seems to limit to the "more than one" ability to just the three named components. Section 8.2 I am not entirely sure when the TEXT value type would be used. If it's just there to allow for certain types of extensibility, that might be worth stating specifically. There is no mapping for [RFC8288] "title*", "anchor", "rev" or "media". Maybe "there is currently no mapping"? Or is the definition of such mapping prevented for some technical reason(s)? Section 9 This specification updates the RELATED-TO property defined in Section 3.8.4.5 of [RFC5545]. I'd consider adding a note that "the contents of Section 9.1 below replace Section 3.8.4.5 of [RFC5545]" to clarify the relationship between the two sections. Section 9.1 By default, the property value points to another calendar component that has a PARENT relationship to the referencing object. The "RELTYPE" property parameter is used to either explicitly state the default PARENT relationship type to the referenced calendar component or to override the default PARENT relationship type and specify either a CHILD or SIBLING relationship or a temporal relationship. We allow some new relationship types that are neither CHILD/SIBLING nor temporal (e.g., CONCEPT, REFID). Should those get some text in the description too? (I am not sure if DEPENDS-ON and FIRST should get lumped in as "temporal", either -- we don't do so in §5.) The FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTART relationships define temporal relationships as specified in the reltype parameter definition. Likewise here, it seems some more discussion is in order for the other relationship types. Changes to a calendar component referenced by this property can have an implicit impact on the related calendar component. For Do we want to say anything about changes to a component referenced by this property using any of the new relationship types? Section 10 Many thanks for referencing the URI security considerations and calling out "reliability and consistency"! We might say that the security considerations of RFC 5545 continue to apply. There are perhaps some privacy considerations if a user uses the new CATEGORY or REFID functionality to expose information about a related group of events, but it's a little hard to concoct a scenario where this information gets to an attacker other than the calendar server, which is already in something of a trusted position with respect to the user. Are there any considerations about the new linking and relation operators exposing information to other users about calendar components that they're not authorized to access? Very large "gap" parameters seem likely to lead to unexpected behavior. NITS Section 1.4 iCalendar component. This new LINK property is closely aligned to the LINK header defined in [RFC8288] There are probably some pedantic distinctions that could be made here relating to how RFC 8288 defines the generic concept of Web Linking (which is not intrinsically tied to HTTP), as well as its expression in an HTTP header *field*. Also, please put a full stop at the end of the sentence. The ATTACH property defined in [RFC5545] is being extended to handle server-side management and stripping of inline data. [...] It's hard (at least on first read) to tell if this sentence is referring to the RFC 8607 work or something being done by this document. Clients may choose to handle attachments differently from the LINK property as they are often an integral part of the message - for example, the agenda. Please clarify whether "they" refers to attachments of the LINK property. The singular/plural signal implies it's "attachments" but we could probably be more clear to the reader. Also, two hyphens for an em dash. Section 4 This section defines the usual temporal relationships for use with What's the context behind "usual"? I don't remember (but may have missed) a previous reference giving context for temporal relationships. RELTYPE=FINISHTOFINISH: Task-B can only be completed after Task-A is finished. The related tasks may run in parallel before completion. For example, if the goal is to prepare a meal, we start the potatoes, then the meat then the peas but they should all be cooked at the same time. This doesn't look like a great example for "finish-to-finish", as we prefer all things to finish at the same time, rather than with a strict ordering between end times. Section 6.1 Registration: These relation types are registered in [RFC8288] I think we mean '''registered in the "Link Relation Types" registry established by [RFC8288]'''. Section 8.2 Property Parameters: The VALUE parameter is required. Non-standard, reference type or format type parameters can also be specified on this property. The LABEL parameter is defined in [RFC7986] I'm not sure I see what in the ABNF would correspond to the "reference type" parameters. The closest seems to be the linkrelparam, but that's a relation type, not a reference type. Section 9.1 Looking at the diff from RFC 5545, we should title case "Property Name" and "Value Type". We also have changed the order in which we list the options for property parameters but that seems unimportant. Section 11.1 The following iCalendar property names have been added to the iCalendar Properties Registry defined in Section 8.3.2 of [RFC5545] Pedantically, RELATED-TO is not "added" but is rather covered by the "has added a reference to this document where ... have been updated by this document". So if we were to keep this phrasing we might make two tables, or we could try to fudge the wording here a bit.
- [calsify] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk via Datatracker
- Re: [calsify] Benjamin Kaduk's Discuss on draft-i… Michael Douglass
- Re: [calsify] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [calsify] Benjamin Kaduk's Discuss on draft-i… Michael Douglass
- Re: [calsify] Benjamin Kaduk's Discuss on draft-i… Francesca Palombini