Subject: Re: Call for Comment: "RFC Format Requirements and Future Development"

From: t.p. <[email-masked]>
Date: Fri, 1 Mar 2013 17:59:20 +0000

I think that this I-D has one hole in it but it is a massive one.  It
places no limit on the size to which an alternative format could expand
our documents.

I was reminded of this when I received a 514kbyte e-mail from another
SDO on an IETF list.  I saved the text and so lost the exact formatting
but none of the semantics or sense.  The result was 32kbyte, ie the
formatting used by another SDO had increased the size 16-fold, a 16-fold
increase in network traffic, a 16-fold increase in the storage needed
for as long as the document was stored.

Repeat this across the IETF's I-Ds and the ability to produce RFCs would
be substantially reduced.

There should be an immutable requirement that any alternative format
MUST NOT increase the size by more than a factor of two compared to
ASCII text.

Tom Petch

----- Original Message -----
From: "IAB Chair" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 01, 2013 7:53 PM
Subject: Call for Comment: "RFC Format Requirements and Future
Development"

This is an announcement of an IETF-wide Call for Comment on "RFC Format
Requirements and Future Development".

The document is being considered for publication as an Informational RFC
within the IAB stream, and is available for inspection here:
http://tools.ietf.org/html/draft-iab-rfcformatreq

The Call for Comment will last until February 29, 2013. Please send
comments to iab at iab.org or submit them via TRAC (see below). Please
also cc: [email-masked] (for membership info, see:
https://www.rfc-editor.org/mailman/listinfo/rfc-interest).
===============================================================
Submitting Comments via TRAC
1. To submit an issue in TRAC, you first need to login to the IAB site
on the tools server:
http://tools.ietf.org/wg/iab/trac/login

2. If you don't already have a login ID, you can obtain one by
navigating to this site:
http://trac.tools.ietf.org/newlogin

3. Once you have obtained an account, and have logged in, you can file
an issue by navigating to the ticket entry form:
http://trac.tools.ietf.org/wg/iab/trac/newticket

4. When opening an issue:
a. The Type: field should be set to "defect" for an issue with the
current document text, or "enhancement" for a proposed addition of
functionality (such as an additional requirement).
b. The Priority: field is set based on the severity of the Issue. For
example, editorial issues are typically "minor" or "trivial".
c. The Milestone: field should be set to milestone1 (useless, I know).
d. The Component: field should be set to the document you are filing the
issue on.
e. The Version: field should be set to "1.0".
f. The Severity: field should be set to based on the status of the
document (e.g. "In WG Last Call" for a document in IAB last call)
g. The Keywords: and CC: fields can be left blank unless inspiration
seizes you.
h. The Assign To: field is generally filled in with the email address of
the editor.

5. Typically it won't be necessary to enclose a file with the ticket,
but if you need to, select "I have files to attach to this ticket".

6. If you want to preview your Issue, click on the "Preview" button.
When you're ready to submit the issue, click on the "Create Ticket"
button.

7. If you want to update an issue, go to the "View Tickets" page:
http://trac.tools.ietf.org/wg/iab/trac/report/1

Click on the ticket # you want to update, and then modify the ticket
fields as required.

---

From: "John Levine" <[email-masked]>
Date: 1 Mar 2013 19:44:12 -0000

>MUST NOT increase the size by more than a factor of two compared to

So you're saying you're unalterably opposed to the RFC editor providing
PDF, HTML, epub, mobipocket, and every other format that people actually
use on modern computers, as well as anything that includes reasonably
legible images?

If that's not what you mean, what DO you mean?  We all seem to agree
that we want to continue to provide the traditional line printer image
format, but on today's Internet where 20Mb/sec cable modems aren't
particularly fast, it's silly to demand that documents be sized for
floppy disks.

R's,
John

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 1 Mar 2013 14:56:04 -0500 (EST)

> From: "t.p." <[email-masked]>
> 
> The result was 32kbyte, ie the

Certainly larger formats are less desirable than smaller formats.  But
since RFC 1000 (1987), the size of disk drives has increased over
1000-fold
(http://en.wikipedia.org/wiki/File:Hard_drive_capacity_over_time.png),
and communication speeds have also increased greatly.  So size
increases of a factor of 10 over periods of decades is unlikely to
reduce our ability to work.

Dale

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Mar 2013 12:58:40 -0800

> MUST NOT increase the size by more than a factor of two compared to

<tongue position="incheek">
Given Moore's law, would that change 18 months from now to an immutable requirement of a factor of four?
</tongue>

--Paul Hoffman

---

From: t.p. <[email-masked]>
Date: Sat, 2 Mar 2013 12:45:54 +0000

----- Original Message -----
From: "John Levine" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 01, 2013 7:44 PM

> use on modern computers, as well as anything that includes reasonably

I am opposed to the careless, thoughtless use of these formats which
causes a massive increase in the resources needed to do anything with
them; I quoted a 16-fold increase in one that came from another SDO but
I have seen 50-fold increases in ones from individuals.

Look under the covers and the markup being used in a way that seems
designed to maximise resource usage.  With *ML, there may be tens of
kilobytes of css which seems to a logical 'or' of anything used anytime
in an organisation; or code translation tables that make UCS seem small;
or applying markup that is no different to the default to each and every
paragraph such as

BORDER-RIGHT: medium none; BORDER-TOP: medium none; VERTICAL-ALIGN:
middle; BORDER-LEFT: medium none; CURSOR: pointer; COLOR: #FFFFFF;
BORDER-BOTTOM: medium none;
FONT-SIZE: 12px; FONT-FAMILY: Arial Unicode MS, san-serif

(The worst offenders seem to documents that have been converted from
MS-Word into something else).

Look at RFC and the XML that goes into it, and a ratio of two to one,
input to output text, is generous on any document of reasonable size.

It is harder to look inside a pdf and see why the same document can be
20kbyte or 100kbyte but I would appeark that a similar consideration
applies.

Impose no limit and you could get a 16-fold increase in the resources
needed.  Great for mobile phone operators and hardware manufacturers,
bad news for those who want to progress the work of the IETF.

Tom Petch

---

From: t.p. <[email-masked]>
Date: Sat, 2 Mar 2013 12:47:56 +0000

----- Original Message -----
From: "Dale R. Worley" <[email-masked]>
To: "t.p." <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, March 01, 2013 7:56 PM

> reduce our ability to work.

Agreed; I fear a 16-fold increase overnight if, for example, the archive
is converted to a format making inefficient use of a more sophisticated
markup..

Tom Petch

---

From: t.p. <[email-masked]>
Date: Sat, 2 Mar 2013 12:50:22 +0000

----- Original Message -----
From: "Paul Hoffman" <[email-masked]>
To: "t.p." <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "ietf" <[email-masked]>
Sent: Friday, March 01, 2013 8:58 PM
Subject: Re: Call for Comment: "RFC Format Requirements and Future
Development"

<tongue position="incheek">
Given Moore's law, would that change 18 months from now to an immutable
requirement of a factor of four?
</tongue>

<tp>
Something of the sort, yes; it is an overnight large increase that
careless users could so easily create which concerns me.

Tom Petch

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 4 Mar 2013 07:51:35 -0500

+1

As recently as ten years ago the third fastest supercomputer offered
12 Teraflops and 12Tb of storage. Today the same can be bought for
$6,000.

A Raspberry Pi casts $35 and has the same performance as the
workstation class of ten years ago.

Any proposal that says we should lock ourselves in to the technology
constraints of the valve tube era of computing is stupid.

There should be an immutable principle that people who want to
contribute to the cutting edge of technology have access to recent
software and reasonably up to date hardware and those that don't
bother have to take responsibility for their personal choices rather
than forcing the rest of us to adapt to their self-imposed
limitations.

On Fri, Mar 1, 2013 at 3:58 PM, Paul Hoffman <[email-masked]> wrote:
> _______________________________________________
> rfc-interest mailing list
> [email-masked]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

-- 
Website: http://hallambaker.com/

---

From: [email-masked] (Martin Rex)
Date: Tue, 5 Mar 2013 00:48:53 +0100 (CET)

John Levine wrote:
[ Charset UTF-8 unsupported, converting... ]
> use on modern computers, as well as anything that includes reasonably

I agree that a strict size limitation would interfere badly with
formats that include graphics.  But that doesn't mean that all graphics
are equal.  I'm aware of one notoriously stupid Office suite that
inserts truecolor BMP images by default, and it is actually difficult
to conceive a worse default behaviour...

> particularly fast, it's silly to demand that documents be sized for

While there might be cable modems with 20Mb/sec available to some,
this is far from being the common internet access bandwidth.
My 6MBit/s DSL subscription at home comes out as ~2MBit/s.  It used
to be close to 4MBit/s in early 2008, but there seems to have been
a rush in subscriptions over the past few years that impairs what I get.

I only get ~ 5-10 MBit/s net from my WLAN (8 neighboring WLANs competing).

For mobile devices, unless you're willing to pay a premium monthly fee,
the commonly available bandwidth seems to be more like 384kBit/s.

On my last vacation in Italy, the hotel offered a public WLAN
(no registration required), but the bandwidth was averaging around
300 KBit/s.

Limiting the waste of network bandwidth seems like a desirable goal,
no matter how I look at it, from the "waiting for download" perspective
as well as the environmental impact.

-Martin

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 Mar 2013 19:30:36 -0500

> as well as the environmental impact.

All that requires is the availability of a small file, not an overall
limitation on the size of files.  No?

A

-- 
Andrew Sullivan
[email-masked]

---

From: t.p. <[email-masked]>
Date: Tue, 5 Mar 2013 10:24:04 +0000

----- Original Message -----
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 05, 2013 12:30 AM
Subject: Re: Call for Comment: "RFC Format Requirements and Future
Development"

> limitation on the size of files.  No?

There is a parallel thread on the IETF list about the difficulty of
staffing the IETF which has contained references to how the IETF is
different, how we do not want to be like the ITU-T.

What prompted my comment is a wish for the technology of the IETF to
evolve, not to make a quantum leap to be like the technology of other
SDOs.  I assume that whatever we do with RFC, which is the subject of
the Call for Comment, will inevitably cascade into all I-Ds and even to
some extent into mailing lists.

The IETF has been conservative in its use of technology and I think that
that is part of its success.  If the entry point for participating in
the IETF were a 20MBit/s link to the desktop with the latest versions of
MS Office, Acrobat reader, Photoshop etc then we would be an
insignificant pimple on the back of other SDOs.

I quoted the example of a document from another SDO which was 16 times
larger than it would have been using IETF technology.  I have seen
individual documents that are even more expanded.  Look at where the
documents have been - MS Word is good at telling me that - and it is
from within large organisations, to whom the latest technology is likely
no barrier.

The other example I have quoted before is a WG mailing list discussion
where the e-mails in the thread went over one Mbyte in size each and
yes, there were commenting from perspective of another SDO.  Whether or
not the SDO's technology was being used I cannot tell but I am sure that
the e-mails reflected the common practice of that SDO.  The actual
text added in each successive post was a few hundred bytes, following
the conventions of the IETF would have made the e-mails a few thousand
bytes, but those with a background in another SDO has no concerns about
turning them into a Megabyte or more.  That is inconsiderate and
thoughtless.

That is why I believe that there must be a limit, to avoid a quantum
leap in the costs that will reduce or eliminate the ready availability
of the IETF to potential participants.

Tom Petch

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 5 Mar 2013 13:32:10 -0500 (EST)

Wouldn't it suffice to say "The IETF should not use a document format
if it is substantially bulkier than an alternative format that
satisfies substantially similar goals." and leave the details to the
RFC Editor?

Dale