UWS draft comments

[Paul Harrison]

On 2014-10 -17, at 10:58, Mark Taylor <M.B.Taylor at bristol.ac.uk> wrote:

> Hi Paul et al.
> 
> I have some minor comments about the current unpublished UWS 1.1 draft.
> 
> I have already fixed a small number of tiny typos in volute (r2750).

Thanks for those.
> 
> Other items:
> 
> sec 2.1.3:
>   Diagram lacks ARCHIVED phase

I had not got round to doing this as the license has expired for the package that I used to draw the original diagram. I will redraw the diagram from scratch.
> 
> sec 2.2 (2.2.2?):
>   I would like clarification of whether whitespace is permitted
>   in text/plain REST endpoints, e.g. {jobs}/(job-id)/phase -
>   see my email on the grid list:
>   http://mail.ivoa.net/pipermail/grid/2014-September/002648.html
>   As far as current practice goes (which you may or may not wish
>   to endorse), my experience is that most services return exactly
>   the required string, but the ESAC GACS service appends \r\n to phase.

I think that the original intent was that there should be no whitespace, however, given that XML responses are basically allowed whitespace freedom, my personal feeling would be to say that the text/plain responses should be equal to the given strings after whitespace stripping.
> 
> sec 2.2.1:
>   last cell in table says "an appropriate identifier as discussed in
>   in section 3".  It's not really discussed in section 3 (though it
>   would be nice if it was).

There was a deliberate policy of devolving as much as possible of this to the SSO document, as it was clear that authentication recommendations would be changing as technology popularities changed - I think that I do not really want to change this policy very much especially on the point of what form the identifier might take. As we discussed at the Interop there could perhaps be an acknowledgement that some other form of identifier (e.g. cookies) that was not strictly an IVOA standard could be used, but I would want to be careful, as there is a danger of making interactions with services confusing if there is some passive (e.g. cookies) as well as active identification/authentication occurring simultaneously. I do agree that this is a matter of some urgency on improving the usability of authentication of IVOA services in general, though I would not want this point to delay a UWS 1.1 unduly though.
> 
> sec 2.2.1.1:
>   "UWS 1.1 introduces blocking behaviour where the server may not
>    return the result of a request immediately (i.e. block) ..."
>   A bit ambiguous.  Reword "... the server may defer returning the
>   result of a request (i.e. block) ...” ?

your wording is much better ;-) I had been drawn into rfc2116ese

> 
>   "A client that is UWS1.1 compliant should also be aware that
>    it will receive immediate responses if it attempts to perform
>    this operation on a UWS 1.0 server."
>   - add a note here about how the client can determine server version?
>   Or don't we know yet?  In any case this functionality is unusable
>   unless the client can reliably determine that it is talking to a
>   1.1 UWS service.

I think that it can be determined by the VOSI standardID for a pure UWS. However, there is still a slight grey area for what the best VOSI practice is for services that use UWS patterns as a component of the overall service- I think that this probably needs to be considered more widely in perhaps an update to the VOSI document.

> 
> sec 2.2.2.1:
>   "The list may be empty if the UWS is idle."  Reword?  Idle sounds
>   like it means it's not running any jobs currently, not that it has
>   no records of any.
> 
Agreed - I will reword. 

I have made another edit of the document in Volute with some of the unresolved issued highlighted in yellow.

Paul.