Subject: [urn] Some observations to add to the discussion

From: [email-masked] (Dale R. Worley)
Date: Thu, 3 Jul 2014 14:53:18 -0400

I was thinking about the question of "fragments" and URNs and realized
that we already use them:

	Dante's Inferno, Canto XXV

As was stated in that W3C document that someone referred to, what makes
this work as a fragment reference is that all manifestations of the
resource resolve the fragment identifier to the semantically
equivalent "part" of the resource.  (Regardless of what language it
has been translated to!)

Which led me back to realizing that we now identify parts of scholarly
works by page numbers because of printing -- the work exists in a vast
number of copies that place the words on the pages in the same way.
Back in the manuscript era, a page number was not consistent from copy
to copy, only chapter and section identifiers.

In fact, with printing, we get to the point where we don't give names
to individual copies; we only give ISBNs to entire editions of a work,
because the individual copies are interchangeable for almost all
purposes.

In regard to rebuilld the syntax of URNs from scratch, I can
understand why one would want to do that.  But there is no reason we
can't embed URNngs as a NID of URNs (assuming that they're a sequence
of Unicode characters) by generous use of %-escapes:
urn:ng:%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx.  That doesn't provide
anything other than making them "syntactically interoperable" with
existing URIs, but syntactic interoperability is a desirable feature.

Dale

---

From: Juha Hakala <[email-masked]>
Date: Fri, 04 Jul 2014 13:37:53 +0300

Hi,

> 	Dante's Inferno, Canto XXV

These are what we have called logical fragment in the URNBIS (and 
component parts in libraries).

We have agreed earlier that URN namespaces may have their own principles 
of identification regarding the logical fragments. For instance, ISBN 
system allows assignment of ISBNs to logical fragments if they are for 
sale inedividually. Physical fragments (encoding of the document) may or 
may not have anything to do with the logical structure of the document. 
Inferno can be published as text file with no structure in it (see 
http://www.gutenberg.org/files/1001/1001-h/1001-h.htm).

Component parts are essential in description of e.g. music and journals. 
And there can be more than two levels. A journal has volumes, issues and 
articles, and articles may have e.g. images that should be described 
independently.

> to copy, only chapter and section identifiers.

The Bible (or Quran) are also good examples of resources where page 
numbers are still not used in references. There are so many editions and 
translations that my pages most likely would not be the same as yours.

So far, many e-books are faithful copies of printed ones in PDF or some 
other suitable file format. But new formats like EPUB 3 - in which 
layout will change depending on whether the reader uses a PC, tablet, 
mobile or something else -  mean that before long it may not make sense 
to talk about pages any more, and it may be necessary to go back to the 
old practice of encoding the logical structure of the work into the 
document itself in much greater detail that we have been doing lately.

> because the individual copies are interchangeable for almost all

Actually, ISO TC 46 is currently developing International Standard Item 
Identifier, because sometimes it is important to identify a single copy 
(or, in library slang, item). A library may own for instance the copy of 
Arithmetica containing Pierre Fermat's comment about The Last Theorem 
(alas, that copy has small margins). There is definitely a need to be 
able to identify that copy from any other copy of the book even though 
the actual proof of the theorem is not included and was only provided by 
Andrew Wiles a few years after Fermat made his remark.

Old books are often unique in the sense that all copies are different. 
When libraries, Google, Microsoft etc. digitize them, it is a good idea 
to indicate which copy has been used as the source.

Juha
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 07 Jul 2014 17:15:23 +0900

Hello Dale,

> existing URIs, but syntactic interoperability is a desirable feature.

Can you give a more specific example? Some people seem to get scared 
when they see that many % signs.

Of course in URI form, non-ASCII characters will have to be escaped with 
%HH. But I don't see a need to do that for US-ASCII characters or in an 
IRI form.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 07 Jul 2014 20:11:33 +0900

> document itself in much greater detail that we have been doing lately.

My understanding is that *most* ebook formats these days don't show 
pages the same way they are printed in books, but that some of them have 
features indicating the page numbers of "real pages", which may be in 
the middle of a displayed page. One reason is that e-ink doesn't yet 
have such a high resolution.

Regards,   Martin.

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 7 Jul 2014 18:39:57 -0400

> From: "Martin J. Dürst" <[email-masked]>
> 

Here's what I mean, or rather, some examples of what I mean:

Suppose we decide to create a "URNng", and the appropriate
authorities decide that the string "Dante's Inferno" should be a
URNng for the book.

As a matter of syntactic embedding, we can create a URN NID named
"ng" for the new URNng strings, and using %-encoding whenever
necessary, represent the URNng as a URI:

    urn:ng:Dante%27s%20Inferno

This isn't particularly pleasing to the eye, but that doesn't really
matter -- the question is to achieve syntactic uniformity in protocol
contexts where URIs are expected.  If the "application" that deals
with this URI knows or expects it to be a URNng, it can easily convert
it to/from "Dante's Inferno" for the user's use.

Now let us suppose that they decide to use "Canto XXV" as a fragment
identifier in the sense of RFC 3986 (or its successor), then we can
represent that as a URI:

    urn:ng:Dante%27s%20Inferno#Canto%20XXV

However, if URNng uses different semantics for a "part", we'll retain
the URNng "part" indicator character as a non-special character in the
NSS.  Assuming URNng uses U+2192 (RIGHTWARDS ARROW) to indicate the
part, that can be represented as a URI:

    urn:ng:Dante%27s%20Inferno%e2%86%92Canto%20XXV

(Assuming I have done the UTF-8 conversion correctly.)  Again, not
human-friendly, but the software can cover that up.

Now, let's suppose that the string "掌握帶人带团队的方法╟培养訓练，溝
通互动，团隊氛圍爄造，激勵詏计" is a URNng.  (I don't have any idea
what those characters mean; they were the name of a PDF file that was
sent me as spam.)  That can be represented as the NSS of a URI as:

    urn:ng:%e6%8e%8c%e6%8f%a1%e5%b8%b6%e4%ba%ba%e5%b8%a6%e5%9b%a2%e9%98%9f%e7%9a%84%e6%96%b9%e6%b3%95%e2%95%9f%e5%9f%b9%e5%85%bb%e8%a8%93%e7%bb%83%ef%bc%8c%e6%ba%9d%e9%80%9a%e4%ba%92%e5%8a%a8%ef%bc%8c%e5%9b%a2%e9%9a%8a%e6%b0%9b%e5%9c%8d%e7%88%84%e9%80%a0%ef%bc%8c%e6%bf%80%e5%8b%b5%e8%a9%8f%e8%ae%a1

Dale

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jul 2014 23:45:03 -0400

--On Monday, July 07, 2014 18:39 -0400 "Dale R. Worley"
<[email-masked]> wrote:

>> > understand why one would want to do that.  But there is no
>> > reason we can't embed URNngs as a NID of URNs (assuming
>> > that they're a sequence of Unicode characters) by generous
>> > use of %-escapes:
>> > urn:ng:%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx.  That
>> > doesn't provide anything other than making them
>> > "syntactically interoperable" with existing URIs, but
>> > syntactic interoperability is a desirable feature.
>> 
>> Can you give a more specific example? Some people seem to get
>> scared  when they see that many % signs.
>> 
>> Of course in URI form, non-ASCII characters will have to be
>> escaped with  %HH. But I don't see a need to do that for
>> US-ASCII characters or in an  IRI form.
> 
> authorities decide that the string "Dante's Inferno" should be
> a URNng for the book.
> 
> As a matter of syntactic embedding, we can create a URN NID
> named "ng" for the new URNng strings, and using %-encoding
> whenever necessary, represent the URNng as a URI:
> 
> This isn't particularly pleasing to the eye, but that doesn't
> really matter -- the question is to achieve syntactic
> uniformity in protocol contexts where URIs are expected.  If
> the "application" that deals with this URI knows or expects it
> to be a URNng, it can easily convert it to/from "Dante's
> Inferno" for the user's use.
> 
> Now let us suppose that they decide to use "Canto XXV" as a
> fragment identifier in the sense of RFC 3986 (or its
> successor), then we can represent that as a URI:
> 
> However, if URNng uses different semantics for a "part", we'll
> retain the URNng "part" indicator character as a non-special
> character in the NSS.  Assuming URNng uses U+2192 (RIGHTWARDS
> ARROW) to indicate the part, that can be represented as a URI:
> 
> (Assuming I have done the UTF-8 conversion correctly.)  Again,
> not human-friendly, but the software can cover that up.
> 
> 通互动，团隊氛圍爄造，激勵詏计" is a URNng.  (I
> don't have any idea what those characters mean; they were the
> name of a PDF file that was sent me as spam.)  That can be
> represented as the NSS of a URI as:
> 
> 
> urn:ng:%e6%8e%8c%e6%8f%a1%e5%b8%b6%e4%ba%ba%e5%b8%a6%e5%9b%a2%
> e9%98%9f%e7%9a%84%e6%96%b9%e6%b3%95%e2%95%9f%e5%9f%b9%e5%85%bb
> %e8%a8%93%e7%bb%83%ef%bc%8c%e6%ba%9d%e9%80%9a%e4%ba%92%e5%8a%a
> 8%ef%bc%8c%e5%9b%a2%e9%9a%8a%e6%b0%9b%e5%9c%8d%e7%88%84%e9%80%
> a0%ef%bc%8c%e6%bf%80%e5%8b%b5%e8%a9%8f%e8%ae%a1

Dale,

I want to stress that what I'm about to say is just personal
opinion -- I'm happy with whatever the WG converges on if it
really meets the needs of relevant communities.  That said,
while I agree that the above could be made to work, I think
experience predicts that it will be a disaster.  In more detail:

First, every time we've made the assumption that a UR* or other
object identifier would not need to be seen by users, it has
been a mistake.  For the Internet the family of relevant
incorrect assumptions goes back to "we can just number hosts and
other hosts/systems will invent local nicknames and apply them
as needed".  I've been told that the original web design assumed
that users would never actually have to look at a URL; certainly
the Bush "As We May Think" paper does an impressive amount of
handwaving about what links would actually look like and how
they would function at a low level.   

If users need to look at the things, much less read them and
type them in (even if only for debugging and testing and history
predicts it will be much more than that) I can't imagine the
examples above, especially the Chinese one, getting a good
reception.    More important, strings like this that are not
immediately obvious and lack good mnemonic value are
exceptionally error-prone and cause typical users to glaze over
sufficiently to create an attack vector and associated security
problem.  As an example, quickly and without overlaying the
strings on each other or decoding them back to native
characters, tell me whether the hypothetical string above and
the one that follows are identical under the URN equivalency
rules:

urn:ng:%e6%8e%8c%e6%8f%a1%e5%b8%b6%e4%ba%bb%e5%b8%a6%e5%9b%a2%e9%98%9f%e7%9a%84%e6%96%b9%e6%b3%95%e2%95%9f%e5%9f%b9%e5%85%bb%e8%a8%93%e7%bb%83%ef%bc%8c%e6%ba%9d%e9%80%9a%e4%ba%92%e5%8a%a8%ef%bc%8c%e5%9b%a2%e9%9a%8a%e6%b0%9b%e5%9c%8d%e7%88%84%e9%80%a0%ef%bc%8c%e6%bf%80%e5%8b%b5%e8%a9%8f%e8%ae%a1

My guess is that would be even more true, and hence more of an
issue, for URNs than for URLs (or other generic URIs) because,
well, we call them names and pretend that they are.

Independent of the URI syntax rules and what needs to be
escaped, any non-ASCII case takes us down the several
URI/IRI-related rabbit holes as well, including claims that
having to escape local characters but not basic Latin ones is
discriminatory and the problem that, while U+NNNN code point
escapes (and syntactic variations on them) are easily looked up
in tables and, if seen as identifiers or a repertoire by its
code points, are CCS and encoding form independent.  "%nn"
escapes, by contrast, are not only tied to Unicode in UTF-8 but
require UTF-8 encoding and decoding software to use (very few of
us can get to and from U+nnnn and its UTF-8 representation for
code point values higher than around U+0300 in our heads).

If your point was to illustrate that, if we considered
preserving all of the syntax rules and general interpretations
of 3986 and/or not extending from 2141 in the ways that its text
clearly anticipates to be the dominant priority, I agree.    We
could quibble about the difference between UTF-8-based octet
escapes and code point-based escapes (the latter would also
require moving away from 3986), but the point is clear.

My difficulty is that I don't accept that priority.  I think
URNs need to be reasonably readable and at least plausibly
type-able in most cases.   I expect them to be able to have
mnemonic value in most (or many) cases.  I'd rather see "no
escapes" than a regime that requires that a very large fraction
of NSS strings contain lots of them.  And I think that, as we
extend URNs beyond what 2141 allows and into what 2141
anticipates (and maybe beyond), we should consider kludges to be
unattractive and to have costs that we should strive to avoid if
doing so doesn't cause too much damage in other areas.  

Obviously, "too much" is part of a delicate balance the WG needs
to strike, noting that no one has suggested an approach that
would violate the "Method:<stuff>" super-generic syntax.  But,
at least to my design taste and human factors design experience,
I think your examples are over the line.

best,
   john

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 8 Jul 2014 10:36:31 -0400

> From: John C Klensin <[email-masked]>

> I've been told that the original web design assumed that users would
> never actually have to look at a URL;

That's a point, but it's one that cuts both ways:  While it is assumed
now that people will both type and look at URLs, my browser will
accept a wide range of URL-like strings and (either visibly or
invisibly) translate them into strings that conform to the URL syntax.

So it does not seem to me to be an unreasonable expectation that user
interfaces will accept from the user, say:

    urn:ng:掌握帶人带团队的方法╟培养訓练，溝

but actually put on the wire 
> a0%ef%bc%8c%e6%bf%80%e5%8b%b5%e8%a9%8f%e8%ae%a1

and vice-versa.

However, at this point I think we need more concrete input, as the
remaining devils are in the details; first, people who work daily with
identifiers, and second, people who build user interfaces for people
of the first type.

Dale

---

From: Larry Masinter <[email-masked]>
Date: Tue, 8 Jul 2014 15:37:19 +0000

> > never actually have to look at a URL;

http://www.ietf.org/rfc/rfc1630 isn't the earliest document, but 
it's close enough. Nothing in there makes any assumption that
"users would never actually have to look at a URL".

It explicitly makes a requirement 

     Printable               It is possible to express any URI using
                              7-bit ASCII characters so that URIs may,
                              if necessary, be passed using pen and ink.

the documents about the original design of the web are readily available

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 09 Jul 2014 19:20:23 +0900

> the documents about the original design of the web are readily available

I think the situation isn't black and white:

Good Web stuff is designed so that you never have to look at an URI/IRI 
if you don't want, but you always can if you need. [1]

Good Web stuff is designed so that those URIs/IRIs that have a high 
chance of being used on napkins,... and in user's heads are short and 
easily memorable, and others aren't unnecessarily lengthy.

There are many ways to get to what one wants (e.g. a document), only 
some of which go through URIs/IRIs. And only a part of the later require 
keyboarding or similar manual work. Clicking on links in mails, 
copypasting, and so on are often sufficient.

US-ASCII is a good lowest common denominator, but it is lower for some 
(roughly the Western Hemisphere) than for others, and if the 'others' 
are the main users, then it makes sense to inconvenience some very few 
with %-encoding if that lowers the bar for the main user group(s).

Long sequences of %-encoding are definitely not what you want to deal 
with on average [2]. But even a simple ISBN is 10 or 13 digits, often 
without spaces, and difficult to type in correctly.

With respect to URNs and libraries, I would expect neither the average 
library user nor the technical expert librarian to have to look at URNs 
and input them except in very rare cases.

Regards,   Martin.

[1] People on this list might not believe it, but there are occasionally 
Web applications where all documents in the system have the same URI. 
The official system to publish documents for lectures,... at our 
University is such a system, it's a corporate product and a big pain... 
Fortunately I run my own server/system with some open source, which 
doesn't have these problems.

[2] My students often use (Japanese) Wikipedia as a reference in some of 
their reports. Since about two years, I request that they use IRIs 
rather than URIs, because it's immediately clear to me what the article 
is referring to in the former, whereas the later is mostly just a long 
list of %-escaping.

---

From: John C Klensin <[email-masked]>
Date: Wed, 09 Jul 2014 11:44:05 -0400

--On Tuesday, July 08, 2014 10:36 -0400 "Dale R. Worley"
<[email-masked]> wrote:

>> I've been told that the original web design assumed that
>> users would never actually have to look at a URL;
> 
> That's a point, but it's one that cuts both ways:  While it is
> assumed now that people will both type and look at URLs, my
> browser will accept a wide range of URL-like strings and
> (either visibly or invisibly) translate them into strings that
> conform to the URL syntax.

Yes.  Many (or most) browsers will, and that is, if I understand
correctly, part of time impetus to change  the URL spec (and
deviate from or obsolete 3986 in the process) so that the URL
definition is more closely bound to what browsers will accept
and translate.  

I've actually got a lot of sympathy for that "make the standard
conform to reality" approach, especially if it would result in
all browsers doing the same thing with now-non-conforming
strings: different browsers using different heuristics can
create attack vectors that no one needs.

At the same time, it is difficult to hear what sounds like
"we've already violated the URI standard enough for the URL case
that we get to change it unilaterally and move toward
unilaterally repudiating it" and "URNs should be held strictly
conformant to all details of the URI standard, to the point that
providing needed functionality requires kludges" from almost the
same direction.

> So it does not seem to me to be an unreasonable expectation
> that user interfaces will accept from the user, say:
> 
>     urn:ng:掌握帶人带团队的方法╟培养訓练，溝
> 

Sure.  But I would expect that, unless that conversion (in both
directions) is a requirement (no IETF standard I know of today,
including 3987, requires that) and that requirement is observed
and implemented correctly by everyone, end users will end up
either seeing the second string and making a botch of it, or
seeing the first string and copying and pasting it in a way that
doesn't quite work.  

In that regard, I note that the native-character string above
appears to contain an ASCII comma as the next-to-last character.
It clearly is not.   Unless the conversion tool I used failed,
the coded sequence claims that it is U+8A4F, "詏".  It clearly
isn't that either, so, well, Q.E.D.

I also note that a big deal has been made about what does and
does not count when one is trying to consider whether two
putative URNs (or URIs more generally) are equal to each other.
By forcing everything into the NSS using encoding tricks, you
completely preempt that discussion in favor of "everything
counts in comparisons".

> However, at this point I think we need more concrete input, as
> the remaining devils are in the details; first, people who
> work daily with identifiers, and second, people who build user
> interfaces for people of the first type.

Yes, but see several recent notes.

   john