Subject: Re: URI documents

From: Leslie Daigle <[email-masked]>
Date: Wed, 24 Dec 1997 15:13:40 -0500 (EST)

Roy,

You currently have your name on an Internet-Draft document that says
it is a URI syntax document.  To date, you have personally rejected
100% of the URN WG chairs' required edits to make a document that 
reflects the work that has been carried out in the IETF's URN Working Group.

Thus, your document is just that -- your document, and not a URI syntax
and semantics document, not an IETF document that accurately reflects
the syntax and semantics of all URIs as defined within the auspices
of the IETF.

Your arguments against the "# fragment" and relative URNs are, again, _your_
arguments -- you are countering the entire output of the URN WG with
your own interpretations and opinions. THese are all discussions that
have been held on the URN mailing list, and results are well-documented.
I'm not going to get back into attempting to justify them to you here; I
don't see why I have to, as you are not the jury and arbiter on URNs.

It is in fact this stone-wall editing that caused me concern over the
whole idea of trying to develop a URI syntax document.  However, I
have been attempting to work with the material that was put on the table.
It's pretty hard to cooperate with a stone wall.  The end result of this
obstinate lack of cooperation may either be inaccurate documentation or
the IETF/W3C may have to do without a URI syntax document for now.  
That seems pretty sad, and I will re-emphasisze it's not because of
_any_ lack of effort to participate on the URN WG's part.

By the way:

On Tue, 23 Dec 1997, Roy T. Fielding wrote:
> standard!  When I made detailed comments on various URN drafts, they
> were ignored --- not noted as being discussed and "resolved", just ignored.

I went through the entire URN WG mail archive, and found only 2 messages
from you (other than the cc'ed messages re. this document from October).
Neither message contained detailed discussion of documents, or points
that required responses.  So, I don't know where you sent these detailed 
comments that went unanswered, but as it was not the URN mailing list,
I can't speak to the issue. 

> Happy Holidays,

And to you, too.

Leslie.

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

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

---

From: Larry Masinter <[email-masked]>
Date: Wed, 24 Dec 1997 16:06:33 PST

Between:

a) Roy's last URL syntax draft what we did a last call on.
b) Roy's attempt to turn this into a URI document, at (I believe
   the original suggestion of the area directors) by doing
   a global substitute
c) Leslie's attempt to split (b) into a URI and a URL document
d) Larry's attempt to create a single document which discusses
    URIs and URLs.
   (ftp://ftp.parc.xerox.com/pub/masinter/uri-url-syntax.txt)

We have heard from a few folks, but not a lot. To recap:

Leslie says "There are only 2 possible paths forward here"
and indicated that only (a) and (c) are acceptable; the arguments
against (b) being posted to the list.

Roy finds (b) acceptable, would find (a) acceptable if some
editorial improvements (included in (b)) were retrofitted,
thinks (c) is totally unacceptable, and thinks the "fixes" in (d)
are are not needed and in several places actually overspecified
the requirements for URNs.  

Dave Durand posted that fragment identifiers SHOULD apply to
some URN in the context of XML, but didn't clearly indicate a
preference for any of the drafts.

Al Gilman posted about the issue of fragment identifiers and
URIs, but didn't indicate a preference for any of the drafts.

Are there any other opinions about the relative merits of the
individual drafts or proposed modifications to any of them?

Regards,

Larry

---

From: "John C. Mallery" <[email-masked]>
Date: Wed, 24 Dec 1997 22:44:26 -0500

I would like to support Leslie's point (c) that the URI document be separated from
the URL document and that it be consistent with the URN work.

URI's should not be encumbered with the URL lagacy. Separating the documents
is the best way to do this. 

URLs have some muddy distinctions: physical locations (e.g., ftp:) vs. logical 
locations (e.g. news:). It would be nice to clarify these differences by calling 
the logical locations URNs and grandfathering them in. Then, we would have a bit 
cleaner identifier ontology.

These documents are going to provide the foundation for the development of
a world wide assertion infrastructure and everyone will benefit from doing
a clean job on them.

Roy: Remember when I pointed out the need for keep alive in the old http spec
in the summer of 1995? URNs are analogous; in two years these things will be
everywhere and people will be building all kinds of interesting things atop them.
The main difference is that enabling distributed assertions is *really* big -- and
you want to be remembered for doing it right.

If there is some reason why the URI document cannot be done right now, then
the URL document should go forward without *any* mention of URIs or URNs.
Someone else can later do the URI document and perhaps provide a more detached
perspective on the controversies.

---

From: Larry Masinter <[email-masked]>
Date: Wed, 24 Dec 1997 20:24:07 PST

> the URL document and that it be consistent with the URN work.

Hi John,

Just to make it really clear: we're not talking about 'points'
or 'principles', we're talking about specific documents. Do you
find that the document(s) that Leslie recently posted (c) are
the only acceptable solution to documenting the relationship of
URLs and URIs and URNs? That the documents (a), (b), and (d)
are unacceptable?

Larry

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

---

From: "John C. Mallery" <[email-masked]>
Date: Thu, 25 Dec 1997 00:29:47 -0500

>URLs and URIs and URNs? That the documents (a), (b), and (d)

Hi Larry,

Just to be clear, I choose C.

C Separate documents for URLs, URIs, and URNs.

Meaning that:

Documents a, b, d are unacceptable.

---

From: Al Gilman <[email-masked]>
Date: Thu, 25 Dec 1997 12:02:20 -0500 (EST)

> URLs and URIs and URNs? That the documents (a), (b), and (d)

On what basis do you feel entitled to "make it really clear"?
I thought that the decision structure had decomposed to the
point where only the ADs could make that pronouncement.

The one thing I would like to vote on is that this process rule
is out of order.

The range of documents offered fails to contain a mutually
agreeable solution precisely because you have not given enough
respect and time to the discovery of areas of agreement expressed
as principles.

The request from Dan, at least, is insensitive to whether there
is one document or multiple.  He needs to be able to refer to
an "URI-reference" in his specs and that definition should be
in one place.  How the rest gets laid out is not, in principle,
of concern to him.

-- Al Gilman

---

From: Larry Masinter <[email-masked]>
Date: Thu, 25 Dec 1997 13:20:44 PST

> On what basis do you feel entitled to "make it really clear"?

I didn't think it required any formal permission to ask someone
to be clear about their opinion on the mailing list. But,
just to make it really clear, I am acting as a member of the
application area directorate:

     http://www.apps.ietf.org/apps-area.html

Within the applications area directorate, I believe that I have 
primary responsibility to facilitate the progress of URI-related
documents, although John Curran has been helping on this particular
issue.

In addition, just to make it clear, I am also speaking as one
of the authors of the documents (a)-(d) in question; my name is
listed as an author on all of them, I have significant investment
in their development. As an editor or author of a standards track
document, I have the responsibility to reflect the consensus of the
Internet community. In order to do so, though, it is reasonable
to ask those members of the community to be clear about which,
if any, of the offered alternatives are acceptable, to explain
their opinions and the basis for them.

> The one thing I would like to vote on is that this process rule

The rules of order for the Internet process are specified in
RFC 2026. The rules call for open review and discussion. Asking
people to be clear about their opinion on documents seems to
be part of "open review and discussion". I believe that "open review"
means, in particular, "open review of documents". We have four
documents. I would like you to review them. You may have important
opinions about other related topics, but at this point, we need
review of the documents.

> respect and time to the discovery of areas of agreement expressed

Al: We've evaluted the principles endlessly. We have four
documents (or more precisely, three documents and one pair
of documents) to consider as choices. It is reasonable to
poll the community, at this point in the process, to be specific
not just about principles (which have been discussed for at least
four years), but about the specific documents. As it stands,
as long as we are talking about general principles as applied
to Internet Protocols, I think we have general agreement. That is,
there is no disagreement, as far as I can see, over the principle
that the relative forms, the generic URL syntax, or the use of
fragment identifiers are defined for URLs, and, in fact, only
for some URLs and not for others. I think there is no disagreement
or any counter-claims that, in general, these forms do not
apply universally to all URNs. There is also no disagreement,
as far as I can tell, to the claim that these forms *might*,
at some point in the future, apply to *some* URNs. (That is,
the messages have been consistent on the point that this is
something that the URN working group 'has not yet decided',
rather than that this is something that the URN working group
'has decided, and decided that the answer is negative.')

The disagreement seems to be entirely over the proper way of
*expressing* the concepts over which we seem to all agree.

In one expression (a), we merely claim that these forms apply
to URLs, and leave any discussion of whether they might apply
to URNs to some other (yet unwritten) document. In expression (b),
we claim that these forms *might* apply to all URIs, that their
applicability depends on the scheme (for relative forms) or the
scheme and media type (for fragment identifiers), and leave it up
to the definition of the URN scheme to be explicit about the
applicability or non-applicability of those forms.

In expressions (c) and (d), the applicability of relative forms
and fragment identifiers is explicitly only referenced for URLs
and omitted for URNs; (c) does this with two documents and (d)
with one.

> in one place.  How the rest gets laid out is not, in principle,

The only document which does not define "URI-reference" is (a).
If we proceed with (a), we still have some choices about how to
deal with the request for the definition of such a term.

The other three choices define "URI-reference"; (b) is explicit
about the possibility that a URI-reference *might*, at some point,
consist of a URN and a fragment identifier, while (c) and (d)
do not admit that possibility. 

I believe that the only reasonable way out of the circular discussions
we've had on this is to get a broader set of input from more members
of the Internet community, and ask that people be explicit about
their preference with respect to the particular expressions that
have been produced so far.

If you dislike all of (a) - (d), or think that specific changes would
give us a document or document set we could all rally around, then
please offer us yet another alternative.

Larry

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 26 Dec 1997 15:36:46 +0100

>We have heard from a few folks, but not a lot. To recap:

Remember - this is Christmas time.
Season of good cheer and good will to all men, and not too much time
left over for IETF discussions!

Just to recap:
The lack of a basic UR* syntax document is blocking forward progress
on some other documents that have chosen to refer to such a document,
including the data: UR? scheme and the extended mailto: UR? scheme.
(the question marks indicate my doubts about the proper labelling of those
schemes, BTW....)

The ADs found, after some thinking, that the situation where we had
a well documented URL concept, a well documented URN concept,
and a totally undocumented URI concept embracing the two was not only
harmful, 
but silly.

The suggestion was made, perhaps foolishly, by me, to turn the URL document
into an URI document to rectify this problem, and Roy attempted to do this,
not
being terribly happy with the result.

So we're where we are, and searching for a sane way out.
To me in my AD position, the parameters of a solution are:

- The solution must document the overall concept that embraces all the
  identifiers of this class, commonly called "URI". (This rules out a)
- The solution must not invalidate current UR* schemes, including URNs.
- The solution should not needlessly complicate or constrain future UR*
  schemes

All I can say is - I hope we find a solution.

Season's greetings to you all, and have a happy new year!

                                   Harald A

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 26 Dec 1997 23:41:42 -0800

>reflects the work that has been carried out in the IETF's URN Working Group.

That is an interesting interpretation of history.  You asked for no
requirements to be placed on URNs, so I placed no requirements on them.
You asked for me to reference RFC 2141, and I did exactly that.
You asked that we not say things about URNs in a document titled
"URL: Syntax and Semantics", and so Larry first removed what I had
written about URIs and later we changed the document title and rewrote
the entire section.  When the eleventh draft of this review (uri-00)
was completed on November 5th, Keith asked for your comments.
You made no comments that I am aware of until December 10, and even
then you did not send them to me.

When I finally did receive your comments, I provided counterexamples
to every claim you made.  There is no basis for your "required edits",
and therefore I have no reason to make them.

>the syntax and semantics of all URIs as defined within the auspices

My document (and yes, it is my document, in addition to Larry and TimBL)
is quite capable of standing on its own.  If you would direct your comments
to what is actually written in the document, instead of what you imagine a
guy like me would be tempted to write, then maybe we can make some progress.

>don't see why I have to, as you are not the jury and arbiter on URNs.

And as I said before, the #fragment is not part of the URN.  It doesn't
make sense for the URN working group to have any opinion regarding them,
just as you can't forbid the use of anchor href attributes in HTML.
The #fragment part of a URI-reference is not in your ballywick.
Plenty of URN-based counterexamples have been provided, so at this
point I don't particularly care what was said about them on the URN WG.
They are part of the URI architecture, of which URN is only one element.
They are an optional feature that is checked for and removed from a
reference BEFORE the parser knows whether it is looking at a URL or URN,
so the URN parser can't do a bloody thing about it.  The only way we could
remove them from the syntax is to exclude the use of URNs from the
URI-reference, which would completely oppose the reason for having
a URI syntax in the first place.

>have been attempting to work with the material that was put on the table.

No you haven't.  You tried to bypass it.  If you had simply sent your
comments on the actual text of the draft, then we could have discussed them.
Instead, you butchered 14 months of hard work and claimed the result
represented the URI syntax.  Well, I know better -- the URI syntax is
defined by the implementations of protocol libraries like libwww-perl
(which I wrote) and libwww (which is the basis for most URI-enabled
applications).  They allow the usable set of URI schemes, including "urn",
to be extended and dynamically loaded with the implicit assumption that
all schemes obey the requirements described in
<draft-fielding-uri-syntax-01.txt>.  That is how we are able to progress
the URI syntax as a Draft Standard.  It is both technically sound and
demonstrated by deployed applications.

>_any_ lack of effort to participate on the URN WG's part.

We have a URI syntax document that meets all of the URN WG's requirements,
as well as those of HTTP, HTML, and XML.  I suggest you read it and make
comments, but don't expect your comments to have any special status just
because you are the chair of a WG.  If the comments are technically
sound, then the WG should be capable of defending them.  The comments
you have made so far have not been technically sound.  Right now the
only excuse you have for not approving the document is that I am one
of the authors, and last I checked that wasn't a valid excuse either.
After all, I won't be able to change the document once it becomes an RFC,
so there is no point in imagining "alarm bells".

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 26 Dec 1997 23:51:12 -0800

>All I can say is - I hope we find a solution.

I claim that <draft-fielding-uri-syntax-01.txt> meets all of those
parameters, and does so in a way that can be demonstrated by current
practice.  The only thing I *would* change at this point is how scheme
prefixes are treated by the relative parsing algorithm (to better match
what has been implemented), but that has nothing to do with the URN
discussion.

....Roy

---

From: Patrik Faltstrom <[email-masked]>
Date: Sat, 27 Dec 1997 20:00:06 +0100 (MET)

> Documents a, b, d are unacceptable.

I agree with the above. (c) is the only working solution.

This is needed because the document currently under the name of a URI
syntax document talk so much about URLs, and use a terminology that is
only valid for URLs, that confusion occurs regarding, if nothing else, the
difference between a URL and a URN. It does not help that the document
have "may" all over the place.

I think it is definitely better if we have documents about URIs, URNs and
URLs, so the number of "may" can be limited to a minimum when we talk
about so important things as grammars and what characters are allowed, how
encoding is done and how to handle/accept things like fragments, queries
and relative addressing.

Personally I have not read the URI syntax document until I, as a member of
the URN working group, was told about the URL syntax document turning into
a URI syntax document during the IETF in Washington, DC. Leslie, as the
chair of the working group, promised to talk to the authors, the area
directors and Larry as the chair of the HTTP group, about the problems we
in the URN working group saw with the intention of the document changed,
and because of that I have not said anything until now. 

I have now reread draft-fielding-uri-syntax-01.txt aswell as Leslies two
proposed documents, to test the thesis I have that (c) is the best choice,
and I must say that it is.

   Patrik

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 27 Dec 1997 13:05:58 -0800

>I agree with the above. (c) is the only working solution.

(c) does not correspond to any implementation that I know of, and
contradicts the implementations of most URI-enabled applications.
You can prove this for yourself by using a URN proxy and attempting
to include "#something" in the reference.  You will find that the
"#something" is stripped before being sent to the proxy, and therefore
cannot be part of the URN because it is the fragment.

>have "may" all over the place.

Almost all example URIs are URLs.  There is no way I could talk about
anything more without defining URN technology, which I preferred to do
by reference to the relevant URN RFC.  You can't have it both ways.
All of the requirements, and even all of the "may", do apply to URNs.
They simply have no impact when they are applied.

As we've said a hundred times already, the point of this exercise is
to define what a parser must do when it is presented with a URI reference,
before it even knows whether the URI is a URL or a URN.  That is because
all scheme-specific parsing takes place within the scheme-handler and
not within the part of the application that deals with URI references.
The purpose of the document is NOT to describe the intersection between
URL and URN -- that would be a total waste of time, since by the time
you know whether it is a URL or URN you are in a different parsing
situation which is scheme-specific.

....Roy

---

From: Patrik Faltstrom <[email-masked]>
Date: Sun, 28 Dec 1997 06:52:19 +0100 (MET)

> They simply have no impact when they are applied.

This is why most of your text works best in a URL definition paper.

> situation which is scheme-specific.

Once upon a time, in Houston, we had a vote(!) in the URI working group if
the string "url", the URI scheme "URI", should be included in the syntax
of a URI. It was a close cut, but the majority voted for not including the
string "url:" in the URL. Several people left the room in protest...and it
was not fun at all.

It _might_ be the case that a URN should be parsed differently than a URL.
It might be that a totally new UR* should be parsed even differently than
a URN and a URL. I agree with you that a design like that might be stupid,
but the fact is that you do have some small common syntactic rules for
URNs and URLs, and that is how you find which one it is. A URN is simple
to recognise as it is prepended with the "urn:" string, but a URN is
harder because the URL scheme is syntactically written in the position
where the URI scheme should be. A parser must because of that have a list
of all known URL schemes, and if the URI scheme is one of those, the
identifier is a URL.

Now, you simplify this by saying that syntactically, a URN can be parsed
the same way as a URL, and one can install in the software a URN parser
just like one does install a handler for a HTTP scheme or mailto scheme.

Well, a lot of people probably do agree with you that that is the way one
can _implement_ URLs and URNs, but that is not the way things are defined.
What do we do when we get URZs which _doesn't_ have "URZ" prepended, but
have the URZ scheme immediately in the beginning of the string, just like
URLs? What happens if the market start writing URNs without the string
"urn:" in the beginning of the string, and instead only write "isbn:" (you
write in your document about the "side of the bus problem" regarding the
fact that HTTP URLs loose their "http://" part)? Is "isbn" now a scheme?
Yes, in the implementation it might be when you parse the string, but it
is still a URN, and not a URL.

We have today two different types of URIs; URLs and URNs. What some of us
ask for are your document divided in three so it is crystal clear what is
a definition for URIs, what is URLs and what is URNs. I simply don't
understand why you are opposing that so much?

It will be much simpler to have the documents updated, and each one of the
documents will be much simpler to read and understand, than having URL and
URN implications in the URI definition part and vice versa.

   Patrik

---

From: Larry Masinter <[email-masked]>
Date: Sat, 27 Dec 1997 22:45:15 PST

I've been wondering if we might progress with a different
perspective, which I will lay out briefly:

The term "URI" denotes a concept: some kind of uniform
space of identifiers for resources. The terms "URL", and "URN",
however, denote explicit protocol elements, with specific
syntax and semantics associated with that syntax. The URL
syntax is well defined and widely implemented; the URN syntax
is newer, but well underway.

It is possible, and convenient, to allow for mutual embedding
of these protocol elements. That is, the space of URNs can
be embedded in the space of URLs by prepending the URN with
the string "urn:". This means that "all URNs are URLs" only
in the trivial sense that it is possible to write a URN as
a URL. The simple embedding is possible because the URN syntax
was chosen (wisely) to fit within the URL syntax.

Conversely, one could imagine embedding the URL name space
in the URN space. Imagine, for example, a URN which consisted
of a date and a URL. The resource named would be 'the
resource that was available at the specified location
at the specified time. This would be perfectly good URN;
perhaps one could say that 'dated-url' was the naming authority,
and write <durl:199712272238:http://www.parc.xerox.com/masinter>.
as the undecorated URN.

With this notion of 'URI is a concept', we don't need or want
a general URI syntax. There's a URL syntax and a URN syntax.
There might be a completely separate URC syntax at some point.
While it is convenient to embed URNs into the URL name space,
it is just an embedding; the semantics associated with URLs
are not inherited by URNs than they are inherited by email
addresses merely because there is a 'mailto:' URL scheme.

Larry

---

From: Larry Masinter <[email-masked]>
Date: Sun, 28 Dec 1997 00:45:54 PST

> What some of us
> a definition for URIs, what is URLs and what is URNs. 

The proposal (c) divides (b) into two, not into three. I'm
guessing you really meant "two".

And the question is whether (c) actually makes it "crystal clear"
what is a definition for URIs, what is URLs and what is URNs. I think
we all want the definitions to be "clear", but it is exactly the clarity
of these documents that we're discussing.

In an earlier message, it sounds like you are saying that you have
reviewed (b) (draft-fielding-uri-syntax) and (c) (Leslie's two-documents),
and that "(c) is the only working solution". Do you mean to say
that you also have found (a) and (d) unacceptable?

Do you find it less, or more confusing, to have both:

>    Many URL schemes have been defined.  The scheme defines the
>    space of the URL, and thus may further restrict the syntax and
>    semantics of identifiers using that scheme.

in the URL document, and also

>   Many URI schemes have been defined.  The scheme defines the
>   namespace of the URI, and thus may further restrict the syntax and
>   semantics of identifiers using that scheme.

in the URI document?

> have "may" all over the place.

Can you say what the 'confusion' is? There's a section 1.2 URI, URL, and URN,
which attempts to discuss the difference.  Is this confusion also in
place for (d) or (a)?

> encoding is done and how to handle/accept things like fragments, queries

There are no fewer "may"s in the combined (c) than there are in (b).

As far as I can tell, there is no proposal to have a different
set of allowed characters in "URI" than in "URL", so I'm not sure 
waht you mean by "what characters are allowed". Also, I don't see
any proposals to have a different mechanism for encoding for URNs
and URLs. Are you suggesting there might be such a thing?

I agree that the query forms are unlikely to apply to URNs, that relative
addressing is problematic, and that fragments are controversial, but your
message indicated that you belive there are more extensive differences
that are not just restrictions, which would be a much more serious issue.

Larry

---

From: Larry Masinter <[email-masked]>
Date: Sun, 28 Dec 1997 00:53:29 PST

> can _implement_ URLs and URNs, but that is not the way things are defined.

....

The question is: do you think that is the way things SHOULD BE defined?
I"m guessing that's really what this is about. SHOULD we allow URZs to
have different rules than URLs and still call them the same protocol element?

---

From: Patrik Faltstrom <[email-masked]>
Date: Sun, 28 Dec 1997 13:43:21 +0100 (MET)

> guessing you really meant "two".

Well, we do have a document which talks about the syntax for URNs aswell.
I.e. yes, it is true that (c) splits the document on the table in two, but
the result will be three documents.

> that you also have found (a) and (d) unacceptable?

Yes.

What I mean is that I think that draft-fielding-uri-syntax should be split
into two, and as arguments for that I did read the original document --
and then Leslies suggestion on how a split should be done.

> >   semantics of identifiers using that scheme.

If we just decide that a cut and creation of two documents makes the final
result better, we can then work on the details. I think there are things
in Leslies cut which did not make 100% sense, mostly (I guess) because
text should be rewritten (like the above) when we have two documents.

As it is now -- I do only argue for a separate document about URI syntax
from one about URL syntax.

I think Leslies suggestion did show that two documents were better. I can,
if we go down that path, come with perticular suggestions what should be
better in those.

I think for example that some "may" in the URL document should be "must".

> which attempts to discuss the difference.  Is this confusion also in

The confusion is when there are so many parts that talk about (today)
URL-specific things as URI-things, but with a "may". One example is
relative URLs, which I think should be described as relative URLs, and not
relative URIs. The same thing about fragments, and details on how to
construct and parse query/username etc constructions. It sounds like if
these things -- even though they are preceded with a "may" -- should apply
to all URIs, and more specifically to the _design_ of a URZ, URB, URX or
whatever.

> There are no fewer "may"s in the combined (c) than there are in (b).

Well, I think they might be able to be fewer. I might be wrong. I would
like to say that _IF_ certain functionality should be able to be applied
to a URL scheme, it _MUST_ syntactically be written in a certain way. That
rule might not be possible to create if we also include URNs -- because
the URN namespace itself might have rules and constructions which makes
that rule not appliable.

Also, because a URN and a URL are different things (as a URN can be used
in a number of ways, N2Ls, N2L, N2C,...) they are also used differently --
and certain operations one can apply to a URL can not be applied to a URN
and vice versa.

> and URLs. Are you suggesting there might be such a thing?

This is from a discussion I had with the Handle people, which didn't
understand why we when talking about URNs did say that the character set
in use should be UTF-8 encoded UNICODE 2.0, when so many different
character sets did work when using HTTP URLs. Well, this is because when
getting a URL, you normally (there are exceptions of course) get them in a
HTML document as a reference. That reference is then, as-is, passed back
to the same server as the one that did pass the reference to the client,
so noone have to parse the stream of bytes passed back and fourth over the
wire. The URL, if displayed on the screen in the clients browser, might
look funny, or like garbage, but it will work. This as long as the client
doesn't change the stream of bytes.

But, when talking about URNs, the URN will be inside some document, say a
HTML one. That URN will _NOT_ be passed to the same HTTP server, but to
some resolver (in the case of a N2L resolution) which must understand what
characters are represented in the name-space-specific string, so a search
can be done, which in turn will result in the URL which is sent back to
the client. That URL is then what the browser in this example sends back
to the HTTP server to get the next HTML page.

As you can see in this example, we have when using URNs a third party
involved -- or at least some function which acts as a resolver which in
this simple example turns the URN into a URL which is then used as normal.

Because of that -- it is definitely needed when talking about URNs to
agree on what character set and encoding is used, as the parties involved
have to be able to parse the characters (not the bytes) sent in the URN.

> that are not just restrictions, which would be a much more serious issue.

All of these issues you rise are things that we know how to handle in the
case of a URL, and character set issues are things we know when talking
about URNs. We do though not know in detail how things like relative
addressing, fragments, query forms etc etc should, if ever, applicable to
URNs, so I rather have one document for URIs, one for URLs and a third for
URNs.

It does just make so much more sense -- especially when the URLs and URNs
are so different regarding usage. I.e. many things are more mature when
talking about URLs. I do not say that the URN people (including me) should
invent their own way of handling things different than URLs. That would
be stupid. Totally stupid. I just say that some things might NOT apply to
URNs, only to URLs. Who knows if they will apply to URXs? So, let write
about URLs in one document and URNs in one.

I also think it is a good idea to talk about things like how to implement
a parser for URLs that also handle URNs and URXs, like what Roy has done,
but that is something different than talking about the syntax for each one
of the constructs. That is a BCP which might also be needed.

   Patrik

---

From: Patrik Faltstrom <[email-masked]>
Date: Sun, 28 Dec 1997 13:53:20 +0100 (MET)

> have different rules than URLs and still call them the same protocol element?

This is exactly why we need a URI syntax paper, and a separate URL and URN
one. Everything that fulfils the basic requirements of a URI paper should
be able to be a URZ or whatever. They should not have to fulfil everything
that are URL requirements.

If the URZ designers are smart (and the IETF process should stop them
otherwise) they _inherit_ things from the URL and URN papers so URZ are as
little different from URLs and URNs as possible. One example is that '#'
is a special character in the URN syntax, inherited from the URI RFC 1730
(or whatever it was...), but also because IF '#' was allowed as a
non-quoted character in a URN, it would break so many implementations.

Anyway, from my point of view, there is a big difference making URZs
compliant to a URI syntax paper -- and then _inheriting_ necessary and
interesting parts from the URL and URN syntax papers, from making URZs
using some "mays" from a common URI/URL syntax document. Say that in URZs
one need (for some reasons) have the query portion specified differently
than in URLs (that's why they are URZs...)? Should that not be allowed?

   Patrik

---

From: Dan Connolly <[email-masked]>
Date: Fri, 02 Jan 1998 09:29:40 -0600

> >We have heard from a few folks, but not a lot. To recap:
[...]
> All I can say is - I hope we find a solution.

Harald, it would help me out if you would
please point out how it is that (b) is not a solution.
I read it quite carefully and I find it satisfactory.

I don't understand the arguments from the folks who
find it unsatisfactory; rather, I think I understand them,
but I can't find any technical content to them. They
seem to boil down to "but we're not sure it's going to
work that way for URNs."

I am trying to find (c) to review it, but I'm not having
any luck.

Since Larry asked, I'll (re-)state the W3C opinion: we're
heavily invested in the notion of a single, extensible universal
address space:

============
Univeral Resource Identifiers -- Axioms of Web architecture
Tim Berners-Lee
Date: December 19, 1996 
[1]http://www.w3.org/DesignIssues/Axioms.html

Universal Resource Identifiers

The Web is a universal information space. It is a space in
the sense that things in it have an address. The
"addresses", "names", or as we call them here identifiers,
are the subject of this article.  They are called Univeral
Resource Identifiers (URIs). 

On object is "on the web" if it has a URI.  Objects which
have URIs are sometimes known as "First Class Objects"
(FCOs).  The Web works best when anything of value and
identify is a first class object.  If someothing does not have
a URI, you can't refer to it, and the power of the Web is the
less for that. 

By Universal I mean that ...
============

The name has changed over the years (from UDI=Universal Document
Identifier to URI=Universal Resource Identifer to
URI=Uniform Resource Identifier) but the concept remains
the same. Not to mention the fact that the gizmos themselves
remain the same (try
http://info.cern.ch/hypertext/WWW/TheProject.html and you'll
still get information about the World Wide Web project at CERN.)

So we (W3C) disagree with what Leslie wrote:

Leslie, 23 Dec 1997:
>Roy, 22 Dec 1997:
>> Within the WWW, a fragment serves the purpose of a client-side
>> specialization of the resource identification.  It is implicit that
>
>URIs are not limited to the WWW (okay, these are getting into old
>arguments...).

URIs are limited to the WWW by definition; that is, the
WWW is the set of things addressable by URIs.

I have asked whether folks
expect URNs to fit into the same protocol/software slots
as today's URIs do (e.g. in proxied HTTP GET requests,
Java URLConnection() parameters, libwww URI parsing
calls, etc.) but I don't think I got a clear answer. If
URNs _are_ expected to fit into those slots, then
we need a spec for those slots, and (b) is good enough for me.
(we also need one registry of schemes, and one
process document for adding items to that registry). If
URNs are _not_ expected to fit in those slots, then
I have a problem with that.

The axioms document[1] goes on to say things like:

=============
Axiom 1: Global uniqueness 

 It doesn't matter to whom or where you specify that URI, it
 will have the same meaning.
=============

These axioms are exactly that: arbitrary assertions without
supporting evidence. They take on value as folks choose
to accept them (folks being implementors, information providers,
etc.) "The value of
a network goes up as the square of the number of connected
resources" and all that.

So while it's perfectly possible
to use names/addresses/identifiers that aren't part of
the URI space, any such set of names doesn't benefit from
the value of being part of the URI space. At W3C, we
think there's plenty of ways to improve the operation of
the URI space, and no reason to invest in something
that doesn't interoperate, at this point.

=============
Axiom 3: non unique 

 URI space does not have to be the only universal space

The assertion that the space of URIs is a universal space
sometimes encounters opposition from those who feel
there should not be one universal space. These people
need not oppose the concept because it is not of a single
universal space: Indeed, the fact that URIs form universal
space does not prevent anyone else from forming their own
universal space, which of course by definition would be
able to envelop within it as a subset the universal URI
space. Therefore the web meets the "independent design"
test, that if a similar system had been concurrently and
independently invented elsewhere, in such a way that the
arbitrary design decisions were made differently, when
they met later, the two systems could be made to
interoperate. 

There may be in the world many universal spaces, and
there need not be any particular quarrel about one
particular one having a special status. (Of course, having
very many may not be very useful, and in the World Wide
Web, the URI space plays a special role by being the
universal space chosen in that design.) 

For example, it would be possible to map all international
telephone numbers into URI space very easily, by inventing
a new URI "phone:" after which was the phone number. It
would in fact also conversely be possible to map URIs into
international phone numbers by allocating a special phone
number not used by anyone else, perhaps a special
country code for URI space, and then converting all URIs
into a decimal representation. In that case, both URIs and
phone numbers would be universal spaces. Identifiers in
one space would be consisting only of numbers, and in the
other of alphanumeric characters. One would be shorter
than the other, but there is no reason why, in principle, the
two could not co-exist, allowing you to dial any Web object
from a telephone as a telephone number, and point to any
phone from a hypertext document.

So, on this last axiom rests not specifically the operation of
the web, but its acceptance as a non-domineering
technology, and therefore our trust in its future evolvability.
=============

-- 
Dan Connolly, W3C Architecture Domain Lead
http://www.w3.org/Architecture/

---

From: Michael Mealling <[email-masked]>
Date: Fri, 2 Jan 1998 11:43:56 -0500 (EST)

> seem to boil down to "but we're not sure it's going to

I'll try to explain some below.

No argument. Just a desire that has been explained before:
It is agreed that all Objects have identifiers. It is
observed that there are identifiers that have the characteristics
of names (spatial/temporal uniqueness, encouraged but not required 
persistence) and others that have the characteristics of addresses 
(strong tie to location, non temporal uniqueness, no desire for
persistence (some are specifically one-time use only)). 

The URN group's desire was to attempt to group those identifiers
that had naming qualities into a class of identifiers so that
ANYTHING that identified itself as being part of that class
could be assumed to have those same qualities by an entity that
didn't know that particular subscheme.

> By Universal I mean that ...

This is true by definition. What Leslie was trying to explain was
that many URIs may never be used by by a parser and were never
intended to do so by their creators. E.g. the library commmunity may want
to use URNs as a way to umbrella several identifiers out there. 
The syntax defines how they do it. There is no "protocol slot".

> we need a spec for those slots, and (b) is good enough for me.

But the document's we have been talking about talk in
terms of those slots. Not the identifiers themselves. What
we are concerned about is that the requirments created by the protocol
slots are inappropriate for the universaly understood definition
of a URI.

I've always wanted a document that described URIs in a completely
abstract way. Sans the Web. Sans hypertext. Sans libwww. Sans any
protocol or markup language.

Then write a document that describes how specific technologies use
them. 

I.e. I think your desire for a spec for those slots is wrong.
You should want a spec for URIs in an abstract sense. And then
a spec for how those abstractly defined URIs fit your protocol/software
slots.

> I have a problem with that.

URNs are expected to fit those slots. But those slots should not
get to define what URNs are. Instead those slot specifications should 
define how they use them.

> The axioms document[1] goes on to say things like:

URNs also define an additional requirment of uniqueness: time.
This is the non-reassignment requirment.

Which is why we formulated URNs to fit that scheme. What
I think we're after is a definition of URIs that isn't
in terms of specific technology but of a true abstract
definition unencumbered by specific technology.

I think you're bordering on Larry's last suggestions which
I liked. What I'm suggesting is that the currently discussed
draft makes to many _hypertext_ specific requirments that cause
it to not be able to subsume other namespaces in your interoperability
example. Make the definition of URIs general enough and not tied
to any current implementation so that the requirments on grandfathered/
interoperated schems is _extremely_ minimal.

It's then perfectly reasonable to create a new document that
describes the limitations that use by the hypetextually oriented
Web creates (relative URIs and fragments).

-MM

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

---

From: Michael Mealling <[email-masked]>
Date: Fri, 2 Jan 1998 12:03:23 -0500 (EST)

(Can you tell I just got back from the holidays?)

> perspective, which I will lay out briefly:

I have to say I like this approach with some minor wordsmithing.
It falls into my desire for an abstract definition instead of
a protocol/markup language specific one.

> however, denote explicit protocol elements, with specific

I'd suggest removing the "protocol" in the last sentence. It
should be up to each design to determine whether or not it
is intended for a real wire protocol or not.

> was chosen (wisely) to fit within the URL syntax.

This is inline with Dan's cut-n-paste of Tim's Axiom 3 on non-uniqueness
of URL namespaces (the phone: example).

> and write <durl:199712272238:http://www.parc.xerox.com/masinter>.

Sure. Someone suggested this before. Actually, I think you did. 

> addresses merely because there is a 'mailto:' URL scheme.

Exactly! (I'll have to remember your mailto example).

-MM

---

From: Michael Mealling <[email-masked]>
Date: Fri, 2 Jan 1998 12:39:58 -0500 (EST)

> We have heard from a few folks, but not a lot. To recap:

Larry reminded me that I didn't answer this question before I started
blabbing my opinions. I'm an advocate of (c). I'd like to see
it re-worded in order to reflect Larry's later suggestion of
URIs being a concept rather than something defined by a protocol slot.

-MM

---

From: Larry Masinter <[email-masked]>
Date: Fri, 2 Jan 1998 09:53:03 PST

Michael,

I think you've made an important point that I don't want to
get lost. The syntax forms that are controversial
(fragment identifiers, relative forms, query syntax)
are part of the application of HYPERTEXT.

In fact, whether or not you want those forms seems to depend
entirely on whether or not you think you're doing hypertext.

The distinction between having them and not seems to have
little to do with whether or not the identifiers are "location
independent". If you want a resource locator but you're
not doing hypertext (e.g., the resources that you're locating
are printers for IPP or servers for service location or whatever)
then the relative, query, and fragment forms are not applicable.

If you ARE doing hypertext, then those forms are useful,
even if you believe the identifiers are permanent, location
independent, and have all of the attributes that are intended
for URNs and not for URLs.

"Uniform Resource Identifiers" define a space of fully qualified,
non annotated names, while "hypertext references" imbue some
semantics to the internal syntax of URIs (namely, give significance
to "/" and "?" within Uniform Resource Identifiers), add a new
syntactic element ("#" fragment identifiers), and add a new protocol
element (relative identifiers).

Larry

---

From: Al Gilman <[email-masked]>
Date: Fri, 2 Jan 1998 17:29:29 -0500 (EST)

> entirely on whether or not you think you're doing hypertext.

This is an interesting idea to pursue, but not credible in
the strong form you stated.

If I were on the road wanting to find the nearest IPP accessible
Braille embosser with a courier delivery option, I believe this
could well wind up as a resource-discovery query involving
something much like the ?parm-list familiar in URLs.

Not all of the functions you reference are limited to HyperText
applications.  But one can, for the purpose of analysis and
understanding, break out a lattice of classes of [names or
identifiers] with longer and shorter sets of "what you can
do with it" attached to the class.

>From the naming perspective, the paramount characteristic
is that the identifier contains a sufficient key (attribute
cluster).  The ability to abbreviate [for relative forms]
in selected contexts [where a document context or other basis
for establishing a BASE environment characteristic exists]
and to parse by certain methods are introduced lower down
in the class web, in more concrete "derived" classes. 

["lower" here is dependent on having adopted a "naming
perspective."]

The difference between an URL view and an URN view of URIs could
be summarized in terms of which of the following failure modes
you are more concerned to avoid:

	- The identified resource exists, but you don't get it.
		-- URL cares first to avoid this
	- You get a resource, but it is not what you intended.
		-- URN cares first to avoid this

-- Al Gilman

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 02 Jan 1998 22:11:32 -0800

>entirely on whether or not you think you're doing hypertext.

Nope.  Relative forms are a means of namespace abbreviation.
Query syntax is simply a convenient mechanism for parameterized
access to a resource, which exists only for the sake of common
client implementations.  Fragment identifiers are a mechanism for
identifying a subset of the result of a retrieval.  Whether or not
all of these are only part of the application of hypertext depends
on your definition of hypertext.

Hypertext can be usefully defined either in terms of the UI or
the architecture.  Using the UI definition of hypertext from
Ted Nelson (via Jeff Conklin's Survey): "a combination of natural
language text with the computer's capacity for interactive branching,
or dynamic display ... of a nonlinear text" is obviously insufficient
to cover all of the applications which use relative URI today.
Keep in mind that my protocol library was original written to support
maintenance applications, not dynamic display.

The architectural definition of hypertext is simply that information
can be organized by relationships between information, and further
that resources can be organized by the relationships between
representations of those resources.  This is what I think of as an
Engelbart/Berners-Lee definition, though I'm not sure it was ever
written as such by them.  This definition does cover all of the
controversial syntax forms, but then it also covers all possible uses
of URNs as well, including semantically rich name comparison.

In either case, making a distinction between URI use in hypertext and
URI use outside of hypertext is pointless.  The URI syntax includes a
variety of forms that *allow* the use of relative identifiers, *allow*
the distinction of query parts, and *allow* the presence of fragment
identifiers.  They exist NOT because they are useful for all URI, but
because they ARE useful for some URI.  The syntax is thus defined to
*reserve* those forms in such a way as they *can* be used when someone
wants to use them, and in a way that is *independent* of the scheme
definition.  Moreover, their presence has no adverse impact on uses
of URI that exclude those forms.

That is why I made an explicit distinction between URI-reference
and the other BNF terms in the specification.  HTTP, HTML, and XML
(and many other protocols) need a Draft Standard for a URI-reference.
That is what the URI syntax is all about.  It is not, and never has been,
the intersection of the requirements for URL and URN.  It cannot be,
since the actual requirements for individual URL schemes do not have
much in the way of an intersection.  Protocol fields that do not wish
to allow the relative form and/or fragment will use the <absoluteURI>
BNF term instead.

>then the relative, query, and fragment forms are not applicable.

Fragment wouldn't be useful, but relative and query forms are
useful in any context where many related printers are being identified,
or servers for service location or whatever.  Namespace abbreviation 
is a universal principle.

>element (relative identifiers).

Sorry, that has no basis in reality.  "Uniform Resource Identifiers"
have a Uniform syntax in order to be used and processed as URI references
by portions of overall system implementations that DO NOT KNOW the
scheme-specific semantics.  This allows a separation of concerns between
those elements of the system that collect references (e.g., HTTP field
value parsers, HTML/XML element attribute parsers, etc.) and those
elements of the system that perform semantic operations on those
identifiers.

In order to process an entire set in common, the set of rules that
guide that process must be common for the entire set.  Applications
that use a URI reference do not check to see whether it is a name
or a location before they apply the relative resolution process.
Aside from Navigator (which is artificially restricted to a small set
of URL schemes by poor design), existing WWW applications don't even
check the scheme name until an actual retrieval request is made.

Michael, while I appreciate your desire to have a general definition
of URI that represents only the philosophical principle of identifying
a resource, the fact of life is that we don't need one.  Such a paper
would be useful as a research survey, but not as a Draft Standard
definition of specific protocol elements in current practice.  The latter
is what I am doing, and what <draft-fielding-uri-syntax-01> is intended
to represent, and why we are discussing this in the IETF and not at
a research conference.

While we sit here debating what is or is not relevant to a URN, several
dozen technical specifications in preparation by the IETF or the W3C are
being held back because we don't want them to be specified in terms of
the older RFCs (1670, 1738, 1808) which are known to be wrong.  If there
is nothing in the current draft that prevents the URN WG from defining
the URN as they please, then there is no valid objection to the draft
regarding what the URN does or does not allow.

The only alternative is to make "Locator" synonymous with "a URI that
might be used to locate a resource for the purpose of access" and then
call everything a URL, including all URNs when they are used for that
purpose.  But we have ALREADY discussed and discarded that option because
nobody here (including me) wants to refer to URNs as a subset of URLs.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 02 Jan 1998 22:28:17 -0800

>I am trying to find (c) to review it, but I'm not having

Sorry for the delay in responding -- lovely flu season here.
The original message was MIMEencoded, so I placed the intro
and two split specs in my sandbox

    http://www.ics.uci.edu/~fielding/url/leslie0.txt
    http://www.ics.uci.edu/~fielding/url/leslie1.txt
    http://www.ics.uci.edu/~fielding/url/leslie2.txt
    
....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 02 Jan 1998 23:22:45 -0800

>to all URIs, and more specifically to the _design_ of a URZ, URB, URX or

That's because they do in current practice, by design.  Protocols and
data formats that make use of URI references do place all of those
"may", "should", and "must" requirements on anything that is placed
within those URI references, whether it be a URL, URN, URZ, URB, URX or
whatever.  That is the purpose of the URI syntax.  If a protocol
element does not want those features, then it does not use the BNF
terms associated with those features.

>the URN namespace itself might have rules and constructions which makes

The URL schemes already in practice do not have anything more in
common than what is specified in the URI draft.  There are no MUST
requirements for such things because doing so places semantic requirements
on URLs that simply aren't needed by the generic parser.

>and certain operations one can apply to a URL can not be applied to a URN

Scheme-specific semantics do not belong in the generic syntax draft.
In any case, the above is false --- it depends on the scheme definition
and not on whether it is a URL or URN.

>have to be able to parse the characters (not the bytes) sent in the URN.

Before making such arguments, it is useful to check the specification,
specifically section 2.1:

   In general practice, many different character encoding schemes are
   used in the second mapping (between sequences of represented
   characters and sequences of octets) and there is generally no
   representation in the URI itself of which mapping was used unless
   the URI scheme requires a specific mapping.  While there is a strong
   desire to provide for a general and uniform mapping between more
   general scripts and URIs, the standard for such use is outside of the
   scope of this document.

The operative words here are "unless the URI scheme requires a
specific mapping."  The "urn" scheme does require a specific mapping.
This does not in any way interfere with its treatment as a URI.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 02 Jan 1998 23:40:26 -0800

>addresses merely because there is a 'mailto:' URL scheme.

This is what we were working on, until the URN folks insisted that
a URN could not be a URL, and therefore could not be referenced
by the URL specification.  Likewise, many people feel that
"identifier" is a better term for this interchangeable syntax
than is "locator".  If people could just make up their minds on
which is better 

   o URN can be considered a URL for some purposes

   o URN can be considered a URI for some purposes

then maybe we can make some progress.  Please note that we have already
written both of those specifications, minus a few adjustments needed to
correspond with more recent editorial improvements.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 03 Jan 1998 00:14:48 -0800

>of all known URL schemes, and if the URI scheme is one of those, the

I don't think you understand the impact of the URN WG's decisions.
The "urn" is a URI scheme.  It is not "harder" or "easier" to interpret
than any other URI scheme --- you just give it to the "urn" handler,
which is then perfectly capable of giving it to some other sub-handler
if that is how the "urn" handler is designed.  The URI syntax doesn't
care about such things, because the URI parser doesn't care whether the
identifier is a URL or URN.  Those are scheme-dependent issues, not
URI issues.

The only application I know of that is dumb enough to use a fixed
list of known URL schemes is Navigator, and plain text scanners which
attempt to convert URLs in text to a hypertext reference.  Most
everything else is based on either the W3C/CERN libwww which uses a
registry of callbacks, or my own libwww-perl which uses module hooks.
This is because these architectures are designed for extensibility.
We all want this to be true, and even more prevalent in the future,
because URNs will never be deployed if they can't be used.

>is still a URN, and not a URL.

Yes, if people were not to include the "urn:" prefix, then it is no
longer within the "urn" scheme.  The scheme is not optional, nor will it
ever be optional.  I believe I've said this before on the URN list.

You are talking about a philosophical problem, and I am talking about
running code.  We need a definition that corresponds to the running code,
not to the philosophical problem.

>understand why you are opposing that so much?

Because what you are asking for is not true in current practice, nor can
it be defended by any implementations, nor is it capable of being defined
as a Draft Standard.  Aside from that, it is also poor design.  That is
why I oppose it so much --- I have no desire for a useless specification
that specifies nothing more than the territorial boundary between two
IETF working groups.

....Roy

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 06 Jan 1998 12:59:34 +0100

>I read it quite carefully and I find it satisfactory.

That's why it went to Last Call - at first glance I found it so too.
At second glance (and considering others' vehemence), I'm not 
sure at all.

>heavily invested in the notion of a single, extensible universal

The problem, to my mind, is that we really have two deep axioms
here:

- The class of identifiers that, roughly speaking, start with
  a short string and a colon, and go on in a charset-limited way.
  All the URI axioms you cite are axioms of that class.
- The class of identifiers that, in addtion to being of the first
  class, obey certain additional rules, such as hierarchy,
  hostname representation and so on.
  None of this is necessary for the URI axioms; they are vitally
  necessary for today's day-to-day usage of the World Wide Web.

(Everyone with me so far?)

There are people among us who think (I think) that the rules of the
second class are more a result of the history of the field than they
are a good design that should be followed in the future; in particular,
they want to make sure that nobody - BUT NOBODY - builds into their
software assumptions that all URLs that happen to look like "type 2"
can be treated like "type 2" URLs.

This separation is, I think, probably best served by having 2 different
documents, one for URIs giving the "type 1" rules and one giving
the "type 2" rules.

If this is the case, we have more issues:

- Is the #fragment rule a "type 1", "type 2" or "none of the above, but
  should be mentioned in both places"?
- For things that are currently called URLs, but don't follow the "type 2"
  rules, should we recategorize them as URIs or say that the URL concept
  embraces both "type 2" URIs and some other URIs?

If separation is not the Right Way, the issues are of course slightly
different....

                                   Harald A

---

From: Al Gilman <[email-masked]>
Date: Tue, 6 Jan 1998 10:07:25 -0500 (EST)

to follow up on what Harald Tveit Alvestrand said:

> >heavily invested in the notion of a single, extensible universal

Al Gilman:
That's one of the sources of the problem:  too much emphasis on
singleness.  If you frame the problem as understanding a class
of text strings that function as identifiers, in the context of
a web of string and name classes, you will get unstuck from the
impasses.

> (Everyone with me so far?)

Al Gilman:

Almost.  You are very close.  But you are not getting quite deep
enough.  It is not clear that everything that gets called an URN
needs to have all the armor of your first class.

There is a level of abstraction for names where the relative and
absolute URLs that retrieve the same resource are viewed as
variant forms of one name.  We may need to link the URI documents
to documents which capture this view of the naming agenda in
order to have adequate documentation of what is going on.

> If separation is not the Right Way, the issues are of course slightly

Al Gilman:

The Right Way is a web of sub-documents specifying a web of
classes.  So long as the semantics of the sub-documents is strong
enough, the grouping into documents becomes a non-problem.  The
IETF is being materially hampered in working this situation by
its failure to adopt more powerful linking and semantic modeling
norms for its working documents.

The canonical sub-document web for this topic is:

Ancestor classes [standards track]:

	a string class that survives a variety of environments

	a name class that guarantees certain semantic properties

Resource classes [BCP track]:

	addressing imported from the Internet platform

	generic hierarchy as has been used in multiple URL schemes
	
	intra-document references to named subdocuments or locations
	[via #fragment construct]

	[I may not have got them all]

Scheme specifications [three tracks per URLreg plans]:

	Draw on the above two sets of class definitions.

The URN development 
	
	- should be free to define names as polymorphic
	and containing some forms that do not meet
	the hardiness requirements of the HTML/HTTP cycle.

	- should get with the program of scheme extension
	so we have one program of scheme vocabulary 
	definition which will preserve the low cost of
	distinguishing things syntactically across a
	broad range of contexts.

-- Al Gilman

---

From: "David G. Durand" <[email-masked]>
Date: Tue, 6 Jan 1998 13:08:34 -0500

On Jan 6, 12:59pm, Harald Tveit Alvestrand wrote:
> Subject: Re: URI documents

This class of properties certainly seems to be essential to solving the
concrete protocol problems. Standards like HTML and XML need to be able to
refer to identifiers regardless of whether they are names or locators, and need
to be able to parse those locators dependably (which means knowing about
character repertoire, and scheme identifier at the least).

>   necessary for today's day-to-day usage of the World Wide Web.

The hierarchy rule is potentially applicable to many sorts of namespace.
Hostnames are much more limited in application to specific protocols (leaving
aside the use of hostnames as indentifiers in contexts where communication with
the host is irrelevant).

While several proposed URL spaces have no notion of hierarchy, some do, and of
those, _some_ but not all, may sensibly be used with "relative addresses" of
the "relative URI" sort. So the "hierarchy properties" may not apply globally
to all forms of URI. On the other hand, _where_ hierarchy can be applied, it
should be done in a uniform way, so that knowledge of naming scheme is not
required in order to parse and properly resolve relative URIs.

The current framework actually provides this -- if non-hierarchical namespaces
are required to always escape any occurrences of the "/" character in their
URIs. This is probably an inconvenience in some legacy URN spaces, but
providing a uniform method for using hierarchical and relative URIs does not
force non-hierarchical namespaces out of existence. It does limit their
character set further so that they don't contain the hierarchy-marking
character.

I agree with that relative URNs may well be a bad idea, nd they are certainly
not well understood (what is the "base URI" in a protocol-independent context?)
However, the current URI proposal does _not_ prevent URN namespaces from being
defined in a way that can avoid relative URNs and their attendant hair -- and
will allow them to be deployed safely and in a manner uniform with relative
URLs.

> (Everyone with me so far?)

Mostly, but I'm not yet convinced that we actually need two documents to meet
the needs implied by your helpful analysis.

> can be treated like "type 2" URLs.

I guess I can understand that perspective quite well, but I'm unconvinced that
it is a real problem with the current language -- we can avoid relative URNs by
simply not allowing "/" in the relevant namespaces. As to fragment ID's I'll
say more in a minute.

> documents, one for URIs giving the "type 1" rules and one giving

Making this disctinction clearer might help, but I don't in fact see that
allowing the type 2 rules as universals is in fact a practical problem. If we
don't make URNs that look like "TYPE 2" URLs then there's no problem to solve.

>   should be mentioned in both places"?

It's TYPE 1, because the interpretation of fragment IDs explicitly depends on
the application and data type of the resource. The HTML applications use it in
a way that does not depend on URI format or resolution method at all.

XML, for instance, defines special processing for Fragment-IDs that is relevant
for any URI that is resolved to an XML document.  This syntax is intended to be
used with URI references in XML documents for processing by XML Linking-aware
software. Whether the URI is a URN or URL, is irrelevant to this application.

This is perhaps an example of Larry's "Hypertext-like" applications of URIs.

[[aside: at one point I proposed the use of (URN-like) SGML FPIs for authority
control in a series of art databases. Query-strings and fragment-IDs are
unlikely to be sensible for objects like "Picasso" or "Guernica". But this
doesn't really strike me as a problem that name syntax will really solve, but
rather an issue of the semantics of some namespaces and applications. "Fetch
resource," for instance, is unlikely to work on "Picasso" without criminal
activity or supernatural intervention.]]

>   embraces both "type 2" URIs and some other URIs?

I don't know about this one..

> If separation is not the Right Way, the issues are of course slightly

   I think you actually got the issues pretty well, but I don't see that
separation is needed. The current single-document approach may be a bit
unweildy, but it's technically sound.

  -- David

------------------------------------------+----------------------------
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

---

From: <[email-masked]>
Date: Tue, 6 Jan 1998 16:03:55 -0500

David G. Durand writes:
 > While several proposed URL spaces have no notion of hierarchy, some
 > do, and of those, _some_ but not all, may sensibly be used with
 > "relative addresses" of the "relative URI" sort. So the "hierarchy
 > properties" may not apply globally to all forms of URI. On the other
 > hand, _where_ hierarchy can be applied, it should be done in a
 > uniform way, so that knowledge of naming scheme is not required in
 > order to parse and properly resolve relative URIs.

I agree completely.  One addition I would make: In cases where hierarchy
doesn't apply for a scheme, but the scheme still uses '/', if relative
URIs are never used relative to URIs in that scheme, then there should
never be a problem with the lack of support for hierarchy.  But if
hierarchy were later introduced for some reason, that would be a problem.

 > I agree with that relative URNs may well be a bad idea, nd they are
 > certainly not well understood (what is the "base URI" in a
 > protocol-independent context?)  

We discussed relative URNs at some length last spring or so, and I was
under the impression that the problems with relative URNs were more of
an uncertainty about the nature of the beast rather than a clear danger.
Concerning the base URI problem, there is a clear answer: the client
should either use what it is told to use, or it should use the last URI
(not the first) that it used to resolve to the resource.

By the way, I am of the belief that hierarchical URIs (including URNs)
are necessary for scalability, just as DNS itself uses hierarchy for
scalability.  The use of hierarchy to support relative URIs is
secondary, but also useful for some of the same reasons they are useful
relative to the run-of-the-mill http URLs.  Multiple URIs (including
multiple URNs) for a single document are allowed, and will occur.

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

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 07 Jan 1998 10:22:31 +0100

At 00:03 1998-01-07 PST, Larry Masinter wrote:
>If we attempted to remove any indication that the URI document did
>anything more than specify the syntax of URIs and how that syntax
>should be processed by URI-processing software, with any semantic
>interpretation of the *meaning*, do you think we could get beyond
>the current impasse?

Yes.

See my posting on this problem with the different levels of characters,
octets etc, that should float around on this list, as one example of what
complicates things -- which shows that we should make this simpler, not
more complicated.

   Patrik

Email: [email-masked]            URL: http://www.tele2.se
PGP: 4D38 91A4 27D9 C8B2 6975  D6BB 21D0 4C57 BD23 6602

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 07 Jan 1998 07:27:58 +0100

>  should be mentioned in both places"?

It depends on if you talk about the syntax (using the octet with value '#'
in US-ASCII as a special octet in the URI sequence) or if you talk about
the functionality. I.e. the conclusion is that it has to be mentioned in
both. The character '#' is a special in the URI syntax, and must be treated
as such for all URI schemes. The argument is that it is (as it is in RFC
1730 if I am not mistaken) to be used as a fragment specifier. In the URL
syntax paper one can more definitely talk about what a fragment specifier
is, and how it is to be treated for URLs (if it is the fact that this is
something that _have_ to be treated exactly the same way for all URL schemes).

I.e. the syntax is one thing, and the "semantic interpretation" of the
octet is something different when found in a URI sequence (which as
mentioned in the character set thread started by Larry) is something
different (maybe) from the "character in the URI".

   Patrik

---

From: Larry Masinter <[email-masked]>
Date: Wed, 7 Jan 1998 00:03:46 PST

> different (maybe) from the "character in the URI".

If we just change the *title* of draft-fielding-uri-syntax-XX
and remove the word "Semantics", it might make things clearer.
The only normative part of the specification is the definition
of the syntactic processing. There's some general advice about
how schemes might define semantics, too, but they're not part
of what it's defining.

I should point out that the syntax (and any scheme-specific semantics)
are assigned to the character sequence, not to any octet sequence.
In fact, the mapping of character sequences to octet sequences is
part of the semantics that a scheme specifies. That's the reason
why some schemes might employ different encoding mechanisms than
%XX.

Larry

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 07 Jan 1998 16:12:14 +0100

>why some schemes might employ different encoding mechanisms than

I don't agree with this, but it might be because the overloaded use of the
word "character".

The way I interpret what you are saying is that a URI parser (yes, a URI
parser) should operate on the _characters_ in the URI string and not the
octets?

That means, that I should be able to use percent encoding of the fragment
identifier, and still have the fragment delimiter, which in turn means that
the encoding does not have any meaning at all.

I.e. what I am talking about, and I think we agree on, is that we have to
define "characters", and we also have to agree on what octets are valid on
various levels in the chain of parsing URIs. I see that we have four layers:

Client
    [BIG5]
  Maps between nativ charset to some known
  which is specified in the schema definition.
    [UNICODE]
URI string
    [UNICODE]
  This is mapped into whatever the translitteration
  string is defined to be according to the
  _URI_SYNTAX_ document.
    [UTF-8 encoded UNICODE]
Translitterated string
    [UTF-8 encoded UNICODE]
  Here we can do some %-encoding if needed.
    [String in "US-ASCII"]
URI sequence of bytes

The processes above are described in various documents, and I want
everything from the translitterated string and downwards to be described in
a URI syntax document, while what is above the translitterated string
should go in a URL/URN syntax document and various schema definition
documents.

When _I_ talk about characters, I talk about characters in the URI string,
while the URI syntax document when talking about the fragment delimiter '#'
as being forbidden in a URI, talks about the "Translitterated string". I.e.
semantics for schemes are on the URI string, while syntax and semantics for
URIs are on the tranlitterated string.

    Patrik

---

From: Michael Mealling <[email-masked]>
Date: Wed, 7 Jan 1998 11:15:45 -0500 (EST)

Larry Masinter said this:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> interpretation of the *meaning*, do you think we could get beyond

It would go along way to making me happy. I still prefer two (c) 
documents, though.

-MM

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 07 Jan 1998 08:57:23 -0800

>interpretation of the *meaning*, do you think we could get beyond

It depends on what would be removed.  I don't want to remove any
information which has been proven necessary for people implementing
parsers in URI-enabled applications.  That covers just about everything
in the current document, since we already went through 12 iterations
of removing things that were not needed and adding those that people
have requested.

If the URN group does not want fragments to be in the syntax, then
a URN is not a URI.  I don't think there is even a tiny bit of logic
to support the conclusion that a URN would not use fragments, but I
can't stop people from shooting themselves in the foot.

Stripping the URL specification such that it is as meaningless as the
URN specification is not an option --- we know what is and is not
generic syntax and semantics simply by looking at the parsers which
implement these things in current practice.  If a URN is not a URI,
then we should define the URL specification to represent the complete
scope of locators, and simply ignore URN.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 07 Jan 1998 09:35:17 -0800

>can be treated like "type 2" URLs.

I am inclined to tell those people to go out and implement a system
that behaves as such, and then standardize it.  Forcing such opinions
onto systems that are definitely not implemented that way
is inappropriate for a Draft Standard.

>documents, one for URIs giving the "type 1" rules and one giving

We can't do that.  A given protocol element MUST be defined according
to one and only one set of rules.  The "type 1" and "type 2" rules
that you mention are conflicting -- no system can implement both,
since they determine what parts of the protocol element represent
the URI and what parts represent a fragment.  A system of interrelated
protocol standards (like the Web) depends on a consistent syntax and
semantics for its identifiers, since they get moved from in-document
reference in one media type to a field in another protocol to a display
in a browser and onward to a napkin in a bar and somebody else's
document in perhaps an entirely different media type.

That means that either all systems implement "type 2" rules, or
"type 1" identifiers are not allowed in "type 2" systems except
when they do obey "type 2" rules.  Either way, what we need is a
specification of the "type 2" rules, since those are the rules that
need to be referenced by HTTP, HTML, and XML (and all of the other
URI-enabled protocols in current practice).

....Roy

---

From: Larry Masinter <[email-masked]>
Date: Wed, 7 Jan 1998 10:02:44 PST

This point is really hard to make, apparently, and the
current text fails to make it. I'd appreciate any suggestions
for how to word this to make it clearer.

> the encoding does not have any meaning at all.

No. The URI  b://a/%2Ec

contains the CHARACTERS "b", ":", "/", "/", "a", "/", "%", "2", "F", "c".

At this level, the "%", "2", and "F" are just characters. They should NOT
be decoded, scanned, parsed, or treated in any special way prior to parsing.
The mechanism by which the sequence "%", "2", "F" is turned into a single
octet MUST NOT be applied until AFTER the URI has been scanned.

If you have "b://a/%2Ec" in EBCDIC, or in UTF-16 (which uses double bytes
for representing sequences of characters), you should parse the URI
in the native encoding for the delimiters "/", "%", ":", etc., and then
take the remaining character sequences scheme=["b"], site=["a"],
path=["%2Fc"], and, based on the scheme, turn the remaining components
into octet sequences.

> I.e. what I am talking about, and I think we agree on, 

apparently not

>                                                    is that we have to
> various levels in the chain of parsing URIs.

Some of the levels don't operate on "octets", so that doesn't make
sense.

> I see that we have four layers:
> 
> Client
>     [BIG5]

I don't understand this layering, and don't think that "UNICODE"
is appropriate at these levels.

> The processes above are described in various documents,

Then you should give references, since the processes you've described
aren't familiar to me.

>                                          and I want
> a URI syntax document,

You get what you see, which is a description of the mapping at the
layer of the URI syntax, and a description of a common, frequent,
and useful encoding of octets by sequence of characters which is
common to many URI schemes.

>                 while what is above the translitterated string

Not all schemes will use the same encoding.

> URIs are on the tranlitterated string.

Patrik: a "character" is an abstract concept, as in an "octet". You're
free to talk about characters in the URI string, but we have to talk
about characters in multiple contexts. Given how difficult it has been
to arrive at the current terminology and framework, I don't want to
upset the rough consensus of the expert community in order to fit into
your way of conceptualizing this relationship. So: I don't accept your
proposal that this section be reworded to match your conceptualization.
If what's there isn't CLEAR, then I can try to improve it; if there's
some incompatbility with some other documents, we will have to resolve
that incompatibility, but if it's just that YOU think about it in a
different way, I hope you can find a way to see the world from a different
perspective.

Regards,

Larry

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 7 Jan 1998 15:37:09 -0500 (EST)

> and remove the word "Semantics", it might make things clearer.
[snip]
> interpretation of the *meaning*, do you think we could get beyond

It's not clear to me from what you've said whether you think that
changing just the name of the document would achieve this goal, or
if you think that there is material that would in that case be
removed from the document (to which Roy has already stated his
objections).

Before I'd say whether this works or not, I'd want to see more
specifically what you are proposing -- because I suspect that 
worldviews are sufficiently at odds that there isn't agreement
on what this document _should_ look like.

Leslie.

  "_Be_                                           Leslie Daigle
             where  you

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 07 Jan 1998 23:08:07 +0100

>different way, I hope you can find a way to see the world from a different

The problem that I saw was exactly that we have the concept of a
"character" in different contexts. _I_ know how this works (even though my
way of looking at things differ from others, and we should not argue about
those views) but there are others which don't know the difference between
the character you type in in a browser and the character which is in the
URI. I did get the question on the last IETF why the user have to type in
the '%' character in a URL when needed! I.e. no understanding on the
difference on what glyphs are visible in the user interface, and what
characters are in the URL is which is used by the software.

Well, I will stop here, as this should not disturb the other discussion,
which I am sorry for have interupted.

Sorry...

   Patrik