Re: resolving the URL mess

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?

> 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.

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.

> 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.

> (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.

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.

> 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.

Thanks for your considered and interesting comments, John.

Best regards,

David

> 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 Friday, 3 October 2014 10:03:00 UTC