# Re: URN and citations

Keith Moore (moore@cs.utk.edu)
Sat, 16 Apr 1994 18:31:18 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Keith Moore: "Re: URL requrements: Structure in string"
- Previous message: Alexsander Totic: "Re: URN and citations"
- In reply to: Alexsander Totic: "Re: URN and citations"

    Message-Id: <199404162231.SAA00703@wilma.cs.utk.edu>

    From: Keith Moore <moore@cs.utk.edu>

    To: atotic@ncsa.uiuc.edu (Alexsander Totic)

    Subject: Re: URN and citations

    In-Reply-To: Your message of "Sat, 16 Apr 1994 16:53:31 CDT."

                 <9404162153.AA22310@void.ncsa.uiuc.edu>

    Date: Sat, 16 Apr 1994 18:31:18 -0400

> Being able to refer to a particular field within a URC would be very
> useful. For example, the weather map URC might contain URLs for all
> available weather maps. We could use something similar to the # directive
> in URLs, that will contain the additional query arguments for the URC.

I'm not sure this is desirable either, because I could see cases where
the same file would be a valid instance for multiple URNs, even if
neither of the resources named by those URNs was a subset of the other.
(i.e. URN A could point to LIFN x and y, and URN B could point to LIFN
y and z.) So I would not constrain LIFNs to be an index into a particular
URC. I would much prefer that a URN name a URC-like object, which would
contain LIFNs.

> > One means of doing this is to have a distinguished "location independent
> > file name" (LIFN) for each valid instance of an object, with a description
> > of that object (containing e.g. the MD5 signature) available from the
> > naming authority.
>
> As someone mentions later in this thread, why not return MD5 together with
> the URL, and then run the check when you download the file?

Because that separates the authenticity information about that file from the
rest of the description of the file. I would like to ensure that the
description of the file is consistent with the file itself, including the
authenticity information.
>
> > Ideally, this LIFN would be always used as the actual handle from which a
> > location of the resource were derived. In that way it would be possible to
> > verify the authenticity and/or integrity of a resource. Furthermore, a
> > LIFN->URL mapping obtained from the naming authority for the LIFN, would
> > provide reasonable assurance that the URL pointed to the correct (and
> > current) version of that resource.
>
> This would create another level of indirection. Why is LIFN to URL mapping
> and more inherently secure than URN to URL mapping? In both cases you
> trust the server to provide you with a valid URL. And both servers would
> have the same problems ensuring their URLs are valid.

Not quite. If you change the file that a URL points to, you have to change
the authenticity check information in the URC (or whatever) as well. If
you have multiple locations for a file, there's no way you can update them
all at once, so some of them are going to be invalid. But by definition,
you never change the contents of a file pointed to by a particular LIFN.
(of course it will happen sometimes, but that's what the MD5 is for.)

On the other hand, it's somewhat easier to add a new LIFN to the URC-thingy
(perhaps marking the new LIFN as the 940415 version of the file), and have
LIFN->URL servers which are updated by mirroring programs (with appropriate
authentication required).

Keith

- Next message: Keith Moore: "Re: URL requrements: Structure in string"
- Previous message: Alexsander Totic: "Re: URN and citations"
- In reply to: Alexsander Totic: "Re: URN and citations"