ietf-822
[Top] [All Lists]

Re: Comments and extensions to STIF

1993-09-22 04:16:01
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>

<Prev in Thread] Current Thread [Next in Thread>