[Top] [All Lists]

Re: Attempt to clear off the open issues

1997-07-24 16:14:43
I've been holding off raising new technical issues until the WG status
and charter got worked out.  Paul mentions an effort to finish up, and I
don't know what it is that is trying to be accomplished.  Repeating my
question of Jul 2, where are we?

As far as open issues goes, I don't think the issue about the
DN-to-email mapping requirements of section 3.1 of the cert document has
been resolved.

The msg document makes use of the application/mime media type, which the
IESG has not approved.  I have serious concerns with application/mime. 
It has a far-reaching impact on MIME implementations which is both
non-obvious and subtle, and this impact is not mentioned at all in

An application/mime can transport a binary MIME object.  It is the first
method by which this can be done in the context of internet mail.  A
large number of deployed MIME readers in the email domain are incapable
of handling binary MIME objects.  It needs to be understood that
implementing application/mime will require rewriting these MIME
implementations, and the document needs to make this requirement more

The application/mime document is also entirely missing an explanation of 
the canonical encoding implications of the type.  The contents of an
application/mime are in canonical (CRLF-separated) form, and this must
be made clear.  Many MIME parsers deal with MIME entities which have
had  CRLF sequences encoded into a local form of line break.  Such MIME
parsers cannot be directly handed an application/mime object, especially
if that object is binary.

This "binary MIME object" problem is also an issue for the
application/pkcs7-mime type.  I've already heard reports of
noninteroperability between different S/MIME implementations, because
some senders imbed binary MIME objects inside an application/pkcs7-mime
objects and some readers cannot handle binary MIME objects contained
inside application/pkcs7-mime objects.