DepositCapability
Declares whether the implementation provides the optional deposit surface, and on what terms. This block is REQUIRED in /capabilities: every implementation states its position explicitly, so a client never has to infer read-only-ness from a missing key.
supported is the single flag clients check. When it is true the implementation provides the deposit and RO-Crate endpoints, and idMinting and fileUpload MUST also be present. When it is false the implementation is read-only, the deposit and RO-Crate endpoints are not provided, and the remaining fields MUST be omitted.
Deletion behaviour is declared separately, in the top-level tombstonePolicy.
Whether the implementation provides the deposit surface. true - deposits are accepted and the deposit and RO-Crate endpoints are available; false - the implementation is read-only.
trueHow RO-Crate IDs are minted at deposit creation. client - the client MUST propose an ID; server - the server always mints one; both - the client MAY propose an ID and the server mints one when absent.
Possible values: [client, server, both]
bothThe file staging modes the implementation supports on PUT /deposit/{id}/file/{fileId}. inline - the file's bytes in the request body; presigned - transport metadata in the request, bytes uploaded directly to a returned target. New modes may be added by revision of this specification; clients MUST ignore values they do not recognise.
Possible values: [inline, presigned], >= 1
["inline","presigned"]How long an open deposit lives before expiring. When absent, expiry is implementation-defined and clients should not rely on any particular TTL.
Possible values: >= 1
604800The largest file the implementation accepts in a deposit. When absent, no limit is declared.
Possible values: >= 1
5368709120{
"supported": true,
"idMinting": "both",
"fileUpload": [
"inline",
"presigned"
]
}