[rfc-i] Resetting this format debate a bit

Larry Masinter masinter at adobe.com
Mon Mar 26 18:57:51 PDT 2012

> That is, I think the partitioning exercise is needed here, 
> since discussion is all over the map, servicing a variety of different agendas.

1. Whatever we do, we should adopt it step by step with review
    -- IETF serves a big community; big changes will have unforeseen impacts;
    -- quite a bit can be done without disrupting anyone
    -- improving tooling to do what we already allow, but do better
        ** high payoff, low cost, small risk of wasted effort**
    -- I outlined some steps in a previous message, the details don't matter
   -- See Martin Duerst's XML2RFC hack to for using a single XML
      to produce Unicode HTML and PDF
   -- early step: publish things we have (like XML for RFCs)

2. There are multiple communities to be served
   -- I think it's possible to make things better for almost everyone
   -- let's be careful about trading off improvements for one community 
        by making things terribly worse for others
   -- however, "rough consensus": understand requirements, not necessarily
       Follow proposed solutions
   -- I think it's best to think of the "workflow": who does what when
      and how often

      * Spec author/editors (small number, but needs are important)
          **   Extract material from older documents (infrequently, ~twice per document)
          ** Create new text (often)          
         **   Edit previous drafts based on comments (frequent)
         ** use version management software and tracker to link document changes to issues (frequent)
          ** Submit documents to I-D editor (a little less frequently)
         **  Review RFC editor's edition during AUTH48  (infrequently, ~twice per document)
         ** some spec authors are also jointly authoring related documents in other
              standards groups with their own publication rules and tools.

     * spec reviewers: Working group members, iesg, ietf community (large number)
          ** read internet drafts at various stages of development (frequently)
         ** send comments back to working group & editors (less frequently)

     * RFC editor  (small group, needs tools to support)
       ** Edit/transform internet draft and produce AUTH48 copy
       ** Publish and distribute RFC in various formats

    * RFC user (very large number, on a wide variety of devices)
      ** read, review, discuss, reference RFCs

    * Authors of other specifications, standards, legal review, etc.
    ** cite authoritatively sections of RFCs
   * Archivists
    ** preserve RFCs such that future needs of users, authors
     of other specs, others re-using text can continue to do work
     after > 20 years

Each of these communities have different needs, and the document formats
and work processes chosen should support those needs.

We've mainly been talking about the needs of the document authors
(who are familiar with and prefer different sets of tools), and occasionally
of document users and reviewers (who want to print, view on mobile 
devices, etc.)

It's possible and easily demonstrated that the formats used at various
steps can be different.  The authoring community has a variety of
needs and working environments, and we should not be in a hurry
to change things so they can't use what already works for them.

The RFC user community is quite large and has diverse needs. 
Some prefer to print documents and reference them with a convenient
pagination, and even reference them by page #.

Others prefer to read them on mobile devices.
Other standards groups formats

W3C: HTML 4.0 + pubrules
WHATWG: html



It *might* be possible to satisfy the needs of readers and reviewers
with a single format and transformation tools, but doing so is difficult;
consider multiple formats instead.

When there are multiple editions (formats) of a document,
only one should be authoritative.

We should keep the ASCII text requirement while we develop
the optional alternate form and regularly produce alternates which
_could_ serve as the authoritative copy.

The notion of a "file format" is complicated. he media type
of the format is an insufficient label, since we're really talking
about publication rules which include a media type plus a 
likely large number of rules, styles, conventions, and extensibility
path for formats.

Much of our opportunity for miscommunication is because of
an incomplete vocabulary for talking about formats & publication

With that caveat (that we don't have a good vocabulary)
The families of formats we're talking about are:

ASCII text (fixed line, paged)
        Publication form
UTF8 text (same but allow UTF8, with some restrictions TBD)
      Publication form
    Authoring form
XML: Xml2rfc format (with various evolutions, present and proposed)
     Authoring form, possible intermediate publishing form
HTML (with various restrictions or profiles, style sheets)
    Publishing format, potentially authoring format
ePub (actually zip-packaged HTML + images etc.)
    publishing format but contains authoring format

More information about the rfc-interest mailing list