Re: [url] Feedback from TPAC
On 11/25/2014 03:52 PM, David Walp wrote: 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 ru...@intertwingly.net 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. I've filed a bug on your behalf: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27516 There already is a discussion as a result. I encourage you to register with bugzilla and add yourself to the cc-list for this bug. 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. I've filed a bug on your behalf: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27517 Hopefully you find the following work-in-progress easier to follow: https://specs.webplatform.org/url/webspecs/develop/ If not, please let me know how it could be improved. 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. This is the subject of an existing bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26431 The webspecs link above contains a concrete proposal for resolving this. 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. To the best of my knowledge, the fix has not been released, but a workaround has been published. See: https://connect.microsoft.com/IE/feedbackdetail/view/1002846/pathname-incorrect-for-out-of-document-elements Cheers, _dave_ - Sam Ruby
RE: [url] Feedback from TPAC
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 ru...@intertwingly.net 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_
Re: [url] Feedback from TPAC
On 11/25/2014 03:52 PM, David Walp wrote: 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. Thanks! Looking forward to it! Can I ask that you either open an issue or a bug (it matters not which to me) on each of these items. https://github.com/webspecs/url/issues https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WHATWGcomponent=URL Feel free to link back to your original post on this topic in the issue/bug reports: http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0505.html I also actively encourage pull requests, so if you care to propose a change, I encourage you to do so. Finally, I've expanded that list since October. Here's a few more topics that you might want to weigh in on: http://intertwingly.net/projects/pegurl/url.html#discuss And by all means, don't stop there! - Sam Ruby On Wednesday, October 29, 2014 6:55 PM, Sam Ruby ru...@intertwingly.net 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_
[url] Feedback from TPAC
bcc: WebApps, IETF, TAG in the hopes that replies go to a single place. - - - I took the opportunity this week to meet with a number of parties interested in the topic of URLs including not only a number of Working Groups, AC and AB members, but also members of the TAG and members of the IETF. Some of the feedback related to the proposal I am working on[1]. Some of the feedback related to mechanics (example: employing Travis to do build checks, something that makes more sense on the master copy of a given specification than on a hopefully temporary branch. These are not the topics of this email. The remaining items are more general, and are the subject of this note. As is often the case, they are intertwined. I'll simply jump into the middle and work outwards from there. --- The nature of the world is that there will continue to be people who define more schemes. A current example is http://openjdk.java.net/jeps/220 (search for New URI scheme for naming stored modules, classes, and resources). And people who are doing so will have a tendency to look to the IETF. Meanwhile, The IETF is actively working on a update: https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04 They are meeting F2F in a little over a week[2]. URIs in general, and this proposal in specific will be discussed, and for that reason now would be a good time to provide feedback. I've only quickly scanned it, but it appears sane to me in that it basically says that new schemes will not be viewed as relative schemes[3]. The obvious disconnect is that this is a registry for URI schemes, not URLs. It looks to me like making a few, small, surgical updates to the URL Standard would stitch all this together. 1) Change the URL Goals to only obsolete RFC 3987, not RFC 3986 too. 2) Reference draft-ietf-appsawg-uri-scheme-reg in https://url.spec.whatwg.org/#url-writing as the way to register schemes, stating that the set of valid URI schemes is the set of valid URL schemes. 3) Explicitly state that canonical URLs (i.e., the output of the URL parse step) not only round trip but also are valid URIs. If there are any RFC 3986 errata and/or willful violations necessary to make that a true statement, so be it. That's it. The rest of the URL specification can stand as is. What this means operationally is that there are two terms, URIs and URLs. URIs would be of a legacy, academic topic that may be of relevance to some (primarily back-end server) applications. URLs are most people, and most applications, will be concerned with. This includes all the specifications which today reference IRIs (as an example, RFC 4287, namely, Atom). My sense was that all of the people I talked to were generally OK with this, and that we would be likely to see statements from both the IETF and the W3C TAG along these lines mid November-ish, most likely just after IETF meeting 91. More specifically, if something along these lines I describe above were done, the IETF would be open to the idea of errata to RFC3987 and updating specs to reference URLs. - Sam Ruby [1] http://intertwingly.net/projects/pegurl/url.html [2] https://www.ietf.org/meeting/91/index.html [3] https://url.spec.whatwg.org/#relative-scheme
