[rfc-i] Proposed new RFC submission requirements
hallam at gmail.com
Fri May 25 09:07:39 PDT 2012
This does not need to be a choice though.
We already have tools to convert XML2RFC. If we have a decent profile for
HTML that captures all the metadata we want it is going to be pretty easy
to convert that HTML output back to XML2RFC. In fact the ability to round
trip like that seems to me to be one of the success criteria that is
We would need those tools for a transition strategy anyhow.
On Fri, May 25, 2012 at 10:21 AM, Paul Hoffman <paul.hoffman at vpnc.org>wrote:
> On May 24, 2012, at 2:47 PM, Joe Hildebrand wrote:
> > On 5/24/12 2:49 PM, "Joe Touch" <touch at isi.edu> wrote:
> >>> If that's the case, then why not continue to accept multiple input
> >>> Joe's statement was that there had to be one.
> >> There has to be one canonical format. There does not have to be one
> >> input format for submission.
> > There doesn't *have* to be one input format for all submissions, but if I
> > were the RFC editor, I'd sure prefer that, in order to drastically reduce
> > the amount of tooling required. N input formats * M output formats = a
> > mess.
> > I would say that for a *given* submission, I would like there to be
> > one input, from which all of the output formats are generated. If we
> > take this approach, there's no way, short of heroic human effort, to
> > that the multiple inputs say the same thing.
> If the RFC Editor's only decision criteria is "what would make my life
> easier", they should prefer to have only one submission format. If they
> have other criteria such as "we want to make publication in the RFC series
> available to authors who don't want to learn XML", they might prefer to
> have something easier (for the author) as well.
> --Paul Hoffman
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rfc-interest