Subject: RE: I-D file formats and internationalization

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 1 Dec 2005 14:19:53 -0800

> Behalf Of Tim Bray
> > Unfortunately,
> > most web browsers fail to preserve page breaks (FF characters) when 
> > printing flat text files, which makes the resulting 
> documents hard to 
> > read.
> 
> Turn this around; when printing HTML, the browser inserts 
> appropriate page breaks depending on the combination of font, 
> styling, and paper size that's in effect.  This has the 
> effect that when you're arguing about some text, you have to 
> say "Look at 5.2.1.3, 2nd para" rather than "Look at page 13, 
> 2nd para".  It's not clear that this is any better or worse.

This is actually a rediscovery of something the medieval scribes
discovered (and Tim almost certainly knows more on this than I do)

Early codex manuscripts (books with pages) have foliation, not
pagination. That is there is one number per sheet of paper rather than a
separate number for each side. The original purpose of the marks was
probably to assist the production of the books rather than allow
citations but there is some use of citations.

Once people started to use foliation for citations they started to see
the disadvantages. Editions of the bible were particularly problematic
once people started attempting to cross reference translations back to
the original text. This was a particular problem with the old testament
as some parts of the vulgate are actually translations of translations.
The solution was to refer to scripture by chapter and verse.

In HTML there are three separate options for creating citations. You can
use style sheet pagination if you must but citations will be extremely
fragile and can be broken by any edit to the text. You can also use
section.subsection etc references which are more robust. The best method
though is to label each section with a name. That allows citations to
survive from one version of the document to another even if sections are
added or deleted.

On a point of information, most of the references I see in existing RFCs
are to sections in any case.

    Phill

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

---

From: Keith Moore <[email-masked]>
Date: Thu, 1 Dec 2005 17:26:26 -0500

> The solution was to refer to scripture by chapter and verse.

By the time RFCs take on the significance of scripture (and are as
widely corrupted as scripture) I'm sure we'll all be using section
numbers :)

> fragile and can be broken by any edit to the text. 

Anyone who tries to use a page number from RFC 1342 to refer to text in
RFC 2047 deserves whatever he gets.

Keith

---

From: Robert Sayre <[email-masked]>
Date: Thu, 1 Dec 2005 17:38:04 -0500

> are to sections in any case.

I suspect this is because almost everyone refers to an HTML version in
informal communication. But, I actually agree with Keith that keeping
the format as a text file is the right thing to do. I agree with Tim
about internationalization and printing reality, but think UTF-8 text
files would be the best route.

I don't like the idea of using HTML, because it breaks up the document
and allows bitmap illustrations. I think Keith is spot-on when he says
the text format encourages clear thinking. In the WG I frequent, I've
found that the worst and most complicated ideas usually come with
elaborate illustrations.

Anyway, I'm still not clear on the what must-have software is
preventing the IETF from using UTF-8. My linux systems allow me to
write Thai and Katakana in vi. Guess it must be the printing. I
haven't owned a printer since 1998, so I find it hard understand why
some consider printing to be a frequent and important task.

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Keith Moore <[email-masked]>
Date: Thu, 1 Dec 2005 18:16:14 -0500

> the format as a text file is the right thing to do.

Actually I don't think that utf-8 plain text is the right thing to do.
I think we should stick with ASCII for now, as the benefits of UTF-8
_for our particular purposes_ aren't compelling enough, and the
the ability to read and print UTF-8 in the field is still significantly
worse than the ability to read and print ASCII.  

In a few years, perhaps, we should move to UTF-8, but by then I
suspect we'd be better off doing (M)HTML than plain text.   OS support
for plain text files seems to be getting worse over time rather than
better.  

Or maybe we'll just continue to have PDF versions of the RFCs but allow
them to contain non-Latin characters for authors' names.  (seems like
our current rules more or less let us do that already, and it would
just require an extension to xml2rfc to allow such names to be
specified and some changes to the document production toolchain to
permit them to be included in the PDF version)

Keith

---

From: John C Klensin <[email-masked]>
Date: Thu, 01 Dec 2005 18:50:34 -0500

(distro trimmed -- I assume everyone participating in this
interminable discussion is on the IETF list)

--On Thursday, 01 December, 2005 17:38 -0500 Robert Sayre
<[email-masked]> wrote:

>> On a point of information, most of the references I see in
>> existing RFCs are to sections in any case.
> 
> I suspect this is because almost everyone refers to an HTML
> version in informal communication.

Bad inference, I think.  We have had explicit guidelines (some,
I think, in various versions of "Instructions to RFC Authors")
that express a preference for section references.  There are
many ways to scan (visually) an RFC, or to find material in it
online using an ASCII text editor (think ED and its clones, not
just emacs/vi), that make section numbers much easier to find
than page numbers and paragraphs.  Section numbers are related
to actual content and context, which is usually what people are
trying to reference.

I think that, if you went back to archives old enough that there
was no HTML alternative because there was no HTML, you would
still find that the overwhelming number of references into RFCs,
informal and formal, used page numbers.

    john

---

From: Tim Bray <[email-masked]>
Date: Thu, 01 Dec 2005 17:44:14 -0800

On Dec 1, 2005, at 3:16 PM, Keith Moore wrote:

>  the

That assertion could use a little empirical backing.  Empirically,  
there are people who find the ASCII versions easier to deal with; you  
are one.  Empirically, there are those who simply do not observe  
problems with UTF-8; I am one.  I could say "There are more like me  
than like you" and while I suspect that is correct, I have no  
evidence to back it up, so I won't assert it.  I will state with some  
confidence however that the group of people in your position is  
shrinking, while that in mine is growing.

And I will freely admit that I find the notion that a group of people  
designing global infrastructure think it's OK to use ASCII so morally  
and and aesthetically offensive that it probably interferes with my  
evaluation of the trade-offs.

I will now shut up.  It is clearly the case that there is tremendous  
resistance within the IETF to leaving their comfy ASCII enclave.  -Tim

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 02 Dec 2005 09:51:47 +0100

Hi Tim,

on 2005-12-02 02:44 Tim Bray said the following:
[snip]
> resistance within the IETF to leaving their comfy ASCII enclave.

Following the debate from the sideline till now, it's clear to me that
there are at least a few people who are adamantly against change.  I'm
not at all convinced that a large majority feels this way.  A poll might
reveal more than the relative proportions of highly engaged people
voicing their views here.

As for the issue itself - no, make that some of the issues...

A lot of people seem to appreciate the html-ized and PDF-ized versions
provided on the tools.ietf.org site, even if the convenience offered
by those are small compared to what could be available if a richer
format was available during document preparation.

Personally, I think we would benefit from 

  * having the XML format championed by xml2rfc as a common source format

  * having support for the complete range of unicode characters for
    author attribution in the source format

  * having the ability to consistently generate multiple presentation
    format from this - including ASCII and UTF-8 text for textual diffs,
    html with links for browsing, and pdf for consistent cross-platform
    printing.
    
Regarding the stability of the presentation format, I note that

- A new version of PDF called PDF/A (A for Archive) has recently been 
  standardized in ISO 19005-1 as an "Electronic document file format for
  long-term preservation".  This is going to be around for a while.

- HTML 4 is also stable; the latest published version is 4.01 from 1999.

- Text, as has been pointed out, is going to be readable long after other
  formats have come and gone.  Yes, that's true, but readable doesn't
  necessarily mean as easily accessible as other formats.  I think we're
  already seeing that richer formats is passing text as the format of
  choice for most people, and platform support for easy handling of the
  different formats is shifting.

However - aren't we lucky!  If we have a standardized format (RFC 2629
or revisions thereof) from which we can generate multiple presentation
formats, we could always use it to generate the format-du-jour if it
should come to pass that both PDF/A, HTML 4 and text should be hopelessly
outdated...

Now, the toughest question here is which presentation format should be
normative.  I think that something richer than ASCII would be good.
It's not clear to me that there is one obvious choice for which format
it should be.  In 1 or 2 years I might say PDF/A if it has enough tool
support, as it's open and free, cross-platform consistent, designed to
be stable and long-term accessible.  But I'd consider it only if we have
a common source format from which we can reliably produce other versions
such as HTML for browsing and ASCII/UTF-8 for diffing.

	Henrik

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 02 Dec 2005 20:05:37 +0900

A fundamental problem, among many, of Unicode is that, most
people can't recognize most of local characters.

With the internationalized context of IETF, it is prohibitively
impolite to spell names of people in a way not recognizable
by others.

Thus, for the internationalization, names of people MUST be
spelled with characters recognized by all the international
participants, which means ASCII is the only choice.

						Masataka Ohta

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 02 Dec 2005 13:00:35 +0100

>resistance within the IETF to leaving their comfy ASCII enclave.

Tim,
"ASCII enclave" is excellent. I felt like you for years. Then RFC 
3935 came. I understood it was the same old group of people who 
"believe that the existence of the Internet, and its influence on 
economics, communication, and education, will help [them] to build 
a  better human society" and this is why they are to "influence the 
way people design, use, and manage the Internet". To do so this group 
"uses the English language for its work is because of its utility for 
working in a global context.". This is an old religion. ASCII is part 
of it. From the very beginning.

You cannot oppose a religion. But you can expose it, so everyone may 
knowingly adhere or repudiate it. This is the reason of my RFC 3066 
bis saga: the current outcome (simultaneous USG Tunis deal and IESG 
approval of the painstakingly trimmed Draft) brought the limitations 
I wanted. The appeal underway will clarify the IESG position: is the 
IETF exclusive or still possibly inclusive?

This is of key importance because two visions of the Internet oppose. 
Most of us share the vision of a functional Internet where our "goal 
is connectivity, the tool is the Internet Protocol, and the 
intelligence is end to end rather than hidden in the network." (RFC 
1958). The vision of your "ASCII enclave" is for them to be the 
globalization core of an hardware Internet "a large, heterogeneous 
collection of interconnected systems that can be used for 
communication of many different types between any interested parties 
connected to it." BTW this is quite the same definition, and 
resulting objectives, as 47 USC 230 (f)(1) legal US definition: 
Internet is "the international computer network of both Federal and 
non-Federal interoperable packet switched. data networks."

This is a very consistent, time proven, stakeholders supported 
vision. If they do not want to move, I do not think you can change it 
without changing of Internet.
jfc

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 02 Dec 2005 21:32:43 +0900

JFC (Jefsey) Morfin wrote:

> To do so this group "uses the English 
> language for its work is because of its utility for working in a global 
> context.". This is an old religion. ASCII is part of it. From the very 
> beginning.

I'm tired of this kind of fallacy.

ASCII is not English.

A charset is not tied to some content language.

For exmaple, the line below is in Japanese language spelled in ASCII.

	Uso ha yasumi yasumi tsuke.

							Masataka Ohta

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 02 Dec 2005 13:52:16 +0100

>A charset is not tied to some content language.

I am also fed-up with this kind of logic violation. Read the RFC and 
read my mail!

English language is selected by the IETF.
English is tied to ASCII.
This is one of its leading advantage: to support information 
interchanges with the most limited charset.

To read into this anything else, and in particular that ASCII would 
be limited to English is absurd or baised.
jfc

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 02 Dec 2005 22:23:27 +0900

> English is tied to ASCII.

All the languages in the world is tied to ASCII too.

So?

> interchanges with the most limited charset.

ISO 646 IRV (Internatinal Reference Version) is defined by not
IETF but ISO.

							Masataka Ohta