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 :
<cid:process>
<cid:label>Upload with post interation</cid:label>
<cid:upload url="http://example.com/upload" required="true"/>
<cid:interact url="http://example.com/interact" required="true"/>
</cid:process>
<cid:process>
<cid:label>Direct upload</cid:label>
<cid:upload url="http://example.com/upload" required="true"/>
</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 :
<cid:manifest xmlns:cid="http://www.cid-protocol.org/schema/v1/core">
<cid:process>
<cid:label>Upload with post interation</cid:label>
<cid:upload url="http://example.com/upload" required="true"/>
<cid:interact url="http://example.com/interact" required="true"/>
</cid:process>
<cid:process>
<cid:label>Direct upload</cid:label>
<cid:upload url="http://example.com/upload" required="true"/>
</cid:process>
<cid:transports>
<cid:webTransport>
<cid:authentications>
<cid:basicHttp/>
</cid:authentications>
<cid:webInteract>
<request method="GET" properties="header queryString"/>
<request method="POST;application/x-www-form-urlencoded" properties="queryString header post"/>
<request method="POST;multipart/form-data" properties="header queryString post"/>
</cid:webInteract>
<cid:webUpload>
<request method="PUT" properties="header queryString"/>
<request method="POST" properties="header queryString"/>
<request method="POST;multipart/form-data" properties="header queryString post"/>
</cid:webUpload>
</cid:webTransport>
</cid:transports>
</cid:manifest>
And the following one is not valid.
<cid:manifest xmlns:cid="http://www.cid-protocol.org/schema/v1/core">
<cid:process>
<cid:label>Upload with post interation</cid:label>
<cid:upload url="http://example.com/upload" required="true"/>
<cid:interact url="http://example.com/interact" required="true"/>
</cid:process>
<cid:process>
<cid:label>Direct upload</cid:label>
<cid:upload url="http://example.com/upload" required="true"/>
</cid:process>
<cid:transports>
<cid:webTransport>
<cid:authentications>
<cid:basicHttp/>
</cid:authentications>
<cid:webInteract>
<request method="GET" properties="header queryString"/>
<request method="POST;application/x-www-form-urlencoded" properties="queryString header post"/>
<request method="POST;multipart/form-data" properties="header queryString post"/>
</cid:webInteract>
<cid:webUpload>
<request method="PUT" properties="header queryString"/>
<request method="POST" properties="header queryString"/>
<request method="POST;multipart/form-data" properties="header queryString post"/>
</cid:webUpload>
</cid:webTransport>
<cid:webTransport>
<cid:authentications>
<cid:basicHttp/>
</cid:authentications>
<cid:webUpload>
<request method="PUT" properties="header queryString"/>
<request method="POST" properties="header queryString"/>
<request method="POST;multipart/form-data" properties="header queryString post"/>
</cid:webUpload>
</cid:webTransport>
</cid:transports>
</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.
<cid:manifest xmlns:cid="http://www.cid-protocol.org/schema/v1/core">
<cid:process transports="myTransportId">
<cid:label>Upload with post interation</cid:label>
<cid:upload url="http://example.com/upload" required="true"/>
<cid:interact url="http://example.com/interact" required="true"/>
</cid:process>
<cid:process>
<cid:label>Direct upload</cid:label>
<cid:upload url="http://example.com/upload" required="true"/>
</cid:process>
<cid:transports>
<cid:webTransport id="myTransportId">
<cid:authentications>
<cid:basicHttp/>
</cid:authentications>
<cid:webInteract>
<request method="GET" properties="header queryString"/>
<request method="POST;application/x-www-form-urlencoded" properties="queryString header post"/>
<request method="POST;multipart/form-data" properties="header queryString post"/>
</cid:webInteract>
<cid:webUpload>
<request method="PUT" properties="header queryString"/>
<request method="POST" properties="header queryString"/>
<request method="POST;multipart/form-data" properties="header queryString post"/>
</cid:webUpload>
</cid:webTransport>
<cid:webTransport>
<cid:authentications>
<cid:basicHttp/>
</cid:authentications>
<cid:webUpload>
<request method="PUT" properties="header queryString"/>
<request method="POST" properties="header queryString"/>
<request method="POST;multipart/form-data" properties="header queryString post"/>
</cid:webUpload>
</cid:webTransport>
</cid:transports>
</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.