On 2/9/95 at 12:40 PM, Glenn Vanderburg wrote:
...as I interpret it, there are two strings which must not appear as body
The RFC speaks explicitly about the preceding CRLF being conceptually attached
to the boundary string, but merely states that the boundary string "must be
followed by another CRLF".
Steve and I talked about this: I think you misinterpreted the RFC. Though
it does say that the preceding CRLF is "conceptually attached", that is
only to decide what counts as part of the preceding part:
NOTE: The CRLF preceding the encapsulation line is
conceptually attached to the boundary so that it is possible
to have a part that does not end with a CRLF (line break).
That DOESN'T mean that the preceding CRLF is *part* of the boundary; the
definition of the encapsulation boundary is quite specific:
...The encapsulation boundary is defined
as a line consisting entirely of two hyphen characters ("-",
decimal value 45) followed by the boundary parameter value
from the Content-Type header field.
So, neither the preceding nor the following CRLF are part of the
encapsulation boundary per se; an encapsulation boundary is defined as an
entire line, which is something bounded by two CRLF's. That's why the
vendor got it wrong: There is this very tiny ambiguity about whether what
is between the two CRLF's is what cannot appear anywhere else within the
body part, with or without being bounded by two CRLF's.
I think it takes a good deal of mind bending to come up with the
interpretation they did. For such bizarre minds, I guess the draft should
Pete Resnick - presnick(_at_)qualcomm(_dot_)com
Home:(217)337-1905 / Fax: (217)337-1980