VOSpace v2.1 Proposed Recommendation: Request for Comments

RFC page for the IVOA VOSpace 2.1 Proposed Recommendation.

The VOSpace 2.1 Proposed Recommendation can be found at:

• VOSpace-2.1.pdf

And here:

• http://www.ivoa.net/documents/VOSpace/20170405/

Change Overview

The change notes since version 2.0:

From version 2.1-20170405:

• Replaced the dated Custom Protocols section with a new Public Share Protocol section
• Added REQUEST=redirect for further optimized pullFromVoSpace
• Removed "search" and "find nodes" until use cases and implementations are presented
• Changed Transfer in XSD to accept parameters.
• Recreated and expanded all webservice operation examples
• Changed XSD element authType to SecurityMethod to match IVOA standard.
• Fixed text inconsistencies
• Clarified role of the node busy flag

From version 2.1-20140805:

• 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
• Deprecated view=data convenience method of data transfer
• Corrections to minor XML format errors in the examples throughout the document.

An earlier VOSpace discussion page can be found here:

• http://wiki.ivoa.net/twiki/bin/view/IVOA/VOSpace21Spec

Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18

Implementation and Validators

Please note your implementation or validator in this section.

Comments from Pierre Fernique

Implementation references

• Presently, it seems that there is one VOSpace 2.1 server working (CANFAR) declared in the VO registry. MSSL, CASU and WFAU seems to be out of order. Is there already VOSpace 2.1 clients ?

Abstract

• p2 - It is a little bit surprising to have directly in the abstract a note about the (un)compatibility with the previous releases of the standard. May be a dedicated section, just after the Abstract, should be more adapted.
• More largelly, the fact that the compatibility between clients and servers of different versions is rarelly insured questions me. This choice has always the same big impact. The consequence is to force the servers and the clients to implement VOSpace 1.0, 2.0 and 2.1 the time that all potential clients (resp. servers) have upgraded their codes. This remark is not limited to VOSpace, we have the same challenge for SIAv2 which is a totally new standard compared to SIAv1.

Introduction

• p5 - This section provides the analogy "node = file". Should we have to extend this analogy as "node = file or directory" ? This remark comes from our experience for implementing VOSpace client in Aladin. The role and functions on "directories" are not so clear in the previous release documents. And concretely, our experience shown us that the directory manipulations are generally not, or very lighted implemented. The situation could be improved, if we specify immediately that a node is potentially a directory (cf p11 - figure 2)

Typical use of a VOSpace service

• p5 - This subsection is important to understand the role of VOSpace, but I am wondering if it is a little bit too detailed as this level of the introduction (XML examples, ...)

VOSpace identifiers

• p9 - The alternative '!' or '~' substitution characters should be justified. Why two substitutions characters ? Is it really required ? I suspect that it could be a source of potential bugs (cf. section 2.1 - identifier resolution). It seems that the response is provided p64 "Note that the # sign in PROTOCOL is URL encoded as %23 and that the alternate separator ‘~’ is used instead of ‘!’ in the TARGET".
• P10 - The end of this section cites the standardID of this specification. May be, a short explanation of what is a "standardID" would be welcome to avoid the possible reader confusion with the node identifier (same section). This standardID is also described in page 36. Maybe this last definition should be sufficiente.

VOSpace data model

• p12 - "LinkNode" is described. But we do not know if we have to understand only dataLinkNode, or potentially ContainerLinkNode ?
• p13 - The support of all type of nodes is not required (end of the section). But does it means that a VOSPace could be not supporting hierarchy (flat view only) ?

Property identifiers

• p14 - URN is introduced here but not described. I suggest a end page note, or a RFC reference on URN.

Property descriptions

• p15 & 16 "Note that at the time of writing, the schema for registering PropertyDescriptions in the IVO registry has not been finalized" - This remark is repeated at various places in the document, but concretely, there is no progress on this point since VOSpace 1.0 (2007). Maybe these remarks should be simply removed.

Standard properties

• p16 - The standard properties identifiers are IVOID. But following the last Registry recommendation, any IVOID must be declared in the VO registry otherwise they are not valid. Actually, "ivo://ivoa.net/vospace/core" is not registered yet (or not accessible by the two active Full queryable resistries: euroVO and NAVO).
• p17 - "ivo://ivoa.net/vospace/core#group...". This is the first (and the unique) mention of "group" notion. Surprisingly, there is no notion of "owner" (only creator, publisher and contributor which are probably not at the same level). It seems that this document does not described these notions (except briefly p36 "Nodes are considered to be owned by the user who created them"). May be, it could help the implementors to have a section describing these notions.

Cababilities

• p19 - "Note that at the time of writing, the schema for registering Capability-Descriptions in the IVO registry has not been finalized" - same remark as p16

View descriptions

• p24 - "Note that at the time of writing... " - same remark as p16
• p25&26 - "pullToVoSpace" and "pushToVoSpace" are cited here, but never introduced before. May be a reference to the associated section would be welcome.

Public share protocol

• p29 - A "standard ID" for "public share protocol" is provided in this section (new in VOSpace 2.1) => http://wiki.ivoa.net/twiki/bin/view/IVOA/VOSpacePublicShare. This ID is not compatible with regular IVOA standardID based on IVOID contrary to the other "standard protocols" defined in 3.5.3 (ex: ivo://ivoa.net/vospace/core#httpget). Is there a reason for this alternative nomenclature ?

Transfers

• p30 - In the XML example, there are security method identifiers for which the vocabulary seems to take various origins ( ivo://ivoa.net/sso#tls-with-certificate, http://www.w3.org/Protocols/HTTP/1.0/spec/html#BasicAA). Reference to associated documents would help.

REST binding

• p35 - "These names are part of the VOSpace 2.1 standard". It lets suppose that other elements in the document may be not relevant to VOSpace 2.1. I suggest to remove any reference to VOSpace 2.1 as this document is 2.1 specification (except for history list...)
• p35 - ".auto", ".null" are cited in this section, but without explanation. The description of their respective role should be appreciate.
• p36 - "For backwards compatibility support, services SHALL include the securityMethod element"... but as there is no real compatibility support (cf abstract), this sentence is a little bit surprising.

Create Node

• p41 - "If the Node xs:type...". This is the first citation of "xs:type" which seems to refer to node types.This notion should be defined somewhere before in the document, maybe page 11 in "Nodes and node types"
• p43 - In the example, (and the following examples), there are 2 paragraphes: Request:... Response:... but the Response paragraph also contains the HTTP request part of the dialog. Strickly speaking the "Response" starts at the ligne "HTTP/1.1 nnn...", the lines above ("PUT....") are the "Request". I would suggest to change the "Response" title by "HTTP dialog" which seems to be more appropriate.

Transfering data

• p55 - The difference between pushToVoSpace (sending data to a service) and pullFromVoSpace (reading data from a service) is not obvious. Same for pullToVoSpace (importing data into a service) and pushFromVoSpace (sending data from a service). I suppose that depends of the origin of the action, but it is just a speculation. As these 4 actions are a key point of VOSpace, small examples, or a small graphic would be appreciate.

Change since last version

• p82 - We have the list of the changes from the previous "version 2.1-20150601". The full history is provided in appendix D. It is probably preferable to have all the history in the same place.
• p82 - a "(?TBD)" is still present

Message schema

• p82 - "VOSPace 2.0" must be replaced by "VOSpace 2.1" in the introduction sentence.

-- PierreFernique - 2017-04-11

Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18

WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard.

IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.

TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )

Applications Working Group ( _Pierre Fernique, Tom Donaldson )

Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )

Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )

Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )

Registry Working Group ( _Markus Demleitner, Theresa Dower )

Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )

Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )

Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )

Data Curation & Preservation Interest Group ( Françoise Genova )

Operations Interest Group ( _Tom McGlynn, Mark Taylor )

Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )

Theory Interest Group ( _Carlos Rodrigo )

Standards and Processes Committee ( Françoise Genova)