Hi,
Interesting new thread on a complete rewrite of the IETF
RFCs that define URI/IRI, initated by Larry Masinter.
This would have very wide-ranging impact (from protocols
to parsing libraries). The overall reason is to add back the
real parsing rules that were lost from the first URL RFCs.
Humorously (to me), note the proposal to revert to "URL"
(what the rest of the non-techie world uses anyway).
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
Temporary Cabin *** 2012 only *** 906-494-2523
---------- Forwarded message ----------
From: Larry Masinter <masinter at adobe.com>
Date: Sat, Nov 3, 2012 at 4:59 PM
Subject: Re: obsoleting 3986 -- what would it look like?
To: Erik Wilde <dret at berkeley.edu>
Cc: "uri at w3.org" <uri at w3.org>, James M Snell <jasnell at gmail.com>
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* <http://larry.masinter.net>
Erik Wilde <dret at berkeley.edu> wrote:
hello.
On Nov 2, 2012, at 8:27, James M Snell <jasnell at gmail.com> wrote:
On Fri, Nov 2, 2012 at 12:24 AM, Larry Masinter <masinter at 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.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/pwg-announce/attachments/20121104/255c8793/attachment-0001.html>