Dave,
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-
type.
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.
Example:
Name: Gregory M. Vaudreuil
Face:
=?OID-GIF?B?LKJDFOsdfJLKLIreJLtyuJLSDtyuIJLKtutututuJOIJSFIJK?=
Best Friend: =?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=
Phone: +1 214 733 2722 (Work) / +1 214 733 8666 (Fax)
Greg Vaudreuil