[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MIME boundary question recap
On Feb 9, 11:47pm, Ned Freed wrote:
} Subject: MIME boundary question recap
} (2) The current draft of the final specification changed this so that
} one boundary cannot be a leading substring of another. This was agreed
} to on the list in October and was changed to make it possible to allow
} for trailing whitespace without an arbitrary amount of lookahead.
} (5) We need to decide how to proceed. I don't see how we can have it both
} ways -- we either allow trailing whitespace on boundary lines or we
} allow one boundary string to be a leading substring of another. Which
} one is more important? Requiring infinite lookahead is not acceptable in
} my opinion.
} (7) Speaking as an implementor, I could go either way on this. I don't
} generate boundaries the way Eudora does, and I currently support
} Eudora's boundaries.
I confess to a philosophical preference for Eudora's position, and Keith
has a point that in practice the lookahead shouldn't need to be more than
1000 characters. However, I can also appreciate the position that a
boundary string shouldn't be a substring (whether a leading substring or
otherwise) of any string intended to be encapsulated by that boundary.
(That is, I see less to quarrel with in the case of
than in the reverse case; but the distinction is not worth worrying about.)
Philosphy aside, I generally agree with Keith's suggestion:
On Feb 10, 10:08am, Keith Moore wrote:
} Subject: Re: MIME boundary question recap
} For robustness, I suggest:
} (a) MIME composers MUST avoid emitting boundaries such that
} one boundary is a substring of another. (However, MIME readers
} MUST NOT refuse to process a message because it has such
If this is going to "break" metamail and several other widely-deployed
reader implementations, I think I'd want to drop that parenthetical.
} (b) MIME readers MUST ignore trailing whitespace in lines that
} are less than 1000 characters long, when examining a line
} to see if it is a boundary marker. (However, since a
} boundary marker can contain no more than 74 characters before any
} padding whitespace, including leading and trailing '-'
} characters, any line with non-white-space characters after
} the 74th position cannot be a boundary marker.)
Right; that is, the lookahead problem occurs only when there are an
arbitrary number of whitespace characters following a successful prefix
match against a boundary string. Any prefix match followed by a non-
whitespace character is clearly not a match (so perhaps metamail is
already "broken" by any interpretation).
Bart Schaefer Vice President, Technology, Z-Code Software
firstname.lastname@example.org Division of Network Computing Devices, Inc.