<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Tom,<div><br></div><div>if it was broken for UWS, then it would be broken for all dynamic content produced by any web server, of any kind, anywhere. Please stop scaremongering. UWS works, without caching problems, in several implementations. Dynamic content works, and we don't have to mess around with HTTP details to make it work. What does <i>not </i> work is misusing HTTP get to change state "because it's simpler".</div><div><br></div><div>Guy</div><div><br><div><div>On 3 Nov 2009, at 14:46, Tom McGlynn wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>By the by, presumably this issue of whether we can count on getting an up to date version of a UWS resources accessed via a GET call applies not just to the job list but to any resource called by GET. They are all dynamic. The phase request in particular seems designed to be called repeatedly in a loop and might be especially liable to caching. So this needs to be resolved clearly. The text that you quoted suggests that the proposed UWS standard is on pretty thin ice and that we are relying on the vagaries of current server implementations. I was surprised that CGI like requests are specifically exempted from being cached so that they are not subject to this unless the user explicitly sets a future date for expiration. Perhaps going back to a more CGI like syntax<br><br> $rooturl/$jobid?phase<br>rather than<br> $rooturl/$jobid/phase<br><br>should be considered since that seems to get the HTTP standard a little closer our side. Or warn users to specify $rooturl/$jobid/phase?junk if they wish to be careful about avoiding caching.<br><br>Though I'm not sure that's really enough since even for a CGI-like GET there's nothing that the current standard says that precludes a service from setting an expiration date in the future. It seems that to do any GET requests properly the protocol needs to say something more proactive to ensure that caching is turned off.<br><br><br><span class="Apple-tab-span" style="white-space:pre"> </span>Regards,<br><span class="Apple-tab-span" style="white-space:pre"> </span>Tom<br><br><br>Tom McGlynn wrote:<br><blockquote type="cite">I can't really see the difference here between the create case (i.e., my<br></blockquote><blockquote type="cite">use of GET to create a job) and the job list case. In fact the text you<br></blockquote><blockquote type="cite">quote seems to suggest that the job list is more likely to be cached<br></blockquote><blockquote type="cite">than a job creation request with parameters.<br></blockquote><blockquote type="cite">In both cases we start out with some URL (in fact the same URL for both<br></blockquote><blockquote type="cite">cases). There are two differences in the processing at that HTTP sees:<br></blockquote><blockquote type="cite">The return code is different (303 for a creation versus 200 for a job<br></blockquote><blockquote type="cite">list). There is nothing that I know of in the HTTP protocol that<br></blockquote><blockquote type="cite">suggests that a 200 is less likely to get a Expiration time header<br></blockquote><blockquote type="cite">associated with it than a 303 (or more likely for that matter).<br></blockquote><blockquote type="cite">The more significant difference is that the job creation URL is going to<br></blockquote><blockquote type="cite">have job creation parameters (well at least for me!). That suggests --<br></blockquote><blockquote type="cite">looking at the text you quoted below -- that it is less likely to have a<br></blockquote><blockquote type="cite">problem with an expiration time being associated with it. It's the job<br></blockquote><blockquote type="cite">list that is more likely.<br></blockquote>-- I got slightly confused here in discussing the consequences The expiration time header is a side issue. The question is whether the server (or some proxy in the path) is allowed to cache. The words below suggest it is for a URL that does not include ? (e.g., a request to list the jobs or get the current phase) when either there is no expiration date or the expiration date is in the future. For CGI like requests with parameters, caching is allowed only when there is an expiration date in the future.<br><blockquote type="cite">Now you may be entirely correct that the servlet containers that you've<br></blockquote><blockquote type="cite">used take care of this very nicely. But it doesn't sound like it's<br></blockquote><blockquote type="cite">required by the protocol. So to ensure that users get an up to date job<br></blockquote><blockquote type="cite">list I think the protocol needs to specify that any job list specify an<br></blockquote><blockquote type="cite">immediate expiration to disable caching - the very details that you were<br></blockquote><blockquote type="cite">leery of below.<br></blockquote><blockquote type="cite"> Regards,<br></blockquote><blockquote type="cite"> Tom<br></blockquote><blockquote type="cite">Guy Rixon wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">FWIW, this is the passage in RFC 2616 that restricts the use of GET for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">state-changing requests:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> 13.9 Side Effects of GET and HEAD<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Unless the origin server explicitly prohibits the caching of their<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">responses, the application of GET and HEAD methods to any resources<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">SHOULD NOT have side effects that would lead to erroneous behavior if<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">these responses are taken from a cache. They MAY still have side<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">effects, but a cache is not required to consider such side effects in<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">its caching decisions. Caches are always expected to observe an origin<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">server's explicit restrictions on caching.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">We note one exception to this rule: since some applications have<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">traditionally used GETs and HEADs with query URLs (those containing a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">"?" in the rel_path part) to perform operations with significant side<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">effects, caches MUST NOT treat responses to such URIs as fresh unless<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the server provides an explicit expiration time. This specifically means<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">that responses from HTTP/1.0 servers for such URIs SHOULD NOT be taken<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">from a cache. See section 9.1.1<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1">http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1</a>> for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">related information.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Reading the details of this, we /could /have written UWS to start<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">queries using GET, but then we'd have to qualify it with "and then you<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">must do x, y and z with the response headers to turn off caching". This<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">is extra work for the implementor and quite unecessary because a POSTed<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">request is naturally uncached. Creating a sub-resource is exactly what<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">POST is for.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The particular caching cock-up I had in mind works like this:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">1. You GET the job list with query-starting parameters.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">2. The service starts a query and returns 303 "See other" redirecting to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the new job<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">3. The web server tacks on some default cache-expiration because, hey,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">it's a GET response and we're suppose to cache those.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">4. You GET the job list again with parameters for another query.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">5. The web-cache sends you back the 303 for the first query and the TAP<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">service never sees the request.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Maybe this only catchs you out if the queries in steps 1 and 4 are the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">same - i.e. same URL including query string. Not sure about the details<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">there...meaning that it's subtle and scary and dangerous to depend on<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">this kind of usage. On the other hand, using POST makes it 100% certain<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">that the cache won't swallow your request.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">In respect of job lists getting cached what sees to happen with Java is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">this: when you GET a response from a servlet or JSP, everything works as<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">expected with dynamic content; you never seem to get a stale page.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">However, when the same servlet engine delivers a static HTML page, or a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">CSS stylesheet or (particularly) and XSLT for in-browser transformation<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">then it caches like hell and you can easily miss updates. (This bit me<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">repeatedly when I was setting up the browser-side styling of the job<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">resources for my TAP implementation.) Something in the servlet engine<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">seems to know when the content should be dynamic and adjusts the HTTP<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">headers appropriately.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Cheers,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Guy<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On 2 Nov 2009, at 16:56, Tom McGlynn wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Guy Rixon wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Tom,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">if you want to get the job list then go ahead and do HTTP-GET. That's<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> part of UWS (although implementations may restrict the set of you<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> reported to be those owned by the caller). What you can't do is use<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> HTTP-GET to submit a query via UWS. If you want to use GET to do a<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> query then you're doing a synchronous query by definition.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Cheers,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Guy<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">But I recall from earlier in this discussion some clever fellow said...<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">GET responses can be cached, and the caching is out of your control<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">as a service provider - it may be on the user's LAN (HTTP proxy) or<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">in their client (browser cache). If you send the same query twice<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">then via GET,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">for the second request you could get the response for the first,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">pulled from the cache,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">and no new job.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">If what you said earlier is correct, then I can't rely on what I get<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">back from a GET call. I might be getting a cached response and not<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the current state of the system. If caching is truly an issue, then<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">there doesn't seem to be any reliable way to get the job list.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Tom<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On 2 Nov 2009, at 14:13, Tom McGlynn wrote:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Paul Harrison wrote:<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Guy has already done a good job of answering most of these points - I<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The UWS design of the two stage process is for two principal reasons<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">a) to be able to manipulate job metadata parameters before the job is<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">run - e.g. the DestructionTime - and receive the feedback from the<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">service whether it is prepared to honour such requests before actually<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">committing the job.<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">b) to allow complete parameter namespace freedom on the job creation<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">step - i.e. if PHASE is used by UWS then it could not be a parameter<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">for the implementation protocol.<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">So if for a particular implementation using UWS there is no problem<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">with meeting that second condition, then there is no particular reason<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">why job metadata parameters could not be included with the initial UWS<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">job creation step if desired - this would require revision of the UWS<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">specification to include this possibility - I think that this is a<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">small enough change to be added into the document as part of the RFC -<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">it does have a larger impact on possible service implementers however<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">- their code might not be structured to allow this change easily. For<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">a generalized UWS client the change would not be so great, all that<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">would happen is that after the initial submission a job object would<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">be returned with the PHASE=EXECUTING, and general clients should not<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">make any assumptions about state in their coding, so should probably<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">still be able to react appropriately.<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Just as a side note to show that UWS is not so strange in this<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">multiple interaction between client and server - consider what happens<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">when a web browser loads a web page - it does the initial get of the<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">html, then parses this html and then gets images, javascript etc.<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">before the page is shown to the user.<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I trust the goal is not to require that UWS services need to have<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> the complexity of an interactive visual Web browser. The protocol<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> should cater to simple applications as well.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I'd be perfectly happy with a change that made it clear that the<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> request that created the job could return it in any state. In<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">fact, even without the desire to be able to start jobs at creation,<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">that is probably needed to accommodate the situation where there is<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">a problem detected in creating the job but we want the user to be<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">able to parse the error with IVOA protocol level error handling.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The specific text that I find problematic is in 2.1.3:<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">PENDING: the job is accepted by the service but not yet committed<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> for execution by the client. In this state the job quote can be<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> read and evaluated. This is the state into which a job enters when<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> it is first created.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">in conjunction with<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">2.2.3.1 Creating a job.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Posting a request to the job list creates a new job (unless the<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> service rejects the request).<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I would suggest something like the following changes<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">-<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">In 2.1.3 add somewhere<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> Phases are ordered with PENDING before QUEUED, QUEUED before<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> EXECUTING and EXECUTING before the trio of COMPLETED, ABORTED and<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> ERROR. The state of a job may change only to a later state but<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">need not pass through any intermediate state. A job may be created<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">in any state.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">-<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Delete the last sentence in the definition of PENDING.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">-<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I think it would be desirable to suggest how a job could be created<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> in the run state even if this is not required by the standard It<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> would be possible to do this without polluting the parameter name<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> space by specifying a new URI for that. E.g., ${jobs} creates a<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">new request but does not start it. ${jobs}/run could create and<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">start the job if that is permitted in the given service. However I<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">find the worry about pollution of the parameter name space less<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">than compelling, since we require certain parameters to be used in<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">calls to start the job running or to alter other aspects of the<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">job. It would be poor practice to have phase= mean one thing in a<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">job creation request and mean something else in a job update<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">request. In effect, these parameters are reserved already.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">This discussion brought up another thing that's not really clear.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> 2.2.3.1 has the little parenthetical phrase "(unless the service<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> rejects the request)" which is neither explained, nor is the action<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> implied in rejection specified. I think something like:<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> Errors may occur in the creation of the job. Where possible a job<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> should be created in the ERROR phase with a error message that<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> describes the problems. If this is not possible, an HTTP 500 error<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> must be returned.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">would be clearer for implementation and should replace that phrase.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Finally, one new issue/concern. [This probably reflects a lack of<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> understanding on my part but if so then perhaps it could be<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> clarified in the standard.]: It doesn't seem like there is any<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> valid way to get the current job list.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I can't do a GET request for /{$jobs} because that's cacheable and<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> the list is dynamic. And I can't do a POST request for it since a<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> post to /{$jobs} means that I'm creating a new job and I'm supposed<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> to be redirected to the job information for the newly created job.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">So how do I get to it?<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">In my TAP implementation I assume that any request to create a new<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> job needs to have a REQUEST= parameter and if I don't see this I<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> return the job list. If I do, I create the new job. However this<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> doesn't seem to be literally correct. I suppose you could say that<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> I'm 'rejecting' the request and since that behavior is undefined I<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> can do anything I want. Relying on undefined behavior doesn't seem<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> satisfactory.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Tom<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote></div></blockquote></div><br></div></body></html>