On 10/24/2012 11:36 AM, Jari Arkko wrote: > Ted, Ian, > >> Un-marked context shifts are >> likely, and likely to be bad. Avoiding them by picking a new term is >> both easy and appropriate. > > FWIW, I agree with Ted's advice above. Further to that, some guy's fine tool [1] says that RFC 3986 is referenced by 193 other RFCs. Google scholar says that RFC 3986 has 2090 citations. [2] While that's nowhere near the full story, it is nonetheless significant. Buggering about with a spec like that whilst only considering a limited context seems hugely dumb to me, no matter how good a case you seem to have for changing bits and pieces of it. So far, I've not seen the argument for changing 3986, but there do seem to be good arguments for additional things such as error-handling specific to the browser context. I honestly don't get the argument for forking, and I agree with Ted that that's what's at issue and would be stupid. I don't know that inventing a new term is that good an approach either really, it'd seem better to me to try specify the additional stuff needed in the whatwg context and then see if there's any change to 3986 needed and if so, then propose those changes as an update to the RFC, following the IETF process. That is not what I see happening now and I do see an apparent intent to create the stupid fork that Ted identified. Getting an update to 3986 through the IETF process will I'm sure be a huge PITA for whoever does propose it, since there are so many other dependent specs. But that's life, and its quite do-able, if done by someone who's able to handle that kind of work. S. [1] http://www.arkko.com/tools/allstats/citations-rfc3986.html [2] http://scholar.google.com/scholar?cites=6121683772362091274&as_sdt=2005&sciodt=0,5&hl=en > >> >> My personal opinion, as always, >> > > Mine too. > > Jari > > >