[rfc-i] RFC Format - final requirements and next steps
hallam at gmail.com
Sun May 13 17:21:35 PDT 2012
I think the deeper point is that the IETF processes for changing the
operation of the IETF have always tended towards deadlock and inertia.
That is why I am thinking that we are likely to have to think in terms
of a two phase strategy.
Develop a HTML RFC format that is logically equivalent to RFC2XML
format and tools to convert from XML to the new HTML markup and back.
The submission tool would accept input in XML, plaintext or HTML
format. No need for multiple submissions any more. The format
conversion would be done by the RFC tools.
This would allow for many but not all of Heather's requirements to be
met but would not support graphics or equations. The HTML permitted
would be a strict subset.
Once people are submitting docs in HTML form it will be much easier to
get the graphics changes through.
On Sun, May 13, 2012 at 10:33 AM, Dave Crocker <dhc at dcrocker.net> wrote:
> On 5/13/2012 7:17 AM, Ole Jacobsen wrote:
>>> I find it very strange that apparently the RFC Editor has been given
>>> > authority to unilaterally decide on a new RFC format. Writing RFCs
>>> > is the core business of the IETF. As such, the way I see it, the
>>> > format of RFCs must be decided upon through the usual IETF decision
>>> > making mechanism.
>> I don't think Heather said "I cannot change the I-D format, but I will
>> change the RFC format" which seems to be what you are implying here.
> Deeper point:
> The RFC Editor has never formally or actually been entirely subject to the
> IETF rough consensus process.
> Formally and actually there has, I think always, been a consultation
> process, but that's quite a different thing.
> While it would test the system for the RFC Editor to go wildly away from any
> obvious community rough consensus, that's a practical point, not a formal
> Dave Crocker
> Brandenburg InternetWorking
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest