Re: Content Type Attribute Question

Chris:

Please look at the Content Hints attribue defined in ESS.  Would it be useful to add the EncapsulatedContentType structure to this attribute?  Would this meet your requirements?

Russ

At 09:37 PM 1/14/98 -0500, Bonatti, Chris wrote: 
>>>>
> 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/>http://www.ieca.com/"       | 
> --------------------------------------------------------------- 
<<<<