ietf-smime
[Top] [All Lists]

Re: Attempt to clear off the open issues

1997-07-24 20:52:50
John,

At 04:12 PM 7/24/97 -0700, John Gardiner Myers wrote:
The msg document makes use of the application/mime media type, which the
IESG has not approved.  I have serious concerns with application/mime. 

        Good timing.  So good, in fact, I'm wondering who wrote the Twilight 
Zone
episode...

        It has been a very long time since I've even thought about the spec.  As
coincidences would have it, I just found out today that the draft has been
forgotten about by other folk, too, including the relevant area directors.
Can't blame them though.  Shakespeare was right.  The fault is in myself
not my star (or something like that.)  The IESG had a revised copy but
insisted that it be posted as an I-D before they would consider.  I then
promptly forgot about it.  I'm posting a new and slightly improved version
tonight.

        Aapp/mime got a number of public reviews, most especially on the 
non-ietf
s/mime list (egad, a summer ago)?  Out of all that it looked like folks
were generally comfortable with it.

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
draft-crocker-wrap-01.txt.  

        Indeed they are not.  This is the first I've heard of such impact.  But
sometimes things just work out...Glad we can explore it in so timely a
fashion.

An application/mime can transport a binary MIME object.  It is the first

        It can??  I thought c-t-e binary wasn't currently part of the standard, 
at
this point?  In any event, please elaborate.  How can it do that?

It needs to be understood that
implementing application/mime will require rewriting these MIME

        There just might be some other outcomes, I suspect, if we seek them.  In
any event I had the impression that c-t-e binary is not in widespread use.
Why will app/mime change that?  Why will objects encoded in c-t-e binary be
put into app/mime with any more frequency than they are now?

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

        Well, there's certainly nothing wrong with reminding the spec reader 
that
objects being exchanged over the Internet are required to be in network
standard form.  On the other hand it would be interesting to see an
implementor try to send off a locally-encoded object -- inside app/mime or
any other standardized form -- and claim that recipients should be able to
handle it.

d/
--------------------
Dave Crocker
Internet Mail Consortium                               +1 408 246 8253
675 Spruce Dr.                                    fax: +1 408 249 6205
Sunnyvale, CA 94086 USA              info(_at_)imc(_dot_)org , 
http://www.imc.org

Member, interim Policy Oversight Committee     http://www.gtld-mou.org