RPC Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
(No formal agenda)

1. Talk about xml doc, particular seeing if we can get some help creating test cases to help answer documentation questions
reference work and lists (lists are very complex); just copying the definition from old spec is sufficient;
Julian to send what test cases are needed to the list; send test cases to Julian - text that can be pasted in to a document in an xml2rfc document
in the repo, there are examples in the test doc - maybe we should set up a sample document in the repo so that people can add things to a single test doc; Julian already has a huge test case document, but it tests many other things as well so might not be idea for this


2. Some action on the rfc-i list re: v3 vocabulary, but not as much as I expected.  Are others content with the responses so far?
Notice the problems when working on docs, and so when not writing RFCs, not experiencing the pain.  Hard to contribute without the pain driver.  The longer we leave the list open, the more we will get contributions "in doing this doc, I hate doing x where x is fixable"
RSE declares end of January to be the cut off date for the new documentation.  Ted/Paul suggests draft submission cut off date, especially with nudges in the t2 weeks before that 
What about a v2 to v3 xslt?  That depends on what kind of features we think about.  As we define v3, Julian will implement it.  This isn't something that would be implemented in any case before the cut off.  No workable transformation steps.
HF to send an encouragement for features in mid January, reminder at end of January, cut off input February 14.

XML for ASCII art defining packet diagrams - good idea? bad idea?   would be nice to add to the XML spec if people think its a good idea.  Joe agrees it is a good idea nd have has implemented it (see https://github.com/hildjj/pdu2html) Joe and Julian have talked about what that would look like in XML, and we can start with that HTML to inform XML.  This could also work well as an Accessibility thing.  It could be the alt text for the PDU descriptions.  What's in there is straightforward programming, no interesting architecture.  
A tool that takes something more manipulable and produces XML from it that can be copied into a document.  We will need xml2rfc to xml2rfc in order to add link targets.  This could be one of the things that happen in that step.
This would have to be in the canonical document, the format people would use (alt text in HTML or the equiv for tables)


This proposal takes a human readable input and turns in to an ASCII output; why not an SVG output?  SVG is harder, not right for tables.  We have other typical ASCII art graphical patterns (i.e., ladder diagrams - see prototype https://github.com/hildjj/arrow); there are other tools also out there that we should leverage; state transition see dot (?)


The pattern is that there is human readable people as alt text and either access inut for tooling that generates SVG.  Should the input text be part of the canonical XML at the end?  Yes.  IF we get the tooling right, then people will write the text and the back end tooling will call the creation of the diagrams/tables - the requirements that say there is accessible text is the important one for the short term, this can be a multiphase approach.  We recognize a a point where the tools) will be extendible, so it would be good to call out that the first thing produced should anticipate additional work 


POST TO WIKI
from Joe Hildebrand to Everyone:
https://github.com/hildjj/pdu2html
from Ted Lemon to Everyone:
http://www.fugue.com/packet/
from Joe Hildebrand to Everyone:
https://github.com/hildjj/arrow
from RjS to Everyone:

http://sourceforge.net/projects/callplot/

from Paul Hoffman to Everyone:
https://svn.tools.ietf.org/svn/tools/xml2rfc
from Julian Reschke to Everyone:

http://trac.tools.ietf.org/tools/xml2rfc/trac/



HF to post notes from previous calls

3. Nevil and SVG - what can we do to help?
Joe sent email earlier, so Nevil has enough to go on for now.

4. Joe and the draft - need answer re: authorship.  I have several changes I would like to make/propose - what should I be editing?  
Post to list as participant, will have an SVN repository that Henrik had set up (Julian to sen

7. regarding non-ASCII encoding.  We have guidelines I think work (some word-smithing still in order) and should apply to the XML and the Publication formats.  Thoughts on whether this guidance belongs in its own RFC?

8. Draft Style Guide is (I think) just about finished collecting comments from the RPC.  We've had some back-and-forth discussion on this over the last week or so.  Paul and I have talked about whether this should be one, two, or more drafts (split apart what we have) given the implications some of the Guide has on tools and format (i.e., structure of the references, ordering and numbering (or lack thereof) of sections).  I don't like that idea - we've pulled out some very specific things like number of lines and columns, running headers and footers, how to structure a protocol table, but I don't think breaking it down further is helpful to the editors or the authors that want to know what rules we're using when we edit their docs.  Thoughts?