- From: Graham Klyne <gk@ninebynine.org>
- Date: Fri, 19 Dec 2014 19:21:16 +0000
- To: Sam Ruby <rubys@intertwingly.net>, Mark Nottingham <mnot@mnot.net>, Larry Masinter <masinter@adobe.com>
- CC: "public-ietf-w3c@w3.org" <public-ietf-w3c@w3.org>, Wendy Seltzer <wseltzer@w3.org>, Philippe Le Hégaret <plh@w3.org>, Barry Leiba <barryleiba@computer.org>, Pete Resnick <presnick@qualcomm.com>
While I can agree there are difficulties in URI/URL-land, it's not clear to me that any of the problems lie with RFC3986. RFC3986 is along-standing stable specification that (for me) has served well. I get twitchy about suggestions that it needs to be updated without understanding what about it might need to change. In saying this, I'm not objecting to your proposals for work in other areas. But what you don't have at this stage is my consensus that RFC3986 needs to change. Indeed, your notes say "Change the URL Goals to only obsolete RFC 3987, not RFC 3986 too.", but that's not quite what I read in your problem statement. Additionally, I think there *could* be a case for relaxing "he set of valid URI schemes is the set of valid URL schemes". As URI scheme reviewer, I see a number of scheme registrations that don't really have anything to do with the Web. I can see an argument for saying the that set of URLs (as used on the Web, in Web protocols) might be a subset of URI schemes. For those schemes, I would expect that URL parse results should be URI-compatible (your notes - and IIRC your problem statement draft - mentioned round-tripping, but I'm unclear what are the points between which round tripping may occur; what I would expect is that URL-parsing is idempotent, and its output is URI-conformant). Your referenced email note also mentions the URI spec referencing URLs. I'm not seeing why that would be needed or useful. #g -- On 19/12/2014 12:08, Sam Ruby wrote: > What frustrates me is that we met, in person, face to face. You proposed some > specific actions whereby the IETF (where you are a member) and the TAG (where > you are a member) would either endorse or propose changes to what I proposed. I > took notes and published them promptly: > > http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0000.html > > I've seen no follow through on what you personally proposed. I want to know > what it takes to get an endorsement from Mark Nottingham. Not a thanks that > I've picked up this work, an actual endorsement of URL Living Standard and/or > the URL W3C Working draft, as well as the stated direction. > > In addition, let me now up the ante. You mentioned a W3C recommendation. I > have personally updated the document which is on the W3C Rec track: > > http://www.w3.org/TR/url/ > > I have kept a working draft up to date: > > http://rawgit.com/w3ctag/url/develop/url.html > > Please tell me what it will take for me to formally propose that a RFC3986bis be > created. If necessary, I'll volunteer to be the author. > > - Sam Ruby > > On 12/18/2014 11:01 PM, Mark Nottingham wrote: >> >>> On 19 Dec 2014, at 12:47 pm, Larry Masinter <masinter@adobe.com> wrote: >>> >>> Mark, as you know, consensus is built one person at a time. >> >> As much as any aphorism is true, I agree. >> >>> Do you agree with this document's "Problem Statement", >>> that it identifies an important problem. If not, why not? >>> >>> If so, do you believe that the Proposed Solution is the >>> best course forward to pursue, and likely to succeed? >>> Do you think the problem unsolvable, or do you have >>> ideas for better solutions. >>> >>> You, Mark. And others on the list of course. >> >> This list is not a forum for building IETF consensus. I've directly CC:ed the >> relevant ADs for their thoughts on >> <http://tools.ietf.org/html/draft-ruby-url-problem-00>; my thoughts as liaison >> below. >> >> Sam asked what the appropriate channels were, and I tried to point him in the >> right direction. >> >> I don't disagree with the document -- I just don't understand how trying to >> get IETF Consensus on it helps, or is worth the (considerable) effort involved >> in doing so, as opposed to getting a sense of the IESG in a liaison statement >> exchange, or more informally. >> >> Furthermore, doing so begs the question regarding the other organisations >> listed -- e.g., do we need a W3C Recommendation to serve the same function in >> that organisation? >> >> What would help me do my job as liaison is to understand you intention is. If >> you're looking to get the IETF to agree to a path forward via consensus, it is >> likely to be difficult and time-consuming (as I and others have outlined), >> since organisations tend not to like to sign blank cheques like that. >> >> Specifically, Section 4 proposes the following activities relating to IETF >> documents: >> >> """ >> Build a plan to update or obsolete [RFC3986], [RFC3987], [RFC5895], and >> [kerwin-file-scheme] to be consistent with [URL-LS] and [UTS-46]. >> ... >> Reconcile how [appsawg-uri-scheme-reg] and [URL-LS] handle currently unknown >> schemes, update [appsawg-uri-scheme-reg] to state that registration applies to >> both URIs and URLs... >> """ >> >> RFC3987 and 3987 are standards-track documents, and anything that updates or >> obsoletes them needs to go through the process. Publishing a consensus >> document saying we're going to come up with a plan to do so seems overly >> bureaucratic, and fraught with the possibility that people's expectations will >> still fail to be met despite that consensus (since consensus to plan doesn't >> mean that there's consensus on *a* plan). >> >> If you want to start working on them, the best way to do so is to bring issues >> to people's attention, either on the URI list, or as errata. Once we have >> data, we can start to talk about what's necessary, and how to go about that >> (e.g., in a WG-forming BoF). Yes, that's messy and slow, but I don't see how >> getting this document to consensus first helps avoid that. >> >> RFC5895 is Informational, on the Independent Stream. If you want to update it, >> I suggest you engage the authors (Pete and Paul). >> >> kerwin-file-scheme is currently being considered for adoption by the APPSAWG. >> If you want to make changes, just go ahead and start that discussion there. >> >> appsawg-uri-scheme-reg is an active document in the APPAWG, and being held for >> the outcome of whatever's happening in the W3C. If you want to make changes, >> just go ahead and start that discussion there. >> >> Pete, Barry - anything else? >> >> Regards, >> >> >>> >>> Thanks, >>> Larry >>> >>> >>>> -----Original Message----- >>>> From: Mark Nottingham [mailto:mnot@mnot.net] >>>> Sent: Thursday, December 18, 2014 3:36 PM >>>> To: Sam Ruby >>>> Cc: public-ietf-w3c@w3.org; Wendy Seltzer; Philippe Le Hégaret >>>> Subject: Re: [url] Requests for Feedback (was Feedback from TPAC) >>>> >>>> Hey Sam, >>>> >>>>> On 18 Dec 2014, at 10:34 pm, Sam Ruby <rubys@intertwingly.net> wrote: >>>> [...] >>>>> I'm still looking for advice on how to get this approved as Informational plus >>>> IETF Consensus. >>>> >>>> Did you see <http://www.w3.org/mid/EBA7F2BE-DCC7-4BD2-AEAC- >>>> 92790C30A92D@mnot.net>? I think that contains the starting points you need; >>>> if you need more information, glad to help. Again I urge you to coordinate with >>>> Wendy and Philippe (CC:ed). >>>> >>>> Cheers, >>>> >>>> >>>> -- >>>> Mark Nottingham https://www.mnot.net/ >>>> >>> >>> >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >
Received on Friday, 19 December 2014 19:21:54 UTC