Re: obsoleting 3986 -- what would it look like?

uri should remain as restricted syntax as compatible as possible with 3986 (same strings legal)  and iri too. along with leiri, for that matter. but they are depricated in that new protocols should expect the broader range of urls if possible.

Sent from mobile Larry
--
http://larry.masinter.net



Erik Wilde <dret@berkeley.edu> wrote:

hello.

On Nov 2, 2012, at 8:27, James M Snell <jasnell@gmail.com<mailto:jasnell@gmail.com>> wrote:
On Fri, Nov 2, 2012 at 12:24 AM, Larry Masinter <masinter@adobe.com<mailto:masinter@adobe.com>> wrote:
Initially as a thought experiment, I've started to sketch out what it would look like to obsolete 3986 (URI) with a document that combined it with 3987 (IRI), reverts to the "URL" name, and gave updated parsing advice.
Doing so is pretty ambitious, of course, and likely to lead to all sorts of controversies, but I thought I'd give it a try.
Seems to be a reasonable effort to undertake... you had me at combining 3986 and 3987. I'll happily help any way I can.

same here, and i think it makes a lot of sense to consolidate things as much as possible. some refactoring, plus some new parts such as the parsing rules. not sure i'd like to deprecate the URI name, which is what i have been using religiously, but in the end, we should pick the name that works best.

*  how much of the introductory and explanatory material from 3896 and 3897 to retain. While it's philosophically and historically interesting, it's also a fertile ground for philosophical debates over whether http://larry.masinter.net#the_person could  identify, locate, or name me rather than a paragraph of my home page. So I'm tempted to leave all that behind.
+1 ... I can't see any reason why the updated spec should delve into any of that.

yes, i agree to this one. any conventions should be left to define and describe for those who want to use them.

* Include URNs? I'm tempted to include at least a pointer to URNbis, but I'm not sure which one.
Not convinced it would be necessary to include but could be wrong.

isn't it really yet another scheme? a little different because it's a scheme for schemes, but it really is nothing but a scheme.

* I'm having trouble resisting the temptation to put a stake into the httpRange-14 by removing any basis for support of using http URLs to "mean" abstractions or people. Right now I'm considering putting that in a "URLs and Semantic Web" appendix.
Hmm.. not sure this really needs to be touched on at all really. Why not simply focus on the mechanics of the syntax, parsing, and error handling and avoid the semantics completely.

i think avoiding semantics would be the way to go, and the httpRange-14 debate might be one that's best deferred to those layers where people introduce and then need to solve those problems.

* I'll accept sincere offers of co-authorship as long as you're willing to accept the requirements that to obsolete 3986 we need to address current use cases that make reference to 3986, 3987, etc.
Happy to help where I can.

same here. it'll be quite a bit of work, but it would be worth it.

cheers,

dret.