gmane.ietf.rfc.interest

Towards Consensus

Phillip Hallam-Baker — 2012-05-25T15:46:34

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.

A proposal: HTML

Iljitsch van Beijnum — 2012-05-24T20:16:02

It seems to me that the discussion is veering off in unproductive directions. So I'll explain the HTML format I have in mind and why I think HTML is a good direction, better than any of the alternatives.

Note that I'm not an HTML expert, there are probably better ways to do many of the things that I'm suggesting here.

A big problem today is that the draft/RFC format can't easily be generated by widely used tools, and the tool(s) that _can_ generate it are not exactly user friendly. There is no magic bullet that will make that problem disappear completely, but HTML gets us at least a good part of the way there. So let's discuss that part first.

WRITING

Writing a draft/RFC has three main parts:

1. The front matter, with author names, publication dates, titles, etc
2. The main body text and headings
3. The references

At this point, I'm going to refrain from complaining about how XML2RFC handles part 1, but rather assume that there is no reasonable way to make this completely painless, and suggest that although the details can be improved, we should probably stick close to how XML2RFC handles this. That could look as follows:

etc

Part 2, the main text. The problem with XML2RFC is that it heavily relies on nested <t> elements. This is unlike HTML or the way in which word processors work, where the heading levels are not automatically deduced from the explicit nesting, but rather the heading level is explicit. So converting back and forth between HTML and word processor formats is much more convenient and less likely to lead to loss of information. Also, the HTML way of doing this is much easier on humans, because you don't have to hunt through the entire document for missing </t> elements (yes, I've missed submission deadlines for this reason).

An example:

<h2>Stateless EPRT translation</h2>

<p>
If the address specified in the EPRT command is the client's IPv6 address, then the FTP ALG reformats the EPRT command into a PORT command with the IPv4 address that maps to the client's IPv6 address. The port number must be preserved for compatibility with stateless translators.
</p>

(Note that the section numbering can be made automatic using CSS but it may be useful to make this explicit/hardcoded during the RFC publication process.)

Then there is part 3. This is unbelievably bad in XML2RFC. In order to refer to an RFC, which is by far the easiest type of reference, I need to have incomprehensible incantations at the top and the bottom of my document:

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc959 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0959.xml">
]>

so I get to use these in my text: <xref target="RFC0959" />. I guess the decision on whether the leading zero should or shouldn't be there was solved by randomly requiring it to be present or requiring it to be absent.

This needs to be made much, much easier. During the writing stage, just linking to the canonical location of a reference should suffice. Afterwards, a tool should find all the links, see if they exist in the reference database, and if so, add them to the reference section in the appropriate order (RFC number, appearance for non-RFCs, whatever), where each reference is just text without any markup with a link back to the reference database rather than the carefully marked up and therefore incredibly hard to generate reference format for non-RFC references that XML2RFC imposes.

READING

I hope I've been able to make a good case that an HTML format is useful as an authoring format. Now on to HTML as a consumption format.

There are currently text, PDF and different HTML versions of RFCs. These are created by running a tool that performs the necessary conversions. However, making such tools isn't all that easy, so it would be very good to remove the dependency on tools where we can. And CSS gives us exactly that. Again, I'm no HTML/CSS expert, but I do know that you can make CSS do almost anything in a browser. And the really good part is that this can all be done by modifying an external CSS file, without making ANY changes to the actual HTML content.

So it's entirely conceivable that the same HTML file can be displayed like this:

http://tools.ietf.org/html/rfc2460

or like this:

http://pretty-rfc.herokuapp.com/RFC2460

Or in may other ways. An HTML RFC CSS file would require quite a bit of plumbing to get some stuff done, but lots of things, such as TOC presence, colors, margins and font type/size should be very easy to change by any user who can edit a text file.

TOOLS

Because all the pertinent information is explicitly marked up, parsing an HTML RFC would both be easy and relatively foolproof. The only thing we need to do is limit the HTML allowed to the subset that we need for RFCs, so tools don't have to implement esoteric browser features, but can simply work on basic HTML. The hard part of a browser's job is displaying the HTML, which our tools wouldn't need to do, they only have to parse it.

We can also format the HTML elements and text such that the text sticks relatively close to the current ASCII format, so that simply removing all the HTML leaves a usable ASCII version.

ARCHIVING

So if we can have a format that is both good for writing RFCs as well as for reading them on screens and parse them with relatively simple tools, such a format would of course also be the perfect format to archive, and at some later point use as the basis for an update.

PRINTING

The only limitation that we currently have is that printing HTML doesn't always produce the best results. So for printing, it would probably be useful to have one or more alternative PDF versions. More if we don't care about page numbers, so we'd have a version for letter size and one for A4 size, one if we do care about page numbers, which will print on both letter and A4 paper.

Note that having alternative versions for printing is less of an imposition than having alternative versions for different types of displays, because with printing "deep linking" is rarely an issue, while following a link to a section of an RFC in a format that is not really compatible with your screen size can be disruptive and isn't easy to avoid if multiple versions for different screens exist. Printing on the other hand is a deliberate process where extra steps to find the right format are less disruptive.
_______________________________________________
rfc-interest mailing list
rfc-interest< at >rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

Speaking of presenting RFCs

Tim Bray — 2012-05-16T19:33:03

Check out http://pretty-rfc.herokuapp.com

for example http://pretty-rfc.herokuapp.com/RFC3986

Works great on my mobile; even shifts the ToC in and out depending
whether the phone is in landscape or portrait. A fine piece of work.
-T

RFC Format - final requirements and next steps

Heather Flanagan (RFC Series Editor — 2012-05-11T16:50:00

Hi all -

Thanks to the feedback from the community, I've modified the 
requirements for the format of RFCs (which ties in I-D format 
as well, though any actual change to I-D format is outside my 
purview).  I've collapsed two categories in to one (Edit and 
Review) since they have almost exactly the same requirements.  
RFC Editor requirements in most cases are similar to Edit/Review, 
but with a few unique ones important to the editors.  Archive 
and End consumption still vary.

http://www.rfc-editor.org/rse/wiki/doku.php?id=formatreq
(point of order - is it better for me to include a link as above, 
or copy the list in to the email?)
 
At this point, I would like to encourage people to submit (or 
point to existing) I-Ds with these requirements and requests as 
input.  I do not expect any proposed solution can meet all the
needs and wants listed by the community, but I'd like to see how 
close we can get.

Note that the deadline for I-D submission for an initial document
to be discussed at IETF 84 in Vancouver is 2012-07-09.  I don't
expect to make a decision at the Vancouver meeting, but I will 
likely host a BoF to discuss what has been submitted and next steps.

Thank you again for the input so far!
Heather Flanagan, RSE

support for tables (from RFC 5892)

Larry Masinter — 2012-04-24T22:13:17

This is also a good example of "Better support for tables". While XML2RFC supports tables, the ASCII output is hard to read.

Should authors be allowed or discouraged from styling tables? (Separating lines, alignment, etc.)?



Larry



-----Original Message-----
From: rfc-interest-bounces< at >rfc-editor.org [mailto:rfc-interest-bounces< at >rfc-editor.org] On Behalf Of Peter Saint-Andre
Sent: Tuesday, April 24, 2012 1:08 PM
To: Iljitsch van Beijnum
Cc: rfc-interest< at >rfc-editor.org
Subject: Re: [rfc-i] Use of unicode



On 4/24/12 1:51 PM, Iljitsch van Beijnum wrote:






That's really all we're talking about here. Can we agree that we're in

violent agreement and end this thread?



As one instance of such examples, consider the six lines at the bottom

of page 7 of RFC 5892:



00DF; PVALID     # LATIN SMALL LETTER SHARP S

03C2; PVALID     # GREEK SMALL LETTER FINAL SIGMA

06FD; PVALID     # ARABIC SIGN SINDHI AMPERSAND

06FE; PVALID     # ARABIC SIGN SINDHI POSTPOSITION MEN

0F0B; PVALID     # TIBETAN MARK INTERSYLLABIC TSHEG

3007; PVALID     # IDEOGRAPHIC NUMBER ZERO



It would be friendlier for those lines to be something like this:



00DF; PVALID     # ß LATIN SMALL LETTER SHARP S

03C2; PVALID     # ς GREEK SMALL LETTER FINAL SIGMA

06FD; PVALID     # ۽ ARABIC SIGN SINDHI AMPERSAND

06FE; PVALID     # ۾ ARABIC SIGN SINDHI POSTPOSITION MEN

0F0B; PVALID     # ་ TIBETAN MARK INTERSYLLABIC TSHEG

3007; PVALID     # 〇 IDEOGRAPHIC NUMBER ZERO



--ᏚᎢᎵᏋᎢᏋᏒ



[U+13DA] [U+13A2] [U+13B5] [U+13CB] [U+13A2] [U+13CB] [U+13D2]

_______________________________________________

rfc-interest mailing list

rfc-interest< at >rfc-editor.org<mailto:rfc-interest< at >rfc-editor.org>

https://www.rfc-editor.org/mailman/listinfo/rfc-interest
_______________________________________________
rfc-interest mailing list
rfc-interest< at >rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

Now tell me how to communicate this as effectively inplaintext

Phillip Hallam-Baker — 2012-04-23T16:28:14

I have been working on the attached document for several months. It
describes a proposal to change the structure of PKI. Note that none of
the other proposals referenced are described in RFC form either, nor
do the authors have any intention of using that format.

The subject matter is neither simple nor straightforward. The
arguments are not straightforward either. PKI is a complicated subject
because it deals with the real world and the real world is complex.

While all the diagrams and illustrations are described in the text, it
is much more likely that people will understand the diagrams than the
text.


Now while I could convert this into plaintext format I am not going
to. I am going to make my argument in the format I think is going to
be most effective for communication.

I have the following questions:

1) Does anyone seriously want to argue that the document would be
easier to interpret in plaintext format without any diagrams?

2) Do people respect the fact that it would take me a great deal of
time to write text that could come anywhere near as clear as the
diagram?

3) Does anyone imagine people would read the result?

4) Would anyone insist on plaintext if they thought that people had a
choice in the standards organization they participate in?


[I understand that the attached file will not work on kindle but I
would be only too pleased to produce the file in an alternative format
if we agreed one. Indeed the kindle format might well serve the
purpose]

Guidelines for illustrations

Larry Masinter — 2012-04-23T22:39:52

I think some simple guidelines for illustrations would go a long way. Maybe not "rules", but "guidelines". But engineers often get carried away since most people who author Internet Drafts are not professional designers and don't think about simple things like accessibility and whether the diagram will print out.

For text, the RFC editor can actually fix grammar errors and missing references and periods in the wrong place.
For graphics, the RFC editor can only fix things for which the RFC editor has tools which can edit the graphics that are delivered to the RFC editor.

That won't be true for graphics delivered as images -- not editable. And while Adobe illustrator can be used to edit SVG, the kinds of edits needed are probably not really supported.

Some guidelines:

Keep the diagram or illustration to something that could reasonably be done in ASCII art. That's not because we like ASCII art, but just as a matter of insuring maximum interoperability. For example, diagrams and illustrations could be kept to simple lines, arcs, text which doesn't depend on the font -- even if the font is embedded.

Diagrams should avoid unnecessary use of color -- to make sure the illustration or diagram can be printed on a black and white printer, that it doesn't require calibration of color of devices.

I don't know how much of this the RFC editor wants to get into, though.

If it is a requirement that someone can take an old RFC and start editing it to produce a new one, then having the archival form of the illustrations be in an editable vector graphic format seems a minimum, but that's problematic, if only because the field is still developing.

http://www.yworks.com/en/products_yed_about.html
http://www.gliffy.com/
http://code.google.com/p/diagram-editor-for-google-plus/

Use of unicode

Larry Masinter — 2012-04-23T10:14:30

Locations:


Authors' names (ID/RFC author, author of cited document)
EAI Authors' email addresses
Titles of cited documents
IRIs for cited documents
Examples for protocols about I18N and non-ASCII characters
Other examples
Unicode art
Normative text


I think these have different priority and different impact.  The problems are quite similar to the problems of URIs vs. IRIs: there is a tradeoff between global transcription (everyone can copy text from one device to another, visually, even if haltingly) and local optimization (people get the names and characters they are familiar with).

Some guidelines:

Avoid spurious uses, like upside-down letters written for fun, dingbats, emoji, etc.
Only use non-ASCII when absolutely necessary; preferably provide ASCII alternative also.
If characters are used for which fonts are not universally available, release at least one format with embedded fonts (PDF/A, ePub).

Accessibility requirements

Larry Masinter — 2012-04-18T06:52:27

One of the requirements we must be aware of and optimize for is accessibility.

* Non-ASCII characters: I do not know the deployment of support for Unicode strings in screen readers, but I imagine that it isn't as consistent as support for ASCII strings, especially for obscure characters (dingbats, emoji, etc.)
* Equations: I am told that MathML has a better story for accessibility than other forms of equations. Treating equations as illustrations reduces accessibility.
* Illustrations, diagrams: Explicitly requiring accessibility for illustrations (alternate descriptions) might make documents MORE accessible over ASCII art.

I think we should be EXTREMELY conservative about making accessibility of documents WORSE for ANY audience, and so explicit attention to accessibility is important.

The W3C recommendation "Web Content Accessibility Guidelines (WCAG) 2.0" is a must-read.

"Web Content Accessibility Guidelines (WCAG) are part of a series of Web accessibility guidelines published by the W3C's Web Accessibility Initiative. They consist of a set of guidelines for making content accessible, primarily for disabled users, but also for all user agents, including highly limited devices, such as mobile phones. The current version is 2.0."

http://www.w3.org/TR/WCAG/

Note that there are accessibility guidelines for HTML, PDF, SVG.

I don't think WCAG actually goes far enough for this. WCAG is focused on "how to make whatever content you have accessible", while we are focused on "whether to allow material which cannot be as easily made accessible".

Reclassification of RFC 2223

SM — 2012-04-17T23:49:47

Hi Nevil,

According to http://www.rfc-editor.org/info/rfc2223 RFC 2223 is not 
Obsolete.  According to the RFC Editor website, RFC Document Style is 
documented at http://www.rfc-editor.org/rfc-style-guide/rfc-style and 
Instructions to Request for Comments (RFC) Authors is documented at 
http://www.rfc-editor.org/rfc-editor/instructions2authors.txt

I gather that the information provided in RFC 2223 is out of 
date.  Between you and me, it's a bit like V'Ger.  Instead of waiting 
until 2273, I suggest reclassifying RFC 2223 as  Historic within the 
immediate future.

Regards,
-sm

Problems and requirements for RFC Format

Heather Flanagan (RFC Series Editor — 2012-04-17T21:13:08

Hi all -

Thank you all for your patience and input to the RFC Format question.
One of the things I've been working on is an organized list of what
problems we're trying to solve and what the requirements actually are
for the RFC series.  As Larry Masinter mentioned in the BoF, there are
several different constituencies that have their own particular problems
and concerns, and that will in turn influence whatever we decide
regarding the future of the RFC format.

What I would like from the folks on the rfc-interest list is feedback on
whether or not I've captured consensus on the problem space.  Note that
I'm avoiding formal use of MUST and SHOULD right now, though I have
tried to indicate level of requirement as I understand it so far.

======

Draft-Edit (what authors worry about when writing an I-D)
* Respect for authors names (Limit to character set prevents proper
display of all names)
* Authors need a way to update documents easily and see how they might
look when published
* Need to be able to include complex graphics/equations
* Need be able to diff versions of a draft
* Need to be able to create new documents by hacking away at older ones
* Want a more flexible line length
* Want to be able to tag ownership/source of comments


Draft-Review (what authors, Ads, and working groups worry about when
reviewing an I-D)
* Respect for authors names (Limit to character set prevents proper
display of all names)
* Need to be able to include complex graphics/equations
* Need be able to diff versions of a draft
* Want a more flexible line length
* Want to be able to tag ownership/source of comments


RFC-Edit (what RFC editors worry about when editing a document)
* Respect for authors names (Limit to character set prevents proper
display of all names)
* Need to be able to include complex graphics/equations
* Want a common source file type (lack of one common source file type
results in more training on markup language (nroff, xml) and
inconsistency in output)
* Want a single, discrete source file for a draft (not multiple files
and a make file)
* Want a publicly available "official" conversion tool (same source file
producing the same output between I-D submission and RFC editing step)
* Need source file to be editable by both authors and RFC editors


RFC-Archive (what the RFC Editor worries about when publishing an RFC)
* Need format to be easily rendered in to other, potentially undefined
formats (.txt, .html, other)
* Need one format to be the authoritative version, suitable for legal
records
* Need to be able to create new documents by hacking away at older ones
* Need backward compatibility to recreate documents originally created
in an older version of the output tools (backward compatibility issue
doesn't apply to docs published prior to the format change)


End consumption (what consumers of RFC worry about)
* Need to be able to see complex graphics/equations
* Want to be able to link sections and jump ahead in the document
* Want intelligent html-style linking within references
* Want the RFC to be suitable for small screens/mobile devices
* Want to have neat printing (intelligent pagination)
* Need to be able to search document and document repositories with
tools such as *grep

======

So, what's missing?

-Heather Flanagan, RSE

Withdrawing Authors, Editors, and Contributors doc

Heather Flanagan (RFC Series Editor — 2012-04-16T17:55:32

Hello everyone -

A few months ago, I sent out a document for review (Authors,
Contributors, Editors, and overload" to the rfc-interest list
(http://www.rfc-editor.org/pipermail/rfc-interest/2012-January/002840.html)
and my advisory group.  The overwhelming feedback regarding the
creation and standardization of a Contributing Authors section and
potential modification to the authors and affiliations on the main
page was negative.  As such, that document is being withdrawn from
consideration for becoming RFC Editor policy.

For the recurring question of number of authors and editors, we will
address this in the revised style guide (in progress).  The current policy
(http://www.rfc-editor.org/policy.html#policy.authresp) is in place until
the revised style guide is available

Thank you all for your feedback!

Heather Flanagan, RSE

must vs. MUST and conformance requirements

Larry Masinter — 2012-04-11T05:54:06

I'm less concerned about the syntactic representation of conformance requirements, and much more concerned about the poor job many document editors and working groups do at establishing conformance criteria that are testable, or even meaningful. 

Wishful thinking: some tooling that gathers together the context of normative keywords would help encourage better spec-writing?

draft-rfc-image-files-03

Iljitsch van Beijnum — 2012-04-08T18:16:22

I just had a look at http://tools.ietf.org/id/draft-rfc-image-files-03.txt

I think this is a spectacularly bad idea. This way, we would have all the downsides of PDF, all the downsides of formatted ASCII text, and lose the advantage that we only have a single file.

This also locks us into pagination even deeper, while IMO that's something we should move away from, because the number of times when US letter pagination is convenient are dwarfed by the number of times when it is not.

There are lots of tools that read and write PDFs, but that doesn't mean it's necessarily reasonably possible to round trip an image from an image editing program to PDF and back without losing a lot of information. For instance, the image may be rasterized so what was a vector image is now a high resolution bitmap. Or logical structures are broken up in lots of small structures but the relationship between them is lost.

I don't think these issues are easily avoidable without blessing a specific tool. And tools tend to go away on decades timescales. Therefore I think that if we want to allow images as authoritative parts of RFCs (which I still have to see a good case for) this needs to be relatively low resolution bitmaps in an open format, like PNG. Bitmaps have the advantage that they are very simple structures that are easily manipulated with simple software, not unlike ASCII files.

Finally, let me observe that a lot of people here are applying a tinkering/hacking mindset, trying to get some benefits with modest changes. I don't think that's the right approach here. It's perfectly fine to make very big changes if that gives us what we need. Small steps are a bad thing here, that means that 20 years from now the tools that scrape the RFC repository need to support many variations that were around for only a short time rather than just "old" and "new".

RFC Server Outage Report

Glen — 2012-04-06T22:09:51

All -

Yesterday (April 5) at 8:54 AM Pacific time the RFC Editor server was attacked
and compromised by an outside party.  As a result of this hack, the server's
operation became erratic.  Staff were unable to login, and the website was
returning invalid search results for searches against the RFC Editor database.

AMS IT staff took immediate action, halting the server and performing an
investigation.  We restored service 90 minutes later, after repairing and
restoring the damaged server, and doing a thorough check to make sure we
hadn't missed anything.

At the time, notifications were sent out to RFC and IETF leadership; this
follow-up message is being sent to the community at the request of the
IAOC chair.

AMS took steps to identify the attack vector and remove the discovered
vulnerability.  A variety of other steps were taken to ensure that no other
systems were compromised, and that future attacks of the same type would fail.
No data was lost, no permanent damage was done, and the total downtime for
the website was 90 minutes.

The game of hack vs. hack-prevention is, unfortunately, an ongoing one.  
There are many who believe that attacking servers is an appropriate course
of action.  Reality (and various international laws) prevents us from 
totally eliminating those type of threats.  This attack was caught, handled
quickly, and AMS staff continues to watch for any future threats that
doubtless will come our way at some point.

Thank you for your attention.

Glen
Glen Barney
IT Director
AMS (IETF Secretariat, RFC Publisher)

Timely Spec Restyling Proposal from W3C

Martin J. Dürst — 2012-04-02T01:17:06

Given all the intense discussions last week about how to move forward 
with new format(s) for RFCs and Internet Drafts, I'm glad to be able to 
forward this timely proposal from W3C, in the hope that it will provide 
some additional stimulation for our discussion.

I'm sorry if this proposal is slightly late is some parts of the world, 
it's already Monday here but it should have gone out on Sunday.

Acknowledgments got to Fantasai for the explanatory text below and to 
Tab Atkinson for the new design.

Regards,    Martin.

-------- Original Message --------
Subject: Spec Restyling Proposal
Resent-Date: Sun, 01 Apr 2012 22:38:07 +0000
Resent-From: spec-prod< at >w3.org
Date: Sun, 01 Apr 2012 15:37:33 -0700
From: fantasai <fantasai.lists< at >inkedblade.net>
To: spec-prod <spec-prod< at >w3.org>

Hello spec-prod!

The CSS Working Group has finally prepared a spec restyling proposal that
we feel captures the mission of the W3C. I've sent a preview as applied to
several of our CSS specs to www-archive:
 
http://lists.w3.org/Archives/Public/www-archive/2012Apr/att-0000/css3-images
 
http://lists.w3.org/Archives/Public/www-archive/2012Apr/att-0000/css3-flexbox

Below is an explanation of the motivations for our changes:

Futuristic Look
   In keeping with W3C's mission to "lead the Web to its full potential",
   we wanted to emphasize that W3C is creating the Future of the Web.
   To show that, we chose a deep space background, which gives the design
   its futuristic feel. To preserve sufficient contrast with the background
   in keeping with the WCAG, we chose a bright yellow text color.

Passion and Creativity
   People have the impression that creating specs at W3C is a boring,
   beaureaucratic, process-laden process. They rarely get to see the
   passionate dedication to a better Web that our Members bring to our
   discussions, such as the vibrant discussions of longdesc and video
   formats in the HTMLWG. To better reflect the passion and creativity
   of the standards process, we propose a new W3C logo creatively
   designed with animated flames.

Diversity and Dynamism
   Symbolizing the diversity and dynamism of the Web, we chose animated
   rainbow horizontal rules to set off headings from the body text.
   A defining characteristic of 90s web design, this also gives us a more
   modern, up-to-date look by hooking us into the "retro" trends of some
   of the latest and most fashionable designers. (And by choosing the 90s
   rather than an earlier decade of visual design, we expect to remain
   ahead of the curve for awhile. Future-compatibility being one of the
   design principles of CSS, we felt this was an important consideration.)

Under Construction
   Of course we wanted to address the concerns that people don't take the
   "under construction" nature of our specs seriously, referring to Working
   Drafts and Candidate Recommendations as if they were a done deal. To that
   end we added an "under construction" logo to the background of the text.
   So as not to interfere with the readability of the spec itself, this logo
   is only placed in the marginal gutters on either side of the spec. But to
   make sure that even people landing on ULRs with fragment IDs see it, we
   gave it a repeat-y value so that it shows up on all sections of the spec.
   (Of course for REC, the "under construction" styling would be removed.)

Preserving Symmetry
   Tying the design together, and upholding the the classical ideals of
   symmetry--which represents our commitment to logical design decisions--
   we center-aligned all the text.

We hope you like the new design! As you can see, we've already deployed
it on all of the CSSWG editor's drafts:
   http://dev.w3.org/csswg/

We look forward to seeing the new design adopted W3C-wide~

For the CSSWG,
~fantasai

Meetecho session recording available

Meetecho IETF support — 2012-03-29T17:12:47

Dear all,

the full recording (synchronized video, audio, slides and jabber room)
of RFCFORM session at IETF-83 is available.

You can watch it by either clicking the proper link on the remote 
participation page 
(http://www.ietf.org/meeting/83/remote-participation.html#Meetecho), or 
by directly accessing the following URL:
http://ietf83.conf.meetecho.com/index.php/Recorded_Sessions#RFCFORM_IETF83

For the chair(s): please feel free to put the link to the recording in 
the minutes, if you think this might be useful.

In case of problems with the playout, just drop an e-mail to
team< at >meetecho.com.

Cheers,
the Meetecho team

Pagination and some other stuff

Iljitsch van Beijnum — 2012-03-28T12:44:22

The pagination question is very important. Even more so than creating the required line length, coming up with the pagination in drafts is problematic. Tools commonly used today simply don't output in this format, and it's hard to create it manually, too.

Now that would be one thing if it's useful for people who want to read drafts and RFCs, but I'm afraid that's rarely the case. 55-line pages don't fit well on screens (large and small alike, although more of an issue on small ones) or on European paper sizes.

However, if we want to get rid of pagination we need to be able to live without page number references. Are we prepared for that? Obviously a ToC can be generated for the PDF versions (yes, multiple: one for each common paper size), but otherwise they can't be used anymore. Someone mentioned paragraph numbers for referencing stuff, but I'm not sure that would work well. In practice today we use a section number or quote the offending text, which seems to work well enough. But I could be mistaken.

After thinking a bit more about the various issues, it occurs to me that pretty much all complaints about how RFCs look can be addressed by people getting the appropriate alternative format, and thus don't seem sufficient to change the main format.

I'll be very happy to see an ePub version along with text/HTML/PDF, and we may want to come up with a canonical HTML version, as well as make the alternative versions more prominent on the IETF and RFC Editor websites.

The RFC format has been tightened a lot in recent years and we have more tools, so we can derive alternative formats pretty reliably from recent RFCs these days, and any change isn't going to address the old ones anyway. And although not as easy to work with as it once was, the RFC format is still very accessible and there are no signs of this changing anytime soon. So no reason to make changes for archival purposes, either.

So then there are difficulties in writing drafts, non-Latin characters, images and equations. Equations can also be represented in text so I'm not even sure if there's a real problem, or otherwise as images so they reduce to the image problem. Non-authoritative images are already possible, and making images authoritative seems problematic. This option isn't used a lot, and a large part of ASCII art is header diagrams which aren't too hard to draw and could be prettyfied into image form algorithmically. So not sure we have a problem here, either.

We need to be really careful with non-Latin characters as they are not universally understood by the community. (My first name is from Russian and my last name is Dutch. So my name should really be written as Ильи́ч van Beĳnum (note the ĳ). Can you type that?) But we can either make non-authoritative versions that have them or allow limited amounts of UTF-8 in RFCs without breaking much, if anything.

So apart from the minor issue of whether to allow UTF-8, it seems to me that it all boils down to the question of whether _writing_ RFCs is so difficult that we need to improve the input format, and/or whether the conversions between the different formats are problematic enough that we need to streamline this process by requiring better meta data in the authoritative format.

_______________________________________________
rfc-interest mailing list
rfc-interest< at >rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

illustrations & equations rare: extra overhead for creating them acceptable

Larry Masinter — 2012-03-28T09:31:33

Opinion: Illustrations and equations should continue to be very rare:
 Because:   Reviewers must review the legibility of the document without the illustration, and the equivalence of the illustration to the non-illustration text.
   
Opinion: extra overhead for creators of illustrations and equations is OK
   Because: they are (and should remain) rare.  
                       No matter what technology is used to display, they're not usually edited "by hand" anyway.
                     There are numerous tools for creating and converting to (perhaps not for editing of) mathml / svg
            
   Opinion: equations and diagrams should have accessible alt-text / longdescs 
      Because: needed for accessibility,  for creating text-only renditions.

Observation:     diagrams and equations don't work well on small-screen devices, no matter what file format
       (ASCII art, PDF, jpeg, SVG, whatever), unless the diagrams and equations are really small.

Next steps in the RFC Format discussion

Heather Flanagan (RFC Series Editor — 2012-03-28T09:24:56

Hi all -

I believe my next steps are to filter through what's been said on the
list and in the BoF in order to determine the global requirements for
the input, archiving, and display of RFC.  I'm going to avoid specific
technologies and/or protocols at this point in favor of documenting what
the problems and requirements are that those technologies may be solving.

Some of you are working on tools to demonstrate your point, and others
are working on Internet-Drafts to describe your proposal.  That's fine,
though you may find it useful to hold off for a bit to incorporate my
findings.  Your call.

Thank you all.  This has been a useful conversation for me, and in
particular, a useful BoF.

-Heather

Normalized HTML

Larry Masinter — 2012-03-28T08:16:04

After listening to the BOF discussions and reading the email, I've changed my thinking.

I'm leaning toward a marked up profile of HTML where the authoring format and distribution format is a canonicalization of the authoring format. That is, I think we could move away from XML/XML2RFC and instead have a "cleaned profile" HTML with a tidy-step that does the work that xml2rfc does but which is idempotent (i.e., the output is suitable for input and generates the same HTML.)

Having the output format suitable for input and production of other formats trivializes the re-use issues.

"View Source" is powerful.

ID-editor: edit in simplified profile of HTML, or else edit in some tool and generate ("clean") HTML.

ID-submission:
Preprocessor run through a 'tidy' which does things like "make head/title match h1 header", fixing up metadata, annotating or styling references, fix cross-references.
Postprocessor: generate ASCII-only view of HTML by substituting longdesc for diagrams, changing cross-references, etc.

ID-review:
Reviewers can comment on HTML or derived forms (ASCII-text view, PDF, epub, etc.)

RFC-editor:
Validate ID-submitted form, edit in same way that ID-editor does, if necessary.

RFC-produce:
Convert RFCs also into .txt, .pdf, epub.

If they appear, diagrams MUST be in SVG. Equations MUST be in MathML. No images allowed(!) (Text should be text so it is searchable). Probably need some "clean" styling requirements for diagrams.

Equations and diagrams must have ASCII-only alt descriptions for accessibility, meet accessibility guidelines.

Probably something similar to W3C pub-rules and using tools similar to W3C pub tools.