Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4791

Calendaring Extensions to WebDAV (CalDAV)

Pages: 107
Proposed Standard
Errata
Updated by:  568966386764780979538996
Part 5 of 5 – Pages 77 to 107
First   Prev   None

Top   ToC   RFC4791 - Page 77   prevText

9. XML Element Definitions

9.1. CALDAV:calendar XML Element

Name: calendar Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies the resource type of a calendar collection. Description: See Section 4.2. Definition: <!ELEMENT calendar EMPTY>

9.2. CALDAV:mkcalendar XML Element

Name: mkcalendar Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies a request that includes the WebDAV property values to be set for a calendar collection resource when it is created. Description: See Section 5.3.1. Definition: <!ELEMENT mkcalendar (DAV:set)>
Top   ToC   RFC4791 - Page 78

9.3. CALDAV:mkcalendar-response XML Element

Name: mkcalendar-response Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies a response body for a successful MKCALENDAR request. Description: See Section 5.3.1. Definition: <!ELEMENT mkcalendar-response ANY>

9.4. CALDAV:supported-collation XML Element

Name: supported-collation Namespace: urn:ietf:params:xml:ns:caldav Purpose: Identifies a single collation via its collation identifier, as defined by [RFC4790]. Description: The CALDAV:supported-collation contains the text of a collation identifier, as described in Section 7.5.1. Definition: <!ELEMENT supported-collation (#PCDATA)> PCDATA value: collation identifier

9.5. CALDAV:calendar-query XML Element

Name: calendar-query Namespace: urn:ietf:params:xml:ns:caldav Purpose: Defines a report for querying calendar object resources. Description: See Section 7.8. Definition: <!ELEMENT calendar-query ((DAV:allprop | DAV:propname | DAV:prop)?, filter, timezone?)>
Top   ToC   RFC4791 - Page 79

9.6. CALDAV:calendar-data XML Element

Name: calendar-data Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specified one of the following: 1. A supported media type for calendar object resources when nested in the CALDAV:supported-calendar-data property; 2. The parts of a calendar object resource should be returned by a calendaring report; 3. The content of a calendar object resource in a response to a calendaring report. Description: When nested in the CALDAV:supported-calendar-data property, the CALDAV:calendar-data XML element specifies a media type supported by the CalDAV server for calendar object resources. When used in a calendaring REPORT request, the CALDAV:calendar- data XML element specifies which parts of calendar object resources need to be returned in the response. If the CALDAV: calendar-data XML element doesn't contain any CALDAV:comp element, calendar object resources will be returned in their entirety. Finally, when used in a calendaring REPORT response, the CALDAV: calendar-data XML element specifies the content of a calendar object resource. Given that XML parsers normalize the two- character sequence CRLF (US-ASCII decimal 13 and US-ASCII decimal 10) to a single LF character (US-ASCII decimal 10), the CR character (US-ASCII decimal 13) MAY be omitted in calendar object resources specified in the CALDAV:calendar-data XML element. Furthermore, calendar object resources specified in the CALDAV: calendar-data XML element MAY be invalid per their media type specification if the CALDAV:calendar-data XML element part of the calendaring REPORT request did not specify required properties (e.g., UID, DTSTAMP, etc.), or specified a CALDAV:prop XML element with the "novalue" attribute set to "yes". Note: The CALDAV:calendar-data XML element is specified in requests and responses inside the DAV:prop XML element as if it were a WebDAV property. However, the CALDAV:calendar-data XML element is not a WebDAV property and, as such, is not returned in PROPFIND responses, nor used in PROPPATCH requests.
Top   ToC   RFC4791 - Page 80
   Note:  The iCalendar data embedded within the CALDAV:calendar-data
      XML element MUST follow the standard XML character data encoding
      rules, including use of &lt;, &gt;, &amp; etc. entity encoding or
      the use of a <![CDATA[ ... ]]> construct.  In the later case, the
      iCalendar data cannot contain the character sequence "]]>", which
      is the end delimiter for the CDATA section.

   Definition:

         <!ELEMENT calendar-data EMPTY>

         when nested in the CALDAV:supported-calendar-data property
         to specify a supported media type for calendar object
         resources;

         <!ELEMENT calendar-data (comp?,
                                  (expand | limit-recurrence-set)?,
                                  limit-freebusy-set?)>

         when nested in the DAV:prop XML element in a calendaring
         REPORT request to specify which parts of calendar object
         resources should be returned in the response;

         <!ELEMENT calendar-data (#PCDATA)>
         PCDATA value: iCalendar object

         when nested in the DAV:prop XML element in a calendaring
         REPORT response to specify the content of a returned
         calendar object resource.

         <!ATTLIST calendar-data content-type CDATA "text/calendar"
                                 version CDATA "2.0">
         content-type value: a MIME media type
         version value: a version string

         attributes can be used on all three variants of the
         CALDAV:calendar-data XML element.

9.6.1. CALDAV:comp XML Element

Name: comp Namespace: urn:ietf:params:xml:ns:caldav Purpose: Defines which component types to return.
Top   ToC   RFC4791 - Page 81
   Description:  The name value is a calendar component name (e.g.,
      VEVENT).

   Definition:

         <!ELEMENT comp ((allprop | prop*), (allcomp | comp*))>

         <!ATTLIST comp name CDATA #REQUIRED>
         name value: a calendar component name

   Note:  The CALDAV:prop and CALDAV:allprop elements have the same name
      as the DAV:prop and DAV:allprop elements defined in [RFC2518].
      However, the CALDAV:prop and CALDAV:allprop elements are defined
      in the "urn:ietf:params:xml:ns:caldav" namespace instead of the
      "DAV:" namespace.

9.6.2. CALDAV:allcomp XML Element

Name: allcomp Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies that all components shall be returned. Description: The CALDAV:allcomp XML element can be used when the client wants all types of components returned by a calendaring REPORT request. Definition: <!ELEMENT allcomp EMPTY>

9.6.3. CALDAV:allprop XML Element

Name: allprop Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies that all properties shall be returned. Description: The CALDAV:allprop XML element can be used when the client wants all properties of components returned by a calendaring REPORT request. Definition: <!ELEMENT allprop EMPTY>
Top   ToC   RFC4791 - Page 82
   Note:  The CALDAV:allprop element has the same name as the DAV:
      allprop element defined in [RFC2518].  However, the CALDAV:allprop
      element is defined in the "urn:ietf:params:xml:ns:caldav"
      namespace instead of the "DAV:" namespace.

9.6.4. CALDAV:prop XML Element

Name: prop Namespace: urn:ietf:params:xml:ns:caldav Purpose: Defines which properties to return in the response. Description: The "name" attribute specifies the name of the calendar property to return (e.g., ATTENDEE). The "novalue" attribute can be used by clients to request that the actual value of the property not be returned (if the "novalue" attribute is set to "yes"). In that case, the server will return just the iCalendar property name and any iCalendar parameters and a trailing ":" without the subsequent value data. Definition: <!ELEMENT prop EMPTY> <!ATTLIST prop name CDATA #REQUIRED novalue (yes | no) "no"> name value: a calendar property name novalue value: "yes" or "no" Note: The CALDAV:prop element has the same name as the DAV:prop element defined in [RFC2518]. However, the CALDAV:prop element is defined in the "urn:ietf:params:xml:ns:caldav" namespace instead of the "DAV:" namespace.

9.6.5. CALDAV:expand XML Element

Name: expand Namespace: urn:ietf:params:xml:ns:caldav Purpose: Forces the server to expand recurring components into individual recurrence instances. Description: The CALDAV:expand XML element specifies that for a given calendaring REPORT request, the server MUST expand the recurrence set into calendar components that define exactly one
Top   ToC   RFC4791 - Page 83
      recurrence instance, and MUST return only those whose scheduled
      time intersect a specified time range.

      The "start" attribute specifies the inclusive start of the time
      range, and the "end" attribute specifies the non-inclusive end of
      the time range.  Both attributes are specified as date with UTC
      time value.  The value of the "end" attribute MUST be greater than
      the value of the "start" attribute.

      The server MUST use the same logic as defined for CALDAV:time-
      range to determine if a recurrence instance intersects the
      specified time range.

      Recurring components, other than the initial instance, MUST
      include a RECURRENCE-ID property indicating which instance they
      refer to.

      The returned calendar components MUST NOT use recurrence
      properties (i.e., EXDATE, EXRULE, RDATE, and RRULE) and MUST NOT
      have reference to or include VTIMEZONE components.  Date and local
      time with reference to time zone information MUST be converted
      into date with UTC time.

   Definition:

         <!ELEMENT expand EMPTY>

         <!ATTLIST expand start CDATA #REQUIRED
                          end   CDATA #REQUIRED>
         start value: an iCalendar "date with UTC time"
         end value: an iCalendar "date with UTC time"

9.6.6. CALDAV:limit-recurrence-set XML Element

Name: limit-recurrence-set Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies a time range to limit the set of "overridden components" returned by the server. Description: The CALDAV:limit-recurrence-set XML element specifies that for a given calendaring REPORT request, the server MUST return, in addition to the "master component", only the "overridden components" that impact a specified time range. An overridden component impacts a time range if its current start and end times overlap the time range, or if the original start and end
Top   ToC   RFC4791 - Page 84
      times -- the ones that would have been used if the instance were
      not overridden -- overlap the time range.

      The "start" attribute specifies the inclusive start of the time
      range, and the "end" attribute specifies the non-inclusive end of
      the time range.  Both attributes are specified as date with UTC
      time value.  The value of the "end" attribute MUST be greater than
      the value of the "start" attribute.

      The server MUST use the same logic as defined for CALDAV:time-
      range to determine if the current or original scheduled time of an
      "overridden" recurrence instance intersects the specified time
      range.

      Overridden components that have a RANGE parameter on their
      RECURRENCE-ID property may specify one or more instances in the
      recurrence set, and some of those instances may fall within the
      specified time range or may have originally fallen within the
      specified time range prior to being overridden.  If that is the
      case, the overridden component MUST be included in the results, as
      it has a direct impact on the interpretation of instances within
      the specified time range.

   Definition:

         <!ELEMENT limit-recurrence-set EMPTY>

         <!ATTLIST limit-recurrence-set start CDATA #REQUIRED
                                        end   CDATA #REQUIRED>
         start value: an iCalendar "date with UTC time"
         end value: an iCalendar "date with UTC time"

9.6.7. CALDAV:limit-freebusy-set XML Element

Name: limit-freebusy-set Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies a time range to limit the set of FREEBUSY values returned by the server. Description: The CALDAV:limit-freebusy-set XML element specifies that for a given calendaring REPORT request, the server MUST only return the FREEBUSY property values of a VFREEBUSY component that intersects a specified time range. The "start" attribute specifies the inclusive start of the time range, and the "end" attribute specifies the non-inclusive end of
Top   ToC   RFC4791 - Page 85
      the time range.  Both attributes are specified as "date with UTC
      time" value.  The value of the "end" attribute MUST be greater
      than the value of the "start" attribute.

      The server MUST use the same logic as defined for CALDAV:time-
      range to determine if a FREEBUSY property value intersects the
      specified time range.

   Definition:

         <!ELEMENT limit-freebusy-set EMPTY>

         <!ATTLIST limit-freebusy-set start CDATA #REQUIRED
                                      end   CDATA #REQUIRED>
         start value: an iCalendar "date with UTC time"
         end value: an iCalendar "date with UTC time"

9.7. CALDAV:filter XML Element

Name: filter Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies a filter to limit the set of calendar components returned by the server. Description: The CALDAV:filter XML element specifies the search filter used to limit the calendar components returned by a calendaring REPORT request. Definition: <!ELEMENT filter (comp-filter)>

9.7.1. CALDAV:comp-filter XML Element

Name: comp-filter Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies search criteria on calendar components. Description: The CALDAV:comp-filter XML element specifies a query targeted at the calendar object (i.e., VCALENDAR) or at a specific calendar component type (e.g., VEVENT). The scope of the CALDAV:comp-filter XML element is the calendar object when used as a child of the CALDAV:filter XML element. The scope of the CALDAV:comp-filter XML element is the enclosing calendar component
Top   ToC   RFC4791 - Page 86
      when used as a child of another CALDAV:comp-filter XML element.  A
      CALDAV:comp-filter is said to match if:

      *  The CALDAV:comp-filter XML element is empty and the calendar
         object or calendar component type specified by the "name"
         attribute exists in the current scope;

      or:

      *  The CALDAV:comp-filter XML element contains a CALDAV:is-not-
         defined XML element and the calendar object or calendar
         component type specified by the "name" attribute does not exist
         in the current scope;

      or:

      *  The CALDAV:comp-filter XML element contains a CALDAV:time-range
         XML element and at least one recurrence instance in the
         targeted calendar component is scheduled to overlap the
         specified time range, and all specified CALDAV:prop-filter and
         CALDAV:comp-filter child XML elements also match the targeted
         calendar component;

      or:

      *  The CALDAV:comp-filter XML element only contains CALDAV:prop-
         filter and CALDAV:comp-filter child XML elements that all match
         the targeted calendar component.

   Definition:

         <!ELEMENT comp-filter (is-not-defined | (time-range?,
                                prop-filter*, comp-filter*))>

         <!ATTLIST comp-filter name CDATA #REQUIRED>
         name value: a calendar object or calendar component
                     type (e.g., VEVENT)

9.7.2. CALDAV:prop-filter XML Element

Name: prop-filter Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies search criteria on calendar properties. Description: The CALDAV:prop-filter XML element specifies a query targeted at a specific calendar property (e.g., CATEGORIES) in the
Top   ToC   RFC4791 - Page 87
      scope of the enclosing calendar component.  A calendar property is
      said to match a CALDAV:prop-filter if:

      *  The CALDAV:prop-filter XML element is empty and a property of
         the type specified by the "name" attribute exists in the
         enclosing calendar component;

      or:

      *  The CALDAV:prop-filter XML element contains a CALDAV:is-not-
         defined XML element and no property of the type specified by
         the "name" attribute exists in the enclosing calendar
         component;

      or:

      *  The CALDAV:prop-filter XML element contains a CALDAV:time-range
         XML element and the property value overlaps the specified time
         range, and all specified CALDAV:param-filter child XML elements
         also match the targeted property;

      or:

      *  The CALDAV:prop-filter XML element contains a CALDAV:text-match
         XML element and the property value matches it, and all
         specified CALDAV:param-filter child XML elements also match the
         targeted property;

   Definition:

         <!ELEMENT prop-filter (is-not-defined |
                                ((time-range | text-match)?,
                                 param-filter*))>

         <!ATTLIST prop-filter name CDATA #REQUIRED>
         name value: a calendar property name (e.g., ATTENDEE)

9.7.3. CALDAV:param-filter XML Element

Name: param-filter Namespace: urn:ietf:params:xml:ns:caldav Purpose: Limits the search to specific parameter values. Description: The CALDAV:param-filter XML element specifies a query targeted at a specific calendar property parameter (e.g., PARTSTAT) in the scope of the calendar property on which it is
Top   ToC   RFC4791 - Page 88
      defined.  A calendar property parameter is said to match a CALDAV:
      param-filter if:

      *  The CALDAV:param-filter XML element is empty and a parameter of
         the type specified by the "name" attribute exists on the
         calendar property being examined;

      or:

      *  The CALDAV:param-filter XML element contains a CALDAV:is-not-
         defined XML element and no parameter of the type specified by
         the "name" attribute exists on the calendar property being
         examined;

   Definition:

         <!ELEMENT param-filter (is-not-defined | text-match?)>

         <!ATTLIST param-filter name CDATA #REQUIRED>
         name value: a property parameter name (e.g., PARTSTAT)

9.7.4. CALDAV:is-not-defined XML Element

Name: is-not-defined Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies that a match should occur if the enclosing component, property, or parameter does not exist. Description: The CALDAV:is-not-defined XML element specifies that a match occurs if the enclosing component, property, or parameter value specified in a calendaring REPORT request does not exist in the calendar data being tested. Definition: <!ELEMENT is-not-defined EMPTY>

9.7.5. CALDAV:text-match XML Element

Name: text-match Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies a substring match on a property or parameter value.
Top   ToC   RFC4791 - Page 89
   Description:  The CALDAV:text-match XML element specifies text used
      for a substring match against the property or parameter value
      specified in a calendaring REPORT request.

      The "collation" attribute is used to select the collation that the
      server MUST use for character string matching.  In the absence of
      this attribute, the server MUST use the "i;ascii-casemap"
      collation.

      The "negate-condition" attribute is used to indicate that this
      test returns a match if the text matches when the attribute value
      is set to "no", or return a match if the text does not match, if
      the attribute value is set to "yes".  For example, this can be
      used to match components with a STATUS property not set to
      CANCELLED.

   Definition:

         <!ELEMENT text-match (#PCDATA)>
         PCDATA value: string

         <!ATTLIST text-match collation        CDATA "i;ascii-casemap"
                              negate-condition (yes | no) "no">

9.8. CALDAV:timezone XML Element

Name: timezone Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies the time zone component to use when determining the results of a report. Description: The CALDAV:timezone XML element specifies that for a given calendaring REPORT request, the server MUST rely on the specified VTIMEZONE component instead of the CALDAV:calendar- timezone property of the calendar collection, in which the calendar object resource is contained to resolve "date" values and "date with local time" values (i.e., floating time) to "date with UTC time" values. The server will require this information to determine if a calendar component scheduled with "date" values or "date with local time" values intersects a CALDAV:time-range specified in a CALDAV:calendar-query REPORT. Note: The iCalendar data embedded within the CALDAV:timezone XML element MUST follow the standard XML character data encoding rules, including use of &lt;, &gt;, &amp; etc. entity encoding or the use of a <![CDATA[ ... ]]> construct. In the later case, the
Top   ToC   RFC4791 - Page 90
      iCalendar data cannot contain the character sequence "]]>", which
      is the end delimiter for the CDATA section.

   Definition:

         <!ELEMENT timezone (#PCDATA)>
         PCDATA value: an iCalendar object with exactly one VTIMEZONE

9.9. CALDAV:time-range XML Element

Name: time-range Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies a time range to limit the set of calendar components returned by the server. Description: The CALDAV:time-range XML element specifies that for a given calendaring REPORT request, the server MUST only return the calendar object resources that, depending on the context, have a component or property whose value intersects a specified time range. The "start" attribute specifies the inclusive start of the time range, and the "end" attribute specifies the non-inclusive end of the time range. Both attributes MUST be specified as "date with UTC time" value. Time ranges open at one end can be specified by including only one attribute; however, at least one attribute MUST always be present in the CALDAV:time-range element. If either the "start" or "end" attribute is not specified in the CALDAV:time- range XML element, assume "-infinity" and "+infinity" as their value, respectively. If both "start" and "end" are present, the value of the "end" attribute MUST be greater than the value of the "start" attribute. Time range tests MUST consider every recurrence instance when testing the time range condition; if any one instance matches, then the test returns true. Testing recurrence instances requires the server to infer an effective value for DTSTART, DTEND, DURATION, and DUE properties for an instance based on the recurrence patterns and any overrides. A VEVENT component overlaps a given time range if the condition for the corresponding component state specified in the table below is satisfied. Note that, as specified in [RFC2445], the DTSTART property is REQUIRED in the VEVENT component. The conditions depend on the presence of the DTEND and DURATION properties in the VEVENT component. Furthermore, the value of the DTEND property
Top   ToC   RFC4791 - Page 91
      MUST be later in time than the value of the DTSTART property.  The
      duration of a VEVENT component with no DTEND and DURATION
      properties is 1 day (+P1D) when the DTSTART is a DATE value, and 0
      seconds when the DTSTART is a DATE-TIME value.

      +---------------------------------------------------------------+
      | VEVENT has the DTEND property?                                |
      |   +-----------------------------------------------------------+
      |   | VEVENT has the DURATION property?                         |
      |   |   +-------------------------------------------------------+
      |   |   | DURATION property value is greater than 0 seconds?    |
      |   |   |   +---------------------------------------------------+
      |   |   |   | DTSTART property is a DATE-TIME value?            |
      |   |   |   |   +-----------------------------------------------+
      |   |   |   |   | Condition to evaluate                         |
      +---+---+---+---+-----------------------------------------------+
      | Y | N | N | * | (start <  DTEND AND end > DTSTART)            |
      +---+---+---+---+-----------------------------------------------+
      | N | Y | Y | * | (start <  DTSTART+DURATION AND end > DTSTART) |
      |   |   +---+---+-----------------------------------------------+
      |   |   | N | * | (start <= DTSTART AND end > DTSTART)          |
      +---+---+---+---+-----------------------------------------------+
      | N | N | N | Y | (start <= DTSTART AND end > DTSTART)          |
      +---+---+---+---+-----------------------------------------------+
      | N | N | N | N | (start <  DTSTART+P1D AND end > DTSTART)      |
      +---+---+---+---+-----------------------------------------------+

      A VTODO component is said to overlap a given time range if the
      condition for the corresponding component state specified in the
      table below is satisfied.  The conditions depend on the presence
      of the DTSTART, DURATION, DUE, COMPLETED, and CREATED properties
      in the VTODO component.  Note that, as specified in [RFC2445], the
      DUE value MUST be a DATE-TIME value equal to or after the DTSTART
      value if specified.
Top   ToC   RFC4791 - Page 92
   +-------------------------------------------------------------------+
   | VTODO has the DTSTART property?                                   |
   |   +---------------------------------------------------------------+
   |   |   VTODO has the DURATION property?                            |
   |   |   +-----------------------------------------------------------+
   |   |   | VTODO has the DUE property?                               |
   |   |   |   +-------------------------------------------------------+
   |   |   |   | VTODO has the COMPLETED property?                     |
   |   |   |   |   +---------------------------------------------------+
   |   |   |   |   | VTODO has the CREATED property?                   |
   |   |   |   |   |   +-----------------------------------------------+
   |   |   |   |   |   | Condition to evaluate                         |
   +---+---+---+---+---+-----------------------------------------------+
   | Y | Y | N | * | * | (start  <= DTSTART+DURATION)  AND             |
   |   |   |   |   |   | ((end   >  DTSTART)  OR                       |
   |   |   |   |   |   |  (end   >= DTSTART+DURATION))                 |
   +---+---+---+---+---+-----------------------------------------------+
   | Y | N | Y | * | * | ((start <  DUE)      OR  (start <= DTSTART))  |
   |   |   |   |   |   | AND                                           |
   |   |   |   |   |   | ((end   >  DTSTART)  OR  (end   >= DUE))      |
   +---+---+---+---+---+-----------------------------------------------+
   | Y | N | N | * | * | (start  <= DTSTART)  AND (end >  DTSTART)     |
   +---+---+---+---+---+-----------------------------------------------+
   | N | N | Y | * | * | (start  <  DUE)      AND (end >= DUE)         |
   +---+---+---+---+---+-----------------------------------------------+
   | N | N | N | Y | Y | ((start <= CREATED)  OR  (start <= COMPLETED))|
   |   |   |   |   |   | AND                                           |
   |   |   |   |   |   | ((end   >= CREATED)  OR  (end   >= COMPLETED))|
   +---+---+---+---+---+-----------------------------------------------+
   | N | N | N | Y | N | (start  <= COMPLETED) AND (end  >= COMPLETED) |
   +---+---+---+---+---+-----------------------------------------------+
   | N | N | N | N | Y | (end    >  CREATED)                           |
   +---+---+---+---+---+-----------------------------------------------+
   | N | N | N | N | N | TRUE                                          |
   +---+---+---+---+---+-----------------------------------------------+

      A VJOURNAL component overlaps a given time range if the condition
      for the corresponding component state specified in the table below
      is satisfied.  The conditions depend on the presence of the
      DTSTART property in the VJOURNAL component and on whether the
      DTSTART is a DATE-TIME or DATE value.  The effective "duration" of
      a VJOURNAL component is 1 day (+P1D) when the DTSTART is a DATE
      value, and 0 seconds when the DTSTART is a DATE-TIME value.
Top   ToC   RFC4791 - Page 93
      +----------------------------------------------------+
      | VJOURNAL has the DTSTART property?                 |
      |   +------------------------------------------------+
      |   | DTSTART property is a DATE-TIME value?         |
      |   |   +--------------------------------------------+
      |   |   | Condition to evaluate                      |
      +---+---+--------------------------------------------+
      | Y | Y | (start <= DTSTART)     AND (end > DTSTART) |
      +---+---+--------------------------------------------+
      | Y | N | (start <  DTSTART+P1D) AND (end > DTSTART) |
      +---+---+--------------------------------------------+
      | N | * | FALSE                                      |
      +---+---+--------------------------------------------+

      A VFREEBUSY component overlaps a given time range if the condition
      for the corresponding component state specified in the table below
      is satisfied.  The conditions depend on the presence in the
      VFREEBUSY component of the DTSTART and DTEND properties, and any
      FREEBUSY properties in the absence of DTSTART and DTEND.  Any
      DURATION property is ignored, as it has a special meaning when
      used in a VFREEBUSY component.

      When only FREEBUSY properties are used, each period in each
      FREEBUSY property is compared against the time range, irrespective
      of the type of free busy information (free, busy, busy-tentative,
      busy-unavailable) represented by the property.


      +------------------------------------------------------+
      | VFREEBUSY has both the DTSTART and DTEND properties? |
      |   +--------------------------------------------------+
      |   | VFREEBUSY has the FREEBUSY property?             |
      |   |   +----------------------------------------------+
      |   |   | Condition to evaluate                        |
      +---+---+----------------------------------------------+
      | Y | * | (start <= DTEND) AND (end > DTSTART)         |
      +---+---+----------------------------------------------+
      | N | Y | (start <  freebusy-period-end) AND           |
      |   |   | (end   >  freebusy-period-start)             |
      +---+---+----------------------------------------------+
      | N | N | FALSE                                        |
      +---+---+----------------------------------------------+

      A VALARM component is said to overlap a given time range if the
      following condition holds:

         (start <= trigger-time) AND (end > trigger-time)
Top   ToC   RFC4791 - Page 94
   A VALARM component can be defined such that it triggers repeatedly.
   Such a VALARM component is said to overlap a given time range if at
   least one of its triggers overlaps the time range.

      The calendar properties COMPLETED, CREATED, DTEND, DTSTAMP,
      DTSTART, DUE, and LAST-MODIFIED overlap a given time range if the
      following condition holds:

          (start <= date-time) AND (end > date-time)

   Note that if DTEND is not present in a VEVENT, but DURATION is, then
   the test should instead operate on the 'effective' DTEND, i.e.,
   DTSTART+DURATION.  Similarly, if DUE is not present in a VTODO, but
   DTSTART and DURATION are, then the test should instead operate on the
   'effective' DUE, i.e., DTSTART+DURATION.

      The semantic of CALDAV:time-range is not defined for any other
      calendar components and properties.

   Definition:

         <!ELEMENT time-range EMPTY>

         <!ATTLIST time-range start CDATA #IMPLIED
                              end   CDATA #IMPLIED>
         start value: an iCalendar "date with UTC time"
         end value: an iCalendar "date with UTC time"

9.10. CALDAV:calendar-multiget XML Element

Name: calendar-multiget Namespace: urn:ietf:params:xml:ns:caldav Purpose: CalDAV report used to retrieve specific calendar object resources. Description: See Section 7.9. Definition: <!ELEMENT calendar-multiget ((DAV:allprop | DAV:propname | DAV:prop)?, DAV:href+)>
Top   ToC   RFC4791 - Page 95

9.11. CALDAV:free-busy-query XML Element

Name: free-busy-query Namespace: urn:ietf:params:xml:ns:caldav Purpose: CalDAV report used to generate a VFREEBUSY to determine busy time over a specific time range. Description: See Section 7.10. Definition: <!ELEMENT free-busy-query (time-range)>

10. Internationalization Considerations

CalDAV allows internationalized strings to be stored and retrieved for the description of calendar collections (see Section 5.2.1). The CALDAV:calendar-query REPORT (Section 7.8) includes a text searching option controlled by the CALDAV:text-match element, and details of character handling are covered in the description of that element (see Section 9.7.5).

11. Security Considerations

HTTP protocol transactions are sent in the clear over the network unless protection from snooping is negotiated. This can be accomplished by use of TLS, as defined in [RFC2818]. In particular, HTTP Basic authentication MUST NOT be used unless TLS is in effect. Servers MUST take adequate precautions to ensure that malicious clients cannot consume excessive server resources (CPU, memory, disk, etc.) through carefully crafted reports. For example, a client could upload an event with a recurrence rule that specifies a recurring event occurring every second for the next 100 years, which would result in approximately 3 x 10^9 instances! A report that asks for recurrences to be expanded over that range would likely constitute a denial-of-service attack on the server. When creating new resources (including calendar collections), clients MUST ensure that the resource name (the last path segment of the resource URI) assigned to the new resource does not expose any data from within the iCalendar resource itself or information about the nature of a calendar collection. This is required to ensure that the presence of a specific iCalendar component or nature of components in a collection cannot be inferred based on the name of a resource.
Top   ToC   RFC4791 - Page 96
   When rolling up free-busy information, more information about a
   user's events is exposed if busy periods overlap or are adjacent
   (this tells the client requesting the free-busy information that the
   calendar owner has at least two events, rather than knowing only that
   the calendar owner has one or more events during the busy period).
   Thus, a conservative approach to calendar data privacy would have
   servers always coalesce such busy periods when they are the same
   type.

   Procedure alarms are a known security risk for either clients or
   servers to handle, particularly when the alarm was created by another
   agent.  Clients and servers are not required to execute such
   procedure alarms.

   Security considerations described in iCalendar [RFC2445] and iTIP
   [RFC2446] are also applicable to CalDAV.

   Beyond these, CalDAV does not raise any security considerations that
   are not present in HTTP [RFC2616] and WebDAV [RFC2518], [RFC3253],
   [RFC3744].

12. IANA Considerations

This document uses one new URN to identify a new XML namespace. The URN conforms to a registry mechanism described in [RFC3688].

12.1. Namespace Registration

Registration request for the CalDAV namespace: URI: urn:ietf:params:xml:ns:caldav Registrant Contact: See the "Authors' Addresses" section of this document. XML: None. Namespace URIs do not represent an XML specification.

13. Acknowledgements

The authors would like to thank the following individuals for contributing their ideas and support for writing this specification: Michael Arick, Mario Bonin, Chris Bryant, Scott Carr, Andre Courtemanche, Mike Douglass, Ted Hardie, Marten den Haring, Jeffrey Harris, Sam Hartman, Helge Hess, Jeff McCullough, Alexey Melnikov, Dan Mosedale, Brian Moseley, Francois Perrault, Kervin L. Pierre, Julian F. Reschke, Wilfredo Sanchez Vega, Mike Shaver, Jari Urpalainen, Simon Vaillancourt, and Jim Whitehead.
Top   ToC   RFC4791 - Page 97
   The authors would also like to thank the Calendaring and Scheduling
   Consortium for advice with this specification, and for organizing
   interoperability testing events to help refine it.

14. References

14.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2445] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998. [RFC2446] Silverberg, S., Mansour, S., Dawson, F., and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries", RFC 2446, November 1998. [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners- Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
Top   ToC   RFC4791 - Page 98
   [RFC3744]               Clemm, G., Reschke, J., Sedlar, E., and J.
                           Whitehead, "Web Distributed Authoring and
                           Versioning (WebDAV) Access Control Protocol",
                           RFC 3744, May 2004.

   [RFC4346]               Dierks, T. and E. Rescorla, "The Transport
                           Layer Security (TLS) Protocol Version 1.1",
                           RFC 4346, April 2006.

   [RFC4790]               Newman, C., Duerst, M., and A. Gulbrandsen,
                           "Internet Application Protocol Collation
                           Registry", RFC 4790, March 2007.

   [W3C.REC-xml-20060816]  Paoli, J., Maler, E., Yergeau, F., Sperberg-
                           McQueen, C., and T. Bray, "Extensible Markup
                           Language (XML) 1.0 (Fourth Edition)", World
                           Wide Web Consortium Recommendation REC-xml-
                           20060816, August 2006,
                           <http://www.w3.org/TR/2006/REC-xml-20060816>.

14.2. Informative References

[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998. [RFC2739] Small, T., Hennessy, D., and F. Dawson, "Calendar Attributes for vCard and LDAP", RFC 2739, January 2000. [RFC4331] Korver, B. and L. Dusseault, "Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections", RFC 4331, February 2006. [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006. [rfc2518bis] Dusseault, L., "HTTP Extensions for Distributed Authoring - WebDAV", Work in Progress, December 2006.
Top   ToC   RFC4791 - Page 99

Appendix A. CalDAV Method Privilege Table (Normative)

The following table extends the WebDAV Method Privilege Table specified in Appendix B of [RFC3744]. +------------+------------------------------------------------------+ | METHOD | PRIVILEGES | +------------+------------------------------------------------------+ | MKCALENDAR | DAV:bind | | REPORT | DAV:read or CALDAV:read-free-busy (on all referenced | | | resources) | +------------+------------------------------------------------------+

Appendix B. Calendar Collections Used in the Examples

This appendix shows the calendar object resources contained in the calendar collection queried in the examples throughout this document. The content of the calendar collection is being shown as if it were returned by a CALDAV:calendar-query REPORT request designed to return all the calendar data in the collection: >> Request << REPORT /bernard/work/ HTTP/1.1 Host: cal.example.com Depth: 1 Content-Type: application/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <C:calendar-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> <D:prop> <D:getetag/> <C:calendar-data/> </D:prop> <C:filter> <C:comp-filter name="VCALENDAR"/> </C:filter> </C:calendar-query> >> Response << HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
Top   ToC   RFC4791 - Page 100
   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:"
                 xmlns:C="urn:ietf:params:xml:ns:caldav">

     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd1.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd1"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTIMEZONE
   LAST-MODIFIED:20040110T032845Z
   TZID:US/Eastern
   BEGIN:DAYLIGHT
   DTSTART:20000404T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZNAME:EDT
   TZOFFSETFROM:-0500
   TZOFFSETTO:-0400
   END:DAYLIGHT
   BEGIN:STANDARD
   DTSTART:20001026T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZNAME:EST
   TZOFFSETFROM:-0400
   TZOFFSETTO:-0500
   END:STANDARD
   END:VTIMEZONE
   BEGIN:VEVENT
   DTSTAMP:20060206T001102Z
   DTSTART;TZID=US/Eastern:20060102T100000
   DURATION:PT1H
   SUMMARY:Event #1
   Description:Go Steelers!
   UID:74855313FA803DA593CD579A@example.com
   END:VEVENT
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>

     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
       <D:propstat>
Top   ToC   RFC4791 - Page 101
         <D:prop>
           <D:getetag>"fffff-abcd2"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTIMEZONE
   LAST-MODIFIED:20040110T032845Z
   TZID:US/Eastern
   BEGIN:DAYLIGHT
   DTSTART:20000404T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZNAME:EDT
   TZOFFSETFROM:-0500
   TZOFFSETTO:-0400
   END:DAYLIGHT
   BEGIN:STANDARD
   DTSTART:20001026T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZNAME:EST
   TZOFFSETFROM:-0400
   TZOFFSETTO:-0500
   END:STANDARD
   END:VTIMEZONE
   BEGIN:VEVENT
   DTSTAMP:20060206T001121Z
   DTSTART;TZID=US/Eastern:20060102T120000
   DURATION:PT1H
   RRULE:FREQ=DAILY;COUNT=5
   SUMMARY:Event #2
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   BEGIN:VEVENT
   DTSTAMP:20060206T001121Z
   DTSTART;TZID=US/Eastern:20060104T140000
   DURATION:PT1H
   RECURRENCE-ID;TZID=US/Eastern:20060104T120000
   SUMMARY:Event #2 bis
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>

     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
Top   ToC   RFC4791 - Page 102
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd3"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTIMEZONE
   LAST-MODIFIED:20040110T032845Z
   TZID:US/Eastern
   BEGIN:DAYLIGHT
   DTSTART:20000404T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZNAME:EDT
   TZOFFSETFROM:-0500
   TZOFFSETTO:-0400
   END:DAYLIGHT
   BEGIN:STANDARD
   DTSTART:20001026T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZNAME:EST
   TZOFFSETFROM:-0400
   TZOFFSETTO:-0500
   END:STANDARD
   END:VTIMEZONE
   BEGIN:VEVENT
   ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
   ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
   DTSTAMP:20060206T001220Z
   DTSTART;TZID=US/Eastern:20060104T100000
   DURATION:PT1H
   LAST-MODIFIED:20060206T001330Z
   ORGANIZER:mailto:cyrus@example.com
   SEQUENCE:1
   STATUS:TENTATIVE
   SUMMARY:Event #3
   UID:DC6C50A017428C5216A2F1CD@example.com
   END:VEVENT
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>

     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
       <D:propstat>
         <D:prop>
Top   ToC   RFC4791 - Page 103
           <D:getetag>"fffff-abcd4"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTODO
   DTSTAMP:20060205T235335Z
   DUE;VALUE=DATE:20060104
   STATUS:NEEDS-ACTION
   SUMMARY:Task #1
   UID:DDDEEB7915FA61233B861457@example.com
   BEGIN:VALARM
   ACTION:AUDIO
   TRIGGER;RELATED=START:-PT10M
   END:VALARM
   END:VTODO
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>

     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd5.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd5"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTODO
   DTSTAMP:20060205T235300Z
   DUE;VALUE=DATE:20060106
   LAST-MODIFIED:20060205T235308Z
   SEQUENCE:1
   STATUS:NEEDS-ACTION
   SUMMARY:Task #2
   UID:E10BA47467C5C69BB74E8720@example.com
   BEGIN:VALARM
   ACTION:AUDIO
   TRIGGER;RELATED=START:-PT10M
   END:VALARM
   END:VTODO
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
Top   ToC   RFC4791 - Page 104
     </D:response>

     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd6.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd6"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTODO
   COMPLETED:20051223T122322Z
   DTSTAMP:20060205T235400Z
   DUE;VALUE=DATE:20051225
   LAST-MODIFIED:20060205T235308Z
   SEQUENCE:1
   STATUS:COMPLETED
   SUMMARY:Task #3
   UID:E10BA47467C5C69BB74E8722@example.com
   END:VTODO
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>

     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd7.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd7"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTODO
   DTSTAMP:20060205T235600Z
   DUE;VALUE=DATE:20060101
   LAST-MODIFIED:20060205T235308Z
   SEQUENCE:1
   STATUS:CANCELLED
   SUMMARY:Task #4
   UID:E10BA47467C5C69BB74E8725@example.com
   END:VTODO
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
Top   ToC   RFC4791 - Page 105
       </D:propstat>
     </D:response>

     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd8.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd8"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VFREEBUSY
   ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com
   UID:76ef34-54a3d2@example.com
   DTSTAMP:20050530T123421Z
   DTSTART:20060101T000000Z
   DTEND:20060108T000000Z
   FREEBUSY:20050531T230000Z/20050601T010000Z
   FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z
   FREEBUSY:20060103T100000Z/20060103T120000Z
   FREEBUSY:20060104T100000Z/20060104T120000Z
   FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20060105T100000Z/20060105T120000Z
   FREEBUSY:20060106T100000Z/20060106T120000Z
   END:VFREEBUSY
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>

   </D:multistatus>
Top   ToC   RFC4791 - Page 106

Authors' Addresses

Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA EMail: cyrus@daboo.name URI: http://www.apple.com/ Bernard Desruisseaux Oracle Corporation 600 Blvd. de Maisonneuve West Suite 1900 Montreal, QC H3A 3J2 CANADA EMail: bernard.desruisseaux@oracle.com URI: http://www.oracle.com/ Lisa Dusseault CommerceNet 169 University Ave. Palo Alto, CA 94301 USA EMail: ldusseault@commerce.net URI: http://commerce.net/
Top   ToC   RFC4791 - Page 107
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.