From: Pierre Landau <firstname.lastname@example.org> Message-Id: <199507101918.MAA15589@bud.indirect.com> Subject: URN Resolution Security and Privacy Issues (fwd) To: email@example.com Date: Mon, 10 Jul 1995 12:18:32 -0700 (MST) > From: Fisher Mark <FisherM@is3.indy.tce.com> > To: "'URI'" <firstname.lastname@example.org> > Subject: URN Resolution Security and Privacy Issues > Date: Mon, 10 Jul 95 11:41:00 PDT > Message-Id: <30017541@MSMAIL.INDY.TCE.COM> > Encoding: 29 TEXT > X-Mailer: Microsoft Mail V3.0 > Sender: email@example.com > Precedence: bulk > > > Because the mere knowledge that a string is a valid URN can useful in some > contexts, it is advisable to have mechanisms that prevent the discovery of > this fact. Any generally useful resolution service must be able to not only > refuse to resolve a URN (or URL), it must be able to avoid giving the > impression that what was handed to it was a valid URN or URL to begin with. Maybe I'm missing something here. My understanding of the motivation behind the creation of a URN was to say "I'm now publishing something I want people to read/use/whatever; here's a persistent name for that object." Any URN registry service must be able to answer the question of whether a URN exists in order to decide whether it can be assigned to a new object. If you're playing with confidential information, what is it doing on an essentially public network, where security is basically nonexistent?