LO93709: ATTACHMENT DISPLAY NAME PARSING PROBLEM
Direct links to fixes
Closed as program error.
This customer uses Thunderbird IMAP clients. When they send an email with an attachment that has a filename with Japanese characters, the Notes and iNotes clients can display the file name correctly and can display the attachment. Unfortunately, the native iOS mobile client garbles the display name of the attachment, although it does display the attachment contents correctly. Furthermore, the iOS Verse client garbles the display name, and it does not even display the attachment. Traveler delivered a change via APAR LO93557 that causes us to uses the name from the MIME ContentDisposition header (if available) as the attachment display name, instead of always passing the file name from ContentType. Unfortunately in this case that display name is encoded wrong when Domino passes it to Traveler, so when Traveler sends that to the device, the device cannot parse the name correctly for display purposes. The iOS Verse client parses the name to decide how to display it, based on file extension (e.g., .jpg is an image), so inability to parse the name prevents display. This APAR reverses APAR LO93557, causing Traveler to send the file name from ContentType, which was working before.
Traveler mobile devices may not display attachments correctly when they are created from a third party client and contain DBCS characters.
The Traveler server has been updated to handle this scenario correctly.
This fix will be included in IBM Traveler 188.8.131.52 and all future releases. For the latest available maintenance release see this technote: http://www.ibm.com/support/docview.wss?uid=swg24019529
Reported component name
LOTUS NOTES TRA
Reported component ID
NoSpecatt / Xsystem
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fixed component name
LOTUS NOTES TRA
Fixed component ID
Applicable component levels
Translate this page: