2.2.3.67.1 Fetch (ItemOperations)
The Fetch element is an optional child element of the ItemOperations element in ItemOperations command requests and an optional child element of the Response element in ItemOperations responses. In both contexts, it retrieves an item from the server.
Elements referenced in this section are defined in the ItemOperations namespace, except where otherwise indicated by the presence of a namespace prefix (as defined in section 2.2.4).
|
Command request/response |
Parent elements |
Child elements |
Data type |
Number allowed |
|---|---|---|---|---|
|
ItemOperations command request (section 2.2.1.10) |
ItemOperations (section 2.2.3.94) |
Store (section 2.2.3.178.2) documentlibrary:LinkId (section 2.2.3.50) (optional) search:LongId (section 2.2.3.98.1) (optional) airsync:CollectionId (optional) (section 2.2.3.30.3) airsync:ServerId (optional) (section 2.2.3.166.7) Options (optional) (section 2.2.3.125.3) airsyncbase:FileReference (optional) (section 2.2.3.8) rm:RemoveRightsManagementProtection ([MS-ASRM] section 2.2.2.11) |
container ([MS-ASDTYPE] section 2.2) |
0...N (optional) |
|
ItemOperations command response |
Response (section 2.2.3.153.4) |
documentlibrary:LinkId (optional) search:LongId (optional) airsync:CollectionId (optional) airsync:ServerId (optional) Status (section 2.2.3.177.8) airsync:Class (optional) (section 2.2.3.27.3) airsyncbase:FileReference (optional) Properties (optional) (section 2.2.3.139.2) |
container |
0...N (optional) |
The fetch operation is intended to be used on Windows SharePoint Services technology or UNC document metadata, search results, and items and attachments.
Because the ItemOperations response potentially contains large amounts of binary data, this protocol enables the client to choose a delivery method that is most efficient for its implementation by providing the following two methods to deliver content that is requested by the Fetch element:
Inline—The binary content is encoded with base64 encoding and is included inside the WBXML.
Multipart—This method involves a multipart structure in which the WBXML is the first part, and the requested data populates the subsequent parts. This format enables a client to handle large files without consuming large amounts of memory.
The inline approach generally requires the client to read the WBXML part into memory in order to parse it, thereby consuming a large amount of memory. The multipart approach enables the client to parse the small WBXML part, obtain references to the binary parts, and handle the binary parts as necessary, without reading the whole response into memory.
In the request, the client specifies the location and a byte range for the item. The location is indicated by either a link ID (documentlibrary:LinkId element) if the target item is identified by a URI, or a file reference (airsyncbase:FileReference element (section 2.2.3.8)) if the client is retrieving an email attachment. The location is indicated by a server ID (airsync:ServerId element) if an ActiveSync ID is being used to identify the item.
The Fetch element supports several options, such as byte ranges, body preference, and schema, as specified in section 2.2.3.125.3.
The ItemOperations command response contains either the requested byte range of the item, or an error code that indicates why the fetch failed.
Multiple fetch operations can be included within one ItemOperations request. In this case, the fetch operations are executed in the order that is specified.
For more information about the Fetch element, see section 2.2.1.10.1.
Protocol Versions
The following table specifies the protocol versions that support this element. The client indicates the protocol version being used by setting either the MS-ASProtocolVersion header, as specified in [MS-ASHTTP] section 2.2.1.1.2.6, or the Protocol version field, as specified in [MS-ASHTTP] section 2.2.1.1.1.1, in the request.
|
Protocol version |
Element support |
|---|---|
|
2.5 |
|
|
12.0 |
Yes |
|
12.1 |
Yes |
|
14.0 |
Yes |
|
14.1 |
Yes |
|
16.0 |
Yes |
|
16.1 |
Yes |