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

[Cantor, Scott]

On 8/23/13 4:33 AM, "Leif Johansson" <leifj at sunet.se> wrote:
>>-- 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.?
>Agree. Lets describe the use of the HEAD method for cache
>validity checks.

-1

We don't need HEAD to do cache checks, and that just adds multiple ways of
doing the same thing.

>> -- 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.
>Also good point.

Disagree. We're defining what the codes mean in our context here.

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

No, it's precluding the brace because it has special meaning. The encoding
of the character should be irrelevant here. We're talking about the
decoded value not being a brace.

>>-- 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?
>They should be case-insensitive.

I'd prefer not. URLs are case sensitive, and I'd rather not introduce
folding requirements.

>>    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)
>We should do a threat-analysis....

We're not using the hashes for security here, so I doubt there's much
concern.

>> -- 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!
>... or sha256

There really is no clean way to address URL length that I've ever seen.

>>    In 3.2.1, are the curly braces around the IDs literal curly braces
>>    or is that just a semantic representation issue?
>cf note about needing to discuss {} above

It's a specification of the actual character, after any decoding.

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

The reason it wasn't required is for protocols like OpenID and OAuth. We
were trying to be general and not limit this to SAML and our use cases.

-- Scott