[rfc-i] New proposal for "canonical and others"

Phillip Hallam-Baker 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
transformation.

"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
	Transaction Top
		Description
			|OBP Connection Management Query requests and responses contain
			|the following common elements:
		Abstract
		Request		Request
		Response	Response

	Message Request
		Abstract
		Description
			|The following parameters MAY be specified in any request:
		Binary Ticket			
			Description
				|Opaque ticket issued by the server that identifies
				|the cryptographic parameters for encryption and
				|authentication of the message payload.
		Binary MAC
			Required
			Description
				|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.
>
> R's,
> John
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest



-- 
Website: http://hallambaker.com/


More information about the rfc-interest mailing list