[art] Stephen Farrell's Discuss on

[Stephen Farrell]

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

[Dave Crocker]

Steve,

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

Inline...

Post by Stephen Farrell
Appendix C: this spec and the whatwg web page may or may not
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.

Post by Stephen Farrell
I think this may be the first PS that we've
produced where that fact finally hits that fan - is that

What fact?

Post by Stephen Farrell
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

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

Post by Stephen Farrell
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.)

d/

[Stephen Farrell]

Post by Dave Crocker
Steve,
Sorry, but I can't tell what the specific concern is... Please clarify
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/

Post by Dave Crocker
Inline...

Post by Stephen Farrell
Appendix C: this spec and the whatwg web page may or may not
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.

Post by Stephen Farrell
I think this may be the first PS that we've
produced where that fact finally hits that fan - is that

What fact?

Post by Stephen Farrell
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

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

Post by Stephen Farrell
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.)

d/

[Dave Crocker]

Post by Stephen Farrell
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]

...

Post by Stephen Farrell
[1] http://url.spec.whatwg.org/

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]

Post by Stephen Farrell
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]

...

Post by Stephen Farrell
[1] http://url.spec.whatwg.org/

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/

[Stephen Farrell]

Hi Dave,

Post by Dave Crocker

Post by Stephen Farrell
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]

...

Post by Stephen Farrell
[1] http://url.spec.whatwg.org/

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.

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

Post by Dave Crocker
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.

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

Post by Dave Crocker
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.

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

Post by Dave Crocker
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:-)

Post by Dave Crocker
d/

[Dave Crocker]

Post by Stephen Farrell
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.

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/

[Roy T. Fielding]

Post by Stephen Farrell
Hi Dave,

Post by Dave Crocker

Post by Stephen Farrell
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]

...

Post by Stephen Farrell
[1] http://url.spec.whatwg.org/

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.

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

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

[Matthew Kerwin]

From: Stephen Farrell [mailto:***@cs.tcd.ie]
Sent: Wednesday, 14 December 2016 03:57

Post by Stephen Farrell
Hi Dave,

Post by Dave Crocker

Post by Stephen Farrell
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]

...

Post by Stephen Farrell
[1] http://url.spec.whatwg.org/

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.

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

[snip]

Post by Stephen Farrell

Post by Dave Crocker
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.

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

[Stephen Farrell]

Hiya,

Post by Matthew Kerwin
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.

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.

[Ned Freed]

Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/
----------------------------------------------------------------------
----------------------------------------------------------------------
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?

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.

Post by Stephen Farrell
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.)

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

[Dave Crocker]

Post by Ned Freed
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.

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]

Steve,

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

Inline...

Post by Stephen Farrell
Appendix C: this spec and the whatwg web page may or may not
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.

Post by Stephen Farrell
I think this may be the first PS that we've
produced where that fact finally hits that fan - is that

What fact?

Post by Stephen Farrell
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

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

Post by Stephen Farrell
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.)

d/

[Alissa Cooper]

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

Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/
----------------------------------------------------------------------
----------------------------------------------------------------------
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.)

[Ted Hardie]

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

Post by Alissa Cooper
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
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
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.
https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/
----------------------------------------------------------------------
----------------------------------------------------------------------
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.)
_______________________________________________
art mailing list
https://www.ietf.org/mailman/listinfo/art

[Dave Crocker]

Post by Ted Hardie
"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."

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/

[Roy T. Fielding]

Post by Dave Crocker

Post by Ted Hardie
"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."

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

+1

....Roy

[Claudio Allocchio]

another +1

Post by Roy T. Fielding

Post by Dave Crocker

Post by Ted Hardie
"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."

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

+1
....Roy
_______________________________________________
art mailing list
https://www.ietf.org/mailman/listinfo/art

[Delfi Ramirez]

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

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
__________________________________________

Post by Dave Crocker

Post by Ted Hardie
"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."

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
Brandenburg InternetWorking
bbiw.net
_______________________________________________
art mailing list
https://www.ietf.org/mailman/listinfo/art

[Alissa Cooper]

Post by Ted Hardie
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

Post by Ted Hardie
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
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.
———
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

Post by Stephen Farrell
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 <https://www.ietf.org/iesg/statement/discuss-criteria.html>
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ <https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/>
----------------------------------------------------------------------
----------------------------------------------------------------------
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.)

_______________________________________________
art mailing list
https://www.ietf.org/mailman/listinfo/art <https://www.ietf.org/mailman/listinfo/art>

[Ben Campbell]

Post by Alissa Cooper

Post by Ted Hardie
"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.

Count me as another +1.

Ben.

[Matthew Kerwin]

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:***@gmail.com]
Sent: Friday, 16 December 2016 04:02
To: Alissa Cooper
Cc: draft-ietf-appsawg-file-***@ietf.org; appsawg-***@ietf.org; ***@ietf.org; Stephen Farrell; The IESG; Dave Crocker
Subject: Re: [art] WHATWG URL spec citation in draft-ietf-appsawg-file-scheme



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 <***@cooperw.in> 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.



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 <***@cs.tcd.ie> wrote:



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

[Stephen Farrell]

Post by Matthew Kerwin
Thanks Alissa and Ted,
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.

Post by Matthew Kerwin
Cheers
This body part will be downloaded on demand.

[Dave Crocker]

Post by Stephen Farrell
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.

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/

[Delfi Ramirez]

agreed. no objection.

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
__________________________________________

Post by Dave Crocker

Post by Stephen Farrell
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.

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
Brandenburg InternetWorking
bbiw.net
_______________________________________________
art mailing list
https://www.ietf.org/mailman/listinfo/art

[Henry S. Thompson]

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