Subject: [urn] A first cut at the Draft Charter for the proposed URNbis WG

From: Alfred Hönes <[email-masked]>
Date: Tue, 27 Apr 2010 19:05:07 +0200 (MESZ)

Folks,
Based on work done by Juha Hakala in February, I have updated
and amended the Draft Charter and hereby bring it to the urn list
for discussion.   Comments welcome!

Kind regards,
  Alfred Hönes.

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

Uniform Resource Names, Revised (URNbis) -- Draft Proposed WG Charter
========================================

Last Modified:  2010-04-26 [AH]

Chair(s):
  o   Juha Hakala  <[email-masked]>
  o   N.N.

Applications Area Director(s):
  o   Alexey Melnikov  <[email-masked]>
  o   Peter Saint-Andre  <[email-masked]>

Applications Area Advisor:
  o   Peter Saint-Andre  <[email-masked]>

Mailing Lists:
  General Discussion: [email-masked]
  To Subscribe: https://www.ietf.org/mailman/listinfo/urn
  Archive: http://www.ietf.org/mail-archive/web/urn/current/maillist.html

  Related lists (used for IANA registration procedures (BCP 35/66):
    [email-masked], [email-masked]

Additional information will be available at:
  http://tools.ietf.org/wg/urnbis

Description of Working Group:

  Uniform Resource Names (URNs) are persistent identifiers for
  information resources.  The RFCs defining URNs and services based on
  them were published 1997-2001.  Since then, the URN system has gained
  popularity.  Among the more traditional parties with deep interest in
  persistent identifiers and making heavy use of URNs are national
  libraries; solely within this area, tens of millions of resources
  have been assigned URNs; this enables efficient searching of and
  persistent linking to these documents.

  This working group is chartered to revise the key RFCs describing the
  URN system, including RFC 2141 (URN Syntax) and RFC 4306 (Namespace
  Definition Mechanisms), update important URN namespace specifications,
  and to screen and update RFCs describing URN resolution principles
  and practices.

  For RFC 2141, this revision will include in particular: an update of
  the formal syntax specification in the light of the URI Standard
  (STD 66, RFC 3986) using the ABNF from STD 68 (RFC 5234), a revision
  of URN examples from imaginary ones into existing URNs in current
  namespaces, providing a formal IANA registration for the 'urn' URI
  scheme using the template from BCP 35 (RFC 4395), and an update of
  the section describing how URNs are resolved in the Internet.
  RFC 4306 (BCP 66) needs a less pervasive update, mostly to align it
  with the current IANA procedures and terminology as defined in BCP 26
  (RFC 5226).

  Regarding URN Namespace specifications, the WG will focus on updates
  for the definitions of URNs based on bibliographic identifier systems,
  in particular RFC 3187 (URN Namespace for International Standard Book
  Numbers) and RFC 3188 (URN Namespace for National Bibliography
  Numbers).  In both cases, the respective identifier system and/or the
  institutions and roles involved in their assignment and resolution
  have evolved significantly since these RFCs have been published.
  In particular, the URN:ISBN namespace needs to be extended according
  to the revision of the international ISBN standard, and the usage of
  the URN:NBNs has grown rapidly and there is a need to align the
  namespace registration with experience and current practice.
  In a second stage, RFC 3044 (URN Namespace for International Series
  Standard Number) will be checked for the necessity of an update.

  Thus, in support of the current international efforts to establish a
  distributed, linked system of URN resolution systems for bibliographic
  identifiers, the primary aim of the WG is an updated set of standards
  documents, which is needed to assure uniformity and interoperability
  of the URN resolution services.

  Alongside the modernization of these core RFCs for URNs and specific
  URN namespaces, the working group will also consider a revision of
  earlier RFCs related to the principles of URNs and URN resolution,
  such as RFC 2483 (URI Resolution services necessary for URN
  resolution), RFC 2276 (Architectural principles of Uniform Resource
  Name Resolution), RFC 1737 (Functional requirements for Uniform
  Resource Names) and RFC 2169 (A trivial convention for using HTTP in
  URN resolution).  All these must be checked; if the document is still
  deemed relevant, it will be modernized.

  The working group will also consider the possibility of publishing
  Best Current Practices on how to resolve the URNs utilizing the
  existing Internet protocols such as HTTP.  This BCP will be based on
  the European URN resolution infrastructure under construction in the
  project PersID.

  Since the revised specifications will be based on existing production
  systems and provide important guidelines for future implementers,
  the WG aims at publishing the RFCs on the Standards Track and will try
  to advance the core document at least to Draft Standard status as fast
  as possible.

  The WG can take on work to update other well-established URN namespace
  definitions upon a case-by-case decision.

Input documents:

  RFC 2141
  RFC 3406

  RFC 3187
  RFC 3188

  RFC 2483
  RFC 2276
  RFC 1737
  RFC 2169

Goals and Milestones (preliminary):

  Feb 2010   Initial WG formation as 'URN-R' (outside the IETF)
  Mar 2010   WG work plan completed, brought to IETF APP Area
  May 2010   first Internet-Drafts for most important core document
             revisions
  Jul 2010   Presentation of the group & early results at IETF 78 (BoF)
  Aug 2010   Formal establishment of the IETF WG
  Dec 2010   WG Last Call on WG core document set
  Feb 2011   core document set forwarded to IESG
      2011   work on supporting documents (guidelines, URN resolution)
      2012   implementation report for promoting 2141bis to Draft Std.

Internet-Drafts:

  draft-ah-rfc2141bis-urn          (-00: March 2010)
  draft-hakala-rfc3187bis-isbn-urn (-00: March 2010)
  draft-hakala-rfc3188bis-nbn-urn  (-00 due for week 18/2010)

Request For Comments:

  none so far

---

From: Juha Hakala <[email-masked]>
Date: Wed, 28 Apr 2010 08:20:54 +0300

Hello all,

Quite a lot has already happened since February, so the draft charter 
written by me back then was already badly out of date. Alfred's thorough 
revision has updated the charter, and also improved its content 
significantly in other ways.

>   Standard Number) will be checked for the necessity of an update.

Should be changed into:

"The need for revising RFC 3044 (URN Namespace registration for ISSN, 
International Serial Standard Number) will be analysed with the ISSN 
International Centre. If the revision is required, it will be done in 
close co-operation with the centre."

I have discussed revision of RFC 3044 with the ISSN International 
Centre, but no firm decision has been done yet to start the work.

The second request is that RFC 3044 should be added to the list of input 
documents, before RFC 3187 so that all namespace registrations are 
grouped together.

RFC3188bis still needs a lot of work. PersID colleagues and Alfred have 
provided many useful comments to the preliminary draft that will / must 
be taken into account, but my intention is still to publish the first 
draft on week 18 as the attached version of the charter suggests (that 
is, the deadline is Friday 7th of May).

Best regards,

Juha

Alfred � wrote:
>   Alfred H�nes.
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

  Juha Hakala
  Director of IT Development

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email [email-masked], tel +358 50 382 7678

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Apr 2010 02:49:36 -0400

I'm a bit curious and I can't really tell from the charter - what is it
about the URN syntax that needs to be changed?  I feel like RFC 2141 is
sort of a contract with implementors to say "this is what URNs will look
like" and we have an obligation to not change it without a very good
reason.   I don't suppose it hurts too much to change to the newer style
ABNF notation as long as the new ABNF recognizes the same set of strings
as the old ABNF, but I don't think that "new ABNF" is a sufficiently
good reason by itself.  And I haven't analyzed RFC 2141 against RFC 3986
to see how the latter might be incompatible with the former.  But in my
opinion, if there is any incompatibility, it's latter document which is
incorrect.  I don't think RFC 3986 was meant to retroactively invalidate
existing practice.

As the entire idea behind URNs is for them to be long-term persistent
identifiers, I think it's especially important that IETF not invalidate
existing URNs or use of URNs, as long as such URNs were created and such
use is consistent with existing IETF standards.

Keith

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 28 Apr 2010 09:12:54 +0200 (MESZ)

Juha,
thanks for your response.

> close co-operation with the centre."

Unless someone opposes and takes over the duty, I'll maintain
a working copy of the draft charter, incorporate changes as they are
suggested and accepted, and re-post it to the list as approporiate,
until a BoF Wiki has been granted and it can be maintained there
directly.
Of course, your above change is "accepted"! I thought adding RFC 3044
to the text from the first cut on would be prudent, and I expected
feedback from you to this topic.

> documents, before RFC 3187 so that all namespace registrations are

I agree -- I'd better included it in the list immediately; but since
the list somehow reflects the 'precedence' of work (already done or
in progress, or still to be started), which also is the order in which
these RFCs are discussed in the body of the charter text, I'd prefer
to list it _after_ 3187 and 3188.

> Alfred wrote:
>> <snip/>
 (see: <http://www.IETF.ORG/mail-archive/web/urn/current/msg00002.html> )

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 28 Apr 2010 10:02:23 +0200 (MESZ)

Keith,
thanks for your feedback.

> use is consistent with existing IETF standards.

You're knocking on open doors!  (see below)

Since the details are already described in the rfc2141bis draft, the
draft charter has been kept rather terse in this regard.
It would be great if you could review the draft (or at least the
syntax part, for now) and check your concerns with the draft text.

The primary issues I found in RFC 2141 were the contradictions between
the formal BNF and the textual description -- the syntax rules admitted
specific delimiter characters that subsequently got waived in the prose,
and the formal rules were ambiguous regarding the '%' character.

I have tried to document these details and the envisioned changes in the
original draft published end of March and my announcement sent to the
uri-review, apps-discuss, and urn-nid lists (AT IETF.ORG) -- please refer
to the draft's announcement archived at
  <http://www.IETF.ORG/mail-archive/web/uri-review/current/msg01136.html>
and to the draft proper, available at
  <http://tools.IETF.ORG/html/draft-ah-rfc2141bis-urn-00>.

Further, the draft tries to make clear the relationship of URN syntax
to the RFC 3986 URI components and syntax rules and re-use them where
possible, to the benefit of parser implementers.

Admittedly, the text and formatting in the syntax section got a bit
unpleasant by the attempt to present new text and juxtapose referenced
text and discussion; that will be cleaned up after resolution, and a
detailed change log (both incrementally and from RFC 2141 to the draft)
be added in the next draft revisions.

Regarding the principles:
  Of course, no existing URN namespace definition or URN instance
  must be invalidated by the revised specification.

The primary questions are related to whether or not the general URN
syntax should allow *new* or *revised* URN namespace definitions to
explicitly admit <question> and/or <fragment> parts, and whether or
not the few delimiter characters admitted in the revised URI syntax
<path> components but not in RFC 2141 should be allowed (without
percent-encoding) in the URN syntax.
It has been reported to me that for URNs based on bibliographic
identifiers, some folks would like to be able to add a fragment
identifier, which could be carried over unchanged into a network
reachable URI (e.g. http URI) returned by a URN resolution service
given such extenedd, say NBN, URN.
I have not heard of a similar use case for <question> parts, so this
is more or less a theoretical question so far, but it should be
assessed as well in the WG.

Leslie Daigle has reported that these questions have been discussed
controversially in the original URN WG, and we hope that the list
archives from those days (that unfortunately have disappeared from
the public web) can be restored on the servers maintained by the
IETF Secretariat, in order to make that precedent available to all.

It will be part of the WG's task to cross check with all existing
URN namespace definitions the impact of what goes into rfc2141bis.

Kind regards,
  Alfred.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Apr 2010 14:56:09 +0200

On 28.04.2010 10:02, Alfred � wrote:
> ...
> explicitly admit<question>  and/or<fragment>  parts, and whether or
 > ...

URNs are URIs, right? According to RFC 3986, the fragment identifier is 
entirely independent from the URI scheme:

"The semantics of a fragment identifier are defined by the set of 
representations that might result from a retrieval action on the primary 
resource. The fragment's format and resolution is therefore dependent on 
the media type [RFC2046] of a potentially retrieved representation, even 
though such a retrieval is only performed if the URI is dereferenced. If 
no such representation exists, then the semantics of the fragment are 
considered unknown and are effectively unconstrained. Fragment 
identifier semantics are independent of the URI scheme and thus cannot 
be redefined by scheme specifications." -- 
<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5.p.2>

So the question here is: what's the purpose of a fragment identifier in 
the absence of a representation?

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Apr 2010 09:23:27 -0400

On 4/28/10 8:56 AM, Julian Reschke wrote:
> URNs are URIs, right? According to RFC 3986, the fragment identifier
> is entirely independent from the URI scheme:
Mumble. 

A single URI (including a URN) can map to multiple representations of a
resource through content negotiation of some kind.  But in practice,
fragment identifiers don't readily map between one representation
(typically content-type, though you can also have multiple
representations with the same content-type) and another.   What I find
myself wondering is whether a URN with a fragment id has a persistent
binding between the URN and the resource (fragment) that it identifies. 
I suppose that academically you could say that the URN->resource binding
is still persistent even if the URN#fragment -> resource fragment
binding is not persistent.  But people tend to associate the fragment
identifier with the URI, so I suspect that using a fragment id with a
URN is at best confusing.

We could write a rule that says "don't use fragment ids with a URN
unless those fragment ids are meaningful across all representations of
the resources named by the URN."  But I keep seeing examples that
illustrate that people don't understand URNs or how they're to be used,
even though the rules are quite simple.   I suspect that adding more
rules decreases the likelihood that people will use URNs correctly.

But neither do I want to revise 3986 to say that fragment ids don't
apply to URNs.  That's a huge can of worms I'd prefer to leave closed.

So maybe writing the rule is the best way.   Though I have little
confidence that it will be followed.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Apr 2010 15:35:31 +0200

> fragment identifiers don't readily map between one representation

Sometimes they do...

> URN is at best confusing.

It is.

> the resources named by the URN."  But I keep seeing examples that

That would be almost the same rule as for any URL^HI.

> confidence that it will be followed.

What we need to do is to clarify that although fragment identifiers 
aren't particularly useful unless you have representations, the URN 
*syntax* - being compatible to RFC 3986 - allows them; and thus the hash 
character needs to be percent-escaped in a URN. (which reminds me of 
<http://greenbytes.de/tech/webdav/draft-rsalz-qname-urn-latest.html#rfc.issue.any-uri>).

Best regards, Julian

---

From: Xiaoshu Wang <[email-masked]>
Date: Wed, 28 Apr 2010 09:42:41 -0400

> the absence of a representation?
The same question applies to a URN, with or without a fragment 
identifier. Let me rephrase your question as follows:

"What is the purpose of a name in the absence of a representation?"

A name does not necessarily refer to a representation. The retrieval of 
the representation of a thing referred to by a fragment identifier 
depends on the document type. It is no different from a URN that is 
absent of a fragment identifier.

For example: both of the followings can be used as a name to refer an apple.

(a) http://example.com/anApple
(b) http://example.com/#anApple

The difference is that, in case (b), the representation requires another 
retrieval mechanism other than HTTP. And this retrieval mechanism varies 
by MIME type. But that is the only difference. There isn't any 
inconsistencies between URI with or without fragment identifiers.

Xiaoshu

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Apr 2010 09:45:45 -0400

> That would be almost the same rule as for any URL^HI.
True.  But we don't expect ordinary URIs to have persistent
URI->resource bindings, which is the entire (original) reason for URNs. 
(Despite URNs being widely used today as unique names with no binding to
any resource.)
> *syntax* - being compatible to RFC 3986 - allows them; and thus the
> hash character needs to be percent-escaped in a URN.
Certainly so if you want the hash character to be part of the base URN
itself.

I think it's also necessary to say something about the persistence (or
lack thereof) of a URN#fragment -> resource fragment binding.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Apr 2010 10:00:29 -0400

On 4/28/10 9:42 AM, Xiaoshu Wang wrote:
> A name does not necessarily refer to a representation. The retrieval
> of the representation of a thing referred to by a fragment identifier
> depends on the document type. 
More precisely, it depends on the representation.  Different
representations of a resource can have the same document type
(content-type) and still not use fragment identifiers in the same way. 

Consider the problem of translating a document from one language to
another.  The original document contains named fragments of text which
(due to differences in the way things are expressed in the different
languages) do not cleanly map from the original document to the
translation.   In general there are just too many barriers to expecting,
as a matter of web architecture, that fragment identifiers mean the same
thing across different representations of a resource.

Basically, this was not a well thought out aspect of the design of the
web.   Content-negotiation was not anticipated.    While it makes sense
for HTML to have the ability to name subsections of a document, fragment
identifiers in URIs were never designed to be stable across different
representations of a resource.  

Even in those cases where URL#fragment is useful, there's no assurance
that, given a URN that is associated with the same resource as that URL,
URN#fragment is similarly useful.
> It is no different from a URN that is absent of a fragment identifier.
>
> The difference is that, in case (b), the representation requires
> another retrieval mechanism other than HTTP. And this retrieval
> mechanism varies by MIME type. But that is the only difference. There
> isn't any inconsistencies between URI with or without fragment
> identifiers. 
Uh, no.  It makes no sense to have different syntaxes for a URI in
different contexts.   The # character (if it appears in a URI) MUST
always separate a base URI from a fragment identifier, and for any URI
which is bound to a resource, the way the base URI vs. fragment
identifier are parsed MUST be independent of the access mechanism.

Keith

---

From: Xiaoshu Wang <[email-masked]>
Date: Wed, 28 Apr 2010 10:27:25 -0400

On 4/28/10 10:00 AM, Keith Moore wrote:
> translation.   In general there are just too many barriers to 
> expecting, as a matter of web architecture, that fragment identifiers 
> mean the same thing across different representations of a resource.
Right. But we can describe an apple in different languages. But the 
apple is the apple. The URI does not refer to the representation. Of 
course, it can made it be. But if so, it requires to be explicitly 
specified.
> web.   Content-negotiation was not anticipated.    While it makes 
> sense for HTML to have the ability to name subsections of a document, 
> fragment identifiers in URIs were never designed to be stable across 
> different representations of a resource.
If the following three URIs are used to refer to the same thing, say, an 
apple

(a) http://a.com/anApple (say only return an HTML representation)
(b) http://b.com/anApple (say only return a JPEG representation)
(c) http://c.com/#anApple (return both an HTML and JPEG representation 
via content negotiation)
     (c1) the HTML representation of "http://c.com/#anApple"
     (c2) the JPEG representation of "http://c.com/#anApple"

Is there any difference that if (a) and (b) are inconsistent vs. the 
case that (c1) and (c2) are inconsistent?
> that, given a URN that is associated with the same resource as that 
> URL, URN#fragment is similarly useful.
My point is that it doesn't matter if there is a fragment identifier or 
not. A URI is a URI. The path to its representation may differ; but it 
doesn't matter what a URI is used to refer to something.

> identifier are parsed MUST be independent of the access mechanism.
I didn't mean to have different syntax in different context. I am trying 
to illustrate that whether a URI has a fragment identifier or not is 
irrelevant to the issue of naming. We have to understand that what a URI 
references is not the same as what is de-referenced from the URI. The 
de-reference process of a URI with a fragment identifier is a bit 
different from those that are not. But it has nothing to do with what 
the URI references.

Xiaoshu

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Apr 2010 10:35:14 -0400

On 4/28/10 10:27 AM, Xiaoshu Wang wrote:
> We have to understand that what a URI references is not the same as
> what is de-referenced from the URI.
Well, IMO, that makes very little sense.  I realize that there's a
growing tendency to use URIs as pure names, or as names that don't refer
specifically to a network-accessible resource - and then to say that if
de-referencing the URI over the network happens to return a resource,
that it's not the same thing as what is named by the URI.  But neither
URIs nor the other mechanisms associated with the web were designed to
work this way.  Trying to re-justify all of the existing notations,
protocols, and other infrastructure in terms of some more abstract (and
revisionist) idea of what URIs are, is silly, and has no place in an
organization that purports to do engineering.

Keith

---

From: Xiaoshu Wang <[email-masked]>
Date: Wed, 28 Apr 2010 10:42:49 -0400

On 4/28/10 10:35 AM, Keith Moore wrote:
> growing tendency to use URIs as pure names, or as names that don't 
> refer specifically to a network-accessible resource - and then to say 
> that if de-referencing the URI over the network happens to return a 
> resource, that it's not the same thing as what is named by the URI.  
> But neither URIs nor the other mechanisms associated with the web were 
> designed to work this way.  Trying to re-justify all of the existing 
> notations, protocols, and other infrastructure in terms of some more 
> abstract (and revisionist) idea of what URIs are, is silly, and has no 
> place in an organization that purports to do engineering.
Well, I disagree. But what is the purpose of this URN mailing list? I am 
not sure what you mean by "use URIs as pure names, ...". Can you define:

-- What is "a pure name"?
-- What is a network-accessible resource?

Is knowledge engineering what all of us ultimately want to do? If not, 
what is it? And if so, I guess that we cannot avoid these hard questions.

Xiaoshu

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Apr 2010 16:53:49 +0200

Keith,

> that it's not the same thing as what is named by the URI.  But neither

What's returned isn't the resource, but a representation of the resource.

> organization that purports to do engineering.

could you clarify whether you want to challenge this part of RFC 3986?

"When URIs are used within information retrieval systems to identify 
sources of information, the most common form of URI dereference is 
"retrieval": making use of a URI in order to retrieve a representation 
of its associated resource. A "representation" is a sequence of octets, 
along with representation metadata describing those octets, that 
constitutes a record of the state of the resource at the time when the 
representation is generated. Retrieval is achieved by a process that 
might include using the URI as a cache key to check for a locally cached 
representation, resolution of the URI to determine an appropriate access 
mechanism (if any), and dereference of the URI for the sake of applying 
a retrieval operation. Depending on the protocols used to perform the 
retrieval, additional information might be supplied about the resource 
(resource metadata) and its relation to other resources." -- 
<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.1.2.2.p.3>

?

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Apr 2010 12:24:39 -0400

On 4/28/10 10:42 AM, Xiaoshu Wang wrote:
>> But neither URIs nor the other mechanisms associated with the web
>> were designed to work this way.  Trying to re-justify all of the
>> existing notations, protocols, and other infrastructure in terms of
>> some more abstract (and revisionist) idea of what URIs are, is silly,
>> and has no place in an organization that purports to do engineering.
> Well, I disagree. But what is the purpose of this URN mailing list? I
> am not sure what you mean by "use URIs as pure names, ...". Can you
> define:
>
This is a term we were using many years ago in the original URN
discussions.   I never saw a formal definition of the term.  My best
attempt to define a pure name would be a name that isn't bound to
anything that exists in concrete or tangible form.  If it's bound to
anything, it's an abstract concept.   It's meaningless to speak of
de-referencing or accessing the resource associated with a pure name.
> -- What is a network-accessible resource?
It's a resource that can be accessed using the network.  If the resource
named by http://foo.com/bar.doc is a Microsoft Word document, and you
can download that resource from the indicated web site, it's a
network-accessible resource.  (Often the resource and the representation
really are the same thing.)
> what is it? And if so, I guess that we cannot avoid these hard questions.
I can't answer that question for others.  But I can confidently say that
trying to take an extremely widely deployed architecture and
infrastructure, and trying to redefine its behavior in a way that
conflicts with its design and widespread use, is unlikely to be
successful.   Ultimately our job here is to write specifications that
will be used to implement code that works consistently between
implementations and across the entire Internet.  We can't do that if
what we specify conflicts with widespread existing practice.  And when
we talk about using well-established protocols like http URIs or even
URNs in an abstract fashion that doesn't consider the huge body of
existing practice, it's hard to imagine that anything useful will come
of it.

Keith

---

From: Xiaoshu Wang <[email-masked]>
Date: Wed, 28 Apr 2010 12:35:22 -0400

On 4/28/10 12:24 PM, Keith Moore wrote:
>>> refer specifically to a network-accessible resource - and then to 
>>> say that if de-referencing the URI over the network happens to 
>>> return a resource, that it's not the same thing as what is named by 
>>> the URI.  But neither URIs nor the other mechanisms associated with 
>>> the web were designed to work this way.  Trying to re-justify all of 
>>> the existing notations, protocols, and other infrastructure in terms 
>>> of some more abstract (and revisionist) idea of what URIs are, is 
>>> silly, and has no place in an organization that purports to do 
>>> engineering.
If a name is bound to nothing. It is useless. Any name is bound with a 
*transportation* protocol. The names that we use in natural language is 
bound to our cognitive system. A pure name, in the sense that is not 
bound with any retrieval protocol, doesn't exist.
> It's a resource that can be accessed using the network.  If the 
> resource named by http://foo.com/bar.doc is a Microsoft Word document, 
> and you can download that resource from the indicated web site, it's a 
> network-accessible resource.  (Often the resource and the 
> representation really are the same thing.)
"http://foo.com/bar.doc" can be potentially bound with an HTML 
representation. What is this network-accessible resource? I can use 
"http://example.com/earth" to name the Earth. Is the earth 
network-accessible resource?
>> Is knowledge engineering what all of us ultimately want to do? If 
>> not, what is it? And if so, I guess that we cannot avoid these hard 
>> questions.
> I can't answer that question for others.  But I can confidently say 
> that trying to take an extremely widely deployed architecture and 
> successful. 
Who said there is a conflict? Isn't what I am trying to say is that: 
there is an ontological ground that there is not a conflict. But once 
you insist that reference and dereference are symmetric relation, it is 
this thesis that is heading to trouble.
> Ultimately our job here is to write specifications that will be used 
> to implement code that works consistently between implementations and 
> across the entire Internet.  We can't do that if what we specify 
> conflicts with widespread existing practice. 
Right. But who is doing that?
> And when we talk about using well-established protocols like http URIs 
> or even URNs in an abstract fashion that doesn't consider the huge 
> body of existing practice, it's hard to imagine that anything useful 
> will come of it.
You bring another ambiguous concept -- "abstraction" -- into discussion. 
Again, it will be your burden of proof to clarify the distinction.

Xiaoshu

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Apr 2010 13:58:05 -0400

On 4/28/10 12:35 PM, Xiaoshu Wang wrote:
>>>>> We have to understand that what a URI references is not the same
>>>>> as what is de-referenced from the URI.
>>>> the web were designed to work this way.  Trying to re-justify all
>>>> of the existing notations, protocols, and other infrastructure in
>>>> terms of some more abstract (and revisionist) idea of what URIs
>>>> are, is silly, and has no place in an organization that purports to
>>>> do engineering.
>>> Well, I disagree. But what is the purpose of this URN mailing list?
>>> I am not sure what you mean by "use URIs as pure names, ...". Can
>>> you define:
>>>
> *transportation* protocol. The names that we use in natural language
> is bound to our cognitive system. A pure name, in the sense that is
> not bound with any retrieval protocol, doesn't exist.
URNs are not bound to any retrieval protocol.  That's the entire point
of URNs - to allow resources to be named independently of their location
or the protocol used to access them.  That doesn't mean, of course, that
a URN is not bound to anything, just that it's not associated (as most
URLs are) with any particular location or retrieval protocol.

And just because a name isn't bound to anything that exists in concrete
or tangible form, doesn't mean it's useless.   We give names to ideas
all the time.
>> resource named by http://foo.com/bar.doc is a Microsoft Word
>> document, and you can download that resource from the indicated web
>> site, it's a network-accessible resource.  (Often the resource and
>> the representation really are the same thing.)
> representation. What is this network-accessible resource? 
It's not complicated.  If a resource can be accessed over the network,
it's a network-accessible resource.  

I cited a Microsoft Word document that has only one representation just
as a simple, concrete example.    A resource that has multiple
representations can still be network-accessible.  It's just that when
you make a distinction between resource and representation, you head
down a slippery slope to a place where the resource exists only in
abstract form and the only concrete realizations are "representations". 
At that ill-defined place, the "resource" is no longer network-accessible.
> I can use "http://example.com/earth" to name the Earth. Is the earth
Not unless you have some way to download the Earth over the network.
> you insist that reference and dereference are symmetric relation, it
> is this thesis that is heading to trouble.
The ontological ground might not produce a conflict in itself, but it
might conflict with widespread existing practice.   IETF's job is to
make things work well, not to get the philosophy right.
> Right. But who is doing that?
Well, if we talk about fragment identifiers and how they relate to base
URIs, and we end up defining the behavior in such a way that it's
inconsistent with existing widespread practice, it doesn't matter how
clean the philosophy is - it's still broken. 
>> And when we talk about using well-established protocols like http
>> URIs or even URNs in an abstract fashion that doesn't consider the
>> huge body of existing practice, it's hard to imagine that anything
>> useful will come of it.
> You bring another ambiguous concept -- "abstraction" -- into
> discussion. Again, it will be your burden of proof to clarify the
> distinction.
I beg your pardon?   I don't think I have to prove anything to you about
URNs.

Keith

---

From: Xiaoshu Wang <[email-masked]>
Date: Wed, 28 Apr 2010 14:18:18 -0400

On 4/28/10 1:58 PM, Keith Moore wrote:
>>>>> return a resource, that it's not the same thing as what is named 
>>>>> by the URI.  But neither URIs nor the other mechanisms associated 
>>>>> with the web were designed to work this way.  Trying to re-justify 
>>>>> all of the existing notations, protocols, and other infrastructure 
>>>>> in terms of some more abstract (and revisionist) idea of what URIs 
>>>>> are, is silly, and has no place in an organization that purports 
>>>>> to do engineering.
>> If a name is bound to nothing. It is useless. Any name is bound with 
>> a *transportation* protocol. The names that we use in natural 
>> language is bound to our cognitive system. A pure name, in the sense 
>> that is not bound with any retrieval protocol, doesn't exist.
> of URNs - to allow resources to be named independently of their 
> location or the protocol used to access them.  That doesn't mean, of 
> course, that a URN is not bound to anything, just that it's not 
> associated (as most URLs are) with any particular location or 
> retrieval protocol.
>
> And just because a name isn't bound to anything that exists in 
> concrete or tangible form, doesn't mean it's useless.   We give names 
> to ideas all the time.
> I cited a Microsoft Word document that has only one representation 
> just as a simple, concrete example.    A resource that has multiple 
> abstract form and the only concrete realizations are 
> "representations".  At that ill-defined place, the "resource" is no 
> longer network-accessible.
This is the logic behind the so-called "information resource", which no 
one can give a meaningful definition yet.
> Not unless you have some way to download the Earth over the network.
Again, you are implying that what a name references is the same as what 
is dereferenced from it. "http://example.com/earth" is a name referring 
to the Earth. Dereferencing it gets you a representation of the Earth, 
but not the Earth itself.

It is the same with your "Word Document" example. You never get *the* 
document, even if it is a single representation of it. At most, you get 
a copy of it.
> make things work well, not to get the philosophy right.
But isn't it because things does not work well that this URN mailing 
list is created?
>>> to implement code that works consistently between implementations 
>>> and across the entire Internet.  We can't do that if what we specify 
> Well, if we talk about fragment identifiers and how they relate to 
> base URIs, and we end up defining the behavior in such a way that it's 
So, you mean we should do things the old way, regardless if it is wrong 
or not? If that is the case, how science and technology advance?
> I beg your pardon?   I don't think I have to prove anything to you 
> about URNs.
You uses a lot of concepts, such as "abstract", "ideas", etc. in the 
dispute. But the truth is all these are philosophical debatable concept. 
My thesis is very simple: as long as we understand the asymmetry between 
reference and dereference, everything is clear. There is no need to 
bring in any other vaguely defined concepts, such as "abstraction", 
"information resource", and "ideas" etc. into the debate. Doing so 
doesn't help. It only brings more questions.

Xiaoshu

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Apr 2010 15:13:11 -0400

> Again, you are implying that what a name references is the same as
> what is dereferenced from it. 
I'm saying that there is an enormous body of existing practice for which
this is true, and there is a lot of dependence on this being true.

e.g. in many cases when you download a file using an http: URL, what you
require is not that you get some "representation" of the resource named
by that URL, but an exact copy of that resource.
> "http://example.com/earth" is a name referring to the Earth.
> Dereferencing it gets you a representation of the Earth, but not the
> Earth itself.
If you coin a URI you get to decide what that URI is bound to.  You get
to decide whether it refers to a very specific sequence of octets, or to
something a bit fuzzier.  But saying that you're coining a URI for the
Earth when the best you can ever hope to return is an extremely inexact
representation of it, seems grossly imprecise at best, and probably not
a good example on which to base a protocol engineering discussion.
> document, even if it is a single representation of it. At most, you
> get a copy of it.
Correct, you get an exact copy of it.   And of course, the distinction
between a copy of the resource and the resource pointed to by the URI is
important - e.g. if you change the copy, it doesn't change the resource
bound to the URI.
>>>>> not, what is it? And if so, I guess that we cannot avoid these
>>>>> hard questions.
>>> there is an ontological ground that there is not a conflict. But
>>> once you insist that reference and dereference are symmetric
>>> relation, it is this thesis that is heading to trouble.
I have yet to understand the specific reasons why this list was created,
other than to clean up a few very technical ambiguities and errata in
the existing URN specifications and in how they relate to other
specifications.   I'm not aware that these technical ambiguities or
errata have caused any significant operational problems, though of
course they might have.
>>>> Ultimately our job here is to write specifications that will be
>>>> used to implement code that works consistently between
>>>> implementations and across the entire Internet.  We can't do that
>>>> if what we specify conflicts with widespread existing practice.  
>> base URIs, and we end up defining the behavior in such a way that
>> it's inconsistent with existing widespread practice, it doesn't
>> matter how clean the philosophy is - it's still broken.
> So, you mean we should do things the old way, regardless if it is
> wrong or not? If that is the case, how science and technology advance?
I'm saying that the old way is not "wrong" merely because it conflicts
with your (or anyone else's) philosophy.  It's just different, and
perhaps less useful that it might have been if it were better designed
in the first place.  (or perhaps not).  The old way - the huge body of
widespread practice - is what it is, for better or worse.  We cannot
retroactively change existing behavior, and we have very little power to
affect the behavior of new implementations if those implementations
would act contrary to current widely-expected behavior.   

e.g. If you don't like the old way that existing fragment identifiers
work, it's too bad, you can't change it.  You might be able to get
someone to define a new kind of fragment identifier with a different
syntax.  (Though it probably wouldn't be within the scope of a new URI
working group.)
> dispute. But the truth is all these are philosophical debatable
> concept. My thesis is very simple: as long as we understand the
> asymmetry between reference and dereference, everything is clear. 
Well, I think it's confusing to use "reference" to refer to the creation
of a binding from a URI to a resource, and "dereference" to refer to the
obtaining of a copy (or representation) of that resource given the URI. 
But of course these are two distinct operations. 
> There is no need to bring in any other vaguely defined concepts, such
> as "abstraction", "information resource", and "ideas" etc. into the
> debate. Doing so doesn't help. It only brings more questions.
I want the discussion to be grounded in technical reality - what a URI
means in terms of what you can do with it on the network, and when
appropriate, what it means in terms of specific protocol interactions.  
And part of that technical reality is that we're mostly stuck with
existing practice, even if the model isn't as ideologically pure as some
of us like.

Keith

---

From: Xiaoshu Wang <[email-masked]>
Date: Wed, 28 Apr 2010 16:33:22 -0400

On 4/28/10 3:13 PM, Keith Moore wrote:
>
>>>> I can use "http://example.com/earth" to name the Earth. Is the 
>>>> earth network-accessible resource?
> I'm saying that there is an enormous body of existing practice for 
> which this is true, and there is a lot of dependence on this being true.
>
> e.g. in many cases when you download a file using an http: URL, what 
> you require is not that you get some "representation" of the resource 
> named by that URL, but an exact copy of that resource.
It is an implicit assumption. But I do not believe that it is true or it 
has to be true. Such a problem never occur in other information system, 
such as the traditional file system because there is a one-to-one 
relationship. This is what I believe what HTTP protocol excels compared 
with any other known information systems. It mirrors the reality that we 
live in. An apple is not that streams of photons that strike your eyes 
or the smells that touches your nose.  These are merely some 
representations of the apple. It is your cognition that makes you 
believe it is an apple or not.
> If you coin a URI you get to decide what that URI is bound to.  You 
> get to decide whether it refers to a very specific sequence of octets, 
> or to something a bit fuzzier.  But saying that you're coining a URI 
> for the Earth when the best you can ever hope to return is an 
> extremely inexact representation of it, seems grossly imprecise at 
> best, and probably not a good example on which to base a protocol 
> engineering discussion.
Nope. Let me repeat that. A URI does not necessarily refer to a sequence 
of octets stream. Of course, we can make them to. But that requires more 
information. Again, you use some ambiguous words -- "extremely inexact", 
please define it.

Say, http://www.w3.org, do you believe that there is an exact copy of 
what you see from your browser? Does it matter? The same with your Word 
Doc example! Exact or in-exact, what is it compared to? And by which 
criteria?

> between a copy of the resource and the resource pointed to by the URI 
> is important - e.g. if you change the copy, it doesn't change the 
> resource bound to the URI.
>>>>> I can't answer that question for others.  But I can confidently 
>>>>> say that trying to take an extremely widely deployed architecture 
>>>>> and infrastructure, and trying to redefine its behavior in a way 
>>>>> that conflicts with its design and widespread use, is unlikely to 
>>>>> be successful. 
>>>> Who said there is a conflict? Isn't what I am trying to say is 
>>>> that: there is an ontological ground that there is not a conflict. 
>>>> But once you insist that reference and dereference are symmetric 
>>> The ontological ground might not produce a conflict in itself, but 
>>> it might conflict with widespread existing practice.   IETF's job is 
>>> to make things work well, not to get the philosophy right.
> I have yet to understand the specific reasons why this list was 
> created, other than to clean up a few very technical ambiguities and 
> errata in the existing URN specifications and in how they relate to 
> other specifications.   I'm not aware that these technical ambiguities 
> or errata have caused any significant operational problems, though of 
> course they might have.
> retroactively change existing behavior, and we have very little power 
> to affect the behavior of new implementations if those implementations 
It is not just different. It carries an implicit assumption that we take 
for granted. That is where the wrong lies. There isn't a problem in the 
past because most information system, there is a one-to-one relationship 
between the identifier and representation. Thus, we never bothered or 
dared to use those identifier to reference anything-else.
> syntax.  (Though it probably wouldn't be within the scope of a new URI 
I think the purpose is to clarify the issue. It is to understand where 
or what kind of assumption that leads to the conflict. I think new URI 
specification (RFC 3986) makes an attempt to undistinguish URN from URL. 
Thus, if this group is interested in revise URN, the first purpose is to 
understand what a name is and its relationship to transportation 
protocol or URL, right?
> Well, I think it's confusing to use "reference" to refer to the 
> creation of a binding from a URI to a resource, and "dereference" to 
> refer to the obtaining of a copy (or representation) of that resource 
> given the URI.  But of course these are two distinct operations.
What is the confusion?
URI -- references --> A Resource
URI -- dereferenced_to --> A Representation
And Resource != Representation

Isn't that simple and clear enough?
> appropriate, what it means in terms of specific protocol 
> interactions.   And part of that technical reality is that we're 
> mostly stuck with existing practice, even if the model isn't as 
> ideologically pure as some of us like.
Are you talking about URN or URL or just URI? As you said, URN should 
not be bound with any protocol or network. Then, how we should ever 
discuss that. If we talked about it, then there is a binding 
somewhere/somehow, right? Then, a URN isn't "technically" a URN. It is 
still a URL.

On the other side, I do believe that we should have a URN. But my 
suggestion is that we need only one set URN but not many. And the 
binding should be kept in human knowledge as opposed to be defined in a 
protocol.

I think we need a URN, which I called it schemeless URN. Take 
http://example.com/earth as an example. The URN should be

//example.com/earth

And this URN can be bound with any transportation protocol, such as 
HTTP, HTTPS, FTP etc., which all should lead to some representations 
consistent with the intension of "//example.com/earth". The purpose is 
to maintain the URN's stability as the Web advances while new protocols 
are developed. Currently, HTTP can be considered the de fault bootstrap 
protocol. But 100 years from now, it could be a different "de fault" 
protocol, yet the usage of "//example.com/earth" remains stable.

Xiaoshu

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Apr 2010 19:05:22 -0400

On 4/28/10 4:33 PM, Xiaoshu Wang wrote:
> It is an implicit assumption. But I do not believe that it is true or
> it has to be true.
For some uses of the HTTP protocol and http: URLs, it absolutely has to
be true.
> Such a problem never occur in other information system, such as the
> traditional file system because there is a one-to-one relationship.
> This is what I believe what HTTP protocol excels compared with any
> other known information systems. It mirrors the reality that we live in. 
I don't know about your reality, but in the reality that I live in, I
need for protocols to work predictably.
> An apple is not that streams of photons that strike your eyes or the
> smells that touches your nose.  These are merely some representations
> of the apple. It is your cognition that makes you believe it is an
> apple or not.
The intended purpose of URNs is not to name fruits.  It is to name
network-accessible resources.
>> get to decide whether it refers to a very specific sequence of
>> octets, or to something a bit fuzzier.  But saying that you're
>> coining a URI for the Earth when the best you can ever hope to return
>> is an extremely inexact representation of it, seems grossly imprecise
>> at best, and probably not a good example on which to base a protocol
>> engineering discussion.
> Nope. Let me repeat that. A URI does not necessarily refer to a
> sequence of octets stream. 
Correct so far (except for the "Nope"), and this is consistent with what
I wrote above.
> Of course, we can make them to. But that requires more information.
It doesn't require more explicit information.    Either the origin
server acts predictably or it doesn't.  
> Again, you use some ambiguous words -- "extremely inexact", please
> define it.
I'm using the words in their usual sense.
> what you see from your browser? Does it matter? The same with your
> Word Doc example! Exact or in-exact, what is it compared to? And by
> which criteria?
Every single day, the vast majority of the files that I download need to
be exact copies of what is on the origin server.
>> I'm saying that the old way is not "wrong" merely because it
>> conflicts with your (or anyone else's) philosophy.  It's just
>> different, and perhaps less useful that it might have been if it were
>> better designed in the first place.  (or perhaps not).  The old way -
>> the huge body of widespread practice - is what it is, for better or
>> worse.  We cannot retroactively change existing behavior, and we have
>> very little power to affect the behavior of new implementations if
>> those implementations would act contrary to current widely-expected
>> behavior.   
> It is not just different. It carries an implicit assumption that we
> take for granted.
So make it explicit.   That's fine.   But don't try to change widespread
existing behavior even if you don't think it works as well as it should.
> That is where the wrong lies. There isn't a problem in the past
> because most information system, there is a one-to-one relationship
That was, in many cases, a feature.
>> syntax.  (Though it probably wouldn't be within the scope of a new
>> URI working group.)
> specification (RFC 3986) makes an attempt to undistinguish URN from
> URL. Thus, if this group is interested in revise URN, the first
> purpose is to understand what a name is and its relationship to
> transportation protocol or URL, right?
IMO, there should not be a group to "revise" URNs.   At most, the group
should remove ambiguities and correct errata that are present in the
existing specifications.
>>>>>> URIs or even URNs in an abstract fashion that doesn't consider
>>>>>> the huge body of existing practice, it's hard to imagine that
>>>>>> anything useful will come of it.
No, it's incorrect in lots of very subtle ways.  
>>> There is no need to bring in any other vaguely defined concepts,
>>> such as "abstraction", "information resource", and "ideas" etc. into
>>> the debate. Doing so doesn't help. It only brings more questions.
>> I want the discussion to be grounded in technical reality - what a
>> URI means in terms of what you can do with it on the network, and
>> when appropriate, what it means in terms of specific protocol
> Are you talking about URN or URL or just URI? 
I'm trying to use each term as appropriate.
> As you said, URN should not be bound with any protocol or network.
> Then, how we should ever discuss that. If we talked about it, then
> there is a binding somewhere/somehow, right? Then, a URN isn't
> "technically" a URN. It is still a URL.
Of course the URN can be bound to access protocols, server addresses,
etc.   It's just that the binding isn't exposed in the URN itself.  It's
allowed to change over time.
> binding should be kept in human knowledge as opposed to be defined in
> a protocol.
>
I strongly object to your or anyone else's efforts to change
well-established standards and practice regarding URNs.   Those should
be entirely out of scope for this working group. 

Keith

---

From: Xiaoshu Wang <[email-masked]>
Date: Wed, 28 Apr 2010 19:55:59 -0400

On 4/28/10 7:05 PM, Keith Moore wrote:
>>> you require is not that you get some "representation" of the 
>>> resource named by that URL, but an exact copy of that resource.
> For some uses of the HTTP protocol and http: URLs, it absolutely has 
> to be true.
Really? Show me an example that if they do not take that assumption, it 
will fail.
> network-accessible resources.
Most people that I work with, they want names for genes, proteins, 
molecules, diseases, etc. But again, these can be network-accessible 
resources as you have not given me a definition that I can tell one from 
others.
>>>> Dereferencing it gets you a representation of the Earth, but not 
>>>> the Earth itself.
>>> coining a URI for the Earth when the best you can ever hope to 
>>> return is an extremely inexact representation of it, seems grossly 
>>> imprecise at best, and probably not a good example on which to base 
>>> a protocol engineering discussion.
> Correct so far (except for the "Nope"), and this is consistent with 
> what I wrote above.
Predictably with regard of what? If "http://example.com/aThing" names a 
thing, what do you expect it to be? How do you measure this 
predictability? Thus, getting back your early question, how do you 
measure failure? Please explicit your criteria.
> I'm using the words in their usual sense.
That is what you mean a technical definition?
> Every single day, the vast majority of the files that I download need 
> to be exact copies of what is on the origin server. 
Is Resources == Files? What is that you downloaded? Resource or 
Representation?
>>>>>>> implementations and across the entire Internet.  We can't do 
>>>>>>> that if what we specify conflicts with widespread existing 
>>>>>>> practice. 
>>> different, and perhaps less useful that it might have been if it 
>>> were better designed in the first place.  (or perhaps not).  The old 
>>> way - the huge body of widespread practice - is what it is, for 
>>> better or worse.  We cannot retroactively change existing behavior, 
>>> and we have very little power to affect the behavior of new 
>>> implementations if those implementations would act contrary to 
>>> current widely-expected behavior.
> So make it explicit.   That's fine.   But don't try to change 
> widespread existing behavior even if you don't think it works as well 
> as it should.
What is the widespread existing behavior that any of these will change? 
First, I don't think there is anything that will be changed. It just 
makes people to think/describe things more clearly. Second, even if it 
requires changes, if it is for a better world, why not?
> That was, in many cases, a feature.
A feature of ?
>>> e.g. If you don't like the old way that existing fragment 
>>> identifiers work, it's too bad, you can't change it.  You might be 
>>> able to get someone to define a new kind of fragment identifier with 
>>> a different syntax.  (Though it probably wouldn't be within the 
>>> scope of a new URI working group.)
>> I think the purpose is to clarify the issue. It is to understand 
>> where or what kind of assumption that leads to the conflict. I think 
>> new URI specification (RFC 3986) makes an attempt to undistinguish 
>> URN from URL. Thus, if this group is interested in revise URN, the 
>> first purpose is to understand what a name is and its relationship to 
> IMO, there should not be a group to "revise" URNs.   At most, the 
> group should remove ambiguities and correct errata that are present in 
> the existing specifications.
Then, what is the errata?
>>>>>>> And when we talk about using well-established protocols like 
>>>>>>> http URIs or even URNs in an abstract fashion that doesn't 
>>>>>>> consider the huge body of existing practice, it's hard to 
>>>>>>> imagine that anything useful will come of it.
>>>> You uses a lot of concepts, such as "abstract", "ideas", etc. in 
>>>> the dispute. But the truth is all these are philosophical debatable 
>>> refer to the obtaining of a copy (or representation) of that 
>>> resource given the URI.  But of course these are two distinct 
>>> operations.
>> What is the confusion?
Tell me where it is wrong. The reverse would be: dereference = reference 
or Resource = Representation. If this is your plea, you will have a very 
huge gap to bridge -- The DeCartian Gap.
>>>> such as "abstraction", "information resource", and "ideas" etc. 
>>>> into the debate. Doing so doesn't help. It only brings more questions.
> etc.   It's just that the binding isn't exposed in the URN itself.  
> It's allowed to change over time.
Does it really matter if the protocol is exposed in URN or not? Have we 
ever prefixed a file-path with anything? But is file name is locator or 
name or identifier?
> be entirely out of scope for this working group.
I didn't want to change anything. I think the new URI spec is good to 
not make a distinction between URN and URL. What I mean is if we need a 
URN, we should only define only one set of URN and to make it a name, do 
not bind it (i.e., a via specification) with any transportation 
protocol. That would make it a pure (technically) name.

Otherwise, as long as a specification is defined to bind a particularly 
schemed URN to some transportation protocol, then it is no different 
from a URL. Or, if no binding whatsoever, the name is practically 
useless.  It is as simple as that.

Xiaoshu

---

From: Ted Hardie <[email-masked]>
Date: Wed, 28 Apr 2010 17:52:17 -0700

Howdy,

This is top posted, rather than in-line because it is a meta point.

The text of RFC 2141 includes this:

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers and are designed to make
   it easy to map other namespaces (which share the properties of URNs)
   into URN-space.

The mechanism used to signal that something is a URN (and therefore is
intended to have these properties) is to use the URN scheme and a
namespace identifier, which in turn indicates how those properties are
achieved (commonly with an organization managing the namespace).

If there are other properties desired, other URI schemes may be more
appropriate choices.    There are 40 defined URN namsepaces in use now,
and the principle of least surprise says that we need to make sure any
changes this group might make to the documents does not violate the
expectations on
which they have built their systems.  You might note, for example, that
the XMPP namespaces that use URNs include at least one with a fragment
identifier:

http://xmpp.org/registrar/namespaces.html

While we might include information for  namespace authorities about how
best to use these, taking the tack now that they are not permitted is
inappropriate
because it would violate the persistence principle inherent in URNs.

Generalizing that a bit, I suspect that a group working on URN-related documents
can update the language and BNF and can make sure the registration procedures
are clear, but it has to have limited scope.  Any basic change to syntax
or semantics has the potential for impact on the namespaces already in use;
anything that does that has to be a non-starter because of the need to maintain
a consistency.

Just my take on it, of course.

regards,

Ted Hardie

On Wed, Apr 28, 2010 at 4:55 PM, Xiaoshu Wang <[email-masked]> wrote:
> Again, you are implying that what a name references is the same as what is
> dereferenced from it.
>
> require is not that you get some "representation" of the resource named by
> that URL, but an exact copy of that resource.
>
> It is an implicit assumption. But I do not believe that it is true or it has
> to be true.
>
> For some uses of the HTTP protocol and http: URLs, it absolutely has to be
> true.
>
> Really? Show me an example that if they do not take that assumption, it will
> fail.
>
> traditional file system because there is a one-to-one relationship. This is
> what I believe what HTTP protocol excels compared with any other known
> information systems. It mirrors the reality that we live in.
>
> I don't know about your reality, but in the reality that I live in, I need
> for protocols to work predictably.
>
> An apple is not that streams of photons that strike your eyes or the smells
> that touches your nose.  These are merely some representations of the apple.
> It is your cognition that makes you believe it is an apple or not.
>
> "http://example.com/earth" is a name referring to the Earth. Dereferencing
> it gets you a representation of the Earth, but not the Earth itself.
>
> If you coin a URI you get to decide what that URI is bound to.  You get to
> decide whether it refers to a very specific sequence of octets, or to
> something a bit fuzzier.  But saying that you're coining a URI for the Earth
> when the best you can ever hope to return is an extremely inexact
> representation of it, seems grossly imprecise at best, and probably not a
> good example on which to base a protocol engineering discussion.
>
> Nope. Let me repeat that. A URI does not necessarily refer to a sequence of
> octets stream.
>
> Correct so far (except for the "Nope"), and this is consistent with what I
> wrote above.
>
> It doesn't require more explicit information.    Either the origin server
> acts predictably or it doesn't.
>
> thing, what do you expect it to be? How do you measure this predictability?
> Thus, getting back your early question, how do you measure failure? Please
> explicit your criteria.
>
> Again, you use some ambiguous words -- "extremely inexact", please define
> it.
>
> Say, http://www.w3.org, do you believe that there is an exact copy of what
> you see from your browser? Does it matter? The same with your Word Doc
> example! Exact or in-exact, what is it compared to? And by which criteria?
>
> Every single day, the vast majority of the files that I download need to be
> exact copies of what is on the origin server.
>
> Ultimately our job here is to write specifications that will be used to
> implement code that works consistently between implementations and across
> the entire Internet.  We can't do that if what we specify conflicts with
> widespread existing practice.
>
> inconsistent with existing widespread practice, it doesn't matter how clean
> the philosophy is - it's still broken.
>
> So, you mean we should do things the old way, regardless if it is wrong or
> not? If that is the case, how science and technology advance?
>
> I'm saying that the old way is not "wrong" merely because it conflicts with
> your (or anyone else's) philosophy.  It's just different, and perhaps less
> useful that it might have been if it were better designed in the first
> place.  (or perhaps not).  The old way - the huge body of widespread
> practice - is what it is, for better or worse.  We cannot retroactively
> change existing behavior, and we have very little power to affect the
> behavior of new implementations if those implementations would act contrary
> to current widely-expected behavior.
>
> It is not just different. It carries an implicit assumption that we take for
> granted.
>
> First, I don't think there is anything that will be changed. It just makes
> people to think/describe things more clearly. Second, even if it requires
> changes, if it is for a better world, why not?
>
> That is where the wrong lies. There isn't a problem in the past because most
> information system, there is a one-to-one relationship between the
> identifier and representation. Thus, we never bothered or dared to use those
> identifier to reference anything-else.
>
> e.g. If you don't like the old way that existing fragment identifiers work,
> it's too bad, you can't change it.  You might be able to get someone to
> define a new kind of fragment identifier with a different syntax.  (Though
> it probably wouldn't be within the scope of a new URI working group.)
>
> I think the purpose is to clarify the issue. It is to understand where or
> what kind of assumption that leads to the conflict. I think new URI
> understand what a name is and its relationship to transportation protocol or
> URL, right?
>
> And when we talk about using well-established protocols like http URIs or
> even URNs in an abstract fashion that doesn't consider the huge body of
> existing practice, it's hard to imagine that anything useful will come of
> it.
>
> dispute. But the truth is all these are philosophical debatable concept. My
> thesis is very simple: as long as we understand the asymmetry between
> reference and dereference, everything is clear.
>
> Well, I think it's confusing to use "reference" to refer to the creation of
> a binding from a URI to a resource, and "dereference" to refer to the
> obtaining of a copy (or representation) of that resource given the URI.  But
> of course these are two distinct operations.
>
> What is the confusion?
> Tell me where it is wrong. The reverse would be: dereference = reference or
> Resource = Representation. If this is your plea, you will have a very huge
> gap to bridge -- The DeCartian Gap.
>
> There is no need to bring in any other vaguely defined concepts, such as
> "abstraction", "information resource", and "ideas" etc. into the debate.
> Doing so doesn't help. It only brings more questions.
>
> I want the discussion to be grounded in technical reality - what a URI means
> in terms of what you can do with it on the network, and when appropriate,
> what it means in terms of specific protocol interactions.   And part of that
> technical reality is that we're mostly stuck with existing practice, even if
> the model isn't as ideologically pure as some of us like.
>
> As you said, URN should not be bound with any protocol or network. Then, how
> we should ever discuss that. If we talked about it, then there is a binding
> somewhere/somehow, right? Then, a URN isn't "technically" a URN. It is still
> a URL.
>
> Of course the URN can be bound to access protocols, server addresses, etc.
> It's just that the binding isn't exposed in the URN itself.  It's allowed to
> change over time.
>
> Does it really matter if the protocol is exposed in URN or not? Have we ever
> prefixed a file-path with anything? But is file name is locator or name or
> identifier?
>
> On the other side, I do believe that we should have a URN. But my suggestion
> is that we need only one set URN but not many. And the binding should be
> kept in human knowledge as opposed to be defined in a protocol.
>
> well-established standards and practice regarding URNs.   Those should be
> entirely out of scope for this working group.
>
> I didn't want to change anything. I think the new URI spec is good to not
> make a distinction between URN and URL. What I mean is if we need a URN, we
> should only define only one set of URN and to make it a name, do not bind it
> (i.e., a via specification) with any transportation protocol. That would
> make it a pure (technically) name.
>
> schemed URN to some transportation protocol, then it is no different from a
> URL. Or, if no binding whatsoever, the name is practically useless.  It is
> as simple as that.
>
> Xiaoshu
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Apr 2010 22:37:55 -0400

On 4/28/10 7:55 PM, Xiaoshu Wang wrote:
>>>> e.g. in many cases when you download a file using an http: URL,
>>>> what you require is not that you get some "representation" of the
>>> It is an implicit assumption. But I do not believe that it is true
>>> or it has to be true.
> Really? Show me an example that if they do not take that assumption,
> it will fail.
downloading any encrypted or cryptographically signed resource.  another
example: executable code. 
> molecules, diseases, etc. 
Perhaps URNs were not intended to solve those people's naming problems? 
If they can be used for those purposes without violating the design of
URNs, fine, but that's not a justification for changing the design. 
Especially when using URNs in a way that is contrary to their design
dilutes the intended utility of URNs.
> But again, these can be network-accessible resources as you have not
> given me a definition that I can tell one from others.
actually, I have.    well, maybe you can't tell, but the distinction exists.
> Predictably with regard of what? If "http://example.com/aThing" names
> a thing, what do you expect it to be?
It's whatever the origin server named by example.com (at port 80)
returns when given a GET request for /aThing.
> Thus, getting back your early question, how do you measure failure?
> Please explicit your criteria.
I'm not going to play this game with you. 
>>> Say, http://www.w3.org, do you believe that there is an exact copy
>>> of what you see from your browser? Does it matter? The same with
>>> your Word Doc example! Exact or in-exact, what is it compared to?
>>> And by which criteria?
A file is one kind of resource.  Most of the resources I access via the
web are files.  Most of the time, I need exact copies of those files.
> What is the widespread existing behavior that any of these will
> change? First, I don't think there is anything that will be changed.
> It just makes people to think/describe things more clearly. 
It's all well and good to clarify things.
> Second, even if it requires changes, if it is for a better world, why
> not?
Because it won't work.  You can't specify significant changes to the way
URNs work without breaking them.  That and who is to say that your idea
of a better world is really better?
>>> between the identifier and representation. Thus, we never bothered
>>> or dared to use those identifier to reference anything-else.
simplicity.  robustness.  predictability.  interoperability. 
>> group should remove ambiguities and correct errata that are present
>> in the existing specifications.
I don't know.  But if any are identified, we should of course try to
correct them.

>>>>>>> discussion. Again, it will be your burden of proof to clarify
>>>>>>> the distinction.
>>>>>> I beg your pardon?   I don't think I have to prove anything to
>>>>>> you about URNs.
>>>>> the dispute. But the truth is all these are philosophical
>>>>> debatable concept. My thesis is very simple: as long as we
>>>>> understand the asymmetry between reference and dereference,
>>>>> everything is clear. 
>>>> creation of a binding from a URI to a resource, and "dereference"
>>>> to refer to the obtaining of a copy (or representation) of that
> Tell me where it is wrong. The reverse would be: dereference =
> reference or Resource = Representation. If this is your plea, you will
> have a very huge gap to bridge -- The DeCartian Gap.
Offhand, I don't know how to describe this in terms that you will
understand.
> Does it really matter if the protocol is exposed in URN or not? 
If you have to ask that question, then you clearly don't understand
either the purpose or the design of URNs.
>>> binding should be kept in human knowledge as opposed to be defined
>>> in a protocol.
>>>
>> well-established standards and practice regarding URNs.   Those
>> should be entirely out of scope for this working group. 
> not make a distinction between URN and URL.
Perhaps the distinction doesn't belong in the URI spec, as it might
properly be out of scope for that document.  But the distinction still
exists.
> What I mean is if we need a URN, we should only define only one set of
> URN and to make it a name, do not bind it (i.e., a via specification)
> with any transportation protocol. That would make it a pure
> (technically) name.
Have you even read the URN specifications?

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Apr 2010 22:41:40 -0400

> anything that does that has to be a non-starter because of the need to maintain
seems entirely reasonable.

Keith

---

From: Xiaoshu Wang <[email-masked]>
Date: Thu, 29 Apr 2010 06:54:08 -0400

On 4/28/10 10:37 PM, Keith Moore wrote:
> downloading any encrypted or cryptographically signed resource.  
> another example: executable code.
Change the word "resource" to representation, anything breaks?
> Perhaps URNs were not intended to solve those people's naming 
> problems?  If they can be used for those purposes without violating 
> the design of URNs, fine, but that's not a justification for changing 
> the design.  Especially when using URNs in a way that is contrary to 
> their design dilutes the intended utility of URNs.
Changing what design?
> actually, I have.    well, maybe you can't tell, but the distinction 
This is the problem. Everyone has its own distinction but no standard one.
>>>>> If you coin a URI you get to decide what that URI is bound to.  
>>>>> You get to decide whether it refers to a very specific sequence of 
>>>>> imprecise at best, and probably not a good example on which to 
>>>>> base a protocol engineering discussion.
Then, what is not predictable?
>>> Every single day, the vast majority of the files that I download 
>>> need to be exact copies of what is on the origin server. 
> A file is one kind of resource.  Most of the resources I access via 
> the web are files.  Most of the time, I need exact copies of those files.
Most of the resources you accesses are web servers, which backend is a 
process. What you received is a file.
> Because it won't work.  You can't specify significant changes to the 
> way URNs work without breaking them.  That and who is to say that your 
> idea of a better world is really better?

> simplicity.  robustness.  predictability.  interoperability.
Sigh....you just make claim, never use an example to justify it. I or 
anyonelse can do the same. That doesn't help persuade people's opinion.
>> reference or Resource = Representation. If this is your plea, you 
>> will have a very huge gap to bridge -- The DeCartian Gap.
>>> Of course the URN can be bound to access protocols, server 
>>> addresses, etc.   It's just that the binding isn't exposed in the 
>>> URN itself.  It's allowed to change over time.
Do you think that is the way that an IETF recommendation should be 
written? To define a protocol for something that they cannot define?
>> What I mean is if we need a URN, we should only define only one set 
>> of URN and to make it a name, do not bind it (i.e., a via 
>> specification) with any transportation protocol. That would make it a 
>> pure (technically) name.
Of course, I do.

Xiaoshu

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Apr 2010 13:47:20 +0200

> because it would violate the persistence principle inherent in URNs.

To me, the important thing to clarify is that URNs are compatible with 
the generic URI format, thus, the first "#" character *always* starts a 
fragment identifier, and, consequently, if you need a "#" in the NSS 
(nanespace specific string), it needs to be percent-escaped.

I *believe* everybody agrees on that, but checking doesn't hurt.

That being said, what a fragid in a URN *means* is an orthogonal 
question. We can both point out that for now it may be a bad idea to 
rely on it, without actually breaking the cases where they are already used.

Best regards, Julian

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 29 Apr 2010 20:56:25 +0900

Hello Ted,

> http://xmpp.org/registrar/namespaces.html

That would be urn:xmpp:langtrans#items.

> because it would violate the persistence principle inherent in URNs.

Given what RFC 3986 says, it would definitely be difficult to prohibit 
using fragment identifiers on URI starting with "uri:" (i.e. URNs). But 
what Keith was wondering was whether the various properties that the URN 
spec says hold for URNs also hold if there is a fragment identifier 
attached to one of them. Although in the above single case, that 
probably wouldn't be a problem, I think it's difficult to guarantee this 
in general.

I think people who want some extension to URN syntax but want to make 
sure it can be handled by resolution infrastructure in the most 
'persistent' way should use something else than fragment identifiers. 
The reason is not only that fragment identifiers depend on the type of 
the returned resource, but also, or even much more, that fragment 
identifiers get resolved locally, not sent over the network. So e.g. if 
you want to create some persistent identifier for e.g some part of a 
book, but you want to make that book available in various 
representations, in some of which the identified part is a single 
entity, whereas in others it's a part of a file or it's several files, 
then you should either try with e.g. with a specific syntax extension or 
with a query syntax, not with a fragment identifier.

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Thu, 29 Apr 2010 07:25:55 -0700

On Thu, Apr 29, 2010 at 4:47 AM, Julian Reschke <[email-masked]> wrote:
> To me, the important thing to clarify is that URNs are compatible with the
> generic URI format, thus, the first "#" character *always* starts a fragment
> identifier, and, consequently, if you need a "#" in the NSS (nanespace
> specific string), it needs to be percent-escaped.
>

I agree with this.

>
> That being said, what a fragid in a URN *means* is an orthogonal question.
> We can both point out that for now it may be a bad idea to rely on it,
> without actually breaking the cases where they are already used.
>
>> ...

Well, I think the presence of an unescaped # in a URN has whatever
semantic meaning the namespace authority says it does.  As long is
it doesn't break the URN properties (persistence, chiefly) and
matches the URI syntax, the semantics can vary from namespace to
namespace.

Just my opinion, of course,

regards,

Ted

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Apr 2010 16:34:18 +0200

> matches the URI syntax, the semantics can vary from namespace to

So, looking at RFC 2141, Section 2.3.2 
(<http://tools.ietf.org/html/rfc2141#section-2.3.2>):

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

I think this needs to change (for "#") to say "MUST NOT". Otherwise the 
spec would give the impression that there are legitimate cases where a 
"#" can appear in the NSS.

Best regards, Julian

---

From: Ted Hardie <[email-masked]>
Date: Thu, 29 Apr 2010 07:40:18 -0700

> Hello Ted,
 You might note, for example, that
> That would be urn:xmpp:langtrans#items.

Yes.

> Given what RFC 3986 says, it would definitely be difficult to prohibit using
> fragment identifiers on URI starting with "uri:" (i.e. URNs). But what Keith
> was wondering was whether the various properties that the URN spec says hold
> for URNs also hold if there is a fragment identifier attached to one of
> them. Although in the above single case, that probably wouldn't be a
> problem, I think it's difficult to guarantee this in general.
>

Well, as I said in my reply to Julian, I think the semantics of
fragment identifiers
is up to the individual namespace authorities.  But I think the properties are
not.  If you are a namespace authority, you are signing up to mint URNs
that have the properties described in RFC 2141.  You have a syntax in which
to do that, and that includes fragment identifiers.  But if you wish to mint
and identifier which does not have those properties (because it is unique to
a specific format, for example), then you should mint it with some
other identifier
scheme.  We have several available already (tag, to take the most obvious)
and we could create more if needed.

> I think people who want some extension to URN syntax but want to make sure
> it can be handled by resolution infrastructure in the most 'persistent' way
> should use something else than fragment identifiers. The reason is not only
> that fragment identifiers depend on the type of the returned resource, but
> also, or even much more, that fragment identifiers get resolved locally, not
> sent over the network. So e.g. if you want to create some persistent
> identifier for e.g some part of a book, but you want to make that book
> available in various representations, in some of which the identified part
> is a single entity, whereas in others it's a part of a file or it's several
> files, then you should either try with e.g. with a specific syntax extension
> or with a query syntax, not with a fragment identifier.
>

If I am understanding you correctly, a persistent identifier in the
"parts of the book"
example like #chapter7 makes sense to me, because that identifier relates to
an internal structural component that is itself persistent.  An example like
#pp77-90 does not, because the number of pages may vary in different
representations.  If there is no internal structural element that can be used
to identify pages 77-90, I would personally say that some real thought
should be put into the question of whether or not a URN is the right type
of identifier for this.  Using one of the other available types might be
better, even if a URN is the right type for the book itself or even the book
and its chapters.

I have not thought in a long while about what query syntax might mean here,
though, and I'll have think about that some more.

regards,

Ted