Re: MIME boundary question recap

["Barton E. Schaefer" <[e-mail]>]

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.

Same here.

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

    --inner-outer
    --inner
    --inner--
    --inner-outer--

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
}     boundaries.)

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
[e-mail]               Division of Network Computing Devices, Inc.