Apologies for being a late comer to the discussion, but here is some feedback
in our implementation. We're looking forward to engaging on these interactions
more proactively in the future.
On Wednesday, October 29, 2014 6:55 PM, Sam Ruby wrote:
> Now to get to what I personally am most interested in: identifying
> changes to the expected test results, and therefore to the URL
> specification -- independent of the approach that specification takes
> to describing parsing. To kick off the discussion, here are three examples:
>
> 1) http://intertwingly.net/projects/pegurl/urltest-results/7357a04b5b
>
> A number of browsers, namely Internet Explorer, Opera(Presto), and
> Safari seem to be of the opinion that exposing passwords is a bad
> idea. I suggest that this is a defensible position, and that the
> specification should either standardize on this approach or at a minimum
> permit this.
Yes, we, Microsoft, are of the opinion that exposing passwords is a bad idea.
Based on received feedback, customers agree and I suspect our customers are not
unique on this opinion.
> 2) http://intertwingly.net/projects/pegurl/urltest-results/4b60e32190
>
> This is not a valid URL syntax, nor does any browser vendor implement
> it. I think it is fairly safe to say that given this state that there
> isn't a wide corpus of existing web content that depends on it. I'd
> suggest that the specification be modified to adopt the behavior that
> Chrome, Internet Explorer, and
> Opera(Presto) implement.
Agreed. Standardizing something not used that is not in anyone's interest.
What you have posted on Github:
https://github.com/rubys/url/tree/peg.js/reference-implementation#readme ".. I
found I had a hard time determining what should be the parsing output for a
number of cases." rings true here. There is no advantage to adding complexity
when it is not required.
> 3) http://intertwingly.net/projects/pegurl/urltest-results/61a4a14209
>
> This is an example of a problem that Anne is currently wrestling with.
> Note in particular the result produced by Chrome, which identifies the
> host as a IPV4 address and canonicalizes it.
This is the type of interop issue we think should be a focus of the URL
specification and the W3C efforts.
Finally we are focused at identifying and fixing real-world interop bugs that
we see in live sites in support our goal of "The web should just work...".
(http://blogs.msdn.com/b/ie/archive/2014/05/27/launching-status-modern-ie-amp-internet-explorer-platform-priorities.aspx).
For example, I think you had at one time listed an IE issue in the discussion
section of the URL spec -
http://intertwingly.net/projects/pegurl/url.html#discuss. This bug was related
to a missing "/" at the front of URLs under certain conditions. Since this
issue has been removed from the discussion section, I am hoping you have seen
that we have fixed the issue. We are actively pursuing and fixing similar
interop bugs. We want the URL spec to be source of interop behavior and
believe that our goal is in line with your direction.
Cheers,
_dave_
