Subject: RE: Alternative formats for IDs

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 2 Jan 2006 11:39:49 +0200

> It does not matter how many people can read MSWord. 
> The only supported formats should be the ones where you know 
> what the format is (and not the ones that depend on particular
program).

Why ?

If you take that as an axiom, then indeed it is easy to rule
lots of formats out.

But, what is the justification of the axiom?
Why not say - only use formats for which there are decent
editors easily available?

And why do all the other SDOs get along with non-ASCII formats?
On my intranet I have a list of 120+ SDOs in the communications
and computer-science fields, and although I haven't gone through
them all (I have asked someone to do so) I haven't found another
group that uses ASCII files.

If the axiom is so strong, then why doesn't it bother anyone else?

Y(J)S

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 02 Jan 2006 10:49:52 +0100

>> what the format is (and not the ones that depend on particular

Formats are there to stay. Programs change. Microsoft has modified the 
Word format multiple times, sometimes breaking compatibility completely, 
sometimes just introducing minor compatibility problems affecting 
specific documents.

(Anecdote: back when I was working for Motorola in the late 90s, 
Windows-based colleagues came over to us with Macs so that we would 
import their old documents and "save as" something their current Windows 
version would read)

There is not a single "Word" format. There are partly-compatible 
"binary" versions, there is the XML format introduced in Office 11 
(2003), and there's yet another incompatible XML format that will be 
introduced in Office 12.

So exactly which one are you referring to?

> If the axiom is so strong, then why doesn't it bother anyone else?

You're confusing the issue of whether ASCII is good enough with the one 
whether Word is an acceptable replacement for it, it seems.

If you're concerned with the limitations of ASCII, I'd advise pushing 
for something that doesn't have these limitations, yet is open, stable 
and really widely available. Such as HTML 4 (strict).

Best regards, Julian

---

From: Peter Dambier <[email-masked]>
Date: Mon, 02 Jan 2006 11:36:53 +0100

>>what the format is (and not the ones that depend on particular

They are written to be readable by everybody.

Sun-cenrtic, IBM-centric and real computercompanies tend to receject mails
and documents that need a special Operating System together with a special
wordprocesser in a special version to be able to process, read or write a
document. I remember there used to be several versions of Microsoft Word
beeing incompatible over Mac, Dos, Windows and OS/2 . That was the time
when companies decided a document has to be 7-bit ASCII without country
specifics extensions. Alternatively EBCDIC was welcome to. There still
exist programmes like kermit that can be used to transfer documents
between flatfile ASCII and structured file EBCDIC over hardware borders.

Even html is designed 7-bit ASCII and breaks when you use 8-bits and
change hardware.

With 7-Bit ASCII it does not matter wether you use an X-BOX with 8-bit
words or a mainframe with 36-bit words. Using 16 bit words breaks when
you move from the X-BOX to the X-BOX/360 both from the same company
but building on different processors.

> If you take that as an axiom, then indeed it is easy to rule

Otherwise you rule a lot of participants out. There was never a
good reason for IBM to move from SNA to tcp/ip. On SNA they had
document exchange. There was never a good reason for DEC to move
from DDCMP to tcp/ip. DDCMP was much more flexible. Why should
Microsoft move from NetBIOS to tcp/ip. They never got it working
without quirks. So you rest with a handful of unix-centric
companies, mostly sun and next. They do speak ASCII what now?

> group that uses ASCII files.

I usually dont bother. If I cannot read it I delete it. Probably
you never got an answer for documents I could not read.

> If the axiom is so strong, then why doesn't it bother anyone else?

You see, they delete it :)
Maybe their virus scanner did in the first place :)

Cheers
Peter and Karin

-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
mail: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 02 Jan 2006 11:59:01 +0100

Julian Reschke wrote:

> If you're concerned with the limitations of ASCII, I'd advise
> pushing for something that doesn't have these limitations,
> yet is open, stable and really widely available. Such as HTML
> 4 (strict).

<dreaming>
 I love the new tools.ietf.org/html rfcmarkup magic.  I also
 love the new unpaginated xml2rfc output.  And of course the
 ordinary ASCII xml2rfc output.  But obviously the process
 XML -> xml2rfc -> ASCII -> rfcmarkup -> HTML loses some of
 the details in the XML source.

 xml2rfc has its own HTML output, but this doesn't reflect the
 look and feel of a "real" RFC like rfcmarkup or what faqs.org
 does.  With a new xml2rfc HTML output "compatible" with the
 rfcmarkup style there would be no losses.  Where "compatible"
 means precisely the same format as in the ASCII output, but
 with links, #page-1 etc. anchors, and #section anchors, like
 rfcmarkup.

 In addition xml2rfc could offer further anchors and links,
 anything rfcmarkup can't "see" because it works with the
 plain ASCII text instead of the XML source.  

 Maybe it could also offer <b>, <i>, and <b><i> while still
 creating monospaced <pre> output.  Or rather content-based
 style tags (reserving <u> for links it will physically be
 bold, italics, or both.  That works with even Lynx if the
 monitor isn't monochrome)

 Last but not least, if we'd "allow" that as the "normative"
 output in addition to text/plain, then "and now allow also
 UTF-8 for the author address in THIS text/html" is trivial.

 This should also work with XHTML 1.0 strict or XHTML basic.
 Matter of taste, I think that XML is simpler than SGML for
 tools trying to do something with it.
</dreaming>

OTOH the MS Word / PDF idea isn't a dream, it's a nightmare.

                            Bye, Frank

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 2 Jan 2006 04:32:00 -0800 (PST)

> editors easily available?

"Decent editor" is in the eye of the beholder ... We're all different 
people and what is good for one maybe bad for somebody else. What
matters is availability of choices and if type of format is not known, 
then it is not an open system and you're locked in one vendor (even if 
others claim to support it,without details of the format, that can not
be completely true). Where as when format is known, the software to 
read/write it can be created by anyone for any architecture.

So, like many people told you already on this list, MSWord is not a
format that IETF should support. If IETF is interested in supporting 
direct "editor" format in the future, then it should probably be
OpenDoc - once its more widely used and more then two implementations
for all major platforms.

Also with vendor-developed format, the actual format tends to change
from one version of the program to the other - that has been the problem 
with PDF as well, eventhough unlike MSWord it is an open format. So one
particular version that is well supported could in this case be chosen.

> group that uses ASCII files.

The question you should ask is can you find a platform where ASCII
file CAN NOT be read and created? Now substitute some other format
in place of ASCII and ask the same question....

> If the axiom is so strong, then why doesn't it bother anyone else?

Lets go ahead and ask then -
   Does anyone else think that IETF should allow documents which
   format/structure is not publicly known as one of the ways to
   distribute IETF specifications?

I think answers so far have been quite clear and from multiple people,
but if somebody else wants to support above, then lets hear it.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: grenville armitage <[email-masked]>
Date: Mon, 02 Jan 2006 23:39:41 +1100

william(at)elan.net wrote:
	[..]
>   distribute IETF specifications?

No.

cheers,
gja

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 2 Jan 2006 10:14:52 -0500

>    distribute IETF specifications?

Not me (or not I, whichever)

David Harrington
[email-masked]

---

From: Peter Dambier <[email-masked]>
Date: Mon, 02 Jan 2006 16:55:50 +0100

> Not me (or not I, whichever)

Not for us either

Peter and Karin

---

From: "Mr. James W. Laferriere" <[email-masked]>
Date: Mon, 2 Jan 2006 09:14:44 -0700 (MST)

Hello All ,

> Not me (or not I, whichever)
 	I have to concur ,  No I do not want any document structure
 	that does not have a COMPLETELY publicly documented
 	specification as an IETF should allow document format .
 		JimL
-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network        Engineer | 3542 Broken Yoke Dr. |  Give me Linux  |
| [email-masked] | Billings , MT. 59105 |   only  on  AXP |
+------------------------------------------------------------------+

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Jan 2006 14:42:41 -0500

--On Monday, 02 January, 2006 11:39 +0200 Yaakov Stein
<[email-masked]> wrote:

> and computer-science fields, and although I haven't gone
> through them all (I have asked someone to do so) I haven't
> found another group that uses ASCII files.
> 

At least one of the reasons is that most of those groups are
moving very slowly away from a paper-based mentality and, in
most cases, a charge-for-standards (on paper and surrogates for
paper) mentality.  With that combination, a format such as PDF
page images (without extractable text) is acceptable and may
actually be an advantage -- it can be read, printed, and is
guaranteed to reproduce the appearance of the printed page
exactly.  Similarly, concerns about proprietary formats with
widely-available "readers" such as MS Word may be less than the
concerns would be if  "editable without information loss" were a
requirement.

In many cases, distribution in Word or PDF has been justified as
increasing distribution speed and lowering (printing, postage,
and mailing) costs to the SDO, with no changes in procedures
about how those documents are handled, reviewed, and processed.

The IETF and its predecessors started with, and continues, a
collaborative norm in which the ability of everyone to read,
extract from, and manipulate an online document is vitally
important, in part because we have long believed that materials
and consensus need to be developed on mailing lists, not by
lengthy development meetings and whiteboards followed by
transcription into the next fixed-benchmark version of a
document.  I see a number of SDOs moving toward that norm, but
most of them are doing so in baby steps.  For several of them, I
would not expect the concept of proprietary formats, and
display-only distributed documents, to survive for very long
once they get to the state of online collaboration and editing
that we have been at for 20 or 30 years.

Finally, there is a longstanding and more or less explicit
decision in the IETF community to keep the costs of
participation as low as possible and, in particular, to not have
costs imposed by the SDO become a bar to effective
participation.  It is getting harder --much harder than I
personally considerable-- to participate effectively in the IETF
without ever setting foot in a meeting, but it is still possible
to do so.  Against our "minimal required costs" background,
effectively insisting a participant maintain a current version
of a particular operating system on which to run particular
versions of word processing and document presentation software
is a pretty steep cost requirement.

That sensitivity to costs of participation is not as important
to most of the SDOs on my list and, I would assume, on yours.
Instead, their norm is participation or membership fees that, in
many cases, I consider high enough to be barriers, requirements
for meeting attendance.  If the minimum entry cost for
participation in SDO X --including membership fees and minimal
meeting attendance costs-- is $5K or $10K or more, then maybe
maintaining even a dedicated machine for dealing with their
documents is a reasonable marginal cost.   But, for IETF
participation, it is not.

    john

---

From: "Tom.Petch" <[email-masked]>
Date: Mon, 2 Jan 2006 21:36:20 +0100

I have always thought that ASCII had much to commend it  - ease of use,
compactness, open standard - which outweighed its limited functionality.

But while we debate this, have events already overtaken us?  I was surprised to
find, when reading
draft-fu-nsis-qos-nslp-statemachine-02.txt
repeated statements to the effect that if you want to see what this looks like,
look at the .pdf version.  It would seem that the system is giving tacit
support to .pdf (although I am cannot readily see just where the .pdf version is
filed:-(

What will anyone say when this I-D reaches last call?

Tom Petch

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Jan 2006 23:14:58 -0500

On Monday, January 02, 2006 09:36:20 PM +0100 "Tom.Petch" 
<[email-masked]> wrote:

> But while we debate this, have events already overtaken us?  I was
> surprised to find, when reading
> repeated statements to the effect that if you want to see what this looks
> like, look at the .pdf version.  It would seem that the system is giving
> tacit support to .pdf (although I am cannot readily see just where the
> .pdf version is filed:-(
>

Under our current process, if the responsible AD is doing his/her job, then 
the document will never _reach_ last call with normative references to 
non-ASCII content.

That is, after all, one of the major facets of the ongoing discussion.

Since someone has asked...

To a certain (large) extent, the format of IETF documents, including 
standards documents, needs to be future-proof.  That is, we need to be able 
to be reasonably sure that someone at some point in the future will still 
be able to read our documents.  There's been lots of discussion and 
arguments about how far in the future we should be worried about, and what 
level of effort is reasonable to expect of future readers, and about how 
well which formats meet these requirements.  However, I daresay there is 
rough concensus that some level of future-readability is required.

In order to achieve that future-readability, it is desirable to require our 
documents to use a specific format, or perhaps one of several specific 
formats.  Such formats should be well-documented as to their syntax and 
semantics, just as we would do for a network protocol.  It is not necessary 
to specify that documents be produced by a particular tool or that a 
particular tool be used to read them, only that they be in a particular 
form.

We don't specify network protocols in terms of specific implementations; 
why should we do so for our document formats?

-- 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: Mon, 02 Jan 2006 23:32:59 -0500

On Monday, January 02, 2006 02:42:41 PM -0500 John C Klensin 
<[email-masked]> wrote:

> to do so.

Actually, I think that recently we've been getting _better_ in that regard, 
and I hope the trend continues:

- For several meetings, we've had jabber rooms for every session.
- More recently, we've also has streaming audio for every session.
- Chairs now have the ability to put slides online _during_ sessions.

Each of these tools has seen steadily increasing usage since its 
introduction.  These days, the chairs in nearly every session make an 
effort to find jabber scribes to report on the meeting and take questions 
from remote participants in real time.  People are getting better about 
always using the microphones, though we have a long way to go in this area. 
And, I know some groups have made an effort to get slides and presentations 
online before or during the meetings, even before the tools became 
available to conveniently do so in a standard place.

As a working group chair, I've conducted meetings in which key participants 
used these tools to effectively participate in a meeting without being 
physically present.  Of course, it doesn't scale to having _everyone_ 
participate remotely, or even a large fraction of very active participants, 
and I don't really think that would be desirable.  However, it is possible 
for large numbers of people to watch, listen, and even make an occaisonal 
comment.  I think we're doing better on this front than we have in many 
years.

-- Jeff

---

From: Melinda Shore <[email-masked]>
Date: Tue, 03 Jan 2006 08:38:22 -0500

On 1/2/06 11:32 PM, "Jeffrey Hutzelman" <[email-masked]> wrote:
> I think we're doing better on this front than we have in many
> years.

The technical support for remote participation really has become
terrific.  Some sessions are run with great sensitivity to remote
participation, others are not - it depends on the chairs.  However,
on the other hand it does seem as if groups have become more
likely to make "final" decisions during meetings and not on
mailing lists.  Rarely you run into the perfect storm of
no jabber scribe, poor microphone placement, and decisions made
in meetings only, but it does happen.  I haven't travelled to
a meeting in about a year but I have participated remotely, and
although the handling of remote participation has been inconsistent
from working group to working group overall it's been pretty good.

Melinda

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Jan 2006 16:51:11 +0100

Melinda Shore wrote:
> mailing lists.  

I'd like to point out that this would be an appealable process failure,
i.e. there should always be (at the minimum) an email call for consensus
about decisions embedded in the minutes, and important decisions should
certainly have their own email consensus call.

    Brian