- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 23 Oct 2012 10:32:54 +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:25 AM, Ian Hickson <ian@hixie.ch> wrote: > > What exactly do you suggest? > > Doing the work but at the IETF? See my reply to James. Don't much care about the venue, as long as there's *some* coordination / communication. > Waiting for the IETF to do the work? We did, and timed out. Understood, and unfortunate. Arguably, you waited longer than the timeout. > Not doing the work? That doesn't lead to interop. Absolutely - again, I don't see anyone suggesting that. Do I smell straw? > Doing the work as a diff spec? That's what we did for a while, but it > doesn't work. Having to reference three specs (pre-parse, IRI, URI) just > to parse and resolve a URL is not what leads to implementors having a good > time and thus not what leads to interop. Really? You're comfortable with the current weight and depth of the HTML5 spec, but balk at a pre-processing step for URIs? Seriously? 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." By collapsing them into one thing, you're doing those folks a disservice. Browser implementers may not care, but it's pretty obvious that lots of other people do. 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? Regards, -- Mark Nottingham http://www.mnot.net/
Received on Monday, 22 October 2012 23:33:24 UTC