idnits 2.17.1 draft-ietf-calext-ical-relations-05.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 (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 (July 29, 2020) is 1365 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) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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) July 29, 2020 5 Intended status: Standards Track 6 Expires: January 30, 2021 8 Support for iCalendar Relationships 9 draft-ietf-calext-ical-relations-05 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 January 30, 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. Redefined Relation Type Value . . . . . . . . . . . . . . . . 5 61 5. New Property Parameters . . . . . . . . . . . . . . . . . . . 8 62 5.1. Rel . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5.2. Gap . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 6. New Value Data Types . . . . . . . . . . . . . . . . . . . . 9 65 7. New Properties . . . . . . . . . . . . . . . . . . . . . . . 10 66 7.1. Concept . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 7.2. Link . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 7.3. Refid . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 8. Redefined RELATED-TO Property . . . . . . . . . . . . . . . . 13 70 8.1. RELATED-TO . . . . . . . . . . . . . . . . . . . . . . . 14 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 10.1. iCalendar Property Registrations . . . . . . . . . . . . 16 74 10.2. iCalendar Property Parameter Registrations . . . . . . . 16 75 10.3. iCalendar Value Data Type Registrations . . . . . . . . 16 76 10.4. iCalendar RELTYPE Value Registrations . . . . . . . . . 17 77 10.5. New Reference Type Registration . . . . . . . . . . . . 17 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 79 12. Normative References . . . . . . . . . . . . . . . . . . . . 18 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 82 1. Introduction 84 iCalendar entities often need to be related to each other or to 85 associated meta-data. These relationships can take the following 86 forms 88 Structured iCalendar: iCalendar entities are related to each other 89 in some structured way, for example as parent, sibling, before, 90 after. 92 Grouped iCalendar: iCalendar entities are related to each other as a 93 group. CATEGORIES are often used for this purpose but are 94 problematic for application developers. 96 Linked: Entities are linked to each other through typed references. 98 1.1. Structured iCalendar relationships 100 The currently existing iCalendar [RFC5545] RELATED-TO property has no 101 support for temporal relationships as used by standard project 102 management tools. 104 The RELTYPE parameter is extended to take new values defining 105 temporal relationships, a GAP parameter is defined to provide lead 106 and lag values and RELATED-TO is extended to allow URI values. These 107 changes allow the RELATED-TO property to define a richer set of 108 relationships useful for project management. 110 1.2. Grouped iCalendar relationships 112 This specification defines a new REFID property which allows 113 arbitrary groups of entities to be associated with the same key 114 value. 116 REFID is used to identify a key allowing the association of 117 components that are related to the same object and retrieval of a 118 component based on this key. This may be, for example, to identify 119 the tasks associated with a given project without having to 120 communicate the task structure of the project, or, for example, in a 121 package delivery system all tasks associated to a specific package. 123 As such, the presence of a REFID property imparts no meaning to the 124 component. It is merely a key to allow retrieval. This is distinct 125 from categorisation which, while allowing grouping also adds meaning 126 to the component to which it is attached. 128 1.3. Concept relationships 130 The name CONCEPT is used by the Simple Knowledge Organization System 131 defined in [W3C.CR-skos-reference-20090317]. This more accurately 132 defines what we mean by a category. It's not the words but the 133 meaning. 135 The introduction of CONCEPT allows a more structured approach to 136 categorization, with the possibility of namespaced and path-like 137 values. Unlike REFID the CONCEPT property imparts some meaning. It 138 is assumed that the value of this property will reference a well 139 defined category. 141 The current [RFC5545] CATEGORY property is used as a free form 142 'tagging' field. As such it is difficult to establish formal 143 relationships between components based on their category. 145 Rather than attempt to add semantics to the current property it 146 seeems best to continue its usage as an informal tag and establish a 147 new property with more constraints. 149 1.4. Linked relationships 151 The currently existing iCalendar standard [RFC5545] lacks a general 152 purpose method for referencing additional, external information 153 relating to calendar components. 155 This document proposes a method for referencing typed external 156 information that can provide additional information about an 157 iCalendar component. This new LINK property is closely aligned to 158 the LINK header defined in [RFC5988] 160 The LINK property defines a typed reference or relation to external 161 meta-data or related resources. By providing type and format 162 information as parameters, clients and servers are able to discover 163 interesting references and make use of them, perhaps for indexing or 164 the presentation of interesting links for the user. 166 It is often necessary to relate calendar components. The current 167 RELATED-TO property only allows for a UID which is inadequate for 168 many purposes. Allowing other value types for that property may help 169 but might raise a number of backward compatibility issues. The link 170 property can link components in different collections or even on 171 different servers. 173 When publishing events it is useful to be able to refer back to the 174 source of that information. The actual event may have been consumed 175 from a feed or an ics file on a web site. A LINK property can 176 provide a reference to the originator of the event. 178 Beyond the need to relate elements temporally, project management 179 tools often need to be able to specify the relationships between the 180 various events and tasks which make up a project. The LINK property 181 provides such a mechanism. 183 The LINK property SHOULD NOT be treated as just another attachment. 184 The ATTACH property is being extended to handle server-side 185 management and stripping of inline data. Clients may choose to 186 handle attachments differently as they are often an integral part of 187 the message - for example, the agenda. See 188 [I-D.daboo-caldav-attachments] 190 1.5. Caching and offline use 192 To facilitate offline display the link type may identify important 193 pieces of data which should be downloaded in advance. 195 In general, the calendar entity should be self explanatory without 196 the need to download referenced meta-data such as a web page. 198 1.6. Conventions Used in This Document 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 202 "OPTIONAL" in this document are to be interpreted as described in 203 [RFC2119]. 205 2. Reference Types 207 The actual reference value can take three forms specified by the type 208 parameter 210 URI: The default type. This is a URI referring to the target. 212 UID: This allows for linking within a single collection and the 213 value is assumed to be another component within that collection. 215 REFERENCE: An xpointer. In an XML environment it may be necessary 216 to refer to an external XML artifact. The XPointer is defined in 217 [W3C.WD-xptr-xpointer-20021219] and allows addressing portions of 218 XML documents. 220 3. Link Relation Types 222 [RFC5988] defines two forms of relation type, registered and 223 extension. Registered relation types are added to a registry defined 224 by [RFC5988] while extension relation types are specified as unique 225 unregistered URIs, (at least unregistered in the [RFC5988] registry). 227 The relation types defined here will be registered with IANA in 228 accordance with the specifications in [RFC5988]. 230 4. Redefined Relation Type Value 232 Relationship parameter type values are defined in section 3.2.15. of 233 [RFC5545]. This specification redefines that type to include the new 234 temporal relationship values FINISHTOSTART, FINISHTOFINISH, 235 STARTTOFINISH and STARTTOSTART. It also adds the DEPENDS-ON value to 236 provide a link to a component upon which the current component 237 depends. 239 Format Definition: 241 This property parameter is defined by the following notation: 243 reltypeparam = "RELTYPE" "=" 244 ("PARENT" ; Parent relationship - Default 245 / "CHILD" ; Child relationship 246 / "SIBLING" ; Sibling relationship 247 / "DEPENDS-ON" ; refers to previous component 248 / "REFID" ; Relationship based on REFID 249 / "CONCEPT" 250 ; Relationship based on CONCEPT 251 / "FINISHTOSTART" ; Temporal relationship 252 / "FINISHTOFINISH" ; Temporal relationship 253 / "STARTTOFINISH" ; Temporal relationship 254 / "STARTTOSTART" ; Temporal relationship 255 / iana-token ; Some other IANA-registered 256 ; iCalendar relationship type 257 / x-name) ; A non-standard, experimental 258 ; relationship type 260 Description: This parameter can be specified on a property that 261 references another related calendar component. The parameter may 262 specify the hierarchical relationship type of the calendar 263 component referenced by the property when the value is PARENT, 264 CHILD or SIBLING. If this parameter is not specified on an 265 allowable property, the default relationship type is PARENT. 266 Applications MUST treat x-name and iana-token values they don't 267 recognize the same way as they would the PARENT value. 269 This parameter defines the temporal relationship when the value is 270 one of the project management standard relationships 271 FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTART. 272 This property will be present in the predecessor entity and will 273 refer to the successor entity. The GAP parameter specifies the 274 lead or lag time between the predecessor and the successor. In 275 the description of each temporal relationship below we refer to 276 Task-A which contains and controls the relationship and Task-B the 277 target of the relationship. 279 RELTYPE=PARENT: See [RFC5545] section 3.2.15. 281 RELTYPE=CHILD: See [RFC5545] section 3.2.15. 283 RELTYPE=SIBLING: See [RFC5545] section 3.2.15. 285 RELTYPE=DEPENDS-ON: Indicates that the current calendar component 286 depends on the referenced calendar component in some manner. For 287 example a task may be blocked waiting on the other, referenced, 288 task. 290 RELTYPE=REFID: Establishes a reference from the current component to 291 components with a REFID property which matches the value given in 292 the associated RELATED-TO property. 294 RELTYPE=CONCEPT: Establishes a reference from the current component 295 to components with a CONCEPT property which matches the value 296 given in the associated RELATED-TO property. 298 RELTYPE=FINISHTOSTART: Task-B cannot start until Task-A finishes. 299 For example, when sanding is complete, painting can begin. 301 ============ 302 | Task-A |--+ 303 ============ | 304 | 305 V 306 ============ 307 | Task-B | 308 ============ 310 Figure 1: Finish to start relationship 312 RELTYPE=FINISHTOFINISH: Task-B cannot finish before Task-A is 313 finished, that is the end of Task-A defines the end of Task-B. 314 For example, we start the potatoes, then the meat then the peas 315 but they should all be cooked at the same time. 317 ============ 318 | Task-A |--+ 319 ============ | 320 | 321 ============ | 322 | Task-B |<-+ 323 ============ 325 Figure 2: Finish to finish relationship 327 RELTYPE=STARTTOFINISH: The start of Task-A (which occurs after Task- 328 B) controls the finish of Task-B. For example, ticket sales 329 (Task-B) end when the game starts (Task-A). 331 ============ 332 +--| Task-A | 333 | ============ 334 | 335 ============ | 336 | Task-B |<-+ 337 ============ 339 Figure 3: Start to finish relationship 341 RELTYPE=STARTTOSTART: The start of Task-A triggers the start of 342 Task-B, that is Task-B can start anytime after Task-A starts. 344 ============ 345 +--| Task-A | 346 | ============ 347 | 348 | ============ 349 +->| Task-B | 350 ============ 352 Figure 4: Start to start relationship 354 5. New Property Parameters 356 5.1. Rel 358 Parameter name: REL 360 Purpose: To specify the relationship of data referenced by a LINK 361 property. 363 Format Definition: 365 This parameter is defined by the following notation: 367 relparam = "REL" "=" 368 ("SOURCE" ; Link to source of this component 369 / DQUOTE uri DQUOTE 370 / x-name ; Experimental reference type 371 / iana-token) ; Other IANA registered type 373 Description: This parameter MUST be specified on all LINK 374 properties, and defines the type of reference. This allows 375 programs consuming this data to automatically scan for references 376 they support. In addition to the values defined here any value 377 defined in [RFC5988] may be used. There is no default relation 378 type. 380 REL=SOURCE: identifies the source of the event information. 382 Registration: These relation types are registered in [RFC5988] 384 5.2. Gap 386 Parameter name: GAP 388 Purpose: To specify the length of the gap, positive or negative 389 between two temporaly related components. 391 Format Definition: 393 This parameter is defined by the following notation: 395 gapparam = "GAP" "=" dur-value 397 Description: This parameter MAY be specified on the RELATED-TO 398 property, and defines the duration of time between the predecessor 399 and successor in an interval. When positive it defines the lag 400 time between a task and its logical successor. When negative it 401 defines the lead time. 403 An example of lag time might be if task A is "paint the room" and 404 task B is "hang the drapes" then task A may be related to task B 405 with RELTYPE=FINISHTOSTART with a gap long enough for the paint to 406 dry. 408 An example of lead time might be to relate a 1 week task A to the 409 end of task B with RELTYPE=STARTTOFINISH and a negative gap of 1 410 week so they finish at the same time. 412 6. New Value Data Types 414 This specification defines the following new value types to be used 415 with the VALUE property parameter: 417 UID VALUE=UID indicates that the associated value is the UID for a 418 component. 420 REFERENCE VALUE=REFERENCE indicates that the associated value is an 421 xpointer referencing an associated XML artifact. 423 7. New Properties 425 7.1. Concept 427 Property name: CONCEPT 429 Purpose: This property defines the formal categories for a calendar 430 component. 432 Value type: URI 434 Property Parameters: IANA, and non-standard parameters can be 435 specified on this property. 437 Conformance: This property can be specified zero or more times in 438 any iCalendar component. 440 Description: This property is used to specify formal categories or 441 classifications of the calendar component. The values are useful 442 in searching for a calendar component of a particular type and 443 category. 445 Within the "VEVENT", "VTODO", or "VJOURNAL" calendar components, 446 more than one formal category can be specified by using multiple 447 CONCEPT properties. 449 This categorization is distinct from the more informal "tagging" 450 of components provided by the existing CATEGORIES property. It is 451 expected that the value of the CONCEPT property will reference an 452 external resource which provides information about the 453 categorization. 455 In addition, a structured URI value allows for hierarchical 456 categorization of events. 458 Possible category resources are the various proprietary systems, 459 for example Library of Congress, or an open source derived from 460 something like the dmoz.org data. 462 Format Definition: 464 This property is defined by the following notation: 466 concept = "CONCEPT" conceptparam ":" 467 uri CRLF 469 conceptparam = *( 470 ; 471 ; The following is OPTIONAL, 472 ; and MAY occur more than once. 473 ; 474 (";" other-param) 475 ; 476 ) 478 Example: 480 The following is an example of this property. It points to a server 481 acting as the source for the calendar object. 483 SCONCEPT:http://example.com/event-types/sports 484 CONCEPT:http://example.com/event-types/arts/music 485 CONCEPT:http://example.com/task-types/delivery 487 7.2. Link 489 Property name: LINK 491 Purpose: This property provides a reference to external information 492 about a component. 494 Value type: URI, TEXT or REFERENCE 496 Property Parameters: Non-standard, reference type or format type 497 parameters can be specified on this property. 499 Conformance: This property MAY be specified in any iCalendar 500 component. 502 Description: When used in a component the value of this property 503 points to additional information related to the component. For 504 example, it may reference the originating web server. 506 Format Definition: 508 This property is defined by the following notation: 510 link = "LINK" linkparam / 511 ( 512 ";" "VALUE" "=" "TEXT" 513 ":" text 514 ) 515 ( 516 ";" "VALUE" "=" "REFERENCE" 517 ":" text 518 ) 519 ( 520 ";" "VALUE" "=" "URI" 521 ":" uri 522 ) 523 CRLF 525 linkparam = *( 527 ; the following is MANDATORY 528 ; and MAY occur more than once 530 (";" relparam) / 532 ; the following are MANDATORY 533 ; but MUST NOT occur more than once 535 (";" fmttypeparam) / 536 (";" labelparam) / 537 ; labelparam is defined in ... 539 ; the following is OPTIONAL 540 ; and MAY occur more than once 542 (";" xparam) 544 ) 546 Example: 548 The following is an example of this property. It points to a server 549 acting as the source for the calendar object. 551 LINK;REL=SOURCE;LABEL=The Egg:http://example.com/events 553 7.3. Refid 555 Property name: REFID 557 Purpose: This property value acts as a key for associated iCalendar 558 entities. 560 Value type: TEXT 562 Property Parameters: Non-standard parameters can be specified on 563 this property. 565 Conformance: This property MAY be specified multiple times in any 566 iCalendar component. 568 Description: The value of this property is a text identifier that 569 allows associated components to be located or retrieved as a 570 whole. For example all of the events in a travel itinerary would 571 have the same REFID value. 573 Format Definition: 575 This property is defined by the following notation: 577 refid = "REFID" refidparam ":" text CRLF 579 refidparam = *( 581 ; the following is OPTIONAL 582 ; and MAY occur more than once 584 (";" xparam) 586 ) 588 Example: 590 The following is an example of this property. 592 REFID:itinerary-2014-11-17 594 8. Redefined RELATED-TO Property 595 8.1. RELATED-TO 597 Property name: RELATED-TO 599 Purpose: This property is used to represent a relationship or 600 reference between one calendar component and another. The 601 definition here extends the definition in Section 3.8.4.5. of 602 [RFC5545] by allowing URI or UID values and a GAP parameter. 604 Value type: URI, UID or TEXT 606 Property Parameters: Relationship type, IANA and non-standard 607 property parameters can be specified on this property. 609 Conformance: This property MAY be specified in any iCalendar 610 component. 612 Description: By default or when VALUE=UID is specified, the property 613 value consists of the persistent, globally unique identifier of 614 another calendar component. This value would be represented in a 615 calendar component by the "UID" property. 617 By default, the property value points to another calendar 618 component that has a PARENT relationship to the referencing 619 object. The "RELTYPE" property parameter is used to either 620 explicitly state the default PARENT relationship type to the 621 referenced calendar component or to override the default PARENT 622 relationship type and specify either a CHILD or SIBLING 623 relationship or a temporal relationship. 625 The PARENT relationship indicates that the calendar component is a 626 subordinate of the referenced calendar component. The CHILD 627 relationship indicates that the calendar component is a superior 628 of the referenced calendar component. The SIBLING relationship 629 indicates that the calendar component is a peer of the referenced 630 calendar component. 632 The FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTART 633 relationships define temporal relationships as specified in the 634 reltype parameter definition. 636 Changes to a calendar component referenced by this property can 637 have an implicit impact on the related calendar component. For 638 example, if a group event changes its start or end date or time, 639 then the related, dependent events will need to have their start 640 and end dates changed in a corresponding way. Similarly, if a 641 PARENT calendar component is cancelled or deleted, then there is 642 an implied impact to the related CHILD calendar components. This 643 property is intended only to provide information on the 644 relationship of calendar components. It is up to the target 645 calendar system to maintain any property implications of this 646 relationship. 648 Format Definition: 650 This property is defined by the following notation: 652 related = "RELATED-TO" relparam ( ":" text ) / 653 ( 654 ";" "VALUE" "=" "UID" 655 ":" uid 656 ) 657 ( 658 ";" "VALUE" "=" "URI" 659 ":" uri 660 ) 661 CRLF 663 relparam = *( 664 ; 665 ; The following are OPTIONAL, 666 ; but MUST NOT occur more than once. 667 ; 668 (";" reltypeparam) / 669 (";" gapparam) / 670 ; 671 ; The following is OPTIONAL, 672 ; and MAY occur more than once. 673 ; 674 (";" other-param) 675 ; 676 ) 678 Example: 680 The following are examples of this property. 682 RELATED-TO:jsmith.part7.19960817T083000.xyzMail@example.com 684 RELATED-TO:19960401-080045-4000F192713-0052@example.com 686 RELATED-TO;VALUE=URI;RELTYPE=STARTTOFINISH: 687 http://example.com/caldav/user/jb/cal/ 688 19960401-080045-4000F192713.ics 690 9. Security Considerations 692 Applications using the LINK property need to be aware of the risks 693 entailed in using the URIs provided as values. See [RFC3986] for a 694 discussion of the security considerations relating to URIs. 696 The CONCEPT and redefined RELATED-TO property have the same issues in 697 that values may be URIs. 699 10. IANA Considerations 701 10.1. iCalendar Property Registrations 703 The following iCalendar property names have been added to the 704 iCalendar Properties Registry defined in Section 8.3.2 of [RFC5545] 706 +----------+---------+-------------+ 707 | Property | Status | Reference | 708 +----------+---------+-------------+ 709 | CONCEPT | Current | Section 7.1 | 710 | LINK | Current | Section 7.2 | 711 | REFID | Current | Section 7.3 | 712 +----------+---------+-------------+ 714 10.2. iCalendar Property Parameter Registrations 716 The following iCalendar property parameter names have been added to 717 the iCalendar Parameters Registry defined in Section 8.3.3 of 718 [RFC5545] 720 +-----------+---------+-------------+ 721 | Parameter | Status | Reference | 722 +-----------+---------+-------------+ 723 | REL | Current | Section 5.1 | 724 | GAP | Current | Section 5.2 | 725 +-----------+---------+-------------+ 727 10.3. iCalendar Value Data Type Registrations 729 The following iCalendar property parameter names have been added to 730 the iCalendar Value Data Types Registry defined in Section 8.3.4 of 731 [RFC5545] 732 +-----------------+---------+-----------+ 733 | Value Data Type | Status | Reference | 734 +-----------------+---------+-----------+ 735 | UID | Current | Section 6 | 736 | REFERENCE | Current | Section 6 | 737 +-----------------+---------+-----------+ 739 10.4. iCalendar RELTYPE Value Registrations 741 The following iCalendar "RELTYPE" values have been added to the 742 iCalendar Relationship Types Registry defined in Section 8.3.8 of 743 [RFC5545] 745 +-------------------+---------+-----------+ 746 | Relationship Type | Status | Reference | 747 +-------------------+---------+-----------+ 748 | DEPENDS-ON | Current | Section 4 | 749 | REFID | Current | Section 4 | 750 | CONCEPT | Current | Section 4 | 751 | FINISHTOSTART | Current | Section 4 | 752 | FINISHTOFINISH | Current | Section 4 | 753 | STARTTOFINISH | Current | Section 4 | 754 | STARTTOSTART | Current | Section 4 | 755 +-------------------+---------+-----------+ 757 10.5. New Reference Type Registration 759 The following link relation values have been added to the Reference 760 Types Registry defined in Section 6.2.2 of [RFC5988] 762 +--------+---------+-------------+ 763 | Name | Status | Reference | 764 +--------+---------+-------------+ 765 | SOURCE | Current | Section 5.1 | 766 +--------+---------+-------------+ 768 11. Acknowledgements 770 The author would like to thank the members of the Calendaring and 771 Scheduling Consortium technical committees and the following 772 individuals for contributing their ideas, support and comments: 774 Adrian Apthorp, Cyrus Daboo, Marten Gajda, Ken Murchison 776 The author would also like to thank CalConnect, the Calendaring and 777 Scheduling Consortium for advice with this specification. 779 12. Normative References 781 [I-D.daboo-caldav-attachments] 782 Daboo, C. and A. Quillaud, "CalDAV Managed Attachments", 783 draft-daboo-caldav-attachments-03 (work in progress), 784 February 2014. 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, 788 DOI 10.17487/RFC2119, March 1997, 789 . 791 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 792 Resource Identifier (URI): Generic Syntax", STD 66, 793 RFC 3986, DOI 10.17487/RFC3986, January 2005, 794 . 796 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 797 Scheduling Core Object Specification (iCalendar)", 798 RFC 5545, DOI 10.17487/RFC5545, September 2009, 799 . 801 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 802 DOI 10.17487/RFC5988, October 2010, 803 . 805 [W3C.CR-skos-reference-20090317] 806 Bechhofer, S. and A. Miles, "SKOS Simple Knowledge 807 Organization System Reference", World Wide Web Consortium 808 CR CR-skos-reference-20090317, March 2009, 809 . 811 [W3C.REC-xml-20060816] 812 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 813 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 814 Edition)", World Wide Web Consortium Recommendation REC- 815 xml-20060816, August 2006, 816 . 818 [W3C.WD-xptr-xpointer-20021219] 819 DeRose, S., Daniel, R., and E. Maler, "XPointer xpointer() 820 Scheme", World Wide Web Consortium WD WD-xptr-xpointer- 821 20021219, December 2002, 822 . 824 Author's Address 826 Michael Douglass 827 Bedework 828 226 3rd Street 829 Troy, NY 12180 830 USA 832 Email: mdouglass@bedework.com 833 URI: http://bedework.com