IPP> Re: MIME multipart/* vs HTTP

IPP> Re: MIME multipart/* vs HTTP

Phillip M. Hallam-Baker hallam at ai.mit.edu
Thu May 1 12:19:41 EDT 1997


This is a multi-part message in MIME format.


------=_NextPart_000_01BC5629.F21A77C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


>> Besides searching for the boundary marker was very expensive
computationally, every byte had to be examnined.
>
>I think 'very' is pretty subjective, and using string matching
>algorithms like boyer-moore mean that the number of comparisons
>is reduced for longer boundary strings.




Its still prohibitive if you want to send video through the channel.
I want to be able to have http proxies perform high level routing
using minimal state and FSM graphs.


I don't care much about wasted bytes, provided they don't cause
the header to exceed the first "fast" packet and they are not a
performance problem at low bandwidth they are unlikely to be
a problem with large data sizes where the control/data ratio
is much lower.


There is absolutely no problem with a 1000 TPS server sending static
files using content length. The vast majority of Web files are static
and
this will remain so - few people use dynamic images.


HTTP has a solution to the content length for variable length data
- chunked. When chunked was proposed the problems with MIME
were understood. I would have liked to see MIME adopted and add 
a content length but that was politically incorrect and chunked is
better.


I don't see what the problem is, Web->Mail gateways have to perform
some relatively simple transformations. Big deal.


>The standard says only that the boundary string DOES NOT appear
>in the body. It happens that if you know nothing about the body
>at all, then you can implement this in a probabalistic way, e.g.,
>the likelihood that a randomly generated boundary string would
>appear in arbitrary data could be made arbitrarily small ("less
>than the probability that the computer would spontaneously explode").


Not true for real time streams which can become introspective. Imagine
you have a network monitor that is  pushing a record of network packets


onto a central display. The monitors own packets appear here from time
to time causing the marker to appear.


The probablistic argument is BOGUS and WRONG. The
probability is not infintessimal, it is real and most likely to bite
people
like us.


But since it is never necessary to use MIME with HTTP the problem 
does not appear.




   Phill


------=_NextPart_000_01BC5629.F21A77C0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"


MIIGVAYJKoZIhvcNAQcCoIIGRTCCBkECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBUMw
ggU/MIIEqKADAgECAhBhQxVohIHU1aLeK14myavFMA0GCSqGSIb3DQEBBAUAMGIxETAPBgNVBAcT
CEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xh
c3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzA0MTAwMDAwMDBaFw05ODA0MTAy
MzU5NTlaMIIBGzERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTQw
MgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJzY3JpYmVyMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4gYnkgUmVmLixMSUFC
LkxURChjKTk2MScwJQYDVQQLEx5EaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQxJDAiBgNV
BAMTG1BoaWxsaXAgTWFydGluIEhhbGxhbS1CYWtlcjEgMB4GCSqGSIb3DQEJARYRaGFsbGFtQGFp
Lm1pdC5lZHUwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAn1xytd7KYvG9xC2rzkxgAmoQLavzeX5J
hSRifuyeS0Ib8m4juKZA+SM6K+C8PAt+nfRu2/QtDFlS6KRs/ty8rQIDAQABo4ICfTCCAnkwCQYD
VR0TBAIwADCCAh8GA1UdAwSCAhYwggISMIICDjCCAgoGC2CGSAGG+EUBBwEBMIIB+RaCAadUaGlz
IGNlcnRpZmljYXRlIGluY29ycG9yYXRlcyBieSByZWZlcmVuY2UsIGFuZCBpdHMgdXNlIGlzIHN0
cmljdGx5IHN1YmplY3QgdG8sIHRoZSBWZXJpU2lnbiBDZXJ0aWZpY2F0aW9uIFByYWN0aWNlIFN0
YXRlbWVudCAoQ1BTKSwgYXZhaWxhYmxlIGF0OiBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT
OyBieSBFLW1haWwgYXQgQ1BTLXJlcXVlc3RzQHZlcmlzaWduLmNvbTsgb3IgYnkgbWFpbCBhdCBW
ZXJpU2lnbiwgSW5jLiwgMjU5MyBDb2FzdCBBdmUuLCBNb3VudGFpbiBWaWV3LCBDQSA5NDA0MyBV
U0EgVGVsLiArMSAoNDE1KSA5NjEtODgzMCBDb3B5cmlnaHQgKGMpIDE5OTYgVmVyaVNpZ24sIElu
Yy4gIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIENFUlRBSU4gV0FSUkFOVElFUyBESVNDTEFJTUVEIGFu
ZCBMSUFCSUxJVFkgTElNSVRFRC6gDgYMYIZIAYb4RQEHAQEBoQ4GDGCGSAGG+EUBBwEBAjAsMCoW
KGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L0NQUyAwEQYJYIZIAYb4QgEBBAQD
AgeAMDYGCWCGSAGG+EIBCAQpFidodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9D
UFMwDQYJKoZIhvcNAQEEBQADgYEAJh3+fz9jUp3TQecpDPMYoZLUJ42ncGftpS00xNE8ILttcpp9
CPSB38TMpr0JIyetRoMCB6M4Sq5IrNadWE/Ot5Rj//x8GjP5f2UWjZnenvCgSGbZdy0d0j+9jk9O
+sDZ2f7fKCMYabUDVatyJfIhLVlxuXChUKdiCiEiUEjOtnUxgdowgdcCAQEwdjBiMREwDwYDVQQH
EwhJbnRlcm5ldDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENs
YXNzIDEgQ0EgLSBJbmRpdmlkdWFsIFN1YnNjcmliZXICEGFDFWiEgdTVot4rXibJq8UwCQYFKw4D
AhoFADANBgkqhkiG9w0BAQEFAARAbaPLXkqsn7NibcesiCdUM0FGl+Aqw1UlfKK6SpkC+tP/9s0v
MG3ytUlHhDqslPVkV2tNgYXqGhRhM/cOiz2v7g==


------=_NextPart_000_01BC5629.F21A77C0--



More information about the Ipp mailing list