Subject: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 15 Jun 2006 10:13:22 +0200

On Wed, Jun 14, 2006 at 10:56:03AM -0400,
 The IESG <[email-masked]> wrote 
 a message of 18 lines which said:

> - 'Proposed Experiment: Normative Format in Addition to ASCII Text '
>    <draft-ash-alt-formats-02.txt> as an Experimental RFC

This draft is a bad answer to a very real and important problem. I
agree with many of the nagtive remarks done on the IETF mailing list.

But I want to add one: authorizing an *output* format without the
corresponding *input* format (the "source") would be a very dangerous
step away from open formats. Because it would mean a great difficulty,
should we need to modify the RFC for a future version. Even a simple
bug fix would be difficult.

IMHO, IETF should always publish the "source" of its documents (the
current RFC process is far from perfect in that respect).

BTW, the draft completely fails to mention that there are text formats
which are better than ordinary raw ASCII and able to be automatically
translated to a nice rendering (typical candidates are LaTeX for
equations and Graphviz for state machines).

In short: no.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 15 Jun 2006 18:05:21 +0200

> This draft is a bad answer to a very real and important problem. 

We are willing to entertain constructive comments as to a good answer.

> But I want to add one: authorizing an *output* format without the
corresponding *input* format (the "source") 
> would be a very dangerous step away from open formats. 

We were forced into specifying ONLY an output format by comments on THIS
LIST.
We originally tried specifying OpenDocument, various commercial
word-processors, etc.

> BTW, the draft completely fails to mention that there are text formats
which are better than ordinary raw ASCII 
> and able to be automatically translated to a nice rendering (typical
candidates are LaTeX for equations and Graphviz for state machines).

I personally an a TeX-adict. If the IETF would adopt TeX input as
normative
then we could accomplish all that we want - great looking equations,
decent graphics, etc.
And we could easily generate PDF.

Of course, this would eliminate the need for XML notation and tools 
as there are TeX packages that are much simpler to use than XML2RFC.
So I guess there is even less chance of getting that idea off the
runway.

Y(J)S

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 Jun 2006 09:01:22 -0700

Stephane Bortzmeyer wrote:
...
> current RFC process is far from perfect in that respect).

Which source (XML2RFC is only one; some use troff, and others use Word,
among others)? Why would inter-source conversion be more useful than
cut-and-paste?

Joe

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 15 Jun 2006 14:11:59 -0400

One of the persistent problem today is that "bis" drafts are harder to 
write than they should be. Rather than being able to work from the final 
source, there are often only almost-final, pre-RFC-editor versions in 
XML (or Word), where one then has to make sure that no late-stage 
changes are being missed. It can be done, but its tedious. (Even access 
to the pre-final versions relies on individuals keeping old files 
around.) Having a more organized and documented source management 
mechanism in place would help.

Joe Touch wrote:
> ------------------------------------------------------------------------
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 16 Jun 2006 09:22:33 +0200

On Thu, Jun 15, 2006 at 09:01:22AM -0700,
 Joe Touch <[email-masked]> wrote 
 a message of 34 lines which said:

> > IMHO, IETF should always publish the "source" of its documents
> > (the current RFC process is far from perfect in that respect).
> 
> Which source

The source. The author certainly knows it (yes, I'm aware that the RFC
editor performs changes which are not backported in the author's copy,
a really annoying thing; that's why I said the current process is
bad).

> (XML2RFC is only one; some use troff, and others use Word, among
> others)

Sure. This is not a problem for me. I just want to see the source, as
the author saw it. 

> Why would inter-source conversion be more useful than cut-and-paste?

I don't have experience with MS-Word but (re)generating the RFC 2629
source from the ASCII version is a big pain (while there are automatic
converters, for instance from *roff to XML and, of course, from one
XML to the other).

---

From: Bill Fenner <[email-masked]>
Date: Fri, 16 Jun 2006 05:11:42 -0700

>Having a more organized and documented source management 

While I agree with your and Stephane's points, I think that's
a seperate discussion to have.

  Bill

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Jun 2006 09:10:07 -0700

> a really annoying thing; that's why I said the current process is

That's part of the problem. The other is that 'source' is useful only
with a snapshot of the tools that are used to process it. XML2RFC is a
moving target in that regard, as is Word.

...
> converters, for instance from *roff to XML and, of course, from one

In Word it's fairly simple to paste, remove the leftside indent, and
rewrap the paragraphs quickly. Setting heading types, lists, and figures
can be automated with scripts, but I haven't bothered to do that; it's
sufficiently quick to do that manually, IMO.

I have heard there are tools to back-port output to XML or nroff
approximations which, like Word paste, often need manual adjusting, but
haven't used them myself.

Joe

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Jun 2006 20:45:40 +0200

> moving target in that regard, as is Word.

Re XML2RFC: why do you need a snapshot if future development produces 
versions that continue to implement the semantics defined in RFC2629?

Best regards, Julian

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Jun 2006 13:45:09 -0700

Julian Reschke wrote:
>>>  Joe Touch <[email-masked]> wrote  a message of 34 lines which said:
>>>

It doesn't use 2329; it extends it based on its unofficial successor
(see the web pages).

Joe

---

From: Julian Reschke <[email-masked]>
Date: Sat, 17 Jun 2006 11:12:16 +0200

> It doesn't use 2329; it extends it based on its unofficial successor

Yes, but:

1) If there'd be a decision to officially use rfc2629bis for document 
production, we certainly would revise rfc2629 first, so the extensions 
then would be sufficiently described in an RFC, and

2) how's that relevant for the initial question? As long as future 
versions of xml2rfc are compatible with the one you used, why would you 
*need* to keep a snapshot of an old version?

Best regards, Julian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 17 Jun 2006 06:30:03 -0500

Just to explain why I'm agreeing here...

> then would be sufficiently described in an RFC, and

(Because the XML2RFC community is not excessively perverse - see following 
point where their lack of perversity also matters)

> *need* to keep a snapshot of an old version?

Without reference to any other point that has been made in this thread or 
its predecessors, I have to say that the idea of the XML2RFC tool breaking 
compatbility with RFC2629/RFC2629bis is simply amazing.

Please see the last three letters of "XML2RFC" to better understand why I 
think this is less likely than me winning the lottery. In an jurisdiction 
that doesn't have a lottery. And blocks access to Internet lottery sites. 
Given that I don't buy lottery tickets.

And, if the XML2RFC community lost its collective mind, it would not be 
beyond the realm of possibilities that we might ask for a translator to be 
produced before adopting the new and even more wonderful XML2RFC, and that 
this community (which includes RFC authors who just MIGHT have 
RFC2629/RFC2629bis input files they don't want to cut-and-paste themselves) 
might even think of this on their own.

XML2RFC is "a moving target", but we could have a lot of influence on where 
this target moves, and when, and whether there's still a target in the same 
place as last year, after "moving".

Sheesh. Can we go back to discussing appeals about appeals again? Even that 
was more productive.

Spencer

p.s. I didn't start using XML2RFC the first day the tool existed, but I have 
been using it since the late 1990s, when it was not much/any easier to use 
than nroff. It's not perfect now, but it's gotten a lot better, especially 
on providing line numbers where processing failed (this used to be a real 
gamble) for diagnostics.

If we could decide on using XML input (as opposed to ASCII output from XML 
input), XML2RFC would probably work even better. The most recent 
frustrations *I've* been having were about combining formatting and 
verification/enforcement - for example, the standard tool doesn't produce an 
output at all, if you have more than five authors listed, and if someone 
manages to create a document with a section called "Security Consideration", 
that's also a fatal error (because it's not "Security Considerations", 
plural). If we could make a decision about using this tool as a part of the 
process, it would make sense to bitch about stuff like this, but if the tool 
is only one way of producing ASCII text, why bother?

And yet I use XML2RFC to this very day. I must be nuts.

---

From: Joe Touch <[email-masked]>
Date: Sat, 17 Jun 2006 13:58:14 -0700

> *need* to keep a snapshot of an old version?

As long as future versions are backward compatible with all past
versions, that's fine. That has not been my impression of xml2rfc over
the small window I tried to use it.

Joe

---

From: Julian Reschke <[email-masked]>
Date: Sat, 17 Jun 2006 23:03:12 +0200

> the small window I tried to use it.

I guess that depends on the expectation. RFC2629 defines semantical 
markup. If your expectation is that a given input document will produce 
*identical* ASCII output over time, then yes, you may experience 
incompatibilities.

As far as I am concerned, that's fine, as long as the meaning of the 
source is not distorted (of course that's the reason one should stay 
away from "features" for presentation, such as <vspace>).

Best regards, Julian

---

From: Joe Touch <[email-masked]>
Date: Sat, 17 Jun 2006 21:40:06 -0700

> *identical* ASCII output over time, then yes, you may experience

That's a problem when it changes page numbers (which end up being as
useful as semantic tags) or figures. Or (as importantly) template or
boilerplate text.

Joe

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 18 Jun 2006 00:03:14 -0500

Well, we agree on some things :-)

From: "Joe Touch" <[email-masked]>
Sent: Saturday, June 17, 2006 11:40 PM

>useful as semantic tags) or figures. Or (as importantly) template or

(a) I see changing page numbers as pretty darned inconsequential, because 
it's just as easy to reference section numbers (and certainly works better 
when one suspects that all of the readers are cheating, and looking up the 
references in HTML versions that don't have page numbers anyway, but ignore 
that for now)

(b) template and boilerplate changes are pretty darned CONsequential. One 
obvious boilerplate item that needs to NOT change is IPR conformance 
statements, for example. There are likely others.

(c) I believe we are talking in good faith, and are both bright enough guys. 
I would love to have a meaningful and terminating discussion on requirements 
for XML2RFC backward compatibility, etc. but suspect this would work better 
if we were making a commitment to use XML2RFC as a normal part of our 
processes and procedures (so we also have "skin in the game"). I wonder how 
best to move forward on this stuff (as much fun as chattering on the IETF 
list has proven to be).

Thanks,

Spencer

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 18 Jun 2006 16:02:43 -0700

On Jun 15, 2006, at 9:13 AM, Keith Moore wrote:

> PDF used to be a free (as in beer), well-documented, relatively  
> unencumbered, reasonably portable format.  Nowadays there are a  
> number of compatibility problems between generators and viewers,  
> which appear to be mostly due to Adobe's introduction of DRM to the  
> PDF format.

PDF has had many portability problems to do with fonts and licensing  
of fonts long before any DRM was introduced.

---

From: Robert Elz <[email-masked]>
Date: Mon, 19 Jun 2006 10:51:38 +0700

Date:        Sat, 17 Jun 2006 21:40:06 -0700
    From:        Joe Touch <[email-masked]>
    Message-ID:  <[email-masked]>

  | That's a problem when it changes page numbers (which end up being as
  | useful as semantic tags) or figures. Or (as importantly) template or
  | boilerplate text.

That's only true if the purpose of re-processing is to make the original
document again for some reason - which would only be useful if the
formatted version were not to be archived, but only the source, and I
don't believe anyone is suggesting that.

Archiving the source is useful for people who want to make revisions
 - certainly that is possible without the source, and for some source formats
and some later editors, ignoring the source and using the formatted
version might even be preferable - but not always, for many, having the
source available makes things much easier.

If you accept that the purpose of archiving the source is to ease the
production of a revised document, and not to reproduce the original unchanged,
then whether or not the formatting tool would produce the original,
unchanged, is completely irrelevant.

I'm not entirely sure what any of this has to do with the question of
allowing non-ascii normative formats, but it seems to be what this
discussion has turned into, so ...

kre

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 Jun 2006 07:17:51 -0700

...
> unchanged, is completely irrelevant.

Sure - but if I cite an I-D, and have only the name of the I-D in the
XML source, but all the references' details are in the xml2rfc support
files, I need to archive them.

Those files change as I-Ds come out. While I can enter that info into
the doc, most people do not.

And I'm worried about changes to XML that render the result
uncompilable, not minor text formatting changes. See the changes to 2629
(sometimes referred to as 2629bis, although no I-D has been issued - and
we're currently using this 'bis' version) noted on the xml2rfc pages.
What happens when a real 'bis' WG is created? will the current changes
be supported into the future or not?

Joe

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Jun 2006 16:30:57 +0200

> files, I need to archive them.

Correct. That's one of the reasons not to do that (that is, copy the 
reference into the document).

> the doc, most people do not.

Correct. We need to educate them. For instance, once we get there the 
RFC Editor could refuse to accept documents like these.

> be supported into the future or not?

Do you have any evidence of non-backwards compatible changes that 
occurred in the past?

Best regards, Julian

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 Jun 2006 07:45:29 -0700

...
> Do you have any evidence of non-backwards compatible changes that

As I noted off-list, I had this experience, but didn't bother saving the
failed file; that was the 'straw' that shifted me over to revising the
Word template, and I didn't save the failed version (unfortunately).

Joe

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Jun 2006 16:53:19 +0200

> Word template, and I didn't save the failed version (unfortunately).

Well, maybe what you saw actually was a bug fix.

xml2rfc is using an embedded "almost XML" parser, which of course is 
asking for trouble. I recommend to run all input through a validating 
*conforming* XML parser first.

Best regards, Julian