Subject: [Tools-discuss] Re: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC

From: "Alex Rousskov" <[email-masked]>
Date: Tue, 05 Apr 2005 13:30:31 -0600

On Wed, 2005/03/02 (MST), <[email-masked]> wrote:

> I've suggested (via Reply-To) discussion on the IETF list.

Bruce,

	Thanks a lot for reviewing and commenting on the draft!

I am preparing a revision to address Last Call comments.

I am not on the IETF list anymore (too much noise), so I am CCing Tools  
discussion list instead. Please feel free to forward elsewhere.

> It seems odd that there is no provision for upload of nroff source
> (RFC 2223) mentioned in sections 7 and 8 of the draft.

The motivation for uploading XML sources is that they are used by tools  
and humans processing submitted drafts. For example, RFC Editor is often  
using authors' XML sources. We expect such uses to grow once XML sources  
are easily available. In fact, the submission tool itself is expected to  
extract useful metadata from XML sources.

What would be the motivation for uploading nroff sources? I understand  
that some folks prefer to create drafts using nroff, MS Word, or other  
formats, but what would be the primary benefit of uploading those sources  
to IETF repositories? And if nroff sources are accepted, should we accept  
MS Word and other source formats?

Thank you,

Alex.

_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-discuss

---

From: "Alex Rousskov" <[email-masked]>
Date: Tue, 05 Apr 2005 14:27:40 -0600

Frank,

I am not on the IETF list anymore (too much noise), so I am CCing Tools  
discussion list instead.
Please feel free to forward elsewhere.

On Wed, 2005/03/02 (MST), <[email-masked]> wrote:

> | If any of the include PIs
> s/include/included/

"include PIs" was intentional. I added a phrase defining this unfortunate  
term.

> | the Toolset attempts to generate plain text format from
> | submitted XML sources (R70/b).
> |
> | If XML sources are available, the Toolset generates HTML
> | draft format
> In the latter case it apparently _also_ generates (X)HTML.  In
> the former case if an attempt to generate plain text fails, why
> not exit with an error mesage instead of _also_ trying HTML ?

In the former case, if a generation attept fails, then the draft will not  
be auto-posted. Please see R113:

     If any error is found, automated posting becomes impossible (R113/a).
     This rule applies to all errors, even those that do not refer to R113  
and
     do not explicitly prohibit automated posting.

It seemed like a waste of readers attention to explicitly refer to R113  
 from every rule because there are so many rules that depend on R113. Do  
you agree?

Generating HTML even if plain text generation fails can be useful to give  
the submitter (and/or the Secretariat) more warnings/errors about HTML  
generation. I have seen cases where HTML generation would fail for reasons  
different from plain text generation... Not generating HTML would only  
save a few CPU cycles and storage bytes. I do not think we should optimize  
in that direction.

> | The Toolset requires author email addresses
> It should allow to specify an address outside of the submitted
> draft for privacy reasons.  The author could use an URL in the
> published text, which is not "obviously" a mail address, e.g.
> <uri>http://purl.net/xyzzy/mailto/webmaster</uri> in XML.

I think the Toolset allows to specify an address outside of the submitted  
draft but does not allow automated postings of such anonymous drafts. That  
is, a draft without an author email would go [via the Toolset] to the  
Secretariat for manual validation. Do you think that is a reasonable  
interface?

> | An IETF IPR Statement and other boilerplate required for
> | drafts according to [RFC3667] and [RFC3668
> s/RFC3667/BCP 78/ and s/RFC3668/BCP 79/

I am not sure I can do the above with xml2rfc. Does anybody know how  
(without creating a custom reference)? Note that the expanded references  
at the end of the draft do say "BCP 7x".

> Actually I don't understand why "the Toolset" cannot insert an
> equivalent ipr="full3667" or ipr="fullshit" on its own behalf,
> asking the author how much "fullshit" (s)he's ready to tolerate
> at this stage.

I think that the Toolset should not create or modify IPR statements. There  
is too much liability/danger there, and it would complicate the interface.  
My understanding is that the vast majority of submitted drafts will have  
one of the standard/approved boilerplates. Given the risks and  
complications, I would argue that IPR guessing/generation should be out of  
scope. Any other opinions?

> Please note somewhere that submissions to the RfC-editor don't
> require "fullshit" as long as they cover it by broader rights.

Similar argument applies. The Toolset does not require any specific IPR.  
It requires specific IPRs only for _automated_ posting of the drafts. I  
doubt the Toolset can reliably interpret non-standard IPR statements. A  
human judgement would be required. If IETF standardizes a "broader rights"  
template, the Toolset should allow automated posting with that IPR, of  
course. Do you agree with this logic?

> | Toolset may try several recent xml2rfc versions
> It should also try a decent XML validator before xml2rfc based
> on the specified DTD.

For the quoted context, I do not think so (the draft here talks about  
comparing generated plain text version with the submitted plain text  
version).

In general, the Tools team spent a lot of cycles debating whether  
submitted XML must be valid. I think the current draft reflects the  
outcome of those discussions by not requiring explicit validity, but we  
can reopen that debate if others feel like it.

> chapter 16 (email-interface) you have the required mail address
> even if you can't extract it from the meta-data.

Do you mean that the "From" address can be used instead of the email from  
the draft? What if I did not send my own draft (intentionally or not)?

Thank you for all the other comments! I have tried to apply them.

Alex.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 5 Apr 2005 18:07:20 -0400

> discussion list instead. Please feel free to forward elsewhere.

I'm copying the IETF list for closure.
 
> and humans processing submitted drafts.

Likewise for nroff source.

> For example, RFC Editor is often   
> using authors' XML sources.

While I have no data to either confirm or refute that assertion, RFC
2223 section 3 and the draft successor to that document both explicitly
state that the RFC Editor uses nroff.

> We expect such uses to grow once XML sources   

I suspect that similar metadata could be extracted from nroff source,
at least if a suitable macro package (e.g. as described in
draft-lilly-using-troff) is used.

> What would be the motivation for uploading nroff sources?

In addition to extraction of metadata,

o nroff is used by the RFC-Editor (RFC 2223 section 3); keeping the
  same source format from initial draft through RFC production can ease
  the workload for authors and the RFC Editor

o automatic generation of plain text, PostScript, PDF, HTML (including
  line diagrams, tables, data formats, etc.), preserving page layout,
  from single source

o (if a suitable macro package is used) no need to upload boilerplate;
  provided that the (IETF copy of the) macro package is maintained,
  up-to-date boilerplate can be generated automatically

o ability for authors w/o access to formatting tools to upload easily-
  produced document source which can be used to produce a formatted
  draft
 
> I understand   
> to IETF repositories?

For nroff, see above.  As I haven't suggested other formats, I have no
comments at this time regarding putative benefits attributable to them.

> And if nroff sources are accepted, should we accept   

For me, source formats other than nroff are uninteresting (i.e. "I
don't care").

---

From: "Alex Rousskov" <[email-masked]>
Date: Tue, 05 Apr 2005 21:56:18 -0600

On Tue, 2005/04/05 (MDT), <[email-masked]> wrote:

>> On Tue April 5 2005, Bruce Lilly wrote:
>
> Yes, but speaking from personal experience, that doesn't mean they'll use
> _your_ nroff sources. I stopped bothering to send in my nroff sources  
> when I found out that the RFC Editor wasn't using it

That was my (possibly incorrect) impression as well:
RFC Editor creates nroff from XML or plain text.
Thus, I did not consider nroff as "source" in this context
(note that I did not say RFC Editor is not using nroff).
Again, I could be wrong.

However, I would like to avoid focusing too much attention on current RFC  
Editor practices, regardless of whether you  consider them perfect or  
arcane. I am sure that folks will write many tools to extract info from  
XML drafts once XML drafts are available. I would be surprised if the same  
would happen to nroff sources, especially long-term, especially in  
competition with XML. There are many reasons, including general knowledge  
of the subject and libraries availability.

Does anybody have any statistics showing the percentage of current  
Internet-Drafts written using xml2rfc? I do not volunteer, but I suspect  
there is something specific to xml2rfc plain text output that a simple  
script can detect while grepping through the drafts archive. Can the same  
be done for nroff? These stats would help us to understand at least the  
current environment better...

Thank you,

Alex.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 06 Apr 2005 01:29:23 +0200

Alex Rousskov wrote:

> I am not on the IETF list anymore (too much noise)

It's rather quiet at the moment, but no problem.

> so I am CCing Tools discussion list instead.  Please feel
> free to forward elsewhere.

I'm not on the "tools" list, so let's start an experiment, you
post on the "tools" list, Bruce on the general IETF list, and I
use the [email-masked] (with a reason, see below).

> It seemed like a waste of readers attention to explicitly
> refer to R113 from every rule because there are so many
> rules that depend on R113. Do you agree?

Yes, assuming that it was no forward reference.  I read the
text top down, and mainly the parts about privacy, xml2rfc,
and the new BP 78 / 79.

> I think the Toolset allows to specify an address outside of
> the submitted draft but does not allow automated postings of
> such anonymous drafts.  That is, a draft without an author
> email would go [via the Toolset] to the Secretariat for
> manual validation. Do you think that is a reasonable
> interface?

As long as it doesn't insist on a visible mail address for the
address harvesters it's fine.  It could automatically send a
challenge to the address specified outside of the draft, with
an URL for the confirmation.

> I am not sure I can do the above with xml2rfc.  Does anybody
> know how (without creating a custom reference)?

Version 1.29 will handle it, but you have to change your old
ipr="full3667".  Maybe that's a trick to keep all draft and
xml2rfc authors alert, let's hope that 1.29 offers a neutral
ipr="fullEULA" (I don't insist on "fullshit" if it's just the
actual version of these BCPs ;-)

For a general solution (all BCPs by their number) I don't know
what <xref> can do, probably you can overwrite the "RfC nnnn"
by "BCP mm".  Or maybe it's better to start separate "bibxml"
directories for STDs and BCPs, always referencing the actual
RfC(s) for the corresponding STD or BCP (?)

In one case it's settled, Scott Hollebeck said that we should
now start to use 2234bis...

http://xml.resource.org/public/rfc/bibxml3/reference.I-D.crocker-abnf-rfc2234bis.xml

...instead of 2234 (ABNF), and let the RfC editor fix it later
manually, when 2234bis got an RfC number.  Something in this
bibxml-system cries for PURLs, doesn't it ?  Or should existing
I-D references simply be updated to reflect the later RfC, e.g.
reference.I-D.klyne-hdrreg-mail.xml => reference.RFC.4021.xml ?

> I think that the Toolset should not create or modify IPR
> statements. There is too much liability/danger there

Yes, that's the precise reason why nobody should publish I-Ds
before he has published a will and hired a lawyer.  It's the
IETF who insists on this "fullEULA" ("EULA" is a synoym for
a bogus legal statement in the EU, like e-mail "disclaimers").

I'd even grant IETF a "creative commons share alike license"
for I-Ds, and more for RfCs.  But not this BCP 78/79 legalese,

> My understanding is that the vast majority of submitted
> drafts will have one of the standard/approved boilerplates.

Maybe there are some drafts which are simply never published.

My best legal advise (IANAL):  Do NOT publish I-Ds unless you
really must.  Don't bother innocent bystanders with texts that
start and end with tons of legal crap, neither you nor your
readers know what it really means.  Either somebody will sue
you, or patent whatever you've written.

>> It should also try a decent XML validator before xml2rfc
>> based on the specified DTD.

> For the quoted context, I do not think so (the draft here
> talks about comparing generated plain text version with the
> submitted plain text version).

Okay, then do it elsewhere.

> the Tools team spent a lot of cycles debating whether
> submitted XML must be valid.

Yes, they MUST be valid XML, the 2629 DTD is relatively simple.

It's no problem if a valid XML input somehow does not make it
through xml2rfc, but if invalid XML apparently works it's bad.

At the moment xml2rfc is not very smart to detect and report
problems.  That's the reason why I posted this on the xml2rfc
list, maybe <http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/>
could help to find obscure xml2rfc problems.

In one case validator.w3.org found a (trivial) problem missed
by xml2rfc.  IMHO "valid" XML (as determined by an extra tool,
validator.w3.org is officially only for SGML) is a MUST.

> we can reopen that debate if others feel like it.

Please do this, as it is xml2rfc requires interested users, it
would be better if it's never forced to process invalid XML.

>> chapter 16 (email-interface) you have the required mail
>> address even if you can't extract it from the meta-data.

> Do you mean that the "From" address can be used instead of
> the email from the draft?

No, only if there is no (obvious) address in the draft.

> What if I did not send my own draft (intentionally or not)?

Same problem as a forged address in the draft, or isn't it ?

                         Bye, Frank

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 05 Apr 2005 19:38:21 -0400

>state that the RFC Editor uses nroff.

See slides 24, 61, and 62 of ftp://ftp.rfc-editor.org/in-notes/rfc-editor/tutorial62.pdf

		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: [email-masked]
Date: Tue, 05 Apr 2005 16:29:26 -0700 (PDT)

Yes, but speaking from personal experience, that doesn't mean they'll use
_your_ nroff sources. I stopped bothering to send in my nroff sources when I
found out that the RFC Editor wasn't using it (this despite having tried to use
the same macro package in the same way, and having switched from a much better
system than nroff in the first place in order to be RFC Editor friendly).

Shortly after finding out about this I switched to using xml2rfc, in part
because Marshall spent considerable time aligning its nroff output with the RFC
Editor's needs. And some time after that it became possible to send the RFC
Editor the XML source and have them use it. I haven't looked back since.

> > extract useful metadata from XML sources.

Exactly. And powerful tools to assist in this sort of extraction are readily
available.

> draft-lilly-using-troff) is used.

Bruce, with all due respect, the effort you have expended on developing this
seems to me to be headed in the wrong direction. IMO the place we are at with
xml2rfc and the RFC Editor's acceptance of the format is much better than
anything can ever get from any scheme that is based on nroff as the primary
format.

>   the workload for authors and the RFC Editor

See above. Use of xml2rfc accomplishes this goal. Use of nroff does not.

>   line diagrams, tables, data formats, etc.), preserving page layout,

All possible with the xml2rc format.

>   up-to-date boilerplate can be generated automatically

Xml2rfc has been realigned each time the boilerplate requirements have changed.
This has proved to be tremendously convenient.

>   produced document source which can be used to produce a formatted
 
IMO neither nroff source nor XML source qualify as "easily produced". But the
number of tools for producing and vetting XML is large and growing. (I
personally use something called "Exchanger XML Editor".) I don't think the same
can be said for nroff.

				Ned

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 6 Apr 2005 07:52:19 -0400

On Tue April 5 2005 23:56, Alex Rousskov wrote:

> I suspect
> script can detect while grepping through the drafts archive.

Such as line breaks in the middle of words, followed by loss of
indentation?

N.B. no smiley.

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 6 Apr 2005 09:38:40 -0400

On Tue April 5 2005 19:29, [email-masked] wrote:

> _your_ nroff sources.

True.  But the opportunity is there.

> anything can ever get from any scheme that is based on nroff as the primary

I've spent about the same amount of time and effort in developing troff
macros as on trying to use xml2rfc (the biggest difficulty being (not)
finding a suitably productive XML editor).  Even if the macros are not
useful to anybody else, they're useful to me; I have 5 drafts currently
in various stages produced using them.  All I have to show for roughly
the same effort in the XML direction is a somewhat better understanding
of some XML arcana and loss of respect for some products which heavily
hype XML output but which seem incapable of producing RFC-specific XML
without major effort (e.g. OpenOffice/StarOffice).  In some cases, some
heavily-hyped document preparation tools seem incapable of producing
simple plain (formatted) text (such as is required for I-Ds)!

> All possible with the xml2rc format.

Tools for producing complex tables, data format diagrams, mathematical
equations, line drawings, chemical diagrams, graphs, and formatted ABNF
are readily available for use with troff/nroff.  I no of none
specifically for use with xml2rfc (though I suppose with some effort
some of the troff-based tools could be adapted).

> This has proved to be tremendously convenient.

Ditto for the macros (as of this morning, there's an update that
incorporates the latest versions of 1id-guidelines.txt,
ID-Checklist.html (formerly ID-nits), and the change in boilerplate
rules scheduled to go into effect a month from today.
 
> IMO neither nroff source nor XML source qualify as "easily produced".

A text editor -- any text editor -- suffices for nroff source.  That
includes vi, emacs, textpad (MS Windows), SiED (PalmOS), etc.  In
theory, there exist commercial XML editors for PalmOS, but I suspect
thay they are less productive than the ones on other platforms.

> But the 

The number of text editors is very large and probably growing.

The biggest problem with XML editors is that they are unproductive.
Editing XML in all of the ones I've seen goes something like:

1. hunt for mouse
2. move cursor to nondescript icon and click
3. try to figure out what it is
4. type a few characters of text
5. go to step 1

(or see http://www.ivritype.com/xml/) [no, I didn't write it and I
don't care about MS Windows programs]

Conversely, nroff source can be generated directly from a keyboard; no
need to embark on wild mouse chases.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 6 Apr 2005 17:03:26 +0300 (EEST)

> thay they are less productive than the ones on other platforms.
[...]

> 4. type a few characters of text

I can't understand why you basically say that nroff can be typed 
manually, but XML requires an editor.

I've never used an XML editor and have.. what, a couple of dozen 
drafts, many of them RFCs already.   I've used solely xml2rfc for 
about 1.5 years now.  Nor do I have plans to use an XML editor.

Prior to XML I used custom nroff macros which I also edited manually.

A good text editor is your friend.  That applies equally to nroff and 
xml2rfc.  For those who want fancy (but maybe not user-friendly) 
WYSIWYG editors, those exist but are definitely not required.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 Apr 2005 16:04:19 +0200

Bruce Lilly wrote:
> ...

I am producing XML with a text editor as well. Plugins allow 
one-keystroke syntax checks (== run it through an XML parser) or preview 
of HTML (== display it in a browser with XSLT).

Best regards, Julian

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 6 Apr 2005 10:32:11 -0400

On Wed April 6 2005 08:03, Eliot Lear wrote:
> So what?

So if the primary purpose of a piece of software is to produce
properly-formatted text documents, and it fails at that task, all bets
are off (i.e. if it fails to produce *correct* results, being fast,
cheap, small, flashy, self-contained, portable, etc, usually don't
matter; and in this case being slow, requiring multiple external
programs etc. are simply additional baggage).

> The nice thing about an XML format is that if you don't like  
> the representation you can change it without changing the source.  Isn't 
> that nice?!

Not if the primary output is unusable.  But maybe I missed your point...

---

From: "Alex Rousskov" <[email-masked]>
Date: Wed, 06 Apr 2005 09:10:44 -0600

On Wed, 2005/04/06 (MDT), <[email-masked]> wrote:

> I have to admit that I use nroff about 75% of the time and XML about
> 25%, I'm much happier about the postscript/PDF output options from
> nroff than from XML,

To be fair, poor output quality is not XML's fault, it is tool's fault.  
Popular tools improve with time (and IETF can influence/speedup such  
improvement if needed).

> and I can't imagine having written the 120-page PIM spec in XML.

My largest XML-based RFC is only 60 pages, but I do not see why 120 pages  
would be "too long" for XML. Can you clarify? Just curious...

Thank you,

Alex.

---

From: "Alex Rousskov" <[email-masked]>
Date: Wed, 06 Apr 2005 09:02:22 -0600

On Wed, 2005/04/06 (MDT), <[email-masked]> wrote:

> A text editor -- any text editor -- suffices for nroff source.
> That includes vi, emacs, textpad (MS Windows), SiED (PalmOS), etc.

Same for editing XML sources, of course. One does not have to use
fancy XML-aware editors to edit XML, especially draft sources that
do not use much markup. FWIW, I do not use such an editor when
writing my drafts.

Can we stop this debate? It is clear to me that there are people who love  
nroff and people who prefer XML. There is no point in discussing the  
advantages of one imperfect format over the other imperfect format,  
especially in such a biased way.

What we should debate instead is whether ID Submission tool requirements  
should be modified to include nroff sources submission. So far, I heard of  
a single argument why that change should be done: "because the RFC Editor  
is using submitted nroff sources". Others have said it is not true. We can  
ask the Editor to tell us the truth. Meanwhile, are there any more  
arguments for nroff sources to be processed by the ID Submission tool?

Thank you,

Alex.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 06 Apr 2005 16:55:11 +0200

> Not if the primary output is unusable.  But maybe I missed your point...

Yes.  Don't like the software?  Write your own...

Eliot

---

From: Bill Fenner <[email-masked]>
Date: Wed, 6 Apr 2005 06:49:53 -0800

On Apr 6, 2005 5:38 AM, Bruce Lilly <[email-masked]> wrote:
> [mouse,icon,click,type a bit,mouse,...]

I've found that I can mostly avoid the mouse using XMLmind's XML
editor and my xml2rfc plugin
(http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/).  xxe has been
designed to have keyboard shortcuts for most common operations and
I've tried to continue that (e.g., "enter" to insert a new paragraph
or split the current one at the cursor).

I have to admit that I use nroff about 75% of the time and XML about
25%, I'm much happier about the postscript/PDF output options from
nroff than from XML, and I can't imagine having written the 120-page
PIM spec in XML.

  Bill

---

From: Eliot Lear <[email-masked]>
Date: Wed, 06 Apr 2005 14:03:00 +0200

> Such as line breaks in the middle of words, followed by loss of

So what?  The nice thing about an XML format is that if you don't like 
the representation you can change it without changing the source.  Isn't 
that nice?!

Eliot

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 06 Apr 2005 12:23:03 +0200

On Wed, 2005-04-06 at 11:52 +0200, Brian E Carpenter wrote:
> Well, I thought I'd try something daring. We have people
> arguing about xml versus nroff (again). If you write Internet
> Drafts, try this toy (and only vote once, please...).
> If the toy doesn't work, don't blame me... I just found the
> site with Google.
> 
> http://www.internationalvoting.com/int3/ask.cgi?pid=22-143

As this is the tools discussion after all, might it maybe be a good tool
to have a voting tool for the IETF?

Just like the above, except that the chairs can see the email addresses
that people gave when they voted. They could then check this list
against the list that has actually been signed up on the wg's
mailinglist and filter out discrepancies, might these exist.

Thus a following process could be made:

- WG Chair adds a vote (topic,description,options,enddate)
- Tool posts this new vote to the WG's list.
- WG members (*1) read this message and go to the URL
  that is given in the message
- WG member votes
- Tool sends a confirmation, to verify that this user
  is really that user that just voted.
- WG member confirms his/her/it's/* vote.
- Tool closes the vote
- Tool sends results to the list

The pro of this procedure is that votes can always be reviewed, checked,
they are easily accounted for etc. And best of all, it doesn't require
one to be present at eg a meeting, so if for instance there would be a
vote during a meeting, even remote participants can be in the vote. Only
requirement then would be that people are able to read their email
where-ever they are, but that should not be a problem for technical
folks would it ? :)

Single side-effect I quickly can come up with though would be that
people who are reading the WG maillist using an exploder address will
come out in the votes as 'bogus' as they are not signed up.
These folks could of course be asked under which address they are signed
up or some other procedure. There are not likely many, though one never
knows for sure of course. This "you are not on the mailinglist" can of
course be handled by the tool. Other side-effects, raise your voice.

*1) If you are not on the list, how else will you know what they are
talking about, thus why should you vote? ;)

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Apr 2005 11:52:56 +0200

Brian

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 06 Apr 2005 12:29:40 -0400

> to have a voting tool for the IETF?

"We reject kings, presidents, and voting..."

This isn't 100% true, of course; there are a very few specific cases where 
"voting" is used to make a decision.  They tend to be somewhat specialized 
(for example, the system the IESG uses to decide whether to approve 
documents) and have specially-designed tools.

I don't think a general-purpose voting tool is needed or appropriate.

-- Jeff

---

From: "Alex Rousskov" <[email-masked]>
Date: Wed, 06 Apr 2005 10:29:39 -0600

Henrik,

	Could you please add this detailed suggestion to our "tool wishes" wiki  
page/database? I would just replace "voting" with "polling" or some other  
word that might be less offensive in IETF context.

I think it would be a useful tool.

It may be a good idea to have an option to disable confirmations. An email  
receipt is sufficient for many polls and simplifies the procedure by an  
order of magnitude.

Thank you,

Alex.

---

From: Bill Fenner <[email-masked]>
Date: Wed, 6 Apr 2005 08:27:50 -0800

> Popular tools improve with time (and IETF can influence/speedup such

Very true - I'm just talking abot the current state of affairs.

> would be "too long" for XML. Can you clarify? Just curious...

Well, I think the main reason is that any time we needed custom
handling for a topic it was easy to write a macro to handle it; the
same thing in XML would probably mean adding preprocessors (perhaps an
xsl transform).  We also ended up with some tables that required some
pretty fine tuning to get to fit in 7x characters; my gut tells me
that would be harder to do in XML.  Finally, the optional figures in
the postscript version would not have been supported by the currently
available tools.

  Bill

---

From: "Alex Rousskov" <[email-masked]>
Date: Wed, 06 Apr 2005 11:13:41 -0600

On Wed, 2005/04/06 (MDT), <[email-masked]> wrote:

> xsl transform).

Yes, I use preprocessors (though not XSLT). I think that writing a  
preprocessor is equivalent to writing marcos. Some people can write XML  
preprocessors faster than nroff macros and vice versa, naturally.

> We also ended up with some tables that required some
> that would be harder to do in XML.

That depends, I think. If you typeset your table manually, then you can  
use artwork to include that into XML sources. You would have to call it a  
Figure then, I guess :-(.

If you use nroff to format most of the table except a few special places,  
then current XML DTD is not that flexible.

> Finally, the optional figures in

Very true.

Note that the last two arguments (and even the first one, to an extent)  
seem to be unrelated to document length.

Thank you,

Alex.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Apr 2005 10:16:21 +0200

Jeffrey Hutzelman wrote:
> This isn't 100% true, of course; there are a very few specific cases 
> where "voting" is used to make a decision.  They tend to be somewhat 
> specialized (for example, the system the IESG uses to decide whether to 
> approve documents) and have specially-designed tools.
> 

But we *often* take straw polls in f2f meetings, and that's very hard
to do by email.

    Brian

---

From: Thomas Narten <[email-masked]>
Date: Thu, 07 Apr 2005 07:18:15 -0400

> mailinglist and filter out discrepancies, might these exist.

Maybe this is pointing out the obvious, but discounting input because
it comes from someone not subscribed to the list is Poor
Practice. Often, the most critical (but also the best) reviews come
from folk outside of the WG, who are not following the work closely,
and are reading a draft entirely on its own merits, and from a broader
perspective than the WG might have.

> talking about, thus why should you vote? ;)

Because an AD, chair or other concerned individual actively solicits
input from someone who is not actively following a WG (or is currently
focusing their priorities elsewhere)?

One of the realities of the IETF today (and for some time) is that it
is simply not possible for one person to closely follow all the
activities they might want to (or are expert in).

Thomas

---

From: [email-masked] (Scott Bradner)
Date: Thu, 7 Apr 2005 08:58:03 -0400 (EDT)

> But we *often* take straw polls in f2f meetings,

but we do not count hands - we look to see if there is a clear
difference between hands one way and or the other

Scott

---

From: Thomas Narten <[email-masked]>
Date: Thu, 07 Apr 2005 09:39:27 -0400

> difference between hands one way and or the other

I agree that this is exactly how we should be using hums/polls.

But I'm sure many of us have also seen cases where a consensus call is
made and it is not immediately/obviously clear (to all) just how clear
the difference between the two sides really is. Or to someone outside
the room who wasn't there.

Having hand counts makes it possible to have a more honest discussion
(both during and after the fact) about just how close the call really
is, how much participation there was, etc.

If folk are unhappy about a particular call, but they are not really
able to challenge it, it can reinforce the perception (rightly or
wrongly) that the IETF processes are unfair.

But as others also note, there are also downsides with "voting". And
there have been cases where "packing the vote" have taken place. The
most obvious example I recall was in the case of IDN WG. It is exactly
in these cases that we need to have good/strong chairs that recognize
when this is happening and factor it into the consensus call.

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Apr 2005 16:36:39 +0200

Regardless of the interesting side-discussion about 'voting',
what the toy shows after about a day is:

prefer nroff: 8
prefer xml:  37
neither:      9

which implies a few hundred abstentions, of course.

    Brian

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 07 Apr 2005 18:29:38 +0200

> perspective than the WG might have.

This was not obvious, at least did not directly jump into my mind to me
when I wrote the above part, but indeed is very logical.

On Thu, 2005-04-07 at 10:26 -0400, Bruce Lilly wrote:

> In short, quality of argument trumps (if the chair is chairing)
> quantity.  Voting (incl. as "straw polls") only measures quantity, not
> quality.

And I fully agree with that statement too.

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Apr 2005 13:38:50 +0200

I deliberately wanted to make the poll binary, but my
assumption is that 'neither' must mainly represent that
proprietary solution. I can't imagine many people generate
I-Ds using a plain text editor, and intuitively OpenOffice
doesn't seem likely either.

It's easy to create your own poll at the same site.

We're at 11/43/10 now, by the way. It looks as if XML suits
about 2/3 of our authors, but we have a substantial nroff
party.

    Brian

Stewart Bryant wrote:
> I would also be interesting to know how many use Microsoft Word
> to produce drafts.
> 
> Stewart
> 
> Brian E Carpenter wrote:
>

---

From: Scott W Brim <[email-masked]>
Date: Fri, 08 Apr 2005 08:27:01 -0400

> what the toy shows after about a day is:

I wonder how many of those have actually written a draft using both?

---

From: "Elwyn davies" <[email-masked]>
Date: Fri, 8 Apr 2005 11:32:18 +0100

FYI I am an ex-Word user, now fully converted to xml2rfc.

I thought Word was a convenient way to conform to Draft style and handle
revision control but was frustrated by the toolchain.  The main problem I
found was the badly broken 'Generic Text Printer' driver which has not
worked properly for a number of versions of Word in my experience. Symptoms
include:
- unilaterally changing the paragraph width so that it outputs one character
on each line starting from some random point in the document
- unilaterally changing the fount height to a microscopic value so that text
is converted to a horizontal line in random paragraphs

Microsoft are in denial about these bugs.  Presumably there is not much call
for the Generic Text Printer. (I must admit I haven't bothered to try it in
my most recent version of Word, but I wouldn't hold my breath).

I am aware of other possible ways to get the ASCII output but they are all
just as flaky and tedious.

I'll live with the need for balanced tags (I am pretty adept at detecting
what has gone wrong by now) and some other minor irritations for the sake of
knowing that I won't end up fighting the tools when trying to get a draft
out close to the deadlines (when of course the random bugs noted above
always strike!)

I know several other authors who have defected for similar reasons.

Regards,
Elwyn

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stewart Bryant
> Sent: 08 April 2005 10:47
> To: Brian E Carpenter
> Cc: [email-masked]; Bruce Lilly; Alex Rousskov; [email-masked]; IETF
> TOOLS discussion
> Subject: Re: Last Call: 'Requirements for IETF Draft Submission Toolset'
> to Informational RFC
> 
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 08 Apr 2005 10:47:09 +0100

Stewart

---

From: Eliot Lear <[email-masked]>
Date: Fri, 08 Apr 2005 15:14:17 +0200

> I wonder how many of those have actually written a draft using both?

Isn't it sufficient for one to have to have suffered *roff in other 
contexts?

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 8 Apr 2005 15:20:40 -0400

On Fri April 8 2005 13:55, Francis Dupont wrote:

>    and intuitively OpenOffice doesn't seem likely either.
> 
> => to prefer emacs to OOo is a subtle way to like open source (:-).

OOo is one of those that I mentioned doesn't seem to be able to
generate formatted plain text with appropriate parameters (in
addition to apparently not being able to generate RFC-specific
XML).

> => nroff is not so bad. The problem is the community which supported it
> moved to Latex many years ago...

Oh?  One of the reasons that I haven't used TeX (and things like LaTeX
which are layered on it) is the difficulty of getting suitable plain
text output.

> BTW IMHO the best tool should be so painful that 
> I-Ds would be very small (:-)?

The size of the boilerplate alone precludes that, unfortunately.  And
it gets worse next month when the secretariat stops accepting "he" (or
"she", as the case may be) as an alternative to "he or she" in that
boilerplate.

> PS: what we need is a rfc2xml. It seems there is a secret rfc2nroff...

Going from formatted RFC or draft to troff source is fairly easy. As
text will be re-flowed into paragraphs, it's mostly a matter of
inserting the right directives between paragraphs, for section
headings, etc.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 10 Apr 2005 08:40:47 +0300

[email-masked] wrote:

>Let's see. I've done lots of drafts with both, using (in the nroff case)
>several different macro packages. I have also produced several very large
>non-RFC documents (in the thousand page range) using XML, nroff, and a variety
>of other tools.
>
>XML is the hands-down winner IMO. 
>  
>
I agree. I have written a fair number of drafts (some of them lengthy)
using word, nroff, latex, and XML.  There's really no contest, XML is
the way to go.

Of course, I can imagine some toolset improvements but these
improvements are minor compared to some of the major (imho)
issues that the other alternatives have. And I can also imagine some
special purpose support (mibs, state tables, you name it) that people
may need. Personally, when I have that kind of issues I usually end up
writing a script that does some pre- or postprocessing to achieve what
is needed. Interestingly, I run into this on a regular basis when using
nroff, latex, and word. But I have needed only minor things in the last
couple of years when I have been using XML.

>P.S. Anyone who uses an XML editor that requires mouse use which gets in the
>way of simply entering text is using a crap tool. Plenty of alternatives exist
>that work properly.
>
Just use emacs, that's what I do :-)

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Fri, 08 Apr 2005 19:55:22 +0200

In your previous mail you wrote:

   I deliberately wanted to make the poll binary, but my
   assumption is that 'neither' must mainly represent that
   proprietary solution. I can't imagine many people generate
   I-Ds using a plain text editor,

=> why? I used a plain text editor before moving to xml2rfc (xml edited
with a plain text editor too) because of the new boiler stuff pressure...

   

=> nroff is not so bad. The problem is the community which supported it
moved to Latex many years ago... And for short I-Ds direct writing is
easier/faster/etc. BTW IMHO the best tool should be so painful that
I-Ds would be very small (:-)?

Regards

[email-masked]

---

From: Tim Bray <[email-masked]>
Date: Sat, 09 Apr 2005 16:11:35 -0700

xml2rfc also has the advantage that it simultaneously reduces the 
whining from 66-column-ASCII-and-stone-axes traditionalists and the 
whining from typography-and-i18n radicals; which has to be a good 
thing. -Tim

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Apr 2005 11:48:15 -0700

Hi -

> From: "Scott W Brim" <[email-masked]>
> To: "Brian E Carpenter" <[email-masked]>
> Cc: <[email-masked]>; "Bruce Lilly" <[email-masked]>; "Alex Rousskov" <[email-masked]>;
<[email-masked]>; "IETF TOOLS discussion" <[email-masked]>
> Sent: Friday, April 08, 2005 5:27 AM
> Subject: Re: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC
...
...

I have.  For a short, simple, document xml2rfc is ok.
For larger, more complex (e.g. diagrams, pseudocode,
MIB modules, references to works-in-progress, multi-document
sets) ones nroff shines.

Randy

---

From: [email-masked]
Date: Sat, 09 Apr 2005 15:05:22 -0700 (PDT)

XML is the hands-down winner IMO. In fact I now use xml2rfc routinely for
non-IETF-related documents of various sorts.

				Ned

---

From: Bill Fenner <[email-masked]>
Date: Fri, 8 Apr 2005 10:09:41 -0700

> I wonder how many of those have actually written a draft using both?

I picked "neither" since I use both and don't have a strong
preference.  nroff gives me much more control over the actual
formatting, xml lets me leave the tool maintenance to someone else and
I do see the advantage of well-formed metadata.

(otoh I have nroff macros to help in writing MIBs, which e.g., create
the SEQUENCE so it's never out of sync with the objects in a table...
can't think of how I would do that in XML offhand)

  Bill

---

From: "Alex Rousskov" <[email-masked]>
Date: Sun, 10 Apr 2005 18:16:39 -0600

> can't think of how I would do that in XML offhand)

You would use XML entities (recent xml2rfc versions have better support
for those) and/or a preprocessor. I would not be surprised if xml2rfc
eventually has native preprocessing capabilities (i.e., macros).
Virtually any large document and many small ones need them.

Alex.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Apr 2005 13:15:54 +0200

James M. Polk wrote:
> At 03:20 PM 4/8/2005 -0400, Bruce Lilly wrote:
> 
> I don't understand this point, can you expound on it for those of us 
> that don't know about it?

See http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01093.html

    Brian

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 10 Apr 2005 15:44:03 -0600

>"she", as the case may be) as an alternative to "he or she" in that

I don't understand this point, can you expound on it for those of us that 
don't know about it?

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Apr 2005 11:41:22 +0200

I think I'm going to declare the toy poll closed. What it shows
is:

  prefer nroff: 11
  prefer xml:   52
  neither:      11

We can't claim statistical significance, but I think
we can see that, without discriminating against
traditional plain text, we help a majority of authors
by making XML submission straightforward.

    Brian

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 12 Apr 2005 12:56:52 -0700 (PDT)

> I wonder how many of those have actually written a draft using both?

I have.  I'm a recent convert to xml, and hugely prefer xml, to the
extent that I have converted most resubmissions of mine from nroff to
xml.

Kireeti.
-------