[rfc-i] draft-flanagan-rfc-framework-00 and transition

Russ Housley housley at vigilsec.com
Thu Sep 11 12:06:45 PDT 2014


Heather:

>> These comments are on Section 7 of
>> draft-flanagan-rfc-framework-00.
>> 
>> 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
> formats;
> 
> 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
> PDF/A-3.
> 
> 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
> section:
> 
> 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?

Yes.  Thanks.


>> 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.

Russ



More information about the rfc-interest mailing list