Subject: Re: [URN] URN required reading & a modest proposal
From: Leslie Daigle <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: [email-masked]
Date: Tue, 30 Jun 1998 22:06:17 -0400 (EDT)

Larry,

This "strictly syntactic" manipulation is no different than what is
presented in the URI syntax document.  As such, if URNs are said
to support URI hierarchy, they should indeed be subjected to precisely these
syntactic rules prior to resolution or other use.

However, this still overlooks at least one fundamental issue which undermines
persistence in the use of identifiers:    the separation of a 
relative reference from its base.

On Tue, 30 Jun 1998, Larry Masinter wrote:
> Under this view, the validity of the hierarchical nature of URNs,
> and the utility of relative forms against a URN base, are independent
> of the mechanisms and architectural principles of  RESOLUTION,
> since the syntactic processing happens before resolution is attempted.

To do this requires both the base and the relative fragment, and
the only mechanisms we currently have for communicating that base are
(at least currently), dependent on the resolution process (e.g.: "use
the URI used to access the resource").

> > I.e., doing an N2R that has relative references in it will leave you out in
> > the cold,
> 
> N2R, or any URL resolution mechanism, should never be applied to
> relative references. The relative references must first be syntactically
> processed against the base to obtain an absolute reference, before doing
> any resolution.

I'm sorry my example was not clearer.  My point was that you run into
difficulty when:

	. you do an N2R resolution and get a resource, which
	  contains relative references
	. you then want to resolve the relative references which,
	  and unless a specific base is delivered, the URI syntax
	  document says "default to the URI used to get here" -- i.e.,	
	  the URN.

If URNs do not support hierarchy, then you have a URI scheme that
is not appropriate for the syntactic manipulation, and you have a problem.

If URNs _do_ support hierarchy in the general way, then:

	. _all_ URN references to this document must be formed on
	  the same hierarchy as the relative references, or else
	  the URNs formed after the syntactic manipulation will simply
	  be wrong.  And, there's no (known) way of distinguishing 
	  between a URN that accepts the document's embedded hierarchy
	  and those that do not.

Note that the embedded references are likely created by the document
author/responsible person.  URNs, by contrast, will be assigned by
a variety of independent organizations, which have their own requirements
for name structure.  As it stands today, the Swedish library is assigning
URNs to any web resource in the Nordic countries.  Some publishers
are assigning Digital Object Identifiers (which may yet become a URN
namespace) to published resources.  A single web page may validly
have assigned to it URNs from both of these sources; the sources do
not have the same hierarchical structure, nor are they in any way 
related to the structure of the relative references offered by the
author.  Therefore, it is _not_ valid to assume that relative fragments
will work with all these URIs for the same resource.

> It would be safe to say that the calcuation of the 'base' to be used
> when resolving relative references within a document should prefer
> the most local form of the document's base that is available, and that
> relative forms should be avoided when the base is unavailable or unclear
> or might be in the future. This is especially true for documents which
> are intended for long-term permanent storage and which are believed to
> allow for additional global names: RFCs, published books, etc.

Yeah; but I'll play an unusual card and point out that the reality
is that the bulk of existing resources are web pages, and they already
have relative references in them, with little or no formal declaration
of base.  

We can write a BCP on when to use relative references and when not, but
the reality is that people will slap URNs on existing resources, however
they are formulated.

> >  Keith asked whether or not it is worth casting into
> > question URNs' ability to provide persistent references in order to support
> > this case.  Anything I've seen suggests it comes back to point #1 --
> > we don't yet understand well enough how to do these across _all_ URN
> > namespaces.
> 
> Perhaps by 'understand' you really mean 'accept'? Syntactic preprocessing
> is certainly 'understandable', isn't it? It's really a matter of whether
> you accept it as a viable way of dealing with relative processing.

No, I mean understand, as in understand and address all the very real 
ramifications.  Your proposal is indeed easily understood, and
technically straightforward.  But, it's like an extended warranty
on a new car:  what's important is not the long list of things it
will cover, so much as the very significant bits that are not.

I have no problem with new proposals; the difficulty is that we haven't
yet agreed what problem we are trying to solve.  I think what you have
proposed is the appropriate technical solution -- for part of the problem.
But you haven't addressed (accepted?) the deployment issues outlined
above.  And, at least the last time I checked, this group was still
concerned with anticipating deployment and scaling issues.

>    In contrast to URNs, one can imagine a variety human-friendly naming
>    (HFN) schemes supporting different suites of applications and user
>    communities.  These will need to provide mappings to URNs in tighter
>    or looser couplings, depending on the namespace.  It is these HFNs
>    that will be mnemonic, content-full, and perhaps mutable, to track
>    changes in use and semantics.  They may provide nicknaming and other
>    aliasing, relative or short names, context sensitive names,
>    descriptive names, etc.  Their definition is not part of this effort,
>    but will clearly play an important role in the long run.
> 
> Following this advice, the proposal is merely that a 'relative form' is
> a kind of HFN that can be used in conjunction with a URN that has a
> hierchical assignment mechanism to provide, using the relative reference
> processing rules, to support a mapping to URNs (via the relative+base=>URN
> mapping), and a relative name scheme.
> 
> The definition of relative forms is not part of 'this effort' (the URN
> group), but plays an important role, and allowing the use of "/" to
> delimit hierarchies in URN schemes, which would support such use, would
> seem to be entirely reasonable and consistent with the architectural
> principles already laid out.

I have every faith that HFIs will address many problems.  And, if _that_
work can address the kinds of problems that will be encountered in
real usage terms, then it will be appropriate to update RFC2168 
with the appropriate terminology.   But, to change the syntax in
anticipation of the successful outcome is, to my way of thinking, like
saying "let's load the gun and figure out how to aim later".

Leslie.

----------------------------------------------------------------------------

    "The nice thing about reality                 Leslie Daigle
       is that there are        
     so many versions to choose from."            Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

Date: Tue, 30 Jun 1998 20:41:30 -0400
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: The "ietf" namespace and internet-drafts (was Re:ftp://ds.internic.net/rfc/)
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Larry, Keith, et al.,

I'm having a little trouble distilling the core issues with respect to
relative identifiers, but I think both of you have hit on several
important points.  Fundamentally, there is the question of determining
"relative to what".  Relative locations are important.  One manages
collections of instances resources as collections (and hence may move
them to new physical locations as collections).  It is probably less
important to be able to move a collection of names wholesale into
another name namespace, especially namespaces which may not embody
much if any semantics.  Furthermore, this may be difficult to achieve.
If I am labelling physical locations, and there cannot be more than
one thing in any one location, conflicts are easy to discover.  If
"overlaying" or reassigning a name happens in the virtual space of a
namespace, such a mishap may be much more difficult to discover and
avoid.

Now, we can consider the mechanisms under discussion.  In the URL
world, relative identifiers can be embedded in a resource that either
does or does not specify the base.  If it specifies the base, then the
relative URLs are only a shorthand for fully expanded URLs.  It seems
to me that this sort of facility is easily implementable and
non-controversial with respect to URNs as well, and essentially a
non-issue.

The other alternative is that the base is not specified.  When that
happens it must be discovered by some other means.  With URNs we are
talking about picking up subnamespaces and adding them to other
subnamespaces.  The syntax URN is extensible and doesn't necessarily
have the common syntax defined for URLs.  The reflection of
hierarchical assignment of delegation may be reflected in various
different syntaxes.  Hence, a URN subspace may choose to reflect
hierarchy by putting name components at the left or right, or both.
There may not be a single left to right or right to left hierarchical
reading of a URN.  Thus a set of "relative" URNs within some subspace
may conflict in extremely peculiar ways with another URN space.  This
may not be obvious at all to the naive inheritor of a set of
resources.  They could lead to the cons'ing up of URNs that did not
reflect the original intentions at all.  In order to correctly
understand any hierarchical structure, some reference is needed.  Are
we not now almost back at specifying a base, which in this case was
not supposed to be the case?

I suppose one really needs to understand the impact of those
misleading and incorrect URNs.  First, it clearly makes such a scheme
less reliable; it seems to me that long-lived validity of identifiers
is key to the value of URNs.  Beyond that, if they fail and mislead a
user, it is impossible to predict the consequences.  We could simply
say that the user must beware.  I don't find this a very comforting
approach.  We are supposed to solving a problem, not creating more
problems.  I am not yet convinced by the arguments that
relative URNs are useful and it appears that there are significant
pitfalls.

			Karen

Date: Tue, 30 Jun 1998 15:22:47 -0700
From: [email-masked] (David G. Durand)
To: "Leslie Daigle" <[email-masked]>, "Larry Masinter" <[email-masked]>
Subject: Re:  [URN] URN required reading & a modest proposal
Cc: <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked] (David G. Durand)

Larry has given a very clear and convincing case for how relative URNs could
make sense, and why "/" should not be _forbidden_ to URN schemes. It's
clear that some URN schemes will not be compatible with such relative names,
and that some namespace definers would prefer to rule them out. Anyone
defining a namespace, however, is free to require absolute names in all
contexts, by _not_ using a "/" character in the namespace.

    -- David

I've been very skeptical of "relative" URNs because of resolution problems, but
I think Larry's "syntactic" proposal eliminates those issues.
------------------------------------------+----------------------------
David Durand                 [email-masked]| [email-masked]
Boston University Computer Science        | Dynamic Diagrams
http://www.cs.bu.edu/students/grads/dgd/  | http://dynamicDiagrams.com/
                                          | MAPA: mapping for the WWW
                                          | http://dynamicDiagrams.com/minimapa

From: "Larry Masinter" <[email-masked]>
To: "Leslie Daigle" <[email-masked]>
Cc: <[email-masked]>
Subject: [URN] URN required reading & a modest proposal
Date: Tue, 30 Jun 1998 12:24:17 PDT
Importance: Normal
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

> 	. To say we "do relative URNs", we would have to understand how
> 	  to make it work (while preserving the characteristics of URNs,
> 	  such as persistence, etc) for ALL URNs in all namespaces.  We
> 	  have said that we don't yet know how to do that, and nothing
> 	  presented to date in this current instantiation of this thread
> 	  suggests we have learned otherwise.

I don't think we're in a situation of perpetual mystery, where 'we didn't
understand before' supports 'we don't understand now'. If you find this
message even slightly illuminating, perhaps you could comment on whether
we're able to move the understanding forward, just a bit?

A working group "rough consensus" at some point might be "we don't
know how to do that", but "not knowing how" isn't thus grounds
for rejecting proposals for "how".

Recast in terms of the technical specifications, the statement is
more palatable, e.g., "A proposal for relative URNs would need to
explain, or point to an explanation, of how it would work with all
URN namespaces."   Then the validity a proposal could be judged on
its own merits.

With that context, I want to try, once again, to make a proposal
for "doing relative URNs", or, at least, "using URNs with /-delimited
hierarchical forms and relative forms."

PROPOSAL:  the processing of relative forms against the base is
_entirely_ syntactic, and occurs BEFORE any attempt at resolution.

Under this view, the validity of the hierarchical nature of URNs,
and the utility of relative forms against a URN base, are independent
of the mechanisms and architectural principles of  RESOLUTION,
since the syntactic processing happens before resolution is attempted.

This is not a proposal for "relative URNs", but rather it is a proposal
to allow hierarchical URN forms, which admit to being candidates for
relative-form processing.

The processing of a relative form "../a/b" against a base, whether
URN or URL, of form "scheme://authority/s1/s2/s3", is to be done
_completely syntactically_ without reference to the semantics of
the scheme; the result of the syntactic processing is another absolute
form. Only after relative form processing is applied is the scheme
examined, and resolved using the architectural principles of URNs
as expressed in rfc2276.txt, or according to the methods set out by
the definition of the URL scheme.

This is a simple proposal for how to 'do relative forms in conjunction
with URNs' which I hope is clear enough to be understandable, simple
enough to be implemented, compatible with most existing URL resolution
mechanisms, and which does not interfere with any of the persistent
properties of URNs themselves because it is an entirely syntactic
operation.

This proposal 'preserves the characteristics of URNs such as persistence,
etc) for ALL URNs in all namespaces, primarily because it does not
modify the characteristics of URNs at all, but merely provides an additional
syntactic preprocessing step. (Think of it as a macro-language pre-processor
to your programming language.) It is completely compatible with RFC 2276,
because it applies before the resolution laid out in RFC 2276 occurs, and
is completely compatible with RFC 2168, for the same reason.

> Furthermore, there has been work done (and there is still effort to refine it)
> to ensure that the expression of relative URIs in the defining syntax
> document makes it clear that a relative reference is only useful, within
> a document, if the defined "base" URI (see the syntax document to learn
> how to derive that) is of a scheme that supports relative references.

I actually think that the utility of relative references is narrower
than that, since there are additional restrictions you would want to
apply. Even when the syntax allows relative references, the use of ANY
reference (relative or absolute) needs to be considered in the context of the
lifetime of the reference compared to the lifetime of the document.
In some situations, even when syntactically allowed, an 'absolute'
reference has a shorter lifetime than a 'relative' reference, and in
other situations, a 'relative' reference might have a shorter lifetime.

This is an important constraint on the context and use of references.

> I.e., doing an N2R that has relative references in it will leave you out in
> the cold,

N2R, or any URL resolution mechanism, should never be applied to
relative references. The relative references must first be syntactically
processed against the base to obtain an absolute reference, before doing
any resolution.

>  unless there is an explicit base URI transmitted in the transaction
> (e.g., within the HTML, HTTP exchange, whatever), but if you do an N2L
> and then resolve the URL, you are in fact still dealing with relative
> references against a URL.

> This may yet give you problems if the URL you used was not
> the one anticipated in writing the relative reference, but that's a URL
> problem, not a URN one.

It would be safe to say that the calcuation of the 'base' to be used
when resolving relative references within a document should prefer
the most local form of the document's base that is available, and that
relative forms should be avoided when the base is unavailable or unclear
or might be in the future. This is especially true for documents which
are intended for long-term permanent storage and which are believed to
allow for additional global names: RFCs, published books, etc.

But this doesn't remove the utility of relative forms from outside the
resources themselves, nor the utility of using a consistent syntax for
describing hierarchy.

> I.e., as Keith and Larry's exchange underscored, the problem is _only_ when
> you have extra-document references, not governed by the URI relative
> reference rules.

Well, the narrower problem is the crux of the matter, although the
relative syntax is valid in all contexts for which a base is available.

>  Keith asked whether or not it is worth casting into
> question URNs' ability to provide persistent references in order to support
> this case.  Anything I've seen suggests it comes back to point #1 --
> we don't yet understand well enough how to do these across _all_ URN
> namespaces.

Perhaps by 'understand' you really mean 'accept'? Syntactic preprocessing
is certainly 'understandable', isn't it? It's really a matter of whether
you accept it as a viable way of dealing with relative processing.

> I know there are people who disagree with this, but it's the considered
> opinion of this working group.

I don't disagree that the group had come to the conclusion in the past that
it "didn't understand" how to deal with relative forms in the context of
URNs, but there don't seem to be architectural principles that would rule out
syntactic pre-processing. In fact, RFC 2276 alludes to this:

   In contrast to URNs, one can imagine a variety human-friendly naming
   (HFN) schemes supporting different suites of applications and user
   communities.  These will need to provide mappings to URNs in tighter
   or looser couplings, depending on the namespace.  It is these HFNs
   that will be mnemonic, content-full, and perhaps mutable, to track
   changes in use and semantics.  They may provide nicknaming and other
   aliasing, relative or short names, context sensitive names,
   descriptive names, etc.  Their definition is not part of this effort,
   but will clearly play an important role in the long run.

Following this advice, the proposal is merely that a 'relative form' is
a kind of HFN that can be used in conjunction with a URN that has a
hierchical assignment mechanism to provide, using the relative reference
processing rules, to support a mapping to URNs (via the relative+base=>URN
mapping), and a relative name scheme.

The definition of relative forms is not part of 'this effort' (the URN
group), but plays an important role, and allowing the use of "/" to
delimit hierarchies in URN schemes, which would support such use, would
seem to be entirely reasonable and consistent with the architectural
principles already laid out.

Regards,

Larry

Date: Tue, 30 Jun 1998 14:19:46 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] required reading
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Before _anyone_ posts anything further on this thread (which has morphed
itself into the "whydon'twehaverelativeURNs" thread), read:

	http://www.ietf.org/internet-drafts/draft-fielding-uri-syntax-03.txt
	  (the latest draft of the URI syntax, including relative references)
	ftp://ftp.isi.edu/in-notes/rfc2276.txt
	   Architectural Principles of Uniform Resource Name Resolution
	   (i.e., the whole overview of what we think we're doing)
	ftp://ftp.isi.edu/in-notes/rfc2168.txt
	   Resolution of Uniform Resource Identifiers using the Domain Name 
	   System
	   (i.e., not just what the proposed IETF namespace does, but what
	   can be done with our one proposed RDS).

Too many of the arguments presented here have been based on an extrapolation
of assumptions based on exposure only to the IETF namespace document,
and/or a faulty understanding of the URI relative syntax handling.

Let's review the group's position on relative URNs, and the use of "/" in
a URN:

	. To say we "do relative URNs", we would have to understand how
	  to make it work (while preserving the characteristics of URNs,
	  such as persistence, etc) for ALL URNs in all namespaces.  We
	  have said that we don't yet know how to do that, and nothing
	  presented to date in this current instantiation of this thread
	  suggests we have learned otherwise.

	. We have said that, in anticipation of one day understanding that,
	  and in order not to collide unnecessarily with URI schemes that
	  do use hierarchies, we will not use "/" in an unescaped fashion
	  in URNs.

	. We have also said that individual namespaces may elect to describe
	  relative referneces using a hierarchical syntax of their choice.
	  This does not allow abbreviated document references, but it does
	  still permit the expression of relationships and namespace-specific
	  software can make use of it.

Furthermore, there has been work done (and there is still effort to refine it)
to ensure that the expression of relative URIs in the defining syntax 
document makes it clear that a relative reference is only useful, within
a document, if the defined "base" URI (see the syntax document to learn
how to derive that) is of a scheme that supports relative references.  I.e.,
doing an N2R that has relative references in it will leave you out in
the cold, unless there is an explicit base URI transmitted in the transaction
(e.g., within the HTML, HTTP exchange, whatever), but if you do an N2L
and then resolve the URL, you are in fact still dealing with relative references
against a URL.  This may yet give you problems if the URL you used was not
the one anticipated in writing the relative reference, but that's a URL
problem, not a URN one.

I.e., as Keith and Larry's exchange underscored, the problem is _only_ when
you have extra-document references, not governed by the URI relative
reference rules.  Keith asked whether or not it is worth casting into
question URNs' ability to provide persistent references in order to support
this case.  Anything I've seen suggests it comes back to point #1 -- 
we don't yet understand well enough how to do these across _all_ URN 
namespaces.

I know there are people who disagree with this, but it's the considered
opinion of this working group.   

Again -- read the documents.

Leslie.

----------------------------------------------------------------------------

    "The nice thing about reality                 Leslie Daigle
       is that there are        
     so many versions to choose from."            Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

From: Keith Moore <[email-masked]>
To: Michael Richardson <[email-masked]>
cc: [email-masked], [email-masked]
Subject: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://ds.i 
Date: Mon, 29 Jun 1998 20:39:30 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

>   Now, I can see some confusion could easily arise if someone can arrive via
> URLs of different types and then is presented with an URN. (Maybe they used
> the explicit FTP url because they can't process URNs!)

No, that's not a problem.  The problem is when you arrive via a URN
and then need to try to interpret relative URLs.  And the only solution
that makes sense to be is that the "base URL" needs to be derived
as part of the URN resolution step.

>   Now, as for the suggestion that IETF documents should simply be given
> some arbitrary number... I think we already do this. 

Yes, in fact we do.  The only difference between RFCs and most document
series is that people become familiar with RFC numbers.  

But the reason I proposed a separate numbering scheme - and I wasn't 
completely serious - is to point out that people were making assumptions 
about how URNs should work, based on the example of RFCs.  

>   However, I prefer something that looks like the rest of the URLs that
> the non-technical public is already familliar with. So, if having to parse
> the relative links and perform complicated equality tests in my caches
> is the price of keeping the same syntax, then I'm happy to do it.

That issue was decided long ago, and is no longer open for discussion.

Keith

From: Keith Moore <[email-masked]>
To: [email-masked] (=?ISO-8859-1?Q?Claus_Andr=E9_F=E4rber?=)
cc: [email-masked], [email-masked]
Subject: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp:// 
Date: Mon, 29 Jun 1998 20:30:47 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> Keith Moore <[email-masked]> schrieb:
> > > It would also reflect the organisation of most FTP servers that provide
> > > RFCs and other IETF and related documents for downloading.
> >
> > This is NOT a goal of URNs.  URNs should not reflect storage hierarchy,
> > because such hierarchies are inevitably going to change over time,
> > and URNs need to be stable.
> 
> Yes. However, the structure mentioned above is present on nearly every  
> FTP server that offers these documents. 

Yes, but all of this will probably change when RFCs start to be offered 
in HTML, and they include embedded images, and the images need to be 
in the same directory as the main RFC text.

> So it seems to make some sense
> to organzie it that way. The same reasons that makes FTP admins organize
> the documents that way could also be valid for the writers of the IETF
> URN spec.

It sets a bad example.  Storage organizations change over time, even
for RFCs.  We don't want those assumptions wired into ietf URNs.
 
> [snip]
> > Any approach that tries to use the existing names sets a misleading
> > example.
> 
> > e.g. URN:ietf:23408 might correspond to RFC 822, and
> >      URN:ietf:28934 might correspond to STD 11
> 
> This would make resolvers unnecessarily complex. (I.e. all of them would  
> need a table which number corresponds to which document.)

Yes.  In other words, it would require general purpose URN resolvers 
rather than resolvers which were purpose-built to handle IETF space.

Keith

From: Keith Moore <[email-masked]>
To: "Larry Masinter" <[email-masked]>
cc: "Keith Moore" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: The "ietf" namespace and internet-drafts (was Re:ftp://ds.internic.net/rfc/) 
Date: Mon, 29 Jun 1998 13:55:58 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> I was just trying to point out that the contexts where hierarchical
> naming and relative references are useful are not limited to those
> of "HYPERTEXT". 

we agree on this point.

> An instantiation (URL) of a permanent document (URN) must carry along
> with it any references. If you move a resource from one location to
> another, you have to rewrite relative references that don't work in the
> new context. For hypertext purposes itself, the 'base' should definitely
> _not_ be the URN, but rather, the resource location base.

Yes, I think that's right.  Or at least it should be a (possibly
location-independent) URI that refers to the current instantation 
of the resource.

> The best use of relative references for URNs is primarily within
> external references, and not those contained within the resources themselves.

Yes, but how important is that use?  Is there more utility gained by
having relative references with URNs than there would be by having
all URNs be absolute?  And is the utility gained in such a case worth 
the cost of the inevitable misuse of URNs and the degradation of the
value of "URN:" as an indicator of persistence?

Keith

From: "Larry Masinter" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: [URN] Re: The "ietf" namespace and internet-drafts (was Re:ftp://ds.internic.net/rfc/) 
Date: Mon, 29 Jun 1998 10:02:08 PDT
Importance: Normal
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

> The issue is not whether relative forms can be useful with URNs.
> The issue is whether having relative forms in URNs at all
> encouages misuse of URNs in a way that degrades the utility 
> of URNs as long-term persistent names.  And it seems that 
> a good number of the suggestions for use of relative forms 
> with URNs - from members of this very working group - would 
> degrade their persistence.  If people in this working group,
> who have been discussing these issues for months or years,
> would misuse relative URNs, surely people outside this working 
> group would be even more likely to do so.

I was just trying to point out that the contexts where hierarchical
naming and relative references are useful are not limited to those
of "HYPERTEXT". I agree that the more semantics that are inferred from
a name, the more likely it is that over time those semantics will become
less useful. I'm not sure, though, that the tack of removing semantics
actually improves longevity, rather than just reducing the short-term
utility function without actually having an effect on longevity.

> Which is not to say that we should ignore the problem of
> use of URNs to name documents that contain relative references -
> but that maybe we shouldn't consider a document's URN as a base 
> for such references.  (Even this doesn't work - a document
> can have multiple URNs.  Seems like the base URL needs to be 
> derived as part of URN resolution.)

An instantiation (URL) of a permanent document (URN) must carry along
with it any references. If you move a resource from one location to
another, you have to rewrite relative references that don't work in the
new context. For hypertext purposes itself, the 'base' should definitely
_not_ be the URN, but rather, the resource location base.

The best use of relative references for URNs is primarily within
external references, and not those contained within the resources themselves.

Larry

To: [email-masked]
Subject: Re: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://ds.i 
Date: Mon, 29 Jun 1998 12:26:42 -0300
From: Michael Richardson <[email-masked]>
Sender: [email-masked]
Reply-To: Michael Richardson <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Keith" == Keith Moore <[email-masked]> writes:
    Keith> No, it doesn't follow.  Just because a document is built out of
    Keith> separate fragments, doesn't mean that those fragments need
    Keith> relative names.

  I will make an observation about relative names and URNs. Perhaps this
is obvious already:
  The chief advantage of relative names (from my point of view) is that
  they allow a document, or set of documents to move around without
  breaking the links between them. (I dislike to the excessive use of
  BASE for this reason)

  For references between documents (not within a single one), the use of 
  absolute URLs/URNs is only a problem if you think the documents are going
  to move.

  BUT: if you are using URNs, then you know the documents aren't going to
  move int he URN-space. If they were going to move in the URN-space then it
  wouldn't be appropriate to use a URN. 

  Now, I can see some confusion could easily arise if someone can arrive via
URLs of different types and then is presented with an URN. (Maybe they used
the explicit FTP url because they can't process URNs!)

  Now, as for the suggestion that IETF documents should simply be given
some arbitrary number... I think we already do this. If we change from
calling it "RFC822" to calling it "urn:ietf:42913", then future generations
won't call it "RFC822". They will call it "urn:ietf:42913". 
  If you make the id non-numeric and hard to type, write on blackboards,
and tell people over the IP-phone, then they will just start using some
other shorthand, and will then want to standardize the shorthand and have
a URN description for it.

  I don't know if naptr://ietf/rfc/../draft/ietf/../.././rfc/822 is
appropriate.  If that is the argument for colons vs /'s, then I don't mind
colons. 
  However, I prefer something that looks like the rest of the URLs that
the non-technical public is already familliar with. So, if having to parse
the relative links and perform complicated equality tests in my caches
is the price of keeping the same syntax, then I'm happy to do it.

    Keith> p.s. FWIW, IETF will eventually allow HTML and other document
    Keith> types.  Everyone agrees that this is a good idea; the problem is

  I'm glad to hear this. Maybe this calls for the locking people in a room
without food or beer and telling them to agree trick.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[email-masked]</A>. PGP key available.
 Corporate: <A HREF="mailto:[email-masked]">[email-masked]</A>. 

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: "Keith Moore" <[email-masked]>, "Larry Masinter" <[email-masked]>, "=?iso-8859-1?B?Q2xhdXMgQW5kcukgRuRyYmVy?=" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://ds.i 
Date: Mon, 29 Jun 1998 11:14:12 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> I had not intended to re-enter this discussion, but I think 
> there is a fundamental problem with the 'hypertext view'.
> 
> Hypertext is dead, the Web killed it. I know about the
> hypertext litterature and the community that worked on
> it.
> 
> Tim Berners-Lee could not get a paper published at a 
> hypertext conference until long after the Web had
> become what it has become. 

> The hypertext community believes that we were wrong, I 
> know that. 

I don't care about any of the above, nor do I see how it
is relevant to the discussion.

> I know that you all think we designed the Web
> wrongly and you think you can fix it.

I don't know where you get this idea.  Some of us saw a need 
for long-term persistent resource names, that could be distinguished
from other resource names, so we designed a naming scheme that
had the characteristics we wanted.

> Ther installed base of HTML which depends on the use
> of relative names exists. This is a backwards 
> compatibility issue.

Yes, this is true, and it needs to be dealt with.  However, there
are other ways to deal with this problem than using the URL 
algorithm for evaluating relative names with URNs.

> If any system of names is to work it has to deal with 
> problems like the broken frames and image transclusion 
> mechanisms. Those mechanisms mean that even a single
> hypertext document has to be compounded out of separate
> fragments. Relative names are inescapable.

No, it doesn't follow.  Just because a document is built
out of separate fragments, doesn't mean that those fragments
need relative names.

I do think there is a need to be able to refer to a component
of a resource, and in some sense that is a relative name. 
The problem is, chances are good that the relationship between 
a resource and one of its components two will change over time.
If you try to encode the relationship between those resources
in their respective URNs, sooner or later that encoding will 
no longer be valid... unless of course the resource is static.

> You will not get persistence without relative names.

It doesn't follow from what you have said here.

> The problem with taking the IETF namespace as a model
> is that the documents are simple ASCII files which are
> by now almost entirely unrepresentative of the documents
> for which URNs are required.

I agree that the IETF document series isn't representative.   
Not only do they not have links to other documents, the
documents themselves never change once issued.

Keith

p.s. FWIW, IETF will eventually allow HTML and other document types.
Everyone agrees that this is a good idea; the problem is 
figuring out how to get the perceived benefits of HTML without
losing several useful characteristics of the RFC series.
There's been a lot of handwaving about this - not to mention
namecalling - and very little effort toward solving the problems
or developing workable compromises.

From: "Phillip Hallam-Baker" <[email-masked]>
To: "Keith Moore" <[email-masked]>, "Larry Masinter" <[email-masked]>
Cc: "=?iso-8859-1?B?Q2xhdXMgQW5kcukgRuRyYmVy?=" <[email-masked]>, <[email-masked]>
Subject: RE: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://ds.i 
Date: Mon, 29 Jun 1998 10:19:20 -0400
Importance: Normal
Sender: [email-masked]
Reply-To: "Phillip Hallam-Baker" <[email-masked]>

I had not intended to re-enter this discussion, but I think 
there is a fundamental problem with the 'hypertext view'.

Hypertext is dead, the Web killed it. I know about the
hypertext litterature and the community that worked on
it.

Tim Berners-Lee could not get a paper published at a 
hypertext conference until long after the Web had
become what it has become. 

The hypertext community believes that we were wrong, I 
know that. I know that you all think we designed the Web
wrongly and you think you can fix it.

Ther installed base of HTML which depends on the use
of relative names exists. This is a backwards 
compatibility issue.

If any system of names is to work it has to deal with 
problems like the broken frames and image transclusion 
mechanisms. Those mechanisms mean that even a single
hypertext document has to be compounded out of separate
fragments. Relative names are inescapable.

You will not get persistence without relative names.

The problem with taking the IETF namespace as a model
is that the documents are simple ASCII files which are
by now almost entirely unrepresentative of the documents
for which URNs are required.

What will happen of course is that having chosen a domain
in which there is already a flat naming scheme as the
model it will be asserted that the soundness of the solution
has been 'proven'.

	Phill

From: Keith Moore <[email-masked]>
To: "Larry Masinter" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: The "ietf" namespace and internet-drafts (was Re:ftp://ds.internic.net/rfc/) 
Date: Mon, 29 Jun 1998 09:27:10 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> > Again we come back to this. As keeps happening from time to time, some
> > blur the difference between the requirements for a HYPERTEXT links
> > and the requirements for a system of identifiers that can be used by
> > systems that are not hypertext oriented. 
> 
> A document repository might contain a database of elements
> and, for the database, have links to named documents within a searchable
> repository where the repository elements were 'relative'.

Now you're trying to make URNs reflect storage hierarchies.
What happens when those storage hierarchies change?  What happens
when some of those documents are moved to a different repository?

> A bookstore catalog might want to refer to ISBN numbers relative
> to the "ISBN naming authority" without having to repeat "URN:ISBN" for
> every ISBN number, even though that catalog might include absolute URNs
> for those items that don't have ISBN numbers assigned.

Sure.  But this is a single very limited case.  It only works because
ISBNs happen to be syntactically compatible with relative URIs.
It wouldn't necessarily work for other namespaces, like handles.

> An index of legal terms might contain pointers to the laws of a region
> via the URNs of the laws, with a "base" that was set to the common
> preface of URNs for law citations for that domain.

Maybe.   But this assumes that there are never two "bases" in 
effect at once (are laws ever shared by multiple domains?)

The issue is not whether relative forms can be useful with URNs.
The issue is whether having relative forms in URNs at all
encouages misuse of URNs in a way that degrades the utility 
of URNs as long-term persistent names.  And it seems that 
a good number of the suggestions for use of relative forms 
with URNs - from members of this very working group - would 
degrade their persistence.  If people in this working group,
who have been discussing these issues for months or years,
would misuse relative URNs, surely people outside this working 
group would be even more likely to do so.

Which is not to say that we should ignore the problem of
use of URNs to name documents that contain relative references -
but that maybe we shouldn't consider a document's URN as a base 
for such references.  (Even this doesn't work - a document
can have multiple URNs.  Seems like the base URL needs to be 
derived as part of URN resolution.)

Keith

Date: 29 Jun 1998 11:09:00 +0200
From: [email-masked] (=?ISO-8859-1?Q?Claus_Andr=E9_F=E4rber?=)
To: [email-masked]
Subject: Re: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://
Sender: [email-masked]
Reply-To: [email-masked] (=?ISO-8859-1?Q?Claus_Andr=E9_F=E4rber?=)

Keith Moore <[email-masked]> schrieb:
> > It would also reflect the organisation of most FTP servers that provide
> > RFCs and other IETF and related documents for downloading.
>
> This is NOT a goal of URNs.  URNs should not reflect storage hierarchy,
> because such hierarchies are inevitably going to change over time,
> and URNs need to be stable.

Yes. However, the structure mentioned above is present on nearly every  
FTP server that offers these documents. So it seems to make some sense  
to organzie it that way. The same reasons that makes FTP admins organize  
the documents that way could also be valid for the writers of the IETF  
URN spec.

[snip]
> Any approach that tries to use the existing names sets a misleading
> example.

> e.g. URN:ietf:23408 might correspond to RFC 822, and
>      URN:ietf:28934 might correspond to STD 11

This would make resolvers unnecessarily complex. (I.e. all of them would  
need a table which number corresponds to which document.)

-- 
Claus Andre Faerber <http://www.muc.de/~cfaerber/> Fax: +49_8061_3361
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E  25 56 69 A5 C6 A0 C9 DC

From: "Larry Masinter" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [URN] RE: The "ietf" namespace and internet-drafts (was Re:ftp://ds.internic.net/rfc/)
Date: Sun, 28 Jun 1998 20:18:28 PDT
Importance: Normal
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

> Again we come back to this. As keeps happening from time to time, some
> blur the difference between the requirements for a HYPERTEXT links
> and the requirements for a system of identifiers that can be used by
> systems that are not hypertext oriented. 

A document repository might contain a database of elements
and, for the database, have links to named documents within a searchable
repository where the repository elements were 'relative'.

A bookstore catalog might want to refer to ISBN numbers relative
to the "ISBN naming authority" without having to repeat "URN:ISBN" for
every ISBN number, even though that catalog might include absolute URNs
for those items that don't have ISBN numbers assigned.

An index of legal terms might contain pointers to the laws of a region
via the URNs of the laws, with a "base" that was set to the common
preface of URNs for law citations for that domain.

None of these cases are "HYPERTEXT" (is all-caps a way to denigrate
a term?) unless you extend "hypertext" to include all known kinds of
references.

> This, in my opinion, is one of the fundamental problems with the 
> current URI document: by putting the "URL-reference" specification
> into the the same document as the specifications for generic URIs, the
> system is biased toward hypertext.

To show 'bias', it is necessary to actually show harm, rather
than make vague references to the potential for bias based on
a mis-characterization of the design requirements.

>                       This is a fundamental design mistake.

Please. Is this a 'mistake' in the design, or a claim of a mistake
in the methodology of the design? Or in the organization of the
documents?

> Identifiers identify. If you want a system to specify hypertext links
> then specify that seperately. You can still use URIs in your hypertext
> link but please be very careful NOT to assume that a URI _IS_ a hypertext
> link. It is not. 

It is unhelpfully pedantic to personalizing this ("_You_ can still use
URIs in _your_ hypertext link ..."). To turn this around,
please be very careful NOT to assert a design requirement where none
was assumed.

The BNF for relative and absolute forms of URIs contained many common
elements. It was useful to put the syntax for both of these in the same
document for conciseness and to insure harmony of terminology and syntax.
Despite the fears that are raised by putting them into the same document,
there is no actual harm.

Larry
--
http://www.parc.xerox.com/masinter

From: "Larry Masinter" <[email-masked]>
To: "Peter Deutsch" <[email-masked]>, "Phillip Hallam-Baker" <[email-masked]>, <[email-masked]>, "Leslie Daigle" <[email-masked]>, "David Holmes" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/)
Date: Sun, 28 Jun 1998 16:50:56 PDT
Importance: Normal
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

> > >This thread started off with an unhealthily aggressive tone, and has
> > >now just gotten off topic.

Just to lend some support:

In general, it is the responsibility and the authority of the
chair of the working group to moderate the discussion and
move things along productively. In particular, it is Leslie's
duty and right to close off topics as she sees fit.

I tried to keep my comments focused on the (new) proposal
to move NAPTR from "Experimental" to "Proposed Standard", but
if things seem to have gotten out of line, I apologize.

I think we've actually made a little progress recently, e.g., on the
long-standing issue of the utility of relative pointers in URIs,
and hoped we might be able to make some decisions in an area
where we'd left things at "we don't know yet" many years ago.
If that's not to be, so be it.

Larry
--
http://www.parc.xerox.com/masinter

From: "Larry Masinter" <[email-masked]>
To: "Peter Deutsch" <[email-masked]>, "Phillip Hallam-Baker" <[email-masked]>, <[email-masked]>, "Leslie Daigle" <[email-masked]>, "David Holmes" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/)
Date: Sun, 28 Jun 1998 16:50:56 PDT
Importance: Normal
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

> > >This thread started off with an unhealthily aggressive tone, and has
> > >now just gotten off topic.

Just to lend some support:

In general, it is the responsibility and the authority of the
chair of the working group to moderate the discussion and
move things along productively. In particular, it is Leslie's
duty and right to close off topics as she sees fit.

I tried to keep my comments focused on the (new) proposal
to move NAPTR from "Experimental" to "Proposed Standard", but
if things seem to have gotten out of line, I apologize.

I think we've actually made a little progress recently, e.g., on the
long-standing issue of the utility of relative pointers in URIs,
and hoped we might be able to make some decisions in an area
where we'd left things at "we don't know yet" many years ago.
If that's not to be, so be it.

Larry
--
http://www.parc.xerox.com/masinter

From: Keith Moore <[email-masked]>
To: "Larry Masinter" <[email-masked]>
cc: "Keith Moore" <[email-masked]>, "=?iso-8859-1?B?Q2xhdXMgQW5kcukgRuRyYmVy?=" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://ds.i 
Date: Sun, 28 Jun 1998 18:51:29 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> > The more I think about it, the more I'm convinced that if there's 
> > going to be an IETF namespace, the names within that namespace
> > shouldn't reflect RFC numbers or STD numbers or ID names or anything
> > else.  They should consist entirely of serial numbers and/or dates.
> > Any approach that tries to use the existing names sets a misleading
> > example.
> > 
> > e.g. URN:ietf:23408 might correspond to RFC 822, and
> >      URN:ietf:28934 might correspond to STD 11
> 
> 
> Just to be clear about this: are you saying that you are convinced
> that the scheme laid out in draft-ietf-urn-ietf-03.txt should not
> be used?

There's nothing in that spec that violates the URN requirements.

However, I fear it makes a poor first example for a URN namespace,
because it encourages people to encode information about relationships
between documents in the URN.

> Are you opposed to someone using a structure
> 
>    <base href="URN:ietf">
> 
>         <A href="23408"> This is known as RFC 822 </A>
>         <A href="28934"> This is known as STD 11 </A>

Yes.  Again, it makes a poor example, because it encourages people
to use relative forms with URNs in the absence of any guidance
as to how to do so without degrading their persistence.

There are certainly cases where relative forms can be made to work
with URNs.  Since RFCs supposedly never change after publication,
I don't see how using relative forms within RFCs, to reference 
other RFCs, can cause any problems with URN persistence.  But this
is an unusual situation, and it doesn't generalize to most uses
of URNs.

I think it's incumbent on those who want to use relative forms with
URNs, to document conditions under which those forms will still
meet the URN persistence requirements.  Until that time, use of
relative forms with URNs should be considered experimental and
not-ready-for-prime-time.

Keith

From: "Larry Masinter" <[email-masked]>
To: "Keith Moore" <[email-masked]>, "=?iso-8859-1?B?Q2xhdXMgQW5kcukgRuRyYmVy?=" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://ds.i 
Date: Sun, 28 Jun 1998 15:13:50 PDT
Importance: Normal
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

> The more I think about it, the more I'm convinced that if there's 
> going to be an IETF namespace, the names within that namespace
> shouldn't reflect RFC numbers or STD numbers or ID names or anything
> else.  They should consist entirely of serial numbers and/or dates.
> Any approach that tries to use the existing names sets a misleading
> example.
> 
> e.g. URN:ietf:23408 might correspond to RFC 822, and
>      URN:ietf:28934 might correspond to STD 11

Just to be clear about this: are you saying that you are convinced
that the scheme laid out in draft-ietf-urn-ietf-03.txt should not
be used?

Are you opposed to someone using a structure

   <base href="URN:ietf">

        <A href="23408"> This is known as RFC 822 </A>
        <A href="28934"> This is known as STD 11 </A>

and would prefer that relative forms not be used, but require absolute
forms such as:

        <A href="urn:ietf/23408"> This is known as RFC 822 </A>
        <A href="urn:ietf/28934"> This is known as STD 11 </A>

or

        <A href="urn:ietf:23408"> This is known as RFC 822 </A>
        <A href="urn:ietf:28934"> This is known as STD 11 </A>

From: Keith Moore <[email-masked]>
To: [email-masked] (=?ISO-8859-1?Q?Claus_Andr=E9_F=E4rber?=)
cc: [email-masked], [email-masked]
Subject: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://ds.i 
Date: Sun, 28 Jun 1998 17:09:24 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> It would also reflect the organisation of most FTP servers that provide   
> RFCs and other IETF and related documents for downloading.

This is NOT a goal of URNs.  URNs should not reflect storage hierarchy,
because such hierarchies are inevitably going to change over time,
and URNs need to be stable.

The more I think about it, the more I'm convinced that if there's 
going to be an IETF namespace, the names within that namespace
shouldn't reflect RFC numbers or STD numbers or ID names or anything
else.  They should consist entirely of serial numbers and/or dates.
Any approach that tries to use the existing names sets a misleading
example.

e.g. URN:ietf:23408 might correspond to RFC 822, and
     URN:ietf:28934 might correspond to STD 11

(no, they're not the same thing)

Keith

From: Keith Moore <[email-masked]>
To: "Larry Masinter" <[email-masked]>
cc: [email-masked], "=?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?=" <[email-masked]>, "Phillip Hallam-Baker" <[email-masked]>, [email-masked], "Michael Richardson" <[email-masked]>, [email-masked], [email-masked]
Subject: [URN] Re: The "ietf" namespace and internet-drafts (was Re:ftp://ds.internic.net/rfc/) 
Date: Sun, 28 Jun 1998 13:56:08 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> > At first glance this might seem to be true.  But there have actually 
> > been serious proposals to split up the RFC series into different 
> > classes of documents, with different series names for informational,
> > experimental, and standards-track documents - and to grandfather
> > existing RFCs into those categories.  (this because some vendors 
> > have been known to cite informational RFCs as if they were standards)
> > 
> > I'm not really expecting it to happen, but if this were to happen,
> > it begs the question of how to handle relative references of 
> > a document that has names in multiple contexts.  Problem is, 
> > the contexts aren't themselves persistent.
> 
> This confuses me, since I thought this had already happened. There's
> a "STD" series, as well as an RFC series, and some documents have two
> names, one as a STD and another as an RFC. The fact that the STD
> series exists doesn't mean that it is useless to be able to
> define a context in which "rfc/1834" is interpreted relative
> to the base of "urn://ietf/".

No, but it does mean that you have problems interpreting
"822" within a document that can be referenced by either
"urn://ietf/rfc/822" or "urn://ietf/std/11".

And if we were to say "it's okay to define relative names relative
a URN namespace, but not in other cases" people would want to
define a new URN name space every time they wanted a new naming
context.  This is not the purpose of URN namespaces, and a large
number of URN namespaces would be a Bad Thing.

> > Which is why URNs - even for supposedly well-behaved document
> > series like RFCs - should ideally be opaque strings that don't 
> > imply any context whatsoever.  
> 
> "opaque" is a property of the interpreting agent. The URN can be
> opaque at one level and not at another.

In this case I meant "opaque to (most) humans", in the same sense
that ISBNs are opaque to (most) humans. 

> > Why not just use absolute URNs for this case?
> > What is gained by using relative naming here?
> 
> Relative forms are shorter, easier to type and maintain. 

They are not necessarily shorter.   Since URNs don't need to contain
human-readable components, and they don't have to reflect storage
hierarchies that are designed to be traversed by humans, they can
be very terse as compared to typical URLs.  

Relative forms are not necessarily easier to maintain, either,
because if you use a relative form with a URN, all combinations 
of "base URN + relative form" need to be maintained.

> Allowing relative forms for URNs might, in addition, allow a 
> URL->URN transition by allowing some contexts to set up a new 
> 'base' which is a URN rather than  a HTTP or FTP or whatever URL scheme.

Yes, but now you're back to trying to make relative forms work 
from within a document.  And this only works under certain poorly 
understood and extremely unlikely conditions, without undermining 
the long-term stability of the URN.  

Keith

Date: 26 Jun 1998 14:13:00 +0200
From: [email-masked] (=?ISO-8859-1?Q?Claus_Andr=E9_F=E4rber?=)
To: [email-masked]
Subject: Re: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.i
Sender: [email-masked]
Reply-To: [email-masked] (=?ISO-8859-1?Q?Claus_Andr=E9_F=E4rber?=)

Patrik Fältström <[email-masked]> schrieb:
> The question is because of that if
> urn:ietf:rfc/822
> and
> urn:ietf:rfc/822/../821
> is the same thing.

Wait a moment. This does not even apply to the average hierarchical file  
system, where dir1/dir2/file is not the same as dir1/dir2/file/../file2  
as dir1/dir2/file/. is invalid (i.e. it's no directory, but an object).

However, dir1/dir2/file is the same as dir1/dir3/../dir2/file.

For RFCs, relative URLs look a bit strange, e.g. if urn:ietf:2000 and  
urn:ietf:2001 are given, the first could reference the second one as  
urn:ietf:2001 or urn:ietf:./2000.

Then, for a hierarchical system it would require the URN to start with
"/", otherwise rfc/2000 would be ambigous: Is it /rfc/2000 or
./rfc/2000?

Nevertheless do I think that it makes sense and is the most logical  
thing to define ietf as a hierarchical namespace, even if it might be of  
limited use.
It would also reflect the organisation of most FTP servers that provide   
RFCs and other IETF and related documents for downloading.

--
Claus Andre Faerber <http://www.muc.de/~cfaerber/> Fax: +49_8061_3361
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E  25 56 69 A5 C6 A0 C9 DC

From: "Larry Masinter" <[email-masked]>
To: <[email-masked]>
Cc: "=?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?=" <[email-masked]>, "Phillip Hallam-Baker" <[email-masked]>, <[email-masked]>, "Michael Richardson" <[email-masked]>, <[email-masked]>
Subject: [URN] RE: The "ietf" namespace and internet-drafts (was Re:ftp://ds.internic.net/rfc/) 
Date: Sat, 27 Jun 1998 18:56:57 PDT
Importance: Normal
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

> At first glance this might seem to be true.  But there have actually 
> been serious proposals to split up the RFC series into different 
> classes of documents, with different series names for informational,
> experimental, and standards-track documents - and to grandfather
> existing RFCs into those categories.  (this because some vendors 
> have been known to cite informational RFCs as if they were standards)
> 
> I'm not really expecting it to happen, but if this were to happen,
> it begs the question of how to handle relative references of 
> a document that has names in multiple contexts.  Problem is, 
> the contexts aren't themselves persistent.

This confuses me, since I thought this had already happened. There's
a "STD" series, as well as an RFC series, and some documents have two
names, one as a STD and another as an RFC. The fact that the STD
series exists doesn't mean that it is useless to be able to
define a context in which "rfc/1834" is interpreted relative
to the base of "urn://ietf/".

> Which is why URNs - even for supposedly well-behaved document
> series like RFCs - should ideally be opaque strings that don't 
> imply any context whatsoever.  

"opaque" is a property of the interpreting agent. The URN can be
opaque at one level and not at another.

> > If you create a different series (say, the STD series), you might find
> > that relative references _within_ the document itself might be harmful,
> > but a list of STDs that used relative forms within the list would still
> > be useful.
> 
> Why not just use absolute URNs for this case?
> What is gained by using relative naming here?

Relative forms are shorter, easier to type and maintain. Allowing
relative forms for URNs might, in addition, allow a URL->URN transition
by allowing some contexts to set up a new 'base' which is a URN rather than
a HTTP or FTP or whatever URL scheme.

Larry

From: Keith Moore <[email-masked]>
To: "Larry Masinter" <[email-masked]>
cc: [email-masked], "=?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?=" <[email-masked]>, "Phillip Hallam-Baker" <[email-masked]>, [email-masked], "Michael Richardson" <[email-masked]>, [email-masked], [email-masked]
Subject: [URN] Re: The "ietf" namespace and internet-drafts (was Re:ftp://ds.internic.net/rfc/) 
Date: Sat, 27 Jun 1998 21:20:47 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> > If you look at the URN requirements document, you will see that
> > the ability to use relative forms is not one of the requirements
> > of URNs. 
> 
> It isn't one of the requirements that was agreed. If you're talking
> about RFC 1737, I think I remember the context of the document. And
> the question of whether 'relative forms' are _useful_ is different from
> the question of whether 'relative forms' are a requirement for URNs.

Relative identifiers are sometimes useful.  I don't think anyone 
disagrees with that.  The problem is, we haven't yet figured out 
how to give good advice for how to use relative identifiers in
a way that isn't detrimental to their long-term persistence.

> >  And there is a significant body of opinion that holds
> > that use of relative forms is detrimental to long-term persistence.
> 
> That would be dependent on the context and the use of those relative
> forms, wouldn't it? In particular, using a relative form WITHIN
> a document may be detrimental to long-term persistence, but a situation
> where you set up a context ("the RFC series") and then use relative forms
> within that context would seem to be perfectly reasonable, and not
> at all detrimental to long-term persistence.

At first glance this might seem to be true.  But there have actually 
been serious proposals to split up the RFC series into different 
classes of documents, with different series names for informational,
experimental, and standards-track documents - and to grandfather
existing RFCs into those categories.  (this because some vendors 
have been known to cite informational RFCs as if they were standards)

I'm not really expecting it to happen, but if this were to happen,
it begs the question of how to handle relative references of 
a document that has names in multiple contexts.  Problem is, 
the contexts aren't themselves persistent.

Which is why URNs - even for supposedly well-behaved document
series like RFCs - should ideally be opaque strings that don't 
imply any context whatsoever.  

> If you create a different series (say, the STD series), you might find
> that relative references _within_ the document itself might be harmful,
> but a list of STDs that used relative forms within the list would still
> be useful.

Why not just use absolute URNs for this case?
What is gained by using relative naming here?

Keith

From: "Larry Masinter" <[email-masked]>
To: <[email-masked]>
Cc: "=?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?=" <[email-masked]>, "Phillip Hallam-Baker" <[email-masked]>, <[email-masked]>, "Michael Richardson" <[email-masked]>, <[email-masked]>
Subject: [URN] RE: The "ietf" namespace and internet-drafts (was Re:ftp://ds.internic.net/rfc/) 
Date: Sat, 27 Jun 1998 18:06:49 PDT
Importance: Normal
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

> If you look at the URN requirements document, you will see that
> the ability to use relative forms is not one of the requirements
> of URNs. 

It isn't one of the requirements that was agreed. If you're talking
about RFC 1737, I think I remember the context of the document. And
the question of whether 'relative forms' are _useful_ is different from
the question of whether 'relative forms' are a requirement for URNs.

>  And there is a significant body of opinion that holds
> that use of relative forms is detrimental to long-term persistence.

That would be dependent on the context and the use of those relative
forms, wouldn't it? In particular, using a relative form WITHIN
a document may be detrimental to long-term persistence, but a situation
where you set up a context ("the RFC series") and then use relative forms
within that context would seem to be perfectly reasonable, and not
at all detrimental to long-term persistence.

> > Hierarchical forms are useful organizing principle for a collection of
> > documents if there is a single common organization of the documents for
> > which relative forms are a natural expression of the organization.
> 
> Just because there is thought to be a single common organization
> of the documents in a name space, does not mean that such organization
> is useful in the long term.

Keith, this doesn't make a lot of sense to me. If it is useful, it is
useful now, and for the forseeable future. That there are some uses that
might also be harmful ("relative references within the document itself")
doesn't mean that the other applications decline in utility.

> URNs should not indicate anything about the relationships between 
> documents, because the relationships between documents may change 
> over time.

The relationship between RFCs doesn't change, in that an RFC that makes
a reference to another RFC will always make reference to that RFC, and
the context of "the RFC series" makes sense over the lifetime of the
RFC series, independent of the storage media of the RFCs or their
locations.

If you create a different series (say, the STD series), you might find
that relative references _within_ the document itself might be harmful,
but a list of STDs that used relative forms within the list would still
be useful.

Larry

From: Keith Moore <[email-masked]>
To: "Phillip Hallam-Baker" <[email-masked]>
cc: "Leslie Daigle" <[email-masked]>, [email-masked], [email-masked]
Subject: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/) 
Date: Fri, 26 Jun 1998 12:47:37 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> If this group would not insist that it is creating a URN when
> it is actually creating a URL the charter of the URLREG would
> not have been written to exclude URNs.

You seem to have missed one of the basic premises of URNs -
which is not only that they are intended as long-term persistent
identifiers, but that they are visibly so to humans.  This is why 
URNs are intentionally distinguishable from URLs by humans.

It is of course possible and desirable to build resolution systems 
for URLs which allow them to be resolvable for the long term, and 
for some kinds of URLs to be chosen in such a way that they are
never reassigned.   It might even be useful to establish a 
convention for such URLs that indicates to users that the URL is
intended to be a long-term persistent identifier.

However, URNs raise the bar a bit over those kinds of URLs, by
employing various disciplines to discourage use of URNs as
non-persistent identifiers.  This is a deliberate, conscious,
and thoroughly considered design choice.

> You are essentially saying that this group is the only forum in
> the IETF at which URNs may be discussed.

URN is not a name for the class of URI which can be long-term
persistent.  URN is a particular kind of URI which is *required*
to be long-term persistent.

> I think Larry, Daniel, John and myself could pretty much agree on
> a set of identifiers which are unquestionably URN's. 

This may be the case.  But it sounds like you're trying to define
"URN" in a way which is at odds with the established consensus
of this working group.  This is inappropriate and unwelcome.

> Like myself they appear to hang arround the fringes of this 
> group occasionally raising their heads above the parapet 
> because they consider the issue important.

Some people apparently think that they can constrain the names
that other people can use to name resources -- they want to 
insist that all resource names fit a particular pattern which
reflects their view of the world.  URNs are not trying to 
constrain anything else.  People can use URNs if they want to,
and if URNs meet their needs.  If they don't like URNs, they 
can use URLs -- or they can define their own name spaces which
don't conform to the rules for either URNs or URLs.

> You have successfully driven away the likes of Ragget, Connoly
> and Berners-Lee who once were active in this area and also have
> some critical insights on the issue. Every time someone tries to
> question the preconceptions this group has taken to the problem
> they get slapped down. 

And rightly so.  It's well and good to question the assumptions
behind URNs - whether it's useful to have a separate name space
for persistent names, whether they should be visually distinct
from URLs, whether all of the "URN requirements" in RFC 1737
are appropriate.  But this discussion was had a long time ago,
and this group is premised on these assumptions.  If you don't
agree with the assumptions, don't use URNs, and don't waste
the group's time trying to argue that the premises are wrong.

The bottom line is that we can never be sure whether URNs are
a good thing until people start using them - and even if they 
are wildly successful there will still be some stubborn people 
who will insist that URNs were a Bad Idea.  

> There is a very simple, high leverage 90% solution that requires
> very little infrastructure and is entirely viable from a business
> model perspective. Separate the name from the resolution service
> entirely. Allow the folks building large search engines for the
> purpose of indexing the Internet to use them to do just that.

This is perfectly legitimate as one way to resolve URNs.  But there
are concerns about scalability, privacy, and currency if this is
the only method available.  More generally, URNs are supposed to be
usable for many decades, and a resolution system that happens to
work now many not work well a few decades from now.  So we don't
want to assume any particular URN resolution system.

Keith

From: [email-masked] (Peter Deutsch)
Date: Fri, 26 Jun 1998 11:40:02 -0400
To: "Phillip Hallam-Baker" <[email-masked]>, [email-masked], "Leslie Daigle" <[email-masked]>, David Holmes <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/)
Cc: <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked] (Peter Deutsch)

[ You wrote: ]

> >This thread started off with an unhealthily aggressive tone, and has
> >now just gotten off topic.
> 
> If you don't understand why the discussion Larry, Daniel and myself
> have just had is on topic I don't think I can help you.

Boy, talk about your agressive tone! Without trying to
speak on her behalf, as someone who has been involved with
this topic from day one, and someone who's seen a lot of
water go under the bridge since then, I'd have to agree
with Leslie that you're tone is getting in the way of your
content.

> > Phillip, we've now heard your perspective on "the right way" to do
> > URNs -- thank you for sharing.  I would direct you to read the
> > [email-masked] archives to get a more complete understanding of what
> > problem we have solved here, and why we've made the decisions we have.
> 
> Thanks, patronising comments like that are pretty much the reason
> why folk are apt to be somewhat aggressive.

Again, without attempting to speak on Leslie's behalf, I
want to say that she has been trying to "divide the
circle" in this area for a long time and she should be
given some credit as moderator.

There appears to be (to this observer) two fundamentally
opposed world views in the area of URNs and as I
understand it, there has been a conscious attempt to
separate the camps and allow the one faction to get its
work done. This should in no way stop others from pursuing
their ideas, but there was a lot of time lost on world
view debates and I personally approve of the chair trying
to head off another round at this point.

You may feel Leslie was being patronizing but I've known
her a long time and believe me, all she's trying to do is
get this particular piece of work closed.

> If this group would not insist that it is creating a URN when
> it is actually creating a URL the charter of the URLREG would
> not have been written to exclude URNs.

Okay, this is what I mean by "world views". If you don't
agree with the group's approach you are free to form your
own working group and write your own documents. If the
current URN working group is wrong, you will see it in the
results. If they are right, the work will prove useful.
Criticizing the axioms in this fashion just muddies the
water and reopens a long and (ultimately) sterile debate.

> You are essentially saying that this group is the only forum in
> the IETF at which URNs may be discussed.

Again, I submit that you are using a confrontational tone.
Unless I missed it, nobody said you can't have your own
approach to the problem. Nobody said you can't work on
your own projects in other groups. The chair merely has
tried to keep this particular group focused and going
forward. That's her job.

> 
> I think Larry, Daniel, John and myself could pretty much agree on
> a set of identifiers which are unquestionably URN's. Like myself
> they appear to hang arround the fringes of this group occasionally
> raising their heads above the parapet because they consider the
> issue important.

Then I submit you should write up your work. I could be
compared to the current effort. once the two are done.

> You have successfully driven away the likes of Ragget, Connoly
> and Berners-Lee who once were active in this area and also have
> some critical insights on the issue. Every time someone tries to
> question the preconceptions this group has taken to the problem
> they get slapped down. I think that is a bad way to run a group.

Again, this is an ad hominem attack. Given that your
message is in response to Leslie's mail, this leaves the
impression that you hold Leslie personally responsible for
"driving away" the likes of Tim Berners-Lee. This is a
rewriting of history.

Alan Emtage and I were the founders of the original URL
working group and after the group got underway, Jim Fulton
of CNIDR took my place. Even then, there was a fundamental
philosophical difference apparently among the people
interested in this topic. I personally had several
conversations with Tim, who (in my opinion) simply didn't
believe in the concept of URNs as it is currently
understood by this group. He wouldn't make requested
changes in the URL structure and appears to have written
off such discussions long before Leslie even appeared on
the scene. To tar her with this brush is really not
sporting. Perhaps blame Alan, myself or some of the others
who were active at that point, but I don't recall Tim
being active in this discussion since Leslie took on the
chair of the current URN group.

Dan and others did participate and have now bowed out but
you seem to be holding Leslie personally responsible. That
seems a bit strong, to say the least. This is the IETF.
Nobody wields *that* much power!

BTW, note that I'm not saying there wasn't a schism. There
was, and frankly I think it had to happen to allow this
particular group to get on with its work. If the
participants are wrong in their axioms, it will become
apparent soon enough. That's the Darwinian nature of the
net, as those who disagree with the axioms and conclusions
are free to not use the work output. What I see here is
that you are being fairly agressive, and I think, given
the history of this work, Leslie's call for some
moderation was appropriate and in keeping with her role as
group chair. 

Please consider toning down your anger.  We've seen far
too much debate on the axioms to reopen the question at
this point.

				- peterd

-- 
------------------------------------------------------------------------------
     Peter Deutsch,                                   (514) 875-8611  (phone)
  Bunyip Information Systems Inc.                     (514) 875-8134  (fax)
    <[email-masked]>                               http://www.bunyip.com

 "Get a job you like and you'll probably be quite good at it. And make your
  lifestyle fit your income. Don't try to make your income fit your
  lifestyle. It's that simple. Guys who like their job, they're very good
  at it. I don't care what it is..."
                                                - Chuck Yeager
----------------------------------------------------------------------------

From: [email-masked] (Peter Deutsch)
Date: Fri, 26 Jun 1998 11:40:02 -0400
To: "Phillip Hallam-Baker" <[email-masked]>, [email-masked], "Leslie Daigle" <[email-masked]>, David Holmes <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/)
Cc: <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked] (Peter Deutsch)

[ You wrote: ]

> >This thread started off with an unhealthily aggressive tone, and has
> >now just gotten off topic.
> 
> If you don't understand why the discussion Larry, Daniel and myself
> have just had is on topic I don't think I can help you.

Boy, talk about your agressive tone! Without trying to
speak on her behalf, as someone who has been involved with
this topic from day one, and someone who's seen a lot of
water go under the bridge since then, I'd have to agree
with Leslie that you're tone is getting in the way of your
content.

> > Phillip, we've now heard your perspective on "the right way" to do
> > URNs -- thank you for sharing.  I would direct you to read the
> > [email-masked] archives to get a more complete understanding of what
> > problem we have solved here, and why we've made the decisions we have.
> 
> Thanks, patronising comments like that are pretty much the reason
> why folk are apt to be somewhat aggressive.

Again, without attempting to speak on Leslie's behalf, I
want to say that she has been trying to "divide the
circle" in this area for a long time and she should be
given some credit as moderator.

There appears to be (to this observer) two fundamentally
opposed world views in the area of URNs and as I
understand it, there has been a conscious attempt to
separate the camps and allow the one faction to get its
work done. This should in no way stop others from pursuing
their ideas, but there was a lot of time lost on world
view debates and I personally approve of the chair trying
to head off another round at this point.

You may feel Leslie was being patronizing but I've known
her a long time and believe me, all she's trying to do is
get this particular piece of work closed.

> If this group would not insist that it is creating a URN when
> it is actually creating a URL the charter of the URLREG would
> not have been written to exclude URNs.

Okay, this is what I mean by "world views". If you don't
agree with the group's approach you are free to form your
own working group and write your own documents. If the
current URN working group is wrong, you will see it in the
results. If they are right, the work will prove useful.
Criticizing the axioms in this fashion just muddies the
water and reopens a long and (ultimately) sterile debate.

> You are essentially saying that this group is the only forum in
> the IETF at which URNs may be discussed.

Again, I submit that you are using a confrontational tone.
Unless I missed it, nobody said you can't have your own
approach to the problem. Nobody said you can't work on
your own projects in other groups. The chair merely has
tried to keep this particular group focused and going
forward. That's her job.

> 
> I think Larry, Daniel, John and myself could pretty much agree on
> a set of identifiers which are unquestionably URN's. Like myself
> they appear to hang arround the fringes of this group occasionally
> raising their heads above the parapet because they consider the
> issue important.

Then I submit you should write up your work. I could be
compared to the current effort. once the two are done.

> You have successfully driven away the likes of Ragget, Connoly
> and Berners-Lee who once were active in this area and also have
> some critical insights on the issue. Every time someone tries to
> question the preconceptions this group has taken to the problem
> they get slapped down. I think that is a bad way to run a group.

Again, this is an ad hominem attack. Given that your
message is in response to Leslie's mail, this leaves the
impression that you hold Leslie personally responsible for
"driving away" the likes of Tim Berners-Lee. This is a
rewriting of history.

Alan Emtage and I were the founders of the original URL
working group and after the group got underway, Jim Fulton
of CNIDR took my place. Even then, there was a fundamental
philosophical difference apparently among the people
interested in this topic. I personally had several
conversations with Tim, who (in my opinion) simply didn't
believe in the concept of URNs as it is currently
understood by this group. He wouldn't make requested
changes in the URL structure and appears to have written
off such discussions long before Leslie even appeared on
the scene. To tar her with this brush is really not
sporting. Perhaps blame Alan, myself or some of the others
who were active at that point, but I don't recall Tim
being active in this discussion since Leslie took on the
chair of the current URN group.

Dan and others did participate and have now bowed out but
you seem to be holding Leslie personally responsible. That
seems a bit strong, to say the least. This is the IETF.
Nobody wields *that* much power!

BTW, note that I'm not saying there wasn't a schism. There
was, and frankly I think it had to happen to allow this
particular group to get on with its work. If the
participants are wrong in their axioms, it will become
apparent soon enough. That's the Darwinian nature of the
net, as those who disagree with the axioms and conclusions
are free to not use the work output. What I see here is
that you are being fairly agressive, and I think, given
the history of this work, Leslie's call for some
moderation was appropriate and in keeping with her role as
group chair. 

Please consider toning down your anger.  We've seen far
too much debate on the axioms to reopen the question at
this point.

				- peterd

-- 
------------------------------------------------------------------------------
     Peter Deutsch,                                   (514) 875-8611  (phone)
  Bunyip Information Systems Inc.                     (514) 875-8134  (fax)
    <[email-masked]>                               http://www.bunyip.com

 "Get a job you like and you'll probably be quite good at it. And make your
  lifestyle fit your income. Don't try to make your income fit your
  lifestyle. It's that simple. Guys who like their job, they're very good
  at it. I don't care what it is..."
                                                - Chuck Yeager
----------------------------------------------------------------------------

Date: Fri, 26 Jun 1998 11:28:36 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: Roman Czyborra <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: Argh!!! Help! Your mailer-daemon is mail-bombing me!
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Hello everyone,

On Fri, 26 Jun 1998, Roman Czyborra wrote:
> 
> Today I have already received 75 copies of the following message:

Sorry about this -- I don't know what's happened.  I've forwarded a copy
of the problem message to our sys admin.

The best current guess is that some malformed headers in the original
message caused a rather nasty wipeout; I'm not yet sure whether that
happened at the poster's end, or when majordomo got its hands on it.

This seems to have only happened for one particular message;  if it happens
again, we'll have more data to track down the majordmo problem (if any).

Again, sorry for the mail dumping -- I wish I could offer something more
concrete in the way of explanation/assurance it won't happen again.

Leslie.

----------------------------------------------------------------------------

    "The nice thing about reality                 Leslie Daigle
       is that there are        
     so many versions to choose from."            Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

From: "Phillip Hallam-Baker" <[email-masked]>
To: "Leslie Daigle" <[email-masked]>, "Phillip Hallam-Baker" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/) 
Date: Thu, 25 Jun 1998 19:54:20 -0400
Importance: Normal
Sender: [email-masked]
Reply-To: "Phillip Hallam-Baker" <[email-masked]>

>This thread started off with an unhealthily aggressive tone, and has
>now just gotten off topic.

If you don't understand why the discussion Larry, Daniel and myself
have just had is on topic I don't think I can help you.

> Phillip, we've now heard your perspective on "the right way" to do
> URNs -- thank you for sharing.  I would direct you to read the
> [email-masked] archives to get a more complete understanding of what
> problem we have solved here, and why we've made the decisions we have.

Thanks, patronising comments like that are pretty much the reason
why folk are apt to be somewhat aggressive.

If this group would not insist that it is creating a URN when
it is actually creating a URL the charter of the URLREG would
not have been written to exclude URNs.

You are essentially saying that this group is the only forum in
the IETF at which URNs may be discussed.

I think Larry, Daniel, John and myself could pretty much agree on
a set of identifiers which are unquestionably URN's. Like myself
they appear to hang arround the fringes of this group occasionally
raising their heads above the parapet because they consider the
issue important.

You have successfully driven away the likes of Ragget, Connoly
and Berners-Lee who once were active in this area and also have
some critical insights on the issue. Every time someone tries to
question the preconceptions this group has taken to the problem
they get slapped down. I think that is a bad way to run a group.

There is a very simple, high leverage 90% solution that requires
very little infrastructure and is entirely viable from a business
model perspective. Separate the name from the resolution service
entirely. Allow the folks building large search engines for the
purpose of indexing the Internet to use them to do just that.

It is a solution which is viable and valid. It isn't one which
many would have considered viable in 1992 but it is viable today.

	Phill

From: "Phillip Hallam-Baker" <[email-masked]>
To: <[email-masked]>, "Phillip Hallam-Baker" <[email-masked]>
Cc: "=?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?=" <[email-masked]>, <[email-masked]>, "Michael Richardson" <[email-masked]>, <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re:ftp://ds.internic.net/rfc/)
Date: Thu, 25 Jun 1998 19:35:56 -0400
Importance: Normal
Sender: [email-masked]
Reply-To: "Phillip Hallam-Baker" <[email-masked]>

>  > Combine a DNS name, a time and an object reference and you
>  > have a label that can be ascribed a unique owner. Pretty
>  > handy basis for a URN huh?
> 
> We considered adding a date to the path scheme, but it seemed kind of
> intrusive, and provided no absolute guarantee of correct resolution by
> itself.  

Irrelevant. There is no guarantees ever possible with names. That is
their nature. Their relatiuonship to the designata is purely 
conventional and hence dependent on the authority which chooses
the convention.

>In the case of a hostile takeover of a name space, the new
> "owner" could resolve identifiers dated before the takeover in its favor
> and to the possible detriment of the original "owner" of the name space,

That is the purpose of the date. Adding it to the PDI means that
there is an objective definition of who has the right to assert
that binding. 

Enforcement is another issue entirely and not one which the URN
group can or should address.

>  > I think it is worthwhile adding a completely random GUID
>  > like name as well since there are times when a person
>  > does not have access to any registry whatsoever and human
>  > readability is irrelevant.
> 
> It is easy to provide a registry per person: simply give each person
> a prefix to attach to all identifiers that they want to register.

Not everything that needs to create identifiers is a person. Nor
is it necessarily the case that a systematic relationship
is desirable. 

We have an O/S based on GUIDs, it makes sense to translate them 
into the URN space simply as a legacy issue if nothing else.

> The purpose of assigning (or choosing, for that matter) random
> identifiers is generally to avoid any implied semantics.  A consequence
> of creating random identifiers is that it becomes more difficult to
> resolve them in a globally consistent and scalable manner - where do you
> look them up? 

Alta Vista.

that is if the object can be looked up. It might be a physical object
which was being referred to - or an idea - or any one of a hundred
'resources' which need a name but are not necessarily resolvable
on a computer network.

> The uniqueness requirement is really about the reverse relationship,
> that a single name must only have a single resource associated with it,
> such that everyone can use it mean the same thing.  (But the definition
> of "a single resource" is left open.)

An equally bogus requirement. The resolution of a name is dependent
on context. The President of the United States and Bill Clinton are
two names which in the context of 1998 resolve to the same thing
but in 2002 will not.

It is a good thing for names to be re-used. The more this takes 
place the more usefull the name becomes. It is not a 'requirement'
however and cannot be.

> This kind of non-uniqueness seems to be about relative names, where a
> single relative name may have a different meaning depending upon the
> context of its use.  This is valid, but it is quite different from
> resources having more than one name, although the reason they might have
> more than one name is that they have different names relative to
> different contexts.

No, it is not. All names are relative to an interpretation that
defines their semantics. That is inescapable - as you conclude yourself.

> (BTW, the unique id in the current URN scheme is unique relative to the
> naming authority; the very same id might be used in by another naming
> authority to mean something different.  But supposedly, the unique id is
> never separated from its naming authority.)

I think it is possible to create a mechanism by which folk who are
acting in good faith will not accidentally re-use the same 
identifier. I don;t think it is practical to insist that a scheme
guarantee that this cannot happen. Essentially that is a trust issue
which should be left to a PKI.

You may then end up with a SDSI like system in which you have 
'Phill's URN:foobar'. In order to remove the relative qualifiers
you need to be able to trust that Phill's idea of a foobar
conforms to normal usage.

		Phill

From: Keith Moore <[email-masked]>
To: "Larry Masinter" <[email-masked]>
cc: "=?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?=" <[email-masked]>, "Phillip Hallam-Baker" <[email-masked]>, [email-masked], "Michael Richardson" <[email-masked]>, [email-masked], [email-masked]
Subject: [URN] Re: The "ietf" namespace and internet-drafts (was Re:ftp://ds.internic.net/rfc/) 
Date: Fri, 26 Jun 1998 09:31:24 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> No, that isn't necessary. The only important question is whether it is
> useful to define relative forms. For example, might you want to write
> a document that talks about all of the RFCs, and in which it defines
> a context which has, for example,
>       BASE="urn:ietf:rfc"
> 
> and then uses relative forms "822", "821" for the RFCs themselves.

If you look at the URN requirements document, you will see that
the ability to use relative forms is not one of the requirements
of URNs.   And there is a significant body of opinion that holds
that use of relative forms is detrimental to long-term persistence.

> Hierarchical forms are useful organizing principle for a collection of
> documents if there is a single common organization of the documents for
> which relative forms are a natural expression of the organization.

Just because there is thought to be a single common organization
of the documents in a name space, does not mean that such organization
is useful in the long term.

URNs should not indicate anything about the relationships between 
documents, because the relationships between documents may change 
over time.

Keith

Date: Fri, 26 Jun 1998 09:28:30 -0400
To: "Larry Masinter" <[email-masked]>, "Phillip Hallam-Baker" <[email-masked]>, <[email-masked]>, "Michael Richardson" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re:ftp://ds.internic.net/rfc/)
Cc: <[email-masked]>
Sender: [email-masked]
Reply-To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>

At 22.03 -0700 98-06-25, Larry Masinter wrote:
>> The new I-D regarding the URI syntax do specify not only that the '/' is a
>> special character regarding hierarchy, but also what means with hierarchy.
>> One example, the construction <term>/.. can always be removed from the URI.
>
>But this isn't true, Patrik. ".." only has a special meaning **within
>a relative path-reference".
>
>#  these path components are only considered special
>#  when resolving a relative-path reference to its absolute form
>#  (Section 5.2).
>
>There is no restriction about using ".." within an absolute URI, although
>it reduces the utility of some relative forms.

This is a separate discussion which Larry, I and others already have
regarding URI's and not URN's, but I think it is important that I just make
my point clearer here.

My point is that it is very confusing if it is the case that the absolute
URI foo://bar/a/../b is not the same as ./a/../b when the base is
foo://bar. This is one of three minor issues I want to have changed in the
current I-D.

I.e. IF you have a URI which conforms to the "generic URI syntax", the
constructions '/', './' and '<term>/..' should all be valid and the same
regardless if it is a relative or absolute URI.

I'll be back in one hour approximately to you personally with the three
changes.

    Patrik

Date: Thu, 25 Jun 1998 23:46:08 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/)
To: "Karen R. Sollins" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Ned Freed <[email-masked]>

>    > The bottom line is that I see no reason not to include URNs for I-D's
>    > as long as there is some scheme for generating unique ones, and in
>    > fact it might be quite useful, as several people have pointed out.

>    The best way to handle this is probably to ask the folks
>    who accept internet-drafts, to see whether they are willing
>    to adopt disciplines for assignment of internet-draft IDs,
>    to make sure that they are never re-assigned.

Actually, I think this is part of the procedure already. When I've
tried to submit a I-D for standard in the proposed --> draft cycle,
I've been prevented from reusing the I-D name from the
WG --> proposed cycle. I don't know if this is a hard-and-fast rule, but is
doesn't sound like it would be hard to make it one.

> Yep - it might not be a bad idea to include a timestamp or hash (like
> MD5) of the document or something like that as well, just for safety's
> sake.

That would be fine too, of course.

				Ned

From: "Larry Masinter" <[email-masked]>
To: "=?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?=" <[email-masked]>, "Phillip Hallam-Baker" <[email-masked]>, <[email-masked]>, "Michael Richardson" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re:ftp://ds.internic.net/rfc/)
Date: Thu, 25 Jun 1998 22:03:47 PDT
Importance: Normal
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

Patrik Fältström wrote:

> The new I-D regarding the URI syntax do specify not only that the '/' is a
> special character regarding hierarchy, but also what means with hierarchy.
> One example, the construction <term>/.. can always be removed from the URI.

But this isn't true, Patrik. ".." only has a special meaning **within
a relative path-reference".

#  these path components are only considered special
#  when resolving a relative-path reference to its absolute form
#  (Section 5.2).

There is no restriction about using ".." within an absolute URI, although
it reduces the utility of some relative forms.

> If this is not the case, you do not have hierarchy, which in turn means
> that you have to use a different delimiter than the '/'.
> This means that if you have
>
> foo/bar
> fratz/oof
>
> then foo/bar and fratz/oof/../bar is the same thing. If that is the case,
> then you can use the '/' as divider.
> I.e. the way I see it, what you ask for IS in the new proposed I-D for
> URI's, but it at the same time defines (in a good way) what it means by
> being hierarichal. Things that are not hierarichal should not use '/'.

The only important interpretation of hierarchical is that 'relative forms
can be used'.

> The question is because of that if
>
> urn:ietf:rfc/822
>
> and
>
> urn:ietf:rfc/822/../821
>
> is the same thing.

No, that isn't necessary. The only important question is whether it is
useful to define relative forms. For example, might you want to write
a document that talks about all of the RFCs, and in which it defines
a context which has, for example,
      BASE="urn:ietf:rfc"

and then uses relative forms "822", "821" for the RFCs themselves.

Hierarchical forms are useful organizing principle for a collection of
documents if there is a single common organization of the documents for
which relative forms are a natural expression of the organization.

Larry

Date: Fri, 26 Jun 1998 11:36:43 +0900 (JST)
From: Mail Delivery Subsystem <[email-masked]>
Subject: [URN] Returned mail: Service unavailable
To: <[email-masked]>
To: "[email-masked] X-URI": "http://www.cs.utk.edu/~moore/ From: Keith Moore <[email-masked]> cc: \"Roman Czyborra\"" <[email-masked]>
To: [email-masked]
To: "[email-masked] Mime-Version": 1.0.Content-Type:text/plain;charset=us-ascii.Date:[email-masked];;;@mocha.bunyip.com;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
To: 25 Jun 1998 17:"30:14 -0400 Sender: [email-masked] Precedence: bulk Reply-To: Keith Moore" <[email-masked]> Errors-To: [email-masked]
Auto-Submitted: auto-generated (failure)
Sender: [email-masked]
Reply-To: Mail Delivery Subsystem <[email-masked]>

This is a MIME-encapsulated message

--LAA22123.898828603/tama.tas.ntt.co.jp

The original message was received at Fri, 26 Jun 1998 11:36:37 +0900 (JST)
from services.Bunyip.Com [192.77.55.2]

   ----- The following addresses had permanent fatal errors -----
<[email-masked]>

   ----- Transcript of session follows -----
... while talking to [192.68.248.11]:
>>> DATA
<<< 550 "[email-masked]
554 <[email-masked]>... Service unavailable

--LAA22123.898828603/tama.tas.ntt.co.jp
Content-Type: message/delivery-status

Reporting-MTA: dns; tama.tas.ntt.co.jp
Received-From-MTA: DNS; services.Bunyip.Com
Arrival-Date: Fri, 26 Jun 1998 11:36:37 +0900 (JST)

Final-Recipient: RFC822; [email-masked]
Action: failed
Status: 5.2.0
Remote-MTA: DNS; [192.68.248.11]
Diagnostic-Code: SMTP; 550 "[email-masked]
Last-Attempt-Date: Fri, 26 Jun 1998 11:36:43 +0900 (JST)

--LAA22123.898828603/tama.tas.ntt.co.jp
Content-Type: text/rfc822-headers

Date: Thu, 25 Jun 1998 22:04:58 -0400
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked],
        [email-masked]
Subject: Re: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/)
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>
   Precedence: bulk
   Reply-To: Keith Moore" <[email-masked]>
   Errors-To: [email-masked]

--LAA22123.898828603/tama.tas.ntt.co.jp--

Date: Thu, 25 Jun 1998 22:21:24 -0400
From: Mail Delivery Subsystem <[email-masked]>
Subject: [URN] Returned mail: User unknown
To: 25 Jun 1998 17:"30:14 -0400 Sender: [email-masked] Precedence: bulk Reply-To: Keith Moore" <[email-masked]> Errors-To: [email-masked]
Sender: [email-masked]
Reply-To: Mail Delivery Subsystem <[email-masked]>

<<< RCPT To:<[email-masked]>
<<< DATA
550 "[email-masked]
   Mime-Version": 1.0.Content-Type:text/plain;charset=us-ascii.Date:[email-masked];... User unknown
<<< QUIT

   ----- Unsent message follows -----
Date: Thu, 25 Jun 1998 22:04:58 -0400
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
        [email-masked]
Subject: Re: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/)
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>
   Sender: [email-masked]
   Precedence: bulk
   Reply-To: Keith Moore" <[email-masked]>
   Errors-To: [email-masked]

   > The whole point of URNs is that the underlying resource has permanance.
   > Internet-Drafts, by there definition, expire in 6 months and can be 
   > replaced at any time.  Therefore, they were purposely excluded from
   > the "ietf" definition.

   Nope.  The binding between the URN and the resource has permanence,
   but that doesn't mean that resource itself is available for a long
   time.  

   (And for what it's worth, there are places that keep old I-Ds around.)

   Keith

It seems to me that the real issue is whether or not the URNs
generated from I-Ds would be long-lived.  I agree with Keith that the
question of permanence of the resource is irrelevant.  What is
important is that the URN not be reassigned to another resource.

What is the policy with respect to I-D names and long-term uniqueness?
There are two sources of I-D's reflected in their names, those from
WGs and those that are in some sense unsolicited, from individuals or
organizations outside the IETF.  I suspect that working group names
and acronyms don't get reused (but I don't know whether there is any
policy on this), so it isn't hard to imagine that the I-D's out of
working groups are intended to be long-lived.  The problem may be with
names for the other I-D's.  Something like "draft-smith-new-ip-00.txt"
may not be unique.  My recollection is that the author gets to choose,
within some guidelines that include the author's name.  Since we can
be quite sure that two I-D's won't have the same name at the same
time, using a timestamp would be one way of generating unique names
that could be as URNs.  Obviously there are also others, but long-term
uniqueness is the issue that is important here.

The bottom line is that I see no reason not to include URNs for I-D's
as long as there is some scheme for generating unique ones, and in
fact it might be quite useful, as several people have pointed out.

			Karen

Date: Thu, 25 Jun 1998 22:20:33 -0400
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/)
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

   > The bottom line is that I see no reason not to include URNs for I-D's
   > as long as there is some scheme for generating unique ones, and in
   > fact it might be quite useful, as several people have pointed out.

   The best way to handle this is probably to ask the folks
   who accept internet-drafts, to see whether they are willing
   to adopt disciplines for assignment of internet-draft IDs,
   to make sure that they are never re-assigned.

   Keith

Yep - it might not be a bad idea to include a timestamp or hash (like
MD5) of the document or something like that as well, just for safety's
sake.

			Karen

From: Keith Moore <[email-masked]>
To: "Karen R. Sollins" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/) 
Date: Thu, 25 Jun 1998 22:13:40 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> The bottom line is that I see no reason not to include URNs for I-D's
> as long as there is some scheme for generating unique ones, and in
> fact it might be quite useful, as several people have pointed out.

The best way to handle this is probably to ask the folks
who accept internet-drafts, to see whether they are willing
to adopt disciplines for assignment of internet-draft IDs,
to make sure that they are never re-assigned.

Keith

Date: Thu, 25 Jun 1998 22:04:58 -0400
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/)
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

   > The whole point of URNs is that the underlying resource has permanance.
   > Internet-Drafts, by there definition, expire in 6 months and can be 
   > replaced at any time.  Therefore, they were purposely excluded from
   > the "ietf" definition.

   Nope.  The binding between the URN and the resource has permanence,
   but that doesn't mean that resource itself is available for a long
   time.  

   (And for what it's worth, there are places that keep old I-Ds around.)

   Keith

It seems to me that the real issue is whether or not the URNs
generated from I-Ds would be long-lived.  I agree with Keith that the
question of permanence of the resource is irrelevant.  What is
important is that the URN not be reassigned to another resource.

What is the policy with respect to I-D names and long-term uniqueness?
There are two sources of I-D's reflected in their names, those from
WGs and those that are in some sense unsolicited, from individuals or
organizations outside the IETF.  I suspect that working group names
and acronyms don't get reused (but I don't know whether there is any
policy on this), so it isn't hard to imagine that the I-D's out of
working groups are intended to be long-lived.  The problem may be with
names for the other I-D's.  Something like "draft-smith-new-ip-00.txt"
may not be unique.  My recollection is that the author gets to choose,
within some guidelines that include the author's name.  Since we can
be quite sure that two I-D's won't have the same name at the same
time, using a timestamp would be one way of generating unique names
that could be as URNs.  Obviously there are also others, but long-term
uniqueness is the issue that is important here.

The bottom line is that I see no reason not to include URNs for I-D's
as long as there is some scheme for generating unique ones, and in
fact it might be quite useful, as several people have pointed out.

			Karen

From: Keith Moore <[email-masked]>
To: "Ryan Moats" <[email-masked]>
cc: "Roman Czyborra" <[email-masked]>, [email-masked], [email-masked]
Subject: [URN] Re: The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/) 
Date: Thu, 25 Jun 1998 17:30:14 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> The whole point of URNs is that the underlying resource has permanance.
> Internet-Drafts, by there definition, expire in 6 months and can be 
> replaced at any time.  Therefore, they were purposely excluded from
> the "ietf" definition.

Nope.  The binding between the URN and the resource has permanence,
but that doesn't mean that resource itself is available for a long
time.  

(And for what it's worth, there are places that keep old I-Ds around.)

Keith

Date: Thu, 25 Jun 1998 15:39:41 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
cc: [email-masked]
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/) 
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Howdy,

This thread started off with an unhealthily aggressive tone, and has
now just gotten off topic.  

Phillip, we've now heard your perspective on "the right way" to do
URNs -- thank you for sharing.  I would direct you to read the 
[email-masked] archives to get a more complete understanding of what 
problem we have solved here, and why we've made the decisions we have.

Thanks,
Leslie.
(URN WG co-chair)

----------------------------------------------------------------------------

    "The nice thing about reality                 Leslie Daigle
       is that there are        
     so many versions to choose from."            Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

From: <[email-masked]>
Date: Thu, 25 Jun 1998 14:45:20 -0400 (EDT)
To: "Phillip Hallam-Baker" <[email-masked]>
Cc: =?ISO-8859-1?Q?=22Patrik_F=E4ltstr=F6m=22?= <[email-masked]>, <[email-masked]>, "Michael Richardson" <[email-masked]>, <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re:ftp://ds.internic.net/rfc/)
Sender: [email-masked]
Reply-To: <[email-masked]>

Phillip raises a couple new twists of the naming issue.  I largely agree
with him, but we have some discussion points.

Phillip Hallam-Baker writes:
 > I still think that the naming scheme should simply be an
 > extension of the DNS registry. [...] Any
 > scheme that is predicated on a new registry of any sort [is]
 > doomed.

I agree.  Since you are pushing the PDI scheme of late, I'd like to
remind people that the "path" scheme uses DNS extensively, of course,
but also, importantly, it blurs the distinction between the part
resolved by DNS and the remainder that could be internal to a server.

 > Combine a DNS name, a time and an object reference and you
 > have a label that can be ascribed a unique owner. Pretty
 > handy basis for a URN huh?

We considered adding a date to the path scheme, but it seemed kind of
intrusive, and provided no absolute guarantee of correct resolution by
itself.  In the case of a hostile takeover of a name space, the new
"owner" could resolve identifiers dated before the takeover in its favor
and to the possible detriment of the original "owner" of the name space,
unless there were some higher-level arbiter that decides for the good of
all what the "correct" resolution is.  But given such an arbiter, it
could make such a decision regardless of the presense of a date in the
identifier, if it decides that a particular identifier is forever
associated with one particular resource, as names are intended to
behave.

Furthermore, name spaces are free to include dates in their identifiers
if they wish.  Why should they be required to do so?

 > I think it is worthwhile adding a completely random GUID
 > like name as well since there are times when a person
 > does not have access to any registry whatsoever and human
 > readability is irrelevant.

It is easy to provide a registry per person: simply give each person
a prefix to attach to all identifiers that they want to register.

The purpose of assigning (or choosing, for that matter) random
identifiers is generally to avoid any implied semantics.  A consequence
of creating random identifiers is that it becomes more difficult to
resolve them in a globally consistent and scalable manner - where do you
look them up?   So I am not sure what they are good for, except for 
purposes of comparison, or local lookup in a cache (e.g. news messages).

 > The hard part is (3). The key is that an object MAY HAVE
 > MORE THAN ONE NAME. Nothing was so bogus as the incessant
 > demands that names be unique! How on earth can a sign which
 > has no systematic relationship to the designata POSSIBLY
 > be unique. The requirement was pure nonsense.

I think you misinterpreted the requirement.  I think the requirement
as stated is fairly easily misunderstood, so don't feel too bad.

There has been reluctant acceptance of the notion that resources MAY
have more than one name.  I say "reluctant" because I don't see much
movement towards dealing with the consequences of resources having more
than one name.  

The uniqueness requirement is really about the reverse relationship,
that a single name must only have a single resource associated with it,
such that everyone can use it mean the same thing.  (But the definition
of "a single resource" is left open.)

 > Names are not unique for the simple reason that they have
 > no meaning except in relation to another name. Everything
 > is relative to a world view and even given the fact that
 > we have a shared ontology we most frequently use names
 > to describe relationships between concepts rather than
 > atomic constructs.

 > So I say 'what is the weather like today', and refer to
 > an entirely different 'weather' than Larry would in
 > el ninio stricken California.

This kind of non-uniqueness seems to be about relative names, where a
single relative name may have a different meaning depending upon the
context of its use.  This is valid, but it is quite different from
resources having more than one name, although the reason they might have
more than one name is that they have different names relative to
different contexts.

(BTW, the unique id in the current URN scheme is unique relative to the
naming authority; the very same id might be used in by another naming
authority to mean something different.  But supposedly, the unique id is
never separated from its naming authority.)

 > In a system of knowledge we must have the ability to refer
 > to a designatum by any relationship to any other
 > designatum we need to.

That's fine.  But should we go further to say that a reference can ONLY
be relative to some designatum?  I.e. there is ALWAYS a context for the
interpretation of a reference.  I believe so.

--
Daniel LaLiberte
 [email-masked]  (was: [email-masked])
 [email-masked]

From: "Phillip Hallam-Baker" <[email-masked]>
To: "Michael Richardson" <[email-masked]>, <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/) 
Date: Thu, 25 Jun 1998 13:37:12 -0400
Importance: Normal
Sender: [email-masked]
Reply-To: "Phillip Hallam-Baker" <[email-masked]>

>     Phillip> Get Microsoft to modify Frontpage so that it automatically
>     Phillip> throws a GUID into every HTML document it produces 
> and you have
> 
>   Let's not bring up products that don't produce useful HTML.

Make it easy to do and everyone can support it. I was thinking 
mainly in terms of finding one product that could set a lead.

>   I certainly agree that a documentID, ala MessageId is a good thing. 
>   I would suggest that it makes an excellent proposal for one URN type. 
> However, there are a lot of things, like the IETF documents, which do
> have a structure, can easily have cross references, and don't need to
> have their structure hidden from humans.

Absolutely. But there is a massive difference between allowing 
structure and requiring structure.

>   I think that there is space in the URN space for both types of 
> solutions.

Yes. What I think should not be allowed in URN space is any form
of locator scheme - regardless of the number of levels of
indirection employed.

> The IETF document space is a simple and clear system, with the 
> advantage that
> the consistuency involved is very capable of adopting it.

I entirely disagree.

The IETF is so ossified it cannot even agree to use HTML as 
the basis for specifications. I know the history of that 
decision - a bad experience with postscript but HTML answers 
that objection.

There is no process for effecting such a change in the IETF.

If the hope is to organize the way the RFC editor does her job,
well have fun trying. 

		Phill

To: [email-masked]
Subject: Re: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/) 
Date: Thu, 25 Jun 1998 13:23:15 -0300
From: Michael Richardson <[email-masked]>
Sender: [email-masked]
Reply-To: Michael Richardson <[email-masked]>

>>>>> "Ryan" == Ryan Moats <[email-masked]> writes:
    Ryan> This is an issue for the I-D repository folks at ietf.org.  If you
    Ryan> are volunteering, I'm sure they will be very interested :-).

  While the ID editors may remove a draft, I may want to retain is locally,
and continue to have my local URNs work.
  A number of groups have had drafts untouched for six months because those
drafts depended on ones that were ungoing massive changes.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[email-masked]</A>. PGP key available.
 Corporate: <A HREF="mailto:[email-masked]">[email-masked]</A>. 

To: [email-masked]
Subject: Re: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/) 
Date: Thu, 25 Jun 1998 13:20:33 -0300
From: Michael Richardson <[email-masked]>
Sender: [email-masked]
Reply-To: Michael Richardson <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Ryan" == Ryan Moats <[email-masked]> writes:
    Ryan> As another IETF person who mirrors the RFCs and the drafts (from
    Ryan> behind a modem connection), the amount of extra time is not all
    Ryan> that noticable.

  I'm not talking about the time to download to your site.
  I'm talking about the fact that my web cache can't connect
	ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-ietf-05.txt
  with even:
	http://www.ietf.org/internet-drafts/draft-ietf-urn-ietf-05.txt

  I build local indexes on the internet drafts and the RFCs (which I do based
upon local criteria, what we are working on), I have to use the internal
URL, rather than use the external URL and know that my internal cache
knows that I have a mirror.
  Ideally, with some smarts in my web cache and/or local URN->URL converter,
it can fetch a new draft in real time when I click on the URL in the 
IETF-announce'ment.

    Ryan> While I don't have a strong stake in the exclusion/inclusion of
    Ryan> IDs, there was a discussion of this in the archives some time back
    Ryan> and no complaints were raised.  Under the heading of "my bad",

  I had brain CPU cycles devoted elsewhere. I assumed the right thing
was occuring here :-)
  I also just moved employers, and wound up setting up a new mirror. I need
to hack FTP mirror to use the protocol to get the listing, but to use a
web proxy to get the articles. You see, my current and previous employers'
use the same ISP, and we'd benefit by going through their cache for the
documents. I then wished I didn't have to go directly to ftp.ietf.org,
but could grab from some other less likely to be loaded site. However,
there aren't as many ID draft mirrors as their used to be. (Or maybe I'm
just deluded)

    Ryan> there was a statement to the effect of why IDs were ignored in -02
    Ryan> that has fallen out.  I'll put such a statement back in and
    Ryan> re-release as -06 (once I get back from my business trip).

  Thank you.

    Ryan> Of course, if there is working group consensus that IDs should be
    Ryan> added, I will do so.

  I would prefer it.

    Ryan> This one has to do with the wording of 2141. If you look at section
    Ryan> 2.3.2 you find:

  I will re-read that rfc and comment more. I think I read it first
before it was an RFC.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[email-masked]</A>. PGP key available.
 Corporate: <A HREF="mailto:[email-masked]">[email-masked]</A>. 

To: [email-masked]
Subject: Re: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/) 
Date: Thu, 25 Jun 1998 13:01:20 -0300
From: Michael Richardson <[email-masked]>
Sender: [email-masked]
Reply-To: Michael Richardson <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Phillip" == Phillip Hallam-Baker <[email-masked]> writes:
    Phillip> the radio without appearing to have a fixation I can't see any
    Phillip> reason to change from the slashes used in URLs.

  Yes.

    Phillip> Get Microsoft to modify Frontpage so that it automatically
    Phillip> throws a GUID into every HTML document it produces and you have

  Let's not bring up products that don't produce useful HTML.

    Phillip> Such a scheme is a rough and ready hack that does not solve all
    Phillip> the alledged requirements in the RFC. It is a high leverage idea
    Phillip> however, it gives high return at low cost. In short it is like a
  
  I certainly agree that a documentID, ala MessageId is a good thing. 
  I would suggest that it makes an excellent proposal for one URN type. 
However, there are a lot of things, like the IETF documents, which do
have a structure, can easily have cross references, and don't need to
have their structure hidden from humans.

    Phillip> If this group wants to actually achieve something it should
    Phillip> decide whether its objective is simply to provide a better URL
    Phillip> with one extra level of indirection or a genuine URN. Since the
    Phillip> proposals all seem to be for a URL with extra indirection I
    Phillip> suggest that the name be changed.

  I think that there is space in the URN space for both types of solutions.
The IETF document space is a simple and clear system, with the advantage that
the consistuency involved is very capable of adopting it.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[email-masked]</A>. PGP key available.
 Corporate: <A HREF="mailto:[email-masked]">[email-masked]</A>. 

From: "Phillip Hallam-Baker" <[email-masked]>
To: "=?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?=" <[email-masked]>, "Phillip Hallam-Baker" <[email-masked]>, <[email-masked]>, "Michael Richardson" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re:ftp://ds.internic.net/rfc/)
Date: Thu, 25 Jun 1998 12:22:03 -0400
Importance: Normal
Sender: [email-masked]
Reply-To: "Phillip Hallam-Baker" <[email-masked]>

> urn:ietf:rfc/822
>
> and
>
> urn:ietf:rfc/822/../821
>
> is the same thing.
>
> If it is not (or if the latter is undefined in the namespace) then '/' can
> not be used as divider.

Yep, this is what should happen.

I still think that the naming scheme should simply be an
extension of the DNS registry. Any scheme that is specific
enough that it has to address the IETF as a special case
is bogus. There are a million odd sites out there. Any
scheme that is predicated on a new registry of any sort
doomed.

Since the ownership of a dns name is unambiguous at one
point in time the construction of John's PDIs is about
as good as you will get for a human readable name.

Combine a DNS name, a time and an object reference and you
have a label that can be ascribed a unique owner. Pretty
handy basis for a URN huh?

John's PDI's are not necessarily the final word. One might
argue that a bit more hierarchy could be supported. On the
other hand I think they pretty much work in the context for
which they were designed - central assignment of persistent
identifiers from a single issuing center in a system that
supports multiple decentralized and disconnected issuing
centers.

I think it is worthwhile adding a completely random GUID
like name as well since there are times when a person
does not have access to any registry whatsoever and human
readability is irrelevant.

I would also say that nobody should EVER be allowed to use
the urn prefix, especially for any scheme that is designed
to suppot location which is therefore indexical in nature
and not a name. The prefixes URL and URI were always reserved
as generics. The prefix URN should also be reserved as generic.

The proposal to prefix every URI with URL or URN was and is
entirely bogus. Just like the folk who demanded the little
angle brackets - an equally worthless syntactic sugar which
broke existing implementations.

If the group actually wanted to achieve something we could knock
out a series of genuine URN drafts in a week.

1) A PDI like system
2) Some system based on a randomly chosen string of digits.
3) A draft defining bindings to HTML and HTTP

I think that (1) is relatively straightforward and usefull
with little room for argument over the details. It might
be necessary to remove the versioning part and allow for
hierachical structure so that a closure formed on a
collection of related HTML texts linked by relative URLs
could be captured.

while I like the versioning part this might be added in in
some other fashion - by modification of the resource name
for example, or by simply making it optional. Or since
the archival issue is only wrt static texts a query term
might be employed (foobar?version=1)

Draft (2) is pretty simple. One can argue only about
whether it should be base16 or base64. The former is
probably essential since it is simply not practical to
read out case sensitive identifiers in mixed case.

Alternatively one might grandfather the GUID scheme by
simply allowing hyphens to be added anywhere and for
either base16 or base64 with a trailing == to be
employed. The canonical form could be chosen arbitrarily.
The transformations to canonical form are obvious and are
left as an exercise for the reader.

The hard part is (3). The key is that an object MAY HAVE
MORE THAN ONE NAME. Nothing was so bogus as the incessant
demands that names be unique! How on earth can a sign which
has no systematic relationship to the designata POSSIBLY
be unique. The requirement was pure nonsense.

Names are not unique for the simple reason that they have
no meaning except in relation to another name. Everything
is relative to a world view and even given the fact that
we have a shared ontology we most frequently use names
to describe relationships between concepts rather than
atomic constructs.

So I say 'what is the weather like today', and refer to
an entirely different 'weather' than Larry would in
el ninio stricken California.

Even as we hypothesize a single, unified shared vocabulary
names are not unique since an object may have more than a
single relationship to its environment. The names 'Bill
Clinton' and 'the 42nd President of the United States of
Amrerica' are both signs which relate to the same person.
'Bill Clinton' is a pure name, 42nd etc has a quasi
indexical quality to it but is actually a compound of
a relationship "42nd" to a name "USA".

There is no earthly reason to insist that Bill be only
ever known by one name. The fact is that the name attaches
to the relationship of the designata to the environment and
not to the thing itself.

In a system of knowledge we must have the ability to refer
to a designatum by any relationship to any other
designatum we need to.

	Phill

Date: Thu, 25 Jun 1998 10:13:09 -0400
To: "Phillip Hallam-Baker" <[email-masked]>, <[email-masked]>, "Michael Richardson" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/)
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]
Reply-To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>

At 09.28 -0400 98-06-25, Phillip Hallam-Baker wrote:
>Since Gopher is now irrelevant I suggest that the URI RFC be rewritten
>to state what should always have been the case. The name space is
>hierarchical and employs the / character to denote hierarchy.

The new I-D regarding the URI syntax do specify not only that the '/' is a
special character regarding hierarchy, but also what means with hierarchy.
One example, the construction <term>/.. can always be removed from the URI.
If this is not the case, you do not have hierarchy, which in turn means
that you have to use a different delimiter than the '/'.
This means that if you have

foo/bar
fratz/oof

then foo/bar and fratz/oof/../bar is the same thing. If that is the case,
then you can use the '/' as divider.

I.e. the way I see it, what you ask for IS in the new proposed I-D for
URI's, but it at the same time defines (in a good way) what it means by
being hierarichal. Things that are not hierarichal should not use '/'.

The question is because of that if

urn:ietf:rfc/822

and

urn:ietf:rfc/822/../821

is the same thing.

If it is not (or if the latter is undefined in the namespace) then '/' can
not be used as divider.

    Patrik

From: "Ryan Moats" <[email-masked]>
To: "R. P. Channing Rodgers, M.D." <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/)
Date: Thu, 25 Jun 1998 09:54:07 -0400
Importance: Normal
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

> > >>>>> "Ryan" == Ryan Moats <[email-masked]> writes:
> >     Ryan> The whole point of URNs is that the underlying resource has
> >     Ryan> permanance.  Internet-Drafts, by there definition, expire in 6
> >     Ryan> months and can be replaced at any time.  Therefore, they were
> >     Ryan> purposely excluded from the "ietf" definition.
> >
> >   Yes, but as an IETF person who mirrors the RFCs and the drafts, drafts
> > come out more often, so I spend more bandwidth fetching them.
>
> We should not confuse authority with permanence.  A document like an
> Internet Draft may have exceeded its 6-month lifetime, but that does
> not mean that it does not remain "on the record" in a broader sense.
> It should still be an available, retrievable, historical document.
>
> Cheerio, Rick Rodgers

This is an issue for the I-D repository folks at ietf.org.  If you are
volunteering,
I'm sure they will be very interested :-).

Ryan

From: "Phillip Hallam-Baker" <[email-masked]>
To: <[email-masked]>, "Michael Richardson" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/) 
Date: Thu, 25 Jun 1998 09:28:49 -0400
Importance: Normal
Sender: [email-masked]
Reply-To: "Phillip Hallam-Baker" <[email-masked]>

>    "2.3.2 The other reserved characters
> 
>       RFC 1630 [2] reserves the characters "/", "?", and "#" for 
> particular
>       purposes. The URN-WG has not yet debated the applicability and
>       precise semantics of those purposes as applied to URNs. Therefore,
>       these characters are RESERVED for future developments.  Namespace
>       developers SHOULD NOT use these characters in unencoded form, but
>       rather use the appropriate %-encoding for each character."
> 
> Therefore, I decided not to use "/".  Again, once there is working group
> consensus
> on the use of "/" then seeing if "/" is appropriate here makes sense.

The majority of the group was always of the opinion that the / character
denoted a hierarchical delineation of the name space. The Gopher people
insisted that because of a peculiarity of now defunct platform they did
not want the / character to apply to them. 

Since Gopher is now irrelevant I suggest that the URI RFC be rewritten
to state what should always have been the case. The name space is
hierarchical and employs the / character to denote hierarchy.

Using another character to represent hierarchy is definitely
unacceptable and unnecessary. The group never intended to prohibit the 
use of reserved characters, they merely wished to reserve them for
specific uses. Ergo if you have one f those uses use them.

		Phill

Date: Thu, 25 Jun 1998 09:17:36 -0400
From: [email-masked] (R. P. Channing Rodgers, M.D.)
To: [email-masked], [email-masked]
Subject: Re: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/)
Sender: [email-masked]
Reply-To: [email-masked] (R. P. Channing Rodgers, M.D.)

> >>>>> "Ryan" == Ryan Moats <[email-masked]> writes:
>     Ryan> The whole point of URNs is that the underlying resource has
>     Ryan> permanance.  Internet-Drafts, by there definition, expire in 6
>     Ryan> months and can be replaced at any time.  Therefore, they were
>     Ryan> purposely excluded from the "ietf" definition.
> 
>   Yes, but as an IETF person who mirrors the RFCs and the drafts, drafts
> come out more often, so I spend more bandwidth fetching them.

We should not confuse authority with permanence.  A document like an
Internet Draft may have exceeded its 6-month lifetime, but that does
not mean that it does not remain "on the record" in a broader sense.
It should still be an available, retrievable, historical document.

Cheerio, Rick Rodgers 

-----
R. P. C. Rodgers, M.D. * [email-masked] * (301)496-9305 (voice, fax)
   CSB, LHNCBC, National Library of Medicine, NIH
   8600 Rockville Pike, Bethesda MD 20894 USA
   http://www.nlm.nih.gov/, search personnel roster for "rodgers"

From: "Ryan Moats" <[email-masked]>
To: "Michael Richardson" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/) 
Date: Thu, 25 Jun 1998 08:10:26 -0400
Importance: Normal
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

> >>>>> "Ryan" == Ryan Moats <[email-masked]> writes:
>     Ryan> The whole point of URNs is that the underlying resource has
>     Ryan> permanance.  Internet-Drafts, by there definition, expire in 6
>     Ryan> months and can be replaced at any time.  Therefore, they were
>     Ryan> purposely excluded from the "ietf" definition.
>
>   Yes, but as an IETF person who mirrors the RFCs and the drafts, drafts
> come out more often, so I spend more bandwidth fetching them.

As another IETF person who mirrors the RFCs and the drafts (from behind a
modem
connection), the amount of extra time is not all that noticable.

>   With a URN, there is a better chance my web/ftp cache will know the
> nearest location for them.

While I don't have a strong stake in the exclusion/inclusion of IDs, there
was a discussion of this in the archives some time back and no complaints
were
raised.  Under the heading of "my bad", there was a statement to the effect
of why IDs were ignored in -02 that has fallen out.  I'll put such a
statement
back in and re-release as -06 (once I get back from my business trip).

Of course, if there is working group consensus that IDs should be added, I
will
do so.

>   I also wanted to ask why the spec says to use ":"
>   Why not have:
> 	urn:ietf:rfc/1809
> 	urn:ietf:fyi/7
>
>   And either:
> 	urn:ietf:internet-drafts/draft-ietf-urn-ietf-05.txt
>
>   or (what I hope to propose to the IETF draft editor)
> 	urn:ietf:drafts/ietf/urn/ietf-05.txt
>   with  urn:ietf:drafts/author/subject-foo-06.txt for non WG
> related things.

This one has to do with the wording of 2141. If you look at section 2.3.2
you find:

   "2.3.2 The other reserved characters

      RFC 1630 [2] reserves the characters "/", "?", and "#" for particular
      purposes. The URN-WG has not yet debated the applicability and
      precise semantics of those purposes as applied to URNs. Therefore,
      these characters are RESERVED for future developments.  Namespace
      developers SHOULD NOT use these characters in unencoded form, but
      rather use the appropriate %-encoding for each character."

Therefore, I decided not to use "/".  Again, once there is working group
consensus
on the use of "/" then seeing if "/" is appropriate here makes sense.

Ryan

From: "Larry Masinter" <[email-masked]>
To: <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/) 
Date: Thu, 25 Jun 1998 04:06:27 PDT
Importance: Normal
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

Or even:
  naptr://ietf/rfc/1809

as a URL scheme.

From: "Phillip Hallam-Baker" <[email-masked]>
To: "Michael Richardson" <[email-masked]>, <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/) 
Date: Thu, 25 Jun 1998 00:03:26 -0400
Importance: Normal
Sender: [email-masked]
Reply-To: "Phillip Hallam-Baker" <[email-masked]>

>     Ryan> The whole point of URNs is that the underlying resource has
>     Ryan> permanance.  Internet-Drafts, by there definition, expire in 6
>     Ryan> months and can be replaced at any time.  Therefore, they were
>     Ryan> purposely excluded from the "ietf" definition.
> 
>   Yes, but as an IETF person who mirrors the RFCs and the drafts, drafts
> come out more often, so I spend more bandwidth fetching them.
> 
>   With a URN, there is a better chance my web/ftp cache will know the
> nearest location for them.
> 
>   I also wanted to ask why the spec says to use ":"
>   Why not have:
> 	urn:ietf:rfc/1809
> 	urn:ietf:fyi/7

Michaels points demonstrate exactly what is wrong with the URN 
group approach. It attempts to creat voluntary permanence. 

If the URNs are permanent they cannot be an opt in system.
anyone can create permanent URLs today - they just decide on
a naming scheme and stick to it.

The whole point is that you need to be able to ensure that the
resource will be there DESPITE the fact that the person who
maintained it has moved or deleted it.

The colons are a pure conceit. They add nothing to the specification,
they only detract from it. The authors are fixated on them and will
not change them.

Hey guys, heard about this Web thing? It's grown quite a bit
since I first heard these stories back in 1992. I don't think
that the market is rejecting the alledged URN schems unreasonably.

Get rid of the colons and stop pretending that the location schemes 
are anything other than a better URL. The moment the syntax of
a sign is constrained in order to express meaning it becomes 
an index - just like a URL.

Michael is only saying what everyone else outside the group has
always said. The colons are entirely bogus, the requirements
document is a wish list rather than a realistic set of goals.

	Phill

From: "Phillip Hallam-Baker" <[email-masked]>
To: "Ryan Moats" <[email-masked]>, "Roman Czyborra" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/)
Date: Wed, 24 Jun 1998 23:26:40 -0400
Importance: Normal
Sender: [email-masked]
Reply-To: "Phillip Hallam-Baker" <[email-masked]>

> > > That's why URNs like urn:ietf:rfc:2068 are suggested by
> > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-ietf-05.txt
> > 
> > In your draft-ietf-urn-ietf-05.txt I miss an example like my
> > "urn:ietf:rfc:2068" (can I say <URL:uri:...>?)  and a scheme for
> > drafts like urn:ietf:draft:draft-ietf-urn-ietf-05.txt because drafts
> > get mirrored, too. 
> 
> The whole point of URNs is that the underlying resource has permanance.
> Internet-Drafts, by there definition, expire in 6 months and can be 
> replaced at any time.  Therefore, they were purposely excluded from
> the "ietf" definition.

I never heard any rational explanation for the colons. Apart from
making the resulting identifiers impossible to read out on the radio 
without appearing to have a fixation I can't see any reason to change 
from the slashes used in URLs.

The irrational explanation for the colons is to deliberately
break relative URI calculations. The gopher people had the same
wierd idea - check your IIS 4.0 for gopher support. Provided
the name of an object is known relative names are not ambiguous.
The 'requirement' is bogus.

Folk on this list would do well to decide what they think a NAME
is. I contend that it is a purely random collection of characters
whose meaning arises from usage (as does Wittgenstein). The
'requirement' for a location scheme is entirely bogus.

Get Microsoft to modify Frontpage so that it automatically throws
a GUID into every HTML document it produces and you have a URN.
Alta-Vista can work out the resulting mess. Even better, give
each document two GUIDs, one that uniquely identifies the
document version and the other identifies the series.

Such a scheme is a rough and ready hack that does not solve
all the alledged requirements in the RFC. It is a high
leverage idea however, it gives high return at low cost. In
short it is like a URL, the principle advantage of which
was that it ditched a lot of hypertext superstitions about
the essential need for bidirectional links.

All the schemes based on the concept of a directory system of any
kind that requires action on the part of the author are doomed.
John's PDIs work for the simple reasdon that they incorporate
a date. The ownership of a DNs name on a given date is unique,
unambiguous and it is therefore a viable naming scheme if you
do not like random character strings such as GUIDs or MD5 output.

If this group wants to actually achieve something it should 
decide whether its objective is simply to provide a better URL
with one extra level of indirection or a genuine URN. Since
the proposals all seem to be for a URL with extra indirection
I suggest that the name be changed.

An extra level of indirection may be the comp sci equivalent
of an all purpose hammer but I don't see the need to change
terminology. Mail and news message IDs are genuine names. Index
terms of any sort are precisely that, index terms.

	Phill

To: [email-masked]
Subject: Re: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/) 
Date: Wed, 24 Jun 1998 18:48:01 -0300
From: Michael Richardson <[email-masked]>
Sender: [email-masked]
Reply-To: Michael Richardson <[email-masked]>

>>>>> "Ryan" == Ryan Moats <[email-masked]> writes:
    Ryan> The whole point of URNs is that the underlying resource has
    Ryan> permanance.  Internet-Drafts, by there definition, expire in 6
    Ryan> months and can be replaced at any time.  Therefore, they were
    Ryan> purposely excluded from the "ietf" definition.

  Yes, but as an IETF person who mirrors the RFCs and the drafts, drafts
come out more often, so I spend more bandwidth fetching them.

  With a URN, there is a better chance my web/ftp cache will know the
nearest location for them.

  I also wanted to ask why the spec says to use ":"
  Why not have:
	urn:ietf:rfc/1809
	urn:ietf:fyi/7

  And either:
	urn:ietf:internet-drafts/draft-ietf-urn-ietf-05.txt

  or (what I hope to propose to the IETF draft editor)
	urn:ietf:drafts/ietf/urn/ietf-05.txt
  with  urn:ietf:drafts/author/subject-foo-06.txt for non WG related things.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[email-masked]</A>. PGP key available.
 Corporate: <A HREF="mailto:[email-masked]">[email-masked]</A>. 

From: "Ryan Moats" <[email-masked]>
To: "Roman Czyborra" <[email-masked]>
Cc: <[email-masked]>
Subject: [URN] The "ietf" namespace and internet-drafts (was Re: ftp://ds.internic.net/rfc/)
Date: Wed, 24 Jun 1998 18:08:05 -0400
Importance: Normal
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

> > That's why URNs like urn:ietf:rfc:2068 are suggested by
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-ietf-05.txt
> 
> In your draft-ietf-urn-ietf-05.txt I miss an example like my
> "urn:ietf:rfc:2068" (can I say <URL:uri:...>?)  and a scheme for
> drafts like urn:ietf:draft:draft-ietf-urn-ietf-05.txt because drafts
> get mirrored, too. 

The whole point of URNs is that the underlying resource has permanance.
Internet-Drafts, by there definition, expire in 6 months and can be 
replaced at any time.  Therefore, they were purposely excluded from
the "ietf" definition.

From: Michael Mealling <[email-masked]>
Subject: [URN] Re: Status of RFC2169, THTTP
To: [email-masked] (John C. Mallery)
Date: Wed, 17 Jun 1998 21:23:34 -0400 (EDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

John C. Mallery said this:
> Is this being updated to conform with the URI update to the resolution
> services draft?
> 
> Seems desirable to have a resolution spec that someone can implement
> without too much interpolation.

Good question. Unlike NAPTR I think there's probably a good case
for not letting THTTP go to far forward. Its an interesting hack
but the implementations I've been doing show how it can almost be
dangerous if it gets implemented to much.

It might be updated to reflect the URI vs URL stuff in the services
document. But that would be if someone actually really started using
it.

Suggestions?

-MM

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Sr. Research Engineer   | Herndon, VA 22070	       | ICQ#:        14198821
Network Solutions	| <URL:http://www.netsol.com>  |  [email-masked]

Date: Thu, 18 Jun 1998 00:15:47 -0400
To: [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: [URN] URI Resolution Services Draft
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

Can we add a URI to RDS service to the resolution draft?

This would allow a resolver to support RDS.

The task is to return a list of resolver domain names with information
about:

	resolution protocols supported

	Resolution hints (e.g. ports for http connection)

	Preference numbers

	Authoritativeness

	(What else?)

Errors: Unknown URI
	
	No resolver known

	Malformed URI

	Access denied

	Service not supported

(BTW, all the resolution service errors should include the possibility
that the particular service is not supported. A positive statement
is helpful for both implementors and clients.)

This information needs to be packaged somehow.  Choices
are a new mime type like text/uri-list or a new xml/rdf namespace or
an URN namespace for resolvers with their characterization, which
would allow text/uri-list to be reused here.

I think a text mime type would be useful. RDF will follow
for all these pretty soon.

Date: Thu, 18 Jun 1998 00:12:38 -0400
To: [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: [URN] URI Resolution Services
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

Can we add some URI to RDS services to the resolution draft?

I2RDS ?

This would allow a resolver to support RDS.

The task is to return a list of resolver domain names with information
about:

	resolution protocols supported

	Resolution hints (e.g. ports for http connection)

	Preference numbers

	Authoritativeness

	(What else?)

Errors: Unknown URI
	
	No resolver known

	Malformed URI

	Access denied

	Service not supported

(BTW, all the resolution service errors should include the possibility
that the particular service is not supported. A positive statement
is helpful for both implementors and clients.)

This information needs to be packaged somehow.  Choices
are a new mime type like text/uri-list or a new xml/rdf namespace or
an URN namespace for resolvers with their characterization, which
would allow text/uri-list to be reused here.

I think a text mime type would be useful. RDF will follow
for all these pretty soon.

Date: Wed, 17 Jun 1998 22:36:26 -0400
To: [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: [URN] Re: Status of RFC2169, THTTP
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

We're using it at the EOP indefinitely and we'll support
something like WIRE when the clients understand it.

THTTP is needed to allow legacy clients to deal with URNS.

As far as we're concered, the only relevant methods are
I2R, I2C. Others may want the I2L methods.

On my view, THTTP should be brought forward to reflect
the new URI resolution service names and specs, AS new resolution
protocols are developed and deployed in clients.

Certainly, the new protocols should be wired into new clients
and NOT THTTP.

(AS you might guess, I'm updating my URN, err I mean, URI resolution 
code. I'm thinking that non-urn URI's (ie URLs) are going to
have different implementational issues from URNs with their
namespaces. How do we find a resolver? What resolvers 
are authoritative? How do we know? How do we tell? .....)

Date: Wed, 17 Jun 1998 21:05:28 -0400
To: Ron Daniel <[email-masked]>, Michael Mealling <[email-masked]>
From: "John C. Mallery" <[email-masked]>
Subject: [URN] Status of RFC2169, THTTP
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

Is this being updated to conform with the URI update to the resolution
services draft?

Seems desirable to have a resolution spec that someone can implement
without too much interpolation.

From: Ron Daniel <[email-masked]>
To: [email-masked]
Subject: RE: [URN] NAPTR status
Date: Fri, 12 Jun 1998 08:22:07 -0700
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

[This message seems to have gotten lost - or at least I have
not seen a copy on the URN list after sending it a few days
ago. Apologies if others have seen it.]

John Mallery identifies two main concerns with scaling in NAPTR,
taking DNS caching into account...  [I'm rearranging his message
a little in the quoted sections]

> 1. However, as the rate of delegation increases, NAPTR records for the
> namespace 
> the must be updated with increasing frequency. This violates the
> assumption about
> long lifetimes.
[...]
Consider the example of the PDI namespace. Top-level document series are
delegated
to anybody who wants one.  Supposing it becomes popular and some
millions
of organizations obtain top-level document series (basically the same
number as
have toplevel domain names). The NAPTR entry that performs delegation
will be
changing all the time, required an update time of say every day or every
6 hours.

[Ron Daniel]  The idea of having large numbers of NAPTR
records associated with a single domain name (e.g. pdi.urn.net)
will not work well due to the design and implementation of DNS.
Its reasonable to have 10 NAPTR records, maybe even 20, associated
with one domain name. Millions will not fly. This indicates a
scaling limit on NAPTR. Coupled with the assumption that no more
than 3-5 probes into DNS are reasonable before the terminal NAPTR
record is found, this indicates that a single namespace (such as
PDI) has an upper limit on the number of delegations it can handle
using NAPTR. The limit is not hard, but 10^3 is reasonable and
20^5 would be pushing it if one accepts my guesstimates given above.
(Two notes: the number of probes can be reduced through the use of
DNS' "additional information", but that information takes up space
in the response so it is not independent of the number of records
returned. Also, the 10^3 and 20^5 figures are only achieved if there
is some pseudo-hierarchical structure in the namespace. This is not
as strong a limitiation as it might appear. The first set of regexps
might simply look at the first character of the PDI and divide it
into 26 bins (A, B, ...).

This does not mean that a namespace can't have more than 1000 or
3,200,000 sub-namespaces. It means that truely large namespace
delegation jobs need to be handled outside of NAPTR. This is easy.
There could be a single, terminal, NAPTR record for a namespace saying
"speak this other protocol and talk to this host and they can
help you out". [In more recent messages, both John and Michael have
been looking at adding such capabilities to resolution protocols
like WIRE].
>  
> 
> 2. As the number of delegated partions in a namespace increases, the
> reg-x becomes
> increasingly complex.  this will make delegation slower and more
> brittle as
> the opportunity for error increases.
[...] 
> Next, consider the complexity of the reg-x that handles this
> delegation and
> toss in the chronological delegation as well.  Note that chronological
> delegation
> must be handled by enumeration because reg-x doesn't do numeric
> comparisons.
> 
[Ron Daniel]  There seem to be two objections here - that
regexps can't handle some things (like numeric comparisons)
and that people might make errors. People *will* make errors.
They will make them in NAPTR regexps and lots of other places.
When they make them in top-level NAPTR records, the resolution
in that namespace is going to get screwed up. The same criticisms
of "it won't work if its misconfigured" can be applied to any other
system. Some systems have ways of
reducing the impact. For example, changed records should have a
short time-to-live until they have been tested and found good,
at which time the TTL is lengthened. We can recommend good
practices, and DNS provides the facilities for those good
practices, but NAPTR has no QOS quarantees. Personally, since
nothing much else in the Internet has QOS, this does not seem
like a large failing in NAPTR.

The second objection was that regexps couldn't do some things.
Regexps were chosen for NAPTR because:
  1) They existed, saving us a long period of arguing about a
     rewrite language.
  2) There are a lot of people who know how to write regexps
  3) They do a lot of useful things
  4) They are very compact, which is important since the size of
     DNS resource records is a consideration.
I am the first to admit that regexps are ugly, error-prone, hard-
to-read, and can't do a lot of things. I would be very happy to see
them augmented by a better method of writing the rewrite rules.
Because NAPTR has the flag field, it is possible to come up with
a different syntax for the rules and provide records using it without
breaking older clients (although they will, of course, not be able to
handle the newer form of rules). It is even possible for us to look
at deprecating regexps *once we have specified something better*.

> I can see how NAPTR can work for a while, certainly long enough to get
> us into
> trouble, but I don't understand what will happen when URNs and URI
> resolution
> become mainstream.
> 
[Ron Daniel]  Not surprisingly, I see things differently.
I see the flags field and the protocol field as giving us
a great deal of future flexability, so that NAPTR can work
for quite awhile, and we can gracefully transition to other
schemes as they arise.

Can you share with us your thoughts on how we cope with these scaling
issues?

[Ron Daniel]  Let's look at the case of PDI becoming very
popular. Assume it has millions of registered sub-spaces.
How long will it take for that to happen? During the time
it takes, I assume that new URN resolution protocols will
come about, so that NAPTR does not need to do so much
of the delegation to resolvers. (NAPTR is a RDS, not the
resolver itself. As resolvers do more, the rules for
getting to the rigth one become simpler). The protocol field
lets NAPTR accomodate the development of new resolution protocols.
In the meantime, there is enough flexability in NAPTR's abilities
that it can handle delegation among thousands, even hundreds
of thousands, of sub-namespaces. This will require some
creative use of regexps, but that's what general machinery
is for.

I do not believe NAPTR is perfect. But I am an engineer, and
I think it makes pretty good tradeoffs and makes good use of
existing technology to get something that is implementable now,
can grow for a long time, and can hand off to other things when
they come along. (Of course, I would say that, wouldn't I? :-)
But seriously, I am not aware of a better RDS at this time.

later,
Ron Daniel Jr.
DATAFUSION, Inc.
139 Townsend Street, Ste. 100
San Francisco, CA  94107
415.222.0100 fax 415.222.0150 
[email-masked]
http://www.datafusion.net

From: Ron Daniel <[email-masked]>
To: [email-masked]
Subject: RE: [URN] NAPTR status
Date: Fri, 12 Jun 1998 08:22:07 -0700
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

[This message seems to have gotten lost - or at least I have
not seen a copy on the URN list after sending it a few days
ago. Apologies if others have seen it.]

John Mallery identifies two main concerns with scaling in NAPTR,
taking DNS caching into account...  [I'm rearranging his message
a little in the quoted sections]

> 1. However, as the rate of delegation increases, NAPTR records for the
> namespace 
> the must be updated with increasing frequency. This violates the
> assumption about
> long lifetimes.
[...]
Consider the example of the PDI namespace. Top-level document series are
delegated
to anybody who wants one.  Supposing it becomes popular and some
millions
of organizations obtain top-level document series (basically the same
number as
have toplevel domain names). The NAPTR entry that performs delegation
will be
changing all the time, required an update time of say every day or every
6 hours.

[Ron Daniel]  The idea of having large numbers of NAPTR
records associated with a single domain name (e.g. pdi.urn.net)
will not work well due to the design and implementation of DNS.
Its reasonable to have 10 NAPTR records, maybe even 20, associated
with one domain name. Millions will not fly. This indicates a
scaling limit on NAPTR. Coupled with the assumption that no more
than 3-5 probes into DNS are reasonable before the terminal NAPTR
record is found, this indicates that a single namespace (such as
PDI) has an upper limit on the number of delegations it can handle
using NAPTR. The limit is not hard, but 10^3 is reasonable and
20^5 would be pushing it if one accepts my guesstimates given above.
(Two notes: the number of probes can be reduced through the use of
DNS' "additional information", but that information takes up space
in the response so it is not independent of the number of records
returned. Also, the 10^3 and 20^5 figures are only achieved if there
is some pseudo-hierarchical structure in the namespace. This is not
as strong a limitiation as it might appear.. The first set of regexps
might simply look at the first character of the PDI and divide it
into 26 bins (A, B, ...).

This does not mean that a namespace can't have more than 1000 or
3,200,000 sub-namespaces. It means that truely large namespace
delegation jobs need to be handled outside of NAPTR. This is easy.
There could be a single, terminal, NAPTR record for a namespace saying
"speak this other protocol and talk to this host and they can
help you out". [In more recent messages, both John and Michael have
been looking at adding such capabilities to resolution protocols
like WIRE].
>  
> 
> 2. As the number of delegated partions in a namespace increases, the
> reg-x becomes
> increasingly complex.  this will make delegation slower and more
> brittle as
> the opportunity for error increases.
[...] 
> Next, consider the complexity of the reg-x that handles this
> delegation and
> toss in the chronological delegation as well.  Note that chronological
> delegation
> must be handled by enumeration because reg-x doesn't do numeric
> comparisons.
> 
[Ron Daniel]  There seem to be two objections here - that
regexps can't handle some things (like numeric comparisons)
and that people might make errors. People *will* make errors.
They will make them in NAPTR regexps and lots of other places.
When they make them in top-level NAPTR records, the resolution
in that namespace is going to get screwed up. The same criticisms
of "it won't work if its misconfigured" can be applied to any other
system. Some systems have ways of
reducing the impact. For example, changed records should have a
short time-to-live until they have been tested and found good,
at which time the TTL is lengthened. We can recommend good
practices, and DNS provides the facilities for those good
practices, but NAPTR has no QOS quarantees. Personally, since
nothing much else in the Internet has QOS, this does not seem
like a large failing in NAPTR.

The second objection was that regexps couldn't do some things.
Regexps were chosen for NAPTR because:
  1) They existed, saving us a long period of arguing about a
     rewrite language.
  2) There are a lot of people who know how to write regexps
  3) They do a lot of useful things
  4) They are very compact, which is important since the size of
     DNS resource records is a consideration.
I am the first to admit that regexps are ugly, error-prone, hard-
to-read, and can't do a lot of things. I would be very happy to see
them augmented by a better method of writing the rewrite rules.
Because NAPTR has the flag field, it is possible to come up with
a different syntax for the rules and provide records using it without
breaking older clients (although they will, of course, not be able to
handle the newer form of rules). It is even possible for us to look
at deprecating regexps *once we have specified something better*.

> I can see how NAPTR can work for a while, certainly long enough to get
> us into
> trouble, but I don't understand what will happen when URNs and URI
> resolution
> become mainstream.
> 
[Ron Daniel]  Not surprisingly, I see things differently.
I see the flags field and the protocol field as giving us
a great deal of future flexability, so that NAPTR can work
for quite awhile, and we can gracefully transition to other
schemes as they arise.

Can you share with us your thoughts on how we cope with these scaling
issues?

[Ron Daniel]  Let's look at the case of PDI becoming very
popular. Assume it has millions of registered sub-spaces.
How long will it take for that to happen? During the time
it takes, I assume that new URN resolution protocols will
come about, so that NAPTR does not need to do so much
of the delegation to resolvers. (NAPTR is a RDS, not the
resolver itself. As resolvers do more, the rules for
getting to the rigth one become simpler). The protocol field
lets NAPTR accomodate the development of new resolution protocols.
In the meantime, there is enough flexability in NAPTR's abilities
that it can handle delegation among thousands, even hundreds
of thousands, of sub-namespaces. This will require some
creative use of regexps, but that's what general machinery
is for.

I do not believe NAPTR is perfect. But I am an engineer, and
I think it makes pretty good tradeoffs and makes good use of
existing technology to get something that is implementable now,
can grow for a long time, and can hand off to other things when
they come along. (Of course, I would say that, wouldn't I? :-)
But seriously, I am not aware of a better RDS at this time.

later,
Ron Daniel Jr.
DATAFUSION, Inc.
139 Townsend Street, Ste. 100
San Francisco, CA  94107
415.222.0100 fax 415.222.0150 
[email-masked]
http://www.datafusion.net

Date: Fri, 12 Jun 1998 10:24:20 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: "John C. Mallery" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] NAPTR status
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Hmm.... interesting perspective.

On Thu, 11 Jun 1998, John C. Mallery wrote:
> possible for URN RDS to move forward. This creates a two-tier RDS scheme
> whereby only primary RDS (finding the primary for a namespace) is performed 
> using DNS and all secondary RDS (finding resolvers for partitions of the namespace)
> is performed within the resolution framework using the URI2resolver service. 

What I hear you proposing is a separation that cuts along similar lines
to a disinction that was understood in the original architecture, but was
purposefully blurred in the NAPTR proposal.  What was originally proposed
was a distinction between discovery of authority (for a namespace, or
one of a finite number of subcomponents of a namespace), and discovery
of (final) resolution services for a given authority.

While I understand this point, and appreciate the sentiment that drives it,
we have a problem in that we don't have a "URI2resolver" service at the 
standards level (i.e., NAPTR is the closest we've got, and you're arguing
against it for that purpose).

> Therefore, modifying resolution standards to compensate (i.e. providing
> an RDS service URI2resolver) solves the problem. Removing minefields (REGX)
> that undermine robustness and scaleability (especially when misused) and 
> are OBSOLESCED by these changes ENSURES scaleable aggregate performance.  

>From what I've heard in all the messages on this topic, it's not the case
that NAPTR _is_ bad, but there are fears that bad things _could_happen_
through its use.  Similarly, PostScript is not inherently bad, but you
can actually write PS commands that will do nasty things to your filesystem
(e.g., delete files).

So, the question is:  should we only put forward enough of NAPTR so that
we're sure people can't make a mess, or should we put forward NAPTR as it
stands, and be sure we know what the possible consequences are/can deal
with them?

On that note, what _are_ the real potential problems of badly-formed regexps? 
Are you arguing that it will take down DNS, or make some URNs unresolvable?
Can we get away with making a service-level distinction, saying that
URN.net will only contain 1 NAPTR record per namespace, no regexps, and
let individual namespaces use NAPTR (with regexps) as a URI2resolver
protocol (for now)?

Thoughts from all, please.

Leslie.

> 
> Defining a new spec (WIRE or similar) and modifing a few specs is a small amount 
> of work by comparison to implementation and testing requirements needed to move to 
> farther along the standards track.
> 
> This seems like an obvious way to leverage the existing investment.
> 

----------------------------------------------------------------------------

    "The nice thing about reality                 Leslie Daigle
       is that there are        
     so many versions to choose from."            Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

To: IETF-Announce:;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-net-procedures-00.txt
Date: Thu, 04 Jun 1998 10:16:23 -0400
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Uniform Resource Names Working Group of the IETF.

	Title		: Assignment Procedures for the URI Resolution 
                          using DNS (RFC2168)
	Author(s)	: M. Mealling
	Filename	: draft-ietf-urn-net-procedures-00.txt
	Pages		: 5
	Date		: 03-Jun-98
	
RFC2168 defines a DNS resource record and an algorithm for using DNS
as a registry for retrieving URN authority delegation rules (sometimes
called resolution hints). That document specifies that the first step
in that algorithm is to lookup the first NAPTR record for the namespace-
id in the 'urn.net' zone; i.e., the first step in resolving
'urn:ietf:rfc:2168' would be to lookup a NAPTR record for the domain
'ietf.urn.net'. This document describes the procedures for inserting
a new rule into this DNS-based URI resolution registry.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-urn-net-procedures-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-net-procedures-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-urn-net-procedures-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-urn-net-procedures-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-urn-net-procedures-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 11 Jun 1998 18:47:40 -0400
To: [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: Re: [URN] NAPTR status
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>
Point: If the current NAPTR RDS does not scale suitably to advance on

the standards track -- which is what some people believe -- then fixing
the scaling problems by forcing delegation into the resolution layer makes it
possible for URN RDS to move forward. This creates a two-tier RDS scheme
whereby only primary RDS (finding the primary for a namespace) is performed 
using DNS and all secondary RDS (finding resolvers for partitions of the namespace)
is performed within the resolution framework using the URI2resolver service. 

Therefore, modifying resolution standards to compensate (i.e. providing
an RDS service URI2resolver) solves the problem. Removing minefields (REGX)
that undermine robustness and scaleability (especially when misused) and 
are OBSOLESCED by these changes ENSURES scaleable aggregate performance.  

Defining a new spec (WIRE or similar) and modifing a few specs is a small amount 
of work by comparison to implementation and testing requirements needed to move to 
farther along the standards track.

This seems like an obvious way to leverage the existing investment.

Date: Wed, 10 Jun 1998 11:07:13 -0400
To: [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: Re: [URN] NAPTR status
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

>You shouldn't require this since the protocols that support this function
>can be specified in the rule for the delegation. I.e. THTTP can be
>changed this way but if it doesn't then you just specify that this rule
>doesn't support thttp. Thus, no client will pursue that tree with THTTP.
>For those poor clients that only do THTTP that resolution will be a dead
>end. I hope that a better, fast more resolution protocol will be specified.
>A few of us plan on working on this before Chicago....
>
>> What do you think? Does this address the issues?
>
>For a protocol that decided to support returning yet another delegation, sure.
>I just don't think we should make it required for all resolution 
>protocols...

I disagree. An RDS service MUST be required for every client and resolver.
Resovlver MAY implement it with an error code signalling that they don't
do RDS. Clients MUST implement the RDS service for any resolution protocol
which they implment.  This is the only way to assure interoperation and
to assure a scaleable system.

Without the requirement, people will overload NAPTR.  An additional
change need to prevent NAPTR overloading is removal/deprecation of
the REGX feature to its abuse.

I think clients must also implement a key selection of the URI resolution 
services to assure competent operation, esp. URI-to-Resource, URI-to-URL.

Date: Wed, 10 Jun 1998 02:06:33 -0400
To: Ron Daniel <[email-masked]>
From: "John C. Mallery" <[email-masked]>
Subject: RE: [URN] NAPTR status
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

Hmmm.  I suppose one way to scale NAPTR is to allow a single record for a
delegating namespace (like PDI) and have it go to a principal resolver 
(or load-balanced set) that just gives back the name of the right resolvers 
to consult.

If the URI resolution protocol were also able to answer resolver discovery questions
(e.g. URI->resolvers), then DNS would only be touched once to find the
root resolvers for a namespace. Thereafter, all the activity would be in
the resolution protocols.

An HTTP-based protocol, such as WIRE, could then leverage HTTP proxy caching and 
implement a look up table to answer RDS questions.

It seems this approach would make NAPTR scaleable and push the problem
where it should be handled. Thus, a change to the resolution spec and
some caveats in the NAPTR spec could be enough to move both forward.

Proposal:  add a URI to resolver service for THTTP and other resolution
protocols. Provide an appropriate media type to return (e.g.,  XML-based).
Provide error types to return to handle exceptional situations like
no-resolver-known, undelegated-URI, resolver-redirect, etc

What do you think? Does this address the issues?

From: Ron Daniel <[email-masked]>
To: "John C. Mallery" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: [URN] NAPTR status
Date: Tue, 9 Jun 1998 09:02:06 -0700 
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

John Mallery identifies two main concerns with scaling in NAPTR,
taking DNS caching into account...  [I'm rearranging his message
a little in the quoted sections]

> 1. However, as the rate of delegation increases, NAPTR records for the
> namespace 
> the must be updated with increasing frequency. This violates the
> assumption about
> long lifetimes.
[...]
Consider the example of the PDI namespace. Top-level document series are
delegated
to anybody who wants one.  Supposing it becomes popular and some
millions
of organizations obtain top-level document series (basically the same
number as
have toplevel domain names). The NAPTR entry that performs delegation
will be
changing all the time, required an update time of say every day or every
6 hours.

[Ron Daniel]  The idea of having large numbers of NAPTR
records associated with a single domain name (e.g. pdi.urn.net)
will not work well due to the design and implementation of DNS.
Its reasonable to have 10 NAPTR records, maybe even 20, associated
with one domain name. Millions will not fly. This indicates a
scaling limit on NAPTR. Coupled with the assumption that no more
than 3-5 probes into DNS are reasonable before the terminal NAPTR
record is found, this indicates that a single namespace (such as
PDI) has an upper limit on the number of delegations it can handle
using NAPTR. The limit is not hard, but 10^3 is reasonable and
20^5 would be pushing it if one accepts my guesstimates given above.
(Two notes: the number of probes can be reduced through the use of
DNS' "additional information", but that information takes up space
in the response so it is not independent of the number of records
returned. Also, the 10^3 and 20^5 figures are only achieved if there
is some pseudo-hierarchical structure in the namespace. This is not
as strong a limitiation as it might appear. The first set of regexps
might simply look at the first character of the PDI and divide it
into 26 bins (A, B, ...).

This does not mean that a namespace can't have more than 1000 or
3,200,000 sub-namespaces. It means that truely large namespace
delegation jobs need to be handled outside of NAPTR. This is easy.
There could be a single, terminal, NAPTR record for a namespace saying
"speak this other protocol and talk to this host and they can
help you out".
>  
> 
> 2. As the number of delegated partions in a namespace increases, the
> reg-x becomes
> increasingly complex.  this will make delegation slower and more
> brittle as
> the opportunity for error increases.
[...] 
> Next, consider the complexity of the reg-x that handles this
> delegation and
> toss in the chronological delegation as well.  Note that chronological
> delegation
> must be handled by enumeration because reg-x doesn't do numeric
> comparisons.
> 
[Ron Daniel]  There seem to be two objections here - that
regexps can't handle some things (like numeric comparisons)
and that people might make errors. People *will* make errors.
They will make them in NAPTR regexps and lots of other places.
When they make them in top-level NAPTR records, the resolution
in that namespace is going to get screwed up. I know of no
system that can be immune to this. Some systems have ways of
reducing the impact. For example, changed records should have a
short time-to-live until they have been tested and found good,
at which time the TTL is lengthened. We can recommend good
practices, and DNS provides the facilities for those good
practices, but NAPTR has no QOS quarantees. Personally, since
nothing much else in the Internet has QOS, this does not seem
like a large failing in NAPTR.

The second objection was that regexps couldn't do some things.
Regexps were chosen for NAPTR because:
  1) They existed, saving us a long period of arguing about a
     rewrite language.
  2) There are a lot of people who know how to write regexps
  3) They do a lot of useful things
  4) They are very compact, which is important since the size of
     DNS resource records is a consideration.
I am the first to admit that regexps are ugly, error-prone, hard-
to-read, and can't do a lot of things. I would be very happy to see
them augmented by a better method of writing the rewrite rules.
Because NAPTR has the flag field, it is possible to come up with
a different syntax for the rules and provide records using it without
breaking older clients (although they will, of course, not be able to
handle the newer form of rules).

> I can see how NAPTR can work for a while, certainly long enough to get
> us into
> trouble, but I don't understand what will happen when URNs and URI
> resolution
> become mainstream.
> 
[Ron Daniel]  Not surprisingly, I see things differently.
I see the flags field and the protocol field as giving us
a great deal of future flexability, so that NAPTR can work
for quite awhile, and we can gracefully transition to other
schemes as they arise.

Can you share with us your thoughts on how we cope with these scaling
issues?

[Ron Daniel]  Let's look at the case of PDI becoming very
popular. Assume it has millions of registered sub-spaces.
How long will it take for that to happen? During the time
it takes, I assume that new URN resolution protocols will
come about, so that NAPTR does not need to do so much
of the delegation to resolvers. (NAPTR is a RDS, not the
resolver itself. As resolvers do more, the rules for
getting to the rigth one become simpler). The protocol field
lets NAPTR accomodate the development of new resolution protocols.
In the meantime, there is enough flexability in NAPTR's abilities
that it can handle delegation among thousands, even hundreds
of thousands, of sub-namespaces. This will require some
creative use of regexps, but that's what general machinery
is for.

I do not believe NAPTR is perfect. But I am an engineer, and
I think it makes pretty good tradeoffs and makes good use of
existing technology to get something that is implementable now,
can grow for a long time, and can hand off to other things when
they come along. (Of course, I would say that, wouldn't I? :-)
But seriously, I am not aware of a better RDS at this time.

later,
Ron Daniel Jr.
DATAFUSION, Inc.
139 Townsend Street, Ste. 100
San Francisco, CA  94107
415.222.0100 fax 415.222.0150 
[email-masked]
http://www.datafusion.net

Date: Mon, 08 Jun 1998 10:06:02 +0200
To: "John C. Mallery" <[email-masked]>, [email-masked]
From: Harald Tveit Alvestrand <[email-masked]>
Subject: Re: [URN] NAPTR status
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Harald Tveit Alvestrand <[email-masked]>

At 22:17 01.06.98 -0400, John C. Mallery wrote:
>>> One of the key issues is that the number of resources will always
>>> be a couple of orders of magnitude larger than the number of servers.
>>> Thus, we can hardly expect DNS to voluntarily address scaling problems
>>> for a larger problem which they do not own.

Don't assume that someone else owns the DNS.
It's ours, where "we" = "The Internet".
And as Michael pointed out, the number of resolvers isn't likely to be
much greater than the number of hosts.

>If every URL accessed by anyone on the planet when through URI resolution,
>including discovery, what would be the impact on DNS? Zero?  How can we
>tell for sure?

My guess: Larger than zero, smaller than the result of NSI's irresponsible
flattening of the .com domain.
We are never sure until we try, unfortunately :-(.

>We have the WIRE extension to HTTP coming along. This could leverage
>HTTP caching mechanisms, which are are pretty good (and certainly better
>than none).  BUT, we need to provide time to live for entries to really
>make caching help.

"Pretty good" means what?

HTTP caching usually is considered "successful" if the hitrate is
more than 30%; I don't know what the numbers for the DNS are.
(My preliminary looks at NAMED source and output stats gave me the
numbers RQ=68.891 and SFwdQ=14.833 for one of my servers, indicating a 
79% hitrate, but I might be looking at 100% wrong numbers)

                       Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

From: Michael Mealling <[email-masked]>
Subject: Re: [URN] NAPTR status
To: [email-masked] (John C. Mallery)
Date: Thu, 4 Jun 1998 13:13:11 -0400 (EDT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

John C. Mallery said this:
> At 9:16 PM -0400 98-05-30, Michael Mealling wrote:
> >John C. Mallery said this:
> >> I have been thinking a little about the tree structure used to
> >> delegate URN space in NAPTR. The problem is that we're always
> >> going to the root and descending the pointer structure to
> >> find the right resolver.
> >
> >Yep. But as designed the root records very long times to live.
> >Someone had better have a really good reason for changing a record
> >in the root once its there.
> >
> ....
> >NAPTR, as well as any RDS, is meant as the resolution step of last resort.
> >The firs step in the algorithm is to check locally for any known caches
> >or other hints.
> >
> >Also, since the root is cached for very long periods of time, the local
> >resolver will have that answer. I.e. in DNS, all of your requests go
> >to your local nameserver first, then the root if it doesn't have the
> >answer. In the case of NAPTR, once a root query is cached in your local
> >nameserver you shouldn't query the root until the nameserver is restarted
> >or changes.
> >
> 
> These points hold for a URN namespace where there is little or no delegation.
> 
> 1. However, as the rate of delegation increases, NAPTR records for the 
> namespace the must be updated with increasing frequency. This violates the 
> assumption about long lifetimes.

Hopefully not at the root, though. But yes, you are right. As URNs become
adopted and widespread NAPTR will begin to show its age. By then I hope that
several things will have happened: a) WIRE and friends will have matured
and be in the process of being adopted b) DNS will go back to just naming
hosts and mailboxes and a real directory service will provide the
registry database and c) caching and other client side services will understand
the rules (hints) at a more fundamental level and can cope with them coming
from different locations.

> 2. As the number of delegated partions in a namespace increases, the reg-x 
> becomes increasingly complex.  this will make delegation slower and more 
> brittle as the opportunity for error increases.

Yep. That's one reason why we have that protocol specific trap door. At
some point I suspect that delegations will happen where the rule is hidden
in a database and not sent down to the client.

> Consider the example of the PDI namespace. Top-level document series are 
> delegated to anybody who wants one.  Supposing it becomes popular and some 
> millions of organizations obtain top-level document series (basically the 
> same number as have toplevel domain names). The NAPTR entry that performs 
> delegation will be changing all the time, required an update time of say 
> every day or every 6 hours.

Sure. But that won't happen at the root. That will only happen at the 
point where that delegation needs to take place. But I suspect that
you aren't going to see that level of growth within the next 2 years
are you? If so then something is going on I'm not aware of. If people
seriously think that we will see the NAPTR-breaking demand within the
next 2 years then sure, I'll scrap NAPTR in a heartbeat. I just don't
think that'll happen.

> Next, consider the complexity of the reg-x that handles this delegation and
> toss in the chronological delegation as well.  Note that chronological 
> delegation must be handled by enumeration because reg-x doesn't do numeric 
> comparisons.

Yep. I've always stated that NAPTR is not enough. I'd personally really
like to hand around applets to express the rules. But there isn't 
anyway you can compress a Java applet into the size of a DNS packet.
NAPTR is the first Resolver Discovery System. I hope something will
come along soon to replace it. But until then we need to get it 
out the door and into software or there won't be any URN service to
fix.

> I can see how NAPTR can work for a while, certainly long enough to get us into
> trouble, but I don't understand what will happen when URNs and URI resolution
> become mainstream.

I have some ideas....
 
> Can you share with us your thoughts on how we cope with these scaling issues?

1) we need a directory service that is capable of an Internet wide naming
context. It needs to be scalable and not have packet limitations and 
data representation limitations (to a certain extent). Yes, schema 
representation and management will be a problem. It needs two versions.
One needs to be blindingly fast (DNS-like) for small hints. The other
needs to be robust for large and complex hints.

2) we need the clients to understand hints and resolution in general to a 
much better degree. Some of the discussions we've had with Lewis and Henryk
about WIRE and the changes it would make to APIs and HTTP are moving
in that direction.

3) URN(I) resolution will have opaque pockets where the rules are not
expressed to the client. This is because of large database lookups
where the delegation rule is either complex or proprietary (DUNS). 

4) Proxies and caches will understand URNs and what it means to name
documents so that caching will be useable across different communities.

Anyone want to start on these? ;-)

Right now I'm trying to spend most of my time getting people who
write browsers to include NAPTR in their code. I'm having a hell of
a time. Personally, I'm of the opinion that we can solve the problems
I've enumerated above once we actually have code in the market. Right
now URNs aren't anywhere near that. 

My Explorer code will probably be ready before Chicago (licensing issues). 
But it sucks. I'm not a win32 programmer. I'm challenging folx to help me 
get code into the market. I really need some help writing the Mozilla code. 
I really need a good win32 programmer who understand apartment and gui threads 
to help me thread this protocol handler.

(Sorry if I rambled on there...)

-MM

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Sr. Research Engineer   | Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]

Date: Thu, 4 Jun 1998 12:32:10 -0400
To: [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: Re: [URN] NAPTR status
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

At 9:16 PM -0400 98-05-30, Michael Mealling wrote:
>John C. Mallery said this:
>> I have been thinking a little about the tree structure used to
>> delegate URN space in NAPTR. The problem is that we're always
>> going to the root and descending the pointer structure to
>> find the right resolver.
>
>Yep. But as designed the root records very long times to live.
>Someone had better have a really good reason for changing a record
>in the root once its there.
>
....
>NAPTR, as well as any RDS, is meant as the resolution step of last resort.
>The firs step in the algorithm is to check locally for any known caches
>or other hints.
>
>Also, since the root is cached for very long periods of time, the local
>resolver will have that answer. I.e. in DNS, all of your requests go
>to your local nameserver first, then the root if it doesn't have the
>answer. In the case of NAPTR, once a root query is cached in your local
>nameserver you shouldn't query the root until the nameserver is restarted
>or changes.
>

These points hold for a URN namespace where there is little or no delegation.

1. However, as the rate of delegation increases, NAPTR records for the namespace 
the must be updated with increasing frequency. This violates the assumption about
long lifetimes.

2. As the number of delegated partions in a namespace increases, the reg-x becomes
increasingly complex.  this will make delegation slower and more brittle as
the opportunity for error increases.

Consider the example of the PDI namespace. Top-level document series are delegated
to anybody who wants one.  Supposing it becomes popular and some millions
of organizations obtain top-level document series (basically the same number as
have toplevel domain names). The NAPTR entry that performs delegation will be
changing all the time, required an update time of say every day or every 6 hours.

Next, consider the complexity of the reg-x that handles this delegation and
toss in the chronological delegation as well.  Note that chronological delegation
must be handled by enumeration because reg-x doesn't do numeric comparisons.

I can see how NAPTR can work for a while, certainly long enough to get us into
trouble, but I don't understand what will happen when URNs and URI resolution
become mainstream.

Can you share with us your thoughts on how we cope with these scaling issues?

John C. Mallery
Artificial Intelligence Laboratory, Massachusetts Institute of Technology
545 Technology Square, NE43-797, Cambridge, MA 02139-4301 USA
Email: [email-masked], Phone: 617-253-5966, Fax: 617-253-5060 
WWW: http://www.ai.mit.edu/people/jcma/jcma.html

From: Ron Daniel <[email-masked]>
To: "John C. Mallery" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: [URN] NAPTR status
Date: Tue, 9 Jun 1998 09:02:06 -0700 
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

John Mallery identifies two main concerns with scaling in NAPTR,
taking DNS caching into account...  [I'm rearranging his message
a little in the quoted sections]

> 1. However, as the rate of delegation increases, NAPTR records for the
> namespace 
> the must be updated with increasing frequency. This violates the
> assumption about
> long lifetimes.
[...]
Consider the example of the PDI namespace. Top-level document series are
delegated
to anybody who wants one.  Supposing it becomes popular and some
millions
of organizations obtain top-level document series (basically the same
number as
have toplevel domain names). The NAPTR entry that performs delegation
will be
changing all the time, required an update time of say every day or every
6 hours.

[Ron Daniel]  The idea of having large numbers of NAPTR
records associated with a single domain name (e.g. pdi.urn.net)
will not work well due to the design and implementation of DNS.
Its reasonable to have 10 NAPTR records, maybe even 20, associated
with one domain name. Millions will not fly. This indicates a
scaling limit on NAPTR. Coupled with the assumption that no more
than 3-5 probes into DNS are reasonable before the terminal NAPTR
record is found, this indicates that a single namespace (such as
PDI) has an upper limit on the number of delegations it can handle
using NAPTR. The limit is not hard, but 10^3 is reasonable and
20^5 would be pushing it if one accepts my guesstimates given above.
(Two notes: the number of probes can be reduced through the use of
DNS' "additional information", but that information takes up space
in the response so it is not independent of the number of records
returned. Also, the 10^3 and 20^5 figures are only achieved if there
is some pseudo-hierarchical structure in the namespace. This is not
as strong a limitiation as it might appear. The first set of regexps
might simply look at the first character of the PDI and divide it
into 26 bins (A, B, ...).

This does not mean that a namespace can't have more than 1000 or
3,200,000 sub-namespaces. It means that truely large namespace
delegation jobs need to be handled outside of NAPTR. This is easy.
There could be a single, terminal, NAPTR record for a namespace saying
"speak this other protocol and talk to this host and they can
help you out".
>  
> 
> 2. As the number of delegated partions in a namespace increases, the
> reg-x becomes
> increasingly complex.  this will make delegation slower and more
> brittle as
> the opportunity for error increases.
[...] 
> Next, consider the complexity of the reg-x that handles this
> delegation and
> toss in the chronological delegation as well.  Note that chronological
> delegation
> must be handled by enumeration because reg-x doesn't do numeric
> comparisons.
> 
[Ron Daniel]  There seem to be two objections here - that
regexps can't handle some things (like numeric comparisons)
and that people might make errors. People *will* make errors.
They will make them in NAPTR regexps and lots of other places.
When they make them in top-level NAPTR records, the resolution
in that namespace is going to get screwed up. I know of no
system that can be immune to this. Some systems have ways of
reducing the impact. For example, changed records should have a
short time-to-live until they have been tested and found good,
at which time the TTL is lengthened. We can recommend good
practices, and DNS provides the facilities for those good
practices, but NAPTR has no QOS quarantees. Personally, since
nothing much else in the Internet has QOS, this does not seem
like a large failing in NAPTR.

The second objection was that regexps couldn't do some things.
Regexps were chosen for NAPTR because:
  1) They existed, saving us a long period of arguing about a
     rewrite language.
  2) There are a lot of people who know how to write regexps
  3) They do a lot of useful things
  4) They are very compact, which is important since the size of
     DNS resource records is a consideration.
I am the first to admit that regexps are ugly, error-prone, hard-
to-read, and can't do a lot of things. I would be very happy to see
them augmented by a better method of writing the rewrite rules.
Because NAPTR has the flag field, it is possible to come up with
a different syntax for the rules and provide records using it without
breaking older clients (although they will, of course, not be able to
handle the newer form of rules).

> I can see how NAPTR can work for a while, certainly long enough to get
> us into
> trouble, but I don't understand what will happen when URNs and URI
> resolution
> become mainstream.
> 
[Ron Daniel]  Not surprisingly, I see things differently.
I see the flags field and the protocol field as giving us
a great deal of future flexability, so that NAPTR can work
for quite awhile, and we can gracefully transition to other
schemes as they arise.

Can you share with us your thoughts on how we cope with these scaling
issues?

[Ron Daniel]  Let's look at the case of PDI becoming very
popular. Assume it has millions of registered sub-spaces.
How long will it take for that to happen? During the time
it takes, I assume that new URN resolution protocols will
come about, so that NAPTR does not need to do so much
of the delegation to resolvers. (NAPTR is a RDS, not the
resolver itself. As resolvers do more, the rules for
getting to the rigth one become simpler). The protocol field
lets NAPTR accomodate the development of new resolution protocols.
In the meantime, there is enough flexability in NAPTR's abilities
that it can handle delegation among thousands, even hundreds
of thousands, of sub-namespaces. This will require some
creative use of regexps, but that's what general machinery
is for.

I do not believe NAPTR is perfect. But I am an engineer, and
I think it makes pretty good tradeoffs and makes good use of
existing technology to get something that is implementable now,
can grow for a long time, and can hand off to other things when
they come along. (Of course, I would say that, wouldn't I? :-)
But seriously, I am not aware of a better RDS at this time.

later,
Ron Daniel Jr.
DATAFUSION, Inc.
139 Townsend Street, Ste. 100
San Francisco, CA  94107
415.222.0100 fax 415.222.0150 
[email-masked]
http://www.datafusion.net

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-net-procedures-00.txt
Date: Thu, 04 Jun 1998 10:16:23 -0400
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Uniform Resource Names Working Group of the IETF.

	Title		: Assignment Procedures for the URI Resolution 
                          using DNS (RFC2168)
	Author(s)	: M. Mealling
	Filename	: draft-ietf-urn-net-procedures-00.txt
	Pages		: 5
	Date		: 03-Jun-98
	
RFC2168 defines a DNS resource record and an algorithm for using DNS
as a registry for retrieving URN authority delegation rules (sometimes
called resolution hints). That document specifies that the first step
in that algorithm is to lookup the first NAPTR record for the namespace-
id in the 'urn.net' zone; i.e., the first step in resolving
'urn:ietf:rfc:2168' would be to lookup a NAPTR record for the domain
'ietf.urn.net'. This document describes the procedures for inserting
a new rule into this DNS-based URI resolution registry.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-urn-net-procedures-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-net-procedures-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-urn-net-procedures-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-urn-net-procedures-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-urn-net-procedures-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 1 Jun 1998 22:17:17 -0400
To: [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: Re: [URN] NAPTR status
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

At 9:16 PM -0400 98-05-30, Michael Mealling wrote:
>John C. Mallery said this:

>
>> An even better approach would be to perform all the discovery within
>> URN resolver space.  This must wait until we have considerably wider
>> deployment of resolvers.
>
>Can you explain what you mean by "within URN resolver space" a bit
>more?

If we had good resolution systems with interesing caching, security etc,
we could move natpr or equivalent into them. This would eliminate any
DNS impact and might also be more efficient, if done well.
>
>> One of the key issues is that the number of resources will always
>> be a couple of orders of magnitude larger than the number of servers.
>> Thus, we can hardly expect DNS to voluntarily address scaling problems
>> for a larger problem which they do not own.
>
>DNS records do not point at resources, they point to resolvers. Once you
>find an answer it is valid until a time to live expires. I.e. in http,
>once you get an A record for the host in the URL you don't keep hitting
>DNS over and over again. In NAPTR (as in any RDS) once you resolve
>a URN you can send a new URN back through the resolver process that
>will hopefully use the hints it cached from the last resolution step.

So, scalability depends on the time to live of the NAPTR record.

If every URL accessed by anyone on the planet when through URI resolution,
including discovery, what would be the impact on DNS? Zero?  How can we
tell for sure?

This is presumably the key question.
>
>> Another key issue is cache management for resolver discovery information.
>> The present story is that we hope DNS is doing the right thing for us.
>
>DNS is only half the story. But from my tests it's half works and works
>well. The other half is cache managment in browsers and libraries.
>My hacking on win32 has shown that Microsoft's cache management needs
>some work in order to really do URN caching correctly. I'm just now
>getting into the guts of Netscape's cache system.

We have the WIRE extension to HTTP coming along. This could leverage
HTTP caching mechanisms, which are are pretty good (and certainly better
than none).  BUT, we need to provide time to live for entries to really
make caching help.

From: Ron Daniel <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: [URN] NAPTR status
Date: Mon, 1 Jun 1998 04:49:19 -0700 
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Michael Mealling says:
> John C. Mallery said this:
> > I have been thinking a little about the tree structure used to
> > delegate URN space in NAPTR. The problem is that we're always
> > going to the root and descending the pointer structure to
> > find the right resolver.
[...]
> > A better approach would have us climbing the tree from some
> > known starting point, like the resolver at my site, and reaching
> > the root only when no resolvers on the way up the tree know the
> resolver
> > for the URN scheme.
> 
> NAPTR, as well as any RDS, is meant as the resolution step of last
> resort.
> The firs step in the algorithm is to check locally for any known
> caches
> or other hints.
> 
Michael makes the point I would make - that resolvers should
check locally. for example, back at LANL our resolver code
was set to talk with the LANL library system if the namespace
was SICI, because we have info on a bunch of e-journal articles
identified that way.

Michael also makes good points on the nature of caching in DNS.

Later,
Ron