Re: [apps-discuss] Experimental (was - Re: Review of draft-ietf-appsawg-file-scheme)

[Matthew Kerwin <[e-mail]>]

On 14 April 2016 at 10:02, Mark Nottingham <[e-mail]> wrote:

> The draft states:
>
> """
> This document defines a syntax that is compatible with most extant
> implementations, while attempting to push towards a stricter subset of
> "ideal" constructs.  In many cases it simultaneously acknowledges and
> deprecates some less common or outdated constructs.
> """
>
>
Actually since Dave's review the working copy now says:

"""
​This document specifies a syntax that is compatible with most extant
implementations. It also documents other less common or outdated constructs.
"""

​That is, the idealism and deprecation are both removed. Essentially it's
an update of the syntax from RFC 1738 to fit better with 3986, and some
information regarding unspecified edge cases and implementation-specific
divergences.

As I mentioned in my reply to Dave's review, I want to work out how to
clarify the intention and structure of the document; I think this helps
inform that.


I'm concerned about how well this draft aligns with current and future
> behaviour of common clients (especially, but not exclusively, Web
> browsers), especially since it's making decisions about deprecation and
> subsetting.
>
> Have we had any input or statements of support from those communities?
>
>
A little, mostly tangential or out of band.

Is it typical for lots of entities to do a similar thing in different ways,
and block standardisation by not engaging? It sounds snarky, but I'm
genuinely asking, since I'm still quite new to this whole open
standardisation thing and don't know the politics of it.

If it's my fault for not appropriately seeking that engagement, I'll
happily go seeking it (even if it's too late for this draft.)


Is there a test suite or other data to validate the decisions made?
>
>
Nope. How would that look? Would a list of URIs and the expected outcomes
of parsing/dereferencing them (alongside metrics of known implementations
that pass/fail) be enough?


Absent those things, I question whether it should be published at all.
> Experimental doesn't seem like the correct path, because the experiment
> would effectively be to "see if this sticks." It's one thing to define a
> new protocol extension with the hope that it will get traction in time;
> it's another to do hope-based definition of existing protocol constructs.
>
>
Since everyone "does" file URIs, but they all do it differently, and the
spec that defines it is ancient, underspecified, and officially obsolete,
would you suggest instead I write an informational RFC describing the
situation and what everyone is doing right now? Because I really don't want
to walk away and leave the situation the way it currently is.

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/