Gentle Net People,
I have just finished the MIME spec. It is a good and timely thing. My
praise to the authors and working group members.
Please indulge my curiosity and forgive my ignorance if this topic has
already been covered. I see no provision for data compression in the
spec. In my opinion, this would fit nicely into one of the C-T-E
types and it seems to be a big win in the audio/video data world,
however, I recall considerably strong wording recommending against any
new C-T-E's.
Also, I am in need of some clarification about the semantics of the
application/foo content type. Is it OK if the output of the
application "foo" actually yields a MIME message. For instance, if
application/pem becomes a reality (@#$!$) might we expect the output
of a PEM un-enhancer to be itself a self-describing MIME message
(video, audio, text, multipart, whatever). Should this be the default
for an application (always run MIME on the output), or is this
explicitly discouraged or handled in another manner, or should this be
defined on a per-application basis ?
Last, a question about the registration procedure for new
application/subtypes. I would like to register the PKCS (Public
Key-Cryptography Specifications) as a MIME Conversion Value for the
Application content-type. Appendix C states that the published spec.
must be an RFC. Even though PKCS are publicly available specs, must
we republish and maintain them as RFCs. I suspect this is the
requirement, however, I would like to make sure (the
application/postscript does not seem to abide by this rule).
Thanks for your time,
Steve Dusse
Engineer
RSA Data Security, Inc.