Difference: VOSpace21Spec (1 vs. 22)

Revision 222014-10-10 - AndreSchaaff

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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
This field is optional in the transfer document.

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

Changed:
<
<
Two implementations of the VOSpace 2.1 specification needed by June, 2015.
>
>
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

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.
Changes in detail:
  • (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.

<--  
-->

META FILEATTACHMENT attachment="vospace-in-arch.png" attr="h" comment="vospace-in-arch" date="1399741332" name="vospace-in-arch.png" path="vospace-in-arch.png" size="351230" user="BrianMajor" version="1"
META FILEATTACHMENT attachment="vospace-node-hierarchy.png" attr="h" comment="vospace-node-hierarchy" date="1399741365" name="vospace-node-hierarchy.png" path="vospace-node-hierarchy.png" size="228549" user="BrianMajor" version="1"

Revision 212014-10-09 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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
This field is optional in the transfer document.

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.

Added:
>
>

VOSpace 2.1 - Two Implementations

Two implementations of the VOSpace 2.1 specification needed by June, 2015.

 

The 2.1 Working Draft

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.
Changes in detail:
  • (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.

<--  
-->

META FILEATTACHMENT attachment="vospace-in-arch.png" attr="h" comment="vospace-in-arch" date="1399741332" name="vospace-in-arch.png" path="vospace-in-arch.png" size="351230" user="BrianMajor" version="1"
META FILEATTACHMENT attachment="vospace-node-hierarchy.png" attr="h" comment="vospace-node-hierarchy" date="1399741365" name="vospace-node-hierarchy.png" path="vospace-node-hierarchy.png" size="228549" user="BrianMajor" version="1"

Revision 202014-10-07 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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
Changed:
<
<
  • userid/password basic authentication
>
>
  • password over TLS
 
  • cookies
Changed:
<
<
  • x509 client certificate
>
>
  • x509 client certificate over TLS
 
  • OAuth
This field is optional in the transfer document.

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.

Deleted:
<
<

Notes / Questions / Discussion Items / Ideas

  • Add authentication types to the capabilities?
 

The 2.1 Working Draft

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.
Changes in detail:
  • (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.

<--  
-->

META FILEATTACHMENT attachment="vospace-in-arch.png" attr="h" comment="vospace-in-arch" date="1399741332" name="vospace-in-arch.png" path="vospace-in-arch.png" size="351230" user="BrianMajor" version="1"
META FILEATTACHMENT attachment="vospace-node-hierarchy.png" attr="h" comment="vospace-node-hierarchy" date="1399741365" name="vospace-node-hierarchy.png" path="vospace-node-hierarchy.png" size="228549" user="BrianMajor" version="1"

Revision 192014-10-05 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Deleted:
<
<
Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.
 

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
  • userid/password basic authentication
  • cookies
  • x509 client certificate
Changed:
<
<
This field should be optional in the transfer document.
>
>
  • OAuth
Added:
>
>
This field is optional in the transfer document.
 
Changed:
<
<
Update: The IVOA Single Sign-On Profile should be consulted on this, though it is now a bit out-of-date (2008).
>
>

Capabilities: dynamic capabilities and error handling

 
Changed:
<
<

Notes / Questions / Discussion Items

>
>
Please refer to this thread
 
Added:
>
>

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.

Notes / Questions / Discussion Items / Ideas

 
  • Add authentication types to the capabilities?
Deleted:
<
<
  • JPEG2000 Interactive Protocol (JPIP) and VOSpace?
  • How would authType be best placed in the XML schema?
 

The 2.1 Working Draft

Changed:
<
<
>
>
 

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.
Changes in detail:
  • (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:

Changed:
<
<
  • In the transfer object, the 'direction' can conflict with the protocol URI. For example, the direction can be 'pullFromVoSpace' and the protocol can be 'HTTP-PUT'. This could be cleaned up to remove error cases.
  • Should VOSpace should have it's own registry extension, VoSpaceRegEx?
>
>
Please see The VOSpace 3.0 Discussion Page for future changes and enhancements to VOSpace beyond version 2.1.
Deleted:
<
<
  • Section 4, Access Control: Version 3.0 should state access control policies at the Node level?
 
<--  
-->

META FILEATTACHMENT attachment="vospace-in-arch.png" attr="h" comment="vospace-in-arch" date="1399741332" name="vospace-in-arch.png" path="vospace-in-arch.png" size="351230" user="BrianMajor" version="1"
META FILEATTACHMENT attachment="vospace-node-hierarchy.png" attr="h" comment="vospace-node-hierarchy" date="1399741365" name="vospace-node-hierarchy.png" path="vospace-node-hierarchy.png" size="228549" user="BrianMajor" version="1"

Revision 182014-07-02 - SarahEmeryBunn

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.

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
  • userid/password basic authentication
  • cookies
  • x509 client certificate
This field should be optional in the transfer document.

Update: The IVOA Single Sign-On Profile should be consulted on this, though it is now a bit out-of-date (2008).

Notes / Questions / Discussion Items

  • Add authentication types to the capabilities?
  • JPEG2000 Interactive Protocol (JPIP) and VOSpace?
  • How would authType be best placed in the XML schema?

The 2.1 Working Draft

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.
Changes in detail:
  • (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:

  • In the transfer object, the 'direction' can conflict with the protocol URI. For example, the direction can be 'pullFromVoSpace' and the protocol can be 'HTTP-PUT'. This could be cleaned up to remove error cases.
  • Should VOSpace should have it's own registry extension, VoSpaceRegEx?
  • Section 4, Access Control: Version 3.0 should state access control policies at the Node level?
<--  
-->
Deleted:
<
<
META FILEATTACHMENT attachment="VOSpace2-1.html" attr="" comment="VOSpace 2.1 WD" date="1402087807" name="VOSpace2-1.html" path="VOSpace2-1.html" size="204458" user="BrianMajor" version="3"
 
META FILEATTACHMENT attachment="vospace-in-arch.png" attr="h" comment="vospace-in-arch" date="1399741332" name="vospace-in-arch.png" path="vospace-in-arch.png" size="351230" user="BrianMajor" version="1"
META FILEATTACHMENT attachment="vospace-node-hierarchy.png" attr="h" comment="vospace-node-hierarchy" date="1399741365" name="vospace-node-hierarchy.png" path="vospace-node-hierarchy.png" size="228549" user="BrianMajor" version="1"
Deleted:
<
<
META FILEATTACHMENT attachment="VOSpace.html" attr="" comment="VOSpace 2.1 WD" date="1402433146" name="VOSpace.html" path="VOSpace.html" size="203874" user="BrianMajor" version="1"
 

Revision 172014-06-10 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.

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
  • userid/password basic authentication
  • cookies
  • x509 client certificate
This field should be optional in the transfer document.

Update: The IVOA Single Sign-On Profile should be consulted on this, though it is now a bit out-of-date (2008).

Notes / Questions / Discussion Items

  • Add authentication types to the capabilities?
  • JPEG2000 Interactive Protocol (JPIP) and VOSpace?
  • How would authType be best placed in the XML schema?

The 2.1 Working Draft

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.
Changes in detail:
  • (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:

  • In the transfer object, the 'direction' can conflict with the protocol URI. For example, the direction can be 'pullFromVoSpace' and the protocol can be 'HTTP-PUT'. This could be cleaned up to remove error cases.
  • Should VOSpace should have it's own registry extension, VoSpaceRegEx?
  • Section 4, Access Control: Version 3.0 should state access control policies at the Node level?
<--  
-->

META FILEATTACHMENT attachment="VOSpace2-1.html" attr="" comment="VOSpace 2.1 WD" date="1402087807" name="VOSpace2-1.html" path="VOSpace2-1.html" size="204458" user="BrianMajor" version="3"
META FILEATTACHMENT attachment="vospace-in-arch.png" attr="h" comment="vospace-in-arch" date="1399741332" name="vospace-in-arch.png" path="vospace-in-arch.png" size="351230" user="BrianMajor" version="1"
META FILEATTACHMENT attachment="vospace-node-hierarchy.png" attr="h" comment="vospace-node-hierarchy" date="1399741365" name="vospace-node-hierarchy.png" path="vospace-node-hierarchy.png" size="228549" user="BrianMajor" version="1"
Added:
>
>
META FILEATTACHMENT attachment="VOSpace.html" attr="" comment="VOSpace 2.1 WD" date="1402433146" name="VOSpace.html" path="VOSpace.html" size="203874" user="BrianMajor" version="1"
 

Revision 162014-06-06 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.

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
  • userid/password basic authentication
  • cookies
  • x509 client certificate
This field should be optional in the transfer document.

Update: The IVOA Single Sign-On Profile should be consulted on this, though it is now a bit out-of-date (2008).

Notes / Questions / Discussion Items

  • Add authentication types to the capabilities?
  • JPEG2000 Interactive Protocol (JPIP) and VOSpace?
  • How would authType be best placed in the XML schema?

The 2.1 Working Draft

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.
Changes in detail:
  • (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:

  • In the transfer object, the 'direction' can conflict with the protocol URI. For example, the direction can be 'pullFromVoSpace' and the protocol can be 'HTTP-PUT'. This could be cleaned up to remove error cases.
  • Should VOSpace should have it's own registry extension, VoSpaceRegEx?
  • Section 4, Access Control: Version 3.0 should state access control policies at the Node level?
<--  
-->
Changed:
<
<
META FILEATTACHMENT attachment="VOSpace2-1.html" attr="" comment="VOSpace 2.1 WD" date="1402011669" name="VOSpace2-1.html" path="VOSpace2-1.html" size="201055" user="BrianMajor" version="2"
>
>
META FILEATTACHMENT attachment="VOSpace2-1.html" attr="" comment="VOSpace 2.1 WD" date="1402087807" name="VOSpace2-1.html" path="VOSpace2-1.html" size="204458" user="BrianMajor" version="3"
 
META FILEATTACHMENT attachment="vospace-in-arch.png" attr="h" comment="vospace-in-arch" date="1399741332" name="vospace-in-arch.png" path="vospace-in-arch.png" size="351230" user="BrianMajor" version="1"
META FILEATTACHMENT attachment="vospace-node-hierarchy.png" attr="h" comment="vospace-node-hierarchy" date="1399741365" name="vospace-node-hierarchy.png" path="vospace-node-hierarchy.png" size="228549" user="BrianMajor" version="1"

Revision 152014-06-05 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.

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
  • userid/password basic authentication
  • cookies
  • x509 client certificate
This field should be optional in the transfer document.

Update: The IVOA Single Sign-On Profile should be consulted on this, though it is now a bit out-of-date (2008).

Notes / Questions / Discussion Items

  • Add authentication types to the capabilities?
  • JPEG2000 Interactive Protocol (JPIP) and VOSpace?
  • How would authType be best placed in the XML schema?

The 2.1 Working Draft

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.
Changes in detail:
  • (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:

  • In the transfer object, the 'direction' can conflict with the protocol URI. For example, the direction can be 'pullFromVoSpace' and the protocol can be 'HTTP-PUT'. This could be cleaned up to remove error cases.
  • Should VOSpace should have it's own registry extension, VoSpaceRegEx?
  • Section 4, Access Control: Version 3.0 should state access control policies at the Node level?
<--  
-->
Changed:
<
<
META FILEATTACHMENT attachment="VOSpace2-1.html" attr="" comment="VOSpace 2.1 WD" date="1399741256" name="VOSpace2-1.html" path="VOSpace2-1.html" size="201293" user="BrianMajor" version="1"
>
>
META FILEATTACHMENT attachment="VOSpace2-1.html" attr="" comment="VOSpace 2.1 WD" date="1402011669" name="VOSpace2-1.html" path="VOSpace2-1.html" size="201055" user="BrianMajor" version="2"
 
META FILEATTACHMENT attachment="vospace-in-arch.png" attr="h" comment="vospace-in-arch" date="1399741332" name="vospace-in-arch.png" path="vospace-in-arch.png" size="351230" user="BrianMajor" version="1"
META FILEATTACHMENT attachment="vospace-node-hierarchy.png" attr="h" comment="vospace-node-hierarchy" date="1399741365" name="vospace-node-hierarchy.png" path="vospace-node-hierarchy.png" size="228549" user="BrianMajor" version="1"

Revision 142014-05-13 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.

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>

Changed:
<
<
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.
>
>
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
  • userid/password basic authentication
  • cookies
  • x509 client certificate
Deleted:
<
<
 This field should be optional in the transfer document.

Update: The IVOA Single Sign-On Profile should be consulted on this, though it is now a bit out-of-date (2008).

Notes / Questions / Discussion Items

  • Add authentication types to the capabilities?
  • JPEG2000 Interactive Protocol (JPIP) and VOSpace?
  • How would authType be best placed in the XML schema?

The 2.1 Working Draft

Added:
>
>
 

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.
Deleted:
<
<
 Changes in detail:
  • (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:

  • In the transfer object, the 'direction' can conflict with the protocol URI. For example, the direction can be 'pullFromVoSpace' and the protocol can be 'HTTP-PUT'. This could be cleaned up to remove error cases.
  • Should VOSpace should have it's own registry extension, VoSpaceRegEx?
  • Section 4, Access Control: Version 3.0 should state access control policies at the Node level?
<--  
-->
Deleted:
<
<
 
META FILEATTACHMENT attachment="VOSpace2-1.html" attr="" comment="VOSpace 2.1 WD" date="1399741256" name="VOSpace2-1.html" path="VOSpace2-1.html" size="201293" user="BrianMajor" version="1"
META FILEATTACHMENT attachment="vospace-in-arch.png" attr="h" comment="vospace-in-arch" date="1399741332" name="vospace-in-arch.png" path="vospace-in-arch.png" size="351230" user="BrianMajor" version="1"
META FILEATTACHMENT attachment="vospace-node-hierarchy.png" attr="h" comment="vospace-node-hierarchy" date="1399741365" name="vospace-node-hierarchy.png" path="vospace-node-hierarchy.png" size="228549" user="BrianMajor" version="1"

Revision 132014-05-10 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.

Changes and Enhancements for VOSpace 2.1

Parameter based sync transfer negotiation

Changed:
<
<
This is a proposal to support the ability to perform a transfer negotiation by performing an HTTP GET with transfer parameters to the /sync endpoint. For example:
>
>
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>

Changed:
<
<
The motivation for adding this functionality is to reduce the number of redirects the client needs to perform before starting the data transfer. The HTTP GET request would return the endpoint URL for data transfer immediately. The POST to the /sync returns a redirect to the transfer details of the job, which contains the endpoint URL.
>
>
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

Changed:
<
<
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:
>
>
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
  • userid/password basic authentication
  • cookies
  • x509 client certificate
Added:
>
>
 This field should be optional in the transfer document.

Update: The IVOA Single Sign-On Profile should be consulted on this, though it is now a bit out-of-date (2008).

Changed:
<
<

Notes

>
>

Notes / Questions / Discussion Items

 
  • Add authentication types to the capabilities?
Added:
>
>
  • JPEG2000 Interactive Protocol (JPIP) and VOSpace?
  • How would authType be best placed in the XML schema?
 

The 2.1 Working Draft

Deleted:
<
<
 

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.

Changes in detail:

  • (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
Changed:
<
<
  • (5.4.3.1) Removed view=data as a suggested convenience for "pullFromVoSpace". Replaced with optimized HTTP GET from /sync example.
>
>
  • (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:

  • In the transfer object, the 'direction' can conflict with the protocol URI. For example, the direction can be 'pullFromVoSpace' and the protocol can be 'HTTP-PUT'. This could be cleaned up to remove error cases.
  • Should VOSpace should have it's own registry extension, VoSpaceRegEx?
Changed:
<
<
  • Section 4, Access Control: Version 3.0 should state access control policies at the Node level.
>
>
  • Section 4, Access Control: Version 3.0 should state access control policies at the Node level?
 
<--  
-->
Added:
>
>

META FILEATTACHMENT attachment="VOSpace2-1.html" attr="" comment="VOSpace 2.1 WD" date="1399741256" name="VOSpace2-1.html" path="VOSpace2-1.html" size="201293" user="BrianMajor" version="1"
META FILEATTACHMENT attachment="vospace-in-arch.png" attr="h" comment="vospace-in-arch" date="1399741332" name="vospace-in-arch.png" path="vospace-in-arch.png" size="351230" user="BrianMajor" version="1"
META FILEATTACHMENT attachment="vospace-node-hierarchy.png" attr="h" comment="vospace-node-hierarchy" date="1399741365" name="vospace-node-hierarchy.png" path="vospace-node-hierarchy.png" size="228549" user="BrianMajor" version="1"
 

Revision 122014-05-09 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.

Changed:
<
<

Changes and Enhancements for VOSpace 2.1

>
>

Changes and Enhancements for VOSpace 2.1

 
Changed:
<
<

Parameter based sync transfer negotiation

>
>

Parameter based sync transfer negotiation

 
Changed:
<
<
This is a proposal to support the ability to perform a transfer negotiation by performing an HTTP GET with transfer parameters to the /sync endpoint. For example:
>
>
This is a proposal to support the ability to perform a transfer negotiation by performing 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>

Changed:
<
<
The motivation for adding this functionality is to reduce the number of redirects the client needs to perform before starting the data transfer. The HTTP GET request would return the endpoint URL for data transfer immediately. The POST to the /sync returns a redirect to the transfer details of the job, which contains the endpoint URL.
>
>
The motivation for adding this functionality is to reduce the number of redirects the client needs to perform before starting the data transfer. The HTTP GET request would return the endpoint URL for data transfer immediately. The POST to the /sync returns a redirect to the transfer details of the job, which contains the endpoint URL.
 
Changed:
<
<
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.
>
>
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.
 
Changed:
<
<

Add desired authentication method to transfer document

>
>

Add desired authentication method to transfer document

  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:

  • anonymous
  • userid/password basic authentication
  • cookies
  • x509 client certificate
This field should be optional in the transfer document.

Update: The IVOA Single Sign-On Profile should be consulted on this, though it is now a bit out-of-date (2008).

Changed:
<
<

Link Node documentation clarity

>
>

Notes

 
Changed:
<
<
For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.:
>
>
  • Add authentication types to the capabilities?
 
Changed:
<
<
  • Example, on the getNode operation, what does view=data mean when the target is a link node? Is it a 'ViewNotSupported' fault or should the link target be resolved and downloaded?
>
>

The 2.1 Working Draft

 
Changed:
<
<

For future VOSpace versions:

>
>
Added:
>
>

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.

Changes in detail:

  • (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:

 
  • In the transfer object, the 'direction' can conflict with the protocol URI. For example, the direction can be 'pullFromVoSpace' and the protocol can be 'HTTP-PUT'. This could be cleaned up to remove error cases.
  • Should VOSpace should have it's own registry extension, VoSpaceRegEx?
  • Section 4, Access Control: Version 3.0 should state access control policies at the Node level.
<--  
-->

Revision 112014-05-08 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.

Changes and Enhancements for VOSpace 2.1

Parameter based sync transfer negotiation

Changed:
<
<
This is a proposal to support the ability to perform a transfer negotiation by performing an HTTP GET with transfer parameters to the /sync endpoint. This would be functionally equivalent to posting the transfer XML document to the /sync endpoint. For example:
>
>
This is a proposal to support the ability to perform a transfer negotiation by performing an HTTP GET with transfer parameters to the /sync endpoint. For example:
  Parameter based GET:
Changed:
<
<
curl -X POST -d "TARGET=vos://nvo.caltech!vospace/mydata1&DIRECTION=pullFromVoSpace&PROTOCOL=ivo://ivoa.net/vospace/core#httpget" "http://localhost:8000/sync"
>
>
curl -d "TARGET=vos://nvo.caltech!vospace/mydata1&DIRECTION=pullFromVoSpace&PROTOCOL=ivo://ivoa.net/vospace/core#httpget" "http://localhost:8000/sync"
 
Changed:
<
<
Would be equivalent to:
>
>
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>

Changed:
<
<
The motivation for adding this functionality is to reduce the number of redirects the client needs to perform before starting the data transfer.
>
>
The motivation for adding this functionality is to reduce the number of redirects the client needs to perform before starting the data transfer. The HTTP GET request would return the endpoint URL for data transfer immediately. The POST to the /sync returns a redirect to the transfer details of the job, which contains the endpoint URL.
 
Added:
>
>
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

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:

  • anonymous
  • userid/password basic authentication
  • cookies
  • x509 client certificate
This field should be optional in the transfer document.

Update: The IVOA Single Sign-On Profile should be consulted on this, though it is now a bit out-of-date (2008).

Link Node documentation clarity

For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.:

  • Example, on the getNode operation, what does view=data mean when the target is a link node? Is it a 'ViewNotSupported' fault or should the link target be resolved and downloaded?

For future VOSpace versions:

  • In the transfer object, the 'direction' can conflict with the protocol URI. For example, the direction can be 'pullFromVoSpace' and the protocol can be 'HTTP-PUT'. This could be cleaned up to remove error cases.
  • Should VOSpace should have it's own registry extension, VoSpaceRegEx?
Added:
>
>
  • Section 4, Access Control: Version 3.0 should state access control policies at the Node level.
 
<--  
-->

Revision 102014-05-08 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.

Changes and Enhancements for VOSpace 2.1

Parameter based sync transfer negotiation

Changed:
<
<
This is a proposal to support the ability to perform a transfer negotiation by posting transfer parameters to the /sync endpoint. This would be functionally equivalent to posting the transfer XML document to the /sync endpoint. For example:
>
>
This is a proposal to support the ability to perform a transfer negotiation by performing an HTTP GET with transfer parameters to the /sync endpoint. This would be functionally equivalent to posting the transfer XML document to the /sync endpoint. For example:
 
Changed:
<
<
Parameter based POST:
>
>
Parameter based GET:
  curl -X POST -d "TARGET=vos://nvo.caltech!vospace/mydata1&DIRECTION=pullFromVoSpace&PROTOCOL=ivo://ivoa.net/vospace/core#httpget" "http://localhost:8000/sync"

Would be 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>

Changed:
<
<
The motivation for adding this functionality is to allow the negotiation of a transfer to happen with a single URL without having a smart client or having to generate an XML document. This is convenient when referring to VOSpace nodes from web interfaces.
>
>
The motivation for adding this functionality is to reduce the number of redirects the client needs to perform before starting the data transfer.
 

Add desired authentication method to transfer document

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:

  • anonymous
  • userid/password basic authentication
  • cookies
  • x509 client certificate
This field should be optional in the transfer document.

Update: The IVOA Single Sign-On Profile should be consulted on this, though it is now a bit out-of-date (2008).

Link Node documentation clarity

For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.:

Changed:
<
<
  • Example, on the getNode operation, what does view=data mean when the target is a link node? Is it a 'ViewNotSupported' fault or should the link target be resolved and downloaded?
>
>
  • Example, on the getNode operation, what does view=data mean when the target is a link node? Is it a 'ViewNotSupported' fault or should the link target be resolved and downloaded?
 

For future VOSpace versions:

Changed:
<
<
  • In the transfer object, the 'direction' can conflict with the protocol URI. For example, the direction can be 'pullFromVoSpace' and the protocol can be 'HTTP-PUT'. This could be cleaned up to remove error cases.
>
>
  • In the transfer object, the 'direction' can conflict with the protocol URI. For example, the direction can be 'pullFromVoSpace' and the protocol can be 'HTTP-PUT'. This could be cleaned up to remove error cases.
 
  • Should VOSpace should have it's own registry extension, VoSpaceRegEx?
Changed:
<
<
>
>

Revision 92014-05-07 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.

Changes and Enhancements for VOSpace 2.1

Parameter based sync transfer negotiation

This is a proposal to support the ability to perform a transfer negotiation by posting transfer parameters to the /sync endpoint. This would be functionally equivalent to posting the transfer XML document to the /sync endpoint. For example:

Parameter based POST:

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

Would be 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>

The motivation for adding this functionality is to allow the negotiation of a transfer to happen with a single URL without having a smart client or having to generate an XML document. This is convenient when referring to VOSpace nodes from web interfaces.

Add desired authentication method to transfer document

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:

  • anonymous
  • userid/password basic authentication
  • cookies
  • x509 client certificate
This field should be optional in the transfer document.
Added:
>
>
Update: The IVOA Single Sign-On Profile should be consulted on this, though it is now a bit out-of-date (2008).
 

Link Node documentation clarity

Changed:
<
<
For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.
>
>
For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.:
 
Changed:
<
<

Issues

>
>
  • Example, on the getNode operation, what does view=data mean when the target is a link node? Is it a 'ViewNotSupported' fault or should the link target be resolved and downloaded?
 
Added:
>
>

For future VOSpace versions:

  • In the transfer object, the 'direction' can conflict with the protocol URI. For example, the direction can be 'pullFromVoSpace' and the protocol can be 'HTTP-PUT'. This could be cleaned up to remove error cases.
  • Should VOSpace should have it's own registry extension, VoSpaceRegEx?
 
<--  
-->

Revision 82014-05-06 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.

Changes and Enhancements for VOSpace 2.1

Parameter based sync transfer negotiation

This is a proposal to support the ability to perform a transfer negotiation by posting transfer parameters to the /sync endpoint. This would be functionally equivalent to posting the transfer XML document to the /sync endpoint. For example:

Parameter based POST:

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

Would be 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>

The motivation for adding this functionality is to allow the negotiation of a transfer to happen with a single URL without having a smart client or having to generate an XML document. This is convenient when referring to VOSpace nodes from web interfaces.

Add desired authentication method to transfer document

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:

  • anonymous
  • userid/password basic authentication
  • cookies
  • x509 client certificate
This field should be optional in the transfer document.

Link Node documentation clarity

For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.

Issues

Deleted:
<
<

Parameters for views in negotiated transfers?

One of the elements in a transfer document is the "view" element. If a value for this view is supplied (and it is not the Default View), VOSpace will respond in a way that is specific to that view for the target Node. However, one can imagine views that require input parameters in order to create a sensible response. For example: cutouts. For a cutout view to be implemented, there must be a way for users to provide cutout parameters. Version 2.0 of VOSpace does not allow for input parameters to be supplied to views in transfer negotiations.

 
<--  
-->

Revision 72014-05-01 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.

Changes and Enhancements for VOSpace 2.1

Parameter based sync transfer negotiation

This is a proposal to support the ability to perform a transfer negotiation by posting transfer parameters to the /sync endpoint. This would be functionally equivalent to posting the transfer XML document to the /sync endpoint. For example:

Parameter based POST:

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

Would be 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>

The motivation for adding this functionality is to allow the negotiation of a transfer to happen with a single URL without having a smart client or having to generate an XML document. This is convenient when referring to VOSpace nodes from web interfaces.

Add desired authentication method to transfer document

Changed:
<
<
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:
>
>
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:
 
Added:
>
>
  • anonymous
 
  • userid/password basic authentication
  • cookies
  • x509 client certificate
Deleted:
<
<
 This field should be optional in the transfer document.

Link Node documentation clarity

For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.

Issues

Parameters for views in negotiated transfers?

One of the elements in a transfer document is the "view" element. If a value for this view is supplied (and it is not the Default View), VOSpace will respond in a way that is specific to that view for the target Node. However, one can imagine views that require input parameters in order to create a sensible response. For example: cutouts. For a cutout view to be implemented, there must be a way for users to provide cutout parameters. Version 2.0 of VOSpace does not allow for input parameters to be supplied to views in transfer negotiations.


<--  
-->

Revision 62014-02-27 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.

Changes and Enhancements for VOSpace 2.1

Parameter based sync transfer negotiation

This is a proposal to support the ability to perform a transfer negotiation by posting transfer parameters to the /sync endpoint. This would be functionally equivalent to posting the transfer XML document to the /sync endpoint. For example:

Parameter based POST:

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

Would be 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>

The motivation for adding this functionality is to allow the negotiation of a transfer to happen with a single URL without having a smart client or having to generate an XML document. This is convenient when referring to VOSpace nodes from web interfaces.

Added:
>
>

Add desired authentication method to transfer document

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:

  • userid/password basic authentication
  • cookies
  • x509 client certificate

This field should be optional in the transfer document.

 

Link Node documentation clarity

For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.

Issues

Parameters for views in negotiated transfers?

One of the elements in a transfer document is the "view" element. If a value for this view is supplied (and it is not the Default View), VOSpace will respond in a way that is specific to that view for the target Node. However, one can imagine views that require input parameters in order to create a sensible response. For example: cutouts. For a cutout view to be implemented, there must be a way for users to provide cutout parameters. Version 2.0 of VOSpace does not allow for input parameters to be supplied to views in transfer negotiations.


<--  
-->

Revision 52014-02-06 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.

Changes and Enhancements for VOSpace 2.1

Parameter based sync transfer negotiation

This is a proposal to support the ability to perform a transfer negotiation by posting transfer parameters to the /sync endpoint. This would be functionally equivalent to posting the transfer XML document to the /sync endpoint. For example:

Parameter based POST:

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

Would be 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>

The motivation for adding this functionality is to allow the negotiation of a transfer to happen with a single URL without having a smart client or having to generate an XML document. This is convenient when referring to VOSpace nodes from web interfaces.

Link Node documentation clarity

For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.

Added:
>
>

Issues

Parameters for views in negotiated transfers?

One of the elements in a transfer document is the "view" element. If a value for this view is supplied (and it is not the Default View), VOSpace will respond in a way that is specific to that view for the target Node. However, one can imagine views that require input parameters in order to create a sensible response. For example: cutouts. For a cutout view to be implemented, there must be a way for users to provide cutout parameters. Version 2.0 of VOSpace does not allow for input parameters to be supplied to views in transfer negotiations.

 
<--  
-->

Revision 42014-01-07 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

Discussion page for the VOSpace 2.1 specification

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

Changed:
<
<

>
>
Please edit this page directly to add comments or specification changes and additions.
 
Changed:
<
<
Since this is a minor revision, all changes to the specification must be backwards compatible with the VOSpace-2.0 specification.
>
>
Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.
 
Changed:
<
<

>
>

Changes and Enhancements for VOSpace 2.1

Deleted:
<
<

Enhancements for VOSpace 2.1

 

Parameter based sync transfer negotiation

This is a proposal to support the ability to perform a transfer negotiation by posting transfer parameters to the /sync endpoint. This would be functionally equivalent to posting the transfer XML document to the /sync endpoint. For example:

Parameter based POST:

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

Would be 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>

The motivation for adding this functionality is to allow the negotiation of a transfer to happen with a single URL without having a smart client or having to generate an XML document. This is convenient when referring to VOSpace nodes from web interfaces.

Link Node documentation clarity

For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.


<--  
-->

Revision 32014-01-06 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

Discussion page for the VOSpace 2.1 specification

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


Since this is a minor revision, all changes to the specification must be backwards compatible with the VOSpace-2.0 specification.


Changed:
<
<

Matters arising from IVOA Waikoloa (September 2013)

>
>

Enhancements for VOSpace 2.1

 

Parameter based sync transfer negotiation

This is a proposal to support the ability to perform a transfer negotiation by posting transfer parameters to the /sync endpoint. This would be functionally equivalent to posting the transfer XML document to the /sync endpoint. For example:

Parameter based POST:

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

Would be equivalent to:

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

Where job.xml is a file containing:

Changed:
<
<
<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>
>
>
<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>
 
Changed:
<
<
The motivation for adding this behaviour is to allow the negotiation of a transfer to happen with a single URL without having a smart client or having to generate an XML document. This is convenient when referring to VOSpace nodes from web interfaces.
>
>
The motivation for adding this functionality is to allow the negotiation of a transfer to happen with a single URL without having a smart client or having to generate an XML document. This is convenient when referring to VOSpace nodes from web interfaces.
Deleted:
<
<

Deprecation of view=data

 

Link Node documentation clarity

Added:
>
>
For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.
 
<--  
-->

Revision 22014-01-06 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

Discussion page for the VOSpace 2.1 specification

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


Since this is a minor revision, all changes to the specification must be backwards compatible with the VOSpace-2.0 specification.


Matters arising from IVOA Waikoloa (September 2013)

Parameter based sync transfer negotiation

This is a proposal to support the ability to perform a transfer negotiation by posting transfer parameters to the /sync endpoint. This would be functionally equivalent to posting the transfer XML document to the /sync endpoint. For example:

Parameter based POST:

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

Would be equivalent to:

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

Where job.xml is a file containing:

Changed:
<
<
<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>
>
>
<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>
 
Added:
>
>
The motivation for adding this behaviour is to allow the negotiation of a transfer to happen with a single URL without having a smart client or having to generate an XML document. This is convenient when referring to VOSpace nodes from web interfaces.
 

Deprecation of view=data

Link Node documentation clarity


<--  
-->

Revision 12014-01-03 - BrianMajor

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

Discussion page for the VOSpace 2.1 specification

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


Since this is a minor revision, all changes to the specification must be backwards compatible with the VOSpace-2.0 specification.


Matters arising from IVOA Waikoloa (September 2013)

Parameter based sync transfer negotiation

This is a proposal to support the ability to perform a transfer negotiation by posting transfer parameters to the /sync endpoint. This would be functionally equivalent to posting the transfer XML document to the /sync endpoint. For example:

Parameter based POST:

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

Would be 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>

Deprecation of view=data

Link Node documentation clarity


<--  
-->
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback