idnits 2.17.1 draft-ietf-calext-ical-relations-08.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 (October 13, 2021) is 926 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 647, but not defined Summary: 0 errors (**), 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) October 13, 2021 5 Intended status: Standards Track 6 Expires: April 16, 2022 8 Support for iCalendar Relationships 9 draft-ietf-calext-ical-relations-08 11 Abstract 13 This specification updates RELATED-TO defined in iCalendar (RFC5545) 14 and introduces new iCalendar properties LINK, CONCEPT and REFID to 15 allow better linking and grouping of iCalendar components and related 16 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 April 16, 2022. 35 Copyright Notice 37 Copyright (c) 2021 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 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Structured iCalendar relationships . . . . . . . . . . . 3 54 1.2. Grouped iCalendar relationships . . . . . . . . . . . . . 3 55 1.3. Concept relationships . . . . . . . . . . . . . . . . . . 3 56 1.4. Linked relationships . . . . . . . . . . . . . . . . . . 4 57 1.5. Caching and offline use . . . . . . . . . . . . . . . . . 5 58 1.6. Conventions Used in This Document . . . . . . . . . . . . 5 59 2. Reference Types . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Link Relation Types . . . . . . . . . . . . . . . . . . . . . 5 61 4. New temporal RELTYPE Parameter values . . . . . . . . . . . . 6 62 5. Additional New RELTYPE Parameter Values . . . . . . . . . . . 7 63 6. New Property Parameters . . . . . . . . . . . . . . . . . . . 8 64 6.1. Link Relation . . . . . . . . . . . . . . . . . . . . . . 8 65 6.2. Gap . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7. New Value Data Types . . . . . . . . . . . . . . . . . . . . 9 67 8. New Properties . . . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Concept . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 8.2. Link . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.3. Refid . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 9. Redefined RELATED-TO Property . . . . . . . . . . . . . . . . 12 72 9.1. RELATED-TO . . . . . . . . . . . . . . . . . . . . . . . 12 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 11.1. iCalendar Property Registrations . . . . . . . . . . . . 14 76 11.2. iCalendar Property Parameter Registrations . . . . . . . 15 77 11.3. iCalendar Value Data Type Registrations . . . . . . . . 15 78 11.4. iCalendar RELTYPE Value Registrations . . . . . . . . . 15 79 11.5. New Reference Type Registration . . . . . . . . . . . . 16 80 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 81 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 13.1. Informative References . . . . . . . . . . . . . . . . . 16 83 13.2. Normative References . . . . . . . . . . . . . . . . . . 17 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 iCalendar entities often need to be related to each other or to 89 associated meta-data. The specifications below support relationships 90 of the following forms: 92 Structured iCalendar: iCalendar entities can be related to each 93 other in some structured way, for example as parent, sibling, 94 before, after. 96 Grouped iCalendar: iCalendar entities can be related to each other 97 as a group. CATEGORIES are often used for this purpose but are 98 problematic for application developers due to their lack of 99 consistency and use as a free-form tag. 101 Linked: Entities can be linked to other entities such as vcards 102 through a URI and associated REL and FMTTYPE parameters. 104 1.1. Structured iCalendar relationships 106 The currently existing iCalendar [RFC5545] RELATED-TO property has no 107 support for temporal relationships as used by standard project 108 management tools. 110 The RELTYPE parameter is extended to take new values defining 111 temporal relationships, a GAP parameter is defined to provide lead 112 and lag values, and RELATED-TO is extended to allow URI values. 113 These changes allow the RELATED-TO property to define a richer set of 114 relationships useful for project management. 116 1.2. Grouped iCalendar relationships 118 This specification defines a new REFID property which allows 119 arbitrary groups of entities to be associated with the same key 120 value. 122 REFID is used to identify a key allowing the association of 123 components that are related to the same object and retrieval of a 124 component based on this key. Two examples of how this may be used 125 are to identify the tasks associated with a given project without 126 having to communicate the task structure of the project, and to group 127 all tasks associated to a specific package in a package delivery 128 system. 130 As such, the presence of a REFID property imparts no meaning to the 131 component. It is merely a key to allow retrieval. This is distinct 132 from categorisation which, while allowing grouping also adds meaning 133 to the component to which it is attached. 135 1.3. Concept relationships 137 The name CONCEPT is used by the Simple Knowledge Organization System 138 defined in [W3C.REC-skos-reference-20090818]. The term "concept" 139 more accurately defines what we often mean by a category. It's not 140 the text string that is important but the meaning attached to it. 141 For example, the term "football" can mean very different sports. 143 The introduction of CONCEPT allows a more structured approach to 144 categorization, with the possibility of namespaced and path-like 145 values. Unlike REFID the CONCEPT property imparts some meaning. It 146 is assumed that the value of this property will reference a well 147 defined category. 149 The current [RFC5545] CATEGORY property is used as a free form 150 'tagging' field. As such it is difficult to establish formal 151 relationships between components based on their category. 153 Rather than attempt to add semantics to the CATEGORY property it 154 seems best to continue its usage as an informal tag and establish a 155 new CONCEPT property with more constraints. 157 1.4. Linked relationships 159 The currently existing iCalendar standard [RFC5545] lacks a general 160 purpose method for referencing additional, external information 161 relating to calendar components. 163 This document proposes a method for referencing typed external 164 information that can provide additional information about an 165 iCalendar component. This new LINK property is closely aligned to 166 the LINK header defined in [RFC8288] 168 The LINK property defines a typed reference or relation to external 169 meta-data or related resources. By providing type and format 170 information as parameters, clients and servers are able to discover 171 interesting references and make use of them, perhaps for indexing or 172 the presentation of interesting links for the user. 174 It is also often necessary to reference calendar components in other 175 collections. For example, a VEVENT might refer to a VTODO from which 176 it was derived. The PARENT, SIBLING and CHILD relationships defined 177 for the RELATED-TO property only allow for a UID which is inadequate 178 for many purposes. Allowing other value types for those 179 relationships may help but would cause backward compatibility issues. 180 The LINK property can link components in different collections or 181 even on different servers. 183 When publishing events it is useful to be able to refer back to the 184 source of that information. The actual event may have been consumed 185 from a feed or an ics file on a web site. A LINK property can 186 provide a reference to the originator of the event. 188 Beyond the need to relate elements temporally, project management 189 tools often need to be able to specify the relationships between the 190 various events and tasks which make up a project. The LINK property 191 provides such a mechanism. 193 The LINK property MUST NOT be treated as just another attachment. 194 The ATTACH property defined in [RFC5545] is being extended to handle 195 server-side management and stripping of inline data. Clients may 196 choose to handle attachments differently from the LINK property as 197 they are often an integral part of the message - for example, the 198 agenda. 200 For more information on managed attachments see [RFC8607] 202 1.5. Caching and offline use 204 To facilitate offline display the link type may identify important 205 pieces of data which should be downloaded in advance. 207 In general, the calendar entity should be self explanatory without 208 the need to download referenced meta-data such as a web page. 210 1.6. Conventions Used in This Document 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and 214 "OPTIONAL" in this document are to be interpreted as described in BCP 215 14 [RFC2119] [RFC8174] when, and only when, they appear in all 216 capitals, as shown here. 218 2. Reference Types 220 The actual reference value can take three forms specified by the type 221 parameter 223 URI: The default type. This is a URI referring to the target. 225 UID: This allows for linking within a single collection and the 226 value MUST be another component within that collection. 228 REFERENCE: An XPointer. In an XML environment it may be necessary 229 to refer to an external XML artifact. The XPointer is defined in 230 [W3C.WD-xptr-xpointer-20021219] and allows addressing portions of 231 XML documents. 233 3. Link Relation Types 235 [RFC8288] defines two forms of relation type: registered and 236 extension. Registered relation types are added to the Link Relations 237 registry as specified in Section 2.1.1 of [RFC8288]. Extension 238 relation types, defined in Section 2.1.2 of [RFC8288], are specified 239 as unique URIs that are not registered in the registry. 241 The relation types defined in Section 6.1 will be registered with 242 IANA in accordance with the specifications in [RFC8288]. 244 4. New temporal RELTYPE Parameter values 246 This section defines the usual temporal relationships for use with 247 the RELTYPE parameter defined in Section 3.2.15 of [RFC5545]: 248 FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTART. 250 The [RFC5545] RELATED-TO property with one or more of these temporal 251 relationships will be present in the predecessor entity and will 252 refer to the successor entity. 254 The GAP parameter (see Section 6.2) specifies the lead or lag time 255 between the predecessor and the successor. In the description of 256 each temporal relationship below we refer to Task-A, which contains 257 and controls the relationship, and Task-B the target of the 258 relationship. 260 RELTYPE=FINISHTOSTART: Task-B cannot start until Task-A finishes. 261 For example, when sanding is complete, painting can begin. 263 ============ 264 | Task-A |--+ 265 ============ | 266 | 267 V 268 ============ 269 | Task-B | 270 ============ 272 Figure 1: Finish to start relationship 274 RELTYPE=FINISHTOFINISH: Task-B can only be completed after Task-A is 275 finished. The related tasks may run in parallel before 276 completion. 278 For example, if the goal is to prepare a meal, we start the 279 potatoes, then the meat then the peas but they should all be 280 cooked at the same time. 282 ================== 283 | Task-A |--+ 284 ================== | 285 | 286 ============ | 287 | Task-B |<-+ 288 ============ 290 Figure 2: Finish to finish relationship 292 RELTYPE=STARTTOFINISH: The start of Task-A (which occurs after Task- 293 B) controls the finish of Task-B. For example, ticket sales 294 (Task-B) end when the game starts (Task-A). 296 ============ 297 +--| Task-A | 298 | ============ 299 | 300 ============ | 301 | Task-B |<-+ 302 ============ 304 Figure 3: Start to finish relationship 306 RELTYPE=STARTTOSTART: The start of Task-A triggers the start of 307 Task-B, that is Task-B can start anytime after Task-A starts. 309 ============ 310 +--| Task-A | 311 | ============ 312 | 313 | ============ 314 +->| Task-B | 315 ============ 317 Figure 4: Start to start relationship 319 5. Additional New RELTYPE Parameter Values 321 This section defines the additional relationships below: 323 RELTYPE=FIRST: Indicates that the referenced calendar component is 324 the first in a series the referenced calendar component is part 325 of. 327 RELTYPE=DEPENDS-ON: Indicates that the current calendar component 328 depends on the referenced calendar component in some manner. For 329 example a task may be blocked waiting on the other, referenced, 330 task. 332 RELTYPE=REFID: Establishes a reference from the current component to 333 components with a REFID property which matches the value given in 334 the associated RELATED-TO property. 336 RELTYPE=CONCEPT: Establishes a reference from the current component 337 to components with a CONCEPT property which matches the value 338 given in the associated RELATED-TO property. 340 6. New Property Parameters 342 6.1. Link Relation 344 Parameter name: LINKREL 346 Purpose: To specify the relationship of data referenced by a LINK 347 property. 349 Format Definition: 351 This parameter is defined by the following notation: 353 linkrelparam = "REL" "=" 354 ("SOURCE" ; Link to source of this component 355 / DQUOTE uri DQUOTE 356 / iana-token) ; Other IANA registered type 358 Description: This parameter MUST be specified on all LINK 359 properties, and defines the type of reference. This allows 360 programs consuming this data to automatically scan for references 361 they support. In addition to the values defined here any value 362 defined in [RFC8288] may be used. There is no default relation 363 type. 365 REL=SOURCE: identifies the source of the event information. 367 Registration: These relation types are registered in [RFC8288] 369 6.2. Gap 371 Parameter name: GAP 373 Purpose: To specify the length of the gap, positive or negative, 374 between two temporaly related components. 376 Format Definition: 378 This parameter is defined by the following notation: 380 gapparam = "GAP" "=" dur-value 382 Description: This parameter MAY be specified on the RELATED-TO 383 property, and defines the duration of time between the predecessor 384 and successor in an interval. When positive it defines the lag 385 time between a task and its logical successor. When negative it 386 defines the lead time. 388 An example of lag time might be if task A is "paint the room" and 389 task B is "hang the drapes" then task A may be related to task B 390 with RELTYPE=FINISHTOSTART with a gap long enough for the paint to 391 dry. 393 An example of lead time might be to relate a 1 week task A to the 394 end of task B with RELTYPE=STARTTOFINISH and a negative gap of 1 395 week so they finish at the same time. 397 7. New Value Data Types 399 This specification defines the following new value types to be used 400 with the VALUE property parameter: 402 UID VALUE=UID indicates that the associated value is the UID for a 403 component. 405 REFERENCE VALUE=REFERENCE indicates that the associated value is an 406 XPointer referencing an associated XML artifact. 408 8. New Properties 410 8.1. Concept 412 Property name: CONCEPT 414 Purpose: This property defines the formal categories for a calendar 415 component. 417 Value type: URI 419 Property Parameters: IANA, and non-standard parameters can be 420 specified on this property. 422 Conformance: This property can be specified zero or more times in 423 any iCalendar component. 425 Description: This property is used to specify formal categories or 426 classifications of the calendar component. The values are useful 427 in searching for a calendar component of a particular type and 428 category. 430 Within the "VEVENT", "VTODO", or "VJOURNAL" calendar components, 431 more than one formal category can be specified by using multiple 432 CONCEPT properties. 434 This categorization is distinct from the more informal "tagging" 435 of components provided by the existing CATEGORIES property. It is 436 expected that the value of the CONCEPT property will reference an 437 external resource which provides information about the 438 categorization. 440 In addition, a structured URI value allows for hierarchical 441 categorization of events. 443 Possible category resources are the various proprietary systems, 444 for example Library of Congress, or an open source of 445 categorisation data. 447 Format Definition: 449 This property is defined by the following notation: 451 concept = "CONCEPT" conceptparam ":" 452 uri CRLF 454 conceptparam = *(";" other-param) 456 Example: 458 The following is an example of this property. It points to a server 459 acting as the source for the calendar object. 461 CONCEPT:http://example.com/event-types/arts/music 463 8.2. Link 465 Property name: LINK 467 Purpose: This property provides a reference to external information 468 about a component. 470 Value type: URI, TEXT or REFERENCE 471 Property Parameters: The VALUE parameter is required. Non-standard, 472 reference type or format type parameters can also be specified on 473 this property. The LABEL parameter is defined in [RFC7986] 475 Conformance: This property can be specified zero or more times in 476 any iCalendar component. 478 Description: When used in a component the value of this property 479 points to additional information related to the component. For 480 example, it may reference the originating web server. 482 Format Definition: 484 This property is defined by the following notation: 486 link = "LINK" linkparam ":" 487 ( text / ; for VALUE=REFERENCE 488 uri / ; for VALUE=URI 489 text ) ; for VALUE=TEXT 490 CRLF 492 linkparam = ; the elements herein may appear in any order, 493 ; and the order is not significant. 495 (";" "VALUE" "=" ("UID" / 496 "URI" / 497 "TEXT")) 498 1*(";" linkrelparam) 499 (";" fmttypeparam) 500 (";" labelparam) 501 *(";" other-param) 503 Example: 505 The following is an example of this property which provides a 506 reference to the source for the calendar object. 508 LINK;LINKREL=SOURCE;LABEL=Venue;VALUE=URI:http://example.com/events 510 Example: 512 The following is an example of this property which provides a 513 reference to an entity from which this one was derived. The link 514 relation is a vendor defined value 516 LINK;LINKREL="https://example.com/linkrel/derivedFrom";VALUE=URI: 517 http://example.com/tasks/01234567-abcd1234.ics 519 8.3. Refid 521 Property name: REFID 523 Purpose: This property value acts as a key for associated iCalendar 524 entities. 526 Value type: TEXT 528 Property Parameters: Non-standard parameters can be specified on 529 this property. 531 Conformance: This property can be specified zero or more times in 532 any iCalendar component. 534 Description: The value of this property is free-form text that 535 creates an identifier for associated components. All components 536 that use the same REFID value are associated through that value 537 and can be located or retrieved as a group. For example, all of 538 the events in a travel itinerary would have the same REFID value, 539 so as to be grouped together. 541 Format Definition: 543 This property is defined by the following notation: 545 refid = "REFID" refidparam ":" text CRLF 547 refidparam = *(";" other-param) 549 Example: 551 The following is an example of this property. 553 REFID:itinerary-2014-11-17 555 9. Redefined RELATED-TO Property 557 9.1. RELATED-TO 559 Property name: RELATED-TO 561 Purpose: This property is used to represent a relationship or 562 reference between one calendar component and another. The 563 definition here extends the definition in Section 3.8.4.5 of 564 [RFC5545] by allowing URI or UID values and a GAP parameter. 566 Value type: URI, UID or TEXT 568 Property Parameters: Relationship type, IANA and non-standard 569 property parameters can be specified on this property. 571 Conformance: This property MAY be specified in any iCalendar 572 component. 574 Description: By default or when VALUE=UID is specified, the property 575 value consists of the persistent, globally unique identifier of 576 another calendar component. This value would be represented in a 577 calendar component by the "UID" property. 579 By default, the property value points to another calendar 580 component that has a PARENT relationship to the referencing 581 object. The "RELTYPE" property parameter is used to either 582 explicitly state the default PARENT relationship type to the 583 referenced calendar component or to override the default PARENT 584 relationship type and specify either a CHILD or SIBLING 585 relationship or a temporal relationship. 587 The PARENT relationship indicates that the calendar component is a 588 subordinate of the referenced calendar component. The CHILD 589 relationship indicates that the calendar component is a superior 590 of the referenced calendar component. The SIBLING relationship 591 indicates that the calendar component is a peer of the referenced 592 calendar component. 594 To preserve backwards compatibility the value type MUST be UID 595 when the PARENT, SIBLING or CHILD relationships are specified. 597 The FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTART 598 relationships define temporal relationships as specified in the 599 reltype parameter definition. 601 Changes to a calendar component referenced by this property can 602 have an implicit impact on the related calendar component. For 603 example, if a group event changes its start or end date or time, 604 then the related, dependent events will need to have their start 605 and end dates changed in a corresponding way. Similarly, if a 606 PARENT calendar component is cancelled or deleted, then there is 607 an implied impact to the related CHILD calendar components. This 608 property is intended only to provide information on the 609 relationship of calendar components. It is up to the target 610 calendar system to maintain any property implications of this 611 relationship. 613 Format Definition: 615 This property is defined by the following notation: 617 related = "RELATED-TO" relparam ":" 618 ( uid / ; for VALUE=UID 619 uri / ; for VALUE=URI 620 text ) ; for VALUE=TEXT or default 621 CRLF 623 relparam = ; the elements herein may appear in any order, 624 ; and the order is not significant. 625 [";" "VALUE" "=" ("UID" / 626 "URI" / 627 "TEXT")] 628 [";" reltypeparam] 629 [";" gapparam] 630 *(";" other-param) 632 Example: 634 The following are examples of this property. 636 RELATED-TO:jsmith.part7.19960817T083000.xyzMail@example.com 638 RELATED-TO:19960401-080045-4000F192713-0052@example.com 640 RELATED-TO;VALUE=URI;RELTYPE=STARTTOFINISH: 641 http://example.com/caldav/user/jb/cal/ 642 19960401-080045-4000F192713.ics 644 10. Security Considerations 646 Applications using the LINK property need to be aware of the risks 647 entailed in using the URIs provided as values. See [RFC3986] for a 648 discussion of the security considerations relating to URIs. 650 The CONCEPT and redefined RELATED-TO property have the same issues in 651 that values may be URIs. 653 11. IANA Considerations 655 11.1. iCalendar Property Registrations 657 The following iCalendar property names have been added to the 658 iCalendar Properties Registry defined in Section 8.3.2 of [RFC5545] 659 IANA has also added a reference to this document where the properties 660 originally defined in [RFC5545] have been updated by this document. 662 +------------+---------+----------------------+ 663 | Property | Status | Reference | 664 +------------+---------+----------------------+ 665 | CONCEPT | Current | Section 8.1 | 666 | LINK | Current | Section 8.2 | 667 | REFID | Current | Section 8.3 | 668 | RELATED-TO | Current | [RFC5545], Section 9 | 669 +------------+---------+----------------------+ 671 11.2. iCalendar Property Parameter Registrations 673 The following iCalendar property parameter names have been added to 674 the iCalendar Parameters Registry defined in Section 8.3.3 of 675 [RFC5545] 677 +-----------+---------+-------------+ 678 | Parameter | Status | Reference | 679 +-----------+---------+-------------+ 680 | GAP | Current | Section 6.2 | 681 | REL | Current | Section 6.1 | 682 +-----------+---------+-------------+ 684 11.3. iCalendar Value Data Type Registrations 686 The following iCalendar property parameter names have been added to 687 the iCalendar Value Data Types Registry defined in Section 8.3.4 of 688 [RFC5545] 690 +-----------------+---------+-----------+ 691 | Value Data Type | Status | Reference | 692 +-----------------+---------+-----------+ 693 | REFERENCE | Current | Section 7 | 694 | UID | Current | Section 7 | 695 +-----------------+---------+-----------+ 697 11.4. iCalendar RELTYPE Value Registrations 699 The following iCalendar "RELTYPE" values have been added to the 700 iCalendar Relationship Types Registry defined in Section 8.3.8 of 701 [RFC5545] 702 +-------------------+---------+-----------+ 703 | Relationship Type | Status | Reference | 704 +-------------------+---------+-----------+ 705 | CONCEPT | Current | Section 5 | 706 | DEPENDS-ON | Current | Section 5 | 707 | FINISHTOFINISH | Current | Section 4 | 708 | FINISHTOSTART | Current | Section 4 | 709 | FIRST | Current | Section 5 | 710 | REFID | Current | Section 5 | 711 | STARTTOFINISH | Current | Section 4 | 712 | STARTTOSTART | Current | Section 4 | 713 +-------------------+---------+-----------+ 715 11.5. New Reference Type Registration 717 The following link relation values have been added to the Reference 718 Types Registry defined in Section 6.2.2 of [RFC8288] 720 +--------+---------+-------------+ 721 | Name | Status | Reference | 722 +--------+---------+-------------+ 723 | SOURCE | Current | Section 6.1 | 724 +--------+---------+-------------+ 726 12. Acknowledgements 728 The author would like to thank the members of the Calendaring and 729 Scheduling Consortium technical committees and the following 730 individuals for contributing their ideas, support and comments: 732 Adrian Apthorp, Cyrus Daboo, Marten Gajda, Ken Murchison 734 The author would also like to thank CalConnect, the Calendaring and 735 Scheduling Consortium for advice with this specification. 737 13. References 739 13.1. Informative References 741 [RFC8607] Daboo, C., Quillaud, A., and K. Murchison, Ed., 742 "Calendaring Extensions to WebDAV (CalDAV): Managed 743 Attachments", RFC 8607, DOI 10.17487/RFC8607, June 2019, 744 . 746 13.2. Normative References 748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 749 Requirement Levels", BCP 14, RFC 2119, 750 DOI 10.17487/RFC2119, March 1997, 751 . 753 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 754 Scheduling Core Object Specification (iCalendar)", 755 RFC 5545, DOI 10.17487/RFC5545, September 2009, 756 . 758 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 759 DOI 10.17487/RFC7986, October 2016, 760 . 762 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 763 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 764 May 2017, . 766 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 767 DOI 10.17487/RFC8288, October 2017, 768 . 770 [W3C.REC-skos-reference-20090818] 771 Miles, A. and S. Bechhofer, "SKOS Simple Knowledge 772 Organization System Reference", World Wide Web Consortium 773 Recommendation REC-skos-reference-20090818, August 2009, 774 . 776 [W3C.WD-xptr-xpointer-20021219] 777 DeRose, S., Daniel, R., and E. Maler, "XPointer xpointer() 778 Scheme", World Wide Web Consortium WD WD-xptr-xpointer- 779 20021219, December 2002, 780 . 782 Author's Address 784 Michael Douglass 785 Bedework 786 226 3rd Street 787 Troy, NY 12180 788 USA 790 Email: mdouglass@bedework.com 791 URI: http://bedework.com