# Re: Persistent Documents and Locations

Karen R. Sollins (sollins@lcs.mit.edu)
Mon, 21 Aug 1995 11:21:18 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Karen R. Sollins: "Re: Persistent Documents and Locations"
- Previous message: Dirk.vanGulik: "Re: save everything"
- Next in thread: Keith Moore: "Re: Persistent Documents and Locations"
- Reply: Keith Moore: "Re: Persistent Documents and Locations"
- Reply: Larry Masinter: "Re: Persistent Documents and Locations"
- Reply: lazear@dockside.mitre.org: "Re: Persistent Documents and Locations"

    Date: Mon, 21 Aug 1995 11:21:18 -0400

    Message-Id: <199508211521.LAA09705@lysithea.lcs.mit.edu>

    From: "Karen R. Sollins" <sollins@lcs.mit.edu>

    To: uri@bunyip.com

    Subject: Re: Persistent Documents and Locations

Perhaps I'm misunderstanding something, but it seems to me that
dangling references (whether they are URNs or URLs or anything else)
will always have validity in some cases. If I let out a reference to
something for which I have sole responsibility and that I intend to
keep that way, then I have the option of causing that thing to be no
longer available. Et voila! the potential for dangling references.
If one takes the position that dangling references are a "bad" thing,
one is saying that this sort of situation is a "bad" thing. Either I
can never let out the references or the things can never be withdrawn.
I'm not happy with either of these options, leading me to the
position, that there will be some dangling references. Even the
people who built capability systems many years ago in much more
limited contexts realized that revocation had to be an integral part
of any naming/access system.

If I'm understanding Larry correctly, I also disagree with him about
such a service subsuming the naming problem. First, such a service,
unless it were virtually centralized will have exactly the same
problems we have discussed repeatedly in terms of name assignment. It
needs to be distributed in management, and most likely needs to be
able to evolve. Second, unless it will provide a single name
resolution mechanism forever, it will also have the same set of issues
with respect to name resolution (one-to-one mapping between name
assignment scheme and resolution scheme vs. many-to-many). Third, all
the meta-information issues will not only be present in terms of
creating, managing and propagating meta-information, but now one also
needs to build a storage service that the world will trust to embody
the policies of each policy domain, whether it be authenticity and
integrity of information, privacy and security of access and
information, or billing and payment. I find it difficult to believe
that even we, as intelligent as we are, could engineer such a universal
policy server in which everyone would believe.

That doesn't maan that the sort of service in which Larry is
interested is not useful, but only that one cannot assume that it
should/will be a universal solution to the dangling reference problem.
It would be a very useful service, since much of what may be put out
there will be available for some sort of network-based, long-lived,
stable storage. But I hope you all understand that it will have the
same problems with which we are already grappling and more.

Karen

- Next message: Karen R. Sollins: "Re: Persistent Documents and Locations"
- Previous message: Dirk.vanGulik: "Re: save everything"
- Next in thread: Keith Moore: "Re: Persistent Documents and Locations"
- Reply: Keith Moore: "Re: Persistent Documents and Locations"
- Reply: Larry Masinter: "Re: Persistent Documents and Locations"
- Reply: lazear@dockside.mitre.org: "Re: Persistent Documents and Locations"