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

[Leif Johansson]

On 08/26/2013 09:22 PM, Cantor, Scott wrote:
> On 8/26/13 3:03 PM, "Leif Johansson" <leifj at sunet.se> wrote:
>>> We don't need HEAD to do cache checks, and that just adds multiple ways
>>> of
>>> doing the same thing.
>> I think its reasonable to expect that http clients are going to do what
>> they usually do for cache checks - some do HEAD.
> I don't think most clients that aren't browsers do anything in particular
> unless they're instructed to, but it is true that supporting HEAD isn't
> hard. But I still don't see a strong need.
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 :-)
>
>>> Disagree. We're defining what the codes mean in our context here.
>> why?
> It's an application profile of HTTP. I also think we should be precisely
> nailing down what codes can be used, so it's not as though we're saying
> all of HTTP's status space is fair game, or at least not specified.
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.
>> I guess I can buy that argument, however doing case-folding is
>> not unreasonable in terms of work and it will make the protocol
>> more robust.
> 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 ...
>> Not sure I agree - we're using hashes to lookup security-critical
>> objects. We need to be sure of this if we decide to keep md5
> To look them up, but not to accept them. If I ask for foo and I get back
> bar, my code's not going to accept that. So a hash collision just results
> in failure. Perhaps worth highlighting.
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.
>
> You're not asking for metadata for some entity whose name you don't know.
> The hash isn't really used for that.
>
> -- Scott
>
>