[BXXPwg] MIME header is gone

Wolfgang Hoschek wolfgang.hoschek@cern.ch
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 &
error prone.
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 mimelength=0:
	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
the draft. 

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.
> /mtr

Is this still the case? Draft 08 is silent on this. Also found no
consistency check.

Thanks for pointing out whatever I missed to understand and for
summarizing the current thinking about this issue.