DALI comments

[Markus Demleitner]

Dear DAL,

Last mail for today, promised.

On Mon, Feb 29, 2016 at 03:46:31PM -0500, Tom McGlynn (NASA/GSFC Code 660.1) wrote:
> While I'm often agnostic on the merits of most of Markus' recent comments on
> the DALI specification, they have at least prompted me to read the document

:-)  Well, I tend to agree with most of Tom's points and choose to be
agnostic on some others, except:

> 7. We should be specific about how we pass in parameters.  We are are
> assuming the standard CGI formats when we use the '=' notation latter on.
> So just call it out.  [I don't know if there is a formal reference for this
> but it should be referenced if appropriate.]  If you don't

I guess the authoritative reference here is HTML5,
https://www.w3.org/TR/2014/REC-html5-20141028/, section 4.10.1.3.
AFAIK, there's no better place for the key=value thing in URIs.  RFC
3986 at least doesn't say anything about the structure of the query
part.

> 13. I find the discussion of VOTable encodings a bit out of place but I'm
> not sure why.  I wonder if this structure is causing some contortions.  If
> we separate the parameter encoding and the VOtable encodings, then we've no
> problem allowing a single values numeric parameter to be interpreted as a
> range.  I.e., user specifies
>     band=1
> which get's interpreted as band=1 1 so that the current discussion (in other
> DAL email) of array=2 versus array=2* is moot.

I'm very much in favour of coupling as much of our parameter parsing
to VOTable for three reasons:

(a) several protocols base their parameter declaration on VOTable
PARAMs, and hence the VOTable type system is more or less implied

(b) Such PARAMs can have @value-s, which are to be parsed using
VOTable TABLEDATA defintions.  It'd be unfortunate if one would have
to use two different parsers for parameters in such values and those
that come in through the web

(c) Almost every piece of software in the VO probably has some sort
of TABLEDATA-aware value parser.  Simply re-using that for the
parameters reduces code size in a particularly evil and bug-ridden
place (parsing arbitrary user input).

> 12.  I can't follow what 3.4.2 is saying.

[This is about dropping support for VERSION] -- well, I guess most
implementors found that supporting multiple, incompatible versions of
a protocol on one endpoint using VERSION has so many snags that it's
not worth it in practice.  Perhaps  that could be said a bit more
clearly, but I certainly second giving up on explicit version
negotiation, at least as part of DALI.  Thinking up something like
HTTP's versioned requests might help, but we'd need much more
experience what's a good idea here and what's not.

> 14.  Aaargh.  I do have a substantive comment.  The discussion of 3.4.4
> allows MAXREC to fail because there is no data matching the request (as I
> read it) or to succeed regardless.  I don't think this is right.  Either it
> should be a way of getting the metadata regardless of whether there is
> matching data, or it should always check that there is matching data and use
> the overflow indicator to indicate whether any data was found (i.e., if
> there would be data, then the overlow is set to yes).

The way I read this, "fail" here means "include an
QUERY_STATUS=ERROR".  The metadata would still be present, I hope.

But yes, this should be clarified.

> 
> 15.   The discussion in 3.4.5 is confusing.  We first say we would have this
> parameter
>     UPLOAD=table3,param:t3
> and this content where we then put multipart-form data in great detail.

Yeah, I'm not a great fan of repeating stuff on multipart/form-data
in this document.  +1 for just referencing that material from
somewhere else (HTML5 these days, I guess).

> 18.  I'd suggest the Content-type be mandatory.  Not sure I care about the
> others http headers.

I had argued for all language on HTTP headers to be dropped.  This
remark actually made me look again.  It turns of the RFC 2616 (HTTP
1.1) has this language (sec. 7.2.1):

  Any HTTP/1.1 message containing an entity-body SHOULD include a
  Content-Type header field defining the media type of that body. If
  and only if the media type is not given by a Content-Type field, the
  recipient MAY attempt to guess the media type via inspection of its
  content and/or the name extension(s) of the URI used to identify the
  resource. If the media type remains unknown, the recipient SHOULD
  treat it as type "application/octet-stream".

Yikes!

So, I correct my previous suggestion.  The material between "The
service should set the following HTTP headers..." up to and including
the table should be replaced by:

  In addition to following HTTP's rules on required and recommended
  headers (RFC 2616 or later versions as appropriate), DAL responses
  MUST always have a non-empty Content-Type header containing a
  well-formed RFC <whatever> media type.

Cheers,

         Markus