N.B. en cours de rédaction ...

Discussion about VOSpace with Dave Morris during the Trieste meeting in Trieste

VOSpace 2.x

HTTP param GET

Unless there is a strong use case that justifies it, then AG would like to drop the HTTP param GET option from the specification. See request for use case.

Version 2.x was supposed to be 1.1 with SOAP replaced by REST. No new functionality unless there is a very strong case for it.

IF a strong use case is presented (that can't be solved using a separate resolver), then we will try to include it in 2.0, but it should not block progress for this version.

Suggest we look at a separate resolver service for HTTP param GET access, similar to a DOI resolver.

Unknown properties

Request to change the specification to require that a service rejects properties that it does not understand. This solves a future security problem with unknown properties.

At the moment, client can send any property URI to the server, and it will be stored as a string value. e.g.

property uri=test:2113

This cause a problem if we want to introduce server generated security values in the future, e.g MD5 checksum For example we want to introduce a property called 'ivoa:security.md5' that should be set by the server.

property uri=ivoa:security.md5

The problem occurs if a client attempts to set this property on an older service that does not understand that the property should be set by the server. This would enable a malicious client to appear to set the security checksum on a node in the older service.

Performance for large lists

Speed issues with DOM based SOAP libraries e.g. early versions of Axis meant listing large collections was slow. In 1.x this is addressed by using the pagination. In 2.x most toolkits will be SAX based, so pagination is no longer as needed.

CDS implementation questions

• All VOSpace users are mapped to a single iRODS account.
• If data is added via VOSpace interface, then metadata is propagated to iRODS.
• If data is added to iRODS, then at the moment this is not visible via VOSpace interface.

• Current implementation will work for for both an existing iRODS system, or a new install.
• Current implementation is tightly coupled with iRODS.

• Looking to use DAViS as a basis for the 2.x implementation, with SSL authentication.

Version interop question

Data transfer between 1.x and 2.x services is possible if the client understands both versions of the protocol. The services do not need to understand each other.

Client sends a 'pullFrom' request to the source, collects the URL and sends that to the target service in a 'pullTo' request. The target service uses the URL to perform the data transfer direct from the source.

This is 'by design' as it means that services don't have to 'understand' multiple versions of the specification.