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

[Cantor, Scott]

On 9/9/13 4:05 AM, "Leif Johansson" <leifj at sunet.se> wrote:

>That assumption (that most HTTP clients are just low-level libraries)
>certainly isn't true for a lot of languages. In python there are at
>least 3 perfectly reasonable choices and at least 2 of them try to
>ask the dev to make fewer choices. Isn't that nice :-)

The history of defaults in HTTP clients isn't a very confidence-inducing
one, but I'm writing the client side of this, so as long as there's no
requirement on me to support HEAD, I will leave it to the server-oriented
people to weigh in.

>Again I agree but I believe in practice you'll see a lot of clients
>that just plug in a generic HTTP stack and although I do see your
>point of keeping the spec tight, the expected behaviour of a MDX
>client needs to be pretty well aligned with what is "reasonable"
>for a general REST/HTTP stack.

We're talking about the server side in this respect. Having a particular
set of status codes have defined semantics and that any others would be
left unspecified is fine with me. As long as we're not violating the norms
of any status codes, there should be no issue with any HTTP clients.

>>I'm reading the hash identifiers as a registry in the making here, and so
>> my feeling is that we shouldn't have aliases in such a registry.
>
>You already have 1 alias: the null-hash of the entityID ...

I don't follow. Where are we defining a null-hash?

>OK then that needs to be explicit in the spec: you MUST validate
>the entityID of the received XML to make sure it matches what
>you hashed. Plus we need some redress-strategies in case the
>verification fails so clients aren't just left hanging.

I think I'm mistaken, now that I'm swapping all this back in. I suspect
the hash support is there for SAML artifact usage, so in that case you
only know the hash up front. So I suppose if you had collisions, then
there's a slight issue in that you'd query the wrong IdP, but of course
that's also just going to fail. Still best avoided, so I'm not sure we
have a strong enough use case for md5 to warrant having it.

-- Scott