Difference between revisions of "DAV/Methods/POST/REQUEST"

From Davical
< DAV‎ | Methods‎ | POST
Jump to navigationJump to search
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
The {{Schedule RFC}} defines two forms of POST request which apply to the [[DAV/Resourcetypes/schedule-outbox|schedule-outbox]] [[DAV/Resourcetypes/collection|collection]] of a [[DAV/Resourcetypes/principal|principal]].
+
The {{CalDAV Scheduling RFC}} defines two forms of POST request which apply to the [[DAV/Resourcetypes/schedule-outbox|schedule-outbox]] [[DAV/Resourcetypes/collection|collection]] of a [[DAV/Resourcetypes/principal|principal]].
  
 
== REQUEST ==
 
== REQUEST ==
Line 11: Line 11:
 
Allows clients to ask for the information they have regarding the status of an event be brought up-to-date with the current canonical information from the event organiser.
 
Allows clients to ask for the information they have regarding the status of an event be brought up-to-date with the current canonical information from the event organiser.
  
== Specification (from draft-schedule-05) ==
+
== Specification (from draft-schedule-08) ==
The POST method submits a scheduling or freebusy message to one or
+
7.  Request for Busy Time Information
more recipients by targeting the request at the URI of a scheduling
 
Outbox collectionThe request body of a POST method MUST contain a
 
scheduling message or freebusy message (e.g., an iCalendar object
 
that follows the iTIP semantic).  The resource identified by the
 
Request-URI MUST be a resource collection of type CALDAV:schedule-
 
outbox (Section 3.1.2).
 
  
Only specific types of scheduling message are allowed in a POST
+
The POST method is used to request busy time information of one or
request on a scheduling Outbox collection:
+
more Calendar Users by targeting the request at a scheduling Outbox
 +
collection.  The request body of a POST method MUST contain a
 +
"VFREEBUSY" calendar component with the "METHOD" iCalendar property
 +
set to the value "REQUEST" as specified in Section 3.3.2 of iTIP
 +
[I-D.ietf-calsify-2446bis].  The resource identified by the Request-
 +
URI MUST be a resource collection of type CALDAV:schedule-outbox
 +
(Section 4.1).
  
          +----------------+---------------------------------+
+
7.1.  Status Codes
          | iTIP METHOD    | COMPONENT                      |
 
          +----------------+---------------------------------+
 
          | PUBLISH        | None                            |
 
          | REQUEST        | VFREEBUSY                      |
 
          | REPLY          | None                            |
 
          | ADD            | None                            |
 
          | CANCEL        | None                            |
 
          | REFRESH        | Any except VTIMEZONE, VFREEBUSY |
 
          | COUNTER        | None                            |
 
          | DECLINECOUNTER | None                            |
 
          +----------------+---------------------------------+
 
  
Servers SHOULD reject any scheduling message that is not allowed.
+
The following are examples of response codes one would expect to be
However, for backwards compatibility with earlier version of this
+
used for this method.  Note, however, that unless explicitly
specification, servers MAY return a valid schedule response result
+
prohibited any 2/3/4/5xx series response code may be used in a
indicating success for the iTIP operation being executed.
+
response.
  
  Preconditions:
+
* 200 (OK) - The command succeeded.
 +
* 204 (No Content) - The command succeeded.
 +
* 400 (Bad Request) - The client has provided an invalid scheduling message.
 +
* 403 (Forbidden) - The client cannot submit a scheduling message to the specified Request-URI.
 +
* 404 (Not Found) - The URL in the Request-URI was not present.
 +
* 423 (Locked) - The specified resource is locked and the client either is not a lock owner or the lock type requires a lock token to be submitted and the client did not submit it.
  
      (CALDAV:supported-collection): The Request-URI MUST identify the
+
7.2.  Additional Method Preconditions
      location of a scheduling Outbox collection;
 
  
      (CALDAV:supported-calendar-data): The resource submitted in the
+
This specification defines additional method preconditions for the
      POST request MUST be a supported media type (e.g., "text/
+
POST method. Preconditions defined in WebDAV ACL [RFC3744] and
      calendar") for scheduling or freebusy messages;
+
CalDAV [RFC4791] that applies to the POST method are also listed here
 +
for completeness.
  
      (CALDAV:valid-calendar-data): The resource submitted in the POST
+
7.2.1.  DAV:need-privileges Precondition
      request MUST be valid data for the media type being specified
 
      (e.g., valid iCalendar object);
 
  
      (CALDAV:valid-scheduling-message): The resource submitted in the
+
Name: need-privileges
      POST request MUST obey all restrictions specified for the POST
 
      request (e.g., the scheduling message follows the restrictions of
 
      iTIP);
 
  
      (CALDAV:originator-allowed): The currently authenticated user MUST
+
Namespace: DAV:
      be granted the CALDAV:schedule-deliver privilege or a suitable
 
      sub-privilege on the scheduling Outbox collection being targeted
 
      by the request;
 
  
      (CALDAV:organizer-allowed): The calendar user identified by the
+
Apply to: POST
      "ORGANIZER" property in the POST request's scheduling message MUST
 
      be the calendar user (or one of the calendar users) associated
 
      with the scheduling Outbox collection being targeted by the
 
      request when the scheduling message is an outgoing scheduling
 
      message;
 
  
      (CALDAV:max-resource-size): The resource submitted in the POST
+
Use with: 403 Forbidden
      request MUST have an octet size less than or equal to the value of
 
      the CALDAV:max-resource-size property value [RFC4791]on the
 
      scheduling Outbox collection targeted by the request;
 
  
      (CALDAV:attachments-allowed): The resource submitted in the POST
+
Purpose:  (precondition) -- The currently authenticated user MUST be
      request MUST NOT contain any inline ATTACH properties;
+
granted the CALDAV:schedule-send or CALDAV:schedule-send-freebusy
 +
privilege on the scheduling Outbox collection being targeted by
 +
the request.
  
  Postconditions: None
+
Definition:
  
8.1.1. Handling a REFRESH
+
  <!ELEMENT DAV:need-privileges (DAV:resource)* >
 +
<!ELEMENT DAV:resource (DAV:href, DAV:privilege) >
  
  When an iTIP REFRESH scheduling message is executed, the server
+
Example:
  delivers the scheduling message to the calendar user specified by the
 
  "ORGANIZER" property value in the scheduling object resource that was
 
  POST'ed.
 
  
 +
<D:need-privileges xmlns:D="DAV:"
 +
                    xmlns:C="urn:ietf:params:xml:ns:caldav"/>
 +
  <D:resource>
 +
  <D:href>/home/bernard/calendars/outbox/</D:href>
 +
  <D:privilege><C:schedule-send-freebusy/></D:privilege>
 +
  </D:resource>
 +
</D:need-privileges>
  
8.1.2.  Response to a POST request
+
7.2.2.  CALDAV:supported-collection Precondition
  
  A POST request may deliver a scheduling message to one or more
+
Name: supported-collection
  calendar user recipients. Since the behavior of each recipient may
 
  vary, it is useful to get response status information for each
 
  recipient in the overall POST response.  This specification defines a
 
  new XML response to convey multiple recipient status.
 
  
  A response to a POST method that indicates status for one or more
+
Namespaceurn:ietf:params:xml:ns:caldav
  recipients MUST be a CALDAV:schedule-response XML element. This MUST
 
  contain one or more CALDAV:response elements for each recipient, with
 
  each of those containing elements that indicate which recipient they
 
  correspond to, the scheduling status of the request for that
 
  recipient, any error codes and an optional description.  See
 
  Section 11.1.
 
  
  In the case of a freebusy request, the CALDAV:response elements can
+
Apply to: POST
  also contain CALDAV:calendar-data elements which contain freebusy
 
  information (e.g., an iCalendar VFREEBUSY component) indicating the
 
  busy state of the corresponding recipient, assuming that the freebusy
 
  request for that recipient succeeded.
 
  
8.1.3. Status Codes for use with the POST method
+
Use with: 400 Bad Request
  
  The following are examples of response codes one would expect to be
+
Purpose:  (precondition) -- The Request-URI MUST identify the
  used for this method.  Note, however, that unless explicitly
+
location of a scheduling Outbox collection.
  prohibited any 2/3/4/5xx series response code may be used in a
 
  response.
 
  
      200 (OK) - The command succeeded.
+
Definition:
  
      201 (Created) - The command succeeded and a new resource was
+
<!ELEMENT supported-collection EMPTY >
      created in the scheduling Outbox collection.
 
  
      400 (Bad Request) - The client has provided an invalid scheduling
+
Example:
      message.
 
  
      403 (Forbidden) - The client cannot submit a scheduling message to
+
<C:supported-collection xmlns:C="urn:ietf:params:xml:ns:caldav"/>
      the specified Request-URI.
 
  
      404 (Not Found) - The URL in the Request-URI was not present.
+
7.2.3.  CALDAV:supported-calendar-data Precondition
  
      423 (Locked) - The specified resource is locked and the client
+
Name:  supported-calendar-data
      either is not a lock owner or the lock type requires a lock token
 
      to be submitted and the client did not submit it.
 
  
      507 (Insufficient Storage) - The server did not have sufficient
+
Namespace:  urn:ietf:params:xml:ns:caldav
      space to record the scheduling message in a scheduling Outbox
 
      collection being targeted by the POST request.
 
  
8.1.4. Example - Simple meeting invitation refresh
+
Apply to: POST
  
  >> Request <<
+
Use with:  400 Bad Request
  
  POST /bernard/calendar/outbox/ HTTP/1.1
+
Purpose:  (precondition) -- The resource body submitted in the POST
  Host: cal.example.com
+
request MUST be a supported media type (e.g., text/calendar).
  Content-Type: text/calendar
 
  Content-Length: xxxx
 
  
  BEGIN:VCALENDAR
+
Definition:
  VERSION:2.0
 
  PRODID:-//Example Corp.//CalDAV Client//EN
 
  METHOD:REFRESH
 
  BEGIN:VEVENT
 
  UID:43777-876@example.com
 
  DTSTAMP:20040901T200200Z
 
  ORGANIZER:mailto:lisa@example.com
 
  ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
 
    Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr
 
    uisseaux:mailto:bernard@example.com
 
  END:VEVENT
 
  END:VCALENDAR
 
  
  >> Response <<
+
<!ELEMENT supported-calendar-data EMPTY >
  
  HTTP/1.1 200 OK
+
Example:
  Date: Thu, 02 Sep 2004 16:53:32 GMT
 
  Content-Type: application/xml; charset="utf-8"
 
  Content-Length: xxxx
 
  
  <?xml version="1.0" encoding="utf-8" ?>
+
<C:supported-calendar-data xmlns:C="urn:ietf:params:xml:ns:caldav"/>
  <C:schedule-response xmlns:D="DAV:"
 
                xmlns:C="urn:ietf:params:xml:ns:caldav">
 
  <C:response>
 
    <C:recipient>mailto:lisa@example.com</C:recipient>
 
    <C:request-status>2.0;Success</C:request-status>
 
    <D:responsedescription>Delivered to recipient
 
    scheduling inbox</D:responsedescription>
 
  </C:response>
 
  </C:schedule-response>
 
  
  In this example, the client requests the server to deliver a
+
7.2.4CALDAV:valid-calendar-data Precondition
  "REFRESH" scheduling message to the "Organizer" of the meeting
 
  mailto:lisa@example.comThe response indicates that delivery to the
 
  relevant scheduling Inbox collection of the "Organizer" was
 
  accomplished successfully.
 
  
 +
Name:  valid-calendar-data
  
8.1.5. Example - Freebusy lookup
+
Namespace: urn:ietf:params:xml:ns:caldav
  
  >> Request <<
+
Apply to:  POST
  
  POST /lisa/calendar/outbox/ HTTP/1.1
+
Use with: 400 Bad Request
  Host: cal.example.com
 
  Content-Type: text/calendar
 
  Content-Length: xxxx
 
  
  BEGIN:VCALENDAR
+
Purpose: (precondition) -- The resource submitted in the POST
  VERSION:2.0
+
request MUST be valid data for the media type being specified
  PRODID:-//Example Corp.//CalDAV Client//EN
+
(e.g., a valid iCalendar object).
  METHOD:REQUEST
 
  BEGIN:VFREEBUSY
 
  DTSTAMP:20040901T200200Z
 
  ORGANIZER:mailto:lisa@example.com
 
  DTSTART:20040902T000000Z
 
  DTEND:20040903T000000Z
 
  UID:34222-232@example.com
 
  ATTENDEE;CN=Bernard Desruisseaux:mailto:bernard@
 
    example.com
 
  ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.com
 
  END:VFREEBUSY
 
  END:VCALENDAR
 
  
  >> Response <<
+
Definition:
  
  HTTP/1.1 200 OK
+
<!ELEMENT valid-calendar-data EMPTY>
  Date: Thu, 02 Sep 2004 16:53:32 GMT
 
  Content-Type: application/xml; charset="utf-8"
 
  Content-Length: xxxx
 
  
  <?xml version="1.0" encoding="utf-8" ?>
+
Example:
  <C:schedule-response xmlns:D="DAV:"
 
                xmlns:C="urn:ietf:params:xml:ns:caldav">
 
  <C:response>
 
    <C:recipient>mailto:bernard@example.com</C:recipient>
 
    <C:request-status>2.0;Success</C:request-status>
 
    <C:calendar-data>BEGIN:VCALENDAR
 
  VERSION:2.0
 
  PRODID:-//Example Corp.//CalDAV Server//EN
 
  METHOD:REPLY
 
  BEGIN:VFREEBUSY
 
  DTSTAMP:20040901T200200Z
 
  ORGANIZER:mailto:lisa@example.com
 
  DTSTART:20040902T000000Z
 
  DTEND:20040903T000000Z
 
  UID:34222-232@example.com
 
  ATTENDEE;CN=Bernard Desruisseaux:mailto:bernard@
 
    example.com
 
  FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/
 
    20040902T090000Z,20040902T170000Z/20040903T000000Z
 
  END:VFREEBUSY
 
  END:VCALENDAR
 
  </C:calendar-data>
 
  </C:response>
 
  <C:response>
 
    <C:recipient>mailto:cyrus@example.com</C:recipient>
 
    <C:request-status>2.0;Success</C:request-status>
 
    <C:calendar-data>BEGIN:VCALENDAR
 
  VERSION:2.0
 
  PRODID:-//Example Corp.//CalDAV Server//EN
 
  METHOD:REPLY
 
  BEGIN:VFREEBUSY
 
  DTSTAMP:20040901T200200Z
 
  ORGANIZER:mailto:lisa@example.com
 
  DTSTART:20040902T000000Z
 
  DTEND:20040903T000000Z
 
  UID:34222-232@example.com
 
  ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.com
 
  FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/
 
    20040902T090000Z,20040902T170000Z/20040903T000000Z
 
  FREEBUSY;FBTYPE=BUSY:20040902T120000Z/20040902T130000Z
 
  END:VFREEBUSY
 
  END:VCALENDAR
 
  </C:calendar-data>
 
  </C:response>
 
  </C:schedule-response>
 
  
  In this example, the client requests the server to determine the busy
+
<C:valid-calendar-data xmlns:C="urn:ietf:params:xml:ns:caldav"/>
  information of the calendar users mailto:bernard@example.com and
+
 
  mailto:cyrus@example.com, over the time range specified by the
+
7.2.5.  CALDAV:valid-scheduling-message Precondition
  scheduling message sent in the requestThe response includes
+
 
  "VFREEBUSY" components for each of those calendar users with their
+
Name:  valid-scheduling-message
  busy time indicated.
+
 
 +
Namespace:  urn:ietf:params:xml:ns:caldav
 +
 
 +
Apply to:  POST
 +
 
 +
Use with:  400 Bad Request
 +
 
 +
Purpose:  (precondition) -- The resource submitted in the POST
 +
request MUST obey all restrictions specified for the POST request
 +
(e.g., the scheduling message follow the restrictions of iTIP).
 +
 
 +
Definition:
 +
 
 +
<!ELEMENT valid-scheduling-message EMPTY >
 +
 
 +
Example:
 +
 
 +
<C:valid-scheduling-message
 +
    xmlns:C="urn:ietf:params:xml:ns:caldav"/>
 +
 
 +
7.2.6.  CALDAV:organizer-allowed Precondition
 +
 
 +
Name:  organizer-allowed
 +
 
 +
Namespace:  urn:ietf:params:xml:ns:caldav
 +
 
 +
Apply to:  POST
 +
 
 +
Use with:  409 Conflict
 +
 
 +
Purpose:  (precondition) -- The Calendar User identified by the
 +
"ORGANIZER" property in the POST request's scheduling message MUST
 +
be the Calendar User (or one of the Calendar Users) associated
 +
with the scheduling Outbox collection being targeted by the
 +
request;
 +
 
 +
Definition:
 +
 
 +
<!ELEMENT organizer-allowed EMPTY >
 +
 
 +
Example:
 +
 
 +
<C:organizer-allowed xmlns:C="urn:ietf:params:xml:ns:caldav"/>
 +
 
 +
7.2.7. CALDAV:max-resource-size Precondition
 +
 
 +
Name:  max-resource-size
 +
 
 +
Namespace:  urn:ietf:params:xml:ns:caldav
 +
 
 +
Apply to:  POST
 +
 
 +
Use with:  403 Forbidden
 +
 
 +
Purpose:  (precondition) -- The resource submitted in the POST
 +
request MUST have a size in octets less than or equal to the value
 +
of the CALDAV:max-resource-size property (defined in Section 5.2.5
 +
of [RFC4791]) specified on the scheduling Outbox collection
 +
targeted by the request.
 +
 
 +
Definition:
 +
 
 +
<!ELEMENT max-resource-size EMPTY >
 +
 
 +
Example:
 +
 
 +
<C:max-resource-size xmlns:C="urn:ietf:params:xml:ns:caldav"/>
 +
 
 +
7.3.  Response to a POST request
 +
 
 +
A POST request may deliver a scheduling message to one or more
 +
Calendar Users.  Since the behavior of each recipient may vary, it is
 +
useful to get response status information for each recipient in the
 +
overall POST responseThis specification defines a new XML response
 +
to convey multiple recipient status.
 +
 
 +
A response to a POST method that indicates status for one or more
 +
recipients MUST be a CALDAV:schedule-response XML element.  This MUST
 +
contain one or more CALDAV:response elements for each recipient, with
 +
each of those containing elements that indicate which recipient they
 +
correspond to, the scheduling status for that recipient, any error
 +
codes and an optional description.  See Section 14.1.
 +
 
 +
In the case of a freebusy request, the CALDAV:response elements can
 +
also contain CALDAV:calendar-data elements which contain freebusy
 +
information (e.g., an iCalendar VFREEBUSY component) indicating the
 +
busy state of the corresponding recipient, assuming that the freebusy
 +
request for that recipient succeeded.  See Appendix B.5 for an
 +
example freebusy request and response.

Latest revision as of 09:46, 14 November 2009

The CalDAV Scheduling Extensions to WebDAV (RFC6638) defines two forms of POST request which apply to the schedule-outbox collection of a principal.

REQUEST

The iTIP request method allows clients to request free/busy information related to a principal for a period of time.

The response-status element should contain codes in line with the iTIP REQUEST-STATUS element.

REFRESH

Allows clients to ask for the information they have regarding the status of an event be brought up-to-date with the current canonical information from the event organiser.

Specification (from draft-schedule-08)

7. Request for Busy Time Information

The POST method is used to request busy time information of one or more Calendar Users by targeting the request at a scheduling Outbox collection. The request body of a POST method MUST contain a "VFREEBUSY" calendar component with the "METHOD" iCalendar property set to the value "REQUEST" as specified in Section 3.3.2 of iTIP [I-D.ietf-calsify-2446bis]. The resource identified by the Request- URI MUST be a resource collection of type CALDAV:schedule-outbox (Section 4.1).

7.1. Status Codes

The following are examples of response codes one would expect to be used for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a response.

  • 200 (OK) - The command succeeded.
  • 204 (No Content) - The command succeeded.
  • 400 (Bad Request) - The client has provided an invalid scheduling message.
  • 403 (Forbidden) - The client cannot submit a scheduling message to the specified Request-URI.
  • 404 (Not Found) - The URL in the Request-URI was not present.
  • 423 (Locked) - The specified resource is locked and the client either is not a lock owner or the lock type requires a lock token to be submitted and the client did not submit it.

7.2. Additional Method Preconditions

This specification defines additional method preconditions for the POST method. Preconditions defined in WebDAV ACL [RFC3744] and CalDAV [RFC4791] that applies to the POST method are also listed here for completeness.

7.2.1. DAV:need-privileges Precondition

Name: need-privileges

Namespace: DAV:

Apply to: POST

Use with: 403 Forbidden

Purpose: (precondition) -- The currently authenticated user MUST be granted the CALDAV:schedule-send or CALDAV:schedule-send-freebusy privilege on the scheduling Outbox collection being targeted by the request.

Definition:

<!ELEMENT DAV:need-privileges (DAV:resource)* >
<!ELEMENT DAV:resource (DAV:href, DAV:privilege) >

Example:

<D:need-privileges xmlns:D="DAV:"
                   xmlns:C="urn:ietf:params:xml:ns:caldav"/>
 <D:resource>
  <D:href>/home/bernard/calendars/outbox/</D:href>
  <D:privilege><C:schedule-send-freebusy/></D:privilege>
 </D:resource>
</D:need-privileges>

7.2.2. CALDAV:supported-collection Precondition

Name: supported-collection

Namespace: urn:ietf:params:xml:ns:caldav

Apply to: POST

Use with: 400 Bad Request

Purpose: (precondition) -- The Request-URI MUST identify the location of a scheduling Outbox collection.

Definition:

<!ELEMENT supported-collection EMPTY >

Example:

<C:supported-collection xmlns:C="urn:ietf:params:xml:ns:caldav"/>

7.2.3. CALDAV:supported-calendar-data Precondition

Name: supported-calendar-data

Namespace: urn:ietf:params:xml:ns:caldav

Apply to: POST

Use with: 400 Bad Request

Purpose: (precondition) -- The resource body submitted in the POST request MUST be a supported media type (e.g., text/calendar).

Definition:

<!ELEMENT supported-calendar-data EMPTY >

Example:

<C:supported-calendar-data xmlns:C="urn:ietf:params:xml:ns:caldav"/>

7.2.4. CALDAV:valid-calendar-data Precondition

Name: valid-calendar-data

Namespace: urn:ietf:params:xml:ns:caldav

Apply to: POST

Use with: 400 Bad Request

Purpose: (precondition) -- The resource submitted in the POST request MUST be valid data for the media type being specified (e.g., a valid iCalendar object).

Definition:

<!ELEMENT valid-calendar-data EMPTY>

Example:

<C:valid-calendar-data xmlns:C="urn:ietf:params:xml:ns:caldav"/>

7.2.5. CALDAV:valid-scheduling-message Precondition

Name: valid-scheduling-message

Namespace: urn:ietf:params:xml:ns:caldav

Apply to: POST

Use with: 400 Bad Request

Purpose: (precondition) -- The resource submitted in the POST request MUST obey all restrictions specified for the POST request (e.g., the scheduling message follow the restrictions of iTIP).

Definition:

<!ELEMENT valid-scheduling-message EMPTY >

Example:

<C:valid-scheduling-message
   xmlns:C="urn:ietf:params:xml:ns:caldav"/>

7.2.6. CALDAV:organizer-allowed Precondition

Name: organizer-allowed

Namespace: urn:ietf:params:xml:ns:caldav

Apply to: POST

Use with: 409 Conflict

Purpose: (precondition) -- The Calendar User identified by the "ORGANIZER" property in the POST request's scheduling message MUST be the Calendar User (or one of the Calendar Users) associated with the scheduling Outbox collection being targeted by the request;

Definition:

<!ELEMENT organizer-allowed EMPTY >

Example:

<C:organizer-allowed xmlns:C="urn:ietf:params:xml:ns:caldav"/>

7.2.7. CALDAV:max-resource-size Precondition

Name: max-resource-size

Namespace: urn:ietf:params:xml:ns:caldav

Apply to: POST

Use with: 403 Forbidden

Purpose: (precondition) -- The resource submitted in the POST request MUST have a size in octets less than or equal to the value of the CALDAV:max-resource-size property (defined in Section 5.2.5 of [RFC4791]) specified on the scheduling Outbox collection targeted by the request.

Definition:

<!ELEMENT max-resource-size EMPTY >

Example:

<C:max-resource-size xmlns:C="urn:ietf:params:xml:ns:caldav"/>

7.3. Response to a POST request

A POST request may deliver a scheduling message to one or more Calendar Users. Since the behavior of each recipient may vary, it is useful to get response status information for each recipient in the overall POST response. This specification defines a new XML response to convey multiple recipient status.

A response to a POST method that indicates status for one or more recipients MUST be a CALDAV:schedule-response XML element. This MUST contain one or more CALDAV:response elements for each recipient, with each of those containing elements that indicate which recipient they correspond to, the scheduling status for that recipient, any error codes and an optional description. See Section 14.1.

In the case of a freebusy request, the CALDAV:response elements can also contain CALDAV:calendar-data elements which contain freebusy information (e.g., an iCalendar VFREEBUSY component) indicating the busy state of the corresponding recipient, assuming that the freebusy request for that recipient succeeded. See Appendix B.5 for an example freebusy request and response.