Subject: RFC Style guide

From: Robert Sparks <[email-masked]>
Date: Wed, 19 Jan 2011 13:21:12 -0600

I had occasion to read through the RFC Style guide at
<http://www.rfc-editor.org/rfc-style-guide/rfc-style>
(linked from <http://www.rfc-editor.org/styleguide.html>)

and found a few tidbits that I had forgotten/misremembered.

If you haven't looked through it recently, consider doing so - it's good input for shepherd reviews.

RjS

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Jan 2011 12:42:16 -0700

> If you haven't looked through it recently, consider doing so - it's good input for shepherd reviews.

I wonder why that document is not itself published as an RFC...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Thaler <[email-masked]>
Date: Wed, 19 Jan 2011 21:14:30 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Peter Saint-Andre
> Sent: Wednesday, January 19, 2011 11:42 AM
> To: Robert Sparks
> Cc: [email-masked] Chairs
> Subject: Re: RFC Style guide
> 

Well for one, because the real "style guide" is currently scattered across 
multiple docs, linked from http://www.rfc-editor.org/styleguide.html,
and so needs some work to get things down to only one or two documents.

But mainly, I think, because it would be the job of the RSE to do things like
this, and that hasn't been the priority for the TRSE.

One of the TRSE's reports mentioned this as an example of some longer-term
work that the RSE needs to do.

-Dave

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 20 Jan 2011 02:02:19 -0700

> work that the RSE needs to do.

Sorry that I haven't followed this closely enough, but Glen has now been
formally the RSE since 2010-04-20?

Is it appropriate and respectful for us to start asking questions of the RSE
and RSAG yet about things we'd like to see for the future?  There were a few
questions I asked in Beijing that were met with "please wait for a few
months".

-- 
Joe Hildebrand

---

From: Barry Leiba <[email-masked]>
Date: Fri, 21 Jan 2011 16:38:51 -0500

> questions I asked in Beijing that were met with "please wait for a few

Glen has never been, and never will be, formally the RSE.  Glen's the
Transitional RSE, and he expects to turn things over to the "formal"
RSE before his year is up.

Barry

---

From: Glenn Kowack <[email-masked]>
Date: Fri, 21 Jan 2011 17:03:58 -0500

> RSE before his year is up.

Barry is generally right (see below).  However, there's no harm in discussing
issues as long as everyone appreciates that it would not be proper for us (or
me) to start making a lot of things happen just before the new  RSE shows
up. That could pull the rug out from under them.  We want to give the new
RSE full support for a clean start and a chance to start getting things right
w/r/t the "big picture" that they develop with the community.

So, if there are things you'd like to discuss, please feel free to bring them to
this list and I'll make sure they are carried over during the transition.

(*) Actually, I have formally been the RSE since 19 April, but with the
understanding that this is a transitional period, consistent with the points
I raised above.
http://www.rfc-editor.org/pipermail/rfc-interest/2010-April/001743.html

thanks,
Glenn

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 26 Jan 2011 00:12:30 -0700

On 1/21/11 3:03 PM, "Glenn Kowack" <[email-masked]> wrote:

> understanding that this is a transitional period, consistent with the
> points I raised above.

Yup, that was the message to which I was referring, and which I (slightly)
misunderstood, apparently.

> So, if there are things you'd like to discuss, please feel free
> to bring them to this list and I'll make sure they are carried
> over during the transition.

Well, you asked, and few will be surprised that I want to open *the* can of
worms:

The plain-text RFC format of our forefathers is woefully outdated to the
point where it is hindering our ability to build an Internet.  We at the
**very** least MUST allow authors to use their correct names in their own
specifications, and we MUST be able to write specifications that deal with
internationalization issues that actually use non-ASCII glyphs.

I would further suggest that the 80-column fixed page-size ^L format that
worked for some printers back when we started hinders readability,
particularly since most modern printers don't work that way in their normal
modes.

I personally don't care much about the ASCII-art issue, but that could be a
further refinement to shoot for down the road.

Now that adequate tooling such as HTML exists, we no longer have to accept
these limitations.

Objections:
- "That's the way we've always done it"
Yes, because when we started, that was the only way we could agree to do it.
We can do better now, and we have a responsibility to do so.

- "It's too hard to change"
XML2RFC already creates passable HTML.  We could start with that for *new*
specs.

- "I like to use Word to edit my text"
We can always build new tools if we need to; if the HTML format was
canonical, we could just work tooling directly for that, rather than making
folks edit the XML format.

- "English is the language of the IETF"
We could specify that all normative text was understandable to an English
speaker.

- "We don't want an unreadable mishmosh of fonts, colors, and blink tags"
Again, we could define what it's going to look like, and give the RFC editor
the power to enforce visual continuity.

- "We'll be able to read plain ASCII text 100 years from now"
Does anyone think you won't be able to read well-formed UTF-8 encoded HTML
in 100 years?  Even if you couldn't read the formatting, you could always
write 1 line of Perl2100 to strip out the tags.  But chances are, there will
still be enterprises running IE6 then.

-- 
Joe Hildebrand

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jan 2011 09:45:05 -0500

Joe,

I also chafe at the limitations of ascii for drafts/RFCs. Yet I think we 
must be careful about giving up the devil we know for the devil we don't 
know.

I have had some small experience with 3gpp specs.
They use MSWord, and I found it to be a nightmare to manage. The issues 
aren't all related to use of Word - its also due to cooperative editing 
of huge documents.

But the bottom line is that changing the document format impacts all the 
tools and procedures for managing the documents. So we should carefully 
consider those impacts before changing how we do things.

	Thanks,
	Paul

On 1/26/2011 2:12 AM, Joe Hildebrand wrote:
> On 1/21/11 3:03 PM, "Glenn Kowack"<[email-masked]>  wrote:
>

---

From: Julien Meuric <[email-masked]>
Date: Wed, 26 Jan 2011 16:04:09 +0100

"Changing our internal document format is not that easy (good thing to 
consider it though), but the global network MUST upgrade its billions 
hosts to v6..." I love the irony, but I might be the only one. ;-)

Julien (shield on)

Le 26/01/2011 15:45, Paul Kyzivat wrote:
>
>  [...] But the bottom line is that changing the document format
>  impacts all the tools and procedures for managing the documents. So
>  we should carefully consider those impacts before changing how we do
>  things. [...]
>
> > [...]
> > Objections: - "That's the way we've always done it" [...]
> >
> > - "It's too hard to change" [...]
> >

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Jan 2011 07:25:22 -0800

Why is this thread appropriate for wg-chairs? What makes us special in 
the consideration of the RFC format?

---

From: Barry Leiba <[email-masked]>
Date: Wed, 26 Jan 2011 11:32:48 -0500

> Why is this thread appropriate for wg-chairs? What makes us special in the
> consideration of the RFC format?

Maybe Joe wanted to float it here first before opening it up to the
One True Rathole.

And I agree with everything Joe says.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 26 Jan 2011 16:34:30 +0000

>>consideration of the RFC format?
I am agreeing that this is probably not the right list for this discussion.

>And I agree with everything Joe says.
+1.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 26 Jan 2011 11:38:18 -0500

+1 on both points!

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 26 Jan 2011 11:45:22 -0500

> From: Joe Hildebrand [[email-masked]]
> 
> Objections:

The expansion of the character set from ASCII to Unicode/UTF-8 would
be a good idea, at the very least to remove the bias against people
whose names cannot be properly expressed by the ASCII character set.

> We could specify that all normative text was understandable to an English

Strictly speaking, an English *reader* -- there are many more people
who read English effectively than can speak or hear it.  Fortunately,
reading is the critical skill for our purposes.

> folks edit the XML format.

The obvious choice is (X)HTML.  If written cleanly, HTML (1) provides
advanced formatting, (2) allows easy extraction of the text content,
and (3) is still low-bandwidth (thus not disadvantaging those with
poor network connectivity).

The problem with HTML is that much of it is generated by tools that
produce hideously complex HTML, often HTML that does not properly
express the intent of the native format of the text.  (E.g., I've seen
a lot of HTML-encoded e-mail where paragraphs were line-broken in the
HTML, despite that the text was clearly intended to flow, and HTML can
express that naturally.)

To put it simply, "People should be able to use HTML to express RFCs,
but they should not be allowed to use the HTML that Word generates."

This leads to he idea of allowing XML2RFC as an allowed source format,
and also distributing the HTML that XML2RFC generates.

Dale

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Jan 2011 09:02:25 -0800

On 1/25/2011 11:12 PM, Joe Hildebrand wrote:
>...
...
> folks edit the XML format.

I appreciate that this entire discussion is a bit off-topic for this 
list, but just to clarify the state of Word-based editing, in case 
anyone else wants to use it:

See RFC 5385.

The .dot file and scripts to support that are accessible from the IETF 
author tools page; that tool has been available since 2004:

http://www.ietf.org/mail-archive/web/i-d-announce/current/msg03176.html

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 26 Jan 2011 12:05:26 -0500

On Wed, Jan 26, 2011 at 11:45:22AM -0500, Worley, Dale R (Dale) wrote:
> The obvious choice is (X)HTML. 

[. . .]

I think some here have heard my rants about the conflation of form and
content implicit in most of the RFC formatting discussions, the deep
mistake of understanding "ASCII" and "fixed page layout with
ASCII-encoded text" as meaning the same thing, and the bizarre
arrogance of computer geeks shrugging off the expert advice of
librarians on the topic of what is and is not a reliably durable
electronic archival format.  So I'll not repeat any of that.

But before we start deciding what "the obvious choice" is, could we
please at least do a little analysis of what the problem is?  I would
like to suggest that we leave that analysis to the next RSE incumbent
-- someone who will no doubt be eager to turn into a terrier and
explore this little hole in the ground.  It is not plain that "the
obvious choice" is anything given different and possibly competing
needs of the RFC Series, and over on the rfc-i list we are busily
hammering out the requirements for the job of someone who would
presumably be in a position to advise about those needs.  

If people really want this debate to be opened, then, I encourage them
to go read Glenn's proposals for the RSE, and comment on the rfc-i
list.  Indeed, that list has had an unfortunate preponderance of
certain well-known voices, and it might be nice to have some different
perspectives.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jan 2011 12:11:48 -0500

> and also distributing the HTML that XML2RFC generates.

We could get a lot of mileage out of that. Just allow xml2rfc source to 
be submitted for drafts as an alternative to text, rather than waiting 
till the RFC stage.

And have the draft announcement messages and queries offer links to any 
of the formats XML2RFC can produce when the xml is available.

	Thanks,
	Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 26 Jan 2011 12:33:02 -0500

> be submitted for drafts as an alternative to text, rather than waiting  

Part of the reason I argued in this thread that we need to do a needs
analysis first before making this sort of change is that I think the
above is a terrible idea.

The only thing xml2rfc has going for it is that it automates certain
tasks that are otherwise harder to automate.  Those tasks are all a
direct result of the preposterous situation that we have line printer
output as our official format for the RFC.  Several of the checks that
are done by the nit checkers at distribution are in fact nits about
_page layout_, a problem that no author should in fact have to be
thinking about while making drafts.

But if we want to throw that line printer format over, then we need to
decide what we really want, and we need not to embrace a tool that is
a marginal author-input improvement over the line printer format, but
that still entrenches that format, as our official submission format.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 26 Jan 2011 12:36:57 -0500

> From: Andrew Sullivan [[email-masked]]
> 

All of what you say is well-taken, but it would make it easier for us
to participate in the manner you suggest if you gave more information
on how to do so.  After some searching, I think that when you say
"rfc-i list" you mean the "rfc-interest mailing list", with the info
page at https://www.rfc-editor.org/mailman/listinfo/rfc-interest.  I
haven't yet tracked down "Glenn's proposals for the RSE"; all I can
find are discussions about the political structure of the RFC Editor
function.  (And does "Glenn" mean "Glenn Kowack"?)  Perhaps you could
give the title of the thread, or even a link to it?

Thanks,

Dale

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Jan 2011 09:38:38 -0800

Hi, Paul,

Again, as an FYI:

> be submitted for drafts as an alternative to text, rather than waiting

The tools submission page already allows .xml to be submitted, and 
provides the link to the HTML it generates.

It does require .txt, which basically only forces the author to verify 
that the .xml compiles to .txt, rather than shifting that burden on the 
tool itself. The tool could probably be modified to accept .xml and turn 
it into .txt, but that seems like a tool issue, not a "canonical 
formatting" issue.

> of the formats XML2RFC can produce when the xml is available.

IMO, it might even be useful to have the draft announcement pages point 
to the tools version, rather than a long list of URLs for different formats.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 26 Jan 2011 12:49:34 -0500

On Wed, Jan 26, 2011 at 12:36:57PM -0500, Worley, Dale R (Dale) wrote:
> on how to do so.

Sorry it wasn't clear (though I'm vaguely alarmed that anyone on the
wg-chairs list doesn't already know about all this); you're quite
right for taking me to task.  

Everything you need to know to get started is available at 

http://www.rfc-editor.org/rse/RSE.html

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Jan 2011 19:21:12 +0100

On Jan 26, 2011, at 18:38, Joe Touch wrote:

> The tool could probably be modified to accept .xml and turn it into .txt, but that seems like a tool issue, not a "canonical formatting" issue.

I don't think so, because then you wouldn't have submitted the legal boilerplate.

Gruesse, Carsten

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Jan 2011 10:29:54 -0800

> I don't think so, because then you wouldn't have submitted the legal boilerplate.

FWIW, that can be fixed on the confirmation page, where the text output 
including the legal boilerplate could appear and require positive 
confirmation.

Joe

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 26 Jan 2011 13:46:05 -0500

________________________________________
From: Andrew Sullivan [[email-masked]]

http://www.rfc-editor.org/rse/RSE.html
________________________________________

You can safely assume that if you address a community that is not specifically involved with a subject, that most of its members will know little about the internal discussion mechanics of the subject.  Especially in this situation, where you specifically want to get previously uninvolved people involved, you can pretty much assume that the people you are targeting don't know about it.

Looking at RSE.html, or rather draft-kowack-rfc-editor-model-v2-motivations-00, which is linked from it, all I see is that the RFC Editor is expected to lead a discussion on RFC formats.  The vast remainder appears to be what I call "the politics of the RFC Editor function", which I have absolutely no interest in dealing with.

So is there really a discussion of RFC formats on rfc-interest or not?  If so, how do I find it?

Dale

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 26 Jan 2011 13:50:07 -0500

> So is there really a discussion of RFC formats on rfc-interest or not?  If so, how do I find it?

No, there isn't, and I don't think I suggested there was.

What there is instead is a discussion of the scope of the RSE job, and
perhaps (probably, I'd guess from the drift of the discussion) an
oversight committee.  This is a sort of meta-requirements discussion.
But one of the important issues is what sort of experience one might
want in an RFC Series Editor if one were going to have that
discussion.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Jan 2011 11:36:37 -0800

On 1/26/2011 10:46 AM, Worley, Dale R (Dale) wrote:
...
> So is there really a discussion of RFC formats on rfc-interest or not?  If so, how do I find it?

There have been many; the discussion (sadly) appears to be cyclical. The 
following are pointers to such discussions - they're not the head of 
each thread, but should allow you to find it

As you can see, we had some gaps (2002-2004, 2007, 2009). I was hoping 
we could make it to 2012 at least until this whack-a-mole popped up again...

Joe

------

mail list	date		string

IETF(main list)	Feb 22, 2001	Why we shouldn' use ASCII text
IETF		Dec 12, 2001	the ascii discussion all over again...
IETF		Apr  8, 2005	I-D/RFC source formats
tools-team	Apr 14, 2005	Accepting other formats for "source"
IETF		Jun 14, 2006	(draft-ash-alt-formats)
IETF		Jan 12, 2006	Alternative formats for IDs
rfc-i		Sep 25, 2008	Action:draft-rfc-image-files-01.txt
rfc-i		Sep 25, 2008	ACTION:draft-hoffman-utf8-rfcs-02.txt
rfc-i		Jan 30, 2010	"canonical" URI for RFCs, BCPs
IETF		Mar 13, 2010	Towards consensus on document format

IETF list:
http://www.ietf.org/mail-archive/web/ietf/current/maillist.html

tools-team:
http://tools.ietf.org/discuss-archive

rfc-i:
http://www.rfc-editor.org/pipermail/rfc-interest/

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Jan 2011 15:18:01 -0500

--On Wednesday, January 26, 2011 13:46 -0500 "Worley, Dale R

> or not?  If so, how do I find it?

Dale, while I agree with Andrew's later note, the specific
answer to your question is that such discussions have occurred
over and over again, at intervals of a few years, on the
rfc-interest list since it was created, on the IETF list, and
elsewhere.  

The wgchairs list is almost the worst possible place to try to
initiate the discussion because almost none of the relevant
people are on it.

The bottom line about those prior discussions, at least to date,
is that the decisions that have been made have been strongly
conditioned on two things: the importance of having the RFC
Series (or at least its nominal official format) be archival and
archivally accessible and the importance of being able to easily
extract material from RFCs (especially what we now consider
standards-track ones) for use in other or updated documents.
Those two key principles, especially the first, have created
huge conservatism about changes.  That conservatism becomes
especially pronounced when formats are proposed that require
that a particular version of a document be bound to a particular
processor (or version of a processor) in order to get the same
output.  

That concern derives not just from theory but from a problem
that occurred fairly early in the life of the series -- many
early RFCs actually were created in in machine-readable form,
but using processors that one hears about today only in computer
history contexts (e.g., I assume that few contemporary
participants in the IETF have even heard of NLS, much less used
it or seen it in action).   We've discovered that the most
efficient way to salvage those documents is to scan paper
copies, run OCR programs over them, and then manually correct
the results.   Not good for an archival series.

So, over the years, proposals for having the authoritative
versions be in runoff and nroff, WordStar,  WordPerfect, HTML,
various generations of MSWord, Postscript, and PDF and a series
of other page-image arrangements have been rejected on the
grounds that either precise control of the RFC as the reader saw
it required binding to a particular version of a processor,
required a more or less complex profile (and tools to enforce
it) to maintain compatibility and archival permanence, or failed
on the extract-and-paste requirement.

If you (or others) want to start the debate again, you will need
to have it with the new RSE and whatever review groups are
associated with that role.  And that is where the rfc-interest
list comes in, both for defining the role and, in the future,
having the discussion.   Just as personal opinion, I'd recommend
that you (and others) think carefully about the historical
archival and extract-and-paste requirements before suggesting
alternate primary/official forms.

    john

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 26 Jan 2011 16:29:03 -0500

I thought the rule was we don't talk about the RFC format until spring? Isnt
that in the Zen document or something?

I want epub but what do I know. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Barry Leiba
Sent: Wednesday, January 26, 2011 11:33 AM
To: Paul Hoffman
Cc: [email-masked]
Subject: Re: Canonical RFC formatting

Barry

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 26 Jan 2011 17:18:25 -0500

> From: John C Klensin [[email-masked]]

> associated with that role.

Yes, that is the important point that wasn't stated clearly.  In the
context, it would have been more useful to say something like:

    This discussion recurs periodically, but for it to be useful, it
    needs to involve a librarian that is familiar with archival needs.
    That will have to wait until we select the new RFC Editor.

> I assume that few contemporary participants in the IETF have even
> heard of NLS, much less used it or seen it in action.

But I'm glad to see that we're still using Nroff, which appears to be
a descendant of the CTSS "runoff", which I first learned of in an
illustration in the September 1966 "Scientific American"!

Dale

---

From: John Levine <[email-masked]>
Date: 27 Jan 2011 05:39:53 -0000

>want in an RFC Series Editor if one were going to have that

Entirely agree.  Selecting an archival document format that will
address the shortcomings of lineprinter ASCII while remaining usable
for decades is a hard problem, and I have to say that the recent
discussion, like previous IETF discussions on this topic, mostly
remind me that we may know a lot about network software, but we don't
know much about documents and archives.  (As an example, all of the
PDF RFCs to date need to be rebuilt to be of archival quality, because
they're all missing definitions of some of the fonts they use.)

This project is clearly something the RFC Editor needs to lead.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Thu, 27 Jan 2011 02:05:20 -0500

--On Wednesday, January 26, 2011 17:18 -0500 "Worley, Dale R
(Dale)" <[email-masked]> wrote:

>> If you (or others) want to start the debate again, you will
>> need to have it with the new RSE and whatever review groups
>> are associated with that role.
> 
> Yes, that is the important point that wasn't stated clearly.
> In the context, it would have been more useful to say
> something like:
> 
>     This discussion recurs periodically, but for it to be
> useful, it     needs to involve a librarian that is familiar
> with archival needs.     That will have to wait until we
> select the new RFC Editor.

That statement is true too.   We are describing different
perspectives on the proverbial elephant here... others who have
been even more involved than I have might describe things yet
differently although I hope my approximation is good enough.
And, while I think some having some approximation to "librarian
that is familiar with archival needs" in the system is
important, others might remind you that, while there are people
in the current Production Center who identify themselves
(justifiably) as professional technical editors, most or all of
what the RFC Editor staff has known that would fit into your
"librarian" category was learned on the job, over many years,
and by people who didn't primarily identify themselves with
those skills.

>> I assume that few contemporary participants in the IETF have
>> even heard of NLS, much less used it or seen it in action.
> 
> But I'm glad to see that we're still using Nroff, which
> appears to be a descendant of the CTSS "runoff", which I first
> learned of in an illustration in the September 1966
> "Scientific American"!

:-) 

Having used typset and runoff, on CTSS, before that and then
Multics runoff, which was completely forward-compatible, you
have just succeeded in making me feel really old :-(.   And,
yes, nroff and troff are descendants of runoff, sharing the
general syntax and basically providing a forward-compatible set
of commands.   With a few exceptions, and some issues about
conversion to ASCII, I think most of what was written in/for
runoff on CTSS in the mid-60s would process in a reasonable way
with nroff today... but the results might look a little
different.

    john

---

From: John C Klensin <[email-masked]>
Date: Thu, 27 Jan 2011 04:19:17 -0500

--On Wednesday, January 26, 2011 16:29 -0500 Richard Shockey
<[email-masked]> wrote:

> I thought the rule was we don't talk about the RFC format
> until spring? Isnt that in the Zen document or something?
> 

Richard (and others),

(1) If this discussion is to be useful, it has to occur on a
list to which the RFC Editor staff have access.  This one isn't
one of those, even if the issues that contributed to "spring"
didn't exist.

(2) FWIW, I think personally that the discussion would make lots
more progress if folks distinguished between authoritative
archival forms(s) and forms they would like to have the RFC
Editor make available as a matter of routine.  One could then
have a fairly focused discussion about how close to the
authoritative format the other formats needed to be, whether any
warnings were needed about the differences, resources required,
etc.  

Resources permitting, I think having epub (and maybe a few other
alternate reading-convenience forms) would be great.  I don't
know whether the community would want to invest resources that
way or what (extra) resources it would take, but that is a
matter for a separate discussion on another list.  I am pretty
confident that, as a primary archival form, epub would not pass
even a simple laugh test, but I don't think you suggested that.

     john

---

From: Warren Kumari <[email-masked]>
Date: Thu, 27 Jan 2011 13:56:47 -0500

On Jan 26, 2011, at 12:33 PM, Andrew Sullivan wrote:

> But if we want to throw that line printer format over,

And, while we are figuring this out, I have a little python script  
that makes dealing with the line printer format easier...

Personally I like reading drafts and RFCs on dead trees (yes, I know,  
I know, but it works for me...).
Printing the current format on a laser printer leads to all sorts of  
ugliness (page length, weird page breaks, simplex / duplex, etc), so I  
have written a small script to make more pleasant. It grabs a draft or  
RFC (or reads it from disk), converts it to a PDF (using the  
ReportLabs stuff) and then ships it off to lpr to actually print it --  
it takes various flags to control operation...

This was written for my own use, and so the code is neither  
documented, nor polished, but if folk find it useful I can try make it  
better...

http://www.kumari.net/code/print_rfc_or_draft.py

W

> then we need to

---

From: Joe Hildebrand <[email-masked]>
Date: Fri, 28 Jan 2011 01:25:07 -0500

> Maybe Joe wanted to float it here first before opening it up to the

Exactly.  I wanted to scare out any other likely objections to add to the
list before igniting the flames. :)

-- 
Joe Hildebrand

---

From: Joe Hildebrand <[email-masked]>
Date: Fri, 28 Jan 2011 01:27:02 -0500

> reading is the critical skill for our purposes.

Typo.  Apparently you're a better reader than I am a speaker. :)

> but they should not be allowed to use the HTML that Word generates."

+1

> and also distributing the HTML that XML2RFC generates.

We might even semanticize the output of XML2RFC more; I haven't looked at it
recently to see how well it does.

-- 
Joe Hildebrand

---

From: Joe Hildebrand <[email-masked]>
Date: Fri, 28 Jan 2011 01:39:24 -0500

On 1/26/11 10:05 AM, "Andrew Sullivan" <[email-masked]> wrote:

> ASCII-encoded text" as meaning the same thing,

I understand the difference, but I raised them as two separate points since
it's possible that if we tackle one, we'll be within spitting difference of
a solution to the other.

> and the bizarre

I acknowledge both my ignorance and arrogance.  Any chance you could point
me at some links off-list so I can work on the first?

> please at least do a little analysis of what the problem is?

+1

> I would
> explore this little hole in the ground.

What if how someone digs into this problem is one of the primary criteria
that someone would use to choose the next RSE incumbent?

-- 
Joe Hildebrand

---

From: Joe Hildebrand <[email-masked]>
Date: Fri, 28 Jan 2011 01:42:59 -0500

> that in the Zen document or something?

That was why my original question was so elliptical.  I was hoping not to
light the flamewar until it was time.

"Spring" is ill-defined, but if it was meant to be "after Prague", then I'll
just continue to be disappointed in us for another several months.

-- 
Joe Hildebrand

---

From: Scott Lawrence <[email-masked]>
Date: Fri, 28 Jan 2011 07:31:39 -0500

> the consideration of the RFC format?

Please, people... take this discussion elsewhere.  IETFers of all people 
should be clued in to the appropriate choice of lists for a discussion.