tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4791

 
 
 

Calendaring Extensions to WebDAV (CalDAV)

Part 5 of 5, p. 77 to 107
Prev RFC Part

 


prevText      Top      Up      ToC       Page 77 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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.