In
<5(_dot_)2(_dot_)1(_dot_)1(_dot_)0(_dot_)20050503074403(_dot_)0420f0b0(_at_)pop(_dot_)mail(_dot_)yahoo(_dot_)com>
David MacQuigg <david_macquigg(_at_)yahoo(_dot_)com> writes:
At 01:25 AM 5/3/2005 -0500, wayne wrote:
[tale of woe about xml2rfc v1.29 deleted]
Is there no way to avoid this torture?
Up until the use of xml2rfc v1.29, xml2rfc had been very nice to use
and very productive.
Your HTML version below is
much more readable than even the best formatted TXT.
I mostly agree, and that is one of the reasons I didn't just dump
xml2rfc (aka RFC2629).
I assume you can
output it also in PDF.
I think I can generate a PDF from the nroff that xml2rfc creates, but
I'm not interested in doing the work right now.
From section 2 of "Guidelines to Authors of Internet Drafts":
PostScript and/or PDF are acceptable, but only when submitted with a
matching ASCII version (even if figures must be deleted).
I'm assuming you are referencing:
http://www.ietf.org/ietf/1id-guidelines.html
What is acceptable as an Internet Draft is not the same as what is
acceptable for an RFC. This is good, because a lot of I-Ds are only
intended as ideas to be thrown out and to get feedback. By publishing
these ideas via the IETF, you have committed to certain IPR disclosure
requirements.
For I-Ds that intend to go on to be RFCs, you need to consult:
ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt
As noted in that document, the ascii text documents are the
controlling documents, only a few postscript documents have been
accepted, and that anything other than the ascii text is discouraged.
The RFC editors will then convert the ascii text into nroff, if the
editor hasn't already supplied the nroff source. As a result,
targeting the nroff as what needs to look the best is being nice to
the RFC editors.
I'm surprised they don't accept HTML also. Is there anyone in the
world that can't read at least the W3C subset of HTML?
The Internet, and RFCs, have been around for a very long time, much
longer than HTML and the web. There are a lot of advantages to using
a common format for all RFCs. HTML documents can look different
depending on many different things and the last thing you want with a
standard specification is keywords or formatting being dropped off by
some browser. The XML stuff in RFC2629 (aka xml2rfc) defines a very
small subset, much like you are suggesting.
These are supposed to be drafts, not final documents.
Ah, there is the rub: I'm trying to get this SPF spec accepted as a
final document, not a draft.
The alternative is to sacrifice the nice formatting and just write the
document in TXT from day 1.
Well, Meng *did* start writing all the SPF specs in flat ascii on day
one. Mark Lentczner took on the large job of converting the documents
to XML, and I am very thankful that he did. Up until the latest
release of xml2rfc, it had saved me a lot of time and the results look
much nicer.
-wayne