Subject: RE: I-D file formats and internationalization

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 4 Dec 2005 09:17:03 +0200

> Now, the toughest question here is which presentation format should be
normative.  

Why should any electronic format be normative?

The normative version should be the hardcopy print-out,
and any editing tool that can produce a precisely reproducible print-out

should be allowed.

This should hold for artwork as well.

Y(J)S

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

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 3 Dec 2005 23:52:25 -0800

Perhaps it's just me, but I find it bizarre that the question of 
limiting RFC text to ASCII vs. UTF-8 is being conflated with the 
question of limiting RFC illustrations to "ASCII art" vs. other graphic 
formats.  I don't think the two have anything important in common.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 04 Dec 2005 12:14:45 +0100

Hi Yaakov,

> This should hold for artwork as well.

I guess here we differ to some degree in our views - I would rather say
that if any single presentation format should be normative, it should
be the one that people read during last call and during the IESG approval
process.  I think that's quite independent of the ability to produce
precisely reproducible paper copies.

I'm not sure, though, how hard the requirement on one single normative
presentation format is.  If all 3 or 5 (or whatever) formats in common
use can easily and consistently be generated from the same source, does
it matter?

Today, any RFC2629 (or rfc2629bis) source can be consistently turned
into HTML, XHTML, PDF, CHM and more, by using various combinations of
xml2rfc, rfc2629xslt, xsl11toFop, xml2rfcpdf.  The only major gap we
have is really the ability to turn rfc2629bis sources which contain
diagrams in image formats automatically into good ASCII artwork.

With enough confidence in the consistency of the generated output,
we might not care so much any more about whether it was the PDF/A version,
the ASCII version, or the printed page which was normative...

Of course, this only holds if the source from which the various formats
can be produced is as easily available as any single presentation format.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 04 Dec 2005 12:22:09 +0100

> formats.  I don't think the two have anything important in common.

It is two different issues.

They are easily conflated because in both cases the ASCII format is
limiting, and other richer formats are less limiting.

But you're right, and a change of subject line would have been in order.

	Henrik

---

From: Douglas Otis <[email-masked]>
Date: Sun, 04 Dec 2005 08:40:02 -0800

> But you're right, and a change of subject line would have been in order.

If by other graphics, this could also mean utilizing graphical
characters to create clean lines, boxes, and borders.  This could be a
matter of the character-repertoire going beyond ASCII in conjunction
with a drawing application.  This approach should permit a simple
translation back into ASCII-artwork for the ASCII only version.

If by graphics you mean something more complex in terms of graphs and
charts, then having a means for reproducing these images will offer a
greater challenge.  It would seem some open-source application should be
specified, where the input data is also made available.  The ASCII only
version could list just this input data in lieu of graphics.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 4 Dec 2005 09:18:53 -0800

At 11:52 PM -0800 12/3/05, Doug Ewell wrote:
>question of limiting RFC illustrations to "ASCII art" vs. other 
>graphic formats.  I don't think the two have anything important in 
>common.

It is not just you. Every time any change is proposed to RFCs on this 
list, every desired change is conflated, and they all instantly 
achieve MUST status, and the IETF are idiots for not having done it 
five years ago. Maybe it will be the same for our grandchildren.

--Paul Hoffman, Director
--VPN Consortium

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 06 Dec 2005 23:27:30 +0100

Douglas Otis wrote:

> this could also mean utilizing graphical characters to create
> clean lines, boxes, and borders.  This could be a matter of
> the character-repertoire going beyond ASCII in conjunction
> with a drawing application.  This approach should permit a
> simple translation back into ASCII-artwork for the ASCII only
> version.

This won't work.  Forget it.  The xml2rfc ASCII-approximations
for Latin-1 and some additional windows-1252 characters are
already dubious.  Weird cp858 example added below, bye, Frank
�¿ �˻ +-+
�Ŵ �ι |+|
��� �ʼ +-+
┌┬┐ ╔╦╗ +-+
├┼┤ ╠╬╣ |+|
└┴┘ ╚╩╝ +-+

---

From: Douglas Otis <[email-masked]>
Date: Tue, 6 Dec 2005 18:02:18 -0800

On Dec 6, 2005, at 2:27 PM, Frank Ellermann wrote:

>> clean lines, boxes, and borders.  This could be a matter of the  
>> character-repertoire going beyond ASCII in conjunction with a  
>> drawing application.  This approach should permit a simple  
> This won't work.  Forget it.

The unicode box drawing characters (2500-257F) you used are  
specifically for box and line drawing, but depend upon the line  
spacing matching their point size.  This can be used to create clean  
drawings, when formating is controlled and perhaps output as PDF or  
HTML, for example.  These same characters can be translated into the  
same dashed-line quality ASCII-artwork for the current US-ASCII  
version RFCs.

Unicode does offer the possibility that artwork can look clean, but  
font  selection and line spacing must be controlled, which is not  
practical in emails.  : (

┌─┬─┐  +-+-+
├─┼─┤  |-+-|
└─┴─┘  +-+-+

-Doug