idnits 2.17.1 draft-ietf-calext-ical-relations-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5545, but the abstract doesn't seem to directly say this. It does mention RFC5545 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC5545, updated by this document, for RFC5378 checks: 2005-10-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 March 2022) is 763 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4791' is defined on line 899, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Douglass 3 Internet-Draft Bedework 4 Updates: 5545 (if approved) 22 March 2022 5 Intended status: Standards Track 6 Expires: 23 September 2022 8 Support for iCalendar Relationships 9 draft-ietf-calext-ical-relations-11 11 Abstract 13 This specification updates the iCalendar RELATED-TO property defined 14 in RFC5545 by adding new relation types and introduces new iCalendar 15 properties LINK, CONCEPT and REFID to allow better linking and 16 grouping of iCalendar components and related data. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 23 September 2022. 35 Copyright Notice 37 Copyright (c) 2022 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Revised BSD License text as 46 described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Revised BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Structured iCalendar relationships . . . . . . . . . . . 3 53 1.2. Grouped iCalendar relationships . . . . . . . . . . . . . 3 54 1.3. Concept relationships . . . . . . . . . . . . . . . . . . 3 55 1.4. Linked relationships . . . . . . . . . . . . . . . . . . 4 56 1.5. Caching and offline use . . . . . . . . . . . . . . . . . 5 57 1.6. Conventions Used in This Document . . . . . . . . . . . . 5 58 2. LINK Property Reference Types . . . . . . . . . . . . . . . . 5 59 3. Link Relation Types . . . . . . . . . . . . . . . . . . . . . 6 60 4. New temporal RELTYPE Parameter values . . . . . . . . . . . . 6 61 5. Additional New RELTYPE Parameter Values . . . . . . . . . . . 8 62 6. New Property Parameters . . . . . . . . . . . . . . . . . . . 8 63 6.1. Link Relation . . . . . . . . . . . . . . . . . . . . . . 9 64 6.2. Gap . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 7. New Value Data Types . . . . . . . . . . . . . . . . . . . . 10 66 8. New Properties . . . . . . . . . . . . . . . . . . . . . . . 11 67 8.1. Concept . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 8.2. Link . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 8.3. Refid . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 9. Updates to RFC 5545 . . . . . . . . . . . . . . . . . . . . . 14 71 9.1. RELATED-TO . . . . . . . . . . . . . . . . . . . . . . . 15 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 11.1. iCalendar Property Registrations . . . . . . . . . . . . 17 75 11.2. iCalendar Property Parameter Registrations . . . . . . . 18 76 11.3. iCalendar Value Data Type Registrations . . . . . . . . 18 77 11.4. iCalendar RELTYPE Value Registrations . . . . . . . . . 19 78 11.5. New Reference Type Registration . . . . . . . . . . . . 19 79 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 81 13.1. Informative References . . . . . . . . . . . . . . . . . 20 82 13.2. Normative References . . . . . . . . . . . . . . . . . . 20 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 85 1. Introduction 87 iCalendar entities defined in [RFC5545] often need to be related to 88 each other or to associated meta-data. The specifications below 89 support relationships of the following forms: 91 Structured iCalendar: iCalendar entities can be related to each 92 other in some structured way, for example as parent, sibling, 93 before, after. 95 Grouped iCalendar: iCalendar entities can be related to each other 96 as a group. CATEGORIES are often used for this purpose but are 97 problematic for application developers due to their lack of 98 consistency and use as a free-form tag. 100 Linked: Entities can be linked to other entities such as vcards 101 through a URI and associated REL and FMTTYPE parameters. 103 1.1. Structured iCalendar relationships 105 The iCalendar [RFC5545] RELATED-TO property has no support for 106 temporal relationships as used by project management tools. 108 The RELTYPE parameter is extended to take new values defining 109 temporal relationships, a GAP parameter is defined to provide lead 110 and lag values, and RELATED-TO is extended to allow URI values. 111 These changes allow the RELATED-TO property to define a richer set of 112 relationships useful for project management. 114 1.2. Grouped iCalendar relationships 116 This specification defines a new REFID property which allows 117 arbitrary groups of entities to be associated with the same key 118 value. 120 REFID is used to identify a key allowing the association of 121 components that are all related to the referring, aggregating 122 component and the retrieval of components based on this key. For 123 example, this may be used to identify the tasks associated with a 124 given project without having to communicate the task structure of the 125 project. A further example is the grouping of all sub-tasks 126 associated with the delivery of a specific package in a package 127 delivery system. 129 As such, the presence of a REFID property imparts no meaning to the 130 component. It is merely a key to allow retrieval. This is distinct 131 from categorisation which, while allowing grouping also adds meaning 132 to the component to which it is attached. 134 1.3. Concept relationships 136 The name CONCEPT is used by the Simple Knowledge Organization System 137 defined in [W3C.REC-skos-reference-20090818]. The term "concept" 138 more accurately defines what we often mean by a category. It's not 139 the text string that is important but the meaning attached to it. 140 For example, the term "football" can mean very different sports. 142 The introduction of CONCEPT allows a more structured approach to 143 categorization, with the possibility of namespaced and path-like 144 values. Unlike REFID the CONCEPT property imparts some meaning. It 145 is assumed that the value of this property will reference a well 146 defined category. 148 The current [RFC5545] CATEGORY property is used as a free form 149 'tagging' field. These values have some meaning to those who apply 150 them but not necessarily to any consumer. As such it is difficult to 151 establish formal relationships between components based on their 152 category. 154 Rather than attempt to add semantics to the CATEGORY property it 155 seems best to continue its usage as an informal tag and establish a 156 new CONCEPT property with more constraints. 158 1.4. Linked relationships 160 The currently existing iCalendar standard [RFC5545] lacks a general 161 purpose method for referencing additional, external information 162 relating to calendar components. 164 This document proposes a method for referencing typed external 165 information that can provide additional information about an 166 iCalendar component. This new LINK property is closely aligned to 167 [RFC8288] which defines the generic concept of Web Linking as well as 168 its expression in the HTTP LINK header field. 170 The LINK property defines a typed reference or relation to external 171 meta-data or related resources. By providing type and format 172 information as parameters, clients and servers are able to discover 173 interesting references and make use of them, perhaps for indexing or 174 the presentation of interesting links for the user. 176 Calendar components are often grouped into collections to represent a 177 calendar or a series of tasks, for example [RFC4791]' (CalDAV) 178 calendar collections. 180 It is also often necessary to reference calendar components in other 181 collections. For example, a VEVENT might refer to a VTODO from which 182 it was derived. The PARENT, SIBLING and CHILD relationships defined 183 for the RELATED-TO property only allow for a UID which is inadequate 184 for many purposes. Allowing other value types for those 185 relationships may help but would cause backward compatibility issues. 186 The LINK property can link components in different collections or 187 even on different servers. 189 When publishing events it is useful to be able to refer back to the 190 source of that information. The actual event may have been consumed 191 from a feed or an ics file on a web site. A LINK property can 192 provide a reference to the originator of the event. 194 Beyond the need to relate elements temporally, project management 195 tools often need to be able to specify the relationships between the 196 various events and tasks which make up a project. The LINK property 197 provides such a mechanism. 199 The LINK property MUST NOT be treated as just another attachment. 200 The ATTACH property defined in [RFC5545] has been extended by 201 [RFC8607] to handle server-side management and stripping of inline 202 data and to provide additional data about the attachment (size, 203 filename etc). 205 Additionally clients may choose to handle attachments differently 206 from the LINK property as attachments are often an integral part of 207 the message - for example, the agenda. 209 1.5. Caching and offline use 211 In general, the calendar entity should be self explanatory without 212 the need to download referenced meta-data such as a web page. 214 However, to facilitate offline display the link type may identify 215 important pieces of data which should be downloaded in advance. 217 1.6. Conventions Used in This Document 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and 221 "OPTIONAL" in this document are to be interpreted as described in BCP 222 14 [RFC2119] [RFC8174] when, and only when, they appear in all 223 capitals, as shown here. 225 The notation used in this memo to (re-)define iCalendar elements is 226 the ABNF notation of [RFC5234] as used by [RFC5545]. Any syntax 227 elements shown below that are not explicitly defined in this 228 specification come from iCalendar [RFC5545]. 230 2. LINK Property Reference Types 232 The reference value in the LINK property defined below can take three 233 forms specified by the VALUE parameter: 235 URI: This is a URI referring to the target. 237 UID: This allows for linking within a single collection of calendar 238 components and the value MUST refer to another component within 239 the same collection. 241 XML-REFERENCE: In an XML environment it may be necessary to refer to 242 a fragment of an external XML artifact. This value is a URI with 243 an XPointer anchor value. The XPointer is defined in 244 [W3C.WD-xptr-xpointer-20021219] and its use as an anchor is 245 defined in [W3C.REC-xptr-framework-20030325] 247 Note that UID references may need updating on import. An example, is 248 data to be imported from a file containing VTODO and VEVENT 249 components with a VTODO referring to VEVENT components by UID. When 250 imported into a CalDAV system, the VTODO components are typically 251 placed in a different collection from the VEVENT components. This 252 would require the UID reference to be replaced with a URI. 254 3. Link Relation Types 256 [RFC8288] defines two forms of relation type: registered and 257 extension. Registered relation types are added to the Link Relations 258 registry as specified in Section 2.1.1 of [RFC8288]. Extension 259 relation types, defined in Section 2.1.2 of [RFC8288], are specified 260 as unique URIs that are not registered in the registry. 262 The relation types defined in Section 6.1 will be registered with 263 IANA in accordance with the specifications in [RFC8288]. 265 4. New temporal RELTYPE Parameter values 267 This section defines the usual temporal relationships for use with 268 the RELTYPE parameter defined in Section 3.2.15 of [RFC5545]: 269 FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTART. 271 The [RFC5545] RELATED-TO property with one or more of these temporal 272 relationships will be present in the predecessor entity and will 273 refer to the successor entity. 275 The GAP parameter (see Section 6.2) specifies the lead (a negative 276 value) or lag (a positive value) time between the predecessor and the 277 successor. 279 In the description of each temporal relationship below we refer to 280 Task-A, which contains and controls the relationship, and Task-B the 281 target of the relationship. This is indicated by the direction of 282 the arrow in the diagrams below. 284 Also each relationship may be modified by the addition of a GAP 285 parameter to the relationship which applies to the targeted 286 component. 288 RELTYPE=FINISHTOSTART: Task-B cannot start until Task-A finishes. 289 For example, when painting is complete, carpet-laying can begin. 291 ============ 292 | Task-A | 293 ============ 294 | 295 V 296 ============ 297 | Task-B | 298 ============ 300 Figure 1: Finish to start relationship 302 RELTYPE=FINISHTOFINISH: Task-B can only be completed after Task-A is 303 finished. The related tasks may run in parallel before 304 completion. 306 For example, in the development of two related pieces of software, 307 e.g. the api and the implementation, the design of the 308 implementation (B) cannot be completed until the design of the api 309 (A) has been completed. 311 ================== 312 | Task-A |--+ 313 ================== | 314 | 315 ============ | 316 | Task-B |<-+ 317 ============ 319 Figure 2: Finish to finish relationship 321 RELTYPE=STARTTOFINISH: The start of Task-A (which occurs after Task- 322 B) controls the finish of Task-B. For example, ticket sales 323 (Task-B) end after the game starts (Task-A). 325 ============ 326 +--| Task-A | 327 | ============ 328 +---------+ 329 ============ | 330 | Task-B |<-+ 331 ============ 333 Figure 3: Start to finish relationship 335 RELTYPE=STARTTOSTART: The start of Task-A triggers the start of 336 Task-B, that is Task-B can start anytime after Task-A starts. 338 ============ 339 +--| Task-A | 340 | ============ 341 | 342 | ============ 343 +->| Task-B | 344 ============ 346 Figure 4: Start to start relationship 348 5. Additional New RELTYPE Parameter Values 350 This section defines the additional relationships below: 352 RELTYPE=FIRST: Indicates that the referenced calendar component is 353 the first in a series the referencing calendar component is part 354 of. 356 RELTYPE=NEXT: Indicates that the referenced calendar component is 357 the next in a series the referencing calendar component is part 358 of. 360 RELTYPE=DEPENDS-ON: Indicates that the current calendar component 361 depends on the referenced calendar component in some manner. For 362 example a task may be blocked waiting on the other, referenced, 363 task. 365 RELTYPE=REFID: Establishes a reference from the current component to 366 components with a REFID property which matches the value given in 367 the associated RELATED-TO property. 369 RELTYPE=CONCEPT: Establishes a reference from the current component 370 to components with a CONCEPT property which matches the value 371 given in the associated RELATED-TO property. 373 Note that the relationship types of PARENT, CHILD and SIBLING 374 establish a hierarchical relationship. The new types of FIRST and 375 NEXT are an ordering relationship. 377 6. New Property Parameters 378 6.1. Link Relation 380 Parameter name: LINKREL 382 Purpose: To specify the relationship of data referenced by a LINK 383 property. 385 Format Definition: This parameter is defined by the following 386 notation: 388 linkrelparam = "LINKREL" "=" 389 ("SOURCE" ; Link to source of this component 390 / DQUOTE uri DQUOTE 391 / iana-token) ; Other IANA registered type 393 Description: This parameter MUST be specified on all LINK 394 properties, and defines the type of reference. This allows 395 programs consuming this data to automatically scan for references 396 they support. There is no default relation type. 398 In addition to the value defined here any link relation in the 399 link registry established by [RFC8288], or new link relations, may 400 be used. 402 It is expected that link relation types seeing significant usage 403 in calendaring will have the calendaring usage described in an 404 RFC. 406 LINKREL=SOURCE: identifies the source of the event information. 408 Registration: These relation types are registered in [RFC8288] 410 6.2. Gap 412 Parameter name: GAP 414 Purpose: To specify the length of the gap, positive or negative, 415 between two components with a temporal relationship. 417 Format Definition: This parameter is defined by the following 418 notation where dur-value is defined in section 3.3.6 of [RFC5545]. 419 : 421 gapparam = "GAP" "=" dur-value 423 Description: This parameter MAY be specified on the RELATED-TO 424 property, and defines the duration of time between the predecessor 425 and successor in an interval. When positive it defines the lag 426 time between a task and its logical successor. When negative it 427 defines the lead time. 429 An example of lag time might be if task A is "paint the room" and 430 task B is "lay the carpets" then task A may be related to task B 431 with RELTYPE=FINISHTOSTART with a gap of 1 day - long enough for 432 the paint to dry. 434 ==================== 435 | Paint the room |--+ 436 ==================== | 437 |(lag of one day) 438 | 439 | =============== 440 +->| lay carpet | 441 =============== 443 Figure 5: Finish to start relationship with lag 445 For an example of lead time, in constructing a two storey building 446 the electrical work must be done before painting. However the 447 painter can move in to the first floor as the electricians move 448 upstairs. 450 ===================== 451 | Electrical work |--+ 452 ===================== | 453 +-------------+ 454 |(lead of estimated time) 455 | ================== 456 +->| Painting | 457 ================== 459 Figure 6: Finish to start relationship with lead 461 7. New Value Data Types 463 This specification defines the following new value types to be used 464 with the VALUE property parameter: 466 UID VALUE=UID indicates that the associated value is the UID for a 467 component. 469 XML-REFERENCE VALUE=XML-REFERENCE indicates that the associated 470 value references an associated XML artifact and is a URI with an 471 XPointer anchor value. The XPointer is defined in 472 [W3C.WD-xptr-xpointer-20021219] and its use as an anchor is 473 defined in [W3C.REC-xptr-framework-20030325]. 475 8. New Properties 477 8.1. Concept 479 Property name: CONCEPT 481 Purpose: This property defines the formal categories for a calendar 482 component. 484 Value type: URI 486 Property Parameters: IANA, and non-standard parameters can be 487 specified on this property. 489 Conformance: This property can be specified zero or more times in 490 any iCalendar component. 492 Description: This property is used to specify formal categories or 493 classifications of the calendar component. The values are useful 494 in searching for a calendar component of a particular type and 495 category. 497 This categorization is distinct from the more informal "tagging" 498 of components provided by the existing CATEGORIES property. It is 499 expected that the value of the CONCEPT property will reference an 500 external resource which provides information about the 501 categorization. 503 In addition, a structured URI value allows for hierarchical 504 categorization of events. 506 Possible category resources are the various proprietary systems, 507 for example Library of Congress, or an open source of 508 categorisation data. 510 Format Definition: This property is defined by the following 511 notation: 513 concept = "CONCEPT" conceptparam ":" 514 uri CRLF 516 conceptparam = *(";" other-param) 518 Example: The following is an example of this property. It points to 519 a server acting as the source for the calendar object. 521 CONCEPT:https://example.com/event-types/arts/music 523 8.2. Link 525 Property name: LINK 527 Purpose: This property provides a reference to external information 528 related to a component. 530 Value type: URI, UID or XML-REFERENCE 532 Property Parameters: The VALUE parameter is required. Non-standard, 533 link relation type, format type, label and language parameters can 534 also be specified on this property. The LABEL parameter is 535 defined in [RFC7986]. 537 Conformance: This property can be specified zero or more times in 538 any iCalendar component. 540 Description: When used in a component the value of this property 541 points to additional information related to the component. For 542 example, it may reference the originating web server. 544 Format Definition: This property is defined by the following 545 notation: 547 link = "LINK" linkparam ":" 548 ( uri / ; for VALUE=XML-REFERENCE 549 uri / ; for VALUE=URI 550 text ) ; for VALUE=UID 551 CRLF 553 linkparam = ; the elements herein may appear in any order, 554 ; and the order is not significant. 556 (";" "VALUE" "=" ("XML-REFERENCE" / 557 "URI" / 558 "UID")) 559 1*(";" linkrelparam) 560 1*(";" fmttypeparam) 561 1*(";" labelparam) 562 1*(";" languageparam) 563 *(";" other-param) 565 This property is a serialisation of the model in [RFC8288], where 566 the link target is carried in the property value, the link context 567 is the containing calendar entity, and the link relation type and 568 any target attributes are carried in iCalendar property 569 parameters. 571 The LINK property parameters map to [RFC8288] attributes as 572 follows: 574 LABEL: Maps to the "title" attribute defined in section 3.4.1 of 575 [RFC8288]. 577 LANGUAGE: Maps to the "hreflang" attribute defined in section 578 3.4.1 of [RFC8288]. 580 LINKREL: Maps to the link relation type defined in section 2.1 of 581 [RFC8288]. 583 FMTTYPE: Maps to the "type" attribute defined in section 3.4.1 of 584 [RFC8288]. 586 There is no mapping for [RFC8288] "title*", "anchor", "rev" or 587 "media". 589 Example: The following is an example of this property which provides 590 a reference to the source for the calendar object. 592 LINK;LINKREL=SOURCE;LABEL=Venue;VALUE=URI: 593 https://example.com/events 595 Example: The following is an example of this property which provides 596 a reference to an entity from which this one was derived. The 597 link relation is a vendor defined value. 599 LINK;LINKREL="https://example.com/linkrel/derivedFrom"; 600 VALUE=URI: 601 https://example.com/tasks/01234567-abcd1234.ics 603 Example: The following is an example of this property which provides 604 a reference to a fragment of an XML document. The link relation 605 is a vendor defined value. 607 LINK;LINKREL="https://example.com/linkrel/costStructure"; 608 VALUE=XML-REFERENCE: 609 https://example.com/xmlDocs/bidFramework.xml 610 #xpointer(descendant::CostStruc/range-to( 611 following::CostStrucEND[1])) 613 8.3. Refid 615 Property name: REFID 617 Purpose: This property value acts as a key for associated iCalendar 618 entities. 620 Value type: TEXT 622 Property Parameters: Non-standard parameters can be specified on 623 this property. 625 Conformance: This property can be specified zero or more times in 626 any iCalendar component. 628 Description: The value of this property is free-form text that 629 creates an identifier for associated components. All components 630 that use the same REFID value are associated through that value 631 and can be located or retrieved as a group. For example, all of 632 the events in a travel itinerary would have the same REFID value, 633 so as to be grouped together. 635 Format Definition: This property is defined by the following 636 notation: 638 refid = "REFID" refidparam ":" text CRLF 640 refidparam = *(";" other-param) 642 The current link registry 644 Example: The following is an example of this property. 646 REFID:itinerary-2014-11-17 648 9. Updates to RFC 5545 650 This specification updates the RELATED-TO property defined in 651 Section 3.8.4.5 of [RFC5545]. The contents of Section 9.1 replace 652 that section. 654 The RELTYPE parameter is extended to take new values defining 655 temporal relationships, a GAP parameter is defined to provide lead 656 and lag values, and RELATED-TO is extended to allow URI values. 657 These changes allow the RELATED-TO property to define a richer set of 658 relationships useful for project management. 660 9.1. RELATED-TO 662 Property Name: RELATED-TO 664 Purpose: This property is used to represent a relationship or 665 reference between one calendar component and another. The 666 definition here extends the definition in Section 3.8.4.5 of 667 [RFC5545] by allowing URI or UID values and a GAP parameter. 669 Value Type: URI, UID or TEXT 671 Property Parameters: Relationship type, IANA and non-standard 672 property parameters can be specified on this property. 674 Conformance: This property MAY be specified in any iCalendar 675 component. 677 Description: By default or when VALUE=UID is specified, the property 678 value consists of the persistent, globally unique identifier of 679 another calendar component. This value would be represented in a 680 calendar component by the "UID" property. 682 By default, the property value points to another calendar 683 component that has a PARENT relationship to the referencing 684 object. The "RELTYPE" property parameter is used to either 685 explicitly state the default PARENT relationship type to the 686 referenced calendar component or to override the default PARENT 687 relationship type and specify either a CHILD or SIBLING 688 relationship or a temporal relationship. 690 The PARENT relationship indicates that the calendar component is a 691 subordinate of the referenced calendar component. The CHILD 692 relationship indicates that the calendar component is a superior 693 of the referenced calendar component. The SIBLING relationship 694 indicates that the calendar component is a peer of the referenced 695 calendar component. 697 To preserve backwards compatibility the value type MUST be UID 698 when the PARENT, SIBLING or CHILD relationships are specified. 700 The FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTART 701 relationships define temporal relationships as specified in the 702 reltype parameter definition. 704 The FIRST and NEXT define ordering relationships between calendar 705 components. 707 The DEPENDS-ON relationship indicates that the current calendar 708 component depends on the referenced calendar component in some 709 manner. For example a task may be blocked waiting on the other, 710 referenced, task. 712 The REFID and CONCEPT relationships establish a reference from the 713 current component to the referenced component. 715 Changes to a calendar component referenced by this property can 716 have an implicit impact on the related calendar component. For 717 example, if a group event changes its start or end date or time, 718 then the related, dependent events will need to have their start 719 and end dates changed in a corresponding way. Similarly, if a 720 PARENT calendar component is cancelled or deleted, then there is 721 an implied impact to the related CHILD calendar components. This 722 property is intended only to provide information on the 723 relationship of calendar components. 725 Deletion of the target component, for example the target of a 726 FIRST, NEXT or temporal relationship can result in broken links. 728 It is up to the target calendar system to maintain any property 729 implications of these relationships. 731 Format Definition: This property is defined by the following 732 notation: 734 related = "RELATED-TO" relparam ":" 735 ( text / ; for VALUE=UID 736 uri / ; for VALUE=URI 737 text ) ; for VALUE=TEXT or default 738 CRLF 740 relparam = ; the elements herein may appear in any order, 741 ; and the order is not significant. 742 [";" "VALUE" "=" ("UID" / 743 "URI" / 744 "TEXT")] 745 [";" reltypeparam] 746 [";" gapparam] 747 *(";" other-param) 749 Example: The following are examples of this property. 751 RELATED-TO:jsmith.part7.19960817T083000.xyzMail@example.com 753 RELATED-TO:19960401-080045-4000F192713-0052@example.com 755 RELATED-TO;VALUE=URI;RELTYPE=STARTTOFINISH: 756 https://example.com/caldav/user/jb/cal/ 757 19960401-080045-4000F192713.ics 759 10. Security Considerations 761 All of the security considerations of section 7 pf [RFC5545] apply to 762 this specification. 764 Applications using the LINK property need to be aware of the risks 765 entailed in using the URIs provided as values. See section 7 of 766 [RFC3986] for a discussion of the security considerations relating to 767 URIs. 769 In particular note section 7.1 "Reliability and Consistency" of 770 [RFC3986] which points out the lack of a stability guarantee for 771 referenced resources. 773 When the value is an XML-REFERENCE type the targeted data is an XML 774 document or portion thereof. Consumers need to be aware of the 775 security issues related to XML processing - in particular those 776 related to XML entities. See [RFC4918] - Section 20.6. Additionally 777 note that the reference may be invalid or become so over time. 779 The CONCEPT and redefined RELATED-TO property have the same issues in 780 that values may be URIs. 782 Extremely large values for the GAP parameter may lead to unexpected 783 behavior. 785 11. IANA Considerations 787 11.1. iCalendar Property Registrations 789 The following iCalendar property names have been added to the 790 iCalendar Properties Registry defined in Section 8.3.2 of [RFC5545]. 791 IANA has also added a reference to this document where the properties 792 originally defined in [RFC5545] have been updated by this document. 794 +============+=========+========================+ 795 | Property | Status | Reference | 796 +============+=========+========================+ 797 | CONCEPT | Current | Section 8.1 | 798 +------------+---------+------------------------+ 799 | LINK | Current | Section 8.2 | 800 +------------+---------+------------------------+ 801 | REFID | Current | Section 8.3 | 802 +------------+---------+------------------------+ 803 | RELATED-TO | Current | [RFC5545], Section 9.1 | 804 +------------+---------+------------------------+ 806 Table 1 808 11.2. iCalendar Property Parameter Registrations 810 The following iCalendar property parameter names have been added to 811 the iCalendar Parameters Registry defined in Section 8.3.3 of 812 [RFC5545]. 814 +===========+=========+=============+ 815 | Parameter | Status | Reference | 816 +===========+=========+=============+ 817 | GAP | Current | Section 6.2 | 818 +-----------+---------+-------------+ 819 | LINKREL | Current | Section 6.1 | 820 +-----------+---------+-------------+ 822 Table 2 824 11.3. iCalendar Value Data Type Registrations 826 The following iCalendar property parameter names have been added to 827 the iCalendar Value Data Types Registry defined in Section 8.3.4 of 828 [RFC5545]. 830 +=================+=========+===========+ 831 | Value Data Type | Status | Reference | 832 +=================+=========+===========+ 833 | XML-REFERENCE | Current | Section 7 | 834 +-----------------+---------+-----------+ 835 | UID | Current | Section 7 | 836 +-----------------+---------+-----------+ 838 Table 3 840 11.4. iCalendar RELTYPE Value Registrations 842 The following iCalendar "RELTYPE" values have been added to the 843 iCalendar Relationship Types Registry defined in Section 8.3.8 of 844 [RFC5545]. 846 +===================+=========+===========+ 847 | Relationship Type | Status | Reference | 848 +===================+=========+===========+ 849 | CONCEPT | Current | Section 5 | 850 +-------------------+---------+-----------+ 851 | DEPENDS-ON | Current | Section 5 | 852 +-------------------+---------+-----------+ 853 | FINISHTOFINISH | Current | Section 4 | 854 +-------------------+---------+-----------+ 855 | FINISHTOSTART | Current | Section 4 | 856 +-------------------+---------+-----------+ 857 | FIRST | Current | Section 5 | 858 +-------------------+---------+-----------+ 859 | NEXT | Current | Section 5 | 860 +-------------------+---------+-----------+ 861 | REFID | Current | Section 5 | 862 +-------------------+---------+-----------+ 863 | STARTTOFINISH | Current | Section 4 | 864 +-------------------+---------+-----------+ 865 | STARTTOSTART | Current | Section 4 | 866 +-------------------+---------+-----------+ 868 Table 4 870 11.5. New Reference Type Registration 872 The following link relation values have been added to the Reference 873 Types Registry defined in Section 6.2.2 of [RFC8288]. 875 +========+=========+=============+ 876 | Name | Status | Reference | 877 +========+=========+=============+ 878 | SOURCE | Current | Section 6.1 | 879 +--------+---------+-------------+ 881 Table 5 883 12. Acknowledgements 885 The author would like to thank the members of CalConnect, the 886 Calendaring and Scheduling Consortium technical committees and the 887 following individuals for contributing their ideas, support and 888 comments: 890 Adrian Apthorp, Cyrus Daboo, Marten Gajda, Ken Murchison 892 The author would also like to thank CalConnect, the Calendaring and 893 Scheduling Consortium for advice with this specification. 895 13. References 897 13.1. Informative References 899 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 900 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 901 DOI 10.17487/RFC4791, March 2007, 902 . 904 [RFC8607] Daboo, C., Quillaud, A., and K. Murchison, Ed., 905 "Calendaring Extensions to WebDAV (CalDAV): Managed 906 Attachments", RFC 8607, DOI 10.17487/RFC8607, June 2019, 907 . 909 13.2. Normative References 911 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 912 Requirement Levels", BCP 14, RFC 2119, 913 DOI 10.17487/RFC2119, March 1997, 914 . 916 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 917 Resource Identifier (URI): Generic Syntax", STD 66, 918 RFC 3986, DOI 10.17487/RFC3986, January 2005, 919 . 921 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 922 Authoring and Versioning (WebDAV)", RFC 4918, 923 DOI 10.17487/RFC4918, June 2007, 924 . 926 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 927 Specifications: ABNF", STD 68, RFC 5234, 928 DOI 10.17487/RFC5234, January 2008, 929 . 931 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 932 Scheduling Core Object Specification (iCalendar)", 933 RFC 5545, DOI 10.17487/RFC5545, September 2009, 934 . 936 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 937 DOI 10.17487/RFC7986, October 2016, 938 . 940 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 941 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 942 May 2017, . 944 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 945 DOI 10.17487/RFC8288, October 2017, 946 . 948 [W3C.REC-skos-reference-20090818] 949 Miles, A. and S. Bechhofer, "SKOS Simple Knowledge 950 Organization System Reference", World Wide Web Consortium 951 Recommendation REC-skos-reference-20090818, 18 August 952 2009, 953 . 955 [W3C.REC-xptr-framework-20030325] 956 Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer 957 Framework", World Wide Web Consortium Recommendation REC- 958 xptr-framework-20030325, 25 March 2003, 959 . 961 [W3C.WD-xptr-xpointer-20021219] 962 DeRose, S., Daniel, R., and E. Maler, "XPointer xpointer() 963 Scheme", World Wide Web Consortium WD WD-xptr-xpointer- 964 20021219, 19 December 2002, 965 . 967 Author's Address 969 Michael Douglass 970 Bedework 971 226 3rd Street 972 Troy, NY 12180 973 United States of America 974 Email: mdouglass@bedework.com 975 URI: https://bedework.com