Content Type Attribute Question

    I'd like to pose the question of why (besides backward
compatibility, which I understand) the ContentType attribute is
limited to only an object identifier?  Object IDs certainly work
for S/MIME content types carrying other S/MIME content types, but
there are a bunch of other likely types of content that aren't
identified in that manner.  X.400, for example, relies on integer
encoding for backward compatibility.  MIME itself uses an ASCII
string identifier for the content, and we don't support this
either.  While I think that object IDs are probably the BEST way
to identify the content type, it is unrealistic to expect the
whole world to change its ways.  Even our own S/MIME ESS document
has a more flexible definition of content type.

    I would like to propose that we define a new attribute to
accommodate more flexible content typing.  The definition I would
propose as a starting point for this new attribute is as follows:

    ContentTypeExtended ::= CHOICE {
        built-in               BuiltInContentType,
        external               ExternalContentType,
        externalWithSubtype    ExternalContentWithSubtype,
        other                  OtherContentType }

    BuiltinContentType ::= [APPLICATION 6] INTEGER {
        unidentified                    (0),
        external                        (1),
        interpersonal-messaging-1984    (2),
        interpersonal-messaging-1988    (22),
        edi-messaging                   (35),
        voice-messaging                 (40) }
                        (0..ub-built-in-content-type)

    ub-built-in-content-type INTEGER ::= 32767

    ExternalContentType ::= OBJECT IDENTIFIER

    ExternalContentWithSubtype ::= SEQUENCE {
        external       ExternalContentType,
        subtype        INTEGER }

    OtherContentType :: = SEQUENCE {
        type    [0] OBJECT IDENTIFIER,
        value   [1] OCTET STRING }

    other-content-type-ia5-mime-subtype OBJECT IDENTIFIER ::= {
TBD }
        -- When used in the "type" field of the OtherContentType,

        -- this value indicates the presence of MIME content type

        -- indications within the octet string.  When this value
        -- is used the content of the octet string must be a
string
        -- of ASCII characters.

This syntax is the same as that in ESS, except that I have added
an additional choice that allows any value to be carried.  My
intention here is that we could effectively convey an ASN.1
constrained ANY, but restricting the encoding to an octet string
for ease of implementation.  This additional field could be used
to convey MIME types.  However, structured the way it is, it
leaves could easily support alternate character sets or other
creative uses in the future.

    I think that such a new attribute would add a lot of
flexibility to S/MIME.  The proposed attribute does nothing to
break backward compatibility, because the old definition will
still be valid and protected messages could actually carry both
attributes through some transition period.

    I look forward to hearing your opinions on this.

  Chris



 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti                 9010 Edgepark Road  |
 |  Vice-president                     Vienna, Virginia 22182  |
 |  bonattic(_at_)ieca(_dot_)com   Tel: 301-212-9428   Fax: 703-506-8377  |
 |  PGP public key available from "http://www.ieca.com/";       |
 ---------------------------------------------------------------