[rfc-i] issue: canonical formats

Julian Reschke julian.reschke at gmx.de
Fri Jun 1 07:55:09 PDT 2012

On 2012-06-01 16:38, Joe Touch wrote:
> On 5/31/2012 7:36 PM, John Levine wrote:
>> As I read the wiki page, I see notes about a canonical source version
>> and a canonical display version. I would like to suggest that there
>> be only one canonical version, and whatever it is, it should be a
>> source versiont has structure and metadata at roughly the level that
>> xml2rfc does.
> I agree that there should be one canonical version, but I consider that
> necessary only for the archival version.
> As to metadata, I don't think that needs to be inside that version per
> se; it needs to be available but not necessarily integrated. That said,
> integration of metadata about the doc itself (author, title, date)
> should be easy to include. Metadata about other docs (refs) serves no
> useful purpose since there's no standard for document metadata that we
> can assume will help link docs together.

At least for references to IETF and W3C specs the xml2rfc format 
provides everything we need.

> As to structure, there should be two considerations:
> - required structure should be minimal. AFAICT, that includes location
> marks and references to locations, and might include tags around code
> and ABNF
> - optional structure should optional - i.e., removable. that includes
> containment markings around non code/abnf (e.g., sections), lists, and
> other aspects of document structure
> Optional structure serves only one purpose AFAICT - support for future
> editing, but the cost is more complexity in the archival format. Since
> most revisions are rewrites (after the RFC is published), we should not
> be trading stability and persistence for author convenience.
> ...

How does including additional information affect stability and 
persistence negatively?

Best regards, Julian

More information about the rfc-interest mailing list