To: bajan@bunyip.com
In-Reply-To: bajan@bunyip.com's message of Sat, 2 Apr 1994 16:44:32 -0800 <94Apr2.164444pst.2735@golden.parc.xerox.com>
Subject: Re: Seattle minutes
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <94Apr4.154417pdt.2732@golden.parc.xerox.com>
Date: Mon, 4 Apr 1994 15:44:15 PDT
Some of the points here are minor, but I thought I would correct them
anyway.
> [Note: there is a debate, yet unresolved, as to the meaning of the 'C'
> in URCs. Karen Sollins, Michael Mealling and others have proposed
What I remember from the discussion at the meeting was the conclusion
that before we can decide what word we want to use, we have to decide
what requirements we're trying to satisfy. I see now that this is
reported later in the meeting minutes. I don't remember the chronology
of the meeting, but I think using 'meaning' here is confusing.
> III. Overview
>
> Karen Sollins made a short presentation.
>
> An overview document needs to be written, and that work should be
> authored under the auspices of the IIIR working group. Would like
> to have a first cut and then run it by this working group for
> review. Approved by the working group.
I think Karen was more specific than "An overview document". I believe
it was 'an overview of the Internet Information Access architecture',
although I might not have the exact name.
...
> Several people questioned the removal of the the issue of URN "sameness"
> from the current draft when it was in previous drafts. Sollins and
> Masinter responded:
As far as I can remember, no-one questioned the removal; rather, we
brought up the subject, in describing what happened since the previous
session.
> o This is an issue, but it is kind of fuzzy at this point. So it was
> dropped from the current Draft.
I think what I said was that when we looked at it, it turned out to be
separate issues, which either we handled in other points or are not
going to handle:
o When are two names 'the same name' but with spelling variations
We did cover this with 'simple comparision'
o When are two resources with different names the same
(when is 'the morning star' the same as 'the evening star')
o can you treat things with the same name as the same
(when is 'the morning star' the same as 'the morning star')
> o The naming authority gets to decide whether two items are the same
> same or not. Within their domain, they can assign the same URN to
> two different data formats with the same intellectual content, if
> they choose to do so [answering Crocker's question -- ed]
It is the last issue (can you treat things with the same name as the
same) that we have left up to 'the naming authority'.
> Sollins and Masinter replied that caching did get dropped because it
> was felt that it was outside the scope of URNs. However, they noted
> that they don't in any way feel that this list is exhaustive.
It got dropped because the issue wasn't resolvable at this time, not
because it was outside the scope.
> Other
> things can be added in the future when the need arises.
I'm not sure this is the case. Rather, I think we've identified a
common set of agreed-upon requirements. There may be additional
requirements, but whether they would appear in a revision to this
document is unclear. It's worth mentioning that security and the
ability to authenticate a resource might be additional requirements.
> At this point,
> the document is an informational document, not a standards track
> document. Also the ability for the URN to guarantee distinguishing
> between mutable and immutable documents they believe is beyond the
> scope of URN unless we have total control over all network space.
I don't think this last point (being beyond the scope) corresponds to
what was said. It *would* be possible to add this at a requirement. I
just don't think there was agreement about whether that requirement
should be added to this document.
> Chris Weider (clw@bunyip.com) noted that transcribability and limiting
> of character sets may discourage people from using them. Could a document
> in Japanese or Chinese have the URN embedded within the document, for
> example?
> Sollins and Masinter replied that they were describing
> transcribability not the ability to generate a URN.
I don't think I used the word 'describing'. I said that the
requirement was explicitly for transcribability, and that it be easy
to generate a URN from the title of a document or some other character
string wasn't a requirement. (It could be a requirement, but there was
no consensus for having it as such.)
> Plus, the URN
> doesn't have to be in the same character set as the document itself.
I think what I said was 'The URN doesn't have to be the same as the
TITLE or NAME of the document.', and gave the example of a document
whose name was in Kanji, but the URN was just a sequence of romaji
ASCII characters.
....
> John Curran noted that the Masinter/Sollins document specifies
> 'centrally registered' authorities and that you can't have both
> centrally registered and hierarchical. Mitra suggested that the Domain
> Name System (DNS) is in fact both, depending on which part of the
> authority is examined. Tim Berners-Lee (timbl@info.cern.ch) [ from the
> net --ed] proposed two components: hyperarticle (or opaque string) and
> an authority that imagines it is going to resolve the the opaque
> string into locations. He would prefer something that is hierarchical
> like DNS. He suggested that we make the boundary between the naming
> authority and the opaque string flexible so that the boundary becomes
> invisible.
I believe I noted that we would change the URN Functional Requirements
document to reflect that only the 'top level' naming authority was
centrally registered, not any sub-authorities.
....
> o Larry Masinter said that the URL is supposed to refer to the
> object, and be unambiguous. So, we can eave out the wildcard. If
> you use a wildcard, you aren't referring to a single object.
I don't think this was me; personally, I have no trouble with "news:*"
as a URL. Perhaps it was someone else.