- From: Larry Masinter <masinter@adobe.com>
- Date: Sat, 27 Dec 2014 06:20:32 +0000
- To: Sam Ruby <rubys@intertwingly.net>
- CC: "www-archive@w3.org" <www-archive@w3.org>
I looked through the mail archives again and reviewed comments. I looked at comments from Mark, Bjoern, Roy, Julian, Graham .... Sending to you for the moment... ========= For Roy, http://lists.w3.org/Archives/Public/public-ietf-w3c/2014Dec/0088.html perhaps you could take your "great effort to Insure that:" and put it in the document as a requirement for updating 3986, so the interop testing for 3986-conformance doesn't have to be repeated if URL and 3986 agree for almost all values that 3986 considers valid, and the differences carefully explained and justified. (To do that with "file:" might need a special case pre-processor for the web, with the result translated/normalized.) ========= You took out the "This document is for discussion purposes", but what I was trying to make clear in the abstract and introduction is that the intent of this internet-draft is not necessarily be published as an RFC (although doing so might turn out to be useful.) Just a forward reference. A lot of the discussion from Mark was around what the intent of this document is. ========== I think for 'naming' point out that IETF authors typically use URL and not URI or IRI, e.g., http://datatracker.ietf.org/doc/draft-singer-appsawg-mcast-url/ just to pick a random one. I'll see if I can come up with more stats on use of URL vs URI in recent IETF internet drafts and RFCs. =========== Graham made a passing comment about URL schemes that identify resources that are far from the web, by other protocols that use URIs without HTTP at all. I'm sympathetic to the and maybe include this thought somewhere. ========== Bjoern comments: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13507.html "differences among APIs for manipulating resource identifiers. I do not think that is a problem and does not need solving" is it explicitly labeled a non-problem? It could be just a wiki or web page, or a separate informational reference, it doesn't have to be here in URL, does it? " Parameterization:" I kind of agree that this isn't clearly a problem, it's a solution to possible interoperability and security problems. "Interoperability" I like his note about kinds of problems but I don't think they are clear classes or category. Maybe just copy his examples and note that it might be useful way of thinking about interop problems and solutions. "specific scheme definition": The 'problem' is that you can't 'simply require somebody' to update specific scheme specifications. I think some of the possible outcomes will make revision of scheme definitions easier or harder. It would be useful to review existing scheme definitions to see if they need update if we update 3986 or 3987. It's part of the due diligence needed to update a 'full standard'. Dealing with Bjoern's comments is hard, but maybe a note for each acknowledging the comment, in the draft or as an issue? ======= Are there w3c Bugzilla bugs we should link to? Going through a search on URL issues shows lots of background information (mixed in, lots irrelevant). Can you think of better searches? https://www.w3.org/Bugs/Public/buglist.cgi?list_id=49773&product=HTML%20WG&product=WebAppsWG&product=WHATWG&short_desc=URL&short_desc_type=casesubstring ====== Is there a possibility of turning URL-LS into an IETF RFC? The issue about trust, normative references, stability, change control should be mentioned, too, if we're going for full disclosure. Larry -- http://larry.masinter.net
Received on Saturday, 27 December 2014 06:21:03 UTC