RE: Filename in AS2 messages

Here we are discussing two proposals to deal with filename. It sounds like 
it is an important enough issue to be clarified in AS2 standard (perhaps 
just by referencing another standard).

Shan,

Is the standard you are referring to available for review?

--Dmitry

At 11:59 AM 4/4/2005, Shan Harter wrote:


>In other markets we have deployed systems that "take control" of the
>filename, for example. The reason is that in that market there is a need
>to track and trace a file and correspond back to its transactions within
>and all the way back to the original inbound filename. The file name
>inbound is simply recorded and new intelligent naming is created inbound
>and tracked all the way back to the transactional level. Then reports
>could be generated that not only referenced the trading partner's file
>name but also time stamps, and other attributes such as size, etc. This
>information was kept and later reported to the trading partner as a
>reference yet still allowing the receiving company to manage the naming
>of over 300 trading partners. This is important when the file name comes
>in as just .payload or edi. There are a lot of applications that send
>the same name.
>
>
>A standard was created that did this
>
><TO_DUNS>.<TIMESTAMP><SEQ>@<DOMAIN><ORIGINALFILENAME>
>
>[email protected]_03_STK10.edi.pgp
>
>Other implementations took this approach
>
><DUNS><TS>_<SEQ>@domain
>
>My recommendation is that file name control be managed by the system
>receiving with reverences to the received filename.
>
>Regards,
>Shan
>
>Shan Harter
>Project Services
>Systrends, Inc.
>7855 South River Parkway
>Tempe Arizona, 85284
>ph:  480-756-6777 Ext 205,
>fax: 480-756-9755, cell: 602-821-2951
>
>
>
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]] On Behalf Of Brent Haines
>Sent: Monday, April 04, 2005 10:56 AM
>To: Dale Moberg; Kyle Meadors; Dmitry Dolinsky; [email protected]
>Subject: RE: Filename in AS2 messages
>
>
>
>Filename preservation isn't necessary. That implies that I can name a
>file that will appear on your system with that filename.
>
>What we are getting from several users is a requirement to have the
>original filename in some standard header in the message such as the
>Content-Disposition Header. We can implement that for our products, but
>it seems like the kind of thing that should be part of the standard.
>
>I can see no real security issues with this and no changes to how the
>standard works other than to allow trading partners to track the
>filename through the transaction.
>
>-Brent Haines
>  Tumbleweed Communications
>
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]] On Behalf Of Dale Moberg
>Sent: Friday, April 01, 2005 3:01 PM
>To: Kyle Meadors; Dmitry Dolinsky; [email protected]
>Subject: RE: Filename in AS2 messages
>
>
>Applications can make use of Content-Disposition Header and not violate
>AS1,2 (and I think 3) but this is not specifically and explicitly
>mentioned in the applicability statements. It is certainly not mandated
>behavior and implementations should not depend on the behavior to
>interoperate.
>
>Historically, there were security concerns about threats/exploits when
>not checking filenames (and especially filenames with a full path). Kyle
>also points out that there are not overwhelmingly convincing use cases
>for letting/requiring the partner saying what the filename should be on
>the system. Early experience back in the late 90s with AS1 showed that
>implementations were not always good about using unique filenames; so
>operational problems of clobbering data could show up for incautious
>implementations. The safest bet when implementing was to have the
>receiver ensure no-clobbering, and an easy way to do that was to just
>ignore the suggested filenames.
>
>I am unconvinced we should open this up again without clear and
>persuasive end-user requirements for why this functionality is needed.
>
>Dale Moberg
>
>
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]] On Behalf Of Kyle Meadors
>Sent: Friday, April 01, 2005 3:39 PM
>To: 'Dmitry Dolinsky'; [email protected]
>Subject: RE: Filename in AS2 messages
>
>
>Dmitry,
>
>Generally, I did not consider filenames of EDI/XML payloads to be
>significant in themselves. The information in the EDI interchanges is
>not treated differently because of the filename. What would be the
>benefit of your trading partner knowing the filename?
>
>Kyle Meadors
>DGI
>
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]]
>On Behalf Of Dmitry Dolinsky
>Sent: Thursday, March 24, 2005 8:28 PM
>To: [email protected]
>Subject: Filename in AS2 messages
>
>
>I'd like to clarify how the filenames are expected to be communicated in
>
>AS2. Since AS2 data is represented by MIME body, the implication is that
>
>Content-Disposition header can be used for that purpose.
>
>Is this a correct assumption?
>
>If so, it would be great if AS2 spec made an explicit reference to
>RFC-2183
>(update of rfc1806) "Communicating Presentation Information in Internet
>Messages: The Content-Disposition Header Field"  with respect to AS2
>filename. I've noticed that the header is included in the samples that
>accompany the specification but making it explicit would improve
>interoperability.
>
>Also, as a practical question, do current AS2 implementation include
>Content-Disposition header with filename parameter when sending and look
>
>for it when receiving as far as people know?
>
>Thank you.
>
>Dmitry Dolinsky
>Tumbleweed Communications Corp.
>
>
>"Tumbleweed E-mail Firewall <tumbleweed.com>" made the following
>annotations on 03/24/05 18:34:12
>------------------------------------------------------------------------
>----
>--
>This e-mail, including attachments, may include confidential and/or
>proprietary information, and may be used only by the person or entity to
>which it is addressed.  If the reader of this e-mail is not the intended
>recipient or his or her authorized agent, the reader is hereby notified
>that any dissemination, distribution or copying of this e-mail is
>prohibited. If you have received this e-mail in error, please notify the
>sender by replying to this message and delete this e-mail immediately.
>========================================================================
>====
>==
>
>
>--
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.308 / Virus Database: 266.7.4 - Release Date: 3/18/2005
>
>
>--
>No virus found in this outgoing message.
>Checked by AVG Anti-Virus.
>Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 3/30/2005
>
>
>
>
>
>"Tumbleweed E-mail Firewall <tumbleweed.com>" made the following
>annotations on 04/04/05 11:01:26
>------------------------------------------------------------------------
>------
>This e-mail, including attachments, may include confidential and/or
>proprietary information, and may be used only by the person or entity to
>which it is addressed.  If the reader of this e-mail is not the intended
>recipient or his or her authorized agent, the reader is hereby notified
>that any dissemination, distribution or copying of this e-mail is
>prohibited. If you have received this e-mail in error, please notify the
>sender by replying to this message and delete this e-mail immediately.
>========================================================================
>======
>
>
>
>CONFIDENTIALITY NOTE:
>This message and any of the attached documents contain privileged and
>confidential information only for the use of the individual or entity
>that was the intended recipient.  If you are not the  intended recipient
>you may not read, copy, distribute, retain or use this information. If
>you have received this message and any of the attached documents in
>error, please immediately notify the sender by reply e-mail and then
>delete this message.  Thank you.


"Tumbleweed E-mail Firewall <tumbleweed.com>" made the following
 annotations on 04/06/05 12:47:38
------------------------------------------------------------------------------
This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed.  If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
==============================================================================