idnits 2.17.1 draft-ietf-calext-ical-relations-06.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 abstract seems to contain references ([RFC5545]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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 (December 31, 2020) is 1210 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3986' is mentioned on line 635, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 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) December 31, 2020 5 Intended status: Standards Track 6 Expires: July 4, 2021 8 Support for iCalendar Relationships 9 draft-ietf-calext-ical-relations-06 11 Abstract 13 This specification updates RELATED-TO defined in [RFC5545] and 14 introduces new iCalendar properties LINK, CONCEPT and REFID to allow 15 better linking and grouping of iCalendar components and related data. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 4, 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified 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. Reference Types . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Link Relation Types . . . . . . . . . . . . . . . . . . . . . 5 60 4. New temporal RELTYPE Parameter values . . . . . . . . . . . . 6 61 5. Additional New RELTYPE Parameter Values . . . . . . . . . . . 7 62 6. New Property Parameters . . . . . . . . . . . . . . . . . . . 8 63 6.1. Link Relation . . . . . . . . . . . . . . . . . . . . . . 8 64 6.2. Gap . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. New Value Data Types . . . . . . . . . . . . . . . . . . . . 9 66 8. New Properties . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. Concept . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8.2. Link . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8.3. Refid . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 9. Redefined RELATED-TO Property . . . . . . . . . . . . . . . . 12 71 9.1. RELATED-TO . . . . . . . . . . . . . . . . . . . . . . . 12 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 11.1. iCalendar Property Registrations . . . . . . . . . . . . 14 75 11.2. iCalendar Property Parameter Registrations . . . . . . . 15 76 11.3. iCalendar Value Data Type Registrations . . . . . . . . 15 77 11.4. iCalendar RELTYPE Value Registrations . . . . . . . . . 15 78 11.5. New Reference Type Registration . . . . . . . . . . . . 16 79 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 80 13. Normative References . . . . . . . . . . . . . . . . . . . . 16 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 83 1. Introduction 85 iCalendar entities often need to be related to each other or to 86 associated meta-data. The specifications below support relationships 87 of the following forms: 89 Structured iCalendar: iCalendar entities can be related to each 90 other in some structured way, for example as parent, sibling, 91 before, after. 93 Grouped iCalendar: iCalendar entities can be related to each other 94 as a group. CATEGORIES are often used for this purpose but are 95 problematic for application developers due to their lack of 96 consistency and use as a free-form tag. 98 Linked: Entities can be linked to other entities such as vcards 99 through a URI and associated REL and FMTTYPE parameters. 101 1.1. Structured iCalendar relationships 103 The currently existing iCalendar [RFC5545] RELATED-TO property has no 104 support for temporal relationships as used by standard project 105 management tools. 107 The RELTYPE parameter is extended to take new values defining 108 temporal relationships, a GAP parameter is defined to provide lead 109 and lag values, and RELATED-TO is extended to allow URI values. 110 These changes allow the RELATED-TO property to define a richer set of 111 relationships useful for project management. 113 1.2. Grouped iCalendar relationships 115 This specification defines a new REFID property which allows 116 arbitrary groups of entities to be associated with the same key 117 value. 119 REFID is used to identify a key allowing the association of 120 components that are related to the same object and retrieval of a 121 component based on this key. Two examples of how this may be used 122 are to identify the tasks associated with a given project without 123 having to communicate the task structure of the project, and to group 124 all tasks associated to a specific package in a package delivery 125 system. 127 As such, the presence of a REFID property imparts no meaning to the 128 component. It is merely a key to allow retrieval. This is distinct 129 from categorisation which, while allowing grouping also adds meaning 130 to the component to which it is attached. 132 1.3. Concept relationships 134 The name CONCEPT is used by the Simple Knowledge Organization System 135 defined in [W3C.CR-skos-reference-20090317]. The term "concept" more 136 accurately defines what we often mean by a category. It's not the 137 text string that is important but the meaning attached to it. For 138 example, the term "football" can mean very different sports. 140 The introduction of CONCEPT allows a more structured approach to 141 categorization, with the possibility of namespaced and path-like 142 values. Unlike REFID the CONCEPT property imparts some meaning. It 143 is assumed that the value of this property will reference a well 144 defined category. 146 The current [RFC5545] CATEGORY property is used as a free form 147 'tagging' field. As such it is difficult to establish formal 148 relationships between components based on their category. 150 Rather than attempt to add semantics to the CATEGORY property it 151 seems best to continue its usage as an informal tag and establish a 152 new CONCEPT property with more constraints. 154 1.4. Linked relationships 156 The currently existing iCalendar standard [RFC5545] lacks a general 157 purpose method for referencing additional, external information 158 relating to calendar components. 160 This document proposes a method for referencing typed external 161 information that can provide additional information about an 162 iCalendar component. This new LINK property is closely aligned to 163 the LINK header defined in [RFC8288] 165 The LINK property defines a typed reference or relation to external 166 meta-data or related resources. By providing type and format 167 information as parameters, clients and servers are able to discover 168 interesting references and make use of them, perhaps for indexing or 169 the presentation of interesting links for the user. 171 It is also often necessary to reference calendar components in other 172 collections. For example, a VEVENT might refer to a VTODO from which 173 it was derived. The PARENT, SIBLING and CHILD relationships defined 174 for the RELATED-TO property only allow for a UID which is inadequate 175 for many purposes. Allowing other value types for those 176 relationships may help but would cause backward compatibility issues. 177 The link property can link components in different collections or 178 even on different servers. 180 When publishing events it is useful to be able to refer back to the 181 source of that information. The actual event may have been consumed 182 from a feed or an ics file on a web site. A LINK property can 183 provide a reference to the originator of the event. 185 Beyond the need to relate elements temporally, project management 186 tools often need to be able to specify the relationships between the 187 various events and tasks which make up a project. The LINK property 188 provides such a mechanism. 190 The LINK property SHOULD NOT be treated as just another attachment. 191 The ATTACH property is being extended to handle server-side 192 management and stripping of inline data. Clients may choose to 193 handle attachments differently as they are often an integral part of 194 the message - for example, the agenda. See 195 [I-D.daboo-caldav-attachments] 197 1.5. Caching and offline use 199 To facilitate offline display the link type may identify important 200 pieces of data which should be downloaded in advance. 202 In general, the calendar entity should be self explanatory without 203 the need to download referenced meta-data such as a web page. 205 1.6. Conventions Used in This Document 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and 209 "OPTIONAL" in this document are to be interpreted as described in BCP 210 14 [RFC2119] [RFC8174] when, and only when, they appear in all 211 capitals, as shown here. 213 2. Reference Types 215 The actual reference value can take three forms specified by the type 216 parameter 218 URI: The default type. This is a URI referring to the target. 220 UID: This allows for linking within a single collection and the 221 value MUST be another component within that collection. 223 REFERENCE: An XPointer. In an XML environment it may be necessary 224 to refer to an external XML artifact. The XPointer is defined in 225 [W3C.WD-xptr-xpointer-20021219] and allows addressing portions of 226 XML documents. 228 3. Link Relation Types 230 [RFC8288] defines two forms of relation type: registered and 231 extension. Registered relation types are added to the Link Relations 232 registry as specified in Section 2.1.1 of [RFC8288]. Extension 233 relation types, defined in Section 2.1.2 of [RFC8288], are specified 234 as unique URIs that are not registered in the registry. 236 The relation types defined in Section 6.1 will be registered with 237 IANA in accordance with the specifications in [RFC8288]. 239 4. New temporal RELTYPE Parameter values 241 This section defines the usual temporal relationships for use with 242 the RELTYPE parameter redefined in Section 3.2.15 of [RFC5545]: 243 FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTART. 245 The [RFC5545] RELATED-TO property with one or more of these temporal 246 relationships will be present in the predecessor entity and will 247 refer to the successor entity. 249 The GAP parameter (see Section 6.2) specifies the lead or lag time 250 between the predecessor and the successor. In the description of 251 each temporal relationship below we refer to Task-A, which contains 252 and controls the relationship, and Task-B the target of the 253 relationship. 255 RELTYPE=FINISHTOSTART: Task-B cannot start until Task-A finishes. 256 For example, when sanding is complete, painting can begin. 258 ============ 259 | Task-A |--+ 260 ============ | 261 | 262 V 263 ============ 264 | Task-B | 265 ============ 267 Figure 1: Finish to start relationship 269 RELTYPE=FINISHTOFINISH: Task-B cannot finish before Task-A is 270 finished, that is the end of Task-A defines the end of Task-B. 271 For example, we start the potatoes, then the meat then the peas 272 but they should all be cooked at the same time. 274 ============ 275 | Task-A |--+ 276 ============ | 277 | 278 ============ | 279 | Task-B |<-+ 280 ============ 282 Figure 2: Finish to finish relationship 284 RELTYPE=STARTTOFINISH: The start of Task-A (which occurs after Task- 285 B) controls the finish of Task-B. For example, ticket sales 286 (Task-B) end when the game starts (Task-A). 288 ============ 289 +--| Task-A | 290 | ============ 291 | 292 ============ | 293 | Task-B |<-+ 294 ============ 296 Figure 3: Start to finish relationship 298 RELTYPE=STARTTOSTART: The start of Task-A triggers the start of 299 Task-B, that is Task-B can start anytime after Task-A starts. 301 ============ 302 +--| Task-A | 303 | ============ 304 | 305 | ============ 306 +->| Task-B | 307 ============ 309 Figure 4: Start to start relationship 311 5. Additional New RELTYPE Parameter Values 313 This section defines the additional relationships below: 315 RELTYPE=DEPENDS-ON: Indicates that the current calendar component 316 depends on the referenced calendar component in some manner. For 317 example a task may be blocked waiting on the other, referenced, 318 task. 320 RELTYPE=REFID: Establishes a reference from the current component to 321 components with a REFID property which matches the value given in 322 the associated RELATED-TO property. 324 RELTYPE=CONCEPT: Establishes a reference from the current component 325 to components with a CONCEPT property which matches the value 326 given in the associated RELATED-TO property. 328 6. New Property Parameters 330 6.1. Link Relation 332 Parameter name: LINKREL 334 Purpose: To specify the relationship of data referenced by a LINK 335 property. 337 Format Definition: 339 This parameter is defined by the following notation: 341 linkrelparam = "REL" "=" 342 ("SOURCE" ; Link to source of this component 343 / DQUOTE uri DQUOTE 344 / iana-token) ; Other IANA registered type 346 Description: This parameter MUST be specified on all LINK 347 properties, and defines the type of reference. This allows 348 programs consuming this data to automatically scan for references 349 they support. In addition to the values defined here any value 350 defined in [RFC8288] may be used. There is no default relation 351 type. 353 REL=SOURCE: identifies the source of the event information. 355 Registration: These relation types are registered in [RFC8288] 357 6.2. Gap 359 Parameter name: GAP 361 Purpose: To specify the length of the gap, positive or negative, 362 between two temporaly related components. 364 Format Definition: 366 This parameter is defined by the following notation: 368 gapparam = "GAP" "=" dur-value 370 Description: This parameter MAY be specified on the RELATED-TO 371 property, and defines the duration of time between the predecessor 372 and successor in an interval. When positive it defines the lag 373 time between a task and its logical successor. When negative it 374 defines the lead time. 376 An example of lag time might be if task A is "paint the room" and 377 task B is "hang the drapes" then task A may be related to task B 378 with RELTYPE=FINISHTOSTART with a gap long enough for the paint to 379 dry. 381 An example of lead time might be to relate a 1 week task A to the 382 end of task B with RELTYPE=STARTTOFINISH and a negative gap of 1 383 week so they finish at the same time. 385 7. New Value Data Types 387 This specification defines the following new value types to be used 388 with the VALUE property parameter: 390 UID VALUE=UID indicates that the associated value is the UID for a 391 component. 393 REFERENCE VALUE=REFERENCE indicates that the associated value is an 394 XPointer referencing an associated XML artifact. 396 8. New Properties 398 8.1. Concept 400 Property name: CONCEPT 402 Purpose: This property defines the formal categories for a calendar 403 component. 405 Value type: URI 407 Property Parameters: IANA, and non-standard parameters can be 408 specified on this property. 410 Conformance: This property can be specified zero or more times in 411 any iCalendar component. 413 Description: This property is used to specify formal categories or 414 classifications of the calendar component. The values are useful 415 in searching for a calendar component of a particular type and 416 category. 418 Within the "VEVENT", "VTODO", or "VJOURNAL" calendar components, 419 more than one formal category can be specified by using multiple 420 CONCEPT properties. 422 This categorization is distinct from the more informal "tagging" 423 of components provided by the existing CATEGORIES property. It is 424 expected that the value of the CONCEPT property will reference an 425 external resource which provides information about the 426 categorization. 428 In addition, a structured URI value allows for hierarchical 429 categorization of events. 431 Possible category resources are the various proprietary systems, 432 for example Library of Congress, or an open source of 433 categorisation data. 435 Format Definition: 437 This property is defined by the following notation: 439 concept = "CONCEPT" conceptparam ":" 440 uri CRLF 442 conceptparam = *(";" other-param) 444 Example: 446 The following is an example of this property. It points to a server 447 acting as the source for the calendar object. 449 CONCEPT:http://example.com/event-types/arts/music 451 8.2. Link 453 Property name: LINK 455 Purpose: This property provides a reference to external information 456 about a component. 458 Value type: URI, TEXT or REFERENCE 460 Property Parameters: The VALUE parameter is required. Non-standard, 461 reference type or format type parameters can also be specified on 462 this property. The LABEL parameter is defined in [RFC7986] 464 Conformance: This property MAY be specified in any iCalendar 465 component. 467 Description: When used in a component the value of this property 468 points to additional information related to the component. For 469 example, it may reference the originating web server. 471 Format Definition: 473 This property is defined by the following notation: 475 link = "LINK" linkparam ":" 476 ( text / ; for VALUE=REFERENCE 477 uri / ; for VALUE=URI 478 text ) ; for VALUE=TEXT 479 CRLF 481 linkparam = ; the elements herein may appear in any order, 482 ; and the order is not significant. 484 (";" "VALUE" "=" ("UID" / 485 "URI" / 486 "TEXT")) 487 1*(";" linkrelparam) 488 (";" fmttypeparam) 489 (";" labelparam) 490 *(";" other-param) 492 Example: 494 The following is an example of this property which provides a 495 reference to the source for the calendar object. 497 LINK;LINKREL=SOURCE;LABEL=Venue;VALUE=URI:http://example.com/events 499 Example: 501 The following is an example of this property which provides a 502 reference to an entity from which this one was derived. The link 503 relation is a vendor defined value 505 LINK;LINKREL="https://example.com/linkrel/derivedFrom";VALUE=URI: 506 http://example.com/tasks/01234567-abcd1234.ics 508 8.3. Refid 510 Property name: REFID 512 Purpose: This property value acts as a key for associated iCalendar 513 entities. 515 Value type: TEXT 516 Property Parameters: Non-standard parameters can be specified on 517 this property. 519 Conformance: This property MAY be specified multiple times in any 520 iCalendar component. 522 Description: The value of this property is free-form text that 523 creates an identifier for associated components. All components 524 that use the same REFID value are associated through that value 525 and can be located or retrieved as a group. For example, all of 526 the events in a travel itinerary would have the same REFID value, 527 so as to be grouped together. 529 Format Definition: 531 This property is defined by the following notation: 533 refid = "REFID" refidparam ":" text CRLF 535 refidparam = *(";" other-param) 537 Example: 539 The following is an example of this property. 541 REFID:itinerary-2014-11-17 543 9. Redefined RELATED-TO Property 545 9.1. RELATED-TO 547 Property name: RELATED-TO 549 Purpose: This property is used to represent a relationship or 550 reference between one calendar component and another. The 551 definition here extends the definition in Section 3.8.4.5 of 552 [RFC5545] by allowing URI or UID values and a GAP parameter. 554 Value type: URI, UID or TEXT 556 Property Parameters: Relationship type, IANA and non-standard 557 property parameters can be specified on this property. 559 Conformance: This property MAY be specified in any iCalendar 560 component. 562 Description: By default or when VALUE=UID is specified, the property 563 value consists of the persistent, globally unique identifier of 564 another calendar component. This value would be represented in a 565 calendar component by the "UID" property. 567 By default, the property value points to another calendar 568 component that has a PARENT relationship to the referencing 569 object. The "RELTYPE" property parameter is used to either 570 explicitly state the default PARENT relationship type to the 571 referenced calendar component or to override the default PARENT 572 relationship type and specify either a CHILD or SIBLING 573 relationship or a temporal relationship. 575 The PARENT relationship indicates that the calendar component is a 576 subordinate of the referenced calendar component. The CHILD 577 relationship indicates that the calendar component is a superior 578 of the referenced calendar component. The SIBLING relationship 579 indicates that the calendar component is a peer of the referenced 580 calendar component. 582 To preserve backwards compatibility the value type MUST be UID 583 when the PARENT, SIBLING or CHILD relationships are specified. 585 The FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTART 586 relationships define temporal relationships as specified in the 587 reltype parameter definition. 589 Changes to a calendar component referenced by this property can 590 have an implicit impact on the related calendar component. For 591 example, if a group event changes its start or end date or time, 592 then the related, dependent events will need to have their start 593 and end dates changed in a corresponding way. Similarly, if a 594 PARENT calendar component is cancelled or deleted, then there is 595 an implied impact to the related CHILD calendar components. This 596 property is intended only to provide information on the 597 relationship of calendar components. It is up to the target 598 calendar system to maintain any property implications of this 599 relationship. 601 Format Definition: 603 This property is defined by the following notation: 605 related = "RELATED-TO" relparam ":" 606 ( uid / ; for VALUE=UID 607 uri / ; for VALUE=URI 608 text ) ; for VALUE=TEXT or default 609 CRLF 611 relparam = ; the elements herein may appear in any order, 612 ; and the order is not significant. 613 [";" "VALUE" "=" ("UID" / 614 "URI" / 615 "TEXT")] 616 [";" reltypeparam] 617 [";" gapparam] 618 *(";" other-param) 620 Example: 622 The following are examples of this property. 624 RELATED-TO:jsmith.part7.19960817T083000.xyzMail@example.com 626 RELATED-TO:19960401-080045-4000F192713-0052@example.com 628 RELATED-TO;VALUE=URI;RELTYPE=STARTTOFINISH: 629 http://example.com/caldav/user/jb/cal/ 630 19960401-080045-4000F192713.ics 632 10. Security Considerations 634 Applications using the LINK property need to be aware of the risks 635 entailed in using the URIs provided as values. See [RFC3986] for a 636 discussion of the security considerations relating to URIs. 638 The CONCEPT and redefined RELATED-TO property have the same issues in 639 that values may be URIs. 641 11. IANA Considerations 643 11.1. iCalendar Property Registrations 645 The following iCalendar property names have been added to the 646 iCalendar Properties Registry defined in Section 8.3.2 of [RFC5545] 647 +----------+---------+-------------+ 648 | Property | Status | Reference | 649 +----------+---------+-------------+ 650 | CONCEPT | Current | Section 8.1 | 651 | LINK | Current | Section 8.2 | 652 | REFID | Current | Section 8.3 | 653 +----------+---------+-------------+ 655 11.2. iCalendar Property Parameter Registrations 657 The following iCalendar property parameter names have been added to 658 the iCalendar Parameters Registry defined in Section 8.3.3 of 659 [RFC5545] 661 +-----------+---------+-------------+ 662 | Parameter | Status | Reference | 663 +-----------+---------+-------------+ 664 | REL | Current | Section 6.1 | 665 | GAP | Current | Section 6.2 | 666 +-----------+---------+-------------+ 668 11.3. iCalendar Value Data Type Registrations 670 The following iCalendar property parameter names have been added to 671 the iCalendar Value Data Types Registry defined in Section 8.3.4 of 672 [RFC5545] 674 +-----------------+---------+-----------+ 675 | Value Data Type | Status | Reference | 676 +-----------------+---------+-----------+ 677 | UID | Current | Section 7 | 678 | REFERENCE | Current | Section 7 | 679 +-----------------+---------+-----------+ 681 11.4. iCalendar RELTYPE Value Registrations 683 The following iCalendar "RELTYPE" values have been added to the 684 iCalendar Relationship Types Registry defined in Section 8.3.8 of 685 [RFC5545] 686 +-------------------+---------+-----------+ 687 | Relationship Type | Status | Reference | 688 +-------------------+---------+-----------+ 689 | DEPENDS-ON | Current | Section 5 | 690 | REFID | Current | Section 5 | 691 | CONCEPT | Current | Section 5 | 692 | FINISHTOSTART | Current | Section 4 | 693 | FINISHTOFINISH | Current | Section 4 | 694 | STARTTOFINISH | Current | Section 4 | 695 | STARTTOSTART | Current | Section 4 | 696 +-------------------+---------+-----------+ 698 11.5. New Reference Type Registration 700 The following link relation values have been added to the Reference 701 Types Registry defined in Section 6.2.2 of [RFC8288] 703 +--------+---------+-------------+ 704 | Name | Status | Reference | 705 +--------+---------+-------------+ 706 | SOURCE | Current | Section 6.1 | 707 +--------+---------+-------------+ 709 12. Acknowledgements 711 The author would like to thank the members of the Calendaring and 712 Scheduling Consortium technical committees and the following 713 individuals for contributing their ideas, support and comments: 715 Adrian Apthorp, Cyrus Daboo, Marten Gajda, Ken Murchison 717 The author would also like to thank CalConnect, the Calendaring and 718 Scheduling Consortium for advice with this specification. 720 13. Normative References 722 [I-D.daboo-caldav-attachments] 723 Daboo, C. and A. Quillaud, "CalDAV Managed Attachments", 724 draft-daboo-caldav-attachments-03 (work in progress), 725 February 2014. 727 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 728 Requirement Levels", BCP 14, RFC 2119, 729 DOI 10.17487/RFC2119, March 1997, 730 . 732 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 733 Scheduling Core Object Specification (iCalendar)", 734 RFC 5545, DOI 10.17487/RFC5545, September 2009, 735 . 737 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 738 DOI 10.17487/RFC7986, October 2016, 739 . 741 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 742 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 743 May 2017, . 745 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 746 DOI 10.17487/RFC8288, October 2017, 747 . 749 [W3C.CR-skos-reference-20090317] 750 Bechhofer, S. and A. Miles, "SKOS Simple Knowledge 751 Organization System Reference", World Wide Web Consortium 752 CR CR-skos-reference-20090317, March 2009, 753 . 755 [W3C.WD-xptr-xpointer-20021219] 756 DeRose, S., Daniel, R., and E. Maler, "XPointer xpointer() 757 Scheme", World Wide Web Consortium WD WD-xptr-xpointer- 758 20021219, December 2002, 759 . 761 Author's Address 763 Michael Douglass 764 Bedework 765 226 3rd Street 766 Troy, NY 12180 767 USA 769 Email: mdouglass@bedework.com 770 URI: http://bedework.com