Dmitry,
I can get permission from the source and see if they want to make it
public. The company is public, so I don't see why not.
Shan
-----Original Message-----
From: Dmitry Dolinsky [mailto:dmitry.dolinsky@xxxxxxxxxxxxxx]
Sent: Wednesday, April 06, 2005 12:42 PM
To: shan.harter@xxxxxxxxxxxxx; 'Brent Haines'; 'Dale Moberg'; 'Kyle
Meadors'; ietf-ediint@xxxxxxx
Subject: 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>
>
>1835122349.20050210084222_000@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
>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: owner-ietf-ediint@xxxxxxxxxxxx
>[mailto:owner-ietf-ediint@xxxxxxxxxxxx] On Behalf Of Brent Haines
>Sent: Monday, April 04, 2005 10:56 AM
>To: Dale Moberg; Kyle Meadors; Dmitry Dolinsky; ietf-ediint@xxxxxxx
>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: owner-ietf-ediint@xxxxxxxxxxxx
>[mailto:owner-ietf-ediint@xxxxxxxxxxxx] On Behalf Of Dale Moberg
>Sent: Friday, April 01, 2005 3:01 PM
>To: Kyle Meadors; Dmitry Dolinsky; ietf-ediint@xxxxxxx
>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: owner-ietf-ediint@xxxxxxxxxxxx
>[mailto:owner-ietf-ediint@xxxxxxxxxxxx] On Behalf Of Kyle Meadors
>Sent: Friday, April 01, 2005 3:39 PM
>To: 'Dmitry Dolinsky'; ietf-ediint@xxxxxxx
>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: owner-ietf-ediint@xxxxxxxxxxxx
>[mailto:owner-ietf-ediint@xxxxxxxxxxxx]
>On Behalf Of Dmitry Dolinsky
>Sent: Thursday, March 24, 2005 8:28 PM
>To: ietf-ediint@xxxxxxx
>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.
========================================================================
======
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.
|
