[Top] [All Lists]

Comments and extensions to STIF

1993-09-17 11:01:00


I have reviewed the STIF document and have a number of comments.  
At a high level I agree that this is a needed piece of technology 
and the general approach is reasonable.  I have several 
applications for which this is almost adequate and would like to 
challenge STIF to meet these needs within the established 
technology of RFC 822/MIME.

One assumption I need to challenge is that exchanged information 
will be of a consistent type (text) and a consistent character 
within a header set.  I can see an immediate need to exchange 
information in multiple character sets, although only with only 
one character set per header line, and items which are not text, 
such as X-Face (X.500 portrait) and Spoken Name.  While these 
non-text examples can be encoded into a text form, the necessary 
specification of format and encoding is unfortunately outside the 
scope of the current STIF document.

An alternate approach to make these assumptions apply to a header 
line rather than to the header as a whole. This gives the 
flexibility to include items of multiple character sets in the same header 
without inventing new protocol.

This approach solves the multiple character sets and multiple 
encodings needs, but does not solve the mixed media.  The encoded 
word assumes data is of type text/plain and provides the one 
parameter to the text/plain as a separate field for the 
specification of the character set.  It would be useful to extend 
this to allow for short segment of any arbitrary content-type.  
To do this I propose an extension to the encoded word for STIF 
use. I would expect that the line length limitations of the 
encoded word would be preserved.

The most obvious extension is to add an additional parameter to 
the encoded word to represent the content-type, either using a 
shortened version of the content-type name or by using the 
corresponding MIME branch OID used for the MIME/MHS mapping. (I 
assume it is reasonable to use an implicit OID branch to avoid 
the long number string)  The character set parameter slot can be 
used for any necessary parameter information for a given content-

This approach has two limitations.  First it is not compatible 
with current encoded word parsers, and second, it adds to the 
already large overhead of the encoded word further reducing the 
amount of data in a single word.

I prefer another approach however which is backward compatible 
with the encoded word.  That is, use the corresponding MIME
content-type OID (or some other short content-type alias) in the
character set parameter when the content-type is not text/plain.
A reserved token, such as the letters OID, can be used if 
necessary to indicate that this is not a character set  This
approach will work only for simple content-types which have no 
use of parameters. I do not believe this is a limitation for the
short simple objects envisioned for inclusion in STIF headers.


Name: Gregory M. Vaudreuil
Best Friend: =?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=
Phone: +1 214 733 2722 (Work) / +1 214 733 8666 (Fax)

Greg Vaudreuil

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