[rfc-i] Graceful degradation is key, was: Re: draft-hildebrand-html-rfc

Joe Hildebrand (jhildebr) jhildebr at cisco.com
Mon Jul 16 13:04:50 PDT 2012

On 7/16/12 12:38 PM, "Martin Rex" <mrex at sap.com> wrote:

>I don't like this approach of
>"how can we make requirements so that _everything_ besides xml2rfc
>will get killed on the way".
>Could you simply accept that there are more active current uses
>of the TXT version of RFC and I-Ds besides what _you_yourself_
>are doing, 

Absolutely.  I don't care what other formats are made available by the RFC
editor or anyone else.  I would like to ensure that one of the formats is
a more modern one that allows for reflow, non-ASCII codepoints and the
like.  I'd like that format to have lots of its data easily extractable.

I believe that format should be a superset, from which generating
less-interesting versions should be possible.

I would prefer if that format could also be submitted, rather than just
generated, to ensure that the superset format is under the direct control
of the author (if desired), and that the author gets to see the version
that is eventually shown to end-users.  I'd also prefer if that format was
one that was readable (using a tool like a web browser) by copy editors
that don't care about the format.  However, I see everything in this
paragraph as things that could also be achieved by allowing the xml2rfc
format to progress, and letting the RFC editor generate HTML.

However, in that latter case, the I-D stream is likely to have some
tooling issues.

>and that there are I-D authoring tools in use that
>are magnitudes easier to operate than xml2rfc,

Sure.  I'm not a huge fan of xml2rfc either.  However, any of the tools
that are producing enough information to be a viable candidate for the
superset format SHOULD be able to generate either xml2rfc or html with
relatively small amounts of code.

>and that they
>are perfectly sufficient to do the job for a number of current
>and prospective authors, authors which may not want having to
>learn XML first and operate awkward toolchains, do not want to
>maintain huge amounts of meta-data and do not need graphics
>to express their ideas.

Those authors are not currently producing a format that is good enough for
the modern era, so they're going to have to change some part of their
toolchain one day.

That day may be farther off if the RFC editor decides to continue to allow
the old format as well as the new format as input during some transition

>Joe Hildebrand (jhildebr) wrote:
>> And you don't have a single box on which you can install
>> whatever software you like
>While I have three boxes where I can install software myself,
>"whatever software you like" does not apply to any machine that
>is not my very own property.
>But really, even if I was allowed, having to maintain software
>on 100+ distinct machines sounds like a big waste of time.
>Even trying to keep my own machines at home "up to date"
>is a tedious waste of precious lifetime.

The IETF is the only place I think I'll ever hear the argument "I don't
have a web browser" in the next 40 years.

>> Do you read RFC's on all of those boxes?
>Correct, I regularly read RFCs on ANY arbitrary machines from these.
>Within xterms, of which i can easily fit 6 of them simultaneously
>on a 1600x1200 screen (-fn 7x14b -geometry 80x44) without having to

So it's up to you to ensure that the RFC editor continues to produce a
slightly-mangled old format from the new format.  At some point, the
editor can make a business decision about the relative value associated
with doing so.

>When implementing stuff, I typically need lots of RFCs open at the
>same time (like 
>and another one or two for searching, in order to figure out what is
>necessary for interop with implementations based on different revisions
>of specifications.

Browser tabs ~= terminal tabs.  I don't understand your point here.

>Implementing RFCs from a browser view, or doing a detailed review is
>frustrating because of the constant need to switch between documents.
>Having to take the fingers off the keyboard in order to navigate with
>the mouse is also a huge waste of time.

I almost never use the mouse when browsing, except to select portions of
text to copy and paste, so this argument is not compelling to me.  If we
were to require a mouse to read the normative text, I would call this an
accessibility issue, and we'd need to fix it ASAP.

>I also try to make my work environment as portable as possible, so it
>must not matter at which machine I'm sitting (in the office or at home)
>or what underlying OS (Linux or Windows) my "frontend" uses, and how
>fast or thorough the connectivity is, the experience needs to be as
>similar as possible.

OK.  Good goal.  Elinks seems to have a nice port to Windows, as well as
all of the other OS's you mentioned.

>I also do not want to constantly have to care about the particular
>OS & release of the machines have that I happened to have ssh'ed to
>in the next best xterm I've chosen to type "vrfc 5280" in.
>> but I don't expect anyone to need to read an RFC on one of them either
>> they (for the most part) can't do outbound HTTP (or other) connections
>> everything is logged and audited.
>Requiring internet access to be able to read an RFC in order for rewiewing
>or implementing would be extremely unreasonable.

I'm not talking about requiring access to the Internet to read.  As a
matter of fact, in my proposal, I bent over backwards to ensure that the
end format was a single file that had everything contained, in order to
prevent this.

I was instead considering what my *expectations* were for locked-down
production machines vs. my development box.

>Why do you think they're
>"unlimited distribution"?  I can access my TXT mirror from all our
>our development machines (I don't use rsync, but instead I'm manually
>piping all ietf-announce Mails to a perl download script on the machine
>where I read my Email and have internet connectivity).

I don't see the phrase "unlimited distribution" above; can you explain
more about what you think I said, please?

If you can access your TXT mirror from all of your machines, you can
continue to do so.  You can either download the text version the RFC
editor provides, or you can create it yourself from the HTML or XML,
perhaps at the time your perl script runs.  If you chose the latter, you
would only need the conversion tool on one box in your setup.

>And it does happen occasionally that the internet connectivity fails
>for several hours.  It would be quite unreasonalbe to create a work
>environment in my office where implementing RFCs was vitally dependent
>on internet connectivity being available.

Luckily, nobody has asked you to do so.  I've got similar personal
requirements, because I'm often reading RFCs on an airplane.

More information about the rfc-interest mailing list