Subject: Baby Steps (was RE: Alternative formats for IDs)

From: "Ash, Gerald R \(Jerry\)" <[email-masked]>
Date: Thu, 5 Jan 2006 08:25:51 -0600

Happy New Year to all!

Many thanks to Yaakov for his excellent handling of the list discussion.  I'm not very surprised with the way it has gone.  Déjà vu all over again :-)

The challenge is to focus the discussion to try to reach consensus on moving forward with a process change, i.e., we need to take baby steps to make progress.

I'd suggest we try to reach consensus first on the following:
Alternative format(s) for IDs, in addition to ASCII text, should be allowed.  

One requirement/motivation for this change (as set forth in the ID) is to be able to include drawings and diagrams with something much more flexible than ASCII art.

Based on the prior discussion of 'ASCII art', and the current discussion, I see few people arguing that ASCII text is all we need and that no other formats should ever be allowed.

Let's set aside for now which format(s), and take that as a later step if we can take this first step.

Thanks,
Regards,
Jerry 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Sunday, January 01, 2006 12:37 AM
To: [email-masked]
Subject: Alternative formats for IDs

Happy new year to everyone.
 
I would like to call your attention to a new ID
http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt.
 
This ID is the result of discussions here on the general list,
and proposes the use of formats other than plain ASCII
for IDs and RFCs. In particular, it proposes the allowance
of diagrams other than "ASCII-art" as normative.
 
The authors felt that further discussion on the list would not be productive, 
but that the writing of an ID might force more serious consideration.
We furthermore suggest that this ID be advanced as a BCP
under the process for process change.
 
Y(J)S

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

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 5 Jan 2006 10:52:48 -0500

On Jan 5, 2006, at 09:25, Ash, Gerald R ((Jerry)) wrote:
> One requirement/motivation for this change (as set forth in the ID)  
> is to be able to include drawings and diagrams with something much  
> more flexible than ASCII art.
>
> Based on the prior discussion of 'ASCII art', and the current  
> discussion, I see few people arguing that ASCII text is all we need  
> and that no other formats should ever be allowed.
>

Splitting the question this way paves the way for those pushing for  
alternative formats to frame the next question as, "Which alternative  
format are we going to allow?", as if it's already decided that we're  
going to allow *some* alternative and just have to find the best, or  
at least the least objectionable, even if there aren't any that  
fulfill the IETF's overall needs as well as plain ASCII text.  If you  
add the qualifier, "if they meet our requirements" ("... better than  
plain ASCII text"?), then I doubt you'll get much disagreement with  
that statement, though you'll probably get a lot of discussion about  
how we don't yet *have* a specific list of requirements.  As Brian's  
brown paper bag note suggests, we should start there, not with the  
assumption that we *will* allow some alternate format....

Personally, I'm skeptical that we'll find an alternative that meets  
our requirements as well, but perhaps we'll wind up with plain UTF-8  
text or something.

Ken

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Jan 2006 11:28:14 -0500

--On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R
\\(Jerry\\)" <[email-masked]> wrote:

> Happy New Year to all!
> 
> Many thanks to Yaakov for his excellent handling of the list
> discussion.  I'm not very surprised with the way it has gone.
> Déjà vu all over again :-)
> 
> The challenge is to focus the discussion to try to reach
> consensus on moving forward with a process change, i.e., we
> need to take baby steps to make progress.
> 
> One requirement/motivation for this change (as set forth in
> the ID) is to be able to include drawings and diagrams with
> something much more flexible than ASCII art.
> 
> discussion, I see few people arguing that ASCII text is all we
> need and that no other formats should ever be allowed.

Even those of us who are strongly supportive of ASCII as our
primary base format and those who believe that the effort needed
to simplify illustrations and diagrams sufficiently that they
can be accurately represented in ASCII artwork is helpful in
forcing clarity are reluctant to say "never".

> Let's set aside for now which format(s), and take that as a
> later step if we can take this first step.

Jerry, one of the nice things about baby steps is that you
sometimes discover that the baby learned to take the steps
without any instruction.

Unless the IESG has changed the rules while I was not looking,
it has been permitted to post I-Ds in PDF in addition to ASCII
for some years. I find it interesting that it has not been taken
advantage of more often (and, for the record, I'm one of those
who has taken advantage of it).  When it has been done for
artwork purposes, the artwork in the ASCII version has sometimes
been pretty rudimentary.   In practice, whether it is "good
enough" has been made on a case by case basis by WG Chairs and
WGs or, for non-WG documents, by whether or not the relevant
people are willing to read and consider those documents.
Similarly, when PDF has been posted in order to exhibit
non-ASCII characters, it has proven helpful to have Unicode
character offsets (i.e., U+nnnn representations)  in both the
ASCII and PDF forms to ensure complete precision even though the
character-glyphs themselves appear only in the PDF form.  

So, consider the first baby step to have been taken: nothing
prevents you from posting an I-D in both ASCII and PDF today,
and the relevant sub-community will sort out, on a case by case
basis, whether the ASCII is good enough.   If you do more of it,
perhaps we can move some of the interoperability problems into
the realm of actual IETF experience and out of the realm of
extrapolation from other situations mixed with pure speculation.

Free advice: if and when you want to move beyond that point,
drop (or isolate into separate documents):

	(1) Recommendations for IETF process change or specific
	ways to determine consensus.  They should be separate so
	they can be considered separately, using an appropriate
	process.

	(2) Distinguish clearly between what is required or
	tolerable for I-Ds and what is required or tolerable for
	RFCs.  RFCs, in general, put a less strong requirement
	on easy extraction and modification of text than I-Ds.
	And, since I-Ds in theory expire after six months, you
	might be able to convince the community that the "be
	sure it can be read twenty years later" requirement for
	archival documents should not be taken as seriously for
	I-Ds.
	
	(3) Recommendations to permit any format that is (i)
	proprietary, or (ii) dependent on particular software
	for processing where that software carries either high
	costs, onerous licensing requirements,  or licensing
	requirement that attempt to prohibit the development of
	independent tools to work with the format, or (iii)
	significantly operating-system dependent, or (iv)
	significantly version-dependent in the sense that the
	documents are not forward and backward compatible.

I would suggest to you that the fact that Word hits a jackpot by
satisfying all of the negative criteria in that third suggestion
is the reason why it has been regularly rejected for IETF
posting and working use in the past and is almost certain to be
rejected in the future.  If you want to consider that déjà vu
(or deja vu, for ASCII-readers), it certainly is in the sense
that we have been here before... but that rather misses the
point: it has been rejected in the past for substantial and
substantive reasons and the déjà vu situation, for me at
least, is that someone decides to bring it up again every few
years as if it had never been considered in the past.

regards,
    john

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 05 Jan 2006 16:49:37 +0000

> our requirements as well, but perhaps we'll wind up with plain UTF-8  
How would I encode graphics in UTF-8?

Stewart

---

From: Scott W Brim <[email-masked]>
Date: Thu, 05 Jan 2006 11:53:05 -0500

> for some years.

Yes.  I support ASCII as the output format.  I appreciate the
discipline it encourages of separating protocol specification from
descriptive text and figures, and of being very clear about state
machines, etc.  However, there are cases where descriptive text and
figures are much more informative in some other format, so I wouldn't
say never (nor should I be forced into a position of choosing between
never and always).

> I find it interesting that it has not been taken
> who has taken advantage of it).  

For heuristic value ... Do you think there is a correlation between
restricting ourselves to formats which are good for protocol
specifications but not much else, and the skew in our success record
toward problems solved by protocol specifications as opposed to the
really complex system problems? :-)

By the way, I like emacs picture mode.  You can bind the keypad keys
so that e.g. "3" means "draw toward the upper right".

swb

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 05 Jan 2006 17:01:16 +0000

>it has been permitted to post I-Ds in PDF in addition to ASCII
BUT the pdf is not allowed to be normative. Changing that rule alone would
be sufficient to allow modern graphics to be called up in normative texts.

>people are willing to read and consider those documents.
Please clarify this. Are you saying that if the WG/WGchairs/ADs agree 
that the non-ASCII
version should be the normative version (because they want the better 
artwork), then  that's
OK? I thought  I asked this a long time ago and was told no.

>basis, whether the ASCII is good enough.   
>
...and if it's not the pdf version of the text including graphics will 
become the RFC?

- Stewart

---

From: Sandy Wills <[email-masked]>
Date: Thu, 05 Jan 2006 12:25:17 -0500

> really complex system problems? :-)

Of course.

> so that e.g. "3" means "draw toward the upper right".

This seems intuituve and easy, if your normal input device is a
telephone keypad.  Otherwise, why choose this example?

-- 
Unable to locate coffee.
Operator halted.

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 5 Jan 2006 13:46:20 -0500

On Jan 5, 2006, at 11:49, Stewart Bryant wrote:
> Ken Raeburn wrote:
>> Personally, I'm skeptical that we'll find an alternative that  
>> meets  our requirements as well, but perhaps we'll wind up with  
>> plain UTF-8  text or something.
>>

Same as you do in ASCII now (i.e., poorly), but you get a few more  
characters to choose from. :-)

Ken

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Jan 2006 15:00:20 -0500

--On Thursday, 05 January, 2006 17:01 +0000 Stewart Bryant
<[email-masked]> wrote:

>...
>> artwork purposes, the artwork in the ASCII version has
>> sometimes been pretty rudimentary.   In practice, whether it
>> is "good enough" has been made on a case by case basis by WG
>> Chairs and WGs or, for non-WG documents, by whether or not
>> the relevant people are willing to read and consider those
>> documents.
 
> Please clarify this. Are you saying that if the
> WG/WGchairs/ADs agree that the non-ASCII
> version should be the normative version (because they want the
> better artwork), then  that's

No, I'm not saying that.  But the distinction I was trying to
make is pretty subtle.   The ASCII is the ASCII.  "Normative"
doesn't mean much for an I-D (see below for RFCs).  The rule
about PDF or Postscript versions is that they are supposed to be
equivalent to the ASCII (and vice versa).  But "equivalent" gets
a little subjective...

We know perfectly well that there are a few cases in which, no
matter what one does with ASCII art, it is not sufficient to
make whatever point is being made and supplemental text --more
description, in words, of what would be in the pictures-- will
not help much either.   Now, part of the point that the people
who have said "if you can't do it in ASCII art, you generally
shouldn't be doing it -- use the ASCII art and write a better
description" are making is that the cases in which we really
need fancy pictures are very few and that, except for those
cases, we are better off without them or at least being able to
treat them as strictly supplementary.

Before I go on, I continue to be fascinated by the observation
that, each time the "we really need pictures and fancy
formatting and need them frequently" argument comes up, the vast
majority of those who make it most strongly are people whose
contributions to the IETF -- in designer, editor, or other
leadership roles-- have been fairly minimal.  Now, of course,
some of them might argue that our current rules prevent them
from contributing and that, if only we would let them submit
documents written with the DeathRay word processor in Klingon
script, not only would their productivity rise, but everyone
else's would too --once we bought copies of DeathRay, learned
Klingon, and persuaded UTC to get the characters into Unicode.

However, that aside, assume that you are describing the new Mona
Lisa protocol, and that it is really impossible to adequately
describe the protocol without a high-resolution scale picture of
the Mona Lisa overlaid with your coordinate system.  The ASCII
form of your document could (and must under our current rules)
describe the coordinate system, include all of the measurements,
and describe what you are doing with them.  That text is
normative (and the important thing is "the text", not whether it
is in ASCII or not) and has to be.  But it is going to be _very_
hard for anyone to understand your protocol without seeing the
picture unless they have a good mental image of it.  

Under those conditions, our precedents are that you can probably
convince the WG/WGchairs/ADs, and eventually the RFC Editor,
that a PDF document containing a picture of the Mona Lisa and an
ASCII document with 

      _        -----
              /     \
      _       | o o |
              |  |  |
              | __  |
      _       |     |
              \_____/
      _
            |   |  |  |

as a substitute for that picture, with the marginal lines
roughly identifying your grid marks and coordinate system, is
"equivalent" or as close to it as one can get.  I would expect
that to be a hard sell.  I, personally, would _want_ it to be a
hard sell.  If it is really necessary, folks will figure out how
to get the picture (maybe only the picture, which will probably
not change from one version of the I-D to the next) to those who
can't handle the PDF (or Postscript).  But we have done it
before, all of the needed rules and procedures are in place, and
nothing new is needed other than your understanding that you are
going to have to get consensus that the artwork is vital before
making that great a departure between the ASCII and the PDF
versions.

>> ASCII and PDF forms to ensure complete precision even though
>> the character-glyphs themselves appear only in the PDF form.  
>> 
>> and the relevant sub-community will sort out, on a case by
>> case basis, whether the ASCII is good enough.   
>> 
> ...and if it's not the pdf version of the text including
> graphics will become the RFC?

No, they both become the RFC, and concerns about which one is
"normative" are just distractions.   For standards-track
documents, if it is posted as an official form of an RFC, it is
normative.   But, the more whatever-is-in-the-PDF differs from
whatever-is-in- the-ASCII --or, to put it differently, the more
the text depends on images that appear only in the PDF rather
than on the text standing alone or with ASCII art-- the harder
it is going to be for you to convince the community, the IESG,
and the RFC Editor that the PDF version is "equivalent" and, to
the extent to which it is obviously not equivalent, sufficiently
necessary to justify its posting.

    john

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 06 Jan 2006 13:39:32 +0100

We need to get out this ancients vs moderns dispute. Ancients saying 
they have no experience of actual need by moderns, and moderns saying 
this is because the ancient culture does not permit it.

Is there an objection to quote non-ascii documents hyperlinks? I suppose not.

Why not to just to proceed step by step and experiment? Let create an 
optional non-ascii art RFC-Editor repositories, for images quoted in 
RFCs. This will not permit non-ASCII art to be normative but will 
permit non-ASCII art to be _better_ descriptive in a first time. 
Experience will show if there are many such images. If there is a 
real need for normative non-ASCII art, it will provide experience to 
create a non-ASCII art IANA registry making sure they will survive, 
at an adeqate place.

jfc

---

From: Sam Hartman <[email-masked]>
Date: Fri, 06 Jan 2006 10:24:15 -0500

>>>>> "Ash," == Ash, Gerald R (Jerry) <[email-masked]> writes:

    Ash,> Happy New Year to all!  Many thanks to Yaakov for his
    Ash,> excellent handling of the list discussion.  I'm not very
    Ash,> surprised with the way it has gone.  Déjà vu all over
    Ash,> again :-)

    Ash,> The challenge is to focus the discussion to try to reach
    Ash,> consensus on moving forward with a process change, i.e., we
    Ash,> need to take baby steps to make progress.

    Ash,> I'd suggest we try to reach consensus first on the
    Ash,> following: Alternative format(s) for IDs, in addition to
    Ash,> ASCII text, should be allowed.

I'd like to propose something I hope is simpler to act on.

I'd like to get in the habit of asking people who propose process
changes that are hard to get consensus on to conduct RFC 3933
experiments.  So in this particular case please restructure your draft
as in experiment.  Find some working groups or authors who would
benefit.  Find some rfc editor staff and an AD who would be willing to
help you out.  Propose a time limit and let's see if the world comes
to an end if we publish a few documents that are not in ASCII.  I
suspect we'll all survive.

I think there are a lot of good reasons why we should do this.

The first is that as part of evaluating plausibility of experiments we
can make sure that the experiment could take place.  It seems
reasonable to require that those wanting to change the process spend
the effort to make their changes possible.  "Hey.  I've got these
people over in the PWE3 working group who would really like to have
better diagrams in their specifications.  The AD says he would be able
to review the diagrams and thinks it might be more clear.  The rfc
editor says they have time and would be willing to try publishing a
few specs with diagrams if the community thinks it is reasonable," is
a lot more compelling as a starting point than "I want the process to
change.  I'm going to write text to change the process and you should
all approve it."  If in trying to put together the experiment you find
that no one actually would take advantage of your process change or
you find that people along the way don't have time to do additional
work required by your proposed change, then perhaps that's not where
we should be spending our process change energy.

Second, a lot of objections (more so for other process changes than
for this one) fall into the category of "That will never work," or
"that will drown us all in additional paperwork."  The nice thing
about experiments is that they can be constructed so that
participation is optional and so that you have flow control at all
stages.  "Well, it will either work or not.  If it doesn't we will
delay a few documents or efforts that agreed to participate in the
experiment," is a more compelling response than "It will work fine!
I'm willing to risk the entire IETF process on it!"  Even if you are
absolutely sure it will work fine, what harm is there in starting out
slow?  Also, opt-in experiments are an excellent response to questions
about whether something is useful.  If you start out with enough
people who think it is to justify the IESG review cycle and
publication of an experimental RFC, then you have a strong response to
those who question utility: "We think it is useful; let us waste our
own time.  We will either be right or wrong."

Another good thing about experiments is that they often do get people
to become familiar with something and that tends to defuse a lot of
negative feelings steming from anxiety about change.  I certainly know
I've had strong negative reactions to things in the past and have
reluctantly agreed to try something.  Typically I find it is not
nearly as bad as I had feared.  Sometimes I find that I was completely
right but that I have significant evidence to point to now helping
others understand the problem.  I don't think I'm atypical in this
regard.

Finally, I'm hoping that we can build a culture of constructive
progress around experiments.  I think we have consensus that the IETF
needs to change and evolve.  Perhaps we can come to consensus that
experiments are a way we can make forward progress.  We may not all
like the experiments but perhaps e can decide that a culture in which
we've all agreed to constructively work towards conducting plausible
experiments is the best compromise we can come up with.  I'm hoping
that we can get to a point where it is culturally unacceptable to
object to plausible experiments without explaining what the proponents
of the experiment would need to do in order to get around the
objection.  I'm also hoping that we can get to a culture where the
response to a long flame war like this quickly becomes "Well, write it
up, convince the people whose work would be influenced to give it a
try and let's go for it."  There will still need to be a lot of
compromise; when people have concerns we will need to try and find
ways of collecting the data we need to evaluate the change.  We
probably want to establish a culture of conducting experiments anyway
even if we understand that there are some questions they will not
answer.  For example I think an experiment about alternative RFC
formats is valuable even though there is no way it will answer
questions about the archival value of things other than ASCII.  Still,
if we get to a point where that is the only open question we will have
made significant progress.

Now, there is one thing that people may not like about how I've tried
to define plausible.  I claim that the proponents of an experiment
need to convince people who would be doing work to join the
experiment.  Implicit in that is the idea that if you are going to
change how the IESG does things, you need to recruit an IESG member at
a minimum.  If you want to try a new way of running a working group,
you need to find a WG chair.  If you want the RFC editor to do
something different, you need to convince someone from their staff
that they should go along.  I think this is a fairly important
constraint because it prevents people from being over committed.  It
also provides somewhat of a selection criteria for experiments: we
work on the ones that attract interest at the right places.

One possible objection is that the IESG or other leadership could
starve out experiments.  I think it is fair to ask the IESG what
experiments it is working on and if the IESG is not spending time
supporting process change experiments to complain and demand
improvement.  It doesn't bother me that the IESG will end up being
able to focus energy on experiments that the IESG believes are most
beneficial/interesting.  That does sound like a management
responsibility that it is reasonable for the IESG to be involved in.
If you don't like the results you can try and convince the IESG to
change, you can give feedback to nomcom or in extreme cases you can
dust off that recall petition you've had sitting on your shelf.

So, a challenge.  Let's see if we can put together a plausible
experiment for this or some other topic that interests the community.
Let's see if we can get a well-oiled RFC 3933 process running and
let's go improve our organization while building a better Internet.