Re: resolving the URL mess

Hi.

For whatever it is worth, let me add a different, three part,
perspective to Sam's comments (I share his concerns):

(1) What are we trying to do?

There are at least three ways to think about a standard and what
it is about:

(i) It is a description of existing, fairly uniform, industry
practice. Normative statements are rarely if ever appropriate
and this segues into something else if industry practice is not
uniform or if there isn't broad consensus about how to define
the relevant "industry".

(ii) It is a target, expressing good or best practices.  It is
useful as a target even if no one actually conforms to it.   If
the differences from existing practice are understood, it may
(and probably should) contain descriptions of the differences,
transition suggestions, or both.

(iii) It is an aspirational statement, sometimes in the form of
what has been called a predictive or anticipatory standard, that
expresses best available judgment about the way things should be
done with no necessary connection to existing practice. 

Each of those options may be appropriate to some community (or
communities) and not others.

While I sometimes get cynical about one or two of those options,
the reality is that each has its place if we are clear about
what we are doing and, if there is a reference community, what
it is and what other communities are expected to do.

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.

(2) Who has responsibility and where does that come from?

The IETF uses the term "change control" to describe
responsibility and authority for a spec and its evolution (or,
if one confines "standard" to the first case above, for
gathering and reporting on industry practices).  Once upon a
time, there was an understanding that change control for URLs
and the generalization to URIs (or, if you prefer, for URIs and
the special case of URLs) belonged in IETF.   I think that
understanding included a very broad view of the
community/audience that included a broad spectrum of users and
uses of identifiers, not just usage/practices in a single type
of application or implementation.   That understanding seems to
have been abandoned without anyone being very explicit about it
(other than a few statements or actions in which one community
seems to be attacking the standards of others).

(3) What is the URI <-> URL relationship?

This is hinted at above, but RFC 3986 and 3987 seem to be
documents that everyone cites and no one completely follows
(IMO, Sam's observation about the relationship between them and
with WHATWG URL spec may be the tip of an iceberg) so either the
status of those documents is unclear, they represent general
guidance that we expect most URI types (which may or may not be
the same as schemes) to deviate from or profile (not necessarily
compatibly), or they are something else that I don't quite
understand (unless it is "obsolete and irrelevant").

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.

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.

best,
     john


--On Thursday, October 02, 2014 14:07 -0400 Sam Ruby
<rubys@intertwingly.net> wrote:

> On 10/02/2014 06:05 AM, David Sheets wrote:
>> 
>>> Anne, Dave Thayer, Sam Ruby, John Klensin come to mind…
>> 
>> I believe that when we have something to show, we should
>> entice them to join us.
> 
> +1
> 
> At the moment, a non-existent spec doesn't solve any problem
> that I currently have.  That's not meant to discourage or
> encourage you to produce a spec, but merely an agreement that
> the time that I would get interested is when you have
> something to show.
> 
> For what it is worth, examples of problem I do have:
> 
> 1) Neither RFC 3986 nor RFC 3987 define the content you will
> find here: https://url.spec.whatwg.org/#api
> 
> 2) The WHATWG URL Living Standard makes a large number of
> normative statements, particularly concerning parsing, that do
> not reflect current implementations.
> 
> I'm not intending to advocate any particular solutions to
> these problems; I'm just providing an early heads up of the
> types of questions I likely will be seeking answers to when
> you have something to show.
> 
> - Sam Ruby

Received on Thursday, 2 October 2014 23:54:47 UTC