Specification: CID protocol

An asynchronous upload is a specific upload declared by the server when the time needed to process the uploaded file does not allow a synchronous response. The server could then define a user-oriented and/or a system oriented wait system.

• The user-oriented system reuse the interaction mechanism.
• The system-oriented system reuse the exchange mechanism.

User and system oriented wait mechanism must declare a url attribute and could declare the needMetas, useMetas and returnMetas step attributes.

<cid:upload url="http://example.com/upload?step=start" needMetas="dc-title dc-creator dc-modified tags" required="true">

    <cid:systemWait url="http://example.com/wait?method=system" returnMetas="Public-url"/>

    <cid:userWait url="http://example.com/wait?method=user" returnMetas="Public-url"/>

</cid:upload>

<cid:upload url="http://example.com/upload?step=start" needMetas="dc-title dc-creator dc-modified tags" required="true">
    <cid:systemWait url="http://example.com/wait?method=system" returnMetas="Public-url"/>
    <cid:userWait url="http://example.com/wait?method=user" returnMetas="Public-url"/>
</cid:upload>

To implement a system wait, the client must send a HTTP GET requests until it gets a 200 response code. A negative response must contains a 202 response code.

A statefull server need to know which session is related to a request. To perform this, CID provides two principles: cookies and session properties.

A web transport definition could specify in the manifest that the client must support cookies to complete the transaction. To perform this, the webTransport element must contain a needCookies attribute set to true. By default (without any attribute) the value is considered as false.

<cid:webTransport needCookies="true">

    ...

</cid:webTransport>

<cid:webTransport needCookies="true">
    ...
</cid:webTransport>

A session property is a pair of key, value which are sent and received following the same scheme than the metadata. The key of the session properties must be declared in a dedicated attribute of the webTransport element. A client which operate a process through such a transport must check if the defined property is returned by the server at each step. When this is the case, the client must send back this property.

<cid:webTransport sessionProperties="session-id">

   ...

</cid:webTransport>

<cid:webTransport sessionProperties="session-id">
   ...
</cid:webTransport>

It is possible to declare several session properties in the attribute.

As for the processes or the authentication, it is possible to define several transport. All the transport should be inserted as a new child of the transports element.

By default, a client could use any process with any transport. It is possible to dedicate a process to a specific transport by the use of ids. A non-generic transport must declare its id in an attribute. A process could bind this transport by the use of the transports attribute.

<cid:process transports="sessionPropTrans">

...

</cid:process>

...

<cid:transports>

    <cid:webTransport id="sessionPropTrans" sessionProperties="session-id">

    ...

    </cid:webTransport>

</cid:transports>

<cid:process transports="sessionPropTrans">
...
</cid:process>
...
<cid:transports>
    <cid:webTransport id="sessionPropTrans" sessionProperties="session-id">
    ...
    </cid:webTransport>
</cid:transports>