[BXXPwg] MIME header is gone
Mon, 04 Dec 2000 15:43:57 +0100
In draft 08, the message syntax seems underspecified wrt. where MIME
headers (Content-Type, Content-Transfer-Encoding, etc.) belong. The
auestion arises: Are MIME headers
a) part of a message,
b) part of a frame header, or
c) part of a frame payload?
in case a) holds:
As far as I understand there are nothing but frames on the wire. Where
does the MIME header go?
in case b) holds:
"2.2.1 Frame Syntax" contradicts this by saying
header = msg / rpy / err / ans / nul
No MIME type mentioned here. It used to be in some older draft and
apparently got kicked out.
in case c) holds:
Say, an app transports gifs and/or videos, and/or xml descriptions in
the payload. How does a beep user application detect content type and
encoding? We have a message and don't know how to interpret it. Probing
the payload and trying to match against valid MIME headers seems fragile
and inefficient, since we cannot easily determine where the mime-header
stops and the "real" payload begins. There may be no mime header at all,
or by accident a GIF payload without mime header may happen to look
identical to a valid mime header. The only way out is to have some
implicit knowledge, for example, that profile X allows only messages of
mime type T. Or, alternatively to delegate all responsibility for
decoding mime headers into user space. Both options seem inconvenient &
In order to allow for easy, efficient & unambigous parsing, my limited
understanding of the issue seems to suggest that the inclusion of mime
info into "frame data" would solve the problem.
"2.2.1 Frame Syntax" ...
data = header mimeheader payload trailer
mimeheader = mimelength CR LF mime
mimelength = 0..2147483647 (ASCII)
if this is not the first frame of the message:
content & encoding of the last frame of the current message is used.
Default content & encoding for this channel is used, as specified in
Now, the frame size would need to be explicitly defined to include
(preferably) the mime header or exclude it.
Another question: Browsing trought the archive I see
> i don't think so. i think you can send mime headers only on the first
> segment of a message. it doesn't make sense to have them anywhere else. we
> should probably add a consistency check rule for that.
Is this still the case? Draft 08 is silent on this. Also found no
Thanks for pointing out whatever I missed to understand and for
summarizing the current thinking about this issue.