Subject: RE: HTML better for small PDAs

From: [email-masked]
Date: Tue, 27 Feb 2001 13:42:44 +0100

Dear everyone,

After reading every day about 20 emails about this subject, this is one of the
wisest thing I have read (ether in a laptop or PDA).

<    Perhaps we ( the IETF ) should have a library of standard,
<downloadable translation / formatting tools that would help people to write
<in whatever format they choose, then convert it to the required ASCII.
<However, this would still not solve the problem os ASCII's poor diagram
<capability.

I am sure that will help, while the discussion on the standard format goes on,
the tools will be helpfull to everyone whatever the final decision should be.

Regards,
Joaquin Rivera

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 27 Feb 2001 13:17:36 +0000

>>the tools will be helpfull to everyone whatever the final decision should be.

there is no substitute for good graphics design skills/ability -
havign said that, some tools WOULD be nice - i think its irrelevant
whether the tools render the output as GIFs or PDF or ascii - the
problem some people appear to have is focusing.
in practice ,there's 3 or 4 diagram types:

1/ packet headers- here the conventions used in rfc791 onwards are
EXCELLENT since they are cpu agnostic- since they are also labelled
they are no more national language specific than a program is:-)
(e.g. C structure or Java ) 

2/ state machines - these are not too bad - yo ucan use the same
approach as is used in old 60s/70s flow charting/call graphing in
general, quite clearly....the most complex state machine (e.g. new PIM
SM spec, or TCP) are not too hard

3/ packet exchange examples (e.g. time sequence diagrams) - i think
these are trivial (except occasionally in multicast:-)
a tool for these would be pretty simple to build...
(something could back end off of emacs, powerpoint animations, ns
animations and magicpoint etc)

4/ topology based expostion (i.e. routing protocols) - these are
generally very hard - ascii makes you think a LOT, as i said before
about keeping the examples simple

any other?

so how about a project to develope some tools for the last trickier case
above? (btw, i dont see how XML helps one bit - PDF or PS are the only
options for platform independnt rendering, and even then there are
problems with portability and fidelity) - and specifying the actual
editing/wordprocessing toolset is not on!

 cheers

   jon

p.s. how mayny people really read a protocol spec on a PDA? i mean the
time i do it is when coding, and when coding i want the spec in a
window, the code in a window, gdb in another window, tcpdump in 2 more
- seriously.