[rfc-i] Proposed new RFC submission requirements
mrex at sap.com
Fri May 25 11:07:29 PDT 2012
Joe Hildebrand wrote:
> "Martin Rex" <mrex at sap.com> wrote:
>> Since the RFC Editor is _not_ the author of most of the documents
>> that are to be published as RFC, it will be essential that the
>> submission format can be automatically generated from
>> easy-to-use authoring formats.
> I don't care what is used for authoring in any way. There's no way the RFC
> Editor can police what your authoring input format is. The only thing that
> matters is what you can submit.
The authoring format will be directly affected in case that any of the
currently accepted submission formats is discontinued. Which is why
I am strongly opposed to discontinuing any of the currently allowed
I would be OK with adding a new submission format or with allowing
(but not requiring) additional "features" in an existing input format.
I'm also OK with I18N characters in some new or some existing submission
format, under the following constraint:
There MUST NOT be any new requirement on display devices for rendering
I18N. Any new RFC must still remain fully comprehensible if all
non-ASCII chars are completely stripped, e.g. because the device
is not capable of rendering them.
I don't mind non-ASCII names, but when there is a formal requirement for
a name in the RFC, a pure-ASCII name MUST be provided, an additional I18N
is optional. Similar for EMail-Addresses. That is a very simple
backwards-interop requirement with both (a) devices that do not recognize
that I18N codepoints and humans that do not recognize that I18N glyphs.
If a significant fraction of the consumers of the RFC can not recognize,
read or spell some I18N stuff in a document, then this information can
NOT be normative, only illustrative. If it can not be normative, it
can be stripped without loss of significant information.
More information about the rfc-interest