[Top] [All Lists]

MIME boundary question recap

1995-02-10 01:03:10
I think a recap at this point would be useful:

(1) The current specification (RFC1521) is ambiguous about whether or
    not one boundary string can be a leading substring of another.

(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.

(3) I screwed up both in not fixing the prose to match the new grammar and
    in my initial response to Steve's query. I did not catch the
    relationship between the two issues, and I thought that one had no impact
    on the other.  I apologize again for my inattentiveness here -- I should
    not try to debug X.400 recipient extension handling code simulataneously
    with doing standards work.

(4) Most people seem to have read the specification the way Steve did, which
    is at odds with how it now reads.

(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.

(6) Someone is going to have to change some code no matter what. We have
    an interoperability problem caused by an ambiguity in the specification
    that has to be resolved one way or the other.

(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 don't have a lookahead problem yet because I don't yet
    support binary message formats completely. I plan to soon, however, and
    I need to have this resolved before this will work right.)


<Prev in Thread] Current Thread [Next in Thread>