Subject: Re: NOT Re: [URN] URI documents -- "# fragment"
From: Leslie Daigle <[email-masked]>
To: "John C. Mallery" <[email-masked]>
Cc: Sam Sun <[email-masked]>, [email-masked], [email-masked]
Date: Thu, 29 Jan 1998 13:57:01 -0500 (EST)

To put this in a bit more context...

On Wed, 28 Jan 1998, John C. Mallery wrote:
> Fragment URNs are now live.
> 
> See bottom of http://www.pub.whitehouse.gov/
> 
> Nota Bene: the delimiter is $ per Ryan Moats suggestion.

This is fragments in a particular namespace, which has a more
constrained world-view than the general URN case (e.g., documents
have declared media types).

Leslie.

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

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

Date: Wed, 28 Jan 1998 00:27:02 -0500
To: "Sam Sun" <[email-masked]>
From: "John C. Mallery" <[email-masked]>
Subject: NOT Re: [URN] URI documents -- "# fragment"
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

Fragment URNs are now live.

See bottom of http://www.pub.whitehouse.gov/

Nota Bene: the delimiter is $ per Ryan Moats suggestion.

From: "Sam Sun" <[email-masked]>
To: "Foteos Macrides" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: [URN] URI documents -- "# fragment"
Date: Tue, 27 Jan 1998 10:29:58 -0500
Sender: [email-masked]
Reply-To: "Sam Sun" <[email-masked]>
From: Foteos Macrides <[email-masked]>

>The #fragment was specified as a way of providing instructions to a
>client via a URI-reference, is positional, and is not considered part
>of the URI.

I think it might help to address the terminology first.

If we don't call

http://www.ietf.org/filename.html#section

a URI or URL, what do we call it?  The draft
(http://ringer.etl.go.jp/net/ftp/internic/internet-drafts/draft-fielding-uri
-syntax-01.txt)
call it a URI-reference. But I think most people will call it a URI
(actually URL).

And the mere different between having "#..." or not  is that:

http://www.ietf.org/filename.html

      identifies the file 'filename.html' at 'www.ietf.org'.

http://www.ietf.org/filename.html

     identifies the section 'section' at 'www.ietf.org/filename.html'.

They are both used to location a (portion) of web resource by location.
And I don't see the benefit of defining the additional term 'URI-Reference'
vs 'URI' here.

Further, I think it would help if we address the question that whether the
generic URI parser (which handles URI-Reference, as in HTParse.c
in libwww) should handle the portion "#......" regardless of the URI
scheme or not.

While it makes sense for 'http' URL or 'ftp' URL to cut the "#..." off
at the client side, it's not so appropriate for other kind of URI
schemes (eg. mailto, telnet, ldap, ... ... ... ... ... ... and new ones
are keep coming :).

Regards,
Sam
[email-masked]

Date: Mon, 26 Jan 1998 22:29:00 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: Foteos Macrides <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] URI documents -- "# fragment"
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

>      smtp:[email-masked]#subject=Backward%20Compatibility

The revised 'mailto' scheme used ?, not #, to delimit client
side modifications of the basic locator.

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

From: Al Gilman <[email-masked]>
Subject: Re: [URN] URI documents -- "# fragment"
To: [email-masked] (Foteos Macrides)
Date: Mon, 26 Jan 1998 23:17:03 -0500 (EST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Al Gilman <[email-masked]>

to follow up on what Foteos Macrides said:

> 	It is positional for the URI syntax in the sense that
> it must be the right-most field in a URI-reference, and the URI,
> itself, is to the left of the delimiter.  

As distinguished from ;qualifier that can refine the parse tree
almost anywhere.

OK I get that.

Al

Date: Mon, 26 Jan 1998 18:44:31 -0500 (EST)
From: Foteos Macrides <[email-masked]>
Subject: Re: [URN] URI documents -- "# fragment"
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Foteos Macrides <[email-masked]>

Al Gilman <[email-masked]> wrote:
>to follow up on what John C. Mallery said:
>
>> Might be worth noting that #fragment is utterly bogus.  It is a
>> positional identifier and cannot be recycled for server-side
>> fragments because it has been consumed by legacy web
>> applications.
>
>I can't grok your claim.  The way I interpret current practice
>the 'fragment' is not positional at all but reference to a name
>in a namespace.  So the client positions the cursor at the start
>of the named item which is a text range in this kind of document.
>But the URL usage is namewise, not positionwise.

	It is positional for the URI syntax in the sense that
it must be the right-most field in a URI-reference, and the URI,
itself, is to the left of the delimiter.  You are thinking about
one type of fragment instruction which applies to text/html, but
there is another, for seeking a MAP element associated with a
client-side image map.  Nothing in the URL -> URI draft precludes
formulation of other instructions, and use of lists in the format:

	#name1=value1;name2=value2[;...]

although perhaps the fragment = *uric in Section 3 needs a statement
that '=' and ';' are reserved, homologous to that following the
query = *uric in Section 4.3.3.

	How about this:
	
	smtp:[email-masked]#subject=Backward%20Compatibility

Hmm... Is that fragment an instruction to the client, the server, or both?
Or how about this:

	smtp:;to=[email-masked];subject=Backward%20Compatibility

That's a URI, and maybe some useful instruction could be added via a
fragment to make it a URI-reference. :)

	In any case, a fragment need not be an instruction concerning an
HTML/XML/SGML NAME -- but the first thing a parser must do is separate it
from the URI in a URI-reference (and then further separate components of
the URI, or invoke some resolver).

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 [email-masked]         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Date: Mon, 26 Jan 1998 17:34:51 -0500
To: Larry Masinter <[email-masked]>
From: "John C. Mallery" <[email-masked]>
Subject: Re: [URN] URI documents -- "# fragment"
Cc: Leslie Daigle <[email-masked]>, Foteos Macrides <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

At 2:03 PM -0800 98-01-26, Larry Masinter wrote:
>I meant to post about this before; I think that "?" is the most
>appropriate delimeter for what John Mallery wants for PDIs, rather than
>"$", since it will be more likely processed correctly when dealing with
>relative references that might be contained within returned material.

No. URNs embedded in URLs will be improperly processed by legacy applications,
not to mention that it overloads the delimiter.

This is analogous to the problem with #.

>
>> Might be worth noting that #fragment is utterly bogus.
>
>It is totally worthless[sic] to attempt to note this.
>
>To put it in less bogus terms: Just because a widely deployed
>syntactic construct doesn't do what YOU want, it doesn't mean that
>it is "utterly bogus", no matter what school of hyperbole you adhere to.

It remains utterly bogus to include it in the URI spec; it's fine in html/http (I use it all the time).

I just get tired of endless thrashing.

Date: Mon, 26 Jan 1998 17:11:33 -0500 (EST)
From: Foteos Macrides <[email-masked]>
Subject: Re: [URN] URI documents -- "# fragment"
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Foteos Macrides <[email-masked]>

"John C. Mallery" <[email-masked]> wrote:
>Might be worth noting that #fragment is utterly bogus.  It is a positional
>identifier and cannot be recycled for server-side fragments because it has
>been consumed by legacy web applications.

	I perhaps should not have included that paragraph under
circumstances in which I have only occassional access to this account
and cannot participate in an extended discussion about the matter,
but since I'm logged in again now...

	I do not see how these references to "bogus" and "legacy web
applications" serve any useful purpose in the "evolution" of the Web.
The #fragment was specified as a way of providing instructions to a
client via a URI-reference, is positional, and is not considered part
of the URI.  I realize that there are only so many US-ASCII characters
which can be used as delims in a platform-independent manner, and most
if not all of them are "taken" for something or other at this point.
If you which to support server-side instructions, then it presumeably
must be via something to the left of any crosshash in an overall
URI-reference.  The '?' and '@' in URLs in effect delimit instructions
to the server, and perhaps could be used for instructions sets in URNs.

>The only relevance for URIs is that applications expecting to move an
>identifier through HTTP URLs (e.g, URN resolution) must quote #. This
                    ????
>is why PDI switched from # to $.

	Fragment instructions apply to media types (presently defined
and widely implemented fragment instructions apply to text/html), not
to schemes, i.e., not specifically to HTTP.

>It is unwise to reify legacy design decisions in all possible future
>identifiers.  Such over encumbering of URIs reduces degrees of freedoms
>needed for evolution and shortens the longevity of any URI framework,
>ie hastening the time when all identifiers must be discarded and one
>must start from scratch.

	The concern is that existing, interoperable implementations
are not broken needlessly in new IETF specs.  Terminology such as
"reify legacy design decisions" is stone throwing, and that often
leads to breakage.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 [email-masked]         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

From: Al Gilman <[email-masked]>
Subject: Re: [URN] URI documents -- "# fragment"
To: [email-masked] (John C. Mallery)
Date: Mon, 26 Jan 1998 17:25:51 -0500 (EST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Al Gilman <[email-masked]>

to follow up on what John C. Mallery said:

> Might be worth noting that #fragment is utterly bogus.  It is a
> positional identifier and cannot be recycled for server-side
> fragments because it has been consumed by legacy web
> applications.

I can't grok your claim.  The way I interpret current practice
the 'fragment' is not positional at all but reference to a name
in a namespace.  So the client positions the cursor at the start
of the named item which is a text range in this kind of document.
But the URL usage is namewise, not positionwise.

Can you elaborate?

Al Gilman

Date: Mon, 26 Jan 1998 14:03:24 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: "John C. Mallery" <[email-masked]>
CC: Leslie Daigle <[email-masked]>, Foteos Macrides <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [URN] URI documents -- "# fragment"
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

I meant to post about this before; I think that "?" is the most
appropriate delimeter for what John Mallery wants for PDIs, rather than
"$", since it will be more likely processed correctly when dealing with
relative references that might be contained within returned material.

> Might be worth noting that #fragment is utterly bogus.

It is totally worthless[sic] to attempt to note this.

To put it in less bogus terms: Just because a widely deployed
syntactic construct doesn't do what YOU want, it doesn't mean that
it is "utterly bogus", no matter what school of hyperbole you adhere to.

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

Date: Mon, 26 Jan 1998 14:30:25 -0500
To: Leslie Daigle <[email-masked]>
From: "John C. Mallery" <[email-masked]>
Subject: Re: [URN] URI documents -- "# fragment"
Cc: Foteos Macrides <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

Might be worth noting that #fragment is utterly bogus.  It is a positional identifier
and cannot be recycled for server-side fragments because it has been consumed by legacy web applications.

The only relevance for URIs is that applications expecting to move an identifier through
HTTP URLs (e.g, URN resolution) must quote #. This is why PDI switched from # to $.

It is unwise to reify legacy design decisions in all possible future identifiers.
Such over encumbering of URIs reduces degrees of freedoms needed for evolution and 
shortens the longevity of any URI framework, ie hastening the time when all identifiers
must be discarded and one must start from scratch.

At 12:27 PM -0500 98-01-26, Leslie Daigle wrote:
>On Fri, 23 Jan 1998, Foteos Macrides wrote:
>> 
>> 	Note also that RFC 1630 had the title "Universal Resource
>> Identifiers in WWW", i.e., was about URIs, not just URLs, and
>> provides for fragments in URIs.  I agree that if URNs are specified
>> such that they could not accept fragments as "instructions to the
>> client", then they should not be considered URIs, and that would
>> be unacceptible (so don't impose that restriction on URNs :).
>
>URIs as a whole have evolved considerably since RFC1630 -- not the least
>of which is the fact that they are now "Uniform" and not "Universal"
>Resource Identifiers.  
>
>My point is this:  be careful of claiming that anything that doesn't
>fit with the earliest specifications is not valid; that prevents evolution
>of design.
>
>Leslie.
>
>----------------------------------------------------------------------------
>
>  "_Be_                                           Leslie Daigle
>             where  you                           
>                          _are_."                 Bunyip Information Systems
>                                                  (514) 875-8611
>                      -- ThinkingCat              [email-masked]
>----------------------------------------------------------------------------

Date: Mon, 26 Jan 1998 15:17:55 -0500 (EST)
From: Foteos Macrides <[email-masked]>
Subject: Re: [URN] URI documents -- "# fragment"
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Foteos Macrides <[email-masked]>

Leslie Daigle <[email-masked]> wrote:
>On Fri, 23 Jan 1998, Foteos Macrides wrote:
>> 
>> 	Note also that RFC 1630 had the title "Universal Resource
>> Identifiers in WWW", i.e., was about URIs, not just URLs, and
>> provides for fragments in URIs.  I agree that if URNs are specified
>> such that they could not accept fragments as "instructions to the
>> client", then they should not be considered URIs, and that would
>> be unacceptible (so don't impose that restriction on URNs :).
>
>URIs as a whole have evolved considerably since RFC1630 -- not the least
>of which is the fact that they are now "Uniform" and not "Universal"
>Resource Identifiers.  
>
>My point is this:  be careful of claiming that anything that doesn't
>fit with the earliest specifications is not valid; that prevents evolution
>of design.

	I much prefer "Uniform" over "Universal" (URIs won't also
be universal until the i18n provisions are fully worked out and
incorporated :).

	However, to be uniform, I still think URIs must be parsable for
fragment instructions which apply to media types, not to schemes, and
regardless of whether particular schemes might actually have fragments,
i.e., any crosshatch which is not a fragment delimiter should be escaped.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 [email-masked]         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Date: Mon, 26 Jan 1998 12:27:07 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: Foteos Macrides <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [URN] URI documents -- "# fragment"
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Fri, 23 Jan 1998, Foteos Macrides wrote:
> 
> 	Note also that RFC 1630 had the title "Universal Resource
> Identifiers in WWW", i.e., was about URIs, not just URLs, and
> provides for fragments in URIs.  I agree that if URNs are specified
> such that they could not accept fragments as "instructions to the
> client", then they should not be considered URIs, and that would
> be unacceptible (so don't impose that restriction on URNs :).

URIs as a whole have evolved considerably since RFC1630 -- not the least
of which is the fact that they are now "Uniform" and not "Universal"
Resource Identifiers.  

My point is this:  be careful of claiming that anything that doesn't
fit with the earliest specifications is not valid; that prevents evolution
of design.

Leslie.

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

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

Date: Fri, 23 Jan 1998 19:08:13 -0500 (EST)
From: Foteos Macrides <[email-masked]>
Subject: Re: [URN] URI documents -- "# fragment"
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Foteos Macrides <[email-masked]>

"Roy T. Fielding" <[email-masked]> wrote:
>[...]
>Also in section 3:
>
>      fragment      = *uric
>
>which excludes "#" and the other delims from appearing within the fragment.

	Duh...  OK (time to log out and go traveling :).

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 [email-masked]         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

To: Foteos Macrides <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [URN] URI documents -- "# fragment" 
Date: Fri, 23 Jan 1998 14:58:03 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

>However, the term "URI-reference" is not defined until Section 3,
>which has:
>
>      URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
>
>and a "plain word explanation" that the fragment is NOT part of the
>"URI".  People who are not dummies or fuddy-duddies have argued that
>characters allowable in the fragment string (to the right of the '#'
>delimiter) are not clearly specified in the URL -> URI drafts
>(because they specify what can be in URIs (URLs), and not also in
>URI-references (URL-references).

Also in section 3:

      fragment      = *uric

which excludes "#" and the other delims from appearing within the fragment.
People who argue otherwise have not read the specification.  Since this
is almost identical to the definitions in RFCs 1670 and 1808, people who
say it hasn't been clearly specified in the URL -> URI drafts are
just plain wrong.  There is no need for more clarification.

This isn't going to stop people from producing invalid URI.  What to
do when you encounter an invalid URI depends on the application type,
so we don't specify it.

....Roy

Date: Fri, 23 Jan 1998 17:22:27 -0500 (EST)
From: Foteos Macrides <[email-masked]>
Subject: Re: [URN] URI documents -- "# fragment" (2)
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Foteos Macrides <[email-masked]>

"Sam X. Sun" <[email-masked]> wrote:
>[...]
>The way current URI parser cuts off '#fragment' regardless of the 
>URI scheme makes it not very user friendly, because if user A 
>has his userid or password containing '#' character, he will have to 
>use '%22' when he reach his ftp server from web browser, even 
>though '#fragment' doesn't make sense in 'ftp' URL. Similar issue 
>holds true for 'telnet', 'mailto', as well. Another example is when we 
>are working with publishers, there are existing naming schemes, 
>like SICI, uses '#' extensively, and it's just not very practical to 
>enforce every SICI names to be hex encoded.

	That's incorrect, which you can verify with any deployed
browser.  Try these two URL-references:

http://www.slcc.edu/lynx/release/lynx2-7-2/lynx_help/lynx_url_support.html#cso
ftp://www.slcc.edu/pub/lynx/release/lynx2-7-2/lynx_help/lynx_url_support.html#cso

which will get you the same document via http versus ftp, and in both
cases have it positioned via the #cso fragment instruction to your
browser.  And if your browser were not to split off the #cso for the
ftp request, it would fail.

	In the case of an ftp URL which has authinfo with a userid or
password that includes a '#', the browsers will unescape the %22 before
sending it to the ftp server.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 [email-masked]         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Date: Fri, 23 Jan 1998 16:17:39 -0500 (EST)
From: Foteos Macrides <[email-masked]>
Subject: Re: [URN] URI documents -- "# fragment"
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Foteos Macrides <[email-masked]>

"Roy T. Fielding" <[email-masked]> wrote:
>[...] there is already an explicit requirement in the URI
>syntax that there be at most one "#" in a URI reference.  That is
                                           ?????????????
>completely unambiguous and not open to any misunderstanding.
					   
	I must disagree with you that it is completely unambiguous
and not open to any misunderstanding.  Section 2 ("URI Characters and
Escape Sequences") describes the unescaped character restrictions
for "URIs" ("URLs" in the preceding drafts).  It's Section 2.4.3
places crosshatch ('#') in the "delims" group of "Excluded US-ASCII
Characters".  That does make it completely clear that one cannot be
present unescaped in the authinfo field of an ftp or telnet URL, or
anywhere else in an actual URI, to the left of a fragment delimiter.
However, the term "URI-reference" is not defined until Section 3,
which has:

      URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

and a "plain word explanation" that the fragment is NOT part of the
"URI".  People who are not dummies or fuddy-duddies have argued that
characters allowable in the fragment string (to the right of the '#'
delimiter) are not clearly specified in the URL -> URI drafts
(because they specify what can be in URIs (URLs), and not also in
URI-references (URL-references).  They have also argued that this
is a GOOD THING.  The characters that are allowed/disallowed in
fragments which currently have application conventions are governed
by the HTML/SGML restictions on NAME and ID attribute values.   They
thus cannot have a crosshatch, nor any hex escaped characters
(because '%' is also disallowed in those attribute values).  But
other fragment-handling conventions might be developed as
"instructions to the client", which need not be governed by the
HTML/SGML restrictions on NAME and ID attribute values!!!!

	I therefore feel compelled to insist that a clear statement
of what unescaped characters are allowed in a fragment string be added
in Section 3, and personally feel that another crosshash must be
excluded -- for backward compatibility, because all CERN/W3C libwww
based (except Lynx as of v2.7) and CERN libwww heritage browsers
(including Netscape) parse from right-to-left for a fragment delimiter,
and are tripped up if an unescaped crosshatch which is not the actual
delimiter is present in the fragment string.  To my knowledge, all
deployed browsers first split off the fragment, before actually
parsing the "actual URI".  US-ASCII control character and space
also should be excluded, for obvious reasons, and I have no objection
to excluding others as well, as from "actual URIs" (if that's what
you intend, and think it already does :), but it's debatable whether
exclusion of others is really necessary.

>Perhaps an addition to the "Differences from RFC 1808" section would
>be more appropriate?

	RFC 1808 specified left-to-right parsing, whereas the current
URI draft simply uses left-to-right parsing for its "example parser"
in the Appendix, so that's a change, I guess, but an addition about
that, per se, would not address the larger issue I'm raising.  It
needs to be made clear in Section 3 (or Section 2 must be modified
to make clear that it applies to URI-references, and not just URIs).

	Note also that RFC 1630 had the title "Universal Resource
Identifiers in WWW", i.e., was about URIs, not just URLs, and
provides for fragments in URIs.  I agree that if URNs are specified
such that they could not accept fragments as "instructions to the
client", then they should not be considered URIs, and that would
be unacceptible (so don't impose that restriction on URNs :).

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 [email-masked]         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

From: "Sam X. Sun" <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: [URN] URI documents -- "# fragment" (2)
Date: Fri, 23 Jan 1998 01:46:02 -0500
Sender: [email-masked]
Reply-To: "Sam X. Sun" <[email-masked]>

[modified and reposted, since it bounced last week,]

Hello, Roy.

> >The point I wanted to show you is that "# fragment" doesn't work by
> >itself. It's actually worked as a relative URL. And the generic URI 
> >parser may never get the "# fragment" alone. (ie, in your 
> >example, <a href="#foo">.... is a relative URL, not just a "#
fragment".)
> 
> I seem to be having a hard time getting this point across.  The generic
> URI parser *is* the thing that takes a string and does the handling
> and interpretation needed to
> 
>    1) determine whether it is absolute or relative
>    2) convert it to absolute form if needed
>    3) give the resulting URI to the scheme-specific handler
> 
> There is no purpose for a generic URI syntax beyond that.  Likewise,
> it is only that syntax which is needed by other protocols as a
> Draft Standard reference.
> 

I believe we are in agrement here...

> >On the other hand, I don't see any usage of "# fragment" for "mailto" or
> >"ldap" URLs as defined in the HTML document. So, if "# fragment" is not
> >needed for all of the URI schemes, I wonder if we could drop it from the
> >overall URI definition? 
> 
> Because you cannot do so and produce an interoperable parser.
> 

I doubt if I understand the whole issue here. But would you think the
following would be ok for the generic URI parser, which basically allow
"#...." to be treated by individual URI scheme handlers accordingly:

1) determine whether it is absolute or relative

2) convert it to absolute form if needed

3) give the resulting URI entirely (ie, including the "#......." trailing),
to the corresponding URI scheme-specific handler, which may then decide
whether to use "#fragment" or not.

> >Lastly, I'm wondering if the "# fragment" requirement is inherited from 
> >the earlier URL standards when there're few URL schemes defined. If 
> >we drop the requirement of "# fragment" from URI as a whole, it can 
> >still be defined by those URL schemes that need it, in their respective 
> >RFCs. And the only thing I see broken is that the generic URI parser 
> >can not catch the "#fragment", and decide what to do, which is not 
> >happening and I think really doesn't have to.
> 
> The "#fragment" is removed from the URI whether the URI is defined
> to use it or not.  

Why it has to do this?

> Other applications allow the user to pass unknown URI schemes
>  to a proxy for resolution, and on those systems you will find that 
>  the "#fragment" is stripped before being sent to the proxy.  

Yes, indeed. I wound conclude then, under current situation, there are
browsers that pass the URI with the '#fragment' to the URI scheme-specific
handlers, which then decide what to do with it. And there are also browsers
that strip off '#fragment' regardless of the URI scheme, before passing the
URI to the scheme-specific handlers.

> It is therefore IMPOSSIBLE for "#" to be used as anything else in the
> URI syntax and still retain interoperability between new and deployed
> systems.
> 
> There is very little room for discussion of what is being defined by
> the specification and in the syntax itself, since that is governed by
> the most interoperable subset of what is implemented.  

I think you are saying that this is a backward compatability issue then.

The question would then be: When we define a standard, do we have to 
make sure it works for all the current implementations (hense to take 
the subset), or should we define the standard with a more emphysis on 
the user usability and future extensibility? I understand the former is 
very important, and break it will affect the usability. But the way major 
browsers making their new releases makes me think that the later 
might weight more, since any software can  be patched or updated 
relatively easy, but the standard tends to stay longer and have a far 
more impact to the future.

The way current URI parser cuts off '#fragment' regardless of the 
URI scheme makes it not very user friendly, because if user A 
has his userid or password containing '#' character, he will have to 
use '%22' when he reach his ftp server from web browser, even 
though '#fragment' doesn't make sense in 'ftp' URL. Similar issue 
holds true for 'telnet', 'mailto', as well. Another example is when we 
are working with publishers, there are existing naming schemes, 
like SICI, uses '#' extensively, and it's just not very practical to 
enforce every SICI names to be hex encoded.

An example that URI parser cuts off '#fragment' regardless of the URI 
scheme makes it less extensible is pointed out by John earlier. 
That is, when a new scheme like 'pdi' is defined, it can not use '#' to 
define its own fragment and have it processed differently from "http" 
URI, simply because URI parser assumes the 'http' behavior and 
chops the '#fragment' off, and didn't parse the '#fragment' to the server.

In summary, all I'm suggesting is that '#fragment' should be processed 
by individual scheme parser, not the URI parser. In terms of libwww, it 
should be handled by individual 'plug-in' module (eg, http), but not in the

Core portion (ie. HTParse.c).

PS.
I assume that we are all in agreement that each URI scheme can define
by itself whether to use or do anything about '#fragment' or not...

> The only question still to be determined is whether we call these
> things URI or URL, and thus whether or not a URN should be referred 
> to as a URI or a URL when it is used by HTTP, HTML, XML, etc.

I'm also having some questions on these issues too. But I think it would
help me a lot to address the '#fragment' question first, and make sure I'm
on the same boat as you are......

Regards,
Sam

To: [email-masked], [email-masked]
Subject: Re: [URN] URI documents -- "# fragment" 
Date: Thu, 22 Jan 1998 21:33:57 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

[reposted, since the uri lists were down last week]

Sam was saying:
>The point I wanted to show you is that "# fragment" doesn't work by itself.
>It's actually worked as a relative URL. And the generic URI parser may never
>get the "# fragment" alone. (ie, in your example, the <a href="#foo"> ... is
>a relative URL, not just a "# fragment".)

I seem to be having a hard time getting this point across.  The generic
URI parser *is* the thing that takes a string and does the handling
and interpretation needed to

   1) determine whether it is absolute or relative
   2) convert it to absolute form if needed
   3) give the resulting URI to the scheme-specific handler

There is no purpose for a generic URI syntax beyond that.  Likewise,
it is only that syntax which is needed by other protocols as a
Draft Standard reference.

>On the other hand, I don't see any usage of "# fragment" for "mailto" or
>"ldap" URLs as defined in the HTML document. So, if "# fragment" is not
>needed for all of the URI schemes, I wonder if we could drop it from the
>overall URI definition?

Because you cannot do so and produce an interoperable parser.

>Lastly, I'm wondering if the "# fragment" requirement is inherited from the
>earlier URL standards when there're few URL schemes defined. If we drop the
>requirement of "# fragment" from URI as a whole, it can still be defined by
>those URL schemes that need it, in their respective RFCs. And the only thing
>I see broken is that the generic URI parser can not catch the "#fragment",
>and decide what to do, which is not happening and I think really doesn't
>have to.

The "#fragment" is removed from the URI whether the URI is defined
to use it or not.  I cannot show you this using Netscape Navigator
because its parser is the only one I know of which is so hopelessly
broken that they use a fixed set of scheme names.  Other applications
allow the user to pass unknown URI schemes to a proxy for resolution,
and on those systems you will find that the "#fragment" is stripped
before being sent to the proxy.  It is therefore IMPOSSIBLE for "#"
to be used as anything else in the URI syntax and still retain
interoperability between new and deployed systems.

There is very little room for discussion of what is being defined by
the specification and in the syntax itself, since that is governed by
the most interoperable subset of what is implemented.  The only question
still to be determined is whether we call these things URI or URL,
and thus whether or not a URN should be referred to as a URI or a URL
when it is used by HTTP, HTML, XML, etc.

.....Roy

To: [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents 
Date: Thu, 22 Jan 1998 21:31:18 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

[reposted, since it bounced last week]

Foteos remarked:
>	I do think, however, that the current draft needs to clarify
>whether more than one unescaped hash ('#') can be present.

I don't understand why.  The current draft only allows a single
unescaped hash to ever occur in a URI-reference --- it is not allowed
in any other component.  That is completely unambiguous, so you can
parse it from any direction you like.  Note that the algorithm
presented in the appendix is left-to-right.

....Roy

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: [URN] Document Action: Architectural Principles of Uniform Resource Name Resolution to Informational
Date: Thu, 22 Jan 1998 08:09:21 -0500
Sender: [email-masked]
Reply-To: The IESG <[email-masked]>

The IESG has approved publication of Architectural Principles of
Uniform Resource Name Resolution <draft-ietf-urn-req-frame-04.txt> as
an Informational RFC.  This document is the product of the Uniform
Resource Names Working Group.  The IESG contact person Harald
Alvestrand and Keith Moore.

From: "David G. Durand" <[email-masked]>
Date: Wed, 21 Jan 1998 16:31:54 -0500
To: [email-masked], [email-masked]
Subject: Re: [URN] [Fwd: "U stands for Uniform"]
Sender: [email-masked]
Reply-To: "David G. Durand" <[email-masked]>

On Jan 21, 11:37am, Larry Masinter wrote:
> Something is "appropriate" if it has a defined meaning. If it's not defined,
> then you shouldn't use it. If it is defined, then you can. Whether or not it
> is defined is not an issue for the syntax, it's an issue for the semantics.
> (We should take the word "semantics" out of the title of (b), since
> the body of (b) talks entirely about syntax. I am not proposing any
> other change to (b) than to change the title.)

This seems quite good. URIs must (practically speaking) have the current rules
for "/", "?", "#", etc. because those rules are already embedded in our
software and standards. This does not mean, as you point out, that _every_ URI
must use these features. It cannot use _those characters_ except in the ways
that they are already used.

>.....

> It's *important* that all URI processing software be assured that the URI
> processing software knows that it doesn't have to first look up the scheme
> before it does syntactic processing of "#", "?" and "/". We have to make
> it CLEAR that those syntactic elements are completely scheme independent,
> and the processing of them can be independent of whether the scheme is really
> "urn" which has different rules of semantics.

Right. URNs will be deployed much more readily if they fit in the same
syntactic slots where URLs do currently. This is more important than an "ideal"
syntax for URNs (which may look uglier when special characters need to be
eascaped).

> Hiding the distinction by having two documents, one of which doesn't even
> mention those elements would be WRONG.

Yes.

A good set of arguments as well. Let's not delay URNs just because unification
with URLs may give us syntactic options we can outlaw later.

And, as I said before, any URN that _can_ be resolved to an XML resource,
_should_ be usable with an XML fragment identifier. XLL (XML linking)
essentially depends on this. We even want to define the meaning of query
strings for XML documents, because we want to have a standard for server-side
fragment distribution.

Of course, some namespaces can't necessarily use any of these things. In
particular this is true for namespaces that aren't resolvable to data, like
many cataloging and metadata related URNs, e.g. for authors, artists, archival
sites, etc.

If a URN namespace definition doesn't define a meaning for features like
hierarchy and fragment-IDs, then they would only be legal if another standard
(with reason, presumably) did define such behaviour.

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

Date: Wed, 21 Jan 1998 11:37:09 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: [email-masked], [email-masked]
Subject: [URN] [Fwd: "U stands for Uniform"]
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

This is a multi-part message in MIME format.
--------------E8B5CCDEF34B1DD6DF568114
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I couldn't understand why I didn't have any responses to this, but
perhaps mail isn't getting through?

Larry
-- 
http://www.parc.xerox.com/masinter
--------------E8B5CCDEF34B1DD6DF568114
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Message-ID: <[email-masked]>
Date: Tue, 13 Jan 1998 20:21:26 -0800
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: [email-masked], [email-masked]
Subject: "U stands for Uniform"
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I sent this privately, but I suppose it should go onto the working
group(s) mailing lists. After reconsideration, I am very strongly
in favor of moving forward with draft-fielding-uri-syntax (b), because:

U stands for Uniform.
   Two documents are Not Uniform: they're different!
   Uniform implies one document, one syntax.

If you want multiple documents, you want non-Uniform Resource
Identifiers, because you want different syntax definitions
for different kinds of things.

I believe that (b), complete with /, #, and  ?, is the best explanation
of scheme-independent URI behavior.

Patrik wrote:

> Leslie, I and some others want to cut "higher"
> up in the inheritance tree of syntax structure, so the URL specific things
> which are not (so far) part of URNs are out of the URI syntax document.

The generic URI document discusses some common syntactic elements that
are (or should be) processed by URI-handling systems independent of whether
those URIs are URLs or URNs or URZs. Those generic elements include "/", "#",
and "?". The generic elements may or may not be appropriate with some schemes,
and may or may not be appropriate for URNs, which are designated by introducing
them with the "urn" scheme. For "mailto", "#" is inappropriate, but "?" is
useful. For "mid", they're all inappropriate. For "data:", "#" might be
appropriate but not "/". And  for "urn", the appropriateness of "/"  "#",
and "?" are yet to be determined by the URN committee. Because they're yet
to be determined doesn't mean they're out of scope.

Something is "appropriate" if it has a defined meaning. If it's not defined,
then you shouldn't use it. If it is defined, then you can. Whether or not it
is defined is not an issue for the syntax, it's an issue for the semantics.
(We should take the word "semantics" out of the title of (b), since
the body of (b) talks entirely about syntax. I am not proposing any
other change to (b) than to change the title.)

If we need to add some wording to (b) to make it completely clear, OK.
It must be absolutely the case that the URN document gets to say whether
or not "#", "/", and "?" are appropriate for URNs, even though those
elements are defined in the generic URI document.
This is just the same, the "mailto" document should say whether or not and
how those elements work with the "vix" scheme; the "data" document should
define whether or not "#", "?", and "/" work for the data scheme.

I don't believe that (b) interferes with the URN committee's ability
to define URNs within the space of URIs, or the ability of the URN committee
to define a new kind of syntactic element which doesn't have the restrictions
of the current URI syntax (as long as we don't call that new thing a URI;
let's call it a EURI or XURI or whatever.) We're not constraining or restricting
development of new kinds of identifiers, we're just letting software developers
have standard specifications that they can be assured won't change out from
under them, and basing that standard on current interoperable implementations.

It's *important* that all URI processing software be assured that the URI
processing software knows that it doesn't have to first look up the scheme
before it does syntactic processing of "#", "?" and "/". We have to make
it CLEAR that those syntactic elements are completely scheme independent,
and the processing of them can be independent of whether the scheme is really
"urn" which has different rules of semantics.

Hiding the distinction by having two documents, one of which doesn't even
mention those elements would be WRONG.

Regards,

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

--------------E8B5CCDEF34B1DD6DF568114--

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: [URN] Document Action: Architectural Principles of Uniform Resource Name Resolution to Informational
Date: Tue, 20 Jan 1998 13:58:32 -0500
Sender: [email-masked]
Reply-To: The IESG <[email-masked]>

The IESG has approved publication of Architectural Principles of
Uniform Resource Name Resolution <draft-ietf-urn-req-frame-04.txt> as
an Informational RFC.  This document is the product of the Uniform
Resource Names Working Group.  The IESG contact person Harald
Alvestrand and Keith Moore.

From: "Sam Sun" <[email-masked]>
To: "Dan Connolly" <[email-masked]>, "Roy T. Fielding" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: [URN] URI documents -- "# fragment"
Date: Thu, 8 Jan 1998 16:57:39 -0500
Sender: [email-masked]
Reply-To: "Sam Sun" <[email-masked]>

>> > Sam Sun wrote:
>> > > In the case of URL, The " [ "#" fragment ] " is only used or useful
by some
>> > > URL schemes. So my question is: is it acceptable to say that the
fragment
>> > > is scheme dependent, and don't bring it up in the URI definition?
>>
>> Dan Said:
>> > No; that is, to say that is not consistent with current
>> > implementations, and I would find it unacceptable.
>>
>> The current implementation (eg. Netscape browser) append the "#fragment"
to
>> whatever the base URI is. I don't quite understand on where it would be
inconsistent?
>
>Uh... you said it yourself: "whatever the base URI is" regardless
>of scheme.
>

The point I wanted to show you is that "# fragment" doesn't work by itself.
It's actually worked as a relative URL. And the generic URI parser may never
get the "# fragment" alone. (ie, in your example, the <a href="#foo"> ... is
a relative URL, not just a "# fragment".)

On the other hand, I don't see any usage of "# fragment" for "mailto" or
"ldap" URLs as defined in the HTML document. So, if "# fragment" is not
needed for all of the URI schemes, I wonder if we could drop it from the
overall URI definition?

[ ......lots of cutting.......]
>> In fact, using %25 to replace the '#' character will fail.
>
>That seems like a bug to me. But I suppose Draft Standard
>is the time to describe what happens rather than prescribe
>something else.
[ ......lots of cutting.......]

To me, there are two ways to look at whether it's a bug or not.

>From the existing standard point of view, it could be a bug, if the standard
spelled it out explicitly. But from the user's point of view, it's a nice
feature. (I feel that hex encoding can be very annoying to the user.) But if
the URI Syntax is to become a new standard, maybe we can loose it a little
bit so that new URI schemes can be defined for different kinds of user need.

Lastly, I'm wondering if the "# fragment" requirement is inherited from the
earlier URL standards when there're few URL schemes defined. If we drop the
requirement of "# fragment" from URI as a whole, it can still be defined by
those URL schemes that need it, in their respective RFCs. And the only thing
I see broken is that the generic URI parser can not catch the "#fragment",
and decide what to do, which is not happening and I think really doesn't
have to.

Regards,
Sam

Date: Thu, 08 Jan 1998 03:07:03 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium (http://www.w3.org/)
To: "Sam X. Sun" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [URN] URI documents -- "# fragment"
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Sam X. Sun wrote:
> 
> > Sam Sun wrote:
> > > In the case of URL, The " [ "#" fragment ] " is only used or useful by
> some
> > > URL schemes. So my question is: is it acceptable to say that the
> fragment
> > > is scheme dependent, and don't bring it up in the URI definition?
> 
> Dan Said:
> >
> > No; that is, to say that is not consistent with current
> > implementations, and I would find it unacceptable.
> 
> The current implementation (eg. Netscape browser) append the "#fragment" to
> whatever
> the base URI is. I don't quite understand on where it would be
> inconsistent?

Uh... you said it yourself: "whatever the base URI is" regardless
of scheme.

Anyway... you report some interesting test results...

> Here is an example which I think doesn't honor the current '#' URI syntax:
> 
> If I define my password as "password_with_#_character", and use "ftp" URL:
> 
> ftp://my_user_id:password_with_#_character@myhost/my_file_path
> 
> Netscape browser implementation will pass the entire password (with #
> character in it) to the server, instead of sending only
> "ftp://user_id:password_with_" to the server.

Hmm... That's certainly different from what Roy's spec[1]
describes.

[1]
http://www.ics.uci.edu/~fielding/url/draft-fielding-uri-syntax-00.txt

According to the regexp in the spec, it parses as:

connolly@beach ../connolly[1005] perl uri.pl 
ftp://my_user_id:password_with_#_character@myhost/my_file_path
[ftp:] [ftp] [//my_user_id:password_with_] [my_user_id:password_with_]
[] [] [] [#_character@myhost/my_file_path]
[_character@myhost/my_file_path]

where uri.pl=
while(<>){
m,^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?,;
print "[$1] [$2] [$3] [$4] [$5] [$6] [$7] [$8] [$9]\n";
}

It's also different from the original implementation:

-------
http://www.w3.org/Library/src/HTParse.c

    /* Look for fragment identifier */
    if ((p = strchr(name, '#')) != NULL) {
	*p++ = '\0';
	parts->fragment = p;
    }
-------

> In fact, using %25 to replace
> the '#' character will fail.

That seems like a bug to me. But I suppose Draft Standard
is the time to describe what happens rather than prescribe
something else.

Hmm... the ftp URL spec[2] doesn't say that passwords
get %xx encoded. Seems to me it should; else there's
no way to express '/' in a password. I suppose that's
not a fatal limitation...

[2] http://ds.internic.net/internet-drafts/draft-casey-url-ftp-00.txt

> Dan Said:
> > For example, consider:
> >
> >       <p>...<a href="#foo">tail</a>
> >
> >       ...
> >
> >       <p><a name="foo">head</a>
> >
> > I can tell you where the link from tail goes (i.e. to head)
> > without knowing what URI scheme was used to access the document. So
> > can lots of implemented web clients (and maybe even some servers).
> >
> 
> The example will fail from the current Netscape implementation if no BASE
> URI is defined.

Wow... we worked really hard on this part of the HTML 2.0
spec:

========
Network Working Group                                    T. Berners-Lee
Request for Comments: 1866                                      MIT/W3C
Category: Standards Track                                   D. Connolly
http://www.w3.org/MarkUp/html-spec/html-spec_7.html#SEC7.4

Fragment Identifiers

Any characters following a `#' character in a hypertext address
constitute a fragment identifier. In particular, an address
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^
of the form `#fragment' refers to an anchor in the same document. 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
========

But I guess rules were made to be broken. :-{

> (Refer the following URL for an example:
> http://ssun.cnri.reston.va.us/ietf/uri/nobase.htm and
> http://ssun.cnri.reston.va.us/ietf/uri/fragment.htm).

nobase.htm is illegal, per

=========
http://www.w3.org/MarkUp/html-spec/html-spec_5.html#SEC5.2.2

The optional BASE element provides a base address for interpreting
relative URLs when the document is read out of context (see section
Hyperlinks). The value of the HREF attribute must be an absolute URI. 

=========

so the behaviour of HTML user agents is unspecified.

> Regards,

Interesting stuff.

-- 
Dan
http://www.w3.org/People/Connolly/

Date: Wed, 7 Jan 1998 23:09 -0500
From: "John C. Mallery" <[email-masked]>
Subject: [URN] URI documents
To: [email-masked]
Comments: Posted from 128.52.39.15 via CL-HTTP HyperArchive at http://wilson.ai.mit.edu/archives/urn-wg.html
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

>Sam Sun wrote:
>> In the case of URL, The " [ "#" fragment ] " is only used or useful by some
>> URL schemes. So my question is: is it acceptable to say that the fragment
>> is scheme dependent, and don't bring it up in the URI definition?
>
>No; that is, to say that is not consistent with current
>implementations, and I would find it unacceptable.
>For example, consider:
>
>‰<p>...<a href="#foo">tail</a>
>
>‰...
>
>‰<p><a name="foo">head</a>
>
>I can tell you where the link from tail goes (i.e. to head)
>without knowing what URI scheme was used to access the document. So
>can lots of implemented web clients (and maybe even some servers).
>
>
>-- 
>Dan
>http://www.w3.org/People/Connolly/
>

Actually, # is *not* a fragment specifier. It is a position
specifier in its use in the HTTP scheme. 

As you note from the earlier URN-WG discussion, we had to
use $ as the fragment delimiter because legacy WWW implementations
swallow everything from the # forward -- and you're not going
to change that easily.

Consequently, # must be a reserved character (as it is) and
must be quoted just in case it is transported through an HTTP
URL to a URN resolver, for example via THTTP.

This is a good example of how past design decisions constrain
future systems and why one should try to provide insulation
whenever possible in order to maintain degrees of freedom, ergo,
evolvability.

Date: Wed, 7 Jan 1998 23:09 -0500
From: "John C. Mallery" <[email-masked]>
Subject: [URN] URI documents
To: [email-masked]
Comments: Posted from 128.52.39.15 via CL-HTTP HyperArchive at http://wilson.ai.mit.edu/archives/urn-wg.html
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

>Sam Sun wrote:
>> In the case of URL, The " [ "#" fragment ] " is only used or useful by some
>> URL schemes. So my question is: is it acceptable to say that the fragment
>> is scheme dependent, and don't bring it up in the URI definition?
>
>No; that is, to say that is not consistent with current
>implementations, and I would find it unacceptable.
>For example, consider:
>
>‰<p>...<a href="#foo">tail</a>
>
>‰...
>
>‰<p><a name="foo">head</a>
>
>I can tell you where the link from tail goes (i.e. to head)
>without knowing what URI scheme was used to access the document. So
>can lots of implemented web clients (and maybe even some servers).
>
>
>-- 
>Dan
>http://www.w3.org/People/Connolly/
>

Actually, # is *not* a fragment specifier. It is a position
specifier in its use in the HTTP scheme. 

As you note from the earlier URN-WG discussion, we had to
use $ as the fragment delimiter because legacy WWW implementations
swallow everything from the # forward -- and you're not going
to change that easily.

Consequently, # must be a reserved character (as it is) and
must be quoted just in case it is transported through an HTTP
URL to a URN resolver, for example via THTTP.

This is a good example of how past design decisions constrain
future systems and why one should try to provide insulation
whenever possible in order to maintain degrees of freedom, ergo,
evolvability.

Date: Wed, 7 Jan 1998 22:57 -0500
From: "John C. Mallery" <[email-masked]>
Subject: [URN] URN-WG HyperArchive
To: [email-masked]
Comments: Posted from 128.52.39.15 via CL-HTTP HyperArchive at http://wilson.ai.mit.edu/archives/urn-wg.html
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

>A hyperarchive for the URN Mailing list is available at
>
>http://wilson.ai.mit.edu/archives/urn-wg.html
>

If you're having trouble tracking the current activity,
the convesation threading and full-text search on the URN-WG
archive above may prove helpful. Alternatively, you can
use the author or subject views.

Note that replying to the right message and including
references headers makes the conversation code work better.

From: "Sam X. Sun" <[email-masked]>
To: "Dan Connolly" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: [URN] URI documents -- "# fragment"
Date: Thu, 8 Jan 1998 03:08:15 -0500
Sender: [email-masked]
Reply-To: "Sam X. Sun" <[email-masked]>

> Sam Sun wrote:
> > In the case of URL, The " [ "#" fragment ] " is only used or useful by
some
> > URL schemes. So my question is: is it acceptable to say that the
fragment
> > is scheme dependent, and don't bring it up in the URI definition?

Dan Said:
> 
> No; that is, to say that is not consistent with current
> implementations, and I would find it unacceptable.

The current implementation (eg. Netscape browser) append the "#fragment" to
whatever
the base URI is. I don't quite understand on where it would be
inconsistent?

Here is an example which I think doesn't honor the current '#' URI syntax:

If I define my password as "password_with_#_character", and use "ftp" URL:

ftp://my_user_id:password_with_#_character@myhost/my_file_path

Netscape browser implementation will pass the entire password (with #
character in it) to the server, instead of sending only
"ftp://user_id:password_with_" to the server. In fact, using %25 to replace
the '#' character will fail. 

Dan Said:
> For example, consider:
> 
> 	<p>...<a href="#foo">tail</a>
> 
> 	...
> 
> 	<p><a name="foo">head</a>
> 
> I can tell you where the link from tail goes (i.e. to head)
> without knowing what URI scheme was used to access the document. So
> can lots of implemented web clients (and maybe even some servers).
> 

The example will fail from the current Netscape implementation if no BASE
URI is defined. (Refer the following URL for an example:
http://ssun.cnri.reston.va.us/ietf/uri/nobase.htm and
http://ssun.cnri.reston.va.us/ietf/uri/fragment.htm).

Regards,
Sam

PS. To avoid distraction from the current discussion on relationship of URN
& URI, I modified the subject title.

Date: Wed, 07 Jan 1998 17:46:49 -0500 (EST)
From: Foteos Macrides <[email-masked]>
Subject: Re: [URN] Re: URI documents
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Foteos Macrides <[email-masked]>

Sam Sun <[email-masked]> wrote:
>I didn't follow the history of the issue long enough, and don't quite
>understand why " [ "#" fragment ] " has to be defined in the URI/URL
>syntax.
>
>In the case of URL, The " [ "#" fragment ] " is only used or useful by some
>URL schemes. So my question is: is it acceptable to say that the fragment
>is scheme dependent, and don't bring it up in the URI definition?

	They are not "scheme dependent".  They are defined via application
conventions, presently for text/html documents, and should apply no matter
what scheme is used to retrieve such documents (i.e., not just http, although
HTTP/1.n has one of the clearest means of specifing the MIME type).  (An)
application convention(s) could, someday, be specified in relation to (a)
scheme(s).  Why impose a restriction against someday doing so for some URNs,
or for URNs that might return text/html documents such that the existing
conventions would apply?

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 [email-masked]         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Date: Wed, 07 Jan 1998 16:49:35 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium (http://www.w3.org/)
To: Sam Sun <[email-masked]>
CC: "Roy T. Fielding" <[email-masked]>, Larry Masinter <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Sam Sun wrote:
> In the case of URL, The " [ "#" fragment ] " is only used or useful by some
> URL schemes. So my question is: is it acceptable to say that the fragment
> is scheme dependent, and don't bring it up in the URI definition?

No; that is, to say that is not consistent with current
implementations, and I would find it unacceptable.
For example, consider:

	<p>...<a href="#foo">tail</a>

	...

	<p><a name="foo">head</a>

I can tell you where the link from tail goes (i.e. to head)
without knowing what URI scheme was used to access the document. So
can lots of implemented web clients (and maybe even some servers).

-- 
Dan
http://www.w3.org/People/Connolly/

Date: Wed, 07 Jan 1998 23:08:07 +0100
To: Larry Masinter <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
Subject: Re: [URN] Re: URI documents
Cc: Harald Tveit Alvestrand <[email-masked]>, Dan Connolly <[email-masked]>, Leslie Daigle <[email-masked]>, "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>

At 10:02 1998-01-07 PST, Larry Masinter wrote:
>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.

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

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

From: "Sam Sun" <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Cc: "Larry Masinter" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [URN] Re: URI documents 
Date: Wed, 7 Jan 1998 16:54:27 -0500
Sender: [email-masked]
Reply-To: "Sam Sun" <[email-masked]>

Hi, Roy,

I didn't follow the history of the issue long enough, and don't quite
understand why " [ "#" fragment ] " has to be defined in the URI/URL
syntax.

In the case of URL, The " [ "#" fragment ] " is only used or useful by some
URL schemes. So my question is: is it acceptable to say that the fragment
is scheme dependent, and don't bring it up in the URI definition?

Regards,
Sam

-----Original Message-----
From: Roy T. Fielding <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Date: Wednesday, January 07, 1998 12:54 PM
Subject: Re: [URN] Re: URI documents

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

Date: Wed, 7 Jan 1998 15:37:09 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: Larry Masinter <[email-masked]>
cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>, Harald Tveit Alvestrand <[email-masked]>, Dan Connolly <[email-masked]>, "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Wed, 7 Jan 1998, Larry Masinter wrote:
> If we just change the *title* of draft-fielding-uri-syntax-XX
> and remove the word "Semantics", it might make things clearer.
[snip]
> 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?

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                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

Date: Wed, 7 Jan 1998 10:02:44 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: "Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=" <[email-masked]>
CC: Harald Tveit Alvestrand <[email-masked]>, Dan Connolly <[email-masked]>, Leslie Daigle <[email-masked]>, "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

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.

I said:
> >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.
> 
And Patrik replied:

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

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
> define "characters", and we also have to agree on what octets are valid on
> 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]
>   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

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
> everything from the translitterated string and downwards to be described in
> 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
> should go in a URL/URN syntax document and various schema definition
> documents.

Not all schemes will use the same encoding.

> 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: 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
-- 
http://www.parc.xerox.com/masinter

Date: Wed, 07 Jan 1998 14:22:29 -0500 (EST)
From: Foteos Macrides <[email-masked]>
Subject: Re: [URN] Re: URI documents
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Foteos Macrides <[email-masked]>

"Roy T. Fielding" <[email-masked]> wrote:
>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.

	For what it's worth, I have yet to read a compelling rationale
in this thread for excluding possible use of fragments with URNs, though
of course they should not be used (for neither URNs nor URLs) if no
application convention has been defined, and at present only two have
been defined (for positioning, and for MAPs, in text/html documents).

	I do think, however, that the current draft needs to clarify
whether more than one unescaped hash ('#') can be present.  The
initial RFCs stated that only one can be present, and only if it
indeed is a fragment delimiter.  That made direction of parsing for
the hash irrelevant, and a number of deployed UAs parse from right
to left.  RFC 1808 and the current draft specify left-to-right parsing,
and do not state that only one, actual fragment delimiter, can be
present.  This understandably has led to the (mis?)interpretation
that additional unescaped hashes can present to the right of a
fragment delimiter, and be used for special purposes (one well
developed suggestion, though not submitted as an IETF draft, sought
to use multiple hashes for specifying components of frame documents).
I do hope this issue will be addressed explicitly before the current
draft is finalized (and my preference is to restore the original
contraint of only one unescaped hash which must be a fragment
delimiter).

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 [email-masked]         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

To: Harald Tveit Alvestrand <[email-masked]>
cc: Dan Connolly <[email-masked]>, Larry Masinter <[email-masked]>, [email-masked], [email-masked]
Subject: [URN] Re: URI documents 
Date: Wed, 07 Jan 1998 09:35:17 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

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

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.

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

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

To: Larry Masinter <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents 
Date: Wed, 07 Jan 1998 08:57:23 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

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

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: Michael Mealling <[email-masked]>
Subject: Re: [URN] Re: URI documents
To: [email-masked]
Date: Wed, 7 Jan 1998 11:15:45 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Larry Masinter said this:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
>
> 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?
> 

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

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

Date: Wed, 07 Jan 1998 16:12:14 +0100
To: Larry Masinter <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
Subject: Re: [URN] Re: URI documents
Cc: Harald Tveit Alvestrand <[email-masked]>, Dan Connolly <[email-masked]>, Leslie Daigle <[email-masked]>, "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>

At 00:03 1998-01-07 PST, Larry Masinter wrote:
>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.

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

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

Date: Wed, 7 Jan 1998 00:03:46 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: "Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=" <[email-masked]>
CC: Harald Tveit Alvestrand <[email-masked]>, Dan Connolly <[email-masked]>, Leslie Daigle <[email-masked]>, "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Patrik Fältström wrote:
> 
> At 12:59 1998-01-06 +0100, Harald Tveit Alvestrand wrote:
> >- 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.
> >
> >
> >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"?
> 
> 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".

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.

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?

Larry

Date: Wed, 07 Jan 1998 07:27:58 +0100
To: Harald Tveit Alvestrand <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
Subject: Re: [URN] Re: URI documents
Cc: Dan Connolly <[email-masked]>, Larry Masinter <[email-masked]>, Leslie Daigle <[email-masked]>, "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>

At 12:59 1998-01-06 +0100, Harald Tveit Alvestrand wrote:
>- 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.
>
>
>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"?

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

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

Date: Wed, 07 Jan 1998 10:22:31 +0100
To: Larry Masinter <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
Subject: Re: [URN] Re: URI documents
Cc: Harald Tveit Alvestrand <[email-masked]>, Dan Connolly <[email-masked]>, Leslie Daigle <[email-masked]>, "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>

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

Date: Tue, 6 Jan 1998 16:03:55 -0500
From: <[email-masked]>
To: "David G. Durand" <[email-masked]>
Cc: Harald Tveit Alvestrand <[email-masked]>, Dan Connolly <[email-masked]>, Larry Masinter <[email-masked]>, Leslie Daigle <[email-masked]>, "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: URI documents
Sender: [email-masked]
Reply-To: <[email-masked]>

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: "David G. Durand" <[email-masked]>
Date: Tue, 6 Jan 1998 13:08:34 -0500
To: Harald Tveit Alvestrand <[email-masked]>, Dan Connolly <[email-masked]>
Subject: [URN] Re: URI documents
Cc: Larry Masinter <[email-masked]>, Leslie Daigle <[email-masked]>, "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "David G. Durand" <[email-masked]>

On Jan 6, 12:59pm, Harald Tveit Alvestrand wrote:
> Subject: Re: URI documents
> At 09:29 02.01.98 -0600, Dan Connolly wrote:
> >Since Larry asked, I'll (re-)state the W3C opinion: we're
> >heavily invested in the notion of a single, extensible universal
> >address space:
>
> 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.

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).

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

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.

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

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.

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

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.

> 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"?

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.]]

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

I don't know about this one..

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

   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: Al Gilman <[email-masked]>
Subject: [URN] Re: URI documents
To: [email-masked] (Harald Tveit Alvestrand)
Date: Tue, 6 Jan 1998 10:07:25 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Al Gilman <[email-masked]>

to follow up on what Harald Tveit Alvestrand said:

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

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.

Harald Alvestrand:
> 
> 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?)

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.

Harald A:
> 
> If separation is not the Right Way, the issues are of course slightly
> different....

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

Date: Tue, 06 Jan 1998 12:59:34 +0100
To: Dan Connolly <[email-masked]>
From: Harald Tveit Alvestrand <[email-masked]>
Subject: [URN] Re: URI documents
Cc: Larry Masinter <[email-masked]>, Leslie Daigle <[email-masked]>, "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Harald Tveit Alvestrand <[email-masked]>

At 09:29 02.01.98 -0600, Dan Connolly wrote:

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

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.

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

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

Date: Sun, 4 Jan 1998 11:15:57 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: "Roy T. Fielding" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: [URN] Re: Hypertext::non-Hypertext not URL::URN
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

I said (to Roy, privately)

> The point is, there are a particular set of applications that
> can use relative forms, fragments, and query syntax. Whether or
> not those applications can use a particular naming scheme
> is independent of whether the naming scheme is intended to
> be "location-independent" or "permanent".

to which Roy reiterated (privately):

> There are some applications which do not use relative forms,
> but the ones that do are not limited to hypertext. Regardless,
> the syntax is uniform in order to support those applications
> that do use those forms.  This is not a hardship for any other
> applications, so there is no point in debating it.

I think we have an agreement on the point that "there are some
applications that do not use fragments, relative forms or queries,
and some that do."  There seems to be some agreement (I'm not sure
how much) that the distinction is based on the application class,
and not (necessarily) on whether the identifier is a URL or a URN.

As to whether or not we should "debate" this, I believe this is the 
crux of the issue that is keeping us from progressing, so I think
it's worth getting clear about it. The question isn't about "hardship",
it is about "applicability" or "appropriateness". Unless it is made explicit,
there is a presumption, at least in many situations, that if you
give a general syntax for a protocol element, the components of
that general syntax are appropriate and allowed for all applications
of that protocol element. However, this is not the case: there are
applications for which fragment identifiers are inappropriate.

If we didn't want to restrict applicability of syntactic components
by having explicit syntactic elements, we'd just stick to "scheme:uric*"
and put footnotes for each application. But that's hardly desirable.

The World Wide Web application (and various other applications) need
and want the BNF for "URI-reference". But other applications (e.g.,
digital libraries, for example), might want to disallow fragment identifiers.

If we pursue this line of reasoning, we would want the URI syntax document
to define sufficient non-terminals to be useful for the different
kinds of application classes. For example,

There are a class of applications that use only 'pure absolute
URIs', with no fragment identifiers, relative forms, or query
processing. (For example, I might imagine various digital library
applications wanting to make this restriction.)

There are a class of applications that use only 'absolute URIs,
and query forms', but no relative forms or fragment identifiers.
For example, I might imagine various resource location applications
wanting this restriction.

There are a class of applications that use "recognize URI in
plain text" syntax. This class might use the "www.blah.com/foo"
form, without any scheme, and might want to restrict the URL scheme
to start with a text character.

Perhaps one way to clarify the issues for some would be to note
some of the different application classes, and even to give
different BNF constructions for each. Hiding it behind the
opaque URI syntax doesn't seem to help those who want some of
the syntactic elements but not the rest.

Larry

To: Patrik Faltstrom <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents 
Date: Sat, 03 Jan 1998 00:14:48 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

Patrik writes:
>
>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.

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.

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

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.

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

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

To: Larry Masinter <[email-masked]>
cc: Patrik Faltstrom <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents 
Date: Fri, 02 Jan 1998 23:40:26 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

In message <[email-masked]>, Larry Masinter writes:
>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.

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

To: Patrik Faltstrom <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents 
Date: Fri, 02 Jan 1998 23:22:45 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

Patrik Faltstrom writes:
>
>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.

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.

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

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.

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

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.

>> 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?
>
>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.

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

To: Dan Connolly <[email-masked]>
cc: [email-masked], [email-masked]
Subject: [URN] Re: URI documents 
Date: Fri, 02 Jan 1998 22:28:17 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

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

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

To: Larry Masinter <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: Hypertext::non-Hypertext not URL::URN 
Date: Fri, 02 Jan 1998 22:11:32 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

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

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.

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

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.

>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).

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: Al Gilman <[email-masked]>
Subject: [URN] Re: Hypertext::non-Hypertext not URL::URN
To: [email-masked] (Larry Masinter)
Date: Fri, 2 Jan 1998 17:29:29 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Al Gilman <[email-masked]>

to follow up on what Larry Masinter said:

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

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

Date: Fri, 2 Jan 1998 09:53:03 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Hypertext::non-Hypertext not URL::URN
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

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
-- 
http://www.parc.xerox.com/masinter

From: Michael Mealling <[email-masked]>
Subject: [URN] Re: URI documents
To: [email-masked] (Larry Masinter)
Date: Fri, 2 Jan 1998 12:39:58 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Larry Masinter said this:
> 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:

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

-- 
------------------------------------------------------------------------------
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]>
Subject: Re: [URN] Re: URI documents
To: [email-masked] (Larry Masinter)
Date: Fri, 2 Jan 1998 12:03:23 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

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

Larry Masinter said this:
> I've been wondering if we might progress with a different
> 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.

> 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

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.

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

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

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

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

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

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

-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]>
Subject: Re: [URN] Re: URI documents
To: [email-masked]
Date: Fri, 2 Jan 1998 11:43:56 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Dan Connolly said this:
> Harald Tveit Alvestrand wrote:
> > - 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.
> 
> 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'll try to explain some below.

> ============
> 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. 

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 ...
> ============
> 
> 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.

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".

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

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.

> (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.

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:
> 
> =============
> Axiom 1: Global uniqueness 
> 
>  It doesn't matter to whom or where you specify that URI, it
>  will have the same meaning.

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

> =============
> 
> 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.

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.

> 
> =============
> 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.

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]

Date: Fri, 02 Jan 1998 09:29:40 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium (http://www.w3.org/)
To: Harald Tveit Alvestrand <[email-masked]>
CC: Larry Masinter <[email-masked]>, Leslie Daigle <[email-masked]>, "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: URI documents
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Harald Tveit Alvestrand wrote:
> 
> At 16:06 24.12.97 -0800, Larry Masinter wrote:
> >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:
[...]
> 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.

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/