On 14.06.2006, at 13:35, Dave Morris wrote:
> Paul Harrison wrote:
>
>> I am also against the use of URIs in many of these cases .... for
>> things like the transport protocol it is far better to use the
>> common well-known name for the protocol e.g. ftp rather than
>> introducing an indirection layer for the name via a URI, so that
>> people can immediately use their domain knowledge to recognise
>> what is being referred to.
>
> The 'http put' transfer is a good example of why the specification
> uses URI rather than just the 'well-known names' for protocols.
> There are several ways to send data using HTTP.
> The two main forms are :
>
> http-put
> http-post
>
> Based on our experience with VOStore and AstroGrid MySpace, we also
> need to distinguish between services that can accept chunked data
> in a http-put call.
> A standard http-put call sends the data size in the header, which
> means that the client has to buffer all of the content to calculate
> the size before it sends the data.
> Sending data using http-put in chunked mode does not require the
> data size in the header field.
> However, not all server implementations can accept chunked data
> (even though they claim to implement HTTP-1.1), so we need to be
> able to distinguish between services that can accept chunked data,
> which gives us three variants of http-put.
>
> http-post
> http-put
> http-put (chunked)
>
all of these should be supported to qualify for being a http1.1
transport - to my way of thinking unless it supports everything it is
not compliant. A web browser talks "http" - it is a client
configuration that allows it to try for specialized features and the
the protocol itself has flags to say which version is being used.
> We may also need to distinguish between services that accept http-
> put with data compression (zip, gzip etc.) and different forms of
> authentication.
> If we used the 'well know name' for protocols, all of the above
> could be covered by 'http'.
> DIME and MTOM attachments also have two main variants.
> The data can be attached to the original VOSpace message, which
> would not require a separate URL to send the data to.
>
> dime-put (this message)
>
> Or, it could be sent in a separate SOAP message, which would
> require information about the target service, the endpoint URL and
> some form of identifier.
>
> dime-put (other) +wsdl, endpoint, ident
This second is a web service in itself - it would need an entire IVOA standard to cover it, and what's more I cannot really see a good use case for it.
>
> There may be other forms which 3rd party developers want to add;
> all based on the core http protocol, but using different data
> handling and authentication methods.
This could go on ad absurdam - each implementor could find a list of areas where his server does not follow the HTTP standards properly, or wants some other variation and invents a new "Transport" and we end up in the situation where VOSpaces cannot transfer data between each other because they have no transports in common - we have to specify a base set. We do not want a situation where the VOSpace 1.0 standard is so open-ended that two people can implement a server that is compliant with the standard, but cannot interoperate. The core of the standard needs to enforce some aspects, as we know from experience with other IVOA standards, that when writing clients that talk to several services, the only practical approach is to rely on only the mandatory parts of the standard, because that is all that the majority of services will have implemented, no matter how appealing/useful some of the optional parts are.
> The reason for identifying these using a URI, particularly an
> ivo://... registry URI is that it gives us somewhere to put a
> description of the protocol.
>
> For example :
> http://galahad.star.le.ac.uk:8080/astrogrid-registry/
> viewResourceEntry.jsp?IVORN=ivo%3A%2F%2Forg.astrogrid.vospace%
> 2Fprotocols%2Fhttp-put
> http://galahad.star.le.ac.uk:8080/astrogrid-registry/
> viewResourceEntry.jsp?IVORN=ivo%3A%2F%2Forg.astrogrid.vospace%
> 2Fprotocols%2Fhttp-put-chunked
>
> I appreciate that using registry resources to describe the
> protocols is contentious, which is why the specification defines
> protocol and format parameters as a URI and not an IVOA registry URI.
> If people don't want to use IVOA registry URIs, then we could use
> the http URL of the protocol specification.
> If someone wants to use a different form of DIME web service to
> receive data, then the URI could point to the service specification
> or WSDL.
> The point is that in much the same way as people use namespace URIs
> in XML schema, the protocol URI is not just a text string, it can
> be used to point to something that describes the specific protocol.
well I did not see you rigorously using URIs in your comments about http-put etc. above - it is not natural. 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, otherwise a simple string name is sufficient. I think that mandating that http be a supported protocol (and defining what exactly we mean by that) would not be too burdensome on implementations.
>
> This was discussed both before and during the Canada meeting, and
> no major objections were raised at the time.
In the jabber I had with you before Canada I raised exactly these objections...
> Which is why the v0.21 document specifies protocol and format as
> URI, with examples of IVOA registry URIs.
> If you want to change this to an enumeration of strings, then we
> need to go back and modify the document.
we have to modify the document anyway - there are lots more issues... Received on 2006-06-14Z14:47:03