[mdx] Feedback on https://datatracker.ietf.org/doc/draft-young-md-query/

[Joe St Sauver]

Hi,

Recently had the chance to eyeball 

  https://datatracker.ietf.org/doc/draft-young-md-query/

a little. Ian encouraged me to join the list and share my feedback 
directly (looking at the archives, I see some familiar faces :-)). 

My feedback (as a total outsider and clueless newb, take it for what
you will or ignore it entirely, you won't hurt my feelings either way):

-- 2.1 requires ("MUST") use HTTP version 1.1 per RFC2616, but 5.1
   urges ("RECOMMEND[S]") use of SSL/TLS at the transport layer, 
   among other possible options. Does the requirement for HTTP 1.1 
   per RFC2616 preclude SSL/TLS per RFC5246? 

   Will the 2.1 specific requirement that HTTP 1.1 *in particular* 
   be used become problematic as the HTTP spec evolves? For example,
   I notice that the HTTPbis Working Group actually kicked out a 
   dash 6 rev for the HTTP v2 spec just yesterday, see
   http://www.ietf.org/id/draft-ietf-httpbis-http2-06.txt (so I'm
   hopeful that at some point we'll move beyond RFC2616)

-- 2.2 specifies that "all metadata retrieval requests MUST use
   the GET method" -- would this preclude the normal use of HEAD
   as an alternative to test for changed data, etc.?

-- 2.5 appears to just recapitulate status codes from RCC2616. If
   so, rather than repeat them verbatim in this draft, I'd suggest
   that a reference simply be made to the appropriate section of 
   the RFC.

-- 2.6, Base URL: does the base URL terminate with a / ? If no
   trailing slash is specified, is one imputed/supplied?

-- 3.1, Identifiers: Prohibits an identifier starting with a left
   curly brace, but is silent about other potentially magical
   characters such as plus signs... (I assume that's because 3.2.1
   specifies that the identifier "must be properly URL encoded" but
   that requirement should really be part of of 3.1, not 3.2.1,
   shouldn't it?

-- 3.1.1, Transforms: are the identifiers case sensitive? That is,
   'md5' is mentioned as is 'sha1' -- is that equivalent to 
   'mD5' and 'Md5' and 'MD5', for example?

   As a wanna-be crypto guy, I also have some concern about 
   a newish spec specifying deprecated hashes (e.g., MD5 should
   really not be re the required "lowest common denominator"
   required transform for this or any other purpose)

-- 3.2.1, Reqest: How long can a request be? Hypothetically, what
   if I have a laundry list of a thousand IDs, all transformed into
   SHA1 hashes? That could make for a long request!

   In 3.2.1, are the curly braces around the IDs literal curly braces
   or is that just a semantic representation issue?

   I'd also prefer to see specificity wrt what happens for an ill-formed
   request (e.g., an unterminated or otherwise malformed ID value, for 
   example, on a query that requests multiple IDs -- should the query
   fail, or should partial results be returned or ?)

-- 4.3, Content Compression: nice to see gzip mentioned 

-- 5.1, Integrity: Seeing that an integrity check is only RECOMMENDED
   rather than REQUIRED bothers me, a lot. I think this is a fundamental
   mistake. Content integrity checks should be MANDATORY IMHO.

-- 5.2, Confidentiality: The recommendation that requester and 
   responder support "SSL/TLS" both in 5.2 and in 5.1 is insufficiently 
   specific (I know, I beat up on the document for being TOO specific 
   about the HTTP 1.1 aspect, and now I whine about it being too vague 
   on the SSL/TLS aspect, sometimes you just can't win :-)). 

   The reason why I flag the issue of SSL/TLS spec is that there's a 
   huge, huge, difference between early versions of the SSL/TLS spec
   and later versions. I'd really like to see a push for 1.2 (or 
   later, if we want to worry about what happens in the future) if at
   all possible

-- 5.3, Authentication: Authentication appears to be optional, should
   it be? I'd also love to see support for something better than just
   HTTP basic and client certs, although I recognize the potential for
   recursive dependencies if you're trying to retrieve metadata about
   auth options, and you need to auth as part of that, etc.

Thanks for the chance to offer feedback on this, and thanks for all
the work that folks have already done on this.

Regards,

Joe