- From: mike amundsen <mamund@yahoo.com>
- Date: Mon, 22 Oct 2012 20:32:51 -0400
- To: Tim Bray <tbray@textuality.com>
- Cc: Ian Hickson <ian@hixie.ch>, Mark Nottingham <mnot@mnot.net>, Jan Algermissen <jan.algermissen@nordsc.com>, Julian Reschke <julian.reschke@gmx.de>, "Roy T. Fielding" <fielding@gbiv.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Noah Mendelsohn <nrm@arcanedomain.com>, URI <uri@w3.org>, IETF Discussion <ietf@ietf.org>
- Message-ID: <CAPW_8m6r38A+OB40FKqJ7LwEk3iUUZb=ZQsc2wvBR1h_KV7o0g@mail.gmail.com>
<snip> I’d have to say that URI interoperability problems haven’t come near getting into the list of top-20 pain points. </snip> I can't recall the last time i experienced "URI interoperability problems" across various user agents/implementations on the public Internet. My problems w/ browser implementations is another thing. In this particular case (URIs), I applaud Anne's attempt to fix the broken way browsers handle these strings within their own executable code (i.e "browsers (apart from Chrome) do not unescape URL escapes."[1]). However, I find the announcement that he plans to change the names of things along the way (i.e. "And yes, the plan is to do away with IRI/URI and just call them all URLs"[1]) a waste of time. Fixing the code can happen regardless of naming. Do that and do it now. Thanks. [1] http://annevankesteren.nl/2012/09/url-equivalence mca+1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen On Mon, Oct 22, 2012 at 8:15 PM, Tim Bray <tbray@textuality.com> wrote: > One more data point... I work on Web software all the time and have for > many years; in recent years mostly at the REST (app-to-app HTTP > conversations) rather than browser-wrangling level. I’d have to say that > URI interoperability problems haven’t come near getting into the list of > top-20 pain points. So either my experience is wildly untypical, or maybe > it’s a combination of being a little bit lucky, and that the pain which > exists is highly concentrated in the browser space. -T > > On Mon, Oct 22, 2012 at 5:05 PM, Ian Hickson <ian@hixie.ch> wrote: > >> On Tue, 23 Oct 2012, Mark Nottingham wrote: >> > On 23/10/2012, at 10:40 AM, Ian Hickson <ian@hixie.ch> wrote: >> > > On Tue, 23 Oct 2012, Mark Nottingham wrote: >> > >> >> > >> Don't much care about the venue, as long as there's *some* >> > >> coordination / communication. >> > > >> > > Everyone is welcome to participate in the WHATWG list. >> > >> > As they are on the IETF list. The difference is that the WHATWG is run >> > by an unelected board of "members" - <http://www.whatwg.org/charter>. >> >> "Run" is a bit of a strong word. There's basically no non-public activity >> from the charter members. >> >> >> > > Anne's spec will define "valid URL", which addressed that need. >> > >> > Why not define (or reuse) a separate term for the input stream, and >> > leave "URL" alone? >> >> Because everyone calls these things URLs (except STD 66). >> >> >> > >> Browser implementers may not care, but it's pretty obvious that lots >> > >> of other people do. >> > > >> > > Browser implementors aren't particularly special here. >> > >> > No, but your arguments are often coloured by your perspective -- just as >> > everyone else's are. >> >> Which arguments in particular are we talking about here? I've mostly been >> talking about curl, wget, GoogleBot, Perl libraries, etc. >> >> >> > If I believed that Anne was willing to and capable of re-specifying >> > RFC3986 in such a way that the definition, syntax and semantics of URLs >> > (or whatever they ends up being called) doesn't change at all, I'd be >> > less concerned. >> > >> > However, that doesn't seem very likely, especially when he isn't >> > engaging with the folks that wrote that spec (especially, Roy). >> > >> > RFC3986 is referenced by a LOT of technologies, not just Web browsers, >> > not just HTML. Replacing it unilaterally with input from the browser / >> > HTML community from an implementer perspective is very likely to break >> > most of them. >> >> I suspect it will break nothing, but I guess we'll find out. >> >> I don't really understand how it _could_ break anything, so long as the >> processing of IRI and URIs as defined by IETF is the same in the WHATWG >> spec, except where software already differs with the IETF specs. >> >> Do you have a concrete example I could study? >> >> >> > As such, they won't use your new spec, and we'll be living in a world >> > where there will be two definitions of "URL" -- the IETF one and the >> > WHATWG one [...]. >> > >> > That seems a pretty bad tradeoff for the benefits you're getting -- a >> > slightly easier-to-read spec for browser implementers (a relatively tiny >> > audience). >> >> If you have any concrete concerns, please don't hesitate to e-mail the >> WHATWG list, showing the specific examples you're worried about. Browsers >> are but one of many implementation classes that are relevant. >> >> >> -- >> Ian Hickson U+1047E )\._.,--....,'``. fL >> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. >> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >> > >
Received on Tuesday, 23 October 2012 00:33:40 UTC