Subject: Re: Canonical RFC formatting

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 02 Feb 2011 00:21:34 -0500

--On Wednesday, January 26, 2011 10:29:54 AM -0800 Joe Touch 
<[email-masked]> wrote:

>
>
> On 1/26/2011 10:21 AM, Carsten Bormann wrote:
>> On Jan 26, 2011, at 18:38, Joe Touch wrote:
>>
>>> The tool could probably be modified to accept .xml and turn it into
>>> .txt, but that seems like a tool issue, not a "canonical formatting"
>>> issue.
>>
>> I don't think so, because then you wouldn't have submitted the legal
>> boilerplate.
>
> FWIW, that can be fixed on the confirmation page, where the text output
> including the legal boilerplate could appear and require positive
> confirmation.

That seems OK for a document like draft-arkko-dual-stack-extra-lite-03.txt, 
which one recent review described as "a very brief (8-page) document", or 
for a document like RFC347.

I worry, though, that the submission process might time out while the 
author verified correct compilation on a document like RFC5661.

More seriously, I also worry that the author is more likely to just click 
through such a confirmation, rather than actually verifying the correctness 
of the generated document.  Legal questions aside, this is a problem when 
the generated document is the one that will be considered "authoritative" 
if there is any discrepancy between versions.  Better IMHO to insist that 
the author submit the authoritative form, along with whatever alternates 
are desired.

FWIW, I completely agree with Joe Hildebrand on the question of moving to 
UTF-8 (which seems like a no-brainer), and on elimination of fixed page 
breaks.  Not so much on allowing 10000-character lines or generated HTML 
with 10x as much tags as content.

-- Jeff

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Feb 2011 22:35:14 -0800

Hi, Jeff,

On 2/1/2011 9:21 PM, Jeffrey Hutzelman wrote:
> That seems OK for a document like
> draft-arkko-dual-stack-extra-lite-03.txt, which one recent review
> described as "a very brief (8-page) document", or for a document like
> RFC347.
>

We have a two phase process right now. That can be part of it, i.e., you 
submit, it compiles off-line, then emails you only when it's ready to 
confirm.

> More seriously, I also worry that the author is more likely to just
> click through such a confirmation, rather than actually verifying the
> correctness of the generated document.

They do that now. People cut/paste without reading things. They generate 
the TXT without reading it either.

 > Legal questions aside, this is a
> problem when the generated document is the one that will be considered
> "authoritative" if there is any discrepancy between versions. Better
> IMHO to insist that the author submit the authoritative form, along with
> whatever alternates are desired.

I'm not sure what "authoritative" means for drafts. They're drafts, 
after all ;-) IMO, integrating the on-line version with the submission 
process just makes it easier for the author - they still can and do use 
automated tools - some online -- and they can and do submit txt that 
they haven't checked.

IMO, providing a one-stop submission process just makes it less obscure 
as a process. I see no reason we require the knowledge of magical 
incantations to submit a doc.

(I'd be all for .doc->.txt too, if I could figure out how to automate 
it, i.e., .doc->.prn->.txt, where the last step is the tool I wrote and 
*is* already online)

> FWIW, I completely agree with Joe Hildebrand on the question of moving
> to UTF-8 (which seems like a no-brainer), and on elimination of fixed
> page breaks. Not so much on allowing 10000-character lines or generated
> HTML with 10x as much tags as content.

I was involved in some of the UTF8 discussions of the past. My challenge is:

	- try to read the txt on a variety of currently common devices
	if most render UTF8 fine, then let's change things

The last time I checked, UTF8 didn't work in Windows; I just checked 
again with Win7: the default text reader - Wordpad - changes fonts 
mid-stream when it hits such chars, and Emacs doesn't work either.

I also just checked on an iPhone4 and an iPad, and it doesn't work there 
either.

I'm all for whatever new format works in most of the most common places, 
but knocking out Windows' default reader, an iPhone, and an iPad, and my 
conclusion remains that it's not ready for prime time.

We can continue that on rfc-interest. This isn't a new issue; I just 
wanted to give the current state of things.

Joe