This is one point of view. I'd be interested in hearing counter-views.
I gave some comments on STIF a couple of months ago but got no
reactions. Obviously I sent them to the wrong mailing list,
<ietf-stif(_at_)udel(_dot_)asd(_dot_)sgi(_dot_)com> ;-)
So, once more:
-----
Date: Thu, 15 Jul 93 19:13:23 +0200
Message-Id:
<9307151713(_dot_)AA18392(_at_)othello(_dot_)admin(_dot_)kth(_dot_)se>
From: Olle Jarnefors <ojarnef(_at_)admin(_dot_)kth(_dot_)se>
To: Dave Crocker <dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu>
Cc: <ietf-stif(_at_)udel(_dot_)asd(_dot_)sgi(_dot_)com>, Peter Svanberg
<psv(_at_)nada(_dot_)kth(_dot_)se>,
Olle Jarnefors <ojarnef(_at_)admin(_dot_)kth(_dot_)se>
Subject: Comments on STIF
I'm unfortunately not able to attend the STIF BOF (RARE WG-CHAR meeting
at the same time), but here are some preliminary comments on draft 00:
I think STIF is really needed. I generally like the ideas but they can
be both extended and simplified.
1) The treatment of "alternate character sets" I regard as the least
satisfying part of the specification:
a) The BNF excludes characters represented by octets > 127 in
<alt-words>!
b) Characters outside the US-ASII repertoire can't be used in
<field-name>s. But for example some Japanese concepts can't be
expressed adequately in English (nor Latin).
c) Everything in <value>s using characters outside US-ASCII must be
put between square brackets. This makes STIF data awkward to read
and difficult to input for most users.
d) STIF data using an alternate character set is in reality a _dual_
coded character set thing. This is unnecessary since all US-ASCII
characters are included in almost all alternate character sets. In
addition, this makes the use of a MIME charset parameter indicating
_one_ character set improper.
I have a better and simpler solution, which I intend to present on the
mailing list.
2) STIF follows "typical RFC822 rules for wrapping of field data"
(section 2.6, paragraph 3). I suppose that this doesn't mean that
continuation lines of a <value> has to start with linear white space.
That would be unnecessary due to the semicolon delimiters. It's
however much more reader-friendly to start each named field on a new
line, so advice to that effect should be included in the document.
3) I'm not sure that the STIF specification need to specify the internal
syntax of <value>s (as is done now with <ascii-word> and <alt-word>
and LWSP). It should be sufficient to exclude "\", ">" and "/" from
the <reg-char>s.
4) I think that "," would be a better <value> separator in <sequence>s
than "/", because it would be more natural and easy to understand as
such for ordinary users.
5) I feel that ordinary parentheses are used frequently enough in data
that is to be expressed in <value>s to motivate that another
construction for comments should be used. I suggest that "!!" leads
into a comment which ends with the following CRLF (or EOF).
6) My final suggestion is that STIF is extended to allow representation
of a file of STIF-structured records. These could be separated by
blank lines and should not have to be named like <nestings>. (If
record names are needed in a particular case a special record name
field can be included in all records.)
--
Olle Jarnefors, Royal Institute of Technology, Sweden
<ojarnef(_at_)admin(_dot_)kth(_dot_)se>