Subject: Re: RFC archival format, was: Re: More liberal draft formatting standards required

From: "Doug Ewell" <[email-masked]>
Date: Fri, 3 Jul 2009 09:07:22 -0600

As always when this discussion occurs, there are at least three 
different issues swirling around:

1.  ASCII-only vs. UTF-8
2.  Plain text vs. higher-level formatting, for text flow and 
readability
3.  Whether it is a good idea to include high-quality pictures in RFCs

There are not the same issue, and it would help combatants on both sides 
not to mix them up.

I don't know where the argument "don't help authors prepare I-Ds using 
the tools of their choice, unless they are open-source" fits into this 
picture.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

---

From: Douglas Otis <[email-masked]>
Date: Fri, 3 Jul 2009 10:14:11 -0700

On Jul 3, 2009, at 8:07 AM, Doug Ewell wrote:

> There are not the same issue, and it would help combatants on both  
> sides not to mix them up.
>
> I don't know where the argument "don't help authors prepare I-Ds  
> using the tools of their choice, unless they are open-source" fits  
> into this picture.

Perhaps some of these difficulties can be remedied by allowing use of  
RFC 2223 with perhaps extensions by RFC 2346.  What is missing are  
likely automation tools able to accept this original publication  
practice.  This approach allowing postscript, html, and pdf output has  
not kept pace with the automation provided by the combination of TCL  
code and XML formats detailed in RFC 2629.  If there is interest to  
revisit the use of roff and standardize preprocessors similar to that  
of xml2rfc, it should not take much effort to include these techniques  
as a means to extend what can be included within an ID and RFC.  For  
this not to create too many problems, RFC 2223 should be updated.

Reliance upon open source tools ensures the original RFCs and ID can  
be maintained by others, without confronting unresolvable  
compatibility issues.  It would also be a bad practice to rely upon  
unstable proprietary formats having limited OS support and significant  
security issues.

-Doug

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 3 Jul 2009 16:16:23 -0600

Douglas Otis <dotis at mail dash abuse dot org> wrote:

> compatibility issues.

Whether a tool is open source or not has nothing to do with how many 
people know how to use it.  Are you talking about maintainability of the 
documents or of the tools?

> It would also be a bad practice to rely upon unstable proprietary 
> formats having limited OS support and significant security issues.

Oh, stop.  Word 2007 can read and save Word 97 documents.  Applications 
for Windows, which has a 90% to 93% desktop market share, can hardly be 
said to suffer from "limited OS support."  And turning off macros is 
becoming more and more common among Word users; it's even a separate 
non-default document format under Word 2007.

I know The Penguin doesn't like the fact that Word is closed-source, 
but -- like the multiple discussions being lumped under "RFC archival 
format" -- we need to separate that issue from questions of whether the 
app is any good.  And if we're talking about an author using Word (or 
TextPad or roff or whatever) to pre-process a file into an RFC 
Editor-friendly format, which can then be converted to traditional RFC 
text or HTML or PDF or something, then isn't the horror of using Word 
limited to that author?

---

From: Douglas Otis <[email-masked]>
Date: Mon, 6 Jul 2009 17:40:00 -0700

On Jul 3, 2009, at 3:16 PM, Doug Ewell wrote:

>> Reliance upon open source tools ensures the original RFCs and ID  
>> can be maintained by others, without confronting unresolvable  
>> compatibility issues.
>
> people know how to use it.  Are you talking about maintainability of  
> the documents or of the tools?

The concern is about the application accepting document instructions  
and text and then generating document output.  When this application  
is proprietary, it is prone to change where remedies might become  
expensive or impossible.  The evolution in hardware tends to force the  
use of different operating systems which may no longer support older  
applications.

IIRC, I did work back in the early 90's that contained Russian written  
using Word 5.  Conversion proved difficult since proprietary fonts  
were needed.  Document recovery then required a fair amount of work to  
rediscover the structure and character mapping.  Trying to get any  
version of Word to generate plain text outputs consistently always  
seemed to be a PITA, that varied from version to version, and never  
seemed worth the effort.

> Oh, stop.  Word 2007 can read and save Word 97 documents.

Instead of 10 years, go back another 5 years.  When people are  
required to input Word Document "instructions" into their Word  
application, they might become exposed to system security issues as  
well.  The variability of the Word data structures makes identifying  
security threats fairly difficult, where many "missing" features seem  
to be an intended imposition as a means to necessitate use of the  
vendor's macro language.  Inherent security issues alone should  
disqualify use of proprietary applications.

>  Applications for Windows, which has a 90% to 93% desktop market  
> share, can hardly be said to suffer from "limited OS support."

When support is almost exclusively Windows, this still represents  
limited support.   It would be sending the wrong message to mandate  
the use of proprietary operating systems or applications in order to  
participate in IETF efforts.  After all, lax security often found  
within proprietary operating systems and applications threatens the  
Internet.

> And turning off macros is becoming more and more common among Word  
> users; it's even a separate non-default document format under Word  
> 2007.

The many automation features fulfilled by TCL and xml2rfc will likely  
be attempted with the native word processor scripts.   The latest  
Word, if you can afford it, is almost ISO/IEC 29500:2008 Office Open  
XML compliant.  Perhaps Word will be compliant in its 2010 version. :^(

> but -- like the multiple discussions being lumped under "RFC  
> archival format" -- we need to separate that issue from questions of  
> whether the app is any good.  And if we're talking about an author  
> using Word (or TextPad or roff or whatever) to pre-process a file  
> into an RFC Editor-friendly format, which can then be converted to  
> traditional RFC text or HTML or PDF or something, then isn't the  
> horror of using Word limited to that author?

Open source includes more than just Linux, and the exposure of  
requiring proprietary applications or operating systems would affect  
nearly all IETF participants that maintain existing documents or  
generating new ones.

-Doug

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 7 Jul 2009 22:19:05 -0600

Douglas Otis <dotis at mail dash abuse dot org> wrote:

> expensive or impossible.

The implication is that open-source software is inherently stable and 
commercial software is inherently unstable.  That's hardly a safe 
across-the-board assumption.

> The evolution in hardware tends to force the use of different 
> operating systems which may no longer support older applications.

"Tends to," "may."  Sounds like FUD to me.  I haven't had any trouble 
using Word 2003 under XP to read documents I created in Word 95 thirteen 
years ago.

> seemed to be a PITA, that varied from version to version, and never 

All work involving Cyrillic text was hit-and-miss fifteen years ago. 
Every word processor or other application had its own custom format. 
Many used KOI8-R, some used CP866 (or worse, CP855), a few used ISO 
8859-5.  PDF files depended entirely on the embedded font to convey 
meaning; copy-and-paste from PDF was useless.  Compatibility problems in 
the era before widespread Unicode adoption were hardly limited to Word.

> When people are required to input Word Document "instructions" into 
> their Word application, they might become exposed to system security 
> issues as well.

"Might be."  More FUD over security.  Has anyone suggested *requiring* 
users to employ mail-merge-type macros as part of I-D preparation, or is 
this just a general flame against Word?

> The variability of the Word data structures makes identifying security 
> threats fairly difficult, where many "missing" features seem to be an 
> intended imposition as a means to necessitate use of the vendor's 
> macro language.

Translation: I don't like Microsoft.

> Inherent security issues alone should disqualify use of proprietary 
> applications.

Hey, maybe if I say the word "security" enough times, people will get 
scared and not use Word any more!

> It would be sending the wrong message to mandate the use of 
> proprietary operating systems or applications in order to participate 
> in IETF efforts.

Who ever proposed to *mandate* the use of Windows or Word to write an 
I-D or otherwise participate in IETF efforts?  The proposal was to ALLOW 
users to prepare I-Ds using Word, and translate the output of Word into 
a format the IETF tools and RFC Editor can deal with.  Nobody ever said 
anything about *mandating* any of these tools.

> After all, lax security often found within proprietary operating 
> systems and applications threatens the Internet.

Pure and complete FUD, despite the real macro threats of a few years 
back.  The Internet will not fall apart if someone uses Word, feeds the 
output into a Word2RFC tool, and submits that output to IETF.

> nearly all IETF participants that maintain existing documents or 

Nobody, but nobody, has proposed requiring Word or Windows for IETF use.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 8 Jul 2009 16:56:19 -0700

On Jul 7, 2009, at 9:19 PM, Doug Ewell wrote:

>> The concern is about the application accepting document  
>> instructions and text and then generating document output.  When  
>> this application is proprietary, it is prone to change where  
>> remedies might become expensive or impossible.
>
> The implication is that open-source software is inherently stable  
> and commercial software is inherently unstable.  That's hardly a  
> safe across-the-board assumption.

When an application is open and the OS APIs change, recompilation  
often provides a remedy.  When the application is proprietary, whether  
patches become available as a remedy to an OS change depends upon the  
vendor, who might also expect some precondition be met.  This concern  
becomes somewhat more pressing when the same vendor controls both the  
application and the OS. :^(

> "Tends to," "may."  Sounds like FUD to me.  I haven't had any  
> trouble using Word 2003 under XP to read documents I created in Word  
> 95 thirteen years ago.

Often application APIs exhibit security vulnerabilities.  Unforetold  
changes to improve security inevitably will inhibit some  
applications.  It was your good fortune that the application was  
updated and made available at a reasonable price.  Backward  
compatibility modes to support older applications might lessen  
security, or simply not function.  After all, due to security  
concerns, libraries are continuously updated, sometimes in  
incompatible ways.

>> IIRC, I did work back in the early 90's that contained Russian  
>> written using Word 5.  Conversion proved difficult since  
>> proprietary fonts were needed.  Document recovery then required a  
>> fair amount of work to rediscover the structure and character  
>> mapping.  Trying to get any version of Word to generate plain text  
>> outputs consistently always seemed to be a PITA, that varied from  
>> version to version, and never seemed worth the effort.
>
> meaning; copy-and-paste from PDF was useless.  Compatibility  
> problems in the era before widespread Unicode adoption were hardly  
> limited to Word.

Not having source available significantly increased recovery efforts,  
nor could this effort be shared per the EULA. :^(

>> their Word application, they might become exposed to system  
>> security issues as well.
>
> "Might be."  More FUD over security.  Has anyone suggested  
> *requiring* users to employ mail-merge-type macros as part of I-D  
> preparation, or is this just a general flame against Word?

The concern about what might be embedded within documents was not in  
regard to simple macros, but that of a program language capable of  
compromising the operating system.   The concern was voiced in  
opposition to suggestions for using Word input files as a means to  
generate inputs for I-D or RFC generation utilities.  Of course,  
collaborators are likely to share these input documents as well.   
Sharing potentially hazardous input files among often virtual  
strangers represents a bad practice with respect to security.  This is  
not any different than warning users not to click on "greeting- 
card.exe" email attachments.

>> The variability of the Word data structures makes identifying  
>> security threats fairly difficult, where many "missing" features  
>> seem to be an intended imposition as a means to necessitate use of  
>> the vendor's macro language.
>

IMHO, unnecessary risks are being taken with respect to code having  
unknown origins.  In other words, this is an argument about ensuring  
people are able to recognize the gun before pulling its trigger.  As a  
result of their iFrame innovation and inevitable clickjacking,  
websites now need to inhibit iFrames with X-FRAME-OPTIONS (supported  
by IE 8 and NoScipts).  Users are also warned to disable this feature  
within their browsers.

WMA files with ".mp3" extensions will launch and prompt with a system  
pop-up for the installation of OS extensions obtained from unknown  
locations hidden within the mislabeled files.  Often users mistakenly  
trust messages that appear generated by the OS.  In view of mistaken  
trust, why are document related exploits low on a list of concerns  
when discussing the generation of archival formats?  Why call this  
FUD?  There is nothing uncertain about the concern.

> Hey, maybe if I say the word "security" enough times, people will  
> get scared and not use Word any more!

Detecting the malware contained within exchanged active content is  
becoming less effective, since malware from unknown sources evolve  
every few minutes into new forms.  Knowing what might be malware, and  
where it originated, remains a difficult problem made increasingly  
difficult by organizations that give security low priority.

>> proprietary operating systems or applications in order to  
>> participate in IETF efforts.
>
> Who ever proposed to *mandate* the use of Windows or Word to write  
> an I-D or otherwise participate in IETF efforts?  The proposal was  
> to ALLOW users to prepare I-Ds using Word, and translate the output  
> of Word into a format the IETF tools and RFC Editor can deal with.   
> Nobody ever said anything about *mandating* any of these tools.

There are security related reasons for not venturing down this path.   
In addition, other options might be allowed to fail with a rationale:

"Since Word generates an input that eventually receives IETF nit  
checker approval, other options become nonessential, since 80+% of  
desktops run Windows."

> back.  The Internet will not fall apart if someone uses Word, feeds  
> the output into a Word2RFC tool, and submits that output to IETF.

What fundamental design element has changed the basic security  
concerns related to the input files?  Simpler structures in XML form?

>> requiring proprietary applications or operating systems would  
>> affect nearly all IETF participants that maintain existing  
>> documents or generating new ones.
>

Sorry, but it would be wise not to consider this application due to  
its lack of security whenever expecting to have shareable process  
inputs.

-Doug

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 9 Jul 2009 10:22:14 +0200

On 9 jul 2009, at 1:56, Douglas Otis wrote:

> The concern was voiced in opposition to suggestions for using Word  
> input files as a means to generate inputs for I-D or RFC generation  
> utilities.

Nobody suggested that.

I said that it would be useful to be able to use a "standard issue"  
word processor to write drafts. As I explained in a subsequent  
message, what I meant by that is any word processor that can generate  
a document with styles. Word is one of those word processors, but  
certainly not the only one, and you'll never hear me recommend Word  
for anything.

---

From: james woodyatt <[email-masked]>
Date: Thu, 9 Jul 2009 09:15:23 -0700

> sides not to mix them up.

I admire the attempt to separate these issues into orthogonal  
concerns, but I don't think it can succeed.

The common aspect of all these issues is the question of whether our  
archival format should A) continue to be limited to a string of ASCII  
characters formatted for printing with a fixed-width font, or B) if it  
should be expanded to include a document archival format that can  
preserve font, style and figures.

There is a related but separable topic of discussion once option B) is  
open for debate: what precisely should be the set of primary natural  
languages used in IETF documents?  Should it continue to be English  
only?  I'd very much prefer to see *that* discussion vigorously  
deferred while our archival format continues to be the largest  
practical obstacle to multilingualism.  I believe there are no  
reasonable candidates for archival formats that can preserve font,  
style and figures without also providing for localization.

> using the tools of their choice, unless they are open-source" fits  

Compared to the previous two issues, this one is just not so much  
important.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 9 Jul 2009 19:01:31 +0200

On 9 jul 2009, at 18:15, james woodyatt wrote:

> B) is open for debate: what precisely should be the set of primary  
> natural languages used in IETF documents?  Should it continue to be  
> English only?  I'd very much prefer to see *that* discussion  
> vigorously deferred while our archival format continues to be the  
> largest practical obstacle to multilingualism.

There are two things that together make it completely impossible to  
adopt more working languages:

1. We don't have any other languages in common than English
2. We don't have the money for translation/interpretation services

Dus als we naast Engels ook andere talen gaan gebruiken betekent dat  
dat de niet-Engelse documenten maar door een deel van de IETF- 
participanten gelezen kan worden, wat natuurlijk niet de bedoeling is.

Or:

So if we start using other languages in addition to English then the  
non-English documents can only be read by part of the IETF- 
participants, which of course defeats the purpose.

Now I'd be very happy to be able to conduct IETF business in Dutch,  
but I'd be very much opposed to having to learn a new language to  
participate in the IETF. It took me long enough to learn English...

---

From: james woodyatt <[email-masked]>
Date: Thu, 9 Jul 2009 10:08:30 -0700

On Jul 9, 2009, at 10:01, Iljitsch van Beijnum wrote:
> adopt more working languages [...]

My point wasn't to argue that we should consider working in non- 
English languages, but simply to explain why it's reasonable to rule  
that discussion out of scope while we get on with talking about  
archival formats: there is no reason to believe that expanding our  
archival formats would further limit our future options for adopting  
new working languages.  (I'm thinking centuries into the future here.)

---

From: Byung-Hee HWANG <[email-masked]>
Date: Mon, 13 Jul 2009 05:39:56 +0900

"Doug Ewell" <[email-masked]> writes:

> Applications for Windows, which has a 90% to 93% desktop market share,
> can hardly be said to suffer from "limited OS support."  And turning
> off macros is becoming more and more common among Word users; it's
> even a separate non-default document format under Word 2007.
>
> format" -- we need to separate that issue from questions of whether
> the app is any good.  And if we're talking about an author using Word
> (or TextPad or roff or whatever) to pre-process a file into an RFC

Doug,

Already, above, Douglas pointed out for your comments correctly. RFC
format is different from a market share format by the purpose. Do you
have been think about the word "compatibility" and "standard"? Here is
IETF, not a market.. ;;  

Sincerely,

-- 
Byung-Hee HWANG, KNU 
∑ WWW: http://izb.knu.ac.kr/~bh/

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 12 Jul 2009 17:42:36 -0600

> have been think about the word "compatibility" and "standard"? Here is 

This thread has been headed down the wrong path from the outset, as soon 
as Tony Hain wrote on July 1:

> An alternative would be for some xml expert to fix xml2rfc to parse 
> through the xml output of Word. If that happened, then the 
> configuration options described in RFC 3285 would allow for wysiwyg 
> editing, and I would update 3285 to reflect the xml output process. I 
> realize that is a vendor specific option, but it happens to be a 
> widely available one.

and Douglas replied by going off on Word:

> Word's closed code is continuously changing.   Availability of this 
> closed application depends upon OS compatibility and version 
> regressions.   Both are moving targets.  In addition, Word formats 
> permit inclusion of potentially destructive scripts within highly 
> flexible and obfuscating structures.

Nobody in this thread has suggested publishing RFCs or distributing I-Ds 
in any native Microsoft Word format.  The only thing Tony suggested was 
to "fix xml2rfc" to convert XML documents generated by Word into the 
standard format for RFCs and I-Ds, just as xml2rfc already converts XML 
documents written in the RFC 2629(bis) format into the standard format 
for RFCs and I-Ds.  I modified that, along the course of the thread, to 
suggest that a separate "word2rfc" tool might be a more sensible option.

To the extent the .doc format is "highly flexible" -- which isn't really 
true anyway; it's been rather stable since 1997, and the new XML-based 
format is called .docx -- I can see that as an obstacle for someone 
writing such a conversion tool.  But I challenge anyone to find the 
slightest suggestion in this thread that we should publish IETF 
documents directly in Word format.  Let's at least argue the same point, 
folks.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 13 Jul 2009 12:56:43 -0700

On Jul 12, 2009, at 4:42 PM, Doug Ewell wrote:

> This thread has been headed down the wrong path from the outset, as  
> soon as Tony Hain wrote on July 1:
>
>> editing, and I would update 3285 to reflect the xml output process.  
>> I realize that is a vendor specific option, but it happens to be a  
>> widely available one.
>
> I modified that, along the course of the thread, to suggest that a  
> separate "word2rfc" tool might be a more sensible option.
>
> To the extent the .doc format is "highly flexible" -- which isn't  
> really true anyway; it's been rather stable since 1997, and the new  
> XML-based format is called .docx -- I can see that as an obstacle  
> for someone writing such a conversion tool.  But I challenge anyone  
> to find the slightest suggestion in this thread that we should  
> publish IETF documents directly in Word format. Let's at least argue  
> the same point, folks.

These concerns took your concept to a logical conclusion.  Notice the  
definition for "sttbListNames" in:
http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx

Logically, rather than modifying TCL xml2rfc code to interpret xml2rfc  
structures embedded within Word structures, Visual Basic would  
represent a more likely tool, since it is already supported by the  
Word application.  To view this support, double click a control in  
Design Mode, and see Word open a Visual Basic editor.  Visual Basic  
provides access to ActiveX routines, where in 2007, additional content  
based routines along with custom XML storage for its binary format had  
been added.  Although placing controls directly into a Word document  
is not the norm (prints as a graphic),  these controls can generate  
RFC compliant outputs, and even bibliographic XML fragments to assist  
in the generation of the bibliographic sections.  No TCL code would be  
needed.    A less risky alternative to that of Word might be to use  
Java with Open Office.

 From the IETF perspective, in addition to the ASCII text files being  
used as the archived form, xml2rfc files are retained to generate  
alternative presentations and as input for generation process.  The  
concern related to the use of the Word input format, which has changed  
in 97, 00, 02, 03, 07, and is likely again in 10, remains that of  
security.  Changes are not always apparent, and even format  
documentation can not be relied upon when details related to active  
components are ill defined.  The security concern is in regard to the  
embedded program language, especially when the program is to be relied  
upon as the means to generate IETF compliant outputs.  The Internet is  
not a safe place, where a practice of embedding programs that can  
cause harm into what could have been innocuous text should be  
considered a bad practice.  Currently, collaboration between  
individuals might be accomplished by sharing xml2rfc input files,  
which are also retained with the plain text  RFC output.  Reliance  
upon Word input files as a replacement for xml2rfc files will  
invariably lead to a bad practice of depending upon potentially  
harmful embedded programs.

Use of xml2rfc conversions has uncovered some odd quirks.  The tool  
does not cache bibliographic database selections.  Either this works  
on-line, or the entire database needs to be local.  Not to diminish  
the service offered by Carl Malamud, occasional sporadic connections  
to the xml.resource.org servers can be a cause of angst for authors  
who have not obtained the entire tarred xml bibliographic database.   
Lately, the dependability of the xml2rfc approach has become less  
reliable when dealing with cryptic entries and beta TCL needed to  
generate I-D boilerplate language as required by nit checker.

This makes one wonder whether there could be a better way.  A hybrid  
approach might offer the similar features found in xml2rfc with the  
simpler the inputs supported by 'roff.  This would not exclude the use  
of Word, but would not depend upon any of Word's content automations.   
Perhaps a bit of Perl could provide the pre and post processors to  
handle something that resembles the xml2rfc front section.  While roff  
is not perfect, it has been more stable than other WISIWYG word  
processors and, when used in conjunction with separate pre/post  
processors, can generate the desired alternative outputs.

-Doug

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Jul 2009 22:10:22 +0200

Douglas Otis wrote:
> ...
> Use of xml2rfc conversions has uncovered some odd quirks.  The tool does 
> not cache bibliographic database selections.  Either this works on-line, 
> or the entire database needs to be local.  Not to diminish the service 
> offered by Carl Malamud, occasional sporadic connections to the 
> xml.resource.org servers can be a cause of angst for authors who have 
 > ...

If it hurts, don't do it.

Translation: if you don't want to rely on network resources, keep a 
local copy. I recommend that anyway, so that the xml2rfc input file is 
self-contained.

Relying on external references for internet drafts is fragile anyway: 
that the reference automatically updates to the latest version may look 
handy, but may cause authors to miss important changes.

> ...
> not obtained the entire tarred xml bibliographic database.  Lately, the 
> dependability of the xml2rfc approach has become less reliable when 
> dealing with cryptic entries and beta TCL needed to generate I-D 
> boilerplate language as required by nit checker.
> ...

The "experimental" version (http://xml.resource.org/experimental.html) 
is as stable as predecessor versions; the main reason it hasn't been 
released is that the authors (IMHO) expected more boilerplate changes to 
occur.

And what exactly do you mean by "cryptic entries"?

> processors, can generate the desired alternative outputs.

I think the right approach is to either help maintaining the TCL code, 
or to rewrite xml2rfc in a different language.

BR; Julian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 13 Jul 2009 22:32:12 +0200

On 13 jul 2009, at 21:56, Douglas Otis wrote:

> Visual Basic would represent a more likely tool, since it is already  
> supported by the Word application.

Only in some versions. In the latest MacOS version it's not supported.

> This makes one wonder whether there could be a better way.

I think a better way would be to create a new intermediate format that  
can both be an input to generate XML2RFC code _to_ as XML2RFC code  
_from_, as well as HTML and the current RFC archival format.

This solves the problem that converting anything else into XML2RFC a  
reverse lossy process: XML2RFC needs more than what other formats can  
supply so automatic conversion (from, for instance, Word) is impossible.

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 13 Jul 2009 20:58:02 -0600

Douglas Otis <dotis at mail dash abuse dot org> wrote:

> ...  The concern related to the use of the Word input format, which 
> has changed in 97, 00, 02, 03, 07, and is likely again in 10, remains 
> that of security.  Changes are not always apparent, and even format 

OK, I've had just about enough of this fearmongering.  Why on Earth 
would someone use Visual Basic within Word to write a utility to convert 
Microsoft Word ***XML*** documents to an IETF-acceptable format, when 
there are much better tools for processing XML?  Why would someone not 
specifically write such a utility to ignore or reject any Word document 
containing executable code?  Are we that stupid?

Based on the logic I am reading here, I should stop writing code in 
Visual Studio because it could be used to create a worm or virus, should 
stop turning on my computer because the box could be used to beat 
someone over the head, should stop driving my car to work in the morning 
because someone could crash it into a preschool.  We shouldn't try to 
stop people from using every tool that could potentially, theoretically, 
be misused or used intentionally for evil.  I use Word almost every day 
and I haven't encountered a macro virus for years, probably because I 
don't open e-mail attachments from unknown senders and don't visit 
MySpaceCoolAddOns.com, and have also learned to walk upright.

I don't plan to respond further to this thread because it is obviously 
going nowhere.

This, on the other hand, from Iljitsch van Beijnum <iljitsch at muada 

> supply so automatic conversion (from, for instance, Word) is 

is a genuinely useful and productive counterargument against the whole 
"word2rfc" concept.

---

From: Doug Otis <[email-masked]>
Date: Tue, 14 Jul 2009 02:20:49 -0700

On Jul 13, 2009, at 7:58 PM, Doug Ewell wrote:
> Why on Earth would someone use Visual Basic within Word to write a  
> utility to convert Microsoft Word ***XML*** documents to an IETF- 
> acceptable format, when there are much better tools for processing  
> XML?

For a third-party application to interpret the changing Word document  
format, even in XML form, would require extensive and ongoing  
support.  This support would go well beyond what is currently needed  
to interpret the simpler xml2rfc structures.  Using Word input files  
alone is likely to represent an effort few could afford to support.

>  Why would someone not specifically write such a utility to ignore  
> or reject any Word document containing executable code?

Use of the bundled program language that operates at an object level  
can hide underlying format changes and avoid the related support  
effort.  Using the bundled programming language likely represents the  
_only_ practical method for directly utilizing Word input files, as  
was suggested.  IMHO, this was a logical conclusion.

> This, on the other hand, from Iljitsch van Beijnum <iljitsch at  
> muada dot com>:
>
>> This solves the problem that converting anything else into XML2RFC  
>> a reverse lossy process: XML2RFC needs more than what other formats  
>> can supply so automatic conversion (from, for instance, Word) is  
>> impossible.
>
> is a genuinely useful and productive counterargument against the  
> whole "word2rfc" concept.

Disagree.  The goal would be to generate RFC and ID documents.   
Requiring XML2RFC intermediaries negates the benefit of using Word.   
Beyond security concerns related to relying upon the bundled program  
language, not having this feature supported in OSX or Unix represents  
yet another concern.  Iljitsch view of XML2RFC intermediaries is not  
practical, but Word2rfc is not impossible when the bundled program  
language is used.  It can be done, but it would not be wise.

On Jul 13, 2009, at 1:10 PM, Julian Reschke wrote:
> The "experimental" version (http://xml.resource.org/ 
> experimental.html) is as stable as predecessor versions; the main  
> reason it hasn't been released is that the authors (IMHO) expected  
> more boilerplate changes to occur.
>

There was little documentation for what would satisfy the nit checker  
a few months ago.  It was a challenge to know what was needed for the  
rfc structure.  The needed ipr parameter appeared rather cryptic.

> I think the right approach is to either help maintaining the TCL  
> code, or to rewrite xml2rfc in a different language.

To support the generation of MHTML, as some have suggested, the  
logical intermediary format seems to be XSLT (for defining xml2rfc  
constructs).

http://tools.ietf.org/html/rfc2557
http://people.dsv.su.se/~jpalme/ietf/mhtml.html

IMHO, pre-processors with roff might offer simpler and cleaner inputs,  
especially for the vision impaired.  A post process could then  
generate simpler MHTML formats.

-Doug

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Jul 2009 11:31:37 +0200

Doug Otis wrote:
>> released is that the authors (IMHO) expected more boilerplate changes 
>> to occur.
>>
> There was little documentation for what would satisfy the nit checker a 
> few months ago.  It was a challenge to know what was needed for the rfc 
> structure.  The needed ipr parameter appeared rather cryptic.
> ...

Well, the @ipr value needs to capture several dimensions, such as type 
of IPR *and* time scale (because the IETF rules keep changing). Of 
course the values could be made less cryptic, but this seems to be 
something of a bike shed discussion, as long as the values a well 
documented.

> To support the generation of MHTML, as some have suggested, the logical 
> intermediary format seems to be XSLT (for defining xml2rfc constructs).

We have that already (xml2rfc->XSLT->(X)HTML), in case you didn't notice.

> especially for the vision impaired.  A post process could then generate 
> simpler MHTML formats.

Best regards, Julian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 14 Jul 2009 12:06:19 +0200

On 14 jul 2009, at 11:20, Doug Otis wrote:

> For a third-party application to interpret the changing Word  
> document format, even in XML form, would require extensive and  
> ongoing support.

In principle, yes. In practice this would probably not be a huge deal  
compared to what needs to happen to conform to new ideas from the  
lawyers. Obviously Microsoft didn't come up with an XML file format  
and then push it through standardization to do all of that again a few  
years from now. We can expect the format to be extended, but the basic  
stuff will probably remain the same for a long time. (And we only need  
the REALLY basic stuff here!)

>>> a reverse lossy process: XML2RFC needs more than what other  
>>> formats can supply so automatic conversion (from, for instance,  
>>> Word) is impossible.

> Disagree.  The goal would be to generate RFC and ID documents.

Directly from .docx files?

> Requiring XML2RFC intermediaries negates the benefit of using Word.

I disagree. If it were possible to generate XML2RFC format from Word  
format that would be extremely useful, because that way people who can  
work with Word can generate XML2RFC that can then be used by people  
who work in that format, including the RFC editor. But as I've said  
before, the semantic markup in XML2RFC makes it impossible to create a  
working XML2RFC file from an input that doesn't have the same semantic  
markup. Although tagging semantics can probably be a bit more pleasant  
in a WYSIWYG tool than in XML source, it still has all the  
documentation and version breaking issues that XML2RFC has, so that  
doesn't really buy us much.

> Iljitsch view of XML2RFC intermediaries is not practical, but  
> Word2rfc is not impossible when the bundled program language is used.

I was talking about a new intermediate format. What I'm thinking of is  
a constrained HTML. HTML can be used both as input and output in word  
processors and text editors with only minimal extra steps, if any. A  
lot of those generate atrocious HTML, but this can easily be fixed by  
removing everything that doesn't conform to the constraints.

Converting from XML2RFC format to HTML would be lossy, so converting  
in the other direction would entail some manual work. But for the  
basic text in the middle a 1-to-1 mapping would be possible, which  
would help a lot.