Re: resolving the URL mess

On Fri, Oct 3, 2014 at 2:29 PM, John C Klensin <klensin@jck.com> wrote:
> (sorry - botched a sentence.  If possible, please ignore prior
> version (four minutes ago) in favor of this one)
>
> --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 am equally or more concerned when ideas taken
> from 3987 are folded into the basic URL concept and mixed with
> various practical alternatives for Unicode character
> representation and escapes. 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.

Could you be a little more specific about what concerns you have
regarding inclusion of IRI concepts into URLs? What do you see as the
most effective specification approach if not unification? A unified
specification of two objects, one a superset of the other? Layered
specifications as we have today?

>>> 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,
>    john
>

Received on Friday, 3 October 2014 13:40:19 UTC