Subject: [art] Stephen Farrell's Discuss on draft-ietf-appsawg-file-scheme-15: (with DISCUSS)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 13 Dec 2016 07:25:26 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-appsawg-file-scheme-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Appendix C: this spec and the whatwg web page may or may not
be in conflict. I think this may be the first PS that we've
produced where that fact finally hits that fan - is that
right? If not, then I'll clear as we'll already have decided
there's nothing to be done about odd behaviour with
"competing" specifications for the same thing (that thing
being RFC3986). If this is the first time we've gotten to
this point, then I think the IESG ought explicitly decide
that we are going to live with what we all know is a pretty
crap situation where different implementers (web vs. non-web
basically) supporting various kinds of URL/URI are liable to
end up doing different and potentially non-interoperable
things. (There is no action required from the author. For the
IESG - we discussed this a couple of years back, but there
have been some personnel changes since and I forget if the
current set of ADs are or are not up to speed with and ok
with this.)

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Dec 2016 08:11:48 -0800

Steve,

Sorry, but I can't tell what the specific concern is...  Please clarify 
with specific references.

Inline...

On 12/13/2016 7:25 AM, Stephen Farrell wrote:
> be in conflict.

1. "May or may not" presumably means that your concern is we don't know. 
  But since that lack of knowledge could be applied to a potentially 
infinite set of web sites, what's the reasons for selecting this one to 
be concerned about?  Further since there's clear text in Appendix C and 
text at the whatwg (but you don't cite which page), it's not clear why 
the answer isn't clear.

2. Since Appendix C is non-normative, what makes the concern of possible 
(but undocumented) divergence a reason for blocking with a Discuss?

3. If there is a deeper concern that you are raising, I've missed it.

 >  I think this may be the first PS that we've

What fact?

> "competing" specifications for the same thing (that thing

You haven't cited any competing specifications, not even possibly 
competing ones.

> current set of ADs are or are not up to speed with and ok

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Ned Freed <[email-masked]>
Date: Tue, 13 Dec 2016 08:12:45 -0800 (PST)

> right?

Not even close. The first example I found after a quick check of their web site
was the lack of RFC 2231 (that's from 1997) support in their "MIME Sniffing"
specfication. I'm also doubtful their rules are even fully aligned with RFC
2045-2046.

Want another? Their HTML specification talks about using a number
of unregistered (and likely unregisterable) standards tree media types -
which they insist on calling "MIME types" because that's "clearer".

Similar issues apparently exist in their usage of W3C specifications, BTW.

I have no doubt there are many other examples to be found, but I'm not going to
waste my time finding them.

> If not, then I'll clear as we'll already have decided

In the email space at least, competing specifications have been the norm
for 30+ years. So you'll have to pardon me for not getting too excited
about this.

				Ned

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Dec 2016 16:45:27 +0000

> with specific references.

Sorry for being unclear.

AFAIK (though I could be wrong) this would be the first time
the IESG would have approved a proposed standard that directly
duplicates text that is on the whatwg's web page [1] where
they "define" (a la living std) URLs.

[1] is a normative reference in W3C specs.

If the above is the case, then I'd like the IESG to be explicit
about doing that and living with the brokenness of which Ned
gave us some examples.

There is no change request/suggested in the spec itself.

Cheers,
S.

[1] http://url.spec.whatwg.org/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Dec 2016 09:38:13 -0800

On 12/13/2016 8:45 AM, Stephen Farrell wrote:
> duplicates text that is on the whatwg's web page [1]
...

Steve,

Thanks.  And yes, this is interesting.

However your citation is to a long document and what we need to assess 
this sort of issue is some precision about what is being duplicated.

The IETF draft isn't an exact duplicate of the whatwg url spec, if only 
because the IETF draft has undergone extensive revision within the IETF.

So knowing exactly which text replicates exactly which text would help.

It's clearly not a direct 'role' conflict about the basic purpose of 
each specification, since one document is for URLs and the other is for 
file schemes.

Further, the file scheme draft has very few occurrences of the string 
"URL" (3 of which are in the whatwg citation and none that are 
normative) -- and none seem to be normative(!)

The whatwg URL spec does contain a registry-ish entry for a 'file' 
scheme and some text that might be intended to serve as a specification, 
though it's quite terse.

So we still need to refine the problem statement.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Dec 2016 09:45:42 -0800

...

Steve,

d/

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Dec 2016 09:46:00 -0800

Steve,

Inline...

What fact?

d/

-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Dec 2016 17:56:56 +0000

Hi Dave,

> this sort of issue is some precision about what is being duplicated.

Given that [1] is liable to change at any time, and that that
is a deliberate decision and goal of the authors of [1] the
fact that there isn't a specific divergence today for the file
scheme is not the only concern. Note: I'm not saying (here)
that the IETF approach to documents is better than whatwg's
just that they differ. As does the scope of 3986 and updates
vs. [1].

The potential divergence between (some?) web developers
following [1] and other folks following RFCs is my main issue.
(The IESG and IAB and W3C liaisons engaged on trying to get
this fixed a while back. No success on that sadly.)

> So knowing exactly which text replicates exactly which text would help.

I didn't say there was such a direct conflict for this draft.
(TBH I actually don't recall if there is, it's been ages since
I read [1].)

> scheme and some text that might be intended to serve as a specification,

Yeah, that is a pretty clear conflict with the IANA registry for
schemes.

> So we still need to refine the problem statement.

I don't think we do. There may be further detailed problems for
the file scheme, but the discuss point I've raised is to ask the
IESG to consider whether or not we're gonna grin and bear this
particular kind of (IMO possibly damaging) duplication. I suspect
that the only practical answer is to do just that for at least
the time for which [1] is considered useful to web developers.

S.

[1] is the same [1] as before:-)

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Dec 2016 10:20:10 -0800

> for 30+ years. So you'll have to pardon me for not getting too excited

Even within the IETF.

SMTP and RFC 5322 have some redundant definitions, because Postel and I 
didn't appreciate the need to avoid this...

d/

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Dec 2016 10:30:40 -0800

On 12/13/2016 9:56 AM, Stephen Farrell wrote:
> but the discuss point I've raised is to ask the

Stephen,

Small point of procedure:

      The current draft is an update to an existing RFC (1738) on URLs, 
which is dated 1994.

      I doubt the whatwg work goes back that far.

So the concern you are raising is for the later, independent decisions 
of an independent group, and its possible, future divergences from 
existing work that was published in the IETF 22 years ago and is now 
being revised.

In effect the concern you are raising is about the basic existence of 
the (earlier) IETF work, not about a new detail.

d/
-- 

   Dave Crocker

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 13 Dec 2016 10:43:16 -0800

> On Dec 13, 2016, at 9:56 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Dave,
> 

FTR, I do not consider the WHATWG spec to be anything other than one
person's semi-formed opinions about how HTML5 browsers ought to process
URL references within the browser environment and populate the "url"
DOM object. They just use misleading terms for doing so. While the five
active browser development groups might be willing to adhere to it,
eventually, the spec disregards all other components of the Web and
the implementation realities of anything not a browser. That is not a
recipe for IETF-style interoperability. It has no relevance for HTTP
server developers (aside from routing bug reports).

One nice thing, though, is that if browsers do eventually implement the
parsing of Unicode-based references with greater consistency, we can
finally write more than just an appendix on how to parse all references
regardless of protocol or media type.  Such a document (developed within
the IETF) could be used to update RFC3986.

....Roy

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 15 Dec 2016 04:55:35 +0000

From: Stephen Farrell [mailto:[email-masked]]
Sent: Wednesday, 14 December 2016 03:57
> this fixed a while back. No success on that sadly.)

[snip]

> the time for which [1] is considered useful to web developers.

Is this any different from RFC 7230? The 'http' and 'https' URI schemes are 
definitely also included in [1], and there's no way to guarantee they are or 
will remain entirely compatible. Maybe browser interest in both groups/specs 
will keep them in line; maybe there'll be another schism one day.

Cheers
-- 
Matthew Kerwin | QUT

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Dec 2016 08:18:10 +0000

Hiya,

> will keep them in line; maybe there'll be another schism one day.

That's a fair point. I don't recall this issue being
specifically raised during IESG evaluation of that
set of documents, and I'm not sure if there was still
hope at that point for a rational solution to the
forking-3986 problem or not.

In any case, I suspect the IESG will discuss this
later today after which I'll clear, so please bear
with us a little while.

Thanks,
S.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 15 Dec 2016 12:47:35 -0500

The IESG had a discussion on today’s telechat about Stephen’s DISCUSS (below), which he has cleared. During that discussion I volunteered to suggest a bit of additional text to describe the existing reference to https://url.spec.whatwg.org/ <https://url.spec.whatwg.org/> in draft-ietf-appsawg-file-scheme because I think the current text doesn’t quite capture the full extent of the referenced document nor the potential implications for implementors of this spec.

Here is my suggestion for Appendix C:
———
OLD 
The WHATWG defines a living URL standard [WHATWG-URL], which includes algorithms for interpreting file URIs (as URLs).

NEW 
The WHATWG defines a living URL standard [WHATWG-URL], which includes algorithms for interpreting file URIs (as URLs) and URL syntax definitions which may or may not be consistent with this specification at any point in time.
———

Just a suggestion.

Alissa

> On Dec 13, 2016, at 10:25 AM, Stephen Farrell <[email-masked]> wrote:
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 15 Dec 2016 10:01:56 -0800

Howdy,

If you are truly trying to capture this, I would say something like:

"The WHATWG URL specification defines browser behavior for a variety of
inputs, including file URIs.  As a living document, it changes to reflect
updates in browser behavior.  As a result, its algorithms and syntax
definitions may or may not be consistent with this specification.
Implementors should be aware of this possible discrepancy if they expect to
share file URIs with browsers that follow the WHATWG specification."

Given that the WHATWG specification also purports to cover domains, IP
addresses, and all other URL schemes, there are certainly other conflicts
possible, but this text covers the immediate ground.

Just my personal suggestion,

Ted

On Thu, Dec 15, 2016 at 9:47 AM, Alissa Cooper <[email-masked]> wrote:

> The IESG had a discussion on today’s telechat about Stephen’s DISCUSS
> (below), which he has cleared. During that discussion I volunteered to
> suggest a bit of additional text to describe the existing reference to
> https://url.spec.whatwg.org/ in draft-ietf-appsawg-file-scheme because I
> think the current text doesn’t quite capture the full extent of the
> referenced document nor the potential implications for implementors of this
> spec.
>
> The WHATWG defines a living URL standard [WHATWG-URL], which includes
> algorithms for interpreting file URIs (as URLs).
>
> NEW
> The WHATWG defines a living URL standard [WHATWG-URL], which includes
> algorithms for interpreting file URIs (as URLs) and URL syntax definitions
> which may or may not be consistent with this specification at any point in
> time.
> ———
>
> Just a suggestion.
>
> Alissa
>
> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art
>
>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 15 Dec 2016 10:06:14 -0800

On 12/15/2016 10:01 AM, Ted Hardie wrote:
> inputs, including file URIs.  As a living document, it changes to
> reflect updates in browser behavior.  As a result, its algorithms and
> syntax definitions may or may not be consistent with this
> specification.  Implementors should be aware of this possible
> discrepancy if they expect to share file URIs with browsers that follow
> the WHATWG specification."

That text looks excellent to me and I strongly urge using it.

(At the level of a positive nit, I think it's good that it refrains from 
the word 'standard', both given the nature of the referenced group and 
the degree of distraction that word often produces...)

d/

-- 

   Dave Crocker

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 15 Dec 2016 10:10:26 -0800

> On Dec 15, 2016, at 10:06 AM, Dave Crocker <[email-masked]> wrote:
> 
> (At the level of a positive nit, I think it's good that it refrains from the word 'standard', both given the nature of the referenced group and the degree of distraction that word often produces...)

+1

....Roy

---

From: Claudio Allocchio <[email-masked]>
Date: Thu, 15 Dec 2016 19:18:08 +0100 (CET)

another +1

>> (At the level of a positive nit, I think it's good that it refrains from the word 'standard', both given the nature of the referenced group and the degree of distraction that word often produces..…

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

               http://www.cert.garr.it/pgp/garr-cert-pgp-keys

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 15 Dec 2016 13:27:54 -0500

> On Dec 15, 2016, at 1:01 PM, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> 
> "The WHATWG URL specification defines browser behavior for a variety of inputs, including file URIs.  As a living document, it changes to reflect updates in browser behavior.  As a result, its algorithms and syntax definitions may or may not be consistent with this specification.  Implementors should be aware of this possible discrepancy if they expect to share file URIs with browsers that follow the WHATWG specification.”

I like it.
Alissa

> 
> Given that the WHATWG specification also purports to cover domains, IP addresses, and all other URL schemes, there are certainly other conflicts possible, but this text covers the immediate ground.
> 
> On Thu, Dec 15, 2016 at 9:47 AM, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
>> On Dec 13, 2016, at 10:25 AM, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>> https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ <https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/>
>> 
>> 
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/art <https://www.ietf.org/mailman/listinfo/art>
> 
>

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 15 Dec 2016 13:18:42 -0600

On 15 Dec 2016, at 12:27, Alissa Cooper wrote:

>> "The WHATWG URL specification defines browser behavior for a variety 
>> of inputs, including file URIs.  As a living document, it changes to 
>> discrepancy if they expect to share file URIs with browsers that 
>> follow the WHATWG specification.”
>
>
> I like it.

Count me as another +1.

Ben.

---

From: Delfi Ramirez <[email-masked]>
Date: Thu, 15 Dec 2016 22:42:19 +0100

count me in +1

Delfi Ramirez i Ruiz
http://delfiramirez.info
http://segonquart.net
http://delfiramirez.blogspot.com
skype: segonquart
linkedin: https://www.linkedin.com/in/delfiramirez
08005 Barcelona. Spain
__________________________________________

On 15 December 2016 at 19:06, Dave Crocker <[email-masked]> wrote:

> the word 'standard', both given the nature of the referenced group and the
> degree of distraction that word often produces...)
>
> d/
>
> --
>
>   Dave Crocker

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 15 Dec 2016 23:34:23 +0000

Thanks Alissa and Ted,

This is a great paragraph, it will be included in -16.

Cheers

-- 

 <http://staff.qut.edu.au/details?id=kerwinm> Matthew Kerwin | QUT

From: Ted Hardie [mailto:[email-masked]] 
Sent: Friday, 16 December 2016 04:02
To: Alissa Cooper
Cc: [email-masked]; [email-masked]; [email-masked]; Stephen Farrell; The IESG; Dave Crocker
Subject: Re: [art] WHATWG URL spec citation in draft-ietf-appsawg-file-scheme

Howdy,

"The WHATWG URL specification defines browser behavior for a variety of inputs, including file URIs.  As a living document, it changes to reflect updates in browser behavior.  As a result, its algorithms and syntax definitions may or may not be consistent with this specification.  Implementors should be aware of this possible discrepancy if they expect to share file URIs with browsers that follow the WHATWG specification."

Ted

The IESG had a discussion on today’s telechat about Stephen’s DISCUSS (below), which he has cleared. During that discussion I volunteered to suggest a bit of additional text to describe the existing reference to https://url.spec.whatwg.org/ in draft-ietf-appsawg-file-scheme because I think the current text doesn’t quite capture the full extent of the referenced document nor the potential implications for implementors of this spec.

———

OLD 

NEW 

———

Just a suggestion.

Alissa

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Dec 2016 01:04:24 +0000

> 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.

If the community also wanted to e.g. help the IESG formulate
a default view on handling other group's creation of parallel
specifications that might also be a good thing. (Though maybe
a bit abstract.) Probably better as a separate thread though
if folks are interested in that.

S.

> 
>  
> 
> Cheers
> 
> 
> 
> This body part will be downloaded on demand.
>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 16 Dec 2016 06:28:48 -0800

On 12/15/2016 5:04 PM, Stephen Farrell wrote:
> specifications that might also be a good thing.

So, here's some grist for the mill...

 From time to time, the IETF must attend to the existence of parallel 
specifications by other organizations.  That is, work in the IETF might 
overlap with work by some other group.  The work might predate IETF 
efforts or might come after.  In the latter case, the question becomes 
one of deciding how to handle a later IETF revision effort.

Rather than have the IESG spontaneously decide how to deal with that, 
each time, it could be helpful to have the community consider this issue 
generally and formulate some basic views about IETF handling of such 
situations.

NEW
===

For /all/ new IETF work, it is reasonable to have the chartering effort 
/always/ include a statement about related work that has been done 
elsewhere.  This sort of due diligence happens periodically but is not a 
regular part of the chartering discussion.  If there is existing, 
parallel work of note, there should then be some statement that 
justifies pursuing the new work in the IETF.

EXISTING
========

When the IETF has an existing specification the predates the parallel, 
outside work, it is worth some investigation about the role that has 
developed for the original IETF work, versus the later, outside work. 
Ideally, this should be done when the IETF revision effort is first 
formulated, rather than at a later stage.

It is possible that the outside work has come to dominate the industry's 
use, or that the original IETF work dominates, or that neither has a 
clear 'edge' in the market.

In the first case, the onus should be on the IETF to justify further 
effort on a specification that has not (yet) succeeded, given that a 
parallel specification has.

In the other cases, it seems best to pursue the IETF effort without 
significant regard for the outside work, except for a possible notation 
about its existence.

ADDENDUM
========

Sometimes the right answer is to pursue actual competition.  This 
invokes the classic "let the market decide" chorus.  Although that 
sounds inefficient, it can be better than requiring prescient judgement 
by the IETF.  Probably what matters most is the process of discussing 
these choices.

It is worth noting that parallel specifications be wind up being 
complementary.  One can feed into the other.  Or they can fill different 
parts of the solution space.  An unusual example, even /within/ the 
IETF, is MIME and ESMTP.  Originally tasked as parallel, competing 
efforts to enhance email support for 'international' characters, they 
came to be complementary transport-and-payload roles.

d/
-- 

   Dave Crocker

---

From: Delfi Ramirez <[email-masked]>
Date: Fri, 16 Dec 2016 17:28:09 +0100

agreed. no objection.

Delfi Ramirez i Ruiz
http://delfiramirez.info
http://segonquart.net

On 16 December 2016 at 15:28, Dave Crocker <[email-masked]> wrote:

> overlap with work by some other group.  The work might predate IETF efforts
> or might come after.  In the latter case, the question becomes one of
> deciding how to handle a later IETF revision effort.
>
> Rather than have the IESG spontaneously decide how to deal with that, each
> time, it could be helpful to have the community consider this issue
> regular part of the chartering discussion.  If there is existing, parallel
> work of note, there should then be some statement that justifies pursuing
> the new work in the IETF.
>
>
> EXISTING
> ========
>
> use, or that the original IETF work dominates, or that neither has a clear
> 'edge' in the market.
>
> Sometimes the right answer is to pursue actual competition.  This invokes
> the classic "let the market decide" chorus.  Although that sounds
> inefficient, it can be better than requiring prescient judgement by the
> IETF.  Probably what matters most is the process of discussing these
> choices.
>
> parts of the solution space.  An unusual example, even /within/ the IETF,
> is MIME and ESMTP.  Originally tasked as parallel, competing efforts to
> enhance email support for 'international' characters, they came to be
> complementary transport-and-payload roles.
>
>
> d/
> --
>
>   Dave Crocker