Agree clean up and editorial things you see that are quick and likely to get noticed (typos) (to keep people from all mentioning them on last call) and get it out.
ALSO do anything that you think someone else might think of as substatial later (so you don't have to repeat last call after you do them) If there are any and send it to last call. Gregg -------------------------------------------------------- Gregg Vanderheiden Ph.D. Director Trace R&D Center Professor Industrial & Systems Engineering and Biomedical Engineering University of Wisconsin-Madison Technical Director - Cloud4all Project - http://Cloud4all.info Co-Director, Raising the Floor - International - http://Raisingthefloor.org and the Global Public Inclusive Infrastructure Project - http://GPII.net On Apr 19, 2013, at 8:29 AM, [email protected] wrote: > The issues that Gunnar is raising are all "tidying up" issues. Existing > problems in implementations today are caused by not complying with stuff > already in the spec for several versions. The spec is pretty complete as-is. > I re-read XMPP's website and they are all in that category. It's really > down to nitpicks at this stage. > > Sent from my BlackBerry device on the Rogers Wireless Network > > -----Original Message----- > From: Kevin Smith <[email protected]> > Sender: [email protected] > Date: Fri, 19 Apr 2013 09:16:04 > To: XMPP Standards<[email protected]> > Reply-To: [email protected], XMPP Standards <[email protected]> > Subject: Re: [Standards] XEP-0301 (In-Band Real Time Text) - review > observations > > On Fri, Apr 19, 2013 at 9:03 AM, Gunnar Hellstrom > <[email protected]> wrote: >> We are clearly down >> to issues where it would be better to take it through last call. > > Ignoring everything else as I've not found time to read the thread > yet, I'll point out that up until LC the authors are free to edit the > document as they please - this stops being true once it's been LCd. > For it to get to Draft it's going to need to have the open issues > cleared up (i.e. knowing there are open issues and "We're intending > further developing it in 2014" is a reason to not send it to Draft > IMO), and once Draft all changes have to go through Council. Changes > /can/ be made to Draft XEPs, but other than tidying of things found in > deployment it needs to by and large remain the same. > > /K
