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

[John C Klensin <[e-mail]>]

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
<[e-mail]> 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.