* Matthew Toseland <toad at amphibian.dyndns.org> [2006-08-19 15:57:40]:
> On Sat, Aug 19, 2006 at 02:55:15PM +0000, NextGen$ wrote: > > * Matthew Toseland <toad at amphibian.dyndns.org> [2006-08-19 15:43:01]: > > > > > On Sat, Aug 19, 2006 at 08:47:14AM +0000, NextGen$ wrote: > > > > * Matthew Toseland <toad at amphibian.dyndns.org> [2006-08-18 22:31:01]: > > > > > > > > > At present, nothing can redirect to a USK. That means that if a URI is > > > > > not a USK, it's fixed; either it can be retrieved with the original > > > > > contents, or it's fallen out of the network. This is a very desirable > > > > > property. The only time it would be useful to redirect to a USK would > > > > > be > > > > > from a KSK, and we can support this with the permanent redirect > > > > > mechanism we use for USK updates: If you fetch KSK at cofe, then you > > > > > get an > > > > > error saying this has moved to USK at ..../cofe/27/ . In Fproxy, this > > > > > would > > > > > be transparent, but it would use an HTTP "permanent redirect" so the > > > > > URL > > > > > would be updated and you would bookmark the USK rather than the KSK. > > > > > > > > What about creating an other key format ? So that KSKs stay immuable but > > > > redirecting to USKs using shorter names is possible. > > > > > > What's wrong with using a permanent redirect? > > > > Nothing. But I think that keeping KSKs not updatable (immuable) is the way > > to go. > > I don't mind if we create a new "UKSK" key type. > > Hmmm, so a UKK key? How is this better than a KSK that redirects to a > USK? I suppose it maps directly to NIM queues - is that your idea? Yes. NextGen$
