Subject: Re: [urn] 3986 relationships - Fragment identifiers

From: Larry Masinter <[email-masked]>
Date: Sat, 4 Apr 2015 18:42:46 +0000

Please review http://www.w3.org/TR/fragid-best-practices/
“Best Practices for Fragment Identifiers and Media Type Definitions”.

It gives advice based on an architectural perspective of how the web works; it sounds like you think the architecture is “broken", and not just the documents that describe it. That’s a more serious disconnect.

Larry
—
http://larry.masinter.net

---

From: Keith Moore <[email-masked]>
Date: Sat, 04 Apr 2015 19:16:12 -0400

> It gives advice based on an architectural perspective of how the web works; it sounds like you think the architecture is “broken", and not just the documents that describe it. That’s a more serious…

In a nutshell, what I think about fragments with respect to 
content-negotiation is this: if as a content developer you want to 
generate several equivalent versions of the same resource, and that 
resource has something analogous to fragments, and you can somehow 
arrange that the named fragments for each of those equivalent versions 
has the same content, you benefit from doing so because URIs containing 
fragment names will be meaningful even across HTTP-style 
content-negotiation.

However, there are lots of reasons why you might not be able to do that, 
or why you might not want to make the other compromises that that 
requires.  Some of these reasons are due to limitations in the ways that 
"fragments" are defined for one media type or another that might make 
them unsuitable for particular purposes.  Other reasons are due to the 
somewhat-arbitrary division, inherited from the HTML world, between 
portions of a file (fragments) and relationships between files that 
together comprise the same resource (paths).  One thing that I've 
noticed is that the same document is often mapped into files differently 
for HTML vs some other representation (say PDF) because of presumed 
differences in how each content-type is typically presented to users.

Ideally, URNs should not impose restrictions on what kinds of resources 
can be named, or restrictions on what kinds of resources should be able 
to be declared equivalent to one another for content-negotiation 
purposes, or restrictions on how a resource should be mapped into 
individual files.    We want URNs to be usable for a very long time - 
centuries even.   From this perspective, saddling URNs with conventions 
inherited from "the web" seems shortsighted.

Keith

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Apr 2015 10:56:19 -0400

--On Saturday, April 04, 2015 18:42 +0000 Larry Masinter
<[email-masked]> wrote:

> "Best Practices for Fragment Identifiers and Media Type
> Definitions".
> 
> It gives advice based on an architectural perspective of how
> the web works; it sounds like you think the architecture is
> "broken", and not just the documents that describe it.
> That's a more serious disconnect.

Larry, 

Two observations about that document.  The first is, in some
respects, just procedural but a symptom of one of the problems
we are having in carrying on a conversation about this subject.
The second is more fundamental.

(1) This is a "working draft" not anything resembling even an
approved, consensus, W3C recommendation.  As such, it has, as I
understand it, little more official status than an
Internet-Draft.  It is also not normatively referenced (or even
informatively referenced) by 3986, so I suggest that it is a
view of things the IETF has never accepted (or even, as far as I
can remember, formally reviewed).  It is also an October 2012
document, 7 1/2 years after 3986 (and the earliest version I can
find is 26 July that year).   I note too that RFC 7320, which is
at least later than 3986, doesn't reference it either.

While I think I understand the point you are trying to make
(which goes to (2) below), we are in a situation in which, at
the time publication was approved, 3986 was claimed to not
change or constrain either 2141 or URN evolution, and now we are
having serious disagreements that some of us are hearing as "you
can't do that in a URN because 3986 won't let you".  In that
context, your citing this document now as advice we should be
following is another, even more retroactive, version of the same
issue of finding a later statement and applying it.

(2) One of the problems we face in trying to evolve URNs to meet
the demonstrated needs of a broader community is that there is a
collection of people who believe that URNs, as a concept, are
unnecessary or even illegitimate.   It is very difficult to
discuss URN evolution with them (especially a subset of that
group) because, from their perspective, it would be better to
deprecate 2141 than to discuss additional syntax (whether
path-like, query-like, or fragment-like).  For the most extreme
members of that group, picking off these extensions (by any
means available) one at a time would yield a desirable outcome,
especially if it caused those who depend on even 2141-style URNs
or the kinds of URNs anticipated by RFC 1737 to lose interest in
URNs and move on.  With a few very prominent exceptions (at
least some of them in the W3C leadership), I no longer know who
those people are.  Some people may be in that group some days
and not on others.   I don't know if the recent thread on the
IETF list about getting rid of the "useless" urn "prefix" is
part of that movement or independent.   You have said enough
things on this general subject that seem contradictory from my
perspective that I don't know whether you are sliding in the
direction of that camp.

Even some of those who are more moderate, whose view might be
characterized as "I think URNs are useless for anything I'm
interested in, but am willing to tolerate them as long as they
don't interfere with anything I might be thinking about doing"
are a problem in this regard because their positions tend,
inevitably, to be be essentially negative turf-defending rather
than constructive suggestions as to how we can move forward
given the needs that have been expressed.

To further complicate things, there are people in the extended
community who take "persistence", and even "permanence"
sufficiently seriously that they see URNs as the only piece of
the URI puzzle that is important in the long term.  They see
most locators, especially those closely linked to access
protocols like HTTP, as inherently transitory (and more so if
linked to domain names for server hosts).  Members if that
community have even suggested, based on solid histories of
reasoning, history, and precedent, that most (or all) HTTP URLs
are not even properly called "identifiers".

I don't know how to get un-stuck from this situation, but I do
wish that we could, at least for the purpose of WG discussions,
assume the legitimacy of URNs and URNs with expanded
capabilities and then concentrate on perceived requirements
associated with URNs and exploration of ways to meet those
requirements, rather than moving off into essentially
philosophical debates about the meaning of URIs (or things that
are claimed to be identifiers more generally) and the "best
practices" models that result if one accepts one position  or
another in that philosophical debate as axiomatic.

best,
    john

---

From: Larry Masinter <[email-masked]>
Date: Wed, 8 Apr 2015 04:53:35 +0000

Procedural:

Let’s work together to make the best standards for the entire
Internet community, and use process as a way of accomplishing
that with sufficient review that we’ve actually accomplished
the goal. Yes, it’s bad when people fork without renaming.
IETF URN vs. IFLA URN would be ugly, like with URLs vs. IRIs
and JSON and HTML5. Lets avoid a URN fork, if we can.

On “Best Practices for Fragment Identifiers”:

I cited http://www.w3.org/TR/fragid-best-practices/

because I thought it was thoughtful and a good read and I wanted to
use some of it’s insights in a conversation about the technology
the URN working group is chartered to respecify.

Its status shouldn’t matter. If you read it and you get no 
insights as to why f-components in URNs might be a bad
idea, I apologize, and I’ll try harder to explain.
But I think letting f-components be defined in URN
namespaces is a bad idea for URNs. Not because of
any precedent or normative requirement, or because 
of what 3986 says or means, but because of
fragment identifiers and how they do (or don’t) 
actually work.

Larry
—

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Apr 2015 01:22:13 -0400

> fragment identifiers and how they do (or don’t)
I can see how it would be useful to have a facility to allow reference 
to a "bookmark" or a "region" of a resource named by a URN.   But I 
think if we're going to have something akin to fragments associated with 
URNs, they probably shouldn't be the same fragments that are used with 
HTTP URLs or that appear in e.g. HTML documents.    The latter haven't 
been designed to be persistent, as they're too tied to notions of "file" 
or the granularity of whatever is returned in response to an HTTP GET.   
Instead, perhaps resources should be allowed to declare a mapping from 
URN "regions" to whatever markers are used internal to the resource.

Keith

---

From: Melinda Shore <[email-masked]>
Date: Thu, 09 Apr 2015 12:36:01 -0800

I'm a little concerned that the discussion has become as
contentious as it is, with so little comment from other
working group participants.  We really need to hear from
others in addition to the draft authors, Keith, and Larry.
We'll discuss this in the interim next Friday but I'm
hopeful we can make progress on this before then.

Thanks,

Melinda