| MM7 XML portion Content-Transfer-Encoding |  Search
|
|
NowSMS Support Forums ⬆ MMS & SMS Technical Discussions (unsupported) ⬆ Archive through August 08, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| tilman Unregistered guest |
In the nowmms documentation it is said that the MM7 XML portion of the document (the first part of the main multipart content) should not use any Content-Transfer-Encoding, it should always be expressed without any encoding Is this a 3gpp or other restrict or is this just nowmms specific? The reason I'm asking is, is that I'm using Apache Axis to develop a mm7 java api and axis or one of the associated libs (activation?mail?) always puts a Content-Transfer-Encoding header in there (7bit, if I remove the standard binary). (Maybe someone has a suggestion how/where I can remove the Content-Transfer-Encoding header for good) Thanx, Tilman} | |||
| tilman Unregistered guest |
Well, one thing I figured out: in org.apache.axis.attachments.MimeUtils.writeToMultiPartStream(java.io.OutputStrea m os, javax.mail.internet.MimeMultipart mp) replace the method body with this: mp.writeTo(os); this will bypass the javax.mail.internet.MimeMessage which adds these Content-Transfer-Encoding Header (as it should cause smtp demands it...) Anyway, its not so nice to mess with the axis distribution,anybody knows if it is really necessary ?( nowmms doesn't seem to mind ) | |||
| tilman Unregistered guest |
Ok, got a response from Bryce in another thread: Content-transfer-encoding: binary (or 8bit or 7bit) will not present any problems. We are just advising not to use "quoted-printable" or "base64" encoding for the MM7 XML portion of the document. I don't think there are any restrictions in the actual spec regarding this. It is just our restriction that we won't understand the XML if it is in "quoted-printable" or "base64". } The workaround I suggested above would take a lot more work anyway, I was only looking at the trace to the remote host, and not at the response.... | |||
