[rfc-i] Does the canonical RFC format need to be "readable" by developers and others?
hallam at gmail.com
Tue Jul 10 08:32:45 PDT 2012
On Tue, Jul 10, 2012 at 9:39 AM, Yoav Nir <ynir at checkpoint.com> wrote:
> On Jul 10, 2012, at 3:38 PM, Julian Reschke wrote:
>> On 2012-07-10 14:30, Phillip Hallam-Baker wrote:
>>> I think we could defer that to a phase 2. The core of this problem is
>>> to have the RFC editor process XML2RFC files and not convert
>>> everything to nroff.
>> Hear, hear :-)
> One core problem is getting drafts and RFCs into multiple output formats that work well on phones, tablets, paper, large screens, and readers. There is no doubt that XML2RFC is far more adaptable to whatever presentation formats we may want to create.
> The other problem that keeps coming up is people wanting to add images, graphs and formulas to documents. XML2RFC as it currently stands is just as ill-suited for this as nroff.
I very much agree with that, but that is a more complex problem, or at
least one with very many more degrees of freedom.
At this point I would like us to get to closure on the basic idea of
moving to an XML based workflow with (unspecified) attachments within
the RFC editor's domain first because that is something I think we are
almost all agreed on.
Which file formats to permit as attachments is a larger question and I
think will require us to agree on some form of registry with some form
of acceptance criteria. For example:
All Formats: Must provide a tool meeting certain criteria for
validating files and rejecting those that are not compliant.
Base Formats: Must be capable of display in x% of deployed browsers.
Extended Formats: Proposer must provide a tool meeting RFC editor
criteria that can convert to a base format
While much of the argument has been focused on image formats, and
these are important, there is a lot more value to having formats like
EBNF and ASN.1 being called out and properly validated.
More information about the rfc-interest