Metadata Distribution Subcommittee of TAC

["Joe St Sauver" <>]

Hi,

Scott helped me out by sharing this URL for the latest draft:

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

I feel better that it only popped out August 16th (my perenial
nightmare is that there's a huge stream of new protocols floating
downstream, and I've missed a key cupfull of content from that 
flood as I crouch by the edge of the bank :-))

That said, reading through the text of that draft, here's my 
quick reactions (as a non-insider/explicityly unclued outsider):

-- 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 canonical draft.

-- 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.

I don't know Ian, and I'm not active in the working group for this
draft, but if any of you are inclined, you have my permission to share
the preceding with him (but obviously you should equally feel free to
let the above nits just float downstream, particularly if we're not
looking at using this spec as part of the InCommon MD distribution
effort)

Regards,

Joe