- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 23 Oct 2012 00:05:09 +0000 (UTC)
- To: Mark Nottingham <mnot@mnot.net>
- cc: Tim Bray <tbray@textuality.com>, 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>
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:05:32 UTC