RFC Format IAB Session - IETF 89 - Notes xml2rfc v2 vocabulary - document existing vocabulary in use xml2rfc v3 vocabulary - making changes based on design goals describing more of the processor stuff since xml will be the canonical format HTML - HF has the pen on this one xml -> html with as much data as would if created using html SVG - indicates elements/attributes allowed in SVG figures how are people going to create SVG drawings played with different drawing packages - tend to produce bulky SVG files create using whatever tool you like, then strip out as needed and see if looks right text version of a figure that a blind person could have read out to them - working on this PDF - in progress will follow up with - those who use PDF files in an online fashion, what features do you use or need/prefer to use; document structure, bookmarks, links, etc. discussion on rfc-interest non-ascii in RFCs reqs expect majority of docs to still be in ascii, so covering exceptions allowed in: person names - ascii variant is required acknowledgements body of the document - where required for implementation and understanding of content requires identifying codepoint as well ??: if can use non-ascii for personal names, why not authors address? Heather: one of main points for author's addresses section is to be able to identify and contact the authors... need to think about this one how to use IDN could be used as guide in the document "use" versus "mention" sip-torture test doc - good test case to use for examples non-ascii chars in artworks not allowed for drawing structure bibliographic text reference entry must be in english because people must be able to find the refs Julian Reschke: best way to find things in refs is to include a URI do refs need to follow our ref format? John Klensin: treat it as a translation as several different RH: agree with JCK; also matches rule in the body of the document Keith Moore: - examples of pubs in language other than english feature extraction from xml is the right thing for the primary ref to be in English vs Russian (example) - internationalized email ugly ascii representation Henrik Levkowetz: need more specification how want unicode points to appear vs ascii text if want tools to automatically handle this get it right with tools support is to encapsulate every point want non-ascii char in element John Klensin: km comment - answer to ref organization question is to make sure everything is tagged/marked up so processor knows what it is internationalized email addresses - no ascii representation for certain chars. will need to make decision how to handle this Andrew Sullivan: one of difficulties going to have with putting char in place because tools try to help you and sometimes do the wrong thing char encoding might be the right thing Elwyn Davies: box drawings - can use non-ascii in text within pics?? carefully chosen alphabetic language with russian, it's left to right and alphabetic. What happens when pick right to left language and what font to use? Heather: needs further thought Phil: Henrik proposed that authors markup and encode readable by people means being edited by people we do not need rules for these things because leave this up to the rpc then after have first years worth of examples, then see whether adding something makes sense additional tools to call things out better during AUTH48 Joe Hildebrand: will Henrik: to ph, need tool to verify that doc followed rules in this draft separate support for whether got exact replication in canonical format John Klensin: use element that picks up char in code point or native char form and has attributes on it so it picks it up combining sequences - impossible to generate except with specific unicode tools need markup to render correctly; don't expect authors to be experts in unicode dave crocker: Joe H: concerned with coming up with enough tags to address all examples and ref entries; beyond our expertise; reluctant to go too far down that path Andrew Sullivan: encoding is needed to make sure these things are right