W3C home > Mailing lists > Public > public-urispec@w3.org > October 2014

Re: resolving the URL mess

From: John C Klensin <klensin@jck.com>
Date: Fri, 03 Oct 2014 09:25:41 -0400
To: David Sheets <sheets@alum.mit.edu>
cc: Sam Ruby <rubys@intertwingly.net>, Larry Masinter <masinter@adobe.com>, public-urispec@w3.org, Anne van Kesteren <annevk@annevk.nl>
Message-ID: <E231D5957BA233C04415777D@JcK-HP8200.jck.com>

--On Friday, October 03, 2014 11:02 +0100 David Sheets
<sheets@alum.mit.edu> wrote:

> On Fri, Oct 3, 2014 at 12:54 AM, John C Klensin
> <klensin@jck.com> wrote:
>> Hi.
> Hi John,
> Thanks for taking the time to send us your thoughts. They are
> very appreciated. Do you mind if I take some of the text from
> your mail and put it into our wiki?

Help yourself.  Nothing there I haven't said before in more
public places, although I hope I'm becoming slightly clearer and
more coherient as I go along.

>> For whatever it is worth, let me add a different, three part,
>> perspective to Sam's comments (I share his concerns):
> My personal goal is to see (write, collaborate, organize...) a
> specification made which attempts to capture (i) and (iii) and
> in doing so produces statements for (ii). I am under no
> illusions that this is anything like an easy or attractive
> task. Of course, I am not entirely altruistic in my motives...
> I have some small type (iii) proposals that I would like to
> see incorporated.

Again, I think that is fine as long as you/we are clear.
Partially in the interest of disclosure of my biases, I should
add that there is another category that I left out because I
don't associate it with "standard".  It involves a relative of
(i), the descriptive/ cataloging case, that simply identifies
and lists the things people are observed to do in the wild.
Such a list can be very useful in helping implementers know what
to watch out for or protect against.  OTOH, if it is turned into
a list of things people are expected to support, it guarantees
what is sometimes described as a race to the bottom, with each
generation of the document encouraging more bad practices.
(Feel free to incorporate that, and anything else in this note
that you consider useful, into the wike as well.)

> I fear that, where URLs are concerned, we are going in all
>> three directions at once without being clear about what we
>> are doing, and the result is likely to be the confusion of
>> competing "standards" with the same basic titles and similar,
>> but not necessarily identical, terminologies.  That
>> combination really doesn't do the Internet, or even the web,
>> much good except, perhaps as a "this is what we are doing,
>> everyone else should get in line"  assertion from one
>> community that is self-assured enough to make such a
>> statement.
> I think this accurately captures the state of the URL
> specification space and I believe that the solution is an
> on-going specification, test, and recommendation process based
> around a single, cohesive document set. If we describe both
> Postelian liberal and conservative viewpoints of the protocol
> and implementations can be tested against our specification
> document (while still being readable), I believe that a single
> specification is sufficient and desirable.

Yes, I agree, but (1) see above and (2) note that this requires
some agreement about a more or less comprehensive consensus
approval processes and/or change control responsibility.   We
seem to be fragmenting even more quickly on that dimension than
we are on specifications.

>> My difficulty with the above is that a "please come back when
>> you have something to show" approach can easily lead to a
>> state in which it is then too late to make actual changes
>> with only the choice of accepting whatever is produced or
>> rejecting it. Rejection in such situations typically leads to
>> forked standards at best and years of snarling at each other
>> while no one really knows what the norm should be at worst.
> My proposed approach is to specify a single, small syntactic
> component of URIs as a demonstration of the quality,
> capability, and usability we should strive toward. At that
> point, the document will be far from final and a discussion
> regarding the pros and cons of the approach can be had.

I recommend that you take a look at the discussions that have
occurred in recent months on the IETF's "urnbis" WG mailing
list, whether as an example of some issues or as a set of views
about the issues.  I think I like your proposed approach (like
others, ask me again when there is a draft we can look at), but
it seems to me that 3986 has failed us by being insufficiently
clear about the differences between syntax and semantics,
between recommendations and requirements, and between examples
or suggestions and normative material.   From the perspective of
someone who spends a lot of time worrying about things that can
go wrong at the localization-internationalization boundary,
especially when precise language context is not identified and
unambiguous,  I want to stress the "insufficiently" part of
that: it is possible that 3986 itself is fine and the difficult
lies with those who try to extract specific information from a
60+ page document.  But those kinds of readers and readings are
part of our reality.
>> So I would really appreciate some clarification relatively
>> soon, before yet another document starts approaching
>> finality.  I think that may parallel Larry's reason for
>> asking the questions that started this thread but am not sure.
> It is my hope that, with a little ingenuity and a lot of
> thankless work, we can satisfy most stakeholders.

I look forward to your draft(s).

best regards,
Received on Friday, 3 October 2014 13:26:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:45:56 UTC