Support for iCalendar Relationships
draft-ietf-calext-ical-relations-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
11 | Gunter Van de Velde | Request closed, assignment withdrawn: Joel Jaeggli Last Call OPSDIR review |
2024-01-26
|
11 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2022-07-22
|
11 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-06-15
|
11 | (System) | RFC Editor state changed to AUTH48 |
2022-05-24
|
11 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2022-05-02
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2022-05-02
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2022-05-02
|
11 | (System) | IANA Action state changed to In Progress from On Hold |
2022-04-04
|
11 | (System) | IANA Action state changed to On Hold from In Progress |
2022-04-04
|
11 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-04-01
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-04-01
|
11 | (System) | IANA Action state changed to In Progress from On Hold |
2022-03-30
|
11 | (System) | IANA Action state changed to On Hold from In Progress |
2022-03-23
|
11 | (System) | RFC Editor state changed to EDIT |
2022-03-23
|
11 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2022-03-23
|
11 | (System) | RFC Editor state changed to EDIT |
2022-03-23
|
11 | (System) | Announcement was received by RFC Editor |
2022-03-23
|
11 | (System) | IANA Action state changed to In Progress |
2022-03-23
|
11 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2022-03-23
|
11 | Amy Vezza | IESG has approved the document |
2022-03-23
|
11 | Amy Vezza | Closed "Approve" ballot |
2022-03-23
|
11 | Amy Vezza | Ballot approval text was generated |
2022-03-23
|
11 | Francesca Palombini | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2022-03-22
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-03-22
|
11 | Michael Douglass | New version available: draft-ietf-calext-ical-relations-11.txt |
2022-03-22
|
11 | (System) | New version accepted (logged-in submitter: Michael Douglass) |
2022-03-22
|
11 | Michael Douglass | Uploaded new revision |
2022-03-22
|
10 | Francesca Palombini | Approved as discussed during IETF 113 - Waiting for v-11 with the update as discussed in https://mailarchive.ietf.org/arch/msg/calsify/LmoeLpt750_E3mo1RYtgmJnnTo8/ |
2022-03-22
|
10 | (System) | Removed all action holders (IESG state changed) |
2022-03-22
|
10 | Francesca Palombini | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation::Revised I-D Needed |
2022-03-17
|
10 | Francesca Palombini | Waiting for v-11 with the update as discussed in https://mailarchive.ietf.org/arch/msg/calsify/LmoeLpt750_E3mo1RYtgmJnnTo8/ |
2022-03-17
|
10 | (System) | Changed action holders to Michael Douglass, Francesca Palombini (IESG state changed) |
2022-03-17
|
10 | Francesca Palombini | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2022-03-07
|
10 | Benjamin Kaduk | [Ballot comment] Thank you for the updates to resolve my earlier Discuss and Comment points! |
2022-03-07
|
10 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2022-02-27
|
10 | (System) | Changed action holders to Francesca Palombini (IESG state changed) |
2022-02-27
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-02-27
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-02-27
|
10 | Michael Douglass | New version available: draft-ietf-calext-ical-relations-10.txt |
2022-02-27
|
10 | (System) | New version approved |
2022-02-27
|
10 | (System) | Request for posting confirmation emailed to previous authors: Michael Douglass |
2022-02-27
|
10 | Michael Douglass | Uploaded new revision |
2022-02-17
|
09 | (System) | Changed action holders to Michael Douglass, Francesca Palombini (IESG state changed) |
2022-02-17
|
09 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2022-02-17
|
09 | Francesca Palombini | [Ballot comment] Many thanks to Spencer Dawkins for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/51-RB9FYMBnJhmCrMu_-Re-xcBY/. |
2022-02-17
|
09 | Francesca Palombini | Ballot comment text updated for Francesca Palombini |
2022-02-17
|
09 | Murray Kucherawy | [Ballot comment] Thanks to Spencer Dawkins for his ARTART review. There's a lot of missing punctuation in here, such as the prose in Sections 11.2 … [Ballot comment] Thanks to Spencer Dawkins for his ARTART review. There's a lot of missing punctuation in here, such as the prose in Sections 11.2 through 11.5, the end of the second and final paragraphs of 1.4, first paragraph of 2, "Property Parameters" of and the latter two examples in 8.2, etc. This document needs a normative reference to ABNF (RFC 5234), and should mention explicitly that a lot of the ABNF tokens (e.g., "dur-value") are imported from RFC 5545. |
2022-02-17
|
09 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
2022-02-17
|
09 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2022-02-17
|
09 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2022-02-16
|
09 | Murray Kucherawy | [Ballot comment] Thanks to Spencer Dawkins for his ARTART review. There's a lot of missing punctuation in here, such as the prose in Sections 11.2 … [Ballot comment] Thanks to Spencer Dawkins for his ARTART review. There's a lot of missing punctuation in here, such as the prose in Sections 11.2 through 11.5, the end of the second and final paragraphs of 1.4, first paragraph of 2, "Property Parametes" of and the latter two examples in 8.2, etc. This document needs a normative reference to ABNF (RFC 5234), and should mention explicitly that a lot of the ABNF tokens (e.g., "dur-value") are imported from RFC 5545. |
2022-02-16
|
09 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
2022-02-16
|
09 | Murray Kucherawy | [Ballot comment] There's a lot of missing punctuation in here, such as the prose in Sections 11.2 through 11.5, the end of the second and … [Ballot comment] There's a lot of missing punctuation in here, such as the prose in Sections 11.2 through 11.5, the end of the second and final paragraphs of 1.4, first paragraph of 2, "Property Parametes" of and the latter two examples in 8.2, etc. This document needs a normative reference to ABNF (RFC 5234), and should mention explicitly that a lot of the ABNF tokens (e.g., "dur-value") are imported from RFC 5545. |
2022-02-16
|
09 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2022-02-16
|
09 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2022-02-16
|
09 | Zaheduzzaman Sarker | [Ballot comment] Thanks for the efforts on this specification. One observation, the abstract should have text to mention that this specification updated 5545. |
2022-02-16
|
09 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2022-02-16
|
09 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2022-02-16
|
09 | Roman Danyliw | [Ballot comment] Thank you to Catherine Meadows for the SECDIR review. ** Abstract. The abstract text needs to mention that it is updating RFC5545. … [Ballot comment] Thank you to Catherine Meadows for the SECDIR review. ** Abstract. The abstract text needs to mention that it is updating RFC5545. ** Section 6.2. Typo. s/temporaly/temporarily/ ** Section 8.1. Per the example, “CONCEPT:http://example.com/event-types/arts/music” should this use https? ** Section 10. Thanks for noting the RFC3986 considerations on using URIs. Digging a bit more into the implementation approaches of the CONCEPT parameter, would clients be expected dereference the taxonomy URI in real-time? I’m wondering if there would be a chance for tracking mechanism akin to a “web bug” on a web page or in HTML email. For example, an .ics file is sent via an asynchronous mechanism (email) with a CONCEPT URI to something unique/unknown to the end-client and to a destination controlled by the sender or even a third party. Could it function as a read-receipt or to harvest an identifier for the system the client is on (IP address)? |
2022-02-16
|
09 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2022-02-15
|
09 | Benjamin Kaduk | [Ballot discuss] The ABNF for linkparam (§8.2) incorporates a "langparam" production, but that is not defined in any of this document, RFC 5455, RFC … [Ballot 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. |
2022-02-15
|
09 | Benjamin Kaduk | [Ballot 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. … [Ballot 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 " may happen, but in general don't do " 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. |
2022-02-15
|
09 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2022-02-15
|
09 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2022-02-14
|
09 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2022-02-09
|
09 | Catherine Meadows | Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Catherine Meadows. Sent review to list. |
2022-02-07
|
09 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. It appears to be useful especially if calendaring applications want to morph into project … [Ballot comment] Thank you for the work put into this document. It appears to be useful especially if calendaring applications want to morph into project management style of calendaring. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Bron Gondwana for the shepherd's write-up including the section about the WG consensus. I hope that this helps to improve the document, Regards, -éric https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-calext-ical-relations-09.txt flags multiple errors and warnings. All of them look easy to address. I also support Erik Kline's comment about the use of "https" everywhere. ## Section 4 It would be nice to add some explanations around the direction of the arrow. Figure 2, I like the example, but the graphic has 2 elements while the example text has 3. # Section 6.2 Even if obvious, "dur-value" is not described in the text of this section. May I also assume that CALEXT has duration types ? So, that there is no need to describe the syntex of this value ? |
2022-02-07
|
09 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2022-02-06
|
09 | Spencer Dawkins | Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Spencer Dawkins. Sent review to list. |
2022-02-05
|
09 | Erik Kline | [Ballot comment] [S2; nit] * "it's use" -> "its use", I think [S8.1, S8.2, S9.1; nit] * Is "http" important to the examples, or should/could … [Ballot comment] [S2; nit] * "it's use" -> "its use", I think [S8.1, S8.2, S9.1; nit] * Is "http" important to the examples, or should/could these be "https"? |
2022-02-05
|
09 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2022-02-03
|
09 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Catherine Meadows |
2022-02-03
|
09 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Catherine Meadows |
2022-01-31
|
09 | Cindy Morgan | Placed on agenda for telechat - 2022-02-17 |
2022-01-31
|
09 | Francesca Palombini | Ballot has been issued |
2022-01-31
|
09 | Francesca Palombini | [Ballot Position Update] New position, Yes, has been recorded for Francesca Palombini |
2022-01-31
|
09 | Francesca Palombini | Created "Approve" ballot |
2022-01-31
|
09 | Francesca Palombini | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2022-01-23
|
09 | (System) | Changed action holders to Francesca Palombini (IESG state changed) |
2022-01-23
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-01-23
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-01-23
|
09 | Michael Douglass | New version available: draft-ietf-calext-ical-relations-09.txt |
2022-01-23
|
09 | (System) | New version approved |
2022-01-23
|
09 | (System) | Request for posting confirmation emailed to previous authors: Michael Douglass |
2022-01-23
|
09 | Michael Douglass | Uploaded new revision |
2021-12-30
|
08 | Barry Leiba | Request for Last Call review by ARTART is assigned to Spencer Dawkins |
2021-12-30
|
08 | Barry Leiba | Request for Last Call review by ARTART is assigned to Spencer Dawkins |
2021-12-30
|
08 | Barry Leiba | Assignment of request for Last Call review by ARTART to James Gruessing was marked no-response |
2021-11-10
|
08 | (System) | Changed action holders to Michael Douglass, Francesca Palombini (IESG state changed) |
2021-11-10
|
08 | Francesca Palombini | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead::External Party |
2021-10-31
|
08 | Christer Holmberg | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Christer Holmberg. Sent review to list. |
2021-10-28
|
08 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2021-10-28
|
08 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2021-10-28
|
08 | Francesca Palombini | Waiting on an answer by the wg to Mark Nottingham's review: https://mailarchive.ietf.org/arch/msg/last-call/NBxeX-3LLiei8cweTaEkB1aoGgY/ |
2021-10-28
|
08 | Francesca Palombini | IESG state changed to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead |
2021-10-28
|
08 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2021-10-27
|
08 | Sabrina Tanamal | IANA Experts State changed to Reviews assigned |
2021-10-27
|
08 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2021-10-27
|
08 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-calext-ical-relations-08. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-calext-ical-relations-08. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are six actions which we must complete. First, in the Properties registry on the iCalendar Element Registries page located at: https://www.iana.org/assignments/icalendar/ Three new registrations are to be made as follows: Property: CONCEPT Status: Current Reference: [ RFC-to-be; Section 8.1 ] Property: LINK Status: Current Reference: [ RFC-to-be; Section 8.2 ] Property: REFID Status: Current Reference: [ RFC-to-be; Section 8.3 ] As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Second, also in the Properties registry on the iCalendar Element Registries page located at: https://www.iana.org/assignments/icalendar/ the existing registration for Property: RELATED-TO will have its reference updated by the addition of [ RFC-to-be; Section 9 ] Third, in the Parameters registry also on the iCalendar Element Registries page located at: https://www.iana.org/assignments/icalendar/ two new registrations will be made as follows: Parameter: GAP Status: Current Reference: [ RFC-to-be; Section 6.2 ] Parameter: REL Status: Current Reference: [ RFC-to-be; Section 6.1 ] As this also requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Fourth, in the Value Data Types registry also on the iCalendar Element Registries page located at: https://www.iana.org/assignments/icalendar/ two new registrations will be made as follows: Value Data Type: REFERENCE Status: Current Reference: [ RFC-to-be; Section 7 ] Value Data Type: UID Status: Current Reference: [ RFC-to-be; Section 7 ] As this also requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Fifth, in the Relationship Types registry also on the iCalendar Element Registries page located at: https://www.iana.org/assignments/icalendar/ eight new registrations will be made as follows: Relationship Type: CONCEPT Status: Current Reference: [ RFC-to-be; Section 5 ] Relationship Type: DEPENDS-ON Status: Current Reference: [ RFC-to-be; Section 5 ] Relationship Type: FINISHTOFINISH Status: Current Reference: [ RFC-to-be; Section 4 ] Relationship Type: FINISHTOSTART Status: Current Reference: [ RFC-to-be; Section 4 ] Relationship Type: FIRST Status: Current Reference: [ RFC-to-be; Section 5 ] Relationship Type: REFID Status: Current Reference: [ RFC-to-be; Section 5 ] Relationship Type: STARTTOFINISH Status: Current Reference: [ RFC-to-be; Section 4 ] Relationship Type: STARTTOSTART Status: Current Reference: [ RFC-to-be; Section 4 ] As this also requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Sixth, section 11.5 of the current document requests: "The following link relation values have been added to the Reference Types Registry defined in Section 6.2.2 of [RFC8288]" IANA Question --> is this request correct? RFC8288 does not have a section 6.2.2. In addition, the link relation types registry established by RFC8288 requires a relation name and description. Relation Name: Description: Reference: [ RFC-to-be ] The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Lead IANA Services Specialist |
2021-10-26
|
08 | Catherine Meadows | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Catherine Meadows. Sent review to list. |
2021-10-21
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2021-10-21
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2021-10-21
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2021-10-21
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2021-10-18
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2021-10-18
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2021-10-15
|
08 | Barry Leiba | Closed request for Last Call review by ARTART with state 'Withdrawn': This request is a duplicate. Bug? |
2021-10-15
|
08 | Barry Leiba | Request for Last Call review by ARTART is assigned to James Gruessing |
2021-10-15
|
08 | Barry Leiba | Request for Last Call review by ARTART is assigned to James Gruessing |
2021-10-15
|
08 | Gonzalo Salgueiro | Assignment of request for Last Call review by ARTART to Gonzalo Salgueiro was rejected |
2021-10-15
|
08 | Barry Leiba | Request for Last Call review by ARTART is assigned to Gonzalo Salgueiro |
2021-10-15
|
08 | Barry Leiba | Request for Last Call review by ARTART is assigned to Gonzalo Salgueiro |
2021-10-14
|
08 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2021-10-14
|
08 | Cindy Morgan | The following Last Call announcement was sent out (ends 2021-10-28): From: The IESG To: IETF-Announce CC: Bron Gondwana , brong@fastmailteam.com, calext-chairs@ietf.org, calsify@ietf.org, … The following Last Call announcement was sent out (ends 2021-10-28): From: The IESG To: IETF-Announce CC: Bron Gondwana , brong@fastmailteam.com, calext-chairs@ietf.org, calsify@ietf.org, draft-ietf-calext-ical-relations@ietf.org, francesca.palombini@ericsson.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Support for iCalendar Relationships) to Proposed Standard The IESG has received a request from the Calendaring Extensions WG (calext) to consider the following document: - 'Support for iCalendar Relationships' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-10-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification updates RELATED-TO defined in iCalendar (RFC5545) and introduces new iCalendar properties LINK, CONCEPT and REFID to allow better linking and grouping of iCalendar components and related data. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-calext-ical-relations/ No IPR declarations have been submitted directly on this I-D. |
2021-10-14
|
08 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2021-10-14
|
08 | Francesca Palombini | Last call was requested |
2021-10-14
|
08 | Francesca Palombini | Last call announcement was generated |
2021-10-14
|
08 | Francesca Palombini | Ballot approval text was generated |
2021-10-14
|
08 | Francesca Palombini | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2021-10-13
|
08 | (System) | Changed action holders to Francesca Palombini (IESG state changed) |
2021-10-13
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-10-13
|
08 | Michael Douglass | New version available: draft-ietf-calext-ical-relations-08.txt |
2021-10-13
|
08 | (System) | New version approved |
2021-10-13
|
08 | (System) | Request for posting confirmation emailed to previous authors: Michael Douglass |
2021-10-13
|
08 | Michael Douglass | Uploaded new revision |
2021-09-17
|
07 | Francesca Palombini | AD review posted at https://mailarchive.ietf.org/arch/msg/calsify/YwCvi-fZUnBneUWulafsSs8FBuw/ |
2021-09-17
|
07 | (System) | Changed action holders to Michael Douglass, Francesca Palombini (IESG state changed) |
2021-09-17
|
07 | Francesca Palombini | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2021-09-08
|
07 | (System) | Changed action holders to Francesca Palombini (IESG state changed) |
2021-09-08
|
07 | Francesca Palombini | IESG state changed to AD Evaluation from Publication Requested |
2021-09-08
|
07 | Francesca Palombini | Ballot writeup was changed |
2021-08-19
|
07 | Bron Gondwana | Document Shepherd Write-Up for draft-ietf-calext-ical-relations 1. This document is being requested as an Proposed Standard because it extends an existing Proposed Standard (RFC5545). … Document Shepherd Write-Up for draft-ietf-calext-ical-relations 1. This document is being requested as an Proposed Standard because it extends an existing Proposed Standard (RFC5545). The request type is indicated in the title page header as "Standards Track". 2. Technical Summary This spec extends the iCalendar format (RFC5545) to add new properties (LINK, CONCEPT and REFID) to allow better linking and grouping of related iCalendar records. Working Group Summary This document has been around for a long time and been through multiple revisions and discussions since it was first proposed in 2013, and first accepted by this working group in 2016. The main delay has been my (Bron, document Shepherd) fault, as it's had multiple working group last calls, and then I've just not gotten around to submitting it until the document expired. Blame 2020. Document Quality The extensions to iCalendar are all very easy to understand and to implement. The concepts in this document have already been implemented in the jscalendar format (RFC8984) - though there is not need to cross-reference them, as that will be done in a separate mapping document between the two protocols, which is still being finalised, and will reference both this docuement and that one (draft-ietf-calext-jscalendar-icalendar). Personnel Document Shepherd - Bron Gondwana (CALEXT co-chair) Responsible Area Director - Francesca Palombini 3. The Document Shepherd has read the document through in detail. 4. There are no concerns about reviews, this document has been well reviewed. 5. There is no review required for the document by other areas. 6. There are no concerns with this document that IESG should be aware of. 7. Yes, the author has been contacted and confirmed and confirmed that they have no disclosures. 8. There have been no IPR disclosures filed. 9. The WG consensus is solid. 10. There has been no discontent. 11. idnits notices a missing reference to RFC3986, which appears to be a tooling bug and easily resolved in the editing process. 12. This document doesn't define anything which needs formal review outside the working group. 13. All references have been identified as normative. 14. All normative references are published standards at the IETF or W3C. 15. There is a downref to an informational RFC, RFC8607. Per that RFC: Although this extension to CalDAV has wide deployment, its design does not comply with some of the best current practices of HTTP. Rather than creating interoperability problems with deployed code, it was decided to simply document how existing implementations interoperate. So this reference is required to specify how this extension will also interact with the deployed base of managed attachments. 16. This RFC does not change the status of any other RFC. 17. The IANA considerations ask for entries to be added 5 separate icalendar registries. The registrations are formatted as tables and clearly specify the values for all the fields in each registry. The author of this specification is one of the expert reviewers for these registries. 18. There are no new registries created. 19. The ABNF section is spread through the document, and was validated with Chris Newman's tool. |
2021-08-19
|
07 | Bron Gondwana | Responsible AD changed to Francesca Palombini |
2021-08-19
|
07 | Bron Gondwana | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2021-08-19
|
07 | Bron Gondwana | IESG state changed to Publication Requested from I-D Exists |
2021-08-19
|
07 | Bron Gondwana | IESG process started in state Publication Requested |
2021-08-19
|
07 | Bron Gondwana | Document Shepherd Write-Up for draft-ietf-calext-ical-relations 1. This document is being requested as an Proposed Standard because it extends an existing Proposed Standard (RFC5545). … Document Shepherd Write-Up for draft-ietf-calext-ical-relations 1. This document is being requested as an Proposed Standard because it extends an existing Proposed Standard (RFC5545). The request type is indicated in the title page header as "Standards Track". 2. Technical Summary This spec extends the iCalendar format (RFC5545) to add new properties (LINK, CONCEPT and REFID) to allow better linking and grouping of related iCalendar records. Working Group Summary This document has been around for a long time and been through multiple revisions and discussions since it was first proposed in 2013, and first accepted by this working group in 2016. The main delay has been my (Bron, document Shepherd) fault, as it's had multiple working group last calls, and then I've just not gotten around to submitting it until the document expired. Blame 2020. Document Quality The extensions to iCalendar are all very easy to understand and to implement. The concepts in this document have already been implemented in the jscalendar format (RFC8984) - though there is not need to cross-reference them, as that will be done in a separate mapping document between the two protocols, which is still being finalised, and will reference both this docuement and that one (draft-ietf-calext-jscalendar-icalendar). Personnel Document Shepherd - Bron Gondwana (CALEXT co-chair) Responsible Area Director - Francesca Palombini 3. The Document Shepherd has read the document through in detail. 4. There are no concerns about reviews, this document has been well reviewed. 5. There is no review required for the document by other areas. 6. There are no concerns with this document that IESG should be aware of. 7. Yes, the author has been contacted and confirmed and confirmed that they have no disclosures. 8. There have been no IPR disclosures filed. 9. The WG consensus is solid. 10. There has been no discontent. 11. idnits notices a missing reference to RFC3986, which appears to be a tooling bug and easily resolved in the editing process. 12. This document doesn't define anything which needs formal review outside the working group. 13. All references have been identified as normative. 14. All normative references are published standards at the IETF or W3C. 15. There is a downref to an informational RFC, RFC8607. Per that RFC: Although this extension to CalDAV has wide deployment, its design does not comply with some of the best current practices of HTTP. Rather than creating interoperability problems with deployed code, it was decided to simply document how existing implementations interoperate. So this reference is required to specify how this extension will also interact with the deployed base of managed attachments. 16. This RFC does not change the status of any other RFC. 17. The IANA considerations ask for entries to be added 5 separate icalendar registries. The registrations are formatted as tables and clearly specify the values for all the fields in each registry. The author of this specification is one of the expert reviewers for these registries. 18. There are no new registries created. 19. The ABNF section is spread through the document, and was validated with Chris Newman's tool. |
2021-07-30
|
07 | Michael Douglass | New version available: draft-ietf-calext-ical-relations-07.txt |
2021-07-30
|
07 | (System) | New version approved |
2021-07-30
|
07 | (System) | Request for posting confirmation emailed to previous authors: Michael Douglass |
2021-07-30
|
07 | Michael Douglass | Uploaded new revision |
2021-07-04
|
06 | (System) | Document has expired |
2021-04-14
|
06 | Bron Gondwana | Added to session: interim-2021-calext-01 |
2021-04-14
|
06 | Bron Gondwana | Added to session: interim-2021-jmap-01 |
2021-03-10
|
06 | Daniel Migault | Changed consensus to Yes from Unknown |
2021-03-10
|
06 | Daniel Migault | Intended Status changed to Proposed Standard from None |
2021-03-01
|
06 | Bron Gondwana | Added to session: IETF-110: calext Wed-1530 |
2020-12-31
|
06 | Michael Douglass | New version available: draft-ietf-calext-ical-relations-06.txt |
2020-12-31
|
06 | (System) | New version approved |
2020-12-31
|
06 | (System) | Request for posting confirmation emailed to previous authors: Michael Douglass |
2020-12-31
|
06 | Michael Douglass | Uploaded new revision |
2020-07-29
|
05 | Michael Douglass | New version available: draft-ietf-calext-ical-relations-05.txt |
2020-07-29
|
05 | (System) | New version approved |
2020-07-29
|
05 | (System) | Request for posting confirmation emailed to previous authors: calext-chairs@ietf.org, Michael Douglass |
2020-07-29
|
05 | Michael Douglass | Uploaded new revision |
2019-03-25
|
04 | Bron Gondwana | Notification list changed to Bron Gondwana <brong@fastmailteam.com> from "Philipp Kewisch" <mozilla@kewis.ch>, Bron Gondwana <brong@fastmailteam.com> |
2019-03-25
|
04 | Bron Gondwana | Notification list changed to "Philipp Kewisch" <mozilla@kewis.ch>, Bron Gondwana <brong@fastmailteam.com> from "Philipp Kewisch" <mozilla@kewis.ch> |
2019-03-25
|
04 | Bron Gondwana | Document shepherd changed to Bron Gondwana |
2018-11-06
|
04 | (System) | Document has expired |
2018-05-15
|
04 | Daniel Migault | IETF WG state changed to In WG Last Call from WG Document |
2018-05-05
|
04 | Michael Douglass | New version available: draft-ietf-calext-ical-relations-04.txt |
2018-05-05
|
04 | (System) | New version approved |
2018-05-05
|
04 | (System) | Request for posting confirmation emailed to previous authors: Michael Douglass |
2018-05-05
|
04 | Michael Douglass | Uploaded new revision |
2018-04-19
|
03 | (System) | Document has expired |
2017-10-11
|
03 | Michael Douglass | New version available: draft-ietf-calext-ical-relations-03.txt |
2017-10-11
|
03 | (System) | New version approved |
2017-10-11
|
03 | (System) | Request for posting confirmation emailed to previous authors: Michael Douglass |
2017-10-11
|
03 | Michael Douglass | Uploaded new revision |
2017-08-14
|
02 | (System) | Document has expired |
2017-02-10
|
02 | Michael Douglass | New version available: draft-ietf-calext-ical-relations-02.txt |
2017-02-10
|
02 | (System) | New version approved |
2017-02-10
|
02 | (System) | Request for posting confirmation emailed to previous authors: "Michael Douglass" |
2017-02-10
|
02 | Michael Douglass | Uploaded new revision |
2017-02-03
|
01 | Michael Douglass | New version available: draft-ietf-calext-ical-relations-01.txt |
2017-02-03
|
01 | (System) | New version approved |
2017-02-03
|
01 | (System) | Request for posting confirmation emailed to previous authors: "Michael Douglass" |
2017-02-03
|
01 | Michael Douglass | Uploaded new revision |
2017-02-03
|
00 | Philipp Kewisch | Notification list changed to "Philipp Kewisch" <mozilla@kewis.ch> |
2017-02-03
|
00 | Philipp Kewisch | Document shepherd changed to Philipp Kewisch |
2016-09-16
|
00 | Alexey Melnikov | This document now replaces draft-douglass-ical-relations instead of None |
2016-08-25
|
00 | Michael Douglass | New version available: draft-ietf-calext-ical-relations-00.txt |