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

[Leif Johansson]

On 09/09/2013 07:07 PM, Cantor, Scott wrote:
> 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.
OK my bad - I was confusing this with the client side.
>
>>> 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?
We allow lookup using the non-hashed entityID no?
>> 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
OK then my recollection is wrong but that wouldn't be the first time...
> 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
>
>