headers
Neil Katin | 2 Jul 1992 02:58
Picon

Re: MAJOR BUG IN MIME


> I also would like to see the multi-part BNF changed as Mark suggests.  This
> doesn't seem to be a real problem to change;  I believe most implementations
> accept one or two CRLF's before the part, so interoperability isn't at stake.
> It sure seems to be cleaner with just one CRLF, though.

Please *don't* make this change unless you can answer this question:
how do you send a binary part that doesn't terminate with a CR-LF?
That's that reason why there are two CR-LFs at the end of a text part --
one is part of the body part, and the other is part of the terminator.

I realize that all public MIME implementations in today's world with
encode binary parts, but who knows what may happen in the future.  I
certainly would like to see MIME remain neutral with respect to transmission
character widths.

	Neil Katin
Permalink | Reply | 1 comment |
headers
Jim Knowles | 2 Jul 1992 03:12
Picon
Picon

Re: MAJOR BUG IN MIME

> Please *don't* make this change unless you can answer this question:
> how do you send a binary part that doesn't terminate with a CR-LF?
> That's that reason why there are two CR-LFs at the end of a text part --
> one is part of the body part, and the other is part of the terminator.

The modified BNF Mark proposed terminates all encapsulations with CRLF.
So text parts will still end with two CRLFs and binary parts will end
with at least one CRLF (the added one).  Here's the BNF Mark proposed:

close-delimiter := "--" boundary "--" CRLF
delimiter := "--" boundary CRLF
epilogue := optional-text
encapsulation := delimiter part-encapsulation CRLF
multipart-body := preamble 1*encapsulation close-delimiter epilogue
premble := optional-text
optional-text := *[*text CRLF]

Doesn't this still work with binary parts?

Jim
Permalink | Reply | 0 comments |
headers
Ned Freed | 2 Jul 1992 04:39

Re: MAJOR BUG IN MIME

I am in complete agreement with Neil on this point. The addition of the
leading CRLF was made for good reason. I am embarassed to say that I didn't
implement this correctly in one case in my code, but I have subsequently
fixed that.

As for whether or not a dot is allowed in a tspecial, I have no strong
feeling about it. I implemented a very lenient parser that does not care
about this particular detail. And thus far I haven't had the need to generate
any parameter values containing a dot that didn't need quoting for other
reasons.

				Ned
Permalink | Reply | 1 comment |
headers
Ned Freed | 2 Jul 1992 06:16

Re: MAJOR BUG IN MIME

I cannot speak for Neil, but this is the first I've seen of any new BNF. Maybe
I lost a message or something... Anyway, I was responding to your statement:

  " ... I believe most implementations accept one or two CRLF's before the part,
  so interoperability isn't at stake. It sure seems to be cleaner with just one
  CRLF, though. ... "

I agree that the BNF you posted in your second message puts two CRLFs before
the boundary when encapsulating normal text. More specifically, here's the BNF
you posted:

preamble := optional-text
epilogue := optional-text
optional-text := *(text CRLF)
close-delimiter := "--" boundary "--" CRLF
delimiter := "--" boundary CRLF
encapsulation := delimiter body-part CRLF
multipart-body := preamble 1*encapsulation close-delimiter epilogue

And here's the BNF from RFC1341:

preamble := *text
epilogue := *text
close-delimiter := CRLF "--" boundary "--"
delimiter := CRLF "--" boundary
encapsulation := delimiter CRLF body-part
multipart-body := preamble 1*encapsulation close-delimiter epilogue

This is one of those cases where all the referencing clouds the issue
rather than revealing it. If you expand the BNF you posted you get:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mark Crispin | 2 Jul 1992 06:40

Re: MAJOR BUG IN MIME

Ned,

     Please read Jim Knowles' message on the subject.  The only thing that my
change to the BNF does is eliminate CRLFs in cases where they are silly.

     If there is some other reason for the leading CRLF, please enlighten me.
I don't remember this ever having been discussed.

-- Mark --
Permalink | Reply | 0 comments |
headers
Mark Crispin | 2 Jul 1992 07:37

Re: MAJOR BUG IN MIME

I'm the author of the new BNF, not that it matters.  The main features of this
new BNF are:

1) It emphasizes that boundary delimiters start at the beginning of a line and
   end with a CRLF.
2) It eliminates the silly-appearing extra CRLF that must occur when there is
   no prelude.

The whole point of the exercise was to redefine delimiter and close-delimiter
to meet those goals, and adjust the rest of the BNF appropriately.  I don't
particularly understand why it is awkward, but it's a matter of personal taste
I guess.

-- Mark --
Permalink | Reply | 0 comments |
headers
Ned Freed | 2 Jul 1992 10:20

Re: MAJOR BUG IN MIME

Your first point is precisely why I think the new BNF is somewhat awkward --
boundary markers are always preceeded by a CRLF as well as being followed by
one. The preceeding CRLF is generally a more important characteristic (in
fact, the trailing CRLF is irrelevant insofar as boundary checking goes
because implementations have to assume that trailing blanks might be
added). The emphasis on the trailing CRLF that's implied by the BNF is
therefore a red herring, and I don't like formal red herrings.

However, there is no way to put the CRLF back into the innermost
portion of the BNF without reinsering the requirement of an initial
CRLF. And I certainly agree that losing the initial CRLF is a good thing
that's worth a little awkwardness.

				Ned
Permalink | Reply | 3 comments |
headers
Nathaniel Borenstein | 2 Jul 1992 13:42
Picon

Re: MAJOR BUG IN MIME

Well, nobody has objected yet, and I agree the change is a good one. 
But I'd point out that given the current proposed standard status  of
MIME,  this  is no longer as easily changed as it once  was.  I believe 
we  can make this change in the DRAFT standard version, in about 6
months, without having to  reset the clock to proposed, but I see no way
to make the change before then.  

Small comfort department:  I believe the word "MAJOR" in the subject of
these messages is an extreme exageration. -- NB
Permalink | Reply | 2 comments |
headers
Mark Crispin | 2 Jul 1992 13:44
Favicon

Re: MAJOR BUG IN MIME

It's a major bug if interoperability is screwed.  It is.

I have received MIME messages that I cannot handle because there are unquoted
dots in parameters.  I am pretty sure MetaMail is among the culprits.  My
users are unsympathetic when I tell them I'm obeying the spec and the sending
mailer is not.  The bug reports are coming in and I have to do something.  I
don't think I can wait for the draft standard.

If I delete dot from my tspecials, then I will generate non-conforming MIME
and what's worse my new code couldn't talk to my old code.  That's even less
acceptable.

I'm afraid this mistake in MIME has forced me into a corner.  I need to split
tspecials into two groups, one for what I generate, one for what I parse, the
difference being that the latter omits dot.  I suspect that other implementors
will have the same problem, so we may end up having to put it into MIME.
Permalink | Reply | 1 comment |
headers
Craig_Everhart | 2 Jul 1992 15:54

Re: MAJOR BUG IN MIME

I'd agree that the sensitivity of MIME to the existence and preservation
of the additional leading CRLF in a message is silly and I'm glad to see
it go.

I'd also argue that it is important to remove this restriction in the
interest of transport-transparency, as I'm sure that there are MTAs out
there that dink around with the leading edge of the body portion of an
RFC 822 message, adding or deleting ``superfluous'' characters.

		Craig
Permalink | Reply | 0 comments |

Gmane