General requirements

Manifest handling

Validity of the manifest

A valid manifest MUST be conform to the manifest schema. Even a CID extension CAN NOT require an improper manifest.

Server exposition

The manifest MUST be accessible through a single unauthenticated HTTP GET request.

Client retrieving

The downloading of the manifest is the first step of the transaction. The client MUST download a new manifest at the beginning of each process.

Process and transport selection

Once the manifest is downloaded by the client, this one MUST select one process and one transport to complete the transaction.

Default behavior

A manifest defines a list of processes and a list of transports. By default, all the processes MUST be compatible with any of the transports, which mean that all the transports MUST defines all the requests defined in the processes (webExchange, webUpload and webInteract).

ExampleExample

Lets consider a manifest that contains two processes defined as following :

1
<cid:process>
2
    <cid:label>Upload with post interation</cid:label>
3
    <cid:upload url="http://example.com/upload" required="true"/>
4
    <cid:interact url="http://example.com/interact" required="true"/>
5
</cid:process> 
6
<cid:process>
7
<cid:label>Direct upload</cid:label>
8
<cid:upload url="http://example.com/upload" required="true"/>
9
</cid:process>

All the transports of the manifest MUST defines one or more webUload requests AND one or more webInteract requests.

Therefore, the following manifest is valid :

1
<?xml version="1.0" encoding="UTF-8"?>
2
<cid:manifest xmlns:cid="http://www.cid-protocol.org/schema/v1/core">
3
    <cid:process>
4
        <cid:label>Upload with post interation</cid:label>
5
        <cid:upload url="http://example.com/upload" required="true"/>
6
        <cid:interact url="http://example.com/interact" required="true"/>
7
    </cid:process>
8
    <cid:process>
9
        <cid:label>Direct upload</cid:label>
10
        <cid:upload url="http://example.com/upload" required="true"/>
11
    </cid:process>
12
13
    <cid:transports>
14
        <cid:webTransport>
15
            <cid:authentications>
16
                <cid:basicHttp/>
17
            </cid:authentications>
18
19
            <cid:webInteract>
20
                <request method="GET" properties="header queryString"/>
21
                <request method="POST;application/x-www-form-urlencoded" properties="queryString header post"/>
22
                <request method="POST;multipart/form-data" properties="header queryString post"/>
23
            </cid:webInteract>
24
25
            <cid:webUpload>
26
                <request method="PUT" properties="header queryString"/>
27
                <request method="POST" properties="header queryString"/>
28
                <request method="POST;multipart/form-data" properties="header queryString post"/>
29
            </cid:webUpload>
30
        </cid:webTransport>
31
    </cid:transports>
32
</cid:manifest>

And the following one is not valid.

1
<?xml version="1.0" encoding="UTF-8"?>
2
<cid:manifest xmlns:cid="http://www.cid-protocol.org/schema/v1/core">
3
    <cid:process>
4
        <cid:label>Upload with post interation</cid:label>
5
        <cid:upload url="http://example.com/upload" required="true"/>
6
        <cid:interact url="http://example.com/interact" required="true"/>
7
    </cid:process>
8
    <cid:process>
9
        <cid:label>Direct upload</cid:label>
10
        <cid:upload url="http://example.com/upload" required="true"/>
11
    </cid:process>
12
13
    <cid:transports>
14
        <cid:webTransport>
15
            <cid:authentications>
16
                <cid:basicHttp/>
17
            </cid:authentications>
18
19
            <cid:webInteract>
20
                <request method="GET" properties="header queryString"/>
21
                <request method="POST;application/x-www-form-urlencoded" properties="queryString header post"/>
22
                <request method="POST;multipart/form-data" properties="header queryString post"/>
23
            </cid:webInteract>
24
25
            <cid:webUpload>
26
                <request method="PUT" properties="header queryString"/>
27
                <request method="POST" properties="header queryString"/>
28
                <request method="POST;multipart/form-data" properties="header queryString post"/>
29
            </cid:webUpload>
30
        </cid:webTransport>
31
32
        <cid:webTransport>
33
            <cid:authentications>
34
                <cid:basicHttp/>
35
            </cid:authentications>
36
37
            <cid:webUpload>
38
                <request method="PUT" properties="header queryString"/>
39
                <request method="POST" properties="header queryString"/>
40
                <request method="POST;multipart/form-data" properties="header queryString post"/>
41
            </cid:webUpload>
42
        </cid:webTransport>
43
    </cid:transports>
44
</cid:manifest>

Transport id

All the transports definition could include an id attribute. This id could be called in the transports attribute of a process to restrain the compatibility to one or more specific transports definition.

Example

With an id and transports attributes, the previously not valid manifest could be restrained as following.

1
<?xml version="1.0" encoding="UTF-8"?>
2
<cid:manifest xmlns:cid="http://www.cid-protocol.org/schema/v1/core">
3
    <cid:process transports="myTransportId">
4
        <cid:label>Upload with post interation</cid:label>
5
        <cid:upload url="http://example.com/upload" required="true"/>
6
        <cid:interact url="http://example.com/interact" required="true"/>
7
    </cid:process>
8
    <cid:process>
9
        <cid:label>Direct upload</cid:label>
10
        <cid:upload url="http://example.com/upload" required="true"/>
11
    </cid:process>
12
13
    <cid:transports>
14
        <cid:webTransport id="myTransportId">
15
            <cid:authentications>
16
                <cid:basicHttp/>
17
            </cid:authentications>
18
19
            <cid:webInteract>
20
                <request method="GET" properties="header queryString"/>
21
                <request method="POST;application/x-www-form-urlencoded" properties="queryString header post"/>
22
                <request method="POST;multipart/form-data" properties="header queryString post"/>
23
            </cid:webInteract>
24
25
            <cid:webUpload>
26
                <request method="PUT" properties="header queryString"/>
27
                <request method="POST" properties="header queryString"/>
28
                <request method="POST;multipart/form-data" properties="header queryString post"/>
29
            </cid:webUpload>
30
        </cid:webTransport>
31
32
        <cid:webTransport>
33
            <cid:authentications>
34
                <cid:basicHttp/>
35
            </cid:authentications>
36
37
            <cid:webUpload>
38
                <request method="PUT" properties="header queryString"/>
39
                <request method="POST" properties="header queryString"/>
40
                <request method="POST;multipart/form-data" properties="header queryString post"/>
41
            </cid:webUpload>
42
        </cid:webTransport>
43
    </cid:transports>
44
</cid:manifest> 

Select a pair

Once determined the list of valid pairs of process and transport, the client must choose one of them. The way this choice is done is out of the scope of the CID protocol. Basically, a client could build a GUI for its user using the labels and docs of the manifest or compute an automatic choice using the is attributes.