[rfc-i] draft-flanagan-rfc-framework-00 and transition
housley at vigilsec.com
Thu Sep 11 12:06:45 PDT 2014
>> These comments are on Section 7 of
>> Section 7.1 on the Testing Phase says: "... final publication
>> will continue to be in plain text only." Why? I recognize that
>> the plain text document will be the canonical document at this
>> point, but why not publish the PDF as well since it is allowed by
>> the current rules? In my view, doing so would allow the community
>> to better see what is coming. This will facilitate the
>> identification of process problems.
> The PDF format that will be created in the new format
> world--PDF/A-3--will require an XML file.
Maybe I missed something. Since these documents are being hand chosen by the stream managers, I'm expecting that XML submissions will be used to learn the most about the new format.
> So, we have three options,
> assuming the authors have only chosen to submit plain text:
> a) have the RFC Editor create the XML file and one or more publication
> b) create a PDF from the plain-text file which will not be PDF/A-3'
> c) have the single plain-text file as the only published format.
> I am opposed to (a) on the grounds that the authors should review the
> canonical file, and if they cannot or will not review XML, it should
> not be created and posted as the canonical format. I think having a
> text-to-XML tool is still a good idea for authors that need to be
> boot-strapped into XML, but I don't think the RFC Editor should be
> *solely* responsible for XML creation.
> I think (b) will engender some confusion in the long run, particularly
> when we're talking about what to archive. As far as I know, there are
> no separate file name extensions to differentiate between PDF 1.7 and
> I think (c) offers the least amount of confusion in the long run.
How about this:
If XML is provided by the author, RFC will be published in plaintext and PDF.
Otherwise, RFC will be published in plaintext only.
>> Section 7.2 on the Transition Phase does not offer any
>> expectations about the duration of this phase. I can see reasons
>> for it to take a long time if major problems are found with the
>> tools. That said, I think the RSE should tell the community the
>> minimum duration of this phase.
> Someone else made a similar point. I've added the following to that
> This phase will require more work on the part of the RPC to support
> both old and new publication processes for at least six months.
> Does that mitigate your concern?
>> As I understand the format that is submitted to the RFC Editor
>> during each phase: - Testing -- tester must submit XML - Transition
>> -- author can submit plain text or XML - Completion -- author can
>> submit plain text or XML
>> While I understad that some tools might be developed to assist the
>> RFC Production Center (RPC) in converting an Internet-Draft to
>> XML, it seems to me that we really reach success when all
>> submissions to the RPC are in XML. This seems like a milestone at
>> the end of the 3rd phase. Such a cut off should not happen without
>> an explicit decision by the IAB with input from the RSE, RSOC, and
>> the whole community. Yet, this seems like something that ought to
>> appear in this document.
> That is the ideal, I agree. But I think the promise made during
> various plenaries and format sessions was that the RFC Editor would
> _always_ accept plain text. That's probably a bit of a broad
> statement to make, but it is what I said based on conversations I had
> with the community.
> Is it worth mentioning the ideal in the framework document?
I think this should be included in the document.
More information about the rfc-interest