Subject: Re: [art] WHATWG URL spec citation in draft-ietf-appsawg-file-scheme

From: John C Klensin <[email-masked]>
Date: Mon, 19 Dec 2016 12:35:46 -0500

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
<[email-masked]> 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.

---

From: [email-masked] (Henry S. Thompson)
Date: Mon, 19 Dec 2016 20:45:40 +0000

John C Klensin writes:

> ...

> 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 don't see how this follows, and I disagree.  It doesn't follow because
recognition of the existence of a competing _non-IETF_ spec is not the
same as recognition of a conflict _between_ IETF specs.

I disagree because in general if we are going to publish a spec which
contradicts/extends/clarifies (pick any number) an existing IETF spec,
we have a process for signalling that the existing spec is
replaced/extended/amended, and I don't believe we should be forced to
abandon that commitment to _internal_ consistency as some kind of
collateral damage arising because we acknowledge that the rest of the
world doesn't always respect our authority :-).

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]