[rfc-i] Pagination requirements

Peter Saint-Andre stpeter at stpeter.im
Thu May 24 11:04:45 PDT 2012


On 5/24/12 11:52 AM, Joe Touch wrote:
> 
> 
> On 5/24/2012 10:39 AM, Peter Saint-Andre wrote:
>> On 5/24/12 11:17 AM, Joe Touch wrote:
>>>
>>>
>>> On 5/24/2012 8:31 AM, Peter Saint-Andre wrote:
>>>> On 5/24/12 9:21 AM, Joe Touch wrote:
>>>>
>>>>> a usable printout is more important than a pretty phone display.
>>>>
>>>> Staying at the level of dueling opinions, I find it passing strange
>>>> that
>>>> the *Internet* Engineering Task Force would optimize for print. IMO the
>>>> ability to view our specifications on a myriad of devices connected to
>>>> the Internet is more important than a usable printout.
>>>>
>>>> Peter
>>>
>>> There are good reasons:
>>>
>>> a) specs and docs are still printed out
>>>
>>> b) I'm not claiming it's *more* important, but that we should be very
>>> careful about trading inconvenience on one device for inconvenience on
>>> another.
>>
>> That statement puzzles me a bit. Yes, I do print specs once in a while,
>> but especially since I was on the IESG and needed to read hundreds of
>> pages of specs every two weeks, I started to read online all the time
>> (and yes, sometimes even on my phone during IETF meetings to quickly
>> check a particular point in a spec while waiting in a hotel lobby). The
>> current canonical format is so unfriendly in those environments (even on
>> a "normal" laptop screen) that the inconvenience factor seems to me way
>> beyond what's acceptable. By constrast, I on those rare occasions when I
>> do print a spec, I can do so using the .txt version, the tools.ietf.org
>> HTML format, or a more native HTML format (xml2html output, W3C HTML
>> format, XSF HTML format) with no effective difference in print
>> quality... in my experience, naturally -- YMMD.
> 
> Why does this statement puzzle you?
> 
> *YOU* choose to read these on electronic devices.
> 
> *YOU* find the .txt hard to read on a laptop.
> 
> I don't know what source format you use, but I'm guessing not Word, so
> I'll assume either nroff or xml2rfc.
> 
> *I* choose to review them on printouts, esp. since it's a lot easier to
> jump back/forth between sections and make written comments as I go.
> 
> *I* read the current .txt format just fine on an iPad and on a laptop,
> as well as on a desktop.
> 
> *I* also edit using a WYSIWYG editor right now.
> 
> Right now, there's inconvenience for you on devices that are already
> limited. 

Every device has its limitations. If we think of paper as a device,
printing out ~25 specs before an IETF meeting (as I used to do) and
carrying those on the plane for review was also inconvenient.

> If we shift to HTML, there's inconvenience for me *on devices
> that are not inherently limited* - as an author during document
> creation, or printing out the HTML (until someone shows otherwise).

No one is saying we're going to pry the txt format from your cold dead
hands. :)  It might not be the canonical format eventually, but it would
continue to be produced as one of the output formats.

> It's clear that none of us is going to be completely satisfied with a
> single format. 

And we don't have to be.

> I hope that we can converge on a set of source formats
> that we're OK with, a canonical format that those can all generate, and
> a set of output formats that the RFC editor can generate that we're all
> OK with. That would be a step forward where there's LESS overall
> inconvenience.

Exactly.

> Any alternative that *trades* inconvenience - ESPECIALLY to support
> devices that are inherently limited anyway - is not a step forward.

There are tradeoffs with everything. Perfection is not an option.

If we are able to move to a model in which multiple output formats can
be produced, then we can vastly improve the experience for those who
aren't attached to printed words on "the paper device", while not
degrading the print experience since one of the output formats would be
exactly what we produce today (or some reasonable facsimile).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/




More information about the rfc-interest mailing list