[rfc-i] Towards Consensus

Phillip Hallam-Baker hallam at gmail.com
Fri May 25 08:46:34 PDT 2012


Watching this discussion I can see some points that I think that most
reasonable people can agree on and I would like to suggest that these
actually give us a pretty clear way forward as far as at least a first step
goes.

*Proposition 0: The objective of having IDs and RFCs is to communicate
information to readers. Format proposals should be judged on their
effectiveness as a communication medium and the demands they impose on
document producers*
*
*
It is very easy to make a case for one particular format by choosing some
bizarre corner case that begs the question. The purpose of RFCs is to
communicate. A format that has a high overhead is going to be unacceptable
as is a format that has a high probability of introducing unchecked errors.


*Proposition 1: It is reasonable for a participant to request the ability
to read IDs and RFCs in a particular format.
Proposition 2: It is utterly unreasonable for anyone to demand that others
read IDs and RFCs in a particular format unless there are specific reasons
why a particular format is necessary*

Note that Proposition 1 does not mean that we necessarily have to support
every format, just that it is reasonable to suggest support for
traditional, HTML, PDF/A or whatnot.

The point I am making with Proposition 2 is that however much others may
like traditional format, I am not going to read RFCs in it. I don't even
review the plaintext format of the IDs I submit myself. I only ever look at
the HTML output and that isn't up for negotiation as far as I am concerned.

The only good reason I can see for requiring a particular format is when
the nature of a draft is such that a particular format is inadequate. I do
not want people to be required to produce plaintext versions of drafts
dealing with I18N. That is a total waste of time in my view. If support for
I18N email addresses is important then so is support for I18N in the
documents describing them.

We can debate whether the demands of people who insist on traditional
format are more important than (say) an author who wants the document to
actually present their name correctly but it is certainly a 'specific
reason'.

I find the arguments about 'Canonical' format to be total nonsense. As far
as IETF tradition goes, the standard has always been set by bits on the
wire rather than the documents. In 20 years of being involved in IETF, I
have never once come across a situation where the presentation format of a
document introduced an ambiguity. And in the highly unlikely case that it
ever did, a new document would be required in any case. The document that
is most likely to be considered 'authoritative' today would be the XML2RFC
input.


*Proposition 3: How to support included files (images, source code) should
be considered separately from whether to support them*

The reason for this is that the option space for how to support included
files is much larger and more complex than the option space for whether to
do so. We can argue over different image file formats (PNG, JPEG, Vector)
at considerable length but none of that has the slightest impact on the
question of how to upload them to the editing system or how to view them.
Any content we decide to support is going to have an associated MIME type
(and quite likely a file extension).

Another reason to avoid having the discussion of what included formats to
support is that everyone fights over images while what is actually most
important is actually included code and examples. People can argue over
whether ASCII art is useful or not. Arguing over whether it is useful to be
able to extract an XML schema file from a Web Services standard is
ridiculous. Of course it is useful to be able to pull the schema from a
specification in a single mouseclick. Doing so reduces the likelihood of
error.

The biggest challenge in developing a toolset for included files is going
to be how to upload them to the site. But that problem stems from the fact
that we don't actually have good tools for managing collections of
documents as a single entity. I can see several possible approaches: mime
archives (mhtml), zip archives, Paul's suggestion. This is going to be
tricky but it probably does not need to concern us till we get to writing
code.


*Proposition 4: XML2RFC MUST continue to be supported as an input format
Proposition 5: HTML MUST be supported as an output format*
*Proposition 6: HTML output SHOULD use a restricted set of HTML features.**
Proposition 7: HTML is capable of serving as both an input format and an
output format*

I think proposition 4 is self-evident. There is a considerable investment
in the XML2RFC format. Even if additional input formats are supported it is
going to be necessary to support XML2RFC for legacy.

Proposition 5 is just a statement of the obvious as far as I am concerned.
HTML is the ONLY format supported on a wide range of devices. Try reading
'plaintext' and you will find that the browser transforms it into HTML for
display. People could argue for additional formats (like continued support
for ASCII) but HTML is now at least as embedded as ASCII. There is more
information in HTML today than any other format. Pretending that HTML
cannot meet the needs of the IETF is just silly.

But even though HTML is inevitable, the full HTML feature set is not. And
in particular we are going to want conventions that enable a common IETF
style sheet to be applied.

Proposition 7 is a simple statement of fact.

If these propositions are accepted, I think we can arrive at a subset of
the eventual system that is almost certainly inevitable:

*1) A profile of HTML for use in RFCs and IDs*. This would specify
permitted tags, required metadata and class identifiers to be applied so
that the document displays correctly with the associated stylesheet. It
MUST be possible to roundtrip information from the HTML profile to the
XML2RFC format and back.

1a) Extend XML2RFC as necessary to avoid unnecessary loss of data.

*2) Stylesheets* for IETF, ISOC, etc documents.

*3) Modify the existing XML2RFC* toolchain to generate the new HTML format

*4) HTML2RFC tool.* This would perform nits checking and be capable of
generating the corresponding XML2RFC file.

*5) Modify the publication Web* site so that the HTML versions of the
drafts are visible alongside the traditional format, pdf etc.

*6) Modify the submission tool* so that ALL that is required to submit a
draft is to provide either the XML2RFC format or the HTML format (or the
traditional format)

I don't think any of these are particularly complex for what I suggest. In
fact I think that my proposal above is pretty much the minimum that we
could do.

I may be able to help on 4. I already have a toolchain that I use to
develop drafts which can probably be modified. It is in C# but this can be
made to run on Mono without much difficulty. If someone could show me how
to make plug-ins work in Visual Studio I could produce a tool whose results
were quite literally 'awesome'. Unfortunately I have a com issue that keeps
tripping me up.


What this proposal does not address is:

*1) How traditional format would continue to be supported. *

For example, how to deal with documents that cannot be represented in that
format. Should there be a new I18N version of the format? What if the only
part that cannot be represented correctly is the author's name?

I think that this is something that can be left to the advocates of
traditional format to decide. But what is not acceptable is for all
possibility of progress to be determined by what is possible in traditional
format. If we have a document that is giving security advice to developers
of application user interfaces, that document is going to have examples of
user interfaces or be worthless. In that particular case, the plaintext
version of the document should probably just state that the HTML version
needs to be consulted.

*The scope of activities of the IETF should not be determined by the
capabilities of the RFC format.*

*2) How to manage included files.*

This is actually the hardest part when it comes to dealing with images and
source. I think that the easiest approach in practice is likely to be to
use MHTML format. This is widely supported by browsers, at least on the
desktop. so one way I could submit a document with included images as a
draft would be to bring it up in my browser, then select, 'save as MHTML'
and submit the saved file. That is clunky but not much more so than usual.

I think that in practice it is going to be more useful to have a nits tool
that can be run by the document author on their own machine that would have
'submit' as one of the options. For such a tool to be useful to me it would
have to be a self contained executable and not something that requires a
separate framework to be compiled and installed first.

*3) What included file formats to support and with what options.*

I think that this is something that is going to require an ongoing process
to manage. In particular we are going to need to decide on specific
criteria for adopting a new format. What options are permitted, validation
tools, etc.

Some formats that we would require are pretty obvious:

Image:  JPEG, PNG, HTML Vector
Code: ABNF, DNS, XML Schema, ASN.1

But the mere fact that a format is obvious does not mean how to implement
it is. To get the full value from this exercise we should be defining nits
for each of the included formats, deploying validation tools, etc. etc.






-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20120525/11384966/attachment-0001.htm>


More information about the rfc-interest mailing list