RSOC call 12-Dec-2012 0. Agenda Bash 1. RSE Reports a. RFC Publication i. Current Queue Summary (http://www.rfc-editor.org/CurrQstats.txt) b. RSE Priorities & Projects i. Format update - see doc attachment 6-Dec-2012 2. RPC/Publisher Annual Review 3. RSOC Procedures 4. AOB ---- Attendees: Alexey Melnikov Bob Hinden David Kessens Fred Baker Joel Halpern John Klensin Nevil Brownlee Ole Jacobsen Apologies: Olaf Kolkman 1. RSE Reports a. RFC Publication b. RSE Priorities & Projects Format Update Note IAB publication process: 2 week IAB/RSOC review (to go out today, not to close until RSOC provides input) then IF the RSOC and IAB recommends, it will go out to a 4 week IETF Call for Comments on Jan 9 will be on the IAB agenda for 9 Jan To be written in an email and entered in to IAB minutes; email would come from RSOC Chair "A year's discussion and 3 BoF's." Endorse decision or not, both are valid; if RSOC agrees with the decision * JCK still having problems on what has been decided and what not; see things still open for discussion and yet parts of the docs are written as if decisions had been made where they hadn't; cannot offer agree/disagree until those points have been made clear * NB - we can approach this in steps * JCK - no problem with steps, just that we be sufficiently clear; parts of section 2 and 3 are the sorts of issues concerned about * UTF-8 for what? we're not looking for RFC to be written in chinese or hieroglyphics, but we are hoping that a Chinese person could write their name; JCK is pushing back on their issues - all in favor of people writing their names in Chinese, but if they aren't available in latin characters (and not in metadata where they might be hidden) most members of the community won't really know who wrote the document) need transliteration in to ascii or their preferred name as written in latin characters in addition to chinese characters; BH: we need to be careful that the tools people use to create/edit/use these documents will display this correctly * the issue is what set of rules to develop to use UTF-8, what we will allow, won't allow, and what our expectations are; other piece of that is whether UTF-8 is acceptable, it's a question of what rules should be used; FB: would it make sense to propose an initial set of rules, such as names, and a set of examples? JCK: Sure * FB - are there other rules we should consider? JCK: need to consider normalization vs canonicalization - may need to identify languages and scripts to make it so the rendering engines work; right paragraph two proposed rules that Fred provided, and if there are other cases the RFC Editor will discuss them with the authors: JCK; one rule to use is that a doc that contains non-ASCII characters must be readable without them; BH: rules ned to be clear enough to allow RFC Ed staff to say no * JCK: editing a document which contains a right to left script can be very difficult with tools that only run left to right * differ in principle and not in practice: cannot approve XML without having enough of a framework to make sure the rules are possible, and while they are certainly probably posseble, they need to be clarified first before decision can be ratified * another set of questions, where to draw the lines between image stock and UTF-8 characters if we start with the principle with the document must be readable even if all non-ASCII characters disappear is a great rule and will remove need for a lot of detail other concern, without an easy rule, is that the production center has to be able to edit these document; if the RPC says we can handle x number of scripts and not others, is that an acceptable way to drive policy Process - acceptable up to this point; need to resolve questions about level of effort Note: Additional comments received from JCK with good points on where the document could use some clarification Question: should there be another common interest session? HF would like to have a small group working on components of design, but their output will not be ready for open floor discussion, BUT there's value in keeping people aware of the conversation more than they might be on rfc-i * what is the impact of doing what is proposed? What changes in tools that people use will be required? That comes out of the next steps and how to make that happen; JCK: more details: if one wants to have names in two representations, someone will have to think through xml2rfc DTD to see if that can work and how hard it will be to implement it; BH: don't want to go forward with something we can't reasonably use or implement; JCK: the UTF-8 situation is a specific example of that generalized concern AI: HF to talk to JCK, revise doc; post to RSOC before end of year, talk to Henrik RSOC procedures: * encourage list discussion; Fred posted something, and the thought is that needs to turn in to a doc * JCK to work on that and post in January Also on the agenda for January: retreat the day before Berlin