[mdx] Joe on 3.1.1

[Ian Young]

On 26 Sep 2013, at 21:18, Tom Scavo <trscavo at gmail.com> wrote:

> I must be missing something. The mapping from entityID to filename
> happens on the server side. The end client doesn't get to choose the
> encoding scheme. That is an opaque implementation choice.

With the current spec, the client gets to choose between these three equivalent representations of an entity ID:

A: http://blahblah/the/real/one

B: {md5}98347947924792734982374

C: {sha1}1298381938109238102938102938102938123

The point is that you need to be able to map all three of those to the same data.

If your canonical key for the data is A (somehow), generating A if the client presents B or C requires reversing those hashes.

If your canonical key is B, you can compute it from A but need to be able to reverse SHA-1 if the client presents C

If your canonical key is C, you can compute it from A but need to be able to reverse MD5 if the client presents B

If there was only one transformed version available, you could pick it as your canonical representation and then compute B (or C) from A, and there would be no need to reverse the other hash.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20130926/ea10010a/attachment.bin>