Conference iosg::all-in-1

    
    Manuela,
    
    What happens if you attempt the reverse, i.e. the EXCEL docuemnt is
    sent from the V3.1 system to V3.1 and V3.2. I'm curious to see if
    there's any change in behaviour...
    
    -Kevin.
    
    

    Hello Kevin,
    
    Sending an EXCEL attachment from ALL-IN-1 V3.1 to V3.2 works fine
    see also the extract of the 2nd NBS File in .0.
    The problems seems to be with ALL-IN-1 V3.2 when sending remote.
    
    One of our customers has reported this problems. The difference to our
    support enviroment is that he is using PMDF Gateway instead of Message
    Router. With ALL-IN-1 V3.1 he had no problems sending EXCEL attachments. 
    Since upgrading to ALL-IN-1 V3.2 the problem appeared.
    
    At customer site a Pop3 client which receives the mail with the EXCEL
    attachment sent with ALL-IN-1 V3.2 does see the following information:
    
    Date: Mon, 13 Jan 1997 12:10:20 +0100
    Subject: P:\MSOFFICE\DATEN\TEST.XLS
    MIME-version: 1.0
    Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1	<--------
    Importance: normal
    A1-format: XLS5
    A1-type: DOCUMENT
    
    
    when sent with ALL-IN-1 V3.1 it did look like:
    
    Date: Mon, 13 Jan 1997 12:10:20 +0100
    Subject: P:\MSOFFICE\DATEN\TEST.XLS
    MIME-version: 1.0
    Content-type: APPLICATION/VND.MS-EXCEL5; NAME=EXCEL5.XLS     <-------
    Content-disposition: ATTACHMENT; FILENAME=EXCEL5.XLS
    Content-transfer-encoding: BASE64
    Importance: normal
    A1-format: XLS5
    A1-type: DOCUMENT
    
    
    According to the customer nothing changed to his enviroment except the
    ALL-IN-1 upgrade.
    
    
    As there is also a problem with ALL-IN-1 V3.2 and Message Router I
    would suspect that the problem is really in ALL-IN-1 V3.2.
    
    
    
    Thanks for your help and best regards,
    Manuela

    Hello Kevin,
    
    I have done some more tests together with Grahame:
    
    ALL-IN-1 V3.2 	OA$MTI_TRNS Logical has a value of 2
    
    1) 	sending a Remote Message as VT user with a Winword and EXCEL 
    	attachment to TOLBA@A1:
    	The body text as well as the 2 attachments will be converted to
    	ASCII, independent of the priority if it is FIRST CLASS or EXPRESS
    
    2)  sending a Remote Message with TeamLinks with a Winword and EXCEL
     	attachment to TOLBA@A1 by FIRST CLASS priority:
    	The Cover Note as well as the 2 attachments will be converted to
    	ASCII.
    
    3) 	sending a Remote Message with TeamLinks with a Winword and EXCEL
    	attachment to TOLBA@A1 by EXPRESS priority:
    	The Cover Note and the EXCEL attachment are converted to ASCII but
    	the Winword document remains as Winword Document.
    
    
    
    So the questions came up:
    
    1)	Is it correct that OA$MTI_TRNS 2 does convert 'FOREIGN' attachments
    	to ASCII?  I thought that only WPS-PLUS attachments will be converted.
    
    2)	If it is correct that also 'FORGEIGN' attachments will be converted is 
    	there a way to supress this to allow to convert only WPS-Plus 
    	attachments?
     	
    3)	What does handle TeamLinks or AIDA Server (?) differently when
    	sending a message FIRST CLASS or EXPRESS?
    
    
    I am looking forward to your feedback.
    
    Thanks and regards,
    Manuela
    
    

As part of this investigation, we also wondered what is supposed to happen 
with non-WPS-PLUS attachments if oa$mti_trns is set to 2. e.g what is the 
point of converting Excel to ASCII?

Or should this be reported by IPMT?

grahame

Does no-one think this is worthy of some discussion?

It seems strange that the Sender will convert ALL non-text attachments to 
ASCII (i.e. rubbish in most cases), whereas the user is carefully prevented 
from doing this explicitly (the Convert Document option will not let you 
convert Excel for instance).

Although I appreciate the difficulty in deciding what the Sender SHOULD do, I 
don't believe the current solution is what most people would want. Or is it - 
does everyone expect their attachments to be wrecked if oa$mti_trns = 2?

grahame

    This is now a CLD.
    
    My view on this is that Grahame is right, and this is no longer the
    best solution. When WPS-PLUS was the only format that we knew how to
    convert, and that wasn't understood by some remote recipients, then
    this functionality, as it was designed and implemented, was correct.
    
    And IMHO, it's described to convert *ALL* messages to ASCII.
    
    The way forward from here is to extend the functionality so that it can
    be specified whether only WPS-PLUS, or all document types, be
    converted. This is unlikely to happen in V4.0 though.

    just some additional comment....
    
    I have opened an IPMT for this case (CFS.49186).
    
    An interesting aspect is that in ALL-IN-1 V3.1 OA$MTI_TRNS 2 only
    converted WPS-Plus attachments and left for example Winword and Excel
    as it is (as it was not possible in ALL-IN-1 V3.1 A1CONFIG to set the 
    value to 2 for OA$MTI_TRNS the customer redefined the logical and
    stopped/started the Sender).  My customer was just happy with this 
    behavior until upgraded to ALL-IN-1 V3.2.
    
    We will send also a requirement to the Product Manager.
    
    Regards,
    Manuela