<div>I'm not convinced the SHA1 UUID will be extensible enough to allow for future plans.   The idea is to not assume anything with a UUID.  Adding assumptions increases scalability at the cost of extensibility.</div>
<div> </div>
<div>Best Regards</div>
<div> </div>
<div>Teravus<br><br> </div>
<div><span class="gmail_quote">On 6/23/08, <b class="gmail_sendername">Melanie</b> <<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi,<br><br>Sean Dague wrote:<br>> I don't understand how your approach deals with sniffing the wire or the<br>
> cache, finding the asset UUID, and just embedding that in you items or<br>> scripts.<br><br>It doesn't. Because that approach is not enjoying blanket coverage<br>in the DMCA. Means, in the case of UUID sniffing, each _item_ is a<br>
separate violation, subject to a separate takedown order. Yes, one<br>per prim!<br><br>If the texture is re-uploaded, blanket protection applies.<br><br>The law isn't always common sense - in fact, it mostly diverges from<br>
common sense!<br><br>> Anyway, it's a little moot for right now, as the current system is<br>> there.  But I really think the way forward involves us using a hashing<br>> strategy.  Once we dig in there, we'll see how hard it would be to make<br>
> UUID generation runtime configurable.  And keep this in mind.<br><br>I'm happy if that concern is not forgotten. That is all I wanted,<br>recognition of this as a valid concern, so no decisions are made<br>that could ultimately lead to an entire grid being judicially shut down.<br>
<br><br>Melanie<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">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</blockquote></div><br>