Date: Fri, 11 Feb 94 20:58:00 -0500
Message-Id: <9402120158.AA15170@zippy.lcs.mit.edu>
From: Karen R. Sollins <sollins@lcs.mit.edu>
To: uri@bunyip.com
Subject: urn functional spec
I am batching my responses to the various messages that people have
sent in response to the draft urn functional spec. I want to thank
Jill Foster, Dirk Herr-Hoyman, Tim Berners-Lee, Steve Putz, Pierre
Desjardins, Mitra, Rob Raisch, and Dave Brennan for their comments.
I'll try to respond to all of them (in no particular order). But
first I want to say that thanks to Steve Putz there is now an html
version of the message I sent out that included the draft of the
document. It is in ftp://ana.lcs.mit.edu/pub/uri/urn-func-spec.html.
I do not have automated tools to generate html and don't really want
to be maintaining two versions of the document for html and not, so
this will only happen with future versions with some help from
others. Thanks, Steve.
1) Dirk Herr-Hoyman said
Maybe I'm being picky, but rather than "globally unique", don't you mean
"Internet unique". I'm thinking that you need to say a) this is for
computer networks and b) is an Internet standard.
Personally, I'd prefer to say that these names are globally unique.
Your point b) highlights the reasoning for this. This document (the
functional spec) is not and will not be an Internet Standard; it will
only be at most an informational RFC. There will be one or more
standards that are designed to meet the spec. Therefore, I'd like the
names to be globally unique, and in this document we should not say
that it is a standard. But, you are right that we should mention that
this is for computer networks. Thanks for bringing this all up - I
believe there has been a certain amount of confusion about the points
you've made.
2) Tim B-L: Scalability:
a) You asked about the scalability of names and whether or not that
implied hierarchical naming and whether or not we might be avoiding
that for some reason. Scalability is an issue within a namespace by
means of the naming authority expanding the namespace. If a naming
authority dispenses names that it believes are an ordered set of
components, then the question is whether it is capable of generating
new names not only be prepending or appending components on the ends
of the ordered set, or whether it can add components in the middle. I
personally am reluctant to talk about hierarchies because to me that
smacks of delegation of authority and we haven't talked about that at
all, and I don't believe we should in this document. Some naming
authorities may choose to delegate name generation authority and
others may not. That can and should remain distinct from whether or
not a namespace is scalable and, if so, where. I must say that I have
real problems with this because I don't believe that that is something
we should be specifying in a functional spec, but this is in there
because I believed that there was consensus on it. You have
definitely asked a difficult question in this area. Understanding the
distinctions between namespaces and delegation of authority is
complex. Pierre Desjardins got this just right in his note on the
subject.
By the way, the term "terminator" was used to identify those
components of an ordered set of name components that are at the ends
of the ends of the ordered set. (Presumably, outside the naming
authority the distinctions among components of a name that are being
made for the purposes of the discussion of scalability MAY be
invisible.)
b) Your second point addresses the problems of delegating parts of
namespaces to inferior naming authorities after part of a namespace
has been used or reclaiming by a parent naming authority from a child
naming authority. I agree with you that for specific naming
authorities this perhaps should be a requirement, but again I do not
think that it belongs in the functional spec. It is certainly a
useful thing for some naming authority designs to be able to do, but
there are certainly situations in which it may be impossible. For the
first part, it means that some child naming authorities will need to
be primed with the set of names within their domains that have already
been used and this may be extremely awkward for them to handle, at
best and may simply not be possible in all cases. I think we should be
keeping a list of points to make in the URN standard that we will also
need to write at some point, and that this should be a candidate for
that. I'll try to remember it when we get to the standards
discussion, but you should too.
Dave Brennan added a comment here about the fact that if one wants to
be able to move the boundaries in the name space among naming
authorities that the delimiters should be the same. Agreed, with the
provisos above about that not belonging in this document.
c) your nit - yes, we should state that the encoding is the same for
people and transmission, but Dave Brennan points out that there is a
minor consideration here about printable characters.
d) It was my thought that we ought to have a summary of the whole
structure that was kind of a preamble to each of the functional specs,
so that each document kind of stood on its own. We probably also want
a somewhat longer document that discusses in more detail the whole
structure - several of us had proposed to do that, but haven't made
much progress yet. For now, sure, refer to my document, but I'd
really like to get the larger document done also.
3) Pierre Desjardins:
a) YOur first set of comments addressed sameness. Again, this is a
difficult problem. It has been discussed by the group at great
length. Sameness is not and cannot be defined by us. This is
something (just as with equality) that is determined by the nature of
the information being evaluated and the particular evaluator (and
perhaps other factors as well). But is certainly not something that
can be defined by a standards group at the infrastructure level.
Consider several examples. What the book industry defines as sameness
or distinction is totally unrelated to what the database people might
say or the telephone company in providing telephone information or the
film industry or...The best thing that we as the information
infrastructure architects can do is to provide the hooks needed to
support whatever policies particular information providing and
managing communities wish to implement. So this functional spec says
that a naming authority determines sameness or difference by whatever
criteria it chooses and reflects those decisions by the imposition of
URNs. These URNs should then be comparable by a string equality test
that will reflect the decision previously made about the sameness of
information. So, you are right about the testing and have hit on a
point that is often difficult to tease apart about where our
responsibilities do and don't lie.
b) Scalability: Yes, you are right, as I mentioned above that the
business about terminators and scalability is about the resulting
namespace. You are also right that points #2 and #3 on naming
authorities and scalability are redundant.
c) Resolution: It is quite possible that there will be URNs that
cannot be resolved for all time. Two reasonable situations in which
this may occur if a URN is created as a place holder for a resource
that does not yet exist or in the case that a resource is either
temporarily or permanently inaccessible (deleted, killed, etc.) In
this latter case, the fact that there was/is a reference may be
important, even if the resource is not currently accessible.
You also asked about the business of naming authorities making some
sort of guarantee about a mapping to URLs. There was lots of
discussion in Houston (and I think on the net, but I'm not sure about
that) about this issue. Opinions ranged from those who believed that
naming authorities should also be resolution authorities to those who
believed that naming authorities are not in the business of having
anything to do with resolution, but rather have the task of assigning
names where appropriate. I must say that I fall at this latter end of
the spectrum, although I was trying to represent the consensus as I
understood it. This point was made in this way rather than as a real
requirement because the thinking on both sides was strong enough that
I was hoping for a compromise in order to get this document completed.
(You saw through my ruse :-)
4) Mitra:
a) You mention more requirements for retrieval and access and
graciously suggest that we probably should proceed with what we have
consensus on. I agree and as my comments above indicate, perhaps
disagree with you about further constraints or requirements on the
retrieval and access side - I'd need to be convinced. Also, remember,
that this is not a standard, but only an Information RFC that will be
used as a metric for one or more standards. In those standards we may
well want to address these additional issues of retrieval and access.
Again, if I forget to bring them up in those discussion, you should
certainly do that.
b) Then you continue with:
I'd like to see the line "although explicit semantics accessible to the
human are discouraged" removed.
and there is an ensuing discussion about semantics in URNs or URLs. I
disagree with you on this point. The reality is that you want names
to give to people that are neither URNs nor URLs but have semantics
about the nature of the information identified, that is meaningful to
humans. I don't think that belongs in either URNs or URLs, but rather
in some yet higher level, probably not long-lived, probably not
global, and perhaps not several other things, naming scheme. When you
hand someone one of these, it would be very nice (but probably not
mandatory because there are other ways it can be handled) to give the
person a URN, a URC and a URL or two. In other words, you give them
an identifying, retrieval, and accessing kit. There is lots of
interesting work to be done on that higher level user friendly naming,
but I don't believe that there will a universal, or even uniform
scheme for that, even within the limited scope of the Internet. I
really hope that we can keep this focussed on creating infrastructure,
and leave the mercurial and evolving world of applications to mutate
freely as necessary, only pinning down the minimum we need to make an
information infrastructure truly global and long-lived.
Dave Brennan also made a similar and interesting point on this
subject.
Needless to say, you have hit on a point that I have strong opinions
about.
5) Rob Raisch mostly was agreeing with the document - thank you, and
pointed out one correction that is needed in saying "zero or more
URLs" may be available from a mapping authority.
6) Dave Brennan sent several messages: In one he suggests that we
work carefully through the document, distinguishing requirements from
encouragements. Yes, although I thought we had done that. Will
definitely do that again.
You bring up a number of good points about places where the text just
needs some fine tuning. I'm not going to address each one here, but
rather will work on the text itself and just bring up those where
there are questions or points to discuss.
a) You brought up canonicalization. The simplest form of this problem
has to do with upper and lower case. Unless names are case sensitive
all names must be canonicalized. IMHO this is only worth a minor
mention, not a big deal, but does need to be mentioned.
b) You make a distinction here that I don't understand:
If scalability is mentioned, I think that it needs to be defined in
more concrete terms. I think that there's been a discussion of two
different scalabilities. Scalability of URNs in general, and scalability
of a class of URNs generated by a specific naming authority.
Could you explain this to me, please?
c) From your message:
> * Caching: Any scheme for which caching is appropriate should not
> impede caching of resources named by it.
Oh, no, not caching again! Just kidding...
Does this refer to caching in the URN->URL lookup, or object caching
based on a URN. In the latter case, it seems that caching is not a
problem when the "sameness" requirement is satisfied.
Help someone...I believe I took this literally from the discussion in
Houston, and didn't quite understand it. Will someone who espoused it
please stand up! I believe that it has to do with object caching and
thaat the problem is that some people believe that whether or not an
object can be freely cached (perhaps because it is immutable, so there
is no problem of inconsistency) should be reflected in a naming
scheme. Therefore I think this was included in order to allow for
that, although, if I'm correct, I disagree with it. So, if anyone has
any opinions here, please jump in.
d) You suggest that a naming authority id should be part of a URN.
That may be true for some specifications of all this and not for
others, so I'd leave that to the specifications and not include it in
the functional spec.
e) YOu asked about the URN-URL mapping also, but from a different
perspective. I don't believe that we can or should require that a
mapping from a URN to a URL be valid. Some mapping servers may be
completely reliable and authoritative, but others may not. In our
work at least, we postulate that there may be different sorts of these
mapping servers. One of the more interesting and hopefully commercial
viable sorts will be experts on something. They will do their best to
keep track of the names and locations of resources within their field
of expertise. The better the service they provide the more likely
they will be to succeed, but they may not provide any guarantees.
You also ask about "trashing" an object. You bring up several
interesting points here. Removing or changing the mapping to an empty
URL both imply that you not only know where all copies of the mapping
are, but also that you have access to change or remove them. With a
global name space, that may simply be impossible, and I don't think we
want to try to do it. In addition, at least in some contexts, lack of
information has a different meaning than having a value of NIL. I
don't know whether you were trying to make this point, but it might be
worth thinking about.
That's it for now. I really want to thank all of you again for your
thought provoking comments and needed suggestions for improvements.
If there's more, please let me know. I really want to get this out
soon and will try to do another round of corrections early next week,
between bouts of shovelling snow.
(For those of you not in the Northeast, we had 24 hrs of snow in the
middle of this week, are now in the middle of getting another foot or
so, and there's more expected on Sunday. For those of you who read
Susan Cooper's books, I feel like we are in one of those periods when
Evil is winning and the whole world is getting snowier and darker and
gloomier and the wind howls all the time. Peter and Alan probably
have us beaten with cold temperatures, but many of these nights it get
down into the single digits (fahrenheit) in the city and colder in the
suburbs, and this is with all that reputed moderating effect of the
ocean, which of course brings more moisture!)
Keep warm and I hope you don't have to shovel snow,
Karen