On 21 May 2005, at 08:44, Eric Scheid wrote:
On 21/5/05 4:24 PM, "Henry Story" <[EMAIL PROTECTED]> wrote:
So those are just a few thoughts on the topic. It just seems that
if one
works with the web these phishing problems seem to disappear.
all good stuff, with the exception of making atom:id
dereferenceable... once
you do that you have to allow it to change (to accommodate changes
in server
set up etc), and once you allow it to change it is no longer
effective as an
id :-(
Yes. I like the idea of being able to move entries around too.
But we do have a dilemma. We have
a- non de-referenceable id:
- can easily be faked
-> lack of trust which undermines its ability to identify
anything
b- de-referenceable id:
- we can't move entries around
- but we can trust the id
Imagine we have both (as we do, but in a more cumbersome format).
If we give the entry a src attribute then we could have a feed such
as the following:
<feed>
<id>http://a.com/feeda</is>
<entry src="http://a.com/feeda/entry1";>
<id>urn:uuid:1225c695-aaa-4ebb-aaaa-80da344efa6a</id>
<updated>2005-01-01T05:00+00:00</updated>
</entry>
<entry src="http://a.com/feeda/entry2";>
<id>urn:uuid:2225c695-bbb-4ebb-aaaa-80da344efa6a</id>
<updated>2005-01-02T06:00+00:00</updated>
</entry>
<entry src="http://a.com/feeda/entry2";>
<id>urn:uuid:3225c695-ccc-4ebb-aaaa-80da344efa6a</id>
<updated>2005-01-03T07:00+00:00</updated>
</entry>
</feed>
Then since the ids can be faked and spoofed all over the place, and
since there is no way to automatically verify the correct uses, the
amount of trust that can be placed in them to identify an entry is
minimal, close to 0, certainly a *lot* less than the dereferenceable
src uri, which will therefore inevitably take the place of the
identifier.
So in any case it seems like the dereferenceable id wins. Perhaps this
is just something in the architecture of the web that we have to work
with.
But perhaps it is not such a problem after all, because perhaps we can
have dereferenceable ids that allow us to move entries around. I can
think
of a few:
- if an entry moves the old entry position redirects to the new
one.
- one creates a special redirect service to redirect ids to
their current
location
- one creates a new URI to URL mapping protocol
Henry Story
So, all the above, but using atom:[EMAIL PROTECTED]'self'] instead.
BTW, /feed/id is useful for other things -- primarily to help big
aggregators to realise that they are retrieving the same feed from
more than
one location (eg. with and without www.)
e.
