The problem arises when the original URL no longer exists and one must attempt to find the new authority somehow.<br><br>Unless of course we are willing to accept that the URL/UUID merely reflects a "point in time".<br>
<br>Even then we get a problem if <a href="http://XYZ.com">http://XYZ.com</a> goes away and some time (years) later a NEW <a href="http://XYZ.com">http://XYZ.com</a> appears and starts doing business on the hypergrid. The new owner of the URL may or may not have any affiliation with the old one.<br>
<br>Karen<br><br><div class="gmail_quote">On Tue, Aug 31, 2010 at 6:01 AM, Melanie <span dir="ltr"><<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
This isn't an issue, the URL includes the authority, so no malicious<br>
collisions are possible unless the UUID is used in isolation. That<br>
should not be done. If a resource is to be used in a contect where a<br>
local identifier is required, a new UUID should be generated and<br>
attached to the URI, then that should be used. Never trust the UUID<br>
in the URI for anything but calling the URI itself.<br>
<font color="#888888"><br>
Melanie<br>
</font><div><div></div><div class="h5"><br>
Karen Palen wrote:<br>
> It was buried in another post, but I maintain that the definitive problem is<br>
> not th eone where the "authority" simply disappears (wait to update the<br>
> cache), but where there are multiple "authorities" claiming the same UUID!<br>
><br>
> There are numerous reasons why this could happen, ONE of which is<br>
> "malfeasance" (fraud)!<br>
><br>
> More likely is the case where the cached "authority" is very much out of<br>
> date and there have been several changes since the last cache update! In<br>
> some situations this could happen in only a few minutes!<br>
><br>
> Every other case resolves to (a) it is in the cache (update whenever we can)<br>
> or (b) the (single) authority can tell us what we should use as the<br>
> "name"/UUID<br>
><br>
> While Diva has pointed out that EVERY "name" is really a UUID (not obvious<br>
> in the "global" case) many of the comments imply that the "name" is some<br>
> arbitrary text string!<br>
><br>
> I claim that Diva is exactly correct - the UUID *IS* the name BOTH global<br>
> and local, and the "text string" (of whatever form) is merely the "human<br>
> compatible liveware" version.  ANYTHING else leads to an enormous number of<br>
> identity collisions!<br>
><br>
> I think that it is all available in the "open" literature now, but in the<br>
> 1960's/1970's the US Military spent an enormous effort ($$$) to be certain<br>
> that the person with the badge "General Jack D. Ripper" really WAS that<br>
> person! With Nuclear Weapons the stakes really ARE that high!<br>
><br>
> Our problem is very similar although not with such dramatic consequences.<br>
><br>
> Karen<br>
><br>
> On Tue, Aug 31, 2010 at 1:17 AM, Ai Austin <<a href="mailto:ai.ai.austin@gmail.com">ai.ai.austin@gmail.com</a>> wrote:<br>
><br>
>> myticaldemina makes a lot of good points... one thing that could be<br>
>> problematic though relates to this comment...<br>
>><br>
>>  From: <<a href="mailto:mysticaldemina@xrgrid.com">mysticaldemina@xrgrid.com</a>><br>
>>> ...I would suggest any<br>
>>><br>
>>> proxies would give the external system and identifier and not chain proxy<br>
>>> to<br>
>>> proxy unless there is a reason to do it, and the assets should be copied<br>
>>> from the original source.<br>
>>><br>
>><br>
>><br>
>> I agree with the first half... no chains, just hand over the external<br>
>> system "authority" and its given identifier pair for the identity involved.<br>
>><br>
>> But I don't agree at all with the idea that you then have to get the asset<br>
>> from that original authority.  The permissions could have changed,<br>
>> corruptions could have occurred or much more likely the authority simply<br>
>> will no longer be there.  The asset "as is" (with its textures, scripted<br>
>> content and what not) should be provided to the destination location/grid if<br>
>> the object permissions allow it, with proper transfer of the permissions to<br>
>> next owner exactly as if an avatar to avatar transfer or rez in world took<br>
>> place on the local grid, without trying to reload the asset from an original<br>
>> source.<br>
>><br>
>> .<br>
>><br>
>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>><br>
><br>
><br>
</div></div>> ------------------------------------------------------------------------<br>
<div><div></div><div class="h5">><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br>