ietf-822
[Top] [All Lists]

Re: Postfix, redux

1991-04-26 15:03:23
1.  Change the definition so that a postfix is simply NOT ALLOWED,
rather than just ignored.  This is slightly problematic because some
MTA's might add trailing blank lines to muddy the waters.

2.  Change the definition so that a postfix is considered another
encapsulated part.  Or, to put it more formally, the multipart syntax
becomes

body := 1*encapsulation

encapsulation := delimiter message CRLF 


I am not sure if I understand your solution 2.  If solution 2 allows the
postfix area to become a body part which does not have any body-part 
headers, I will have to disagree with this solution.  In the previous
discussion, I mentioned that the optional prefix and postfix areas were
not mapped well to X.400 IPM.  Also, previous messages from Craig and Dave
pointed out that we should go for robustness.  Body part without any headers
destroys the robustness!

Dave's message also suggested that using the "TWO strings" delimitors may
solve your concerns stated in solution 1.  

With a minor change to RFC-XXXX, the beginning encapsulation boundary 
marker will be "--foobar" and the last encapsulation boundary marker will
be "--foobar--".

Content-Type: multipart; 1; foobar

--foobar
body part 1
--foobar
body part 2
--foobar--

Or, you may want to drop the last encapsulation boundary marker too.
The mail messages in standard Unix mail box are separated by "\nFrom "
token or "\nEOF" (blank line and end-of-file).  Therefore, the last
encapsulation boundary marker is not very useful, except for error 
recovery.  This suggestion is similar to what Dave suggested, except
that the ending encapsulation boundary marker is always "\nFrom " or 
"\nEOF" in your mailbox, or plain "EOF" if you read directly from sendmail.

Content-Type: multipart; 1; foobar

--foobar
body part 1
--foobar
body part 2


-Vincent

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