- From: David Sheets <sheets@alum.mit.edu>
- Date: Fri, 3 Oct 2014 11:02:31 +0100
- To: John C Klensin <klensin@jck.com>
- Cc: Sam Ruby <rubys@intertwingly.net>, Larry Masinter <masinter@adobe.com>, "public-urispec@w3.org" <public-urispec@w3.org>, Anne van Kesteren <annevk@annevk.nl>
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