Re: [art] WHATWG URL spec citation in draft-ietf-appsawg-file-scheme
John C Klensin <john-ietf@jck.com> Mon, 19 December 2016 17:36 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434FE129C3B; Mon, 19 Dec 2016 09:36:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id on5Gx2YOtF1G; Mon, 19 Dec 2016 09:35:58 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4002129C38; Mon, 19 Dec 2016 09:35:57 -0800 (PST)
Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1cJ1qo-000CkD-AF; Mon, 19 Dec 2016 12:35:50 -0500
Date: Mon, 19 Dec 2016 12:35:46 -0500
From: John C Klensin <john-ietf@jck.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Matthew Kerwin <matthew.kerwin@qut.edu.au>, Alissa Cooper <alissa@cooperw.in>
Message-ID: <A450732F43FCE728380A388C@PSB>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.70
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/ea0LiYxvkZxrO55DhJ_Q2owSgWQ>
Cc: appsawg-chairs@ietf.org, Ted Hardie <ted.ietf@gmail.com>, art@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-appsawg-file-scheme@ietf.org, Dave Crocker <dcrocker@bbiw.net>
Subject: Re: [art] WHATWG URL spec citation in draft-ietf-appsawg-file-scheme
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2016 17:36:03 -0000
Hi. Sorry for the delay in getting to this, but, while I like the new text too, I think there is a complication that has implications elsewhere. I have tried to make what follows as balanced as possible. Opinions are very polarized about what I'm about to say, so finding that balance isn't easy. I note that the Protocol Action announcement for the file scheme specification appeared as I was proofing and about to send this note. If the note changes any thinking, the IESG should consider it an appeal of the decision to approve the file scheme spec. I hope it does not, only that the implications of the decision are clear. Backing up a bit from this particular case, we've got a full Standard for URIs (including URLs) in RFC 3986. That document has been very controversial, with different people seeing it quite differently. Some people see it as an extremely clear, specific, and binding spec. Their view has been used to justify a number of "you can't do that because it is inconsistent with 3986 and the idea of a generic URI" statements and positions vis-a-vis developments in the URI space. In particular, it has been key to the reasons why the URNBIS WG is many years behind its original schedule and continues to slide. I'm not sure whether my view is shared, but I think 3986 definitions and requirements are connected to our inability to move forward in the IETF with clarification and revision to IRIs (RFC 3987). Others of us find 3986 difficult to read and understand. I don't know that there is agreement about the specific issues, but various people believe, among other things, that its use of what is claimed to be ABNF violates the rules of that spec, that it is unclear about what is mandatory and what is merely a collection of examples or alternatives, and about what expectations it sets for parsing or processing of URIs independent of specific schemes. There are also concerns about whether its handling of URNs was consistent with the intent in RFC 2141 and other documents and, if it is not, whether the changes were intended by the community. Others are concerned about whether 3986 is consistent with actual deployed reality wrt either URNs or URLs and where it leaves the never-implemented (or at least never actively-used) URCs. As I understand it, WHATWG claims that their URL document was needed because 3986 does not reflect reality (at least their reality). Again, I personally think the "file:" spec, in its current form and including the new text, is fine and I like the care it takes about different approaches. However, if the IESG is going to allow a non-critical discussion of a definition alternative to 3986, even in a "Similar Technologies" section or appendix, then, IMO, a completely rigid position that people, at least some readers, believe that RFC 3986 takes a position and that position is therefore sacrosanct becomes untenable. I expect the community, and the IESG in particular, will remember that the next time an argument comes up about, e.g., whether a URN document is allowed to do things a bit differently than what some people believe 3986 says. To be clear, an argument against URNs being defined in a way that would cause interoperability problems with generic URI processors is a different matter entirely and should be taken seriously by the community, but, given this reference, those processors need to be real and deployed, and specific examples identified, to count not just theoretically possible given some reading of 3986. best, john --On Friday, 16 December, 2016 01:04 +0000 Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: >> This is a great paragraph, it will be included in -16. > > Add me to the chorus. And thanks to all for thinking more > about this, I think it's to everyone's benefit if we try > as much as we can to handle forks in specs as well as we > can with a view to damage limitation.
- [art] Stephen Farrell's Discuss on draft-ietf-app… Stephen Farrell
- Re: [art] Stephen Farrell's Discuss on draft-ietf… Dave Crocker
- Re: [art] Stephen Farrell's Discuss on draft-ietf… Ned Freed
- Re: [art] Stephen Farrell's Discuss on draft-ietf… Stephen Farrell
- Re: [art] Stephen Farrell's Discuss on draft-ietf… Dave Crocker
- Re: [art] Stephen Farrell's Discuss on draft-ietf… Dave Crocker
- Re: [art] Stephen Farrell's Discuss on draft-ietf… Dave Crocker
- Re: [art] Stephen Farrell's Discuss on draft-ietf… Stephen Farrell
- Re: [art] Stephen Farrell's Discuss on draft-ietf… Dave Crocker
- Re: [art] Stephen Farrell's Discuss on draft-ietf… Dave Crocker
- Re: [art] Stephen Farrell's Discuss on draft-ietf… Roy T. Fielding
- Re: [art] Stephen Farrell's Discuss on draft-ietf… Matthew Kerwin
- Re: [art] Stephen Farrell's Discuss on draft-ietf… Stephen Farrell
- [art] WHATWG URL spec citation in draft-ietf-apps… Alissa Cooper
- Re: [art] WHATWG URL spec citation in draft-ietf-… Ted Hardie
- Re: [art] WHATWG URL spec citation in draft-ietf-… Dave Crocker
- Re: [art] WHATWG URL spec citation in draft-ietf-… Roy T. Fielding
- Re: [art] WHATWG URL spec citation in draft-ietf-… Claudio Allocchio
- Re: [art] WHATWG URL spec citation in draft-ietf-… Alissa Cooper
- Re: [art] WHATWG URL spec citation in draft-ietf-… Ben Campbell
- Re: [art] WHATWG URL spec citation in draft-ietf-… Delfi Ramirez
- Re: [art] WHATWG URL spec citation in draft-ietf-… Matthew Kerwin
- Re: [art] WHATWG URL spec citation in draft-ietf-… Stephen Farrell
- [art] "competing" specifications (was: Re: WHATWG… Dave Crocker
- Re: [art] "competing" specifications (was: Re: WH… Delfi Ramirez
- Re: [art] WHATWG URL spec citation in draft-ietf-… John C Klensin
- Re: [art] WHATWG URL spec citation in draft-ietf-… Henry S. Thompson