[rfc-i] RFC "source" format

Joe Touch touch at ISI.EDU
Thu Oct 9 09:32:02 PDT 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Dave CROCKER wrote:
> 
> 
> Joe Touch wrote:
>> Dave CROCKER wrote:
>>> Hence, unfortunately, we have to distinguish between "submission"
>>> formats" and "publication input" format, 
> ...
>> While that is important, it is not relevant to the proposal to
>> transition from .txt to UTF-8.
> 
> I am not so sure.  At the least, we need to be clear about why it does
> or does not matter.
> 
> 
>> So now you're adding yet another format to discuss:
>>
>>     author source format
>>
>>     submission format
> 
> What is the difference between author source and submission?  Or rather,
> how is author source relevant to a discussion about RFC 'standards'?

For xml2rfc and nroff, author source is a submission format. For other
systems, it is not.

I don't support requiring submission formats that aren't supported as
output of modern WYSIWYG word processors.

> If the author source is entirely private to the author, it is entirely
> out of scope for this discussion.  No?

That's an IF. xml2rfc was an author format that crept into the
submission chain. That may be fine for those who want to use that
format, but if it's required, it's restrictive.

>>     RFC Editor internal format
> 
> .nr is a legal submission format, too.  So it's status as the canonical,
> internal representation is a bit peculiar, perhaps.  Certainly the fact
> of that choice pops up regularly in discussions about making changes to
> the overall system.

The current submission formats are xml2rfc and txt. If you submit a doc,
you're asked if you have xml2rfc or nroff source, which the RFC Editor
starts from, but ultimately needs to check even the nroff against the
originally submitted text.

>>     archival format
> 
> Just to confirm, I assume you mean a format that is published and,
> therefore, directly available for open consumption?
> 
> (An example of something that is archival but not openly published is
> the .nr source...)

"archival" was intended to mean "is maintained by the RFC Editor as the
archived version available to the public".

>>     supplemental format (whether RFC Editor-generated or not)
> 
> What would be an example, that is distinguished from 'archival'?

.ps, .pdf - as submitted by the author
.ps, .pdf, .html, .doc, etc. - as generated by automatic sites, e.g.,
Henrik's

...
>> I don't care what the RFC Editor uses internally, so long as they accept
>> submissions in the same format as are archival.
> 
> In general, I'd probably agree. Unfortunately, the RFC Editor's choices
> affect the rest of the service.  So their internal format choice
> probably should matter to us.

It can/should creep into the submission format as permitted, but not as
required (IMO).

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjuMgIACgkQE5f5cImnZrvpnwCdE5SGuLHhZHpA2PAUHUqC+yRH
K+AAnRv4LJNb/oCkVlTRIXduH4uNXpyv
=jkfB
-----END PGP SIGNATURE-----


More information about the rfc-interest mailing list