Subject: Towards consensus on document format

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 13 Mar 2010 15:54:29 -0500

What I find rather puzzling here is that most of the defenders of the
status quo are saying 'document format is really no big deal, why make
a fuss'. And the contrary argument is 'Actually, this is a very big
deal to us, we care a lot about how the documents look and the type of
tools that can be used to generate them.

If these are genuinely the positions on each side then I really can't
see what the reason for not making a change would be. The people who
care about the issue have made very clear that they are willing to
help write code etc to make a transition. We already have xml2rfc, 95%
of the tools are already in place. The only changes that need to take
place are for the IESG to declare the HTML generated by XML2RFC as
canonical and for the web site and RFC practices to reflect this
change.

Case in point here, I have the 150 pages of the DSKPP document I am
meant to be reviewing next to me, as always I forgot to set the print
margins to match the IETF criteria and so the headers wrap round
making the task of reading them a much bigger chore than it needs to
be. So instead of actually reviewing the document I am writing this
instead.

So in the hope of finding consensus here, lets see what people's
position actually is

A) The format issue does not matter
B) The format issue matters a little to me and I prefer the teleprinter format
C) The format issue matters a lot to me and it MUST be teleprinter format
D) The format issue matters a little to me and I prefer the HTML format
E) The format issue matters a lot to me and it MUST be HTML format

By matters a lot I mean a LOT, as in you avoid bringing work into IETF
process because of the document format or you are less inclined to
read IETF documents or work on them as a result of the format.

Before you answer that, here is a list of consensus requirements on
the document format:

1) Easy to generate
2) Readily supported by a wide range of authoring tools
3) Conformance can be checked using automatic tools
4) Open specification, stable, non proprietary
5) Reversible, able to recover editing format from publication format
6) Longeivity, guarantee of being able to interpret them in 1000 years
time assuming ability to read the physical format still exists

Supporters of the teleprinter format add:

7) Looks like the teleprinter format

Supporters of the HTML format add:

8) Ability to include useful diagrams and tables (ASCII art does not qualify)
9) Ability to code names properly
10) Ability to write an intelligible document on internationalization issues

Looking through the list, it is clear that HTML can meet every one of
the consensus criteria. In most cases meeting it much better than the
IETF format.

1) It is not practical to generate teleprinter format by hand using an
ASCII editor any longer since the adoption of the nits tool.
2) There is only one operating system and one typesetting tool that
makes generating the teleprinter format remotely easy.
3,4) tie
5) It is much easier to convert HTML to XML format than text
6) tie, no really, anyone who thinks we will have difficulty reading
HTML in the future needs to read the history of the Rosetta stone
7) The HTML format for RFCs is as recognizably IETF RFC style as anything else
8, 9, 10) Only supported by HTML.

I am in class E. I find being required to edit documents in
teleprinter format to be very insulting to me personally. I take a
great pride in my work and I do not like being forced to present it in
a format where the principle justification for it appears to be
'because we can force you to do it our way'.

I definitely prioritize IETF work lower than I would because the
document format basically makes me angry every time I see it. And
being told in condescending terms that I should not bother about it
only makes me angrier still.

And note that on this occasion I was not the person who even raised the issue.

Now having got that out of my system I am going to print out the DSKPP
document again and review it.

-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Melinda Shore <[email-masked]>
Date: Mon, 15 Mar 2010 07:53:47 -0800

Phillip Hallam-Baker wrote:
> a fuss'. 

??  I haven't seen anybody argue that, actually, and it would
be odd if they did.

> teleprinter format to be very insulting to me personally. 

That's another odd argument, although it does tend to
support that this is a matter of individual sensibilities.
As nearly as I can tell, people who like to work lower in
the stack tend to prefer certain kinds of formats and
people who work higher in the stack tend to prefer others.
People who don't like strongly-typed languages probably aren't
going to be enthusiastic about strongly-typed document
formats.  It could come down to tastes and possibly
to comfort level with various tools, and it seems unlikely
to me that haranguing people about it will change their
personal relationships with the various technologies.

Melinda

---

From: todd glassey <[email-masked]>
Date: Mon, 15 Mar 2010 09:00:50 -0700

> support that this is a matter of individual sensibilities.
perhaps but the real underlying issue is the information density that
ASCII coding relegates the IETF documents to. The odd issue is that
there was at one time a claim that it would be too cumbersome for people
to live in the HTTP realm or other MIME format.

Now the opposite is true and since the documents are not ASCII to insure
that they are machine readable this is another issue where the IETF has
opted for making it harder to use its work product and to participate.

> people who work higher in the stack tend to prefer others.
In the Stack - which stack are we talking about? And since these people
are NOT in fact designing end-use products for their work products they
are not as you say "Working in the Stack" but rather preventing others
from being able to participate by creating the artificial wall that
mandating the current ASCII only submissions does IMHO.

> formats.  

BS  Melinda - people who like very strong structured documents are those
that live here which is why the document format for the IETF is a
fricken nightmare.

It could come down to tastes and possibly
> personal relationships with the various technologies.

I agree. The solution is to move past them and retire their actions so
that they are not allowed to block the IETF's evolution with such
idiotic and self-centered nits

Sorry - but the IETF should have moved into Web Based automated document
submission years ago.

Todd Glassey
> 
> Melinda
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 15 Mar 2010 17:07:15 +0100

On 15.03.2010 17:00, todd glassey wrote:
> ...
> ...

It did.

Best regards, Julian

---

From: todd glassey <[email-masked]>
Date: Mon, 15 Mar 2010 09:16:48 -0700

>> Sorry - but the IETF should have moved into Web Based automated document

Julian - if this was done properly there would be no need for an Editor
per se... so no they did not. They automated very minor parts of the
process but mandated the ASCII format for the main filings.

XML was not allowed and HTML certainly wasn't.

Dont get me wrong - Postel and the founders had no choice - it was
ASR33's but its been decades since that was the gating control model in
any place where the IETF would be working on standards.

Todd Glassey

---

From: Julian Reschke <[email-masked]>
Date: Mon, 15 Mar 2010 17:22:59 +0100

> process but mandated the ASCII format for the main filings.

Well, you can submit your documents through a web form; this has been 
available for quite some time.

This is orthogonal to the actual publication process.

BR, Julian

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Mar 2010 11:27:39 -0700

> 2) Readily supported by a wide range of authoring tools

WYSIWYG authoring, IMO, ought to be required if we're claiming to climb
out of the stone age (that's basically why I don't use XML, FWIW).

> 8) Ability to include useful diagrams and tables (ASCII art does not qualify)

HTML imports components that follow a variety of other standards (GIF?
BMP?); most of these are not true figures, but are rather renderings of
figures generated some other way.

Yes, figures would be nice to include, but "pictures" are not figures.
So which format are you proposing for this? SVG?

> the consensus criteria. In most cases meeting it much better than the

See above. HTML doesn't cut it for #8 (or at least isn't better than
ASCII without additional requirements).

A larger problem with HTML is that the formatting is not controllable.

I don't like - or want to every use - XML, but I don't understand the
argument that HTML is a better alternative.

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Mar 2010 06:08:05 +0900

> Before you answer that, here is a list of consensus requirements on

The fundamental consensus requirement is that the document format MUST
be widely (and internationally) legible.

The internationalization requirement automatically excludes non-ASCII
characters.

Pure ASCII HTML may (or may not) be widely legible. However,

> 4) Open specification, stable, non proprietary

HTML is already too complex and unstable that there is no hope that
some IETF-specific profiling can be widely and stably supported.

> 5) Reversible, able to recover editing format from publication format

Reversibility does not help if an editor can not recognize (nor input)
some character, which also requires pure ASCII.

> 6) Longeivity, guarantee of being able to interpret them in 1000 years

Then, we should use a format available at least 500 years ago.

Were you using HTML 500 years ago?

							Masataka Ohta

---

From: Julian Reschke <[email-masked]>
Date: Mon, 15 Mar 2010 22:20:02 +0100

> The internationalization requirement automatically excludes non-ASCII

How so?

> HTML is already too complex and unstable that there is no hope that

UNSTABLE?

> some IETF-specific profiling can be widely and stably supported.

Disagreed.

>> 5) Reversible, able to recover editing format from publication format

I do not believe reversibility is required as long as the source format 
is preserved. It would be nice, though.

> some character, which also requires pure ASCII.

Please elaborate.

> Were you using HTML 500 years ago?

Very helpful.

Best regards, Julian

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Mar 2010 08:02:21 +0900

> How so?

People can read ASCII internationally. Even though, in Japan, back
slash characters are displayed as JPY mark in most environment,
Japanese know how to read them.

People can read/edit their local characters.

People can't read/edit local characters of other people.

> UNSTABLE?

Is it still version 1.0?

> Please elaborate.

See above.

							Masataka Ohta

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Mar 2010 00:14:32 +0100

> People can't read/edit local characters of other people.

A conservative approach would be:

1) allow non-ASCII contact information *in addition* to the ASCII version

2) allow non-ASCII in I18N example

for 1), it really doesn't matter whether everybody can read it; just 
stick with the ASCII version

for 2), we should be able to identify a few non-ASCII characters that 
are suitable for use in I18N examples which *do* work widely (a few 
greek characters?)

>>> HTML is already too complex and unstable that there is no hope that

The current version is 4.01, and it has been stable since 1999. The next 
version, 5, is approaching Last Call, and is unlikely to break anything 
that is actually in use.

So your definition of "stable" is that there are no post-1.0 versions? 
Even compatible ones? Just asking...

Best regards, Julian

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Mar 2010 08:37:54 +0900

> 2) allow non-ASCII in I18N example

No. The conservative approach currently deployed is to have ASCII
contact information only, which is enough.

> for 1), it really doesn't matter whether everybody can read it;
> just stick with the ASCII version

Greek capital letter 'A', which is identical to Latin chapital
letter 'A', is already tooooo much.

> version, 5, is approaching Last Call, and is unlikely to break anything 

With more than 40 years of history of RFC, HTML is unstable.

> Even compatible ones? Just asking...

Tools does not support restricted profile very well, as was
demonstrated by a circled 'R' character in a
claimed-to-be-pure-ASCII PDF.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Mar 2010 08:43:10 +0900

Phillip Hallam-Baker wrote:

> Since nobody was using teleprinters 500 years ago the introduction of
> them here as a point of difference is ridiculous.

I can't see your point.

Are you begging our pardon and withdraw your stupid statement of
"being able to interpret them in 1000 years time"?

Or?

						Masataka Ohta

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Mar 2010 00:56:44 +0100

> contact information only, which is enough.

*A* conservative approach != The *most* conservative approach.

> letter 'A', is already tooooo much.

I don't see your point. If it's identical it makes a poor choice for 
demonstrating I18N. It *would* be a good choice for demonstrating 
character spoofing.

> With more than 40 years of history of RFC, HTML is unstable.

HTML is *relatively* unstable compared to text/plain (we're comparing 
formats, not character sets, right?).

Anyway, it's clear that you're not going to convince me, and I'm not 
going to convince you.

> claimed-to-be-pure-ASCII PDF.

I don't think anything was demonstrated at all. If we wanted to test an 
HTML profile, we'd first have to agree on it, and then put the checks in 
place. This hasn't happened yet, so, by definition, nothing was 
demonstrated proving or disproving it can be done.

Best regards, Julian

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Mar 2010 09:29:36 +0900

Phillip Hallam-Baker;

I can understand that you are seriously worrying about archaeology
of year 3010 and beyond.

However, I'm afraid no one else is interested in.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Mar 2010 11:50:33 +0900

> *A* conservative approach != The *most* conservative approach.

Your approach is no conservative.

> I don't see your point.

It's your problem.

> I don't think anything was demonstrated at all.

Again, it's your problem.

						Masataka Ohta

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 16 Mar 2010 06:33:35 -0600

Masataka Ohta <mohta at necom830 dot hpcl dot titech dot ac dot jp> 
wrote:

>> The current version is 4.01, and it has been stable since 1999. The 
>> next version, 5, is approaching Last Call, and is unlikely to break 
>> anything that is actually in use.
>>
>> So your definition of "stable" is that there are no post-1.0 
>> versions? Even compatible ones? Just asking...
>
> demonstrated by a circled 'R' character in a claimed-to-be-pure-ASCII 
> PDF.

So Microsoft Word inserted a registered-trademark symbol into an 
*internal properties field* of a PDF file whose *contents* were claimed 
to be pure ASCII, and now it is claimed that this demonstrates not only 
that the contents of a PDF file cannot be plain ASCII, but also that 
HTML is too unstable for a reduced-feature profile to be successful?

For an Engineering Task Force, this group sure does surprise me 
sometimes with its logical reasoning.

--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages @ http://is.gd/2kf0s

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 16 Mar 2010 13:54:02 +0100

Doug Ewell writes:
> *internal properties field* of a PDF file whose *contents* were 
> claimed to be pure ASCII, and now it is claimed that this 
> demonstrates not only that the contents of a PDF file cannot be plain 
> ASCII, but also that HTML is too unstable for a reduced-feature 
> profile to be successful?
>
> sometimes with its logical reasoning

No, Ohta-san surprises you. FYI this is an invariant: Ohta-san continues 
to surprise you, even after you grow used to him.

(At this point I would like to remark that I am sure Ohta-san has good 
and valuable insights, and that I wish they were easier to notice.)

Arnt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Mar 2010 15:05:00 -0400

I have submitted HTML into that Web form.

And then what happened to it...?

That is the real complaint here. Most of us are now writing documents
in a process that uses XML for authoring and HTML for reviewing. Then
the result is taken and reduced to 1960s teletype.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Mar 2010 15:10:37 -0400

> ??  I haven't seen anybody argue that, actually, and it would

I see numerous statements of that form in the thread.

> personal relationships with the various technologies.

And people wonder why the applications people have mostly deserted to
W3C and/or OASIS.

I don't see the relevance of strong typing. When I worked on routing
level issues I was using formal methods to specify them. It does not
get any more strongly typed than Z/VDM.

One of the reasons I prefer using XML for document preparation is that
it allows me to use automated tools to assemble / validate individual
components of the spec. For example when I was working on SAML 1.0 I
had scripts that generated the schema and documentation from a source
file and then validated the examples against the schema.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Mar 2010 19:18:43 -0400

+1

And the idea that HTML is any less stable than the hacks people have
developed to make non-ASCII characters work in ASCII is totally
absurd. We can reasonably expect that within the next ten, twenty
years, handwriting recognition will render such hacks obsolete and the
memory of them will be as obscure as Morse code is today.

I don't think there is any real likelihood we will entirely loose the
ability to decipher such hacks, any more than it is likely that all
traces of Morse will ever disappear. But that knowledge is going to
become increasingly obscure and ambiguous.

There is no way that I am going to take a document on
'internationalization' seriously if it is printed in an idiotic format
requiring recourse to obscure transcoding hacks to decipher it when
both the original source document preparation format (XML2RFC) and my
screen are capable of displaying the actual character. Absolutely the
only reason that the information is not present is that some people
have decided that their opinions are soooo damn important that they
are going to maliciously and spitefully create shit-work for me.

On Mon, Mar 15, 2010 at 5:20 PM, Julian Reschke <[email-masked]> wrote:
> I do not believe reversibility is required as long as the source format is
> preserved. It would be nice, though.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Mar 2010 19:58:38 -0400

No, your claim was a canard because it is a test that your preferred
document format cannot meet.

I do not need to have the evidence of 500 years of experience of using
HTML to be able to demonstrate that HTML will be readable in 1000
years time. The difficulty of deciphering HTML is remarkably lower
than the difficulty of deciphering Linear B (3500 years old), Egyptian
hieroglyphs (last used 1600 years ago) or Mayan hieroglyphs (last used
400 years ago).

Many people have successfully decoded HTML without any access to the
standard whatsoever. The idea that we shoudld worry about lack of
ability to decipher it is totally absurd. The value of information
encoded in HTML is simply too great for that ever to happen as long as
civilization lasts.

I really don't think it is worth while arguing that the RFC series is
of such utmost importance that we need worry about ability to maintain
it any longer.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 16 Mar 2010 22:22:47 +0100

> E) The format issue matters a lot to me and it MUST be HTML format

Haven't read the discussion until now (will do that tomorrow) but let  
me add F and cast the first vote in favor of it:

F) HTML that reverts back to usable ASCII (although I'm willing to  
live without headers/footers and the whitespace may look a bit  
different as long as it's self-consistent) when everything between <  
and > is removed from the file and a very limited set of &*; sequences  
has been searched and replaced.

No images because those can't be viewed without non-trivial tools and  
they are extremely hard to modify from the published version.

> 'because we can force you to do it our way'.

replace "document format" with "xml2rfc xml format" and I'm with you  
100%.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 17 Mar 2010 06:40:14 +0900

>> demonstrated by a circled 'R' character in a claimed-to-be-pure-ASCII 

FYI, your claim was:

: Here is an example of PDF-A that uses nothing but ASCII characters: 

> a PDF file whose *contents* were claimed to be pure ASCII

See above.

> and now it is claimed that this demonstrates not only 

Are you saying your PDF-A file is good but your definition of PDF-A
is bad?

But, broken definition is worse than broken tools, which, even
more strongly, means we must not use profiled subset.

						Masataka Ohta

---

From: Jorge Amodio <[email-masked]>
Date: Tue, 16 Mar 2010 15:59:50 -0600

> memory of them will be as obscure as Morse code is today.

I'd love to see you trapped in a basement after an earthquake with
only a stick trying to remember how to tap S-O-S.

Hard to believe but Morse is still in use and required for certain
classes of radio operators.

Cheers
Jorge

---

From: Jorge Amodio <[email-masked]>
Date: Tue, 16 Mar 2010 15:56:36 -0600

> the result is taken and reduced to 1960s teletype.

And the most fascinating thing, you can still read the document if you
have one !!!

Cheers
Jorge

---

From: Sam Hartman <[email-masked]>
Date: Tue, 16 Mar 2010 18:27:50 -0400

I'll say that I'm in category c: the format issue matters a lot to me
and I prefer the status quo.

Changing the format issue is difficult, people who want to change it
routinely ignore some of the issues, and neither side participates in a
constructive discussion.
The status quo is acceptable and we could do far worse.

Phil I cannot imagine being insulted by a document format, but I feel
very uncomfortable with a change being lead by a group of people that
feel that strongly.

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 16 Mar 2010 19:42:52 -0400

On Mar 16, 2010, at 5:59 PM, Jorge Amodio wrote:

> On Mon, Mar 15, 2010 at 5:18 PM, Phillip Hallam-Baker <[email-masked] 
> > wrote:
>> +1
>>

That's easy. Three shorts and three longs, repeat until the water  
covers your shoes.

It's _much_ easier than CQD.

Regards
Marshall

---

From: David Morris <[email-masked]>
Date: Tue, 16 Mar 2010 17:05:13 -0700 (PDT)

On Tue, 16 Mar 2010, Marshall Eubanks wrote:

> That's easy. Three shorts and three longs, repeat until the water covers your
> shoes.

As was said ... who can remember .... 
    three dots,  three dashes *AND* three dots ... pause and repeat

---

From: [email-masked]
Date: Tue, 16 Mar 2010 20:35:04 -0400

>     three dots,  three dashes *AND* three dots ... pause and repeat

There was a great demonstration on a morning TV show a few months ago
where they had two amateur radio operators racing against two people
using a cell phone to send SMS messages, to see who could send a
message faster from one person to another.  The cell phone texters
could use all of the standard text message abbrevations with the T9
input methods; and they had the advantage of using a cell phone
keyboard with 12 buttons versus the radio operator's paddles.

Guess who won?

The morse code operators, of course, by a wide margin.

Some times the old fashioned technology is the best.   :-)

				- Ted
				  (who is still using Emacs, not some
				  fancy/shmancy WYSIWYG GUI tool to
				  compose this message.  :-)

P.S.  And I sometimes still use /bin/ed (which yes, will work on a
teleprinter, to edit system files in single user mode; what's wrong
with teleprinters anyway?  I get most of my most productive work done
using an xterm, which is really nothing more than a glass tty....  :-)

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 16 Mar 2010 19:05:24 -0600

> hieroglyphs (last used 1600 years ago) or Mayan hieroglyphs (last used 

The other silly aspect of this "will it be readable in 1000 years" 
argument is the supposition that the documents will sit, forgotten, for 
1000 years until some future archaeologist digs them up and wants to 
decipher them.

Obviously, if a newer and more wonderful format comes along that 
obsoletes PDF or HTML or whatever, there will surely be a utility (or, 
more likely, a spate of them) to convert data from the old format to the 
new format.  The RFC series, and zillions of documents more valuable 
than 80% of the RFC series, will be converted and will exist in both old 
and new formats LONG before there is any risk of irreversible 
obsolescence.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 16 Mar 2010 19:12:42 -0600

wrote:

>> and now it is claimed that this demonstrates not only that the 
>> contents of a PDF file cannot be plain ASCII, but also that HTML is 
>> too unstable for a reduced-feature profile to be successful?
>
> Are you saying your PDF-A file is good but your definition of PDF-A is 
> bad?
>
> But, broken definition is worse than broken tools, which, even more 
> strongly, means we must not use profiled subset.

I really don't understand what you are trying to prove here, except 
perhaps that I am a fool, and I don't understand in what way that 
benefits the IETF.

Is it your claim that no PDF/A file could possibly exist without at 
least one non-ASCII character in its contents?

Is it your claim that the "document properties" metadata, which of 
course doesn't exist for a plain-text RFC, is essential to the nature of 
a PDF/A RFC, and that no tool could exist that would not insert a 
trademark symbol or other non-ASCII character into this metadata?

Or are you just trying to show that you are more clever than me?

---

From: Bill McQuillan <[email-masked]>
Date: Tue, 16 Mar 2010 19:58:17 -0700

> and new formats LONG before there is any risk of irreversible 

I am haunted by the reports I've heard of NASA plaintively requesting
*anybody* to provide them with a 7-track tape machine to allow them to read
old data tapes from the 1960's and 1970's.

Not so much 1000 years as 40 years!

-- 
Bill McQuillan <[email-masked]>

---

From: [email-masked]
Date: Tue, 16 Mar 2010 23:05:38 -0400

> Not so much 1000 years as 40 years!

I think that's a somewhat old story.  See:

http://investorshub.advfn.com/boards/read_msg.aspx?message_id=47354207
http://www.johnbordynuik.com/case-studies/mit
http://www.johnbordynuik.com/case-studies/nasa

Problem solved, with a dose of new technology.  Did it cost extra
money, because some folks didn't plan ahead and didn't convert these
tapes sooner?  Yes.  But it was doable....

(And it had nothing to do with XML or "teleprinter" or Character set
issues....  I can see the headlines now; Internet history lost forever
because historians felt too 'personally insulted' to read 66-line
formatted RFC's.  :-)

						- Ted

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 16 Mar 2010 18:05:21 -0400

Actually, if you knew Morse code you would know that it is SOS, an
in-band signal consisting of ...---... not the letters S-O-S.

As far as being trapped in a building, any regular pattern of bangs is
going to be picked up and acted on.

---

From: "Michel Py" <[email-masked]>
Date: Wed, 17 Mar 2010 12:29:51 -0700

> Jorge Amodio wrote:
> Hard to believe but Morse is still in use and required
> for certain classes of radio operators.

For good reasons; in difficult conditions, Morse still delivers the
message when the voice has long stopped being recognizable. Morse would
be like ASCII: definitely not the prettiest solution, but if something
still works it would be it.

> As far as being trapped in a building, any regular pattern
> of bangs is going to be picked up and acted on.

OTOH, I would enjoy the added capacity to actually communicate with the
rescue team. Possibly someone would figure out that my banging is Morse
code and find an operator. Optional, but nice.

My $0.02: I would still favor a move towards a better format than ASCII.
No more comments that what has already been said 10 times.

Michel.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 18 Mar 2010 01:14:23 +0000

> still works it would be it.

Sure, but modern digital modes such as WSTJ will beat Morse at SNR.

- Stewart

---

From: "Michel Py" <[email-masked]>
Date: Wed, 17 Mar 2010 22:17:16 -0700

>> Michel Py wrote:
>> For good reasons; in difficult conditions, Morse still delivers
>> the message when the voice has long stopped being recognizable.
>> Morse would be like ASCII: definitely not the prettiest solution,
>> but if something still works it would be it.

> Stewart Bryant wrote:

Maybe this actually is a useful comparison; on paper, yes. But you miss
the point. If your email and  telephone are working, you don't need the
ham radio. Now, when you are in a disaster zone with no infrastructure,
it's a different ballgame. The only power you have is the one you
produce by pedaling in the generator while transmitting. It is 110F with
100% humidity, a tree canopy 200ft high and mosquitoes bigger than some
birds. The only reason you have a radio in the first place is because
you jumped out of the plane with it on your back. Obviously the chute
opened, or else you would not be transmitting. Before you set up camp
you had to cross a river with it. The guy you're trying to talk to has
no power either; his antenna is a piece of barb wire.
Where's your WSTJ gear?

Same applies to document formats. You're in the middle of nowhere with a
14.4 modem (in good days). What do you want to read? The 50MB
{put.fancy.doc.format.in.here} or the ASCII version?

Again I support moving away from ASCII, but here has to be a fallback to
it.

Michel.