- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 23 Oct 2012 10:52:55 +1100
- To: Ian Hickson <ian@hixie.ch>
- 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 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>. > There's no reason to have three specs when one suffices. OK. > The underlying point that people seem to be making is that there's >> legitimate need for URIs to be a separate concept from "strings that >> will become URIs." > > 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? > By collapsing them into one thing, you're doing those folks a >> disservice. > > They are not collapsed into one thing. OK, good. >> 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. > BTW, it doesn't have to be a separate spec, although it probably would >> benefit from being one. Browser implementers already have to reference >> TCP, IP, DNS, and likely tens to hundreds of other specs to get what >> they want done -- unless you have bigger plans? > > The difference is that the DNS implementor doesn't need to implement TCP, > he uses TCP (and UDP) and builds on it. And so on. Whereas here we're > talking about one thing, URLs, being specified in one place vs three. OK. 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. 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 (or perhaps the W3C one, I can never remember the relationship there). 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). Regards, -- Mark Nottingham http://www.mnot.net/
Received on Monday, 22 October 2012 23:53:25 UTC