Discussion page for the VOSpace 2.1 specification

This is a discussion page for the VOSpace-2.1 service specification.

Please edit this page directly to add comments or specification changes and additions.

Changes and Enhancements for VOSpace 2.1

Parameter based sync transfer negotiation

This is a proposal to support the ability to perform a simplified transfer negotiation by executing an HTTP GET with transfer parameters to the /sync endpoint. For example:

Parameter based GET:

curl -d "TARGET=vos://nvo.caltech!vospace/mydata1&DIRECTION=pullFromVoSpace&PROTOCOL=ivo://ivoa.net/vospace/core#httpget" "http://localhost:8000/sync"

Would be somewhat equivalent to:

curl -X POST -d @job.xml "http://localhost:8000/sync"

Where job.xml is a file containing:

<vos:transfer xmlns:vos="http://www.ivoa.net/xml/VOSpace/v2.1">
<vos:target>vos://nvo.caltech!vospace/mydata1</vos:target>
<vos:direction>pullFromVoSpace</vos:direction>
<vos:protocol>ivo://ivoa.net/vospace/core#httpget</vos:protocol>
</vos:transfer>

Instead of returning a redirect to the transferDetails (which will contain the endpoint URL(s)), it would return a single, preferred endpoint URL directly. This is an optimization that reduces the number of redirects.

Since there is no job associated with the optimized GET, there less ability to do correct error handling. Upon error, clients should revert to the POST to /sync for full transfer negotiation and error handling capability. This is an optimistic approach and assumes that there is a low error rate in the service and this fallback would not happen frequently.

Add desired authentication method to transfer document

In certain cases, there isn't enough information in the transfer negotiation document to produce URLs to the data store correctly. The missing piece of information is authentication method they wish to use on the URLs. For example, if they wish to use userid/password to authenticate, the URLs must be pointed at a resource that will block and collect that information. If a cookie is to be used, the resource must not block. Authentication method options should include, but are not limited to:

• anonymous
• password over TLS
• cookies
• x509 client certificate over TLS
• OAuth

Capabilities: dynamic capabilities and error handling

Please refer to this thread

Addressing changes from VOSpace 2.1

Please refer to this page

Dave Morris has identified a number of inconsistencies in the document, most dating back to the v1.1 -> v2.0 conversion. There is the question as to how these should be addressed, considering VOSpace 2.0 has been a proposed recommendation for some time. Here are three options:

• Wrap up all the changes and corrections in a new document. That document will be either v2.1 or v3.0 depending on the magnitude.
• Move v2.1 to acceptance, and address the changes in a new version (v2.2 or v3.0)
• Make use of an errata: Go through issues and separate the "regrettable inconsistencies" from the "service errors". The "regrettable inconsistencies" can be turned into a lightweight errata document that would be attached to VOSpace 2.0. v2.1 (or v3.0) could then include both the "regrettable inconsistencies" and the "service errors".

New document format

The existing document is in html format and needs to be converted to a more editable medium. Should this be XHTML or ivotex?

VOSpace interoperable clients and servers

I would like to propose the goal of having a working interoperability of two or more VOSpace implementations (version 2.1?) by Oct 2015.

Please update the implementations table on the VOSpace home page if your institution has built a VOSpace.

VOSpace 2.1 - Two Implementations

Two implementations of the VOSpace 2.1 specification needed in the beginning of 2015 (March/April will be nice) to push the document to the PR Status if we find a consensus during the Banff interop.

The 2.1 Working Draft

• VOSpace2-1.html: VOSpace 2.1 WD

Change Notes

From version 2.0-20130329 (in progress):

• Addition of optimized HTTP GET method of data transfer for pushToVoSpace, pullFromVoSpace
• Addition of authType to Protocol in XML schema for transfer negotiation.
• Added preliminary list of standard authType URIs
• Removed view=data convenience method of data transfer
• Corrections to minor XML format errors in the examples throughout the document.

• (3.4.3) Added "view parameters" to view description
• (3.5, Appendix B) Corrections to required, optional protocol parameters
• (Appendix A) Addition of authType element to protocol element
• (3.6.2) Added sentence about the protocol authType
• (3.8) Added paragraph about HTTP GET to /sync endpoint for optimized transfer negotiation
• (4) Added paragraph about the (preliminary) set of supported authentication types
• (5.4.1, 5.4.2, 5.4.3, 5.4.4) XML formatting corrections in examples
• (5.4.3.1) Removed view=data as a suggested convenience for "pullFromVoSpace". Replaced with optimized HTTP GET from /sync example.
• (5.4.1, 5.4.3) Added authType to protocol in the examples
• (3.5.3) Added (preliminary) set of standard authType URIs
• (6) Preliminary change notes

For future VOSpace versions:

Please see The VOSpace 3.0 Discussion Page for future changes and enhancements to VOSpace beyond version 2.1.