Subject: RE: Process for Process Change (Was Diagrams ((Was RFCs should bedistributed in XML))

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 17 Nov 2005 13:39:35 -0800

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bob Braden

>   *>
>   *> P.S. Some good arguments have already been made on both 
> sides of the
>   *> ASCII art issue.  I, like many others, use Word, etc. 
> editors capable of
>   *> sophisticated graphics, and have to struggle to convert 
> to ASCII art in
>   *> I-Ds.  IMO this is a  ridiculous waste of time and loss 
> of information!
>   *> 
> 
> Ease for the author of a document has to be balanced against 
> convenience and universal access for its readers.

I find ASCII art diagrams utterly useless and never waste my time on
them.

I do not think that you really care about accessibility. If you did you
would understand why the idea of putting ASCII art through a text to
speech interface is utterly ridiculous. At least in HTML the voice
synthesizer knows that it has come to a diagram that it should not
attempt to interpret.

ASCII does not provide universal access and it is insulting to the
people who actually work on accessibility to make the claim.

If you mean YOUR convenience and YOUR access then please make that
point. 

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Nov 2005 16:51:12 -0500

>>>>> "Hallam-Baker," == Hallam-Baker, Phillip <[email-masked]> writes:

    Hallam-Baker,> I do not think that you really care about
    Hallam-Baker,> accessibility. If you did you would understand why
    Hallam-Baker,> the idea of putting ASCII art through a text to
    Hallam-Baker,> speech interface is utterly ridiculous. At least in
    Hallam-Baker,> HTML the voice synthesizer knows that it has come
    Hallam-Baker,> to a diagram that it should not attempt to
    Hallam-Baker,> interpret.

I actually can get some content out of ascii art diagrams.  Certainly
more than I could out of a gif or png and more than I would in
practice out of an svg.

I wouldn't mind though if the IETF went away from ascii diagrams
provided that they commit to guaranteeing that the normative text is
complete without the diagrams.  No, doing that is not as hard as some
people seem to think.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 17 Nov 2005 14:49:23 -0800

At 4:51 PM -0500 11/17/05, Sam Hartman wrote:
>I actually can get some content out of ascii art diagrams.

Oh, Sam, why ruin a perfectly good rant with real-life data?

>complete without the diagrams.  No, doing that is not as hard as some

Many ASCII-art diagrams *supplement*, rather than replace, prose 
descriptions. Given what many of us have seen in deployed 
implementations of IETF protocols, it is naive to assume that saying 
something in just one fashion is sufficient for it to be understood. 
In some WGs, when the ASCII art conflicts with the text above or 
below it, it leads to a useful discussion of how to fix the body text.

A good test for a document in mid-development would be "cover up the 
ASCII art and see if the body text is still understandable". The same 
would be true for documents where there is explanatory text and { 
ABNF | C code | Perl code | ASN.1 | ... }.

--Paul Hoffman, Director
--VPN Consortium

---

From: Lee Mahan <[email-masked]>
Date: Thu, 17 Nov 2005 15:22:58 -0800

I've been quiet through this discussion and its various offsprings, but 
now I just have to say very well done Paul.  It doesn't matter what you 
use for your diagrams if your prose is poorly written.

Paul Hoffman wrote:

> In some WGs, when the ASCII art conflicts with the text above or below 
> it, it leads to a useful discussion of how to fix the body text.
>
> would be true for documents where there is explanatory text and { ABNF 
> | C code | Perl code | ASN.1 | ... }.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Nov 2005 19:30:34 -0500

> use for your diagrams if your prose is poorly written.

Nor, really, does it matter if your prose is well written.  I think we
could save a lot off trouble here if we simply required that _all_ diagrams
be non-normative, and supported by prose (note, I'm not talking about
things like packet formats, tables of assigned numbers, or use of formal
languages -- just diagrams).  Then authors could include additional data,
diagrams, etc in whatever format seemed appropriate (perhaps the RFC
Editor could suggest a set of suitable formats).

A key point that no one seems to have brought up here is that RFC's are
an _archival_ document series.  The idea is that in a hundred or perhaps
a thousand years, it will still be possible to view them.  That suggests
that at least the normative parts should be represented in an archival
data format which will stand the test of time, rather than whatever the
latest fancy presentation format is.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 Nov 2005 17:45:36 -0500

On Thursday, November 17, 2005 07:30:34 PM -0500 Jeffrey Hutzelman 
<[email-masked]> wrote:

> Nor, really, does it matter if your prose is well written.

On reflection, it occurs to me that the above statement may be ambiguous.

Lee pointed out that if your prose is poor, the diagrams really don't 
matter much.

My point is that if your prose is good, the diagrams _also_ really don't 
matter much.

-- Jeff

---

From: [email-masked]
Date: Mon, 21 Nov 2005 09:54:27 +0100

Jeffrey Hutzelman wrote:

> My point is that if your prose is good, the diagrams _also_ really 
> don't matter much.

And this is a silly point in my opinion.
Most people can get a better idea of a solution when diagrams help them 
to do so. People who can do without may be bright and valued in the 
IETF, but we are writing specs for the outside world, not for us.

The IETF is probably the ONLY meaningful organisation in the world that 
insists on using ascii-only specifications. Any rationalization of that 
practise should try to explain why we are so exceptional before 
embarking on specious arguments on the relative merits of writing specs 
in morse code to improve design simplicity.
JM.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Nov 2005 07:05:14 -0800

At 9:54 AM +0100 11/21/05, [email-masked] wrote:
>The IETF is probably the ONLY meaningful organisation in the world 
>that insists on using ascii-only specifications. Any rationalization 
>of that practise should try to explain why we are so exceptional 
>before embarking on specious arguments on the relative merits of 
>writing specs in morse code to improve design simplicity.

We are so exceptional because all of our old standards can be 
implemented from as-is, without any possibly-lossy conversion. 
Standards organizations that used, for example, Microsoft Word 
version 2 for the PC, as their base document format, have had to 
convert their documents multiple times for current users to be able 
to read them. That conversion is sometime clean; often, it involves 
(lossy) humans reformatting text and pictures.

As others have pointed out on this thread, the ASCII art in IETF 
specs is (or should be) optional to implementers. The corollary is: 
why bother to go to a format that uses something other than ASCII 
art, if it is an optional component? Other than prettiness, what is 
the advantage for our intended audience of protocol developers?

This is not to say that all RFCs do just fine with ASCII art. We have 
non-standards documents, which we want the outside world to read, 
that look silly with the current formatting restrictions. We live 
with projecting that visual clumsiness, as geeks often do.

--Paul Hoffman, Director
--VPN Consortium

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 21 Nov 2005 17:30:01 +0100

At 16:05 21/11/2005, Paul Hoffman wrote:
>>that insists on using ascii-only specifications. Any 
>>rationalization of that practise should try to explain why we are 
>>so exceptional before embarking on specious arguments on the 
>>relative merits of writing specs in morse code to improve design simplicity.
>
>This is not to say that all RFCs do just fine with ASCII art. We 
>have non-standards documents, which we want the outside world to 
>read, that look silly with the current formatting restrictions. We 
>live with projecting that visual clumsiness, as geeks often do.

I understand this. But it restricts RFC to the sole English (ASCII) language.
Translating RFC as an authoritative text is therefore impossible.
jfc

---

From: Ole Jacobsen <[email-masked]>
Date: Mon, 21 Nov 2005 08:45:40 -0800 (PST)

Huh?

The ASCII *diagrams* have to be rendered in some other character set 
in order for them to be authoritative? I don't believe there is any 
requirement that the translated *text* be ASCII-only. 

Ole

---

From: [email-masked]
Date: Mon, 21 Nov 2005 18:03:29 +0100

On Nov 21, 2005, at 5:30 PM, JFC (Jefsey) Morfin wrote:

>>> The IETF is probably the ONLY meaningful organisation in the  
>>> world that insists on using ascii-only specifications. Any  
>> convert their documents multiple times for current users to be  
>> able to read them. That conversion is sometime clean; often, it  
>> involves (lossy) humans reformatting text and pictures.
>>
>> specs is (or should be) optional to implementers. The corollary  
>> is: why bother to go to a format that uses something other than  
>> ASCII art, if it is an optional component? Other than prettiness,  
>> what is the advantage for our intended audience of protocol  
>> developers?
>>

and crossing borders with multilanguage support  should be the most  
important approach.

just my 2 cents :-)

---

From: "Thomas Gal" <[email-masked]>
Date: Mon, 21 Nov 2005 10:11:27 -0800

> >non-standards documents, which we want the outside world to 
> read, that 
> >look silly with the current formatting restrictions. We live with 
> >projecting that visual clumsiness, as geeks often do.
> 

	Well there's a reason pilots and sailors and other people who's
business is truly international use english. We can't legitamately expect
technical issues to be drafted in every language (just like we can't expect
pilots to all know 5 languages) either. While I believe in the cultural and
intellectual value of different languages in exposing different viewpoints
and ways of thinking I don't believe there's anything technically oriented
that *can't* be expressed in english as well as any other language. It just
so happens that mostly english is the bridge that connects international
endevours, not that it's necessarily easiest (I believe they use french for
example in many UN docs because it's concise for example) it just happens to
be the one that people accept (much like for example internet standards!).
Nor do I have the personal motivation to translate a technical document to
hungarian or spanish though I could, because, fluent or not, that's still
REALLY hard and depending in any way on being technically colloquial in many
languages, and doing a good job at it.
	That's not to say that anyone won't welcome translations of
important documents, but perhaps that's a much better job for the UN then
the IETF.

-Tom

---

From: "Thomas Gal" <[email-masked]>
Date: Mon, 21 Nov 2005 10:35:52 -0800

> Translating RFC as an authoritative text is therefore impossible.

Interesting commentary on the subject
http://www.cs.tut.fi/~jkorpela/lingua-franca.html

-T

---

From: John C Klensin <[email-masked]>
Date: Mon, 21 Nov 2005 13:52:21 -0500

--On Monday, 21 November, 2005 10:11 -0800 Thomas Gal
<[email-masked]> wrote:

>> Translating RFC as an authoritative text is therefore
>> impossible. jfc
> 
> 	Well there's a reason pilots and sailors and other people
> who's business is truly international use english. We can't
> legitamately expect technical issues to be drafted in every
> language (just like we can't expect pilots to all know 5
> languages) either. While I believe in the cultural and
> intellectual value of different languages in exposing
> different viewpoints and ways of thinking I don't believe
> there's anything technically oriented that *can't* be
> expressed in english as well as any other language. It just so
>...
> Nor
> do I have the personal motivation to translate a technical
> document to hungarian or spanish though I could, because,
> fluent or not, that's still REALLY hard and depending in any
> way on being technically colloquial in many languages, and
> doing a good job at it.
> important documents, but perhaps that's a much better job for
> the UN then the IETF.

Tom, let me take this a step further.  Almost every other
international standards body, ISO and ITU included, end up with
an authoritative version in one language for technical standards
and then with translations that are considered less
authoritative.  I.e., if the translation disagrees with the
original authoritative version, the latter controls -- there is
no battle among translations as to which version is the most
accurate.  Even then, the best of the translations are validated
by the well-known, but difficult, time-consuming, and expensive,
process of having independent parties prepare back translations
to the original language, followed by a careful technical
comparison of the two.   For the most technical standards,
translation is typically waived because it is generally assumed
that, if one is going to get conformance and interoperability
--and be sure one knows what that means-- then there had best be
only one version, rather than standardized interpretations of it.

And the belief that any of this really has anything to do with
whether the base document is expressed in ASCII or not, or
whether its figures use ASCII artwork or images in some
conventional or standard form, is, to be polite, a stretch:
remember that ASCII is inadequate to express all of English
accurately.  To use your example because it is handy, while more
characters than those in ASCII are needed to properly write
Spanish or Hungarian (as with English), one cannot write any of
the three, or French, without those characters.  Things would
get much more interesting with Chinese, Japanese, or Arabic,
but, again, the form in which figures are expressed is the least
of the issues.

   john

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 22 Nov 2005 04:50:23 +0900

Thomas Gal wrote:

> pilots to all know 5 languages) either.

ASCII art is not in English.

ASCII art involves no translation issues.

We can use ASCII art anywhere in the world, just as we can use ASCII
based computer languages (such as C) anywhere in the world.

Remember that trigraphs are not used.

							Masataka Ohta

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Nov 2005 15:03:38 -0800

> relative merits of writing specs in morse code to improve design  

I have various documents more than twenty years old that used the  
popular word processors of the day to introduce graphs and charts.   
With perhaps the exception of nroff, few of these documents can be  
recovered due to the obsolescence of the word processor.  At times,  
printing a page involves recreating an obsolete operating system's  
font libraries.  Not everyone has adopted the use of a graphical  
outputs, but use simply ASCII as sometimes afforded portable  
devices.  While perhaps future graphical renderings will adopt  
persistent conventions, but will the application that generates the  
output still be available?

-Doug

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 21 Nov 2005 17:23:07 -0600

Not replying to anyone in particular, but this thread does seem to be 
cycling...

Thanks,

Spencer

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 22 Nov 2005 09:16:41 +0100

Another couple of references to thinking about language, these in more 
fictionalized forms:

- "The Languages of Pao" by Jack Vance (look it up on Wikipedia)
- "The Player of Games" by Iain M. Banks
- "Brightness Reef" and the succeeding volumes in David Brin's "Uplift 
Storm" trilogy

The nice thing about SF is that for a given theory, you can create an 
universe in which that theory is true, and investigate the consequences of 
that theory.... you don't have to waste cycles on considering that it might 
not, after all, be true....

---

From: [email-masked]
Date: Tue, 22 Nov 2005 11:26:37 +0100

> output still be available?

This issue of formats is a non-issue for a sizeable organisation like 
the IETF. It is always possible to migrate endangered formats to more 
modern versions using the many translation tools available, it just may 
cost a bit of manpower/money if done in due time, and more if done 
later. Many other organisations already do so, why would the IETF be 
exceptional there ?
And even then, 20 years ago you could use PostScript documents that are 
perfectly readable today, just like I expect PDF to stay for a very long 
time, at least as a readable format.

JM.

---

From: Ted Faber <[email-masked]>
Date: Tue, 22 Nov 2005 10:26:11 -0800

> Not replying to anyone in particular, but this thread does seem to be 

Yeah, with a period of about 6 months.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 23 Nov 2005 12:19:54 +0100

On Mon, Nov 21, 2005 at 09:54:27AM +0100,
 [email-masked] <[email-masked]> wrote 

> of that practise should try to explain why we are so exceptional

IETF is special (may be not "exceptional") in many respects and,
personally, I would appreciate is stays special:

1) IETF output (the RFCs) can be freely retrieved, distributed and
used. Only the W3C and Oasis are better on that respect. It means that
the RFC format has to be readable by many people, not all of them
being ready to pay (in money or in RAM upgrades) to get the latest
gizmo.

2) IETF emphasises readability of its documents. RFC are meaned to be
read and understood by normal people. This is in contrast with ITU or
ANSI documents. They don't need a standard format because nobody
actually use their documents, anyway.

3) IETF attendance is quite open (here, IETF is really
exceptional). So, its members are a wide and diverse community and it
is difficult to find a format which is both better than ASCII and
widely available.

So, saying "Everybody do it that way, we should, too" is ignoring many
IETF idiosyncrasies.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 23 Nov 2005 13:33:55 +0100

>So, saying "Everybody do it that way, we should, too" is ignoring many

Full agreement.

>3) IETF attendance is quite open (here, IETF is really exceptional). 
>So, its members are a wide and diverse community and it is difficult 
>to find a format which is both better than ASCII and widely available.

This is here where however we have a real practical problem. Only 
standards and procedures written in English can be authoritative and 
Drafts needs to be designed using the ASCII charsets. This is 
acceptable when only English speaking engineers and reading users are 
concerned. This represents less than 1/4 of the world population. As 
long as the IETF addressed pure Internet technology, it was unlikely 
this would be a problem - and after all an ASCII technology can 
legitimately only documented in ASCII. This is not anymore the case 
with the increase of societal aspects in the digital ecosystem 
convergence and with multilingual issues.

The BCP 49 update the IESG has approved, and I oppose in its current 
form for that reason, creates and is unable to address that 
difficulty. As a BCP it is supposed to document practices which - by 
essence - can be increasingly authoritatively multilaterally 
documented in the concerned languages (the translation is not from an 
authoritative English text to another language, but from another 
language authoritative text to ASCII English). RFC 3066 bis engages 
the IETF in having to be unilaterally authoritative in areas where it 
has no internal expertise (and therefore no cross-expertise), no 
adequate tools and procedures and no proper resources (IANA is not 
multilingual - or even internationalized).

This is why after more drastic initial suggestions, I found the sole 
(IMHO) possible consensual technical proposition: it is to simply 
include in RFC 3066 bis a hook (two lines of additional texte) to the 
RFC 4151 format (URI-tags). This way, ASCII (and proposed RFC 3066 
constrained format) stays authoritative by default, but an external 
tagging system or procedure (whatever the script) can be 
authoritatively referred to in an RFC, an XML page or through a 
library entry, in using ASCII characters. Obviously, upgrading RFC 
4151 towards full IRI-tags support would be better. This approach 
does not address everything, but it addresses most 
(including  protection of the users against simple 
racial/cultural/religious profiling meta-spam [searches in Google 
through language tags the author might ignore (RFC 3066 bis Security 
considerations) em] and language identification encryption).

Otherwise, after being quite open, as you mention it, the IETF will 
become exceptional in our world of increasingly protected and 
respected cultural diversity, as being culturally/societally 
exclusive and the authoritative reference (language IANA registry) of 
that exclusion. I doubt this is the intent, however this is/would be 
the practice.

jfc

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 23 Nov 2005 06:08:59 -0800 (PST)

You can not have two authoritative texts. Yes I understand that it may
happen (probably already did) that RFC text is translation from original 
written in another language. The reason it got translated however is so 
that it could be checked on and commented by IETF community and so that
it could go through IETF process for publication and the reason English 
is used is that IETF participants that review documents read English.

That English text then becomes authoritative because it had gone through 
entire review process where as text in another language would not have
been commented on (its not only substance but sometimes actual words
in text that is important in standard documents). The original in another 
language after publication can then be considered author's own personal 
translation to that language, which is although very helpful for those 
speaking that language, could not be considered authoritative because 
text has not gone through full IETF review.

The best that could be made with your ideas is possibly to ask rfc-editor 
to maintain list & links to unofficial translations for RFCs when existence
of such translations is reported to them as well as info on unofficial 
text of the RFC in some other format (i.e. XML). I think in such a case 
RFC editor should maintain only a link to external site (author or 
translator's own site) to emphasize the unofficial nature of such texts, 
but doing it as "caching copy" (like google does for pages) maybe ok too 
just so its available if link can not be reached, All this would require 
effort (for programming and for maintenance) and probably needs certain 
amount of agreement and desire from IETF participants to make it happen.

And as far as extra links for diagrams (for those with other languages)
if somebody creates a translation, his text can obviously use different 
link for language-specific diagram (and so can XML source or HTML text
of the document to the picture that can be used in place of ASCII art)
and to me it seems the right way to go about it.

On Wed, 23 Nov 2005, JFC (Jefsey) Morfin wrote:

>> 3) IETF attendance is quite open (here, IETF is really exceptional). So, 
>> its members are a wide and diverse community and it is difficult to find a 
>> format which is both better than ASCII and widely available.
>
> This is here where however we have a real practical problem. Only standards 
> and procedures written in English can be authoritative and Drafts needs to 
> be designed using the ASCII charsets. This is acceptable when only English 
> speaking engineers and reading users are concerned. This represents less 
> than 1/4 of the world population. As long as the IETF addressed pure 
> Internet technology, it was unlikely this would be a problem - and after all 
> an ASCII technology can legitimately only documented in ASCII. This is not 
> anymore the case with the increase of societal aspects in the digital 
> ecosystem convergence and with multilingual issues.
>
> The BCP 49 update the IESG has approved, and I oppose in its current form 
> for that reason, creates and is unable to address that difficulty. As a BCP 
> it is supposed to document practices which - by essence - can be 
> increasingly authoritatively multilaterally documented in the concerned 
> languages (the translation is not from an authoritative English text to 
> another language, but from another language authoritative text to ASCII 
> English). RFC 3066 bis engages the IETF in having to be unilaterally 
> authoritative in areas where it has no internal expertise (and therefore no 
> cross-expertise), no adequate tools and procedures and no proper resources 
> (IANA is not multilingual - or even internationalized).
>
> This is why after more drastic initial suggestions, I found the sole (IMHO) 
> possible consensual technical proposition: it is to simply include in RFC 
> 3066 bis a hook (two lines of additional texte) to the RFC 4151 format 
> (URI-tags). This way, ASCII (and proposed RFC 3066 constrained format) stays 
> authoritative by default, but an external tagging system or procedure 
> (whatever the script) can be authoritatively referred to in an RFC, an XML 
> page or through a library entry, in using ASCII characters. Obviously, 
> upgrading RFC 4151 towards full IRI-tags support would be better. This 
> approach does not address everything, but it addresses most (including 
> protection of the users against simple racial/cultural/religious profiling 
> meta-spam [searches in Google through language tags the author might ignore 
> (RFC 3066 bis Security considerations) em] and language identification 
> encryption).
>
> Otherwise, after being quite open, as you mention it, the IETF will become 
> exceptional in our world of increasingly protected and respected cultural 
> diversity, as being culturally/societally exclusive and the authoritative 
> reference (language IANA registry) of that exclusion. I doubt this is the 
> intent, however this is/would be the practice.
>
> jfc