2012-12-12-rsoc-minutes
slides-interim-2022-rfcedprog-02-sessa-2012-12-12-rsoc-minutes-00

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