Domain names that existed before cease to exist, and domain name
transfers happen. This doesn't affect the Hypergrid only, it affects the
entire Internet. As much as I would like to think that we are smarter
than everyone else who has been designing and improving the Internet
architecture for the past 40 years, I think we need to consider the
possibility that we aren't smarter, and so we probably are not going to
solve the general issue of stale, or otherwise misguided, references on
the Internet...
Karen Palen wrote:
The problem arises when the original URL no longer exists and one must
attempt to find the new authority somehow.
Unless of course we are willing to accept that the URL/UUID merely
reflects a "point in time".
Even then we get a problem if http://XYZ.com goes away and some time
(years) later a NEW http://XYZ.com 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.
Karen
On Tue, Aug 31, 2010 at 6:01 AM, Melanie <[email protected]
<mailto:[email protected]>> wrote:
This isn't an issue, the URL includes the authority, so no malicious
collisions are possible unless the UUID is used in isolation. That
should not be done. If a resource is to be used in a contect where a
local identifier is required, a new UUID should be generated and
attached to the URI, then that should be used. Never trust the UUID
in the URI for anything but calling the URI itself.
Melanie
Karen Palen wrote:
> It was buried in another post, but I maintain that the definitive
problem is
> not th eone where the "authority" simply disappears (wait to
update the
> cache), but where there are multiple "authorities" claiming the
same UUID!
>
> There are numerous reasons why this could happen, ONE of which is
> "malfeasance" (fraud)!
>
> More likely is the case where the cached "authority" is very much
out of
> date and there have been several changes since the last cache
update! In
> some situations this could happen in only a few minutes!
>
> Every other case resolves to (a) it is in the cache (update
whenever we can)
> or (b) the (single) authority can tell us what we should use as the
> "name"/UUID
>
> While Diva has pointed out that EVERY "name" is really a UUID
(not obvious
> in the "global" case) many of the comments imply that the "name"
is some
> arbitrary text string!
>
> I claim that Diva is exactly correct - the UUID *IS* the name
BOTH global
> and local, and the "text string" (of whatever form) is merely the
"human
> compatible liveware" version. ANYTHING else leads to an enormous
number of
> identity collisions!
>
> I think that it is all available in the "open" literature now,
but in the
> 1960's/1970's the US Military spent an enormous effort ($$$) to
be certain
> that the person with the badge "General Jack D. Ripper" really
WAS that
> person! With Nuclear Weapons the stakes really ARE that high!
>
> Our problem is very similar although not with such dramatic
consequences.
>
> Karen
>
> On Tue, Aug 31, 2010 at 1:17 AM, Ai Austin
<[email protected] <mailto:[email protected]>> wrote:
>
>> myticaldemina makes a lot of good points... one thing that could be
>> problematic though relates to this comment...
>>
>> From: <[email protected]
<mailto:[email protected]>>
>>> ...I would suggest any
>>>
>>> proxies would give the external system and identifier and not
chain proxy
>>> to
>>> proxy unless there is a reason to do it, and the assets should
be copied
>>> from the original source.
>>>
>>
>>
>> I agree with the first half... no chains, just hand over the
external
>> system "authority" and its given identifier pair for the
identity involved.
>>
>> But I don't agree at all with the idea that you then have to get
the asset
>> from that original authority. The permissions could have changed,
>> corruptions could have occurred or much more likely the
authority simply
>> will no longer be there. The asset "as is" (with its textures,
scripted
>> content and what not) should be provided to the destination
location/grid if
>> the object permissions allow it, with proper transfer of the
permissions to
>> next owner exactly as if an avatar to avatar transfer or rez in
world took
>> place on the local grid, without trying to reload the asset from
an original
>> source.
>>
>> .
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> [email protected] <mailto:[email protected]>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/mailman/listinfo/opensim-dev
------------------------------------------------------------------------
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
