[rfc-i] transition plan for choosing alternative format for RFCs

Tim Bray tbray at textuality.com
Sat Mar 24 21:06:14 PDT 2012


Worth talking about, but speaking as a heavy user of various mobile
devices, I’d like to register an early dissent against PDF in general.
 HTML on the other hand works great with basically anything. -T

On Sat, Mar 24, 2012 at 8:48 PM, Larry Masinter <masinter at adobe.com> wrote:
> I'd like to suggest a transition plan:
>
> * Current: Official policy: ASCII-only text edition is authoritative, PostScript alternative allowed but infrequently invoked.
> In practice: PDF editions also sometimes provided.
>
> * Allow HTML and PDF as alternatives, but converge on rules and tools for producing them more regularly and enforcing some quality control on the profiles allowed.
>
> * Allow ( in cases where it matters) for one of the alternate editions (PDF or HTML)  to be declared authoritative, but require s an ASCII-text edition.  (If HTML is authoritative, also produce a HTML-to-PDF rendition).
>
> * same, but ASCII text not always required.
>
> * non-ASCII-text versions are routinely declared authoritative.
> ...
> * Finally: alternative format is chosen as default for all RFCs.
>
> The idea is to develop the workflow and tools for submission and publication paths for *both* HTML and PDF as valid alternatives and address the cases where Unicode text, images and graphic illustrations are useful.
>
> The goal should including produce HTML and PDF editions of currently applicable existing RFCs - ones that people still use.
>
> I think there are still a number of issues to be resolved before allowing non-ASCII text in primary specifications. For example, for Unicode HTML or text, do you allow private use characters?  Must the Unicode be in a normalized form? Zero-width joiners?  If the examples are expected to be used "as is" from extracting from HTML?
>
> How do we insure that the ASCII edition and the non-ASCII editions are consistent? How is that reviewed? What are the allowable divergences?
>
> The current experiments with xml2rfc extensions to allow a single XML source to be used for multiple format targets are encouraging,
>
> For HTML, how are images packaged (multipart/related? ePub format?  Just in the RFC directory with an RFCxxxx/something.jpeg  auxiliary files?).
>
> For PDF, using Leonard's suggested PDF/A profile addresses the archival requirements. Including the ASCII and XML versions as attachments inside a PDF/a makes sense to me as well.
>
> The question then becomes "which of these formats is most useful, and will aid the community". I'd suggest a trial and a survey...
>
> Take a sample of 5 RFCs (chosen by RFC editor or by RFC authors) and publish HTML and PDF/A editions of them as well.  Create a survey of users asking them which ones they found useful, which ones they preferred to reference, what other concerns they might have.
>
> Converge on an "authoring" format implies restricting authoring tools; I think this is a high and unwarranted cost. So I think focusing on publication format, and allowing Word, NRoff, XML2RFC input paths to remain while getting better experience with other document forms.
>
> Once we're satisfied that we've converged on reasonable rules for these alternative formats, the next step might be to allow one of the alternative forms to be declared "authoritative" (e.g., in its last call).
>
>
>
>


More information about the rfc-interest mailing list