TAP Implementation Issues (cont'd)

[Tom McGlynn]

>> What is the appropriate value of REQUEST for async requests that do
>> not create the query?  The document indicates:
>>    A TAP client must set this parameter correctly in every request
>>    (GET or POST) to /async or /sync web resources.
>> I take this as meaning that invoking something like
>>   http://mytap/async/phase
>> needs a REQUEST.  If it means something else it needs to be clarified.
>>
>> 2.3.2/2.8 The whole version and version negotiation framework seems complex 
>> and ill defined.  E.g., what is the version of TAP that this document refers 
>> to.  I'm guessing that it's '1.0' but perhaps it 'TAP 1.0' or whatever. 
>> Specific examples of the strings to be used, especially the string that 
>> specifies the current standard is required.  There's supposed to be some 
>> sense of compatibility between versions x.a and a.b generally within the IVOA 
>> framework, but how that is to apply here is not discussed.
>>
>> It is also unclear what a user is required to do.  E.g., can a data provider 
>> simply ignore this parameter.  In 2.8.2 there is a statement that the service 
>> 'declares the version it supports' but it's not clear to me how that is done.
>>
>> In 2.8.3 there is a phrase "does not match a version available from the 
>> service at level two". I have no idea what this is.
>>
>> Overall I'd recommend -- especially since this is the first version of the 
>> document -- that there should be a statement to the effect to the effect...
>>
>>   "Services must accept the VERSION parameter but may ignore it."
> 
> I don't think we want to start down the path of services supporting but
> ignoring the VERSION parameter.  The main purpose of this parameter is
> to provide strong checking against a runtime protocol version mismatch.
> A secondary purpose is to allow selection of the version to be used
> if the service implements multiple versions.  This mechanism was
> adopted from minor changes from the OpenGIS standards, and is also
> already used in SSA.
> 
> If the protocol version is explicitly specified by the client but
> is a version not supported by the service this is a hard error and
> the client gets an error response (if this is not what the client
> wants it does not specify VERSION).  The value is supposed to be a
> string such as "1.0".  It may well be that the details need further
> clarification in the spec but the mechanism is fairly simple.
> 
>  	- Doug
> 
One thing that my typo's may have obscured is the issue of upward
compatibility.  There has been a general IVOA statement that version
1.n+1 in somehow compatible with version 1.n.  If I have a client that
is requesting 1.1 but the service only supports 1.2 is that OK?  Or
vice versa?  If no to both, then what do we mean by compatibility 
between minor version numbers?  Or are we simply ignoring that precept here?

Regardless the specification does not indicate how a service indicates
which version it supports and I still have no idea what "level two" is.
Are there any SSA services that actually do anything with this or is it 
something that seems like a good idea but nobodies actually using?

	Tom