dave at ast.cam.ac.uk
Wed Jun 14 07:31:06 PDT 2006
Paul Harrison wrote:
> well I did not see you rigorously using URIs in your comments about
> http-put etc. above - it is not natural.
Your are right, in an email to a human, it isn't natural.
However, it is useful when you want to be very precise about what you
are referring to.
> In general I am in favour of using registry entries to describe
> something that could possibly be machine understood and interpreted,
> so if you can come up with a registry entry that could describe an
> arbitrary transport protocol I would support mandating that the
> transport name be a URI
Personally, yes, I would like work towards defining an extension of
VoResource for protocols, web service interfaces and data types that
would enable us to register them properly.
However, I don't think we are quite ready for that yet.
> otherwise a simple string name is sufficient.
I'm not arguing for full IVOA registry URIs.
I know that many people have valid objections to them, not least of
which is how and where they are registered.
Defining them as xsd:anyURI in the WSDL does not mandate the ivo://.....
We could choose to use a URN syntax for the initial set of core
protocols if you want.
However, xsd:anyURI leaves it open for us to use the ivo://... syntax to
point to a resource document describing the details of the protocol if
we want to.
It would be useful to be able to distinguish between HTTP get and HTTP
put (a service may accept un-authenticated get but require a signed SOAP
message for a put).
It would be useful to be able to distinguish between HTTP-1.0-put
(requires content-size) and HTTP-1.1-put (accepts chunked without
I would need a way of registering the ability to receive chunked data as
a specific capability in a VOSpace service registration.
It would make sense to use the same URIs or URNs for registering
protocol capabilities in the service registration document and the
protocol selection in the SOAP messages.
> I think that mandating that http be a supported protocol
A data center with a large collection of public images would want to use
plain http get, and would probably not want to implement DIME or MTOM.
A database service that allowed users to upload data directly into their
database would probably not accept un-authenticated http-put, and would
require a signed SOAP message with the data in a DIME or MTOM attachment.
> (and defining what exactly we mean by that) would not be too
> burdensome on implementations.
A reference to http://www.w3.org/Protocols/rfc2616/rfc2616.html would work.
However, based on our experience, a standard servlet in Apache Tomcat on
JDK 1.4.x does not support chunked data properly.
Arguing over the details of HTTP-put is a side issue.
I would like to make the specification open enough so that we can
define, describe, and use, a new transport protocol (srb://?) without
having to change the VOSpace specification.
An initial list of core protocols is a good idea.
I'm not convinced that they should be mandatory.
We do need a precise way of referring to them, not just the common name
e.g. 'http', but something that can distinguish between versions and
URN style names if you want
urn:vospace:protocols:http-1.1-put (implies full implementation of
the spec. including chunked data)
Or, URI/URLs that point to something that describes the details of what
each one means.
Defining the parameter as xsd:anyURI in the WSDL is a start, then we can
argu^^ discuss which ones go in the core list, and which if any are
More information about the vospace