RE: RE: Canonicalisation of embedded MIME objects

[[e-mail]]

Ahmed,
 thanks for your reply. The canonicalisation I refer to is defined in RFC45 
section 6.6 page 19 and more specifically again in RFC2049 section 4 subsection 
2 second paragraph page 10. It states:

"For example in the case of text/plain data, the text must be converted to a 
supported character set and lines must be delimited with CRLF delimiters in 
accordance with RFC 822..."


It is my interpretation that ALL embedded objects must have valid <CRLF> line 
ends on their MIME headers. ALL body parts, except binary, must also have valid 
<CRLF> line ends. Just as the outer MIME message has.

Your comments will be very much appreciated.

Regards,
Bartley.
-----Original Message-----
From: zahid.ahmed [SMTP:[e-mail]]
Sent: Saturday, July 08, 2000 1:45 AM
To: bartley.omalley
Cc: zahid.ahmed
Subject: RE: Canonicalisation of embedded MIME objects

can you define what you mean by Canonicalisation of multipart mime?
What specific requirements and assumption you have?

thanks,
Zahid Ahmed


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]
> Sent: Friday, July 07, 2000 2:57 AM
> To: [e-mail]
> Subject: FW: Canonicalisation of embedded MIME objects
> 
> 
> I posted this earlier but got only one response and no help.
> 
> Can anyone help or point me in the right direction where I may find 
> clarification.
> 
> I am aware that the standards say "be modest in what you send 
> and generous in 
> what you accept" but It seems that a significant number of 
> people/implementers 
> are not following the standard as defined.
> 
> Bartley.
> 
> -----Original Message-----
> From: O'Malley, Bartley 
> Sent: Friday, June 23, 2000 1:03 PM
> To: 'ietf-smime'
> Subject: Canonicalisation of embedded MIME objects
> 
> I have noticed that a number of files as produced by 
> different mail programs do 
> not seem to be performing canonicalisation of inner objects correctly.
> 
> The inner objects use LF for line termination not CRLF pairs. 
> It is my 
> understanding that breaks MIME rules for canonicalising 
> embedded objects.
> 
> To illustrate the problem I enclose a signed-then-encrypted 
> message I have 
> received:(I have removed the routing information)
> 
> The outer message appears as follows(All lines are terminated 
> with <CRLF> 
> pairs.).
> -----------------------------------------------------------
> Content-Type: application/pkcs7-mime; 
> smime-type=encrypted-data;                
>               name="xxx.p7m"                                  
>                   
> Content-Disposition: attachment; filename=xxx.p7m             
>                   
> Content-Transfer-Encoding: base64                             
>                   
> Message-ID: 19991015:080159:REF12345                          
>                   
>                                                               
>                   
> MIIbrgYJKoZIhvcNAQcDoIIbnzCCG5sCAQAxggHEMIHfAgEAMEgwQDELMAkGA1
> UEBhMCVVMx        
> ETAPBgNVBAoTCENpdGljb3JwMR4wHAYDVQQLExVFbnRydXN0IERldmVsb3BtZW
> 50IDICBDUa
> :
> :        
> VgIT6ci+93vJE1yRs4la/s3WjmovuOg/PSWUwXiw11EbAmBoB6CitHYFM/Q5sC
> 4RdXrwyH2l        
> 1y59mZTTTtLwr7AbuOlojs/KrIe51CYQMeu14XN/K1tKZXpmB0qgcyDmXq69WY
> Eo+aKglqhJ        
> --------------------------------------------------------------
> ------------------
> ----
> 
> 
> The embedded message looks as follows(All lines are 
> terminated with <LF>).
> 
> --------------------------------------------------------------
> --------------
> Content-Type: application/pkcs7-mime; smime-type=signed-data;
>               name="xxx.p7m"
> Content-Disposition: attachment; filename=xxx.p7m
> Content-Transfer-Encoding: base64
> Message-ID: 19990225:131734:20499
> 
> MIIggQYJKoZIhvcNAQcCoIIgcjCCIG4CAQExCzAJBgUrDgMCGgUAMIISiwYJKo
> ZIhvcNAQcB
> :
> :
> mXw0F0zhCL+ZZdic+fmLh1BQ+rIkVu45zKfJVSI1/F9oyZdaVFMkt0NZaGdjSl
> vuG6deAhgZ
> XJ0KskSW4qT5
> --------------------------------------------------------------
> ---------------
> 
> 
> The inner application file looks as follows: With Content 
> lines terminated with 
> <LF> and the data segment with no line ends.
> 
> --------------------------------------------------------------
> --------------
> Content-Type: application/EDIFACT;
>               name="xxx.edi"
> Content-Transfer-Encoding: binary
> 
> UNA:+.? 'UNB+UNOA:1+
> 
> 
> 
> --------------------------------------------------------------
> ---------------
> 
> 
> It is my interpretation that the use of <LF> to terminate the 
> Content headers 
> in the latter two messages above is not valid.
> 
> Can someone provide me with a definitive answer.
> 
> Thanks,
> Bartley.
> 
> 
> 
> 
>