[rfc-i] New proposal for "canonical and others"
hallam at gmail.com
Wed Jun 20 10:48:35 PDT 2012
I think the only thing that is actually critical here is that the RFC
editor toolchain change to eliminate use of nroff when the input
document is not nroff. The fundamental problem has nothing to do with
the input or output formats. The problem is that the process is lossy
and the useful formatting information is lost as a result of the nroff
"The RFC Editor MUST NOT discard any information provided by the authors".
I don't actually use HTML or XML for the bulk of my spec writing. I
use generators that create the code and the text from a source file
that knows no angle brackets (or unnecessary braces).
The generators can produce either XML2RFC or HTML, they are both just as easy:
Protocol OBPConnection OBP
|OBP Connection Management Query requests and responses contain
|the following common elements:
|The following parameters MAY be specified in any request:
|Opaque ticket issued by the server that identifies
|the cryptographic parameters for encryption and
|authentication of the message payload.
|Message Authentication Code formed over the canonical
|form of the message payload.
I will put the meta-generator up on source forge later this week and
see if I can release the protocol generator as well. I wrote the
meta-generator at Oxford so I own that out right. The latest version
of the protocol compiler is a different matter but I do own others and
they are pretty quick to write.
On Wed, Jun 20, 2012 at 1:37 PM, John Levine <johnl at taugh.com> wrote:
>>Indeed, I am expecting that there will be additional tools for
>>converting the RFC in to several different formats. I am not decided on
>>whether those conversions should happen from the source files or the
>>canonical file. I'm thinking the former would be more flexible?
> For this to work, the source and the canonical files have to be the
> same. To put it in the current context, if the canonical file is
> xml2rfc, we'll have to add some formatting hint directives to the
> xml2rfc language that permit the tweaks currently done in nroff, so it
> can directly generate a satisfactory text version. I don't see that
> as a big issue.
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest